ESTUDIO COMPARATIVO DE SISTEMAS OPERATIVOS DE TIEMPO REAL APLICADO A REDES DE SENSORES INALAMBRICAS.

Jos Ulloa Surez.

Sociedad Agrcola Ojos Buenos Ltda.

INDICE
1 Introduccin................................................................................................................................................3 2 Desarrollo....................................................................................................................................................4 3 Conclusiones.............................................................................................................................................14 4 Referencias................................................................................................................................................15

Introduccin

Las redes de sensores inalmbricas se insertan bajo un nuevo enfoque en el desarrollo de tecnologas para la obtencin 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 ), agrcola (sensar estado de la tierra, el crecimiento de los frutos, etc) entre otros. Principalmente estas apuntan a integrar sistemas autnomos, para la obtencin conjunta y posterior procesamiento de informacin. Especficamente hablamos de dispositivos autnomos distribuidos sobre una regin de trabajo, capaces de establecer comunicacin sin cables entre ellos, y que incluyen adems medir variables fsico-ambientales, ya sea niveles de temperatura, humedad, etc., para luego enviar los datos obtenidos a un servidor central en el cual se almacenarn y procesarn. A travs de redes de sensores, se puede integrar funcionalidades que antes eran independientes unas de otras, con el fin de lograr mxima eficiencia y optimizacin de recursos. En el presente trabajo se expondrn distintos sistemas operativos que se pueden ejecutar sobre estas plataformas. Primero ser necesario contextualizar el problema, por lo que se presentarn las restricciones a cumplir tanto para los dispositivos electrnicos (microprocesadores microcontroladores), como para el sistema operativo. De ste ultimo, presentaremos caractersticas, comparaciones, y restricciones de uso de algunas de las propuestas presentes hoy.

Desarrollo

2.1

Caractersticas de las redes de sensores.

Esta seccin ensea los requerimientos que forman el diseo de redes de sensores 1 Tamao fsico pequeo y bajo consumo de energa. En cualquier punto de la evolucin tecnolgica, el tamao y la energa han restringido el procesamiento, almacenamiento, y las capacidades de interconexin de dispositivos. Obviamente si se reduce el tamao y la energa, estamos forzando el uso de nuevos tecnologas en hardware y asimismo en software, el cual debe ser capaz de usar de manera eficiente el procesador y la memoria, ocupando un mnimo de energa para la realizacin de sus tareas.

Operaciones de Concurrencia Intensiva. El principal modo de operacin de estos dispositivos, consiste en que fluya informacin 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 informacin puede ser capturada simultneamente 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 tambin 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 informacin (saltos) implica generalmente una gran cantidad de eventos de bajo nivel (interactuar a niveles de capa fsica y red) que se comunicarn con procesos de niveles superiores (es necesario desempaquetar para obtener informacin).

Diversidad en diseo y uso: La tendencia de los dispositivos de redes de sensores es a dar respuesta a aplicaciones especficas, ms que aplicaciones con fines de uso general, por lo cual slo se compondrn 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 fsicos irn apareciendo. Adems en cualquier dispositivo, es importante montar fcilmente 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 genrico de desarrollo es necesario, con el que se permita la construccin de aplicaciones especficas a partir de un espectro de dispositivos existentes, sin necesidad de partir de cero.

Operacin Robusta. Estos dispositivos sern numerosos, en gran parte desatendidos, y se esperar que tengan un tiempo operacional largo. La implementacin de tcnicas tradicionales de redundancia para garantizar la confiabilidad de unidades individuales, est limitada en muchas ocasiones tanto por el espacio como por la energa. As realzar la confiabilidad de dispositivos individuales es esencial. Adems, 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 tambin debe facilitar el desarrollo de usos distribuidos confiables.

Para un mayor detalle remtase a la lectura de [1]

Adems se tienen ciertos parmetros, que no tienen relacin con restricciones de hardware, sino ms bien con aspectos logsticos, entre las que se destacan: Gastos econmicos que se deban incurrir por parte del que desea desarrollar una aplicacin. Disponibilidad de informacin, en el que se incluye manuales, tutoriales y aplicaciones. Existencia de grupos de desarrolladores, de forma de asegurar una constante depuracin y perfeccionamiento del sistema disponible. Modelo de programacin modular, de forma de adaptarse a nuevas tecnologas, para as por ejemplo reciclar cdigos.

