wsn-doctorado-2011_v2

Wire Wi rele less ss se sens nsor or net netwo work rks s : 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]

Datos de contacto 

Soledad Escolar Díaz      

Profesor Ayudante Dpto. de Informática Arquitectura y Tecnología de Computad Computadores ores (ARCOS) (A RCOS) Despacho:: 2.2.C Despacho 2.2.C.09 .09 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

Datos de contacto 

Soledad Escolar Díaz      

Profesor Ayudante Dpto. de Informática Arquitectura y Tecnología de Computad Computadores ores (ARCOS) (A RCOS) Despacho:: 2.2.C Despacho 2.2.C.09 .09 Mail: [email protected] Web: http://www.arcos.inf.uc3m.es/~sescolar


31/03/2011

Contenidos 

Parte I:



Parte II: Plataformas de hardware



Parte III: Sistemas operativos



Parte IV: Abstracciones de los sistemas operativos



Parte V: Líneas de inv i nvestigación estigación y desafíos



Trabajos propuestos



Referencias

Introducción


31/03/2011

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


31/03/2011

Introducción 

Una red de sensores (del inglés, Wireless Sensor Network ) e s u n 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)

, , distribuidos geográficamente alrededor de un fenómeno para monitorizarlo, con capacidades de:  sensing ,  cómputo,  almacenamiento y  comunicación inalámbrica


31/03/2011

Elementos de una WSN (I) S

S

S

M

M

M

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

S

S

S

S

M

M

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


31/03/2011

Elementos de una WSN (II) 

Nodos sensores: 

Placa de sensores (S): 

Variables medioambientales: 

uímicos:

 





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

S

S

M

M

M

S

S

M

M

S

M G

S M

Acústicos: 



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

S

e.g. ruido, ultrasonido.

etc.

Mote (M): Radio  µcontrolador 


31/03/2011

Elementos de una WSN (III) 

Gateway : 

S

S

S

M

M

M

Dos funciones: 



Pasarela de comunicaciones entre la WSN y el exterior Reprogramador de nodos sensores

S

S

M

M

S

S M

M

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


31/03/2011

Elementos de una WSN (IV) 

Una estación base: 

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

S

S

S

M

M

M

S

S

M

M

S

S M

G

M

nodos

Estación base


31/03/2011

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 bo as sumer idas 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


31/03/2011

Historia moderna 

La ley de Bell (1972):

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

