Diplomarbeit. Entwurf, Implementierung und Aufbau eines Testbeds für drahtlose Sensornetz-Anwendungen

Transkript

1 Brandenburgische Technische Universität Cottbus Institut für Informatik Lehrstuhl Systeme Diplomarbeit Entwurf, Implementierung und Aufbau eines Testbeds für drahtlose Sensornetz-Anwendungen Hendrik Salomon Cottbus, 7. Mai 2012 Betreuer: Erstgutachter: M. Sc. Marcin Brzozowski Prof. Dr. rer. nat. Peter Langendörfer

2 Eidesstattliche Erklärung Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht. Frankfurt (Oder), 7. Mai 2012

3 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Listingverzeichnis Abkürzungsverzeichnis iv v v vi 1. Einleitung Drahtlose Sensornetze Testen von Anwendungen für Sensornetze Ziel und Aufbau der Arbeit Testbeds Existierende Testbeds MoteLab Kansei ORBIT TWIST Intel Research Berkeley SensorNet Testbed MiNT Testbed-Design Hardware Management Nutzung Entwurf des IHP-Testbeds Anforderungen und Gegebenheiten Vermeidung von Störungen durch WLAN und andere Sensornetze Architektur Testbed-Server Knotenserver Testbed-Sockets Sensorknoten i

4 Inhaltsverzeichnis 3.3. Nutzung Benutzerschnittstelle Jobs Log-Dateien Simulation von Knotenausfall und Hinzufügen neuer Knoten Zeitsynchronisation Ressourcenzuteilung Job-Lebenszyklus Start des Testbeds Erstellen eines neuen Jobs Ausführung des Jobs Abrufen der Ergebnisse und Löschen des Jobs Ermittlung der Konnektivität Testbed-Überwachung Verhalten bei Hardwareausfall Testbed-Software Software-Architektur Start der Testbed-Software Implementierung der Testbed-Software Stand der Implementierung Aufbau und Funktionsweise des Codes Testbed-Server Knotenserver Timer TCP Transceiver Node Manager Job Runner Unterstützung weiterer Sensorknotenplattformen und -betriebssysteme Voraussetzungen Notwendige Anpassungen / Erweiterungen des Codes Testlauf Vorgehensweise Versuchsaufbau Software Planung und Ablauf der Tests Erwartete Ergebnisse Ergebnisse und Auswertung Testergebnisse ii

5 Inhaltsverzeichnis Auswertung Zusammenfassung und Ausblick Zusammenfassung Ausblick A. Anhang 67 A.1. Übersicht Testbeds A.2. Testbed-Datenbank A.3. Sequenzdiagramme Job-Lebenszyklus A.4. Zwischen den Testbed-Komponenten ausgetauschte Nachrichten Literaturverzeichnis viii iii

6 Abbildungsverzeichnis 2.1. TWIST-Architektur MiNT-Architektur MiNT-Core-Node mit Roboter IEEE und IEEE Kanäle Architektur des IHP-Testbeds Programmierdauer auf fit-pc2i mit Intel SCH US15W-Chip Programmierdauer auf Desktop-PC mit Intel ICH10-Chipsatz IEEE MAC Frame Komponenten der Testbed-Software Ablauf des Testbed-Server-Programms Verwendung der Klasse Timer in anderen Klassen Ablauf vom Starten eines Timers bis zum Aufruf der Handler-Methode Arbeitsweise der TCP-Transceiver-Komponente beim Senden von Nachrichten und Dateien Verwaltung verschiedener Sensorknotenplattformen im Node Manager Versuchsaufbau in einem Büroraum des IHP Rollen der Sensorknoten Routen von den Quellen zur Senke Empfangsraten der Quell-Nachrichten bei der Senke Änderung der Routen in Testlauf 3 nach Ausfall von Knoten A.1. Schema der Testbed-Datenbank A.2. Job-Lebenszyklus 1: Testbed-Start und Erstellen eines neuen Jobs A.3. Job-Lebenszyklus 2: Ausführung des Jobs A.4. Job-Lebenszyklus 3: Abrufen der Ergebnisse und Löschen des Jobs iv

7 Tabellenverzeichnis 5.1. Testparameter A.1. Testbed-Übersicht (Teil 1) A.2. Testbed-Übersicht (Teil 2) Listingverzeichnis 3.1. Aufbau der Jobkonfigurationsdatei Beispiel für eine Jobkonfigurationsdatei Jobkonfigurationsdatei für die Testläufe v

8 Abkürzungsverzeichnis BSP ELF FCFS GUI IEEE IHP IRB ISM JCF LQI MAC MiNT MPDU NTP OML ORBIT OSI POSIX PTP RSSI SNMP SPI Benutzerschnittstellenprogramm Executable and Linkable Format First-Come, First-Served Graphical User Interface Institute of Electrical and Electronics Engineers Leibniz-Institut für innovative Mikroelektronik Intel Research Berkeley Industrial, Scientific and Medical Job Configuration File Link Quality Indication Media Access Control Miniaturized Network Testbed MAC Protocol Data Unit Network Time Protocol ORBIT Measurement Library Open Access Research Testbed for Next-Generation Wireless Networks Open Systems Interconnection Portable Operating System Interface Precision Time Protocol Received Signal Strength Indication Simple Network Management Protocol Serial Peripheral Interface vi

9 Abkürzungsverzeichnis SPOF SQL TCP TKN TOSSIM TWIST UART USB WINLAB WLAN WSN XSM Single Point of Failure Structured Query Language Transmission Control Protocol Telecommunication Networks Group TinyOS Simulator TKN Wireless Indoor Sensor network Testbed Universal Asynchronous Receiver/Transmitter Universal Serial Bus Wireless Information Network Laboratory Wireless Local Area Network Wireless Sensor Network extreme Scale Mote vii

10 1. Einleitung 1.1. Drahtlose Sensornetze Drahtlose Sensornetze (engl. Wireless Sensor Network (WSN)) sind Rechnernetze, bestehend aus kleinen, per Funk kommunizierenden Computern den sogenannten Sensorknoten. Ihre Hauptaufgabe ist es, ihre Umgebung mit Sensoren (z. B. für Lichtstärke, Temperatur, Feuchtigkeit, Druck, etc.) zu erfassen und die gewonnenen Informationen zur Auswertung weiterzuleiten. Charakteristisch für Sensorknoten sind, neben ihrer geringen Größe (Kreditkartengröße bis Staubkorngröße), ihre stark begrenzten Ressourcen. Der Sensorknoten Tmote Sky [Mot06b] beispielsweise verfügt über einen Mikrocontroller mit 8 MHz Taktfrequenz, 10 kb Arbeitsspeicher und 48 kb Flashspeicher. Das größte Problem stellen jedoch die begrenzten Energieressourcen dar. Für Sensornetze gibt es vielfältige Einsatzmöglichkeiten. Sie können z. B. verwendet werden zur Überwachung der Statik von Gebäuden, des Wetters und Klimas, kritischer Infrastrukturen wie Pipelines oder Stromnetze oder auch der Vitalfunktionen von Menschen. Momentan existieren hauptsächlich Versuchs- und Demonstrationssensornetze. Dies wird sich jedoch durch die stetige Forschung und Weiterentwicklung im Bereich Sensornetze und der damit einhergehenden weiteren Verkleinerung der Sensorknoten zukünftig ändern. Langfristig sollen Sensornetze aus hunderten bis tausendenden von Sensorknoten bestehen. Ohne die auf den Sensorknoten laufende Software wäre allerdings jedes Sensornetz funktionslos. Wie jede andere Software muss auch die Software für Sensorknoten vor dem Produktiveinsatz gründlich getestet werden. Welche Möglichkeiten es dafür gibt, wird im folgenden Abschnitt beschrieben Testen von Anwendungen für Sensornetze Während der Entwicklung der Software für Sensorknoten können verschiedene Techniken zum Testen genutzt werden: Simulation, Emulation, Testbeds und Real-Welt-Tests. Die Vorteile von Simulatoren und Emulatoren liegen in der einfachen Wiederholbarkeit der Tests, Anpassbarkeit der Testparameter und Auswertung der Ergebnisse. Sie eignen sich dadurch gut für die Validierung der prinzipiellen Funktionsweise von Algorithmen und 1

11 1 Einleitung Protokollen unter kontrollierten Bedingungen und für die Fehlersuche. Schlussfolgerungen über das Verhalten von Anwendungen in realen Sensornetzen lassen sich jedoch nur bedingt aus Simulationen ableiten. In Simulatoren wird mithilfe von Modellen (z. B. für den Funkkanal oder den Energieverbrauch) versucht, die Realität so gut wie möglich nachzubilden. Dabei müssen vereinfachende Annahmen getroffen werden, da die reale Welt kaum exakt nachgebildet werden kann. Eine zu starke Vereinfachung der Modelle kann jedoch zu Ergebnissen führen, die das Verhalten in der realen Welt nicht widerspiegeln [KNG + 04]. Je detaillierter und exakter die Modelle sind, desto mehr Rechenleistung wird für die Simulation benötigt. Es muss also immer ein Kompromiss zwischen Genauigkeit und damit Zuverlässigkeit der Ergebnisse und Rechenaufwand gefunden werden. Hinzu kommt, dass die meisten Simulatoren in der Standardkonfiguration nicht für die Simulation von drahtlosen Sensornetzen geeignet sind. Eine Untersuchung von fünf weit verbreiteten Simulatoren (darunter ns-2 und OMNeT++) in [KSKT09] hat ergeben, dass sie alle angepasst oder erweitert werden müssen, um für die Simulation von Sensornetzen geeignet zu sein, da die mitgelieferten Modelle und Protokolle zu stark vereinfacht oder vom falschen Typ waren. Ein weiteres Problem besteht in der Verwertbarkeit von Simulationsergebnissen. Bei einer Studie in [CSS02] wurde der Flooding-Algorithmus in drei Simulatoren für Mobile Adhoc-Netze (MANET) simuliert. Die Simulationsergebnisse wichen stark voneinander ab und waren teilweise kaum vergleichbar. Die Unterschiede waren nicht nur quantitativer, sondern auch qualitativer Natur. Die zuverlässigsten Ergebnisse liefern sogenannte Real-Welt-Tests, bei denen ein Sensornetz für einen konkreten Testfall aufgebaut wird. Ein Nachteil dabei ist, dass bei jeder Programm- oder Parameteränderung die Sensorknoten eingesammelt, neu programmiert und wieder verteilt werden müssen, wodurch solche Tests vor allem bei einer großen Anzahl von Sensorknoten sehr zeit- und damit kostenaufwendig sind. Eine Brücke zwischen Simulation und Real-Welt-Tests bilden die sogenannten Testbeds. Ein Testbed ist eine Plattform bzw. Testumgebung für Experimente und Forschung. Im Gegensatz zu Softwaresimulatoren bestehen Testbeds aus realer Hardware, welche den physikalischen Einflüssen der Umgebung ausgesetzt ist. Dadurch sind die Testergebnisse realistischer als die von Simulatoren. Testbeds für drahtlose Sensornetze oder lokale Funknetze (engl. Wireless Local Area Network (WLAN)) bestehen je nach Anforderungen und Budget aus einigen wenigen bis mehreren hundert Knoten (Sensorknoten bzw. WLAN-fähige Geräte), auf denen die zu testende Anwendung ausgeführt wird. Zum Einsatz kommt dabei entweder Spezialhardware oder sogenannte Off-the-shelf-Hardware (seriengefertigte Produkte). Die Testbed-Knoten werden dabei einmalig ausgebracht und von einer zentralen Stelle, dem Testbed-Server, programmiert und gesteuert (z. B. ein- und ausgeschaltet). Das Einsammeln, manuelle Programmieren und erneute Verteilen der Kno- 2

12 1 Einleitung ten entfällt damit. Tests in Testbeds sind damit kostengünstiger als Real-Welt-Tests und liefern zugleich realistischere Ergebnisse als Simulationen. Der Zugriff auf den Testbed- Server und damit auf die Funktionen des Testbeds erfolgt über eine Benutzerschnittstelle (z. B. Web-Interface oder Kommandozeile). Je nach Design des Testbeds erhalten die Benutzer direkten Zugriff auf die Knoten oder können Experimente für die automatische Ausführung konfigurieren und einplanen, wobei auch die von den Knoten gesendeten Testergebnisse automatisch eingesammelt werden. Die Speicherung der Experimentkonfigurationen und -ergebnisse erfolgt meist in einer Datenbank, die entweder direkt auf dem Testbed-Server oder auf einem separaten Datenbankserver verwaltet wird. Einige Testbeds bieten die Möglichkeit, während eines Experiments die Testbed-Knoten zu manipulieren. Dazu werden z. B. Daten an sie gesendet oder einzelne Knoten ein- oder ausgeschaltet. Auf diese Weise können Ereignisse und Fehler simuliert werden Ziel und Aufbau der Arbeit Das Ziel dieser Diplomarbeit ist der Entwurf und Aufbau eines Sensornetz-Testbeds für die Forschung im Leibniz-Institut für innovative Mikroelektronik (IHP) 1 in Frankfurt (Oder). Dazu werden in Kapitel 2 existierende Testbeds vorgestellt und Anforderungen an das Design von Testbeds abgeleitet. Darauf aufbauend wird in Kapitel 3 das IHP-Testbed entworfen und beschrieben. Die Implementierung der Testbed-Software wird in Kapitel 4 erläutert. Test und Bewertung des Testbeds erfolgen in Kapitel 5. Kapitel 6 fasst schließlich die Diplomarbeit zusammen und gibt einen Ausblick auf mögliche Erweiterungen und Verbesserungen des Testbeds

13 2. Testbeds Testbeds werden an vielen Universitäten und wissenschaftlichen Einrichtungen auf der ganzen Welt für die Forschung und Entwicklung eingesetzt. Im ersten Abschnitt dieses Kapitels sollen einige dieser Testbeds vorgestellt werden. Dabei werden nicht nur Sensornetz-, sondern auch WLAN-Testbeds betrachtet, da sich diese hinsichtlich Aufbau und Funktionsweise nicht wesentlich von Sensornetz-Testbeds unterscheiden. Eine Übersicht der vorgestellten Testbeds befindet sich in Anhang A.1. Im zweiten Abschnitt werden Anforderungen an das Design von Testbeds abgeleitet und erläutert Existierende Testbeds MoteLab MoteLab [WASW05] ist ein öffentliches Testbed der Harvard University für Forschung und Lehre. Es wurde im Jahr 2004 installiert und erstreckt sich über drei Etagen des Maxwell Dworkin Laboratory (Electrical Engineering and Computer Science building). Es besteht gegenwärtig aus 184 Tmote Sky Sensorknoten von Moteiv, auf denen das Betriebssystem TinyOS läuft. Die Sensorknoten sind an Tmote Connects 2 angeschlossen, die je zwei Ethernet-Ports besitzen. Ein Port wird für die Programmierung der Sensorknoten verwendet, über den anderen kann direkt auf den seriellen Port der Knoten zugegriffen werden. Die Tmote Connects sind per Ethernet mit einem zentralen Server verbunden, der das Testbed verwaltet und ein Web-Interface zur Verfügung stellt. Er ist zuständig für die Ausführung von Jobs 3, das Programmieren der Sensorknoten und das Speichern der von den Knoten gesendeten Daten. Die Software auf dem Server besteht aus folgenden Komponenten: MySQL-Datenbank speichert die Experimentdaten (Programme und Ergebnisse), Benutzerinformationen, Informationen über den Zustand des Testbeds und den Inhalt für das Web- Interface 2 Linksys NSLU2 mit Moteiv Tmote Connect Software 3 Ein Job beschreibt die Konfiguration eines Experiments, inkl. der auszuführenden Anwendung(en), einer Liste der beteiligten Knoten und anderer Parameter. 4

