Hochschule für Technik und Wirtschaft Dresden - Contiki-OSwiki_sn/images/9/91/Master... · 2016. 10. 26. · Theorie Protothreads Interprozess-Kommunikation Beispielprojekt MAC-Implementierung

Contiki-OS

Angelos Drossos Hermann Lorenz

Hochschule für Technik und Wirtschaft DresdenMaster Angewandte Informationstechnologien

Sensornetze

26. November 2012

Übersicht

Einführung in Contiki

ImplementationsaspekteTheorieProtothreadsInterprozess-KommunikationBeispielprojekt

MAC-ImplementierungNet Stack LayersAufgaben und ImplementationenNachrichtenaustausch

Dynamic Module LoadingAnforderungen und UmsetzungenVom Empfang bis zur AusführungAusblick

Schlussbemerkungen

2/39

Was ist Contik-OS?

I Open-Source-Betriebssystem (3-Klausel-BSD-Lizenz)I für

I eingebettete, batteriebetriebene SystemeI Netzwerkgeräte

I bereits auf verschiedenste Hardwareplattformen portiert

»Open Source Operation System for the Internet of Things«

3/39

Was ist Contik-OS?

I Open-Source-Betriebssystem (3-Klausel-BSD-Lizenz)I für

I eingebettete, batteriebetriebene SystemeI Netzwerkgeräte

I bereits auf verschiedenste Hardwareplattformen portiert

»Open Source Operation System for the Internet of Things«

3/39

Welche Funktionalität bietet Contiki?

I Netzwerkunterstützung: UDP, TCP, HTTP, 6LoWPAN,RimeStack, RPL, CoAP

I ProtothreadsI Speicherverwaltung:

I memory block allocation (memb)I managed memory allocator (mmem)

I Dateisystem: CoUee Wash Vle system (CFS)I Programme zur Laufzeit nachladen→ »Dynamic Module

Loading«I Tools:

I Netzwerk-Simulation durch den Cooja SimulatorI Überwachung des Energieverbrauchs (EnergEst-Modul)

4/39

Wie ist Contiki aufgebaut?

Applikationen

ServicesWebserver FTP Telnet . . . eigene

KernProcess Timer Netzwerk ELF-Loader . . .

TreiberPlattform CPU

Tools

5/39

Übersicht





Schlussbemerkungen

6/39

TheorieAnforderungen

Strom Knoten sollen Jahre mit einer Batterieauskommen

Speicher nur wenige KB RAM

Programmierung einfache ProgrammierungNetzwerkprotokolle sind kontrollWuss- und nichtzustandsorientiert

7/39

TheorieSystemarchitekturen

ereignisgesteuertnur ein Stack→ geringer Speicherbedarf

Programmierung als Zustandsmaschine notwendig

threadorientiertintuitivere Programmierung, keine Zustandsmaschinennotwendig

hohe Speicherreservierung je Thread

8/39

ProtothreadsUmsetzung der Makros (schematisch)

QuellcodePROCESS_THREAD(xyz){

int i = 0;PROCESS_BEGIN();

do_something();PROCESS_WAIT();

do_something_else();PROCESS_END();

}

ausgewertete DeVnesint process_xyz(int marke){

int i = 0;switch(marke){case 0:

do_something();return 123;

case 123:do_something_else();return PROCESS_DONE;

}}

CPU-Abgabe return mit nächster SprungmarkeCPU-Zuweisung Funktionsaufruf mit Sprungmarke

I lokale Variablen verlieren Werte beiKontextwechsel

I globale Variablen oder static nutzen

9/39






}





}}



I globale Variablen oder static nutzen

9/39






}





}}



I globale Variablen oder static nutzen9/39

Prozesse und Protothreads

Prozess ist einzelner Protothread

Protothread I leichtgewichtiger ThreadI kein eigener StackI kooperatives Multitasking

wait Protothread gibt Kontrolle ab, bis Eventeintritt

yield Protothread gibt Kontrolle abI keine direkte Switchanweisung

