2. Antecedentesbibing.us.es/proyectos/abreproy/12099/fichero/Memoria%2FCapitulo_2.pdf · 2. Antecedentes 2.1. RedesdeSensoresInalámbricos 2.1.1. Quéesunareddesensoresinalámbricos

2. Antecedentes

2.1. Redes de Sensores Inalámbricos

2.1.1. Qué es una red de sensores inalámbricos

Una red de sensores inalámbricos (en inglés Wireless Sensor Network, WSN),es una red formada por un conjunto de dispositivos que se distribuyen espacialmente,y que acceden al mundo exterior a través de una serie de sensores que les dotan dela capacidad de medir algun parámetro físico como puede ser la temperatura, la luz,la humedad, etc. y realizar algún tipo de tratamiento posterior. Estos dispositivos seles conoce por el nombre de “mote”, el cual procede de la traducción de la palabrainglesa “mota de polvo”, en clara alusión a dos de sus características fundamentales:reducido tamaño y que pueden estar ubicados en cualquier lugar. En la sección 2.1.5se analizarán con más detenimiento éstos y otros conceptos que conforman la basede esta tecnología.

2.1.2. Elementos de una WSN

Figura 2.1.: Elementos de una WSN

En la figura 2.1 se puede ver la estructura típica de una WSN con trescomponentes diferenciados [1]:

5

Capítulo 2 Antecedentes

Nodo Sensor: Formado por la mota propiamente (microcontrolador + radio)más una serie de sensores. Los sensores captan distinta información del medio,como puede ser temperatura, humedad, ruido, etc. y la mota recoge estos datosy los envía a la estación base.Gateway: Es la pasarela de comunicaciones entre la WSN y el exterior.Asimismo, es posible que actúe de reprogramador de los nodos sensores.Estación Base: Es un dispositivo con mayor capacidad de almacenamientoen el que se lleva a cabo el análisis y procesado de los datos que los nodos hanenviado.

2.1.3. Componentes de una mota

Los dispositivos son unidades autónomas y, como se puede observar en la figura2.2, están formados por un microcontrolador, una fuente de energía (en la mayoríade los casos es una simple batería) un transceptor radio y uno o varios sensores [2].Opcionalmente, existe la posibilidad de ampliar la memoria de la que dispone elmicrocontrolador mediante una memoria externa.

Figura 2.2.: Estructura de una mota

SensoresUn sensor es un elemento sensible a diversos agentes que capta información

y la transforma en una señal eléctrica, que será procesada por el sistema del queforma parte y le permita a éste último actuar de forma adecuada sobre su entorno.Existen multitud de sensores, como pueden ser sensores de luz, de temperatura, depresión barométrica, de humedad, de sonido...

TransceptorEn cada nodo, se sitúa un pequeño chip radio que dota a la mota de la

capacidad para transmitir información a otros nodos de manera inalámbrica. Utilizael protocolo Zigbee para realizar esta labor.

MicrocontroladorEs una pequeña CPU, con poca capacidad de procesamiento, de bajo coste y

autosuficiente que se utiliza para controlar la funcionalidad de la red y el flujo dedatos entre los dispositivos para almacenar y/o procesar datos. Será, por tanto, el

6

2.1 Redes de Sensores Inalámbricos

encargado de procesar la información que le envíen los sensores y ejecutar las tareascorrespondientes para el buen funcionamiento del nodo.

Memoria externa (opcional)

Dota a la mota de mayor capacidad de almacenamiento. Es externa almicrocontrolador, de tipo flash EEPROM (no volátil) y con un tamaño de 512Kb usualmente. Su uso principal es para la reprogramación del microcontrolador.

Fuente de energía

Generalmente es una simple pila (tipo AA, AAA o de botón) debido a que elconsumo de todos los elementos es muy reducido.

2.1.4. Tipos de motas comerciales

En la figura 2.3 se muestran varios tipos de motas comerciales, en concreto, MicaZ,Tmote Sky y AvrZigbit.

Figura 2.3.: Motas MicaZ, Tmote Sky y AvrZigbit

En la Figura 2.4 se puede observar una tabla con los tipos de motas másdestacadas y sus características más importantes [3], con objeto de que el lectorse haga una idea general de la sencillez de este tipo de dispositivos y conozca susparámetros más importantes. En el capítulo 3 se describirá con más detenimiento lamota objeto de este proyecto: AvrZigbit.

7


Figura 2.4.: Tipos de motas comerciales

2.1.5. Características de las WSN

A continuación se describen las principales características de este tipo de redes:Reducido consumo. Como los nodos se alimentan mediante una simple batería,uno de los objetivos en el diseño de las motas es minimizar al máximo elconsumo de energía. Como se puede observar en la figura 2.5, la mayor partedel tiempo el sistema se encuentra en un estado que podríamos denominar“dormido”, donde se reduce drásticamente el gasto energético (del ordende microAmperios). Solo cuando se necesita transmitir o recibir datos, se“despierta” y se lleva al estado activo. Aquí sí se produce un consumomayor (del orden de los miliAmperios). Con esta técnica se logra aumentarla autonomía del dispositivo.

Figura 2.5.: Evolución del estado de una mota

8

2.1 Redes de Sensores Inalámbricos

Menor coste. Es otra de las características más importantes de las WSN. Elprecio de las motas es reducido (por ejemplo, el precio del encapsulado ZDM-A1281-PN/PN0 ronda los 20 €), así como también su instalación, ya que alrealizarse la transmisión de forma inalámbrica, no es necesario instalar uncableado como en las redes tradicionales.Tamaño. Reducidas dimensiones que hacen factible la ubicación en cualquierpunto de los nodos. Por dar algún dato, comentar que AvrZigbit en la versióndel encapsulado ZDM-A1281-PN/PN0, por ejemplo, tiene unas dimensionesde 38 x 13.5 x 2 (mm).Funcionamiento autónomo. Cada mota es independiente del resto y no seencuentra supeditada a ningún sistema controlador que le indique qué haceren cada momento.Mantenimiento bajo. El período entre sucesivos cambios de batería puede serdel orden de meses a años.Autoorganización como red Ad-hoc. Los nodos se organizarán dentro de redesmalladas y no es necesario ningún elemento coordinador. Lo que sí existe loque se conoce como nodo recolector que realiza la recolección de la informaciónque mandan el resto de dispositivos y la retransmite de manera inalámbrica omediante otros medios hacia un punto central de tratamiento de la misma.Capacidad de procesamiento distribuido. Debido básicamente a la restricciónde consumo. En cada dispositivo se realizará un procesado de la informacióncon objeto de que se tenga que transmitir el menor número posible de bits.Autorrestauración. Si un nodo falla, la red reencaminará los datos por otroscaminos.Fiabilidad. Es un sistema robusto y seguro.

Pero no todo son ventajas, estas redes también presentan algunos problemas:Cobertura limitada. Máximo unos 100 metros.Severas restricciones de energía. A la vez que el reducido consumo de potenciaes una ventaja, también representa un problema, debido a que, por ejemplo,se debe tener muy en cuenta al realizar aplicaciones para los nodos.Pequeña capacidad de almacenamiento y procesamiento.Nodos autónomos y desatendidos.

2.1.6. Aplicaciones de las WSN

El campo de aplicación de las redes de sensores inalámbricos es muy amplioy cada día que pasa aún mayor, gracias a su gran versatilidad. Para que el lectortenga una idea de dónde se pueden utilizar, se pueden destacar las siguientes [2]:

9


Domótica y automatización de edificios

• Detección de incendios, fugas de agua o gas.• Control de la iluminación, de la climatización, etc.• Aspectos relacionados con la seguridad, como pueden ser el control de

accesos a viviendas.• Sensorización general de edificios inteligentes.

Control industrial

• Control de procesos.• Alarmas y monitorización.• Medio ambiente.• Gestión de energía.• Gestión de recursos.

Agricultura

• Medidas de humedad, temperatura, PH, etc. proporcionándoles datos alos agricultores para la mejora en la producción.

• Control de regadíos (acarreando un importante ahorro de agua).• Control de plagas.

Medicina

• Monitorización de pacientes (temperatura, ritmo cardíaco, tensiónarterial...) tanto en ambientes hospitalarios como a distancia.

• Monitorización de la forma física.

Ciencia

• Estudio de sismicidad y vulcanismo.• Monitorización del medio ambiente y del tiempo atmosférico, análisis de

factores de riesgo ambientales en determinadas zonas como pueden sercauces de ríos, zonas de cultivo, etc.

• Observación de ecosistemas y microclimas.

Otros

• Electrónica de consumo.• Periféricos de PC.• Control del tráfico.• Control continuo o puntual de entornos peligrosos, como pueden ser

centrales nucleares o industrias que trabajen con productos peligrosos.

10

2.2 Sistemas Operativos para WSN

2.2. Sistemas Operativos para WSN

Como ya se introdujo en el apartado 2.1.3, las motas que forman las redes desensores están compuestas por un microcontrolador, que es quien gobierna todoslos dispositivos de la plataforma. No tienen gran capacidad de procesado, pero soncapaces de ejecutar tareas que requieren acceder a los otros elementos hardware(como pueden ser los sensores, el chip radio, etc). Por todo ello, se hace muyconveniente el uso de un sistema operativo de propósito general que permita unagestión más apropiada del hardware y, a la vez, facilite el trabajo a los desarrolladoresde aplicaciones de más alto nivel.