14 2 Testbeds Web-Interface Nutzung durch lokale und externe Benutzer; Möglichkeit für Benutzer neue Jobs zu erstellen und einzuplanen und Ergebnisse abzurufen; zudem verschiedene Verwaltungsfunktionen für Administratoren DBLogger verbindet sich mit dem Tmote-Connect-Port für den Zugriff auf den seriellen Port der Sensorknoten und empfängt die von den Knoten gesendeten Daten, bereitet sie auf und speichert sie in der Datenbank Job Daemon Perl-Skript zum Starten (Knoten programmieren, DBLogger starten,...) und Beenden (Knoten deaktivieren, gestartete Prozesse beenden,...) von Jobs Die Nutzung des Testbeds durch mehrere Benutzer wird geregelt durch ein Zeitkontingent, dass jedem Benutzer zur Verfügung steht. Es gibt die maximale Gesamtlaufzeit aller eingeplanten Jobs eines Benutzers an. Die Abfrage der Ergebnisse eines Experiments erfolgt entweder über das Web-Interface oder durch direkten Zugriff auf die Datenbank. Der Datenbankzugriff ermöglicht die Analyse der Ergebnisse mithilfe der Structured Query Language (SQL). MoteLab bietet dem Benutzer darüberhinaus Zugriff auf den seriellen Port der Sensorknoten (über den Ethernet-Port der Tmote Connects), wodurch er während eines Experiments direkt mit den Sensorknoten interagieren und z. B. Daten an sie senden oder empfangen kann. Es ergeben sich daraus zwei Arten der Nutzung des MoteLab-Testbeds: Der Benutzer kann Jobs einplanen, automatisch ausführen lassen und anschließend die Ergebnisse abrufen. Er kann aber auch während der Ausführung eines Jobs Einfluss nehmen (durch Senden von Daten an einen Knoten) oder in Echtzeit die Ausgaben der Sensorknoten überwachen. Auch die bereits von den Sensorknoten empfangenen Daten können jederzeit in der Datenbank eingesehen werden. Eine weitere Besonderheit von MoteLab ist ein an einen Sensorknoten angeschlossenes Multimeter mit Netzwerkanschluss, mit dem sich der Energieverbrauch des Knotens während eines Experiments beobachten lässt. Die Konnektivität zwischen den Sensorknoten wird regelmäßig durch einen sogenannten Connectivity Daemon ermittelt. Dabei verbindet sich ein Java-Programm mit den Sensorknoten und sagt ihnen, wann sie Nachrichten senden sollen und wann Nachrichten zu 5

15 2 Testbeds empfangen sind. Nach Abschluss dieses Jobs wird die Paketverlustrate für jedes Knotenpaar berechnet und in der Datenbank gespeichert. Die so gewonnenen Konnektivitätsinformationen sind auf der MoteLab-Webseite 4 in Form einer Karte abrufbar Kansei Das öffentlich zugängliche Kansei-Testbed [EAR + 06] der Ohio State University wurde 2004 aufgebaut und seitdem ständig weiterentwickelt. Es soll die Forschung in großen Sensornetzen ermöglichen und besteht gegenwärtig aus 96 sogenannten Kansei-Knoten. Jeder dieser Knoten besteht aus einem extreme Scale Mote (XSM), vier TelosB und einem Imote2, welche alle an ein extreme Scale Stargate 5 angeschlossen sind. Das Stargate verbindet den Kansei-Knoten per Ethernet mit dem Rest des Testbeds. Außerdem läuft über sie die Programmierung und Kommunikation mit den Sensorknoten. Auf den Sensorknoten kommt TinyOS als Betriebssystem zum Einsatz. Die Hauptmerkmale von Kansei sind: heterogene Hardware-Infrastruktur Hybrid-Simulation von großen Sensornetzen Sensordatengenerierung und Einspeisung in das Testbed Softwarekomponenten für komplexe Experimente, die alle drei Ebenen der Kansei- Hardware umfassen (PCs, Stargate-Netzwerk und Sensorknoten) unter Verwendung von realer Hardware, Sensordatengenerierung und Simulation Die Verwaltung der Job-Konfigurationen erfolgt wie bei MoteLab in einer MySQL-Datenbank. Die gesammelten Testdaten werden jedoch im Dateisystem gespeichert. Für ein Experiment können alle Sensorknoten-Typen verwendet werden, sodass Anwendungen für heterogene Sensornetze getestet werden können. Die Generierung von Sensordaten für die Einspeisung ins Testbed erfolgt entweder auf der Basis von echten Messwerten oder mithilfe von parametrischen und/oder Wahrscheinlichkeits-Sensor-Modellen. Zum Testbed gehört neben den Kansei-Knoten ein per Ethernet angebundener PC-Cluster. Ein PC dieses Clusters fungiert als Testbed-Server und ermöglicht Fernzugriff auf das Testbed via Web-Interface. Die anderen PCs werden für Visualisierungen, Analysen, Sensordatengenerierung und die Hybrid-Simulation verwendet Single-Board Linux Computer von Crossbow 6

16 2 Testbeds Kansei-Director Auf dem Testbed-Server läuft der Kansei-Director, eine erweiterbare Softwareplattform bestehend aus mehreren Werkzeugen und Laufzeitkomponenten. Die bereitgestellten Dienste umfassen das Erstellen und Einplanen von Experimenten, Abrufen der Ergebnisse, Überwachung und Verwaltung der Hardware (Sensorknoten, Stargates), Verwaltung von Testbed-Konfigurationen (für ein Experiment verwendete Knoten und Topologie) und die administrative Verwaltung (u. a. Benutzerkonten) des Testbeds. Der Director enthält zudem Werkzeuge für die Einspeisung von Sensordaten in das Testbed, zum Sammeln von Testdaten und für die Hybrid-Simulation. Die Director-Plattform beinhaltet auch Dienste, die auf den Stargates und Sensorknoten laufen. Dazu gehört z. B. eine TinyOS- Komponente für den Empfang von eingespeisten Sensordaten, die in die Software für die Sensorknoten integriert ist. Hybrid-Simulation Die Hybrid-Simulation ist eine Kombination von Simulation und realer Hardware. Es können hunderte virtuelle Sensorknoten mittels TOSSIM [LLWC03] simuliert werden. Für das Senden und Empfangen von Nachrichten und das Messen von Sensorwerten werden jedoch die realen Sensorknoten des Testbeds verwendet. Die Zuordnung zwischen virtuellen und realen Knoten ist dynamisch, sodass Sensornetze simuliert werden können, die deutlich größer sind als das physische Testbed. Durch die Verwendung realer Hardware für die Simulation wird ein Nachteil vieler Simulatoren (zu stark vereinfachende und dadurch ungenaue Modelle z. B. für die Funkausbreitung) eliminiert. Testbed-Überwachung Für die Überwachung des Testbeds wird Chowkidar [BLK + 07] verwendet, dass regelmäßig und auf Anfrage aktualisierte Informationen über den Zustand der verschiedenen Hardwarekomponenten des Testbeds zur Verfügung stellt. Chowkidar unterscheidet dabei zwischen Geräte-, Netzwerk- und Softwarefehlern ORBIT Das Open Access Research Testbed for Next-Generation Wireless Networks (ORBIT) [RSO + 05] ist ein 2005 gestartetes Gemeinschaftsprojekt von Forschungsgruppen der Universitäten Rutgers, Columbia und Princeton sowie den Industriepartnern Lucent Bell Labs, IBM Research und Thomson. Es wird entwickelt und betrieben am Wireless Information Network Laboratory (WINLAB) der Rutgers University. Das frei zugängliche Testbed dient der Evaluation von Drahtlosnetzwerkprotokollen. 7

17 2 Testbeds Designziele: Skalierbarkeit bzgl. der Anzahl an Testbed-Knoten (mehrere hundert) Reproduzierbarkeit der Experimente Flexibilität (Kontrolle über auf den Knoten eingesetzte Protokolle und Software) umfangreiche Messmöglichkeiten auf Ebene der Bitübertragungs-, Sicherungs- (u. a. Media Access Control (MAC)) und Vermittlungsschicht des Schichtenmodells der Open Systems Interconnection (OSI) Fernzugriff, automatischer Betrieb und Robustheit gegenüber Software- und Hardware-Fehlern Das Testbed besteht aus zwei Teilen einem 20 mal 20 Knoten großen Netz in einem Raum des WINLAB für reproduzierbare Experimente unter kontrollierten Bedingungen und einem Netz im Außenbereich für Experimente unter realen Bedingungen. Das Netz im Innenbereich wird verwendet um Konzepte für Protokolle oder Anwendungen zu validieren. Anschließend kann ein Test im Außenbereich unter realistischeren Bedingungen erfolgen. Dafür steht eine frei konfigurierbare Mischung aus dem Mobilfunkstandard 3G und WLAN nach verschiedenen Standards des Institute of Electrical and Electronics Engineers (IEEE) zur Verfügung. Das Netz im Außenbereich umfasst ein 5 km breites und 2 km langes Gebiet inkl. Universitätscampus, Vor- und Innenstadt. Im Folgenden wird das Netz im Innenbereich genauer beschrieben. Es besteht aus folgenden Hardwarekomponenten: ORBIT radio nodes (Testbed-Knoten) ausgestattet mit 1-GHz-CPU, 512 MB Arbeitsspeicher und 20 GB Festplatte, zwei a/b/g-WLAN-Karten für die Kommunikation mit den anderen Testbedknoten, zwei Ethernet-Anschlüsse für Steuerung bzw. Abrufen von Daten; eingebaut in ein spezielles Gehäuse zur Überwachung des Zustands der Knotenhardware und zum Einschalten, Ausschalten und Neustarten der Knoten Subsystem zur Messung von Funksignalen und zur Erzeugung verschiedenartiger, künstlicher Interferenzen unabhängiges WLAN-Überwachungssystem auf Ebene der MAC- und Vermittlungsschicht Webserver, Datenbankserver und Server für die Ausführung der Experimente 8

18 2 Testbeds Die Knoten des Testbeds können für ein Experiment dynamisch zu verschiedenen Topologien verbunden werden. Benutzer des Testbeds haben vollen Zugriff auf die Knoten. Sie können eigene Betriebssystem-Abbilder und Softwarepakete verwenden, die Knoten steuern und neustarten und auf die Konsole und Log-Dateien zugreifen. Dadurch lassen sich spezielle Netzwerk- und Anwendungsszenarien für den Test von Netzwerkprotokollen und Anwendungen maßschneidern. Zu den Softwarekomponenten von ORBIT zählen u. a. Bibliotheken für die Erzeugung von Datenverkehr, Standard MAC-, Vermittlungs- und Transportschichtprotokolle und Werkzeuge für die Messung von Durchsatz, durchschnittlicher Verzögerung und Paketverlustrate. Sie unterstützen zudem die Benutzer bei der Entwicklung eigener Anwendungen, Protokollstapel, Änderungen an der MAC-Schicht und anderen Experimenten. Das ORBIT-Framework besteht aus folgenden Komponenten: 1. Verwaltungs- und Steuerungssoftware Node Handler führt Experiment-Skripte (Konfiguration eines Experiments inkl. verwendete Knoten, Konfiguration der Netzwerkschnittstellen, auszuführende Anwendungen und Bibliotheken) aus und sendet die im Skript definierten Ereignisse bzw. Kommandos an sogenannte Node Agents (einer pro Testbed-Knoten) Collection Server sammelt und speichert Messwerte, die von den Testbed-Knoten empfangen werden; Abruf und Analyse der Daten kann während und nach einem Experiment erfolgen Disk-Loading Server ermöglicht schnellen Austausch der Systemabbilder auf den Testbed-Knoten 2. Software für die ORBIT-Knoten Node Agent empfängt die Kommandos vom Node Handler, führt sie aus und gibt anschließend Rückmeldung; kann die auf dem angeschlossenen Testbed-Knoten laufende Anwendung starten und stoppen, Parameter an sie übergeben und den aktuelle Status des Experiments ermitteln ORBIT Measurement Library (OML) definiert Datenstrukturen und Funktionen für das Senden/Empfangen und Codieren/Decodieren von Messdaten; wird verwendet auf den Testbed-Knoten und dem Collection Server 9

19 2 Testbeds Libmac C-Bibliothek für das Einspeisen und Abfangen von MAC-Rahmen, Manipulation von WLAN-Parametern (Sendeleistung und Kanal) und Aufzeichnung der Empfangsfeldstärke (engl. Received Signal Strength Indication (RSSI)) und Rauschen TWIST TKN Wireless Indoor Sensor network Testbed (TWIST) [HKWW06] ist eine skalierbare und flexible Testbed-Architektur für das Experimentieren mit drahtlosen Sensornetzen, entwickelt von der Telecommunication Networks Group (TKN) der Technischen Universität Berlin. Die TKN betreibt ein auf dieser Architektur basierendes Testbed an der TU Berlin. Es erstreckt sich über drei Etagen und besteht aus 102 Tmote Sky und 102 eyesifx Sensorknoten. Abbildung 2.1.: TWIST-Architektur Quelle: [HKWW06] 10

20 2 Testbeds Die TWIST-Architektur (siehe Abbildung 2.1) besteht aus folgenden Hardwarekomponenten: Sensorknoten Für die externe Stromversorgung, Programmierung und Kommunikation (zum Empfang der von der Anwendung gesendeten Daten) müssen die Sensorknoten eine geeignete Hardware-Schnittstelle besitzen. TWIST setzt dabei auf den Universal Serial Bus (USB), sodass alle Sensorknoten, die die genannten Funktionen über USB realisieren, verwendet werden können. Dadurch sind auch Experimente mit heterogenen Sensorknotenplattformen möglich. Testbed-Sockets und USB-Kabel Ein Testbed-Socket ist in der TWIST-Architektur der Punkt, wo ein Sensorknoten per USB mit dem Testbed verbunden ist. Jeder Socket hat eine eindeutige ID und seine Position im Testbed ist bekannt. Durch die Zuordnung von Sensorknoten zu Sockets ist damit auch die Position der Sensorknoten bekannt. Technisch gesehen sind die Sockets die Enden von USB-Kabeln, welche an USB-Hubs angeschlossen sind. Dabei können auch aktive USB-Kabel (USB-Hub mit einem Port) verwendet werden um größere Distanzen zu überbrücken. USB-Hubs USB-Hubs bieten zunächst einmal die Möglichkeit, mehr als einen Sensorknoten an einen Super Node anzuschließen. Viel wichtiger für die TWIST-Architektur ist jedoch die in der USB 2.0 Spezifikation [CHPI + 00] beschriebene Möglichkeit, die Stromversorgung der USB-Ports eines Hubs ein- und auszuschalten. Sind die Sensorknoten mit Batterien ausgestattet, kann so zwischen Batterie- und USB-Stromversorgung umgeschaltet werden. Bei Sensorknoten ohne Batterien kann zudem der Ausfall und das Hinzufügen neuer Knoten simuliert werden. Dies ist z. B. beim Test der Robustheit von Routingprotokollen sehr hilfreich. Allerdings unterstützt nicht jeder Hub diese Funktionalität. Im TWIST-Testbed der TKN werden USB2HUB4 von Linksys verwendet. Super Nodes Allein mit USB könnten nur 127 Geräte (Hubs und Sensorknoten) im Testbed verwendet werden. Gleichzeitig wäre die geographische Größe des Testbeds begrenzt. Da die TWIST- Architektur aber auch größere Testbeds unterstützen soll, kommen sogenannte Super Nodes zum Einsatz. Diese benötigen mindestens einen USB-Anschluss für den Anschluss der Hubs. Zudem müssen sie eine zweite Kommunikationstechnologie unterstützen, die 11

21 2 Testbeds nicht die gleichen Einschränkungen wie USB hat. Diese zweite Kommunikationstechnologie bildet das Backbone des Testbeds, woran auch der Server und die Control Station angeschlossen sind. Die Super Nodes sind zuständig für das Programmieren der Sensorknoten, die Steuerung der Stromversorgung der USB-Hub-Ports und das Speichern der von den Sensorknoten gesendeten Daten. Diese Daten können schon direkt in den Super Nodes vorverarbeitet, komprimiert, gefiltert und aggregiert werden. Dafür benötigen die Super Nodes ausreichend Rechenleistung, Speicher und Energieversorgung. Die von den Sensorknoten empfangenen Daten werden mit einem Zeitstempel versehen, um die zeitliche Reihenfolge nachvollziehen zu können. Dazu müssen die Uhren der Super Nodes synchron laufen. Die Synchronisation erfolgt mit dem Server per Network Time Protocol (NTP) [MMBK10]. Die Super Nodes sind nicht nur Teil der Testbed-Infrastruktur, sondern können auch als sogenannte High-Level-Knoten (mehr Rechenleistung und Speicher, unbegrenzte Energieversorgung, mehr Fähigkeiten) als Teil der Sensornetzanwendung verwendet werden, wodurch TWIST hierarchische Sensornetze unterstützt. Daneben werden noch flache (gleichartige Knoten, gleiche Anwendung) und segmentierte Netze (Verbund aus flachen Netzen, Super Nodes als Gateways) unterstützt. Beim TKN-Testbed werden Linksys NSLU2 als Super Nodes verwendet, welche auch bei MoteLab (siehe Abschnitt 2.1.1) als Tmote Connect zum Einsatz kommen. Auf den NSLU2 läuft eine angepasste Version von OpenSlug 6, einer Linux-Distribution speziell für eingebettete Systeme. Ein Ethernet-Netzwerk bildet das Backbone des TKN-Testbeds. Server Der Server muss hochverfügbar sein und über entsprechende Hardware verfügen. Er enthält die Testbed-Datenbank (PostgreSQL im Fall des TKN-Testbeds), in der Informationen über die Sensorknoten, die Position der Sockets und die von der Sensornetzanwendung gesendeten Daten gespeichert werden. Zudem laufen auf ihm mehrere Daemons 7 für die Verwaltung des Super-Node-Netzwerks, u. a. für das Dynamic Host Configuration Protocol (DHCP), das Domain Name System (DNS), das Network File System (NFS) und NTP. Control Station Die Control Station steuert die Super Nodes, indem sie die auf den Super Nodes befindlichen Python-Skripte über eine Secure-Shell-Verbindung (SSH) aufruft. Es gibt u. a. Skripte Linux-Hintergrundprozess, der einen bestimmten Dienst zur Verfügung stellt 12

