3_Arquitectura_del_software

Vista previa del material en texto

Capítulo 3
Arquitectura del software
3.1. Introducción
El software que se ejecuta en los nodos de la WSN utiliza los componen-
tes proporcionados por TinyOS para abstraer detalles de implementación
hardware del mote en cuestión. El software desarrollado se estructura en dos
capas: Aplicación y Middleware. El middleware proporciona las funciones ne-
cesarias para implementar las funciones de comunicación Publish/Subscribe
descritas en la sección 2.1.1. La capa de aplicación, por otra parte, se en-
carga de proporcionar al middleware información sobre el mote: qué tipo
de información es capaz de proveer y cómo obtener dicha información. Esta
arquitectura permite el uso del mismo middleware en todos los motes, in-
dependientemente de los sensores que tengan. La aplicación proporciona las
funciones necesarias para acceder a la información de los sensores de forma
independiente del hardware.
La �gura 3.1 muestra una visión general de la arquitectura descrita.
3.2. Capa de aplicación
La capa de aplicación debe proporcionar una serie de funciones que permi-
tan el acceso a los datos recogidos por los sensores. La comunicación entre la
aplicación y el middleware tiene lugar a través de una interfaz implementada
mediante TinySchema (ver [4]). Dicha interfaz es descrita en la sección 3.4.
La aplicación debe determinar qué información es capaz de proveer el nodo.
Este dato vendrá dado por el número y tipo de sensores conectados a él.
La aplicación registra dichos sensores en la interfaz con el middleware, y
17
CAPÍTULO 3. ARQUITECTURA DEL SOFTWARE 18
Figura 3.1: Arquitectura del software
proporciona un función (call-back function) para acceder a los valores de
los mismos. Estos valores deben ser devueltos por la función en un formato
estándar (por ejemplo, en unidades del sistema internacional). El objetivo es
proporcionar información que no dependa de la implementación concreta del
sensor, de manera que el mismo middleware pueda ser empleado en todos los
nodos.
También es posible enviar comandos a la aplicación para realizar ciertas
acciones (por ejemplo, calibrar un sensor). La aplicación debe registrar una
función (call-back function) que es invocada por el middleware cuando llega
la orden de ejecución de dicho comando. El registro de esa función también
se realiza a través de la interfaz aplicación-middleware.
3.3. Capa Middleware
El middleware provee acceso n modo Publish/Subscribe a la información
recogida por la WSN. El middleware proporciona al usuario de la WSN abs-
tracciones, como grupos basados en condiciones ambientales. El middleware
accede a los valores de los sensores a través de las funciones proporcionadas
por la aplicación y registradas en la interfaz aplicación-middleware. Tam-
bién invoca la ejecución de comandos cuando éstos llegan a través del canal
CAPÍTULO 3. ARQUITECTURA DEL SOFTWARE 19
Figura 3.2: Interfaz entre aplicación y middleware (componentes e interfaces
de TinyOS)
correspondiente (ver sección 2.1.2
3.4. Interfaz aplicación - middleware
La interfaz entre la aplicación y el middleware se ha implementado median-
te el uso de TinySchema. TinySchema está formado por una serie de compo-
nentes de TinyOS que proporcionan abstracciones como atributos, comandos
y eventos para la comunicación y la compartición de información entre com-
ponentes (ver [4]). La interfaz usa comandos y atributos de TinySchema para
implementar la comunicación entre la aplicación y el middleware. En la �gura
3.2 se muestran los componentes e interfaces (en terminología de TinyOS)
que son parte de dicha interfaz.
3.4.1. Atributos
Tras la inicialización del mote, la aplicación registra los sensores como
atributos de TinySchema. Cuando se registra una atributo es necesario, en-
tre otras cosas, proporcionar una función para actualizar el valor de dicho
atributo. En este caso dicha función debe proporcionar el valor de la lectura
del sensor en unidades del sistema internacional (o cualquier otro convenio,
pero que sea el mismo en todos los motes). Dicha función forma parte de la
aplicación. Posteriormente, el middleware puede solicitar el valor de la lectu-
ra de un sensor a TinySchema. Cuando esto sucede, TinySchema se encarga
de invocar la función proporcionada por la aplicación para la lectura de dicho
sensor y devolver el valor a middleware. Todas las operaciones se realizan por
fases, por lo que no se desperdicia tiempo de CPU esperando la respuesta
por parte del sensor (ver sección A.1).
CAPÍTULO 3. ARQUITECTURA DEL SOFTWARE 20
3.4.2. Comandos
Los comandos se implementan mediante la abstracción command de TinyS-
chema. La aplicación registra los comandos disponibles a través de TinySche-
ma, proporcionando una función call-back para dicho comando. Cuando el
middleware recibe un mensaje a través del canal de comandos, invoca dicho
comando a través de TinySchema, lo cual provoca la ejecución de la función
call-back proporcionada por la aplicación. El comando puede tener paráme-
tros que se pasan a la función call-back. Estos parámetros pueden determinar
la acción de realizará el comando. Por lo tanto, es posible implementar varios
comandos efectivos a través del paso de parámetros a un solo comando.
3.5. Implementación
En este capítulo se describe la arquitectura básica del software desarrollado
en términos de componentes e interfaces de TinyOS. Para una descripción
en detalle remitimos al lector al documento completo del proyecto, en inglés,
disponible junto con este resumen.
El software desarrollado se basa en dos componentes principales: App y
MW. Ambas son con�guraciones que proporcionan el cableado entre compo-
nentes internos que son los que realmente implementan las funcionalidades.
App y MW interaccionan a través de TinySchema y de la interfaz AppMW.
Existen otros componentes en el programa que añaden las funcionalidades de
Delta (ver sección 7.3, que no serán tratados en este documento debido a que
son componentes auxiliares proporcionados por el fabricante de los motes,
Moteiv.
Componente MW El componente MW establece el cableado entre los
componentes: CommandMng, GroupMng y ChannelMngC . El primero de
ellos recibe comandos a través de Drip (ver sección 6.2.3) e invoca el coman-
do correspondiente a través de TinySchema (sección 3.4.2). Los dos últimos
implementan las funcionalidades descritas en 4 y 5 respectivamente.