Sensornetze auf Basis von 6LoWPAN und Contikiwiki_sn/images/e/e9/FoS... · Alexander Gräb...

transcript

Alexander Gräb 26.01.2017

Sensornetze auf Basis von 6LoWPAN und Contiki

Abschlusspräsentation zum Forschungsseminar

Alexander Gräb Sensornetze auf Basis von 6LoWPAN und Contiki 26.01.2017Seite 2

1. Zielstellung

2. Verwendete Hard- und Software

3. Ergebnisse des ersten Semesters

4. Ergebnisse des zweiten Semesters

5. Ausblick

Gliederung

Zielstellung

1. Zielstellung

Zielstellung

● Contiki 3.0 auf gegebener Hardware zum Laufen bringen

– Ist die Verbindungsqualität unter ContikiMAC damit besser (als unter Contiki 2.7)?

● Funktionierendes Test-Netzwerk aufbauen

● Energieverbrauch mit Contiki 3.0 und ContikiMAC ermitteln

– Mit 8 MHz und 16 MHz CPU-Takt

● Energieverbrauch optimieren

Verwendete Hard- und Software

2. Verwendete Hard- und Software

Hardware Funkmodul deRFmega128 von dresden elektronik● 8-Bit Mikrocontroller ATmega128RFA1 von Atmel● integrierte ZigBee und IEEE 802.15.4 Funkeinheit● CPU bis 16 MHz● 128 KB ROM (Flash-Speicher)● 16 KB Arbeitsspeicher

Node (Ansicht von oben)● deRFnode Board + deRFmega128 Funkmodul● 2 Buttons, 3 LEDs● Temperatur-, Helligkeits- und Beschleunigungs-Sensor● USB-Schnittstelle (USB-zu-Seriell-Interface + Stromversorgung)● JTAG-Programmier-Schnittstelle● Batteriefach für 3 R6 Batterien/Akkus

Node (Ansicht von unten mit Batteriefach)

Border-Router● Breakout-Board + deRFmega128 Funkmodul● Übergang vom drahtlosen IEEE 802.15.4

Netzwerk in anderes Computer-Netzwerk

Software

● Contiki OS

● Betriebssystem für Mikrocontroller

● Geeignet für IoT-Anwendungen

– kompletter Netzwerk-Stack

– Multithreading

– ...

● Open-Source-Software (BSD-Lizenz)

● Geschrieben in C

● Version 1.0 erschien 2003, aktuelle Versionsnummer ist 3.0

● Webseite: http://www.contiki-os.org/

● Quellcode auf GitHub: https://github.com/contiki-os/contiki

Ergebnisse des ersten Semesters

3. Ergebnisse des ersten Semesters

● Contiki 3.0 und ContikiMAC wurden zum Laufen gebracht

● Aber Verbindungsqualität immer noch sehr schlecht

● diverse Verbesserungen im Contiki-Quellcode behoben das Problem

● Verbindungsqualität mit ContikiMAC jetzt fast so gut wie ohne

– ~95 Meter im Freien

– ~50 Meter in Gebäuden mit starken Störquellen (WLAN, Relektion, …)

– Ping-Verluste in Gebäuden, selbst durch mehrere Wände, << 10%

● Energieverbrauch wurde in vorherigen Semestern bereits analytisch bestimmt (anhand eines Oszilloskop-Diagramms)

– Nur für den Idealfall und nur grobe Annäherung

➔ Numerische Methode, welche auf Oszilloskop-Daten angewandt wird, wurde entwickelt

● Ergebnisse der Messungen des StromverbrauchsContiki ContikiMAC CPU-Takt Mittlerer Strombedarf Betriebsdauer mit

1900 mAh Akku

3.0 deaktiviert 8 MHz 22,28 mA 3,48 Tage

3.0 deaktiviert 16 MHz 24,19 mA 3,27 Tage

3.0 aktiviert 8 MHz 1,02 mA 79,57 Tage

Ergebnisse des zweiten Semesters

4. Ergebnisse des zweiten Semesters

● Zielstellung

– Energiebedarf weiter optimieren

● Andere Channel-Check-Raten ausprobieren usw.

– Funktionierendes Test-Netzwerk

Energiebedarf weiter optimieren

● Idee hinter RDC-Mechanismen wie ContikiMAC

– Funkeinheit ist oft größter Verbraucher (macht ca. 2/3 des Gesamtverbrauchs bei der im Forschungsseminat verwendeten Hardware aus)

➔ Funkeinheit bleibt die meiste Zeit deaktiviert und wird nur zyklisch für einen sehr kurzen Augenblick aktiviert

– Die Channel-Check-Rate [Hz] gibt an, wie oft die zyklische Aktivierung erfolgt (z. B. 8 Hz → 8 mal in der Sekunde oder alle 125 ms)

Prinzipielle Funktionsweise von ContikiMAC(Quelle: Paper „The ContikiMAC Radio Duty Cycling Protocol“ von Adam Dunkels, Dezember 2011)

● Nach einigen Verbesserungen nur noch ca. 1/3 des Strombedarfs unter ContikiMAC als vorher

● Verringerung der Channel-Check-Rate führt zu weiterer Verbesserung

● Strombedarf bei verschiedenen Channel-Check-Raten (CCR) und 16 MHz CPU-Takt

Idealfall Realität

Strombed. Betriebsdauer (1900 mAh Akku)

8 Hz 0,31 mA 255,38 Tage 0,33 mA 239,9 Tage

4 Hz 0,18 mA 439,81 Tage 0,26 mA 304,49 Tage

2 Hz 0,11 mA 719,7 Tage 0,17 mA 465,69 Tage