22 2 Testbeds für die Programmierung der Knoten, die Steuerung der Stromversorgung der USB-Hub- Ports und die Kommunikation mit den Sensorknoten. Der Aufruf und die Ausführung der Skripte wird sowohl auf der Control Station als auch auf den Super Nodes parallelisiert, sodass z. B. mehrere Knoten gleichzeitig programmiert werden können Intel Research Berkeley SensorNet Testbed Das SensorNet Testbed von Intel Research Berkeley [CBA + 05] (im Folgenden IRB-Testbed genannt) umfasst 148 Sensorknoten (97 Mica2 und 51 Mica2Dot), die jeweils über ein Crossbow MIB600 Ethernet Gateway mit dem Labornetzwerk verbunden sind. Das Testbed besteht neben den Sensorknoten aus den folgenden Hardwarekomponenten: Die Clients bieten den Benutzern kommandozeilen- oder webbasierten Zugriff auf den Server. Auf dem Server laufen die Dienste, die für das Ressourcenzuteilungssystem Mirage benötigt werden. Die Front-end Machine ermöglicht den physikalischen Zugriff auf das Testbed. Dabei erhalten die Benutzer zeitlich begrenzten Zugriff ausschließlich auf die ihnen zugeteilten Ressourcen (Sensorknoten). Es können mehrere Benutzer parallel auf das Testbed zugreifen, sofern es keine Überschneidungen bei den benutzten Ressourcen gibt. Für das Ressourcenmanagement im IRB- Testbed wurde das mikroökonomische Ressourcenzuteilungssystem Mirage entwickelt. Es basiert auf periodischen, kombinatorischen Auktionen mit einer virtuellen Währung. In jeder Auktionsrunde können die Benutzer angeben, welche Ressourcen sie benötigen und wieviel virtuelles Geld sie bereit sind dafür zu zahlen. Die Gewinner der Runde erhalten dann zeitlich begrenzten Zugriff auf die Ressourcen des Testbeds. Der Ablauf einer Auktionsrunde und das virtuelle Währungssystem werden im Folgenden erläutert. Ablauf einer Mirage-Auktionsrunde 1. Zunächst definiert der Benutzer, welche Ressourcen (Sensorknoten, Zeit) er benötigt und mit welchen Einschränkungen diese verbunden sind (z. B. 32 Sensorknoten für acht Stunden innerhalb der nächsten drei Tage). Mögliche Einschränkungen sind z. B. auf den Sensorknoten verfügbare Sensoren, ein bestimmter Funkkanal, Mindestoder Maximalabstand zwischen den Knoten usw. Anschließend ermittelt er mithilfe des sogenannten Resource-Discovery-Dienstes, welche konkreten Sensorknoten diese Bedingungen erfüllen. 2. Der nächste Schritt ist die Abgabe eines Gebotes mit folgenden Angaben (IRB- Testbed-spezifisch): maximaler Betrag, den der Benutzer zahlen will; Startzeitraum 13

23 2 Testbeds (für die Nutzung der Ressourcen); Dauer der Nutzung; Frequenzbereich; Anzahl benötigter Knoten; Menge in Frage kommender Knoten (im ersten Schritt mittels Resource Discovery ermittelt) 3. Sind alle Gebote eingegangen, wird die Runde geschlossen und die Gewinner ermittelt. Dies geschieht derart, dass für die Bank ein maximaler Ertrag (Summe der gewinnenden Gebote) erreicht wird. Da die Maximalgebote die Wichtigkeit der Anfrage für den Benutzer ausdrücken, wird so eine bestmögliche Zuteilung der Ressourcen erreicht. Zwei Prinzipien spielen bei der Ermittlung der Gewinner eine wichtige Rolle. Erstens werden Benutzer basierend auf der Art der Nutzung des Testbeds priorisiert (Forschung ist z. B. wichtiger als Hausaufgaben). Zweitens werden Benutzer bestraft bzw. belohnt aufgrund ihres Verhaltens in Spitzenlastzeiten. Das Problem der Gewinnerermittlung ist NP-schwer, weshalb bei Mirage ein Greedy-Algorithmus verwendet wird. 4. Nach Ermittlung der Gewinner wird die Bezahlung vorgenommen (virtuelles Geld geht an eine zentrale Bank) und der Zugriff auf die Ressourcen freigegeben. Virtuelles Währungssystem Die Benutzer des geschlossenen Währungssystems von Mirage haben keine Möglichkeit, virtuelles Geld zu verdienen. Stattdessen wird das Geld vom System vergeben. Jeder neue Benutzer wird mit einem Projekt assoziiert, das ein Konto bei der zentralen Bank besitzt. Jedem Konto wird basierend auf der Priorität des Projekts ein Grundbetrag und eine bestimmte Anzahl an Anteilen, die den Geldfluss auf das Konto beeinflussen, zugeteilt. Nach jeder Auktion wird das eingenommene Geld auf alle Konten proportional zur Anzahl der Anteile verteilt. Dadurch ist es möglich, Geld für Spitzenlastzeiten zu sparen. Wenn allerdings nur wenige Benutzer die meisten Testbed-Ressourcen verbrauchen und viele Benutzer für lange Zeit inaktiv sind, sammelt sich das Geld mit der Zeit auf den inaktiven Konten und regelmäßige Benutzer haben irgendwann zu wenig Geld um vernünftig arbeiten zu können, auch wenn die Testbed-Ressourcen kaum genutzt werden. Die Lösung besteht darin, das Guthaben, das über den Grundbetrag eines Kontos hinausgeht, zu besteuern. Die Steuereinnahmen werden ebenfalls proportional zu den Anteilen auf alle Konten verteilt. Bei völliger Inaktivität im Testbed nähern sich alle Konten mit der Zeit wieder ihrem Grundbetrag an. Die Erfahrungen beim Einsatz von Mirage haben gezeigt, dass Benutzer Schwachstellen im Auktionsalgorithmus ausgenutzt haben, um Auktionen mit möglichst geringem Einsatz von virtuellem Geld zu gewinnen. Das verwendete Auktionssystem sollte also möglichst manipulationssicher oder zumindest schwer manipulierbar sein. 14

24 2 Testbeds Die Benutzer des IRB-Testbeds erhalten nach einer gewonnenen Auktion direkten Zugriff auf die Sensorknoten im Testbed. Die automatische Ausführung von Jobs wie z. B. bei MoteLab (siehe Abschnitt 2.1.1) wird nicht unterstützt MiNT Das Miniaturized Network Testbed (MiNT) [DRSC05] ist ein IEEE b-basiertes, mobiles, miniaturisiertes Testbed der Stony Brook University in New York. Die Motivation für dieses Testbed war, die hohen Kosten, die bei Aufbau und Verwaltung großer Testbeds entstehen zu vermeiden. Die Idee bestand darin, die Funksignale bei Sender und Empfänger zu dämpfen, sodass ein Multi-Hop-Netzwerk auf kleinstem Raum aufgebaut werden kann. Abbildung 2.2.: MiNT-Architektur Quelle: [DRSC05] MiNT besteht aus mehreren Core Nodes (den Testbed-Knoten), die von einem per Ethernet verbundenen Controller Node gesteuert und verwaltet werden (siehe Abbildung 2.2). Für die Kommunikation zwischen Controller Node und Core Nodes wird das Simple Network Management Protocol (SNMP) verwendet, wobei jeder Core Node ein sogenanntes Managed Device darstellt. Per SNMP werden u. a. WLAN-Parameter (z. B. Sendeleistung) und -statistiken (z. B. Paketfehlerrate) gesetzt bzw. abgefragt. Der Fernzugriff auf den Controller Node durch Administratoren und Benutzer erfolgt per Kommandozeile oder Web-Interface. 15

25 2 Testbeds Abbildung 2.3.: MiNT-Core-Node mit Roboter Quelle: [DRSC05] Mobilität Jeder Core Node besitzt zwei b-Funkschnittstellen. Eine für die Testbed-Anwendung und eine zum Überwachen und Mitschneiden des Funkverkehrs. Es sind prinzipiell auch weitere Schnittstellen möglich, sodass Experimente mit veschiedenen Funktechnologien durchgeführt werden können. Die Core Nodes selbst sind stationär aufgebaut. Um jedoch Mobilität gewährleisten zu können, sind die Antennen jedes Core Nodes auf einem mobilen Roboter befestigt und per Kabel mit einer Funkschnittstelle des Core Nodes verbunden (siehe Abbildung 2.3). Die Mobilität der Roboter ist wegen der Kabel allerdings stark beschränkt. In der zweiten Version des Testbeds (MiNT-m [DRK + 06]) sind die Core Nodes selbst auf die Roboter montiert, wodurch volle Bewegungsfreiheit ermöglicht wird. Die Steuerung der Roboter erfolgt per Infrarot-Schnittstelle durch die jeweiligen Core Nodes. Miniaturisierung Die Miniaturisierung des Testbeds wird durch Verringerung der Sendereichweite unter Verwendung von Signaldämpfern (zwischen WLAN-Schnittstelle und Antenne) erreicht. Versuche haben gezeigt, dass das Verhalten der unteren vier Schichten des OSI-Modells durch die Signaldämpfung nicht verändert wird. Jedoch gibt es auch einige Einschränkungen. Ein Problem ist, dass störende Funksignale (z. B. durch andere WLANs) aufgrund der geringen Sendeleistung im Testbed einen größeren Einfluss haben. Zudem kann thermisches Rauschen nicht gedämpft werden, da es nicht durch die Empfängerantenne geht. Diese beiden Effekte verringern den Signal-Rausch-Abstand (engl. Signal-to-Noise Ratio (SNR)) im Vergleich zu einem ungedämpften Testbed. Als Lösung für dieses Problem wird eine geringere Dämpfung oder ein kleinerer Abstand zwischen den Knoten bzw. Antennen vorgeschlagen. 16

26 2 Testbeds Konfiguration und Durchführung eines Experiments Die Konfiguration und Verwaltung von Experimenten erfolgt über eine graphische Benutzerschnittstelle (engl. Graphical User Interface (GUI)). Über sie kann zunächst die Topologie des Netzes konfiguriert werden. Dazu werden alle Knoten und die paarweise Signalstärke angezeigt. Der Benutzer kann per Drag and Drop die Knoten bzw. die Roboter nach seinen Wünschen positionieren. Die realen Roboter im Testbed fahren daraufhin zu ihrer neuen Position. Die paarweise Signalstärke wird dabei permanent aktualisiert. Die Bewegungen der Roboter während des Experiments können für jeden Roboter individuell festgelegt werden. Es können Pfade oder Zielpositionen festgelegt werden. Zudem stehen zwei Zufallsbewegungsmodelle (Random Waypoint Model und Random Walk Model) zur Auswahl. Als nächstes konfiguriert der Benutzer die Anwendungen (Datengeneratoren und -senken), die auf den Knoten laufen sollen. Er kann dafür eigene Anwendungen schreiben oder aus einer Bibliothek vorgefertigter Anwendungen wählen. Anschließend werden globale Parameter wie Sendeleistung und Anzahl an Sendewiederholungen eingestellt, die aber auch für jeden Knoten individuell angepasst werden können. Für Anwendungen oder Protokolle, die Kernel-Modifikationen benötigen, wird die Installation von Kernel-Modulen unterstützt. Der Benutzer kann sich über die GUI auch direkt bei einem Knoten einloggen und ihn konfigurieren. Während eines Experiments können jederzeit die bisherigen Ergebnisse eingesehen werden. Der Benutzer hat zudem die Möglichkeit, ein Experiment anzuhalten, Parameter anzupassen und es dann fortzusetzen. Mithilfe einer Skriptsprache kann der Ablauf eines Experiments durch die Simulation von Fehlern, wie Paketverlust, -verzögerung oder -veränderung (z. B. Bitfehler) beeinflusst werden. Die gleiche Skriptsprache ermöglicht die Definition von Protokollbedingungen. Diese können überwacht und damit Implementierungsfehler aufgedeckt werden. Die gesamte Konfiguration eines Experiments kann gespeichert und wiederverwendet werden. Auswertung eines Experiments Die zweite Antenne jedes Core Nodes wird verwendet, um während eines Experiments den Datenverkehr mitzuschneiden. Dadurch kann für die Auswertung die Sicht jedes einzelnen Knotens auf den Funkkanal rekonstruiert werden. Die gesammelten Aufzeichnungen werden zum Control Node geschickt und dort zu einer Datei zusammengefasst. Die Sortierung der Ereignisse erfolgt anhand von Zeitstempeln, weshalb die Core Nodes zu Beginn eines Experiments synchronisiert werden müssen. Für die Visualisierung der Aufzeichnungen wird Ethereal 8 verwendet. Der Benutzer kann mithilfe von Filtern die Aufzeichnung auf bestimmte Schichten und/oder Pakettypen beschränken, wodurch die zu speichernde und zu übertragende Datenmenge reduziert wird. Gleichzeitig erleichtert dies die Analyse der Daten umbenannt in Wireshark: 17

27 2 Testbeds Hybrid-Simulation MiNT unterstützt ähnlich wie Kansei (siehe Abschnitt 2.1.2) die Hybrid-Simulation, bei der die Bitübertragungs- und Sicherungsschicht des Simulators durch reale Hardware und Treiber ersetzt werden. Statt TOSSIM kommt ns-2 als Simulator zum Einsatz. Ns- 2-Skripte und Programmcode für die reine Simulation müssen nur geringfügig für die Hybrid-Simulation angepasst werden. Ein wesentlicher Unterschied zu Kansei besteht darin, dass jedem virtuellen Knoten ein physischer Knoten fest zugeordnet wird. Die Hybrid- Simulation von Netzen, die größer sind als das physische Netz, ist damit nicht möglich Testbed-Design In diesem Abschnitt werden basierend auf den vorgestellten Testbeds verschiedene Aspekte, die beim Design von Sensornetz-Testbeds eine Rolle spielen, beleuchtet und Anforderungen an Testbeds beschrieben Hardware Sensorknoten Um die Kosten für ein Testbed möglichst gering zu halten, sollten bei der Auswahl der Sensorknoten die Anschaffungskosten berücksichtigt werden. Die Sensorknoten benötigen eine oder mehrere Drahtlosschnittstelle(n) für die Experimente und mindestens eine weitere Schnittstelle (z. B. USB) für die Programmierung und Kommunikation mit dem Testbed- Server bzw. der Hardware, über die sie mit dem Testbed verbunden sind. Dabei darf letztere die Experimentierschnittstelle(n) nicht beeinflussen. Je nach Anforderungen kann die Unterstützung verschiedener Sensorknotenplattformen wünschenswert sein, sodass Experimente in heterogenen Sensornetzen mit ggf. verschiedenen Funkstandards- und frequenzen möglich sind. Skalierbarkeit Die Vision für drahtlose Sensornetze besteht darin, Netze mit einer Größe von mehreren hundert oder tausend Sensorknoten zu betreiben. Für den Test von Anwendungen für solche Netze sind dementsprechend große Testbeds nötig, da in größeren Netzen Effekte auftreten können, die in kleineren Netzen nicht beobachtet werden können. Die Architektur eines Testbeds sollte also entsprechend skalieren, sowohl auf Hardware- als auch auf Software-Ebene. Eine hierarchische Architektur wie z. B. TWIST (siehe Abschnitt 2.1.4) ermöglicht den Aufbau großer Netze. Der Vorteil einer solchen Architektur besteht darin, dass nicht ein Server sämtliche Testbed-Knoten steuert und programmiert, sondern diese Aufgaben an untergeordnete Testbed-Hardware (an die die Sensorknoten angeschlossen sind) delegiert werden können. 18

