Modelos de programación en WSN

Post date: Jul 4, 2011 9:21:35 PM

Con el desarrollo de las redes de sensores inalámbricas se han planteado diversos modelos de programación de las mismas. ¿Qué modelo es el más apropiado para la programación de dichas redes?, bien, bajo mi opinión, antes de contestar a dicha pregunta necesitamos conocer aspectos como la aplicación que queremos desarrollar, la tipología de los nodos que van a formar la red de sensores e incluso, como veremos mas adelante, qué topología tiene nuestra red, todos estos elementos puede influir en qué modelo adoptamos a la hora de programar. También es necesario estudiar los diversos roles (programador de aplicaciones, programador de sistemas empotrados, integrador, etc.) y cómo afectará la elección del modelo de programación a su trabajo.

Ni que decir tiene que como el dicho "A un tonto con un martillo todo le parecen clavos" los expertos en cada uno de los modelos dicen que el suyo es el mejor y sirve para todos los casos.

Mostremos un ejemplo con uno de los modelos que mas atención han recibido por parte de los investigadores en el campo de las redes inalámbricas, el modelo de base de datos. Sin lugar a dudas, el mejor y mas conocido ejemplo de este tipo es TinyDB (http://telegraph.cs.berkeley.edu/tinydb/). La idea de este modelo de programación es bastante intuitiva, tenemos una base de datos con una tabla donde las diferentes filas representan cada uno de los sensores

distribuidos en la red. Esta tabla generalmente es actualizada por los datos de la propia WSN y se encuentra alojada en el Sink de la red.

Desde el punto de vista del programador de aplicaciones es bastante cómodo este modelo ya que le permite acceder a los datos de los sensores mediante una tecnología bien conocida, y la cual probablemente le es familiar, como es la de acceso a base de datos. Desde el punto de vista del programador de sistemas empotrados el principal beneficio es que le da libertad para utilizar el

protocolo mas apropiado a la topología de la red y a las características de los nodos inalámbricos para la recolección de datos.

El integrador, entendido como el responsable de que los datos de la WSN se integren efectivamente en la base de datos, tiene una labor algo mas complicada. Necesita desarrollar un componente que entienda el protocolo para recopilar la información de la WSN y la inserte en la base de datos. Uno de los problemas asociados es que posiblemente el módulo sea dependiente de la aplicación. Si desde el punto de vista de la topología tenemos mas de un Sink (bien para ser tolerantes a fallos o para evitar el "Sink hole" que se produce en los nodos vecinos a un único Sink) el problema para evitar duplicidades en la

base de datos y mantenerla consistente puede ser un problema. No digamos si debemos tener varias bases de datos que atienden a diferentes aplicaciones.

Con sus restricciones y ventajas, este tipo de programación es adecuado siempre y cuando estemos ante una WSN relativamente homogénea cuyo principal cometido sea la de recolectar la misma información a intervalos regulares ya que se simplifica el desarrollo de la base de datos. Monitorización de espacios medioambientales y control de agricultura pueden ser ejemplos de este tipo de aplicaciones. Es necesario resaltar entre sus ventajas la escalabilidad de la solución como modelo de programación, otra cosa es el protocolo utilizado dentro de la red de sensores para recolectar la información.

Cuando la red es mas heterogénea, en cuanto al número de sensores y su tipología, este modelo puede no ser el mas apropiado. Por ejemplo, en entornos de control del perímetro (surveillance) y seguridad donde el número y tipología de sensores es mas ámplio (volumétricos, de apertura de ventanas/puertas, de rotura de cristales, de humo, etc.) y donde está mas dirigido a eventos. En este caso la aproximación mas lógica es la programación orientada a eventos.

Un ejemplo de programación orientada a eventos es Remora (http://folk.uio.no/amirhost/remora/) que, bajo un modelo de componentes, permite una gestión de eventos ligera. Quizás no sea tan conocido y esté tan maduro como TinyDB pero es un buen ejemplo de este tipo de programación.

Como todo "Event-driven programming" su principal ventaja es que no necesita mucha memoria y se puede utilizar para aquellos tipos de aplicaciones donde precisamente se gestionan eventos. En realidad, y desde el punto de vista de los nodos que forman parte de la WSN, podemos asumir eventos periódicos para alimentar una base de datos en el Sink y a partir de este punto, utilizar el modelo de programación de bases de datos.

Volviendo al modelo de programación orientada a eventos, desde el punto de vista del desarrollador de la aplicación se necesitan gestionar los eventos que se reciben. Esto puede volverse complicado si de nuevo podemos recibir eventos duplicados, si el orden es importante, etc.

Desde el punto de vista del desarrollador de sistemas empotrados casi todos los sistemas operativos para WSN soportan este modelo de programación (al menos contiki y tinyOS lo hacen) por lo que se debe encargar de las tareas de comunicación y del protocolo utilizado para propagar estos eventos.

Por último, en este modelo, el integrador debe, de nuevo gestionar el tema de los eventos en cuanto a duplicidad, orden, garantía de entrega, etc. que se complica de manera extraordinaria a menos que haga uso de un middleware apropiado.

Aunque existen mas modelos de programación la última parte de este post tiene que estar obligatoriamente dedicado a la adaptación de middleware distribuidos orientada a objetos que hemos desarrollado en el seno del grupo Arco al cual pertenezco.

En este caso la idea también es bastante intuitiva, se define una interfaz de acceso a los sensores (que podrían utilizarse para generarse eventos) y a partir de las herramientas asociadas se genera toda la parte del código de comunicaciones entre la aplicación y los sensores. En nuestros desarrollos utilizamos como punto de partida un middleware orientado a objetos distribuidos (ZeroC ICE www.zeroc.com) y desarrollamos las herramientas para generar de forma automática la parte que va en los nodos de la WSN.

Desde el punto de vista del desarrollador de aplicaciones el acceso a los sensores se realiza como un acceso a un objeto normal y corriente mediante su interfaz (con independencia de la tecnología empleada y con transparencia de localización del mismo). Este modelo nos sirve tanto para redes de sensores como para redes de actuadores. Si tenemos una aplicación mas homogénea, se pueden generar eventos pero la gestión de los mismos de puertas hacia afuera de la WSN corre de parte del middleware. En el caso del programador de sistemas empotrados su labor simplemente es la de programar la lectura de los sensores o accionar los actuadores en cada nodo ya que la parte de comunicaciones específica de la aplicación se genera de forma automática.

Por último, en el caso de los integradores, su labor queda casi prácticamente limitada a establecer y configurar pasarelas entre las tecnologías a nivel de enlace ya que los bridges que se utilizan son totalmente genéricos.

La fiabilidad de este tipo de programación orientada a objetos distribuidos esta ámpliamente demostrada en la industria en grandes proyectos distribuidos tanto en el ámbito civil como en el militar. La extensión que hemos realizado para integrar en estos sistemas las redes de sensores inalambricas nos permite contar con una herramienta poderosa de cara al diseño e implementación de grandes sistemas distribuidos de control y monitorización donde las WSN sean una pieza fundamental.