Middleware für Wireless Sensor Networks

Maximilian Franzke
Sommersemester 2009

Seminar: Trends in Mobilen Systemen
Lehrstuhl für Mobile und Verteilte Systeme
Institut für Informatik
Ludwig-Maximilians-Universität München

Abstract: Die Arbeit beschäftigt sich mit Sensornetzen (Wireless Sensor Networks) und insbesondere der Middleware dafür. Zunächst wird auf den Sinn und Zweck einer Middleware-Lösung eingegangen und warum diese für den die Entwicklung und den Betrieb eines Sensornetzes notwendig ist. Eine Middleware erleichtert die Kommunikation zwischen Endbenutzeranwendungen und dem Netz. Anschließend wird detailliert auf die Anforderungen eingegangen, die an die Middleware gestellt werden, sowohl von Seiten des Netzes als auch von Seiten der Anwendung. Da diese Anforderungen teils widersprüchlich sind, muss die Middleware also einen geeigneten Kompromiss schaffen, wobei es auch hier je nach Einsatzzweck verschiedene Ansatzpunkte gibt, die im Einzelnen besprochen werden.

1 Einleitung

Immer öfter werden für komplizierte Anwendungen Sensornetze (Wireless Sensor Networks) eingesetzt. Dabei finden sich die Wurzeln dieses Konzepts bereits im Kalten Krieg, wo akustische Sensoren die Meere auf der Suche nach feindlichen U-Booten überwachten. Später setzte man vermehrt Distributed Sensor Networks ein, die allerdings noch über Kabel verbunden waren. Immer mehr ging man dann dazu über, die Knoten der Netze möglichst einfach zu halten; deshalb entstanden heterogene Knoten, die nur noch jeweils eine einzige Mess-Aufgabe hatten, aber im Verbund eines Netzes zu einem mächtigen Werkzeug (in dieser Zeit vor allem für das Militär) wurden. Mit dem technologischen Fortschritt konnte man schließlich auch noch die Kabelgebundenheit lösen, indem Funktechnologien für die Kommunikation der Knoten eingesetzt wurden. Hier kann nun von echten Wireless Sensor Networks, oder Sensornetzen, gesprochen werden. [SMZ07]

Die Technologie für Sensoren und eingebettete Systeme hat sich genau wie die der Hardware permanent weiterentwickelt, während gleichzeitig Bedarf für Anwendungen besteht, welche die Daten von Sensornetzen auswerten. Diese Anwendungen können dann auch auf Informationen über schlecht zugängliche Stellen und Gebiete zugreifen und so immer detailliertere und exaktere Aufgaben erfüllen. [dFP08]

Die Idee einer intelligenten Umgebung wird die nächste evolutionäre Entwicklung sein, in der Informationen über die Umgebung gemessen und verarbeitet werden. Dabei geht es um Erkennung von Objekten, Überwachung und Alarmierung. Eingesetzt werden für diese Aufgaben Sensornetze (Wireless Sensor Networks), ein Forschungsgebiet, das enorm interdisziplinär ist, weil es sich neben Themen der Informationsverarbeitung auch mit den physikalischen Herausforderungen der Hardware und spezifischen Anwendungsfällen aus der Praxis auseinandersetzen muss. [Lew04]

1.1 Anwendungsgebiete

[Röm03] nennt als Haupteinsatzweck eines Sensornetzes, als so bezeichnete »Killer app«, die Überwachung von Objekten oder Lebewesen, wobei er dies differenziert in Verhaltens- und Umweltbeobachtung, sicherheitstechnische Überwachung und das so genannte »Smart Battlefield«, wobei es sich hier um die Überwachung von feindlichen Aktivitäten handelt. Als Kernaufgaben des Netzes werden Ereigniserkennung, Objekterkennung und Objektverfolgung aufgeführt.

Häufige Aufgaben bei der Verhaltens- und Umweltbeobachtung sind etwa die Überwachung von Tierpopulationen oder auch die Kontrolle von schwer zugänglichen, aber gefährdeten Gebieten - etwa, wenn man die Waldbrandgefahr verringern möchte. Die sicherheitstechnische Überwachung zielt dagegen vielmehr darauf ab, ein Gebiet oder einen Komplex weiträumig gegen Eindringlinge zu sichern und Sensornetze bieten hier einen einfachen Weg, um großflächige Areale abzusichern. Genauso können aber auch Industrieprozesse oder Maschinen auf Fehlfunktionen überwacht werden. Das Smart Battlefield ähnelt sehr der Absicherung gegen Eindringlinge, hat aber einen starken militärischen Hintergrund. Wenn Feindaktivitäten effizient und schnell erkannt und ausgewertet werden können, haben die eigenen Truppen einen besseren Eindruck der Gefechtslage.

1.2 Konkretes Anwendungsbeispiel