Las características principales que deben cumplir los sistemas operativos paraeste tipo de dispositivos son las siguientes [4]:

Deben ser diseñados teniendo en cuenta las fuertes restricciones, en cuanto arecursos se refiere, que tienen las motas (poca memoria, poca capacidad deprocesamiento del microcontrolador, etc).

Es el responsable de gestionar el microcontrolador (por lo general serámonotarea), el tiempo (relacionado con temporizadores) y la concurrencia.

Manipular el resto de dispositivos hardware que componen la plataformay ofrecer API’s para el acceso a los mismos y facilitar así el desarrollo deaplicaciones.

Debe permitir la creación de aplicaciones.

Presentar una interfaz con la que sea posible cargar e instalar nuevo código enel microcontrolador.

Gestión eficiente de energía, ya que el consumo debe ser el mínimo posiblepara aumentar la vida útil del nodo.

Debe ser multiplataforma, soportando así un conjunto de distintas plataformashardware.

Presentar una arquitectura monolítica, en la que cuando una aplicación secompila, se crea una imagen indivisible compuesta por el propio S.O. y laaplicación que será cargada en la mota.

Tamaños reducidos al compilar las aplicaciones (típicamente del orden de ~4-10 Kb de RAM y ~128 Kb de ROM).

Proporcionan interfaces de alto nivel y usan la interfaz de bajo nivel paraacceder al hardware.

Incluyen implementaciones ya integradas para la gestión de red (protocolos deenrutamiento, capa MAC, etc.), memoria flash (sistema de ficheros propio),temporizadores (basados en software), etc.

11


Dentro de los sistemas operativos, se pueden encontrar dos modelos deejecución bastante diferenciados: el modelo basado en eventos y el modelo basadoen threads.

El primero de ellos se basa en que la ejecución del programa, así como suestructura, están determinados por los sucesos que ocurren en el sistema. Estossucesos pueden estar definidos por el usuario u originados por ellos mismos. Sedeben especificar los eventos que un programa tratará, además de una manejadorpara cada evento, que se encargará de realizar las acciones apropiadas cuando seproduzca éste. En este tipo de programación, cuando arranca el programa se ejecutaun código inicial, pasando después a un estado de bloqueo en el que se espera a quesuceda un evento. Cuando se produce, el manejador del evento ejecuta el códigocorrespondiente. Si se tiene una visión global de lo que sucede, podemos describireste proceso como una máquina de estados en la que la aparición de un evento fuerzaal cambio desde un estado inicial a otro distinto. Como ventajas de este modelo sepueden destacar que solo necesita de una única pila para el cambio de contexto, esmás eficiente en cuanto a recursos utilizados y es asíncrono. Pero también presentauna serie de inconvenientes, entre los que se encuentran que no sigue un flujo deejecución lineal, sino que sigue una máquina de estados. Tampoco la depuración deaplicaciones es sencilla debido precisamente a lo anterior.

El segundo modelo se basa en el concepto de hilos. Permite a una aplicaciónrealizar una serie de tareas concurrentemente. Aquí sí se produce una ejecución linealdel codigo, que permite seguir mejor el flujo del programa que se está ejecutandoen un momento dado. Su ejecución es síncrona y bloqueante. Como punto negativodestacar que utiliza una pila por hilo, lo que conlleva un consumo más alto derecursos.En la figura 2.6 se puede observar una comparativa gráfica entre los dos modelos.

Figura 2.6.: Modelo de ejecución basado en eventos y basado en hilos

2.2.1. TinyOS

Se creó en 2002 en la Universidad de Berkeley y fue el primer sistema operativodesarrollado para redes de sensores. Sus principales características son [4]:

12

2.2 Sistemas Operativos para WSN

Es un sistema operativo de código libre, lo que permite a cualquier individuoque colabore y ayude a mejorarlo.

Inicialmente se implementó en C, pero poco después se reimplementóen nesC, que es un lenguaje de programación derivado de C y que sebasa en componentes. Estos componentes separan la implementación de laconfiguración.

Basado en eventos con algunas modificaciones: Los eventos no se puedenencolar y si un evento se interrumpe, éste se pierde.

Se usan 2 niveles de planificación: Eventos, que son funciones con una prioridadalta y tareas, las cuales son funciones cuya prioridad es más baja.

El tamaño del código ejecutable del programa puede hacer uso de unos 250bytes de ROM y 16 bytes de RAM.

Es multiplataforma, aunque no soporta todas los tipos de sensores que existen.

2.2.2. TinyOS 2.x

Nace a partir de un proyecto común de varias universidades en 2006.Busca conseguir una mayor portabilidad, hacer más fácil el desarrollo de nuevasaplicaciones y ganar en fiabilidad.

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

Hardware Independent Layer (HIL).

Hardware Adaptation Layer (HAL).

Hardware Presentation Layer (HPL).

Cabe destacar las siguientes características:

Implementación de múltiples hilos (TosThreads): En él se conjugan el modelode programación de hilos y el modelo de ejecución basado en eventos.

Incluye un planificador de tareas que es una FIFO capaz de almacenar hasta255 (en TinyOS 1, solo eran posibles 8 tareas).

Se ha mejorado la secuencia de arranque e inicialización.

Se gestiona el consumo de energía de los nodos de manera más eficiente,llevándolos a estados donde se reduce el gasto energético.

Son incompatibles las versiones TinyOS 1.x y TinyOS 2.x.

13


2.2.3. Mantis

MultimodAlNetworked of In-situ Sensors (Mantis). Nace en 2003 de la manode la Universidad de Colorado. Se trata de un sistema operativo que se encuentraimplementado completamente en C y que se basa en llamadas POSIX, lo cual hacemás sencilla la programación.Características [4]:

Multihilo: Consiste en un planificador que se basa en prioridades.Soporta las plataformas Mica2, MicaZ y Telos.El tamaño del código ejecutable del programa suele rondar los 500 bytes deRAM y 14 Kb de ROM.Los procesos largos no bloquean el sistema.Usa un modelo de programación más sencillo que el modelo basado en eventos.Como inconvenientes derivados del modelo multihilo, se produce sobrecargadebido a los intercambios de contexto entre diferentes hilos y hay un aumentosignificativo del consumo de memoria ya que existen múltiples pilas asociadascada una a un thread.

2.3. Sistema operativo Contiki

2.3.1. Introducción

Como hemos visto en la sección 2.1 y más resumido en la tabla de la figura 2.4,los nodos en las WSN están fuertemente condicionados tanto en tamaño (limitan lacomplejidad que pueden tener implementada), como en suministro de energía (ya seha comentado el especial incapié en el ahorro energético para prolongar la autonomíade la mota), pero fundamentalmente lo están en el hardware que lo forma. Por unaparte, suelen llevar un microcontrolador de 8 bits, el cual no tiene una potenciaexcesiva como puedan tener otros tipos de micros actuales y, evidentemente, noes capaz de realizar todas las tareas y operaciones que puedan estos últimos; porotra, y es aquí donde realmente existe una gran restricción, sus escasos recursos dealmacenamiento. Habitualmente estos dispositivos tienen unos 100 Kb de memoriaflash para almacenamiento de los programas y menos de 20 Kb de RAM. Éstolimita las aplicaciones que podemos diseñar y cargar en ellos. El desafío de losdiseñadores de sistemas operativos para estos dispositivos es encontrar mecanismoslo suficientemente livianos (computacionalmente hablando) que proporcionen unapotencia suficiente al ejecutar este entorno a la vez que cumple con las limitacionesde las motas. Con el fin de paliar esta situación, han surgido varios SO que cumplenestas condiciones. En la sección anterior ya se presentaron dos de los sistemasoperativos para WSN más utilizados actualmente: Tinyos y Mantis. A continuación,

14

2.3 Sistema operativo Contiki

se presentará y describirá más en profundidad, el que se utiliza en este proyecto,Contiki [5].

2.3.2. Características básicas de Contiki

Contiki fue uno de los primeros sistemas operativos que se diseñó en códigoabierto para redes de sensores inalámbricos y otros tipos de sistemas embebidosque se pueden interconectar en red. Su autor es Adam Dunkels, del Instituto Suecode Ciencia de la Computación. Como ya se ha comentado, la versión 1.0 se lanzóen Marzo de 2003 y actualmente va por la versión 2.5. Utiliza una licencia BSD yel lenguaje en el que está implementado por completo es C. En su desarrollo hanparticipado empresas tan importantes como Cisco, Atmel, SAP, etc. Ha sido portadocon éxito a una gran variedad de plataformas, desde microcontroladores embebidoscomo pueden ser MSP430 o AVR, a viejos ordenadores domésticos. El tamaño delcódigo suele ser del orden de los kilobytes y el uso de la memoria de unos cuantosbytes si se desea. A modo de anécdota, podemos enumerar una serie de antiguosaparatos en los que se ha conseguido hacer funcionar Contiki:

Familia Atari de 8 bits.Commodore 64.Videoconsola Sega Dreamcast.Sony Playstation.Sistemas Unix (y similares) sobre x86, funcionando sobre GTK+ al igual quedirectamente usando el sistema X Window.etc.Entre los distintos tipos de plataformas usadas habitualmente como sensores

inalámbricos y en los que Contiki trabaja correctamente, podemos destacar lassiguientes:

