Hauptseminar: Kopplungswerkzeuge für Feldbusse und ...midas1.e-technik.tu-ilmenau.de/~webkn/Abschlussarbeiten/Hauptseminarar... · kurz und beispielhaft auf die Kopplung von ZigBee

Hauptseminararbeit

Kopplungswerkzeuge für Feldbusse und

Sensornetze in der Hausautomatisierung

Institut für Informationstechnik

Fakultät für Elektrotechnik und Informationstechnik

Technische Universität Ilmenau

Studiengang: Elektrotechnik und Informationstechnik

Sommersemester 2009

Name: Johannes Krasser

Matrikelnummer:

Abgabetermin: 30.06.2009

Themenstellung

In zukünftigen "intelligenten Häusern" wird eine Vielzahl von Netzen

verfügbar sein: WLAN für hochbitratige Multimediadaten, ZigBee zur

Steuerung der Beleuchtung, Wireless MBUS zur Zählerauslesung und noch

diverse weitere Systeme, offene wie proprietäre.

Dieses Hauptseminar soll nach Kopplungsmechanismen recherchieren, die

mit dem Ziel antreten, diese Vielzahl an sich überlagernden Netzen zentral

ansprechen und verwalten zu können.

Inhaltsverzeichnis

Hauptseminar: Kopplungswerkzeuge für Feldbusse und Sensornetze in der Hausautomatisierung

Johannes Krasser

1. Einleitung........................................................ 1

2. Kopplung mit IP-basierten Netzen .................. 2

2.1. Ethernet – Feldbus der Zukunft ? .......................................2

2.1.1. Probleme und Potentiale von Ethernet .................................. 2 2.1.2. Beispiel: KNXnet/IP ........................................................... 3

2.2. IP-Kopplung von Sensornetzen ..........................................6

3. „High-Level“ Ansätze...................................... 7

3.1. Konzept der Residential Gateways......................................7

3.2. Open Services Gateway initiative (OSGi)........................... 11

3.2.1. Architektur von OSGi........................................................ 12 3.2.2. Zusammenfassung........................................................... 13

3.3. Global Sensor Networks (GSN) ........................................ 15

3.3.1. Ziele von GSN ................................................................. 15 3.3.2. Architektur des GSN-Systems............................................ 16

4. Ausblick .........................................................19

5. Quellenverzeichnis.........................................20

Einleitung


Johannes Krasser

1

1. Einleitung

Die Entwicklung von Sensornetzen hat sich bisher vor allem auf Fragen

wie Datensammlung, Übertragungssicherheit oder auf Energieeffizienz

konzentriert. Mit der Weiterentwicklung dieser Technologien und mit dem

rapiden Preisverfall von drahtlosen Sensoren wird die Zahl von autonomen

Sensornetzwerken, die auf den Markt kommen, steigen.1 Daneben

entstehen Technologien zur Vernetzung und Automatisierung von

Haushaltsgeräten aus dem Bereich der „Weißen Ware“ oder der

Unterhaltungselektronik.

Auch im Bereich der Feldbussysteme gilt kein Feldbus als alleiniger

Standard der Hausautomatisierung, auch wenn z.B. im KNX-Standard

versucht wurde, die Vorteile und Möglichkeiten von drei

Vorgängersystemen zu kombinieren.

Ein Anwender kann sich beispielsweise für ein Sensor-/Aktor-Netz mit

Bussystem entscheiden, um seine Fenster, Rollläden und die Beleuchtung

zu automatisieren, muss jedoch ein Jahr später feststellen, dass für die

geplante Automatisierung der Heizungsanlage ein anderes System

geeigneter oder bis dahin kostengünstiger ist.

Außerdem soll dem Anwender ermöglicht werden, von seiner gewohnten

und übersichtlichen Arbeitsumgebung am PC auf sein Netzwerk zugreifen

zu können, um beispielsweise den Batteriestand eines ZigBee-Gerätes

abzufragen, den Befehl zum Öffnen eines Fensters zu geben oder die

Daten seiner Sensoren protokollieren und visualisieren zu können.

Dazu sind Kopplungswerkzeuge nötig, die bestehende Systeme verbinden

können, aber auch einen Standard für zukünftige Technologien definieren.

