wsn-doctorado-2011_v2

Wireless sensor networks:Sistemas operativos de nodos sensores

Máster en Ciencia y Tecnología Informática

Sistemas Operativos Avanzados

Curso 2010-2011

Soledad Escolar Díaz

[email protected]

� Soledad Escolar Díaz

� Profesor Ayudante

� Dpto. de Informática

� Arquitectura y Tecnología de Computadores (ARCOS)

� Despacho: 2.2.C.09

Mail: [email protected]

Datos de contacto

� Mail: [email protected]

� Web: http://www.arcos.inf.uc3m.es/~sescolar

Redes de sensores inalámbricas: visión de los sistemas operativos 31/03/2011

� Parte I: Introducción

� Parte II: Plataformas de hardware

� Parte III: Sistemas operativos

Contenidos

� Parte IV: Abstracciones de los sistemas operativos

� Parte V: Líneas de investigación y desafíos

� Trabajos propuestos

� Referencias


Contenidos

� Parte I: Introducción

� Wireless Sensor Networks (WSN)

� Historia antigua/moderna

� Elementos de una WSN


� Características

� Aplicaciones

� Tipos de despliegues

� Funcionamiento típico de una WSN

Introducción

� Una red de sensores (del inglés, Wireless Sensor Network) es un sistema distribuido donde parte de sus nodos (nodos sensores) son capaces de interactuar con el entorno físico

� Interactuar: lectura/actuación sobre el medio

� Wireless Sensor and Actuator Networks (WSAN)

� Nodos sensores son dispositivos electrónicos, autónomos,


� Nodos sensores son dispositivos electrónicos, autónomos, distribuidos geográficamente alrededor de un fenómeno para monitorizarlo, con capacidades de:

� sensing,

� cómputo,

� almacenamiento y

� comunicación inalámbrica

Elementos de una WSN (I)

S

M

S

M

S

M

S

M

S

M

Nodo sensor: sensor (S) + mote (M)


S

M

M

G

S

M

M

A PC (estación base), LAN, Internet

Elementos de una WSN (II)

S

M

S

M

S

M

S

M

G

S

M

S

M

S

M

� Nodos sensores:

� Placa de sensores (S):

� Variables medioambientales:

� e.g. luz, temperatura, humedad, presión, concentración de polen.

� Químicos:


M� Químicos:

� e.g. C02, oxígeno, ozono.

� Acústicos:

� e.g. ruido, ultrasonido.

� etc.

� Mote (M):

� Radio

� µcontrolador

Elementos de una WSN (III)

S

M

S

M

S

M

S

M

S

M

� Gateway:

� Dos funciones:

� Pasarela de comunicaciones

entre la WSN y el exterior

� Reprogramador de nodos sensores

S

M

S

M

G


sensores

A PC (estación base), LAN, Internet

Elementos de una WSN (IV)

S

M

S

M

S

M

S

M

S

M

� Una estación base:

�Dispositivo de mayor capacidad (ej. PC, portátil) para el almacenamiento, análisis y procesamiento de los datos procedentes de los

S

M

S

MG


los datos procedentes de los nodos

Estación base

Historia “antigua”

� Proyecto Distributed Sensor Networks (DSN)

� Década de los años 80

� DARPA (Defense Advanced Research Projects Agency) de EEUU

� Sound Surveillance System (SOSUS)

� Red de boyas sumergidas instaladas en las costas de los EEUU


� Red de boyas sumergidas instaladas en las costas de los EEUU durante la Guerra Fría para la detección de submarinos

� Considerada la primera red de sensores

� http://en.wikipedia.org/wiki/SOSUS

Historia moderna

� La ley de Bell (1972):

“aparecerá una nueva tecnología cada diez años”

� Proyecto Smart Dust (1998):

cómo empaquetar en una mote de1mm3 un dispositivo sensorial autónomo (Dr. KristoferPister, Universidad de California, Berkeley)

log (people

per com

pute

r)

year


Pister, Universidad de California, Berkeley)

� La primera mote: René (1999)

� El primer sistema operativo para nodos sensores: TinyOS (2002)

� Wireless Sensor Networks, la primera de las 10 tecnologías emergentes que cambiarán el mundo (MIT Journal, 2003)

Source: http://robotics.eecs.berkeley.edu/~pister/SmartDust/BlowDust.htm

Características

� Redes ad-hoc, sin infraestructura de red

� Redes formadas por miles, millones de pequeños dispositivos de bajo

coste

� Despliegue en terrenos inhóspitos, de difícil acceso:

� e.g. volcanes, glaciares, océanos, bosques

� Nodos autónomos y cooperantes, pensados para operar de manera desatendida un largo período de tiempo


desatendida un largo período de tiempo

� Nodos muy restringidos en cómputo, comunicación, almacenamiento y energía

� Típicamente redes inalámbricas (aunque también cableadas)

� Características específicas de comunicación:

� bajo throughput de datos,

� bajo consumo,

� topologías dinámicas (nodos móviles)

Aplicaciones medioambientales

� Objetivo:

Monitorización

medioambiental� No intrusiva� No necesidad de

infraestructurasConocimiento


� Conocimiento preciso y actualizado

� Ej: Great Duck

Island� Mainwaring et al.,

2002; Szewczyk et al., 2004

Source: http://www.biologie.uni-hamburg.de

Source: http://envisense.org/glacsweb/

Automatización de edificios

� Objetivo: automatización de tareas para el confort y seguridad en el hogar

� Desde edificios inteligentes hasta u-cities� Ubiquitous cities


� Ubiquitous cities

� Ej. Songdo City (Korea)� New Songdo City finalizará en

2014� $25 billones� Smart-cards, RFID, WSNs, etc. � http://www.youtube.com/watch?v=

V2uzo-xzta0

Source: http://www.songdo.com/

„The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.“, Mark Weiser.

Monitorización de infraestructuras

� Objetivo:

cuantificar el grado en que los