Tmote Sky.TelosB.MicaZ.ESB.Atmel Raven.Atmel Zigbit.Contiki proporciona carga, descarga y enlazado dinámico de programas y

servicios. Su kernel está basado en eventos, aunque se puede usar la multitareapreferente opcional solo con añadir librerías opcionales a los programas que asílo requieran. Utiliza una nueva técnica de programación llamada protohilos, que

15


hacen posible que el código sea más lineal en sistemas orientados a eventos. Parala comunicación, integra dos pilas: Rime y uIP. Rime es una pila sencilla que hacefactible la comunicación radio de baja potencia mediante el uso de una serie defunciones que integra. uIP dota al sistema de una completa funcionalidad TCP/IP.

2.3.2.1. Arquitectura del sistema

El sistema en sí está formado por dos partes: el núcleo (core) y los programascargados, como podemos observar en la figura 2.7 [6].

El core se compone del kernel, del cargador de programas, una serie de libreríasbásicas y una pila para la comunicación que integra todas las funciones y drivershardware necesarios para llevar a cabo tal fin. El core se compila y almacena enlos nodos, en tanto que la aplicación se carga en el sistema mediante el cargadorantes mencionado. Ésto lo puede hacer usando la pila de comunicaciones o bienconectándose a un dispositivo externo (tal como una memoria EEPROM) quecontenga el archivo binario.

Figura 2.7.: Estructura del núcleo de Contiki

Así cuando se ejecuta Contiki, éste se compondrá del kernel, librerías, elcargador de programas y un conjunto de procesos (o bien un programa de aplicacióno bien un servicio, éste último se verá en un apartado posterior).

2.3.2.2. El Kernel de Contiki

El kernel de Contiki [6] es un planificador de eventos, permitiendo la carga,descarga y enlazado dinámico de programas y servicios. Enviará eventos para invocarla ejecución de procesos que periódicamente llamarán a manejadores de eventos paraque gestionen dicha incidencia. Un proceso se iniciará o se reanudará si le llega unevento procedente del kernel o si mediante un sondeo detecta cualquier incidencia.

16


Una vez que se encola un evento, ya no podrá ser reemplazado por el kernel y,además, los manejadores de tales eventos no se podrán detener antes de que hayanterminado de ejecutarse. Esta solución encaja perfectamente para aquellos entornosque no pueden implementar un modelo de multitarea completo, debido a sus escasosrecursos, como es el caso de los sensores inalámbricos. En el modelo clásico demultitarea, cada hilo tiene su propia pila de un tamaño desconocido, hecho por elcual, como se ha comentado, lo haría inviable en este tipo de sistemas. En cambio,en el modelo basado en eventos, varios procesos se encuentran compartiendo unamisma pila, lo que lo hace más recomendable para este caso. Aún así, se permite lamultitarea preferente opcional, basada en el uso de librerías que se pueden enlazarsolamente con programas que requieran explícitamente de la multitarea.

En Contiki hay dos tipos de eventos: síncronos y asíncronos. La diferenciaentre ambos radica en que mientras que los asíncronos se encolan por el kernel yse procesarán más tarde, los síncronos causan la planificación del proceso objetivoinmediatamente. Hasta que no termina su tratamiento, no se devuelve el control alllamante.

Contiki también proporciona otra forma de comunicación entre procesos: elsondeo. Este mecanismo se puede ver como eventos de alta prioridad que se planificanentre otros eventos asíncronos y luego se llaman según su orden de preferencia. Estaforma de actuar se utiliza por aquellos procesos que trabajan cercanos al hardware,buscando cambios en el estado de dichos dispositivos.

La planificación de los eventos se lleva a cabo a un único nivel y no es posibleque se puedan reemplazar unos a otros. Podría acarrear un problema de concurrenciaen el planificador de eventos si los manejadores de las interrupciones pudiesen posteareventos, por lo cual no está permitido. En su lugar, solo pueden ser sustituidos porinterrupciones (hardware o software) que no deshabilitan nunca por el S.O. ya queson necesarias para hacer posible la ejecución de programas en tiempo real.

Contiki usa una única pila de memoria que se comparte por todos los procesosque están siendo ejecutados en un instante de tiempo. Este concepto se desarrollaráen la subsección 2.3.2.4.

La carga de programas se realiza mediante el uso de una función especial derelocalización en tiempo de ejecución y de información contenida en el archivo binarioa cargar. Al iniciarse la carga, el cargador intenta asignar la memoria necesaria paraalojar al programa basándose en la información anterior. Si ocurre algún fallo por elque no se pueda hacer la reserva, se aborta el proceso. Si todo va correctamente, elcargador llamará a la función de inicialización del programa que creará los procesosnecesarios y empezará a ejecutar instrucciones.

2.3.2.3. Servicios

Un servicio en Contiki se define como un proceso que proporciona funcionali-dades a otros procesos [6]. Una forma intuitiva de verlos es como si se trataran de

17


una librería compartida. Los servicios pueden ser dinámicamente reemplazados enejecución y además se enlazan dinámicamente. Las pilas de protocolos de comuni-cación, los drivers y aplicaciones de los dispositivos sensores, etc, son ejemplos deservicios.

Figura 2.8.: Una función haciendo uso de un servicio

Este tipo de procesos se manejan por una capa especial llamada capa deservicio, que está situada justo debajo del kernel. Esta capa guarda información dequé servicios se están ejecutando y se puede utilizar para saber cuáles se encuentraninstalados y poder gestionarlos. Los servicios se identifican mediante una cadenade texto que contiene una pequeña descripción del mismo. Así, cuando la capa deservicio busca un servicio determinado, solo tiene que hacer una comparación entreel nombre del que busca y los que hay instalados.

Un servicio consiste en un proceso que lleva a cabo su implementación y unatabla de punteros a funciones que se llaman dependiendo de la situación concretaen que nos encontremos.

Cuando una aplicación necesita llamar a un servicio, lo hace mediante unainterfaz de stub. Dicho interfaz se enlaza con la aplicación y usa la capa de serviciopara hallar el proceso del servicio. Una vez se encuentra, se guarda su identificador deproceso para que se pueda usar en próximas consultas evitando tener que repetir labúsqueda. Se ha de comentar que todo este proceso es transparente para el programaque necesita ese servicio. Este proceso se muestra en la figura 2.8.

Un servicio, como todos los procesos en Contiki, puede ser reemplazado entiempo real. Como el servicio está identificado por el ID del proceso, si el procesodel servicio se reemplaza por otro nuevo, éste deberá conservar el ID previo para nocausar problemas. Esto se logra mediante un mecanismo especial que implementa elkernel.

18


2.3.2.4. Protothreads

En los sistemas tales como Contiki en los que el kernel está basado en eventos(la gran mayoría que se utilizan para WSN actualmente), la abstracción “bloqueen espera” no se soporta. Esto se debe a que cuando se produce un cierto eventoque provoca una llamada a su manejador, éste se ejecuta hasta que termina decompletarse. Por ello, cuando se desea programar un sistema de estas características,habrá que utilizar una máquina de estados que implemente el flujo de control parala lógica de alto nivel, ya que no puede ser expresado como un simple manejador deun evento. Pero esta aproximación hace que el manejo de eventos sea lento y difícilde seguir y depurar para los desarrolladores. Por ello hay que buscar solucionesalternativas que resuelvan estos inconvenientes.

Para el caso particular de Contiki, los procesos se implementan mediante unmecanismo de programación llamado “Protohilos” [7]. Un protohilo es un tipo dehilo extremadamente ligero (en cuanto a recursos) y que no necesita una pila, queha sido diseñado para sistemas embebidos en los que la memoria es escasa, comolos sensores inalámbricos y que permite la ejecución del código de forma lineal. Aparte de Contiki, esta técnica se utiliza en otros sistemas y entornos, por ejemplo:sensores inalámbricos, módulo de decodificación MPEG para receptor de TV porInternet, o en dispositivos de carga acoplada (como los que se usan en escáneres ycámaras digitales). Asimismo, esta abstracción ha sido portada a otros lenguajes deprogramación como C++ y Objective C.

Los protohilos proporcionan una operación de espera bloqueante condicionalque ayuda a reducir la necesidad de máquinas de estados y no producen la sobrecargaque introduce el multihilo convencional. Como se ha comentado, cada protohilo norequiere de una pila donde almacenar las variables actuales, etc. como los hilostradicionales. Compartirán una sola entre todos y para llevar a cabo un cambio decontexto entre protohilos solo hay que hacer un “rebobinado” de la misma. Estorepresenta la principal ventaja de esta técnica debido a que, dependiendo de laarquitectura del sistema, un protohilo solo puede necesitar entre dos y doce bytes dememoria, lo cual, como se puede apreciar, es un gran ahorro en recursos, que es unfactor muy importante para los dispositivos embebidos. Pero, a su vez, esto tambiénrepresenta un problema, ya que las variables locales no conservan su valor despuésde que el protohilo se bloquea.

Un protohilo se ejecuta dentro de una función en C. Dentro de él se puedenhacer llamadas a otras funciones, pero no se pueden ejecutar operaciones bloqueantesdentro de ellas. En su lugar, habría que crear otro protohilo independiente que seencargara de hacerlo.