Im Folgenden soll auf einige Systeme für verschiedene Ebenen

eingegangen werden, die aber noch immer weiter und neu entwickelt

werden.

1 http://lsirpeople.epfl.ch/salehi/papers/LSIR-REPORT-2006-006.pdf

Kopplung mit IP-basierten Netzen


Johannes Krasser

2

2. Kopplung mit IP-basierten Netzen

2.1. Ethernet – Feldbus der Zukunft ?

Mit der Weiterentwicklung der Gebäudeautomation und speziell der

Hausautomatisierung in den letzten Jahren entstand mit der zunächst

unkoordinierten Entwicklung von Sensornetzen auch eine Vielzahl von

verschiedenen Feldbussystemen, die teilweise auch stark spezialisiert

sind. Dazu gehören z.B. EIB (Europäischer Installationsbus) mit seinem

Nachfolger KNX, LON (Local Operating Network) oder DALI (Digital

Adressable Lighting Interface). „Die Konsolidierung in ein einheitliches

Allround-Bussystem ist auch heute noch nicht in Sichtweite, jedoch hat

sich seit einigen Jahren die Nutzung übergeordneter Bussysteme bewährt,

die unterschiedliche Feldbusse über Kommunikationsklemmen mit einem

Gebäudebus koppeln.“2 Auf der Ebene dieser übergeordneten Busse heißt

der Gebäudebus immer häufiger Ethernet, da die Vernetzung immer

unterschiedlicherer Einheiten gefordert wird und Ethernet mit seinen

entwickelten Protokollen von Herstellern und Anwendern weltweit

unterstützt wird.

2.1.1. Probleme und Potentiale von Ethernet

Ethernet bringt durchaus technische Nachteile mit sich, die bisher den

Einsatz in der Hausautomatisierung erschwerten: 3

• Ethernet ist undeterministisch, d.h. der Transport eines Datenpakets

ist zeitlich nicht genau vorhersagbar. Besonders bei Regelschleifen,

die Daten dynamisch erfassen müssen ist dies kritisch.

• Paketkollisionen verringern den Datendurchsatz

2 http://www.netigator.de/netigator/live/show.php3?id=47&aid=31217413 3 http://www.scantec.de/Fachartikel/Fachartikel-Standard/Ethernet-Feldbus-der-Zukunft.pdf



Johannes Krasser

3

• Die Paketstruktur von IP-Paketen ist nicht unbedingt auf die

Anforderungen der Bussysteme angepasst.

Andererseits bietet Ethernet auch wichtige Vorteile und neue

Möglichkeiten:

• Die Spezifikationen des Ethernet-Standards sind offen, so dass

Produkte von unterschiedlichen Herstellern geliefert werden können.

• Die Datenrate ist mit 1Gbit/s weitaus höher, als bei den meisten

Bussystemen. Dem Problem der Paketkollision kann wirkungsvoll mit

strukturierter Verkabelung und entsprechender Auslegung des

Netzwerkes begegnet werden.

• Die Anbindung der Feldbusse an einen PC sowohl über Intranet als

auch Internet ist einfach. Dies ermöglicht die einfache

Fehleranalyse, Datenerfassung, Visualisierung und Auswertung.

• Ethernet ist weit verbreitet und hat sich bewährt.

Im Folgenden soll anhand des Standards KNXnet/IP schematisch die

Kopplung des weit verbreiteten Feldbusses KNX mit einem IP-Netz gezeigt

werden. Ähnliche Standards existieren auch für andere Feldbusse wie z.B.

IP-852 für LON und ermöglichen somit die Kopplung zwischen Feldbussen.

2.1.2. Beispiel: KNXnet/IP 4

KNXnet/IP beschreibt, wie das KNX-Protokoll aufbauend auf dem

Internetprotokoll implementiert wird. Das folgende Bild zeigt ein Szenario,

in dem mehrere KNX-Subnetzwerke an ein IP-Netz und eine Workstation

gekoppelt werden. Die Workstation kann beispielsweise ein PC oder ein

Gateway sein, auf dem das KNXnet/IP client protocol implementiert

wurde.

4 https://www.auto.tuwien.ac.at/downloads/HGA08/seminarteil/knx_lon_ip.pdf



Johannes Krasser

4