28 2 Testbeds Management Benutzerverwaltung Die Verwaltung von passwortgeschützten Benutzerkonten ist essentiell, um Experimente bzw. Jobs Personen zuordnen zu können. Zudem wird erst dadurch eine faire Zuteilung der Testbed-Ressourcen ermöglicht. Die Verwendung von Passwörtern stellt zudem sicher, dass Benutzer nur Zugriff auf ihre eigenen Jobs und Ergebnisse haben. Ressourcenzuteilung Für die effiziente Nutzung der Testbed-Ressourcen (Sensorknoten) sollten mehrere Jobs (mit disjunkten Knotenmengen) gleichzeitig ausgeführt werden können. Dies ist vor allem in Zeiten, wenn viele Benutzer auf das Testbed zugreifen wollen, sehr wichtig. Da gerade bei großen Testbeds nur selten alle Knoten für ein Experiment benötigt werden, würden sonst Ressourcen ungenutzt bleiben und Benutzer unnötig lange auf die Nutzung des Testbeds warten müssen. Die Zuteilung der Ressourcen sollte gleichermaßen fair und effizient (hinsichtlich der Auslastung des Testbeds) sein. Dafür gibt es verschiedene Methoden. Bei wenig genutzten Testbeds ist der einfach zu implementierende First-Come-First-Served- Ansatz (FCFS), bei dem die Anfragen in der Reihenfolge ihres Eingangs bearbeitet werden, in den meisten Situationen ausreichend. Dieser Ansatz kann, wie bei MoteLab (siehe Abschnitt 2.1.1) geschehen, auch mit einem Zeitkontingent für jeden Benutzer erweitert werden, um die Ressourcenzuteilung fairer zu gestalten. Zudem könnte jeder Job mit einer Priorität (abhängig z. B. von der Benutzergruppe und/oder der Wichtigkeit des Experiments) versehen werden. In stark genutzten Testbeds stößt der FCFS-Ansatz jedoch schnell an seine Grenzen. Komplexere Zuteilungsverfahren wie Mirage [CBA + 05] (siehe Abschnitt 2.1.5) sollten dann in Betracht gezogen werden. Zeitsynchronisation Für die Auswertung der Ergebnisse eines Experiments ist die Kenntnis der zeitlichen Reihenfolge der aufgezeichneten Ereignisse von großer Bedeutung. Daher müssen die Geräte, an die die Sensorknoten angeschlossen sind, synchronisiert werden. Dafür kann z. B. NTP [MMBK10] verwendet werden. Lokalisierung Die Kenntnis der genauen Position jedes einzelnen Testbed-Knotens ist sowohl für Administratoren als auch Benutzer von Vorteil. Administratoren können dadurch leichter fehlerhafte Knoten finden und austauschen. Benutzern helfen diese Informationen bei der Analyse der Ergebnisse ihrer Experimente. Um den Knoten Positionen zuordnen zu können, müssen diese eindeutig identifizierbar sein. 19

29 2 Testbeds Konnektivitätsermittlung Damit Benutzer gezielt bestimmte Topologien für ihre Experimente erzeugen können (durch Wahl der Knoten und der Sendeleistung), sollte regelmäßig die Konnektivität (Empfangsleistung, Verbindungsqualität) zwischen den Sensorknoten für verschiedene Sendeleistungen ermittelt werden. Dies ist vor allem beim Testen von Routing-Protokollen ein wichtiges Instrument und auch bei der Auswertung anderer Experimente sehr hilfreich. Testbed-Überwachung In einem großen, komplexen Testbed mit hunderten Sensorknoten und anderer Hardware muss mit dem Auftreten von Hardware-Defekten und anderen Problemen gerechnet werden. Die Überwachung des Zustands des Testbeds (sogenanntes Health Monitoring) ist daher unbedingt nötig. Die dabei gewonnenen Informationen sind zum einen für den Administrator des Testbeds wichtig, damit dieser eventuelle Probleme beheben kann. Aber auch Benutzer benötigen diese Informationen für die Auswertung ihrer Experimente. Würden Benutzer nicht über die während eines Experiments aufgetretenen Probleme informiert werden, könnte dies zu einer Fehlinterpretation der Ergebnisse führen. Der Nutzen des Testbeds wäre damit in Frage gestellt. Die Aktualisierung der Zustandsinformationen sollte regelmäßig und auf Anfrage durchgeführt werden können. Hilfreich ist auch eine Unterscheidung zwischen Hardware-, Software- und Netzwerkproblemen, wie dies bei Chowkidar [BLK + 07] der Fall ist. Neben der Erkennung von Problemen sollte auch neu hinzugefügte Hardware (insbesondere Sensorknoten) automatisch erkannt und in das Testbed integriert werden Nutzung Jobs Einige Testbeds wie z. B. das IRB-Testbed (siehe Abschnitt 2.1.5) bieten den Benutzern lediglich zeitlich begrenzten Zugriff auf die Testbed-Knoten. Die Programmierung und Konfiguration der Knoten sowie die Durchführung der Experimente obliegt allein ihnen. Für eine komfortablere und effizientere (auch nachts) Nutzung des Testbeds sollte die Konfiguration und Ausführung von Jobs unterstützt werden. Eine Job-Konfiguration enthält eine Liste der zu verwendenden Knoten und Programme, die Laufzeit und ggf. weitere Parameter (z. B. Simulation des Ausfalls eines Knotens zu bestimmter Zeit, Anpassung der Sendeleistung). Die Ausführung der Jobs und auch das Speichern der von den Knoten gesendeten Daten erfolgt dann automatisch. 20

30 2 Testbeds Fehlersimulation und Dateneinspeisung Die Simulation von Fehlern (z. B. Bitfehler, Paketverlust, Ausfall von Knoten) ermöglicht es, Anwendungen und Protokolle (z. B. für Routing oder Datentransfer) auf ihre Robustheit hin zu überprüfen. Eine weitere Möglichkeit der Einflussnahme auf ein Experiment ist die Einspeisung von Sensordaten um bestimmte Ereignisse zu simulieren und die Reaktion der Anwendung darauf zu beobachten. In beiden Fällen (außer dem simulierten Knotenausfall) sind zusätzliche Softwarekomponenten auf den Knoten erforderlich, die die Fehler simulieren bzw. die eingespeisten Daten entgegennehmen und an die eigentliche Anwendung weiterreichen. Je nach Nutzungsart des Testbeds löst entweder der Benutzer selbst die Ereignisse aus (durch direkten Zugriff auf die Knoten), oder sie werden, wenn die Ausführung von Jobs unterstützt wird, automatisch entsprechend der Job-Konfiguration ausgelöst. Wiederholbarkeit / Reproduzierbarkeit Der Ablauf eines Experiments (d. h. Ausfall / Hinzufügen von Knoten, Fehlersimulation) sollte wiederholbar sein, damit verschiedene Programmversionen und Parameter unter den gleichen Umständen getestet werden können. Weiterhin kann so überprüft werden, ob ein bestimmtes Programm- oder Protokollverhalten nur Zufall war oder regelmäßig in bestimmten Situationen auftritt. Der zeitliche Ablauf von Experimenten ist bei Unterstützung von Jobs prinzipiell wiederholbar. Jedoch sind die Ergebnisse nur bedingt reproduzierbar. Die meisten Sensorknoten funken im viel genutzten 2,4-GHz-ISM-Band 9, wo sie Störungen durch z. B. WLAN, Bluetooth und anderen Anwendungen ausgesetzt sind. Die Einflüsse dieser Störungen auf Bit- und Paketfehlerrate und die Sichtbarkeit anderer Knoten variieren mit der Zeit und damit von Experiment zu Experiment, sodass auch die Testergebnisse variieren können. Vermieden werden kann dies durch Abschottung des Testbeds von Störquellen. Abgesehen vom hohen Aufwand dafür werden dadurch allerdings auch die Testergebnisse weniger realistisch, da im realen Einsatz eines Sensornetzes mit Störquellen gerechnet werden muss. Es gilt also einen Kompromiss zwischen Realismus und Reproduzierbarkeit zu finden. Eine Möglichkeit, die Störungen wenigstens gering zu halten, ist die Wahl eines freien Funkkanals. Der Standard IEEE definiert beispielsweise 16 Kanäle im Bereich von 2400 bis 2483,5 MHz. Welche Kanäle in Frage kommen, hängt davon ab, in welcher Umgebung das Testbed aufgebaut ist, d. h. welche anderen Anwendungen im genutzten ISM-Band arbeiten. Diese Informationen sollten den Benutzern des Testbeds zur Verfügung gestellt werden, damit diese einen geeigneten Kanal für ihre Experimente auswählen können. 9 Frequenzband für Anwendungen in Industrie, Wissenschaft und Medizin 21

31 2 Testbeds Benutzerschnittstelle Die Benutzerschnittstelle bietet Benutzern und Administratoren Zugriff auf die Funktionen des Testbeds. Sie sollte intuitiv und einfach zu bedienen sein, und auch entfernten Benutzern die Nutzung des Testbeds ermöglichen. Mögliche Schnittstellen sind die Kommandozeile und die graphische Benutzeroberfläche, wobei letzte auch als Web-Interface realisiert sein kann. Die Funktionen für Administatoren sollten folgende Punkte umfassen: Übersicht der Testbed-Knoten inkl. Position, Zustand, Konnektivität zu anderen Knoten und Möglichkeit der manuellen Aktualisierung Verwaltung der Benutzerkonten Manipulation der Job-Liste (um evtl. Konflikte lösen zu können) Benutzer benötigen mindestens folgende Funktionen: Übersicht der Testbed-Knoten inkl. Position, Zustand, Konnektivität zu anderen Knoten Jobverwaltung (einplanen, abbrechen, löschen, Status einsehen) Ergebnisse eines Experiments bzw. Jobs abrufen 22

32 3. Entwurf des IHP-Testbeds In diesem Kapitel wird der Entwurf des IHP-Testbeds beschrieben. Dazu werden in Abschnitt 3.1 zunächst die Gegebenheiten im IHP und die Anforderungen an das Testbed erläutert. In Abschnitt 3.2 wird die Architektur entworfen und die einzelnen Komponenten des Testbeds vorgestellt. Die Nutzung des Testbeds wird in Abschnitt 3.3 erklärt. Das IHP-Testbed soll den Ausfall von Knoten und das Hinzufügen neuer Knoten während eines Experiments simulieren können. In Abschnitt 3.4 wird beschrieben, wie dies umgesetzt wurde. Eine Diskussion der möglichen Verfahren / Protokolle für die Zeitsynchronisation im Testbed erfolgt in Abschnitt 3.5. Abschnitt 3.6 diskutiert verschiedene Verfahren zur Ressourcenzuteilung. Abschnitt 3.7 erläutert anhand des Lebenszyklus eines Jobs die Funktionsweise und das Zusammenwirken der Testbed-Komponenten. Die Ermittlung der Konnektivität zwischen den Sensorknoten wird in Abschnitt 3.8 beschrieben. In Abschnitt 3.9 wird auf die Überwachung der Testbed-Hardware und das Verhalten bei Hardware-Ausfall eingegangen. Im letzten Abschnitt 3.10 wird schließlich der Entwurf der Testbed-Software und ihre Komponenten beschrieben Anforderungen und Gegebenheiten Folgende Anforderungen soll das IHP-Testbed erfüllen: Skalierbarkeit Langfristig soll das Testbed mehrere hundert Sensorknoten umfassen. Heterogenität Verschiedene Sensorknotenplattformen und -betriebssysteme sollen unterstützt werden. Fehlersimulation Der Ausfall von Sensorknoten soll simuliert werden können. Wiederholbarkeit Der Ablauf eines Experiments soll wiederholbar sein. (zeitliche Festlegung von Knotenausfall und dem Hinzufügen von Knoten) Das Testbed soll in den Büroräumen des IHP aufgebaut werden. Für die Kommunikation zwischen den Testbed-Komponenten stehen Ethernet und WLAN nach IEEE a/g/n 23

33 3 Entwurf des IHP-Testbeds [Ins07, Ins09] zur Verfügung. Als Sensorknoten sollen zunächst Tmote Sky [Mot06b] und Tmote Invent [Mot06a] verwendet werden, da diese am IHP in ausreichend großer Zahl zur Verfügung stehen. Unter welchen Voraussetzungen andere Sensorknotenplattformen für das Testbed verwendet werden können und welche Anpassungen bzw. Erweiterungen dafür in der Software notwendig sind, wird in Abschnitt 4.3 beschrieben Vermeidung von Störungen durch WLAN und andere Sensornetze Die zu verwendenden Tmote Sky / Invent funken nach dem Standard IEEE [Ins06] im 2,4-GHz-ISM-Band. Andere in diesem Frequenzband arbeitende Anwendungen im IHP sind u. a. das bereits erwähnte WLAN, Bluetooth-Geräte und andere drahtlose Sensornetze. Bei einem Experiment mit drahtlosen Sensornetzen im IHP [BSL09] konnte beobachtet werden, dass durch diese Anwendungen zum Teil erhebliche Störungen der Kommunikation im Sensornetz auftreten. Die Sendeleistung der Sensorknoten betrug dabei allerdings nur -25 dbm. Bei größeren Sendeleistungen ab -10 dbm sind diese Störungen und die dadurch verursachte Paketfehlerrate im Sensornetz offenbar zu vernachlässigen [HHW09]. Um jedoch im Testbed auch Experimente mit niedrigeren Sendeleistungen zu ermöglichen, sollten die Störungen so gering wie möglich gehalten werden. Die im IHP verwendeten WLAN-Kanäle im 2,4-GHz-Band sind 1, 6 und 11. Daraus ergeben sich die überlappungsfreien Kanäle 15, 20, 25 und 26 (siehe Abbildung 3.1), welche für die Sensorknoten im Testbed verwendet werden sollten. Abbildung 3.1.: IEEE und IEEE Kanäle Quelle: [YXG11] Neben Störungen durch WLAN können auch Störungen durch andere Sensornetze auftreten, insbesondere wenn der gleiche Kanal verwendet wird. Abgesehen von den zu erwartenden Interferenzen kann es auch zum Empfang von Nachrichten aus den anderen Sensornetzen kommen. In TinyOS [LMP + 05] beispielsweise erhält jeder Sensorknoten eine ID, welche für die Adressierung von Nachrichten verwendet wird. Wenn für die Sensorknoten im Testbed und für die in anderen Sensornetzen zum Teil die gleichen IDs verwendet werden, kann es zu gegenseitigen Störungen durch Empfang von Nachrichten aus dem jeweils anderen Netz kommen. Um dies zu vermeiden sollten für das Testbed exklusive Kanäle definiert werden. 24