Diese eher generischen Einsatzzwecke sollen anhand eines ganz konkreten Beispiels nach [TA05] verdeutlicht werden: Bei der Ben Franklin Brücke in New Jersey (U.S.A.) soll die Belastung der Brücke im laufenden Eisenbahn-Betrieb gemessen werden. Dazu wurde ein Sensornetz, bestehend aus zehn einzelnen Sensoren, die mittels Funk bis zu 100 Meter überbrücken können, an der Brücke installiert. Diese einzelnen Sensorknoten befinden sich die meiste Zeit in einem Ruhezustand; nur dann, wenn ein sich nähernder Zug von einem der Knoten erkannt wird, werden alle Knoten auf volle Leistung gefahren, damit sie ihre Messung durchführen können. Die Messdaten werden dann auf einem internen Speicher gesichert und von Zeit zu Zeit ausgelesen.

2 Middleware

Nachdem bereits beim Anwendungsbeispiel einige Komponenten angesprochen wurden, soll nun noch detaillierter auf den Aufbau eines Sensornetzes und insbesondere die Middleware eingegangen werden. Aufgabe und Zweck der Middlware lassen sich nach [SMZ07] folgendermaßen definieren: »Die Middleware befindet sich normalerweise unterhalb der Anwendungsschicht und setzt auf dem Betriebssystem und den Netzwerkprotokollen auf. Sie stellt die Anforderungen der Anwendung auf, blendet Details der darunter liegenden Schichten aus und erleichtert die Anwendungsentwicklung und -auslieferung sowie ihre Verwaltung.«

2.1 Hardwareebene

Unterhalb der Middlware befindet sich das eigentliche Sensornetz, also die eigentliche Hardware. Nach [SMZ07] besteht dieses im Wesentlichen aus vier verschiedenen Komponenten:

2.2 Vermittlungsfunktion der Middleware

Aktuell ist es noch so, dass bei derzeitigen Entwicklungen von Sensornetzen die Anwendungen meistens direkt auf der Hardware ausgeführt werden, ohne dass ein komplexeres Verwaltungssystem wie etwa eine Middleware eingesetzt wird. Dies erschwert allerdings die effiziente Entwicklung und Wartung von Software. [RKM02]

Unter dem Aspekt der modularen Softwareentwicklung erscheint es sinnvoll, das eigentliche Sensornetz von der Anwendung zu trennen. Dadurch wird zugleich eine Portabilität einzelner Programmteile erreicht. Zudem ist es sehr ineffizient, wenn in jeder Anwendung Aspekte bis hinunter zur Hardware-Ebene entwickelt werden müssen.

Wenn also das Netz von der Anwendung abgetrennt wird, muss dennoch eine einheitliche Schnittstelle auf beiden Seiten eingerichtet werden, um das Zusammenspiel zu ermöglichen. Die im Folgenden erläuterten Anforderungen beider Seiten erschweren jedoch auch wieder eine direkte Schnittstelle zwischen Anwendung und Sensornetz, da sie zu verschieden sind. Deshalb muss zwischen beide Komponenten eine Dritte eingefügt werden, die die Kommunikation zwischen beiden Seiten vermittelt und Anfragen der einen Schnittstelle in adäquate Kommandos für die andere übersetzt, die so genannte Middleware.

Abbildung 1: Die Middleware vereinfacht die Kommunikation zwischen Sensornetz und Anwendung Abbildung 1: Die Middleware vereinfacht die Kommunikation zwischen Sensornetz und Anwendung

Die Middleware sieht sich in ihrer Vermittlerfunktion primär mit drei Aufgaben konfrontiert:

3 Anforderungen an die Middleware in Sensornetzen

Die Middleware bezeichnet die Schnittstelle zwischen dem eigentlichen Sensornetz und der Anwendung. Sie ist also eine dazwischenliegende Schicht, die die Aufgabe hat, die Kommunikation zwischen beiden Seiten zu vereinfachen, vergleiche Abbildung 1. Dies wird erreicht, indem jeder Seite eine fest definierte Funktionsschnittstelle zur Verfügung gestellt wird und gleichzeitig die jeweils andere Seite ausgeblendet und in diese Schnittstellen abstrahiert wird. Analog zum Schichtenmodell der Netzwerktheorie ist die Middleware diejenige Schicht, die über der des Sensornetzes und unterhalb der Anwendung liegt und nach oben und unten Service Access Points bereitstellt.

Für Forschung betreffend der Routing- und Kommunikationsprotokolle für Sensornetze wurde bereits viel Aufwand betrieben. Im Gegensatz dazu besteht noch viel Forschungsbedürfnis auf dem Gebiet der so genannten Middleware, in der noch viel Potential steckt, um den Betrieb eines Sensornetzes weiter zu optimieren und den Zugriff darauf für Anwendungen zu vereinfachen. [YKP04]

3.1 Anforderungen seitens Hardware

Aufgrund ihrer physikalischen Beschaffenheit und ihres Einsatzzweckes unterliegen die Knoten eines Sensornetzes gewissen Restriktionen. Durch ihre explizite Konstruktion für einen unabhängigen und selbstständigen Betrieb ergeben sich besondere Eigenschaften und Einschränkungen, die beim Entwickeln einer Middleware beachtet werden müssen. Im Folgenden wird nun auf die charakteristischsten Besonderheiten eines Sensornetzes und ihre Auswirkungen auf das Design der Middleware eingegangen.