Abbildung 1: KNX Netzwerk mit KNXnet/IP 5

KNXnet/IP spezifiziert zwei mögliche Verbindungsarten:

• IP-Tunneling (Punkt-zu-Punkt Übertragung, verbindungsorientiert

mit TCP/IP oder verbindungslos mit UDP/IP):

Dabei wird jeweils ein KNX-Frame in ein IP-Paket gepackt und

versendet. Es wird z.B. zur EIB Programmierung verwendet.

• IP-Routing (Punkt-zu-Mehrpunkt, verbindungslos mit UDP/IP):

Von IP Routing spricht man wenn mehrere KNXnet/IP Router über

eine 1:n Beziehung kommunizieren.

Bei der Verwendung von IP zur Kommunikation

zwischen Bussen gilt es einige Besonderheiten zu

beachten:

Bei einem normalen Feldbussystem empfangen alle

Teilnehmer die Daten, sobald z.B. ein angeschlossener

Sensor Daten verschickt (Physikalischer Aufbau). Im

Gegensatz dazu sind IP-Netze logisch aufgebaut.

5 https://www.auto.tuwien.ac.at/downloads/HGA08/seminarteil/knx_lon_ip.pdf 6 http://www.eib-home.de/instabus_knx-eib_tipps_siemens_ip-schnittstelle_n146.htm

Abbildung 2: Siemens

N146 KNX / IP Router6



Johannes Krasser

5

Jedes Gerät muss also eine eindeutige IP-Adresse zugewiesen bekommen,

unter der es anzusprechen ist.

Weiterhin sind Puffer notwendig, da Ethernet in der Lage ist, weit

schneller Daten zu versenden als die meisten Komponenten des

Bussystems sie verarbeiten können. Schließlich müssen Sequenznummern

eingeführt werden, da im IP-Netz Datenpakete in falscher Reihenfolge

ankommen können, was bei normalen Feldbussystemen nicht möglich ist.



Johannes Krasser

6

2.2. IP-Kopplung von Sensornetzen

Auch bei den Sensornetzen zeigt sich eine Tendenz, Kopplungen mit IP-

Netzwerken herzustellen. Die Vorteile und Schwierigkeiten sind dabei

natürlich Ähnliche wie im vorangegangenen Kapitel. Deshalb soll hier nur

kurz und beispielhaft auf die Kopplung von ZigBee eingegangen werden.

Eine ZigBee-Bridge kann diese Aufgabe erfüllen. Die ZigBee

Netzwerkschicht liegt über der IP Transportschicht (TCP, UDP) und über

der IEEE 802.15.4. Sicherungsschicht (Übertragungsprotokoll, auf dem

ZigBee aufbaut). Die Bridge macht die Verbindung zur IP schicht für die

ZigBee-Geräte transparent.7

Die ZigBee-Sensoren (oder

ganze „Cluster“ von Sensoren)

können über ein IP-Backbone

miteinander kommunizieren,

indem sie die ZigBee-Bridge

nutzen. Sie benötigen nur einen

einzelnen ZigBee-Koordinator.

Eine Möglichkeit der Anwendung

wäre z.B. je eine Bridge in jedem

Stockwerk des Hauses, wobei die

Sensoren nur über kurze Entfernung mit ihrer Bridge kommunizieren und

die einzelnen Bridges via Ethernet oder an das Hausstromnetz

angeschlossene WLAN gekoppelt sind. Zusätzlich besteht die Möglichkeit,

beispielsweise den Batteriestatus von Sensoren über den PC auszulesen

oder vom PC aus Kommandos an Aktoren zu senden.

Das folgende Kapitel wird sich nun mit Kopplungsmechanismen auf

höherer (Gateway-) Ebene und der Verwendung sogenannter Middleware

befassen.

7 http://www.sarmac.com.br/download/Testes/varella/zigbee/04196332.pdf

Abbildung 3: ZigBee-Stack über IP und 802.15.4 7

Ausblick


Johannes Krasser

7

3. „High-Level“ Ansätze

3.1. Konzept der Residential Gateways

Ein wichtiger Ansatz zur Kopplung und Verwaltung verschiedener

Hausautomatisierungssysteme ist das Residential Gateway (RGW, auch

Home Gateway, HG). Das Gateway stellt einerseits die Verbindung

