División de Ciencias Básicas e Ingeniería

Departamento de Ingeniería Eléctrica

Licenciatura de Ingeniería Electrónica

Evaluación de la tecnología NEST

Presentado por los alumnos:

Hernández Simón Marcos 200215403 Lima Carmona David 97217166

Asesor: M. en C. Agustín Suárez Fernández

México D.F. a Junio del 2004

2

A nuestros padres y hermanos

3

INDICE

INDICE.............................................................................................................................3

INTRODUCCIÓN ...........................................................................................................5

TECNOLOGÍA NEST....................................................................................................9 MPR400 (MICA2).......................................................................................................................10 MPR500 ( MICA2DOT ) ...........................................................................................................16 Micrófono......................................................................................................................................22 Sounder..........................................................................................................................................24 Luz y temperatura ........................................................................................................................25 2-Ejes sensores de aceleración ..................................................................................................26 2-Ejes sensores de campo magnético .......................................................................................27

SOFTWARE .................................................................................................................29

Instalación .................................................................................................................................................. 29

Primeros Pasos .......................................................................................................................................... 34

TinyOS y NesC.......................................................................................................................................... 36

Implementación ........................................................................................................................................ 36 Modelo de Concurrencia ............................................................................................................36

Obteniendo Datos ..................................................................................................................................... 38 Programa SerialForwarder .........................................................................................................38

Inicio de la interfaz gráfica Oscilloscope ........................................................................................... 39

Datos del sensor que se transmiten de la radio al puerto serial................................................... 40

Enrutamiento multivías (Multihop Routing ) ................................................................................ 43

Surge Demo................................................................................................................................................ 43

NESC .............................................................................................................................45

Interfaces .................................................................................................................................................... 46

Especificación de los componentes. ..................................................................................................... 47

Módulos ....................................................................................................................................................... 47

Llamando comandos y señalización de eventos. .............................................................................. 48

Task.............................................................................................................................................................. 50

Declaración Atómica. .............................................................................................................................. 50

Configuraciones. ....................................................................................................................................... 50

Wiring (alambrando, conectando)....................................................................................................... 51

4

Concurrencia en NesC ............................................................................................................................ 52

Aplicaciones en NesC............................................................................................................................... 54

Miscelánea.................................................................................................................................................. 54

TINYDB .........................................................................................................................56

Tiny Application Sensor Kit (TASK) .................................................................................................. 56

TinyDB ........................................................................................................................................................ 57

CONCLUSIONES........................................................................................................68

REFERENCIAS............................................................................................................71

5

INTRODUCCIÓN Sistema dedicado Una forma sencilla de explicar la diferencia entre sistema dedicado y una computadora de propósito general, es con la interfaz de usuario. Una computadora de propósito general cuenta normalmente con un monitor, un teclado y un ratón u otro dispositivo apuntador conectado a ella. Un sistema dedicado puede que ni tenga una interfaz de usuario o puede que disponga de una interfaz primaria más especializada, como un único botón, una pantalla táctil o un gran panel de control. Los sistemas dedicados que carecen de interfaz de usuario pueden permanecer simplemente atentos a una red o a un sensor, que sencillamente recopila datos o envía y acepta distintos comandos. Posiblemente, puede conectar un monitor y un teclado a un sistema dedicado, pero no es el modo habitual de operar. Normalmente, se conectarían únicamente para la configuración y la depuración. El método más contundente para determinar si un sistema por computadora encaja en la categoría de “propósito general o “dedicado”, requiere un examen de la misión del sistema en la vida. Los sistemas dedicados tratan de ser soluciones rentables para problemas específicos o para conjuntos particulares de ellos. La misión de la computadora de propósito general se parece mucho a una navaja suiza. Al igual que esta, la computadora se distribuye desde la fábrica sin una misión concreta. La navaja suiza puede cortar, serrar, sajar, atornillar, descorchar, punzar y dispone de pinzas. Asimismo, la computadora de propósito general puede usarse para procesar las nóminas, para jugar a Quake, navegar por Internet y para otras muchas cosas más. Un sistema dedicado tiene una misión limitada. Puede hacer hasta 10 cosas diferentes, pero nunca superará esa cantidad. Por ejemplo, la computadora integrada en algunos automóviles probablemente regule la gasolina, reúna la telemetría fundamental del motor y espere los comandos de un servicio técnico al mismo tiempo, pero eso es todo lo que puede hacer ( no importa la potencia que tenga o si vamos a jugar Quake con ella). Si bien una computadora dedicada tiene una misión limitada, ello no significa que dicha misión no se desarrolle. Por ejemplo, los clientes pueden actualizar los routers Cisco con la última versión de software aparecida. No sólo se solucionan los errores en las versiones nuevas, sino que también puede incorporarse software nuevo, lo cual incrementa la utilidad del sistema dedicado. Otro ejemplo interesante de la misión de un sistema dedicado que se desarrolla según dictan las circunstancias, es el de las naves especiales Voyager 1 y 2 de la NASA. Voyager 2, la primera de las naves que se lanza, inicia su viaje el 20 de agosto de 1977. Voyager 1 se lanzó semanas más tarde, el 5 de septiembre, en una trayectoria más rápida. Al principio, ambas naves sólo explorarían dos planetas (Júp iter y Saturno), pero el increíble éxito de aquellos dos primeros encuentros y el buen estado de la nave, indujo a la NASA a ampliar la misión de Voyager 2 hasta Urano y Neptuno. A medida que la nave se desplazaba por el sistema solar, la reprogramación por control remoto

6

dotó a las Voyager de mejores capacidades que las que tenía antes de abandonar la Tierra. Sensores inalámbricos En el contexto de los sistemas dedicados encontramos una tecnología relativamente nueva, que son los sensores inalámbricos. Esta tecnología además de poseer las características de los sistemas dedicados, también comparte las capacidades de un sistema distribuido, pues permite repartir una tarea a diferentes unidades. Pero hablemos un poco más de la tecnología de la red de sensores.

Las nuevas tecnologías están facilitando que cada vez haya más sensores a nuestro alrededor, capaces de procesar enormes cantidades de datos para ayudar a mejorar el funcionamiento de las fábricas, el control de los procesos productivos, el mantenimiento de las cosechas, o incluso para detectar terremotos.

Los sensores son cada vez más comunes en nuestra vida diaria. Un coche, por ejemplo, utiliza docenas de ellos para permitirnos controlar sus funciones básicas. Sin embargo, este tipo de sensores están muy limitados, puesto que, colocados estáticamente en un lugar, adolecen de la capacidad de analizar o actuar sobre los datos que detectan, y simplemente, su misión se limita a enviar las mediciones que han registrado a un procesador central.

En definitiva, los sensores todavía podrían dar mucho más de sí. Así lo cree toda una industria tecnológica que está detrás de ellos, y son cada vez más las empresas y los equipos de investigadores que trabajan en el desarrollo de este tipo de dispositivos.

La multinacional de los microprocesadores Intel tiene abiertas varias líneas de experimentación, como por ejemplo, la creación de sistemas en centros de atención médica para ayudar a pacientes con problemas de memoria, y avisarles así del momento en el que tienen que alimentarse. En la primavera de 2002, el laboratorio de investigación de Intel en Berkeley, en colaboración con el Colegio del Atlántico en Bar Harbor y la Universidad de California comenzaron en la isla de Great Duck, en la costa norteamericana de Maine, un proyecto que utilizaba redes de sensores para monitorear los microclimas y los nidos de un tipo de ave conocido como petrel de las tormentas, y conocer, entre otras cuestiones, por qué prefieren esta isla y no otras. De esta manera, los investigadores tratan de observar el comportamiento de estos animales sin irrumpir de manera agresiva en su hábitat.

En los jardines botánicos Huntington, en San Marino, California, donde se conservan unas quince mil especies de plantas raras, investigadores del Laboratorio de Propulsión a Chorro (JPL) de la NASA trabajan con una red de sensores web para controlar el calor, la humedad o el estado del suelo en el que viven las cicadias, un tipo de planta que necesita unas condiciones muy específicas. Cada pocos minutos, los sensores se actualizan entre ellos, enviando toda la información a los responsables de las plantas.

Los investigadores hablan ya de una nueva generación de sensores, capaces de organizarse así mismos y conectarse en red de manera inalámbrica, y que podrían generar una revolución similar a la que tuvo la aparición de Internet en los años 70 del

7

siglo pasado. Potencialmente, dicen los expertos, estos sensores podrían generar redes que vigilaran la mayoría del planeta, desde los modelos de compra de la gente hasta los movimientos de personas sospechosas. Si a eso le unimos los avances realizados en Inteligencia Artificial, algunos expertos vaticinan que en los próximos cinco años podrían incluso crearse sensores con inteligencia compleja. "La mayoría del tráfico de datos ya no se realizará entre seres humanos, sino entre estas cucarachas de silicio", avanza Bob Metcalfe, investigador de la empresa Ember, con sede en Boston, que trabaja en el desarrollo de este tipo de sensores.

Como vemos, las posibilidades de estos sensores son enormes. Y como suele pasar con una tecnología que tiene enormes posibilidades, las esferas militares no se quedan al margen. La Agencia de Proyectos de Investigación Avanzados de Defensa (DARPA), la misma institución dependiente del Departamento de Defensa estadounidense que tuvo un papel determinante en la creación de la red de redes, está apostando por su creación y desarrollo, financiando este tipo de investigaciones. Evidentemente, los investigadores de DARPA trabajan en tecnologías con usos eminentemente militares, aunque como en el caso de Internet, dichas tecnologías suelen adaptarse posteriormente en la vida civil.

En este caso, se trataría de seguir el concepto de "polvo inteligente", una idea desarrollada hace cinco años por investigadores de dicha agencia, que consiste en diseminar en el campo de batalla miles de diminutos sensores conectados por una red inalámbrica. Así, estos sensores controlan los movimientos de las tropas y los vehículos del enemigo sin alertarle de su presencia. Al tratarse de una red autoorganizada e inteligente, los sensores filtran toda la información en bruto que reciben antes de enviar los descubrimientos importantes a la base central de operaciones. De esta manera, los mandos militares podrían evitar posibles bajas en sus tropas al detectar por ejemplo posibles amenazas de armas químicas o biológicas.

De hecho, el ejército de los Estados Unidos ya ha experimentado en la vida real con estos prototipos. Hace tres años, se lanzaron desde un avión a una carretera de la ciudad californiana de Twentynine Palms varios tubos conteniendo entre 10 y 20 de los denominados sensores "Rene", que consiguieron establecer la velocidad y dirección de los vehículos que circulaban a partir de las vibraciones del suelo.

Este tipo de sensores inteligentes, conocidos como "motas", han contado para su creación con la colaboración de la Universidad de California en Berkeley y la empresa Intel, dentro del denominado Centro para la Investigación sobre Tecnología de la Información en Interés de la Sociedad (CITRIS). Los investigadores de este centro persiguen la creación de dispositivos inalámbricos de bajo coste que puedan llegar a ser tan diminutos como un grano de arena.

Por el momento han desarrollado ya sensores inalámbricos, denominados "Spec", que contienen chips miniaturizados a menos de un milímetro cúbico. "Se trata de una nueva clase de ordenador", afirma David Culler, profesor de esta universidad y director de un laboratorio de investigación específico en Intel para estos dispositivos, que predice que en diez años esta clase de ordenadores "estarán ya consolidados, con lo que tendremos una nueva clase de desafíos". Para facilitar la organización autónoma en red, han desarrollando además un estándar en código abierto, denominado Tiny, para permitir de esta manera que otros equipos de investigadores puedan mejorar sus

8

características. De hecho, según Culler "existen más de cien grupos en todo el mundo que están utilizando la combinación del sistema operativo TinyOS y la base de datos TinyDB".

Para esta tecnología hay proyectos de aplicaciones comerciales, por ejemplo, la empresa York International realiza sistemas de ventilación para más de 60 mil clientes, y planea para los próximos cinco años instalar sensores en red en sus aparatos para monitorear automáticamente las temperaturas y enviar los datos a la central. En este sentido, compañías como la cadena de supermercados británicos Tesco o la compañía petrolífera Shell han instalado sistemas de primera generación para controlar y monitorear el estado de los expendedores de gasolina en sus estaciones de servicio.

De todas formas, el tema no consiste sólo en conseguir datos, sino en responder a cuestiones específicas, y todavía quedan bastantes cuestiones tecnológicas que resolver, como la implantación de estándares de este tipo de sensores inalámbricos. Los investigadores trabajan con distintas frecuencias de radio para que los sensores se identifiquen. También existe el problema de la energía que les hace funcionar, y para ello ya se barajan distintas soluciones de tipo solar o cinético, o incluso se piensa en el desarrollo de diminutas baterías para estos minúsculos sensores. Y dado que se trata de elementos que utilizan componentes informáticos, la consolidación de un estándar para el software y el hardware de estos sensores se considera también esencial.