materiales se desgastan así como sus defectos estructurales

� Ej. Sustainable bridges


� Ej. Sustainable bridges

� Proyecto europeo del 6PM� Emplean sensores cableados

para monitorizar puentes de ferrocarriles

� [Krüger and Grosse, 2004]

Source: http://www.sustainablebridges.net/

Aplicaciones sanitarias

� Objetivo:diagnóstico de pacientes, respuesta a desastres, rehabilitaciónhttp://www.youtube.com/watch?v=V_UCF

3ZENv4&feature=related


� Ej. CodeBlue� Sensores que miden las

constantes vitales de los pacientes desde sus hogares� Frecuencia cardíaca� Saturación de oxígeno� Etc.Source:

http://fiji.eecs.harvard.edu/CodeBlue

Aplicaciones logísticas

� Objetivo:Monitorización de equipajes, contenedores, etc.� Localización exacta en cada

momento del tiempo� Monitorización de otras variables


� Monitorización de otras variables � RFID: otra tecnología adecuada

� Ej: Intelligent Container� Monitorización y planificación

completamente automatizada de transportes[Behrens et al., 2006]Source:

http://www.intelligentcontainer.com

� No confundir con topología

� Aleatorio

� e.g., instalados desde un avión

� Distribución aleatoria de los nodos sobre un área finita

� Regular

e.g., mantenimiento preventivo, monitorización

Tipos de despliegues

� e.g., mantenimiento preventivo, monitorización

� Distribución manual y localización fija

� No necesariamente estructura geométrica

� Nodos sensores móviles

� Los nodos pueden desplazarse debido a una fuerza externa (viento, agua)

� Pueden localizar áreas interesantes


Funcionamiento

wakeup

sleep

Tiempo


http://www.youtube.com/watch?v=jtRv2PCeOyM

Contenidos

� Parte II: Plataformas de hardware

� Nodos sensores, placas sensoras y gateways

� Arquitectura hardware del nodo sensor

� Componentes de hardware


Componentes de hardware

� Plataformas comerciales:

Nodos sensores


� Plataformas de investigación:

� http://en.wikipedia.org/wiki/List_of_wireless_sensor_nodes

Eko (2010)

� Placa de sensores� Conjunto de sensores y actuadores de distinto

distinto tipo integrados en una única placa� Conectada al nodo sensor a través

del conector de expansión

Gateway

Placas sensores y gateway

Foto: Sensor MTS400


� Gateway� Capacidad de comunicación inalámbrica

� Conexión a estación base por cable:� USB, RS-232, TCP/IP

� Doble función:� Programador de motes

� Descarga del código ejecutable en µc

� Pasarela WSN y estación base� Bidireccional Foto: Gateway Mib520

Arquitectura HW de un nodo sensor

� Microcontrolador

� Radio

� Memoria flash

� LEDs


� LEDs

� Conector de expansión

� Fuente de energía

Componentes de hardware (I)

� Microcontrolador:� Arquitectura Harvard

� Memoria RAM (datos)� Típicamente 4 KBytes

� Memoria ROM (programa)� Típicamente 128 Kbytes

� Baja frecuencia (7-32 Mhz)


� Baja frecuencia (7-32 Mhz)� Arquitectura típicamente RISC de 8-bits� Conversor analógico-digital (ADC)� Varios relojes

� Temporizadores � sincronización de tareas

� Ej.� Atmega 128 de Atmel (familia Mica)

� msp430 Texas Instrument (familia Telos)

Componentes de hardware (II)

� Radio:� Alcance:

� 75 a 100 metros outdoor� Alcances mucho más pequeños en indoor

� Banda de frecuencias:� 2.4 Ghz (compatible con Zigbee)� 933 Mhz

� Modulación


� Modulación

� Consumo energético es importante:� Las radios más nuevas poseen distintos

estados con distintos consumos

� Ej. CC2420(Chipcon), CC1000 (Chipcon), Nrf2401 (Nordic semiconductor)http://inst.eecs.berkeley.edu/~cs150/Documents/CC2420.pdf

Componentes de hardware (III)

� Conector de expansión:� Con la placa de sensores� 51 pines de conexión


Foto: Conector de expansión mote-placa sensora

Componentes de hardware (IV)

� Memoria flash:

� Externa al microcontrolador� Almacenamiento no volátil

(flash EEPROM)� De distintos tipos

� NAND, codifica datos como 1


� NAND, codifica datos como 1� NOR, codifica datos como 0

� Tamaño típico de almacenamiento� 512 Kbytes� Dividida en páginas de 264 bytes (256 útil + 8 bytes

de CRC)

� Aplicaciones:� e.g. sistemas de ficheros, reprogramación, etc.

� e.g. At45DB de Atmel (familia Mica), Strataflashde Intel (familia Telos)

Componentes de hardware (V)

� Batería� Típicamente pilas

�2 pilas alcalinas 1.5 voltios� 2000-3000 mAh

� Desde cinco días hasta años

� Fuentes alternativas de energía Estado: experimental


�Estado: experimental�Células solares, dinamos, etc.

� LEDs:� Tres leds:

� rojo, verde y amarillo

� Función:� Depuración de la aplicación

Contenidos

� Parte III: Sistemas Operativos

� Arquitectura de software

� Características

Modelos de ejecución y programación


� Modelos de ejecución y programación

� Sistemas Operativos para nodos sensores

� Programación de aplicaciones

� Los nodos sensores incluyen un microcontroladorcapaz de ejecutar tareas que requieren el acceso a elementos de hardware (sensores, memoria, radio, etc.)� Dispositivos no dedicados

Sistemas Operativos

� Necesidad de un sistema operativo de propósito general, cuyos objetivos son:� Gestionar eficientemente los recursos de hardware

� Facilitar la programación de aplicaciones de alto nivel


Arquitectura de software


Abstraction level

� Diseñados específicamente teniendo en cuenta las restricciones de hardware de los nodos sensores