3.1.1 Energieeffizienz

Je nach spezifischem Anwendungsfall beträgt die Lebensspanne, in der das Netz funktionieren muss, einige Stunden bis hin zu mehreren Jahren [YB05]. Dementsprechend muss auch die Energieversorgung der einzelnen Knoten innerhalb dieser Zeitspanne sichergestellt werden. Daher versucht man, die Lebenszeit eines Knotens durch Energiegewinnung, Energiespeicherung und Energieverwaltung zu verlängern [Lew04].

Betreffend die Energiegewinnung lässt sich das Beispiel der RFID-Geräte anführen - also passive Transponder, die per Induktion mit Energie versorgt werden [Kel04]. Diese können Energie von eingehenden Funkverbindungen speichern und im Anschluss kann das Gerät mithilfe dieser eigene Operationen ausführen, etwa das Senden einer Nachricht [Lew04]. Das einfache Auswechseln von eventuell vorhandenen Batterien erweist sich leider als nicht praktikabel, da die Kosten eines Wechsels pro Knoten je nach dessen Zugänglichkeit zwischen 10 und 100 US-Dollar betragen [Ost09]. Setzt man dies in Relation zum Anschaffungspreis, der sich im Preisrahmen von ca. 100 Euro bewegt [EP07], wird klar, dass das ständige Austauschen von Batterien unrentabel ist.
Die Faktoren Energiegewinnung und -speicherung betreffen mehr die Hardware-, als die Softwareseite. Viel mehr ist der Punkt Energieverwaltung aus Sicht der Middleware - also einem softwaretechnischen Aspekt - interessant: Wenn diese den Aspekt der Energieeffizient beachtet, sorgt sie dafür, dass »die meisten Komponenten des Geräts wahrscheinlich die meiste Zeit ausgeschaltet werden« [HM06]. Dadurch, dass diese Komponenten heruntergefahren werden, kann wie bei einem Fernsehgerät im Stand-by-Modus die Leistungsaufnahme im Ruhezustand verringert werden.

Natürlich hat die Abschaltung der Sendeeinheiten einzelner Knoten Auswirkungen auf die Konnektivität des gesamten Netzes: Diese beeinflusst nämlich wiederum den Entwurf der Kommunikationsprotokolle und die Algorithmen für die Datenweitergabe. [YB05]

Zusammenfassend kann man sagen, dass die zur Verfügung stehende Energie ein großer limitierender Faktor bei Sensornetzen ist. Allgemein kann man sagen, dass »energiehungrige« Prozesse meistens abgeschaltet oder unterbunden sind. Und selbst wenn diese »aktiv sind, werden energieintensive Aktivitäten wie Motorennutzung und das Senden / Empfangen von Funknachrichten auf ein Minimum beschränkt« [OMRT05].

3.1.2 Speicher und Prozessor

Typischerweise hat jeder Knoten des Sensornetzes »einen Mikroprozessor und eine kleine Menge an Speicher für die Signalverarbeitung und Arbeitsverwaltung« [ZG04]. Demzufolge hat jeder Knoten »die Fähigkeit zur rechenbetonten Verarbeitung« [YB05]. Es handelt sich also um einen kleinen Computer, der prinzipiell ganz »normale« Rechenoperationen ausführen kann.

Allerdings besitzt ein einzelner Knoten in der Praxis keinen großen Funktionsumfang. Vielmehr ist er auf einzelne Aufgaben und Anwendungsszenarien spezialisiert worden. Wenn also komplexere und aufwändigere Aufgaben durchgeführt werden, ist es notwendig die Aufgabe auf mehrere Knoten zu verteilen. Anspruchsvoll ist dabei die Koordinierung dieser Verteilung. [RKM02]

Aufgabe der Middleware ist es, die Rechen- und Speicherleistungen der einzelnen Knoten zu beachten und effizient zu verwalten. Ferner muss diese auch die erwähnte Koordination der Knoten beim Lösen komplexer Aufgaben übernehmen.

3.1.3 Netztopologie

Bei der Einrichtung des Netzes, also der Konfiguration der Verbindungen der Knoten untereinander, gibt es zwei etablierte Verfahren. Beim infrastrukturbasierten Verfahren können die Knoten nur mit Basisstationen kommunizieren, wobei deren Anzahl von der Reichweite der Funksignale abhängt. Dagegen können bei Ad-Hoc-Netzwerken die Knoten auch direkt miteinander kommunizieren und in Verbindung treten. Jeder Knoten wird somit neben einem Sender und Empfänger gleichzeitig zu einem Router, der Nachrichten auch einfach nur weiterleiten kann. Wichtig hierbei ist, dass das Netz in der Lage ist, sich selbst zu konfigurieren und Schwachstellen (etwa ausgefallene Knoten) zu erkennen und zu beheben. [YB05]