TinyOS

Sobre el sistema operativo para esta tecnología podemos decir que el TinyOS es un sistema operativo de código fuente abierto diseñado para las redes de sensores inalámbricas . Ofrece una arquitectura basada en componentes, es decir que tiene porciones de código específicas con funciones y características, las cuales solo tienen que ser invocadas para ser usadas, de cierta manera es parecido a programación orientada a objetos, que permita la innovación y la puesta en práctica rápida mientras que reduce al mínimo el tamaño de código según las limitaciones de la memoria inherentes en las redes de sensores. La biblioteca componente de TinyOS incluye protocolos de red, servicios distribuidos, controladores para los sensores, y las herramientas para la adquisición de datos, los cuales pueden ser usados tal como están o modificarlos para un uso particular. El modelo event-driven de la ejecución de TinyOS permite un manejo óptimo de la energía, permite la flexibilidad de calendarizar necesaria por la naturaleza imprevisible de la comunicación inalámbrica y de los interfaces físicos del mundo.

TinyOS ha sido portado a docenas de plataformas y numerosos tipos de sensores. Una comunidad amplia lo utiliza en la simulación para desarrollar y para probar varios algoritmos y protocolos. Hay varios proyectos que se desarrollan en diferentes partes del mundo.

9

TECNOLOGÍA NEST La red inalámbrica de sensores la podemos esquematizar como se muestra en la siguiente figura:

Figura 1.1. Red inalámbrica de sensores

Cada nodo esta constituido por una tarjeta que se encarga de la transmisión-recepción y es la unidad básica de tecnología NEST y por otra tarjeta de sensores o de adquisición de datos, en nuestro caso utilizamos la tarjeta de sensores, cada nodo transmite la información obtenida hacia una tarjeta conectada directamente a una PC.

Tarjeta Radio / Procesador “Motes” (MPR Series) Las tarjetas de Radio / Procesador genéricamente denominadas “motes” son diferentes plataformas de hardware, en nuestro caso utilizamos la tarjeta correspondiente al MICA2 y otra conocida como MICA2DOT, en la figura 1.2 se muestran las diferentes tarjetas de Crossbow Technology con una breve descripción de sus características.

10

MPR400 (MICA2)

La tarjeta MICA2 que utilizamos corresponde al MPR400 (Figura 1.3) que utiliza un microcontrolador Atmega 128L de 8 bits, que cuenta con un cristal a una frecuencia máxima de 7.3827 MHz, con 128 Kbytes de memoria Flash, 4 Kbytes de memoria SRAM, y 4 Kbytes de memoria EEPROM, tiene un bus SPI y 2 UARTs, cuenta con 8 canales para convertidores A/D de 10 bits, con un voltaje de operación de 2.7 a 5.5 V.

Figura 1.2. Diferentes plataformas de hardware para la tarjeta emisor-receptor de la red.

Figura 1.3. MPR400 ó también llamado MICA2.

Cuenta, además, con un radio transceptor a 916 MHz basado en un Chipcon CC1000 que es un emisor-receptor de UHF diseñado para aplicaciones inalámbricas de muy baja potencia, alrededor de 16 mA para transmisión y 9 mA para recepción, con bandas de frecuencia de 315, 433, 868 y 915 MHz, pero puede ser programado para operar en otras frecuencias en el rango de 300 a 1000 MHz.

11

El CC1000 proporciona comunicación bidireccional a 38.4 KBps, codificación

basada en hardware realizada en el código de línea Manchester, bit de sincronía integrado y modulación FSK con un rango de datos de hasta 76.8 Kbaud. Los parámetros de funcionamiento principales de CC1000 se pueden programar por medio de un bus, lo que hace al CC1000 muy flexible para realizar fácilmente la transmisión-recepción. En un sistema típico el CC1000 puede ser utilizado junto con un microcontrolador y algunos componentes pasivos externos, este transceptor tiene un bus SPI para transferencia de datos, en la figura 1.4 se muestra un diagrama a bloques del CC1000.

Figura 1.4. Diagrama a bloques simplificado del CC1000

Otro aspecto importante en esta tarjeta es la antena, puesto que es un componente fundamental para la recepción-transmisión, hay que considerar que el radio del MICA2 es capaz de operar en múltiples canales, dentro de la banda prevista de operación. El MPR400 puede operar en dos regiones de frecuencia: 868-870 MHz (hasta 4 canales) y 902-928 MHz (hasta 54 canales). El número real de canales posibles es más alto para todos los motes MICA2. Sin embargo, se recomienda que el espaciamiento entre canales adyacentes deba ser por lo menos de 500 KHz para evitar interferencia entre canales contiguos de modo que se reduce el número de canales disponibles. La longitud de la antena para el MPR400 que opera a una frecuencia de 916 MHz, debe de ser de un cuarto de la longitud de onda ( λ ) dada por:

λ = c / f

Donde: c = velocidad de la luz = 3 x 1010 cm

f = frecuencia = 916 MHz Por lo que:

λ = c / f = 32.7511 cm λ / 4 = 8.1878 cm

en este caso la longitud de la antena esta dada en pulgadas y es de 3.2 in y corresponde a la parte número 8060-0010-01, disponible en Crossbow technology así como el

12

mecanismo para conectar la antena al MPR400 que es la parte número 8060-0011-01, en la figura 1.5 se esquematiza a estos dos componentes.

(a)

(b)

Figura 1.5. (a) Antena de longitud de 3.2 in parte número 80-0010-01. (b) Antena con el conector parte número 80-0010-01.

El radio del MICA2 puede ser ajustado para diferentes rangos de potencia de

salida, el registro en el radio que controla la potencia de la radio frecuencia es designado PA_POW en la dirección 0x0B, los valores y sus salidas correspondientes de RF se proporcionan en la tabla 1.1. Esta tabla muestra el valor programable más cercano para la potencia de la salida en pasos de 1 dBm, para el modo de baja potencia las características del Chipcon CC1000 indican que el PA_POW debe ser fijado en 00h [0x00] para la corriente mínima de la salida. El radio del MICA2 también proporciona una medida de la intensidad de la señal recibida referida como RSSI ( Received Signal Strength Indicator ). Esta señal es medida en el ADC del canal 0 y esta disponible para el software. Algunas versiones del TinyOS proporcionan esta medida automáticamente, y otras deben ser habilitadas por el usuario.

El MPR400 tiene una memoria flash serial externa de 512 K byte, que

corresponde al chip AT45DB041B, útil para el almacenamiento de datos, es usada por los diferentes sensores y por la aplicación TinyDB con ese propósito. Además de la memoria central, el AT45DB041B también contiene dos buffers de datos de memoria SRAM de 264 bytes cada uno. Los buffers permiten la recepción de datos mientras que una página en la memoria central se está reprogramando, así como la lectura o la escritura de una secuencia de datos continua. Este dispositivo consume 15 mA cuando almacena datos en la memoria.

Potencia (dBm)

PA_POW 915 MHz

Consumo de corriente

Típico (mA)

Rango (pies)

-20 0x02 5.3 -19 0x02 6.9 18 -18 0x03 7.1 -17 0x03 7.1 -16 0x04 7.1 -15 0x05 7.4 -14 0x05 7.4 -13 0x06 7.4 37 -12 0x07 7.6 -11 0x08 7.6 -10 0x09 7.9 -9 0x0b 7.9

13

-8 0x0c 8.2 -7 0x0d 8.4 75 -6 0x0f 8.7 -5 0x40 8.9 -4 0x50 9.4 -3 0x50 9.6 -2 0x60 9.7 -1 0x70 10.2 150 0 0x80 10.4 1 0x90 11.8 2 0xb0 12.8 3 0xc0 12.8 4 0xf0 13.8 5 0xff 14.8 300

Tabla 1.1. Diferentes valores para el registro PA_POW (0x0B) y sus

correspondientes salidas de RF con una estimación del alcance de transmisión.

También cuenta con una interfaz de conectores, Hirose DF-9 (Figura 1.6), de 51 terminales para las tarjetas de sensores (MTS 300) y la de programación (MIB 500), el conector incluye la interfaz para la fuente de voltaje y tierra, control de alimentación de la tarjeta de sensores periféricos, entradas del ADC para lectura de las salidas del sensor, una interfaz para la UART, entre otros, el esquema correspondiente al conector se muestra en la figura 1.7, en la tabla 1.2 tenemos una breve descripción de cada terminal del conector.

Figura 1.6. Conectores Hirose DF-9

Figura 1.7. Esquema del conector del MPR400.

14

Tabla 1.2. Descripción del conector para el MPR400. Verde: Utilizadas para interfaz de la tarjeta de sensores Amarillo: Funcionalidad compartida. Rojo: Utilizadas para programación El MICA2 tiene una referencia exacta del voltaje que puede ser utilizada para

medir el voltaje de la batería (Vbatt). Los 8 canales ADC del microcontrolador Atmega128 ADC utilizan el voltaje de la batería como la escala de referencia, el máximo valor de la escala de voltaje del ADC cambia cuando el voltaje de la batería cambia. Para calibrar el voltaje de la batería se requiere una referencia externa precisa del voltaje, el MICA2 utiliza un LM4041 para tal motivo, y cuya referencia es de 1.223 volts (Vref), este circuito esta unido al canal 7 del ADC. El MPR400 tiene además 3 leds programables y un puerto JTAG. En la figura 1.8 se muestra un diagrama a bloques del MPR400. Ya que se pretende que esta unidad básica sea lo más autónoma posible, el consumo de potencia debe ser mínimo. Por lo tanto, la alimentación la proporcionan 2 baterías tipo AA y circuitos adicionales de aumento y regulación de voltaje. Además, como ya lo hemos mencionado el radio y el microcontrolador son de baja potencia, en la tabla 1.3 se muestra el consumo de corriente de los diferentes componentes de la tarjeta MPR400. Además, este dispositivo cuenta con dos maneras de alimentarse externamente: 1.- Se puede alimentar al MICA2 por medio del conector Hirose DF-9, tal como se puede ver en la tabla que describe el uso de las terminales del conector (tabla 1.2). 2.- Por un conector de 2 terminales que corresponde a la parte número 53261-0290 de la compañía Moles, este conector se puede observar en la figura 1.3 en la que se ilustra al MPR400.

15

Figura 1.8. Diagrama a bloques del MPR400

Tabla 1.3. Corrientes de operación para los diferentes componentes del MPR400

16

MPR500 ( MICA2DOT ) La tarjeta MPR500 denominado MICA2DOT, figura 1.9 en la que se aprecia el reducido tamaño de la tarjeta, se compone fundamentalmente por los mismos elementos que el MPR400, tales como el microcontrolador Atmega L128, el emisor-receptor Chipcon CC1000 y la memoria flash externa AT45DB041B de 512 Kbytes, para estos dispositivos la descripción es la misma que hicimos para la tarjeta MICA2, salvo que la frecuencia de reloj para el microcontrolador Atmega L128 es de 4 MHz. La longitud de la antena para este dispositivo corresponde al de la tarjeta anterior, puesto que la frecuencia a que operan es la misma de 916 MHz, sólo que para esta tarjeta la antena esta soldada directamente sin conector de por medio.

Figura 1.9. MPR500 ó MICA2DOT La interfaz para el MPR500 está constituida por una serie de 19 terminales espaciadas alrededor de la circunferencia del MPR500 (Figura 1.10). Representan un subconjunto de las terminales disponibles en el MPR400. En esta interfaz se incluyen un sistema de control de energía, de canales del convertidor AD, de alimentación, de tierra, algunas terminales de entrada-salida (E/S) digital de propósito general, y para el puerto de programación serial, en la tabla 1.4 se muestra una breve descripción de cada terminal. Para aplicaciones que requieran más terminales de E/S digital, pueden volver a configurarse las terminales del ADC para utilizarse como entrada-salida digital, pero no ambas. Al igual que la tarjeta anterior el MPR500 cuenta con un sistema para monitorear el nivel de voltaje de la batería. Los 8 canales ADC del microcontrolador Atmega128 utilizan el voltaje de la batería como la escala de referencia, el máximo valor de la escala de voltaje del ADC cambia cuando el voltaje de la batería cambia. Para calibrar el voltaje de la batería se requiere una referencia externa precisa del voltaje (Vref), el MICA2DOT utiliza un diodo Schottky como referencia de voltaje. Un componente adicional de la tarjeta MICA2DOT es el termistor Panasonic ERT-J1VR103J, que esta montado superficialmente del lado de la tarjeta en la que se encuentra el microcontrolador Atmega, localizado con la etiqueta RT1. Su salida está en el ADC1 y se habilita fijando PW6 (PC6/A14) a nivel bajo y a PW7 (PC7/A15) a nivel alto.

17

Figura 1.10. Esquema de las terminales del MPR500

Terminal

NOMBRE DESCRIPCIÓN

