Abschlusspräsentation SS 2013wiki_sn/images/1/1c...17.06.2013 1 Forschungsseminar Sensornetze...

17.06.2013 1

Forschungsseminar Sensornetze

Abschlusspräsentation SS 2013

Rick Belitz, Frank Effenberger, Samuel Bohnet, Falco

Baumgärtel, Thomas Kühnel, Enrico Uhlig, Stefan Lorenz, Marcus Kupke, Markus Fischer

Betreuender Professor: Prof. Dr. Vogt

17.06.2013 2

Gliederung

• 1. Einführung (Nachtrag) 5 Min.

• 2. Gruppe Web Frontend 30 Min.

• 3. Gruppe CoAP 30 Min.

• 4. Gruppe Hardware 30 Min.

• 5. Regelverarbeitung 15 Min

• 6. Gruppe FHEM-802.15.4-Modul 30 Min.

• 7. Quellen

(140 Min.)

17.06.2013 3

1. Einführung (Nachtrag)

Treibende Kräfte im wissenschaftlichen Bereich:

• TU Ilmenau (intelligente Hausautomation),

• Universität der Bundeswehr in München

(intelligente Hausinstrumentierung,

Professur für Sensorik und Messsysteme)

• Universität Salzburg (Sicherheitsaspekte,

Institut für Computerwissenschaften,

Master für angewandte Informatik)

17.06.2013 4



• Fraunhofer Institut

(Materialfluss und Logistik,

Fabrikbetrieb und ~automatisierung)

• Technische Universität Wien

(Sicherheitsaspekte,

Institut für rechnergestützte Automation)

17.06.2013 5



• Arbeitskreis Gebäudeautomatisierung

und Smart Metering (gefördert durch

Bundesministerium für Wirtschaft

und Technologie)

• ETH-Zürich (Contiki-Projekt, CoAP)

17.06.2013 6


Treibende (proprietäre) Kräfte des Marktes:

• RWE (Smarthome)

• Symcon GmbH (IP-Symcon WebFront)

• eQ3-AG (Homematic / Homeputer)

17.06.2013 7


Treibende (proprietäre) Kräfte des Marktes:

• EZcontrol GmbH (EZcontrol)

• Marmitek BV (Marmitek)

17.06.2013 8

2. Gruppe Web Frontend

Gliederung:

• 1. Motivation

• 2. Zielstellung (präzisierte Aufgabenstellung)

• 3. Überblick/Infrastruktur

• 4. Lösungsweg

• 5. Risikoanalyse und nichtfunktionale Anforderungen

• 6. Allgemeine, funktionale Anforderungen und Use Cases

• 7. Abstrahierte funktionale Anforderungen

• 8. Technologische Betrachtungen

• 9. Betrachtung der Konkurrenzprodukte

• 10. Entwurf

• 11. Implementierung - aktueller Stand

• 12. Erkenntnisgewinn und Ausblick

17.06.2013 9

2.1 Motivation

• seit 2010 gehäufte Kommunikation von Dingen (Geräten, Sensoren, etc.)

im Internet: Das Internet der Dinge auf dem Vormarsch

• neben Paketverfolgung wichtige Rolle im Gesundheitswesen,

Werkstoffprüfung, Industrieautomation und Hausautomatisierung

• Hausautomatisierung geprägt durch starken Einfluss auf das private

Umfeld von Personen

17.06.2013 10

2.1 Motivation

• Forschungsseminar 'Sensornetze' greift Thematik des Internets der

Dinge auf, Kommunikation von Sensoren und Aktoren über das Internet

• in den letzten Semestern fand dabei ein Fokussierung auf die

Hausautomatisierung statt

• umfassende Anforderungsanalyse und für programmierunerfahrene

Nutzer bedienbares Web Frontend im Open Source Bereich nicht

vorhanden

17.06.2013 11

2.2 Zielstellung (präzisierte Aufgabenstellung)

Zielstellung des Teilgebietes ‚Web Frontend‘ ist es, ein nutzerfreundliches

Web Frontend für die Hausautomatisierung zu konzipieren. Als Grundlage

wurde dazu von Prof. Dr. Vogt der FHEM-Server vorgegeben.

• Nutzung für PC und Tablet (Smartphone)

• Open Source Projekt (keine Kosten)

• zukunftsfähiges Konzept zur Haussteuerung und Analyse von Daten

17.06.2013 12

2.2 Zielstellung (präzisierte Aufgabenstellung)

Dabei gilt es zeitgleich, Antworten auf folgende Fragen zu finden:

• Welche besonderen funktionalen sowie nichtfunktionalen

Anforderungen gelten im Bereich der Hausautomatisierung?

• Welche dieser Anforderungen lassen sich mit einem Web Frontend realisieren?

• Welche Eigenschaften hat ein nutzerfreundliches Web Frontend unter Berücksichtigung verschiedener Nutzertypen im Bereich der

Hausautomatisierung?

17.06.2013 13

2.3 Überblick/Infrastruktur

• Wo ist unser Ansatzpunkt?

Browser

Tablet/Smartphone

OSI-Schicht 7

17.06.2013 14

2.4 Lösungsweg

