EN los últimos años está adquiriendo cada vez

Acabando con los desarrollos ad-hoc en

Wireless Sensor Networks

Soledad Escolar, Jes´us Carretero, F´elix Garc´ıa, Florin Isaila, Javier Fern´andez

Resumen— En la actualidad, los sistemas

dis-tribuidos est´an aplicando ingenier´ıa del software y est´andares abiertos para la construcci´on de grandes sistemas robustos y f´acilmente configurables donde la unidad b´asica de reemplazo es el componente. La literatura en Wireless Sensor Networks (WSN), tecnolog´ıa recientemente emergente, presenta por el contrario una abolici´on de esas t´ecnicas como res-puesta a las fuertes restricciones imres-puestas por el hardware. Por tanto, el software construido para estas redes presenta caracter´ısticas del software de anta˜no: monol´ıtico, ad−hoc e incompatible entre s´ı. Este trabajo estudia el estado actual de las WSN y Model Driven Architecture (MDA), un est´andar am-pliamente utilizado para guiar el desarrollo de grandes sistemas distribuidos. La aportaci´on principal de este trabajo es fusionar ambos en una primitiva versi´on de arquitectura middleware basado en componentes que resulte factible para cubrir los principales desafos en WSN.

Palabras clave— Wireless Sensor Networks, Model

Driven Architecture, Model Driven Middleware, Middleware basado en Componentes, Componente, OMG, Reusabilidad.

I. Introducci´on

E

N los ´ultimos a˜nos est´a adquiriendo cada vez mayor importancia una nueva tecnolog´ıa basada en peque˜nos dispositivos capaces de monitorizar el entorno mediante sensores que se disponen de una manera ad−hoc en un determinado ´area. Esta tecnolog´ıa ha sido denominada redes de sensores inal´ambricas (WSN) y est´an integradas por unos dis-positivos con caracter´ısticas de sistemas empotrados (QNX o VXWORKS)[1] y con otras caracter´ısticas presentes en sistemas de prop´osito general[2]. A´un as´ı, las WSN plantean fuertes restricciones hardware superando cualquier presupuesto limitado en los sis-temas empotrados de la actualidad. En particular, su tama˜no extremadamente peque˜no, su tiempo de vida expuesto a bater´ıas no renovables y su inte-graci´on en terrenos inh´ospitos han dificultado el de-sarrollo de soluciones por parte de la comunidad de investigadores.

Ante este gran desaf´ıo, diversas soluciones par-ciales e incompletas han tenido lugar en los ´ultimos a˜nos. Importantes equipos de investigadores a lo largo del mundo han ido proporcionando soluciones diferentes para los mismos problemas, pero incom-patibles entre s´ı[3]. Al mismo tiempo, el concepto de reusabilidad del software se ha convertido en parte esencial del desarrollo en otros entornos distribuidos [4]. Un ejemplo claro es la definici´on de arquitecturas

Universidad Carlos III de Madrid. Ar-quitectura y Tecnolog´ıa de Computa-dores. e-mail : sescolar@arcos.inf.uc3m.es, jcarrete@arcos.inf.uc3m.es, fgarcia@arcos.inf.uc3m.es florin@arcos.inf.uc3m.es jfernand@arcos.inf.uc3m.es

middleware que son dise˜nadas teniendo en mente los principios de modelado de la ingenier´ıa del software como dogma para proporcionar sistemas reusables que puedan ser compuestos, configurados e instala-dos para crear sistemas robustos [5]. El concepto clave en esta idea gira entorno al componente soft-ware, cuya integraci´on posibilita la creaci´on de sis-temas, donde el propio sistema es considerado un componente, permitiendo as´ı el ensamblado de sis-temas de sissis-temas. En este sentido, la tendencia m´as clara ha sido el uso del est´andar Model Driven Archi-tecture (MDA)[6] de OMG [7] que permite el dise˜no conducido por modelos mediante vistas del sistema. Sin embargo, el estado del arte en redes de sensores adolece del empleo de una ingenier´ıa de software ca-paz de analizar y resolver los desaf´ıos planteados[8]. En particular, caracter´ısticas como la flexibilidad, el reuso y la compatibilidad entre distintas plataformas y sistemas operativos, representan problemas a´un sin resolver.