� Los sistemas operativos diseñados para otro tipo de sistemas empotrados no se adaptan a las fuertes restricciones de los nodos sensores

� Tamaño, consumo, requisitos de las aplicaciones

� Responsable de:

Gestionar el microcontrolador (típicamente monotarea), tiempo

Características de los SSOO (I)

� Gestionar el microcontrolador (típicamente monotarea), tiempo (temporizadores) y concurrencia

� Gestionar el resto de dispositivos del hardware

� Ofrecer interfaces de acceso (APIs) a los elementos de hardware (sensores, memoria, radio, etc.)

� Programación de aplicaciones

� Ofrecer una interfaz para la instalación del código ejecutable en el microcontrolador

� Ahorro de energía


Características de los SSOO (II)

� Multiplataforma

� Soportan un subconjunto de las plataformas disponibles

� Arquitectura monolítica

� Cuando se compila la aplicación se crea una imagen indivisible compuesta por el S.O. y la propia aplicación

� Footprint (huella) de pequeño tamaño

Limitado por la capacidad de memoria (e.g. 4KB RAM y 128 KB ROM)� Limitado por la capacidad de memoria (e.g. 4KB RAM y 128 KB ROM)

� Ofrecen interfaces de alto nivel (al nivel de aplicación) y usan el interfaz de bajo nivel para acceder a los dispositivos de hardware

� Servicios cross-layer

� En realidad, no tan alto nivel….

� Proveen implementaciones para la gestión de red (protocolos de enrutamiento, MAC, localización), memoria flash (sistemas de ficheros), temporización (relojes de software), etc.

31/03/2011Redes de sensores inalámbricas: visión de los sistemas operativos

Modelos de ejecución

� Basado en eventos

� Basado en threads1 2 3

Modelo basado en eventos

Modelo basado en threads

2

1

3

31/03/2011

2 3

Pila dedicada por thread

Pila compartida

Redes de sensores inalámbricas: visión de los sistemas operativos

Eventos vs. threads

Paradigm Event-based Thread-based

Semantic Run-to-completion Preemptive

Resources Shared stack One stack per thread

Control flow State machine Linear

� Comparativa modelo de ejecución/programación


Control flow State machine Linear

Programming flow Unstructured, ad-hoc code, split-phase functions

Sequential

Synchronization Asynchronous Blocking

Concurrency model Non explicit by event-handlers

Explicitly by threads

� Basado en eventos

Ventajas e inconvenientes

� Una única pila compartida� Más eficiente en cuanto a los recursos utilizados� Asíncrono

� Flujo de ejecución no estructurado (máquina de estados)� La depuración es complicada

� Basado en threads

31/03/2011

� Flujo de ejecución lineal� Síncronos � bloqueantes

� Una pila por thread � más recursos

Redes de sensores inalámbricas: visión de los sistemas operativos

Sistemas operativos para nodos

sensores

� TinyOS (1.x y 2.x)

� Contiki

� Mantis

� LiteOS

� FreeRTOS� FreeRTOS

� NanoOS


� TinyOS :

� Primer SO desarrollado específicamente para nodos sensores

� Jason Lester Hill y David Culler

� Berkeley University, 2002

� Quasi-estándar o estándar de facto

� Sistema operativo de código libre

� Desarrollo activo por parte de numerosos colaboradores

� La primera versión fue escrita en C, y posteriormente fue reescrito

Sistemas Operativos [Jason Lester Hill, 2002]

� La primera versión fue escrita en C, y posteriormente fue reescrito íntegramente en nesC

� Actualmente versión 2.1.1

� Versión 1.x y 2.x no son compatibles

� Multiplataforma

� No soporta todas las plataformas de nodos sensores

� Pequeño footprint (tamaño del código ejecutable)

� 250 bytes of ROM

� 16 bytes of RAM

� http://www.tinyos.net


� Modelo de ejecución basado en eventos

� Con algunas diferencias con respecto al modelo “puro”

� Los eventos tienen una semántica

con-expulsión (preemptive) y no se encolan

� ¿Qué ocurre con los eventos que se

TinyOS

2

1

3

4� ¿Qué ocurre con los eventos que se

interrumpen?

� Se pierden


4

ConfigurationComponent F

ImplementationComponent A

Application(Configuration Component)

ImplementationComponent B

ImplementationComponent C

ImplementationComponent E

Configuration Component D

� Modelo de programación basado en

componentes

nesC

� nesC: networked embedded systems C

� Meta-lenguaje basado en C

� Modelo de programación basado en componentes

� Características:

� Interfaces bidireccionales (use and provide)

� Componentes: separación entre implementación y composición


� Componentes: separación entre implementación y composición

� Implementación mediante module

� Composición estática mediante configuration

� Wiring es la relación de todos los componentes e interfaces implicados en una aplicación, indicando qué componentes usan y proporcionan cada interfaz

Componentes en nesC

� Dos tipos:

� Configuración

� Componentes utilizados por la aplicación (a todos los niveles: HW, OS, y aplicación)

� Relaciones entre componentes

ImplementationComponent A

Application(Configuration Component)

ImplementationComponent C

Configuration Component D

Relaciones entre componentes e interfaces (wiring)

X.Y �� Z.Y

� Implementación o módulo:

� Implementación del componente

� Interfaces que usa y proporciona este componente


ConfigurationComponent F

ImplementationComponent B

ImplementationComponent E

Interfaces en nesC

� Prototipos de las funciones y de los eventos que usan/proporcionan los componentes:

� Comandos

� Similares a las funciones: ruptura de control para ejecutar el comando (función) y retorno a la función llamante

� Se invocan desde un nivel de abstracción mayor a uno menorapp


� Se invocan desde un nivel de abstracción mayor a uno menor

� La implementación de los comandos se proporciona en el componente de nivel inferior

� Eventos

� Para cada evento, el manejador del evento contiene la implementación que ha de ejecutarse cuando se genera el evento

� Se invocan desde un nivel de abstracción menor a uno mayor