zwischen der Wohnumgebung und der Außenwelt dar, andererseits ist es

die Schnittstelle zwischen den im Wohnbereich vorhandenen Netzen.8 Es

sollte die verschiedenen Technologien sowohl kabelgebundener als auch

drahtloser Systeme unterstützen und gleichzeitig sicherstellen, dass kein

Dritter unberechtigten Zugang zum Heimnetz erhält. Innerhalb des

Heimnetzes muss das Gateway Vermittlungsfunktionen übernehmen.9

Neben der Vielzahl an möglichen Kommunikationspartnern und

Sensornetztypen liegen die Schwierigkeiten auch auf den teilweise sehr

hohen Anforderungen an die Datenrate (z.B. bei HDTV).

Die Abbildung zeigt beispielhaft mögliche Verbindungen mit einem

Residential Gateway. Anschlussnetzseitig besteht eine Verbindung über

die DSL-Leitungen. Heimnetzseitig wird zunächst ein oder mehrere PCs

z.B. über Ethernet, WLAN oder USB angeschlossen. Damit übernimmt das

Gateway die Aufgabe des DSL-Modems/Routers. Weiterhin können aber

nun die anderen Geräte, die mit dem Gateway verbunden sind, mit Hilfe

von umfangreichen Management-Programmen von der normalen

Arbeitsumgebung am PC gesteuert werden. Neue Geräte können

konfiguriert werden und die eingehenden Daten von Sensoren gefiltert,

grafisch dargestellt und überwacht werden.

8 http://de.wikipedia.org/wiki/Residential_Gateway 9 http://www.itwissen.info/definition/lexikon/home-gateway-HG-Home-Gateway.html

Ausblick


Johannes Krasser

8

Abbildung 4: Beispiel eines Heimnetzes mit Residential Gateway

Außerdem sind Anschlüsse für Telefone vorhanden (evtl. auch ATA zur

Verbindung von Analogtelefonen mit dem VoIP-Netz). Haushaltsgeräte wie

Waschmaschine oder Kühlschrank aber auch Heizung können

beispielsweise über PLC (Powerline Communication, Übertragung von

Daten über das Stromnetz durch Modulation) verbunden werden. Solche

Geräte werden z.B. von Siemens und Miele unter dem Namen

serve@home bzw. Miele@home bereits angeboten. Die Kommunikation

mit Multimediageräten wie Stereoanlage oder Fernsehgerät und DVD-

Player erfolgt beispielsweise über IEEE 1394 (FireWire).

Weiterhin müssen die verschiedenen Sensornetzwerke und

Feldbussysteme über das Gateway kommunizieren können. Dies kann z.B.

über spezielle Anschlüsse und Programmierschnittstellen (APIs) von

Protokollen für Systeme wie EIB (Europäischer Installationsbus), LON

(Local Operating Network) oder über auf ein System zugeschnittene

Protokolle, die auf IP aufsetzen, und einen Anschluss über Ethernet oder

WLAN ermöglichen, realisiert werden.

Ausblick


Johannes Krasser

9

Neben den bekannten Daten- und Streamingdiensten muss ein solches

Residential Gateway auch remote Services wie die Überwachung von

energieintensiven Haushaltsgeräten, die Fernbeobachtung für

Hauspflegedienste, die Auslösung von Alarmen, wenn bestimmte

Ereignisse nicht mehr eintreten, wie das Öffnen des Kühlschranks o.ä.

übernehmen. 10

Außerdem soll dem Anwender die Möglichkeit gegeben werden, auf das

Gateway und damit sämtliche Komponenten seines Heimnetzwerks von

unterwegs via Internet (beispielsweise über das Mobiltelefon oder über

andere Computer) zugreifen zu können. Daraus entstehen erhöhte

Anforderungen an die Sicherheit des Systems.

Auf einem solchen Gateway muss also eine einheitliche Schicht geschaffen

und Programmierschnittstellen für verschiedene Protokolle bereitgestellt

werden, um die heterogenen und komplexen Systeme der unteren

Schichten für Heimnetzwerke miteinander kommunizieren lassen zu

können. Das Gateway muss den einzelnen Geräten Dienste vermitteln,