Este trabajo inicia la investigaci´on para aplicar el est´andar MDA a una todav´ıa reciente tecnolog´ıa, fusionando as´ı los conceptos de reusabilidad de in-genier´ıa del software con las incipientes redes de sensores inal´ambricas. Para ello se propone la definici´on de un middleware basado en componentes para WSN definido mediante los principios de MDA, benefici´andose de las ventajas que el seguimiento de un est´andar aporta para convertir el dise˜no de soft-ware de las WSN en una tarea ingenieril.

El resto del art´ıculo se organiza como sigue. La Secci´on 2 presenta el estado del arte de las WSN. En la Secci´on 3 se da una breve introducci´on a MDA y su aplicaci´on en otros sistemas distribuidos. La Secci´on 4 describe la arquitectura del middleware basado en componentes para WSN. Los trabajos futuros deriva-dos a partir de este trabajo se presentan en la Secci´on 5. Por ´ultimo, las conclusiones se muestran en la Secci´on 6.

II. Wireless Sensor Networks

En el a˜no 2003 el MIT identific´o las WSN como una de las 10 tecnolog´ıas emergentes que cambiar´ıan el mundo[9]. Por aquel entonces, las redes de sen-sores inal´ambricas se limitaban a un conjunto de aplicaciones muy b´asicas pero de gran potencial ya que por primera vez permit´ıan interactuar con el entorno. As´ı, se iniciaban desarrollos en campos como el medio ambiente (cambio clim´atico), seguri-dad (vigilancia) o de tracking[10] a la vez que evi-denciaban un conjunto de desaf´ıos muy apetecibles para la comunidad investigadora[11].

con-junto de peque˜nos dispositivos denomindos nodos sensores, con capacidad limitada de c´omputo y co-municaci´on, cuyo tiempo de vida depende de una bater´ıa adjunta al dispositivo. El tiempo de vida de la red de sensores depender´a por tanto del tiempo de vida de la bater´ıa de sus nodos. Estos disposi-tivos se encuentran dispersos de manera ad−hoc en una determinada ´area a monitorizar. T´ıpicamente, el modelo seguido por las aplicaciones es el siguiente: realizar una serie de mediciones sobre el medio (v´ıa sensores anal´ogicos), transformar dicha informaci´on en digital en el propio nodo y transmitirla fuera de la red de sensores v´ıa un elemento gateway a una estaci´on base, donde la informaci´on pueda ser al-macenada y tratada temporalmente para acabar fi-nalmente en un servidor con mayor capacidad que permita componer un hist´orico o realizar an´alisis de datos[12].

Diferentes tipos de nodos sensores han sido uti-lizados en estos experimentos. Sin embargo, existe una tendencia clara en este aspecto. En el a˜no 1998 Crossbow Technologies[13] el mayor fabricante de no-dos sensores de la actualidad y proveedor de los prin-cipales investigadores puso en el mercado el primer modelo de nodo sensor o ”mote”, iniciando as´ı una evoluci´on que contin´ua en nuestros d´ıas. Con es-tos nodos como hardware de referencia, la Universi-dad de Berkeley tiene la iniciativa m´as importante y la que m´as repercusi´on ha tenido: el desarrollo en el a˜no 2003 de un sistema operativo capaz de ges-tionar los recursos de las motes y permitir la eje-cuci´on de aplicaciones. Este sistema operativo, de-nominado TinyOS[14] es considerado en la actuali-dad el est´andar de facto. Probablemente el ´exito de TinyOS se debe a que ofreci´o una referencia com´un a los investigadores, de manera que facilit´o oportu-nidades para que otros pudieran comenzaran a tra-bajar y por tanto dando cohesi´on a las distintas solu-ciones.