� La implementación de los eventos se proporciona en el nivel superior

so

hw

Uso de comandos y eventos en nesC

� Prototipos de las funciones y de los eventos

que usan/proporcionan los componentes:

� Comandoscall X.C (tipo1 arg1, tipo2 arg2,…,tipon

argn)

Donde X es un componente de implementación que app


Donde X es un componente de implementación que proporciona la implementación del comando C

� Eventossignal Y.E(tipo1 arg1,tipo2 arg2,…, tipon

argn)

Donde Y es un componente de implementación que proporciona la implementación del evento E

so

hw

Planificación en TinyOS

� 2 niveles de planificación:

� Eventos: funciones de alta prioridad

� Tareas: funciones de más baja prioridad


Ejemplo: Blink application

Configuration Module


Interface

TinyOS 2.x

� Iniciativa de muchas universidades colaborando juntas (Nov, 2006)

� Objetivos:

� Portabilidad

� Facilitar la construcción de aplicaciones

� Fiabilidad

[Philip Levis, David Gay, Vlado Handziski, Jan Hinrich Hauer, Ben Greenstein, Martin Turon, Jonathan Huio, Kevin Klues, Cory Sharp, Robert Szewczyk, Joe Polastre, � Fiabilidad

� El acceso al hardware se organiza en una arquitectura de abstracción de hardware (HAA):� Hardware Independent Layer (HIL)

� Hardware Adaptation Layer (HAL)

� Hardware Presentation Layer (HPL)


Joe Polastre, Philip Buonadonnao, Lama Nachman, Gilman Tolleo, David Culler and Adam Wolisz, 2006]

TinyOS 2.x

� Implementación de múltiples threads (TosThreads)

� Intento de combinar el modelo de programación de threads en un modelo de ejecución basado en eventos

� El planificador maneja una FIFO con capacidad para 255 tareas (en T1 tenía capacidad para 8 tareas)

� La semántica de fallos para insertar una tarea en la cola se mejora

“a post of a task only will fail if and only if the task has been previously posted and its

� Secuencia de arranque e inicialización más óptima

� Nuevas interfaces (e.g. Boot)

� Gestión de la energía más eficiente

� Explota las capacidades de los componentes de HW para transitar a estados de bajo consumo

� Ej. Low Power Listening


“a post of a task only will fail if and only if the task has been previously posted and its execution has not started. This semantic is achieved by locating a byte of state for every task, to test if it must post itself again or not”

Low Power Listening (LPL)

� Idea: reducir el tiempo en que el nodo se encuentra en estado de escucha (idle listening)

� Se define un intervalo (TLPL) para realizar periódicamente el muestreo del canal

� Se pueden construir modelos energéticos analíticos� Se pueden construir modelos energéticos analíticos


� Diseñado para sistemas empotrados conectados en red, incluidos nodos sensores

� Adam Dunkels, Swedish Instititute of Computer Science (SICS), 2003

� http://www.sics.se/contiki/


� Open source

Contiki [Adam Dunkels, 2003]

� Open source

� Modelo de ejecución híbrido (threads y eventos)

� Modelo de programación secuencial

� Escrito en lenguaje de programación C

� Multiplataforma

� Soporte para menos plataformas comerciales

� Reprogramación modular

� Footprint:

� 2 kilobytes de RAM y 40 kilobytes de ROM


Modelo de ejecución de Contiki

� Híbrido:� Threads y eventos combinados en “protothreads”

� Estilo de programación� Proporciona sintaxis secuencial y bloqueos condicionales

� Al igual que los eventos los protothreads no requieren su propia pilapropia pila

� Esto reduce significativamente el gasto de memoria

� Soporte multithreading como librería


� La primera versión de Contiki usaba threads

� La segunda versión de Contiki incorpora los protothreads:

Protothreads (I)

“Protothreads are extremely lightweight stackless threads designed for severelymemory constrained systems, such as small embedded systems or wireless sensornetwork nodes”

� Los protothreads en Contiki se basan en el concepto de “continuación

local” de Reynolds (1993) y las co-rutinas de Simon Tatham (2005)

� Cualquier proceso en Contiki es un protothread, el cual implementa una función de C

� Threads muy ligeros que se ejecutan sobre un kernel basado en

eventos

� Pueden ser vistos como: Manejadores de eventos bloqueantes


� Un protothread se basa en una continuación local (lc), la cual usa n bytes para representar la dirección del salto relativa a una función de C (un puntero)� El tamaño de la dirección es dependiente de la plataforma

� Contiki define una serie de macros de C (directivas de

Protothreads (II)

� Contiki define una serie de macros de C (directivas de pre-procesador) que permiten modificar implícitamente y de manera transparente el valor de lc

� Dos operaciones básicas:� set (lc, dir) � modificar el valor de lc a dir

� resume (lc) � continuar una lc


Macros para continuaciones locales (lc)

#define LC_INIT(s) s = 0; #define LC_RESUME(s) switch(s) { case 0:#define LC_SET(s) s = __LINE__; case __LINE__: #define LC_END(s) } #define LC_END(s) }


Macros para protothreads (I): http://www.sics.se/~adam/contiki/contiki-2.1-doc/a0 0457.html

struct pt {lc_t lc ; // Un protothread define una continuación local

}; #define PT_INIT (pt) LC_INIT((pt)->lc) #define PT_THREAD(name_args) char name_args

#define PT_BEGIN(pt) { char PT_YIELD_FLAG = 1; LC_RESUME((pt)->lc)

#define PT_END(pt) LC_END((pt)->lc); PT_YIELD_FLAG = 0; \PT_INIT(pt); return T_ENDED; } PT_INIT(pt); return T_ENDED; }

#define PT_WAIT_UNTIL(pt, condition) \do { \

LC_SET((pt)->lc); \if(!(condition)) { \

return PT_WAITING; \} \

} while(0)

