ESTUDIO COMPARATIVO DE SISTEMAS OPERATIVOS DE TIEMPO REAL APLICADO A REDES DE SENSORES INALAMBRICAS.
José Ulloa Suárez.
Sociedad Agrícola Ojos Buenos Ltda.
INDICE
1 Introducción................................................................................................................................................3 2 Desarrollo....................................................................................................................................................4 3 Conclusiones.............................................................................................................................................14 4 Referencias................................................................................................................................................15
2
1
Introducción
Las redes de sensores inalámbricas se insertan bajo un nuevo enfoque en el desarrollo de tecnologías para la obtención de datos, y que son aplicables a variados campos, tales como el policial (seguridad en recintos), industrial (vigilar el estado de maquinarias, de procesos de ensamblaje, etc ), agrícola (sensar estado de la tierra, el crecimiento de los frutos, etc) entre otros. Principalmente estas apuntan a integrar sistemas autónomos, para la obtención conjunta y posterior procesamiento de información. Específicamente hablamos de dispositivos autónomos distribuidos sobre una región de trabajo, capaces de establecer comunicación sin cables entre ellos, y que incluyen además medir variables físico-ambientales, ya sea niveles de temperatura, humedad, etc., para luego enviar los datos obtenidos a un servidor central en el cual se almacenarán y procesarán. A través de redes de sensores, se puede integrar funcionalidades que antes eran independientes unas de otras, con el fin de lograr máxima eficiencia y optimización de recursos. En el presente trabajo se expondrán distintos sistemas operativos que se pueden ejecutar sobre estas plataformas. Primero será necesario contextualizar el problema, por lo que se presentarán las restricciones a cumplir tanto para los dispositivos electrónicos (microprocesadores ó microcontroladores), como para el sistema operativo. De éste ultimo, presentaremos características, comparaciones, y restricciones de uso de algunas de las propuestas presentes hoy.
3
2
Desarrollo
2.1
Características de las redes de sensores.
Esta sección enseña los requerimientos que forman el diseño de redes de sensores 1 •
Tamaño físico pequeño y bajo consumo de energía. En cualquier punto de la evolución tecnológica, el tamaño y la energía han restringido el procesamiento, almacenamiento, y las capacidades de interconexión de dispositivos. Obviamente si se reduce el tamaño y la energía, estamos forzando el uso de nuevos tecnologías en hardware y asimismo en software, el cual debe ser capaz de usar de manera eficiente el procesador y la memoria, ocupando un mínimo de energía para la realización de sus tareas.
•
Operaciones de Concurrencia Intensiva. El principal modo de operación de estos dispositivos, consiste en que fluya información de un lugar a otro, con una cantidad reducida de procesos, que se resumen en aceptar un comando, parar, pensar, y responder. Por ejemplo, la información puede ser capturada simultáneamente por sensores, manipulada, y fluir sobre la red hacia el destinatario. Alternativamente, se pueden recibir datos desde otros nodos y por ende deben ser encaminados también a su destino. En general existe poca capacidad de memoria interna, así que el almacenamiento de cantidades grandes de datos, ya sea para enviar o para ser recibidos desde otros nodos debe ser evitado. Por otra parte, cada uno de las reenvios de información (saltos) implica generalmente una gran cantidad de eventos de bajo nivel (interactuar a niveles de capa física y red) que se comunicarán con procesos de niveles superiores (es necesario desempaquetar para obtener información).
•
Diversidad en diseño y uso: La tendencia de los dispositivos de redes de sensores es a dar respuesta a aplicaciones específicas, más que aplicaciones con fines de uso general, por lo cual sólo se compondrán de lo justo y necesario, esto motivado principalmente para reducir los costos. Dado que existe una amplia gama de usos potenciales, nuevos y variados dispositivos físicos irán apareciendo. Además en cualquier dispositivo, es importante montar fácilmente apenas los componentes de software requeridos, de manera de sintetizar el uso de los componentes de hardware. Es por eso, que estos dispositivos requieren un grado inusual de modularidad en el software. Un ambiente genérico de desarrollo es necesario, con el que se permita la construcción de aplicaciones específicas a partir de un espectro de dispositivos existentes, sin necesidad de partir de cero.
•
Operación Robusta. Estos dispositivos serán numerosos, en gran parte desatendidos, y se esperará que tengan un tiempo operacional largo. La implementación de técnicas tradicionales de redundancia para garantizar la confiabilidad de unidades individuales, está limitada en muchas ocasiones tanto por el espacio como por la energía. Así realzar la confiabilidad de dispositivos individuales es esencial. Además, es posible aumentar la robustez del uso tolerando fallas individuales del dispositivo. A tal efecto, el sistema operativo que funciona en un solo nodo no debe solamente ser robusto, sino también debe facilitar el desarrollo de usos distribuidos confiables.
1
Para un mayor detalle remítase a la lectura de [1]
4
Además se tienen ciertos parámetros, que no tienen relación con restricciones de hardware, sino más bien con aspectos logísticos, entre las que se destacan: • • •
•
Gastos económicos que se deban incurrir por parte del que desea desarrollar una aplicación. Disponibilidad de información, en el que se incluye manuales, tutoriales y aplicaciones. Existencia de grupos de desarrolladores, de forma de asegurar una constante depuración y perfeccionamiento del sistema disponible. Modelo de programación modular, de forma de adaptarse a nuevas tecnologías, para así por ejemplo reciclar códigos.
Antes de presentar los distintos sistemas operativos a analizar, resulta necesario definir ciertos aspectos generales en los sistemas operativos, las metodologías de diseño, y los porque de su aplicación a las redes de sensores inalámbricas. 2.2
Presentación de distintos Sistemas Operativos
Múltiples son los sistemas operativos para sistemas embebidos, mas no todos satisfacen las restricciones que imponen las Redes de Sensores Inalámbricas (RSI), motivo por el cual quedan descartados inmediatamente. Así por ejemplo dada las restricciones de tamaño y ahorro de energía de los nodos que conformarán la red, es que todos aquellos microprocesadores que no sean de bajo consumo, quedan descartados. Por lo general entre estos, se incluyen los iguales o superiores a los clasificados como de “rango mediano” dentro de las categorías de microprocesadores (poseen alta disponibilidad de memoria, consumo mayor de energía, etc.). De esta forma los sistemas operativos también quedan restringidos a funcionar sobre estas arquitecturas. A continuación se presentarán tres de los principales Sistemas Operativos para redes de sensores, que cumplen con los requisitos expuestos.
2.2.1
TinyOS.
El diseño de TinyOS está basado en responder a las características y necesidades de las redes de sensores, tales como integración en un tamaño físico reducido, bajo consumo de energía, operaciones de concurrencia intensiva, diversidad en diseños y usos, y finalmente operaciones robustas para facilitar el desarrollo confiable de aplicaciones. Además se encuentra optimizado en términos de uso de memoria y eficiencia de energía. Existen dos niveles de scheduler , uno para los eventos y otro para las tareas. De esta forma permitimos que los eventos (que son rápidamente ejecutables), puedan ser realizados inmediatamente, pudiendo interrumpir a las tareas (que tienen mayor complejidad en comparación a los eventos). El diseño del Kernel de TinyOS está basado en una estructura de dos niveles de planificación: •
•
2
Eventos: Pensados para realizar un proceso pequeño (por ejemplo cuando el contador del timer interrumpe, o atender las interrupciones de un conversor análogo-digital). Además pueden interrumpir las tareas que se ejecutan. . El manejador de eventos es responsable de colocar la tarea en un “administrador” o “planificador”, conocido como “Scheduler 2” de tareas. Tareas: Pensadas para hacer una cantidad mayor de procesamiento y que no son críticas en tiempo (por ejemplo calcular el promedio en un arreglo). Las tareas se encuentran pensadas para ser ejecutadas en su totalidad, pero la solicitud de iniciar una tarea, y el término de ella son funcionen separadas. Esta característica es propia de la programación orientada a componentes, la cual se presentará en detalle en la sección siguiente. Desde ahora en adelante se ocupará este término.
5
Diseño en TinyOS: Modelo de Componentes.
TinyOS ha sido desarrollado sobre NesC, un meta-lenguaje que se deriva de C, y que ha sido diseñado para responder a las necesidades que existen en los sistemas embebidos. Cada componente usa eventos y comandos que rápidamente permitan la transición de un estado a otro. Cada componente se asigna temporalmente al contexto de ejecución mientras duren los cambios del estado. Además se ha agregado a este modelo la noción de “tareas”, que permiten que las componentes soliciten el contexto de ejecución en la CPU para realizar cómputos o procesamientos duraderos. Estas tareas se ejecutan completamente con respecto a otras tareas, es decir, las tareas no pueden dividirse para comenzar con otra y luego retomarlas, más si pueden ser interrumpidas periódicamente por acontecimientos de una prioridad más alta (eventos). Actualmente se utiliza una cola simple FIFO (primero en entrar, primero en salir) para el scheduler , no obstante un mecanismo alternativo podría ser agregado fácilmente. Una ventaja secundaria de elegir este modelo de programación, es que propaga las abstracciones del hardware en el software. Tal como el hardware responde a cambios de estado en sus pines de entrada/salida, nuestras componentes responden a eventos y a los comandos en sus interfaces. Podemos entonces decir que TinyOS consiste en un pequeño scheduler y un gráfico de componentes. Esto se puede observar en la figura 2.2.1.1, donde se muestra como se compone una componente, destacando cuatro elementos correlacionados, y que procedemos a detallar continuación: 1. Manejador de comandos. 2. Manejador de eventos 3. Un frame3 de tamaño fijo y estáticamente asignado, en el cual se representa el estado interno de la componente. 4. Un bloque con tareas simples.
Figura 2.2.1.1 : Modelo de componentes de TinyOS y su interacción.
La componente declara los comandos que se utilizarán y los eventos a señalizar. Con esta declaración, los gráficos de componentes (modulares) pueden ser compuestos. Este proceso de composición crea capas o niveles de componentes. Componentes de niveles superiores proveen comandos a las de niveles inferiores, y éstos señalan eventos a los componentes de un nivel superior. Para proporcionar una definición abstracta de la interacción de dos componentes vía comandos y eventos, es que se introduce una interfaz bidireccional en TinyOS. Los comandos son peticiones no-bloqueadoras, hechas a componentes de capas inferiores. Un comando proporciona retroalimentación, entregando la información del estado al que lo envió. Típicamente, el manejador de comandos pone los parámetros en el frame y agrega una tarea, en la cola de tareas, para su ejecución. La respuesta que indica si el comando fue aceptado, se puede señalar por un evento. Los 3
En este caso nos referimos a un “bloque” que proporciona el contexto en cual se ejecuta el programa y se almacenaran las variables.
6
comandos dejan los parámetros de las solicitudes en el frame, la necesidad de volver estado así que pospone el trabajo desperdiciador de tiempo fijando una tarea y puede llamar al comando de nivel inferior. Los manejadores de eventos son invocados por eventos de componentes de capas inferiores, o por interrupciones cuando se esta directamente conectado al hardware. Similar a los comandos, el frame será modificado y las tareas agregadas. Ambos, tareas y comandos, realizan un trabajo (fijo y pequeño) similar al de las rutinas de servicio de interrupciones. Eventos pueden llamar comandos, señales de eventos, agregar tareas, pero no pueden ser señalizados por comandos. Los eventos tienen preferencias sobre las tareas, no así viceversa, dispara interrupciones de eventos de niveles inferiores y deposita la información en el frame. Las tareas realizan el trabajo primario. se ejecutan hasta terminar y pueden ser sólo pospuestas por eventos, por ejemplo, el enrutar un paquete que llegó al nodo. Las tareas son encoladas en un planificador de tareas ( task scheduler ) implementado con FIFO para realizar un retorno inmediato de las rutinas manejadores de eventos y comandos. Debido a su implementación FIFO, las tareas se ejecutan secuencialmente y deben ser cortas. Alternativamente al planificador de tareas FIFO, planificadores basados en prioridades (priority-based) o basados en plazos ( deadline-based ), pueden ser puestos en ejecución en TinyOS. Su buen desempeño y su desarrollo abierto, han afectado positivamente en el mejoramiento del sistema en sí, e influido en la creación de herramientas que facilitan el diseño y trabajo, tales como simuladores, administradores de bases de datos, máquinas virtuales que permiten reprogramación en línea, etc. Además destaca el hecho de contar con una cantidad numerosa de aplicaciones preconstruidas, las que implementan procesamientos de datos y algoritmos de enrutamientos.
7
2.2.2
PalOS.
Palos está implementado en lenguaje C y por lo tanto facilita emigrar a distintos procesadores. Sin embargo, esto es sólo posible porque la capa de abstracción del hardware está introducida en el software. A continuación en la figura 2.3.2.1 se muestra la esencia del software para una tarea simple. Independiente del Hardware Interfase Independiente,
Dependencia con el Hardware (Procesador)
figura 2.3.2.1 : Estructura del Software. La capa de abstracción del hardware (Register abstraction) encapsula todos los registros en macros (de esta forma no es necesario estar configurando a nivel de bits). Esto es útil, dado que en el momento que la arquitectura del procesador cambie, sólo bastará con redefinir las macros, mientras que el código principal no necesitará ser modificado. La capa de Driver exporta las funcionalidades del hardware de una específica interfaz física sobre el procesador, a la interfaz independiente (Manager). Un driver es casi independiente del hardware del procesador. Una de las razones de su independencia, es porque distintos procesadores proveen diferentes métodos de implementación para una misma funcionalidad, por lo cual a veces es necesario especificar un orden específico en las líneas de programación. Finalmente los manejadores (managers) componen la funcionalidad exportada de uno o más drivers, los que finalmente interaccionan con el hardware a partir de las necesidades que las tareas deban ir cumpliendo. Tareas y su programación.
Cada tarea mantiene una propia cola de eventos. Sin embargo, cada tarea puede poseer una entrada o salida física (probablemente, más tareas serán basadas sobre una interfase física). En la fase de inicialización del programa, cada tarea registra una tarea de eventos en la programación del sistema. Si la tarea 1 desea hablar con la tarea 2, postea un evento en la cola de eventos de la tarea 2, usando una funcionalidad del “Programador del Sistema” (System Scheduler), para luego la tarea 2 capture ese evento al preguntar al “Programador del Sistema” si tiene algún evento para él. Este concepto queda reflejado en el siguiente diagrama.
8
figura 2.3.2.2 Programador del Sistema. Para un correcto funcionamiento de esta estructura de software, es necesario que un “timer” maneje la periodicidad con que una tarea registra eventos. La forma en que se implementa es a través de una tarea “timer”. Esta posee tres colas : la primera para interactuar con las demás tareas –recibe el envío de otras tareas-, la otra conocida como “Cola Delta”, en la cual se ordenan los distintos eventos dependiendo del tiempo de expiración y que finalmente son enviados a la cola de “Eventos Expirados”, para su posterior ejecución. Es importante mencionar ahora que el código del programa consta de un ciclo infinito (loop), en el cual todas las tareas son llamadas secuencialmente. Un modelo de esto sería lo siguiente: void main() { initAll(); … while(1) { TASK1(); TASK2(); … TASKn(); } }
9
2.2.3
SOS 4.
SOS es un sistema operativo desarrollado en la Universidad de California, específicamente en el NESL (Networked & Embedded Systems Laboratory). SOS es un sistema operativo para redes de sensores que procura remediar algunos de las limitaciones propias de la naturaleza estática de muchos de los sistemas precursores a éste (por ejemplo TinyOS). SOS implementa un sistema de mensajería que permite múltiples hebras entre la base del sistema operativo y las aplicaciones, las cuales pasan a ser módulos que pueden ser cargadas o descargadas en tiempo de ejecución sin interrumpir la base del sistema operativo. El principal objetivo de SOS es la “ reconfigurabilidad”. Ésta se define como la habilidad para modificar el software de nodos individuales de una red de sensores, una vez que estos han sido desplegados físicamente e inicializado su funcionamiento. En el caso de encontrar un problema, en caso de no contar con esta solución, habría sido necesario recolectar todos los nodos para poder modificar su software. La capacidad de dinámicamente agregar o remover módulos, permite la construcción de software mucho más tolerante a fallas. Esto presenta dos grandes ventajas: uno es el hecho de poder realizar updates fácilmente, y el otro es la capacidad de anular el funcionamiento de algún módulo defectuoso, de algún nodo que pertenece a la red.
Arquitectura del sistema.
Además de las técnicas tradicionales usadas en el diseño de sistemas embebidos, las características del kernel de SOS son: Módulos cargados dinámicamente. Programación flexible de prioridades. Simple subsistema de memoria dinámica. • • •
Las capas de abstracción de hardware y drivers son las mismas que las descritas en la sección 2.3.2 para el sistema PalOS. A continuación se muestra un esquema de la arquitectura de SOS.
figura 2.3.3.1 Capas funcionales de SOS. 4
Información obtenida desde http://nesl.ee.ucla.edu/projects/sos/publications/
10
Para mayor información acerca de las características y funcionamiento de SOS remétase a leer el paper “A dinamic Operating System for Sensor Nodes” [3]
11
2.3
Comparaciones entre estos Sistemas.
A continuación mostramos cuadros comparativos entre los distintos sistemas operativos presentados. En este primer cuadro se comparan en función de ciertos parámetros, el diseño y funcionalidad de los distintos sistemas operativos.
Madurez del Código Base Plataformas actualmente soportadas Sensores Soportados Aplicaciones Soportadas Documentación Lenguaje de Programación
Scheduling 6 Localización en Memoria Comunidad de Desarrolladores
SOS
TinyOS
PalOS
Version inicial
Versión estable y aprontándose la versión 2.0
Versión estable.
AVR and ARM MTS310 (sensor board), xbow
AVR ,MSP430 Crossbow series
AVR,ARM. Los disponibles en los módulos MK-II. 5
En desarrollo Tutorial Básico
Establecidas Multiple, repositorio.
Establecidas Básica.
C Colas de Prioridad
nesC C Para tareas implementa FIFO7, interrupciones Controlada por controladas por eventos. eventos.
Dinámica
Estática
Estática
Reciente
Muchos
Muchos
Tabla 1: Comparaciones entre los sistemas.
5
Plataforma de red de sensores inalámbricos 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”. 6
12
A continuación un cuadro que resume las principales variables a considerarse para la toma de una decisión.
Lenguaje
Flexibilidad y Dinamismo.
Madurez
TinyOS
PalOS
SOS
Programado en nesC, lenguaje especialmente diseñador para el funcionamiento de las redes de sensores inalámbricas Si bien no incorpora ni comunicación entre tareas, ni manejo dinámico de componentes en el sistema nativo, existen aplicaciones que permiten su incorporación, sin disminuir el desempeño. Versiones estables y en constante desarrollo
Escrito en ansi C
Escrito en ansi C
Permite comunicación entre procesos. A través de las colas de eventos
Permite manejo dinámico de memoria y modificaciones “al vuelo”
Versión estable la define el “Loop Principal” descrito en la sección de PalOS. AVR y ARM
Aún se encuentra en proceso de estandarización.
AVR , MSP430 y Microchip
AVR y ARM
Plataformas Soporte
Mucha Documentación y grupos de apoyo.
Tutoriales
Tutorial Básico
Tabla 2. Principales variables a considerarse.
13
3
Conclusiones.
Dada las características de las redes de sensores inalámbricas, se hace crítico el uso de tecnología estable y con perspectivas a futuro. Si bien los tres sistemas estudiados satisfacen las restricciones expuestas en la sección 2.1, la existencia de una base sólida sobre la cual comenzar a desarrollar las aplicaciones, contando con la información necesaria, es esencial y crítica. SOS presenta una propuesta innovadora, que integra dentro de su sistema, ciertas carencia que sistemas estándares (TinyOS) presentan, tales como la capacidad de insertar y remover módulos de software (para actualizaciones por ejemplo), como el hecho de implementar usos de memoria dinámica. Estas características pueden ser implementadas en sistemas como TinyOS, pero demandan un mayor esfuerzo y un alto nivel de complejidad (máquinas virtuales). Lamentablemente, inherente a su génesis, su desarrollo se encuentra pasos atrás en lo que a estabilidad y robustez de sistema se refiere. PalOS resulta ser una propuesta más débil, su desarrollo y estudio por parte de grupos de usuario es bastante pobre principalmente debido a la simplicidad de su sistema. A criterio, PalOS resulta ser una solución a considerar para sistemas que implementan aplicaciones simples. Hoy en día TinyOS se define como el estándar para las redes de sensores inalámbricas, debido principalmente a su extenso uso por parte de desarrolladores de aplicaciones para este tipo de sistemas. La gran cantidad de grupos de trabajo, el soporte existente en documentación, las plataformas soportadas (gran disponibilidad de librerías que sólo deben ser cargadas en el momento de desarrollar una aplicación), las múltiples aplicaciones desarrolladas, su madurez y finalmente el amplio uso (que verifica su funcionalidad) hace de TinyOS la alternativa más segura y conveniente en la hora de tomar una decisión. En lo que a nuestro proyecto se refiere (redes de sensores inalámbricos aplicados a la agricultura), las características y ventajas de TinyOS son de gran importancia, y es por eso que se trabajará con éste. Sin embargo, dada las características de SOS, estaremos revisando constantemente el desarrollo y los avances que éste pueda presentar, de forma de estar al tanto y poder ir así analizando las innovaciones que éste genere.
14
4
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