También hacer notar que es un mecanismo muy simple que puede ser codificadoen C sin depender del código máquina específico de la arquitectura. El uso de losprotohilos reduce considerablemente las líneas de código, el número de máquinas de

19


estados explícitas y el número de transiciones entre estados1.

Implementación

Un resumen de su implementación se muestra a continuación:

Para implementar en Contiki los protohilos, se hace uso de una serie defunciones y macros que describen la funcionalidad básica de este mecanismo. Elcódigo fuente y más información puede ser encontrada en el manual de referenciade Contiki2.

Con la sentencia PT_INIT se inicializa un protohilo. Esto se debe hacerantes de comenzar su ejecución. Todo protohilo tiene un punto de comienzo yun punto final, declarados mediante PT_BEGIN y PT_END respectivamente.Marcan su entorno y todas las acciones que se quieran incluir deben de estar entreambos puntos. Para realizar la operación de espera bloqueante tenemos la sentenciaPT_WAIT, que viene dada en tres formatos diferentes: PT_WAIT_UNTIL,PT_WAIT_WHILE y PT_WAIT_THREAD. Todas bloquean al protohilo:la primera hasta que se da una cierta condición, la segunda mientras se verifiqueotra y la última esperando a que un protohilo hijo termine de ejecutarse. Si lacondición es verdadera la primera vez que se alcanza la condición bloqueante, secontinúa la ejecución normal sin ninguna interrupción. En cambio, si no lo es,se verificará cada vez que se llame al protohilo. También es posible bloquear unprotohilo incondicionalmente mediante PT_YIELD.

Para crear un protohilo hijo, se puede usar PT_SPAWN, que bloquearáal protohilo que hace esta llamada hasta que se cree al hijo. Su principal uso estener una serie de llamadas de funciones jerárquicamente organizadas con bloqueosrequeridos. Con PT_SCHEDULE podemos establecer un contador que nos digacuando se llama un protohilo.

En las siguientes líneas de código se muestra un ejemplo de implementación deun protohilo. Representa el ciclo de funcionamiento de un dispositivo radio genérico.Como se ha comentado anteriormente, las sentencias PT_BEGIN y PT_ENDmarcan el inicio y el fin, respectivamente, del protohilo. El normal funcionamientodel radio implica, primeramente, su activación (radio_on()) y que permanezca eneste estado un tiempo determinado (t_awake). Es en este momento cuando seintroduce una sentencia de espera bloqueante condicional, PT_WAIT_UNTIL,para aguardar a que se cumpla dicho período de tiempo. Una vez ha expiradoel temporizador, se crea uno nuevo para indicar el tiempo total en el que debe

1Adam Dunkels. Protothreads: Simplifying Event-Driven Programming of Memory-ConstrainedEmbedded Systems

2http://www.sics.se/~bg/telos/contiki-2.x-snap11.pdf

20


estar en reposo (t_sleep). Antes de proceder a desactivar la radio, se compruebasi ha finalizado la comunicación. En caso afirmativo, se pone en reposo la radio(radio_off()) y se produce otra espera bloqueante condicional que bloquea laejecución hasta que se cumpla con el tiempo t_sleep. En caso negativo, hay queaguardar un tiempo extra (t_wait_max) para que finalice dicha comunicación. Paraello, se introduce otra espera bloqueante condicional de la que no se saldrá hastaque, o bien termine la comunicación, o bien que se agote el tiempo asignado paraello (t_wait_max).

int protothread(struct pt *pt) {

PT_BEGIN(pt);while (1) {

radio_on();timer = t_awake;PT_WAIT_UNTIL(pt, expired(timer));timer = t_sleep;if (!comm_complete()) {

wait_timer = t_wait_max;PT_WAIT_UNTIL(pt, comm_complete()|| expired(wait_timer));

}radio_off();PT_WAIT_UNTIL(pt, expired(timer));

}PT_END(pt);

}

Un protohilo consiste en una función y una continuación local situados antesde una sentencia de bloqueo. Una continuación local es un mecanismo de bajo nivelque implementan los protohilos. Es similar a una continuación ordinaria, solo queno se captura la pila de programa. Solo se captura el estado de ejecución dentro deuna función (esto es, el punto en la función donde el programa está siendo ejecutadoy los valores de las variables locales). Cuando el protohilo se invoca de nuevo, lacontinuación local vuelve a reanudarse y, o se chequea la condición bloqueante o sereanuda normalmente la función del protohilo desde ese punto.

En definitiva, los protohilos son una mezcla entre eventos e hilos que permitenque los programas puedan ser escritos de manera secuencial sin tener que diseñarmáquinas de estados explícitas como ocurre en el caso de la programación orientadaa eventos. Asímismo podemos hacer uso de las estructuras de control de flujo típicasde C como bucles while y sentencias if. Por último, suponen un ahorro de memoria

21


considerable al compartir una sola pila en contraposición a los hilos típicos quenecesitan una cada uno.Procesos y protohilos

Un proceso en Contiki se implementa mediante un protohilo que se ejecutaen la cima del kernel del sistema operativo. Será invocado cuando se produzca unevento que haya que procesar (por ej. un temporizador, un paquete entrante...).Como se ha dicho, gracias a los protohilos, es posible codificar procesos que puedanser bloqueados y se mantengan a la espera de que se produzcan nuevos eventos.

2.3.2.5. Soporte para la comunicación

La comunicación en Contiki se implementa mediante un servicio, lo quepermitirá cargar simultáneamente múltiples pilas de comunicación a fin de, porejemplo, realizar una comparación entre distintos tipos de protocolos.

Actualmente existen 2 pilas de comunicación en Contiki: uIP [8] y Rime[9]. La primera de ellas, uIP, es una pila que cumple el estándar TCP/IP confuncionalidades reducidas y que permite al sistema operativo comunicarse a travésde Internet. Rime, en cambio, es una pila más ligera con una serie de primitivasque sirven para llevar a cabo una serie de funcionalidades como posteriormente seexpondrá.

Como se puede observar en la figura 2.9, las aplicaciones pueden utilizar unade las dos pilas, ambas o ninguna incluso. Tanto uIP como Rime pueden hacer usouna de la otra.

Figura 2.9.: uIP y Rime

RimeEsta es una pila de comunicación multicapa que está específicamente diseñada

para redes de sensores. Está constituida por una serie de capas como se puede veren la figura 2.10. Estas capas son muy ligeras (estamos hablando desde los 100 bytesde ibc hasta los 226 bytes de suc y ruc), añaden unas cabeceras muy pequeñas y

22


proporcionan una funcionalidad sencilla, destinada a realizar una tarea concreta. Portanto, para implementar protocolos más complejos, habrá que aglutinar un conjuntode ellas.

Figura 2.10.: Pila de comunicación Rime

Como punto de partida hay que indicar que cualquier comunicación en Rimeestá identificada mediante un canal de 16 bits. Los nodos que se quieren comunicardeben ponerse de acuerdo en los módulos que van usar sobre un determinado canal.Los canales menores a 128 están reservados por el sistema.

La capa inferior es la capa “Anonymous best-effort broadcast layer(abc)”.Proporciona un canal de 16 bit sin direccionamiento. Si se le quiere añadir, se usanlas capas inmediatamente superiores: “Identified sender best-effort broadcast layer(ibc)” introduce una cabecera donde se codifica la dirección del emisor del mensaje;“Unicast abstraction layer (uc)” introduce la información relativa al receptor.

El diseñador de la aplicación puede jugar a introducir o no diferentes capas envista a proporcionar unas u otras funcionalidades. Hay que resaltar que si se lograencajar el funcionamiento del protocolo con las capas de Rime, al ser ésta parte deContiki, se asegura que resultarán unos programas más pequeños.

Por último decir que Rime reduce el consumo de recursos al utilizar un solobuffer tanto para los paquetes salientes como los entrantes.

uIP

Esta pila de comunicación fue implementada para que los sistemas embebidosbasados en microcontroladores de 8 bits pudieran comunicarse utilizando el protocoloTCP/IP. Evidentemente, todos sabemos de la importancia del protocolo TCP/IPy de su amplio uso por ej. en Internet. Por ello, es una ventaja muy importantesobre otro tipo de sistemas el dar soporte en las redes de sensores inalámbricosde este protocolo para que puedan llevar a cabo sus comunicaciones sobre él. Porla serie de limitaciones de recursos que tenemos en estos dispositivos, solo estánincluidas las características mínimas para poder hacer una comunicación TCP/IPbásica. Contiene versiones reducidas de los protocolos IP, TCP, UDP e ICMP, loscuales son compatibles con la mayoría de sensores inalámbricos que existen en elmercado.

23


2.3.2.6. Estructura de directorios de Contiki

El sistema operativo Contiki presenta una estructura definida y clara queagrupa jerárquicamente, en una serie de directorios, las distintas partes de las que secompone. A continuación describen, brevemente las carpetas que componen Contiki:

apps/ - Contiene aplicaciones independientes de la arquitectura del sistema.Existe un subdirectorio por cada aplicación.core/ - Código fuente del sistema. Hay subcarpetas para las distintas partesdel sistema.cpu/ - Código fuente específico de cada tipo de CPU. Un subdirectorio porcada CPU.doc/ - Documentación propia del sistema operativo.examples/ - Carpetas con proyectos ejemplo, una por cada proyecto.platforms/ - Código específico de la plataforma. Un directorio conteniendocada plataforma.tools/ - Software para construir Contiki, enviar archivos, etc.