TP1 GND Tierra TP2 ADC7 ADC canal 7 TP3 ADC6 ADC canal 6 TP4 ADC5 ADC canal 5 TP5 ADC4 ADC canal 4 TP6 VCC Voltaje (batería) TP7 PW1 E-S de propósito general / PWM TP8 PW0 E-S de propósito general / PWM TP9 UART_TXD UART Transmisión

TP10 UART_RXD UART Recepción TP11 RESTEN Reset del microcontrolador TP12 SPI_CK Reloj del radio TP13 ADC3 ADC canal 3 TP14 ADC2 ADC canal 2 TP15 PWM1B E-S de propósito general TP18 GND Tierra TP19 INT1 E-S de propósito general TP20 INT0 E-S de propósito general TP21 THERM_PWR E-S de propósito general

Tabla 1.4. Descripción de las terminales del MPR500.

El MPR500 también tiene un puerto JTAG como el MPR400 pero sólo cuenta con un led programable. Esta tarjeta fue diseñada para operar con una sola batería de litio, pero puede funcionar con cualquier combinación de baterías (AAA, C, D, etc.) con la condición de que la salida este en el entre 2.7 y 3.3 VDC, otra manera de alimentar la tarjeta es por medio de la terminal correspondiente (TP6). Las consideraciones de potencia son las mismas que para la tarjeta anterior. Un diagrama a bloques de este dispositivo se muestra en la figura 1.11.

18

Figura 1.11. Diagrama a bloques del MPR500

19

Entradas e interfaces de red ( MIB ó SPB Series ) Para la comunicación de la red inalámbrica a una PC se monta un dispositivo emisor-receptor en otra tarjeta que sirve de interfaz para la red, para este propósito existen diferentes plataformas de hardware, en la figura 1.12 se muestran diferentes dispositivos disponibles en Crossbow Technology que sirven de interfaz para la red de sensores inalámbricos.

Figura 1.12. Diferentes entradas e interfaces de red.

La plataforma experimental que nosotros empleamos fue la MIB510 (figura 1.13), antes de describir este dispositivo es muy importante tener presente que los dispositivos a programar, en este caso MICA2 y MICA2DOT no poseen diodos para conmutar entre un voltaje externo y el de la batería por lo que el interruptor debe estar en off, para el caso del MICA2, mientras que las baterías deben ser retiradas para el MICA2DOT ya que no posee interruptor.

La tarjeta MIB510 es un plataforma multipropósito que sirve de interfaz para los dispositivos MICA2 y MICA2DOT. Suministra energía a los dispositivos con un adaptador de energía externa, y proporciona un interfaz para el MOTE con el puerto serial RS-232 y el puerto de la reprogramación.

El MIB510 tiene un sistema procesador (In System Processor ISP) para

programar los MOTES. El código se descarga al ISP, por el puerto serial, y la ISP programa el código en el mote. El ISP y el mote comparten el mismo puerto serial. El ISP funciona en una velocidad fija de 115 kbaud. El ISP supervisa continuamente los paquetes seriales entrantes para encontrar un patrón especial multibyte. Una vez que se

20

detecte este patrón inhabilita la Rx y TX serial del mote, y entonces toma el control del puerto serial.

Figura 1.13. MIB510 tarjeta de interfaz serial y de programación. El procesador del ISP tiene dos LEDs, el ‘SP PWR’ (verde) y el ‘ISP’ (rojo).

El SP PWR se utiliza para indicar el estado del voltaje del MIB510. Si el LED ISP está encendido, el MIB510 tiene control del puerto serial. Este LED parpadea cuando se activa el botón de RESET.

El MIB510 tiene conectores para el MICA2 y MICA2DOT, como se puede ver

en la figura 1.13. Para el MICA2 hay otro conector en el lado inferior del MIB510 para adaptarle la tarjeta de sensores. También, se pueden montar tarjetas MICA2DOT con conectores de batería en el lado inferior de esta plataforma.

El MIB510 tiene un regulador de voltaje que acepta de 5 a 7 VDC, y suministra

un voltaje regulado de 3 VDC a los dispositivos MPR400 y MPR500, la plataforma MIB510 se entrega con un adaptador externo de alimentación, es muy importante no aplicar más de 7 VDC al regulador lineal de la tarjeta porque se puede dañar, por lo que se recomienda no usar más que el adaptador proporcionado para esta plataforma.

Cuenta, además, con un sistema incorporado para monitorear el nivel de tensión

que inhabilita la reprogramación si el voltaje de la fuente de alimentación es peligrosamente bajo. Cuando existe el voltaje de programación apropiado el led ISP PWR está encendido. Si el voltaje esta por debajo de 2.9 V, el led ISP PWR parpadea e inhabilitará el mote de cualquier transferencia directa de código. Si el voltaje esta demasiado abajo del nivel de potencia del ISP entonces el led ISP PWR estará apagado.

Tarjetas de sensores de adquisición de datos ( MTS y MDA Series ) Las plataformas de las series MTS y MDA; tarjetas de sensores y de adquisición

de datos respectivamente, están diseñadas para interconectarse con la familia de los motes inalámbricos MICA, MICA2, y MICA2DOT de Crossbow Technology. Hay

21

varias tarjetas de sensores disponibles, estas tarjetas de sensores son específicas para una determinada plataforma, ya sea un dispositivo MICA, MICA2 ó MICA2DOT. Las diferentes tarjetas de sensores permiten una gama de diversas modalidades de detección. La figura 1.14 enumera las tarjetas actualmente disponibles de sensores para cada familia de motes.

Figura 1.14. Diferentes tarjetas de sensores para los dispositivos MICA2 y MICA2DOT La plataforma de sensores que utilizamos fue la MTS310 denominada “micasb” y se ilustra en la figura 1.15, esta tarjeta consta de un sensor acústico, de un magnetómetro, de un acelerómetro, sensores de luz y de temperatura, además de contar con un resonador (Sounder) a una frecuencia de 4kHz. Los diversos tipos de sensores hacen a la tarjeta MTS310CA una plataforma muy flexible con una amplia gama de modalidades de detección, entre sus usos podemos mencionar la detección de vehículos, detección de movimiento, detección sísmica, detectar un rango acústico, robótica, y otros usos. En lo que sigue hacemos una descripción de cada uno de los componentes de la tarjeta.

22

Figura 1.15. Tarjeta de sensores MTS310 ó micasb.

Micrófono El circuito del micrófono tiene dos aplicaciones principales, en la primera funciona como un rango acústico y en la segunda sirve para grabación y como medida de la actividad acústica. El circuito básico se muestra en la figura 1.16, consiste en un pre-amplificador (U1a-1), la segunda etapa de amplificación es controlada con un potenciómetro digital (U1A, PT2). Este circuito amplifica el nivel bajo de salida del micrófono. Esta salida se puede alimentar directamente en el convertidor analógico-digital (ADC2) usando el circuito del selector de la salida del micrófono (MX1) para conectar la señal mic_out con la señal ADC2. Esta configuración es útil en general para grabación y mediciones acústicas. Los archivos de audio se graban en la memoria flash del mote MICA2 para después ser transferidos para su análisis. La salida de la segunda etapa (mic_out) se conecta a un filtro activo (U2) y pasa entonces hacia un detector de tono (TD1). El circuito integrado detector de tono, el CMOS LM567, convierte la señal analógica del micrófono en un nivel alto o bajo digital en la salida INT3 cuando un tono de 4 KHz está presente. El circuito resonador de la tarjeta de sensores puede generar este tono.

23

Figura 1.16. Diagrama del circuito correspondiente al micrófono. Un uso del resonador y del detector de tono es para determinar el rango acústico. En este uso, un mote pulsa el resonador y envía un paquete RF por medio del radio al mismo tiempo. Un segundo mote recibe el paquete de RF y observa el tiempo de llegada reajustando un timer/counter en su procesador. Entonces se incrementa un contador hasta que el detector de tono detecta el pulso del resonador. El valor del contador es el Tiempo-de-Vuelo de la onda acústica ent re los dos motes. El valor del Tiempo-de-Vuelo se puede convertir en una distancia aproximada entre los motes. Usando grupos de Motes con resonadores y micrófonos, se puede construir un sistema de localización.

24

Sounder El sounder es un simple resonador piezoeléctrico fijado a una frecuencia de 4KHz, en la figura 1.17 se muestra un esquema del circuito. El circuito y el control de la frecuencia se construyen dentro del resonador. La única señal requerida para activar y apagar el resonador por interva los, es Sounder_Power. La señal Sounder_Power es controlada por el interruptor de control de energía (P1) y es fijado por la línea PW2 del hardware, en la figura 1.18 se observa el diagrama del interruptor de control de energía.

Figura 1.17. Diagrama del resonador (sounder).

Figura 1.18. Esquema del interruptor de control de energía.

25