Sensornetze können auch heterogen aufgebaut sein. Dann benutzen nicht alle Knoten eines Netzes dasselbe Kommunikationsverfahren, sondern sie »basieren auf einem unterschiedlichen Kommunikationsverfahren« [GPP08]. In der Realität kann es also vorkommen, dass eine Nachricht, die über mehrere Knoten übertragen werden soll, etappenweise auf verschiedene Arten übermittelt wird. Abbildung 2 nach [GPP08] stilisiert diese Übertragung:

Abbildung 2: Weg einer Nachricht durch ein heterogenes Netz Abbildung 2: Weg einer Nachricht durch ein heterogenes Netz
3.1.4 Selbstkonfiguration

Im Rahmen der Netztopologie wurde bereits erwähnt, dass eine Selbstkonfiguration des Netzes von elementarer Bedeutung ist. Diese geht jedoch noch über die besprochene Selbstvernetzung hinaus und betrachtet das Netz als Ganzes. Aus dieser Sicht lassen sich etwa Redundanzen, also mehrfach vorhandene Verbindungen erkennen. Diese kann dann genutzt werden, »um die Gesamtlebensdauer des Systems zu verlängern« [YB05]. Hier wäre etwa denkbar, dass Redundanzen beseitigt werden, um so diejenigen Knoten, deren Kapazitäten nicht mehr benötigt werden, in Stand-by zu versetzen oder auch die gegenteilige volle Ausnutzung der Redundanzen, sodass die Last auf die einzelnen Knoten verteilt wird und etwa die Sendeleistung der Knoten gedrosselt werden kann. Allerdings muss das oberste Ziel, nämlich ein einwandfreies Funktionieren und Zweckerfüllen kontinuierlich beachtet werden, weshalb das Netz sich fortwährend und periodisch neu konfigurieren muss [YB05].

3.1.5 Datenakkumulation

Da jeder Knoten in einem Sensornetz in der Lage ist, Messdaten im Umfang seiner sensorischen Reichweite zu generieren, bestehen bezüglich der Datenakkumulation des gesamten Netzes zwei Problemstellungen: Einerseits kann kein Knoten allein alle Messdaten liefern, es ist also eine Kombination der Daten vieler Knoten notwendig. Andererseits können mehrere Knoten, die ihre Daten weitersenden, »das Netzwerk leicht verstopfen, [indem] sie es mit Informationen überfluten« [YB05]. Es ist also notwendig, den Datenverkehr bereits innerhalb des Netzes zu vereinfachen und zusammenzufassen, um die tatsächlich übertragene Datenmenge gering zu halten.
[KL03] stellt etwa einen Ansatz vor, wie Daten aus einem Netz mit Baumtopologie effizient aggregiert werden können; siehe Abbildung 3: Der Datentransfer findet von den Blättern zur Wurzel des Baumes hin statt. Jedes Element teilt seinem »Vater« einen Wert mit und wie viele andere Knoten zu diesem Wert beigetragen haben. Zusätzlich werden noch Informationen über den überwachten Bereich übermittelt. »Typischerweise ist die Aggregationsfunktion sehr einfach, etwa Minimum, Maximum oder Durchschnitt« [KL03], wobei auch komplexere Funktionen bei steigendem Rechenaufwand möglich sind. Folgende Grafik zeigt exemplarisch die Datenaggregation für die Funktion »Durchschnittstemperatur im Netz« auf:

Abbildung 3: Datenaggregation am Beispiel »Durchschnittstemperatur im Netz« Abbildung 3: Datenaggregation am Beispiel »Durchschnittstemperatur im Netz«

Dieser Prozess soll freilich innerhalb des Netzes ablaufen und muss (beziehungsweise soll) nicht für den Benutzer einer Anwendung sichtbar sein. Dementsprechend wird es Aufgabe der Middleware sein, diesen Aspekt zu beachten und zu integrieren.

3.1.6 Sicherheit

Generell gibt es verschiedene Bedrohungsszenarien für Sensornetze, die deren Funktionalität beeinflussen können. Avancha et. al. [AUJP04] führen folgende Szenarien auf:

Aufgabe der Middleware ist es, diese Bedrohungen abzuwehren. Dazu muss sie einerseits in der Lage sein, Angriffe und Bedrohungen überhaupt zu erkennen. Weiterhin muss sie auf Angriffe oder Ausfälle richtig reagieren, um die Funktion des Netzes dennoch sicherzustellen. Schlussendlich ist es auch nötig, die Verwaltung einer etwaigen Verschlüsselung des Datenverkehrs zu übernehmen - wie etwa die Schlüsselverteilung und Kontrolle der Sicherheitsmechanismen.

3.1.7 Zusammenfassung

Die genannten Problempunkte lassen sich hinsichtlich ihrer Auswirkungen auf den Betrieb in die Aufgabe der Middleware, nämlich Konnektivität, Auswertung komplexer Anfragen und Verwaltung des Netzes, einteilen:

Problempunkt Beschreibung Hat Auswirkung auf
Energieeffizienz Knoten sollen so wenige Operationen wie möglich ausführen. Konnektivität
Speicher und Prozessor Es stehen nur begrenzte Ressourcen zur Verfügung. Auswertung komplexer Anfragen
Netztopologie Die Topologie kann sich permanent ändern. Verwaltung des Netzes
Selbstkonfiguration Das Netz muss sich selbst neu strukturieren können. Verwaltung des Netzes
Datenakkumulation Daten müssen sinnvoll gegliedert werden, um eine Informationsflut zu vermeiden. Auswertung komplexer Anfragen sowie Konnektivität
Sicherheit Das Netz soll vor ungewünschten Eingriffen und Angriffen geschützt werden. Verwaltung des Netzes

3.2 Anforderungen seitens Anwendung

Nachdem nun im vorhergehenden Kapitel die Bedürfnisse geklärt wurden, die die Hardware an die Middleware stellt, wird nun die andere Schnittstellenseite der Middleware genauer untersucht. Diese orientiert sich an der eigentlichen Anwendung, welche die aus dem Sensornetz gewonnen Daten weiter verarbeiten wird. Da Anwendungen in der Praxis auf einer höheren Schicht als der Hardware-Ebene entwickelt werden, muss eine Schnittstelle zur Middleware geschaffen werden, die auf die Anforderungen der Anwendung ausgerichtet ist. Diese Anforderungen sollen nun genauer untersucht werden.

3.2.1 Unkenntnis über Netzwerk

In Abschnitt 3.1.1 wurde bereits darüber gesprochen, dass Sensorknoten ausfallen können, fehlerhaft sind oder sich im Stand-by-Modus befinden. Es wäre sehr ungünstig, wenn der Entwickler einer Applikation all diese Sonderfälle beachten müsste. Vielmehr ist dieser daran interessiert, das Netzwerk als ganzes ansprechen zu können, »ohne Wissen über das Sensornetz zu haben« [YB05] - also eine transparente Sicht auf das Netz.

Die Middleware muss also das tatsächliche Sensornetz abstrahieren. Dies wird erreicht, indem die unteren Schichten (beispielsweise die Hardware-Ebene) ausgeblendet werden und dem Anwendungsentwickler eine homogene und konstante Sicht auf das Sensornetz geboten wird. Dadurch wird es auch möglich, das Sensornetz (also die Hardware) oder auch die Middleware selbst auszutauschen, solange die Anwendungsschnittstelle unverändert bleibt. [dFP08]

Von Anwendungsseite aus wird also eine API (Application Programming Interface) gewünscht, mittels derer dann über definierte Befehle auf das Sensornetz zugegriffen werden kann. Aufgabe der Middleware ist es nun, die Befehle der API unter Berücksichtigung der erläuterten Anforderungen des Netzes zu übersetzen und in Befehlsstrukturen umzuwandeln, die die Sensorknoten verstehen.

3.2.2 Datenzugriff

Wenn eine Anwendung auf ein Sensornetz zugreift, so werden meist Daten nach einem bestimmten Schema abgefragt. Untypisch ist etwa, dass einzelne Knoten nach ihren Messdaten gefragt werden (sofern dies durch die Verschleierung des Aufbaus des Netzes überhaupt möglich ist). Viel eher sind diese Anfragen datenfokussierter Art. Dies bedeutet, dass das Interesse auf den Daten selbst und nicht dem Ort ihrer Erzeugung liegt. Ein Beispiel für so eine Datenabfrage wäre: »Wo im Netz übersteigt die Luftfeuchtigkeit 95%?« Es wird also die Verbindung zwischen dem einzelnen Sensorknoten und den generierten Daten gelockert. [EGHK99]

An bereits bestehenden Anwendungen beziehungsweise Middleware-Lösungen sieht man, dass Anfragen an das Netz des häufigeren in einer SQL (Structured Query Language) sehr ähnlichen Form gestellt werden. Yoneki & Bacon [YB05] stellen einige Beispielbefehle existierender Middleware-Lösungen vor:

3.2.3 Zusammenfassung

Auch die Anforderungen der Anwendungsseite lassen sich wieder anhand ihrer für die Middleware relevanten Problemfelder zusammenstellen:

Problempunkt Beschreibung Hat Auswirkung auf
Unkenntnis über das Netzwerk Die Anwendung kennt das Netz nicht und spricht daher das gesamte Netz an. Verwaltung des Netzes
Datenzugriff Daten werden unabhängig von ihrem Erzeugerknoten angefordert. Auswertung komplexer Anfragen

3.3 Ansätze zum Informationsaustausch

Es existieren verschiedene Ansätze, wie mit den vorgestellten Problemen und Anforderungen umgegangen werden soll. Die wichtigsten und prägnantesten werden nun im Folgenden vorgestellt.

3.3.1 Datenfokussiert