2.4. Simuladores de WSN

2.4.1. Introducción

El uso de simuladores es una potente herramienta para los desarrolladoresde software y es muy importante a la vez que útil en el caso de las redes desensores. Para poder probar un software diseñado para una mota, en primer lugares necesario llevar a cabo el proceso de creación del código, luego hay que realizar lacompilación del mismo y por último, cargarlo en el sensor para poder ser ejecutadoy probarlo. Todo este ciclo resulta complicado y lento, más si cabe si hay que hacerposteriores modificaciones, lo que implicaría repetir todos los pasos anteriores unay otra vez hasta depurarlo completamente y se satisfagan los objetivos inicialesde funcionamiento. Con un simulador, podemos representar un escenario con unaserie de nodos, configurar una serie de parámetros, ejecutar en ellos un programay estudiar tanto su comportamiento como las interacciones que se producen entreellos, proporcionando valiosos datos con los que llevar a cabo posibles cambios quemejoren el funcionamiento de la aplicación, agilizando todo el proceso comentadoantes.

En esta sección primeramente, se van a presentar los simuladores máscomúnmente usados en la actualidad (TOSSim, NS-2 y OMNeT++), describiendosus características más destacadas [1]. A continuación, se llevará a cabo un estudiomás detallado de Cooja, el simulador de redes de sensores incluído en Contiki, cuya

24

2.4 Simuladores de WSN

ampliación para el uso de un nuevo tipo de mota, AvrZigbit, será el eje central deeste proyecto. Este logro proporcionará la posibilidad de realizar simulaciones coneste nuevo tipo de nodo que serán muy útiles para el desarrollo de nuevo software,evaluación de distintos protocolos, medidas de consumo de redes de sensores Zigbit,etc.

2.4.2. TOSSim

Se trata de un simulador de eventos discretos para redes de sensores en elsistema operativo TinyOS.

Permite la posibilidad de compilar las aplicaciones en TinyOS en el propioFramework de TOSSim en lugar de tener que compilar la aplicación para cada nodo.Esto permite a los usuarios depurar, probar y analizar algoritmos en un entornocontrolable.Las características más destacables son las siguientes:

Fidelidad: Captura el comportamiento de TinyOS a muy bajo nivel. Simula lared a nivel de bit y todas las interrupciones del sistema.Temporización: Desde la perspectiva de TOSSim, una porción de código seejecuta de manera instantánea, mientras que la velocidad del reloj es un valoren torno a 4MHz. Esto provoca que algunos eventos no ocurran hasta que elcódigo se complete en lugar de ocurrir en el preciso instante.Modelos: No modela el mundo real, pero permite abstracciones de éste.Mediante herramientas los usuarios pueden implementar los modelos quedeseen.Radio: TOSSim no modela la propagación radio, sino que provee unaabstracción de la radio directa e independiente con bits de errores entre dosnodos. Mediante programas externos se puede recrear el modelo de radiodeseado y mapearlo en los bits de errores mencionados anteriormente.Potencia: Tampoco modela el consumo de energía, pero mediante anotacionesen cada componente es sencillo calcular el consumo de energía.Construcción: Para simular un sistema o un protocolo, se debe escribir unaimplementación en TinyOS de éste. Por un lado es más difícil abstraer lasimulación pero por otro se puede ejecutar aplicaciones desarrolladas en losnodos actuales.Redes: TOSSim simula redes Mica RFM con una pila de 40KB, incluyendo lacapa MAC, encriptación y confirmaciones.Imperfecciones: El hecho de que TOSSim capture el funcionamiento a bajonivel puede provocar que programas que no funcionen en la vida real si quefuncionen en las simulaciones. Por ejemplo una interrupción muy larga puede

25


provocar que el nodo real falle (se bloquee o se resetee), mientras que en elsimulador funcionará sin ningún problema.

La figura 2.11 contiene una captura de pantalla donde se muestra el simuladorTOSSim.

Figura 2.11.: Simulador TOSSim

2.4.3. NS-2

Se trata de un simulador de redes basado en eventos discretos centrado en lainvestigación de redes. Nació en el año 1989 como una variante del simulador deredes REAL. Años más tarde, fue la organización DARPA quién se encargó de sudesarrollo y posteriormente pasó a manos de la Universidad de Berkeley, siendo laresponsable de su mantenimiento y evolución.

NS se utiliza mucho en ámbitos educativos y de investigación. Al ser softwarelibre, tiene una comunidad de colaboradores importante que han desarrollado ymejorado nuevas características.

Es capaz de simular gran variedad de redes IP, tanto cableadas comoinalámbricas (locales o por satélite). Implementa protocolos de red como pueden serTCP y UDP, distintas fuentes de tráfico como Web, FTP, CBR o VBR, mecanismosde gestión de colas de enrutado, de QoS (por ejemplo DiffServ o IntServ) y algoritmosde enrutado propiamente. Proporciona, además, capacidad para la simulación deprotocolos multicast o protocolos de capa MAC para redes de área local también.

La versión 2 está implementada en C++, para la codificación de loscomponentes básicos de red, y OTcl (que no es más que el lenguaje de script Tcl conla extensión orientado a objetos) para el control de dichos componentes.

Su funcionamiento se puede resumir como sigue:

26


Inicialmente se tiene un script OTcl, que es el que contiene el programaque describe la simulación a realizar. NS es un intérprete de dichos scripts quecontiene un planificador de eventos de simulación y una serie de librerías conobjetos de red y otros módulos que ayudan a la configuración de la misma. Unusuario que quiera llevar a cabo una simulación con NS-2 debe escribir un scriptOTcl que inicia el planificador de eventos y en el que se describirá la topologíade la red y las fuentes de tráfico que existirán (indicando cuándo empezarán yterminarán a transmitir paquetes). NS interpretará dicho script, llevando a cabo lasimulación y proporcionará una serie de resultados que serán muy útiles para suanálisis posterior. Además, el entorno proporciona una herramienta de visualizacióngráfica muy sencilla (NAM : Network Animator) que muestra la evolución temporalde la simulación (flujo de paquetes, encolado o posible descarte), permitiendopararla/reanudarla, avanzar/retroceder y de la cual se pueden extraer algunos datossignificativos como el rendimiento o la tasa de pérdida de paquetes.

Por último decir que existe otra versión de NS, NS-3 que es incompatible conNS-2 y que da soporte para la simulación de redes IP o no IP, redes inalámbricascomo WiFi, WiMAX o LTE y protocolos de encaminamiento como OLSR o AODV.

Figura 2.12.: Simulador NS-2

2.4.4. OMNeT++

OMNeT++ es un entorno modular de simulación de eventos discretos. Fuecreado en 2003 en la Universidad de Budapest. Habitualmente, se utiliza para redesde comunicaciones y todo lo que tenga que ver con ellas, por ejemplo, modelarprotocolos de comunicaciones y el tráfico que se produce en ellas. Aunque su utilidadprincipal es ésta, también se ha usado para validar arquitecturas hardware, sistemasmultiprocesadores o distribuidos y, en general, para probar cualquier sistema que sepueda simular gracias a eventos discretos.

Su arquitectura es modular, es decir, se basa en una serie de módulos queproporcionan funcionalidades básicas. Se pueden reunir varios módulos para formarcomponentes o modelos más complejos utilizando un lenguaje de alto nivel llamadoNED (Network Description Language). Hay dos tipos de módulos: los de tiposimple, que contienen los algoritmos que permiten el funcionamiento del modelo(se implementan en C++), y los compuestos, que son agrupaciones de módulos

27


que se conectan mediante puertos o gates. Los módulos pertenecientes a un mismomodelo se comunicarán intercambiando mensajes.

Para llevar a cabo una simulación, es necesario definir la estructura del modeloen lenguaje NED y programar en C++ los módulos simples usando para ello losmódulos de simulación y librerías disponibles. Al crear el modelo se mapea el sistemadentro de una jerarquía de módulos que se comunican entre sí. Una vez hecho ésto,se crea el programa de simulación y se ejecuta. Los resultados se presentan en unvector y en un archivo escalar de salida. El propio entorno contiene herramientasadecuadas para la correcta visualización de estos datos.Podemos citar como ventajas de este simulador las siguientes:

Bien estructurado.Altamente modular.No limitado a simulaciones a nivel de red.Proporciona una interfaz de usuario gráfica que hace más agradable el entorno.Más intuitivo, sencillo y flexible para el usuario a la hora de crear nuevosmódulos.Simulaciones relativamente rápidas.Soportado en plataformas Windows y Linux.

Como contras:Pocos modelos de simulación.

Figura 2.13.: Simulador OMNeT++

2.4.5. Cooja

COOJA [10] (Contiki OS Java Simulator) es un potente simuladorimplementado en el lenguaje de programación Java, que ha sido diseñado pararealizar simulaciones de redes de sensores inalámbricos que ejecutan el sistema

28


operativo Contiki. Cada nodo simulado puede ser de diferente tipo, no solo en elsoftware que ejecuta, sino también en el hardware, lo cual es una gran ventaja yaque se podrán simular redes heterogéneas formadas por distintos tipos de nodos yvisualizar las interacciones que se producen entre ellos. Su uso es relativamentesencillo, existiendo para ello un tutorial3 de los mismos creadores que permiteaprender lo básico para iniciarse en su uso y funcionamiento. Es fácilmente extensibleen muchos de sus aspectos, siendo posible añadir nuevas funcionalidades o nuevoscomponentes, como pueden ser, por ejemplo, nuevos plugins que nos permitaninteractuar con una simulación o nuevos tipos de nodos.