Luz y temperatura Antes de describir los sensores de de luz y temperatura es importante tener en cuenta que ambos sensores comparten el mismo canal del convertidor analógico-digital (ADC1). Por lo que se debe utilizar solamente un sensor a la vez, o la lectura en el ADC1 será equivoca. El sensor de luz corresponde al dispositivo Clairex CL9P4L que se muestra en la figura 1.19 (http://www.clairex.com), es una simple fotocelda de CdSe. La sensibilidad máxima de la fotocelda es para una onda de luz de 690 nm de longitud de onda. La resistencia típica mientras está expuesto a la luz, es de 2 kO mientras que en condiciones de oscuridad, es de 520 kO. Para utilizar el sensor de luz, la señal PW1 del control digital debe estar puesta en ON. La salida del sensor está conectada con el canal analógico-digital 1 (ADC1) del convertidor. Cuando hay luz, la salida nominal del circuito está cerca de VCC o al tope de la escala, y cuando esta oscuro la salida nominal es cercana a tierra o cero. El control de la energía para el sensor de luz es controlada al fijar la señal INT1.

Figura 1.19. Sensor de luz y sus dimensiones. El termistor (Panasonic ERT - J1VR103J) en el MTS310CA es un componente montado superficialmente señalado como RT2. Su configuración es la de un circuito divisor de voltaje con un valor de la mitad de VCC para lecturas de 25°C, en la tabla 1.5 se muestran los porcentajes de VCC para diferentes rangos de temperaturas. La salida del circuito del sensor de temperatura está disponible en ADC1. La energía es controlada fijando la señal INT2, en la figura 1.20 se observa el esquema del circuito para los sensores de luz y de temperatura.

Temperatura ( °C )

Resistencia ( Ω )

Lectura del ADC1

(% de VCC ) -40 427,910 2.3 % -20 114,200 8.1 % 0 35,670 22 % 25 10,000 50 % 40 4090 71 % 60 2224 82 % 70 1520 87 %

Tabla 1.5. Valores de voltaje y resis tencia para diferentes rangos de temperatura.

26

Figura 1.20. Diagrama de los sensores de luz y temperatura.

2-Ejes sensores de aceleración El sensor de aceleración es un sistema microelectromecánico (MEMS) superficial que consta de 2 ejes con una resolución de ± 2 g. Entre sus características tenemos una muy baja corriente de operación (< 1mA) y 10-bit de resolución. El sensor se puede utilizar para la detección de la inclinación, el movimiento, la vibración o medidas sísmicas. La energía para el sensor de aceleración se controla fijando la señal PW4, y los datos analógicos se muestrean en ADC3 y ADC4. El acelerómetro, situado en U5, es el ADXL202JE las características completas están disponible en http://www.analog.com. En la figura 1.21 se muestra un esquema del circuito y en la tabla 1.6 un resumen de sus características.

Figura 1.21. Esquema del circuito del sensor de aceleración.

27

Canales X ( ADC3 ), Y ( ADC4 ) Rango ± 2 g ( 1 g = 9.81 m / s2 ) Ancho de banda En DC 50 Hz ( Se puede controlar con C20 y C21) Resolución 2 mg ( 0.002 ) RMS Sensitividad 167 mV/g ± 17 % Offset 2.5 V ± 0.4 V

Tabla 1.6. Características del sensor de aceleración ( ADXL202JE )

El ADXL202 es un sistema de dos ejes para la medida de la aceleración en un solo circuito integrado. Para cada eje, un circuito de salida convierte la señal analógica a un ciclo modulado (DCM) de señal digital que se puede demodular con un contador temporizado en un puerto de un microprocesador. El ADXL202 es capaz de medir aceleraciones positivas y negativas a un nivel máximo de ±2 g. El acelerómetro mide fuerzas de aceleración estáticas tales como la gravedad, permitiendo que sea utilizada como sensor de inclinación.

El ADXL202 contiene un sensor microelectromecánico en una superficie de polisilicon construida en la superficie de la oblea de silicio. Los resortes de polisilicon suspenden la estructura sobre la superficie de la oblea y proporcionan una resistencia contra las fuerzas de aceleración. La desviación de la estructura se mide usando un condensador diferencial que consiste en placas fijas independientes y otras placas centrales unidas a la masa móvil. Las placas fijas son desfasadas 180° de la fase de la onda cuadrada. Una aceleración desviará la estructura y desequilibrará el condensador diferencial, dando por resultado una onda cuadrada de salida con una amplitud proporcional a la aceleración. Técnicas de demodulación sensibles a la fase son usadas para rectificar la señal y determinar la dirección de la aceleración, en la figura 1.22 se muestra un diagrama a bloques de este circuito.

Figura 1.22. Diagrama a bloques del ADXL202

2-Ejes sensores de campo magnético El circuito del magnetómetro es un sensor de silicio que tiene un único puente resistivo cubierto en una capa altamente sensible de NiFe. Esta capa de NiFe causa que el puente resistivo del circuito cambie. El puente es altamente sensible y puede medir el campo de la Tierra y otros campos magnéticos pequeños. Una aplicación útil es la detección de

28

vehículos. En pruebas realizadas se han detectado perturbaciones producidas por los automóviles en un radio de 15 pies. El detector del campo magnético es el sensor HMC1002 de Honeywell. El detalle de las especificaciones puede encontrarse en http://www.ssec.honeywell.com. La salida de cada eje (X, Y) es amplificado por los dispositivos amplificadores U6, U7. La salida amplificada está disponible en ADC5 y ADC6. La energía del sensor de campo magnético es controlada fijando la señal PW5. Cada dispositivo de amplificación (U6, U7) se puede sintonizar usando el potenciómetro digital PT1 que es controlado por el bus I2C, en la figura 1.23 se muestra un diagrama del circuito.

Figura 1.23. Diagrama del sensor de campo magnético.

29

SOFTWARE

Instalación Como ya se indico el tinyos puede ser usado en distintas plataformas, pero principalmente se usan dos que son linux o windows, empezaremos por explicar como se instala en windows. Es bastante intuitivo instalarlo en windows solo hay que cuidar unos cuantos detalles, en el kit de desarrollo incluye un cd con un wizard, el cual instala todo lo necesario, que en esencia es el cygwin, el tinyos y el compilador de java. Pero a continuación se lista todo el software contenido en el wizard. •TinyOS •TinyOS Tools •NesC •Cygwin •Support Tools •Java 1.4 JDK & Java COMM 2.0 •Graphviz •AVR Tools

avr-binutils avr- libc avr-gcc avarice avr- insight Existe un ejecutable en el cd con el nombre tinyos-1.1.0.exe o puede bajarse de

la pagina de tinyos http://today.cs.berkeley.edu/tos/ donde por supuesto puede ser que la versión varíe ya que al momento de estar escribiendo este texto ya existe una nueva versión.

Al ejecutar dicho programa aparecerá una pantalla que indica se iniciará el wizard que lo llevará de la mano para instalar todo lo necesario en cuanto a software se refiere. Fig 2.1.

Figura 2.1. Pantalla de inicio de la instalación.

30

Dependiendo de las capacidades de su computadora tardará en iniciar, como experiencia personal, tardó cerca de 20 minutos en iniciar, así que no se preocupe relájese. Cuando el programa finalice de inicializar aparecerá otra pantalla en donde usted elegirá el tipo de instalación que desee, y el directorio donde se instalará el software. La recomendación es escoger Complete, de esa forma instalará todo lo que arriba se listó. Fig 2.2.

Figura 2.2. Elección del tipo de instalación.

Después de esto aparecerá otra pantalla, en la cual se escogerá si se quiere instalar el entorno de desarrollo de java. Es importante instalarlo, porque es necesario para muchas de las utilerías que trae el software. Fig 2.3.

Figura 2.3. Elección de la instalación del entorno de desarrollo java.

31

Terminado esto, comenzará a copiar los archivos y después preguntará si se seguirá con la instalación del cygwin, después de escoger el directorio, recomendamos usar el que asigna por default. Comenzará entonces la instalación. Fig 2.4.

Fig 2.4. Progreso de la instalación.

Después de la instalación de el cygwin, automáticamente comenzará a instalar los rpm’s necesarios, además de compilar los programas de java. Esta parte dura mucho tiempo, así que le recomendamos ser pacientes. Después de esto la instalación ha concluido. Fig. 2.5

Figura 2.5. Instalación de rpm’s y fin de la instalación.

32

La estructura después de la instalación queda como se ve en la siguiente figura.

Figura 2.6. Estructura de directorios.

Revisemos que contienen los directorios más importantes, empecemos de la raíz hacia abajo, es decir por el directorio tinyos-1.x.

Figura 2.7. Directorio tinyos-1.x

33

Y veamos ahora que contiene el directorio TOS Fig. 2.8.

Figura 2.8. Directorio TOS

34

Primeros Pasos

Nosotros programamos con el programador MIB510 así, que es útil definir un alias para que las instrucciones de programación sean mas cortas, el alias se define de la siguiente forma:

alias mib510 = “MIB510=/dev/ttyS0”

Esto es porque asumimos que el programador esta conectado en el COM1 de la computadora. Así cada vez que se invoque al programador la línea de comando será más corta. Existen distintas plataformas que soporta el software del tinyos, en lo particular nosotros ocupamos los motes mica2 y mica2dot. Es claro que si estamos hablando de una red de sensores, el involucrarnos con el concepto de red implica que tengamos una comunicación entre los entes que la conforman, y por supuesto que cada nodo participante en la red necesita un identificador que lo haga único, es decir una dirección. La asignación de direcciones es sencilla y se hace al programar el mote. Usando una línea de comandos como la que sigue:

make (re) install.<addr> <plataform>

Donde <addr> es la dirección asignada al mote en la red, es imperativo mencionar que hay valores reservados que no deben usarse estos son:

TOS_BCAST_ADDR = 0xFFFF TOS_UART_ADDR=0x007E

Otra cosa importante de destacar es que el nodo con el identificador 0 será aquel que quede en la base del programador, para que sea el destino de la información recolectada por los sensores.

Existen dos maneras de programar los motes, dependiendo de si se utiliza uno de los dos modificadores ya sea install o reinstall. Install – compila la aplicación para la plataforma escogida, asigna la dirección y programa el mote. Reinstall – asigna la dirección del mote pero no recompila la aplicación, por lo cual es más rápida que la anterior.

Como ya habíamos mencionado para programar con el MIB510, es necesario hacer una modificación en la forma de programar los motes, el formato es como sigue, claro todo esto tecleado en un shell:

MIB510 = /dev/ttyS0 make install mica2

Los motes que utilizamos usan radiofrecuencia para comunicarse, en particular las unidades con que contamos usan una frecuencia de 915 MHZ, el valor específico de la frecuencia que es asignada al mote se encuentra en el archivo:

/tos/plataform/mica2/CC100Const.h

35

Es crítico que se asigne la frecuencia correcta a los motes, de lo contrario la comunicación podría fallar, esta constante se modifica de manera sencilla, en la línea 213 de el archivo antes mencionado, en la cual escogeremos entre dos valores que son

914_077 ó 915_998 Ya seleccionada la frecuencia se sustituye en el archivo: [212]#ifndef CC1K_DEF_PRESET [213]#define CC1K_DEF_PRESET (CC1K_<freq>_MHZ) [214]#endif donde <freq> se sustituirá por la frecuencia deseada. En el mercado existen diferentes tipos de sensores, que pueden ser utilizados en los motes, es importante conocer con cuales se esta trabajando, y especificarlo en el Makefile, usando la variable “SENSORBOARD=”, en nuestro caso debemos asignarle a esta variable el valor de micasb que es el que identifica a los sensores que utilizamos. Hablaremos más a fondo sobre lo que contienen los paquetes que viajan a través de la red de sensores, pero en este momento solo se mencionará que contiene un grupoID en la cabecera del mensaje, lo cual permite que existan diferentes grupos de motes compartiendo la misma frecuencia. El campo grupoID tiene una longitud de 8 bits y el grupo por default es 0x7d (hex). La forma de asignar un identificador de grupo distinto es modificando el archivo Makerules, en la línea:

DEFAULT_LOCAL_GROUP = 0x42 #for example

Hablando un poco más sobre esto, ya habíamos mencionado que cada mote tiene un identificador que los distingue de los otros, bueno pues este identificador viene también en la cabecera del mensaje y ocupa 16 bits. Después de haber realizado la instalación completa, es importante revisar si todo quedo bien, así que usaremos una aplicación que viene incluida en el directorio tools bajo el subdirectorio scripts, ya que estamos situados en tal subdirectorio vamos a escribir el comando toscheck, esperando que al finalizar nos mande una línea, esta línea debe ser “toscheck completed without error”, si existe cualquier error lo reportará, pero lo mas común es que sólo se deban modificar las variables de entorno, para que encuentre lo que busca. Después de finalizar el toscheck sin errores, podemos estar seguros que el software esta trabajando bien. El hardware también debe verificarse para eso existen distintas maneras y cualquiera es valida, ya que en el directorio existen diferentes pruebas, podrían usar los scripts que vienen en el subdirectorio MicaSBVerify.

36

TinyOS y NesC

El tinyos es un sistema operativo, el cual esta escrito en nesC, que es un nuevo lenguaje de programación. Este lenguaje esta hecho para sistemas dedicados tales como las redes de sensores. Como se puede adivinar tiene una sintaxis parecida a la de C, pero soporta el modelo de concurrencia, así como todo lo necesario para tener un sistema robusto de red de sensores. El principal propósito de nesC es permitir a los programadores construir componentes, que puedan fácilmente crear una aplicación en especifico. Tinyos posee todas las características que provienen de nesC, esta construido por componentes bien definidos e interfaces direccionales, además que maneja un modelo de concurrencia basado en tareas y programas que atienden las interrupciones de hardware, además de detectar las condiciones de carrera a tiempo de compilación. Pero hablemos un poco mas acerca de esto: Componentes Una aplicación de nesC puede tener uno o más componentes. Un componente proporciona y utiliza interfaces. Estas interfaces son sólo el punto de acceso al componente y son bidireccionales. Una interfaz decla ra una colección de funciones llamadas comandos que la interfaz debe tener implementadas. Para que un componente llame a los comandos en una interfaz, este debe implementar los eventos de esa interfaz. Un componente simple puede ser usado o proveer múltiples interfaces y diferentes instancias de la misma interfaz. Implementación

Hay dos tipos de componentes en nesC, los módulos y las configuraciones. Los módulos proveen código de aplicación, implementando una o más interfaces. Las configuraciones son usadas para ensamblar otros componentes, conectando interfaces usadas por componentes a interfaces provistas por otras. Esto es llamado cableado (wiring); cada aplicación en nesC es descrita por una configuración principal que ‘conecta’ todos los componentes. Los archivos fuentes de nesC usan la extensión .nc, ya sean interfaces módulos o configuraciones.

Modelo de Concurrencia El tinyOS ejecuta sólo un programa que consiste de una selección de componentes de sistema y componentes necesarios para una aplicación simple. Existen dos líneas de ejecución: task y hardware event handlers. Task son funciones las cuales están diferidas. Si una es programada, se ejecuta hasta que termina, y ninguna otra tiene preferencia. Hardware event handlers son ejecutados en respuesta a una interrupción de hardware y también se ejecutan hasta terminar; pero pueden interrumpir la ejecución de una task o de otro hardware event handlers. Los comandos y eventos que son ejecutados como parte de un hardware event handlers deben ser declarados con la palabra reservada async.

37

Debido a que task y hardware event handlers pueden ser interrumpidos por otro código asíncrono, los programas en nesC son susceptibles a condiciones de carrera. Esto se evita ya sea por acceso exclusivo a datos compartidos dentro de las tasks, bien teniendo acceso total dentro de las funciones atómicas. El compilador de nesC reporta las porciones de código que puedan formar, potencialmente, una de estas condiciones. Si es posible el compilador lo reporta como falso positivo, y pueden ser declaradas con la palabra reservada norace. Esta palabra debe ser usada con extrema precaución.

38

Obteniendo Datos

Programa SerialForwarder El programa Listen es la manera más básica de comunicarse con el mote; abre directamente el puerto serial y muestra en la pantalla los paquetes descargados. No es obviamente fácil visualizar los datos del sensor usando este programa. Lo que realmente quisiéramos es una mejor manera de recuperar y observar los datos obtenidos de la red de sensores.

El programa SerialForwarder (algo así como re-direccionamiento serial) se utiliza para leer paquetes de datos de un puerto serial y desde una conexión de Internet, de modo que puedan otros programas ser escritos para comunicarse con la red de sensores a través de Internet. Para hacer funcionar el programa Serial Forwarder, vaya al directorio tools/java/ y corra el programa tecleando:

java net.tinyos.sf.SerialForwarder -comm serial@COM1:<baud rate >

donde < baud rate > es la velocidad de transferencia de su puerto serial (será típicamente de 19200 ó 57600). El argumento -comm indica que el programa SerialForwarder debe comunicarse sobre el puerto serial COM1 y especifica de donde deben venir los paquetes de datos, en la figura 2.9 se muestra la pantalla de esta aplicación de java.

Figura 2.9. Pantalla lanzada cuando la aplicación de java SerialForwarder esta funcionando correctamente.

Como otros programas SerialForwarder utiliza la misma sintaxis que la variable de entorno MOTECOM que se consideró anteriormente (se puede correr java net.tinyos.packet.BuildSource para conseguir una lista de fuentes válidas). Pero al igual que la mayoría de los demás programas, no presta atención a la variable de entorno de MOTECOM, por lo que se debe utilizar el argumento –comm para especificar la fuente del paquete.

39

La aplicación SerialForwarder no exhibe los paquetes de datos en sí, sino que actualiza la cuenta de dichos paquetes de datos, esta información se muestra en la esquina inferior derecha de la ventana desplegada por la aplicación. Una vez funcionando, la aplicación SerialForwarder esta atenta a conexiones de clientes de la red en un puerto TCP dado (el 9001 es implícito), y remite simplemente mensajes de TinyOS del puerto serial a la conexión del cliente de la red, y viceversa. Observe que múltiples aplicaciones pueden conectarse con el programa SerialForwarder inmediatamente, y todas recibirán una copia de los mensajes de la red de sensores.

Como los paquetes llegan del mote conectado con el puerto serial, se observará que el campo "Pckts Read:" que se muestra en la esquina inferior derecha comienza a incrementarse.

Inicio de la interfaz gráfica Oscilloscope Para exhibir gráficamente los datos que vienen de los motes; dejando la aplicación SerialForwarder corriendo, ejecute el comando

java net.tinyos.oscope.oscilloscope

Figura 2.10. Pantalla lanzada por la aplicación de java Oscilloscope

40

Este comando lanzará una ventana sobre la de SerialForwarder que contiene una exhibición gráfica de las lecturas del sensor del mote. La interfaz gráfica Oscilloscope se conecta con el programa SerialForwarder sobre la red y recupera los paquetes de datos, analiza las lecturas del sensor de cada paquete, y las dibuja en un gráfico, como se muestra en la figura 2.10.

El eje x del gráfico es el número del contador de los paquetes y el eje y es la

lectura del sensor de luz. Si el mote ha estado funcionando por un rato, el contador de los paquetes puede ser grande, así que las lecturas pueden no aparecer en el gráfico; solamente en otro ciclo de energía del mote se reajusta su contador de paquetes a 0. Si no se observa lectura alguna del sensor de luz, debe enfocarse el despliegue gráfico utilizando las opciones de Zoom de la interfaz. Datos del sensor que se transmiten de la radio al puerto serial

La aplicación Oscilloscope esta escrita para utilizar el puerto serial y el sensor de luz. En cambio, al observar apps/OscillosopeRF /, vemos que transmite las lecturas del sensor por medio de la radio. Para utilizar esta aplicación, se necesita proporcionar un puente que reciba los paquetes de datos en la radio y los transmita hacia el puerto serial. El apps/TOSBase/ es una aplicación que hace esto; simplemente envía los paquetes entre la radio y la UART (en ambas direcciones). Es importante señalar que la interfaz gráfica Oscilloscope es capaz de exhibir lecturas de los sensores de múltiples motes. Hay que asegurarse de que esas lecturas estén transmitidas y recibidas correctamente en la red. La comunicación que se establece se esquematiza en la figura 2.11.

Figura 2.11. Ilustración de cómo trabaja OscilloscopeRF

41

Un ejercicio sencillo para probar esta aplicación es programar algunos motes con OscilloscopeRF, cambiando el número de nodo para cada mote 1,2, etc. Usando el comando:

make mica2 install.<n> donde, <n> es la dirección del nodo (en decimal) que se desee programar en cada mote. Programamos un mote con la aplicación TOSBase, con este mote insertado en la tarjeta de programación (MIB510) y con dicha tarjeta conectada al puerto serial, se distribuyen los demás motes programados con la aplicación OscilloscopeRF y con la tarjeta de sensores conectada alrededor de esta tarjeta, como se ve en la figura 2.12.

Figura 2.12. Mote MICA2 alimentado por baterías con la tarjeta de sensores MTS310 conectada, usada con la aplicación OscilloscopeRF.

Después corremos la aplicación SerialForwarder con el comando:

java net.tinyos.sf.SerialForwarder -comm serial@COM1:<baud rate >

y la interfaz gráfica Oscilloscope tecleando el comando:

java net.tinyos.oscope.oscilloscope Se puede observar que la interfaz gráfica despliega con colores diferentes las lecturas de cada sensor de luz, señalando el correspondiente para cada mote con su número de identificación. Una prueba para observar el funcionamiento de la aplicación es cubrir alguno de los sensores de luz, con lo que se observará un cambio en el despliegue de los datos para el mote específico, en la figura 2.13 se muestra la interfaz para un ejemplo en la que usamos 3 motes.

42

Figura 2.13. Pantalla lanzada por la interfaz gráfica OscilloscopeRF Para este ejemplo los datos de los sensores de tres motes diferentes se despliegan en colores

distintos.

43

Enrutamiento multivías (Multihop Routing ) La versión de TinyOS 1.1 y posteriores incluyen las librerías ad-hoc para proporcionar enrutamiento multi-hop para aplicaciones en la red de sensores. La implementación utiliza el algoritmo shortest-path-first (la trayectoria más corta primero) con un solo nodo de destino (la raíz) y una estimación activa de dos vías posibles de ligar la ruta. Los mecanismos de decisión del movimiento y de la ruta de datos están divididos en componentes separados con una sola interfaz entre ellos para permitir que otros esquemas de decisión de la ruta sean integrados fácilmente en el futuro. Utilizar enrutamiento multivías es esencialmente transparente para las aplicaciones (considerando que estas utilizan correctamente la interfaz).

El uso de los componentes de la librería multi-hop es transparente a la aplicación. Cualquier aplicación que utilice la interfaz Send (enviar) se puede conectar con este componente para alcanzar funcionalidad multi-hop. Sin embargo, una limitación del enrutamiento multi-hop es la tasa de datos agregada. Las aplicaciones deben mantener la frecuencia promedio de mensajes en un mensaje, o menos, cada dos segundos. Tasas más altas pueden conducir a la congestión y/o al desbordamiento de la cola de comunicación. Surge Demo La aplicación Surge localizada en el directorio apps/Surge/ es un ejemplo simple de una aplicación de enrutamiento multi-hop. La aplicación Surge toma las lecturas del sensor de luz y las envía al nodo base (identificado como el nodo 0). El complemento de esta aplicación es un programa de Java que se puede utilizar para visualizar la topología lógica de la red y las lecturas del sensor. Se recomienda revisar la aplicación SurgeM.nc y su configuración Surge.nc, para entender mejor cómo utilizar las herramientas del enrutamiento multi-hop. Para implementar la aplicación Surge hay que cambiar al directorio apps/Surge/ y teclear make mica2. Para utilizar las herramientas de java debemos estar en el directorio tools/java/net/tinyos/surge/ y teclear make. Después instalar la aplicación en los nodos, dando a cada nodo un identificador (ID) único, tecleando: MIB510 = /dev/ttyS0 make reinstall. < nodeid > mica2 Sí se asume que se están programando con el MIB510 conectado con el puerto serial COM1. El mote del nodo base debe ser programado con el identificador del nodo 0. Este nodo se debe conectar con el puerto serie de una PC o por medio de una liga de la red. Para posteriormente correr las aplicaciones de java se deben realizar los siguientes pasos:

- Primero se debe arrancar la aplicación SerialForwarder para ligar el nodo base y la PC (por ejemplo, tecleando: java net.tinyos.sf. SerialForwarder –comm serial@COM1:mica2 en el directorio tools/java/ ).

44

- Después debemos arrancar la interfaz gráfica para la topología de la red de sensores (Sensor Network Topology) desde el directorio tools/java/ tecleando:

java net.tinyos.surge.MainClass < Groupid >

donde < Groupid > es el número del identificador del grupo de mensaje activo (AM) en decimal, usado al compilar la aplicación en el mote (por ejemplo, el identificador de grupo implícito es el 0x7d en decimal el 125).

Cuando la aplicación comienza se puede ver inmediatamente, en la interfaz gráfica, al nodo base reportar los valores del sensor. Alrededor de 1 minuto después, otros nodos deben aparecer como las estructuras de la topología de la red, en la figura 2.14 se muestra la pantalla desplegada por esta aplicación gráfica.

Figura 2.14. Topología de la red vista en la interfaz gráfica Surge. Si se cubre el sensor de luz con la mano, el entorno de ese mote particular se oscurece en la pantalla. Se puede hacer que un mote particular desaparezca de la pantalla apagándolo o colocándolo más lejos. Las líneas verdes sólidas indican que esta activo el puente de transmisión de datos y la línea roja representa puentes de comunicaciones previamente activos, que ahora son inactivos, porque el nodo encontró una mejor trayectoria de transmisión. Es importante señalar que la localización de los nodos en la pantalla no representa la localización física de los nodos en torno a la PC.

45

NesC

Como ya se comentó, nesC es una extensión de C diseñado para incorporar los conceptos y el modelo de ejecución del TinyOS. TinyOS es un sistema diseñado para nodos que formen parte de una red de sensores, que tengan recursos limitados (por ejemplo tiene 8 kb de espacio para programa, 512 bytes de RAM). TinyOS se ha reimplementado en nesC. Los conceptos básicos detrás de nesC son:

• Separación de la construcción y la composición: los programas son construidos de componentes, los cuales son ensamblados (“alambrados”), para formar programas completos. Los componentes están definidos en dos ámbitos, uno por su especificación (que contiene el nombre de las instancias de las interfaces) y el otro por su implementación. Los componentes tienen concurrencia interna en forma de task. Los hilos de control puede pasar a un componente a través de las interfaces. Estos hilos de control tienen su raíz en un task o en una interrupción de hardware.

• Especificación del comportamiento de los componentes en términos de la

colección de interfaces. Las interfaces pueden ser provistas o usadas por los componentes. Las interfaces provistas están hechas para representar la funcionalidad que los componentes proporcionan a su usuario, las interfaces usadas representan la funcionalidad que el componente necesita para realizar su trabajo.

• Las interfaces son bidireccionales: especifican una colección de funciones que

se pondrán en ejecución por los proveedores de la interfaz (comandos) y una colección que se pondrá en ejecución por el que usa las interfaces (eventos). Esto permite a una interfaz sencilla representar una interacción compleja entre componentes (ejemplo, el registro de algún evento que nos interese, seguido por un callback cuando este evento pase). Esto es crítico porque todos los comandos largos de el TinyOS (ejemplo, envió de paquete), son no bloqueados; su terminación se señala con un evento (send done). Cuando se especifica una interfaz, un componente no puede llamar al comando send a menos que se proporcione una implementación del evento send done. Típicamente los comandos llaman hacia abajo, es decir llaman componentes que son mas cercanos al software, a diferencia de los eventos que llaman hacia arriba. Ciertos acontecimientos primitivos están limitados a las interrupciones del hardware (la naturaleza de este problema se debe a que es un sistema dependiente, pero esto no está muy documentado.)

• Los componentes se unen estáticamente uno al otro vía sus interfaces. Esto incrementa la eficiencia en tiempo de ejecución, apoya un diseño robusto y permite un mejor análisis estático de los programas.

• NesC es diseñado bajo la expectativa de que el código será generado por

compiladores de programas completos. Esto permite una mejor generación de código y análisis. Un ejemplo de esto es el detector de condiciones de carrera en tiempo de compilación del NesC.

46

• El modelo de concurrencia del NesC se basa en task que se ejecutan hasta terminar, y manejadores de interrupción, los cuales pueden interrumpir las tasks y otros manejadores. El compilador de NesC señala las condiciones de carrera potenciales causadas por manejadores de interrupción.

Interfaces

Las interfaces en NesC son bidireccionales: especifican un canal de funcionamiento múltiple entre la interacción de dos componentes, el que provee y el que la usa. La interfaz especifica una colección de funciones, llamados comandos y otros llamados eventos.

Las interfaces son especificadas por el tipo de interfaz, como el siguiente:

Esto declara el identificador de tipo de interfaz. Este identificador es global y pertenece a un espacio de nombres diferente al componente y al espacio de nombres del tipo de interfaz, así que todos los tipos de interfaces tienen nombres distintos de cada uno de los otros componentes, pero no puede haber conflictos con declaraciones regulares de C. Cada tipo de interfaz tiene un alcance distinto para la s declaraciones en la parte de declaration-list. Esta parte debe estar constituida de declaraciones de funciones con la clase del comando o del evento (si no es así, ocurrirá un error en tiempo de compilación). La palabra reservada optionalasync indica que el comando o el evento se pueden ejecutar en un interrupt handler. Una interfaz puede opcionalmente incluir archivos escritos en lenguaje C por medio de la includes-list. Veamos una simple interfaz:

El que provee la interfaz tipo SendMsg debe implementar el comando send, mientras que el que la usa debe implementar el evento sendDone.

47

Especificación de los componentes.

Un componente de nesC es un módulo o una configuración:

Los nombres de los componentes son especificados por los identificadores. Este identificador tiene alcance global y pertenece al namespace del tipo del componente y de la interfaz.

Un componente puede incluir opcionalmente archivos de C vía la includes-list.

La lista de especificaciones enumera los elementos de la especificación (instancias, comandos o eventos de la interfaz) usados o proporcionados por este componente. Un componente debe implementar los comandos que proporciona su interfaz y los eventos que usa su interfaz. Módulos

Los módulos implementan la especificación de los componentes con código C:

donde translation-unit es una lista de declaraciones tipo C y definiciones. Las declaraciones de nivel superior de la unidad de traducción de los módulos pertenecen al alcance de la componente- implementación de los módulos. Estas declaraciones tienen una extensión infinita y puede ser: cualquier declaración o definición Standard de C, una declaración o una definición de una task, o la implementación de comandos o de eventos. Estas implementaciones de comandos o eventos son especificados con la siguiente sintaxis de extensiones de C:

48

La implementación de un simple comando o evento a tiene la sintaxis de una definición de función en C para a, con la clase contenedora command o event. Adicionalmente, la palabra reservada async debe ser incluida si fue incluida en la declaración. Veamos un ejemplo, este es un módulo que provee la interfaz Send del tipo SendMsg:

La implementación de los eventos o comandos parametrizados a con parámetros P tiene la sintaxis de una función de C para a con la clase contenedora command o event, donde la lista de parámetros regulares es prefijada con los parámetros P entre corchetes. Estas declaraciones de parámetros pertenecen al alcance de a y abarcan lo mismo que los parámetros de una función regular. Por ejemplo, en un módulo que provee la interfaz Send[uint8_tid], del tipo SendMsg vemos:

Los errores en tiempo de compilación son reportados cuando:

• No hay implementación para un comando o evento que se provee. • El tipo, los parámetros de la interfaz, la presencia o ausencia de la palabra

reservada async de un comando o evento, no concuerda con la especificación dada en el módulo.

Llamando comandos y señalización de eventos. Las siguientes extensiones de la sintaxis de C son usadas para llamar comandos y señalizar eventos:

Un comando sencillo es llamado con call a(….), un evento sencillo a es señalizado con signal a(….). Por ejemplo, en un módulo que utiliza la interfaz Send del tipo SendMsg:

call Send.send(1, sizeof(Message), &msg1)

49

Un comando parametrizado a (un evento también) con n parámetros del tipo ß1,. . . , ßn es llamado por expresiones formadas con los parámetros ?1,. . . , ?n como sigue: call a [?1,. . . , ?n ](….) (y para un evento sería signal a [?1,. . . , ?n ](….)) Las expresiones formadas con los parámetros deben ser asignables a los tipos ßi; un ejemplo de esto se ve en un módulo que usa la interfaz Send[uint8_t id] del tipo SendMsg:

La ejecución de comandos y eventos es inmediata por ejemplo call y signal se comportan de manera similar. Las implementaciones reales que ejecutan los comandos y eventos por un call o un signal dependen de las declaraciones en las configuraciones del programa. Estas declaraciones pueden especificar, que 0, 1 ó más implementaciones deben ser ejecutadas. Cuando más de una implementación es ejecutada, decimos que el comando o evento de el módulo tiene “fan-out”.

50

Task

Una task es independiente del control definido por una función y puede ser declarada void es decir que no regrese nada, y además puede ser llamada sin parámetros. El modelo de concurrencia de NesC, incluye tasks, pero eso lo veremos mas adelante. Declaración Atómica.

Garantiza que la declaración es ejecutada sin que nada mas se ejecute, se utiliza para implementar exclusión mutua, para actualizar estructuras de datos concurrentes, etc. Un ejemplo de esto es:

Las funciones atómicas deben ser cortas, para ayudar a cumplir con este requisito, NesC prohíbe llamar comandos o señalizar eventos dentro de las declaraciones atómicas. También está prohibido el uso de: goto, return, break, continue, case., default y labels. Configuraciones. Las configuraciones implementan la especificación de un componente conectando o alambrando una colección de otros componentes:

La parte de component-list lista los componentes que son usados para construir esta configuración. La conection-list especifica como estos componentes son conectados entre ellos y a la especificación de la configuración.

51

Wiring (alambrando, conectando). El wiring es usado para conectar los elementos juntos (interfaces, comandos, eventos).

Las declaraciones de conexión unen dos puntos finales (endpoints). El identifier-path de un punto final nos habla de la especificación de un elemento.

La parte de argument-expresion-list especifica opcionalmente los parámetros de la interfaz. Nosotros decimos que un punto final esta parametrizado si su especificación de elementos esta parametrizada y el punto final no tiene valores de parámetro. Un error en tiempo de compilación ocurre si un punto final tiene valores de parámetro y cualquier condición de las siguientes es verdadera:

• Los valores de los parámetros no son expresiones constantes. • La especificación de los elementos de los puntos finales son no parametrizados. • Que existan más (o menos) valores de parámetro que parámetros en la

especificación de los elementos. • Los valores de los parámetros no están en el rango de las especificaciones de los

tipos de parámetros de los elementos.

Hay tres tipos de declaraciones de conexión (wiring) en NesC:

• endpoint1 = endpoint2 (conexión de equivalencia) es cualquier conexión que implica una conexión a un elemento externo. Esto eficazmente hace que dos especificaciones de elementos sean equivalentes.

• endpoint1 -> endpoint2 (liga conexiones) es una conexión que implica la especificación de dos elementos internos. Conectan un elemento usado por la especificación de endpoint1 con un elemento provisto por endpoint2.

• endpoint1 <- endpoint2 es equivalente a endpoint2 ->endpoint1. En las tres clases de conexiones las dos especificaciones deben ser compatibles, por ejemplo, ambos deben ser comandos o eventos o instancias de interfaces. También

52

si son comandos o eventos, deben de ser el mismo tipo de función. Si son instancias de interfaz deben de ser el mismo tipo de interfaz. Si estas condiciones no se cumplen, ocurrirán errores en tiempo de compilación. Si un punto final (endpoint) es parametrizado, el otro debe serlo también, y los parámetros deben de ser del mismo tipo; de otra manera por supuesto existirán errores en tiempo de compilación. La misma especificación puede ser conectada varias veces. Ejemplo:

En este ejemplo, las múltiples conexiones permitirán múltiples señalizadores para los eventos en la interfaz X y para múltiples funciones que se están ejecutando cuando los comandos en la interfaz X son llamados. Es bueno puntualizar que múltiples conexiones pueden suceder también cuando dos configuraciones son independientemente conectadas en la misma interfaz.

Todas las especificaciones de elementos externos deben estar conectadas. Sin embargo, las especificaciones de los elementos internos no. Concurrencia en NesC

NesC asume un modelo de ejecución, que consiste en ejecutar hasta terminar tareas (task que típicamente representa un programa en curso), y manejadores de interrupción que son señalizados asincrónicamente por hardware. Un planificador para NesC puede ejecutar tareas en cualquier orden. Pero debe obedecer la regla de ejecutar hasta terminar (El estándar de planificadores de TinyOS se comporta como FIFO). Debido a que las tareas no están jerarquizadas y se ejecutan hasta terminar, se podrían considerar atómicas entre ellas, pero no con respecto a los manejadores de interrupción. Como este es un modelo de ejecución concurrente, los programas de NesC son susceptibles de incurrir en condiciones de carrera, en particular las que corresponden a datos en los programas de estado compartido, por ejemplo, sus variables globales y de módulo. NesC no incluye la asignación de memoria dinámica. Estos problemas son evitados teniendo acceso a un estado compartido solamente en tareas, o solamente

53

dentro de declaraciones atómicas. NesC reporta condiciones de carrera en tiempo de compilación.

Formalmente, nosotros dividimos el código en dos partes:

Código Síncrono (SC siglas en ingles): códigos (funciones, comandos y tareas) que sólo pueden ser usados desde una tarea.

Código Asíncrono (AC): códigos que sólo pueden ser usados por al menos un

manejador de interrupción. Aunque, el que no exista preferencia por una u otra tarea elimina las condiciones

de carrera de datos entre las tareas; hay potenciales condiciones de carrera entre SC y AC, así como entre AC y AC. En general, cualquier actualización a un estado compartido que sea accesible desde un AC es una condición de carrera potencial. El NesC básico hace cumplir esto:

Carrera- libre invariante: Cualquier actualización a un estado compartido

solamente es usado en un SC u ocurre en una declaración atómica. El cuerpo de una función f llamada desde una declaración atómica es considerado dentro de la declaración atómica y se considerarán así todas las llamadas a f en la declaración atómica.

Es posible introducir una condición de carrera que el compilador no pueda

detectar, pero esta debe atravesar múltiples declaraciones atómicas o tareas y almacenamiento en variables intermedias.

NesC puede reportar condiciones de carrera que no pueden ocurrir en la práctica, por ejemplo, si todos los accesos son protegidos en una u otra variable. Para evitar mensajes redundantes en este caso, el programador puede marcar una variable v con la palabra reservada norace para eliminar todos los mensajes de precaución para v. Es importante señalar que la palabra norace debe ser usada con precaución. NesC reporta un error en tiempo de compilación, para cualquier comando o evento que sea AC y que no sea declarado con async. Esto asegura que el código que no fue escrito para ser ejecutado de manera segura en un manejador de interrupción no será llamada.

54

Aplicaciones en NesC

Una aplicación en NesC tiene tres partes: una lista de declaraciones de C y definiciones, una colección de tipos de interfaces y una colección de componentes. La manera de nombrar en las aplicaciones de NesC viene estructurada como sigue:

• Uno exterior, con un alcance global con tres espacios de nombres: una variable C y un espacio para las declaraciones de C y las definiciones, y un componente y un espacio para los tipos de interfaces y componentes.

• Las declaraciones de C y las definiciones pueden introducir alcances

jerarquizados sin alcance global (para declaraciones de funciones y definiciones, bloques de código dentro de funciones, etc.).

• Cada tipo de interfaz introduce un alcance que lleva a cabo los comandos o los

acontecimientos de las interfaces. Este alcance se jerarquiza en el alcance global, por lo tanto las definiciones de los comandos y los eventos pueden referir a los tipos y a las etiquetas de C definidos en el alcance global.

• Cada componente introduce dos nuevos alcances. El alcance de la

especificación; esta jerarquizado en un alcance global, contiene una variable namespace que lleva a cabo la especificación de elementos de los componentes. El alcance de la implementación; esta jerarquizado en el alcance de la especificación, contiene una variable y un namespace de la etiqueta.

Miscelánea

1. Funciones que no tienen argumentos, al viejo estilo de las declaraciones de C.

Las funciones de NesC que no tienen argumentos son declaradas con (),

no con (void). Si se usa (void) se obtendrá un error en tiempo de compilación. Los parámetros especificados después de la lista de argumentos no son permitidos en interfaces o componentes.

2. Comentarios.

NesC permite los comentarios mediante el uso de // , en archivos de tipos de interfaces y atributos. 3. Atributos.

NesC soporta tres atributos:

• C: Este atributo es usado para declaraciones de C o definiciones d al nivel mas alto de un módulo (es ignorado por todas las otras declaraciones). Esto especifica que d debería aparecer en el

55

alcance global de C, mas que en el alcance de la implementación por componente del módulo. Esto permite a d ser usado por código en C.

• Spontaneous : Este atributo puede ser usado en cualquier función

f (en módulos o código C). Indica que hay llamadas a f que no son visibles en el código fuente. Típicamente, las funciones son llamadas espontáneamente por manejadores de interrupciones y la función main de C.

• Combine (fnname): Este atributo especifica a una función que

combina para un tipo en una declaración de typedef. La función que combina, especifica como combina los resultados de una llamada a un comando o a un evento, por ejemplo:

especifica un comportamiento como un and lógico, donde combina los comandos o eventos cuyo resultado es result_t. Un error en tiempo de compilación ocurre si la función c combina un tipo t que no tiene el siguiente tipo: t c(t,t).

Ejemplo de uso de atributos en el archivo RealMain.td:

Este ejemplo declara que la función main debería en realidad aparecer en el ámbito global de C, para que el linker pueda encontrarlos. También declara que main puede ser llamada aunque no hay llamadas de la función a main en parte alguna del programa.

56

TINYDB

Tiny Application Sensor Kit (TASK) El desarrollo y despliegue de las aplicaciones de la red de sensores presentan desafíos que desalientan incluso a los mejores desarrolladores de software. Las aplicaciones de la red de sensores combinan la complejidad de diseño de los sistemas distribuidos y la de los sistemas dedicados, y estas son amplificada a menudo por las conexiones de red no fiables y los recursos físicos extremadamente limitados. Por otra parte, se espera que muchas aplicaciones de la red de sensores funcionen sin atención por periodos de meses.

Los usuarios de las redes de sensores que van desde botánicos que supervisan micro-climas en árboles gigantes como la secoya a los encargados de monitorear las señales de vibración en sus equipos, seguramente no son sofisticados desarrolladores de software. Es deseable reducir la complejidad del desarrollo y del despliegue de las aplicaciones de la red de sensores para asegurar el éxito de ésta tecnología en el mundo real.

Muchas de las dificultades en el desarrollo y en el despliegue de las aplicaciones de la red de sensores son causadas por las interfaces actuales de programación de bajo nivel y la carencia de herramientas. En el centro de investigación de Intel en Berkeley, se ha desarrollado un conjunto de herramientas llamadas Tiny Application Sensor Kit (TASK) que esta enfocada a romper la barrera para que los usuarios menos expertos desarrollen y desplieguen sus propias aplicaciones de la red de sensores. Son varios los componentes que constituyen a TASK, el que utilizamos fue el llamado TinyDB a continuación se hace una breve descripción de este componente.

TinyDB es la base del TASK que permite a los programas tradicionales interactuar recíprocamente con la red de sensores con declarativas SQL-como interfaz. El TASK proporciona un número de herramientas de configuración y de interfaces de usuario diseñadas para hacer más fácil interactuar con una red de sensores corriendo con TinyDB. Las características princ ipales son:

- Herramientas de control de la configuración y del despliegue: los usuarios pueden colocar los sensores en un mapa y registrar varias clases de medidas en cada sensor.

- Una interfaz de consultas simple para registrar preguntas.

- Una completa integración con una base de datos relacional para registrar todas

las preguntas, comandos, y resultados enviados a o recibidos de la red.

- Las herramientas de extracción de datos fueron diseñadas para facilitar la consulta de la base de datos en una variedad de aplicaciones para el usuario final.

Las aplicaciones TASK también pueden integrarse fácilmente con la mayoría de las herramientas populares de análisis de datos, por ejemplo, Excel, Matlab, ArcGIS, etc., a

57

través de interfaces estándares de ODBC o de JDBC. Lo que sigue es una guía rápida para el uso de TASK. 1. Después de la instalación de TASK, la base de datos de PostgreSQL necesita ser inicializada antes de que TASK pueda ser utilizada. Primero cambiamos al siguiente directorio:

cd tinyos-1.x/tools/java/net/tinyos/task/tasksvr. En Cygwin, simplemente corremos el:

setup-task-db.sh.

En Linux seguimos los siguientes pasos: a) Como root: mkdir / pgdata; chown postgres / pgdata/ b) cambiar el usuario de postgres. c) corra initdb d) edite /pgdata/pg hba.conf para borrar los caracteres // y descomentar las líneas “ // local all all trust ” y “ // host all all 127.0.0.1 255.255.255.255 trust” y escriba el carácter // para comentar la salida “local all all ident sameuser” al final del archivo. e) corra setup-task-db.sh 2. Programe TASK en los motes desde tinyos-1.x/apps/TASKApp. Se debe programar un mote con el nodo 0 para la estación base. TinyDB