Proyecto Smart Dust (1998):

) r e t u p m o c r e p e l p o e p ( g o l

year

cómo empaquetar en una mote de1mm3 un dispositivo sensorial autónomo (Dr. Kristofer s er, n vers a e a orn a, er e ey 

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

31/03/2011

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



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)


31/03/2011

Aplicaciones medioambientales 

Objetivo: Monitorización medioambiental  



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



No intrusiva No necesidad de infraestructuras Conocimiento preciso y actualizado

Ej: Great Duck Island 

Mainwaring et al., 2002; Szewczyk et al., 2004

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


31/03/2011

Automatización de edificios 

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



Desde edificios inteligentes hasta u-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. Redes de sensores inalámbricas: visión de los sistemas operativos

31/03/2011

Monitorización de infraestructuras 

Objetivo: cuantificar el grado en que los materiales se desgastan así como sus defectos estructurales



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

Ej. Sustainable bridges  



Proyecto europeo del 6PM Emplean sensores cableados para monitorizar puentes de ferrocarriles [Krüger and Grosse, 2004]


31/03/2011

Aplicaciones sanitarias 

Objetivo: diagnóstico de pacientes, respuesta a desastres, rehabilitación http://www.youtube.com/watch?v=V_UCF 3ZENv4&feature=related



Ej. CodeBlue 

Sensores que miden las constantes vitales de los pacientes desde sus hogares 

Source: http://fiji.eecs.harvard.edu/CodeBlue Redes de sensores inalámbricas: visión de los sistemas operativos

 

Frecuencia cardíaca Saturación de oxígeno Etc. 31/03/2011

Aplicaciones logísticas 

Objetivo: Monitorización de equipajes, contenedores, etc.





Localización exacta en cada momento del tiempo



RFID: otra tecnología adecuada

Ej: Intelligent Container 

Source:

Monitorización y planificación completamente automatizada de transportes [Behrens et al., 2006]

http://www.intelligentcontainer.com Redes de sensores inalámbricas: visión de los sistemas operativos

31/03/2011

Tipos de despliegues  





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



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


31/03/2011

wakeup

Funcionamiento

sleep Tiempo

http://www.youtube.com/watch?v=jtRv2PCeOyM Redes de sensores inalámbricas: visión de los sistemas operativos

31/03/2011

Contenidos 

Parte II:

Plataformas de hardware



Nodos sensores, placas sensoras y gateways



Arquitectura hardware del nodo sensor



Com onentes de hardware


31/03/2011

Nodos sensores 

Plataformas comerciales:

Eko (2010)



Plataformas de investigación:



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


31/03/2011

Placas sensores y gateway 

Placa de sensores 



Conjunto de sensores y actuadores de distinto tipo integrados en una única placa Conectada al nodo sensor a través del conector de expansión

distinto

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 31/03/2011

Arquitectura HW de un nodo sensor 

Microcontrolador



Radio



Memoria flash



LEDs



Conector de expansión



Fuente de energía


31/03/2011

Componentes de hardware (I) 

Microcontrolador: 

Arquitectura Harvard 

Memoria RAM (datos) 



Memoria ROM (programa) 

   

Típicamente 128 Kbytes

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



Típicamente 4 KBytes

Temporizadores  sincronización de tareas

Ej. 

Atmega 128 de Atmel (familia Mica)



msp430 Texas Instrument (familia Telos)


31/03/2011

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



o u ac 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/Docume nts/CC2420.pdf


31/03/2011

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


31/03/2011

Componentes de hardware (IV) 

Memoria flash:  



Externa al microcontrolador Almacenamiento no volátil (flash EEPROM) De distintos tipos  



Tamaño típico de almacenamiento  



512 Kbytes Dividida en páginas de 264 bytes (256 útil + 8 bytes de CRC)

Aplicaciones: 



NAND codifica datos como 1 NOR, codifica datos como 0

e.g. sistemas de ficheros, reprogramación, etc.

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


31/03/2011

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  Células solares, dinamos, etc.

LEDs: 

Tres leds: 



rojo, verde y amarillo

Función: 

Depuración de la aplicación


31/03/2011

Contenidos 

Parte III: Sistemas Operativos 

Arquitectura de software



Características



Modelos de ejecución y programación



Sistemas Operativos para nodos sensores



Programación de aplicaciones


31/03/2011

Sistemas Operativos 

Los nodos sensores incluyen un microcontrolador capaz de ejecutar tareas que requieren el acceso a elementos de hardware (sensores, memoria, radio, etc.) 



Dispositivos no dedicados

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


31/03/2011

Arquitectura de software

Abstraction level


31/03/2011

Características de los SSOO (I) 

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 (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


31/03/2011

Características de los SSOO (II) 

Multiplataforma 



Arquitectura monolítica 



Soportan un subconjunto de las plataformas disponibles 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)



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/2011

Modelos de ejecución  

Basado en eventos Basado en threads

Modelo basado en eventos

Modelo basado en threads 1

2

3

1 2

3

Pila compartida


Pila dedicada por thread

31/03/2011

Eventos vs. threads 

Comparativa modelo de ejecución/programación Paradigm

Event-based

Thread-based

Semantic

Run-to-completion

Preemptive

Resources

Shared stack

One stack per thread

Control flow

State machine

Linear

Programming flow

Unstructured, ad-hoc code, split-phase functions

Sequential

Synchronization

Asynchronous

Blocking

Concurrency model

Non explicit by eventhandlers

Explicitly by threads


31/03/2011

Ventajas e inconvenientes 

Basado en eventos 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  

Flujo de ejecución lineal Síncronos  bloqueantes


Una pila por thread  más recursos 

31/03/2011

Sistemas operativos para nodos sensores



TinyOS (1.x y 2.x) Contiki Mantis LiteOS



NanoOS

  


31/03/2011

Sistemas Operativos 

[Jason Lester Hill, 2002]

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

íntegramente en nesC  



No soporta todas las plataformas de nodos sensores

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



Actualmente versión 2.1.1 Versión 1.x y 2.x no son compatibles

Multiplataforma 



,

250 bytes of ROM 16 bytes of RAM

http://www.tinyos.net


31/03/2011

TinyOS 

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



¿ u ocurre con os even os que se interrumpen? 



1 2

3

Application (Configuration Component)

Se pierden

Modelo de programación basado en componentes

Configuration Component D

Implementation Component A

Implementation Component C

Implementation Component B

Configuration Component F

Implementation Component E


31/03/2011

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 imp ementaci 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


31/03/2011

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 e interfaces (wiring)

Application (Configuration Component)

Implementation Component A

Implementation Component C

X.Y  Z.Y 

Configuration Component D

Implementation Component B

Implementación o módulo: 

Implementación del componente



Interfaces que usa y proporciona este componente


Configuration Component F

Implementation Component E

31/03/2011

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 La implementación de los comandos se proporciona en el componente de nivel inferior

app

so

Eventos 

hw 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


31/03/2011

Uso de comandos y eventos en nesC 

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

Comandos call X.C (tipo1 arg1, tipo2 arg2,…,tipon argn)

app

proporciona la implementación del comando C so 

Eventos signal Y.E(tipo1 arg1,tipo2 arg2,…, tipon argn)

hw

Donde Y es un componente de implementación que proporciona la implementación del evento E Redes de sensores inalámbricas: visión de los sistemas operativos

31/03/2011

Planificación en TinyOS 

2 niveles de planificación:  Eventos: funciones de alta prioridad  Tareas: funciones de más baja prioridad


31/03/2011

Ejemplo: Blink application Configuration

Module

Interface


31/03/2011

TinyOS 2.x 2.x 

Iniciativa de muchas univers un iversidades idades colaborando juntas (Nov, 2006)



Objetivos:





Portabilidad



Facilitar la construcción de aplicaciones

El acceso al hardware se organiza en una arquitectura de abstracción de hardware (HAA): 

Hardwa Hardware re Indepe Independe ndent nt Laye Layerr (HIL) (HIL)



Hardwa Hardware re Adaptat Adaptation ion Laye Layerr (HAL) (HAL)



Hardwa Hardware re Pre Presen sentati tation on Laye Layerr (HPL) (HPL)


[Philip Levis, David Gay, Vlado Handziski, Jan Hinrich Hauer, Ben Greenstein, Martin Turon, Jonathan Huio, Kevin Klues, Cory Sharp, Robert Szewczyk, , Philip Buonadonnao, Buonadonnao, Lama Nachman, Gilman Tolleo, David Culler and Adam Wolisz, 2006]

31/03/2011

TinyOS 2.x 2.x 

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



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

El planificador maneja u una na 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 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”



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 Listen ing


31/03/2011

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 ueden const construir ruir modelo modeloss ener ético éticoss analític analíticos os


31/03/2011

Contiki

[Adam Dunkels, 2003]



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/



Características:  O en 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


31/03/2011

Modelo de ejecución de Contiki 

Híbrido: 



Estilo de programación 



Proporciona sintaxis secuencial y bloqueos condicionales

Al igual que los eventos los protothreads no requieren su propia pila 



Threads y eventos combinados en “protothreads”

Esto reduce significativamente el gasto de memoria

Soporte multithreading como librería


31/03/2011

Protothreads (I)  

La primera versión de Contiki usaba threads La segunda versión de Contiki incorpora los protothreads: “Protothreads are extremely lightweight stackless threads designed for severely memory constrained systems, such as small embedded systems or wireless sensor network 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


31/03/2011

Protothreads (II) 

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 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


31/03/2011

Macros para continuaciones locales (lc)

#define #define #define #define

LC_INIT(s) LC_RESUME(s) LC_SET(s) LC_END(s)

s = 0; switch(s) { case 0: s = __LINE__; case __LINE__: }


31/03/2011

Macros para protothreads (I): http://www.sics.se/~adam/contiki/contiki-2.1-doc/a00457.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; } #define PT_WAIT_UNTIL(pt, condition) \ do { \ LC_SET((pt)->lc); \ if(!(condition)) { \ return PT_WAITING; \ } \ } while(0) #define PT_WAIT_WHILE(pt, cond) #define PT_WAIT_THREAD(pt, thread)


PT_WAIT_UNTIL((pt), !(cond)) PT_WAIT_WHILE((pt), PT_SCHEDULE(thread)) 31/03/2011

Macros para protothreads (II): http://www.sics.se/~adam/contiki/contiki-2.1-doc/a00457.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) { \ 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)


31/03/2011

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

#define #define #define #define #define #define e ne #define #define #define

PROCESS_BEGIN() PT_BEGIN(process_pt) PROCESS_END() PT_END(process_pt) PROCESS_WAIT_EVENT() PROCESS_YIELD() PROCESS_WAIT_EVENT_UNTIL(c) PROCESS_YIELD_UNTIL(c) PROCESS_YIELD() PT_YIELD(process_pt) PROCESS_YIELD_UNTIL(c) PT_YIELD_UNTIL(process_pt, c) PROCESS_WAIT_UNTIL c PT_WAIT_UNTIL process_pt, c PROCESS_WAIT_WHILE(c) PT_WAIT_WHILE(process_pt, c) PROCESS_EXIT() PT_EXIT(process_pt) 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


31/03/2011

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); }

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; } Redes de sensores inalámbricas: visión de los sistemas operativos