A modo de ejemplo, en la figura 2.14 se muestra al lector el aspecto de COOJA.La ventana principal contiene cinco subventanas en las que cada una representa unplugin:

Simulation control: Permite manejar el tiempo de simulación. Incluye unaserie de controles con los que se puede dar comienzo a la simulación, pararlao reanudarla. También se muestra el tiempo total de simulación que se hacompletado.

Network: Muestra la disposición de los nodos en el plano X-Y. Mediante esteplugin también es posible añadir otras características adicionales, como puedeser los rangos de transmisión, paquetes tx/rx, etc.

Mote output: Realiza una escucha de los puertos serie de las motas,imprimiendo los mensajes que transmiten.

Timeline: Evolución temporal de los eventos sucedidos en la simulación,indicando claramente para cada uno de ellos el momento en que se hanproducido, el nodo que los ha originado y una pequeña descripción de talevento.

Notes: Útil para anotar cualquier aspecto o circunstancia del desarrollo de lasimulación.

3http://www.contiki-os.org/start.html

29


Figura 2.14.: Ventana principal de COOJA

Un nodo simulado en COOJA tiene tres propiedades básicas:Tipo de nodoHardware de sus periféricosMemoria de datosEl tipo de nodo se comparte entre nodos del mismo tipo y especifica las

propiedades comunes a todos estos nodos. Los nodos del mismo tipo ejecutan elmismo código de programa en los mismos periféricos hardware simulados. En cambio,aunque los nodos del mismo tipo se inicializan con la misma memoria de datos(excepto el id del nodo), durante la ejecución de la simulación, puede variar de unosa otros ya que normalmente serán manipuladas con entradas externas diferentes.

COOJA puede ejecutar programas en Contiki de dos maneras distintas. Laprimera de ellas es ejecutar el código del programa como código nativo en la CPUhost; otra opción es ejecutarlo como código compilado a nivel de instrucción en unemulador del microcontrolador apropiado (MSP430 o ATMega1281, por ej). Tambiénes posible simular nodos que no ejecuten el sistema operativo Contiki, como puedenser nodos implementados en Java o que ejecuten otro sistema operativo distinto.Cualquiera de los distintos enfoques tienen sus pros y contras. Los nodos basados enJava permiten simulaciones más rápidas, pero no ejecutan código a bajo nivel, por

30


ello son especialmente apropiados para el desarrollo de algoritmos distribuidos, porejemplo. Los nodos emulados proporcionan un nivel de detalle de la ejecución mayorque los que proporcionan los basados en Java o los nodos en código nativo, pero encambio, son más lentos. Por último, con los nodos en código nativo se pueden llevara cabo simulaciones más rápidas que las de los nodos emulados, ejecutando ademásel código despegable.

COOJA ejecuta el código nativo haciendo uso de JNI (Interfaces Nativas deJava) para realizar llamadas desde el entorno Java al sistema compilado Contiki,el cual se compondrá del núcleo de Contiki, procesos de usuario preseleccionadosy un conjunto de drivers específicos para la simulación. Todo ello hará posible eldesarrollo y la simulación del mismo código sin cambios, minimizando el retrasoentre simulación y desarrollo.

El simulador tiene control absoluto sobre la memoria de los nodos simulados.Esto le posibilita realizar cambios o visualizar variables de procesos Contiki,permitiendo distintas posibilidades de interacción dinámica desde el simulador.Además, el uso de JNI nos permite utilizar un depurador como gdb y poder realizaruna depuración de la simulación enlazándolo con el sistema simulador por completoy colocando los puntos de ruptura cuando las llamadas JNI se produzcan. Tambiénes posible guardar una simulación y recuperarla posteriormente.

Se llaman interfaces a los periféricos hardware de las motas simuladas.Ejemplos de interfaces son el chip radio de la mota, leds, etc. Permiten al simuladordetectar eventos procedentes de los mismos, como puede ser que un led se encienda.Las interfaces también representan otro tipo de propiedades de los nodos, como porejemplo, la posición espacial de los mismos.

Las interacciones con la simulación se llevan a cabo mediante plugins. Unejemplo de plugin es el visualizador de la simulación, que nos muestra la posiciónde las motas en el espacio y nos permite moverlas desde un punto a otro o mostrarla cobertura de su radio.

Ambos, plugins e interfaces, se pueden añadir fácilmente al simulador,aumentando su funcionalidad y permitiendo al usuario añadir unos controles másespecíficos para la aplicación que quiere llevar a cabo o probar.

2.4.5.1. Simulación Cross-Level

En la actualidad y como se ha visto en apartados anteriores , hay granvariedad de simuladores de redes de sensores inalámbricos. Cada uno de ellos llevaa cabo sus simulaciones en un nivel de abstracción fijo, ya sea a nivel hardware,a nivel de sistema operativo o a nivel de aplicación. Esto conlleva una serie deinconvenientes, pues el nivel que se escoja afectará al nivel en que se puede aplicarel desarrollo software que se realice y a la eficiencia de ejecución de dicho simulador.Por ejemplo, si se elige uno que ejecute simulaciones a nivel hardware nos brindará

31


la oportunidad de implementar código a muy bajo nivel, como puedan ser drivers dedispositivos, otorgándonos un control bastante preciso del dispositivo. En cambio,como contrapartida, la excesiva complejidad que conlleva este tipo de programacióny los largos tiempos de simulación empleados serán un problema. Por otro lado, sise escogiese un simulador de alto nivel, los tiempos de simulación se reduciríandrásticamente, aunque solo podríamos desarrollar algoritmos de alto nivel y notendríamos acceso a funciones de nivel hardware.

A diferencia de los simuladores anteriores, COOJA introduce una ventaja muyimportante respecto al resto: permite la simulación de redes de sensores a variosniveles. Mezcla la simulación de alto nivel con simulación a bajo nivel del hardwarede un nodo. Todo ésto se muestra en la figura 2.15.

Figura 2.15.: COOJA puede simular a la vez varios niveles

Aunque los nodos de distintos niveles se dice que se simulan, los de bajo nivel,realmente, se emulan ya que el programa se compila para otra arquitectura distintade la que realiza la simulación. Es decir, los nodos tipo “ESB”, cuyo microcontroladores el MSP430, se emulan mediante MSPSIM , emulador a nivel de instrucción dedicha familia de micros. Los de tipo “AvrZigbit”, objeto del presente proyecto, poseenun microcontrolador de la familia Atmel y para que COOJA pueda “simularlos”,utiliza el emulador Avrora, que también se modificará y ampliará para que puedareconocer y ejecutar un programa para dicha plataforma Zigbit.

En COOJA, a los tres posibles niveles de ejecución se les denomina Nivel dered (o aplicación), Nivel de sistema operativo y Nivel de conjunto de instruccionesde código máquina.

Nivel de redCuando se desea desarrollar protocolos de encaminamiento, por ejemplo, no

es importante el hardware propio del nodo. Lo que realmente interesa es el medioradio, el chip radio del nodo y tal vez el ciclo de trabajo de la mota4. Por tanto, nosería imprescindible utilizar un simulador de bajo nivel.

COOJA permite al usuario intercambiar ciertos módulos a fin de personalizarla simulación que se desee realizar. Por ejemplo, se pueden elegir diferentes

4También llamado duty-cycle

32


medios radio o drivers de dispositivos. Se puede almacenar una simulación pararecuperarla posteriormente añadiendo o suprimiendo módulos. Por supuesto, sepueden desarrollar en Java nuevos medios radio o interfaces para añadirlos alsimulador y que se puedan utilizar en otras ocasiones.

Para escenarios como el comentado anteriormente, COOJA ofrece la posibili-dad de crear un tipo de nodo especial que ejecuta solamente código Java. No tienenninguna relación con Contiki, pero son muy útiles a la hora de diseñar algoritmosde alto nivel, simplificando la complejidad de su desarrollo. Posteriormente, dichosprotocolos serán portados al código que ejecutarán las motas. Otro ejemplo de utili-zación de este tipo de nodos se da cuando se quiere representar una red de sensorescon muchos nodos de distintos tipos y solo se desea trabajar con un subconjunto deellos. Añadiendo este tipo de motas, las cuales necesitan menos memoria y procesadopara su ejecución, la simulación se puede realizar de manera más eficiente y rápida.Con ello se logrará la funcionalidad deseada y en otro momento posterior, se puedeportar dicha implementación al código de los nodos Contiki para así conseguir quese comporten de la manera diseñada y probada a priori.

Nivel de sistema operativo

COOJA simula el sistema operativo ejecutando el código nativo del mismocomo se ha descrito anteriormente. Al realizar simulaciones con este tipo de nodo,se ejecuta el sistema operativo completo, pudiendo así alterar la funcionalidad delnúcleo de Contiki y ver cuál es el comportamiento, lo que es útil cuando se deseahacer modificaciones en las librerías incluidas.

Nivel de conjunto de instrucciones de código máquina