10/39

Kommunikation zwischen ProzessenEvents und Polling

Event Signal an einen Prozess in die Event Queue einordnen

Event-Queue. . .

Prozess A

Prozess B Prozess C

process_post(prozessC)

process_post_synch(prozessC)

Poll I jeder Prozess besitzt Polling FlagI vor der Event Queue werden alle Polling Flags geprüftI bei gesetzten Polling Flag wird der Polling Handler

ausgeführt

11/39



Event-Queue. . .

Prozess A

Prozess B Prozess C




ausgeführt

11/39



Event-Queue. . .

Prozess A

Prozess B Prozess C




ausgeführt

11/39



Event-Queue. . .

Prozess A

Prozess B

Prozess C




ausgeführt

11/39



Event-Queue. . .

Prozess A

Prozess B Prozess C




ausgeführt

11/39



Event-Queue. . .

Prozess A

Prozess B Prozess C




ausgeführt

11/39

Kommunikation zwischen ProzessenEvents und Polling im Einsatz

Event-Queue. . .

Prozess A

Prozess A Polling-Handler

ISR

process_poll(prozessA)

process_post(prozessA)

12/39


Event-Queue. . .

Prozess A


ISR



12/39


Event-Queue. . .

Prozess A


ISR



12/39


Event-Queue. . .

Prozess A


ISR



12/39

Kommunikation zwischen ProzessenSemaphore und Protosockets

Semaphore zur Synchronisation der ProtothreadsI PT_SEM_INIT(s, c)I PT_SEM_WAIT(pt, c)I PT_SEM_SIGNAL(pt, c)

Protosockets ZugriU auf das uIP-Interface, analog zu BSD-SocketsI PSOCK_INIT(. . . )I PSOCK_SEND_STR(. . . )I PSOCK_READBUF(. . . )I . . .

13/39

Beispielprojekt

RepositoryI klonen

git clone https://github.com/contiki-os/contiki

I anpassenI contiki/cpu/avr/Makefile.avr

I avrdude → sudo avrdude

I platform/avr-atmegarfa1/Makefile.avr-atmegarfa1I AVRDUDE_PROGRAMMER=jtag2 → dragon_jtagI AVRDUDE_PORT=usb:00B000000D79 → usb

ProjektI Projektverzeichnis erstellen

mkdir -p project/hellosworld

I Bibliotheken des Sensorterminalboards kopierenconfig.h, usb.c, usb.h, io_access.c, io_access.h

und io_access_ext.h

14/39

Beispielprojekthellosworld.c

hellosworld.c#include "contiki.h"#include "usb.h"#include <string.h>

/*-------------------------------------------------------*/PROCESS(hellosworld_process, "HeLLo’s World process");AUTOSTART_PROCESSES(&hellosworld_process);/*-------------------------------------------------------*/PROCESS_THREAD(hellosworld_process, ev, data){

char * str = "HeLLo’s World!\n";int i;PROCESS_BEGIN();

usb_init();for(i = 0; i < strlen(str); ++i)

usb_putc_std(str[i], stdout);

PROCESS_END();}/*-------------------------------------------------------*/

15/39

BeispielprojektMakeVle

MakeVleCONTIKI_PROJECT = hellosworldCONTIKI_SOURCEFILES += io_access.c usb.cTARGET = avr-atmega128rfa1

all: $(CONTIKI_PROJECT)

program: $(CONTIKI_PROJECT).$(TARGET).u.PHONY: program

CONTIKI = ../..include $(CONTIKI)/Makefile.include

Verzeichnisbaum

contiki

project

hellosworld

config.c

hellosworld.c

io_access.c

io_access.h

io_access_ext.h

usb.c

usb.h

Makefile

Makefile.include

I make program

16/39

Übersicht





Schlussbemerkungen

17/39

Contiki Net Stack layersDer Aufbau

1. Radio (Hardware)

2. Radio Duty Cycling (RDC)

3. Framer

4. Medium Access Control (MAC)