1. Kennenlernen der Konfiguration und des Aufbaus des FHEM Servers(Freundliche Hausautomatisierung und Energiemessung), Erstellung von Dummy-Modulen für Testdaten

2. Anforderungsanalyse (nichtfunktionale Anforderungen, Risikoanalyse, allgemeine, funktionale Anforderungen, Use Case Beispiele und abstrahierte Anforderungen für ein Web Frontend)

3. Technologische Betrachtungen (Perl/PHP, JS-Charting Bibliotheken, Client- und Serverlast, Floorplanerstellung, bereits vorhandene Lösungen am Markt)

4. Prototypischer Erstentwurf

5. Entwurf

6. Implementierung & Test

Browser(Client)

FHEM (Server)

Analyse des Aufbaus

Analyse der Konfiguration

17.06.2013 15

2.4 Lösungsweg

Alle Gedankengänge, Vorgehensweisen, Diskussionen, Sammlungen von Anforderungen und Betrachtungen sowie die Ergebnisse sind im Forschungsbericht des Teilgebietes Web Frontend des Sommersemesters 2013 zu finden.

• im Folgenden eine kurze Betrachtung des Dokumentes für:

o 2.5 Risikoanalyse und nichtfunktionale Anforderungen

o 2.6 Allgemeine, funktionale Anforderungen und Use Cases

17.06.2013 16

2.7 Abstrahierte funktionale Anforderungen

Allgemeine Funktionale Anforderungen

gefiltert abstrahiert

• Angestrebte Funktionalität des neuen Web Frontends • Priorisierung der Anforderungen in 4 Stufen (durch Farbe gekennzeichnet)

Endanwender

Admin

17.06.2013 17

2.8 Technologische Betrachtungen

PERL oder PHP?

PGM3

1. Vergleich der Basis Technologien

Vorgehensweise: • Analyse der Möglichkeiten an den Bereits bestehenden Web Frontends

Entscheidung:

• Sprache direkt für die Webentwicklung • meistverwendete Sprache auf Serverseite • sehr geringe Einarbeitungszeit • gute Wartbarkeit/Zukunftsfähigkeit

17.06.2013 18

2. Vergleich der Charting Möglichkeiten

Vorgehensweise: • Definition eines zeitgemäßen Chartings • Analyse der Möglichkeiten für das Charting

Entscheidungen: • alle 3 bisherigen Lösungen konnten nicht klar überzeugen

Charting-Bedingungen nicht zusammenhängend erfüllt

• kein schlankes JS-Framework • keine zeitgemäße Optik • keine ausgiebigen Interaktionsmöglichkeiten • keine Automatische Aktualisierung • keine Datenaggregation

Ergebnis: • Vergleich der JS-Frameworks • erste Eingrenzung der 18 JS-Frameworks (durch Charting Bedingungen) • 4 in der Endauswahl endgültige Entscheidung wurde vertagt


17.06.2013 19

3. Vergleich der Floorplan Möglichkeiten


• Forschung noch nicht weiter Vorangetrieben

• Aufgrund der Priorisierung aus der Anforderungsanalyse

FHEM eigene Lösung

17.06.2013 20

2.9 Betrachtung der Konkurrenzprodukte

• Erhalten eines Eindrucks von aktuellen Hausautomatisierungsfrontends

• Vorrange Betrachtung von Kommerziellen Lösungen

eigene Ideen und

Verbesserungsvorschlage

Extrahierung von Elementen

für unser eigenes Web

Frontend

RWE Smarthome Homematic

17.06.2013 21

Extrahierung von Elementen

für unser eigenes Web

Frontend

2.10 Entwurf – Layout grob

RWE Smarthome Homematic

eigene Ideen und

Verbesserungsvorschlage

Konkurrenzprodukte Anforderungen

technologische

Betrachtungen

Erster Entwurf für unser neues

Web Frontend

17.06.2013 22

Home Floorplan Steuerung

(A) A/E-Mode (A)

Username

Password

Logout

Einstellunge

n

(…)

Übersicht Raum 1

20 0

ON

OFF

Sensoren in Raum 1

• gleichzeitige Unterstützung von PC und Tablet

• gleich große Kacheln

• Die Funktionalität möglichst schon auf der Oberfläche bereitstellen für

schnellen Zugriff.

• Menü über Mausklick bzw. Touch ausklappbar

• Hauptansichten Oben, Feinsteuerung links

• Authentifizierung für den Admin-Modus

• Bei Klick auf einen Sensor erhält man das Diagramm mit den

Bedienelementen

• Kleine Diagrammvariante auch auf Oberfläche einbindbar (ca. 3

Einheiten)

Kamera x

Daily Temperatures in New York vs. San Francisco

17.06.2013 23

2.11 Implementierung – aktueller Stand

• Fortschritt noch nahe zu am Anfang

• Fokus liegt zunächst auf der Umsetzung der ersten

Anforderungen für den Endanwender

• Beibehaltung der im Vorfeld festgelegten

Priorisierungen

17.06.2013 24

2.12. Erkenntnisgewinn und Ausblick

Erkenntnisse: • Erkennen der besonderen funktionalen sowie nichtfunktionalen Anforderungen im Bereich der Hausautomatisierung

• Abstrahieren der für ein Web Frontend nötigen Anforderungen aus diesen