Aunque no con tanto ´exito, al mismo tiempo cada grupo de investigadores ha acabado construyendo pi-las completas de software proporcionando soluciones incapaces de ser reusables y coherentes con otros desarrollos, de forma que en la actualidad existe toda una sopa de protocolos[3] y aplicaciones que no pueden interoperar entre s´ı y que son espec´ıficas para la plataforma utilizada. En concreto, numerosos mi-ddleware [15][16][17] para WSN est´an siendo pro-puestos como elementos integradores que tratan de dar soluci´on a los problemas planteados en WSN. Los desaf´ıos de estos middleware han sido descritos pero a´un no han sido resueltos[18]. Cada middleware se ha especializado en uno o varios aspectos diferen-tes: reprogramabilidad, calidad de servicio, ahorro de energ´ıa, adaptabilidad, funciones de agregados, etc. A pesar de existir middlewares basados en com-ponentes para WSN[19] no han sido todava descritos middleware abiertos, reusables, basados por tanto en est´andar, que puedan ser descritos f´acilmente y uti-lizados por las aplicaciones, y que aseguren la inter-operabilidad entre distintas plataformas.

III. Model Driven Architecture Al contrario que en WSN, en otros sistemas dis-tribuidos los investigadores han dirigido sus esfuerzos en la b´usqueda de soluciones abiertas y reusables. Grandes aplicaciones distribuidas (avi´onica, teleco-municaciones, medicina y aplicaciones militares) han buscado la forma de sistemas de sistemas y de com-ponentes hardware y software denominados COTS (commercial off−the−self), componentes creados de manera independiente por distintos fabricantes y que pueden ser f´acilmente configurados e integrados para componer aplicaciones[20].

El estado del arte de los sistemas distribuidos pre-senta numerosos problemas relacionados con el coste del software y la complejidad de manejar ciclos de vida muy largos (de entre 15 y 30 a˜nos)[21]. Para resolver estos desaf´ıos, la tendencia clara ha sido el desarrollo de middleware basados en est´andar que sirvan como plataforma com´un para garantizar la integraci´on. En este sentido, las cualidades de sis-temas ”abiertos” y ”reusables” se deben a un proceso guiado por un est´andar, en particular MDA. En la actualidad, middleware de sistemas distribuidos se est´an desarrollando siguiendo un nuevo paradigma Model Driven Middleware (MDM) como fusi´on de MDA y el concepto de middleware para sistemas DRE (Distributed and Real−Time Embedded Sys-tems).

MDA define tres puntos de vista de un sistema que representa mediante modelos. Cada punto de vista se concentra en aspectos relevantes y se abstrae de aquellos que no lo son. As´ı los puntos de vista de MDA son: Punto de vista Independiente de la Com-putaci´on (CIM), Punto de vista Independiente de la Plataforma (PIM) y Punto de vista Espec´ıfico de la Plataforma (PSM). El CIM debe definir completa-mente los requerimientos del entorno, el dominio del problema y el vocabulario a emplear. El PIM debe realizar una completa descripci´on de las partes del sistema que no cambian de una plataforma a otra. Por ´ultimo, el PSM combina el punto de vista inde-pendiente de la plataforma con los detalles espec´ıficos del uso de una plataforma concreta. V´ıa transforma-ciones de esos modelos mediante ”mappings”, MDA cubre completamente el ciclo de vida del software desde los niveles de especificaci´on de requisitos hasta la instalaci´on de la aplicacin en la plataforma partic-ular. MDA permite adem´as, el uso de Lenguajes de Modelado Espec´ıficos del Dominio (DSML) los cuales son empleados para capturar las propiedades esenciales de la aplicaci´on.