Un protothread

Una lc (código final)

31/03/2011

Contiki: Blink application blink.c 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); } } PROCESS_END(); }

process.h #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)

pt.h #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;


31/03/2011

S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald, A. Torgerson, R. Han

Mantis 

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  

Multiplataforma 



Footprint : 





Mica2, MicaZ y Telos 500 bytes RAM y 14 KB ROM

Ventajas: 

Procesos largos no bloquean el sistema



Modelo de programación más sencillo que modelo basado en eventos

Inconvenientes:

Arquitectura de MANTIS http://mantisos.org/index/tiki-index.php.html



Sobrecarga debida a los intercambios de contexto



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


31/03/2011

Mantis: una aplicación sencilla #include #include #include #include

“led.h” “dev.h” “com.h”

simple_send.c

void start(void){ uint16_t delay; 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); }


31/03/2011

Resumen 

Modelos de ejecución: 

Basado en eventos: 

Modelo basado en eventos 1

TinyOS :

eventos y tareas 



Modelo basado en threads 2

3

1

Basado en threads: 

Mantis: prioridades



LiteOS: multithread

2

3

Híbrido: 

Contiki: protothreads

Un protothread manejador de bloqueante

es un evento Pila compartida


Pila dedicada por thread

31/03/2011

Modelos de programación Modelo 1: TinyOS 1.x (eventos)