● Warum ist Strombedarf in Realität so viel höher?

➔ Routing-Protokoll RPL ist häufig aktiv

– RPL = Routing Protocol for Low power and Lossy Networks

– Sniffing im Test-Netzwerk mit einem Border-Router und drei Nodes ergab: Es wurden > 16000 RPL-Pakete gesendet

– RPL-Verkehr steigt mit zunehmender Anzahl an Geräten

Test-Netzwerk

● Einfaches Test-Netz im ersten Semester funktionierte bereits sehr gut

– Stabilität des Test-Netzwerkes wurde hauptsächlich mit Ping- und Constrained Application Protocol (CoAP)-Anfragen getestet

– Forderung bei Ping-Anfragen nach Paketverlusten << 10% konnte erfüllt werden

– Auch CoAP-Anfragen funktionierten sehr zuverlässig

● Jetzt: Aufbau eines komplexeren Test-Netzwerkes

Test-Netz im ersten Semester

Node (mit Routing-Funktionalität)

Border-Router

Sende-/Empfangs-Radius

Test-Netzwerk

● Alle 15 Minuten wurde die aktuelle Temperatur via CoAP abgefragt

● Abfragen gingen von Computer an Border-Router aus

● Erschwerend kam hinzu, dass sich die Ziel-Node in einem metallenen Briefkasten befand und mehrere Wänder überwunden werden mussten

Schematischer Aufbau des Test-Netzwerkes

Realer Aufbau des Test-Netzwerkes

Briefkasten aus Metall

Test-Netzwerk

● Ergebnis

– Test-Netz organisiert sich automatisch so, dass Node als Router fungierte (keine Anpassung der Software war notwendig)

– Test-Netzwerk lief stabil (> 90% aller CoAP-Anfragen erfolgreich)

Schematischer Aufbau des Test-Netzwerkes

Realer Aufbau des Test-Netzwerkes

Briefkasten aus Metall

Ausblick

5. Ausblick

Ausblick

● Energiebedarf noch weiter senken

– Betriebsdauer >= 10 Jahre möglich?

– Cannel-Check-Raten < 2 Hz?

– Datenverkehr des Routing-Protokolls RPL reduzieren

● Größere Test-Netzwerke mit mehr Hardware

Vielen Dank für Ihre Aufmerksamkeit!

Zeit für Fragen

Ermitteln des Strombedarfs

● Spannungsabfall an Shunt-Widerstand wird mit Oszilloskop gemessen

● Strom, der durch Shunt-Widerstand fließt, lässt sich ermitteln

– Strom durch Shunt-Widerstand = Strom durch RLOAD (Node)

– I = Ushunt

/Rshunt

(Ushunt

wird gemessen, Rshunt

ist bekannt)

● Oszilloskop-Diagramm über eine Sekunde @ 8 Hz Channel-Check-Rate

● Analytische Bestimmung des Strombedarfs anhand des Oszilloskop-Diag.

(Quelle: Zwischenbericht zum Forschungsseminar Sensornetze Sommersemester 2016 von Kai Richter und Alexander Gräb)

● Analytische Methode liefert Ergebnis nur für Idealfall und in grober Annäherung

Idealfall Realität

● Numerische Methode

– Um Realität wieder zu spiegeln Messung über ~30 Minuten

Oszilloskop

Time,Channel A(s),(mV)

0.00000000,3.937008000.00000100,0.000000000.00000200,3.937008000.00000300,0.000000000.00000400,3.937008000.00000500,0.000000000.00000600,0.000000000.00000700,0.000000000.00000800,0.000000000.00000900,0.000000000.00001000,3.937008000.00001100,0.000000000.00001200,3.93700800...

CSV-Daten

∫Programm für numerische Integration

File is: data.csvRead 1000004 lines from file data.csv.Min. 0.00025 mAMax. 28.740156 mAAvg. 0.311457731194 mA

Ergebnisse

Verwendete Hard- und Software - Zusatz

Hardware

Das Zusammenspiel der hardware

deRFnode

deRFmega128-22A00

deRFbreakout Board

deRFmega128-22A00

UART-Bridge

ATmega128RFA1ATmega128RFA1

Rechner als Router

Internet

IEEE 802.15.4 &

6LoWPAN

Ergebnisse des ersten Semesters - Zusatz

● Features, welche in vorherigen Semestern in Contiki 2.x implementiert wurden, wurden wieder übernommen und teilweise verbessert

● Vollkommen neue Features wurden in Contiki 3.0 implementiert

Ausgabe von Debug-Meldungen über USB-Schnitstelle

Radio-On/Off-Indicator

Incoming Ping-Request-Indicator

Neighbour-Found-Indicator

Ergebnisse des zweiten Semesters - Zusatz

Implementierung weiterer Features in Contiki 3.0

Systemlaufzeit (Uptime)URL: coap://sensors/rssi

CPU-TemperaturURL: coap://sensors/cpu_temp

Spannung der AkkusURL: coap://sensors/battery

Beschleunigungs-SensorURL: coap://sensors/acceleration

Temperatursensor-SensorURL: coap://sensors/tmp102_temp

Helligkeits-SensorURL: coap://sensors/luminosity

Signalstärke des zuletztempfangenen DatenpaketsURL: coap://sensors/rssi

ContikiMAC radio alway onGedrückte Taste während des Boot-Vorgangs bewirkt, dass die Funkeinheit immer aktiv bleibt.

Sensornetze auf Basis von 6LoWPAN und Contikiwiki_sn/images/e/e9/FoS... · Alexander Gräb...

Documents