Varias herramientas conformes al paradigma MDA han surgido para dirigir el proceso completo. Por ejemplo, herramientas basadas en el Modelo de Com-ponentes de CORBA (CCM)[22] como Cadena[23] o CoSMIC[24] est´an siendo utilizadas para el desarro-llo de middleware multi−capa de sistemas distribui-dos, donde la unidad b´asica de reuso es un compo-nente, el cual toma forma mediante la especificaci´on de componentes de CORBA[25]. Sin embargo, es-tas herramienes-tas no pueden ser utilizadas m´as all´a

del contexto de CORBA y por tanto, son incapaces de dirigir el desarrollo de software de las WSN. La figura 1 representa el proceso guiado que provee la herramienta CoSMIC.

Fig. 1. Herramientas MDM de CoSMIC

IV. Middleware basado en componentes La aportaci´on m´as importante de este trabajo es el dise˜no de una arquitectura middleware conforme a MDA, basado en componentes y que ha sido dise˜nado teniendo en cuenta los siguientes requerimientos:

• Arquitectura de middleware de WSN,

cons-truido usando componentes reusables e indepen-dientes, que pueden ser ensamblados entre s´ı para generar un determinado instalable en los nodos sensores.

• Independiente de la plataforma y del sistema

operativo. El middleware debe solucionar los problemas de heterogeneidad hardware e inter-operabilidad software presentes en las redes de sensores de la actualidad.

• Debe tener en cuenta las restricciones de las

plataformas hardware: bater´ıa, capacidad de computaci´on, recursos de comunicaci´on, etc.

• Debe proporcionar flexibilidad y adaptabilidad

a las aplicaciones, ocultando los detalles irrele-vantes y ser f´acil de manejar.

• Capaz de manejar los desaf´ıos presentes en

WSN.

La figura 2 describe el proceso completo seguido por el middleware propuesto.

Teniendo en cuenta estos requerimientos, se ha dise˜nado una primitiva versi´on de un middleware para WSN. Su objetivo es la generaci´on autom´atica de aplicaciones robustas basadas en componentes, cuyo c´odigo ejecutable pueda ser descargado a los nodos sensores, permitiendo as´ı la re−programaci´on din´amica de la red. Estas aplicaciones deben ser construidas sobre un conjunto de requisitos que son proporcionados inicialmente por el programador, tanto hardware como software. N´otese que cada unidad en nuestro sistema debe sostenerse sobre una definici´on completa y factible de componente en el ´ambito de WSN.

A. Arquitectura

La arquitectura del middleware basado en compo-nentes ha sido dise˜nada de manera multi−capa en

lu-Fig. 2. Proceso de ejecuci´on del middleware.

gar de forma monol´ıtica, para alcanzar los beneficios que ello conlleva. Este dise˜no multi−capa implica que cada capa de la arquitectura general, propor-ciona servicios al nivel superior y requiere servicios del nivel inferior. Esto nos lleva a pensar que una capa de nuestra arquitectura se comporta como un componente. En la figura 3 se presentan las capas principales de la arquitectura.

Fig. 3. Arquitectura del middleware.

En este trabajo nos centraremos en el nivel de dise˜no de la arquitectura, y en particular en su aportaci´on m´as importante, como es la capa middle-ware. Por tanto, existir´an aspectos de la arquitectura que si bien se han descrito, no se ha proporcionado ninguna soluci´on propia, dejando para posteriores in-vestigaciones la manera en que se ha de resolver el problema.

A.1 La capa Middleware

La capa middleware es el nivel m´as alto de la jer-arqu´ıa, y constituye el elemento del sistema capaz de actuar como interfaz entre el programador y la red de sensores. Para ello, el middleware deber´a recoger e integrar la informaci´on tanto del programador

(es-pecificaci´on de requisitos hardware y software, com-ponentes suministrados por el programador de alto nivel que debe incorporar, etc.), as´ı como otros com-ponentes gen´ericos como por ejemplo la propia red o el sistema operativo(plataforma especfica). Sus ob-jetivos se pueden resumir en:

1. Capturar la especificaci´on completa de compo-nentes hardware y software a usar en la apli-caci´on final.