Modelo 2: TinyOS 2.x (eventos)

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 task 8: } . … 10: event interfaceUsed.event(){ … } 11:}

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

Modelo 3: Contiki (protothreads)

Modelo 4: Mantis (threads/prioridades)

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 Interface 8: PROCESS_END(); 9: } 10: PROCESS_THREAD(PROCESS2,ev,data){…}

1: 2: 3: 4: 5: 6: 7:

void start (void) { // C code with MANTIS interface } // Threads void x(void{ // C code & MANTIS interface }


31/03/2011

Contenidos 

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

Arquitecturas portables



NOSA 



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


31/03/2011

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 sacri icin e icienc has been lon reco nized”. ”Programming Wireless Sensor Networks: Fundamental Concepts and State of the Art” Luca Mottola and Gian Pietro Picco ACM Computing Surveys, February 2010


31/03/2011

Orígenes de problemas 

Complejidad inherente al hardware: 

Recursos limitados de HW y energía



Heterogeneidad de los dispositivos



Número creciente de plataformas





Desarrollo de a licaciones: 

Ad-hoc, bottom-up, fuertemente acopladas



Programación cercana al sistema operativo



Portabilidad de aplicaciones reducida

Ausencia de estándares y arquitecturas abiertas: 

Protocolos de red y desarrollo de aplicaciones



Específicas de un escenario y/o plataforma particular


31/03/2011

Motivación 

Específicamente, los SSOO diseñados para nodos sensores: Exportan tanto la interfaz del hardware como la del propio SO o Límite incierto entre HW/SW

No existen herramientas de alto nivel (lenguajes de programación es ecíficos metalen ua es ca as de abstracción sobre el SO: o Las aplicaciones usan el mismo LP que el SO subyacente o Incremento de la complejidad

Heterogeneidad de los modelos de ejecución/programación o 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 Redes de sensores inalámbricas: visión de los sistemas operativos

31/03/2011

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 de aplicaciones genéricas y portables que puedan ser fácilmente transportadas a plataformas heterogéneas, incrementando así la productividad.


31/03/2011

Arquitectura actual App 1

App 1’

App 1’’

SO – WNS 1

SO –WSN 2

SO – WSN n

Mote – 3

Mote – m

Sensorboard 2

Sensorboard l

Mote – 1

Sensorboard 1

Mote – 2


31/03/2011

Arquitectura propuesta Aplicación 1

OSAL

SO – WNS 1

Mote – 1

Sensorboard 1

Mote – 2

SO –WSN 2

SO – WSN n

Mote – 3

Mote – m

Sensorboard 2

Sensorboard l


31/03/2011

Objetivos de la arquitectura 

Objetivos:   

portabilidad, mínima sobrecarga, productividad

Aplicación 1

OSAL

SO – WNS 1

Mote – 1

Sensorboard 1


Mote – 2

SO –WSN 2

SO – WSN n

Mote – 3

Mote – m

Sensorboard 2

Sensorboard l

31/03/2011

Características de la arquitectura (1/2) 

Arqu Arquit itec ectu tura ra centr centrad ada a en nodo nodo sensor (node-centric ) 

Defini Defi nirr el comportamiento de los nodos nod os ind indiv ividu iduale aless

Aplicación 1

OSAL

SO – WN WNS 1

Mote – 1

Mote – 2

Sensorb Sen sorboa oard rd 1



orma zac n ma m a em  



SO –WSN 2

SO – WSN n

Mote – 3

Mote – m

Sensorboard 2

Sensorboard l

ca usan o eor a e con un os

Organizar los componentes fundamentales y sus relaciones Facilitar la definición de arquitectur arquitecturas as portables

Enfoque Model Driv D riven en Architecture (MDA) Defi Defini nició ción n de aplicaci aplicaciones ones indepe independient ndientes es de la plataforma Defini Definición ción de un proces proceso o de tr transf ansformació ormación n Gene Genera raci ción ón de apli aplicaci caciones ones esp específ ecífica icass


31/03/2011

Características de la arquitectura (2/2) Aplicación 1



Multiplataforma

OSAL

SO – WN WNS 1



SO –WSN 2

SO – WSN n

Mote – 3

Mote – m

Sensorboard 2

Sensorboard l

Diseño multicapa Mote – 1



Mote – 2

Reusabilidad 

Hardware


s ema pera vo 



Abst Ab strracc accio ione ness de pr prog ogrram amaci ación ón de ap apli licac cacio ione ness po port rtab able les: s: 

Operating Sys System tem Abstraction Abstraction Layer (OSAL)



Capa Capa de Apli Aplica caci ción ón

Gener Gen eració ación n de códig código o en tiemp tiempo o de compil compilació ación n


31/03/2011

Características de la arquitectura (2/2) Aplicación 1



Multiplataforma

OSAL

SO – WN WNS 1



SO –WSN 2

SO – WSN n

Mote – 3

Mote – m

Sensorboard 2

Sensorboard l

Diseño multicapa Mote – 1



Mote – 2

Reusabilidad 

Hardware


s ema pera vo 



Abst Ab strracc accio ione ness de pr prog ogrram amaci ación ón de ap apli licac cacio ione ness po port rtab able les: s: 

Operating Sys System tem Abstraction Abstraction Layer (OSAL)



Capa Capa de Apli Aplica caci ción ón

Gener Gen eració ación n de códig código o en tiemp tiempo o de compil compilació ación n


31/03/2011

Implementación de OSAL Aplicación (APP) Sensor Node Open Services Abstraction Layer (SN-OSAL)

API de SN-OSAL

SN-OSAL Translation Engine pre-compilador de SN-OSAL (osalc)

osal2tinyos1x

osal2tinyos2x

osal2contiki

Sistema Operativo (O)

TinyOS 1.x

TinyOS 2.x

Contiki

Hardware (H) Familia Mica

Familia Telos


ESB SKY 31/03/2011

Interfaz de SN-OSAL 

La interfaz de SN-OSAL se compone de: 1. 2. 3.

Primitivas o servicios de alto nivel que gestionan operaciones básicas sobre los dispositivos físicos de los nodos sensores Constructores del lenguaje Espacio de nombres y palabras reservadas


31/03/2011

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: CPU: Comunicación: Almacenamiento : Procesos y planificación: Depuración:

sensores y actuadores sistema de reloj y temporizadores envío y recepción de datos sistema de ficheros gestión de procesos operaciones sobre LEDs


31/03/2011

Ejemplo: primitivas SN-OSAL  I/O int8_t osal_io_open (unsigned char device); int8_t osal_io_read (int8_t desc, uint16_t data);  Gestión del tiempo int8_t osal_timer_start(int8_t num,int8_t granularity,uint8_t frequency); int8_t osal_timer_stop (int8_t desc);  Comunicación n _ osa _ne _sen u n int8_t osal_net_getId ();

_

a

ress, vo

a a, u n

_

eng

;

 Leds void osal_led_on (uint8_t led); void osal_led_off (uint8_t led);  Procesos y planificación osal_ task* osal_task_current(); int8_t osal_task_exit();  Sistema de ficheros int8_t osal_fs_open (char *filename, uint8_t mode) int8_t osal_fs_read (uint8_t fd, char *buffer, int8_t length)


31/03/2011

λ T:SN-OSALI OI j SN-OSALI

TinyOS 1.x

TinyOS 2.x

Contiki

osal_led_on(LED_RED)

call Leds.redOn()

call Leds.Led0On()

leds_on(LEDS_RED)

call Leds.Led1Off()

leds_off(LEDS_GREEN)

osal_led_off (LED_GREEN) call Leds.greenOff()

desc=osal_timer_start (*, SEC,ONE_SAMPLE)

call TimerX.start( call TimerX.startOneShot( etimer_set(&tx, TIMER_ONE_SHOT, \1*1000) \1*1000) \1*CLOCK_SECOND)

*, _ _ SEC, REPEAT_SAMPLE)

. TIMER_ONE_SHOT, \1)