• Korrekte Trennung der Anforderungen für einen nicht erfahren Nutzer von denen eines Erfahrenen Nutzers

• Sinnvollste Technologische Basis • Beschaffenheit der Charting und Floorplan

Möglichkeiten • Aufbau einer zeitgemäßen

Hausautomatisierungsbedienoberfläche

Ausblick: • Verfeinerung der vorhanden Entwürfe • Die Implementierung der Definierten Anwendungsfälle

17.06.2013 25

Vielen Dank für ihre

Aufmerksamkeit!

17.06.2013 26

HTTP Server

FHEM (Server)

PC oder Tablet

2.

3.

1.

5.

xx. Entwurf – Architektur

4.

1. Nutzer Änderung oder AJAX Pooling 2. FHEM Befehl senden über Telnet (Port 7072) 3. Zurücksenden der Response in

XML/JSON/plaintext an HTTP Server 4. Parsen der FHEM Response im HTTP Server 5. Ergebnis an Client übermitteln

17.06.2013 27

3. Gruppe CoAP-Client

Gliederung:

1. Überblick/Infrastruktur

2. Fragestellung/Zielstellung

3. Lösungsweg

4. Systemanalyse

5. Protokolle und deren derzeitige Implementierungen

6. Anforderungsanalyse

7. Entwurf

8. Implementierung

9. Ergebnisse/Erkenntnisgewinn

17.06.2013 28

3.1 Überblick

17.06.2013 29

Wie kann es ermöglicht werden, dass sowohl Befehle des FHEM-Servers zum Sensorboard weitergeleitet werden, als auch eine Sensoransteuerung ohne FHEM (z.B. über Konsole) durchführbar ist?

3.2 Fragestellung/Zielstellung

17.06.2013 30

• Systemanalyse

• Analysieren der vorhandenen Protokolle sowie deren Implementierungen

• Anforderungsanalyse für den Client

• Entwurf und Realisierung einer Lösung

3.3 Lösungsweg

17.06.2013 31

• Physischer Server: Iltis (nur im HTW-Netz erreichbar, Debian-OS)

• FHEM-Server auf Iltis

3.4 Systemanalyse

17.06.2013 32

• Sensorknoten mit Contiki-OS

und Erbium CoAP

Server für die Kommunikation mit Sensoren

3.4 Systemanalyse

17.06.2013 33

• M2M Protokolle: MQTT und CoAP

• Message Queue Telemetry Transport - seit 1999 entwickelt (von IBM und Arcom - heute Eurotech)

• seit 2013 in OASIS-Standardisierung

• Fokus auf leichtgewichtige Kommunikation im Internet der Dinge

3.5 Protokolle + Implementierungen

17.06.2013 34

• M2M Protokolle: MQTT und CoAP

• Constrained Application Protocol seit 2010 entwickelt (von Sensinode, SkyFoundry und Pacific Gas & Electric + seit v4 Uni Bremen)

• IETF Standard, ständig weiterentwickelt

• Fokus auf leichtgewichtige Kommunikation im Internet der Dinge


17.06.2013 35

• Projekt basiert sensorseitig bisher auf CoAP

• CoAP ist bereits standardisiert

• Unterstützung der sensorseitig genutzten Übertragungsprotokolle 802.15.4 und 6LoWPAN

• Uni Bremen und ETH Zürich sehr aktiv


17.06.2013 36


17.06.2013 37

• Kommunikation mit FHEM Modul Datenaustauschformat: ||()

• Unterstützung der Kommunikation mit Sensorknoten (leichtgewichtiges Protokoll)

• Bereitstellen von zwei Einstiegspunkten zur Unterstützung der Kommunikation ohne FHEM

3.6 Anforderungsanalyse Client

17.06.2013 38

3.6 Anforderungsanalyse Client

• Mechanismen zur asynchronen Abarbeitung der Anfragen

• Berücksichtigung von zyklischen Abfragen (OBSERVE)

• Bereitstellen der Antwort für FHEM-Modul ||

17.06.2013 39

3.7 Entwurf

17.06.2013 40

3.8 Implementierung

• Aufbau des Californium Framework sehr modular und erweiterbar

• Verwendung der konkreten Implementierungen der Klasse Request (GETRequest, PUTRequest)

• GETRequest für DISCOVER und OBSERVE

17.06.2013 41

3.8 Implementierung

• Zuordnung Request-Response (getRTT()) für asynchrone Prozessierung

• für OBSERVE eigener Thread da permanente Abfrage einer Resource

• permanente Verbindung mit Socket-Client notwendig

17.06.2013 42

Eine Socket-Verbindung für FHEM Modul

Zweite Socket-Verbindung für weitere Anfragen

3.8 Implementierung Socket Server

17.06.2013 43

Kommunikation außerhalb des Iltis-Servers

• Iltis nutzt eigenes IPv6 Netzwerk

• ist nur über das HTW Netz erreichbar

• SSH Tunnel + IPv6 Tunnel (6to4) + Routing-Tabelle editieren

3.8 Implementierung

17.06.2013 44

• "Cooja" simuliert ein drahtloses Netzwerk von Sensorknoten (motes)

• bereits in Contiki integriert