Antes de presentar los distintos sistemas operativos a analizar, resulta necesario definir ciertos aspectos generales en los sistemas operativos, las metodologas de diseo, y los porque de su aplicacin a las redes de sensores inalmbricas.

2.2

Presentacin de distintos Sistemas Operativos

Mltiples son los sistemas operativos para sistemas embebidos, mas no todos satisfacen las restricciones que imponen las Redes de Sensores Inalmbricas (RSI), motivo por el cual quedan descartados inmediatamente. As por ejemplo dada las restricciones de tamao y ahorro de energa de los nodos que conformarn 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 categoras de microprocesadores (poseen alta disponibilidad de memoria, consumo mayor de energa, etc.). De esta forma los sistemas operativos tambin quedan restringidos a funcionar sobre estas arquitecturas. A continuacin se presentarn tres de los principales Sistemas Operativos para redes de sensores, que cumplen con los requisitos expuestos.

2.2.1

TinyOS.

El diseo de TinyOS est basado en responder a las caractersticas y necesidades de las redes de sensores, tales como integracin en un tamao fsico reducido, bajo consumo de energa, operaciones de concurrencia intensiva, diversidad en diseos y usos, y finalmente operaciones robustas para facilitar el desarrollo confiable de aplicaciones. Adems se encuentra optimizado en trminos de uso de memoria y eficiencia de energa. Existen dos niveles de scheduler, uno para los eventos y otro para las tareas. De esta forma permitimos que los eventos (que son rpidamente ejecutables), puedan ser realizados inmediatamente, pudiendo interrumpir a las tareas (que tienen mayor complejidad en comparacin a los eventos). El diseo del Kernel de TinyOS est basado en una estructura de dos niveles de planificacin: Eventos: Pensados para realizar un proceso pequeo (por ejemplo cuando el contador del timer interrumpe, o atender las interrupciones de un conversor anlogo-digital). Adems 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 crticas 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 trmino de ella son funcionen separadas. Esta caracterstica es propia de la programacin orientada a componentes, la cual se presentar en detalle en la seccin siguiente.
Desde ahora en adelante se ocupar este trmino.

Diseo en TinyOS: Modelo de Componentes. TinyOS ha sido desarrollado sobre NesC, un meta-lenguaje que se deriva de C, y que ha sido diseado para responder a las necesidades que existen en los sistemas embebidos. Cada componente usa eventos y comandos que rpidamente permitan la transicin de un estado a otro. Cada componente se asigna temporalmente al contexto de ejecucin mientras duren los cambios del estado. Adems se ha agregado a este modelo la nocin de tareas, que permiten que las componentes soliciten el contexto de ejecucin en la CPU para realizar cmputos 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, ms si pueden ser interrumpidas peridicamente por acontecimientos de una prioridad ms alta (eventos). Actualmente se utiliza una cola simple FIFO (primero en entrar, primero en salir) para el scheduler, no obstante un mecanismo alternativo podra ser agregado fcilmente. Una ventaja secundaria de elegir este modelo de programacin, 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 pequeo scheduler y un grfico 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 continuacin: 1. 2. 3. 4. Manejador de comandos. Manejador de eventos Un frame3 de tamao fijo y estticamente asignado, en el cual se representa el estado interno de la componente. Un bloque con tareas simples.

Figura 2.2.1.1 : Modelo de componentes de TinyOS y su interaccin. La componente declara los comandos que se utilizarn y los eventos a sealizar. Con esta declaracin, los grficos de componentes (modulares) pueden ser compuestos. Este proceso de composicin crea capas o niveles de componentes. Componentes de niveles superiores proveen comandos a las de niveles inferiores, y stos sealan eventos a los componentes de un nivel superior. Para proporcionar una definicin abstracta de la interaccin de dos componentes va 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 retroalimentacin, entregando la informacin del estado al que lo envi. Tpicamente, el manejador de comandos pone los parmetros en el frame y agrega una tarea, en la cola de tareas, para su ejecucin. La respuesta que indica si el comando fue aceptado, se puede sealar por un evento. Los
3

En este caso nos referimos a un bloque que proporciona el contexto en cual se ejecuta el programa y se almacenaran las variables.

