tiny os on sensor networks

Sensor Networks

vasanza

https://www.linkedin.com/in/vasanza


http://vasanza.blogspot.com/


TinyOS: An Operating System for Sensor Networks vasanza

• Presentar el modelo de diseño y programación de TinyOS, incluido el soportepara la concurrencia y la composición flexible.

• Evaluar TinyOS en términos de su rendimiento, pequeño tamaño, peso ligeroconcurrencia, flexibilidad y soporte para bajo consumo de alimentación.

• Mostrar la experiencia de usar TinyOS a través de tres aplicaciones:• Vigilancia del medio ambiente.• Tracking de objetos.• Procesador de consultas.

• Mostrar un proyecto de ESPOL módulos de comunicación que usan TinyOS.

Objetivos de la Presentación






Redes de Sensores

• Hardware pequeño• Flexible• Bajo consumo de energía• Bajo costo• Fácil interacción o comunicación con otros sensores, actuadores.

Actualmente: Sistemas Single-Chip que integran una baja potencia CPU y lamemoria, radio o comunicación óptico.

• Red de minicomputadores o nodos.• Provistos de sensores.• Colaboran en una tarea común.• Pueden tener un Gateway.






¿Que es TinyOS?






¿Por qué TinyOS?• Recursos Limitados:

• Bajo costo y bajo consumo de energía.• Un procesador 1-MIPS (Microprocessor without Interlocked Pipeline Stages)

con arquitectura RISC (Reduced instruction set computing ) y decenas deKilobytes de almacenamiento.

• Reactive Concurrency:• Muestreo de sensores• Procesamiento de datos local• Datos de enrutamiento para otros nodos• Tareas de procesamiento distribuido (estadística agregación o

reconocimiento de operaciones).• Respuestas en tiempo real.

• Flexibilidad:• La variación en el hardware y las aplicaciones.• OS independiente de la frontera entre hardware y software.

• Baja potencia:• Funcionamiento continuo.• Gestión de energía y ciclo de trabajo.






Características

• Concurrencia orientada a eventos, basados en interfaces de fase dividida.• Eventos asíncronos y tareas de cómputo.• Modelo de programación basado en componentes, NESC (dialecto del C).• No es un sistema operativo tradicional.

• Marco de programación para sistemas embebidos.• Conjunto de componentes que permiten la construcción de un sistema

operativo en una aplicación específica.• Una aplicación típica es alrededor de 15K en tamaño, de las cuales el sistema

operativo base es de aproximadamente 400 bytes.






Características• Conjunto de componentes, cada uno de los cuales es independiente entidad

computacional:• Comandos.- petición a un componente para llevar a cabo algún servicio. Ej.:

lectura de sensores.• Eventos.- Indica la finalización de ese servicio. Pueden ser asíncronos por

interrupciones de hardware.• Tareas.- comandos y controladores de eventos pueden enviar una tarea, una

función ejecutada por el planificador TinyOS en un momento posterior.Representan concurrencia interna dentro de un componente.

Abstrae los recursos de hardware como componentes. 1.- Comando getData ().2.- El sensor hará que la señal más tarde, DataReady () evento cuando se da la

interrupción de hardware.

Actualmente se incluye: redes de un solo salto, enrutamiento, administración deenergía, temporizadores, y el almacenamiento no volátil.






Características






Modelo de componente• Modelo de programación proporcionado por el idioma NESC.• Encapsulan un conjunto específico de servicios mediante interfaces.• Conjunto de componentes de sistemas reutilizables con un programador de

tareas.

• Interfaces proporcionadas aparecen arriba el componente TimerM e interfaces utilizadas están por debajo.

• Flechas hacia abajo representan los comandos y las flechas ascendentes representan eventos.






Modelo de componente• Un componente tiene dos clases de interfaces: las que ofrece y los que utiliza.

Para interactuar directamente con otros componentes.• Un componente puede proporcionar o utilizar el mismo tipo de interfaz varias

veces.






Modelo de componente• Módulos: proporcionan código y extensiones para llamar e implementar

comandos y eventos. Declara variables de estado privada y buffers de datos.• Configuraciones: usados para conectar otros componentes, conectar interfaces

proporcionadas por otros componentes.






Modelo de componente

• Un componente puede invocar una interfaz sin referirse explícitamente a suaplicación, permitiendo realizar interposición mediante la introducción de unnuevo componente que utiliza y proporciona la misma interfaz.

• Las interfaces pueden ser cableados en múltiples ocasiones.






Modelo de componente

• Código Sincrónico (SC): código que sólo es accesible desde tareas.• Código asíncrono (AC): código que es accesible desde al menos una interrupción