• Test des Client mit simulierten Erbium Server und aktueller CoAP Implementierung

3.9 Implementierung testen

17.06.2013 45

• Wartung und Implementierung einer eigenen CoAP Implementierung zu aufwändig (Ergebnisse FS SS 12)

• Erbium Client (C) erwies sich als nicht verwendbar, da von Contiki abhängig

• Californium Framework (Java) als beste Alternative (Weiterentwicklung ETHZ)

3.10 Ergebnisse / Erkenntnisgewinn

17.06.2013 46

• Abfragen von 802.15.4 Modul können asynchron verarbeitet werden

• Abfrage ohne FHEM-Modul möglich

3.10 Ergebnisse / Erkenntnisgewinn

17.06.2013 47

• Anfragen außerhalb der Iltis-Umgebung (Copper-Plugin)

• Fehlerbehandlung und Fehlernachrichten für FHEM-Modul

3.11 Ausblick

17.06.2013 48


Aufmerksamkeit!

17.06.2013 49

4. Hardware

17.06.2013 50

4.1 Hardware

• drahtloses Sensornetz mit beliebig vielen Sensorknoten

• an jedem Sensorknoten diverse Sensoren (Temperatur, Luftdruck, -feuchtigkeit, Helligkeit,...)

• Ansprechen über CoAP, IPv6 • Betriebssystem Contiki auf den Sensoren, damit

fertige Implementierung Netzwerkstack, CoAP-Server, Routing-Funktionalität

17.06.2013 51

4.1 Übersicht

Anwendung CoAP CoAP

Darstellung

Sitzung

Transport UDP UDP

Vermittlung IPv6 6LoWPAN 6LoWPAN 6LoWPAN

Sicherungs Ethernet/WLAN

802.15.4 802.15.4 802.15.4

Bitübertragung

Anwender Border-

Router

Router Sensor-

knoten

17.06.2013 52

4.1.1 Aufgabenstellung

• Analyse der verschiedenen MAC/RDC-Implementierungen in Contiki

• Wahl und ggf. Erweiterung eines geeigneten Verfahren

• außerdem: platformspezifische Anpassung und Erweiterung des Contiki-Codes (Fehler beheben, Funktionen zum Ansprechen von Buttons, LEDs), Einrichten der Sensorknoten, anschließen von Sensoren

17.06.2013 53

4.1.3 MAC/RDC in Contiki

• MAC-Implementierung wird in Verbindung mit Radio Duty Cycling-Protokoll gewählt

• mit Radio Duty Cycling wird entschieden, wann der Microcontroller aktiv sein muss

• vorhandene RDC-Protokolle wurden untersucht und auf Stromverbrauch und Leistung untersucht

17.06.2013 54

4.1.3 Stromsparmodi

17.06.2013 55

4.1.3 ContikiMAC

• Sender schickt immer wieder Datenpaket, bis Empfang bestätigt wird, maximal aber für die Zeitdauer zwischen 2 Aufwachphasen

• Empfänger hört periodisch, ob gesendet wird, wenn Sendevorgang registriert wird, auf nächste Wiederholung warten und Empfang bestätigen

17.06.2013 56

4.1.3 Contiki X-MAC

• Sender schickt immer wieder Strobepaket, bis Empfang bestätigt wird, anschließend eigentliche Daten

• Empfänger hört periodisch, bestätigt empfangenen Strobe und wartet danach auf Daten

17.06.2013 57

4.1.3 NullRDC

• kein Duty Cycling, also bleiben Sender und Empfänger immer im Bereitzustand

• zumindest auf dieser Schicht kein Bedarf der Wiederholung von Paketen

17.06.2013 58

4.1.4 Vergleich der Verfahren

• Messen der Antwortzeit mittels ping-Befehl • Messen des Stromverbrauchs mit Oszilloskop

17.06.2013 59

4.1.4 Ergebnisse

• Batterielaufzeit für 2 Batterien à 1150 mAh • X-MAC könnte DeepSleep nutzen und damit

ähnliche Laufzeit wie ContikiMAC erreichen

• ungenaue Messung bei ContikiMAC, aufgrund sehr geringem Stromverbrauchs

NullRDC ContikiMAC Contiki X-

MAC

Stromverbrauch 16mA 0,48mA 4,8mA

Batterielaufzeit* ~6 Tage ~0,5 Jahre ~20 Tage**

Durchschnittliche Ping-Zeit 68ms 131ms 273ms

17.06.2013 60

4.1.4 Ergebnisse

• Aber: • ContikiMAC und X-Mac sind nicht mit

802.15.4 Standard kompatibel

• Untersuchung in nächstem Semester, wie standardkomformes Verfahren zum Stromsparen realisierbar ist

17.06.2013 61

4.1.4 Ergebnisse

• Sensorknoten als im Standard spezifizierte Reduced Function Devices -> empfangen nicht direkt Nachrichten sondern fragen bei Router an, Router sammelt weiterzuleitende Nachrichten

17.06.2013 62

4.1.4 Probleme

• AVR-Platform bei Contiki im Vergleich zu anderen Platformen schlecht gewartet

• daher zum Teil viele Probleme, das Betriebssystem überhaupt lauffähig zu machen