comandos dejan los parmetros 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 pequeo) similar al de las rutinas de servicio de interrupciones. Eventos pueden llamar comandos, seales de eventos, agregar tareas, pero no pueden ser sealizados por comandos. Los eventos tienen preferencias sobre las tareas, no as viceversa, dispara interrupciones de eventos de niveles inferiores y deposita la informacin en el frame. Las tareas realizan el trabajo primario. se ejecutan hasta terminar y pueden ser slo 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 implementacin 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 ejecucin en TinyOS. Su buen desempeo y su desarrollo abierto, han afectado positivamente en el mejoramiento del sistema en s, e influido en la creacin de herramientas que facilitan el diseo y trabajo, tales como simuladores, administradores de bases de datos, mquinas virtuales que permiten reprogramacin en lnea, etc. Adems destaca el hecho de contar con una cantidad numerosa de aplicaciones preconstruidas, las que implementan procesamientos de datos y algoritmos de enrutamientos.

2.2.2

PalOS.

Palos est implementado en lenguaje C y por lo tanto facilita emigrar a distintos procesadores. Sin embargo, esto es slo posible porque la capa de abstraccin del hardware est introducida en el software. A continuacin en la figura 2.3.2.1 se muestra la esencia del software para una tarea simple. Independiente del Hardware Interfase Independiente,

Dependencia con el Hardware (Procesador)

figura 2.3.2.1 : Estructura del Software. La capa de abstraccin 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, slo bastar con redefinir las macros, mientras que el cdigo principal no necesitar ser modificado. La capa de Driver exporta las funcionalidades del hardware de una especfica interfaz fsica 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 mtodos de implementacin para una misma funcionalidad, por lo cual a veces es necesario especificar un orden especfico en las lneas de programacin. Finalmente los manejadores (managers) componen la funcionalidad exportada de uno o ms drivers, los que finalmente interaccionan con el hardware a partir de las necesidades que las tareas deban ir cumpliendo. Tareas y su programacin. Cada tarea mantiene una propia cola de eventos. Sin embargo, cada tarea puede poseer una entrada o salida fsica (probablemente, ms tareas sern basadas sobre una interfase fsica). En la fase de inicializacin del programa, cada tarea registra una tarea de eventos en la programacin 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 algn evento para l. Este concepto queda reflejado en el siguiente diagrama.

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 travs de una tarea timer. Esta posee tres colas : la primera para interactuar con las dems tareas recibe el envo de otras tareas-, la otra conocida como Cola Delta, en la cual se ordenan los distintos eventos dependiendo del tiempo de expiracin y que finalmente son enviados a la cola de Eventos Expirados, para su posterior ejecucin. Es importante mencionar ahora que el cdigo del programa consta de un ciclo infinito (loop), en el cual todas las tareas son llamadas secuencialmente. Un modelo de esto sera lo siguiente: void main() { initAll(); while(1) { TASK1(); TASK2(); TASKn(); } }

2.2.3

SOS 4.

SOS es un sistema operativo desarrollado en la Universidad de California, especficamente 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 esttica de muchos de los sistemas precursores a ste (por ejemplo TinyOS). SOS implementa un sistema de mensajera que permite mltiples hebras entre la base del sistema operativo y las aplicaciones, las cuales pasan a ser mdulos que pueden ser cargadas o descargadas en tiempo de ejecucin 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 fsicamente e inicializado su funcionamiento. En el caso de encontrar un problema, en caso de no contar con esta solucin, habra sido necesario recolectar todos los nodos para poder modificar su software. La capacidad de dinmicamente agregar o remover mdulos, permite la construccin de software mucho ms tolerante a fallas. Esto presenta dos grandes ventajas: uno es el hecho de poder realizar updates fcilmente, y el otro es la capacidad de anular el funcionamiento de algn mdulo defectuoso, de algn nodo que pertenece a la red.

Arquitectura del sistema. Adems de las tcnicas tradicionales usadas en el diseo de sistemas embebidos, las caractersticas del kernel de SOS son: Mdulos cargados dinmicamente. Programacin flexible de prioridades. Simple subsistema de memoria dinmica. Las capas de abstraccin de hardware y drivers son las mismas que las descritas en la seccin 2.3.2 para el sistema PalOS. A continuacin se muestra un esquema de la arquitectura de SOS.

figura 2.3.3.1 Capas funcionales de SOS.

4

Informacin obtenida desde http://nesl.ee.ucla.edu/projects/sos/publications/

10