2. Obtener componentes software gen´ericos (como el sistema operativo) capaz de gestionar eficien-temente los recursos hardware y la propia apli-caci´on.

3. Integrar todos los componentes anteriores, rea-lizando verificaciones sobre contratos y restric-ciones, de manera que la aplicaci´on pueda ser est´aticamente enlazada una vez se haya compro-bado la factibilidad de la composici´on.

4. Generar un ´unico ejecutable de la aplicaci´on. 5. Instalar dicho ejecutable en la red de sensores. La capa middleware se descompone a su vez en diferentes capas de componentes reusables capaces de encapsular una funcionalidad para cumplir unos objetivos espe´ıficos. En la figura 4 se puede ver el dise˜no de la capa de middleware.

Fig. 4. Capa Middleware

Los elementos que integran la capa middleware son los siguientes:

• Gestor de configuraci´on de componentes. Este

componente captura y verifica los requisitos del programador para componer la aplicaci´on final. Debe por tanto:

1. Capturar una definici´on completa del hard-ware y del softhard-ware de la aplicaci´on. N´otese que esta descripci´on debe pronunciarse so-bre el hardware usado en la red de sensores, que debe ser conocida por el programador. Adem´as, el programador puede proporcionar componentes espec´ıficos que son programados para ser integrados con la aplicaci´on resul-tante. Un desaf´ıo en este punto es la definici´on y el uso de un lenguaje de definici´on de la especificaci´on para proporcionar una manera uniforme de definir tales requisitos, conforme al est´andar MDA.

2. Proporcionar al nivel inferior una lista de

componentes que deban ser integrados para generar la aplicaci´on ejecutable.

• Servidor de componentes. El servidor de

compo-nentes usa los interfaces proporcionados por los niveles inferiores de la arquitectura (en particu-lar, sistema operativo, HAL y Sensor Node) con el objetivo de descargar e instanciar los compo-nentes hardware y software (desde repositorios remotos o locales) para configurar y ensamblar adecuadamente la aplicaci´on a generar. Para ello, debe usar la informaci´on proporcionada por el programador de forma que se pueda compro-bar que efectivamente pueden ser transformadas en componentes v´alidos, que cumplen todos los contratos y restricciones hardware y software y que son compatibles entre s´ı. Durante esta etapa de validaciones, se deber´a interrumpir el proceso de generaci´on si cualquiera de las condiciones es-tablecidas no se verifica. Si todo ha ido bien, una vez instanciados los componentes pueden ser proporcionados al siguiente nivel.

• El ensamblador de componentes es la parte

en-cargada de la integraci´on de los componentes obtenidos por el servidor de componentes para que puedan ser compilados, de manera que se obtenga el c´odigo ejecutable a instalar en la red. Nuevamente, este c´odigo debe pasar ciertas verificaciones relacionadas con las restricciones hardware de la plataforma donde vaya a ser ins-talado.

• El instalador finalmente permitir´a instalar un

binario en la plataforma correspondiente. Di-versas soluciones han sido propuestas para con-seguir la reprogramabilidad de la red, entre ellas las m´as relevantes son las basadas en m´aquinas virtuales[26]. Sin embargo, sera necesario tener en cuenta las peculiaridades de la arquitectura propuesta para obtener un instalador adecud-ado.

A.2 La capa del Sistema Operativo Local

La capa del Sistema Operativo Local, es el ele-mento del sistema que encapsula las funciones del sistema operativo particular en cada nodo sensor y proporciona un interfaz uniforme e independi-ente al componindependi-ente middleware para ser usado por las aplicaciones. En este componente t´ıpicamente deber´an reflejarse los componentes b´asicos del sis-tema operativo. Debido a que el sistema opera-tivo es en s´ı mismo un componente que cumple unas funciones y presenta ciertos interfaces predefinidos, puede ser ensamblado como un componente m´as, de manera que el propio sistema operativo pueda ser una unidad reemplazable en los distintos nodos. Esto es, cualquier sistema operativo dise˜nado de ma-nera conforme a nuestra arquitectura (o transfor-mando sus interfaces) deber´ıa poder integrarse. Tal y como se coment´o anteriormente el sistema opera-tivo est´andar de facto es TinyOS, si bien este dise˜no permite que otros sistemas operativos existentes para