TinyDB es un sistema que realiza queries (consultas) para extraer información de una red de sensores TinyDB, ofrece otra forma de programar los sensores, ya que implementa librerías que manejan la mayoría de las capacidades de NesC, y nos provee de un lenguaje en forma de consultas con una sintaxis parecida a la de SQL, de tal manera que puede especificarse los datos que uno quiere que los sensores recaben, es decir, luz temperatura, etc.

Además de que a dichas consultas se le pueden dar parámetros adicionales, como el tiempo en que los datos serán leídos. Después de hacer una consulta, se comienzan a colectar los datos de los sensores que tengamos trabajando, se filtran y se agregan ruteándolos hacia el nodo 0 que esta conectado a la computadora. Todo esto se hace vía algoritmos que implementan una eficiencia alta, en cuanto a ahorro de energía y el desempeño óptimo de las comunicaciones en la red. TinyDB además incluye una interfaz de propósito general, donde se puede realizar las consultas de una manera sencilla. Algunas características del TinyDB son:

• Manejo de metadatos: Provee un catalogo de metadatos que describe las diferentes clases que están disponibles en la red de sensores.

• Consultas de Alto Nivel: TinyDB usa un lenguaje declarativo para las

58

consultas que permite definir el dato que se desea. • Topología de Red: maneja la red de tal manera que la optimiza, apoyado en el