• aufwändige Fehlersuche, Vergleich mit anderen Platformen und Übertragen relevanter Änderungen

• daher viel Vorarbeit nötig

17.06.2013 63

4.1.4 CoAP-Server

• verwendet neuste CoAP-13 Version • Sensoren über Get abfragbar, oder

periodische Updates mittels Observe abbonierbar

• Sensoren mittels I2C an Microcontroller angeschlossen, derzeit SHT21(Temperatur, Luftfeuchtigkeit) und BMP085(Temperatur, Luftdruck)

17.06.2013 64

4.2 Pairing 4.2.1 präzisierte Aufgabenstellung

• ermöglichen von erstmaliger Verbindungsaufnahme (Pairing) von neuen

Sensoren und bestehendem Netz

• Berücksichtung von Besonderheiten

(Hardware und OS)

• Analyse von Contiki (Netzwerkstacks,

Protokolle, usw.)

17.06.2013 65

4.2 Pairing 4.2.2 Lösungsweg - Contiki/Netzwerkstacks

• Analyse von Contiki ("contiki/core/net") • Contiki besitzt 2 Netzwerkstacks o uIP

o Rime

17.06.2013 66

4.2 Pairing 4.2.2 Lösungsweg - uIP

• Entwicklung von Adam Dunkels • integriert in Contiki • minimaler Code und Speichernutzung

• Protokolle/Code: o ARP, SLIP, ICMP, TCP, UDP, ...

o Webserver, Telnetserver, DNS

• IPv4/IPv6 • 6LoWPAN, RPL, CoAP

17.06.2013 67

4.2 Pairing 4.2.2 Lösungsweg - Rime

• leichtgewichtige Alternative • Schichtsystem

rucb_send --> runicast_send --> stunicast_send_stubborn --> unicast_send --> broadcast_send --> abc_send --> rime_output --> NETSTACK_MAC.send

17.06.2013 68

4.2 Pairing 4.2.2 Lösungsweg - Hardware

• avr-atmega128rfa1

• Buttons ("contiki/core/dev/button-sensor.h") o #if PLATFORM_HAS_BUTTON

o nicht jedes Endgerät(Sensorknoten) muss einen Button haben!!!

• LEDs ("contiki/core/dev/leds.h") o #if PLATFORM_HAS_LEDS

o LEDs sollen den Status des Pairingmodus anzeigen

17.06.2013 69

4.2 Pairing 4.2.2 Lösungsweg - Adressen

• PAN-ID/Knoten-ID • MAC-Adresse • Rime-Adresse • IPv4/IPv6-Adresse

• Problem: o Netzwerkstacks nicht koexistent

o Adressen teilweise hardcoded

17.06.2013 70

4.2 Pairing 4.2.2 Lösungsweg - Pairing Protokoll

• Button aktiviert temporären Pairing-Modus o LED leuchtet durchgehend

o zeitliche Begrenzung, z.B. 120 Sekunden

o muss beidseitig aktiviert werden

• Sensor sendet Funksignal, dass er ins Netzwerk möchte(abhängig von verw. Adressen/Protokollen)

• Router/Border-Router empfängt und antwortet mit benötigten Daten

o setzen von: PAN-ID, IP-Adressen/Netzmasken, ...

17.06.2013 71

4.2 Pairing 4.2.3 Ergebnisse

• Discovery-Modus • Broadcast/Unicast mittels diverser Protokolle • Übermittlung verschiedener Adressen

17.06.2013 72

4.2 Pairing 4.2.4 Erkenntnisgewinn

• Kommunikation auf verschiedenen Schichten möglich

o Pairing mit unterschiedl. Protokollen möglich

• weitere Pairing Methoden/Kanäle denkbar o Kanäle (In-Band/ Out-of-Band): z.B.:

kabelgebunden

o andere Radiokanäle

o Methoden: Schlüsselplakette/Tastatur-Eingabe

17.06.2013 73

4.2 Pairing 4.2.5 Probleme

• umfangreicher, teils schlecht kommentierter Contiki-Code

• Teilaspekte von versch. Protokollen werden nicht unterstützt / sind nicht implementiert

• Plattformabhängigkeit schafft Probleme bei Hardware und Code

17.06.2013 74


Aufmerksamkeit!

17.06.2013 75

5. Regelverarbeitung 5.1 Aufgabenstellung

Betrachtung und Vergleich der

Regelverarbeitung in FHEM mit anderen

Systemen (IP-Symcon)

• Anforderungen • Betrachtung der Regelverarbeitung in FHEM • Vergleich mit anderen Systemen • Vorschläge für eine Verbesserung • Ergebnisse/Erkenntnisgewinn

17.06.2013 76

5. Regelverarbeitung 5.2 Anforderungen

• Steuerung von Aktoren über Sensoren • Festlegen von Bedingungen, bei deren

Eintreten vordefinierte Aktionen ausgeführt

werden (ggf. alternative Aktionen)

• zeitgesteuertes Auslösen von Aktionen • Regelverarbeitung sollte möglichst leicht

konfigurierbar sein

17.06.2013 77

5. Regelverarbeitung 5.3 Betrachtung der Regelverarbeitung in FHEM

FHEM-Weboberfläche

17.06.2013 78