5. Network

18/39

Contiki Net Stack layersDie KonVguration

core/net/netstack.hextern const struct network_driver NETSTACK_NETWORK;extern const struct rdc_driver NETSTACK_RDC;extern const struct mac_driver NETSTACK_MAC;extern const struct radio_driver NETSTACK_RADIO;extern const struct framer NETSTACK_FRAMER;

contiki-conf.h (Platform, Projekt)#define NETSTACK_CONF_MAC nullmac_driver#define NETSTACK_CONF_RDC sicslowmac_driver#define NETSTACK_CONF_FRAMER framer_802154#define NETSTACK_CONF_RADIO rf230_driver#define NETSTACK_CONF_NETWORK sicslowpan_driver

19/39

Contiki Net Stack layersDie KonVguration

core/net/netstack.hextern const struct network_driver NETSTACK_NETWORK;extern const struct rdc_driver NETSTACK_RDC;extern const struct mac_driver NETSTACK_MAC;extern const struct radio_driver NETSTACK_RADIO;extern const struct framer NETSTACK_FRAMER;

contiki-conf.h (Platform, Projekt)#define NETSTACK_CONF_MAC nullmac_driver#define NETSTACK_CONF_RDC sicslowmac_driver#define NETSTACK_CONF_FRAMER framer_802154#define NETSTACK_CONF_RADIO rf230_driver#define NETSTACK_CONF_NETWORK sicslowpan_driver

19/39

Radio – layerAufgaben und Implementationen

AufgabenI Kommunikation mit dem FunksensorI CPU-abhängige ImplementationI Bestimmte Funktionalität auf die Hardware umlegen

(Auto-ACK)

Implementationen (CPU)I NullRadioI rf230 (AVR)I cc2430_rf (cc2430)I cc2530_rf (cc253x)I stm32w (stm32w108)I Contiki MACA (mc1322x)

20/39

Network – layerAufgaben und Implementationen

AufgabenI Schnittstelle zu den Applikationen (Empfangen und Versenden

von Nachrichten)I Interagiert mit dem MAC–layer

ImplementationenI RIMEI SicsLowPAN

21/39

Radio Duty Cycling – layerAufgaben und Implementationen

AufgabenI schaltet den Radio Transceiver so oft wie möglich ausI sorgt damit für energie-eXzientes Arbeiten

ImplementationenI ContikiMAC (Low-Power-Listening, LPL)I LPP (Low-Power Probing)I X-MACI CX-MAC (Compatiblity X-MAC)I SicsLowMAC (no Radio Cycling)I NullRDC (no Radio Cycling)I NullRDC No Framer (no Radio Cycling)

22/39

Framer – layerAufgaben und Implementationen

AufgabenI Erzeugen von Frames zum VersendenI Parsen von Frames beim EmpfangenI Wird vom RDC–layer aufgerufen und legt die bearbeiteten

Frames in einen Packet-BuUer

ImplementationenI Framer 802.15.4I Framer NullMAC

23/39

MAC – layerAufgaben und Implementationen

AufgabenI empfängt eingehende Packete vom RDC layerI benutzt den RDC layer, um Packete zu versendenI sorgt dafür, dass Packete erneut gesendet werden, sofern der

RDC layer eine Kollision detektiert hat

ImplementationenI CSMA (Carrier Sense Multiple Access)I TDMA (Time Division Multiple Access)I CTDMA (Carrier / Time Division Multiple Access)I RIME UDPI NullMACI SicsLowMAC (AVR, nutzt nicht RDC-Protokoll)

24/39

NachrichtenaustauschEintreUende Nachricht

Network

RDC

MAC

input

input

input

Nachricht

Framerparse

ISR

input

Radio

PacketBuUer

APP

Callback / TCP/IP

25/39

NachrichtenaustauschAusgehende Nachricht (TCP/IP)

Network

RDC

MAC sendpacket

Nachricht

Framercreate

ISR

Radio

PacketBuUer

APP

