Download info TinyOS i nesc

ESTUDIO COMPARATIVO DE SISTEMAS OPERATIVOS DE
TIEMPO REAL APLICADO A REDES DE SENSORES
INALAMBRICAS.
José Ulloa Suárez.
Sociedad Agrícola Ojos Buenos Ltda.
INDICE
1
Introducción ........................................................................................................................................ 3
2
Desarrollo ........................................................................................................................................... 4
2.1
Características de las redes de sensores. .................................................................................... 4
2.2
Presentación de distintos Sistemas Operativos .......................................................................... 5
2.2.1
TinyOS. ................................................................................................................................ 5
2.2.2
PalOS. ................................................................................................................................... 8
2.2.3
SOS . ................................................................................................................................... 10
2.3
Comparaciones entre estos Sistemas. ...................................................................................... 12
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:

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.
2
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.
2.
3.
4.
Manejador de comandos.
Manejador de eventos
Un frame3 de tamaño fijo y estáticamente 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 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
En este caso nos referimos a un “bloque” que proporciona el contexto en cual se ejecuta el programa y se almacenaran las
variables.
3
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.
SOS
Madurez del
Código Base
Plataformas
actualmente
soportadas
Sensores
Soportados
Aplicaciones
Soportadas
Documentación
Lenguaje de
Programación
Scheduling6
Localización en
Memoria
Comunidad de
Desarrolladores
TinyOS
Versión estable y
aprontándose la versión
2.0
PalOS
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
Version inicial
Versión estable.
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.
Aún se encuentra en
proceso de
estandarización.
AVR , MSP430 y Microchip
AVR y ARM
AVR y ARM
Mucha Documentación y grupos
de apoyo.
Tutoriales
Tutorial
Básico
Plataformas
Soporte
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