concepto de usar a sus vecinos como intermediarios, manteniendo tablas de ruteo, y asegurándose de que cada mote pueda entregar de manera eficientemente y confiable sus datos a los usuarios.

• Múltiples consultas: permite que diferentes clases de lecturas sean recabas por

el mismo grupo de motes al mismo tiempo. Estas lecturas pueden ser tomadas a intervalos distintos, aprovechando las bondades de NesC que permite hasta 255 diferentes timers. En general trabaja con una gran eficiencia cuando se usan varias tipos de lecturas.

• Usando esta interfaz de propósito general, se puede uno ahorrar mucho código,

pero el problema es que tener esta aplicación trabajando en una computadora con pocos recursos es realmente tener ganas de flagelarse, pues, es casi imposible. Pero queda abierta la posibilidad de escribir un programa que haga que se realicen las lecturas y que se ejecute en modo comando.

Para que la aplicación corra se necesita que se cumpla con algunos requisitos de

software, en la tabla 4.1 se muestran tales requisitos.

Tabla 4.1. Requisitos de software para la aplicación TinyDB

Para verificar que la aplicación esta trabajando correctamente, compile e instale el codigo de TinyDB, para hacer esto, conecte el mote a la tabla de programación, y teclee lo sigueinte:

• cd tinyos-1.x/apps/TinyDBApp/ • MIB510=/dev/ttyS0 make mica2 install.<nodeid> Para ejecutar TinyDB es necesario usar al menos 2 motes: uno que va a actuar como