wobei die sehr allgemeine Serviceausrichtung eine starke

Plattformunabhängigkeit erfordert. Eine Softwareschicht die diese

Aufgaben bewältigt wird Middleware genannt. „In einem Netzwerksystem

werden für den Anwendungsprogrammierer z.B. entfernte

Ereignismeldungen sichtbar, verteilte Transaktionsprozesse

programmierbar und Methoden eines Objekts auf einem entfernten

Computer aufrufbar. Die Implementierung einer Middleware-

Systemschicht verbirgt die Tatsache, dass Nachrichten, Funktionsaufrufe

und Ergebnisantworten in einem verteilten System über Netzwerke und

Datenbusse übertragen werden müssen. Damit bietet eine Middleware-

Schicht dem Programmierer eine ähnlich konsistente

Programmierplattform wie ein PC-Betriebssystem.“11 Die folgende

10 http://www.itwissen.info/definition/lexikon/residential-gateway-RGW.html 11 http://www.inhaus-zentrum.de/media/e4c40fcf1e96307

Ausblick


Johannes Krasser

10

Abbildung verdeutlicht die Stellung der Middleware in einem

Sensornetzsystem.

Abbildung 5: Schichtenmodell offen integrierter Haussysteme mit Middleware Schicht12

Am häufigsten findet sich hier OSGi (open services gateway initiative),

dessen Spezifikationen unabhängig von der verwendeten Hardware

implementiert werden können, was durch den konsequenten Einsatz von

Java erreicht wird. Auf dieses System soll im folgenden Kapitel näher

eingegangen werden.

12 http://www.inhaus-zentrum.de/media/e4c40fcf1e96307

Ausblick


Johannes Krasser

11

3.2. Open Services Gateway initiative (OSGi)

Das OSGi-Framework stellt eine offene, skalierbare, dynamische und

hardwareunabhängige Softwareplattform auf Basis einer Java Virtual

Machine (JVM) dar. Es ermöglicht die Vernetzung intelligenter Endgeräte,

die Installation und Bereitstellung von Diensten, Informationsverteilung

und die Fernsteuerung und Diagnose von Geräten.

Der Hauptvorteil neben der Hardwareunabhängigkeit besteht in der

großen Flexibilität. Es besteht die Möglichkeit dynamisch und kontrolliert

Service-Anwendungen bzw. Komponenten zur Laufzeit einspielen und

auch wieder entfernen zu können. „Im OSGi-Programmiergerüst steht die

Komponente (= "Bundle") im Vordergrund, die ihre Schnittstelle (=

"Service") per Registry (= "Service-Registry") JVM-lokal veröffentlicht und

das Re/Deployment per Komponenten-Lebenszyklus unterstützt.“13

In der 1999 gegründeten OSGi-Alliance sind verschiedene Unternehmen

vertreten (z.B.: Nokia, Motorola, Deutsche Telekom, IBM) die mithelfen,

den OSGi Standard weiterzuentwickeln und industrieübergreifend

einsetzbar zu machen. Die OSGi-Alliance spezifiziert nur die

Programmierschnittstellen (APIs) und stellt Referenzimplementierungen

bereit, die aber nur als Vorlage dienen sollen. Verschiedene OSGi-Gerüste

sind sowohl als kommerzielle Produkte als auch als Open-Source-

Realisierung verfügbar.

OSGi wurde inzwischen als Java-Erweiterung (JSR-291) standardisiert.

Es wurden mehrere Dienste definiert, die es ermöglichen externe

Protokolle auf OSGi umzusetzen14. Dazu gehören z.B.:

- HTTP-Dienst

- UPnP (Universal Plug & Play; Dienst zur herstellerübergreifenden

Ansteuerung von Geräten über ein IP-basiertes Netzwerk)

13 http://de.wikipedia.org/wiki/Osgi 14 http://www.osgi.org/About/Technology

Ausblick


Johannes Krasser

12

- DMT Admin (Device Management Tree Admin): Dienst zur

Ansteuerung mobiler Geräte

3.2.1. Architektur von OSGi

Das OSGi-Framework stellt den Anwendungen (Bundles) eine

standardisierte Umgebung zur Verfügung. Es ist in vier Schichten

aufgeteilt.

L0 – Execution Environment:

Die erste Schicht ist die Spezifikation der

Java-Umgebung wie J2SE, CDC, CDLC,

MIDP.

L1 – Modules:

Die Software wird in Bundles unterteilt

(Anwendungen, die in normale JAVA-

Archive gepackt sind; JAR-Dateien). Im

Unterschied zu normalen JAVA mit nur

einem Klassenpfad hat bei OSGi jedes Bundle eigene Klassen. Außerdem

können Verbindungen zwischen den Klassen hergestellt werden.

L2 – Life Cycle Management:

Jedes Bundle kann während der Laufzeit installiert, gestartet, gestoppt,

aktualisiert und auch wieder deinstalliert werden. Diese Dynamik ist eine

Besonderheit von OSGi. Zusätzlich sind diese Operationen von

Sicherheitsmechanismen geschützt. Der Lebenszyklus eines Bundles muss

laut Spezifikation vollständig fernsteuerbar sein.

15

http://www.osgi.org/About/Technology

Abbildung 6: OSGi-Framework15

Ausblick


Johannes Krasser

13

L3 – Service Registry

Jedes Bundle kann Dienste registrieren, die von anderen Bundles genutzt

werden können, wodurch die Kommunikation zwischen den einzelnen

Bundles ermöglicht wird.

3.2.2. Zusammenfassung

Ein Vorteil von OSGi ist, dass die begrenzten Ressourcen, die in einem

Gateway zur Verfügung stehen, berücksichtigt werden. Die Vernetzung

verschiedener Netztechnologien wird durch die Modularität, die

Kommunikation von Bundles mit Diensten und Registry, sowie der

Möglichkeit der Integration von Protokollen stark erleichtert.

Durch die Möglichkeit, dass einzelne Bundles miteinander kooperieren

können, muss ein Bundle seine Aufgabe nicht allein lösen, sondern kann

auf Dienste anderer Bundles zurückgreifen. Nachteilig ist jedoch, dass

durch dieses System Abhängigkeiten zwischen Bundles entstehen. Wird

ein Bundle entfernt, so können seine Dienste von anderen nicht mehr

genutzt werden. Deshalb ist ein Kontrollsystem notwendig.16

Als Beispiel eines verfügbaren Home-Gateways sei hier das Gigaset SX765

von Siemens mit dem OSGi-Framework und dem remote-management

System der Firma ProSyst genannt17.

Abbildung 7: Netzwerk mit dem SX765 18

16 opus.bsz-bw.de/hdms/volltexte/2005/545/pdf/DA_Alb_Print.pdf 17 www.osgi.org/wiki/uploads/Markets/SuccessStory_ProSyst_SIEMENS.pdf

Ausblick


Johannes Krasser

14

Es verfügt über WLAN nach IEEE 802.11g, integriertes ADSL Modem, bis

zu sechs verschiedene VoIP-Accounts, FXS Ports für analoge Telefone,

Anschlüsse für bis zu vier PCs, USB 2.0 Host-Interface, KNXnet/IP

Interface sowie Funktionen zur Sicherheit, personalisierten Information

und Unterhaltung.

Neben OSGi existieren natürlich noch andere Middlewares, wovon im

Folgenden das speziell für die Kopplung von Sensornetzen entwickelte

GSN vorgestellt werden soll. Einige Komponenten des Systems befinden

sich allerdings noch in Entwicklung.

18 www.osgi.org/wiki/uploads/Markets/SuccessStory_ProSyst_SIEMENS.pdf

Ausblick


Johannes Krasser

15

3.3. Global Sensor Networks (GSN)

3.3.1. Ziele von GSN

GSN (Global Sensor Networks) ist eine Middleware, die sich zum Ziel

gesetzt hat, die Entwicklung von Technologien für Sensornetzwerke

voranzutreiben. Es ermöglicht die Integration heterogener Netze sowie die

Datenauswertung. Die Hauptziele bei der Entwicklung sind19:

• Einfachheit (z.B. einfache Deklaration von Sensordatenströmen mit

XML)

• Anpassbarkeit (Dem System können neue Sensoren/Sensornetze

während der Laufzeit hinzugefügt werden, ohne dass das System

angehalten werden muss)