Es factible crear nodos cuya base sea distinta a la de los nodos típicos. Estosnodos se emularán gracias a un emulador del propio microcontrolador. Actualmenteen COOJA existen dos emuladores a nivel de instrucción de dos familias demicrocontroladores ampliamente usadas hoy en día que se pueden utilizar en modoautónomo o conjuntamente con COOJA:

1. MSPSIM [11]: Es un emulador a nivel de instrucción de los microcontrola-dores de la serie MSP430 con el que se puede lograr una simulación bastanteprecisa. Se usa también para la simulación de algunas plataformas de redes desensores. Está implementado en lenguaje Java. Se puede extender fácilmentepara incorporar nuevos periféricos, pudiendo llevar a cabo simulaciones convarios tipos de sensores siempre basados en dicho microcontrolador. Ademásde simular el MSP430 y los sensores de la mota, MSPSIM muestra una re-presentación gráfica de dicha placa, en la que se puede observar cómo se vaniluminando los leds al llevar a cabo las operaciones que se le va indicando ointeractuar con la simulación pulsando los botones que incorpora. Esto es real-mente útil ya que se puede verificar que la aplicación está siendo correctamentesimulada sólo con observar los leds por ejemplo (sirve para depuración de laaplicación). Como reseña, sus autores son los mismos que el sistema operativo

33


Contiki. A continuación se presentan brevemente las dos arquitecturas másutilizadas actualmente que incluyen tal microcontrolador: Tmote Sky y ESB.

Tmote Sky: Cuenta con un micro TI MSP430F1611 que funciona a unafrecuencia de hasta 8 Mhz. Posee 10 Kb SRAM, 48 Kb Flash ROM y 1Mb de memoria externa. Su chip radio es 2.4 GHz Chipcon CC2420 IEEE802.15.4 Wireless Transceiver, que tiene una tasa de transmisión de 250Kbps. Posee sensores de humedad, luminosidad y temperatura. Tiene unconsumo reducido y se programa mediante el interfaz USB.

ESB: Integra un microcontrolador TI MSP430. En cuanto a almacena-miento, dispone de 2 Kb de RAM y 60 Kb de ROM. El chip radio esTR1001. Incluye una memoria externa EPROM de 32 Kb. Tiene puertoserie, puerto JTAG y una serie de sensores variados: temperatura, infra-rrojos, etc.

MSPSIM soporta la carga de programas indistintamente en formato IHEX oELF. También ofrece una serie de herramientas muy útiles para la visualizaciónde distintos parámetros dentro de la simulación, como el panel de control desimulación (figura 2.16), en la que se puede observar la ejecución del códigomáquina del programa cargado, el código fuente ejecutado y una serie decontroles para manejar en todo momento la simulación; el visor del puertoserie de la mota (figura 2.17), mostrando los datos transmitidos/recibidos através de él; y por último, una imagen de la placa física de la propia mota(figura 2.18) donde se puede ver el encendido o apagado de los leds del nodo,incluso permite pulsar en los botones que llevarán a cabo una acción concreta(por ejemplo el reset de la mota).

Figura 2.16.: Visor del control de la simulación

34


Figura 2.17.: USART1 Port Output

Figura 2.18.: Vista de la mota Tmote Sky

2. Avrora [12]: Se desarrolló en la Universidad de California (UCLA). Es unsimulador a nivel de instrucción (cycle accurate) de los microcontroladoresde la familia AVR y se puede emplear también para redes de sensoresque se basen en esta familia de dispositivos. Gracias a que Avrora seimplementa en Java, el concepto de programación orientada a objetos sirvepara englobar perfectamente a los componentes fundamentales del sistema,como pueden ser los dispositivos hardware, los periféricos, las instruccionesdel micro, etc. formando una estructura clara y concisa para que cualquierusuario interesado en su funcionamiento pueda aprender más sobre él o paraposibles ampliaciones, objetivo que se abordará en este proyecto como partedel desarrollo del mismo. Su funcionamiento es simple: cada dispositivo semodela e implementa en Java, lo cual permite emular su comportamientovia software. A través de una serie de interfaces, podrá interaccionar con lasimulación central. Por otro lado se encuentra el programa simulador, quees quién realmente gestiona la simulación y que se compone de una cola deeventos y un intérprete. El intérprete ejecuta una a una las instrucciones delprograma, mientras que la cola controla el tiempo de simulación, avanzando ollevando al reposo al simulador cuando el microcontrolador se pone en estadoocioso. Los componentes que se encuentran integrados en el micro (on-chipdevices), tales como temporizadores, SPI, etc. se comunican con él a travésde registros internos del microcontrolador; en cambio, los que se encuentran

35


fuera (off-chip devices) como pueden sensores, chip radio, etc. utilizan pinesde entrada/salida, debidamente encapsulados como interfaces, como se hacomentado antes. Con todo estos elementos, se logra realizar una simulaciónbastante fiable de un nodo con microcontrolador AVR, mediante la cual sepodrán probar aplicaciones desarrolladas y compiladas específicamente paradicha plataforma, ayudando así a que el proceso de desarrollo de programaspara sensores inalámbricos sea más sencillo, rápido y eficaz.Hay que indicar claramente y para evitar confusiones, que aunque se permita

la ejecución en cualquiera de los tres niveles, cada nodo individualmente se estásimulando en un sólo nivel. Como resumen, la característica y principal ventaja quenos brinda COOJA es que se puede realizar una simulación donde nodos de distintosniveles pueden coexistir e incluso interactuar entre ellos, pudiendo por ejemplo unnodo implementado en Java mandar paquetes de datos a otro nodo emulado.

2.4.5.2. Medios radio

COOJA da soporte a una serie de distintos medios radio que caracterizan lapropagación de los datos y proporciona a los usuarios la capacidad de probar lasaplicaciones desarrolladas por ellos mismos en diversas condiciones representadaspor dichos medios radio. Se puede seleccionar al comienzo de la simulación.Actualmente existen cuatro tipos en COOJA:

UDGM (Unit Disk Graph Medium): En primer lugar se estudia el modelo en elque se considera que existe una pérdida constante. Es un modelo muy simple demedio radio en el que el rango de transmisión se representa por un círculo. Losnodos que estén dentro de dicho círculo podrán recibir paquetes de datos. Encambio, si se encuentran fuera, no les llegará nada. El radio del círculo del rangode transmisión se calcula multiplicando el rango predefinido del dispositivo porel resultado de dividir la potencia de transmisión de salida entre la potenciade transmisión máxima. Es decir, si el dispositivo tiene un rango de 100 m yla potencia de transmisión es la mitad del máximo que se le puede asignar,el radio del círculo de transmisión será de 50 m. Como variante al modeloanterior, se puede considerar la posibilidad de que la pérdida depende de ladistancia, pero ello implica una serie de pequeñas variaciones que extiendenel modelo presentado antes. En primer lugar, las interferencias se toman enconsideración, pero de manera muy sencilla. Se tendrá otro círculo, en estecaso de interferencias. Si distintos paquetes se interfieren, se pierden todos. Esdecir, paquetes que se transmitan a la vez, interferirán y se desecharán. Ensegundo lugar, es posible definir la tasa de éxito de transmisión y de recepción.Los paquetes se transmiten con probabilidad SUCCESS_RATIO_TX (si esigual a cero, nadie recibe el paquete) y se reciben con SUCCESS_RATIO_RX(si es igual a cero, ese nodo no recibe nada). Por defecto, ambas probabilidadesvalen 1.

36


DGRM (Directed Graph Radio Medium): Es posible utilizarlo solo o comobase de otras implementaciones de medios radio. Establece una tasa de éxitode transmisión y un retraso para cada enlace entre dos nodos.

MRM (Multi-path Ray-tracer Medium): También se conoce como ARM(Advanced Radio Medium). No se basa, como los anteriores, en tomarresultados de diversas pruebas para determinar experimentalmente laspérdidas. Estudia la propagación de los rayos y aplica la fórmula de Friispara determinar la potencia de señal recibida en función de la transmitida.Tiene en cuenta fenómenos como son la reflexión, la refracción y la difracciónproducidos por obstáculos que producen atenuaciones no deseadas. El usuariopuede configurar dicho medio estableciendo una serie de parámetros como sonlas ganancias de las antenas transmisora y receptora, la longitud de onda o ladistancia. Con todo esto, se pueden conseguir unas simulaciones mucho máscercanas a la realidad, que es el objetivo fundamental que se busca.

No radio traffic: En él, no se transfiere ningún dato. Por lo tanto, no es útil enuna simulación en la que se desee establecer una comunicación radio.

2.4.6. Implementación

A continuación se presenta, de manera simplificada, el funcionamiento delsimulador, cómo se ejecuta el código de Contiki, cómo COOJA lo controla y cómointeractúan las distintas partes fundamentales del sistema [10].

2.4.6.1. Compilando Contiki en COOJA

Como se vio en la sección 2.3, Contiki es un sistema operativo manejadopor eventos. Cuando ocurre un evento, se ejecuta y se espera hasta que terminecompletamente. COOJA también va a utilizar esta manera de funcionamiento.Realiza una llamada al sistema operativo que ha sido previamente cargado y permitea cada nodo que ejecute un evento por turno. En el bucle de simulación, es el propiosimulador el que se encarga de dar la autorización a cada nodo para que sondee einterrogue a sus interfaces para ver si tiene que procesar algún nuevo evento. Si nohay ninguno, pasa al siguiente. Cuando completa una pasada entera por todos losnodos, el bucle de simulación incrementa el tiempo de simulación global e informaal simulador de que se ha completado un ciclo. El proceso explicado se puede vermás claro en la figura 2.19.