Para mayor informacin acerca de las caractersticas y funcionamiento de SOS remtase a leer el paper A dinamic Operating System for Sensor Nodes [3]

11

2.3

Comparaciones entre estos Sistemas.

A continuacin mostramos cuadros comparativos entre los distintos sistemas operativos presentados. En este primer cuadro se comparan en funcin de ciertos parmetros, el diseo y funcionalidad de los distintos sistemas operativos. SOS Madurez del Cdigo Base Plataformas actualmente soportadas Sensores Soportados Aplicaciones Soportadas Documentacin Lenguaje de Programacin Scheduling6 Localizacin en Memoria Comunidad de Desarrolladores Version inicial AVR and ARM MTS310 (sensor board), xbow En desarrollo Tutorial Bsico C Colas de Prioridad Dinmica Reciente TinyOS Versin estable y aprontndose la versin 2.0 AVR ,MSP430 Crossbow series Establecidas Multiple, repositorio. PalOS Versin estable. AVR,ARM. Los disponibles en los mdulos MK-II. 5 Establecidas Bsica.

nesC C Para tareas implementa FIFO7, interrupciones Controlada por controladas por eventos. eventos. Esttica Muchos Esttica Muchos

Tabla 1: Comparaciones entre los sistemas.

5 6

Plataforma de red de sensores inalmbricos desarrollado en la Universidad de California. 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.

12

A continuacin un cuadro que resume las principales variables a considerarse para la toma de una decisin. TinyOS Programado en nesC, lenguaje especialmente diseador para el funcionamiento de las redes de sensores inalmbricas Si bien no incorpora ni comunicacin entre tareas, ni manejo dinmico de componentes en el sistema nativo, existen aplicaciones que permiten su incorporacin, sin disminuir el desempeo. Versiones estables y en constante desarrollo PalOS Escrito en ansi C SOS Escrito en ansi C

Lenguaje

Flexibilidad y Dinamismo.

Permite comunicacin entre procesos. A travs de las colas de eventos

Permite manejo dinmico de memoria y modificaciones al vuelo

Madurez

Versin estable la define el Loop Principal descrito en la seccin de PalOS. AVR y ARM Tutoriales

An se encuentra en proceso de estandarizacin. AVR y ARM Tutorial Bsico

AVR , MSP430 y Microchip Plataformas Soporte Mucha Documentacin y grupos de apoyo.

Tabla 2. Principales variables a considerarse.

13

Conclusiones.

Dada las caractersticas de las redes de sensores inalmbricas, se hace crtico el uso de tecnologa estable y con perspectivas a futuro. Si bien los tres sistemas estudiados satisfacen las restricciones expuestas en la seccin 2.1, la existencia de una base slida sobre la cual comenzar a desarrollar las aplicaciones, contando con la informacin necesaria, es esencial y crtica. SOS presenta una propuesta innovadora, que integra dentro de su sistema, ciertas carencia que sistemas estndares (TinyOS) presentan, tales como la capacidad de insertar y remover mdulos de software (para actualizaciones por ejemplo), como el hecho de implementar usos de memoria dinmica. Estas caractersticas pueden ser implementadas en sistemas como TinyOS, pero demandan un mayor esfuerzo y un alto nivel de complejidad (mquinas virtuales). Lamentablemente, inherente a su gnesis, su desarrollo se encuentra pasos atrs en lo que a estabilidad y robustez de sistema se refiere. PalOS resulta ser una propuesta ms dbil, 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 solucin a considerar para sistemas que implementan aplicaciones simples. Hoy en da TinyOS se define como el estndar para las redes de sensores inalmbricas, 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 documentacin, las plataformas soportadas (gran disponibilidad de libreras que slo deben ser cargadas en el momento de desarrollar una aplicacin), las mltiples aplicaciones desarrolladas, su madurez y finalmente el amplio uso (que verifica su funcionalidad) hace de TinyOS la alternativa ms segura y conveniente en la hora de tomar una decisin. En lo que a nuestro proyecto se refiere (redes de sensores inalmbricos aplicados a la agricultura), las caractersticas y ventajas de TinyOS son de gran importancia, y es por eso que se trabajar con ste. Sin embargo, dada las caractersticas 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.

14

Referencias.

[1] System Architecture Directions for Networked Sensors Jason Hill, Rober t Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister Depar tment of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA [2] Motivations Behind SOS Roy Shea, Simon Han, Ram Rengaswamy February 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

15