• Skalierbarkeit (GSN basiert auf einer peer-to-peer Architektur, um

möglichst viele Datenquellen verwalten zu können.)

• einfache Implementierung (GSN lässt sich leicht in die Standard-

Rechnerumgebung einbauen und verbraucht nicht zu viele

Hardwareressourcen. Außerdem ist es aufgrund der auf Java

basierenden Implementierung portabel. Es wird nur eine geringe

Anfangskonfiguration nötig sein und es stehen leicht zu bedienende

Verwaltungswerkzeuge bereit.)

Ein Hauptansatz bei GSN ist die Deklaration von sogenannten virtuellen

Sensoren. Ein virtueller Sensor kann jede Art von Datenquelle sein, z.B.

ein realer Sensor, ein Computer, ein Mobiltelefon oder eine Kombination

von virtuellen Sensoren. Dies hilft die Daten, falls erwünscht, im Voraus

zu kombinieren und somit die Datenmenge, die das Zentralsystem

verarbeiten muss, zu reduzieren. Es ist möglich ein Sensornetz

physikalisch anzusprechen, wenn es direkt mit dem Computer, welcher die

GSN-Instanz hostet, verbunden ist. Außerdem kann ein Netz

angesprochen werden, das mit einer anderen Instanz verbunden ist


Ausblick


Johannes Krasser

16

(Remote-Adressierung). Die GSN Instanz weis dabei nicht, ob die Daten

von einem lokalen oder Remote-Sensor stammen.

Global Sensor Networks stellt auch grundsätzliche Möglichkeiten zur

Datenstromverarbeitung bereit.

3.3.2. Architektur des GSN-Systems

GSN benutzt eine sogenannte

„Container-Architektur“. Dieser

Aufbau bietet den Vorteil, dass

Sensornetze leicht und flexibel

spezifiziert werden können, während

der Großteil der Komplexität im

GSN-Container versteckt bleibt.

Besonders wichtig ist, dass virtuelle

Sensoren während der Laufzeit

konfiguriert werden können.

Die Kommunikation zwischen den

verschiedenen GSN-Containern wird

über die normalen Internetprotokolle

realisiert. Der Hauptvorteil dieser

Architektur liegt jedoch darin, dass

ein hierarchischer Aufbau vermieden

wird, der eventuell ab einer

bestimmten Größe die relativ freie Skalierbarkeit des Systems

beschränken würde. Die Zukunfstsperspektive der Entwickler ist ein

„Sensor Internet“, also ein weitgehend autonomes Sensorsystem mit

großen Freiheiten, das nur geringe Eingriffe nötig macht, ähnlich dem

Internet.


Abbildung 8: GSN „Container“-Aufbau20

Ausblick


Johannes Krasser

17

Jeder Container ist für eine bestimmte Anzahl von Sensoren zuständig.

Der virtual sensor manager (VSM) spricht die einzelnen Sensoren an und

stellt die QoS sicher, indem er das Trennen von Sensoren, fehlende Werte,

unerwartete Verzögerungen, etc. überwacht. Der darüber liegende query

manager (QM) verwaltet die Planung und Ausführung von Anfragen.

Besonders hervorzuheben ist die Aufgabe des notification managers. Er

hat eine variable Architektur und ermöglicht es beispielsweise,

Benachrichtigungen per E-Mail oder SMS zu bekommen. In den drei

obersten Schichten wird der Zugang zu einem GSN-Container geregelt.

Die interface layer stellt Zugangsfunktionen für andere GSN-Container und

für das Internet bereit. Die access control layer stellt sicher, dass nur

befugte Parteien Zugriff haben und die data integrity layer garantiert

Integrität und Vertraulichkeit durch elektronische Signaturen und

Verschlüsselungsverfahren.

Um einen virtuellen Sensor einzubinden, muss eine Beschreibung in Form

eines XML-Descriptors geschrieben werden falls GSN den Gerätetyp

bereits unterstützt. Darin sind alle wichtigen Parameter des Geräts

enthalten. Momentan werden Tiny-OS-Sensoren, USB und Wireless-

Kameras mit HTTP sowie einige RFID-Geräte (Radio Frequency

Identification) unterstützt. Weitere Geräte sollen folgen.

Die Entwickler stellen im Internet auch Tutorials bereit, die zeigen, wie der