34 3 Entwurf des IHP-Testbeds 3.2. Architektur Ausgangspunkt für den Entwurf der Architektur des IHP-Testbeds bilden ein Sensornetz, bestehend aus Tmote Sky und Tmote Invent Sensorknoten, und das im IHP verfügbare Ethernet und WLAN, welche als Backbone für die Kommunikation zwischen den Testbed- Komponenten verwendet werden können. Die Testbed-Architektur bzw. -Infrastruktur muss erstens Zugriff auf die Sensorknoten ermöglichen, sodass diese programmiert und von ihnen gesendete Daten empfangen werden können. Zweitens muss sie mindestens einen Server für den Betrieb des Testbeds (Ressourcenzuteilung, Ausführung von Jobs, Datenverwaltung, Bereitstellung einer Benutzerschnittstelle usw.) enthalten. Eine Möglichkeit, die Sensorknoten zu programmieren, ist das sogenannte Over-the-air programming (OTA) z. B. mittels Deluge [HC04]. Dabei werden neue Programme per Funk an die Sensorknoten übertragen, sodass dafür kein physikalischer Zugriff auf die Knoten nötig ist. Der Vorteil daran ist, dass keine zusätzliche Hardware für die Programmierung benötigt wird und die Sensorknoten frei verteilt werden können. Allerdings stellt sich bei dieser Architekturvariante u. a. die Frage nach der Energieversorgung der Sensorknoten. Die Versorgung über Batterien ist für Testbeds ungeeignet, da dies den Wartungsaufwand erheblich steigern würde. Eine externe Stromversorgung dagegen würde die Vorteile dieser Architektur aufheben. Für das IHP-Testbed wird daher eine Architekturvariante bevorzugt, bei der die Sensorknoten mit einem PC verbunden sind, über den sowohl Programmierung als auch Stromversorgung erfolgen. Dabei gibt es drei Möglichkeiten: 1. Alle Sensorknoten sind an einen PC angeschlossen. Diese Variante findet sich z. B. bei MiNT (siehe Abschnitt 2.1.6). Der Vorteil ist die Kosteneffizienz, da nur ein PC benötigt wird. Allerdings ergeben sich daraus auch Nachteile. Erstens wäre die Größe des Testbeds beschränkt. Da ein USB-Controller die angeschlossenen Geräte mit einer sieben Bit langen Kennung adressiert, können nur 127 USB-Geräte (inkl. USB-Hubs) angeschlossen werden (Adresse 0 ist die vorläufige Adresse für neu angeschlossene oder neugestartete Geräte) [CHPI + 00]. Die geforderte Skalierbarkeit für das IHP-Testbed wäre damit nicht gegeben. Ein weiterer Nachteil ist, dass der PC, an den die Knoten angeschlossen sind, einen sogenannten Single Point of Failure (SPOF) darstellt. Das heißt, wenn dieser PC ausfällt, fällt das gesamte Testbed aus. 2. Jeder Sensorknoten ist an einen eigenen PC angeschlossen. Vorteil ist zum einen die (hardwaremäßige) Skalierbarkeit. Zudem fällt nur ein Sensorknoten aus, wenn ein PC ausfällt. Nachteil ist offensichtlich der hohe Kostenaufwand. Außerdem müssen die Uhren der PCs synchronisiert werden, damit für die Auswertung der Experimente die Reihenfolge der von den Sensorknoten gesendeten Daten rekonstruiert werden kann. 25

35 3 Entwurf des IHP-Testbeds 3. Cluster - mehrere Sensorknoten an einem PC Der Vorteil dieser Variante ggü. der Ersten ist wie bei der Zweiten die bessere Skalierbarkeit. Zudem gibt es keinen SPOF, wobei allerdings mehrere Sensorknoten ausfallen, wenn ein PC ausfällt. Im Vergleich zur zweiten Variante entstehen geringere Kosten. Zudem wird die verfügbare Hardware effizienter genutzt. Der Nachteil ist wie bei der zweiten Variante die notwendige Zeitsynchronisation der PCs. Die dritte Variante, bei der mehrere Sensorknoten an einen PC (im Folgenden Knotenserver genannt) angeschlossen sind, bietet deutliche Vorteile ggü. den ersten beiden Varianten und wird daher für das IHP-Testbed gewählt. Nun werden noch Komponenten für den Betrieb des Testbeds benötigt. Hierfür gibt es zwei naheliegende Möglichkeiten: 1. Betrieb des Testbeds durch die Knotenserver (verteilter, kooperativer Ansatz) Die Vorteile sind zum einen, dass keine weitere Hardware für den Betrieb benötigt wird. Zum anderen gibt es keinen SPOF. Wenn ein Knotenserver ausfällt, können die anderen den Betrieb aufrechterhalten. Dazu müssen jedoch die zu verwaltenden Daten (Benutzerkonten, Informationen über Jobs, usw.) redundant gespeichert, also repliziert werden. Das Problem der Erhaltung der Konsistenz zwischen den Replikaten wird umso größer, je mehr Knotenserver vorhanden sind, wodurch die Skalierbarkeit des Testbeds eingeschränkt wird. 2. Zusätzlicher Server (zentralisierter, hierarchischer Ansatz) Ein zusätzlicher Server speichert sämtliche Informationen (Benutzerkonten, verfügbare Ressourcen, usw.), betreibt das Testbed (Ressourcenzuteilung, Jobplanung, usw.) und stellt eine Benutzerschnittstelle bereit. Da er sämtliche Informationen besitzt, kann er autonom Entscheidungen treffen (z. B. bei der Jobplanung). Der Nachteil dieser Variante ist offensichtlich, dass dieser Server einen SPOF darstellt. Diese Variante wird u. a. bei MoteLab (siehe Abschnitt 2.1.1) verwendet. Ähnliche Architekturen finden sich auch bei Kansei, ORBIT und TWIST (siehe Abschnitte 2.1.2, 2.1.3, 2.1.4), bei denen die Aufgaben allerdings auf mehrere spezielle (nicht redundante) Server verteilt sind. Aufgrund der besseren Skalierbarkeit und des geringeren Aufwands für die Implementierung wird für das IHP-Testbed die zweite Variante gewählt. Um mögliche Ausfallzeiten so gering wie möglich zu halten und damit die Verfügbarkeit zu erhöhen, muss allerdings das Problem des SPOF gelöst oder zumindest abgemildert werden. Dazu wird dem Server (im Folgenden Testbed-Server genannt) ein zweiter Testbed-Server zur Seite gestellt, der seine Aufgaben im Falle eines Ausfalls übernimmt. Dazu müssen sämtliche Daten, die der erste Server verwaltet, beim zweiten Server repliziert werden. Für die Konsistenzerhaltung des Replikats teilt der erste Server jede Änderung am Datenbestand dem zweiten Server mit. 26

36 3 Entwurf des IHP-Testbeds Die Verbindung zwischen erstem und zweitem Testbed-Server wird wegen der höheren Zuverlässigkeit per Ethernet statt WLAN bewerkstelligt. Die Anbindung der Knotenserver an das Testbed kann sowohl per Ethernet als auch per WLAN erfolgen. Für die zuverlässige Kommunikation zwischen den Komponenten wird das Transmission Control Protocol (TCP) verwendet. Lokaler Benutzer Primärer Zweiter, Testbed-Server Redundanter mit Datenbank Testbed-Server Firewall Entfernter Benutzer Internet Ethernet WLAN Access Point Knotenserver USB-Hub Sensornetz Sensorknoten Abbildung 3.2.: Architektur des IHP-Testbeds Die für das IHP-Testbed entworfene Architektur ist in Abbildung 3.2 dargestellt. Die Aufgaben und Funktionen der Komponenten werden im Folgenden noch einmal genauer erläutert Testbed-Server Der Testbed-Server verwaltet, steuert und überwacht das Testbed und plant die Ausführung der Jobs. Für den Zugriff auf die Testbed-Funktionen können sich sowohl lokale als auch entfernte Benutzer über ein Schnittstellenprogramm (siehe Abschnitt 3.3.1) mit ihm verbinden. Sämtliche Informationen über Benutzerkonten, vorhandene Knotenserver und Sensorknoten und auszuführende Jobs werden in einer SQLite-Datenbank [SQL] verwaltet. Das verwendete Datenbankschema ist in Abbildung A.1 im Anhang A.2 dargestellt. Die Ergebnisse eines Jobs werden als Log-Dateien im Dateisystem gespeichert. 27

37 3 Entwurf des IHP-Testbeds Knotenserver Die Knotenserver sind zuständig für die Programmierung der Sensorknoten, den Empfang der von den Knoten gesendeten Daten und die Simulation des Ausfalls von Knoten bzw. das Hinzufügen neuer Knoten. Die Steuerung der Knoten ist parallelisiert, sodass u. a. alle Knoten gleichzeitig programmiert werden können. Bei Kansei (siehe Abschnitt 2.1.2) werden die Knotenserver vom Testbed-Server gesteuert. Für jede Aktion (z. B. Sensorknoten programmieren oder neustarten) sendet dieser ein Kommando an die Knotenserver. Fällt er aus, wird damit auch die Ausführung der Jobs gestört. Um dies zu vermeiden, sind die Knotenserver im IHP-Testbed auch zuständig für die Ausführung der Jobs. Sie erhalten vom Testbed-Server alle notwendigen Daten (Programme, Jobkonfiguration, Startzeit) und erledigen die Ausführung selbständig. Sollte der Testbed-Server ausfallen oder die Verbindung zu ihm unterbrochen werden, wird die Ausführung eines Jobs nicht unterbrochen, da die Knotenserver autonom weiterarbeiten können. Außerdem verhindert dies, dass der Testbed-Server bei größeren Testbeds zum Flaschenhals wird. Als Knotenserver kommen im IHP-Testbed zunächst PCs des Typs fit-pc2i Linux [Com] von CompuLab zum Einsatz. Sie wurden ausgewählt, da sie nur wenig Strom verbrauchen (je nach CPU-Auslastung 6-8 W) und dennoch genügend Rechenleistung für die Aufgaben eines Knotenservers bieten. Sie verfügen über einen Intel Atom Z530 mit 1,6 GHz Taktfrequenz und 1 GB RAM. Für die Anbindung an das Testbed steht neben Gigabit-Ethernet auch WLAN nach IEEE g zur Verfügung. Dank der WLAN-Schnittstelle, durch die sie nicht auf einen Ethernet-Anschluss angewiesen sind, und ihrer geringen Größe (101 x 115 x 27 mm) ergeben sich vielseitige Möglichkeiten für ihre Platzierung und damit für den Aufbau des Testbeds. Sie benötigen lediglich einen Stromanschluss in der Nähe. Weiterhin verfügen sie über vier (zwei Typ-A und zwei Mini-B) USB-2.0-Anschlüsse für den Anschluss der Sensorknoten bzw. USB-Hubs Testbed-Sockets Wie bei der TWIST-Architektur (siehe Abschnitt 2.1.4) ist ein Testbed-Socket der Punkt, wo ein Sensorknoten per USB mit dem Testbed verbunden wird. Im Fall des IHP-Testbeds stellt jeder USB-Hub einen solchen Socket dar. Sie können durch die MAC-Adresse des Knotenservers und der Nummer des USB-Ports, an dem sie angeschlossen sind, identifiziert werden. Ihre Positionen sind in der Datenbank gespeichert. Dabei handelt es sich zunächst um textuelle Angaben wie z. B. Büro XY, am Fenster, die dem Benutzer bei der Auswahl der Knoten helfen. Später könnten diese auch durch Koordinatenangaben ersetzt werden, sodass eine Darstellung der Sockets und ihrer Positionen auf einer Karte (z. B. Grundriss der Büroräume) automatisch erzeugt werden kann. 28

38 3 Entwurf des IHP-Testbeds Sensorknoten Die Sensorknoten werden über die Testbed-Sockets in das Testbed eingebunden. Da die Positionen der Sockets bekannt sind, können somit auch die Positionen der Sensorknoten eingegrenzt werden. Die zunächst für das Testbed verwendeten Tmote Sky und Tmote Invent verfügen über einen IEEE konformen CC2420-Transceiver [Tex07] mit einer Datenrate von 250 kbps und funken im 2,4-GHz-ISM-Band. Die Reichweite beträgt bei Verwendung der integrierten Antenne 50 m in Räumen und 125 m im Freien. Als Mikrocontroller dient ein MSP430 [Tex11] von Texas Instruments (16 Bit Reduced Instruction Set Computer (RISC), 8 MHz Taktfrequenz). Desweiteren stehen 10 kb RAM und 48 kb Flashspeicher zur Verfügung, sowie drei LEDs und diverse Sensoren zur Messung von Temperatur, Luftfeuchtigkeit und Lichtstärke. Die Tmote Sky verfügen zudem über Erweiterungspins und Analog-Digital-Wandler, sodass weitere Sensoren angeschlossen werden können Nutzung In diesem Abschnitt wird die Nutzung des IHP-Testbeds beschrieben. Zunächst wird die Benutzerschnittstelle und ihre Funktionen erläutert. Um eine komfortable und effiziente Nutzung des Testbeds zu ermöglichen, wird die automatische Ausführung von Jobs unterstützt, statt lediglich Zugriff auf die Sensorknoten zu gewähren. Auf diese Weise ist auch die Wiederholung von Experimenten inkl. ihres Ablaufs möglich. Dazu wird in diesem Abschnitt erklärt, was für einen neuen Job benötigt und wie er konfiguriert wird. Abschließend wird beschrieben, wie die Log-Dateien eines Jobs aussehen Benutzerschnittstelle Die Benutzerschnittstelle wurde aufgrund der schnelleren Umsetzbarkeit als Kommandozeilenprogramm entworfen, kann jedoch später auch durch ein komfortableres Web- Interface ersetzt werden. Das Programm kann auf einem beliebigen PC, von dem aus eine Verbindung zum Testbed-Server hergestellt werden kann, eingesetzt werden. Das heißt es kann sowohl auf lokalen PCs innerhalb des IHP als auch externen PCs, nachdem von diesen eine Virtual-Private-Network-Verbindung (VPN) zum IHP-Netzwerk aufgebaut wurde, verwendet werden. Für die Anmeldung am Testbed-Server stehen zwei Kontotypen mit unterschiedlichen Funktionen zur Auswahl - Administrator (für Verwaltung und Wartung des Testbeds) und Benutzer (für die einfache Nutzung). Die Anmeldung erfolgt mit adresse oder Konto-ID (wird bei Kontoerstellung vergeben) und Passwort. 29

39 3 Entwurf des IHP-Testbeds Administratoren stehen nach der Anmeldung folgende Funktionen zur Verfügung: Testbed-Status Status aktualisieren Die Aktualisierung des Status erfolgt automatisch in regelmäßigen Abständen, kann aber auch von einem Administrator manuell ausgelöst werden. Status abrufen Informationen über den Testbed-Status umfassen eine Liste aller Knotenserver und Sensorknoten inkl. Position, Status (aktiv, inaktiv, fehlerhaft) und Konnektivität zu anderen Knoten. Verwaltung der Benutzer- und Administratorkonten Kontoliste abrufen Konto erstellen Konto bearbeiten Konto löschen Jobs Jobliste abrufen Job löschen Das Benutzermenü der Schnittstelle bietet folgende Funktionen: Testbed-Status abrufen Liste aller Sensorknoten inkl. Position, Status (aktiv, inaktiv, fehlerhaft) und Konnektivität zu anderen Knoten Jobs Jobliste abrufen Es kann eine Liste aller Jobs oder nur der Jobs des angemeldeten Benutzers abgerufen werden. Job erstellen Job löschen Der Benutzer kann nur seine eigenen Jobs löschen. Laufende Jobs werden dabei abgebrochen. Ergebnisse abrufen Es können nur die Ergebnisse von eigenen Jobs abgerufen werden. Benutzerkonto löschen 30

40 3 Entwurf des IHP-Testbeds Jobs Ein Job besteht aus einem oder mehreren Programmen, die auf den Sensorknoten ausgeführt werden, und der Jobkonfigurationsdatei jcf (Job Configuration File), in der u. a. der Ablauf eines Experiments definiert wird. Durch mehrfache Verwendung einer Jobkonfigurationsdatei können Experimente einfach wiederholt werden. Da TinyOS eines der bekanntesten und verbreitetsten Betriebssysteme für Sensorknoten ist, unterstützt die aktuelle Version der Software des IHP-Testbeds zunächst nur dieses. Wie die Software für die Unterstützung weiterer Betriebssysteme angepasst werden kann, ist in Abschnitt 4.3 beschrieben. Der für TinyOS verwendete nesc 10 -Compiler ncc erzeugt aus TinyOS-Quellcode Programme im Executable and Linkable Format (ELF) und der Dateiendung exe. Daher müssen Programme für die Verwendung im Testbed in dieser Form vorliegen. Der Name der Jobkonfigurationsdatei muss jcf lauten. Ihr Aufbau ist in Listing 3.1 dargestellt. : name <name > : description < description > : binaries <binary >,< binary_id >... : nodes <serial >,< node_id >,< binary_id >... : schedule <time >,<on/off >,< node_id /all >... <time >, end : conditions allow_concurrent_jobs =< yes /no > max_node_failures =< failures > max_node_server_failures =< failures > Listing 3.1: Aufbau der Jobkonfigurationsdatei In den Abschnitten name und description werden Name bzw. Beschreibung des Jobs angegeben. Im Abschnitt binaries werden die zu verwendenden Programme aufgelistet und mit einer eindeutigen ID versehen. Analog werden im Abschnitt nodes die Sensorknoten aufgelistet. Neben Angabe der Seriennummer des Knotens und einer eindeutigen ID wird hier auch die ID des Programms angegeben, das auf dem Knoten laufen soll. 10 für TinyOS geschaffene Erweiterung der Programmiersprache C 31