#define PT_WAIT_WHILE(pt, cond) PT_WAIT_UNTIL((pt), !(cond))#define PT_WAIT_THREAD(pt, thread) PT_WAIT_WHILE((pt),

PT_SCHEDULE(thread))


Macros para protothreads (II): http://www.sics.se/~adam/contiki/contiki-2.1-doc/a0 0457.html

#define PT_RESTART(pt) \do { \

PT_INIT(pt); \return PT_WAITING; \

} while(0)

#define PT_YIELD(pt) \do { \

PT_YIELD_FLAG = 0; \LC_SET((pt)->lc); \if (PT_YIELD_FLAG == 0) { \if (PT_YIELD_FLAG == 0) { \

return PT_YIELDED; \} \

} while(0)

#define PT_YIELD_UNTIL(pt, cond) \do { \

PT_YIELD_FLAG = 0; \LC_SET((pt)->lc); \if((PT_YIELD_FLAG == 0) || !(cond)) { \

return PT_YIELDED; \} \

} while(0)


Macros para procesos: http://www.sics.se/~adam/contiki/contiki-2.1-doc/

#define PROCESS_BEGIN() PT_BEGIN(process_pt)#define PROCESS_END() PT_END(process_pt)#define PROCESS_WAIT_EVENT() PROCESS_YIELD()#define PROCESS_WAIT_EVENT_UNTIL(c) PROCESS_YIELD_UNTIL(c)#define PROCESS_YIELD() PT_YIELD(process_pt)#define PROCESS_YIELD_UNTIL(c) PT_YIELD_UNTIL(process_pt, c)#define PROCESS_WAIT_UNTIL(c) PT_WAIT_UNTIL( process_pt , c) #define PROCESS_WAIT_UNTIL(c) PT_WAIT_UNTIL( process_pt , c) #define PROCESS_WAIT_WHILE(c) PT_WAIT_WHILE(process_pt, c)#define PROCESS_EXIT() PT_EXIT(process_pt)#define PROCESS_THREAD(name, ev, data) \

static PT_THREAD(process_thread_##name(struct pt *process_pt, \process_event_t ev, \process_data_t data))

#define PROCESS_NAME(name) extern struct process name


Contiki: una aplicación sencilla

static PT_THREAD(example(struct pt *pt)) { PT_BEGIN(pt); while(1) {

PT_WAIT_UNTIL(pt, counter == 1000); printf("Threshold reached\n"); counter = 0;

} PT_END(pt);

}

Un protothread


static char example(struct pt *pt) {switch(pt->lc) { case 0:

while(1) {pt->lc = 12; case 12: if(!(counter == 1000)) return 0; printf("Threshold reached\n"); counter = 0;

} }pt->lc = 0; return 2;

}

Una lc(código final)

Contiki: Blink application

PROCESS(main, “main”)AUTOSTART_PROCESSES(&main)PROCESS_THREAD(main, ev, data) {

static struct etimer t0;PROCESS_BEGIN();while (1){

etimer_set (&t0, 1*CLOCK_SECOND)PROCESS_WAIT_EVENT();if (ev== PROCESS_EVENT_TIMER) {

leds_toggle (LEDS_RED);

#define PROCESS_THREAD(name, ev, data)static PT_THREAD(

process_thread_##name(struct pt process_pt,

process_event_t ev, process_data_t data))

#define PROCESS_BEGIN() PT_BEGIN(process_pt)#define PROCESS_END() PT_END(process_pt)

blink.c process.h

leds_toggle (LEDS_RED);}

}PROCESS_END();

}


#define PT_INIT (pt) pt->lc = 0#define PT_BEGIN(pt)switch(pt->lc){\

case 0:#define PT_EXIT () pt->lc = 0: \

return 2;#define PT_WAIT_UNTIL(pt, c)

pt->lc = __LINE__; \case __LINE__: \if (!(c)) return 0;

#define PT_END(pt) } pt->lc = 0;

pt.h

� MultimodAl networked of In-situ Sensors (MANTIS)

� Universidad de Colorado (2003)

� Sistema operativo escrito en C de código abierto basado en POSIX

� Facilidad de programación

� Multi-threading

� Planificador basado en prioridades

Mantis

� Multiplataforma

� Mica2, MicaZ y Telos

S. Bhatti, J. Carlson, H. Dai,

J. Deng, J. Rose, A. Sheth,

B. Shucker, C. Gruenwald,

A. Torgerson, R. Han


� Footprint:

� 500 bytes RAM y 14 KB ROM

� Ventajas:

� Procesos largos no bloquean el sistema

� Modelo de programación más sencilloque modelo basado en eventos

� Inconvenientes:

� Sobrecarga debida a los intercambios de contexto

� Mayor consumo de memoria debido a la existencia de múltiples pilas

Arquitectura de MANTIS

http://mantisos.org/index/tiki-index.php.html

Mantis: una aplicación sencilla

#include <inittypes.h>#include “led.h”#include “dev.h”#include “com.h”

void start(void){uint16_t delay;uint8_t value ;

simple_send.c


uint8_t value ;comBuf send_pkt;

value= dev_get(DEV_MICA2_LIGHT);mos_led_toggle(0);send_pkt.data[0]=VALUE;send_pkt.size = 1;com_send(IFACE_RADIO, &send_pkt);

}

Resumen

1 2 3

Modelo basado en eventos

Modelo basado en threads

� Modelos de ejecución:

� Basado en eventos:

� TinyOS :

eventos y tareas

� Basado en threads:2

1

3


� Mantis: prioridades

� LiteOS: multithread

� Híbrido:

� Contiki: protothreads

Un protothread es unmanejador de eventobloqueante

2 3

Pila dedicada por threadPila compartida

Modelos de programación