packetsent

outputTCP/IP

set outputtcpip output

sendpacket

sendpacket ?

outputCallback

26/39

NachrichtenaustauschAusgehende Nachricht (RIME)

NetworkRIME

RDC

MAC sendpacket

Nachricht

Framercreate

ISR

Radio

PacketBuUer

APP

packetsent

rimeoutput

abc send

sendpacket

sendpacket ?

recvCallback

RIMEabc

abc sent

27/39

Übersicht





Schlussbemerkungen

28/39

Dynamic Module LoadingEinführung

AnwendungI an schwer zugänglichen Orten (Daten sammeln, extern

auswerten, Software anpassen)I Korrektur von SoftwarefehlernI Schließen von SicherheitslückenI Erweiterung der Funktionalität: spezielle Applikationen

situationsbedingt (temporär) ausführen

ProblemstellungI genügend Speicher zum Zwischenspeichern des »Programms«I energieaufwändige Übertragung (Verkürzung der

Batterielaufzeit)

LösungeXzientes Verteilen der neuen »Softwareversion«

29/39






Batterielaufzeit)


29/39






Batterielaufzeit)


29/39

Dynamic Module LoadingAnforderungen

AnforderungenI Das ganze System ist austauschbar.I Nur ein Modul ist zur Laufzeit nachzuladbar und ausführbar.I Wenn ein kleiner Codeabschnitt geändert werden soll, dann

soll nicht das komplette System neu aufgespielt werden.I niedriger Energieverbrauch sowohl bei der Übertragung als

auch Ausführung

Methoden der UmsetzungI Full-Image ReplacementI DiUerential Image ReplacementI Virtual MachinesI Dynamic Operation Systems

30/39

Dynamic Module LoadingAnforderungen

AnforderungenI Das ganze System ist austauschbar.I Nur ein Modul ist zur Laufzeit nachzuladbar und ausführbar.I Wenn ein kleiner Codeabschnitt geändert werden soll, dann

soll nicht das komplette System neu aufgespielt werden.I niedriger Energieverbrauch sowohl bei der Übertragung als

auch Ausführung


30/39

Dynamic Module LoadingUmsetzungsarten


Lösungen in bekannten BetriebssystemenI TinyOSI SOS (Weiterentwicklung 2008 eingestellt)I Contiki-OS

31/39

Dynamic Module LoadingVom Empfang bis zur Ausführung des Moduls

Schritte vom Empfang bis zur Ausführung1. Empfangen

2. EEPROM beschreiben

3. »Link & Relocation«

4. Flash ROM beschreiben

⇒ Das Programm ist ausführbar.

Technologien im ContikiI ELFI CELF (compact ELF)I Java Virtual MachineI CVM (Contiki Virtual Machine)I (und weitere)

32/39


Schritte vom Empfang bis zur Ausführung1. Empfangen

2. EEPROM beschreiben

3. »Link & Relocation«

4. Flash ROM beschreiben

⇒ Das Programm ist ausführbar.

Technologien im ContikiI ELFI CELF (compact ELF)I Java Virtual MachineI CVM (Contiki Virtual Machine)I (und weitere)

32/39


Notwendige Schritte in den verschiedenen Technologien

ELF CELF Java VM CVM

Empfangen ! ! ! !

EEPROM beschreiben ! !

Link & Relocation ! !

Flash ROM beschreiben ! ! !

Energie-Verbrauch [mJ]


Empfangen 29 12 22 2EEPROM beschreiben 2 1Link & Relocation 3 3Flash ROM beschreiben 1 1 5

33/39


Notwendige Schritte in den verschiedenen Technologien


Empfangen ! ! ! !

EEPROM beschreiben ! !

Link & Relocation ! !

Flash ROM beschreiben ! ! !

Energie-Verbrauch [mJ]


Empfangen 29 12 22 2EEPROM beschreiben 2 1Link & Relocation 3 3Flash ROM beschreiben 1 1 5

33/39


Ausführungszeit (einfaches Programm)