WSN como MANTIS o SOS puedan ser utilizados. A.3 La capa de Abstracci´on del Hardware

Una cuesti´on todav´ıa sin resolver es el tipo de hardware que finalmente se impondr´a en las WSN. Si bien el hardware dominante es el de las motes de Crossbow, numerosos equipos de investigadores trabajan en paralelo con otras plataformas, tales como iPAQ[27], i-mote de Intel[28] o tecnolog´ıa SmartDust[29]. Nosotros visionamos redes de sen-sores formadas tanto por motes, como por sensen-sores biom´etricos, c´amaras de vigilancia o probablemente iPAQ, dado el extenso dominio de aplicaci´on. Es por tanto, fundamental un dise˜no que tenga en mente las enormes posibilidades presentes en el campo del hardware. La capa de abstracci´on del hardware (HAL) debe estar presente entre el sistema operativo y el propio hardware, abstrayendo las peculiaridades de cada plataforma particular y proporcionando un interfaz al sistema operativo particular que oculte el tipo de hardware que se encuentra manejando. Por otro lado, la HAL debe usar interfaces particula-res ofrecidos por cada hardware concreto, probable-mente proporcionado por el fabricante para poste-riormente mapearlo a una llamada est´andar gen´erica usada por el sistema operativo.

Fig. 5. Capa de Abstracci´on de Hardware.

A.4 La capa del Nodo Sensor

La capa del Nodo Sensor es el componente de m´as bajo nivel de nuestra arquitectura. Est´a formado por aquellos elementos hardware presentes de ma-nera gema-neral en los nodo sensores. Estos elemen-tos hardware son modelados como componentes soft-ware, ya que se concentran en caracterizarlos y ab-straer el software que los gestiona. Debido al gran abanico de fabricantes de hardware existentes, la tarea de realizar una descripci´on gen´erica de un nodo sensor (sea cual sea su forma o fabricante) puede llegar a ser un problema extremadamente complejo. Es por ello, que tomando de nuevo como referencia las motes de Crossbow hemos identificado su com-posici´on hardware gen´erica definiendo componentes que abstraigan los detalles entre los distintos

mode-los.

Fig. 6. Capa del Nodo Sensor.

B. Aplicando MDA

El primer paso en el proceso MDA es la descripci´on del sistema mediante modelos independientes de la plataforma (PIM). En la secci´on anterior, pudo verse c´omo es posible definir estos modelos mediante dia-gramas de componentes en los que se hab´ıan iden-tificado las principales entidades de la arquitectura con independencia del hardware y software utilizado. En esta secci´on justificaremos c´omo se puede trans-formar el modelo PIM a modelos espec´ıficos de la plataforma (PSM) mediante determinadas reglas de transformaci´on.

Las reglas de transformaci´on son inherentes a la propia arquitectura, esto es, el propio middleware es qui´en determinar´a qu´e tipo de componente debe utilizar en cada momento. As´ı, pueden existir com-ponentes independientes en la arquitectura (capas de mayor nivel de abstracci´on) y m´as espec´ıficos (la capa de hardware y la HAL). Estos componentes es-pec´ıficos de la plataforma particular deben ser por tanto personalizados e instanciados por otro compo-nente que los usa.

Para ello, el middleware deber´a conocer el con-junto m´ınimo de caracter´ısticas hardware y software (es decir, aquellas que no se pueden asumir o adaptar de ninguna manera) a utilizar por la aplicaci´on. Una vez conocidos esos requisitos, deber´an mapearse en componentes concretos los cuales son instanciados a partir de una plantilla gen´erica para todos los com-ponentes del mismo tipo. De esta forma a partir de componentes independientes (plantillas) se pueden generar componentes concretos que utiliza la arqui-tectura para componer la aplicaci´on final. La idea de componentes gen´ericos y espec´ıficos se debe susten-tar sobre una definici´on de componente tan flexible como rigurosa.