• Befehle in der Kommandozeile o Eingabefeld zum direkten Ausführen von FHEM-

Befehlen

o Befehle in Detailansicht bearbeiten und Änderungen in Konfigurationsdatei „fhem.cfg“ speichern

• komplexe Regeln müssen in Perl implementiert werden o zeitgesteuerte Anweisungen

o Ausführung von Skripten, wenn bestimmte Ereignisse eingetreten sind oder Meßwerte empfangen wurden

17.06.2013 79


• Beispielregel o soll einen Befehl ausführen, sobald der angegebene

Sensor einen Funkbefehl übermittelt hat

o define Schalter1Notify notify

Schalter1 { if („%“ eq „off“) {

fhem(„set wz_Media off“) } }

• Nachteile o vergleichsweise komplizierte Perlsyntax muß

beherrscht werden

o Regeln per Hand oder alternativ direkt in der

Konfigurationsdatei zu formulieren

17.06.2013 80

5. Regelverarbeitung 5.4 Vergleich mit anderen Systemen

• Hexabus o verfolgt dezentralen Regelansatz

o Regelwerk über die einzelnen Knoten verteilt

o erfordert zusätzlichen Kommunikationsaufwand

• Zustandsgraph o formales Modell von Hexabus

o Automat aus Zuständen und Übergängen (Transitionen)

o erkennt Fehlübertragungen und kann Verläßlichkeit bei unerwar- teten Ausfällen erhöhen

17.06.2013 81


• Homeputer o ermöglicht Erstellung von Regeln und

Zeitabhängigkeiten über Makros

o über Programmiersprache mit Befehlen in deutscher Sprache oder menügeführt

17.06.2013 82


• Homeputer o ermöglicht Erstellung von Regeln und

Zeitabhängigkeiten über Makros

o über Programmiersprache mit Befehlen in deutscher Sprache oder menügeführt

17.06.2013 83

5. Regelverarbeitung 5.5 Vergleich mit IP-Symcon

• der Nutzer hat die Möglichkeit, PHP-Befehle mit Hilfe eines Editors zu einem Skript

zusammenzufügen, das sich manuell oder

ereignisgesteuert ausführen läßt

• Definition eines bestimmten Ereignisses o über graphische Oberfläche

o ohne tiefere Programmierkenntnisse

o beim Eintreten der Bedingungen oder zu

bestimmten Zeitpunkten gestartet

17.06.2013 84

5. Regelverarbeitung 5.5 Vergleich mit IP-Symcon

• Erstellung eines Ereignisses

17.06.2013 85

5. Regelverarbeitung 5.6 Vorschläge für eine Verbesserung

• IP-Symcon bevorzugt gegenüber FHEM die menügeführte Regelerstellung

• auf umständliche Formulierung von Quelltext kann verzichtet werden

17.06.2013 86

5. Regelverarbeitung 5.6 Vorschläge für eine Verbesserung

Prototyp

17.06.2013 87

5. Regelverarbeitung 5.7 Ergebnisse/Erkenntnisgewinn

17.06.2013 88

5. Regelverarbeitung 5.8 Quellenangaben

• Bildquellen o http://fhem.de/Heimautomatisierung-mit-fhem.pdf

o https://github.com/mysmartgrid/hexabus/wiki/Hexabus-Assembler

o http://www.contronics.de/download/homeputerCLBeschreibung.pdf

o http://www.ip-symcon.de/doc/IP-Symcon-Dokumentation-2.7.pdf

o http://www.ip-symcon.de/service/dokumentation/konzepte/ereignisse/

17.06.2013 89

6. FHEM-802.15.4-Modul

Wo ist unser Ansatzpunkt?

Bezeichnungen:

CoAP ... Constrained

Application

Protocol

URI ... Uniform Resource

Identifier

WSN ... Wireless Sensor

Network

WSNPHD ... WSN Physical

Device

17.06.2013 90

• Rückblick vorangegangenes FS-Semester (6.1)

• Zielstellung / Fragestellungen / Zuständigkeiten (6.2 -

6.4)

• Evaluation zur Umsetzung des CoAP-Clients (6.5)

• Erweiterung von FHEM zur Nutzung des 802.15.4

WPAN (6.6)

• Testumgebung (6.7)

• Kommunikation zwischen FHEM u. CoAP-Client (6.8 -

6.12)

• Ergebnisse / Erkenntnisgewinn (6.13)

• Vorführung

6. FHEM-802.15.4-Modul Gliederung

17.06.2013 91

6. FHEM-802.15.4-Modul 6.1 Rückblick vorangegangenes FS-Semester

Fragestellung: Können bestehende Hausautomationstechnologien (FS20, HM) in den Ansatz des FS-Projekts integriert werden?

17.06.2013 92

6. FHEM-802.15.4-Modul 6.1 Rückblick vorangegangenes FS-Semester

Ergebnisse:

• Konzept und lauffähiges Programm entwickelt

• Ein Integration kann erfolgen, ist aber sehr Aufwendig und stark Wartungbedürftig.

Übergang zum 2. FS-Semester:

• FHEM als Hausautomationsserver, damit entfällt weitere Betrachtung

• angeeignetes Wissen und gesammelte Erfahrungen hilfreich für neue Aufgabe

