estudio comparativo de sistemas operativos de tiempo …
TRANSCRIPT
ESTUDIO COMPARATIVO DE SISTEMAS OPERATIVOS DE TIEMPO REAL APLICADO A REDES
DE SENSORES INALAMBRICAS.
José Ulloa Suárez.
Sociedad Agrícola Ojos Buenos Ltda.
INDICE
1 Introducción ............................................................................................................... 3 2 Desarrollo .................................................................................................................. 4
2.1 Características de las redes de sensores. .......................................................... 4 2.2 Presentación de distintos Sistemas Operativos ................................................. 5
2.2.1 TinyOS. ......................................................................................................... 5 2.2.2 PalOS. .......................................................................................................... 9 2.2.3 SOS . .......................................................................................................... 11
2.3 Comparaciones entre estos Sistemas. ............................................................. 13 3 Conclusiones. ........................................................................................................... 15 4 Referencias. ............................................................................................................. 16
2
1 Introducción
Las redes de sensores inalámbricas se insertan bajo un nuevo enfoque en el desarrollo de tecnologías para la obtención de datos, y que son aplicables a variados campos, tales como el policial (seguridad en recintos), industrial (vigilar el estado de maquinarias, de procesos de ensamblaje, etc ), agrícola (sensar estado de la tierra, el crecimiento de los frutos, etc) entre otros. Principalmente estas apuntan a integrar sistemas autónomos, para la obtención conjunta y posterior procesamiento de información.
Específicamente hablamos de dispositivos autónomos distribuidos sobre una región de trabajo, capaces de establecer comunicación sin cables entre ellos, y que incluyen además medir variables físico-ambientales, ya sea niveles de temperatura, humedad, etc., para luego enviar los datos obtenidos a un servidor central en el cual se almacenarán y procesarán.
A través de redes de sensores, se puede integrar funcionalidades que antes eran independientes unas de otras, con el fin de lograr máxima eficiencia y optimización de recursos.
En el presente trabajo se expondrán distintos sistemas operativos que se pueden ejecutar sobre estas plataformas.
Primero será necesario contextualizar el problema, por lo que se presentarán las restricciones a cumplir tanto para los dispositivos electrónicos (microprocesadores ó microcontroladores), como para el sistema operativo.
De éste ultimo, presentaremos características, comparaciones, y restricciones de uso de algunas de las propuestas presentes hoy.
3
2 Desarrollo
2.1 Características de las redes de sensores.
Esta sección enseña los requerimientos que forman el diseño de redes de sensores1
• Tamaño físico pequeño y bajo consumo de energía.
En cualquier punto de la evolución tecnológica, el tamaño y la energía han restringido el procesamiento, almacenamiento, y las capacidades de interconexión de dispositivos.Obviamente si se reduce el tamaño y la energía, estamos forzando el uso de nuevos tecnologías en hardware y asimismo en software, el cual debe ser capaz de usar de manera eficiente el procesador y la memoria, ocupando un mínimo de energía para la realización de sus tareas.
• Operaciones de Concurrencia Intensiva.
El principal modo de operación de estos dispositivos, consiste en que fluya información de un lugar a otro, con una cantidad reducida de procesos, que se resumen en aceptar un comando, parar, pensar, y responder.Por ejemplo, la información puede ser capturada simultáneamente por sensores, manipulada, y fluir sobre la red hacia el destinatario. Alternativamente, se pueden recibir datos desde otros nodos y por ende deben ser encaminados también a su destino. En general existe poca capacidad de memoria interna, así que el almacenamiento de cantidades grandes de datos, ya sea para enviar o para ser recibidos desde otros nodos debe ser evitado. Por otra parte, cada uno de las reenvios de información (saltos) implica generalmente una gran cantidad de eventos de bajo nivel (interactuar a niveles de capa física y red) que se comunicarán con procesos de niveles superiores (es necesario desempaquetar para obtener información).
• Diversidad en diseño y uso:
La tendencia de los dispositivos de redes de sensores es a dar respuesta a aplicaciones específicas, más que aplicaciones con fines de uso general, por lo cual sólo se compondrán de lo justo y necesario, esto motivado principalmente para reducir los costos. Dado que existe una amplia gama de usos potenciales, nuevos y variados dispositivos físicos irán apareciendo. Además en cualquier dispositivo, es importante montar fácilmente apenas los componentes de software requeridos, de manera de sintetizar el uso de los componentes de hardware. Es por eso, que estos dispositivos requieren un grado inusual de modularidad en el software. Un ambiente genérico de desarrollo es necesario, con el que se permita la construcción de aplicaciones específicas a partir de un espectro de dispositivos existentes, sin necesidad de partir de cero.
• Operación Robusta.
Estos dispositivos serán numerosos, en gran parte desatendidos, y se esperará que tengan un tiempo operacional largo.
1 Para un mayor detalle remítase a la lectura de [1]
4
La implementación de técnicas tradicionales de redundancia para garantizar la confiabilidad de unidades individuales, está limitada en muchas ocasiones tanto por el espacio como por la energía. Así realzar la confiabilidad de dispositivos individuales es esencial. Además, es posible aumentar la robustez del uso tolerando fallas individuales del dispositivo. A tal efecto, el sistema operativo que funciona en un solo nodo no debe solamente ser robusto, sino también debe facilitar el desarrollo de usos distribuidos confiables.
Además se tienen ciertos parámetros, que no tienen relación con restricciones de hardware, sino más bien con aspectos logísticos, entre las que se destacan:
• Gastos económicos que se deban incurrir por parte del que desea desarrollar una aplicación.
• Disponibilidad de información, en el que se incluye manuales, tutoriales y aplicaciones.
• Existencia de grupos de desarrolladores, de forma de asegurar una constante depuración y perfeccionamiento del sistema disponible.
• Modelo de programación modular, de forma de adaptarse a nuevas tecnologías, para así por ejemplo reciclar códigos.
Antes de presentar los distintos sistemas operativos a analizar, resulta necesario definir ciertos aspectos generales en los sistemas operativos, las metodologías de diseño, y los porque de su aplicación a las redes de sensores inalámbricas.
2.2 Presentación de distintos Sistemas Operativos
Múltiples son los sistemas operativos para sistemas embebidos, mas no todos satisfacen las restricciones que imponen las Redes de Sensores Inalámbricas (RSI), motivo por el cual quedan descartados inmediatamente.Así por ejemplo dada las restricciones de tamaño y ahorro de energía de los nodos que conformarán la red, es que todos aquellos microprocesadores que no sean de bajo consumo, quedan descartados. Por lo general entre estos, se incluyen los iguales o superiores a los clasificados como de “rango mediano” dentro de las categorías de microprocesadores (poseen alta disponibilidad de memoria, consumo mayor de energía, etc.). De esta forma los sistemas operativos también quedan restringidos a funcionar sobre estas arquitecturas.
A continuación se presentarán tres de los principales Sistemas Operativos para redes de sensores, que cumplen con los requisitos expuestos.
2.2.1 TinyOS.
El diseño de TinyOS está basado en responder a las características y necesidades de las redes de sensores, tales como integración en un tamaño físico reducido, bajo consumo de energía, operaciones de concurrencia intensiva, diversidad en diseños y usos, y finalmente operaciones robustas para facilitar el desarrollo confiable de aplicaciones. Además se encuentra optimizado en términos de uso de memoria y eficiencia de energía.
Existen dos niveles de scheduler, uno para los eventos y otro para las tareas. De esta forma permitimos que los eventos (que son rápidamente ejecutables), puedan
5
ser realizados inmediatamente, pudiendo interrumpir a las tareas (que tienen mayor complejidad en comparación a los eventos).
El diseño del Kernel de TinyOS está basado en una estructura de dos niveles de planificación:
• Eventos: Pensados para realizar un proceso pequeño (por ejemplo cuando el contador del timer interrumpe, o atender las interrupciones de un conversor análogo-digital). Además pueden interrumpir las tareas que se ejecutan. . El manejador de eventos es responsable de colocar la tarea en un “administrador” o “planificador”, conocido como “Scheduler 2” de tareas.
• Tareas: Pensadas para hacer una cantidad mayor de procesamiento y que no son críticas en tiempo (por ejemplo calcular el promedio en un arreglo). Las tareas se encuentran pensadas para ser ejecutadas en su totalidad, pero la solicitud de iniciar una tarea, y el término de ella son funcionen separadas. Esta característica es propia de la programación orientada a componentes, la cual se presentará en detalle en la sección siguiente.
Diseño en TinyOS: Modelo de Componentes.
TinyOS ha sido desarrollado sobre NesC, un meta-lenguaje que se deriva de C, y que ha sido diseñado para responder a las necesidades que existen en los sistemas embebidos. Cada componente usa eventos y comandos que rápidamente permitan la transición de un estado a otro. Cada componente se asigna temporalmente al contexto de ejecución mientras duren los cambios del estado. Además se ha agregado a este modelo la noción de “tareas”, que permiten que las componentes soliciten el contexto de ejecución en la CPU para realizar cómputos o procesamientos duraderos. Estas tareas se ejecutan completamente con respecto a otras tareas, es decir, las tareas no pueden dividirse para comenzar con otra y luego retomarlas, más si pueden ser interrumpidas periódicamente por acontecimientos de una prioridad más alta (eventos). Actualmente se utiliza una cola simple FIFO (primero en entrar, primero en salir) para el scheduler, no obstante un mecanismo alternativo podría ser agregado fácilmente.
Una ventaja secundaria de elegir este modelo de programación, es que propaga las abstracciones del hardware en el software. Tal como el hardware responde a cambios de estado en sus pines de entrada/salida, nuestras componentes responden a eventos y a los comandos en sus interfaces.
Podemos entonces decir que TinyOS consiste en un pequeño scheduler y un gráfico de componentes. Esto se puede observar en la figura 2.2.1.1, donde se muestra como se compone una componente, destacando cuatro elementos correlacionados, y que procedemos a detallar continuación:
1. Manejador de comandos.2. Manejador de eventos3. Un frame3 de tamaño fijo y estáticamente asignado, en el cual se representa
el estado interno de la componente.4. Un bloque con tareas simples.
2 Desde ahora en adelante se ocupará este término.3 En este caso nos referimos a un “bloque” que proporciona el contexto en cual se ejecuta el programa y se almacenaran las variables.
6
Figura 2.2.1.1 : Modelo de componentes de TinyOS y su interacción.
La componente declara los comandos que se utilizarán y los eventos a señalizar. Con esta declaración, los gráficos de componentes (modulares) pueden ser compuestos. Este proceso de composición crea capas o niveles de componentes. Componentes de niveles superiores proveen comandos a las de niveles inferiores, y éstos señalan eventos a los componentes de un nivel superior. Para proporcionar una definición abstracta de la interacción de dos componentes vía comandos y eventos, es que se introduce una interfaz bidireccional en TinyOS.
Los comandos son peticiones no-bloqueadoras, hechas a componentes de capas inferiores. Un comando proporciona retroalimentación, entregando la información del estado al que lo envió. Típicamente, el manejador de comandos pone los parámetros en el frame y agrega una tarea, en la cola de tareas, para su ejecución. La respuesta que indica si el comando fue aceptado, se puede señalar por un evento. Los comandos dejan los parámetros de las solicitudes en el frame, la necesidad de volver estado así que pospone el trabajo desperdiciador de tiempo fijando una tarea y puede llamar al comando de nivel inferior.
Los manejadores de eventos son invocados por eventos de componentes de capas inferiores, o por interrupciones cuando se esta directamente conectado al hardware. Similar a los comandos, el frame será modificado y las tareas agregadas. Ambos, tareas y comandos, realizan un trabajo (fijo y pequeño) similar al de las rutinas de servicio de interrupciones.
Eventos pueden llamar comandos, señales de eventos, agregar tareas, pero no pueden ser señalizados por comandos. Los eventos tienen preferencias sobre las tareas, no así viceversa, dispara interrupciones de eventos de niveles inferiores y deposita la información en el frame.
Las tareas realizan el trabajo primario. se ejecutan hasta terminar y pueden ser sólo pospuestas por eventos, por ejemplo, el enrutar un paquete que llegó al nodo. Las tareas son encoladas en un planificador de tareas (task scheduler) implementado con FIFO para realizar un retorno inmediato de las rutinas manejadores de eventos y comandos. Debido a su implementación FIFO, las tareas se ejecutan secuencialmente y deben ser cortas. Alternativamente al planificador de tareas FIFO, planificadores basados en prioridades (priority-based) o basados en plazos (deadline-based), pueden ser puestos en ejecución en TinyOS.
Su buen desempeño y su desarrollo abierto, han afectado positivamente en el mejoramiento del sistema en sí, e influido en la creación de herramientas que facilitan el diseño y trabajo, tales como simuladores, administradores de bases de datos, máquinas virtuales que permiten reprogramación en línea, etc.
7
Además destaca el hecho de contar con una cantidad numerosa de aplicaciones preconstruidas, las que implementan procesamientos de datos y algoritmos de enrutamientos.
8
2.2.2 PalOS.
Palos está implementado en lenguaje C y por lo tanto facilita emigrar a distintos procesadores. Sin embargo, esto es sólo posible porque la capa de abstracción del hardware está introducida en el software. A continuación en la figura 2.3.2.1 se muestra la esencia del software para una tarea simple.
Independiente delHardware
Interfase Independiente,
Dependencia con el Hardware (Procesador)
figura 2.3.2.1 : Estructura del Software.
La capa de abstracción del hardware (Register abstraction) encapsula todos los registros en macros (de esta forma no es necesario estar configurando a nivel de bits). Esto es útil, dado que en el momento que la arquitectura del procesador cambie, sólo bastará con redefinir las macros, mientras que el código principal no necesitará ser modificado.
La capa de Driver exporta las funcionalidades del hardware de una específica interfaz física sobre el procesador, a la interfaz independiente (Manager). Un driver es casi independiente del hardware del procesador. Una de las razones de su independencia, es porque distintos procesadores proveen diferentes métodos de implementación para una misma funcionalidad, por lo cual a veces es necesario especificar un orden específico en las líneas de programación.
Finalmente los manejadores (managers) componen la funcionalidad exportada de uno o más drivers, los que finalmente interaccionan con el hardware a partir de las necesidades que las tareas deban ir cumpliendo.
Tareas y su programación.
Cada tarea mantiene una propia cola de eventos. Sin embargo, cada tarea puede poseer una entrada o salida física (probablemente, más tareas serán basadas sobre una interfase física). En la fase de inicialización del programa, cada tarea registra una tarea de eventos en la programación del sistema. Si la tarea 1 desea hablar con la tarea 2, postea un evento en la cola de eventos de la tarea 2, usando una funcionalidad del “Programador del Sistema” (System Scheduler), para luego la tarea 2 capture ese evento al preguntar al “Programador del Sistema” si tiene algún evento para él. Este concepto queda reflejado en el siguiente diagrama.
9
figura 2.3.2.2 Programador del Sistema.
Para un correcto funcionamiento de esta estructura de software, es necesario que un “timer” maneje la periodicidad con que una tarea registra eventos. La forma en que se implementa es a través de una tarea “timer”. Esta posee tres colas : la primera para interactuar con las demás tareas –recibe el envío de otras tareas-, la otra conocida como “Cola Delta”, en la cual se ordenan los distintos eventos dependiendo del tiempo de expiración y que finalmente son enviados a la cola de “Eventos Expirados”, para su posterior ejecución.
Es importante mencionar ahora que el código del programa consta de un ciclo infinito (loop), en el cual todas las tareas son llamadas secuencialmente. Un modelo de esto sería lo siguiente:
void main(){ initAll(); … while(1) { TASK1(); TASK2(); … TASKn(); }}
10
2.2.3 SOS 4.
SOS es un sistema operativo desarrollado en la Universidad de California, específicamente en el NESL (Networked & Embedded Systems Laboratory).
SOS es un sistema operativo para redes de sensores que procura remediar algunos de las limitaciones propias de la naturaleza estática de muchos de los sistemas precursores a éste (por ejemplo TinyOS).
SOS implementa un sistema de mensajería que permite múltiples hebras entre la base del sistema operativo y las aplicaciones, las cuales pasan a ser módulos que pueden ser cargadas o descargadas en tiempo de ejecución sin interrumpir la base del sistema operativo. El principal objetivo de SOS es la “reconfigurabilidad”.
Ésta se define como la habilidad para modificar el software de nodos individuales de una red de sensores, una vez que estos han sido desplegados físicamente e inicializado su funcionamiento. En el caso de encontrar un problema, en caso de no contar con esta solución, habría sido necesario recolectar todos los nodos para poder modificar su software.
La capacidad de dinámicamente agregar o remover módulos, permite la construcción de software mucho más tolerante a fallas. Esto presenta dos grandes ventajas: uno es el hecho de poder realizar updates fácilmente, y el otro es la capacidad de anular el funcionamiento de algún módulo defectuoso, de algún nodo que pertenece a la red.
Arquitectura del sistema.
Además de las técnicas tradicionales usadas en el diseño de sistemas embebidos, las características del kernel de SOS son:
• Módulos cargados dinámicamente.• Programación flexible de prioridades.• Simple subsistema de memoria dinámica.
Las capas de abstracción de hardware y drivers son las mismas que las descritas en la sección 2.3.2 para el sistema PalOS.
A continuación se muestra un esquema de la arquitectura de SOS.
4 Información obtenida desde http://nesl.ee.ucla.edu/projects/sos/publications/
11
figura 2.3.3.1 Capas funcionales de SOS.
Para mayor información acerca de las características y funcionamiento de SOS remétase a leer el paper “A dinamic Operating System for Sensor Nodes” [3]
12
2.3 Comparaciones entre estos Sistemas. A continuación mostramos cuadros comparativos entre los distintos sistemas operativos presentados.
En este primer cuadro se comparan en función de ciertos parámetros, el diseño y funcionalidad de los distintos sistemas operativos.
SOS TinyOS PalOS
Madurez del Código Base Version inicial
Versión estable y aprontándose la versión 2.0 Versión estable.
Plataformas actualmente soportadas AVR and ARM AVR ,MSP430 AVR,ARM.
Sensores Soportados
MTS310 (sensor board), xbow Crossbow series
Los disponibles en los módulos MK-II. 5
Aplicaciones Soportadas En desarrollo Establecidas EstablecidasDocumentación Tutorial Básico
Multiple, repositorio. Básica.
Lenguaje de Programación C nesC C
Scheduling6 Colas de Prioridad
Para tareas implementa FIFO7, interrupciones controladas por eventos.
Controlada por eventos.
Localización en Memoria Dinámica Estática EstáticaComunidad de Desarrolladores Reciente Muchos Muchos
Tabla 1: Comparaciones entre los sistemas.
5 Plataforma de red de sensores inalámbricos desarrollado en la Universidad de California.6 Programador o administrador de las tareas del sistema operativo.7 Modelo que se define en las colas como “primero en entrar es el primero en salir”.
13
A continuación un cuadro que resume las principales variables a considerarse para la toma de una decisión.
TinyOS PalOS SOS
Lenguaje
Programado en nesC, lenguaje especialmente
diseñador para el funcionamiento de las
redes de sensores inalámbricas
Escrito en ansi C Escrito en ansi C
Flexibilidad y
Dinamismo.
Si bien no incorpora ni comunicación entre tareas,
ni manejo dinámico de componentes en el sistema nativo, existen aplicaciones
que permiten su incorporación, sin
disminuir el desempeño.
Permite comunicación entre procesos. A través
de las colas de eventos
Permite manejo dinámico de memoria y
modificaciones “al vuelo”
MadurezVersiones estables y en
constante desarrolloVersión estable la define el “Loop Principal” descrito en la sección de PalOS.
Aún se encuentra en proceso de
estandarización.
Plataformas
AVR , MSP430 y Microchip AVR y ARM AVR y ARM
SoporteMucha Documentación y
grupos de apoyo.Tutoriales Tutorial
Básico
Tabla 2. Principales variables a considerarse.
14
3 Conclusiones.
Dada las características de las redes de sensores inalámbricas, se hace crítico el uso de tecnología estable y con perspectivas a futuro. Si bien los tres sistemas estudiados satisfacen las restricciones expuestas en la sección 2.1, la existencia de una base sólida sobre la cual comenzar a desarrollar las aplicaciones, contando con la información necesaria, es esencial y crítica.
SOS presenta una propuesta innovadora, que integra dentro de su sistema, ciertas carencia que sistemas estándares (TinyOS) presentan, tales como la capacidad de insertar y remover módulos de software (para actualizaciones por ejemplo), como el hecho de implementar usos de memoria dinámica.
Estas características pueden ser implementadas en sistemas como TinyOS, pero demandan un mayor esfuerzo y un alto nivel de complejidad (máquinas virtuales). Lamentablemente, inherente a su génesis, su desarrollo se encuentra pasos atrás en lo que a estabilidad y robustez de sistema se refiere.
PalOS resulta ser una propuesta más débil, su desarrollo y estudio por parte de grupos de usuario es bastante pobre principalmente debido a la simplicidad de su sistema. A criterio, PalOS resulta ser una solución a considerar para sistemas que implementan aplicaciones simples.
Hoy en día TinyOS se define como el estándar para las redes de sensores inalámbricas, debido principalmente a su extenso uso por parte de desarrolladores de aplicaciones para este tipo de sistemas. La gran cantidad de grupos de trabajo, el soporte existente en documentación, las plataformas soportadas (gran disponibilidad de librerías que sólo deben ser cargadas en el momento de desarrollar una aplicación), las múltiples aplicaciones desarrolladas, su madurez y finalmente el amplio uso (que verifica su funcionalidad) hace de TinyOS la alternativa más segura y conveniente en la hora de tomar una decisión.
En lo que a nuestro proyecto se refiere (redes de sensores inalámbricos aplicados a la agricultura), las características y ventajas de TinyOS son de gran importancia, y es por eso que se trabajará con éste.
Sin embargo, dada las características de SOS, estaremos revisando constantemente el desarrollo y los avances que éste pueda presentar, de forma de estar al tanto y poder ir así analizando las innovaciones que éste genere.
15
4 Referencias.
[1] System Architecture Directions for Networked SensorsJason Hill, Rober t Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer PisterDepar tment of Electrical Engineering and Computer SciencesUniversity of California, BerkeleyBerkeley, CA
[2] Motivations Behind SOSRoy Shea, Simon Han, Ram RengaswamyFebruary 20, 2004
[3] “A Dynamic Operating System for Sensor Nodes”Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler and Mani Srivastava University of California, Los Angeles
16
Estudio y Análisis de las Características de TinyOS.
17
Índice
1 Introducción ............................................................................................................... 3 2 Desarrollo. ................................................................................................................. 4
2.1 Conociendo a TinyOS. ......................................................................................... 4 2.1.1 ¿Qué es TinyOS? .......................................................................................... 4 2.1.2 ¿Qué es necesario para su funcionamiento? .............................................. 4 2.1.3 Cómo comenzar. ........................................................................................... 4
2.2 Introducción a TinyOS. ....................................................................................... 5 2.3 NesC. ................................................................................................................... 6 2.4 TinyOS. ................................................................................................................ 8
2.4.1 Tipos de Componentes. ............................................................................... 9 2.4.2 Ejemplo de una componente. ................................................................... 10 2.4.3 Implementación de una componente. ...................................................... 12 2.4.4 Ejemplo de una aplicación completa. ....................................................... 12 2.4.5 Modelo de Comunicación. ......................................................................... 13
2.5 Componentes contenidas en TinyOS. .............................................................. 13 3 Conclusiones. ........................................................................................................... 15 4 Referencias. ............................................................................................................. 16 Anexos. ....................................................................................................................... 17
4.1 AM Communication Paradigm ......................................................................... 17 4.1.1 Active Messages Overview ........................................................................ 17 4.1.2 Tiny Active Messages Implementation ..................................................... 17
18
5 Introducción
En el presente documento se presentarán las características del sistema operativo “TinyOS”, desarrollado en la Universidad de Berkeley como sistema base para la construcción de aplicaciones en sistemas embebidos, específicamente redes de sensores inalámbricas (RSI).
El objetivo y alcance de este documento es discutir características que TinyOS posee, abarcando tópicos que van desde responder preguntas tales como ¿qué es? o ¿qué se necesita para su funcionamiento?, para pasar luego a ver la filosofía de su implementación y funcionamiento, su lenguaje de programación, el estudio de los modelos de ejecución y de “componentes”, hasta presentar a modo de resumen una lista de las componentes existentes y que pueden utilizarse para una implementación.
Durante este trabajo se mencionará bastante el término “componente”. La metodología de diseño en programación para el trabajo sobre este tipo de sistemas, es conocida como “programación orientada a componentes”, y se encuentra referido a la forma en que se conciben las aplicaciones, las cuales se diseñan de forma modular, definiendo entradas y salidas a ésta. Además siguiendo la idea de separar para lograr un mejor entendimiento y facilidad en el diseño, es que se definen dos tipos de componentes: los módulos, y de configuración. En la medida en que se avance en la lectura de este documento, se irá asimilando mejor esta idea.
19
6 Desarrollo.
6.1 Conociendo a TinyOS.
6.1.1 ¿Qué es TinyOS?TinyOS en un sistema operativo para trabajar con redes de sensores, desarrollado en la Universidad de Berkeley. TinyOS puede ser visto como un conjunto de programas avanzados, el cual cuenta con un amplio uso por parte de comunidades de desarrollo, dada sus características de ser un proyecto de código abierto (Open Source8). Este “conjunto de programas” contiene numerosos algoritmos, que nos permitirán desde generar enrutamientos, como también aplicaciones pre-construidas para sensores. Además soporta diferentes plataformas de nodos de sensores 9, arquitecturas bases para el desarrollo de aplicaciones.Como veremos más adelante, el lenguaje en el que se encuentra programado TinyOS es un meta-lenguaje que deriva de C, cuyo nombre es NesC. Además existen variadas herramientas que ayudan el estudio y desarrollo de aplicaciones para las redes de sensores, que van desde aplicaciones para la obtención y manejo de datos, hasta sistemas completos de simulación. Sin duda esta respuesta puede ampliarse bastante, y es objetivo de este documento presentar todas las características que TinyOS posee, y por ende lo definen.
6.1.2 ¿Qué es necesario para su funcionamiento?Aunque puede trabajar en otras plataformas, las plataformas apoyadas son Linux (RedHat 9), Windows 2000, y Windows XP. Es importante mencionar que el proyecto se inicio sobre BSD (Unix), por lo cual para el funcionamiento en Windows se hace necesario la instalación de Cygwin, un simulador de plataformas unix, siendo necesario tener básicos conocimientos acerca de este entorno. Además muchas de las herramientas disponibles se encuentran desarrolladas para plataformas JAVA, por tanto también es necesaria su instalación. La instalación de éstas en sistema Windows se realiza de forma transparente, puesto que existe un paquete ejecutable, el cual además realiza toda la configuración del sistema.La programación de dispositivos se puede realizar a través de distintos puertos, dependiendo del módulo con el que se cuente. Estos pueden ser serial, paralelo o ethernet. Es entonces necesario contar con al menos uno de estos puertos en el PC.
6.1.3 Cómo comenzar.Tal como se mencionaba, TinyOS es un proyecto de la Universidad de Berkeley, es por esto que el foco principal de información se encuentra en la página del proyecto presente en el servidor de ésta. A continuación se mencionan algunos links importantes.
Dirección Contenido
http://www.tinyos.net Página Principal del Proyecto.
http://www.tinyos.net/download.htmlSección donde se pueden bajar las ultimas versiones del sistema operativo
http://www.tinyos.net/support.htmlPágina con el soporte para TinyOS
http://www.tinyos.net/tinyos-1.x/doc/tutorial/index.html
Tutorial on-line.
8 http://www.sourceforge.net9 En la Universidad de California, Berkeley el desarrollo de los nodos de sensores se ha basado en los “Motes”, más información en http://www.tinyos.net.
20
http://sourceforge.net/projects/tinyos/
Control de Versiones (CVS) de TinyOS, en el se pueden encontrar tanto aplicaciones que se encuentran en desarrollo para implementarse con TinyOS, como el desarrollo del código fuente de éste.
Tabla 2.1.3.1 Principales links.
6.2 Introducción a TinyOS.
El diseño de TinyOS está basado en responder a las características y necesidades de las redes de sensores, tales como reducido tamaño de memoria, bajo consumo de energía, operaciones de concurrencia intensiva, diversidad en diseños y usos, y finalmente operaciones robustas para facilitar el desarrollo confiable de aplicaciones. Además se encuentra optimizado en términos de uso de memoria y eficiencia de energía.
El diseño del Kernel de TinyOS está basado en una estructura de dos niveles de planificación.
• Eventos: Pensados para realizar un proceso pequeño (por ejemplo cuando el contador del timer se interrumpe, o atender las interrupciones de un conversor análogo-digital). Además pueden interrumpir las tareas que se están ejecutando.
• Tareas: Las tareas son pensadas para hacer una cantidad mayor de procesamiento y no son críticas en tiempo (por ejemplo calcular el promedio en un arreglo). Las tareas se ejecutan en su totalidad, pero la solicitud de iniciar una tarea, y el término de ella son funciones separadas. Esta característica es propia de la programación orientada a componentes, la cual se presentará en detalle en la sección siguiente.
Con este diseño permitimos que los eventos (que son rápidamente ejecutables), puedan ser realizados inmediatamente, pudiendo interrumpir a las tareas (que tienen mayor complejidad en comparación a los eventos).
El enfoque basado en eventos es la solución ideal para alcanzar un alto rendimiento en aplicaciones de concurrencia intensiva. Adicionalmente, este enfoque usa las capacidades de la CPU de manera eficiente y de esta forma gasta el mínimo de energía.
Ahora bien, tal como se mencionaba en la sección 2.1.1, TinyOS se encuentra programado en NesC, un lenguaje diseñado para reflejar las ideas propias del enfoque de componentes, incorporando además un modelo de programación que soporta concurrencia, manejo de comunicaciones y fácil interacción con el medio (manejo de hardware). TinyOS y NesC se encuentran profundamente relacionados, es por eso que a continuación presentaremos un pequeño resumen con algunas de las características de este lenguaje.
21
6.3 NesC.
NesC es un meta-lenguaje de programación basado en C, orientado a sistemas embebidos que incorporan el manejo de red. Además soporta un modelo de programación que integra el manejo de comunicaciones, las concurrencias que provocan las tareas y eventos y la capacidad de reaccionar frente a sucesos que puedan ocurrir en los ambientes donde se desempeña (por ejemplo, sensar).
También realiza optimizaciones en la compilación del programa, detectando posibles carreras de datos que pueden ocurrir producto de modificaciones concurrentes a un mismo estado, dentro del proceso de ejecución de la aplicación. Además simplifica el desarrollo de aplicaciones, reduce el tamaño del código, y elimina muchas fuentes potenciales de errores.
Básicamente NesC ofrece:
• Separación entre la construcción y la composición. Hay dos tipos de componentes en NesC: módulos y configuraciones. Los módulos proveen el código de la aplicación, implementando una o más interfaces. Estas interfaces son los únicos puntos de acceso a la componente. Las configuraciones son usadas para unir las componentes entre sí, conectando las interfaces que algunas componentes proveen con las interfaces que otras usan.
• Interfaces bidireccionales: tal como ya se explicaba anteriormente las interfaces son los accesos a las componentes, conteniendo comandos y eventos, los cuales son los que implementan las funciones. El proveedor de una interfaz implementa los comandos, mientras que el que las utiliza implementa eventos.
• Unión estática de componentes, vía sus interfaces. Esto aumenta la eficiencia en tiempos de ejecución, incrementa la robustez del diseño, y permite un mejor análisis del programa.
• NESC presenta herramientas que optimizan la generación de códigos. Un ejemplo de esto es el detector de “carreras de datos”, en tiempo de compilación.
Finalmente y a modo de resumen, mencionamos los principales aspectos que el modelo de programación NesC ofrece y que deben ser entendidos para el entendimiento del diseño con TinyOS:
1. Tal como se mencionó el modelo de NesC está formado por interfaces y componentes.
2. Una interfaz puede ser usada o puede ser provista, las componentes son módulos o configuraciones.
3. Una aplicación se verá representada como un conjunto de componentes, agrupados y relacionados entre sí, tal como se observa en la figura 2.3.1
22
Figura 2.3.1 Aplicación.
4. Las interfaces se utilizan para operaciones que describen la interacción
bidireccional; el proveedor de la interfaz debe implementar comandos, mientras que el usuario de la interfaz debe implementar eventos.
5. Existen dos tipos de componentes:5.1. Módulos, que implementan especificaciones de una componente.5.2. Configuraciones, que se encargarán de unir (wire) diferentes componentes
en función de sus interfaces, ya sean comandos o eventos.
En la figura 2.3.2 se muestra un diagrama de bloques en el que se describe el proceso de compilación para una aplicación TinyOS. Mayor información acerca de NesC, remítase al “Manual de Referencia del Lenguaje” [1].
Ahora bien, comprendido estos conceptos, es posible dar el paso siguiente hacia el entendimiento del diseño en TinyOS.
Figura 2.3.2 Compilación de una aplicación TinyOS.
23
6.4 TinyOS.
TinyOS posee un modelo de programación característico de los sistemas embebidos: el modelo de componentes. Tal como se ha mencionado TinyOS esta escrito en NesC, lenguaje que surge para facilitar el desarrollo de este tipo de aplicaciones. A continuación se presentan las ideas de este modelo.
• Arquitectura basada en componentes: TinyOS se encuentra construido sobre un conjunto de componentes de sistema, las cuales proveen la base para la creación de aplicaciones. En la figura 2.4.1 se muestra el modelo de una componente. Conectar estas componentes, usando un conjunto de especificaciones detalladas, es lo que finalmente definirá una aplicación. Este modelo es esencial en sistemas embebidos para incrementar la confiabilidad, sin sacrificar desempeño.
• Concurrencia en tareas y en eventos: Las dos fuentes de concurrencia en TinyOS son las tareas y los eventos. Las componentes entregan tareas al planificador, siendo el retorno de éste de forma inmediata, aplazando el cómputo hasta que el planificador ejecute la tarea. Las componentes pueden realizar tareas siempre y cuando los requerimientos de tiempo no sean críticos. Para asegurar que el tiempo de espera no sea muy largo, es que se recomienda programar tareas cortas, y en caso de necesitar procesamientos mayores, se recomienda dividirlo en múltiples tareas. Las tareas se ejecutan en su totalidad, y no tiene prioridad sobre otras tareas o eventos. Así tambien los eventos hasta completarse, pero estos sí pueden interrumpir otros eventos o tareas, con el objetivo de cumplir de la mejor forma los requerimientos de tiempo real.
• Todas las operaciones de larga duración deben ser divididas en dos estados: la solicitud de la operación y la ejecución de ésta. Específicamente si un comando solicita la ejecución de una operación, éste debiese retornar inmediatamente mientras que la ejecución queda en mano del planificador, el cual deberá señalizar a través de un evento, el éxito de la operación.
• Una ventaja secundaria de elegir este modelo de programación, es que propaga las abstracciones del hardware en el software. Tal como el hardware responde a cambios de estado en sus pines de entrada/salida, nuestras componentes responden a eventos y a los comandos en sus interfaces.
Ahora se tiene claro que las aplicaciones TinyOS son construidas por componentes. Una componente provee y usa interfaces. Estas interfaces son el único punto de acceso a la componente. Además una componente estará compuesta de un espacio de memoria y un conjunto de tareas.A continuación se detallan los cuatro elementos que conforman una componente:
2 Manejador de comandos.3 Manejador de eventos4 Un frame 10 de tamaño fijo y estáticamente asignado, en el cual se representa el
estado interno de la componente.5 Un bloque con tareas simples.
En la figura 2.4.1 se muestra el modelo gráfico de una componente, en la cual se observan los elementos mencionados anteriormente.
10 En este caso nos referimos a un “bloque” que proporciona el contexto en cual se ejecuta el programa y se almacenaran las variables.
24
Figura 2.4.1 : Modelo de componentes de TinyOS y su interacción.
Los comandos son peticiones hechas a componentes de capas inferiores. Estos generalmente son solicitados para ejecutar alguna operación. Existen dos posibles casos de uso de los comandos. El primero es para operaciones bifase, donde los comandos retornan inmediatamente, no generando bloqueos por la espera de la ejecución, es decir, una vez que realizan la petición, el planificador será el encargado de ejecutar lo solicitado, generando un evento que indique el fin de la operación. El otro es el caso de realizar una operación no bifase, donde ésta se realizará completamente, y por tanto no habrá evento retornado.
Los manejadores de eventos son invocados por eventos de componentes de capas inferiores, o por interrupciones cuando se está directamente conectado al hardware. Similar a los comandos, el frame será modificado y las tareas agregadas. Los eventos son capaces de interrumpir tareas, no así viceversa.
Las tareas se ejecutan hasta terminar y pueden ser sólo interrumpidas por eventos (podríamos decir que eventos tienen mayor prioridad). Las tareas son entregadas a un planificador (task scheduler) que en este caso está implementado con método FIFO. Debido a esta implementación, las tareas se ejecutan secuencialmente y no deben ser excesivamente largas. Alternativamente al planificador de tareas FIFO, puede ser reemplazado por planificadores basados en prioridades (priority-based) ó por planificadores basados en plazos (deadline-based), los cuales pueden ser implementados sobre TinyOS.
6.4.1 Tipos de Componentes.
En general las componentes se clasifican en una de estas categorías:
• Abstracciones de Hardware: Mapean el hardware físico en el modelo de componentes de TinyOS. Por ejemplo, en el módulo que se observa en la figura 2.4.1.1, la componente de radio RFM, es representativa de esta clase, ya que exporta comandos para manipular los pines de entrada-salida conectados al RFM y entrega eventos, informando a otras componentes acerca del bit de transmisión o recepción. Su frame contiene información acerca del estado actual de la componente (si se encuentra transmitiendo o recibiendo, la tasa de transferencia de bits, etc). El RFM detecta las interrupciones del hardware que se transforman en el bit de evento de RX o en el bit TX, dependiendo del modo de operación.
25
• Hardware Sintético: Los componentes de hardware sintéticos simulan el comportamiento del hardware avanzado. Un buen ejemplo de tal componente es el Radio Byte (véase el figura 2.4.1.1). Intercambia datos de entrada o salida del módulo RFM y señaliza cuando un byte ha sido completado. Las tareas internas realizan la codificación y decodificación de los datos. Conceptualmente, esta componente es una máquina de estado que podría ser directamente modelada en el hardware. Desde el punto de vista de los niveles superiores, esta componente provee una interfaz, funcionalmente muy similar a la componente de abstracción de hardware UART11: proporcionan los mismos comandos y señalan los mismos eventos, se ocupan de datos del mismo tamaño, e internamente realizan tareas similares (buscando un bit o un símbolo de inicio, realizando una codificación simple, etc.).
• Componente de alto nivel: Realizan el control, enrutamientos y toda la transferencia de datos. Un representante de esta clase es el módulo de mensajes (“messaging module”), presentado en la figura 2.4.1.1. Éste realiza la función de llenar el buffer de los paquetes antes de la transmisión y envía mensajes recibidos a su lugar apropiado. Además, las componentes que realizan cálculos sobre los datos o su agregación, entran en esta categoría.
Figura 2.4.1.1: Grafo de componentes para un sistema MultiHop.
Otra de las características de TinyOS es que el modelo de componentes permite la fácil migración a otro hardware, dada la abstracción de hardware que se logra con el modelo de manejo de eventos. Además, la migración es particularmente importante en las redes de sensores, ya que constantemente aparecen nuevas tecnologías, donde de seguro los diseñadores de sistemas querrán explorar el compromiso entre la integración a nivel físico, los requerimientos de energía, y el costo del sistema, requerimientos claves para la optimización.
6.4.2 Ejemplo de una componente.
Una componente típica que incluye un frame, eventos, comandos y tareas es mostrada en la figura 2.4.2.1.
11 Universal Asynchronous Receiver-Transmitter
26
Gráficamente, la componente se presenta como un conjunto de tareas, un bloque de estado (frame del componente), un conjunto de comandos (triángulos al revés), un conjunto de manejadores (triángulos), flechas para abajo para los comandos que utiliza, y flechas para arriba (prepicadas) para los comandos que señala.
En la figura 2.4.2.2 se muestra el código de esta componente. Como se puede observar el módulo principal se divide en dos partes: una que contiene las interfaces provistas y la otra que contiene las que utiliza. Es deber del programador hacer coincidir los formatos de eventos y comandos entre las distintas interfaces. De todas formas errores son verificados en tiempo de compilación.
Figura 2.4.2.1: Representación gráfica de la componente “Active Messages” (AM).
27
Figura 2.4.2.2. Archivo que describe la componente.
6.4.3 Implementación de una componente.
En TinyOS las componentes se unen en tiempo de compilación, considerando las especificaciones dadas en las componentes de configuración, es decir, se unen respetando las relaciones declaradas por las interfaces. Para facilitar la composición, cada interfaz está descrita en el inicio de cada archivo de componentes. Éste entrega una lista de los comandos que acepta y los eventos que manipula, como también el conjunto de eventos que señaliza y los comandos que usa. Podemos visualizar el modelo como una caja negra, donde solo se ven entradas y salidas. La completa descripción de estas interfaces superiores e inferiores, son usadas en el tiempo de compilación para generar automáticamente archivos de cabecera.
Todo esto es manejado por el compilador de lenguaje NesC. Un claro ejemplo en que el compilador debe verificar múltiples uniones, es que si un evento simple debe ser manejado por varias componentes, en tiempo de compilación el código será automáticamente generado para enviar el evento a tantos lugares como sea necesario.
6.4.4 Ejemplo de una aplicación completa.En la siguiente figura se muestra una vista simplificada de una aplicación implementada con TinyOS. Cada nodo representa una componente, y las flechas representan las uniones de las interfaces. Cada flecha es rotulada con el correspondiente nombre de la interfaz.
28
Figura 2.4.4.1: Aplicación Surge.
La aplicación se llama Surge, y tiene como función sensar periódicamente una variable, que en este caso es luminosidad, para luego ser enviada a través de la red inalámbrica. El objetivo de esta aplicación es entregar el valor medido a la base. Para eso cada nodo es capaz de identificar a un nodo padre, el cual le permitirá llegar a la estación base.
La aplicación solo debe incorporar las partes que necesita de TinyOS, como son el código de inicio de sistema (MAIN), el temer (Timer), un sensor (Photo), acceso a los leds (Leds), y enrutamiento de mensajes Multihop (Multihop). Además explícitamente se especifican las dependencias de ambiente en función de las interfaces. La aplicación requiere un timer (interfaz Timer), un sensor (interfaz ADC), leds (interfaz Leds) y finalmente comunicación (interfaz Send).
6.4.5 Modelo de Comunicación.
Una pregunta a resolver es ¿cómo se manejarán los mensajes en la red? Sin duda implementar socket en protocolo TCP/IP no es una buena idea, dado que se necesitaría excesiva memoria para almacenar los paquetes que van llegando además de los bloqueos que se generan mientras no se lea el mensaje. También es necesario evitar el excesivo tráfico sobre la red, por lo cual mensajes de recibo, secuencias de retransmisión, etc. son inaceptables.
La solución propuesta es trabajar con la metodología de “Active Messages”. Para su funcionamiento cada mensaje debe contener el nombre de un manejador de eventos. Para esto el que envía debe declarar un buffer en el frame, para así colocar el nombre del manejador, luego solicitar el envío y esperar que llegue la respuesta de realizado. El receptor entonces se encarga de invocar el correspondiente manejador de eventos.
De esta forma no se generan bloqueos o esperas en el receptor, el comportamiento es similar a que ocurriese un evento, y el almacenamiento es simple.
Para más detalles se adjunta en el anexo el material disponible.
29
6.5 Componentes contenidas en TinyOS.Muchos son los componentes a nivel de sistema que se incluyen en TinyOS. Además existe una colección de ejemplos de aplicaciones que demuestran los usos del sistema TinyOS. En la siguiente figura se muestran los componentes contenidos en la versión 1.0 de TinyOS.
Figura 2.5.1 Lista de componentes contenidos en TinyOS 1.0
30
7 Conclusiones.
TinyOS es un sistema operativo de código abierto, diseñado para las redes de sensores inalámbricas. Ofrece una arquitectura basada en componentes, que permite la innovación y rápida puesta en práctica de aplicaciones para este tipo de sistemas, mientras se reduce al mínimo el tamaño del código, según los requisitos inherentes en redes de sensores (memoria y energía, por ejemplo).
NesC y TinyOS se encuentran profundamente relacionados, cualquier avance o desarrollo de uno se verá reflejado en el otro. Es por esto que se hace necesario en su totalidad el buen manejo de este lenguaje.
Aunque hay algunas tareas que son críticas en tiempo, como son el manejo de la comunicación por radiofrecuencia o el obtener datos de algún sensor, TinyOS no se focaliza en dar garantías estrictas de Tiempo Real. Esto se refleja en que si frente a la llegada de algún evento, puede ocurrir que no sea posible la atención, éste y su información será perdido. Ahora bien, estas falencias son muy bien compensadas con el modelo de manejo de eventos.
TinyOS esta programado sobre un lenguaje estático, por lo cual no existen asignaciones de memoria de manera dinámica y los gráficos de llamados quedan totalmente definidos en el tiempo de compilación. Esto facilita enormemente el análisis de programas, y por ende la detección de errores.
La biblioteca de componentes de TinyOS incluye protocolos de red, servicios distribuidos, manejadores de sensores, y herramientas de adquisición de datos, que pueden ser ocupadas directamente, o manipuladas para responder a necesidades más específicas.
El modelo de manejo de eventos en la ejecución de TinyOS permite una administración al detalle de la energía, aún permitiendo mantener toda la flexibilidad que los sistemas de comunicación e interfaces físicas imponen.
Se debe tener cuidado con que se produzcan carreras de datos, esto debido a modificaciones concurrentes a un estado compartido. El compilador NesC es capaz de detectar posibles problemas de este tipo, mas es el usuario el que reparará el error.
TinyOS ha migrado a varias plataformas, corroborando de esta forma su estabilidad y su verificación de funcionamiento. Además se han desarrollado aplicaciones capaces de realizar simulaciones, herramienta que una amplia comunidad utiliza para desarrollar y probar varios algoritmos y protocolos.
Continuamente grupos numerosos de desarrolladores están contribuyendo código al sitio del sourceforge, y están trabajando activamente.
31
8 Referencias.
[1] “ nesC 1.1 Language Reference Manual”David Gay, Philip Levis, David Culler, Eric BrewerMay 2003http://nescc.sourceforge.net/papers/nesc-ref.pdf
[2] “The nesC Language”:A Holistic Approach to Networked Embedded SystemsDavid GayPhilip LevisRobert von Behren
[3] “System Architecture for Wireless Sensor Networks”Jason Lester HillB.S. (University of California, Berkeley) 1998M.S. (University of California, Berkeley) 2000
[4] Introduction to TinyOS.KD Kang.
32
Anexos.
8.1 AM Communication ParadigmA key piece of TinyOS is the communication model it supports. Instead of scaling a PC based communication models down, we believe that it is beneficial to tailor the communication system to meet the needs of these devices. To accomplish this, we have used the Active Messages communication model as primary building blocks for networking in TinyOS.
8.1.1 Active Messages Overview
Active Messages (AM) is a simple, extensible paradigm for message-based communication widely used in parallel and distributed computing systems [35]. Each Active Message contains the name of an application-level handler to be invoked on a target node upon arrival and a data payload to pass in as arguments. The handler function serves the dual purpose of extracting the message from the network and either integrating the data into the computation or sending a response message. The network is modeled as a pipeline with minimal buffering for messages. This eliminates many of the buffering difficulties faced by communication schemes that use blocking protocols or special send/receive buffers. To prevent network congestion and ensure adequate performance, message handlers must be able to execute quickly and asynchronously.
Although Active Messages has its roots in large parallel processing machines and computing clusters, the same basic concepts can be used to the meet the constraints of networked sensors. Specifically, the lightweight architecture of Active Messages can be leveraged to balance the need for an extensible communication framework while maintaining efficiency and agility. More importantly, the event based handler invocation model allows application developers to avoid busy-waiting for data to arrive and allows the system to overlap communication with other activities such as interacting with sensors or executing other applications. It is this event centric nature of Active Messages which makes it a natural fit for TinyOS.
8.1.2 Tiny Active Messages Implementation
In bringing Active Messages out of the high performance parallel computing world and down into this low power design regime, we have attempted to preserve the basic concepts of integrating communication with computation and matching communication primitives to hardware capabilities. The overlap of computational work with application level communication is essential. Execution contexts and stack space must never be wasted because applications are blocked, waiting for communication. The Active Messages communication model can be viewed as a distributed event model where networked nodes send each other events. While quite basic, we believe that all applications can be built on top of this primitive model.In order to make the Active Messages communication model a reality, certain primitives must be provided by the system. We believe that the three required primitives are: best effort message transmission with acknowledgements, addressing, and dispatch. More demanding applications may need to build more functionality on top of these primitives, but that is left for the applications developer to decide. By creating the minimal kernel of a communication system, all applications will be able to build on top of it. Additionally, it is likely that there will be a large variety of devices with different physical communication capabilities and needs. By building the communication kernel as separate components in the
33
TinyOS component model, developers can pick and choose which implementations of the basic components they need. This can take the form of selecting from a collection of delivery components that perform different levels of error correction and detection. However, by providing a consistent interface tocommunication primitives, application developers can easily transfer their applications to different hardware platforms.
Just as there will be various implementations of the core components for the developer to choose from, various other extensions will be available, such as reliable delivery. This is similar to the design of Horus [37], which attempted to have modular PC-based communication protocols where application developers could choose from a variety of building blocks including encryption, flow control, and packet fragmentation.It is extremely advantageous to be able to customize protocols when dealing with network sensors due to their extreme performance constraints and their large diversity of physical hardware.
34
Estudio y Análisis de los Requisitos de TinyOS.
35
Indice
1 Introducción. .............................................................................................................. 3 2 Desarrollo. ................................................................................................................. 4
2.1 Requerimientos de software para el servidor de desarrollo de aplicaciones con TinyOS. ............................................................................................................... 4 2.2 Disponibilidad de librerías de TinyOS, para las distintas plataformas. ............ 7 2.3 Requerimientos de memoria. ............................................................................. 9
3 Conclusiones ............................................................................................................ 11
36
9 Introducción.
El siguiente documento presenta los requerimientos que deben ser considerados para iniciarse en el manejo y uso de software para las redes de sensores inalámbricas, específicamente TinyOS.
Primero se comenzará describiendo algunos de los requerimientos en el servidor de desarrollo para aplicaciones de TinyOS, mencionando el proceso de instalación y configuración, y algunas observaciones respecto a la disponibilidad de librerías y componentes.
Luego se entregará un resumen con los principales microcontroladores ocupados, los transceiver y las principales librerías existentes para el desarrollo de aplicaciones.
Finalmente se discutirá la restricción de memoria que nos impone TinyOS, para la elección de un microcontrolador.
37
10 Desarrollo.
10.1 Requerimientos de software para el servidor de desarrollo de aplicaciones con TinyOS.
Aunque puede trabajar en otras plataformas, las plataformas compatibles son Linux (RedHat 9), Windows 2000, y Windows XP.
Para el funcionamiento en Windows se hace necesario la instalación de Cygwin12, un simulador de plataformas unix, siendo necesario tener básicos conocimientos acerca de este entorno. Además muchas de las herramientas disponibles se encuentran desarrolladas para plataformas Java, por tanto también es necesaria su instalación (http://java.sun.com).
La instalación en sistema Windows se realiza de forma transparente, puesto que existe un paquete ejecutable, el cual además realiza toda la configuración del sistema. En el caso de trabajar sobre linux, se hace necesario tener un mayor conocimiento, dado que es necesario instalar los paquetes (rpms) de forma manual. De la misma forma, si se quieren ocupar las herramientas existentes en Java, será necesario instalar el compilador y el entorno de ejecución (máquina virtual) de éste. Toda la información se puede encontrar en http://www.tinyos.net/download.html.
El lenguaje en el cual se deben programar las aplicaciones de TinyOS es NesC, un meta-lenguaje derivado de C, el cual implementa las abstracciones propias del diseño orientado a componentes. El manual de referencia para el aprendizaje de este lenguaje se encuentra disponible en la siguiente dirección: http://www.tinyos.net/tinyos-1.x/doc/nesc/ref.pdf. Además existen herramientas tanto para la generación de documentación de los programas (revisar http://www.tinyos.net/tinyos-1.x/doc/nesc/nesdoc.html ), como documentación para utilizar el compilador de NesC y su front-end13 (http://www.tinyos.net/tinyos-1.x/doc/nesc/ncc.html).
A continuación detallo cierta información relevante par a la instalación del entorno de desarrollo en Linux.
Existen problemas en la instalación de ciertas herramientas (aplicaciones java que necesiten interactuar con algún puerto de entrada/salida, ya sea serial o paralelo), ya que no existe la API Java Comunication, y es necesario obtener de la página de RXTX14 el archivo rxtx disponible en http://users.frii.com/jarvi/rxtx/download.html
Una vez solucionado esto, se pudo realizar una correcta instalación. Los paquetes ocupados fueron:
• avarice-2.0.20030825cvs-1.i386.rpm
• avr-binutils-2.13.2.1-1.i386.rpm
• avr-gcc-3.3tinyos-1.i386.rpm
• avr-insight-pre6.0cvs.tinyos-1.3.i386.rpm
12 http://www.cygwin.com13 Entorno gráfico de trabajo.14 http://www.rxtx.org
38
• avr-libc-20030512cvs-1.i386.rpm
• graphviz-1.10-1.i386.rpm
• nesc-1.1-1.i386.rpm
• tinyos-tools-1.1.0-1.i386.rpm
Los detalles de los pasos a seguir se encuentran en la siguiente página: http://www.tinyos.net/tinyos-1.x/doc/install.html#linux
Sobre el soporte disponible para distintas plataformas de nodos.
Al revisar el directorio en el cual se instala TinyOS, específicamente el directorio /tinyos-1.x/tos/platform se pueden encontrar las plataformas soportadas. La siguiente lista muestra el resultado obtenido:
• tinyos-1.x/tos/platform/avrmote
• tinyos-1.x/tos/platform/mica
• tinyos-1.x/tos/platform/mica128
• tinyos-1.x/tos/platform/mica2
• tinyos-1.x/tos/platform/mica2dot
• tinyos-1.x/tos/platform/pc
Este resultado se obtiene de la instalación de la versión estable de TinyOS 1.1.0. Para obtener un completo soporte de las nuevas plataformas existentes será necesario actualizar nuestro software a la última versión existente.
A continuación se detallan algunas observaciones sobre los cambios en las versiones de TinyOS.
• Al revisar los cambios significativos entre una versión y otra, detallados en la página http://www.tinyos.net/dist-1.1.0/snapshot-1.1.11Feb2005cvs/doc/changes-minor-releases.html, se puede encontrar que en la distribución de TinyOS 1.1.7 se inicia el soporte para la plataforma Telos, y su microcontrolador MSP430.
• Además es importante destacar que desde la versión 1.1.8 se incluye un nuevo sistema de reprogramación a través de la red para los nodos. La aplicación se llama Deluge y tal como se mencionaba permite programar una nueva imagen del programa a ejecturarse en el nodo de forma inalámbrica. Más información se encuentra disponible en http://www.cs.berkeley.edu/~jwhui/research/projects/deluge/
• Desde la versión de TinyOS 1.1.8 se hace necesario instalar una nueva versión del compilador de NesC, una versión que sea superior a la 1.1.1. El no realizar esto impide la actualización. Es importante mencionar que en esta versión del compilador se realizaron cambios que impiden poder trabajar con el mismo código escrito para aplicaciones creadas sobre versiones inferiores de TinyOS.Se puede bajar desde http://www.tinyos.net/dist-1.1.0/tinyos/ donde se debe
39
seleccionar el tipo de plataforma (linux o windows) para luego poder bajarlo.
• También se destaca que desde la versión 1.1.7, gran parte del desarrollo se ha basado en implementar y mejorar librerías para la plataforma Telos, lo que incluye mejoras con el uC MSP430.
Observaciones sobre el hardware necesario para la programación.
En lo que a hardware se refiere para la programación de los dispositivos, ya sean plataformas existentes (motes) o plataformas creadas, será necesario tener disponible al menos uno de los siguientes puertos del computador donde se trabaje: serial, paralelo, ethernet o usb. El puerto dependerá de la interfaz de comunicación que el módulo posea. Sólo de esta forma será posible la programación y emulación de aplicaciones.
40
10.2 Disponibilidad de librerías de TinyOS, para las distintas plataformas.
Muchas de las librerías disponibles en la distribución de TinyOS, pertenecen a la configuración e implementación de aplicaciones sobre plataformas desarrolladas ya sean por Universidades o por empresas.A continuación se muestran las plataformas disponibles con su respectivo microcontrolador y transceiver y librerías.
Plataforma
Microcontrolador
Fabricante microcontrolador
Transceiver
Fabricante Tranceiver
Librerías
weC AT90S2313 AVR TR1000 RFM No se incluyen en distribución de TinyOS
Rene AT90S2313 AVR TR1000 RFM No se incluyen en distribución de TinyOS
Atmega8 Atmega8 AVR TR1000 RFM Clock, CI 2 , ADC, EEPROM, UART,
avrmote Atmega8 AVR TR1000 RFM CI 2 , ADC, LRFM, UART, Watchdog, Internal Flash, avr_eeprom,
mica Atmega103 AVR TR1000 RFM ByteEeprom, eeprom, ChannelMon, MicaHighSpeedRadio, RadioTiming, Range, SlavePin,SPI, Watchdog.
mica128 Atmega128 AVR CC1000 Chipcon Clock, CI 2 , UART(extiende a mica)
mica2 Atmega128 AVR CC1000 Chipcon ADC, CC1000, UART, MacBAckoff, SPI, Power Management, MacControl, SysTime, Voltage, Flash.
Mica2dot Atmega128 AVR CC1000 Chipcon Flash, UART, CI 2
, Leds, Voltage, micaz Atmega128 AVR CC2420 Chipcon ADC, CC2420,
Power Management, SPI, Timers, PhotoTemp, Voltage, AM.
Rene2 Atmega163 AVR TR1000 RFM RF, Clock.telos MSP430F149
HCS08MSP430 Texas Instrumentos
HCS08
CC2420 Chipcon ADC, CI 2 ,SPI,UART, Power Management, Internal Flash,
41
Motorola Internal Voltage, Internal Temp, Internal Clock, CC2420
telosb MSP430F1611 Texas Instruments.
CC2420 Chipcon DS2411, LSTM25P (Serial ID), CI 2
(incorpora cosas de telos)
TCM120 PIC18F452 Microchip TCM120 EnOcean ADC, AM, Clock, PowerManagement, UART, OceanRadioControl
Tabla 2.2.1 Plataformas con su respectivo Microcontrolador, transceiver y librerías.
TinyOS se encarga de proveer componentes que permiten que estos microcontroladores se relacionen con sensores, transceivers y otros dispositivos de entrada salida; además permitan mapear las funcionalidades del microcontrolador al software, logrando una abstracción de la programación en sus niveles mas altos, lo cual facilita la exportabilidad del código a otras plataformas, en caso de ser necesario. Con todo esto las tareas para lo cual la aplicación ha sido desarrollada podrán ser realizadas.
Entre las principales componentes encontramos: conversores análogo-digital (ADC), comunicación CI 2 , comunicación serial (Standard e inalámbrica), timers, asignación de memorias.
Toda la información de los módulos y librerías desarrolladas para las distintas plataformas de nodos y sensores, se encuentra reunida en las distribuciones del sistema TinyOS, como también en la página del servidor CVS del proyecto. Para la obtención del listado completo, recomendamos dirigirse a http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-1.x/ específicamente en el directorio tos, donde se podrán ver todos los códigos necesarios para el trabajo.
42
10.3 Requerimientos de memoria.
Para tomar una decisión acerca del microcontrolador a ocupar, es necesario tener claro los requerimientos de memoria tanto de programa como de datos.En la tabla 2.3.1 se muestran los requerimientos de tres aplicaciones Surge, Maté, TiniDB.
Tabla 2.3.1. Aplicaciones y tamaño del código.
En la tabla 2.3.2 se muestra en detalle el tamaño de código ocupado por la aplicación Surge, presente en la distribución de tinyos. Como se puede observar el tamaño de código de programa es de aproximadamente 17K, mientras que la memoria de datos es de 1K app.
43
Tabla 2.3.2 Componentes, tamaño de código y datos en memoria.
Es importante mencionar que solo las componentes “TinyOS”, “C runtime” y “RealMain” son requeridas para toda aplicación, mientras que las otras componentes, sólo son incluidas cuando son necesarias.
En caso de optimizar el código (inlined) se puede ahorrar aproximadamente 2K de memoria de programa, lo cual ademas trae ahorro de procesamiento en CPU, aproximadamente un 15%, tal como se mostraba en la figura 2.3.1.
44
11 Conclusiones
Gran parte del desarrollo de aplicaciones en TinyOS, ha sido hecho para plataformas desarrolladas por empresas o universidades (motes), por lo cual muchas de las librerías disponibles se encuentran atadas a las componentes de hardware que estos sistemas poseen. Esta atadura no es estricta, ya que dado el modelo de componentes, y las abstracciones de hardware que se implementan, la migración a otros sistemas se puede realizar con un mínimo de esfuerzo.
A modo de resumen, podemos mencionar que en lo que a procesadores se refiere, la familia AVR de la empresa Atmel, es sin duda la más soportada, producto de años de trabajo sobre este tipo de arquitectura. Aparece luego la familia MSP430 de la empresa Texas Instruments, la cual presenta un procesador con increíble capacidad para el manejo de energía, restricción fundamental en este tipo de sistema. También podemos mencionar los avances realizados en la familia PIC18F y en el microcontrolador motorota HCS08, la cual también ha sido soportada.
En lo que a requerimientos para la ejecución de TinyOS sobre alguna arquitectura, resulta importante destacar la memoria por parte de la aplicación base, siendo aproximadamente del orden de 4Kb, magnitud bajísima si consideramos que hoy en día la mayoría de los procesadores fácilmente pueden traer 60 Kb de memoria para programa (Caso de MSP430, por ejemplo).
45
Referencias.
[1] “System Architecture Directions for Networked Sensors”Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer PisterDepartment of Electrical Engineering and Computer SciencesUniversity of California, BerkeleyBerkeley, CA
[2] MPR/ MIB User’s ManualCrossbow.Rev. A, August 2004
[3 MTS/MDA Sensor Board User’s ManualWireless Sensor NetworksCrossbow.
[4] CVS Sourceforge.
46
Informes Segunda Etapa.
47
Indice
1 Lenguaje NesC ........................................................................................................... 3 1.1 Introducción. ....................................................................................................... 3 1.2 Desarrollo. ........................................................................................................... 4
1.2.1 El ambiente de programación ..................................................................... 4 1.2.2 Archivos en NesC ......................................................................................... 4 1.2.3 Conociendo el lenguaje a partir de aplicaciones simples. ........................ 6 1.2.4 Optimización. ............................................................................................. 12
1.3 Conclusiones. .................................................................................................... 13 2 Abstracción de Hardware. ...................................................................................... 14
2.1 Introducción ...................................................................................................... 14 2.2 Desarrollo ......................................................................................................... 15
2.2.1 Arquitectura. .............................................................................................. 15 2.2.2 Aplicaciones para un módulo de Hardware específico. ........................... 18
2.3 Conclusiones ..................................................................................................... 25 3 Descripción del Entorno de Desarrollo. .................................................................. 26
3.1 Introducción ...................................................................................................... 26 3.2 Desarrollo ......................................................................................................... 27
3.2.1 Instalación de TinyOS y el sistema de desarrollo. .................................... 27 3.2.2 Compilando aplicaciones TinyOS .............................................................. 29 3.2.3 Descripción de las herramientas disponibles ........................................... 30 3.2.4 Descripción de pasos a seguir para la configuración y uso de los Motes CrossBow y el Gateway MIB600 en las herramientas MoteView 1.0, Serial Forwarder y Surge View. .................................................................................... 30
3.3 Conclusiones ..................................................................................................... 33 4 Referencias .............................................................................................................. 34
48
12 Lenguaje NesC
12.1 Introducción.
En el siguiente trabajo se profundizaran los conocimientos adquiridos en el lenguaje de programación NesC.
El análisis se iniciará presentando primero el ambiente de trabajo, para luego ya entrar de lleno en las características del lenguaje, comenzando por discutir los tipos de archivos y las convenciones de nombres que existen para poder realizar desarrollos que sean compatibles en esquema con los oficiales.
Luego se explicarán los conceptos básicos de la programación en nesC, apoyándose principalmente en dos aplicaciones ejemplos: Blink y Surge.
Finalmente se analizarán algunos los problemas de “carreras de datos” y se profundizará en la optimización que nesC puede lograr en la compilación.
49
12.2 Desarrollo.
12.2.1El ambiente de programación
Lo primero es bajar desde http://www.tinyos.net/download.html los archivos de instalación y seguir las instrucciones que se siguen en http://www.tinyos.net/tinyos-1.x/doc/install.html.
TinyOS dispone de una IDE, la cual se puede obtener desde http://csb109pc1.ucd.ie:8080. Ésta IDE se encuentra escrita en Java, por lo que se hace necesario contar con este entorno para su posterior ejecución. La herramienta, pese a su sencillez, facilita el desarrollo ya que destaca sintaxis reconocidas como instrucciones, tiene comunicación directa con el bash de cygwin lo que facilita la compilación, tiene un wizard para la creación de proyectos, entre otras características.
12.2.2Archivos en NesC
Los archivos de NesC se clasifican en tres tipos: Interfaces, módulos, configuraciones. En la siguiente tabla se muestra un ejemplo para cada uno de estos archivos, y una breve descripción de su función.
Tipo Descripción Ejemplo
Interfaz Declara los servicios que se proveen y los servicios que se usarán. Se encuentran en el directorio /tos/interface.
StdControl.nc
Modulo Provee el código de la aplicación, implementando una o más interfaces.
BlinkM.nc
Configuración
Acá se declara como se unirán las distintas componentes, realiza control de flujo.
Blink.nc
Tabla 1.2.2.1 Tipos de Archivos, descripción y un ejemplo.
También es importante mencionar que existe una convención de nombres para los archivos a ser creados.En la tabla 1.2.2.3 se muestran el procedimiento a seguir.
Identificador Reglas para el nombramiento Ejemplo
Interfaces Verbos o SustantivosCasos mezclados: VerboSustantivo
ADCSendMsg
Componentes Sustantivos, que terminan con C : Cuando son componentes que proveen interfacesM: Módulos, implementan el código de la aplicación
TimerCTimerM
Archivos Todos los archivos llevan el sufijo .nc TimerC.nc TimerM.nc
Comandos, eventos y Tareas
Verbos, caso de ser mezclas se debe VerboSustantivoPar Comando/Evento se debe agregar el sufijo Done o Complete
sendMsgputDone
50
Variables Sustantivos, en caso de ser mezcla debe ser verboSustantivo
bool state
Constantes Todo con mayúscula, y con underscore para las separaciones entre palabras
TOS_BCAST_ADDR
Tabla 1.2.2.2 Convenciones de nombres
51
12.2.3Conociendo el lenguaje a partir de aplicaciones simples.
12.2.3.1 Generalidades del lenguaje: Blink.Blink es un programa muy simple, cuya única función es hacer parpadear un led, el cual se encuentra disponible en las plataformas de desarrollo (mica, micaz, etc). Pese a su simplicidad, abarca muchos de los principales tópicos a entender en la programación con NesC.
Archivos necesarios:
• BlinkM.nc: Define el módulo blink e implementa las interfaces.
• Blink.nc: Define la componente, es el archivo de configuración top-level.Se encargará de unir el módulo BlinkM a otras componentes que la aplicación blink necesite.
• SingleTimer.nc: Es una componente que se extiende de TimerC, y que será usada por blink.
A continuación se muestra Blink.nc
configuration Blink {}implementation {components Main, BlinkM, SingleTimer, LedsC;
Main.StdControl -> BlinkM.StdControl;Main.StdControl -> SingleTimer.StdControl;BlinkM.Timer -> SingleTimer.Timer;BlinkM.Leds -> LedsC;}
Código 1.2.3.1.1: Blink.nc
Se puede observar que las componentes en uso son: Main, BlinkM, SingleTimer, LedsC.
NesC usa flechas para definir las relaciones entre las interfaces. Para entender esto, se debe pensar que la flecha “->” significa “ligado a” (traducción de “bind to”). Así por ejemplo tenemos que la interfaz ubicada a la izquierda queda ligada a una implementación especificada a la derecha. En otras palabras, la componente que “usa” una interfaz está a la izquierda, y la componente que “provee” una interfaz está a la derecha.
Main indica cual será la componente que se ejecutará primero en cualquier aplicación de TinyOS. En este caso corresponde a StdControl, la cual es una componente que inicializa y ejecuta la aplicación de TinyOS. Cada componente debe proporcionar ésta interfaz. Dentro del directorio de trabajo se encuentra definida en tos/interfaces/StdControl.nc.
A continuación se muestra esta interfaz:
52
interface StdControl { command result_t init(); command result_t start(); command result_t stop();}
Código 1.2.3.1.2: StdControl.nc
Resulta importante aclarar la función que realizan los comandos init, start y stop.
• init() : ésta puede ser llamadas múltiples veces, pero nuca será llamada después de un start() o un stop().
• Es importante mencionar que si se llama a uno de estos comandos en una componente, se debe también hacer el llamado en las subcomponentes.
Continuando con el análisis del programa:
Main.StdControl -> BlinkM.StdControl;Main.StdControl -> SingleTimer.StdControl;
Estas dos líneas unen la interfaz StdControl a las interfaces StdControl de BlinkM y SingleTimer.De ésta forma se cumple por ejemplo que SingleTimer.StdControl.init() y BlinkM.StdControl.init() sean llamadas por Main.StdControl.init(). De la misma forma se aplica esta regla para los comandos start() y stop().
Para continuar este análisis se hace necesario el estudio del módulo BlinkM. A continuación se muestra de forma resumida el código de éste.
module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; }}// Continued below...
Código 1.2.3.1.3: BlinkM.nc
Se puede notar que este módulo provee la interfaz StdControl y usa las interfaces Timer y Leds.El archivo Timer es el siguiente:
interface Timer { command result_t start(char type, uint32_t interval); command result_t stop(); event result_t fired();}
Código 1.2.3.1.4: Timer.nc
En este caso start() especifica el tipo de timer y el intervalo en el cual el timer expira. Es importante mencionar que la unidad del intervalo es en milisegundos, mientras que tipos válidos serían TIMER_REPEAT y TIMER_ONE_SHOT.
53
El evento fired() es señalizado cuando el intervalo especificado ha finalizado. Acá queda de manifiesto la características bi-direccional de las interfaces, ya que como se observa tenemos comandos y eventos dentro de esta interfaz.
• Interfaz proveedor debe implementar comandos.
• Comandos son llamados por el usuario.
• La interfaz usada debe implementar eventos.
• Los eventos son llamados por el proveedor pero manejados por el que las usa.
Ahora que se tienen definidas las interfaces como las relaciones que existen entre ellas, se hace necesario escribir la implementación.
implementation {
command result_t StdControl.init() { call Leds.init(); return SUCCESS; }
command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000) ; }
command result_t StdControl.stop() { return call Timer.stop(); }
event result_t Timer.fired() { call Leds.redToggle(); return SUCCESS; }}
Código 1.2.3.1.5: Implementación de Blink.
La especificación de componentes es implementada con un esquema similar a la programación de códigos C. Es en este código donde queda definido el funcionamiento de nuestra aplicación.
Como se puede observar cuando el evento Timer.fired() es capturado, el Leds.redToggle() hace parpadear el led rojo que se encuentra en la plataforma con la cual se trabaja.
54
12.2.3.2Interfaces Parametrizadas.
Observemos el siguiente código de programa:
¿Qué significa la línea?: SenseM.Timer -> TimerC.Timer[unique("Timer")];
Una interfaz parametrizada permite a una componente proveer múltiples instancias de esta interfaz la cual se encuentra caracterizada por un valor asignado ya sea en tiempo de ejecución o en tiempo de compilación.
Es necesario primero comentar que una componente es capaz de proveer múltiples instancias de una interfaz y asignarles diferentes nombres, por ejemplo:
provides { interface StdControl as fooControl; interface StdControl as barControl; }
Es así como las interfaces parametrizadas son exactamente una generalización de esta misma idea. Podemos además observar que la componente TimerC declara:
provides interface Timer[uint8_t id];
En otras palabras , prove 256 diferentes instancias de la interfaz Timer.
Es este caso, se quiere que TinyOS pueda manejar múltiples timers de forma independiente y personalizadamente.
Cuando se dice TimerC.Timer[algunval], se está especificando que BlinkM.Timer debería ser unido a una instancia de la interfaz Timer especificada por el valor (algunval) encerrado entre paréntesis cuadrado. Este puede ser cualquier número positivo de 8 bits. Para evitar conflictos de uso de valores es que existe la posibilidad de usar la función contante unique(), la cual genera en tiempo de compilación un identificador único, en este caso se ocupa así: unique("Timer")
Éste generará un identificado único asociado a Timer, de manera tal de que cada vez que se coloque la misma sentencia, se creará otro identificador que garantiza no tener conflictos.
55
configuration SingleTimer { provides interface Timer; provides interface StdControl;}implementation { components TimerC; Timer = TimerC.Timer[unique("Timer")]; StdControl = TimerC;}
12.2.3.3Carreras de datos y Concurrencia en NesC: SurgeM
Las carreras de datos ocurren debido a modificaciones que se realizan de manera concurrente a estados compartidos dentro de la ejecución del programa. NesC es capaz de detectar este tipo de problemas.
Ocurre que en TinyOS el código se ejecuta de dos formas:
• Asincrónicamente (en respuesta a interrupciones)
• Sincrónicamente (para la ejecución de tareas).
Las carreras de datos se presentarán principalmente en estas dos situaciones:
• Cualquier modificación a un estado compartido desde un código asincrónico es una condición potencial de carrera de datos.
• Cualquier modificación de un estado compartido desde un código sincrónico, que es también modificado desde un código asincrónico es una condición potencial de carrera de datos.
La solución para no tener nunca este problema es que cualquier modificación a un estado compartido solo es con un código sincrónico o con una sección atómica.
Una sección atómica puede entenderse como la desactivación de las interrupciones durante unos pocos ciclos de ejecución. Es necesario recordar que esto considera la ejecución bi-fase, ya que el hecho de definir una tarea como atómica tiene relación a que cuando entra a contexto de ejecución esta se considera como un entero.
En el caso de que se conozca que no hay problema de carreras de datos, pero el compilador si encuentra alguno, se puede definir como “norace”.
La concurrencia en NesC está profundamente relacionada con los códigos asincrónicos, ya que son las interrupciones las que generan múltiples solicitudes de ser atendidas. Para manejarla, NesC provee dos herramientas: secciones atómicas y tareas. En el código mostrado a continuación Timer.fired y ADC.dataReady son códigos asincrónicos.
El evento Timer.fired es señalizado periódicamente, así ADC.getData es llamado para obtener un nuevo dato. Como busy es accedido por un código asincrónico su uso es protegido por una declaración de atómica que realiza un “test-and-set” de la variable. Una vez que el valor haya sido obtenido, el ADC.dataReady es señalizado. El envío del mensaje no es una operación de tiempo crítico, por lo cual se procede a “postear” una tarea: sendData. Postear implica que la operación se realizará cuando el procesador este desocupado.
Se deben ocupar con sumo cuidado las declaraciones atómicas, ya que al deshabilitar las interrupciones el sistema se vuelve menos seguro y se pueden perder eventos.
module SurgeM{...}
implementation{ bool busy;
56
norace uint16_t sensorReading; event result_t Timer.fired(){ bool localBusy; atomic { localBusy = busy; busy = true; } if(!localBusy) call ADC.getData(); return SUCCESS; }
task void sendData(){ adcPacket.data = sensorReading; call Send.send(&adcPacket, sizeof adcPacket.data); return SUCCESS; } event result_t ADC.dataReady(uint16_t data){ sensorReading = data; post sendData(); return SUCCESS; }...} //implementation
57
12.2.4Optimización.Como con la detección de carreras de datos, nesC explota las restricciones del modelo de componentes para realizar un análisis estático y optimización. El compilador permite optimizaciones extensas entre componentes relacionadas, lo que incluye mejorar la propagación de constantes, y la eliminación de subexpresiones comunes. Las optimizaciones reducen eficientemente el uso de la memoria de programa, como también la sobrecarga en la ejecución de las aplicaciones.
Las dos principales fuentes de reducción de códigos son:
• Eliminación de “códigos muertos”, es decir recortar todas las definiciones redundantes, o códigos que no realizen ninguna función, lo que generalmente reduce cerca de un 9% del total.
• “In-lining” también reduce el código cerca de un 16%. “In-lining” sólo crea un 1% de mejora en la utilización de la CPU. Códigos intensivos en CPU no estan dominados por llamados de funciones.
Inlining corresponde a una optimización que realiza el compilador, reemplazando todo aquel código que se especifico como inlining en el lugar donde se realiza el llamado.
En la siguiente figura podemos observar el efecto de “inlining” sobre la memoria ocupado por el programa y su desempeño.
Figura 1.2.4.1 Comparación de aplicaciones con optimización y sin optimización
58
12.3 Conclusiones.
NesC es un lenguaje de programación que presenta grandes ventajas para el desarrollo de aplicaciones en sistemas embebidos, específicamente en las redes de sensores inalámbricas. Éste presenta valiosas herramientas para una correcta programación de aplicaciones, primero abstrayendo las características de modularidad que presentan las redes de sensores, facilitando el entendimiento y la implementación de programas para estos sistemas. Además nos entrega herramientas que facilitan el desarrollo, como es el uso de interfaces parametrizadas, como también la verificación y detección de posibles problemas en tiempo de ejecución como son las carreras de datos.
NesC es un lenguaje que está en constante desarrollo y cuyo principal objetivo es facilitar la implementación de aplicaciones para sistemas de redes de sensores, lo cual nos garantiza un constante crecimiento en robustez y adaptabilidad a las nuevas necesidades.
59
13 Abstracción de Hardware.
13.1 Introducción
En el siguiente trabajo se presentaran las principales características del modelo de abstracción de hardware que se ha implementado en el sistema operativo TinyOS.
El objetivo principal es poder entender como TinyOS se logra relacionar con los distintos módulos de hardware, ya sean entradas/salidas, buses de datos y mecanismos disponibles para la administración de energía.
Este informe se basa principalmente en estudios realizados con las plataformas de redes de sensores inalámbricas Telos, la cual incorpora un microcontrolador MSP430. También se irá haciendo mención a algunas de las características de las plataformas anteriores, basadas principalmente en microcontroladores Atmel.
60
13.2 Desarrollo
Una de las principales metas en la programación de sistemas operativos es lograr portabilidad a distintas plataformas. Para poder lograr esto se hace necesario tener un esquema que sea capaz de abstraerse del hardware, misión para nada fácil.
Específicamente las redes de sensores imponen una gran eficiencia en el uso de recursos (ahorro de energía es esencial), por lo que la modularidad que se quiere alcanzar a través de este módelo no debe comprometer estas variables.
A continuación se presenta el modelo propuesto para el desarrollo de aplicaciones a partir de la versión de tinyOS 1.1.7 (específicamente para plataformas con MSP430), y que será base para la versión 2.0 de este sistema operativo
13.2.1Arquitectura.
El presente estudio se basa en la siguiente estructura de organización.
Figura 2.2.1.1 Arquitectura de la Abstracción de Hardware
La arquitectura presenta tres distintas capas de componentes. Cada capa posee responsabilidades y depende de las interfaces que proveen las capas inferiores. El objetivo principal de la inserción de estas capas, es permitir que el programador de aplicaciones logre una mayor independencia del hardware, teniendo en conocimiento las definiciones de las capas inferiores.
A continuación se procede a explicar cada una de las capas:
13.2.1.1Hardware Presentation Layer (HPL)
Esta capa se ubica exactamente por sobre el hardware. Su principal tarea es presentar las capacidades del hardware usando los conceptos nativos del sistema operativo. Ellos acceden al hardware de manera usual, ya sea a través de
61
solicitudes de memoria o interactuando con los puertos de entrada/salida, mientras que inversamente el hardware solicita los servicios a través de la señalización de interrupciones. Es por medio de este canal, que el HPL esconde las dificultades y diferencias de hardware, exportándolas a una interfaz más fácil de usar (específicamente a través de llamado de funciones) para el resto del sistema.
Está claro que las interfaces quedan completamente definidas por las capacidades del módulo de hardware, pero dado que es necesario lograr un esquema común, y una óptima integración con el resto de la arquitectura es que cada componente HPL debe tener:
• Inicialización, partida y detención (Initialization, starting y stopping)
• Comandos “get” y “set” para los registros controlan las operaciones de hardware.
• Habilitar/deshabilitar las interrupciones.
• Rutinas de Servicios de Interrupciones
Es importante mencionar que las rutinas de servicios de interrupciones son sólo las operaciones más críticas en tiempo, y se delega el resto del proceso a componentes de niveles superiores que poseen un conocimiento más extenso acerca del estado del sistema.
La estructura de HPL facilita la manipulación del hardware. En lugar de usar macros y nombres de registros cuyas definiciones se encuentran definidas en los archivos de cabeceras (*.h) de las librerías del compilador, el programador puede ahora acceder al hardware a través de una interfaz mucho mas amistosa.
Un ejemplo podría ser lo que ocurre en muchas de las plataformas existentes con el módulo USART, ya que generalmente los microcontroladores poseen dos. Ellas son funcionalmente idénticas, pero son accedidas a través de registros diferentes y genera diferentes vectores de interrupciones. Acá entonces es cuando el HPL actúa, escondiendo estas diferencias bajo una interfaz consistente, haciendo la programación mucho más abstracta. Al programador solo le bastaría un nuevo recableado (rewiring) sin necesidad de modificar el código de la implementación.
13.2.1.2Hardware Adaptation Layer (HAL)
Se puede decir que esta capa representa la parte esencial de este tipo de arquitectura. Ella usa las interfaces provistas por las componentes de la HPL para construir las abstracciones que serán utilizadas por el programador, y que esconden la complejidad natural asociado con el uso de recursos de hardware. Es importante mencionar que debido a los requerimientos de las redes de sensores, es que en esta capa las abstracciones deben ser adaptadas a un dispositivo en concreto. Esta capa presenta un compromiso entre proveer de la mejor forma las abstracciones, sin comprometer eficiencia por conveniencia.
Exporta modelos específicos por campos, en lugar de abstracciones sobrecargadas y limitadas. Es decir, por ejemplo en vez de trabajar con una interfaz timer, crear una interfaz alarma, en la cual se dejan atrás ciertas restricciones impuestas por hardware y se construyen aplicaciones con una base en común. En la sección 2.2 se explica mejor este caso.
13.2.1.3Hardware Interface Layer (HIL)
62
Esta última capa se encarga de convertir las abstracciones HAL de un hardware específico, en interfaces independientes del hardware. Estas interfaces proveen abstracciones independientes de la plataforma, lo que simplifica el desarrollo de aplicaciones ya que se esconden las diferencias de hardware.
Esta capa no existía dentro del contexto de desarrollo de aplicaciones en las versiones inferiores a tinyos 1.1.7. Esta capa es la que entrega la mayor flexibilidad, al permitir desarrollo de aplicaciones olvidándose del tipo de hardware que se esta ocupando. Existe un número de versión para cada iteración de una interfaz HIL, lo cual permite aún más incrementar los niveles de funcionalidad. Ya para finalizar se hace necesario mencionar que para un desempeño óptimo, la aplicación para una plataforma específica podría evitar las componentes del tipo HIL y directamente acceder a las interfaces HAL, ya que así se provee un acceso completo a los módulos de hardware. La decisión debe tomarse dependiendo del tipo desarrollo y el fin de éste.
¿Cual es la utilidad de ocupar esta capa?
63
13.2.2Aplicaciones para un módulo de Hardware específico.
Tal como ya se mencionaba en la introducción, este nuevo esquema nace con la implementación de la plataforma con el microcontrolador MSP430 (telos). Para las versiones anteriores el esquema solo constaba de dos niveles, muy similares a las dos capas inferiores de este nuevo modelo, pero usa una filosofía diferente en la separación de funcionalidades para las abstracciones superiores.
A continuación mostramos un diagrama funcional del microcontrolador MSP430F149.
.
Figura 2.2.2.1 Diagrama Funcional del MSP430
Acá se observan las componentes del MSP430, que se encontraban incorporadas en la versión de TinyOS 1.1.7.
Figura 2.2.2.2 Componentes de la abstracción de hardware del MSP430
A continuación se estudiaran y analizaran los principales módulos que componen una típica plataforma de redes de sensores inalámbricas.
64
RISC CPU16-Bit
ClockSystem
60 KBFlash 12-Bit ADC USART0 USART1
TimerA TimerBI/O port 1/2InterruptCapability
2 KBRAM
I/O port 3-6
MAB
MDBBu
s C
on
v16-Bit
16-Bit 8-Bit
4-Bit
Main
HPLUARTC
ADCC
HPLUSART0M
HPLUSART1M
HPLUARTMHPLSpiM
ADCM
MSP430InterruptC
MainM
HPLInitC
BusArbitrationC
MSP430ADC12C
MSP430ADC12M
RefVoltC
HPLADC12M
RefVoltM
MSP430InterruptM
BusArbitrationM
HPLInitM
MSP430ClockC
MSP430ClockM
TimerCTimer
M
MSP430TimerCMSP430Timer
M
65
13.2.2.1Proccesing Unit.
El microcontrolador es la parte principal de una plataforma de WSNs. Abstraer las diferencias entre los variados MCU15 es el primer paso hacia un sistema operativo más exportable. Mucho de esto se encuentra incluido en que nesC es un lenguaje de programación con una suite de compilación similar (gcc). Por ejemplo las librerías estándares distribuidas con el compilador crea los códigos necesarios para el funcionamiento del microcontrolador, ya sea definir las variables globales, el puntero del stack y la tabla de vectores de interrupciones.
TinyOS se encarga de proveer distintos mecanismos para acceder a las funcionalidades del microcontrolador. Por ejemplo para los pines externos de la MCU, tinyOS provee la capacidad de cambiar su dirección y su función (I/O de propósito general o alguna función específica, por ejemplo ADC). Todas las macros se encuentran definidas en los archivos hardware.h de cada plataforma.
También TinyOS se encarga de negociar con las distintas formas de acceder a los registros, usando los archivos de cabeceras (.h) disponibles en las librerías standard.
Es importante mencionar que no se pretende aplicar el modelo de tres capas a la MCU, ya que las características del compilador más los archivos hardware.h, son suficientemente eficientes.
13.2.2.2Power Management
La administración de la energía es sin duda una tarea crítica para garantizar una larga vida de los dispositivos de redes de sensores. Cada microcontrolador tiene un perfil diferente de administración de la energía. Este perfil se compone de los distintos niveles de bajo consumo, como también del tiempo que demora en despertar, es decir, el tiempo que demora en pasar del estado dormido (sleep) a activo. La relevancia de estos estados, es el ahorro de energía producto de los distintos niveles de corriente consumida para cada modo.
En el caso de las plataformas basadas en los microcontroladores Atmel, donde el tiempo que demora en despertar es de unos pocos milisegundos, se usa una componente HAL que evalúa cuando el próximo evento del timer ocurrirá, y sólo coloca al microcontrolador en modo sleep si el tiempo es mayor que lo que demoraría en despertar. En cambio el MSP430 demora alrededor de 6 microsegundos, por lo que apenas la MCU no esta procesando, se procede a cambiar a bajo consumo de energía, específicamente al modo sleep.
En ambos casos, antes de pasar al modo sleep, una componente HAL verifica si algún módulo de hardware necesita que la MCU este activa. Adicionalmente todos los servicios, incluyendo las componentes HAL y HPL tienen funciones de inicialización, start y stop. Cuando un servicio no esta ocupando algún módulo de hardware, este podría llamar la función stop de las componentes HPL o HAL. Al hacer esto se desactivan los módulos para el ahorro de energía, pero también ser remueven las dependencias sobre los módulos de hardware para entrar al modo sleep.
Estas ventajas se logran principalmente gracias al diseño de hardware que poseen los microcontroladores, donde la gran mayoría de los módulos se encuentran
15 Micro Controller Unit
66
conectados a la MCU. En la medida que se agreguen más dispositivos externos, se harán necesarios nuevos mecanismos para el manejo de la energía.
67
13.2.2.3Clocks y Timers.
El principal problema que se encuentra acá es que diferentes microcontroladores pueden proveer diferentes números de timers, de registros de comparación y captura, diferentes modos de contar, distintos factores de escalas y diferencias en la resolución. A continuación se muestra lo que ocurre para MSP430 y para Atmel.
MSP430 Dos timers diferentes de 16-bits.1 Uno con tres registros de comparación/captura y el otro
con ocho.2 Cada uno puede poseer cuatro factores de escalamiento.3 Cada registro de comparación permite distintas
interrupciones dependiendo del estado final del contador.Atmel Atmega
Dos timers de 8-bit, cada uno con preescalable de 10 bits y un registro comparador. Dos timers de 16-bit cada uno con tres registros de comparación y limitado en preescalar.
El módulo ocupado para las aplicaciones de Atmel era TimerM. Este módulo no pudo ser adaptado al microcontrolador MSP430, por lo que se diseñó una nueva interfaz que se llamó Alarm, que accede al tiempo actual y permite setear alarmas en el futuro relativo a tiempo atrás. Cada interfaz debe describir la resolución de la alarma que provee, tal como TMilli, T32khz, TMicro .De esta forma cada plataforma exporta un número de interfaces, que corresponderán al numero máximo de alarmas soportadas por la plataforma.
Sin la capa de presentación, la adaptación del hardware estaría atada a muchos recursos y especificaciones de la MCU. Los flags de overflow, el tiempo actual dado por el hardware, y las configuraciones de los registros del sistema son accesibles desde la HPL. El HAL usa estas primitivas para construir las interfaces de Alarm accesibles en el HAL.
En la capa HIL se provee la independencia de la plataforma, además resulta importante mencionar que todos los timers, por ende las alarmas, serán de 32 bits. En el caso de que los timers sean menores que 32 bits (definido por el hardware), en la capa HAL se emulan como si fueran de 32. De esta forma la capa HIL expone un reloj nativo de 32 bits para las aplicaciones y servicios de sincronización.
13.2.2.4Conversor Análogo-Digital.
Tal como el caso de los timers, el mayor desafío en definir la abstracción de hardware para un conversor análogo/digital es negociar con las capacidades y variabilidad del hardware. Principalmente los módulos ADC pueden diferir en su resolución, el número de canales a ser muestreados y convertidos, y el soporte de modos de conversión especiales.
Si se compara el modulo conversor de MSP430 con el de Atmel ATmega, notaríamos grandes diferencias.
El módulo ADCM en TinyOS provee comandos para disparar una conversión simple y para iniciar una conversión que se repite constantemente en un canal. El problema es que fue diseñada para el procesador Atmel, el cual no puede modificar el tiempo en que se mantiene la muestra (sample-and-hold) o una referencia de voltaje individual para canales diferentes. También no soporta modos de conversión en secuencia. Para solucionar esto, es que se diseño una nueva abstracción del ADC, en el que se incorpora el diseño de las tres capas que se presentan en este trabajo.
68
La clave se encuentra en la capa HAL, la que extiende los conceptos incluidos en el módulo ADCM desarrollado para Atmel, específicamente la capacidad de convertir y configurar todos los canales de conversión disponibles. También para clarificar los cuatro modos de conversión que el MSP430 presenta, se han separado en las interfaces: MSP430ADCSingle y MSP430ADC12Multiple para conversión simple y múltiple respectivamente. Cada una provee dos comandos, los que permiten seleccionar si la conversión será una sola vez o periódicamente.
De esta forma se cuenta con interfaces que manejan de mejor manera todas las capacidades disponibles en el nuevo microcontrolador, incluso aumentando el nivel de abstracción de éstas.
13.2.2.5Bus de Datos.
Todo microcontrolador se relaciona con dispositivos digitales externos a través de algún bus standard de datos. Entre ellos podemos encontrar SPI/USART, UART, I2C y 1-Wire. Sólo un subconjunto de estos, son provistos por hardware, siendo necesario entonces implementar los otros con rutinas de software que ocupan pines digitales I/O de uso general.
La abstracción que se propone, debe ser capas de exportar el manejo del reloj de control incluyendo los modos sincrónicos y asincrónicos, factores que pre-escalan el reloj, generación de baud-rate,etc. Además se debe incorporar la capacidad de manejar el consumo de energía (por ejemplo en el caso de que una UART no esté transmitiendo datos, esta debe ser desactivada).
La funcionalidad de la capa HPL presenta dos rutas, una para los datos y otra para el control.
• Control: Permite configurar la fuente del reloj principal, pre-escalar y seleccionar el baud-rate. Las interrupciones pueden ser habilitadas o deshabilitadas acá. A través de esta interfaz los dispositivos pueden ser apagados para ahorrar energía.
• Datos: Esta interfaz se encarga del recibimiento y transmisión de bytes a través de los registros de hardware, así como también reportar interrupciones cuando se recibe algún dato.
Acá hay un ejemplo para la plataforma MSP430:
69
interface HPLUSARTControl {async command void enableUART();async command void disableUART();async command void enableUARTTx();async command void disableUARTTx();async command void enableUARTRx();async command void disableUARTRx();async command void enableSPI();async command void disableSPI();async command void setModeSPI();async command void setModeUART_TX();async command void setModeUART_RX();async command void setModeUART();async command void setClockSource(uint8_t source);async command void setClockRate(uint16_t baudrate, uint8_t mctl);async command result_t disableRxIntr();async command result_t disableTxIntr();async command result_t enableRxIntr();async command result_t enableTxIntr();async command result_t isTxIntrPending();async command result_t isRxIntrPending();async command result_t isTxEmpty();async command result_t tx(uint8_t data);async command uint8_t rx();}interface HPLUSARTFeedback {async event result_t txDone();async event result_t rxDone(uint8_t data);}
Figura .2.2.5.1 USART para MSP430
También se da soporte a los casos en que más de un protocolo es necesario, dándose soporte a todos estos a través de un simple módulo de hardware. Esto se puede hacer debido a una componente que se encarga de arbitrar el bus. A continuación se muestra esta interfaz:
interface BusArbitration {async command result_t getBus();async command result_t releaseBus();event result_t busFree();}
Figura 2.2.5.2 Interfaz que se encarga de controlar el manejo del bus.
Ejemplo de Relación entre las distintas Capas.
Para observar mejor como es que se relacionan las distintas capas de la abstracción de hardware, y así entender la funcionalidad y potencialidad de cada una de ellas, se mostrará un ejemplo : Clock y Timer.Como se explico en la sección 2.2.2.3 se creó una interfaz alarm para poder abstraerse de las características propias de cada hardware (MSP o AVR)
70
interface AlarmTMilli { async command uint32_t get(); async command bool isSet(); async command void cancel(); async command void set(uint32_t t0, uint32_t dt); async event void fired(); }
configuration AlarmC { provides interface AlarmTMilli as AlarmTimerMilli; provides interface AlarmT32khz as AlarmTimer32khz; provides interface AlarmT32khz as Alarm32khz1; provides interface AlarmT32khz as Alarm32khz2; //... provides interface AlarmTMicro as AlarmMicro1; provides interface AlarmTMicro as AlarmMicro2; provides interface AlarmTMicro as AlarmMicro3; //... }
71
interface Timer { command result_t setPeriodic(uint32_t dt); command result_t setOneShot(uint32_t dt); command result_t stop(); command bool isSet(); command bool isPeriodic(); command bool isOneShot(); command uint32_t getPeriod(); event result_t fired(); }
13.3 Conclusiones
Se han presentado las funcionalidades que tinyOS proporciona, desde el punto de vista de un esquema de abstracción de hardware, el cual genera un balance entre los diferentes requerimientos de las aplicaciones de redes de sensores y la creciente necesidad de construir sistemas más portables y fáciles de depurar.
El modelo presentado se encarga de ir poco a poco, desde las capas inferiores hacia arriba, logrando una independencia de la arquitectura de hardware, pero al mismo tiempo sin ir perdiendo el uso de las capacidades de éste.
Antes de iniciarse en el desarrollo de aplicaciones es crítico lograr el entendimiento de este modelo, pues sólo así se podrá reutilizar códigos existentes, facilitando el desarrollo de aplicaciones específicas orientadas a resolver problemas concretos.
Es importante mencionar que dependiendo del hardware a ocupar es que se debe realizar un estudio más acabado de las librerías, ya que son bastante extensas y complejas.
Una vez que se hayan definido estos, más el conocimiento adquirido al entender el modelo de capas presentado en este trabajo, el desarrollo de aplicaciones debiera ser un paso no muy complejo.
72
14 Descripción del Entorno de Desarrollo.
14.1 IntroducciónEn el siguiente trabajo se presentará una breve descripción del entorno de trabajo que nos ofrece tinyOS, y se describirá el procedimiento para poder trabajar con los sensores disponibles en el instituto 3ie.
En principio se analizarán las herramientas disponibles, las que podemos clasificar en de modo consola o modo grafico.
Luego se describirán los pasos a seguir para trabajar con los dispositivos disponibles y las herramientas propuestas anteriormente.
73
14.2 Desarrollo
14.2.1Instalación de TinyOS y el sistema de desarrollo.TinyOS es un sistema operativo que cuenta con muchas herramientas para el desarrollo de aplicaciones específicas, que pueden realizar diferentes funciones, ya sea obtención de datos desde sensores, transmisión de paquetes de información a traves de la red, etc.
El foco principal de información se encuentra en la página del proyecto. A continuación se mencionan algunos links importantes.
Dirección Contenido
http://www.tinyos.net Página Principal del Proyecto.
http://www.tinyos.net/download.html
Sección donde se pueden bajar las ultimas versiones del sistema operativo
http://www.tinyos.net/support.html
Página con el soporte para TinyOS
http://www.tinyos.net/tinyos-1.x/doc/tutorial/index.html
Tutorial on-line.
http://sourceforge.net/projects/tinyos/
Control de Versiones (CVS) de TinyOS, en el se pueden encontrar tanto aplicaciones que se encuentran en desarrollo para implementarse con TinyOS, como el desarrollo del código fuente de éste.
Tabla 3.2.1.1 Principales links.
La instalación de TinyOS puede llevarse a cabo tanto para plataformas Linux como para Windows. En este caso, enfocaremos nuestro trabajo a las herramientas disponibles para windows, las cuales son proporcionadas por la empresa Crossbow, las cuales facilitan bastante el trabajo con los Motes pues proporcionan interfaces gráficas, para la mayoría de las labores a realizarse (programación, pruebas de conectividad, obtención de datos, etc).
14.2.1.1Consideraciones de la distribución de Crossbow.
Los siguientes archivos son instalados al ejecutar el binario tinyos-1.1.0-1is.exe
• TinyOS
• TinyOS Tools
• nesC
• Cygwin
• Support Tools
74
• Java 1.4 JDK & Java COMM 2.0
• Graphviz
• AVR Tools
• avr-binutils
• avr-libc
• avr-gcc
• avarice
• avr-insight
También se hace necesaria la instalación de un update, en el caso de la distribución de la empresa crossbow es la versión tinyos-1.1.7July2004cvs-1.cygwin.noarch.rpm Es importante mencionar que en la página de tinyOS, específicamente http://www.tinyos.net/dist-1.1.0/tinyos/windows/ se pueden encontrar las versiones mas actuales de el paquete tinyos, siendo la ultima versión de éste la 1.1.12.
Una vez realizado esto, tinyOS debiese quedar completamente instalado en el sistema. Como bien se sabe, el ambiente de trabajo es en Cygwin, un entorno unix que corre sobre windows, por lo que para proceder a trabajar con las herramientas de tinyos debemos correr esta aplicación.
La empresa Crossbow a desarrollado aplicaciones que no se encuentran disponibles en la instalación de tinyOS, y que deben ser copiadas directamente por el usuario al directorio de trabajo correspondiente, esto es tinyos-1.x/contrib/xbow.
14.2.1.2Verificación de la instalación.
Lo primero sería entrar a Cygwin.Cambiar al directorio opt/tinyos-1.x/tools/scripts/ y ejecutar toscheck.
$ cd opt/tinyos-1.x/tools/scripts$ ./toscheck
Si todo está bien instalado debiese la última línea de la salida standard decir lo siguiente:
$ toscheck completed without error
75
14.2.2Compilando aplicaciones TinyOSPara la compilación de aplicaciones la siguiente sintaxis debe ser ocupada:
$ make <plataforma>
Donde <plataforma> debe corresponder a una de las soportadas por la versión de tinyos. En el caso de tener instalada la versión básica de la distribución, es decir, tinyos 1.1.0, las plataformas soportadas serán: Mica, mica2, mica2dot y pc.
Es necesario por ende instalar el upgrade para poder trabajar con micaz (plataforma de los motes que se poseen). En el caso de instalar versiones superiores, por ejemplo tinyos 1.1.11, las plataformas soportadas además de las mencionadas anteriormente son: Micaz, Telos, snms_schema, Telos_hc08, Telosa, Telosb y Tmote.
También es importante mencionar que a la compilación se pueden agregar ciertos extras, destacando entre ellos la posibilidad de generar la documentación de la aplicación.
$ nesdoc <Directorio> <aplicación>
76
14.2.3Descripción de las herramientas disponiblesPara el trabajo con los motes existen variadas herramientas, que van desde aquellas que trabajan en consola, hasta interfaces gráficas. Estas últimas se encuentran disponibles en el directorio /tos/tools/ siendo las más importantes las que se encuentran en en el directorio subdirectorio java-
14.2.3.1SerialForwarderEsta es una aplicación Java la cual sirve para abrir un socket en el servidor que contiene la conexión por algún puerto al gateway de la red de sensores inalámbricos. De esta forma, la información de la red puede ser obtenida desde cualquier pc conectado a internet.
14.2.3.2Surge GUIEs una herramienta entregada por la empresa Crossbow para trabajar con los motes, que puede ser descargada desde la página de la empresa, específicamente desde http://www.xbow.com/Support/downloads.htm Surge-view está diseñado para trabajar con los motes, permitiendo obtener datos de los estados de conexión que hay entre los distintos nodos, proporcionando una interfaz gráfica de distribución de los nodos en el espacio.Es importante mecionar que tambien se dispone de una versión libre, la que se puede cargar de la siguiente forma:
$java net.tinyos.surge.MainClass <num_nodos>
14.2.3.3Mote-ViewSe obtiene de la misma forma que Surge GUI.MOTE-VIEW esta diseñado para ser una interfaz entre el usuario y los nodos de una red inalámbrica de sensores. MOTE-VIEW provee al usuario herramientas que simplifican la distribución fisica de los nodos y el monitoreo de estos. Además facilita el conectarse a base de datos, donde se pueden analizar y graficar las variables obtenidas. Más información se puede encontrar en el manual de usuario, disponible al instalar esta aplicación.
14.2.4Descripción de pasos a seguir para la configuración y uso de los Motes CrossBow y el Gateway MIB600 en las herramientas MoteView 1.0, Serial Forwarder y Surge View.
14.2.4.1Configurar MIB600
• Conectar MIB600 (Gateway) al transformador de 5 V, teniendo mucho cuidado de que el switch del MIB600 se encuentre en la posición SW1 (5V).
• Conectar cable de red (ethernet) al MIB600.
• Correr programa DeviceInstaller y ejecutar Search hasta que encuentre el MIB600 (UDS-10/Cobox 5.x), puede demorar unos segundos, en caso que no tenga IP asignada el MIB600, o que la asignada no sea una IP válida en nuestra LAN, habrá que asignar una IP manualmente que sea acorde a la LAN donde uno se encuentre conectado.
77
14.2.4.2Configurar Motes (programar).
• El MIB600 debe estar apagado.
• Conectar Mote en el Gateway en modo Off y sin pilas.
• Encender MIB600 y conectar red.
• Abrir Mote View, entrar en la pestaña Tools y luego en Program Mote. En la ventana que se abre, entrar en la pestaña Settings y luego en Interface Board Settings, una vez adentro elegir MIB600 y colocar la dirección IP asignada al MIB600.
• Luego en la ventana Mote Config que ya esta abierta, elegir el archivo a cargar en el mote, para este caso el archivo “surge_2420_hp”. Luego colocar un mote ID y un group ID (en nuestro caso 125)(OJO: al mote que va a quedar en el MIB600 configurarlo con ID 0). Elegir la frecuencia y canales, lo más importante acá es que se elija RadioBand 2400. Luego pulsar Program.
• Repetir el último paso con todos los motes que se desee trabajar, pero asignándole mote ID diferentes. Cada vez que se cambie un mote en el MIB600 desconectar primero la corriente y luego quitar cambiar motes. Además como se desconecta y conecta el MIB600, este se demora un par de minutos en recuperar su IP.
14.2.4.3Ver Datos de la red en Mote View 1.0
• Luego una vez configurado todos los motes, ponerle pilas a los motes que no se encuentren en el MIB600, agregarle las placas sensoras, y ponerlos en estado ON. Al mote que se encuentra en el MIB600 también ponerlo en estado ON.
• Para conectar el mote que trabajara junto al MIB600, acordarse de que tanto este como el mote se encuentren apagados al momento de conectarse, luego conectar a la corriente el MIB600, y conectarlo a la red, para por último colocar en estado ON el mote. Una vez hecho esto comprobar que el MIB600 tenga asignado una IP válida.
• Luego en el Mote View ingresar a la pestaña Window y luego en Server Configuration, elegir connect, y en Table Name elegir surge_results, por último Aceptar.
• Luego ir a Log Data, elegir Host y colocar los datos correspondientes, luego en XMesh Application poner Surge y por último Start.
• A los pocos minutos deberían empezar a verse los datos recogidos desde los sensores.
78
14.2.4.4Uso de Surge View
• Iniciar programa Serial Forwarder, en Server Port colocar 9001, en Mote Communications colocar “network@direccionIP_MIB600:10002” y luego Start Server, si esta todo bien configurado y los motes encendidos debería empezar a incrementarse los paquetes recibidos.
• Ir mediante mediante una consala cygwin o DOS hasta el directorio Surge View, y ejecutar la aplicación surge con la siguiente línea: surge 125.
79
14.3 ConclusionesTinyos proporciona un set de herramientas para la creación de aplicaciones, proporcionando además programas para la depuración y prueba de éstas.
Según sea la plataforma a ocupar, es que se dispondrán de más o menos herramientas. Es importante mencionar que para plataformas MSP430 existe el uso de JTAG, el cual además de proporcionar la grabación de aplicaciones, también facilita la emulación.
80
15 Referencias
[1] “Mote-View” (Manual de Usuario)
[2] “Getting Started Guide” Rev.B, August 2004, Document 7430-0022-05.
[3] Información disponible en página http://www.tinyos.net
[4] Flexible Hardware Abstraction for Wireless Sensor Networks
81
Informes Segunda Etapa.
82
Índice
1 Tossim. ....................................................................................................................... 3 1.1 Introducción ........................................................................................................ 3 1.2 Desarrollo ........................................................................................................... 4
1.2.1 Compilador: ................................................................................................. 5 1.2.2 Modelo de Ejecución. .................................................................................. 6 1.2.3 Modelo de la Red Inalámbrica. ................................................................... 6 1.2.4 Servicios de Comunicación. ........................................................................ 6 1.2.5 Emulación de Hardware. ............................................................................. 7 1.2.6 Ejecución de Tossim y TinyViz .................................................................... 9
1.3 Conclusiones. .................................................................................................... 12 2 Aplicaciones más importantes. ............................................................................... 13
2.1 Introducción. ..................................................................................................... 13 2.2 Desarrollo. ........................................................................................................ 13 2.3 Conclusiones ..................................................................................................... 17
3 Inyectando comandos en la red. ............................................................................. 18 3.1 Introducción. ..................................................................................................... 18 3.2 Desarrollo ......................................................................................................... 18 3.3 Conclusiones. .................................................................................................... 20
4 Referencias .............................................................................................................. 21 5 Anexos. ..................................................................................................................... 22
5.1 Anexo A- Data Link Layer: TinyOS Networking (AM and Below) .................. 22
83
16 Tossim.
16.1 Introducción
En el presente trabajo se mostrará la aplicación Tossim y las múltiples herramientas que esta posee, profundizando principalmente en la aplicación Java TinyViz. Básicamente Tossim provee un completo entorno de simulaciones para redes de sensores inalámbricas, abarcando tanto el comportamiento de ésta como red, como también la ejecución de la aplicación en cada nodo, posibilitando de esta forma la depuración de aplicaciones que se estén desarrollando.
A continuación se muestran los conceptos básicos que enmarcan el funcionamiento de esta herramienta, para luego presentar su funcionamiento y llegar a la aplicación de ésta en programas reales.
84
16.2 DesarrolloTossim es un completo simulador para las redes de sensores inalámbricas, el cual captura todo el comportamiento e interacción de los motes en una red.
Posee muchas características que lo hacen una herramienta útil y casi esencial para el desarrollo y depuración de aplicaciones. A continuación se muestra un esquema que define la arquitectura de tossim, la cual podemos dividir en 5 partes:
• Soporte para compilar la estructura propia de TinyOS (make pc).
• Cola de eventos, que simula las interrupciones.
• Realiza pequeñas modificaciones a las componentes de abstracciones de hardware, de forma de poder interactuar con el entorno de simulación
• Mecanismos para el trabajo con el conversor ADC y con el transceiver del modelo de comunicación inalámbrica (radio model).
• Comunicación con otros programas externos que permitirán la interacción con la simulación, de la misma forma como se realizaría con una red inalámbrica real.
Figura 1.2.1 Arquitectura de Tossim: Frames, eventos, modelos, componentes y servicios
Tossim ejecuta el mismo código que el que funcionará en un mote cualquiera, y sólo cambiará algunas componentes de bajo nivel (ADC,Clock,RFM). Las interrupciones de hardware, que ocurren en un mote real, son simuladas a partir simulador de eventos discreto.
Podemos imaginar a Tossim como un grafo dirigido (figura 1.2.2), en el cual los vértices (A,B,C,etc) corresponden a los nodos, mientras que las uniones o lazos son los enlaces, los que poseen una probabilidad de error de bit, lo cual permitirá modelar dos de los problemas típicos de este tipo de configuraciones: Terminal oculto, transmisión con condiciones perfectas pero en el que igual hay pérdidas aleatorias.
85
En lo que a conexión con aplicaciones externas se refiere, Tossim es capaz de comunicarse a través de un socket TCP/IP, con herramientas que nos permitirán monitorear el estado de la red.
Figura 1.2.2 Forma de un grafo dirigido.
16.2.1Compilador:
Al compilar una aplicación TinyOS para un PC, el principal cambio en comparación al archivo generado para un mote es el manejo de variables en la memoria.
En la figura siguiente se muestran los dos códigos generados al compilar una aplicación
Figura 1.2.1.1 Cuadro comparación de Códigos.
La forma en que se genera el ejecutable que funciona con el simulador es escribiendo:
$ make pc
Recordemos que al agregar ciertos extras, como docs se genera la documentación.
Una vez realizado esto, en el directorio build/pc/ se encontrará un fichero ejecutable llamado main.exe. Es éste el que al ejecutarse generará la simulación. Además existen ciertas opciones que se detallan a continuación:
86
Usage: ./build/pc/main.exe [options] num_nodes[options] are:-h, --help Display this message.-gui pauses simulation waiting for GUI to connect-a=<model> specifies ADC model (generic is default) options: generic random-b=<sec> motes boot over first <sec> seconds (default: 10)-ef=<file> use <file> for eeprom; otherwise anonymous file is used-l=<scale> run sim at <scale> times real time (fp constant)-r=<model> specifies a radio model (simple is default) options: simple static lossy-rf=<file> specifies file input for lossy model (lossy.nss is default)-s=<num> only boot <num> of nodes-t=<sec> run simulation for <sec> virtual secondsnum_nodes number of nodes to simulate
Figura 1.2.1.2 Opciones para la ejecución de Tossim.
87
16.2.2Modelo de Ejecución.
La clave para entender como se ejecutan las aplicaciones, es tener presente el simulador de eventos (en reemplazo a las interrupciones por hardware). Este se va a encargar de realizar por software por ejemplo la obtención de un valor en el conversor ADC, señalizando a la componente que corresponde que el evento ha ocurrido. En el modelo de ejecución solo existe una gran diferencia a lo que ocurre en un nodo real, esta se debe a que los eventos son generados por software, lo cual impide que el manejador de interrupciones pueda desplazar la ejecución de tareas.
Además es importante mencionar que cada nodo estará funcionando a 4 Mhz, tal como ocurre en los nodos reales. Esto se aplica tanto para las tareas como para los eventos, logrando de esta forma obtener resultados que corresponden de manera fiel a lo que ocurre en la realidad. También ayuda a esto el hecho de que al iniciar una simulación se escoge un tiempo aleatorio para iniciar la ejecución de la aplicación en cada uno de los nodos, modelando de esta forma el comportamiento real que se tiene al iniciar los nodos de una red de sensores.
16.2.3Modelo de la Red Inalámbrica.
El modelo de la red inalámbrica consiste en un grafo dirigido (figura 1.2.1) el cual asigna una probabilidad de error a cada enlace. Existe una diferencia entre la probabilidad de falla entre los nodos (A,B) al de los nodos (B,A), es decir, son asimétricos. Cada nodo tendrá su propia visión de la red, es decir, escuchará y transmitirá cuando el canal este libre. Es importante mencionar que la simulación no modela las cancelaciones producto de RF.
Tossim presenta dos modos de operación en respuesta a los distintos tipos de redes que pueden existir:
• Static (lossy) : Sirve para probar protocolos en caso de MultiHop, con lo cual tossim permite visualizar los saltos que la información realiza entre un nodo y otro, hasta llegar a la estación base.
• Simple : Útil para probar protocolos en ausencia de MultiHop, por lo que permite estudiar situaciones de terminales ocultos, en el que un nodo no escucha a los otros nodos, por lo que dependiendo del protocolo intentará transmitir (aumentando el ruido) o no transmitirá nunca.
16.2.4Servicios de Comunicación.
Tal como se mencionaba al inicio de este trabajo, existen aplicaciones de PC que son capaces de monitorear, manejar y actuar sobre la red de sensores, al comunicarse con Tossim a través de un puerto serial virtual, el cual simulará la conexión de un estación base (gateway) al computador. Específicamente nos referimos a SerialForwarder, la cual al conectarse al nodo cero de la simulación, posibilita la obtención de datos desde la red de sensores.
88
16.2.5Emulación de Hardware.Tossim emula el comportamiento del hardware de las capas inferiores, específicamente:
• ADC
• Clock
• EEPROM
• Componentes de secuencia de boot
• Componentes de la comunicación inalámbrica (Radio Stack)
Un aspecto importante en la emulación del hardware es que se mantiene el comportamiento bi-fase que se propone con la programación en NesC; esto se ve reflejado por ejemplo en el conversor ADC, ya que para proveer el dato existe una función externa que se encargará de esta labor, lo cual luego provocará la señalización dataReady() como respuesta al comando getData().
En el caso del Transceiver, el manejo es de forma especial. Para poder entenderlo es recomendable primero leer el anexo A, donde se explica el funcionamiento de la capa de enlace de datos de forma resumida.
Para la Simulación de la red, se modelan tres tasas de muestreo para la transmisión y recepción de paquetes:
• 40Kbps Transmisión de datos
• 20 Kbps Recepción del simbolo de inicio.
• 10 Kbps Para el envío del simbolo de inicio.
Esto se logra cambiando los períodos entre los eventos del reloj del Radio.
Bajo la simulación se mantiene el concepto del manejador de eventos [2], cuando un mote transmite el bit de sincronización, chequea si algún otro mote que pueda oírlo está en estado de escucha. En el caso de que exista alguno, el nodo encola un evento de transmisión inalámbrica (Radio) para el receptor, representando la ocurrencia de una captura de entrada.
Este modelo incorpora los problemas de distancia, es decir la perdida de datos producto de la falta de potencia en el transmisor.El modelado ha sido comparado con pruebas reales (revisar estudio en publicación [4]) bajo ciertas condiciones y configuraciones de la red, verificando que se acomoda muy bien a la realidad. Mostramos en la figura 1.2.5.1 los gráficos obtenidos en esta simulación.
89
Figura 1.2.5.1 Resultados de pérdida de datos.
90
16.2.6Ejecución de Tossim y TinyVizComo se explico en la sección 1.2.1, al compilar la aplicación con el comando make pc (modo simulación) se crea un archivo ejecutable main.exe. Una de las herramientas muy útiles que nos provee Tossim es la DBG (debug). Para entender mejor su funcionamiento primero se debe aclarar que el lenguaje NesC permite agregar instrucciones, en el código de la aplicación, del tipo dbg (dbg(DBG_<variable reservada>, "<Texto>");) la cual proporciona una especie de printf (escritura por la salida estandar, pantalla) en el momento de ejecución del simulador. Luego así podemos seleccionar que tipo de mensajes dbg queremos observar. Por ejemplo, si lo que interesa es ver sólo los mensajes del tipo AM (active message) bastaría que yo configurara como variable de entorno DGB=am, donde am seria la variable reservada, específicamente escribiría:
export DBG=am.
Así como existen estas variables reservadas, también se pueden agregar flags proporcionados por el usuario. En este caso se debe agregar en el código de la aplicación lineas del tipo:
dbg(DBG_<tipo>, "”);
Donde tipo puede ser: usr1, usr2, usr3, temp.
En la tabla 1.2.6.1 se muestran las opciones validas para realizar el debug.
Tabla 1.2.6.1 : Opciones para debug (DBG).
Otro aspecto importante es que dada la compilación cruzada de la aplicación (NesC -> C), es que podemos ocupar la herramienta GNU de depuración para archivos C (tambien llamada dbg). Esta herramienta nos permitiría realizar un debug completo (con breakpoints, etc) sobre la aplicación que se haya creado. El
91
all: Enable all available messagesboot: Simulation boot and StdControlclock: The hardware clocktask: Task enqueueing/dequeueing/runningsched: The TinyOS schedulersensor: Sensor readingsled: Mote ledscrypto: Cryptographic operations (e.g., TinySec)route: Routing systemsam: Active messages transmission/receptioncrc: CRC checks on active messagespacket: Packet-level transmission/receptionencode: Packet encoding/decodingradio: Low-level radio operations: bits and byteslogger: Non-volatile storageadc: The ADCi2c: The I2C busuart: The UART (serial port)prog: Network reprogrammingsounder: The sounder on the mica sensor boardtime: Timerssim: TOSSIM internalsqueue: TOSSIM event queuesimradio: TOSSIM radio modelshardware: TOSSIM hardware abstractionssimmem: TOSSIM memory allocation/deallocation (for finding leaks)usr1: User output mode 1usr2: User output mode 2usr3: User output mode 3temp: For temporary use
único inconveniente es que este debug al realizarse en el código C generado, dificultará la depuración del código escrito como aplicación (en NesC).
TinyViz : Aplicación Grafica para Tossim.
TinyViz es una herramienta escrita en lenguaje Java, que permite visualizar, controlar, y analizar una simulación de Tossim. Provee un interacción en línea, al ser capaz de modificar parámetros como ADC, Modo de la comunicación inalámbrica, etc., propios tanto de cada nodo como de las redes de sensores.
Posee un sistema de Plugins los cuales permiten una mejor simulación al considerar variables físicas en la simulación, además de facilitar el desarrollo de nuevas herramientas. De esta forma el usuario interactúa con la simulación habilitando (cargando ) estos plugins los que van a proveer la funcionalidad deseada. El directorio donde se encuentran es tools/java/net/tinyos/sim/plugins.Podemos clasificar estos plugins de dos tipos, dependiendo de su direccionalidad:
• Envían mensajes a Tossim
• Reciben salidas generadas por Tossim.
A continuación se muestra una captura de este sistema.
Figura 1.2.6.2 TinyViz.
Los pluggins disponibles son:
• Debug messages: Muestra una ventana con todos los mensajes de debug generados por la simulación. Se pueden seleccionar nodos y también aplicar filtros para seleccionar que tipo de mensaje se desea observar.
Es importante mencionar que los mensajes mostrados dependen del valor
92
asignado a la variable DBG, que se le asigno al correr Tossim. Ejemplo: DBG=usr1,am tinyviz -run build/pc/main.exe 30 sólo mostrará los mensajes del tipo AM y el definido por usr1.
• Set breakpoint: Permite agregar breakpoints, el que pausará la ejecución de la aplicación cuando la condición se cumpla. Pueden ser multiples.
• ADC readings: Muestre los valores más recientes de cada ADC
• Sent radio packets: Este es importante, y muestra el tráfico de paquetes en la red.
• Radio links: Muestra gráficamente la actividad de mensajes. Broadcast se muestra con un círculo azul. Mensaje a un mote en particular con una línea entre los nodos.
• Set location: Realiza una localización virtual de los nodos, disponible gracias a la interfaz apps/TestTinyViz/Location.nc. Existe la posibilidad de cargar mapas de fondo en la simulación, o agregar una grilla, la cual esta graduada en alguna escala de distancia.
• Radio model: Configura tasa de error de bits entre cada nodo, acorde a su localización y el modelo de conectividad que se esta ocupando. Habilitar este pluggin permite tener una simulación más realista. Existen dos modelos básicamente: Empirical (basado en una conexión en lugar abierto, a través del transceiver RFM1000 ) y Fixed radius (todos los nodos dentro de una distancia delimitada tiene conectividad, mientras que el resto no la tiene). Al configurar el scaling factor en el panel de control se escala los parámetros de distancia del modelo a simular.
Otras herramientas.
Existe la posibilidad de ocupar un script de configuración, donde se dejen guardados todos los parámetros a ejecutarse una vez que tinyviz sea ejecutado. El archivo se encuentra en apps/TestTinyViz/sample.autorun y debe ser modificado con los parámetros que uno como desarrollador desea probar.
93
16.3 Conclusiones.Tossim es una herramienta muy valiosa, que presenta muchas ventajas. Entre ellas podemos detallar:
• Útil para el aprendizaje de aplicaciones existentes, ya que al simularl se puede observar con detalles el funcionamiento que ésta tiene, capturando mensajes que se generan con la herramienta debug.
• De gran utilidad para proyectos que incorporan el uso de muchos nodos, ya que no es necesario salir a terreno para obtener una aproximación del comportamiento que la red tendrá.
• La interacción con herramientas externas permite que se pueda ocupar esta herramienta como punto de partida de aplicaciones superiores (en un PC, por ejemplo) el cual podrá ir obteniendo los valores simulados que se obtienen de los motes.
No es posible cargar aplicaciones distintas en los nodos, pero si permite la reprogramación y el envío y recepción de comandos.
Dentro del contexto del proyecto veo la aplicabilidad de esta herramienta en dos areas:
• Protocolos de comunicación: Ya que se podría verificar el funcionamiento del protocolo al forzar ciertas distribuciones físicas y simular la obtención de datos que tengan que ser transmitidos al nodo base.
• Interacción con software de alto nivel: Esto es por ejemplo interactuar con la base de datos, ya que al disponer de la herramienta SerialForwader toda la información se dispone en un socket TCP/IP, la cual puede ser obtenida por el programa que almacenará en la base de datos.
94
17 Aplicaciones más importantes.
17.1 Introducción.A continuación se presentarán las aplicaciones existentes para TinyOS más importantes. En general éstas se encuentran en el directorio /apps de la distribución del Sistema Operativo.
Los parámetros que determinan su elección son principalmente que presenten conceptos de forma simple y explicativa y sobre todo aplicabilidad al proyecto.
17.2 Desarrollo.A continuación se mostrarán en una tabla las aplicaciones con su respectiva explicación y alcance.
Blink Programa simple, que fue diseñado básicamente para poder enseñar la programación de TinyOS, y que se encarga de encender un Led cada un segundo
BlinkTask La función de esta aplicación es la misma que la anterior, pero la diferencia radica en como el evento Clock.fire() (que indica cuando la interrupción del timer se lleva a cabo) es manejada, pues cuando la interrupción ocurre no se atiende por el manejador de interrupciones, sino es encolado como una tarea a realizar.
Bombilla Bombilla es una aplicación de prueba para el intérprete de comunicación centralizada Bombilla. Incluye la maquina virtual y todos sus componentes. Al instalar esta aplicación sobre un mote, quedará por defecto un programa similar a oCntToLedsAndRFM. Programas nuevos podrán ser instalados a traves de la red.Bombilla proporciona herramientas gráficas que permiten la reprogramación y modificación de aplicaciones desde la estación base. Para mayor información se recomienda leer el tutorial de ésta aplicación.
CntToLedsAndRfm
Mantiene un contador sobre un timer de 4Hz, y muestra los tres bits más significativos del contador en los Leds de la plataforma para luego enviar a los demás en un paquete AM, el valor de la cuenta.
CntToRfm Mantiene un contador sobre un timer de 4Hz y lo envía por la red en un paquete AM, esto cada vez que se produce un incremento.
GenericBase GenericBase es un puente desde un PC a un sensor conectado a la red. Los paquetes recibidos desde un pc son enviados desde la UART por Radio(Transceiver), y los paquetes recibidos desde Radio son enviados por la UART. Esto permite monitorear el tráfico de la red e inyectar paquetes a la red.Es importante mencionar que por defecto el GenericBase chequea CRCs. Por lo que los paquetes que se envían por la UART deben configurar su campo CRC a 1º sino no será recibido de forma correcta.Cuando GenericBase envía un paquete a la UART (recibido por
95
radio) se enciende el Led verde. En caso de enviar un paquete por radio, se enciende la luz rojaGenericBase solo recibe y envía paquetes direccionados a su grupo AM.
Ident Aplicación para hacer rastreo de identidades de personas. Necesita lo siguiente:1 Grabar un mote con GenericBase para que se comunique con
los demás motes.2 Grabar aplicación Ident en los demás motes.3 Ejecutar SerialForwarder.4 Ejecutar java net.tinyos.ident.Ident <group id>La herramienta que se ejecuta, permite grabar cada mote con una identidad específica y también borrarlas.Los motes indicarán el estado en que se encuentran funcionando con el leds que estará encendido.
MicaSBVerifyMicaHWVerify
Contiene Aplicaciones que prueban los distintos sensores que puedan existir para estas plataformas.
RfmToLeds RfmToLeds escucha por mensajes del tipo IntMsg. Cuando recibe uno el configura sus leds dependiendo de los últimos tres bits del valor recibido. Generalmente se combina con el CntToRfm o con CntToLedsAndRfm, siendo en conjunto herramientas simples para probar la red.
SecureTOSBase
Aplicación que incorpora nivel de encriptación a la aplicación base TOSBase.
Sense Sense es una aplicación que periódicamente muestrea el sensor de luz, para entregar los 3 bits más significativos del valor obtenido con el ADC a través de los LEds.
SimpleCmdBcast
SimpleCmd, maneja mensajes AM del tipo 8. Este tipo de mensaje corresponde a un comando desde un PC que está conectado a la estación Base.
En la actualidad SimpleCmd solo soporta 4 comandos:5 led_on --- Enciende el LED amarillo6 led_off – Apaga el Led amarillo.7 radio_quieter --- Disminuye la potencia de la transmisión.8 radio_louder --- Incrementa la potencia del RFM
Bcast --- Puede procesar un comando como lo realiza el SimpleCmd y reenviar un nuevo comando por radio a los otros motes.
SenseTask SenseTask es una aplicación que periódicamente muestrea el sensor de luz, para luego postear una tarea que calculará el promedio de las muestras recientes y además mostrará los 3 bits más significativos en los LEDs de la plataforma.
SenseToRfm SenseToRfm es una aplicación que realiza lo mismo que la anterior, pero envía la lectura a través de un paquete en la red. La aplicación se construye simplemente por el cableado de las componentes Main, TimerC, Photo, IntToRfm y SenseToInt.
Surge Surge es una aplicación pensada para probar el funcionamiento de las redes de sensores(MultiHop ad-hoc routing), consta de capturar un valor en el conversor ADC y luego lo envía por la red
96
para que llegue al nodo base.
TinyDBApp TinyDB es un sistema de procesamiento de solicitudes, que permite extraer información desde una red de sensores con TinyOS. Existen diferentes soluciones para la obtención de información en TinyOS (escribir códigos para esto). En lugar de esto, TinyDB provee una interfaz similar a SQL para la obtención de datos.
Para el uso de TinyDB, se deben instalar sus componentes sobre cada uno de los motes de la red (coexiste con otras componentes instaladas, aunque ellas exijan bastantes recursos de sistema ).
TinyDB provee una API en Java, para escribir aplicaciones en el PC que sean capaz de extraer los datos desde la red. También provee una interfaz grafica para mostrar los resultados y datos obtenidos.
Para mayor información de TinyDB, se invita a leer el archivo doc/tinydb.pdf.
La mayoría de la implementación de TinyDB se encuentra almacenada en : tos/lib/TinyDB/ y las interfaces Java en tools/java/net/tinyos/tinydb/
TOSBase TOSBase es una aplicación que actúa como un puente entre un canal de comunicación serial (SerialForwarder) y la red inalámbrica. TOSBase solo hará puente mientras el ID del grupo al cual pertenece sea el mismo que los de la red.
Aplicaciones del tipo Xnp*
Permiten captar solicitudes de reprogramación
XnpCount XnpCount es una extensión de CntToLedsAndRfm pero que puede captar solicitudes de reprogramación..
XnpOscopeRF XnpOscope es extensión de OscilloscopeRF.XnpOscope detiene la componente Clock cuando recibe una solicitud de reprogramación para hacer que la aplicación no compita con la aplicación de reprogramación por el recurso de Radio. XnpOscope inicia Clock de nuevo cuando es notificado de que la reprogramación se llevo a cabo con éxito
Aplicaciones de tipo Test
Permiten evaluar hardware y herramientas externas que se comunican con las aplicaciones instaladas.
TestEEPROM Prueba la EEPROMTestSnooze Permite probar los niveles de bajo consumo de una plataforma.TestTinyAlloc TestTinyAlloc prueba el asignador de espacio de memoria
dinámica TinyAlloc.TestTinySec Prueba la aplicación TinySec.TestTinyViz Pequeña aplicación que permite probar la herramienta TinyViz.TestUart TestUART es una aplicación para la componente UARTDebugger,
la que provee el manejo de un display LCS, y provee una interfaz para escribir mensajes en tiempo de ejecución.
TestWDT Prueba el comportamiento del Watchdog (Timer que en caso de que la aplicación se cuelgue este la reinicia )
97
98
17.3 ConclusionesAl estudiar las distintas aplicaciones disponibles, se pueden rescatar algunas de ellas en vista del proyecto.TinyDB es una aplicación que facilitaría bastante la obtención de datos, dado que trabaja con primitivas similares a SQL, y además optimiza el uso de la energía al ser la central quien solicita la información almacenada en los nodos, en el momento que sea necesario.
También destaco la utilización de SimpleCmd y Bcast, aplicaciones que permiten la ejecución de comandos concretos en la red. Esto en vista de que si por ejemplo, es necesario obtener algún valor de un sensor, a través de la red puedo enviar un comando el cual permitirá obtener estos valores. En el siguiente capítulo se profundiza en esta aplicación.
99
18 Inyectando comandos en la red.
18.1 Introducción.En el siguiente trabajo se investiga acerca de la posibilidad de “inyectar” ciertos comandos a una red de sensores inalámbrica. Se describe en base a dos aplicaciones que existen en los directorios tinyos-1.x/apps/ de la distribución de Tinyos: SimpleCmd y TOSBase.
También se explicará la aplicación Bcast, la cual realiza la misma acción que SimpleCmd pero propagando el comando por la red.
18.2 DesarrolloBásicamente esta aplicación consiste en recibir un paquete con un “comando”, a través de la red inalámbrica, de forma de ser interpretado y realizar un conjunto de acciones dependiendo del comando recibido.
Por el momento se cuenta con solo cuatro posibles comandos, según se detalla en el tutorial de TinyOS:
• led_on --- Enciende el LED amarillo
• led_off – Apaga el Led amarillo.
• radio_quieter --- Disminuye la potencia del transmisor/Receptor.
• radio_louder --- Incrementa la potencia del transmisor/Receptor.
El procedimiento a seguir es el siguiente:
4 Lo primero es programar los “motes”. Uno debe ser grabado con la aplicación TOSBase, mientras que el otro debe ser grabado con la aplicación SimpleCmd.
5 Se debe conectar al gateway de la red, el mote que tiene la aplicación TOSBase.
6 Se inicia la aplicación SerialForwarder16 con los parámetros correctos.7 Luego ya se puede iniciar la aplicación para poder inyectar los paquetes con
comandos en la red. La aplicación se encuentra en tools/java/net/tinyos/tools/BcastInject y se debe iniciar con la siguiente línea de comando: $ java net.tinyos.tools.BcastInject <group_id> <command>Donde <group_id> corresponde al grupo de Active Message que se está ocupando en la red, pero especificado en decimal.
Al analizar el código de SimpleCmdM.nc, podemos notar que este es una aplicación bien simple, la cual se mantiene en espera de que llegue algún mensaje del cual obtendrá un parámetro, el que interpretará como el comando.
La otra aplicación que realiza lo mismo, pero propagando el comando a través de la red es Bcast. Este se encuentra en apps/SimpleCmd/BcastM.nc. Para instalar esta aplicación es necesario editar el archivo apps/SimpleCmd/Makefile y cambiar la línea: COMPONENT=SimpleCmd a COMPONENT=Bcast
16 Remítase a informe segunda etapa.
100
BcastM.nc event TOS_MsgPtr ReceiveCmdMsg.receive(TOS_MsgPtr pmsg){ TOS_MsgPtr ret = msg; result_t retval; struct SimpleCmdMsg *data= (struct SimpleCmdMsg *)pmsg->data;
// Check if this is a new broadcast message call Leds.greenToggle(); if (is_new_msg(data)) { remember_msg(data); retval = call ProcessCmd.execute(pmsg) ;
// Return a message buffer to the lower levels, and hold on to the // current buffer ret = msg; msg = pmsg;
} return ret; }
Figura 3.2.1 Código de BCastM.nc
Para determinar si un mensaje ha sido recibido antes, la componente BcastM, que se muestra en la figura 3.2.1, rastrea la secuencia numérica contenida en el mensaje. Por ejemplo si este número es el actual 127, en decimal, este es aceptado, procesado y retransmitido. De otra forma éste es descartado. Es importante destacar que el programa BcastInject mantiene en el archivo /tools/java/bcast.properties las secuencias numéricas de las invocaciones. En el caso de eliminar este archivo, la secuencia será reiniciada a 1. Se puede implementar redundancia en envíos, de forma de que si se pierde un paquete por corrupción no sea eliminado por el radio stack. Es importante mencionar que se pueden implementar modelos más sofisticados basados en acknowledgments.
101
18.3 Conclusiones.
La utilización de SimpleCmd y Bcast es algo necesario, esto dado que si se desea obtener algún valor de un sensor, a través de la red puedo enviar un comando el cual permitiría obtenerlos.
El aprendizaje de como funcionan estos códigos, permitirá poder incorporarlos en las futuras aplicaciones.
Es necesario, por lo tanto ver si se pueden implementar estas aplicaciones, en otras más complejas, por ejemplo ver si se puede implementar en la aplicación Surge, algo que me permita variar por ejemplo el tiempo de muestreo de los datos tomados por los sensores.
102
19 Referencias
[1] Tossim: Accurate and Scalable Simulation of Entire TinyOS Applications.Phil Levis, Nelson Lee, Matt Welsh and David Culler.Harvard University, Berkeley, Intel Corporation.
[2] Informe Primera Etapa.Proyecto Agrícola Ojos Buenos.José Ulloa S.
[3] Tutorial Tinyoshttp://www.tinyos.net/tinyos-1.x/doc/tutorial/
[4] TOSSIM: A Simulator for TinyOS NetworksPhilip Levis and Nelson [email protected] 17, 2003
103
20 Anexos.
20.1 Anexo A- Data Link Layer: TinyOS Networking (AM and Below)
The TinyOS packet abstraction is an Active Message. AM packets are an unreliable data link protocol, and the TinyOS network stack handles media access control and single hop packet transmission. Active Messages provide precise timestamps as well as synchronous data-link acknowledgments. TinyOS provides a namespace of up to 256 AM message types, each of which can be associated with a separate software handler.
Figure A.1 shows the different phases of packet transmission and reception. The sender first enters a CSMA delay period, listening for an idle channel. The sender then transmits a packet start symbol at 10Kbps, which a receiver samples for at 20Kbps. As the following data is transmitted at 40Kbps, after the start symbol the receiver must synchronize to the sender at a finer granularity.
The sender pauses for a few bit times after the start symbol, then transmits a one bit. The receiver, after the start symbol, polls the channel to identify the falling edge denoting the sender pause. Once it has done so, it polls again, this time for the next rising edge, using an input capture register to take a precise timestamp. These two spin loops take roughly 400-600 µs. The receiver adjusts its radio clock so that its 40Kbps data sample rate is synchronized withthe sender’s signal. The sender starts transmitting encoded packet data, which the receiver decodes into a packet buffer.
Once the packet data has been read in, the sender transmits a pulse of ones for the receiver to use for measuring signal strength. After this strength pulse, the sender transitions into receive mode and the receiver transitions into send mode. The sender introduces a short pause in its timing as part of this phase shift; as the receiver was sampling after the sender actually transmitted a bit, the sender must shift its sampling point to be after the receiver. The receiver then transmits a short bit pattern indicating acknowledgment; if the sender hears it, it marks the sent packet as acknowledged before passing it back in a send done event. The receiver checks the packet CRC, discarding corrupted packets. If the packet is addressed for the receiver or the broadcast address, the networking stack signals a reception event of the proper AM type.
Figura A.1 Paquete de Recepción/Transmisión de TinyOS.
104
Informe Cuarta Etapa.Aplicación Surge para plataforma Telos.
105
Indice
1 Introducción. .............................................................................................................. 3 2 Desarrollo. ................................................................................................................. 4
2.1 Información Previa. ............................................................................................ 4 2.1.1 Obtención de Tinyos a partir del CVS. ........................................................ 4
2.2 Surge ................................................................................................................... 5 2.2.1 Descripción de Surge. ................................................................................. 5 2.2.2 Archivos que lo componen. ......................................................................... 5
2.3 Análisis y Estudio de los distintos ficheros que componen la aplicación Surge. ........................................................................................................................ 6
2.3.1 Surge.h. ........................................................................................................ 6 2.3.2 SurgeCmd.h. ................................................................................................ 7 2.3.3 Surge.nc. ...................................................................................................... 8 2.3.4 SurgeM.nc .................................................................................................. 11
3 Conclusiones ............................................................................................................ 22 4 Referencias. ............................................................................................................. 23 5 Anexos. .................................................................................................................... 24
5.1 Anexo A. ............................................................................................................ 24 5.1.1 Makefile. .................................................................................................... 24 5.1.2 README. ................................................................................................... 24 5.1.3 SurgeM.nc. ................................................................................................. 25
5.2 Anexo B. ............................................................................................................ 27 5.2.1 Detalles del lenguaje. ................................................................................ 27
106
21 Introducción.
Dado el conocimiento adquirido tras el estudio y análisis de Tinyos (su estructura y el lenguaje de programación), es que en esta etapa se ha hecho necesario iniciar el estudio de una aplicación simple y didáctica, que reúna las características y virtudes necesarias que nuestro proyecto demanda.
Surge es una aplicación que engloba de forma perfecta estas necesidades, al incluir la obtención de una variable sensada (temperatura) y además permitir la transmisión del valor capturado, hacia el nodo base a través de la red inalámbrica.
Este estudio se basa en la versión de Surge escrita por la UCB17 para la plataforma Telos, la cual se encuentra disponible en la versión CVS18 de Tinyos.
17 Universidad de California, Berkeley18 CVS : Sistema Concurrente de Versiones del proyecto, para mayor información remítase a http://sourceforge.net/cvs/?gr
107
22 Desarrollo.
22.1 Información Previa.Como se mencionaba en la introducción, el presente estudio se realiza en base a la aplicación Surge (específicamente SurgeTelos), disponible en el directorio de Tinyos:
$TOSROOT/contrib/ucb/apps/SurgeTelosEn la distribución original (instalación con alguna distribución ejecutable) no están presentes los archivos de contribuciones (/contrib/), por lo cual es necesario obtenerlos a partir del directorio CVS del proyecto. A continuación se explica de forma breve como realizar esto.
22.1.1Obtención de Tinyos a partir del CVS.CVS, Concurrent Versions System, es una aplicación cliente/servidor que se encarga de mantener un repositorio de software centralizado que es actualizado y distribuido desde y hacia las copias locales de los desarrolladores o usuarios.
El servidor de CVS provee tanto la versión más actual de un software, como también se encarga de mantener un historial de los ficheros que conforman el proyecto, permitiendo la consulta de versiones anteriores de un mismo fichero de una forma rápida y sencilla.
En el caso particular de Tinyos, el CVS se encuentra en el servidor de proyectos http://www.sourceforge.net, siendo posible visitar de forma gráfica el nodo principal de ficheros en el sitio http://cvs.sourceforge.net/viewcvs.py/tinyos/.
Para obtener una copia local, es necesario escribir el siguiente comando:$cvs -z3 -d:pserver:[email protected]:/cvsroot/tinyos
co –P <modulo>donde <module> debe ser el directorio o archivo que se quiere actualizar.
De esta forma si se quiere obtener toda la versión del CVS (recomendado) se deben seguir los siguientes pasos.
• Eliminar el directorio actual de tinyos-1.x. Esto es si por ejemplo el fichero existente se encuentra en /opt/tinyos-1.x se debe eliminar el directorio tinyos-1.x.
• En el directorio raiz ( /opt en el caso del ejemplo anterior ) se debe escribir el siguiente comando:$cvs-z3 - d:pserver:[email protected]:/cvsroot/tinyos co –P tinyos-1.x
• Una vez obtenida la copia local, es necesario compilar e instalar algunas cosas. A continuación se muestra el procedimiento:
o Entrar a /opt/tinyos-1.x/o Escribir $make o Ejecutar $make install (en caso de usar linux debe realizarse como
root)o Una vez realizado lo anterior entrar a /opt/tinyos-1.x/tools/java/o Ejecutar $make
• Al realizar estos pasos debiese quedar funcional la versión de Tinyos.
Ya definido el entorno de desarrollo y los archivos necesarios, es que podemos pasar a estudiar la aplicación Surge.
108
22.2 Surge
22.2.1Descripción de Surge.Surge es una aplicación de ejemplo la cual usa enrutamiento MultiHop Ad-hoc. Esta está diseñada para trabajar en conjunto con la herramienta Java Surge (disponible en el directorio /opt/tinyos-1.x/tools/java/net/tinyos/surge/). Básicamente cada nodo de la red obtiene un valor de temperatura (ocupando un sensor), para luego enviarlo a la estación base a través de la red inalámbrica.
22.2.2Archivos que lo componen.
La aplicación se encuentra en el directorio: $/opt/tinyos-1.x/contrib/ucb/apps/SurgeTelos. A continuación mostramos un cuadro resumen con los archivos que se encuentran en este directorio, junto con una breve descripción que extenderemos más adelante.
Archivo DescripciónMakefile Archivo necesario para la compilación de la aplicación, que es
ocupado en el momento de ejecutar make.README Archivo que describe tanto la aplicación como las herramientas
existentes para trabajar con ésta.SurgeCmd.h
Fichero Cabecera que define el tipo de dato SurgeCmdMsg y la enumeración AM_SURGECMDMSG.
Surge.h Fichero Cabecera que define variables a ser ocupadas, enumeraciones y el tipo de dato SurgeMsg
SurgeM.nc
Fichero que provee el código de la aplicación, implementando una o más interfaces.
Surge.nc Fichero donde se detalla la configuración de la aplicación, es decir como se uniran las distintas componentes del proyecto.
Tabla 2.2.2.1 Breve descripción de los archivos que componen SurgeTelos.
En la sección anexo A se encuentran los ficheros Makefile, README, mientras que ha continuación se procede a analizar los demás archivos.
109
22.3 Análisis y Estudio de los distintos ficheros que componen la aplicación Surge.
22.3.1Surge.h.
Tabla 2.3.1.1 Fichero Surge.h
Básicamente en este archivo se encuentran las definiciones de ciertas variables que serán ocupadas por el módulo de implementación de Surge.
A continuación se detalla un resumen con los tipos de datos definidos por nesc.
9 uint16_t que viene a ser un entero sin signo que ocupa 16 bits
10 uint8_t que viene a ser un entero sin signo que ocupa 8 bits.
11 result_t, se utiliza para devolver si usa función se ha ejecutado con éxito o no, viene a ser como un booleano pero con los valores SUCCESS y FAIL
• bool, es un valor booleano que puede valer TRUE o FALSE
También es posible ocupar el tipo de dato int, el cual tiene un comportamiento similar al entero definido en C.
El tipo SurgeMsg es una estructura que define el buffer de datos que se transmitirá cuando se invoque el comando send. Corresponde al Payload de la trama TOS_MSG. Podemos notar que tiene parámetros tales como tipo, lectura, nodo padre, y el número de secuencia.
110
// $Id: Surge.h,v 1.3 2004/12/07 22:45:25 jpolastre Exp $
int INITIAL_TIMER_RATE = 2048;int FOCUS_TIMER_RATE = 1000;int FOCUS_NOTME_TIMER_RATE = 1000; enum { SURGE_TYPE_SENSORREADING = 0, SURGE_TYPE_ROOTBEACON = 1, SURGE_TYPE_SETRATE = 2, SURGE_TYPE_SLEEP = 3, SURGE_TYPE_WAKEUP = 4, SURGE_TYPE_FOCUS = 5, SURGE_TYPE_UNFOCUS = 6};
typedef struct SurgeMsg { uint16_t type; uint16_t reading; uint16_t parentaddr; uint32_t seq_no;} SurgeMsg;
enum { AM_SURGEMSG=18}
22.3.2SurgeCmd.h.
Tabla 2.3.2.1 Fichero SurgeCmd.h
Para más detalles sobre que significa union, remítase a la sección de Anexo 2.
111
// $Id: SurgeCmd.h,v 1.1 2004/07/07 22:53:57 jpolastre Exp $
typedef struct SurgeCmdMsg { uint16_t type; union { // FOR SURGE_TYPE_SETRATE uint32_t newrate; // FOR SURGE_TYPE_FOCUS uint16_t focusaddr; } args;
} SurgeCmdMsg;
enum { AM_SURGECMD= seqno++;}
22.3.3Surge.nc.
A continuación se muestra el código que compone el archivo Surge.nc, con los respectivos comentarios.
Tabla 2.3.3.1 Fichero Surge.nc
Es necesario recordar que con este fichero se encuentra definida la componente Surge. En otras palabras al observarlo se puede resumir el alcance que la aplicación tendrá y las componentes e interfaces necesarias para el funcionamiento de ésta.
112
// $Id: Surge.nc,v 1.5 2004/11/02 17:29:46 jpolastre Exp $
/ /Acá se incluyen las cabeceras explicadas anteriormente (Surge.h, SurgeCmd.h) y además la // librería MultiHop.h que se explica en la tabla 2.3.3.4.includes Surge;includes SurgeCmd;includes MultiHop;
// Se inicia la sección de configuración de la aplicación Surge.configuration Surge {}
//Sección de Implementación de la aplicación.implementation {// Lo primero es detallar las componentes que se van a usar. components Main , SurgeM , TimerC , LedsC , DelugeC , DemoSensorC as Sensor , RandomLFSR , GenericComm as Comm , CC2420RadioC , LQIMultiHopRouter as multihopM ;// Se generarán las uniones.// Las interfaces de la izquierda son provistas por las componentes de la derecha.. Main.StdControl -> DelugeC; Main.StdControl -> TimerC; Main.StdControl -> Comm; Main.StdControl -> Sensor; Main.StdControl -> multihopM.StdControl; Main.StdControl -> SurgeM.StdControl;
SurgeM.ADC -> Sensor; SurgeM.Timer -> TimerC.Timer[unique("Timer")]; SurgeM.Leds -> LedsC; SurgeM.Random -> RandomLFSR;
SurgeM.CC2420Control -> CC2420RadioC.CC2420Control; SurgeM.MacControl -> CC2420RadioC.MacControl;
SurgeM.RouteControl -> multihopM; SurgeM.Send -> multihopM.Send[AM_SURGEMSG]; multihopM.ReceiveMsg[AM_SURGEMSG] -> Comm.ReceiveMsg[AM_S dom]; }
enum { AM_MULTIHOPMSG = 250};
/* Fields of neighbor table */typedef struct TOS_MHopNeighbor { uint16_t addr; // state provided by nbr uint16_t recv_count; // since last goodness update uint16_t fail_count; // since last goodness, adjusted by TOs int16_t last_seqno; uint8_t goodness; uint8_t hopcount; uint8_t timeouts; // since last recv} TOS_MHopNeighbor; typedef struct MultihopMsg { uint16_t sourceaddr; uint16_t originaddr; int16_t seqno; uint8_t hopcount; uint8_t data[(TOSH_DATA_LENGTH - 7)];
} __attribute__ ((packed)) TOS_MHopMsg;
Figura 2.3.3.2 Archivo MultiHop.
Gracias a la herramienta nescdoc proporcionado por el compilador, es que lo mismo que se muestra en el archivo puede ser representado de forma gráfica, a través de una especie de diagrama de flujo.A continuación mostramos el diagrama obtenido para esta aplicación y explicamos como se debe interpretar.
Figura 2.3.3.3 Gráfico obtenido con nescdoc para Surge.nc
113
Para poder interpretar de forma correcta este diagrama, es necesario tener claro la siguiente nomenclatura, mostrada en la figura 2.3.3.4
A require la interfaz I, y B la provee
Tanto C y D proveen o requieren la interfaz J. La dirección de la flecha indica como se realiza el cableado, es decir "C = D".
E requiere la función f, y F provee la función f.
Tabla 2.3.3.4 Convenio ocupado por gráficos de nescdoc
A continuación se procederá a analizar el módulo de implementación de Surge (SurgeM.nc), donde no se incorpora el análisis de DelugeC, la que es una componente primitiva, que se ejecuta en paralelo con Surge, y que agrega la funcionalidad de reprogramación del nodo.
114
22.3.4SurgeM.nc
A continuación se procede a analizar el archivo Módulo. Esta sección más extensa, es en la que realmente se programa la implementación que se desea realizar con la aplicación. Esta a su vez, esta dividida en tres subsecciones : Uses, Provide e Implementation. El análisis se irá realizando por partes. Para una visión completa del programa remítase al Anexo A.
Tabla 2.3.4.1. Archivos cabeceras incluidos.
22.3.4.1Subsección Provides y Uses.
Tabla 2.3.4.1.1 Declaración de interfaces (provistas/usadas)
A continuación se entrega una breve descripción de cada interfaz usada, y los comandos y eventos que estas incorporan.
Interfaz Descripción Comandos y Eventos.ADC Interfaz del conversor
análogo digitalresult_t getData (void) result_t getContinuousData (void)
Events result_t dataReady (uint16_t data)
115
// $Id: SurgeM.nc,v 1.5 2004/12/07 22:45:34 jpolastre Exp $
includes Surge;//Se incluye el archivo cabecera Surge.h
includes SurgeCmd;//Se incluye el archive cabecera SurgeCmd.h
module SurgeM {
// Acá se detallan las interfaces que son provistas, es decir, aquellas en las cuales implementamos código. provides { interface StdControl; }
// Acá, similar al caso anterior, se detallam las interfaces que van a ser usadas uses { interface ADC; interface Timer; interface Leds; interface CC2420Control; interface MacControl; interface Send; interface RouteControl; interface Random; }}
Timer Provee un contador genérico, que puede ser usado para generar eventos a intervalos regulares.
result_t start (char type, uint32_t interval) result_t stop (void)
Events result_t fired(void)
Interfaz Descripción Comandos y Eventos.Leds Interfaz para el
manejo de los leds existentes en la plataforma telos.
result_t init (void) result_t redOn (void) result_t redOff (void) result_t redToggle (void) result_t greenOn (void) result_t greenOff (void) result_t greenToggle (void) result_t yellowOn (void) result_t yellowOff (void) result_t yellowToggle (void) uint8_t get(void) result_t set(uint8_t value)
CC2420Control
Interfaz de Control para el transceiver CC2420.
result_t TunePreset (uint8_t channel) result_t TuneManual (uint16_t freq) uint8_t GetPreset(void) uint16_t GetFrequency(void) result_t VREFOn (void) result_t VREFOff (void) result_t OscillatorOn (void) result_t OscillatorOff (void) result_t TxMode (void) result_t TxModeOnCCA (void) result_t RxMode (void) result_t SetRFPower (uint8_t power) uint8_t GetRFPower (void) result_t enableAutoAck(void) result_t disableAutoAck(void) result_t enableAddrDecode(void) result_t disableAddrDecode(void) result_t setShortAddress(uint16_t addr)
MacControl Interfaz de control de la capa Mac.
void enableAck(void) void disableAck(void)
Send Interfaz para el envio de datos del tipo TOSMsg (dato estandar para las redes de sensores que ocupan tinyos)
result_t send (TOS_MsgPtr msg, uint16_t length) void getBuffer (TOS_MsgPtr msg, uint16_t *length) Events result_t sendDone (TOS_MsgPtr msg, result_t success)
RouteControl
Interfaz Control/Monitor para la componente de enrutamiento
uint16_t getParent (void) uint8_t getDepth (void) uint16_t getSender (TOS_MsgPtr msg) uint8_t getOccupancy (void) uint8_t getQuality(void) result_t setUpdateInterval (uint16_t Interval) result_t manualUpdate (void)
Random Intergaz generadora result_t init (void)
116
de números seudoaleatorios. En la actualidad ésta, se encuentra implementada por RandomLFSR
uint16_t rand (void)
Tabla 2.3.4.4.2. Descripción de interfaces ocupadas.
22.3.4.2Subsección de Implementación:
Tabla 2.3.4.2.1 Sección Implementación.
Resulta importante destacar el tipo de dato TOS_Msg, ocupado por esta aplicación.A continuación se muestra la estructura que define el tipo de dato TOS_Msg.
117
implementation {
enum { TIMER_GETADC_COUNT = 1, // Timer ticks for ADC TIMER_CHIRP_COUNT = 10, // Timer on/off chirp count };
bool sleeping; // application command state bool focused; bool rebroadcast_adc_packet; TOS_Msg gMsgBuffer; // Tipo de dato definido en el archive AM.h (/tos/types/) norace uint16_t gSensorData; // protected by gfSendBusy flag uint32_t seqno; bool initTimer; bool gfSendBusy; int timer_rate; int timer_ticks;
typedef struct TOS_Msg{ /* The following fields are transmitted/received on the radio. */ uint16_t addr; uint8_t type; uint8_t group; uint8_t length; int8_t data[TOSH_DATA_LENGTH]; uint16_t crc;
/* The following fields are not actually transmitted or received * on the radio! They are used for internal accounting only. * The reason they are in this structure is that the AM interface * requires them to be part of the TOS_Msg that is passed to * send/receive operations. */ uint16_t strength; uint8_t ack; uint16_t time; uint8_t sendSecurityMode; uint8_t receiveSecurityMode; } TOS_Msg;
El significado de cada uno de los campos es el siguiente:
• addr : es la dirección a la que va destinado el paquete, existen ciertas direcciones especiales:
o TOS_BCAST_ADDR : Es la dirección de broadcast.
o TOS_LOCAL_ADDRESS : Es la dirección local (localhost)
o TOS_UART_ADDR : Es la dirección del puerto serie
• type, es el tipo de paquete que se esta enviando, este tipo se utiliza en las interfaces parametrizadas para determinar que instancia de la interfaz se va a hacer cargo de procesar dicho paquete.
• group: es el grupo al que pertenece el sensor que esta enviando el paquete , de manera que solo lo reciban aquellos sensores que pertenezcan al mismo grupo, de esta manera pueden coexistir dos redes
diferentes de sensores sobre el mismo medio físico aéreo y sobre el mismo canal de radio.
5. lenght: es la longitud total del paquete
6. Data: En este campo se especifican los datos que se van a enviar, estos datos pueden ser una estructura que conforme un nuevo tipo de paquete de nivel superior.
7. crc : permite la corrección de errores.
Luego viene la sección de inicialización de variables, ya que antes solamente se habían declarado, sin asignarle valor de inicio.
static void initialize() { timer_rate = INITIAL_TIMER_RATE; atomic gfSendBusy = FALSE; sleeping = FALSE; seqno = 0; initTimer = TRUE; rebroadcast_adc_packet = FALSE; focused = FALSE; }
Tabla 2.3.4.2.3 Inicialización de Variables.
Ahora se procederá a presentar los comandos que implementan la interfaz StdControl que la aplicación Surge debe proporcionar, es decir, los comandos init, start y stop.
command result_t StdControl.init() { initialize(); //Se dan los valores iniciales a las variables anteriormente definidas. return SUCCESS; }
command result_t StdControl.start() { //Se Crea una variable entera sin signo randomtimer. int16_t randomtimer; //Llamado al comando SetRFPower de la interfaz CC2420Control call CC2420Control.SetRFPower(15);
118
//Llamado a enableAck() de la Interfaz MacControl provista por la componente . call MacControl.enableAck();
//El valor del contador es asignado a partir del llamado a rand() randomtimer = (call Random.rand() & 0xfff) + 1; return call Timer.start(TIMER_ONE_SHOT, randomtimer); }
SetRFPower():
Provista por componente CC2420ControlM.nc la que recibe un valor entre 3 (potencia baja (-25dB)) a 31 (Potencia más alta (0dB)).El código que lo implementa es el siguiente:
command result_t CC2420Control.SetRFPower(uint8_t power) { gCurrentParameters[CP_TXCTRL]=(gCurrentParameters[CP_TXCTRL]&(~CC2420_TXCTRL_PAPWR_MASK)) | (power << CC2420_TXCTRL_PAPWR); call HPLChipcon.write(CC2420_TXCTRL,gCurrentParameters[CP_TXCTRL]); return SUCCESS; }
Resulta importante detenernos en el llamado al comando write, de la interfaz HPLChipcon (en realidad HPLCC2420). Este se encuentra implementado en la componente HPLCC2420M.nc La forma de utilizarlo es la siguiente: uint8_t write(uint8_t addr, uint16_t data) De esta forma se transmiten 16-bit de datos.El código que lo implementa es el siguiente:
async command uint8_t HPLCC2420.write(uint8_t addr, uint16_t data) { uint8_t status = 0;
if (call BusArbitration.getBus() == SUCCESS) { atomic f.busy = TRUE; TOSH_CLR_RADIO_CSN_PIN(); // clear the RX flag if set call USARTControl.isTxIntrPending(); call USARTControl.rx(); call USARTControl.tx(addr); while(f.enabled && !(call USARTControl.isRxIntrPending())) ; status = adjustStatusByte(call USARTControl.rx()); call USARTControl.tx((data >> 8) & 0x0FF); while(f.enabled && !(call USARTControl.isTxIntrPending())) ; call USARTControl.tx(data & 0x0FF); while(f.enabled && !(call USARTControl.isTxEmpty())) ; TOSH_SET_RADIO_CSN_PIN(); atomic f.busy = FALSE;
//Se omite seccion #if 0 dado que no se ejecutará
call BusArbitration.releaseBus(); } return status; }
EnableAck():Este comando es implementado en la componente CC2420RadioM.nc y contiene el siguiente código.
async command void MacControl.enableAck() { atomic bAckEnable = TRUE; call CC2420Control.enableAddrDecode(); call CC2420Control.enableAutoAck(); }
Como se observa la variable bAckEnable toma el valor TRUE. Luego se llaman a los comandos enableAddrDecode() y enableAutoAck() de la interfaz CC2420Control.
119
async command result_t CC2420Control.enableAddrDecode() { gCurrentParameters[CP_MDMCTRL0] |= (1 << CC2420_MDMCTRL0_ADRDECODE); return call HPLChipcon.write(CC2420_MDMCTRL0,gCurrentParameters[CP_MDMCTRL0]); }
async command result_t CC2420Control.enableAutoAck() { gCurrentParameters[CP_MDMCTRL0] |= (1 << CC2420_MDMCTRL0_AUTOACK); return call HPLChipcon.write(CC2420_MDMCTRL0,gCurrentParameters[CP_MDMCTRL0]); }
En ambos casos se procede a ocupar un llamado al comando write de la interfaz HPLChipcon, el cual genera una rutina capaz de comunicarse con el transceiver, esto es, las capas inferiores (acceso al hardware).
call Timer.start Este llamado recibe dos parámetros:
Type : El tipo de timer a iniciar; puede ser TIMER_REPEAT o TIMER_ONE_SHOT
Interval : valor en milisegundos.
Finalmente analizamos el comando stop: command result_t StdControl.stop() { return call Timer.stop(); }
Stop realiza una llamado que detiene el Timer, previniendo que se produzca su encendido otra vez.
A continuación pasamos a analizar la tarea SendData();
task void SendData() { SurgeMsg *pReading; uint16_t Len; dbg(DBG_USR1, "SurgeM: Sending sensor reading\n"); if ((pReading = (SurgeMsg *)call Send.getBuffer(&gMsgBuffer,&Len)) != NULL) { pReading->type = SURGE_TYPE_SENSORREADING; pReading->parentaddr = call RouteControl.getParent(); pReading->reading = gSensorData; pReading->seq_no = seqno++;
#ifdef MHOP_LEDS call Leds.redOn();#endif if ((call Send.send(&gMsgBuffer,sizeof(SurgeMsg))) != SUCCESS)
atomic gfSendBusy = FALSE; }
Tabla 2.3.4.2.4 Tarea SendData.
A continuación se procede a analizar el código de la aplicación.Dos variables son creadas al ejecutar esta tarea.Una de ellas es un puntero a SurgeMsg (que es un tipo de datos definido en el archivo Surge.h).La otra es una variable Len de tipo unsigned de 16 bits.
SurgeMsg *pReading; uint16_t Len;
dbg(DBG_USR1, "SurgeM: Sending sensor reading\n");
Nos encontramos por primera vez con la función dbg. En cualquier parte de la implementación se puede incluir la función dbg que tiene como misión mostrar por la salida estándar o por la interfaz gráfica de simulación, una cadena que pasada como parámetro (en este caso SurgeM: Sending sensor reading).
120
El estilo de pasar parámetros es exactamente igual al que utiliza printf para C estándar. Dbg(NIVEL_DEBUG ,cadena %i?,i);
Donde NIVEL_DEBUG es una constante que puede ser definida para poder establecer diferentes niveles de debugging.
if ((pReading = (SurgeMsg *)call Send.getBuffer(&gMsgBuffer,&Len)) != NULL) {
pReading como se vió en la sección de declaración es un puntero a una estructura de tipo SurgMsg. En esta línea la sentencia if es ejecutada si la asignación es llevada con éxito. La interfaz que se ocupa acá es Send, específicamente el comando getBuffer. Esta función la provee la componente MultiHopEngineM y se muestra a continuación.
command void *Send.getBuffer[uint8_t id](TOS_MsgPtr pMsg, uint16_t* length) { TOS_MHopMsg *pMHMsg = (TOS_MHopMsg *)pMsg->data; *length = TOSH_DATA_LENGTH - offsetof(TOS_MHopMsg,data); return (&pMHMsg->data[0]);
Como se puede observar, retorna el puntero a data[0] es decir, el inicio del buffer. Cada vez que se desee usar la interfaz Send es necesario ocupar este comando para obtener un puntero a una dirección válida de datos.
Una vez que se obtiene este puntero, podemos asignar a cada miembro de la estructura pReading los valores que deseamos tomen. Esto se muestra a continuación:
pReading->type = SURGE_TYPE_SENSORREADING; // Toma valor cero. pReading->reading = gSensorData; pReading->seq_no = seqno++;
Si nos detenemos en la siguiente asignación: pReading->parentaddr = call RouteControl.getParent();
Vemos que se realiza un llamado al comando getParent(), usado por la interfaz RouteControl e implementado por la componente MultiHopLQI El código se muestra a continuación.
command uint16_t RouteControl.getParent() { return gbCurrentParent; }
La variable gbCurrentParent se encuentra definida por el protocolo que establece dicha componente.
Luego viene la siguiente sentencia:#ifdef MHOP_LEDS call Leds.redOn();#endif
La directiva #ifdef es un condicional especializado, que sirve para comprobar si un macro-identificador está definido o no. En caso de estarlo realiza la línea de código que se encuentra entre sus campos.En este caso se realiza el llamado a la interfaz Leds, comando redON(). Esta interfaz es provista por la componente LedsC. El codigo que implementa este comando es:
async command result_t Leds.redOn() { dbg(DBG_LED, "LEDS: Red on.\n"); atomic { TOSH_CLR_RED_LED_PIN(); ledsOn |= RED_BIT; }
121
return SUCCESS; }
Algo importante de mencionar acá es que el comando está definido como asincrónico, y a su vez el acceso al hardware y la configuración se realiza de una sola vez (atomic). Esto garantiza la ejecución del comando.
if ((call Send.send(&gMsgBuffer,sizeof(SurgeMsg))) != SUCCESS)atomic gfSendBusy = FALSE; //Variable booleana
}Acá se hace el llamado al comando send de la interfaz Send que es provisto por la componente MultiHopEngineM
command result_t Send.send[uint8_t id](TOS_MsgPtr pMsg, uint16_t PayloadLen) { uint16_t usMHLength = offsetof(TOS_MHopMsg,data) + PayloadLen;
// Verificamos que el largo de la variable de offset calculada anteriormente no sea mayor que la longitud de // datos definida para la arquitectura. if (usMHLength > TOSH_DATA_LENGTH) { return FAIL; }
//Llamado al comando initializeFields el cual es call RouteSelect.initializeFields(pMsg,id);
if (call RouteSelect.selectRoute(pMsg,id, 0) != SUCCESS) { return FAIL; }
if (call SendMsg.send[id](pMsg->addr, usMHLength, pMsg) != SUCCESS) { sendFailures++; return FAIL; } return SUCCESS; }Podemos ver que es acá donde se realizan los llamados a los algoritmos de enrutamiento. A continuación se muestran los codigos de los comandos que implementan esto.command result_t RouteSelect.initializeFields(TOS_MsgPtr Msg, uint8_t id) { TOS_MHopMsg *pMHMsg = (TOS_MHopMsg *)&Msg->data[0]; pMHMsg->sourceaddr = pMHMsg->originaddr = TOS_LOCAL_ADDRESS; pMHMsg->originseqno = gCurrentSeqNo; pMHMsg->hopcount = gbCurrentHopCount; return SUCCESS; }
command result_t RouteSelect.selectRoute(TOS_MsgPtr Msg, uint8_t id, uint8_t resend) { int i; TOS_MHopMsg *pMHMsg = (TOS_MHopMsg *)&Msg->data[0]; if (pMHMsg->originaddr != TOS_LOCAL_ADDRESS && resend == 0) { for (i = 0; i < MHOP_HISTORY_SIZE; i++) { if ((gRecentPacketSender[i] == pMHMsg->sourceaddr) && (gRecentPacketSeqNo[i] == pMHMsg->seqno)) { return FAIL; }
El llamado a send de la interfaz SendMsg es clave para el envío de paquetes por la red.El código se muestra a continuación. // Comando para aceptar la transmisión de un Active Message. command result_t SendMsg.send[uint8_t id](uint16_t addr, uint8_t length, TOS_MsgPtr data) { if (!state) { state = TRUE; if (length > DATA_LENGTH) {
dbg(DBG_AM, "AM: Send length too long: %i. Fail.\n", (int)length);state = FALSE;return FAIL;
} if (!(post sendTask())) {
122
dbg(DBG_AM, "AM: post sendTask failed.\n");state = FALSE;return FAIL;
} else {
buffer = data;data->length = length;data->addr = addr;data->type = id;buffer->group = TOS_AM_GROUP;dbg(DBG_AM, "Sending message: %hx, %hhx\n\t", addr, id);dbgPacket(data);
} return SUCCESS; } return FAIL; }
El método realiza el envío de un mensaje a la dirección addr, dicho mensaje es data ( TOS_MsgPtr es un puntero a una estructura TOS_Msg que a modo informativo deberá de ser global ya que si se declara local, la duración de ese mensaje solo será hasta que la función termine y cuando esto ocurre todavía no se ha enviado el mensaje ).
123
Implementación de Eventos.
La otra parte de esta sección (implementation) corresponde a la implementación de los eventos. Para saber cuales son los eventos que podemos capturar, es necesario revisar la tabla 2.3.4.4.2. En ella se observa que son tres las interfaces que obligan a implementar eventos:
• ADC.
async event result_t ADC.dataReady(uint16_t data) { dbg(DBG_USR1, "SurgeM: Got ADC reading: 0x%x\n", data); atomic { if (!gfSendBusy) {
gfSendBusy = TRUE;gSensorData = data;post SendData();
} } return SUCCESS; }
Podemos ver que está definido como asincrónico, esto es necesario dado que el evento ocurrirá en el momento que se tenga el valor data capturado por algún puerto del conversor ADC. La zona protegida como sección atómica es para garantizar la asignación del parámetro data a la variable global gSensorData la cual es ocupada por la tarea SendData(), que es ‘posteada’ acá, para enviar el valor por la red inalámbrica.
• Timer.
event result_t Timer.fired() { if (initTimer) { initTimer = FALSE; return call Timer.start(TIMER_REPEAT, timer_rate); } dbg(DBG_USR1, "SurgeM: Timer fired\n"); timer_ticks++; if (timer_ticks % TIMER_GETADC_COUNT == 0) { call ADC.getData(); } return SUCCESS; }Cuando ocurre este evento, si la variable initTimer tiene el valor True se realiza el llamado al comando start con los parámetros mostrados.Además se agrego una línea para que muestre por pantalla en modo debug cada vez que ocurra un evento de fired.Lo más importante es el llamado a getData() de la interfaz ADC, la cual se realiza cada vez que timer_ticks sea múltiplo de la variable TIMER_GETADC_COUNT.
En general este método produce que se empiece un muestreo del valor que posee el sensor, cuando dicho muestreo se haya finalizado, se producirá el evento dataReady()
• Send
event result_t Send.sendDone(TOS_MsgPtr pMsg, result_t success) { dbg(DBG_USR2, "SurgeM: output complete 0x%x\n", success);#ifdef MHOP_LEDS call Leds.redOff();#endif atomic gfSendBusy = FALSE; return SUCCESS;
124
}}
Al capturar este evento se realizan dos cosas: • Apagar el led que se había encendido en el momento de la transmisión.• Asignar el valor False a la variable booleana gfSendBusy, la cual es
consultada cuando se quiere realizar una transmisión.
125
23 Conclusiones
En el presente trabajo se ha analizado la aplicación Surge, con el objetivo de estudiar el modelo de programación de Tinyos y específicamente el reconocimiento de las interfaces y componentes que ocupa la plataforma Telos.
La herramienta nescdoc ha sido de gran ayuda para el estudio de esta aplicación, por lo que su uso y aprendizaje es recomendable, de forma de que las futuras aplicaciones implementadas incorporen este tipo de documentación.
Para realizar cualquier aplicación es importante tener conocimiento de donde se encuentran los ficheros que definen una plataforma. Así por ejemplo para la plataforma Telos en el momento de realizar la compilación cruzada (nesc -> ANSIC) y compilar el archivo C generado, necesitará ficheros que definan las variables que indiquen configuración de puertos, inicializaciones de Timers, etc, los que por defecto vienen definidos en el directorio /tos/platform.
Se pudo observar que el nivel de abstracción es elevado, así por ejemplo para el uso del conversor ADC, no es necesario reconocer en que puerto se está trabajando ya que se encuentra definido por otras componentes las cuales son invocadas por comandos simples (getData).
Se logró el reconocimiento de primitivas claves tanto para manejo de hardware (HPL19) como para las abstracciones de capas superiores, las cuales servirán para la creación de nuestras propias aplicaciones.
19 Hardware Presentation Layer
126
24 Referencias.
[1] Documentación generada por nesC para aplicación SurgeTelos.
[2] Documento “Tutorial de Tinyos”Jose María Alcaraz Calero
[3] SourceforgePágina principal del proyecto Tinyos.
127
25 Anexos.
25.1 Anexo A.
25.1.1Makefile.
Tabla 5.1.1.1 Makefile
25.1.2README.
Tabla 5.1.2.1 Fichero README
128
PFLAGS= -I%T/../contrib/ucb/tos/lib/MultiHopLQI -DSEND_QUEUE_SIZE=8 -DMHOP_LEDS
PLATFORMS=telos telosa telosb
TINYOS_NP ?= BNPCOMPONENT=Surgeinclude ${
README for SurgeAuthor/Contact: [email protected]$Revision: 1.3 $
Description:
Surge is an example application that uses MultiHop ad-hoc routing. Itis designed to be used in conjunction with the Surge java tool. EachSurge node takes temperature readings and forwards them to a base station.The node can also respond to broadcast commands from the base.
This version of surge in contrib/ucb/SurgeTelos only supports(and has been tested on) the Telos platform. Please do not try to runthis version of Surge on any other platform. Other platforms may useSurge in tinyos-1.x/apps/Surge
Tools:
net.tinyos.surge.MainClass
This class processes sensor data from Surge programmed nodes via aGenericBase station. The java applet snoops the multihop headers toprovide a graphical view of the logical network topology. It alsopermits variation of the sample rates and sending pre-defined commandsto the surge nodes.
In tinyos-1.x/tools/java/net/tinyos/surge, you must recompile the javaclasses based on this version of Surge:
cd $TOSDIR/../tools/java/net/tinyos/surge make clean SURGE_PLATFORM=telos make
This creates classes from Surge.h and SurgeCmd.h in contrib/ucb/apps/Surgeand Multihop.h from contrib/ucb/tos/lib/MultiHopLQI.
Now you can run Surge with
java net.tinyos.surge.MainClass 0x7D
Make sure SerialForwarder is connected to Telos before running the Surge java GUI.
129
25.1.3SurgeM.nc.
130
// $Id: SurgeM.nc,v 1.5 2004/12/07 22:45:34 jpolastre Exp $
includes Surge;includes SurgeCmd;
/* * Data gather application */
module SurgeM { provides { interface StdControl; } uses { interface ADC; interface Timer; interface Leds; interface CC2420Control; interface MacControl; interface Send;// interface Receive as Bcast; interface RouteControl; interface Random; }}
implementation {
enum { TIMER_GETADC_COUNT = 1, // Timer ticks for ADC TIMER_CHIRP_COUNT = 10, // Timer on/off chirp count };
bool sleeping; // application command state bool focused; bool rebroadcast_adc_packet;
TOS_Msg gMsgBuffer; norace uint16_t gSensorData; // protected by gfSendBusy flag uint32_t seqno; bool initTimer; bool gfSendBusy;
int timer_rate; int timer_ticks; /*********************************************************************** * Initialization ***********************************************************************/ static void initialize() { timer_rate = INITIAL_TIMER_RATE; atomic gfSendBusy = FALSE; sleeping = FALSE; seqno = 0; initTimer = TRUE; rebroadcast_adc_packet = FALSE; focused = FALSE; }
task void SendData() { SurgeMsg *pReading; uint16_t Len; dbg(DBG_USR1, "SurgeM: Sending sensor reading\n"); if ((pReading = (SurgeMsg *)call Send.getBuffer(&gMsgBuffer,&Len)) != NULL) { pReading->type = SURGE_TYPE_SENSORREADING; pReading->parentaddr = call RouteControl.getParent(); pReading->reading = gSensorData; pReading->seq_no
Tabla 5.1.3.1 SurgeM.nc
131
#ifdef MHOP_LEDS call Leds.redOn();#endif if ((call Send.send(&gMsgBuffer,sizeof(SurgeMsg))) != SUCCESS)
atomic gfSendBusy = FALSE; }
}
command result_t StdControl.init() { initialize(); return SUCCESS; }
command result_t StdControl.start() { uint16_t randomtimer; call CC2420Control.SetRFPower(15); call MacControl.enableAck(); randomtimer = (call Random.rand() & 0xfff) + 1; return call Timer.start(TIMER_ONE_SHOT, randomtimer); }
command result_t StdControl.stop() { return call Timer.stop(); }
/*********************************************************************** * Commands and events ***********************************************************************/ event result_t Timer.fired() { if (initTimer) { initTimer = FALSE; return call Timer.start(TIMER_REPEAT, timer_rate); } dbg(DBG_USR1, "SurgeM: Timer fired\n"); timer_ticks++; if (timer_ticks % TIMER_GETADC_COUNT == 0) { call ADC.getData(); } return SUCCESS; } async event result_t ADC.dataReady(uint16_t data) { //SurgeMsg *pReading; //uint16_t Len; dbg(DBG_USR1, "SurgeM: Got ADC reading: 0x%x\n", data); atomic { if (!gfSendBusy) {
gfSendBusy = TRUE;gSensorData = data;post SendData();
} } return SUCCESS; }
event result_t Send.sendDone(TOS_MsgPtr pMsg, result_t success) { dbg(DBG_USR2, "SurgeM: output complete 0x%x\n", success);#ifdef MHOP_LEDS call Leds.redOff();#endif atomic gfSendBusy = FALSE; return SUCCESS; }}
25.2 Anexo B.
25.2.1Detalles del lenguaje.
25.2.1.1Definición de tipos (typedef).typedef se puede usar para definir nuevos nombres de datos explícitamente, usando algunos de los tipos de datos de C, donde su formato es:
typedef <tipo> <nombre>;
Se puede usar typedef para crear nombres para tipos más complejos, como una estructura, siendo este el caso ocupado por nuestro programa. A continuación mostramos un ejemplo:
typedef struct direc{ char nombre[30]; char calle[40]; char ciudad[20]; char estado[3]; unsigned int codigo;} sdirec;
sdirec info_direc={"Vicente Fernandez","Fantasia 2000","Dorado","MMX",12345};
En este caso direc sirve como una etiqueta a la estructura y es opcional, ya que ha sido definido un nuevo tipo de dato, por lo que la etiqueta no tiene mucho uso, en donde sdirec es el nuevo tipo de datos e info_direc es una variable del tipo sdirec, la cual es una estructura.
25.2.1.2Enumeraciones.Una enumeración es un conjunto de constantes enteras con nombre y especifica todos los valores legales que puede tener una variable del tipo enum.La forma como se define una enumeración es similar a como se hace con las estructuras, usando la palabra clave enum para el comienzo de un tipo de enumeración.
Su formato es: enum nombre_enum { lista_de_enumeración } lista_de_variables;
Es opcional nombre_enum y lista_de_variables. La primera se usa para declarar las variables de su tipo.
25.2.1.3Uniones.
Una union es una variable que podría guardar (en momentos diferentes) objetos de diferentes tamaños y tipos. Así por ejemplo tenemos:
union numero{ uint32_t numeroentero uint16_t numerocorto; } un_numero;
Acá se define una unión llamada numero y una instancia de esta llamada un_numero. numero es la etiqueta de la unión y tiene el mismo comportamiento que la etiqueta en la estructura.
132
Cuando el compilador de NesC esta reservando memoria para las uniones, siempre creará una variable lo suficientemente grande para que quepa el tipo de variable más largo de la unión. Con la finalidad de que el programa pueda llevar el registro del tipo de variable unión usada en un momento dado, es común tener una estructura (con una unión anidada) y una variable que indica el tipo.
133