37


Figura 2.19.: Bucle de simulación principal

Al crear un nodo de un tipo concreto, el sistema operativo Contiki se compilaexclusivamente para esa plataforma. La plataforma, a su vez, especifica los driversque permiten la comunicación con el hardware de dicho nodo. Si el nodo se emula,como es el caso de Tmote Sky o MicaZ, Contiki se compila para la arquitectura delMSP430 o ATMega128, respectivamente. En cambio, si el nodo se simula utilizandocódigo nativo, el sistema operativo se compila para una plataforma especial desimulación, la cual contendrá una amplia variedad de drivers que hacen posiblela correcta ejecución de cualquier proceso de Contiki. Desde el simulador se lleva acabo la gestión de la compilación y la carga posterior de la librería resultante, así quees posible seleccionar qué dispositivos hardware y qué procesos estarán disponibles.Una vez hecho todo esto, el archivo principal que contiene el código fuente delsistema operativo Contiki se genera, compila y se carga en el simulador.

2.4.6.2. Simulación del sistema operativo Contiki

Cada nodo se compone de una serie de interfaces y posee su propia memoria.Esta memoria está formada por uno o varios segmentos de memoria que seidentificarán por una dirección inicial y contendrán datos. El conjunto de segmentosde memoria debe representar las partes que realmente son importantes y que elsimulador necesita de Contiki.

Cuando un nodo se simula en código nativo, el tipo de nodo es el nexo de uniónentre el nodo y Contiki. Él es quién carga la librería compilada que se comentó antes.Además, cualquier interacción entre el simulador y la librería se realiza a través deltipo de nodo. En la figura 2.20 se puede observar todo ello, además de otras partesimportantes de un nodo, como es la memoria y sus interfaces.

38


Figura 2.20.: El tipo de nodo actúa como enlace a la librería Contiki cargada

El tipo de nodo hace uso de varias funciones para hacer llamadas al sistemaoperativo compilado, entre las que se encuentran las necesarias para copiar o sustituirsegmentos de memoria, inicializar el sistema o para permitir a Contiki que proceseun evento.

Nodos que son del mismo tipo comparten la misma memoria de programa (elsistema operativo Contiki y varios programas también de Contiki). En cambio, lamemoria de datos (el estado del programa) es diferente para cada uno de ellos.COOJA lo que hace es una copia local de cada una de estas memorias para,posteriormente, realizar el cambio de contexto entre unas y otras al ir pasandopor distintas motas. Así, cuando se está ejecutando un nodo, el simulador (entornoJava) copia su memoria de datos al entorno del sistema operativo (C) y se hace unallamada JNI (Java Native Interface) al núcleo de Contiki. Éste procesará un eventode la cola de eventos y cuando finaliza, devuelve el control a COOJA. Cualquiercambio que se produzca en la memoria de datos provocará que se tenga que haceruna copia para su almacenamiento en el simulador.

Otro premisa que se debe cumplir es que COOJA debe conocer las direccionesde memoria de cada una de las variables y funciones de cada sistema operativoContiki que se carga. Esto se realiza parseando el mapa de archivos que se genera entiempo de enlazado de la librería. Con ello, COOJA puede averiguar las direccionesde cualquier variable que se localice en la citada librería compilada. Gracias alo anterior, el simulador es capaz de ver o modificar determinadas variables, enfunción de las cuales, podrá hacer una u otra acción (es, básicamente, el modo defuncionamiento de un plugin).

Al cambiar de nodo en la simulación, es necesario sustituir la memoria deproceso de uno por la del siguiente. Específicamente, COOJA hace una copia de lamemoria de datos y BSS5 del nodo actual y lo reemplaza por la del siguiente. Graciasa que Contiki es un sistema manejado por eventos y que solo se procesa un solo eventocompletamente cada vez, solo es necesaria una única pila para almacenar toda estainformación. Como no es recomendable que las aplicaciones diseñadas para Contiki

5Sección de memoria de la RAM que contiene las variables estáticas o variables globales noinicializadas del programa de aplicación

39


hagan uso de esta pila, no es necesario que el simulador copie su contenido cuandose están simulando varios nodos usando el mismo sistema operativo cargado. Porúltimo, el segmento de memoria de texto es el mismo para todos los nodos simulados,con lo que queda que solo es necesario guardar el contenido de la memoria de datosy BSS.

Figura 2.21.: Control de Contiki manejando segmentos de memoria

2.4.7. Plugins e interfaces

Los plugins e interfaces permiten al usuario del simulador interactuar con lasimulación. Los primeros son útiles para la visualización de determinados eventosque se producen en el sistema o, simplemente, para el manejo de la propia simulación.Las interfaces, en cambio, permiten al simulador manejar distintas propiedades delos nodos que se están simulando.

COOJA permite la personalización del entorno, brindándole la oportunidadal usuario de añadir/quitar determinadas funcionalidades que sean de más interésen la posterior simulación. Asimismo, existe la posibilidad de modificar o inclusocrear nuevos plugins o interfaces, que se adecuen a nuestras posibilidades entanto en cuanto toda la aplicación, como ya antes se ha comentado, se encuentraimplementado en Java y no resulta excesivamente complicado crear nuevoscomponentes.

2.4.7.1. Plugins

Son pequeños programas en Java que proporcionan la posibilidad deinteraccionar con la simulación. Se registran antes del inicio de la simulación, en lacarga de la aplicación simulador. El usuario creará después instancias de los pluginsque se encuentren disponibles y que quiera utilizar. Se representan mediantes simplescuadros gráficos con botones o cuadros de texto donde se muestra información,eventos, etc.Existen tres tipos diferentes de plugins:

40


Plugin GUI: Solo necesita una interfaz de usuario gráfica para que se puedacrear. A través de ella, puede acceder a determinada información, como puedeser la simulación actual (si existe) y los nodos simulados. Por ello, y al dependersolo de la GUI, no se elimina cuando se destruye la simulación. Como solopuede realizarse una simulación al mismo tiempo, este tipo de plugin ofrece laposibilidad del intercambio de todos los parámetros o datos que sean necesariosentre diferentes simulaciones. Un ejemplo de este tipo de plugin puede ser elque realiza la carga de la simulación, almacena los datos o carga en un momentoposterior otra simulación.Plugin de simulación: Cuando se crean, se pasa la simulación como argumento.Por tanto, en el momento en que se elimina dicha simulación, desaparecen conella. Una muestra de tal tipo puede ser un plugin que muestre el estado actualde la simulación, con botones para detenerla, reanudarla, etc. Este pluginpresenta dos variantes, dependiendo de si se carga automáticamente al crearla simulación o es opcional y se puede escoger o no por el usuario.Plugin de nodo: Depende totalmente del nodo simulado, por lo que suexistencia está supeditada al anterior. Un ejemplo puede ser un plugin quemuestre alguna característica en concreto del nodo, como puede ser el estadode los leds.

2.4.7.2. Interfaces

Mientras que los plugins dan la posibilidad de interactuar con una simulación,las interfaces permiten interaccionar con nodos simulados. Ofrecen la posibilidadde acceder al hardware simulado de la mota. Además se pueden crear o modificarpara alcanzar un grado de precisión más alto en las simulaciones. Las interfacesrepresentan propiedades de los nodos, como puede ser la posición que ocupa en elespacio o su hardware radio. En el primer caso, como el nodo no sabe su posicióndentro de la simulación, la interfaz no tiene que proporcionarle esa información ala memoria del nodo ni al sistema operativo Contiki que se encuentra por debajo.Solo debe indicar dicha modificación para que otros elementos, como puede ser elplugin que representa espacialmente a los nodos de la simulación, tenga en cuentaeste hecho y haga los cambios oportunos (siguiendo con el ejemplo del plugin quesitua a los nodos en el espacio, deberá representarlos en otro punto distinto).

Las interfaces que tienen que comunicarse con código Contiki, tienen suhomólogo en el propio S.O. Contiki, es decir, por ejemplo, además de la interfazque representa el radio en el nodo, en Contiki existe código que implementa dichohardware. Aquí si existe un trasvase de información entre ambos mundos. Siguiendocon el ejemplo de la radio, cuando un nodo recibe un paquete, se manipulará suporción de memoria para indicar dicho evento. Cuando se copia esta memoria alS.O. Contiki, digamos que la correspondiente interfaz dentro de él que representa alchip radio, le notifica que un paquete ha sido recibido de la misma manera que si,

41


por hardware, hubiera sucedido realmente dicha acción. Por lo tanto, este flujo deinformación se realiza mediante la manipulación de la memoria del nodo.

Por último, y para ofrecer algunos ejemplos de interfaces, en COOJA, parala plataforma MicaZ existen las siguientes: MicaZID, MicaClock, MicaZRadio,MicaZLED y MicaSerial que representan el id del nodo, el reloj, la radio, los leds yel puerto serie de la mota, respectivamente.

42

Documents

2. Antecedentesbibing.us.es/proyectos/abreproy/12099/fichero/Memoria%2FCapitulo_2.pdf · 2. Antecedentes 2.1. RedesdeSensoresInalámbricos 2.1.1. Quéesunareddesensoresinalámbricos