41 3 Entwurf des IHP-Testbeds Im Abschnitt schedule wird der Ablauf des Experiments definiert. Da das IHP-Testbed die Simulation von Knotenausfall und dem Hinzufügen bzw. Neustarten von Knoten unterstützen soll, können hier Knoten nach Ablauf einer bestimmten Zeit ein- und ausgeschaltet werden. Damit kann auch gezielt die Topologie des Sensornetzes während der Ausführung von Jobs verändert werden. In jeder Zeile des Abschnitts wird zunächst der Zeitpunkt (relativ zum Start des Experiments) eines Ereignisses in Millisekunden, danach die auszuführende Aktion (on für Knoten einschalten, off für Knoten ausschalten) und schließlich die ID des betreffenden Knotens (alternativ all für alle Knoten) angegeben. Die Ereignisse müssen chronologisch sortiert sein, wobei auch mehrere Ereignisse zu einem Zeitpunkt stattfinden können. Die Knoten sind initial ausgeschaltet, sodass sie zu Beginn des Experiments explizit eingeschaltet werden müssen, wobei auch ein zeitversetzter Start einzelner Knoten möglich ist. Die letzte Zeile des schedule-abschnitts definiert das Ende des Experiments. Dazu wird der Zeitpunkt und als Ereignis end angegeben. Im letzten Abschnitt conditions wird festgelegt, unter welchen Bedingungen ein Job ausgeführt werden kann. Prinzipiell können im Testbed mehrere Jobs mit disjunkten Knotenmengen und disjunkten Knoten-ID-Mengen gleichzeitig ausgeführt werden. Bei gleichzeitiger Ausführung mehrerer Jobs mit viel Drahtloskommunikation zwischen den Sensorknoten kann es jedoch zu Beeinflussungen und Störungen der Jobs untereinander kommen. Mit dem Parameter allow_concurrent_jobs besteht deshalb die Möglichkeit die gleichzeitige Ausführung anderer Jobs zu erlauben oder zu verbieten. Somit können Jobs auch ohne Störungen durch andere Jobs ausgeführt werden. Andere Störquellen wie WLAN und Bluetooth können damit jedoch nicht ausgeschlossen werden. Mit den letzten beiden Parametern max_node_failures und max_node_server_failures wird schließlich festgelegt, welche Hardwareausfälle toleriert werden können, bevor die Ausführung des Jobs abgebrochen werden soll (siehe dazu auch Abschnitt 3.9.1). Listing 3.2 zeigt eine Beispielkonfiguration für einen Job, bei dem ein Programm namens led.exe auf drei Sensorknoten mit den IDs 1, 3 und 7 getestet werden soll. Alle Knoten werden zum Beginn des Experimentes eingeschaltet. Die Knoten mit den IDs 1 und 7 werden nach 20 bzw. 22 s ausgeschaltet und 60 bzw. 60,5 s nach dem Start in umgekehrter Reihenfolge wieder eingeschaltet. Nach insgesamt 80 s soll das Experiment beendet werden. Der Benutzer hat in der Konfiguration zudem angegeben, dass andere Jobs gleichzeitig ausgeführt werden dürfen. Der Ausfall eines einzigen Sensorknotens ist akzeptabel. Ein in die Ausführung des Jobs involvierter Knotenserver sollte jedoch nicht ausfallen. 32

42 3 Entwurf des IHP-Testbeds : name Example : description Example of JCF usage : binaries led.exe,1 : nodes M4AP41AQ,1,1 M4AP118Y,3,1 M4AH6DF0,7,1 : schedule 0,on, all 20000, off, , off, , on, , on, , end : conditions allow_concurrent_jobs = yes max_node_failures =1 max_node_server_failures =0 Listing 3.2: Beispiel für eine Jobkonfigurationsdatei Log-Dateien Für jeden Sensorknoten, der in einen Job involviert ist, wird im entsprechenden Job- Verzeichnis eine Log-Datei angelegt, in der die von ihm empfangenen Daten bzw. Nachrichten gespeichert werden. Um die Analyse eines Experiments zu erleichtern, wird jeder Zeile der Log-Datei ein Zeitstempel vorangestellt. Eine neue Zeile wird nach Empfang eines Zeilenvorschubs ( \n ) begonnen. Neben den von den Sensorknoten empfangenen Nachrichten werden auch die in der Jobkonfigurationsdatei definierten Ereignisse, die den jeweiligen Knoten betreffen, in der Log-Datei festgehalten Simulation von Knotenausfall und Hinzufügen neuer Knoten In Abschnitt wurde beschrieben, dass Sensorknoten während der Ausführung von Jobs ein- und ausgeschaltet werden können. Im Folgenden werden verschiedene Möglichkeiten für die Realisierung dieser Funktion diskutiert. Eine Möglichkeit ist die Verwendung von USB-Hubs mit eigener Stromversorgung, welche nach der USB 2.0 Spezifikation [CHPI + 00] die Steuerung der Stromversorgung der USB-Ports unterstützen sollen. Mittels eines speziellen USB-Kommandos können so ge- 33

43 3 Entwurf des IHP-Testbeds zielt einzelne USB-Ports und damit auch die daran angeschlossenen Sensorknoten ein- und ausgeschaltet werden. Diese Variante kommt auch beim TKN-Testbed der TU Berlin (siehe Abschnitt 2.1.4) zum Einsatz. Die dort verwendeten Linksys USB2HUB4 11 sind allerdings neu kaum erhältlich. Es gibt zwar eine Reihe von USB-Hubs mit eigener Stromversorgung, jedoch ist bei diesen nicht ersichtlich, ob sie die Steuerung der Stromversorgung der Ports tatsächlich unterstützen. Eine weitere Möglichkeit ist die Verwendung einer speziellen Software-Komponente auf den Sensorknoten, welche ein Kommando vom Knotenserver empfängt und daraufhin den Sensorknoten abschaltet. Mittels eines speziellen Reset-Kommandos kann ein Knoten wieder gestartet werden. Die Software-Komponente zum Ausschalten verbraucht allerdings Speicherplatz, welcher dann der eigentlichen Anwendung nicht mehr zur Verfügung steht. Außerdem obliegt es allein dem Benutzer, die Komponente in seine Anwendung zu integrieren und sie korrekt mit anderen Komponenten (z. B. der Komponente für die Kommunikation per Universal Asynchronous Receiver/Transmitter (UART)) zu verknüpfen. Aus diesem Grund wurde für das IHP-Testbed die folgende Variante implementiert. Um einen Sensorknoten auszuschalten, wird dieser neu programmiert, jedoch nicht neugestartet. Ein Neustart erfolgt erst, um den Knoten wieder einzuschalten. Bei Messungen der benötigten Programmierzeit eines Tmote Sky mit einer Symbolrate von Baud auf den als Knotenservern verwendeten fit-pc2i wurde festgestellt, dass sie erwartungsgemäß linear von der Programmgröße (siehe Abbildung 3.3 a), aber exponentiell von der Anzahl der gleichzeitig programmierten Knoten (siehe Abbildung 3.3 b) abhängt Programmierdauer [s] Programmierdauer [s] Programmgröße [Bytes] Anzahl Sensorknoten 1 Knoten 4 Knoten 8 Knoten 10 Knoten 1396 Bytes Bytes Bytes Bytes Bytes Bytes (a) (b) Abbildung 3.3.: Programmierdauer auf fit-pc2i mit Intel SCH US15W-Chip

44 3 Entwurf des IHP-Testbeds Dies ist wahrscheinlich auf die limitierten Ressourcen des in den fit-pc2i verwendeten Chips SCH US15W [Int10] zurückzuführen. Auf einem Desktop-PC mit einem ICH10- Chipsatz [Int08] konnte lediglich ein linearer Anstieg der Programmierdauer beobachtet werden (siehe Abbildung 3.4). 20 Programmierdauer [s] Bytes Bytes Anzahl Sensorknoten Bytes Bytes Bytes Bytes Abbildung 3.4.: Programmierdauer auf Desktop-PC mit Intel ICH10-Chipsatz In der Jobkonfigurationsdatei kann nicht nur der Ausfall eines einzelnen, sondern auch der gleichzeitige Ausfall aller an einen Knotenserver angeschlossenen Sensorknoten geplant werden. Da ein Sensorknoten erst dann wieder eingeschaltet (neugestartet) werden kann, nachdem ein Programmiervorgang abgeschlossen wurde, wird wegen des exponentiellen Anstiegs der Programmierdauer als Kompromiss zwischen Programmierdauer und pro Knotenserver einsetzbaren Sensorknoten die Anzahl der Sensorknoten pro Knotenserver auf acht festgelegt (je ein 4-Port-USB-Hub pro Typ-A-Port des fit-pc2i). Damit wird der zeitliche Mindestabstand zwischen dem Ausschalten und wieder Einschalten eines Knotens begrenzt. Aufgrund des linearen Zusammenhangs zwischen Programmgröße und Programmierzeit lässt sich die benötigte Zeit für beliebige Programme mit der folgenden Formel berechnen (acht Tmote Sky an fit-pc2i, Symbolrate: Baud): P rogrammierzeit[s] = 0,66 s/kbyte P rogrammgrösse[kbytes] + 2,67 s Die gleichzeitige Programmierung aller acht Sensorknoten eines Knotenservers mit einem Programm maximaler Größe (48 kb bei Tmote Sky) dauert somit auf den fit-pc2i etwa 34,4 s. Für die Festlegung des Mindestabstands zwischen Ausschalten und wieder Einschalten wird der berechnete Wert sicherheitshalber aufgerundet und 1 s aufaddiert und beträgt damit bei einem Programm dieser Größe 36 s. Damit der Mindestabstand nicht unnötig groß wird, wird er für jeden Sensorknoten anhand der Größe des verwendeten Programms separat berechnet. Die für einen Neustart eines Sensorknotens benötigte Zeit steigt linear mit der Anzahl der gleichzeitig neugestarteten Knoten und beträgt bei acht Knoten 35

45 3 Entwurf des IHP-Testbeds etwa 1,3 s. Der Mindestabstand zwischen einem Einschalt-Ereignis und anschließendem Ausschalt-Ereignis wird daher auf 3 s festgelegt. Am Ende eines Jobs werden die Sensorknoten mit einem Programm programmiert, das sie schlafen lässt, sodass andere Experimente nicht gestört werden. Dies kann allerdings erst geschehen, nachdem eine vorherige Aktion (Programmieren oder Neustarten) abgeschlossen ist. Aus diesem Grund muss zwischen dem letzten Ausschalten eines Knotens und dem Ende des Jobs ebenfalls der von der Programmgröße abhängige Mindestabstand eingehalten werden. Der Mindestabstand zwischen dem letzten Einschalten eines Knotens und dem Ende beträgt wiederum 3 s. Ein Nachteil dieser Lösung für das Ein- und Ausschalten der Sensorknoten ist der etwas höhere Verschleiß des Flashspeichers der Sensorknoten, da für jeden Ausschaltvorgang das komplette Programm neu in den Speicher geschrieben wird. Zudem gibt es durch die Mindestabstände zwischen Ein- und Ausschaltvorgängen Einschränkungen bei der Planung dieser Ereignisse Zeitsynchronisation Die Synchronisation der Uhren der Testbed-Komponenten ist zum einen nötig, um die in der Jobkonfigurationsdatei festgelegten Ereignisse zur richtigen Zeit und vor allem in der richtigen Reihenfolge ausführen zu können. Außerdem ist dies wichtig für die Auswertung eines Experiments, da nur so die Reihenfolge der von den Sensorknoten an die Knotenserver gesendeten Daten und deren zeitliche Abstände ermittelt werden kann. Zunächst soll ermittelt werden, welche Genauigkeit bei der Synchronisation erforderlich ist. Für die Analyse von z. B. Routing- oder Datenübertragungsprotokollen ist es wichtig, dass Sende- und Empfangsereignisse in der richtigen Reihenfolge erfasst werden, dass also der Empfang einer Nachricht nicht vor deren Versand gemeldet wird. Der Versand eines minimalen MAC-Frames (siehe Abbildung 3.5) von 14 Bytes Länge (1 Byte Nutzdaten, 2 Byte Empfängeradresse wie in TinyOS üblich) dauert bei einem Tmote Sky mit einer Übertragungsrate von 250 kbps etwa 448 µs. Nach Empfang des Frames muss der Mikrocontroller des Empfängerknotens die MAC Protocol Data Unit (MPDU) über das Serial Peripheral Interface (SPI) aus dem Empfangspuffer des Transceivers (CC2420) lesen. Die SPI-Clock ist bei den Tmote-Sky-Sensorknoten mit 510 khz getaktet. Da der Mikrocontroller zwischen dem Lesen zweier Bytes mindestens 50 µs wartet [BSL10], dauert das Lesen der MPDU (8 Bytes) mindestens 475 µs. Der Versand einer minimalen Nachricht (von Sendebeginn bis Lesen der Nachricht vom Transceiver beim Empfänger) dauert damit etwa 923 µs. Um die richtige Reihenfolge von Sende- und Empfangsereignissen rekonstruieren zu können, wird somit eine Genauigkeit der Uhren von mindestens 460 µs benötigt. Die zeitliche Festlegung der in der Jobkonfiguration definierten Ereignisse (simulierter Kno- 36

46 3 Entwurf des IHP-Testbeds tenausfall bzw. Hinzufügen von Knoten) erfolgt in Millisekunden. Eine Genauigkeit von 460 µs ist damit auch für die Ausführung dieser Ereignisse in der richtigen Reihenfolge ausreichend. MAC Layer PHY Layer Bytes: Start of frame Preamble Delimiter Sequence (SFD) Synchronisation Header (SHR) Frame Length PHY Header (PHR) Bytes: to 20 n 2 Frame Data Frame Check Address Control Field Sequence Frame payload Sequence Information (FCF) Number (FCS) MAC Header (MHR) MAC Payload MAC Footer (MFR) 11 + (0 to 20) + n PHY Protocol Data Unit (PPDU) 5 + (0 to 20) + n MAC Protocol Data Unit (MPDU) PHY Service Data Unit (PSDU) Abbildung 3.5.: IEEE MAC Frame Quelle: CC2420 Datasheet [Tex07] Für die Synchronisation der Testbed-Komponenten steht eine Vielzahl von Synchronisationsprotokollen und -algorithmen zur Verfügung. Eines der bekanntesten ist das Network Time Protocol (NTP) [MMBK10]. Bei Verwendung von NTP in lokalen Netzwerken können Abweichungen bis wenige Millisekunden auftreten [Mil94], womit dieses Verfahren für das Testbed zu ungenau ist. Ein weiteres Protokoll ist das Precision Time Protocol (PTP), standardisiert als IEEE 1588 [Ins02]. In lokalen Netzen (engl. Local Area Network (LAN)) können mit Software-Implementierungen von PTP Genauigkeiten von 100 bis 5 µs erreicht werden [End, Hir]. Dieses Protokoll wäre damit für die Synchronisation der per Ethernet mit dem Testbed-Server verbundenen Knotenserver geeignet. Auch im WLAN können Genauigkeiten von wenigen Mikrosekunden erreicht werden. Bei größerem Datenverkehr steigen die Abweichungen jedoch auf mehrere hundert Mikrosekunden [KVHH04]. Für die Synchronisation der per WLAN verbundenen Knotenserver wäre dieses Protokoll damit zu ungenau. Eine Alternative wäre z. B. die Reference-Broadcast Synchronization (RBS) [EGE02], welche im WLAN selbst bei starkem Datenverkehr Genauigkeiten um 50 µs erreicht. Auch mit der zu IEEE kompatiblen Clock Sampling Mutual Network Synchronization (CSMNS) [RK05] können Genauigkeiten von wenigen Mikrosekunden erreicht werden. Für die Wahl eines geeigneten Zeitsynchronisationsverfahren für die per WLAN verbundenen Knotenserver sind allerdings weitere Untersuchungen nötig Ressourcenzuteilung Bei den im Testbed verfügbaren Ressourcen handelt es sich um Sensorknoten und Zeit. Die Sensorknoten werden von den Benutzern des Testbeds für ihre Experimente selbst ausgewählt, damit sie gezielt die Topologie des Sensornetzes, in dem ihre Anwendung getestet 37