V. Trabajos futuros

Es mucho el trabajo que queda por hacer en el ´ambito de middleware abiertos para WSN y las posi-bilidades que se plantean son enormes. En con-creto, una caracterizaci´on completa de la arquitec-tura en base a plantillas que puedan ser instanciadas en tiempo de ejecuci´on, tal y como se plantea en este trabajo, nos permitir´ıa evaluar la posibilidad y efi-ciencia para caracterizar componentes reales. Una posible forma de realizar tal especificaci´on de com-ponentes podr´ıa realizarse mediante Schemas XML o DTD (Document Type Definition).

Una capa gen´erica de abstracci´on de hardware, ca-paz de abstraer las peculiaridades de cada plataforma nos permitir´ıa manejar la heterogeneidad del hard-ware en WSN.

Por otro lado, el concepto relativamente reciente de Programaci´on Orientada a Aspectos (AOP) apli-cado a WSN representa un importante desaf´ıo de cara a la construcci´on del software. Las t´ecnicas uti-lizadas en AOP tratan de gestionar eficientemente aquellas propiedades recurrentes de un sistema dis-tribuido complejo, que no se pueden ubicar en una localizaci´on concreta y que sin embargo, afectan a di-ferentes componentes de software. Sin duda, la apli-caci´on de estas t´ecnicas en el desarrollo del software para WSN redundar´ıa en una programaci´on m´as efi-ciente y como consecuencia, en una mejor gesti´on de los recursos.

VI. CONCLUSIONES

Las WSN presentan tantas capacidades poten-ciales como limitaciones reales a´un sin resolver. El tipo de hardware y software que finalmente domi-nar´a en este tipo de redes es todav´ıa desconocido, si bien las actuales capacidades de energ´ıa, c´omputo y comunicaci´on, limitan la manera en que se ha de construir su software. Diferentes middleware para WSN est´an siendo planteados como arquitec-tura para soportar los desaf´ıos planteados. En este trabajo nosotros hemos abordado el problema de la construcci´on de software en WSN gui´andonos para ello de soluciones tomadas en otros entornos dis-tribuidos. Para ello, se ha estudiado y aplicado el est´andar MDA para la construcci´on de un middle-ware basado en componentes para WSN. Esta ar-quitectura se basa en la idea de que puedan ser f´acilmente reemplazados, verificados y ensamblados para construir la aplicaci´on final. Por tanto, ha sido necesario una definici´on rigurosa y a la vez flexible de los componentes de nuestra arquitectura, de manera que cualquier componente conforme a dicha especi-ficaci´on pueda ser f´acilmente integrado. Adem´as, el proceso ha sido guiado por el est´andar MDA lo cual nos garantiza un sistema abierto, con la ventaja de alcanzar una propiedad clave de la ingenier´ıa del soft-ware hasta ahora abandonada en el ´ambito de WSN: la reusabilidad.

Referencias

[1] S. Bhatti, J. Carlson, H . Dai, J. Rose, A. Sheth, B. Shucker, C. Gruenwald, A. Togerson, R. Han MANTIS

OS: An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms, in ACM Kluwer

Mo-bile Networks & Applications (MONET) Jounal, August 2005

[2] C. Han, R. Kumar, R. Shea, E. Kohler and M. Srivas-tava A Dynamic Operating System for Sensor Nodes, in Proceedings of the 3rd international conference on Mobile systems, applications, and services, 2005

[3] D. Culler, P. Dutta, C. Tien Ee, R. Fonseca, J. Hui, P. Levis, J. Polastre, S. Shenker, I. Stoica, G. Tolle, J. Zhao