Beim datenfokussierten Ansatz stehen die vom Sensornetz generierten Daten im Vordergrund. Die Knoten sammeln und speichern Daten, um sie später der Anwendung in Echtzeit zur Verfügung zu stellen. Das Sensornetz wird hier als große Datenbank abstrahiert, an die Anfragen gestellt werden können. Diese Anfragen werden dann herunter gebrochen und an die Knoten verteilt. Allerdings zeigt dieser Ansatz seine Grenzen darin, dass es sehr aufwändig wird, komplexe Anfragen in elementare Knotenbefehle umzuwandeln. [YB05]

Folgende Tabelle bewertet den datenfokussierten Ansatz anhand der zuvor ermittelten Aufgaben der Middleware:

Punkt Bewertung
Konnektivität Request-Prinzip: Anwendung kann unnötig viel Datenverkehr verursachen.
Verwaltung des Netzes Komplex, da alle Knoten und Daten zur Datenbankstruktur abstrahiert werden.
Auswertung komplexer Anfragen Möglich, aber aufwändig, da Umwandlung in atomare Befehle nötig.
3.3.2 Ereignisfokussiert

Der ereignisfokussierte Ansatz fokussiert sich auf besonders relevante oder charakteristische Messdaten: Die Knoten erhalten die Rolle eines Senders, dessen Nachrichten dann von einem oder mehreren Empfängern abonniert werden können. Wird dann das abonnierte Ereignis ausgelöst, können sich die Empfänger darauf verlassen, darüber automatisch informiert zu werden. [YB05]

Folgende Tabelle bewertet den ereignisfokussierten Ansatz anhand der zuvor ermittelten Aufgaben der Middleware:

Punkt Bewertung
Konnektivität Gerade bei Überwachungsaufgaben wird effizient nur bei Ereigniseintritten kommuniziert.
Verwaltung des Netzes Geringer - Knoten müssen nicht aufwändig abstrahiert werden.
Auswertung komplexer Anfragen Schwer möglich, da abstrahierte Anordnung der Knoten fehlt.
3.3.3 Qualitätsfokussiert

Der qualitätsfokussierte Ansatz kann gewählt werden, wenn die vom Sensornetz ermittelten Daten möglichst zuverlässig beziehungsweise genau sein sollen. Dazu werden die angeforderten Daten als Variablen betrachtet. Dann wird die von der Anwendung übermittelte Toleranzgrenze der Messgenauigkeit mit der möglichen Genauigkeit der Daten verglichen, die die Sensoren bereitstellen können. Somit werden insgesamt weniger Daten an die Anwendung übermittelt, dafür sind diese umso zuverlässiger. [YB05]

Folgende Tabelle bewertet den qualitätsfokussierten Ansatz anhand der zuvor ermittelten Aufgaben der Middleware:

Punkt Bewertung
Konnektivität Mittel bis hoch, da unter Umständen sehr viele Knoten befragt werden müssen, um verlässlichle Messwerte zu generieren
Verwaltung des Netzes Geriner, da die Knoten nicht in eine Struktur gebracht werden müssen.
Auswertung komplexer Anfragen Aufwändig, da stets die Verlässlichkeit der Daten geprüft werden muss.
3.3.4 Internetorientiert

Bei diesem Ansatz wird versucht, das Sensornetz nicht für eine spezielle Anwendung zu isolieren. Vielmehr sollen die Daten des Netzes über das Internet verschiedenen Endanwendungen zur Verfügung gestellt werden. Dadurch kann einerseits ein mächtiger Zugangsknoten im Netz (beziehungsweise der Middleware) notwendig werden, der die Verbindung nach außen, sprich dem Internet, herstellt und verwaltet; dieser ist dann auch für Anfragen an das Netz verantwortlich. Ferner können auch Daten verschiedener Sensornetze getrennt abgerufen werden, um sie später zu kombinieren und zentral zu verwalten. Diese Daten können dann auch automatisch an interessierte Abonnenten verteilt werden. [YB05]

Punkt Bewertung
Konnektivität Abhängig von der Menge der Anfragen von außerhalb, die Zwischenspeicherung von Daten außerhalb des Netzes auf Servern kann die Belastung für das Netz senken.
Verwaltung des Netzes Aufwändig, da das Netz als Datenbank gesehen wird.
Auswertung komplexer Anfragen Sehr aufwändig, insbesondere, wenn für die Anfrage Daten aus mehreren Sensornetzen herangezogen werden müssen.
3.3.5 Weitere Ansätze

Zu erwähnen ist noch der vermittlungsbasierte Ansatz, bei dem die Infrastruktur in die Schichten der Sensoren, der Sensorplattform, des Systems und der Anwendung eingeteilt wird. Diese Schichten stellen dann dienstorientierte Funktionen zur Verfügung. Während bei den bisherigen Ansätzen meist versucht wurde, das Sensornetz als möglichst weit verteilt und unabhängig zu organisieren, versucht der zentralisierte Ansatz wieder, die generierten Daten gebündelt an einer Stelle zu sammeln, was beispielsweise bei Anwendungsszenarien, bei denen Objekte verfolgt werden sollen, hilfreich sein kann. [YB05]