47 3 Entwurf des IHP-Testbeds wird, bestimmen können. Außerdem legen sie die Dauer eines Experiments fest. In diesem Abschnitt soll nun eine Methode gefunden werden, die festlegt, wann welcher Job ausgeführt wird, d. h. wann eine Menge von Sensorknoten für eine bestimmte Dauer durch einen Benutzer belegt werden kann. Prinzipiell können im Testbed mehrere Jobs mit disjunkten Knotenmengen und disjunkten Knoten-ID-Mengen gleichzeitig ausgeführt werden. Jobs mit sich überschneidenden Knotenmengen oder Knoten-ID-Mengen müssen nacheinander ausgeführt werden. Für die Festlegung der Reihenfolge gibt es verschiedene Methoden, die die Kriterien Durchsatz, Auslastung und Fairness unterschiedlich gut erfüllen. Optimaler Durchsatz bedeutet, dass in einem bestimmten Zeitraum soviele Jobs wie möglich erledigt werden. Hierfür bietet sich z. B. die Strategie Shortest-Job-Next (SJN) bzw. Shortest-Job-First (SJF) an, bei der immer der kürzeste Job in der Warteschlange als nächstes ausgeführt wird. Nachteil dieser Strategie ist, dass lange Jobs möglicherweise nie ausgeführt werden, wenn regelmäßig neue kürzere Jobs zur Warteschlange hinzugefügt werden. Fairness ist dadurch nicht gegeben. Fairness lässt sich z. B. mit dem FCFS-Verfahren erreichen, bei dem die Jobs in der Reihenfolge ihres Eingangs abgearbeitet werden. Dabei können wie eingangs erwähnt u. U. auch mehrere Jobs gleichzeitig ausgeführt werden. Es wird u. a. bei MoteLab, Kansei und ORBIT verwendet (siehe Abschnitte 2.1.1, 2.1.2, 2.1.3). Um die Fairness zu verbessern, erhält bei MoteLab zusätzlich jeder Benutzer ein Zeitkontingent, das die maximale Gesamtdauer aller einplanbaren Jobs vorgibt. Dadurch wird verhindert, dass ein einzelner Benutzer die Ressourcen des Testbeds über längere Zeit für sich beanspruchen kann. Möglich wäre zudem auch die Vergabe von Prioritäten durch die Benutzer, um die Wichtigkeit eines Jobs auszudrücken. Die Jobs würden zunächst nach Prioritäten sortiert und dann innerhalb der Prioritätsklassen nach dem FCFS-Verfahren abgearbeitet werden. Damit auch Jobs niedriger Priorität irgendwann ausgeführt werden, kann die Priorität eines Jobs automatisch mit der Zeit erhöht werden. Nachteil des FCFS-Verfahrens ist, dass nur selten eine optimale Auslastung des Testbeds erreicht wird. Wenn beispielsweise momentan nur ein einziger Sensorknoten durch einen Job belegt ist und dieser Sensorknoten vom ersten Job in der Warteschlange benötigt wird, kann dieser Job und wegen des FCFS-Prinzips auch alle anderen Jobs nicht ausgeführt werden, obwohl die dafür benötigten Sensorknoten evtl. verfügbar wären. Um eine optimale Auslastung und damit Effizienz des Testbeds zu erreichen müssen ggf. die Jobs in der Warteschlange umsortiert werden. Bei der Fairness müssen dabei jedoch Abstriche gemacht werden, da u. U. später eingeplante Jobs eher ausgeführt werden. 38

48 3 Entwurf des IHP-Testbeds Ein Kompromiss zwischen Fairness und Auslastung kann z. B. mit dem Ressourcenzuteilungssystem Mirage (siehe Abschnitt 2.1.5) erreicht werden, bei dem in regelmäßig stattfindenden Auktionsrunden ermittelt wird, welche Benutzer Zugriff auf das Testbed erhalten. Durch die Höhe der Gebote wird die Wichtigkeit und damit die Priorität ausgedrückt. Fairness wird durch die Begrenzung der jedem Benutzer zur Verfügung stehenden Geldmenge erreicht. Durch die Art und Weise der Auswahl der Gewinner einer Auktionsrunde wird eine möglichst gute Auslastung des Testbeds erreicht. Da sich das IHP-Testbed noch im Aufbau befindet und damit zunächst nicht mit einer großen Nachfrage zu rechnen ist, soll für die Ressourcenzuteilung anfangs wie bei Mote- Lab das FCFS-Verfahren mit zusätzlichem Zeitkontingent für jeden Benutzer verwendet werden. Bei steigender Nachfrage sollte dieses Verfahren hinsichtlich der Auslastung des Testbeds optimiert und ggf. ein System wie Mirage implementiert werden Job-Lebenszyklus In diesem Abschnitt soll anhand des Lebenszyklus eines Jobs die Funktionsweise des Testbeds und das Zusammenspiel der Komponenten erläutert werden. Der gesamte Ablauf ist in den Abbildungen A.2 bis A.4 im Anhang A.3 dargestellt und wird in den folgenden Unterabschnitten erläutert Start des Testbeds Ausgangspunkt für die Beschreibung bildet ein vollständig abgeschaltetes Testbed. Zunächst wird der Testbed-Server eingeschaltet. Die darauf laufende Software für den Betrieb des Testbeds wird automatisch als Linux-Daemon gestartet. Zunächst wird die Testbed- Datenbank und Verzeichnisse für Jobs und deren Ergebnisse angelegt, sofern diese noch nicht existieren. Anschließend wartet der Testbed-Server auf eingehende Verbindungen von Knotenservern oder dem Benutzerschnittstellenprogramm (BSP). Danach werden die Knotenserver gestartet, wobei die auf ihnen laufende Software ebenfalls als Linux-Daemon arbeitet. Nach dem Start ermitteln die Knotenserver, welche Sensorknoten an sie angeschlossen sind. Anschließend verbinden sie sich mit dem Testbed-Server 12 und übertragen eine Liste der Sensorknoten und die eigene MAC-Adresse, die der Identifikation der Knotenserver dient. Anschließend ist das Testbed betriebsbereit Erstellen eines neuen Jobs Nach dem Start des Testbeds können nun Jobs zur Ausführung erstellt werden. Dazu startet ein in diesem Beispiel bereits registrierter Benutzer das BSP, welches daraufhin 12 Die TCP-Verbindung zwischen Testbed-Server und Knotenservern bleibt dauerhaft bestehen. 39

49 3 Entwurf des IHP-Testbeds automatisch eine Verbindung zum Testbed-Server herstellt. Der Benutzer kann sich nun mit adresse oder Konto-ID und Passwort beim Testbed-Server anmelden. Dieser sendet eine Bestätigung, falls die Benutzerdaten gültig sind. Um einen neuen Job erstellen zu können, muss der Benutzer zunächst in Erfahrung bringen, welche Sensorknoten im Testbed zur Verfügung stehen und wie die Konnektivität (siehe Abschnitt 3.8) zwischen diesen aussieht. Diese Informationen kann er über das BSP vom Testbed-Server abrufen und anschließend eine Jobkonfigurationsdatei (siehe Abschnitt 3.3.2) erstellen. Diese Konfigurationsdatei muss zusammen mit den zu verwendenden Sensorknotenprogrammen in einem Verzeichnis abgelegt werden. Dieses wird beim Erstellen des Jobs angegeben. Die Konfigurationsdatei wird zunächst vom BSP auf Korrektheit überprüft (u. a. Eindeutigkeit der Programm- und Knoten-IDs, ausreichend großer Abstand zwischen den Ereignissen (siehe Abschnitt 3.4)) und anschließend mit den im Verzeichnis enthaltenen Programmdateien zum Testbed-Server übertragen. Dieser prüft als erstes, ob die in der Konfigurationsdatei angegebenen Sensorknoten tatsächlich existieren. Danach vergibt er dem neuen Job eine ID, speichert die empfangenen Job-Dateien in einem entsprechenden Verzeichnis und legt einen neuen Eintrag für den Job in der Datenbank an. Die vergebene ID wird an das BSP gesendet. Diese benötigt der Benutzer später u. a. für das Abrufen der Ergebnisse. Daraufhin kann sich der Benutzer vom Testbed abmelden Ausführung des Jobs Der momentane Entwurf sieht vor, dass Jobs nach dem FCFS-Verfahren abgearbeitet werden (siehe Abschnitt 3.6). Der nächste Job in der Jobliste kann ausgeführt werden, wenn kein anderer Job ausgeführt wird oder sowohl die bereits laufenden Jobs als auch der nächste auszuführende Job die gleichzeitige Ausführung anderer Jobs erlauben. Weiterhin müssen alle benötigten Sensorknoten verfügbar sein und die zugewiesenen Knoten-IDs dürfen nicht schon in laufenden Jobs verwendet werden. Für die Ausführung erzeugt der Testbed-Server zunächst für jeden involvierten Knotenserver eine angepasste Jobkonfigurationsdatei, die nur die Sensorknoten (und entsprechenden Ereignisse) enthält, die an dem jeweiligen Knotenserver angeschlossen sind. Auf diese Weise kann sichergestellt werden, dass alle benötigten Sensorknoten tatsächlich verfügbar sind. Sollte ein Sensorknoten nicht vorhanden sein, bemerkt dies der betroffene Knotenserver und kann es dem Testbed-Server mitteilen. Die angepassten Jobkonfigurationsdateien und jeweils benötigten Programme werden an die Knotenserver übertragen. Diese bestätigen den neuen Job, falls alle benötigten Sensorknoten verfügbar (d. h. angeschlossen und inaktiv) sind. Danach wählt der Testbed-Server eine Startzeit für den Job, teilt diese den Knotenservern mit und vermerkt sie in der Datenbank. Die Startzeit wird dabei so gewählt, dass die Knotenserver genügend Zeit für die initiale Programmierung der Sensorknoten vor Job-Beginn haben. In der Zeit bis zum Start des Jobs erzeugen die Knotenserver aus den Programmdateien für jeden Sensorknoten neue Programmdateien, in denen die in der Jobkonfigurationsdatei definier- 40

50 3 Entwurf des IHP-Testbeds ten Knoten-IDs entsprechend gesetzt sind (siehe Abschnitt 4.2.6). Anschließend werden die Sensorknoten mit den angepassten Programmen initial programmiert, aber noch nicht gestartet. Ab dem mitgeteilten Startzeitpunkt arbeiten die synchronisierten Knotenserver die Ereignisliste der Konfigurationsdatei ab und speichern die von den Sensorknoten empfangenen Daten in Log-Dateien. Das Ein- und Ausschalten (d. h. Neustarten bzw. Programmieren) der Knoten erfolgt in jeweils dafür erzeugten Prozessen, sodass mehrere Knoten parallel programmiert werden können. Am Ende des Jobs werden alle Knoten mit einem Programm beschrieben, das sie schlafen lässt. Die Knotenserver teilen dem Testbed- Server die Beendigung des Jobs mit, woraufhin dieser die Log-Dateien von ihnen anfordert. Abschließend wird der Zeitpunkt der Beendigung des Jobs in der Datenbank vermerkt Abrufen der Ergebnisse und Löschen des Jobs Nach Beendigung des Jobs kann sich der Benutzer erneut anmelden und die Ergebnisse des Jobs unter Angabe der ID abrufen. Danach kann der Benutzer den Job löschen. Das BSP sendet ein entsprechendes Kommando an den Testbed-Server, woraufhin dieser die betreffenden Job- und Log-Dateien und den Datenbankeintrag des Jobs löscht. Außerdem sendet er einen Löschbefehl an die in den Job involvierten Knotenserver, welche ebenfalls alle betreffenden Dateien löschen Ermittlung der Konnektivität Für die Planung von Experimenten und der dabei verwendeten Topologie des Sensornetzes ist es wichtig, die Konnektivität zwischen den Sensorknoten des Testbeds zu kennen. Zu diesem Zweck werden die paarweise Paketverlustrate und die Indikatoren für Empfangsfeldstärke (engl. Received Signal Strength Indication (RSSI)) und Verbindungsqualität (engl. Link Quality Indication (LQI)) ermittelt. Ähnlich wie in Motelab (siehe Abschnitt 2.1.1) wird dazu regelmäßig (z. B. mehrmals am Tag oder nach jedem Job) ein spezieller Job ausgeführt. Die Ausführung wird vom Testbed-Server angestoßen, indem er einen Ablaufplan an die Knotenserver sendet. Diese programmieren daraufhin die angeschlossenen Sensorknoten mit einem Konnektivitätsprogramm. Alle Sensorknoten befinden sich nach dem Start dieses Programms im Empfangsmodus. Entsprechend dem Ablaufplan sendet ein Programm auf den Knotenservern nacheinander an jeden angeschlossenen Sensorknoten ein Kommando, welche daraufhin eine bestimmte Anzahl an Broadcast- Nachrichten 13 mit verschiedenen Sendeleistungen senden. Die verwendete Sendeleistung ist neben der Sequenznummer in den Nutzdaten der gesendeten Nachrichten enthalten. Jeder Sensorknoten ermittelt für die empfangenen Nachrichten die RSSI- und LQI-Werte und die Paketverlustrate und überträgt sie an die jeweiligen Knotenserver, von wo sie weiter zum Testbed-Server übertragen werden. Der Vorgang wird mehrfach wiederholt 13 Nachricht an alle anderen Netzteilnehmer 41

51 3 Entwurf des IHP-Testbeds und die ermittelten Werte gemittelt, um den Einfluss von kurzzeitigen Störungen auf die Konnektivitätswerte zu verringern Testbed-Überwachung Die Überwachung der korrekten Funktion der Testbed-Hardware ist wie schon am Ende des Abschnitts beschrieben essentiell für den Betrieb eines Testbeds. Die Überprüfung der korrekten Funktion der Hardware des IHP-Testbeds ist durch die regelmäßige Ermittlung der Konnektivität zwischen den Sensorknoten bereits abgedeckt, da sämtliche Knotenserver und Sensorknoten darin involviert sind. Wenn ein Knotenserver bzw. dessen Software ausgefallen ist oder ein Sensorknoten nicht mehr programmiert werden kann, wird dies dabei festgestellt. Auch isolierte Sensorknoten, die keine Nachrichten von anderen Knoten mehr empfangen können oder deren Nachrichten von keinem anderen Knoten empfangen werden, können damit erkannt werden Verhalten bei Hardwareausfall Im Folgenden wird das Verhalten des Testbeds bei Ausfall von Hardware während der Ausführung von Jobs beschrieben. Ausfall eines Sensorknotens Im Verlauf eines Experiments sollen ggf. Sensorknoten aus- und wieder eingeschaltet werden, wofür sie neu programmiert bzw. neugestartet werden. Sollte dabei ein Fehler auftreten (z. B. Programmierung schlägt fehl oder Sensorknoten reagiert nicht), wird dies in der Log-Datei des betreffenden Knotens vermerkt und ggf. dem Testbed-Server mitgeteilt. Die Ausführung des Jobs wäre damit eigentlich fehlgeschlagen. Möglicherweise ist jedoch bei bestimmten Experimenten der Ausfall einzelner Sensorknoten tolerierbar. Für diesen Fall kann der Benutzer in der Jobkonfigurationsdatei festlegen, wieviele Sensorknoten maximal ausfallen dürfen bevor der Job abgebrochen wird (siehe Abschnitt 3.3.2). Auf diese Weise können die Testbed-Ressourcen effizienter genutzt werden, da auf die erneute Ausführung von Jobs u. U. verzichtet werden kann. Nachfolgende Jobs, bei denen ausgefallene Sensorknoten zum Einsatz kommen sollen, werden erst ausgeführt, wenn diese Sensorknoten wieder funktionsfähig sind. Ausfall eines Knotenservers Wenn die Software eines Knotenservers während der Ausführung eines Jobs ausfällt, können die von den Sensorknoten gesendeten Daten nicht mehr empfangen und gespeichert werden. Auch die in der Jobkonfigurationsdatei definierten Ereignisse werden nicht mehr 42