\1*1000)

// go into a loop _ , \1*CLOCK_SECOND)

osal_io_open(TEMP)

call TempControl.init()

ф

temperature_sensor.activate()

osal_io_close(TEMP)

call TempControl.stop()

ф

temperature_sensor.deactivate()

osal_io_read(TEMP,*)

call TempControl.start() call Temp.getData()

call Temperature.read() data=temperature_sensor.value(0)

osal_net_getId()

TOS_LOCAL_ADDRESS

TOS_NODE_ID

node_id

osal_net_send(*,*,*)

if (call SendX.send( \1,\3,\2 )==SUCCESS){ osal_radio_busy=TRUE;}

if (call AMSendX.send( \1,\2,\3 )==SUCCESS){ osal_radio_busy=TRUE;}

rimebuf_clear() rimebuf_copyfrom(\2,\3) addr.u8[0]=addr.u8[1]=(\1) Y_send(X_conn,&addr)

.


31/03/2011

SN-OSAL Translation Engine 

Proceso de transformación (TP) TP(APPSN-OSAL) =

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

si SO = {Contiki}

donde: .

omp ac n e a ap cac n

SN-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 → {APPo }, i = {T1, T2, Contiki} i


31/03/2011

Sensor Node Domain Specific L anguage

(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

homogéneos 

Lenguaje específico de dominio Metalenguaje del lenguaje de programación C



Define la sintaxis y la semántica de las aplicaciones


31/03/2011

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: 

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


31/03/2011

VisualOSAL 

VisualOSAL es un entorno de desarrollo gráfico de aplicaciones

de alto nivel construidas sobre SN-OSAL

Capa de Aplicación (APP) VisualOSAL



Características:  

Guiar el proceso completo de desarrollo de aplicaciones erm r espec car ap cac ones e manera v sua : 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) Código independiente (SN-DSL)