1: module MyApp { 2: uses interface { … interfaces …} 3: provides interface {StdControl,…}} 4: implementation{5: command StdControl.init(){ … }6: command StdControl.start(){ 7: // call command

// post task8: }9: command StdControl.stop(){ … }

Modelo 1: TinyOS 1.x (eventos)

1: module MyApp { 2: uses interface {Boot, …. } 3: provides interface { …interfaces…}4: }5: implementation{6: event Boot.booted(){7: // call command

// post task8: }9: event interfaceUsed.event(){ … }

Modelo 2: TinyOS 2.x (eventos)


9: command StdControl.stop(){ … }10: event interfaceUsed.event(){ … }11:}

9: event interfaceUsed.event(){ … }10:}

Modelo 4: Mantis (threads/prioridades)

1: void start (void) {2: // C code with MANTIS interface3: }4: // Threads5: void x(void{6: // C code & MANTIS interface7: }

1: PROCESS(PROCESS1, “PROCESS1”);2: PROCESS( PROCESS2, “PROCESS2”);3: AUTOSTART_PROCESS

(&PROCESS1,&PROCESS2);5: PROCESS_THREAD(PROCESS1,ev,data){6: PROCESS_BEGIN();7: // C code & Contiki Interface8: PROCESS_END();9: }10: PROCESS_THREAD(PROCESS2,ev,data){…}

Modelo 3: Contiki (protothreads)

Contenidos

� Parte IV: Capas de abstracción de los sistemas operativos

� Arquitecturas portables

� NOSA

http://opensource.gsfc.nasa.gov/projects/osal/


� http://opensource.gsfc.nasa.gov/projects/osal/

� Capa de abstracción del S.O.

� http://rts.eit.uni-kl.de/fileadmin/publication_files/SERNA_SAC10.pdf

Motivación

“Application development is still one of the main hurdles to a wide adoption of WSN technology. […] The need for appropriate high-level

programming abstractions, capable to simplify the programming

chore without sacrificing efficiency, has been long recognized”.


chore without sacrificing efficiency, has been long recognized”.

”Programming Wireless Sensor Networks: Fundamental Concepts and State of the Art”

Luca Mottola and Gian Pietro Picco

ACM Computing Surveys, February 2010

� Complejidad inherente al hardware:

� Recursos limitados de HW y energía

� Heterogeneidad de los dispositivos

� Número creciente de plataformas

Orígenes de problemas

� Desarrollo de aplicaciones:

� Ausencia de estándares y arquitecturas abiertas:

� Protocolos de red y desarrollo de aplicaciones

� Específicas de un escenario y/o plataforma particular

� Desarrollo de aplicaciones:� Ad-hoc, bottom-up, fuertemente acopladas

� Programación cercana al sistema operativo

� Portabilidad de aplicaciones reducida


� Específicamente, los SSOO diseñados para

nodos sensores:

No existen herramientas de alto nivel (lenguajes de programaciónespecíficos, metalenguajes, capas de abstracción) sobre el SO:

Exportan tanto la interfaz del hardware como la del propio SOo Límite incierto entre HW/SW

Motivación

específicos, metalenguajes, capas de abstracción) sobre el SO:o Las aplicaciones usan el mismo LP que el SO subyacenteo Incremento de la complejidad

Heterogeneidad de los modelos de ejecución/programacióno Modelos de ejecución: basado en eventos, basado en threads o Acoplamiento entre modelo de ejecución y paradigmas de programación


El tamaño reducido de los nodos impide tener la generalidad y las abstracciones esperadas en el nivel del SO

Arquitecturas portables

de nodo sensor [S. Escolar ,

J. Carretero, 2006]

Diseño, implementación y evaluación de una arquitectura

software centrada en nodo sensor que soporte el desarrollo deaplicaciones genéricas y portables que puedan ser fácilmentetransportadas a plataformas heterogéneas, incrementando así la


transportadas a plataformas heterogéneas, incrementando así laproductividad.

App 1 App 1’ App 1’’

Arquitectura actual

SO – WNS 1 SO –WSN 2 SO – WSN n

Mote – 1

Sensorboard 1

Mote – 2 Mote – 3 Mote – m

Sensorboard 2 Sensorboard l


Arquitectura propuesta

Aplicación 1

OSAL



Mote – 1

Sensorboard 1



Objetivos de la arquitectura

� Objetivos: � portabilidad,

� mínima sobrecarga,

� productividad


Mote – 1

Sensorboard 1

Aplicación 1



OSAL


Sensorboard 1 Sensorboard 2 Sensorboard l

Características de la arquitectura (1/2)

� Arquitectura centrada en nodosensor (node-centric)� Definir el comportamiento de los

nodos individuales

� Formalización matemática usando teoría de conjuntos


Mote – 1

Sensorboard 1

Aplicación 1



OSAL

� Formalización matemática usando teoría de conjuntos� Organizar los componentes fundamentales y sus relaciones� Facilitar la definición de arquitecturas portables

� Enfoque Model Driven Architecture (MDA)Definición de aplicaciones independientes de la plataformaDefinición de un proceso de transformaciónGeneración de aplicaciones específicas




Mote – 1

Sensorboard 1

Aplicación 1



OSAL

� Multiplataforma

� Diseño multicapa

� Reusabilidad

� Hardware

� Sistema Operativo



� Abstracciones de programación de aplicaciones portables:

� Operating System Abstraction Layer (OSAL)

� Capa de Aplicación

� Generación de código en tiempo de compilación



Mote – 1

Sensorboard 1

Aplicación 1



OSAL

� Multiplataforma

� Diseño multicapa

� Reusabilidad

� Hardware




� Abstracciones de programación de aplicaciones portables:

� Operating System Abstraction Layer (OSAL)

� Capa de Aplicación

� Generación de código en tiempo de compilación

Aplicación (APP)

API de SN-OSAL

Sensor Node Open Services Abstraction Layer (SN-OSAL)

SN-OSAL Translation Engine

pre-compilador de SN-OSAL (osalc)

Scripts de traducción (mappers)

Implementación de OSAL

osal2tinyos1x osal2tinyos2x osal2contiki

Scripts de traducción (mappers)

Sistema Operativo (O)

TinyOS 1.x TinyOS 2.x Contiki

Familia Mica

Hardware (H)

Familia TelosESBSKY


Interfaz de SN-OSAL� La interfaz de SN-OSAL se compone de:

1. Primitivas o servicios de alto nivel que gestionan operacionesbásicas sobre los dispositivos físicos de los nodos sensores

2. Constructores del lenguaje

3. Espacio de nombres y palabras reservadas


Interfaz de SN-OSAL: Primitivas

� 30 primitivas que homogeneizan los servicios comunes

ofrecidos por los sistemas operativos de nodos sensores

� Basado en POSIX

Facilitar la programación

:� Clasificadas por funcionalidad:E/S: sensores y actuadores

CPU: sistema de reloj y temporizadores

Comunicación: envío y recepción de datos

Almacenamiento : sistema de ficheros

Procesos y planificación: gestión de procesos

Depuración: operaciones sobre LEDs


Ejemplo: primitivas SN-OSAL

� I/Oint8_t osal_io_open (unsigned char device);int8_t osal_io_read (int8_t desc, uint16_t data);

� Gestión del tiempoint8_t osal_timer_start(int8_t num,int8_t granularity,uint8_t frequency);int8_t osal_timer_stop (int8_t desc);

� Comunicaciónint8_t osal_net_send (uint8_t address, void *data, uint8_t length);


int8_t osal_net_send (uint8_t address, void *data, uint8_t length);int8_t osal_net_getId ();

� Ledsvoid osal_led_on (uint8_t led);void osal_led_off (uint8_t led);

� Procesos y planificaciónosal_ task* osal_task_current();int8_t osal_task_exit();

� Sistema de ficherosint8_t osal_fs_open (char *filename, uint8_t mode)int8_t osal_fs_read (uint8_t fd, char *buffer, int8_t length)

λT:SN-OSALI� OIj

osal_led_on(LED_RED) call Leds.redOn() call Leds.Led0On() leds_on(LEDS_RED)

osal_led_off(LED_GREEN) call Leds.greenOff() call Leds.Led1Off() leds_off(LEDS_GREEN)

desc=osal_timer_start(*, call TimerX.start( call TimerX.startOneShot( etimer_set(&tx, SEC,ONE_SAMPLE) TIMER_ONE_SHOT, \1*1000) \1*1000) \1*CLOCK_SECOND)

// go into a loopdesc=osal_timer_start(*, call TimerX.start( call TimerX.startPeriodic( etimer_set(&tX,

SN-OSALI TinyOS 1.x TinyOS 2.x Contiki


osal_io_open(TEMP) call TempControl.init() ф temperature_sensor.activate()

desc=osal_timer_start(*, call TimerX.start( call TimerX.startPeriodic( etimer_set(&tX, SEC, REPEAT_SAMPLE) TIMER_ONE_SHOT, \1) \1*1000) \1*CLOCK_SECOND)

osal_io_close(TEMP) call TempControl.stop() ф temperature_sensor.deactivate()

osal_io_read(TEMP,*) call TempControl.start() call Temperature.read() data=temperature_sensor.value(0)call Temp.getData()

osal_net_send(*,*,*) if (call SendX.send( if (call AMSendX.send( rimebuf_clear()\1,\3,\2 )==SUCCESS){ \1,\2,\3 )==SUCCESS){ rimebuf_copyfrom(\2,\3)osal_radio_busy=TRUE;} osal_radio_busy=TRUE;} addr.u8[0]=addr.u8[1]=(\1)

Y_send(X_conn,&addr)

osal_net_getId() TOS_LOCAL_ADDRESS TOS_NODE_ID node_id

SN-OSAL Translation Engine

� Proceso de transformación (TP)

K ◦ J ◦ H ◦ G(APPSN-OSAL) si SO= {T1, T2}

K ◦ J ◦ G(APPSN-OSAL) si SO = {Contiki}TP(APPSN-OSAL) =

donde:

1. Compilación de la aplicación APPSN-OSAL 1. Compilación de la aplicación APPSN-OSAL

G : SN-OSALI → SN-OSALI

2. Obtención de abstracciones: componentes, wirings e interfaces

H : APPSN-OSAL→ {C,W, OIi , ф}, i = {T1, T2}

3. Obtención de los eventos

J : APPSN-OSAL → {E, ф}

4. Generación de código (mappers)K : APPSN-OSAL → {APPoi}, i = {T1, T2, Contiki}


Sensor Node Domain Specific Language (SN-DSL)

� Motivación:� Desacoplar el lenguaje de programación del sistema operativo

� Ocultar el modelo de ejecución y programación exhibido por los SSOO

� Proporcionar abstracciones para escribir aplicaciones usando SN-OSAL:

� TinyOS (nesC): interfaces, componentes, wirings, eventos

� Contiki (C): macros protothreads, callbacks, primitivas bloqueantes

� Definir un espacio de nombres global y único y un conjunto de servicios � Definir un espacio de nombres global y único y un conjunto de servicios homogéneos


� Lenguaje específico de dominioMetalenguaje del lenguaje de programación C

� Define la sintaxis y la semántica de las aplicaciones

Sintaxis y semántica de SN-DSL

� Sintaxis:

� Espacio de nombres o alfabeto de SN-DSL

� Reglas de escritura

� Formalización mediante gramática capaz de generar SN-DSL

� Semántica:� Semántica:

� Modelo de ejecución/programación basado en eventos

� Bloques de programación:

� Función principal (main)

� Entidades de ejecución

• Tareas (TinyOS) o protothreads (Contiki)

� Manejadores de eventos


VisualOSAL

� VisualOSAL es un entorno de

desarrollo gráfico de aplicaciones

de alto nivel construidas sobre SN-OSAL


� Guiar el proceso completo de desarrollo de aplicaciones

� Permitir especificar aplicaciones de manera visual:

Capa de Aplicación (APP)

WSN ARQUITECTURA

VisualOSAL

� Permitir especificar aplicaciones de manera visual:

o Los elementos del lenguaje SN-DSL se substituyen por notación gráfica para especificar de manera sencilla e intuitiva aplicaciones de alto nivel

� Generar código en distintos niveles de abstracción y etapas de desarrollo:

o Código portable (XML)

o Código independiente (SN-DSL)

o Código específico de la plataforma (SO)

� Prototipo en desarrollo


Contenidos

� Parte V: Líneas futuras de investigación,

tendencias y desafíos

� Líneas futuras de investigación

�Tendencias


� Desafíos

� Energía

� Herramientas de desarrollo, APIs de programación

� Simulación

� Integración con otras tecnologías de red

� Complejidad inherente al hardware:� Recursos limitados de HW y energía

� Búsqueda de fuentes alternativas de energía

� Heterogeneidad de los dispositivos

� Número creciente de plataformas

� Desarrollo de aplicaciones:

Desafíos (I)

� Ad-hoc, bottom-up, fuertemente acopladas

� Programación cercana al sistema operativo

� No existen lenguajes de programación por encima de los sistemas operativos

� Portabilidad de aplicaciones reducida

� Simulación de aplicaciones

� Ausencia de estándares y arquitecturas abiertas:

� Protocolos de nivel de red y aplicación

� API estándar de programación/ Metodología de desarrollo/ Arquitectura de software


� Integración de las WSN con otras tecnologías de red

� Internet (6lowpan)

� Middleware de comunicaciones

� Escalabilidad, heterogeneidad, etc.

� Seguridad

Desafíos (II)

� Simulación de aplicaciones de redes de sensores

� Depuración de aplicaciones en un entorno PC


Roadmap de tecnologías básicas


Tendencias

� Mercado de RFID y WSN hasta 2010

31/03/2011

NOTA: USN: Ubiquitous Sensor Networks


Líneas futuras de investigación

� Líneas futuras de investigación y estimación en el tiempo


Lista de trabajos

� Sistemas operativos:� Ahorro de energía en los sistemas operativos Contiki y TinyOS

� Estado del arte de otros sistemas operativos diseñados para redes de sensores: LiteOS, nanoOS

� OSAL:� osal2mantis: portar OSAL al sistema operativo mantis

� osal2<wsn-os>� osal2<wsn-os>

� Introducir primitivas de ahorro de energía en OSAL

� Redes y comunicación� Análisis del consumo de energía del protocolo MAC 802.15.4

� Diseño e implementación de un protocolo de enrutamiento de paquetes basado en árboles B

� Integración de una WSN con Internet (6lowpan) � Desarrollos en TinyOS y Contiki


Bibliografía (I)[1] Sensors everywhere. Fundación Vodafone. (online:

http://vodafone.es/fundacion/fundacion.vodafone.es/VSharedClient/FundacionVodafone/PDF/LibroSensors.pdf)

[2] Introducción a las redes de sensores (online:

http://www.arcos.inf.uc3m.es/~sescolar/index_files/presentacion/wsn.pdf)

[3] System architecture for wireless sensor networks by Jason Lester Hill

[4] The nesC language: A holistic approach to networked embedded systems by David

Gay, Philip Levis, Robert von Behren, Matt Welsh, Eric Brewer, David Culler.


Gay, Philip Levis, Robert von Behren, Matt Welsh, Eric Brewer, David Culler.

[5] TinyOS programming by Phillip Levis (online: http://www.tinyos.net/tinyos-2.x/doc/pdf/tinyos-programming.pdf)

[6] Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors

by Adam Dunkels , Björn Grönvall , Thiemo Voigt

[7] Mantis os: An embedded multithreaded operating system for wireless micro sensor

platforms by Shah Bhatti , James Carlson , Hui Dai , Jing Deng , Jeff Rose , Anmol Sheth , Brian Shucker , Charles Gruenwald , Adam Torgerson , Richard Han

[8] Protothreads: Simplifying event-driven programming of memory-constrained

embedded systems. Adam Dunkels, Oliver Schmidt, Thiemo Voigt, and Muneeb Ali.

Bibliografía (II)[9] T2: A Second Generation OS For Embedded Sensor Networks (2006) by Philip Levis, David Gay,

Vlado Handziski, Jan-Hinrich Hauer, Ben Greenstein, Martin Turon, Jonathan Huio, Kevin Klues, Cory Sharp, Robert Szewczyk, Joe Polastre, Philip Buonadonnao, Lama Nachman‡, GilmanTolleo, David Culler, and Adam Wolisz.

[10] Versatile low power media access for wireless sensor networks by Joseph Polastre, JasonHill and David Culler

[11] Flexible Hardware Abstraction for Wireless Sensor Networks (2005) by Vlado Handziski, Joseph Polastrey, Jan-Hinrich Hauer, Cory Sharpy, Adam Wolisz and David Culler

[12] Low Power Listening. (online: http://www.tinyos.net/tinyos-2.x/doc/html/tep105.html)

[13] IEEE 802.15.4 (online: http://www.ieee802.org/15/pub/TG4.html)


[13] IEEE 802.15.4 (online: http://www.ieee802.org/15/pub/TG4.html)

[14] Zigbee Alliance (online: www.zigbee.org)

[15] Operating System Abstraction Layer (online: http://opensource.gsfc.nasa.gov/projects/osal/index.php)

[16] An operating system abstraction layer for portable applications in wireless sensor networks by Ramon Serna Oliver, Ivan Shcherbakov, Gerhard Fohler

[17] Wireless sensor networks: a survey by I. F. Akyildiz , W. Su , Y. Sankarasubramaniam , E. Cayirci

[18] Directed Diffusion: A scalable and robust communication paradigm for sensor networksby Chalermek Intanagonwiwat , Ramesh Govindan , Deborah Estrin

Wireless sensor networks:Sistemas operativos

Máster en Ciencia y Tecnología Informática

Sistemas Operativos Avanzados

Curso 2010-2011

Soledad Escolar Díaz

[email protected]