3.4 Bewertung

Die beim datenfokussierten Ansatz vorhandene Möglichkeit der Kommunikation zwischen Anwendung und Sensornetz ist sehr einseitig: Die Anwendung allein schickt Anfragen und das Sensornetz antwortet. Bleiben diese Anfragen aus, sieht sich das Sensornetz nicht in der Pflicht, Daten herauszuschicken. Dies kann allerdings besonders bei Überwachungsfunktionen kritisch sein: Die Anwendung müsste hier permanent (und daher meistens unnötig oft) das Netz befragen, ob sich Änderungen ergeben haben. Dem gegenüber steht der ereignisfokussierte Ansatz, der sich besonders für sicherheitstechnische Überwachungszwecke eignet. Dieser kann bei dererlei Einsatzgelegenheiten helfen, unnötige Kommunikation und die damit einhergehenden Ressourcenprobleme zu vermeiden - besonders, wenn man annimmt, dass kritische Ereignisse nur selten eintreten. Anwendungsgebiete für den datenfokussierten Ansatz liegen dagegen mehr im Bereich der Verhaltens- und Umweltbeobachtung, wo zum Beispiel nur in regelmäßigen Intervallen Anfragen generiert werden, um einen langzeitlichen Verlauf von Messwerten zu verfolgen. Qualitätsfokussierte Ansätze finden oft Anwendung bei medizinischen Aufgaben, da hier weniger der Kostenfaktor eine Rolle spielt, dafür die Messungen umso genauer sein müssen, da auf diesen folgenschwere Behandlungsentscheidungen basieren. Der Internetorientierte Ansatz eignet sich insbesondere dann, wenn man sich von einem isolierten Anwendungsfall lösen möchte, um weit vernetzte Anwendungen zu schaffen.

Da die Middleware stets einen Kompromiss zwischen den Anforderungen des Sensornetzes und denen der Anwendung schaffen muss, ist es schwer, einen Lösungsansatz pauschal zur Ideallösung zu deklarieren. Vielmehr hat die Bewertung der einzelnen Ansätze gezeigt, dass es vom Anwendungszweck abhängig ist, welche Lösung sich am besten eignet. Es gibt also keinen Ansatz, der stets für jeden Anwendungszweck garantieren kann, beste Ergebnisse zu erzielen.

Allerdings könnte man sich eine universelle Middleware-Distribution vorstellen, die für jeden Lösungsansatz eine eigene Komponente mitbringt. Bei der Konfiguration des Sensornetzes würde dann der Anwendungszweck ermittelt und die passende Komponente installiert werden. Ähnlich wird beispielsweise bei den Distributionen von Betriebssystemen verfahren, wo je nach Einsatzzweck des Computers Komponenten hinzugefügt oder entfernt werden können.

3.5 Existierende Middleware-Lösungen

Um einen kleinen, natürlich nicht vollständigen Überblick über bestehende Lösungen zu bekommen, stellt folgende Tabelle nach [HM06] und [YB05] einige Projekte vor und teilt diese zugleich nach verwendetem Lösungsansatz sowie dem exemplarischen Einsatzgebiet ein:

Projekt Beschreibung Verwendeter Lösungsansatz Anwendungsszenarien
Cougar Verwaltet große Mengen an Sensoren Datenfokussiert Überwachung und Beobachtung
DsWare Obwohl ereignisfokussiert, verwendet Data Service Middleware einen Cache-Mechanismus, um eine datenbankähnliche Schnittstelle zu liefern. Ereignisfokussiert Überwachung
EnviroTrack Objektorientierter Ansatz, der sich besonders gut für die Verfolgung von Objekten eignet Ereignisfokussiert Umweltüberwachung
Impala Wechselt zwischen Protokollen, um Mobilität, Skalierbarkeit und Erweiterbarkeit zu ermöglichen Ereignisfokussiert Überwachen und Verfolgen von Objekten
MiLAN Abstrahiert das Netz auf hohem Level und bietet Funktionen für neue oder verschwindende Knoten Qualitätsfokussiert Medizinische Anwendungen
Mires Verwendet das asynchrone Nachrichtenmodell mit Sender-Abonennten-Prinzip Ereignisfokussiert Sicherheitstechnische Überwachung
TinyDB Einfach zu bedienen, da Entwicklungs-Tools bereitgestellt werden. Datenfokussiert Überwachung und Beobachtung

4 Schluss und Ausblick

Derzeit befinden sich die meisten Forschungsprojekte zu Sensornetzen noch in den Kinderschuhen. Primär wird viel an Algorithmen und den Komponenten geforscht, die erst später dann eine stabile Grundlage für die Middleware bieten sollen. Zwar existieren bereits zahlreiche Ideen und Ansätze, wie dieser Report gezeigt hat, aber die meisten Projekte wurden noch nicht in der Praxis, sondern nur im Laborbetrieb getestet. [RKM02]