17.06.2013 93

6. FHEM-802.15.4-Modul 6.2 Zielstellung

Erweiterung des Hausautomation-Servers FHEM um Module zur Nutzung der 802.15.4-Module

• Erstellung eines Konzeptes • Diskussion des Konzeptes • Implementierung

17.06.2013 94

6. FHEM-802.15.4-Modul 6.3 Fragestellungen

CoAP ist ein energieoptimiertes Transferprotokoll und damit für drahtlose Sensornetze geeignet ...

Kann der freie Hausautomationsserver FHEM verwendet werden, um per CoAP, mit der Welt der 802.15.4-Sensorknoten zu interagieren?

• Wird der Ansatz bereits anderweitig verfolgt? • Wie kann die Kombination aus FHEM und CoAP

softwaretechnisch sinnvoll realisiert werden?

• Welcher Gewinn bzw. welche Beschränkungen ergeben sich daraus?

17.06.2013 95

• Evaluierung zur Umsetzung des CoAP-Clients

• Entwurf und Implementierung eines

FHEM-Moduls zum Anlegen,

Abfragen und Manipulieren

der 802.15.4-Sensoren /

Aktoren (als WSN-Modul

bezeichnet)

Ergebnisse

• Testumgebung zur Simulation des CoAP-Clients

• Erweiterung um ein weiteres Modul WSNPHD, zur

besseren Handhabung der

Socket-Kommunikation

• Festlegung eines Austauschformats zwischen

FHEM und dem CoAP-Client

Einarbeitung (FHEM, CoAP) | Ausarbeiten des Konzeptes | Diskussion

6. FHEM-802.15.4-Modul 6.4 Zuständigkeiten

MK MF

17.06.2013 96

6. FHEM-802.15.4-Modul 6.5 Evaluation zur Umsetzung des CoAP-Clients

• Kriterien o möglichst akuelle CoAP-Version

o CoAP-Bibliothek sollte den Standard weitreichend unterstützen

o Datenaustausch (FHEM CoAP-Client)

• Möglichkeiten o FHEM-Modul

o Wrapper

externe Anwendung als beste Option

17.06.2013 97

6. FHEM-802.15.4-Modul 6.6 Erweiterung von FHEM zur Nutzung des 802.15.4 WPAN

• Anforderungen o primär: Anlegen von Geräten; Get/ Set

o sekundär: Discover; Observe

• Einarbeitung in FHEM o anhand ähnlicher Module die Struktur der FHEM-

Implementierung nachvollziehen

o Implementations-Spezifika von FHEM beachten

• prototypische Implementierung o Realisierung der primären Kriterien

17.06.2013 98

6. FHEM-802.15.4-Modul 6.6 Erweiterung von FHEM zur Nutzung des 802.15.4 WPAN

eigenständiges Modul für Kommunikation

mit CoAP-Client notwendig

17.06.2013 99

6. FHEM-802.15.4-Modul 6.7 Testumgebung

• Python-Skript mit Socket-Verbindung zum WSN-Modul

• dient zum schnellen Testen verschiedener Entwurfsideen

• stetig an die neuen Anforderungen angepasst • verwaltet CoAP-Ressourcen in einer Textdatei

(URI, Wert)

17.06.2013 100

6. FHEM-802.15.4-Modul 6.8 Kommunikation zwischen FHEM u. CoAP-Client

• erste prototypische Umsetzung des WSN- Moduls zu unflexibel

• Trennung zwischen Kommunikation und Verwaltung der Sensorknoten

• Ausnutzung von FHEM-Funktionalitäten o Aufrechterhaltung der Verbindung zum CoAP-

Client

o Verwendung des Dispatchers damit Nachrichten dem richtigen Modul zugeordnet werden

• Testumgebung weiterhin nutzbar

17.06.2013 101

6. FHEM-802.15.4-Modul 6.9 WSNPHD

• als physisches FHEM-Modul (ähnlich des CUL Funk-Sticks)

• dient zum Setzen und Abfragen ressourcen- unabhängiger Befehle (discover, (pairing))

• polling des CoAP-Client, um indirekt angeforderte Nachrichten zu empfangen

• dadurch CoAP observe nachrüstbar • kann von anderen logischen FHEM-Modulen

verwendet werden

17.06.2013 102

6. FHEM-802.15.4-Modul 6.10 Austauschformat

• wird zur Kommunikation mit dem CoAP-Client benötigt

Anforderungen: • nur das nötigste übermitteln • alle CoAP-Nachrichten abdecken

|[=]?

get|[aaaa::221:2eff:ff00:1962]/temp1

set|[aaaa::221:2eff:ff00:1062]/lamp2=on

discover|[aaaa::221:2eff:ff00:1962]

17.06.2013 103

6. FHEM-802.15.4-Modul 6.11 Systemübersicht

17.06.2013 104

6. FHEM-802.15.4-Modul 6.12 Weg zum Sensorwert (get-Nachricht)

17.06.2013 105

6. FHEM-802.15.4-Modul 6.13 Ergebnisse / Erkenntnisgewinn

Ergebnis: Zwei lauffähige FHEM-Module, mit denen die Sensorknoten mittels CoAP abgefragt werden können.