o

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

o



WSN ARQUITECTURA

Prototipo en desarrollo


31/03/2011

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


31/03/2011

Desafíos (I) 

Complejidad inherente al hardware: 

Recursos limitados de HW y energía 

 



Heterogeneidad de los dispositivos Número creciente de plataformas

Desarrollo de aplicaciones:  

Ad-hoc, bottom-up, fuertemente acopladas Programación cercana al sistema operativo 

 



Búsqueda de fuentes alternativas de energía

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


31/03/2011

Desafíos (II) 



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

Internet (6lowpan)



Middleware de comunicaciones



Escalabilidad, heterogeneidad, etc.



Seguridad

Simulación de aplicaciones de redes de sensores 

Depuración de aplicaciones en un entorno PC


31/03/2011

Roadmap de tecnologías básicas


31/03/2011

Tendencias 

Mercado de RFID y WSN hasta 2010

31/03/2011

NOTA: USN: Ubiquitous Sensor Networks Redes de sensores inalámbricas: visión de los sistemas operativos

16/11/2010

Líneas futuras de investigación 

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


31/03/2011

Lista de trabajos 

Sistemas operativos:  



OSAL: 

 



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 osal2mantis: portar OSAL al sistema operativo mantis osa 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


31/03/2011

Bibliografía (I) [1] Sensors everywhere. Fundación Vodafone. (online: http://vodafone.es/fundacion/fundacion.vodafone.es/VSharedClient/FundacionVodafon e/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 ay, p ev s, o ert von e ren, att e s , r c rewer, av u er. [5] TinyOS programming by Phillip Levis (online: http://www.tinyos.net/tinyos2.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. Redes de sensores inalámbricas: visión de los sistemas operativos

31/03/2011

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‡, Gilman Tolleo, David Culler, and Adam Wolisz. [10] Versatile low power media access for wireless sensor networks by Joseph Polastre, Jason Hill 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) [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 networks by Chalermek Intanagonwiwat , Ramesh Govindan , Deborah Estrin


31/03/2011

wsn-doctorado-2011_v2

Recommend Documents