52 3 Entwurf des IHP-Testbeds simuliert. Wenn der Knotenserver selbst ausfällt (z. B. durch Hardwaredefekt oder Stromausfall), werden die angeschlossenen Sensorknoten u. U. nicht mehr mit Strom versorgt und fallen ebenfalls aus. Ob der Ausfall von Knotenservern tolerierbar ist, kann ebenfalls in der Jobkonfigurationsdatei festgelegt werden (siehe Abschnitt 3.3.2). Der Ausfall eines Knotenservers wird vom Testbed-Server durch Abbruch der Verbindung zum Knotenserver festgestellt. Stellt der Knotenserver innerhalb einer noch zu definierenden Zeit bzw. bis zum Ende des Jobs keine neue Verbindung her, muss der Ausfall des Knotenservers angenommen werden. Dies wird in den Log-Dateien betroffener Jobs vermerkt und Jobs, die den Ausfall nicht tolerieren, werden abgebrochen. Wird die Verbindung wiederhergestellt, gibt es zwei Möglichkeiten. Entweder war tatsächlich nur die Verbindung unterbrochen und der Knotenserver war nicht ausgefallen oder er wurde neugestartet. Im ersten Fall wurde die Ausführung der Jobs nicht unterbrochen, da die Knotenserver dies autonom erledigen. War bereits der definierte Zeitraum für die Wiederherstellung der Verbindung abgelaufen, muss der Vermerk über den Ausfall gestrichen und der Zähler für ausgefallene Knotenserver bei den noch laufenden Jobs um 1 verringert werden. Wurde der Knotenserver neugestartet oder hat dies automatisch getan, wird das als Ausfall gewertet und entsprechend in den Log-Dateien vermerkt. Die Ausführung von Jobs, die den Ausfall tolerieren, kann vom Knotenserver wieder aufgenommen werden. Dazu erfragt dieser beim Testbed-Server, welche Jobs gerade auf dem Knotenserver laufen sollten und deren Startzeit. Neue Jobs werden nur gestartet, wenn alle benötigten Sensorknoten verfügbar sind. Jobs, die Sensorknoten benötigen, die an einen ausgefallenen Knotenserver angeschlossen sind, werden übersprungen bis dieser wieder läuft. Ausfall des primären Testbed-Servers Zur Erkennung des Ausfalls des primären Testbed-Servers besteht zwischen diesem und dem zweiten Testbed-Server eine permanente TCP-Verbindung. Sollte diese unterbrochen werden, fragt der zweite Server bei den Knotenservern nach, ob diese noch eine Verbindung zum ersten Server haben. Ist bei diesen ebenfalls die Verbindung zum ersten Server unterbrochen, kann von dessen Ausfall ausgegangen werden und der zweite Server übernimmt den Betrieb des Testbeds. Die Knotenserver verbinden sich dann automatisch zu diesem. Sollte auch der zweite Testbed-Server ausfallen, können die laufenden Jobs von den Knotenservern autonom weiter ausgeführt werden. Neue Jobs können jedoch erst gestartet werden, wenn einer der beiden Testbed-Server wieder läuft und die Verbindung zu den Knotenservern wiederhergestellt wurde. Auch die Benutzerschnittstelle steht erst dann wieder zur Verfügung. 43

53 3 Entwurf des IHP-Testbeds Testbed-Software In diesem Abschnitt wird zunächst die Architektur der Testbed-Software beschrieben. Anschließend wird erläutert, wie die Software auf dem Testbed-Server und den Knotenservern gestartet wird. Eine Übersicht der zwischen den Testbed-Komponenten ausgetauschten Nachrichten befindet sich in Anhang A Software-Architektur Die Architektur der Software und ihre Komponenten sind in Abbildung 3.6 dargestellt und werden im Folgenden kurz beschrieben. Testbed Server Testbed DB JCF Reader Job Manager SQLite Wrapper SQLite Library Node Server Node Manager User Interface Menu Timer Connectivity Manager Timer Job Runner JCF Reader Connection Manager JCF Reader TCP Transceiver TCP Socket TCP Transceiver TCP Socket TCP Transceiver TCP Socket Abbildung 3.6.: Komponenten der Testbed-Software User Interface (Benutzerschnittstelle) Menu zeigt das Benutzer- bzw. Administratormenü an und nimmt Eingaben entgegen Testbed Server Job Manager verwaltet die Jobs und entscheidet, wann welcher Job ausgeführt wird; bereitet zudem ihre Ausführung vor (Wahl der Startzeit und Einholen der Bestätigung von den Knotenservern) und überwacht ihre Beendigung (Warten auf Beendigungsnachricht von den Knotenservern) 44

54 3 Entwurf des IHP-Testbeds SQLite Library SQLite-C-Programmbibliothek SQLite Wrapper C++-Wrapper für die SQLite-Bibliothek Testbed DB Zugriff auf die Testbed-Datenbank über testbedspezifische Funktionen (z. B. Sensorknoten hinzufügen, Liste der Benutzerkonten abfragen) Connectivity Manager führt regelmäßig und bei Bedarf (von einem Administrator ausgelöst) eine Aktualisierung der Konnektivitätsinformationen durch und bereitet die ermittelten Werte auf Connection Manager verwaltet die Verbindungen zu Benutzerschnittstellen und Knotenservern und ordnet ihnen die dazugehörigen Konto-IDs bzw. MAC-Adressen zu Node Server (Knotenserver) Job Runner führt die Jobs aus und schaltet entsprechend dem in der Jobkonfigurationsdatei festgelegten Ablaufplan die Sensorknoten ein und aus Node Manager ermittelt und verwaltet die angeschlossenen Sensorknoten und stellt Funktionen für die Programmierung und den Neustart der Knoten bereit Gemeinsame Komponenten JCF Reader liest Jobkonfigurationsdateien ein und speichert die enthaltenen Informationen in geeigneten Datenstrukturen für die Verwendung durch andere Komponenten TCP Socket stellt eine TCP-Verbindung zu anderen Testbed-Komponenten her TCP Transceiver ermöglicht Nachrichten- und Dateiversand über einen TCP-Socket Timer stellt die typischen Funktionen eines Timers zur Verfügung und ermittelt die aktuelle Zeit 45

55 3 Entwurf des IHP-Testbeds Start der Testbed-Software Damit der Testbed-Server und die Knotenserver ohne Peripherie (Monitor, Tastatur) betrieben werden können, wird die auf ihnen laufende Software beim Start der Server automatisch als Linux-Daemon (Hintergrundprozess) gestartet. Um Ausfallzeiten durch Abstürze der Software so kurz wie möglich zu halten, soll sie automatisch neugestartet werden. Eine Möglichkeit, um dies zu realisieren, ist die Verwendung eines Überwachungsprozesses, welcher statt der Testbed-Software als Daemon gestartet wird. Erst dieser Überwachungsprozess startet dann die Testbed-Software. Sollte sie abstürzen, wird dies dem Überwachungsprozess durch ein Signal 14 mitgeteilt, welcher daraufhin die Software neustarten kann. Genau diese Funktionalität bietet der Linux-Daemon init, weshalb dieser für den Start und die Überwachung der Testbed-Software verwendet wird. 14 Systemnachricht an einen laufenden Prozess 46

56 4. Implementierung der Testbed-Software In diesem Kapitel wird die Implementierung der Software des IHP-Testbeds und einiger ihrer Komponenten beschrieben. Abschnitt 4.1 erläutert zunächst den aktuellen Stand der Implementierung. Der Aufbau und die Funktionsweise einiger Software-Komponenten wird in Abschnitt 4.2 beschrieben. Abschnitt 4.3 erklärt schließlich, wie weitere Sensorknotenplattformen (neben Tmoty Sky und Tmote Invent) und Betriebssysteme (neben TinyOS) im Testbed verwendet werden können Stand der Implementierung Die Testbed-Software wurde in C++ geschrieben und ist konform zum Portable Operating System Interface (POSIX) IEEE-Standard [Ins08]. Sie kann daher auf allen POSIX konformen Systemen kompiliert und ausgeführt werden. Für die Kompilierung des Quellcodes wird ein Makefile bereitgestellt, sodass die Testbed-Software mithilfe des Programms make erzeugt werden kann. Die aktuelle Implementierung enthält alle Funktionen, die für den Grundbetrieb eines Testbeds benötigt werden. Sie ermöglicht das Abrufen einer Liste aller Sensorknoten und Jobs, die automatische Ausführung von Jobs (inkl. Ein- und Ausschalten von Sensorknoten) und das Abrufen der Ergebnisse. Die gleichzeitige Ausführung mehrerer Jobs wird jedoch noch nicht unterstützt. Weiterhin müssen noch folgende Komponenten bzw. Funktionalitäten implementiert werden: Administrator- und Benutzerkonten (siehe u. a. Abschnitt 3.3.1) Verwaltung der Testbed-Sockets 15 inkl. ihrer Position (siehe Abschnitt 3.2.3) Connection Manager (siehe Abschnitt ) Gültigkeitsprüfung der Jobkonfigurationsdatei (siehe Abschnitt 3.3.2) Konnektivitätsermittlung (siehe Abschnitt 3.8) Verhalten bei Hardwareausfall (siehe Abschnitt 3.9.1) 15 Momentan werden die Sensorknoten lediglich den Knotenservern zugeordnet. 47

57 4 Implementierung der Testbed-Software 4.2. Aufbau und Funktionsweise des Codes In diesem Abschnitt wird zunächst der Aufbau des Testbed-Server- und Knotenserver- Hauptprogramms erläutert. Anschließend wird die Implementierung und Verwendung einiger Komponenten der Testbed-Software (siehe Abbildung 3.6) beschrieben Testbed-Server Der Ablauf des Testbed-Server-Programms ist in Abbildung 4.1 dargestellt. Nach dem Start des Programms werden in der Initialisierungsphase die verwendeten Komponenten (siehe Abbildung 3.6) erzeugt. Für die Kommunikation mit dem BSP und den Knotenservern werden Sockets verwendet. Dabei handelt es sich um eine Schnittstelle für die Interprozess- und Netzwerkkommunikation. Für die Netzwerkkommunikation über Sockets können verschiedene Protokolle wie z. B. TCP oder das User Datagram Protocol (UDP) verwendet werden. Für das IHP-Testbed wird TCP als Kommunikationsprotokoll verwendet, da es den zuverlässigen Austausch von Nachrichten realisiert. Es werden zunächst zwei Sockets erzeugt, die nur dem Zweck dienen, auf neue Verbindungen zu warten einer für das BSP und einer für die Knotenserver. Nach der Initialisierungsphase tritt das Programm in eine Endlosschleife. An deren Beginn wird darauf gewartet, dass ein BSP oder ein Knotenserver eine Verbindung aufbauen will oder eine Nachricht sendet. Für den Aufbau einer neuen Verbindung wird ein neuer Socket erzeugt, über den dann die Kommunikation läuft. Die so erzeugten Sockets und damit die Verbindungen zum BSP und den Knotenservern werden vom Connection Manager verwaltet. Wenn eine Nachricht empfangen wurde, wird diese vom jeweiligen Socket gelesen und verarbeitet. Für das Warten auf neue Verbindungen und Nachrichten wird die Methode pselect() verwendet. Alternativ könnte für jeden Socket ein eigener Prozess erzeugt werden, in dem dann mit einem blockierenden Aufruf von accept() oder read() auf neue Verbindungen bzw. den Empfang einer Nachricht gewartet wird. Jedoch müssten diese Prozesse auf gemeinsame Daten für die Verwaltung der Verbindungen und die Verarbeitung empfangener Nachrichten zugreifen. Dazu müssten die Zugriffe auf die gemeinsamen Daten synchronisiert werden. Um diesen zusätzlichen Aufwand zu vermeiden, wurde stattdessen pselect() verwendet, womit in einem einzigen Prozess mehrere Sockets überwacht werden können. Mittels des Aufrufs von pselect() wird nicht nur auf Socket-Ereignisse, sondern auch auf das Ablaufen von Timern, welche in den in der Initialisierungsphase erzeugten Komponenten verwendet werden, gewartet. Ist einer der Timer abgelaufen, wird eine entsprechende Methode zur Behandlung dieses Ereignisses aufgerufen. Details zur Implementierung und Verwendung des Timers sind in Abschnitt beschrieben. Am Ende der Endlosschleife des Testbed-Server-Programms werden ausstehende Nachrichten verschickt, sofern der jeweilige Socket beschreibbar ist. Details dazu und zur für das Senden und Empfangen von Nachrichten und Dateien verwendeten Komponente TCP Transceiver sind in Abschnitt beschrieben. 48

58 4 Implementierung der Testbed-Software Abbildung 4.1.: Ablauf des Testbed-Server-Programms Knotenserver Das Knotenserver-Programm entspricht vom Ablauf her grundsätzlich dem Testbed-Server- Programm. Auch hier wird pselect() verwendet um auf Nachrichten vom Testbed-Server und Timer-Ereignisse zu warten. Die Knotenserver sind zuständig für die Ausführung der Jobs und empfangen die von den Sensorknoten gesendeten Daten. Dafür wird eine serielle Verbindung zu jedem Sensorknoten aufgebaut. Mit dem Aufruf von pselect() im Knotenserver-Programm wird auch auf den Empfang von Nachrichten über eine solche serielle Verbindung gewartet Timer Verschiedene Komponenten des Testbed-Server- und des Knotenserver-Programms benötigen eine Timer-Funktionalität, z. B. der Job Runner für die Abarbeitung des Ablaufplans der Jobkonfigurationsdatei (Ein- und Ausschalten von Sensorknoten). Diese Funktionalität könnte unter Verwendung der Timeout-Funktion von pselect() realisiert werden. Beim Aufruf von pselect() kann ein Timeout-Parameter übergeben werden, der festlegt, wann 49

59 4 Implementierung der Testbed-Software die Methode spätestens verlassen wird, auch wenn kein Ereignis (z. B. Empfang einer Nachricht) eingetreten ist. Wenn mehrere Komponenten die Timer-Funktionalität benötigen, müssten allerdings das Testbed-Server- und das Knotenserver-Hauptprogramm, in denen der Aufruf von pselect() erfolgt, eine Liste von Timeouts und eine Liste der Methoden, die bei Ablauf der Timeouts aufgerufen werden soll, verwalten. Um die Komplexität der Hauptprogramme gering zu halten und die Übersichtlichkeit zu verbessern, wurde stattdessen gemäß dem objektorientierten Programmierparadigma die Timer-Funktionalität in einer eigenen Timer-Klasse implementiert. Jede Klasse (Komponente) kann durch Anlegen eines Objekts der Timer-Klasse die Timer-Funktionen benutzen. Zusätzlich müssen diese Klassen von der Schnittstellen-Klasse Timer_Handler 16 erben (siehe Abbildung 4.2) und die Handler-Methode timer_fired() implementieren. Diese Methode wird von der Timer-Klasse aufgerufen, wenn ein Timer abgelaufen ist. Dazu verwaltet diese in einer statischen (von allen Instanzen gemeinsam genutzten) Liste Zeiger auf Timer_Handler- Objekte und damit auf die Objekte, die einen Timer verwenden. Abbildung 4.2.: Verwendung der Klasse Timer in anderen Klassen Der Ablauf vom Starten eines Timers bis zum Aufruf der Funktion timer_fired() ist in Abbildung 4.3 dargestellt und wird im Folgenden beschrieben. 1. Aufruf der Timer-Methode start_timer() (in diesem Beispiel durch den Job Runner); Als Parameter kann entweder die Zeit bis zum Ablaufen des Timers oder der Zeitpunkt angegeben werden. 2. Das Timer-Objekt ruft daraufhin die POSIX-Methode timer_settime() auf und startet damit den Timer. 16 Handler behandeln Ereignisse, d. h. sie werden beim Auftreten von Ereignisse aufgerufen und führen entsprechende Aktionen aus. 50

60 4 Implementierung der Testbed-Software 3. Nach Ablauf des Timers sendet der Kernel das Signal SIGALRM an den Testbed- Server-Prozess. Daraufhin wird die Methode SIGALRM_handler() aufgerufen, welche bei Erzeugung des ersten Timer-Objekts für dieses Signal registriert wurde. Die Methode vermerkt in der Variable fired, welcher Timer abgelaufen ist. 4. Der Empfang von SIGALRM führt außerdem zum Verlassen von pselect() im Testbed- Server-Hauptprogramm. 5. Daraufhin wird die Methode Timer::check_timer_fired() aufgerufen. 6. check_timer_fired() prüft zunächst, ob ein Timer abgelaufen ist, da pselect() z. B. auch beim Empfang einer Nachricht über einen Socket verlassen wird. Anschließend wird anhand der Variable fired ermittelt, welcher Timer abgelaufen ist und die timer_fired()-methode des entsprechenden Objekts (in diesem Beispiel Job Runner) aufgerufen. Abbildung 4.3.: Ablauf vom Starten eines Timers bis zum Aufruf der Handler-Methode TCP Transceiver Zwischen den Testbed-Komponenten müssen verschiedene Dateien ausgetauscht werden, u. a. Jobkonfigurationsdateien, Programme und Log-Dateien. Um den Versand und Empfang von Dateien komfortabler zu gestalten, wurde die Komponente TCP Transceiver implementiert, mit der sich aber auch einfache Nachrichten austauschen lassen. Zum Senden und Empfangen werden die in den Hauptprogrammen erzeugten TCP-Sockets verwendet. Die Arbeitsweise des Transceivers beim Versand von Nachrichten und Dateien ist in Abbildung 4.4 dargestellt und wird im Folgenden beschrieben. 51