Damit wurde das Ziel unserer Teilgruppe erreicht!

Wird der Ansatz bereits anderweitig verfolgt?

Die Arbeitsgruppe Rechnernetze des TZI der Universität

Bremen verfolgte mit dem Projekt SAHARA einen

ähnlichen Ansatz. Auf Basis einer CoAP-Implementierung

in Ruby und einem eigenen Webfrontend.

17.06.2013 106

6. FHEM-802.15.4-Modul 6.13 Ergebnisse / Erkenntnisgewinn

Beste softwaretechnische Realisierung? Als Ergebnis der Evaluierung wurde ermittelt, dass der CoAP-Client als externe Anwendung die beste Option darstellt.

Gewinn bzw. Beschränkungen? Durch die Integration von unseren Sensorknoten in FHEM können die Vorteile des Hausautomationsservers genutzt werden (Web GUI, Regelverarbeitung, Mischbetrieb mit Sensortechnologie anderer Hersteller (FS20, HM))

Zum Betrieb der 802.15.4-Sensorknoten im FHEM ist die Zwischenschicht des CoAP-Client zwingend erforderlich

17.06.2013 107

6. FHEM-802.15.4-Modul Vorführung

17.06.2013 108

8. Schlussbetrachtungen /

Diskussion

Diskussion

17.06.2013 109

8. Quellen

• http://de.wikipedia.org/wiki/Internet_der_Dinge - 04.05.2013

• http://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdf - 04.05.2013

• http://www.fhemwiki.de/wiki/FHEM - 04.05.2013

• http://www.comnets.uni-bremen.de/itg/itgfg521/aktuelles/fg-workshop-29092011/ITG_HH_thomas_poetsch.pdf - 25.04.2013

• http://tools.ietf.org/html/draft-ietf-core-coap-13 - 22.04.2013

• Forschungsbereiche:

• http://www.hsu-hh.de/researchdb/index_pEvNWCpZtgNojGkx.html

• https://www.tu-ilmenau.de/it-kn/forschung/forschungsgebiete/intelligente-hausautomation/

http://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www2.htw-dresden.de/~jvogt/forschungsseminar/ps-00-organisation.pdfhttp://www.hsu-hh.de/researchdb/index_pEvNWCpZtgNojGkx.htmlhttp://www.hsu-hh.de/researchdb/index_pEvNWCpZtgNojGkx.htmlhttp://www.hsu-hh.de/researchdb/index_pEvNWCpZtgNojGkx.htmlhttp://www.hsu-hh.de/researchdb/index_pEvNWCpZtgNojGkx.html

17.06.2013 110

8. Quellen

• http://forschung.unibw-muenchen.de/papers/ni2jleszggk1a5pcmxj9gf5lh4inz3.pdf

• http://softwareresearch.sbg.ac.at/fileadmin/src/docs/teaching/SS11/SaI/ulschrit_Seminararbeit_Sec-in-BAS_07-2011.pdf

http://forschung.unibw-muenchen.de/papers/ni2jleszggk1a5pcmxj9gf5lh4inz3.pdfhttp://forschung.unibw-muenchen.de/papers/ni2jleszggk1a5pcmxj9gf5lh4inz3.pdfhttp://forschung.unibw-muenchen.de/papers/ni2jleszggk1a5pcmxj9gf5lh4inz3.pdfhttp://forschung.unibw-muenchen.de/papers/ni2jleszggk1a5pcmxj9gf5lh4inz3.pdf

17.06.2013 111

8. Quellen

Bilder

• http://image.made-in-china.com/2f0j00aeTtnEZsgiqo/Cool-Computer-Case.jpg

• http://mobilspionage.de/wp-content/uploads/2012/09/handyortung-im-internet.jpg

• http://www.pearl.de/Presse/PX-3495_1_simvalley_MOBILE_Dual-SIM-Smartphone_SP-140_Android_4.0.jpg

• http://www.quinta.biz/uploads/product_pic/product_37/37_1.jpg

• http://a2a.blogsport.de/images/RFID_Chip.jpg

• http://www.haus-automatisierung.de/images/produkte/i10/104279-HomeMatic-Aussen-Bewegungsmelder-1.jpg

• http://forum.fhem.de/index.php?t=getfile&id=1354&private=0

17.06.2013 112

8. Quellen

• http://www.test232.com/wp-content/uploads/2013/03/EQ3-76923-HomeMatic-Temperatur-Feuchte-Sensor-ausen-HM-WDS-OTH-picture-1-418-e1362485992360.jpg

• http://www.elektriker.org/files/2011/09/Indirekte-Beleuchtung.jpg

• http://www.smarthome-guide.de/wp-content/uploads/2013/02/smarthome-debitel-mobilcom.png

• http://www.cis.uab.edu/saxena/device_pairing/images/mechanism.JPG

• http://www.senslab.info/wp-content/uploads/2013/01/contiki.png

• http://vis.uky.edu/~cheung/courses/ee586/Lecture%2039/data/images/img43.jpg

17.06.2013 113

Übersicht

Date post:	11-Feb-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Abschlusspräsentation SS 2013wiki_sn/images/1/1c...17.06.2013 1 Forschungsseminar Sensornetze...

Documents