Native Java VM CVM

Ausführungszeit [ms] 0.479 1.79 0.845Energieverbrauch [µJ] 0.54 2.0 0.95

Energieverbrauch [µJ] 36 000 27 000 2 000bei der Übertragung

Ausführungszeit (komplexes Programm)

Native Java VM CVM

Ausführungszeit [ms] 0.67 65.6 58.52Energieverbrauch [µJ] 0.75 73 65

34/39


Ausführungszeit (einfaches Programm)

Native Java VM CVM

Ausführungszeit [ms] 0.479 1.79 0.845Energieverbrauch [µJ] 0.54 2.0 0.95

Energieverbrauch [µJ] 36 000 27 000 2 000bei der Übertragung

Ausführungszeit (komplexes Programm)

Native Java VM CVM

Ausführungszeit [ms] 0.67 65.6 58.52Energieverbrauch [µJ] 0.75 73 65

34/39

Dynamic Module LoadingAusblick

FazitI Optimale Lösung kommt auf den Anwendungsfall an.I Virtual Machines haben ihren Reiz bei der Übertragung, aber

DeVzite bei der AusführungI Virtual Machine Code kann nicht auf Hardware-nahe

Funktionen zugreifen: Es sind native Schnittstellen erforderlich.

Dynamic Module Loading in der HausautomatisierungI Application ReconVguration ist eine mögliche AnwendungI Sicherheit ist ein Problem: z.B. ManipulationenI für Entwicklungsumgebungen sinnvollI in der Praxis i.d.R. zu hoher Energieverbrauch

35/39

Dynamic Module LoadingAusblick

FazitI Optimale Lösung kommt auf den Anwendungsfall an.I Virtual Machines haben ihren Reiz bei der Übertragung, aber

DeVzite bei der AusführungI Virtual Machine Code kann nicht auf Hardware-nahe

Funktionen zugreifen: Es sind native Schnittstellen erforderlich.

Dynamic Module Loading in der HausautomatisierungI Application ReconVguration ist eine mögliche AnwendungI Sicherheit ist ein Problem: z.B. ManipulationenI für Entwicklungsumgebungen sinnvollI in der Praxis i.d.R. zu hoher Energieverbrauch

35/39

Übersicht





Schlussbemerkungen

36/39

Schlussbemerkungen

I die Implementierung von Contiki ist sehr verwobenI die Programmierung für Contiki ist recht elegantI der Dokumentation fehlen Einführungen für das

SystemverständnisI die Netzwerk-Anbindung ist gut ausgebautI die Funktionalität im Net Stack sind klar getrenntI die praktischen Einsatzmöglichkeiten des Dynamic Module

Loading ist in Sensornetzen beschränkt

37/39

Ausblick

I Net Stack: Security–layer (ContikiSec)I Sleep Modi einbauenI Debug-System (bisher nur als Macro pro Datei)I Echtzeit-Eigenschaften

38/39

Ausgewählte Quellen

Farooq, O. M. & Kunz, T.: Operating Systems for Wireless SensorNetworks: A Survey,www.mdpi.com/1424-8220/11/6/5900/pdf, 2011

Strübe, Jan Moritz: Dynamische Re-Programmierung vonSensorknoten zur Laufzeit,strübe.de/wp-content/uploads/2008/08/da.pdf,Diplomarbeit, 2008

Dunkels, Adam et al.: Run-Time Dynamic Linking forReprogramming Wireless Sensor Networksdunkels.com/adam/dunkels06runtime.pdf, 2006

39/39

www.mdpi.com/1424-8220/11/6/5900/pdf

str�be.de/wp-content/uploads/2008/08/da.pdf

dunkels.com/adam/dunkels06runtime.pdf

Documents

Hochschule für Technik und Wirtschaft Dresden - Contiki-OSwiki_sn/images/9/91/Master... · 2016. 10. 26. · Theorie Protothreads Interprozess-Kommunikation Beispielprojekt MAC-Implementierung