Java-Code (sog. wrapper) für neue Gerätetypen geschrieben werden

kann.

Die Wrapper ermöglichen, dass die Datenströme unterschiedlicher Geräte

von verschiedenen Herstellern vom GSN-System richtig interpretiert

werden, und dass umgekehrt die Steuerbefehle an die Geräte des

Sensornetzes richtig umgesetzt werden. Durch die Definition von

virtuellen Sensoren können nun die Datenströme logisch verknüpft

werden. Beispielsweise soll die Heizung eines Raumes abgeschaltet und

das Fenster kurz geöffnet werden, solange der Datenstrom eines

Ausblick


Johannes Krasser

18

Temperatursensors Daten über einem gewissen Schwellwert liefert oder

ein CO2-Sensor einen zu hohen CO2-Gehalt anzeigt.

Abbildung 9: Sensornetz an einem Computer mit GSN21

Die Abbildung zeigt noch einmal ein Sensornetz, das über einen speziellen

Netzknoten mit einem Computer verbunden ist, auf dem GSN ausgeführt

wird.

Dieser Computer kann – wie hier gezeigt – über das Internet oder auch

über ein Intranet im Haus mit anderen Computern verbunden sein, die

wiederum mit Sensornetzen verbunden sind.

21

http://sourceforge.net/apps/trac/gsn/wiki/Introduction

Ausblick


Johannes Krasser

19

4. Ausblick

Die Technologien, die zu einer zentralen Kopplung aller automatisierten

Geräte im Haus führen, sind sehr wichtig und entscheidend für den Erfolg

von „intelligenten Häusern“ bei einer breiten Anwenderschicht.

Die eleganteste Lösung ist momentan wahrscheinlich der Ansatz eines

Residential Gateways mit Middleware. Am weitesten entwickelt ist hier

OSGi, das beispielsweise in der Automobilindustrie bereits eingesetzt wird.

Ob es allerdings der Hausautomation zum Durchbruch verhilft und

langfristig verwendet wird, ist noch nicht eindeutig abzusehen.

Bei allen Vorteilen der zentralen Kopplung aller Systeme sollte auch

verstärkt ein Augenmerk auf das Problem der Sicherheit gelegt werden.

Insbesondere, wenn alle Komponenten mit dem Internet verbunden sind,

müssen die Daten des Anwenders und die Steuerungen vor

unberechtigtem Zugriff oder Angriffen von Außen geschützt werden.

Quellenverzeichnis


Johannes Krasser

20

5. Quellenverzeichnis

http://www.netigator.de/netigator/live/show.php3?id=47&aid=31217413

https://www.auto.tuwien.ac.at/downloads/HGA08/seminarteil/knx_lon_ip.pdf

http://www.scantec.de/Fachartikel/Fachartikel-Standard/Ethernet-Feldbus-der-

Zukunft.pdf

http://www.eib-home.de/instabus_knx-eib_tipps_siemens_ip-schnittstelle_n146.htm

http://www.sarmac.com.br/download/Testes/varella/zigbee/04196332.pdf

http://www.zigbee.org/

www.osgi.org

http://it-republik.de/jaxenter/artikel/Das-OSGi-Framework-2221.html/

http://de.wikipedia.org/wiki/Osgi

http://de.wikipedia.org/wiki/Residential_Gateway

http://www.itwissen.info/

www.osgi.org/wiki/uploads/Markets/SuccessStory_ProSyst_SIEMENS.pdf

http://www.inhaus-zentrum.de/media/e4c40fcf1e96307

opus.bsz-bw.de/hdms/volltexte/2005/545/pdf/DA_Alb_Print.pdf

http://gsn.sourceforge.net/publications/

http://sourceforge.net/apps/trac/gsn/wiki/Introduction

http://lsirpeople.epfl.ch/salehi/papers/LSIR-REPORT-2006-006.pdf

http://www.elektronikpraxis.vogel.de/index.cfm?pid=880&pk=70571

Documents

Hauptseminar: Kopplungswerkzeuge für Feldbusse und ...midas1.e-technik.tu-ilmenau.de/~webkn/Abschlussarbeiten/Hauptseminarar... · kurz und beispielhaft auf die Kopplung von ZigBee