Towards a Sensor Network Architecture: Lowering the Waistiline, University of California, 2003.

[4] R. E. Schantz, D. C. Schmidt Middleware for Distributed

Systems, in

[5] R. E. Schantz, D. C. Schmidt Middleware for Distributed

Systems: Evolving the Common Structure for Network-centric Application, Encyclopedia of Software Eng., Wiley

& Sons. New York, 2001

[6] Object Management Group, Model Driven Architecture (MDA) , OMG Document ormsc/2001−07−01 edition,

July 2001.

[7] http://www.omg.org/

[8] O. Niertrasz, G. Arvalo, S. Ducasse, R. Wuyts, A. Black, P. Muller, C. Zeidler, T. Genssler, R. van den Born A

Dynamic Operating System for Sensor Nodes,

Proceed-ings First International IFIP/ACM Working Conference on Component Deployment, ACM, Berlin, Germany, June 2002.

[9] http://www.technologyreview.com/

[10] Jason Hill, System Architecture for Wireless Sensor

Net-works, University of California, 2003.

[11] D. Estrin, R. Govindan, J. Heidemann, S. Kumar Next

Century Challenges: Scalable Coordination in Sensor Networks, in MOBICOM, 1999.

[12] R. Szewczyk, J. Polastre, A. Mainwaring, D. Culler

Lessons From A Sensor Network Expedition, in

Proceed-ings of the First European Workshop on Sensor Networks (EWSN), 2004

[13] http://www.xbow.com [14] http://www.tinyos.net.

[15] Wendi B. Heinzelman, Amy L. Murphy, Hervaldo S. Car-valho, Mark A. Perillo Middleware to Support Sensor

Network Applications , IEEE Network Mag., 18(1):6–14,

2004.

[16] Curino, C. Giani, M. Giorgetta, M. Giusti, A. Murphy, A.L. Picco, G.P. TinyLIME: bridging mobile and sensor

networks through middleware , Pervasive Computing and

Communications, 2005. PerCom 2005. Third IEEE Inter-national Conference on (2005), pp. 61-72.

[17] Matthew Wolenetz Characterizing Middleware

Mecha-nisms for Future Sensor Networks, in 2005

[18] Middleware Challenges for Wireless Sensor Networks , in Mobile Computing and Communications Review, 2002. [19] C. Mascolo, S. Zachariadis, G. P. Picco, P. Costa, G. Coulson The RUNES Middleware: A Reconfigurable Component-based Approach to Networked Embedded Sys-tem, in 2005

[20] K. Balasubramanian, J. Balasubramanian, A. S. Krishna, G. Edwards, G. Deng, E. Turkay, J. Parsons, and D. C. Scmidt Model Driven Middleware: A New Paradigm for

Developing and Provisioning Distributed Real−time and Embedded Applications, , 2003.

[21] A. Gokhale, K. Balasubramanian, A.S. Krishna, J. Bal-asubramanian, G. Edwards, G. Deng, E. Turkay, J. Par-sons, D.C. Schmidt. Model Driven Middleware: A new

Paradigm for Developing Distributed Real-Time and Em-bedded Systems, Vanderbilt University, April 2005

[22] http://www.omg.org/technology/documents/formal/components.htm [23] http://cadena.projects.cis.ksu.edu.

[24] http://www.dre.vanderbilt.edu/cosmic.

[25] http://www.omg.org/docs/formal/02−06−07.pdf [26] P. Levis and D. Culler Mat: a tiny virtual machine for

sensor networks, ASPLOS-X, 2002.

[27] T. Lieu, M. Martonsi Impala: A Middleware System for

Managing Autonomic, Parallel Sensor Systems, 2003

[28] http://www.intel.com/research/exploratory/motes.htm. [29] J. M. Kahn, R. H. Katz, K. S. J. Pister Next Century

Challenges: Mobile Networking for Smart Dust, in

Inter-national Conference on Mobile Computing and Network-ing (MOBICOM)(1999)