Die meisten Projekte, die sich mit dem Thema Middleware beschäftigen, befinden sich noch in einem frühen Stadium. Das Hauptaugenmerk bei der Entwicklung liegt noch auf der Entwicklung von Algorithmen und Komponenten der Schicht der Middleware. Die Ansätze bestehender Lösungen müssen sich noch beweisen, ob sie den Anforderungen, die an sie gestellt werden, gerecht werden. [HM06]

Die große Zukunftsvision der Entwickler von Sensornetzen ist sicherlich der »Smart Dust«, also der intelligente Staub. Dort sind die Sensorknoten dann winzig klein und werden in Stückzahlen von Hunderttausenden ausgebracht. Sie können dann Kilometergroße Gebiete abdecken und lassen die Umwelt intelligent werden. [HKP98]

Das Interesse an Sensornetzen steigt kontinuierlich: Das Michigan Institue of Technology hat die Wireless Sensor Networks in die Liste derjenigen zehn Technologien aufgenommen, die die Welt verändern können. Ferner wird geschätzt, dass der kommerzielle Markt um Sensornetze im Jahr 2009 erstmals die Milliarden-Dollar-Marke knacken wird. [Sri07]

Literatur

[AUJP04]
Sasikanth Avancha, Jeffrey Undercoffer, Anupam Joshi und John Pinkston. Wireless sensor networks, Kapitel Security for wireless sensor networks, Seiten 253-275. Kluwer Academic Publishers, 2004.

[dFP08]
Pignaton de Freitas und Edison Pignaton. A Survey on Adaptable Middleware for Wireless Sensor Networks. Bericht, School of Information Science, Computer and Electrical Engineering, Halmstad University, 2008.

[EGHK99]
Deborah Estrin, Ramesh Govindan, John Heidemann und Satish Kumar. Next Century Challanges: Scalable Coordination in Sensor Networks. Bericht, USC/Information Sciences Institute, 1999.

[EP07]
Philipp Engel und Teja Philipp. Lokalisierung und Zustandserkennung in Sensornetzen basierend auf TinyOS. Diplomarbeit, Ludwig-Maximilians-Universität München, 2007.

[GPP08]
F. Graziosi, L. Pomante und D. Pacifico. A Middleware-Based Approach for Heterogeneous Wireless Sensor Networks. In Proceedings of the 12th WSEAS International Conference on Circuits, Seiten 52-57. World Scientific and Engineering Academy and Society, 2008.

[HKP98]
V.S. Hsu, J.M. Kahn und K.S.J. Pister. Wireless Communications for Smart Dust. Bericht, University of California, 1998.

[HM06]
Salem Hadim und Nader Mohamed. Middleware: Middleware Challenges and Approaches for Wireless Sensor Networks. IEEE Distributed Systems Online, 7(3):1, Mar 2006.

[Kel04]
H. Kelter. Radio Frequency Identification: Risiken und Chancen des Einsatzes von RFID-Systemen. Bericht, Bundesamt für Sicherheit in der Informationstechnik, 2004.

[KL03]
Holger Karl und Marc Löbbers. A Data Aggregation Framework for Wireless Sensor Networks. In Proceedings Dutch Technology Foundation ProRISC, Workshop on Circuits. Systems and Signal Processing, Nov 2003.

[Lew04]
F. L. Lewis. Smart Environments: Technologies, Protocols, and Applications, Kapitel Wireless Sensor Networks, Seiten 13-46. Wiley & Sons, 2004.

[OMRT05]
G. M. P. O'Hare, David Marsh, Antonio Ruzzelli und Richard Tynan. Agents for Wireless Sensor Network Power Management. Bericht, University College Dublin, May 2005.

[Ost09]
Harry Ostaffe. Wireless power energizes wireless sensor networks, Mar 2009.

[RKM02]
Kay Römer, Oliver Kasten und Friedemann Mattern. Middleware challenges for wireless sensor networks. ACM SIGMOBILE Mobile Computing and Communications Review, 6(4):59-61, Oct 2002.

[Röm03]
Kay Römer. Einführung in Sensornetze, 2003.

[SMZ07]
Kazem Sohraby, Daniel Minoli und Taieb Znati. Wireless Sensor Networks: Technology, Protocols, and Applications. Wiley & Sons, 2007.

[Sri07]
Sundhar Ram Srinivasan. Smart dust network that performs complex tasks. The Hindu, Aug 2007.

[TA05]
Chris Townsend und Steven Arms. Sensor Technology Handbook, Kapitel 22, Seiten 439-449. Jon S. Wilson, 2005.

[YB05]
Eiko Yoneki und Jean Bacon. A survey of Wireless Sensor Network technologies: research trends and middleware's role. Bericht, University of Cambridge, 2005.

[YKP04]
Yang Yu, Bhaskar Krishnamachari und Viktor K. Prasanna. Issues in Designing Middleware for Wireless Sensor Networks. Network, IEEE, 18(1):15-21, Jan/Feb 2004.

[ZG04]
Feng Zhao und Leonidas J. Guibas. Wireless sensor networks: an information processing approach. Morgan Kaufmann, 2004.