Das Rahmenwerk vereinfacht die Entwicklung und Integration von Sensoren. So werden alle Basisfunktionen ei-nes Sensors bereitgestellt und müssen nur um die sensorspezifischen Funktionen erweitert werden (siehe Ab-schnitt 4.3.1 und 4.3). Eine weitere Unterstützung bei der Integration von Sensoren bietet die Generierung der notwendigen Beschreibung (wie später in Abschnitt 6.2.2 erläutert wird).
Basis Schema
Viele der Funktionalitäten eines Sensors lassen sich generisch auf andere abbilden. Daher liegt es nahe eine ge-meinsame Basisschnittstelle anzubieten. Diese Basisschnittstelle hat folgende Aufgaben:
• Wiederverwendung gemeinsamer Funktionalitäten.
• Abstraktionsebene für Sensoren - Vereinfachung der Schnittstelle für Sensor-Entwickler.
• Kapselung und Anbindung des Konnektors.
• Generierung und Anbindung der Sensorbeschreibung.
Wie in Abbildung 6.6 dargestellt, erfolgt eine Anbindung eines Sensors in den folgenden Schritten:
6 Realisierung 145
1. Initialisierung
3. Lokalisation 2. Registrierung
4. Beschreibung Anfordern
4. Beschreibung Anfordern 5. Anfrage 5. Anfrage
Abbildung 6.6:Ablauf: Nutzung der Sensor-Basis
1. Initialisierung:Zur Anmeldung eines Sensors müssen die grundlegenden Beschreibungselemente und die Schnittstelle mit den erweiterten Funktionalitäten (sowie eine Referenz auf das Objekt, welches die Schnitt-stelle instanziiert) an die Sensor-Basis übergeben werden.
2. Registrierung: Anhand der übergebenen Schnittstelle wird die Beschreibung der erweiterten Funktionali-täten des Sensors generiert. Die Sensor-Basis meldet die erweiterten FunktionaliFunktionali-täten, zusammen mit den Grundfunktionalitäten am Konnektor an.
3. Lokalisation:Über den Konnektor wird der Sensor als neuer Dienst im Netz angeboten.
4. Beschreibung anfordern:Sobald ein System den neuen Dienst im Netz erkennt, kann dieser die Beschrei-bungselemente des Sensors anfordern.
5. Anfrage:Eine Anfrage auf den eigentlichen Sensor wird direkt auf das bei der Anmeldung übergebene Objekt weitergereicht, welches die Schnittstelle implementiert.
Durch die Kapselung aller für die Anbindung eines Sensors benötigten Funktionalitäten in Form einer Sensor-Basis, kann eine Anbindung eines Sensors stark vereinfacht und der Aufwand letztlich auf die Übergabe einer Schnittstelle (mit semantischen Anmerkungen) bei der Anmeldung reduziert werden.
6.2.1 Umsetzung von Sensoren
Im Rahmen der Umsetzung von ContextFramework.KOM wurde eine Reihe von Sensoren umgesetzt die innerhalb des Rahmenwerkes nutzbar sind. Die Plattformen, welche hierbei getestet und genutzt wurden, sind:
• Windows, Linux:Standard PC System mit dem jeweiligen Betriebssystem.
• Nokia N810:Linux basierter PDA, ARM 400 MHz CPU, 128 MB RAM und 2 GB Flash-Speicher.
• Windows Mobile (WM):Smartphone mit Unterstützung von Microsofts .NET Compact Framework (CF).
• Gumstix: Linux basiertes, eingebettetes (engl. embedded) System. Der Gumstix Verdexhat eine 600 MHz CPU, 128 MB RAM und 32 MB Flash-Speicher.
• NSLU2: EinNetwork Attached Storage-Gerät (NAS) mit Linux, 266 MHz ARM CPU und 32 MB RAM (ver-gleichbar mit handelsüblichen Breitbandroutern).
• SunSpot:Drahtloser Sensor mit 180 MHz ARM CPU, 512 KB Ram und 4 MB Flash-Speicher. Fähigkeit zur Ausführung von Java-MicroEdition Code, sowie integriertem Helligkeits-, Temperatur- und Beschleunigungs-sensor. Die Kommunikation erfolgt über IEEE 802.15-4.
• TMote:Der drahtlose SensorTelos Bhat eine 8 MHz CPU, 10 KB RAM und 1 MB Flash-Speicher. Die Funk-schnittstelle unterstützt 802.15-4. Auf dem Sensorknoten sind Helligkeits-, Temperatur- und Feuchtigkeits-sensoren integriert.
Die Plattformabhängigkeit einzelner Sensoren beruht meist auf der Nutzung systemspezifischer Schnittstellen.
Die Tabelle 6.1 gibt einen Überblick über die entwickelten Sensoren und die jeweils nutzbaren Plattformen.
146 6.2 Sensoren
BezeichnungPlattformenErfassteInformationen AnwendungWindowsAktuelleAnwendungimVordergrundeinesNutzers,Tastaturaktivität AufgabenplanerWindowsAusgewählteAufgabeauseinemAufgabenplaner BatterieNokiaN810LadestandderBatterie BewegungSunSpotBewegungs-,Lagesensor BluetoothLinux,Gumstix,NSLU2SichtbareGeräteinderUmgebung,Signalstärke ComputerAktivitätWindowsMausbewegung Datenbank*ParameterisierbareAbbildungen(z.B.AbbildungvonNameaufArbeitsplatz) E-Mail*NachrichtenaustauschmitanderenNutzern Endgeräte*Endgeräteingeschaltet,Adresse(Telefonnummer) Endgeräte-TemperaturNokiaN810InternerTemperaturfühler GPSWM,NokiaN810Position HelligkeitNokiaN810,TMote,SunSpotLichtstärkeimRaum KalenderWindows,WMAktuelle,nächsteEreignisse KameraWindows,Linux,Gumstix,NSLU2BewegungimRaum,Bild KontakteWindows,WMAbbildungvonNamezuAdressenundumgekehrt,Beziehungen Kontext*ZuständeamKontextdienst(zurNutzungandererKontextdimenstionen) NachbarschaftTmote,SunSpotSichtbareSensorknoteninderUmgebung(IDundSignalstärke) Ping*ErreichbarkeitvonGerätenimNetzwerk PulsSunSpotHerzschlag SkypeWindowsEingestelltesVerfügbarkeitslevel,Kontakte StuhlTMoteNutzungeinesBürostuhls(eingebauteKontaktmatte) Telefonie*AngemeldeteGeräte,aktiveGespräche TemperaturTMote,SunSpotUmgebungstemperatur TerminkalenderWindowsEingetrageneEreignisseimTerminkalender WLanLinux,WM,Gumstix,NSLU2SichtbareFunknetzwerkeinderUmgebung,Signalstärke *plattformunabhängigeIntegrationdesSensors. Tabelle6.1:ÜberblicküberdieimRahmenvonContextFramwork.KOMentwickeltenSensoren
6 Realisierung 147
6.2.2 Sensorbeschreibung
Das System ist offen gegenüber neuen Sensoren und Technologien. So können im Nachhinein auch neue, unbe-kannte Sensoren am System angemeldet und genutzt werden. Sensoren und deren benötigte bzw. angebotene Informationen werden hierbei geeignet beschrieben, um neben der Relevanz eines Sensors für bestimmte Suchan-fragen auch eine korrekte Verarbeitung und Nutzung der Informationen zu gewährleisten. Zur Beschreibung kom-men sowohl Technologien aus dem Bereich der Schnittstellenbeschreibung von Diensten als auch Methoden zur semantischen Beschreibung von Diensten und Informationen zum Einsatz.
Die Nutzung eines Standards oder eines offenen Ansatzes verspricht Kompatibilität zu anderen Systemen und die Wiederverwendung von bestehenden und etablierten Technologien und Programmen. Wie in Abschnitt 4.4 beschrieben, existieren verschiedene Ansätze um Dienste und Informationen semantisch zu beschreiben.
Die Hauptaufgabe besteht in der semantischen Beschreibung der Eingabe- und Ausgabedaten eines Sensors, sowie der Beschreibung der Relation eines Sensors zu anderen Objekten (Individuals). Die beschriebenen Techno-logien SAWSDL, WSMO und OWL-S sind hierzu prinzipiell geeignet. Für diese Arbeit wurde OWL-S ausgewählt, da eine Reihe weiterer Technologien und Werkzeuge vorhanden sind, welche sich mit OWL-S gut anwenden lassen:
• OWL:Das auf XML und RDF basierende Format OWL wird in vielen Arbeiten zur Beschreibung von Ontolo-gien genutzt. OWL-S geht aus OWL hervor und lässt sich gut in Kombination damit anwenden.
• JENA:Das JENA-Framework6basiert auf Java und bietet eine umfangreiche API, um mit OWL und OWL-S zu arbeiten.
• CMU:Diese API für OWL-S wurde von der Carnegie Mellon University erstellt7. Da das Rahmenwerk grund-legend unabhängig von anderen Systemen betrieben werden soll und diese API nur mit Verweisen auf extern gelagerte Ontologien arbeitet, kam dieses System für diese Arbeit nicht in Betracht.
• Mindswap: Dieses System der University of Maryland bietet ebenfalls eine API für OWL-S, welche wiederum auf JENA aufsetzt8. Diese API ermöglicht jedoch die Verwendung eines Zwischenspeichers für die Beschrei-bungen, welcher auch mit lokal gelagerten Beschreibungen gefüllt werden kann. Dies ermöglicht die lokale Bereitstellung und den Zugriff auf OWL und OWL-S Dokumente innerhalb abgeschlossener Systeme. Diese API wird im Rahmen dieser Arbeit genutzt, um mit OWL-S Dateien zu arbeiten.
• SWRL:Weitere Technologien, wie SWRL ermöglichen die Definition von Anfragen über semantische Inhalte einer Ontologie. Solche Anfragen können mit SWRL anhand der semantisch beschriebenen Suchergebnisse und der Ontologie ausgewertet werden. Die Nutzung von SWRL zur Auswertung der Suchergebnisse zählt zu den Aufgaben nachfolgender Arbeiten am Rahmenwerk.
• Protégé: Der OWL Editor Protégé9 eignet sich gut, um mit OWL und OWL-S zu arbeiten. Der Editor ist speziell für OWL entworfen und bietet ein entsprechend angepasstes GUI an.
• SWeDE: Das Semantic Web Development Environment (SWeDE) bietet einen OWL Editor als Eclipse Plu-gin an. Durch die Integration in Eclipse können bekannte Funktionen wie Syntax-Hervorhebung, Code-Vervollständigung und die syntaktische Fehlererkennung bei der Bearbeitung von OWL Dateien genutzt wer-den.
Generierung von OWL-S-Beschreibungen
Durch die Entscheidung OWL-S10zu nutzen, wird für jeden Sensor eine OWL-S konforme Beschreibung benötigt.
Wie in Abschnitt A.4 beschrieben, werden dazu mehrere Dateien benötigt:OWL-S Service,OWL-S Profile,OWL-S ProcessundOWL-S Grounding. In Abschnitt A.5 des Anhangs wird die OWL-S Beschreibung eines Sensors bereits in gekürzter Form dargestellt. Wie sich daran erkennen lässt ist der Umfang dieser XML basierten Beschreibung relativ groß. Eine weitere Funktionalität, welche im Rahmen von ContextFramework.KOM entwickelt wurde, ist die auto-matische Generierung der OWL-S Beschreibung. Hierzu wird ein Java-Interface mit zusätzlichen Annotationen (in Form von normalen Kommentaren) versehen genutzt. Innerhalb dieser Annotationen können semantische Zusatz-informationen definiert werden. In dem folgenden Beispiel wird das Java-Interface des Skype-Sensors dargestellt:
6 http://jena.sourceforge.net/
7 http://www.daml.ri.cmu.edu/owlsapi/
8 http://www.mindswap.org/2004/owl-s/api/
9 http://protege.stanford.edu/
10OWL-S 1.1:http://www.daml.org/services/owl-s/1.1/overview/
148 6.2 Sensoren
package sn.sensors.skype;
/**
* This class accesses the Skype client and returns its status
* @category AbstractSensor
*/
/**
* @return SkypeActivity
* @expirationTime 10000
*/
public String getSkypeStatus();
Die Definition der Java-Methode kann direkt genutzt werden, um beispielsweise Elemente desOWL-S Groun-dings zu generieren. Die mit speziellen Schlüsselworten versehenen Kommentare (@category,@param, @return und@expirationTime) werden ausgelesen, um die Kategorie des Sensors, den semantischen Datentyp und weitere Eigenschaften wie deren Gültigkeit zu bestimmen.
In der Abbildung 6.7 ist die Anwendung dieser semantisch annotierten Schnittstelle dargestellt.
OWL-S Generator Schnittstelle
mit semantischen Annotationen
Dienst
Grounding Profile Process
Diensteverzeichnis Profile Grounding
OWL-S Beschreibung Erstellung
Registrierung Implementiert
Initialisierung
Aufruf Aufruf Anfrage
1. Anmeldung 2. Aufruf
Anmeldung
Abbildung 6.7:OWL-S Generierung und Nutzung
Ein Sensor benötigt für die Anbindung an den Konnektor ein Interface. Dieses Interface als Grundlage für die OWL-S-Beschreibung zu nutzen ist weitaus intuitiver und einfacher, als manuell eine OWL-S-Beschreibung zu er-stellen oder zu editieren. Durch die Integration in das Rahmenwerk kann die Beschreibung zur Laufzeit generiert werden, wodurch kein zusätzlicher Schritt in der Entwicklung oder Ausführung von Diensten notwendig wird.
Wie in Abschnitt 4.4 beschrieben, steht bei der Beschreibung eines Sensors die semantische Beschreibung der bereitgestellten Informationen im Vordergrund. Die Funktionsweise lässt sich bei normalen Sensoren meist auf die Bereitstellung der jeweiligen Information reduzieren. Daher wird ein Großteil der Möglichkeiten, welche durch die Beschreibung im OWL-S Processzur Verfügung gestellt werden, nicht benötigt. Relevant wird dieser Teil beim Zwischenspeichern von Sensordaten, da dort entsprechende Informationen über die Gültigkeit der Sensordaten enthalten sind.
6.2.3 Gateway
Zur transparenten Anbindung drahtloser Sensornetzwerke wurde einGatewayentwickelt. Dieses Gateway bildet den Proof-of-Concept zur Anbindung von Kleinstgeräten an das Rahmenwerk. Wie in Abbildung 6.8 dargestellt, wird jeder aufgefundene, drahtlose Sensor am Gateway durch einen Proxy-Sensor am Rahmenwerk angemel-det. Dieser Proxy-Sensor bietet auf der Seite des Rahmenwerkes eine vollständige Implementierung der Sensor-Schnittstelle an. Auf der anderen Seite werden die Anfragen auf die Funktionen der drahtlosen Sensoren abgebil-det.
Auf der Seite der drahtlosen Sensoren besteht eine sehr starke Ressourcenbeschränkung. Diese führt zu Heraus-forderungen im Bereich der Selbstbeschreibung von Sensoren und der Erfüllung von hohen QoS-AnHeraus-forderungen.
6 Realisierung 149
Mote 1 Sensor A
Gateway
Proxy Sensor A Mote 3
Mote 2 Sensor B
Sensor B
Diensteverzeichnis Registry Sensor A Sensor B
... ...
Abbildung 6.8:Anwendungsbeispiel: Nutzung des Gateways
Beschreibung von drahtlosen Sensoren
Eine vollständige Beschreibung eines Sensors auf der Basis des herangezogenen OWL-S Standards erfordert eine relativ große Menge an Speicher und Transfervolumen. Der Einsatz eines solchen Standards auf Systemen wie beispielsweise den TMotes ist nicht sinnvoll. Möglichkeiten diesem zu begegnen bestehen meist in Ansätzen wie:
• Kompression der Beschreibung [RHS09].
• Reduzierung auf wesentliche Aussagen.
• Nutzung geeigneter, ressourcensparender Formate und Auszeichnungssprachen.
• Verweis auf externe, öffentlich zugängliche Speicherorte mit der vollständigen Beschreibung des Sensortyps.
Aktuell wird die zweite Variante angewandt. In weiteren, aktuell durchgeführten Arbeiten am Rahmenwerk werden auch die anderen Ansätze weiter verfolgt.
Erfüllung von QoS Anforderungen
Aktuell werden Anfragen direkt an den jeweiligen drahtlosen Sensor weitergeleitet. Die direkte Anfrage eines Sensors erfordert eine Reihe von Aufrufen, welche dazu möglicherweise über mehrere drahtlose Sensoren weiterge-leitet werden müssen. Eine solche Anfrage würde einen erhöhten Zeitaufwand mit sich führen, wodurch mögliche QoS Anforderungen verletzt werden könnten. Zum einen wird diese Herausforderung durch den Mechanismus zur Vorhaltung von Sensorinformationen (engl.Prefetching) adressiert. Zum anderen behandeln aktuelle Arbeiten am Rahmenwerk mögliche Ansätze zur aktiven Weitergabe von Sensordaten eines drahtlosen Sensors in Richtung des Gateways.