manejador.






Recursos limitados• El tamaño y la estructura de las aplicaciones TinyOS.• El compilador debe reducir el tamaño del código a través de la optimización.






• Ciclos de CPU, tanto de trabajo como de cruce de frontera para la gestión de eventos de reloj. Optimización reduce el recuento de ciclo total en un 38%.

Recursos limitados






Aplicaciones






AplicacionesMonitoreo del hábitat en Great Duck Island

*Autonomía 7-9 meses.*Sensores:- Luz.- Temperatura.- Humedad relativa.- Presión.- Infrarroja.*Internet conexión vía satélite.* Muestre cada 68 s.* 35 uA en estado de bajo consumo, en comparación con 18 a 20 mA* 1,2 millones de lecturas en 4 meses.






AplicacionesTracking de objetos

*Detectar.*Localizar.* Seguimiento.* Sensor de campo magnético.* servicios distribuidos:- Enrutamiento.- Intercambio de datos.- Tiempo de sincronización.- Localización.- Gestión de energía.- Filtrado de sensor.






Aplicaciones

Terremoto y tsunami de Japón, 11 de marzo de 2011.






Aplicaciones





c1

S4

S5

S1

S3

S2

S7

S8

S6






Estación en tierraEthernet

/ GSM

SERVIDOR

GPRS / WIFI

Red Mesh de Boyas Sensor en mar.






MAR

BOYA

BOYA

BOYA

BOYA

Estación en tierra






BEAGLEBONE

IN D

C 1

2 o

24

VD

C

BORNERAS OUT Digital 0-5Vdc

REGULADOR

RS232

SOCALO BEAGLEBONE

SOCALO BEAGLEBONE

BORNERAS IN Analógicas 0-5Vdc

Ethernet XBEE

GSM






DATALOGGER Ethernet

Sensores

Salidas Digitales

SENSORES MÓDULO UNIDADES

Acelerómetro + Giroscopio(AG)

Mpu-6050Grad, Grad/Seg

[i2c]

Temperatura del Agua (STA)

DS18B20ºC

[1-Wire]

Humedad y Temperatura del

Aire (SHTA)DHT11

0-100% (Humedad Relativa) y ºC

[Digital-DHTlib]

Velocidad del Viento (SV)

HYXC-FSVm/s

[Analógico 0-5VDC]

Luz (SL) TSL2561Watts/(m^2 x Hora)

[i2c]

Brújula Magnética Cmps03Grad[i2c]







. Comparativa en mediciones de Temperatura Aire y Humedad Relativa Aire entre ENKI e INAMHI

ENKI INAMHI

HoraTemperatura

Aire[°C]Humedad Relativa

Aire[%]

Temperatura

Aire[°C]

Humedad Relativa Aire[%]

13:00 26 62 26,75 66,5

14:00 27 60 27,8 62

15:00 28 58 28,4 62,3

16:00 28 62 28,1 64

17:00 26 61 27,3 63,6

18:00 26,75 66 27,5 67,5

19:00 26,75 68 27 70,2

20:00 26 69 26,5 72

21:00 26 66 25,6 72







Variable Física Porcentaje Error

Temperatura Aire 9 %

Humedad Relativa Aire 12 %

ENKI INAMHI

Temperatura Aire[°C]


Temperatura Aire[°C]


26,722 63,555 27,216 66,677






Referencias

• Philip Levis, Sam Madden, Joseph Polastre, Robert Szewczyk, KaminWhitehouse, Alec Woo, David Gay, Jason Hill, Matt Welsh, Eric Brewer and DavidCuller. TinyOS: An Operating System for Sensor Networks.http://users.eecs.northwestern.edu/~peters/references/TinyOSSpringer05.pdf

• Digi International Inc. Xbee-PRO 900HP. http://www.digi.com/products/xbee-rf-solutions/modules/xbee-pro-900hp

• Libelium. Smart World. http://www.libelium.com/• TinyOs Alliance. http://www.tinyos.net/• Romero, G., Salazar, C., & Asanza, V. (2015). Desarrollo de un Prototipo de

Sistema Hidrometeorológico. Revista Tecnológica-ESPOL, 28(5).

http://users.eecs.northwestern.edu/~peters/references/TinyOSSpringer05.pdf

http://www.digi.com/products/xbee-rf-solutions/modules/xbee-pro-900hp

http://www.libelium.com/

http://www.tinyos.net/

http://www.rte.espol.edu.ec/index.php/tecnologica/article/view/455





tiny os on sensor networks

Engineering