estación base y otro más para que recabe los datos deseados comunicándolos al nodo base. Es importante que todos los motes tengan un identificador diferente y que el identificador del nodo base sea 0. Después de programar los motes enciendalos. Se tendrá algo como lo que se ve en la figura 4.1.

Figura 4.1. Configuración para la aplicación TinyDB

59

Pasado con éxito este punto, debemos ahora compilar las clases de java que usa

esta aplicación, es decir la interfaz. Para hacer esto teclee lo siguiente:

• cd tinyos-1.x/tools/java/net/tinyos/tinydb • make • cd tinyos-1.x/tools/java • java net.tinyos.tinydb.TinyDBMain

Es necesario asegurarse de tener los siguientes archivos .jar en su classpath, claro verificándose que existan en el directorio tinyos-1.x/tools/java/jars.:

• Jlex.jar • cup.jar • plot.jar

Después de haber ejecutado el comando java net.tinyos.tinydb.TinyDBMain,

aparecerá la pantalla que se ilustra en la figura 4.2.

Figura 4.2. Interfaz gráfica para TinyDB En esta pantalla se generan las consultas, al ejecutar el comando, también, aparecerá la pantalla que se muestra en la figura 4.3, desde la cual se pueden mandar distintos comandos que ya vienen especificados a la red de motes

60

Figura 4.3. Interfaz gráfica desde la que se pueden lanzar algunos comandos Para usar esta interfaz se escogen los tipos de datos que se desean leer y se mueven desde la lista de atributos disponibles (available attributes) que se encuentra a la izquierda (ver figura 4.2), a la lista de la derecha que es la de los atributos que se van a recabar (projected attributes). Veamos un ejemplo, tomaremos lecturas mediante el sensor de luz, primero se selecciona light en la columna de la izquierda, luego oprimimos el botón que tiene el signo “>>>”. La pantalla debe verse como se muestra en la figura 4.4.

Figura 4.4. Interfaz en la que se selecciona realizar lecturas del sensor de luz

Es de destacar que el texto de abajo muestra como se va formando la consulta, la parte del Sample Period especifica el intervalo en el cual se realizaran las lecturas, los valores son en milisegundos. Es recomendable que seleccionemos, también, el identificador del mote, escogiendo el nodeid de la misma manera como seleccionamos light. La interfaz lucirá como la imagen que se muestra en la figura 4.5.

61

Figura 4.5.Interfaz en la que se selecciona el nodo del que se realizaran las lecturas

Ahora presionamos el botón que tiene la leyenda “Send Query”, y se desplegará una pantalla con las lecturas que se van recibiendo de cada uno de los motes, como se ve en la figura 4.6.

Figura 4.6. Interfaz en la que se desplegaran las lecturas de los sensores

Cuando esta pantalla aparezca, el led rojo en el mote base debe parpadear algunas veces, y casi inmediatamente los leds rojos en los otros motes deben encenderse. Despues de algunos segundos los leds amarillos se encenderan en todos los motes una vez cada segundo, esto indica que todo esta funcionando perfectamente. Si esto no ocurre se puede oprimir el boton con la leyenda “Resend Query” para que reinicie la rutina de inicializacion, se establezca la comunicacion y se reciban las lecturas. Los resultados se desplegaran cada vez que sean recibidos de la red de sensores al mote base y se veran como en la figura 4.7.

62

Figura 4.7. Pantalla en la que se muestran las lecturas de dos motes.

Esto es una introducción a TinyDB, ahora veremos algunas características que vuelven a esta herramienta muy útil y nos permiten realizar infinidad de combinaciones para poder obtener la clase de lecturas deseadas. Características Extras

Veámos la cláusula WHERE, las consultas generadas pueden contener una cláusula WHERE que filtra las lecturas que no deseamos. Por ejemplo, puede que necesitemos conocer los siguientes datos: luz, temperatura, y el nodeid de los motes cuando el valor de la luz sea mayor a 400, esto lo lograríamos con la siguiente sintaxis:

SELECT nodeid,light,temp FROM sensors WHERE light > 400 SAMPLE PERIOD 1024

Para crear una consulta de este tipo puede usarse la interfaz, si presionamos el boton con la leyenda “New Predicate” para indicar que haremos nuestra consulta un poco mas especifica. Seleccionamos light del menú de atributos (Predicative attribute), seleccionamos “>” del menú de operadores comparativos y tecleamos 400 en el campo del valor, como se ve en la figura 4.8.

63

Figura 4.8. Pantalla donde se utiliza la cláusula WHERE.

Es de destacar que también es posible usar la cláusula WHERE sobre el atributo nodeid, de tal manera que se puede seleccionar sólo una parte de la red de motes, de la cual estemos interesados en recibir lecturas.

Operadores de acumulación: TinyDB permite acumular las lecturas que están siendo reportadas por muchos nodos en una lectura. Por ejemplo, para obtener la temperatura media de las lecturas de todos los sensores, donde la luz rebasa el valor de 400, la sintaxis quedaría como sigue:

SELECT AVG(temp) FROM sensors WHERE light > 400

SAMPLE PERIOD 1024 Para especificar esta consulta, seleccione “AVG” de los operadores de

acumulación antes de mover el atributo temp hacia la lista de atributos de la derecha, como se observa en la figura 4.9.

64

Figura 4.9. Uso del operador de acumulación AVG.

Esto se ejecuta de manera eficiente, de tal manera que los motes agregan sus lecturas a las lecturas de sus vecinos y la suma la reenvían hacia el nodo base.

Para crear nuevos atributos, TinyDB en la ventana de comandos implementa un

modo de adicionar nuevos atributos a los ya existentes en el catalogo de la interfaz de TinyDB. Primero presionamos el botón con la leyenda “Add Attribute”, aparecerá una ventana en la cual le asignaremos un nombre, seleccionaremos el tipo de atributo y asignaremos un valor constante. Aceptamos, presionando el botón “OK”. El led verde debe encenderse una vez que los motes reciban el comando que adiciona el atributo. El nuevo atributo debe estar listo para usarse en cualquier consulta que desee, en la figura 4.10 se muestran las interfaces lanzadas por la aplicación.

Figura 4.10. Ventana en la que se agregan atributos a las consultas.

65

Para agregar un atributo sólo a un mote, deseleccionamos el broadcast en la ventana de comandos, y escribimos el identificador del nodo. Se debe tener cuidado, porque si se utiliza un nombre de atributo que ya exista, se sobrescribirá el viejo con las características del nuevo.

Aquí terminamos de revisar la interfaz grafica. Nos enfocaremos ahora hacia como ejecutar las consultas sin utilizar la interfaz. Como se comento antes, es posible correr las consultas en modo texto, para evitarnos usar la interfaz gráfica, sobre todo si no tenemos una maquina con suficientes recursos. Al usar el modo texto, los resultados son arrojados a la pantalla y los motes son reseteados cada vez, actualmente no se pueden correr diferentes consultas al mismo tiempo, mediante este modo. Un ejemplo de como correr una consulta es: java net.tinyos.tinydb.TinyDBMain -run ‘‘select nodeid,light epoch duration 1024’’ y los resultados serían algo parecido a esto:

Ahora revisemos el código de un programa en java que corre independiente de la interfaz, este programa ejecuta una consulta que manda a tomar lecturas de luz de la red de sensores. El programa completo es este: package net.tinyos.tinydb; import net.tinyos.tinydb.parser.*; import java.util.Vector; import java.io.*; public class DemoApp implements ResultListener public DemoApp() try TinyDBMain.initMain(); //parse the query q = SensorQueryer.translateQuery("SELECT light", (byte)1); //inject the query, registering ourselves as a listener for result System.out.println("Sending query."); TinyDBMain.injectQuery( q, this); catch (IOException e) System.out.println("Network error."); catch (ParseException e)

66

System.out.println("Invalid Query."); /* ResultListener method called whenever a result arrives */ public void addResult(QueryResult qr) Vector v = qr.resultVector(); //print the result for (int i = 0; i < v.size(); i++) System.out.print("\t" + v.elementAt(i) + "\t|"); System.out.println(); public static void main(String argv[]) new DemoApp(); TinyDBQuery q; Para ejecutar este programa es necesario ubicarse en el siguiente path tools/java y ejecutar java net.tinyos.tinydb.DemoApp la salida en la pantalla mostrará algo parecido a esto: Listening for client connections on port 9000 SerialPortIO: initializing Successfully opened COM1 client connected from localhost.localdomain (127.0.0.1) Sending query. 1 | 835 | 2 | 833 | 3 | 833 | 4 | 833 | 5 | 833 | 6 | 833 | 7 | 833 | ... Ahora revisemos el programa a detalle. La clase DemoApp implementa la interfaz ResultListener, el método addresult(…) es solo parte de esta interfaz, y puede ser llamado siempre que un dato llegue para una consulta que DemoApp haya lanzado.

Las primeras líneas del constructor de DemoApp() inicializan TinyDB, analizan la consulta, e “inyectan” la consulta en la red: TinyDBMain.initMain(); //parse the query q = SensorQueryer.translateQuery("SELECT light", (byte)1); //inject the query, registering ourselves as a listener for result System.out.println("Sending query."); TinyDBMain.injectQuery( q, this); La llamada a TinyDB.initMain() lee el archivo de la configuración de TinyDB e inicializa la comunicación en la red. En forma implícita, abre su propia conexión al puerto serial, aunque puede ser configurado para compartir la conexión vía un SerialForwarder.

67

Después, la llamada de SensorQueryer.translateQuery(..) convierte la consulta especificada en un objeto de TinyDBQuery; el segundo parámetro ((byte)1) especifica que el identificador para esta consulta debe ser 1; este identificador se puede utilizar para cancelar o para modificar la consulta después de que se haya inyectado a la red.

Finalmente, el TinyDBMain.injectQuery(..) envía la consulta en la red y la comienza realmente a ejecutar. El segundo parámetro, especifica que el objeto de DemoApp se debe colocar como escucha para los resultados de esta pregunta.

Siempre que un resultado llegue para esta consulta, el método addResult será

llamado para imprimir cada campo de cada resultado que llegue.

68

CONCLUSIONES

La tecnología NEST es sin duda de gran utilidad, y pude ser utilizada en distintos sectores, y con distintas aplicaciones. Después de realizar los distintos test que se recomiendan para comprobar el buen funcionamiento de los motes y los sensores. Es pertinente decir que es preferible realizar primero una comprobación de la comunicación en los motes, la mas sencilla es con la aplicación Mote-Test, la forma de usarlo esta descrita en el capitulo 2, pero aunque sea repetitivo no debe olvidarse fijar la frecuencia correcta con respecto a los motes que estemos utilizando, ya que si no se hace esto al realizar la prueba será necesario tener los motes muy cerca de la base para que se comuniquen, sin que esto quiera decir que tengan algún defecto, solo que la frecuencia no es la adecuada, por lo cual la comunicación es defectuosa. En cuanto al software se refiere es importante que se realicen ciertos ajustes para que funcione y sea mas cómodo el uso de las distintas herramientas que ya vienen incluidas en la distribución de el TinyOS, en si el mayor problema que surge es cuando; después de haber realizado el test que prueba el software, usualmente manda un error de la versión de java, porque encuentra la instalación anterior a la que se instaló junto con el TinyOS, el problema se resuelve fácilmente editando el archivo .bash_profile que es la configuración del usuario, un ejemplo de la línea que se debe agregar es la siguiente:

export PATH="/cygdrive/c/tinyos/jdk1.4.1_02/j2sdk1.4.1_02/bin:$PATH" Después de agregar esta línea, usted puede comprobar el software con el test que mencionamos antes, y ya no debe existir problema alguno. El movernos sobre el árbol de directorios del TinyOS es algo tedioso porque tiene rutas muy largas; para mejorar esto es posible agregar un alias en este mismo archivo que nos ayude un poco. Un ejemplo sencillo de esto es por ejemplo la ruta donde se encuentran los programas de java, la línea que se debe agregar es la siguiente: alias javadir=“cd c:/<install dir>/tinyos/cygwin/opt/tinyos-1.x/tools/java”

Después de agregar esta línea, cuando uno quiera moverse hacia los programas de java solo será necesario teclear cd javadir, desde cualquier lugar del árbol de directorios en que nos encontremos ubicados.

Hablando de la parte de la programación, siempre que una variable u otro dato es

modificado, existe la posibilidad de que el dispositivo funcione de manera incorrecta debido a las condiciones de carrera. Una condición de carrera ocurre siempre que una operación no se ejecuta de manera automática, pero necesita coherencia a través de su ejecución. La carrera se da entre una operación no atómica y otro código que debe ejecutarse al mismo tiempo. Al programar en NesC es imperativo ser cuidadosos con este tipo de problemas, dado que usar código que se ejecute de manera asíncrona es la forma más fácil de tener problemas con este tipo de cuestiones.

Otro de los aspectos importantes, por supuesto, es la comunicación entre los

motes, después de haber trabajado con ellos y ver la forma en que trabajan nos damos

69

cuenta de que el éxito de la red de sensores proviene de que implementan protocolos multi-hop para redes inalámbricas.

Las redes ad hoc pueden desplegarse de forma completamente autónoma o

combinarse con las redes locales inalámbricas para conectarse a Internet, utilizando puntos de acceso inalámbricos. Dichas redes deben poder adaptarse dinámicamente ante los cambios continuos de las características de la red, tales como la posición de las estaciones, la potencia de la señal, el tráfico de la red y la distribución de la carga. De entre estas características, el principal reto de las redes ad hoc estriba en los continuos e impredecibles cambios de la topología de la red.

El termino ad hoc, aunque podría ser interpretado con connotaciones negativas

tales como “improvisado” o “desorganizado”, en el contexto de las redes inalámbricas hace referencia a redes flexibles, en las que todas las estaciones ofrecen servicios de encaminamiento para permitir la comunicación de estaciones que no tienen conexión inalámbrica directa. En el desarrollo de las redes de sensores existen aspectos específicos que se necesitan considerar, los nodos pueden dejar de transmitir por alguna falla, lo que nos pasaba con frecuencia era que los movíamos fuera del rango de transmisión. Los protocolos que ocupa están hechos para minimizar el gasto de energía, ya que estamos pensando que nuestros sensores estarán trabajando por muchos meses o tal vez hasta años. Estos protocolos deben ser capaces de determinar dinámicamente cuales nodos son los mejores para transmitir en base a tres criterios, que son el de usar la menor cantidad de energía posible, la calidad del enlace, y la relación de vecindad con los otros motes. Para realizar las distintas pruebas y comenzar a familiarizarse con los motes, los sensores y su funcionamiento es recomendable usar como plataforma windows NT, en este caso nosotros ocupamos Windows XP que está basado en NT. Por la facilidad de la instalación de el TinyOS en Windows ya que solo es necesario correr un ejecutable (wizard) que instalará todo lo indispensable para realizar las pruebas, claro que se necesita una maquina con recursos apropiados tanto de memoria como de espacio en disco, para lograr que funcione correctamente, sobre todo las aplicaciones de java que requieren de mas recursos. Recomendamos contar con un equipo de 128 MB de RAM, pero para que se ejecuten las aplicaciones sin problemas debiera usarse un equipo con 256 MB de RAM. Pero para trabajar con aplicaciones que requieran ejecutar más de una cosa a la vez, o que sea necesario el manejar bases de datos como postgresSQL, es imperativo una plataforma multiproceso, que sea estable y que pueda soportar aplicaciones de este tipo. Recomendamos usar Linux, ya que nos da una gama de posibilidades como la de ejecutar distintos programas a la vez, que es el problema que tiene el cygwin, que emula un kernel de linux, ya que al ejecutar varias cosas dentro de shell, pasma el equipo, y por supuesto no podemos obtener los resultados deseados. Así que en lugar de usar una emulación de Linux, es preferible instalarlo y usar su capacidad, para el caso particular de este proyecto, fue decisivo usarlo, ya que, las aplicaciones en java son ejecutadas sin problemas; más que los derivados de las capacidades de el equipo, los datos obtenidos de la red de sensores, son registrados en una base de datos, como manejador de bases de datos ocupamos postgreSQL, que es, hasta el momento, software libre, ya obtenidas las lecturas, se implemento una página web en la cual se puede acceder a las últimas

70

lecturas que se han registrado en las tablas de acuerdo al dato que se este leyendo del ambiente por los sensores.

La consulta además genera una gráfica, la consulta esta programada en php que nos ofrece librerías para conectarnos a postgresSQL, de tal manera que se pueden leer los datos de la base y trabajar con ellos. Claro, es de esperarse que necesitemos un servidor web, y Linux también nos apoya en ese sentido, ya que utilizamos el servidor de web Apache, el cual también es gratuito, este servidor es fácil de configurar y es estable. Al terminar de configurar tanto el TinyOS como lo referente a la página que mostrará los datos obtenidos en tiempo real por los sensores, podemos decir que tenemos completado el cuadro, y puede uno darse cuenta de las capacidades de esta tecnología, las herramientas están funcionando. Hay un futuro realmente promisorio, ya hay distintos desarrollos que se han implementado con base en esta nueva tecnología, y también distintas universidades están haciendo desarrollo sobre ello. Sólo es necesario adecuarla a aplicaciones específicas que determinarán las necesidades que deberán ser cubiertas por la red de sensores. Existen empresas que ya se han dado cuenta de el enorme potencial que una red de sensores ofrece, tales como York International, que realiza sistemas de ventilación, y planea para los próximos cinco años instalar sensores en red en sus aparatos para monitorear automáticamente las temperaturas y enviar los datos a la central. Sus responsables afirman que gracias a esta medida aliviarían el sobrecargado trabajo de sus más de dos mil técnicos, elevando así la productividad hasta un 15 por ciento. Es crucial el problema de la energía, se manejan distintas formas de solucionar este problema usando energía solar, energía cinética, pero también pensando en lograr un estándar para el hardware. En estos momentos estos sensores están trabajando con baterías, las cuales deben ser revisadas, ya que si se descargan, los motes comienzan a sufrir un mal funcionamiento, en cuanto a los datos que leen los sensores y la comunicación.

71

REFERENCIAS

1] Chen, B., Jamieson, H., Balakrishnan, H, Morris, S. SPAN: An energy-efficient coordination algorithm for topology maintenance in ad hoc wireless networks. Proceeedings of the 7th ACM International Conference on Mobile Computing and Nteworking. 85- 96. Rome Italy, July 2001.

2] Culler, E.D., Hill, J., Buonadonna, P., Szewczyck R., Woo, A. A Network-Centric Approach to Embbedded Software for Tiny Devices.

3] Culler, E.D., Brewer, E., Wagner, D. Secure Language-Based Adaptative Service Plataform (SLAP) for Large-Sacle Embedded Sensor Networks.

4] Crossbow. MTS/MDA Sensor and Data Acquisition Boards User’s Manual. Rev. A, October 2003. Document 7430-0022-02.

5] Crossbow. MPR - Mote Processor Radio Board MIB - Mote Interface / Programming Board User’s Manual. Rev. A, October 2003. Document 7430-0022-05.

6] Crossbow. TinyOS getting started guide. Rev. A, October 2003. Document 7430-0022-03. 7] Suárez, F.A. , Jiménez V.D., Hernández M. E. , Bautista L. M. A. Tarjeta de experimentación

para un microprocesador 80C188EB. Reporte de investigación . División de Ciencias básicas e ingeniería. UAM-Iztapalapa 1999.

8] Hill, J., Culler, E.D. A wireless embedded sensor architecture for system level optimization. In UC Berkeley Technical Report, 2002.

9] http://webs.cs.berkeley.edu/tos/tinyos-1.x/doc/ 10] http://webs.cs.berkeley.edu/tos/tinyos-1.x/doc/