10 - IEEE - Middleware For Internet of Things - A Survey - Español

publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final.
información de referencia: DOI 10.1109 / JIOT.2015.2498900, IEEE Internet de las

cosas Diario
IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 1
Middleware para Internet de las cosas: una Encuesta

MA Razzaque, Marija Milojevic-Jevric, Andrei Palade, Siobh' una Clarke
Abstracto -El internet-de-objetos (IO) prevé un futuro en el En un entorno de computación ubicua como la IO, no es práctico para imponer
el cual las cosas u objetos digitales y físicos (por ejemplo, teléfonos inteligentes, normas y hacer que cada uno cumpla. Una red a gran escala de ultra de las cosas y
televisores, automóviles) se puede conectar por medio de tecnologías de información y
el gran número de eventos que se pueden generar de forma espontánea por estas
comunicación adecuados, para permitir una amplia gama de aplicaciones y servicios. Las
cosas, junto con heterogéneos dispositivos / tecnologías / aplicaciones de la IO traerá
características de la IO, incluyendo una red de ultra gran escala de las cosas, el
dispositivo y la heterogeneidad a nivel de red, y un gran número de eventos generados nuevos retos en el desarrollo de aplicaciones, y hacer que los retos existentes en la
espontáneamente por estas cosas, hará que el desarrollo de las diversas aplicaciones y computación ubicua considerablemente más di fi culto [2], [3]. En este contexto, un
servicios de una tarea muy difícil. En general, el middleware puede facilitar un proceso de middleware puede ofrecer servicios comunes para las aplicaciones y facilidad de
desarrollo mediante la integración de dispositivos informáticos y de comunicaciones
aplicación desarrollo mediante la integración de dispositivos informáticos y de
heterogéneas y favoreciendo la interoperabilidad dentro de las diversas aplicaciones y
comunicaciones heterogéneas y favoreciendo la interoperabilidad dentro de las
servicios. Recientemente, ha habido una serie de propuestas para la IO middleware.
Estas propuestas dirigidas sobre todo redes de sensores inalámbricos (WSN), un diversas aplicaciones y servicios que se ejecutan en estos dispositivos. Un número
componente clave de la IO, pero no tienen en cuenta Radio-Frecuencia de identi fi cación de sistemas operativos se han desarrollado [9] - [16] para apoyar el desarrollo de
(RFID), Machine-to-Machine (M2M) las comunicaciones y Control de Supervisión y soluciones de middleware de la IO. En general, éstas residen en los dispositivos
Adquisición de Datos (SCADA), otros tres elementos centrales en la visión de la IO. En
físicos, y proporcionan las funcionalidades necesarias para permitir el despliegue de
este artículo, describimos una serie de requisitos para la IO middleware, y presenta una
servicios. Complementarios a middleware son enfoques de programación del
revisión exhaustiva de las soluciones de middleware existentes contra esos requisitos.
Además, las cuestiones de investigación abiertas, los desafíos y las futuras líneas de lenguaje [17], [18]. Estos enfoques abordan algunos de los problemas (tales como el
investigación están resaltados. descubrimiento, desconexiones de red, y la comunicación de grupo) que plantea la
IO, pero están limitados en su apoyo a otras como la sensibilidad al contexto (por
ejemplo, el descubrimiento de servicios sensibles al contexto) y la escalabilidad.
Términos del Índice -WSNs, RFID, M2M Comunicación, SCADA,

Características de la IO, Requisitos Middleware
I. INTRODUCCIÓN WSNs, RFID, comunicaciones M2M, y SCADA son los cuatro componentes esenciales (Figura 2) de
la IO [19], [20]. Un middleware completamente funcional IO necesita integrar estas tecnologías para
Con el avance de numerosas tecnologías, incluyendo sensores, actuadores,
apoyar los diversos dominios de aplicación previstos [19]. Hasta la fecha, la mayoría de las propuestas
computación empotrados y computación en la nube, y el surgimiento de una nueva
dleware mediados de la IO existentes [21] - [29] están centradas en redes inalámbricas de sensores.
generación de dispositivos inalámbricos más barato, más pequeños, muchos objetos o cosas
Muchos estudios se han realizado sobre WSNs middleware [30] - [36], o bien éstos no son integrales [34]
en nuestras vidas diarias están convirtiendo en forma inalámbrica interoperable con la
- [36] o no informe más reciente trabajo [30] - [32]. A partir de estos estudios, es evidente que ningún
miniatura adjunto y baja dispositivos inalámbricos Accionado o pasiva (por ejemplo, las
middleware existente puede soportar todos los requisitos necesarios para redes inalámbricas de
etiquetas RFID pasivas). El Foro Mundial de Investigación inalámbrica predice que para el
sensores o aplicaciones de la IO. Por ejemplo, era Per- et al. [20] Ed identificó que la mayoría de
middleware WSN existente y las soluciones centradas en la IO no son compatibles con sensibilidad al
2017, habrá 7 billones de dispositivos inalámbricos que sirven 7 mil millones de
contexto. Además, a diferencia WSNs, el número de propuestas de middleware para RFID, así como las
personas [1] (es decir, mil dispositivos por persona). Este gran número de ultra de
comunicaciones M2M, y SCADA es limitada [19], [37] - [41]. Por otro lado, en los últimos años, están
cosas o dispositivos conectados formará la IO [2], [3].
surgiendo IO-especí fi cos middleware [19], [25], [42] - [46] al igual que algunos estudios [19], [24], [47].
Bandyopadhyay et al. [24], [47] se han centrado en poner de relieve la importancia de un sistema
Al permitir el acceso fácil de, y la interacción con, una amplia variedad de
dleware mediados de la IO, y no incluyen la mayoría de middleware IO-mercantiles [19], [25], [44] - [46].
dispositivos físicos o cosas tales como, electrodomésticos, cámaras de vigilancia,
Zhou ha presentado solamente una vista conceptual de un marco ed fi uni para la IO middleware basada
sensores de control, actuadores, displays, vehículos, máquinas y así sucesivamente,
en la orientación de servicio [19]. Además, este trabajo no incluye reciente, y la IO-específicos
la IO fomentará el desarrollo de aplicaciones en muchos campos diferentes, tales
middlewares fi c [25], [46]. [47] se han centrado en poner de relieve la importancia de un sistema dleware
como la domótica, automatización industrial, ayudas médicas, cuidado de la salud
mediados de la IO, y no incluyen la mayoría de middleware IO-mercantiles [19], [25], [44] - [46]. Zhou ha
móvil, la asistencia de ancianos, la gestión inteligente de la energía y las redes
presentado solamente una vista conceptual de un marco ed fi uni para la IO middleware basada en la
inteligentes, automotores, gestión de trá fi co, y muchos otros [4]. Estas aplicaciones
orientación de servicio [19]. Además, este trabajo no incluye reciente, y la IO-específicos middlewares fi c
hacer uso de la potencialmente enorme cantidad y variedad de datos generados por
[25], [46]. [47] se han centrado en poner de relieve la importancia de un sistema dleware mediados de la
este tipo de objetos para proporcionar nuevos servicios a los ciudadanos, empresas
IO, y no incluyen la mayoría de middleware IO-mercantiles [19], [25], [44] - [46]. Zhou ha presentado
y administraciones públicas [3], [5] - [8].
solamente una vista conceptual de un marco ed fi uni para la IO middleware basada en la orientación de
servicio [19]. Además, este trabajo no incluye reciente, y la IO-específicos middlewares fi c [25], [46].
Considerando la importancia de la IO en varios dominios, este artículo tiene

MA Razzaque, Marija Milojevic-Jevric, Andrei Palade, y una visión holística de middleware para la IO y (1) fi identifica las
Siobh' Clarke son una con el Grupo de Sistemas Distribuidos, Facultad de Informática y Estadística,
características clave de la IO, y los requisitos de middleware de la IO (Sección
el Trinity College de Dublín, Dublín, Irlanda. E-mail: {razzaqum, milojavm, Paladea,
Siobhan.Clarke}@scss.tcd.ie
II), (2) en base a los requisitos fi cados, presenta una revisión exhaustiva de
Manuscrito recibido 8 Apr. 2015; 9 revisado julio de 2015. los existentes
2327-4662 (c) 2015 IEEE. El uso personal está permitida, pero republicación / redistribución requiere el permiso del IEEE. Ver http://www.ieee.org/publications_standards/publications/rights/index.html para más información. Este artículo ha sido aceptado para su
publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI 10.1109 / JIOT.2015.2498900, IEEE Internet de las
cosas Diario
sistemas de middleware que se centran en la corriente, el estado de la técnica de la investigación comunicar sobre una red, sin de humano a humano o la interacción de persona
(Sección III), y (3) esboza desafíos de investigación abiertas, recomendando futuras direcciones a ordenador, para intercambiar información y tomar decisiones inteligentes con
de investigación (sección IV). el apoyo de ics analyt- avanzada [50].
II. segundo ANTECEDENTES La definición de “cosas” en la visión de la IO es muy amplia e incluye una variedad de
elementos físicos. Estos incluyen objetos personales que llevamos como teléfonos
A. IO y sus características
inteligentes, tabletas y cámaras digitales. También incluye elementos en nuestros
La investigación sobre la IO se encuentra todavía en su fase inicial, y un nivel de ambientes (por ejemplo, hogar, vehículo o de trabajo), industrias (por ejemplo, máquinas,
fi nición de la IO no está disponible todavía. IO se puede ver desde tres motor, robot), así como cosas fi TTED con las etiquetas (por ejemplo, RFID), que se
perspectivas: orientadas a Internet, orientada a las cosas (sensores o cosas convierten conectados a través de un dispositivo de pasarela (por ejemplo, una teléfono
inteligentes) y orientado a la semántica (conocimiento) [6]. Además, la IO se puede inteligente). Sobre la base de esta visión de “cosas”, un enorme número de dispositivos
ver ya sea como consumidores de apoyo (humana) o aplicaciones industriales y de será conectado a Internet, cada uno proporcionando datos e información, y algunos, incluso
hecho podría ser nombrado como Internet humano de las cosas (HIoT) o Internet servicios.
Industrial de las cosas (IIoT) [19] [48], - [50 ]. A pesar de que estos diferentes
puntos de vista han evolucionado debido a la naturaleza interdisciplinaria de la Redes de Sensores (SNS), incluyendo redes inalámbricas de sensores
materia, es probable que se cruzan en un dominio de aplicación para lograr los (WSNs) y de sensores inalámbricos y redes de accionamiento (WSANs), RFID,
objetivos de la IO. comunicaciones M2M y Control de Supervisión y Adquisición de Datos (SCADA)
son los componentes esenciales de la IO. Como se describe en más detalle en
La primera definición de la IO era desde una perspectiva de “cosas primero”, esta sección, un número de características de la IO se heredan de uno o más de
donde las etiquetas RFID fueron considerados como cosas [6]. Según la estos componentes. Por ejemplo, “recursos limitados” se hereda de RFID y
comunidad RFID, la IO puede ser definida como, “la red mundial de objetos SNS, y “inteligencia” se hereda de WSNs y M2M. Otras características (por
interconectados de forma única direccionables en base a protocolos de ejemplo, la red de gran escala Ultra, interacciones espontáneas) son
comunicación estándar” [51]. La Figura 1 ilustra el Cluster Europeo de especificidad c para la IO. Las principales características de la IO se presentan
Investigación de la IO (IERC) de fi nición, donde “La Internet de las cosas permite desde la perspectiva de infraestructura y aplicaciones.
a las personas y cosas que se pueden conectar en cualquier momento y en
cualquier lugar, con cualquier cosa y cualquier, idealmente usando cualquier ruta /
red y todo servicio” [52], [53]. La Unión Internacional de Telecomunicaciones (UIT) 1) Características de la IO Infraestructura:
considera la IO muy parecida: “De cualquier momento, Any-conectividad lugar • Los dispositivos heterogéneos: La naturaleza incrustado y la computación sensor de
para nadie, ahora vamos a tener conectividad para cualquier cosa” [54]. muchos dispositivos IO significa que las plataformas de computación de bajo costo son
Semánticamente, la IO significa “una red de objetos interconectados en todo el susceptibles de ser utilizados. De hecho, para minimizar el impacto de este tipo de
mundo de forma única direccionable, dispositivos en el consumo de energía y el medio ambiente, las radios de baja potencia
son susceptibles de ser utilizados para la conexión a Internet. Tales dios ra- baja
potencia no utilizan Wi-Fi, o tecnologías de redes celulares bien establecidas. Sin
embargo, la IO no se compone solamente de dispositivos y sensores embebidos,
también necesitará dispositivos informáticos de orden superior para llevar a cabo
En cualquier Alguien,
momento cualquier contexto cualquiera tareas de servicio más pesados (de encaminamiento, conmutación, procesamiento de
datos, etc.). heterogeneidad Dispositivo surge no sólo de las diferencias en capacidad
y características, pero también por otros motivos, incluidos los productos de múltiples
Cualquier cosa Cualquier servicio

proveedores, los requisitos de aplicación, etc. [4], [54]. La Figura 2 ilustra 6 tipos
IOTS
cualquier dispositivo Cualquier Negocio diferentes de dispositivos de IO.
Cualquier lugar Cualquier ruta de • Con recursos limitados: la informática y sensores embebidos necesitan un factor de
en cualquier lugar cualquier red
forma pequeño dispositivo, lo que limita su cessing, la memoria y la capacidad de
comunicación pro-. Como se muestra en la Figura 2, la capacidad de recursos (por
Fig. 1. De definición de la IO [52]. ejemplo, capacidades de conectividad, con- computacionales, los requisitos de
memoria) disminuye de izquierda a derecha. Por ejemplo, los dispositivos RFID o
La mayoría de las de fi niciones de la IO no ponen de relieve de forma explícita el etiquetas (en el extremo derecho lado de la figura) no pueden tener ninguna
punto de vista industrial de la IO (IIoT). empresas líderes mundiales están dando capacidad de procesamiento o incluso la batería para poder ellos. Por otra parte, en
especial atención y hacer inversiones signi fi cativas en la IO por sus soluciones la Figura 2 dispositivos convierten caro y de mayor factor de forma cuando se mueve
industriales (IIoT). A pesar de que utilizan diferentes términos tales como “planeta más hacia la izquierda.
inteligente” por IBM, “Internet de todo” por Cisco e “Internet Industrial” por GE, su
principal objetivo es utilizar la IO para mejorar la producción industrial mediante la • La interacción espontánea: En las aplicaciones de la IO, interacciones
reducción de los tiempos de parada no planificada y signi fi cativamente la reducción de repentinos pueden tener lugar como los objetos se mueven alrededor, y entrar
la energía costes junto con el número de otros beneficios potenciales [19], [48] - [50], en el rango de comunicación otros objetos, que conduce a la generación
[55]. El IIoT se refiere a objetos industriales, o “cosas”, instrumentados con sensores, espontánea de eventos. Por ejemplo, un usuario del dispositivo puede estar en
automáticamente estrecho contacto con una nevera lavadora TV / / en la casa y que puede ge-
cosas Diario
-End medio de dispositivos de computación (por

Dispositivos informáticos de gama alta
ejemplo, Computing Onboard Computación de gama baja Los sensores y actuadores RFID / NFC etiquetas o
Internet o la nube (por ejemplo, SCADA frente
Unidad de Vehículo para M2M dispositivos inalámbricos Redes dispositivos
procesador de extremo)
comunicación) de gama alta
De gama baja
Las limitaciones de recursos cada vez más escasos y aumenta el dinamismo
Fig. 2. Ejemplos de heterogeneidad de dispositivos en la IO.
erate eventos sin la participación del usuario. Típicamente, en la IO, una Arquitectura componentes (SOA), y objetos virtuales serán interoperable y
interacción con un objeto significa que un evento se genera y se empuja capaz de actuar de forma independiente basado en el contexto, las
al sistema sin mucha atención humana. circunstancias o entornos [60], [61].
• Consciente de la ubicación: Ubicación o información espacial sobre las cosas
• Ultra red a gran escala y el gran número de eventos: (objetos) o sensores en la IO es crítico, ya que la ubicación juega un papel vital en
En un entorno de la IO, miles de dispositivos o cosas pueden interactuar entre la informática consciente del contexto. En una red a gran escala de las cosas, las
sí, incluso en un mismo sitio local (por ejemplo, en un edificio, supermercado, interacciones dependen de su ubicación, su entorno, y la presencia de otras
universidad), que es escala mucho mayor que la mayoría de los sistemas de entidades (por ejemplo, cosas y personas) altamente.
redes convencionales. A nivel mundial, la IO será una red a gran escala de
ultra que contiene nodos en la escala de miles e incluso en billones. Gartner • Repartido: La propia Internet tradicional es una red distribuida globalmente,
ha predicho [56] que habrá cerca de 26 mil millones de dispositivos en la IO y así también es la IO. La dimensión espacial fuerte dentro de la IO hace
en 2020. Del mismo modo, ABI Research [57] estima que más de 30 mil que la red IO distribuye a diferentes escalas (es decir, tanto a nivel mundial
millones de dispositivos serán inalámbrica conectados por 2020. En la IO, como Internet, y también a nivel local dentro de un área de aplicación).
interacciones espontáneas entre un ultra gran número de cosas o
dispositivos, producirá un enorme número de eventos como un
2) Características de las aplicaciones de la IO:
comportamiento normal. Este número incontrolado de eventos puede causar
• Diversas aplicaciones: El IO puede ofrecer sus servicios a un gran número de
problemas tales como la congestión evento y la capacidad de procesamiento
aplicaciones en numerosos ámbitos y entornos. Estos dominios y entornos se
de eventos reducida.
pueden agrupar en (no exhaustiva) categorías de dominio, tales como: (i) el
transporte y la logística, (ii) Healthcare, (iii) el medio ambiente inteligente
(hogar, de oficina, planta), (iv) Industrial y (v ) de dominio personal y social. La
• Red dinámica y sin infraestructura: Como se muestra en la Figura 2, la IO
figura 3 destaca algunos dominios de aplicación clave para la IO. Las
integrará dispositivos, muchos de los cuales será móvil, conectado de forma
diferentes aplicaciones es probable que necesiten diferentes arquitecturas de
inalámbrica, y de recursos con- tensa. Los nodos móviles dentro de la red se
despliegue (por ejemplo, tiempo, impulsada por eventos) y tienen diferentes
incorporen o abandonen cualquier momento que deseen. Además, los nodos
quirements re-. Sin embargo, dado que la IO está conectado a Internet, la
pueden ser desconectados debido a las malas comunicaciones inalámbricas o
mayoría de los dispositivos que comprenden los servicios de la IO se necesita
escasez de la batería. Estos factores harán que la red en la IO altamente
para operar dentro de un ambiente que apoya su comprensión mutua.
dinámico. Dentro de este entorno ad hoc, donde no está limitada o ninguna
conexión con una infraestructura fija, que será difícil de mantener una red
estable para soportar muchos escenarios de aplicación que dependen de la IO.
Los nodos tendrán que cooperar para mantener la red conectada y activa.
• Tiempo real: Las aplicaciones que utilizan la IO pueden ser ampliamente
clasificados como en tiempo real y no en tiempo real. Por ejemplo, la IO para el
cuidado de la salud, el transporte, etc. necesitará la entrega a tiempo de sus datos
• Sensible al contexto: El contexto es clave en la IO y sus aplicaciones. Un gran
o servicio. retraso en la entrega de los datos puede hacer que la aplicación o
número de sensores generará grandes cantidades de datos, que no tendrá
servicio inútil e incluso peligroso en aplicaciones de misión crítica.
ningún valor a menos que se analiza, interpreta, y comprendido. la informática
consciente del contexto almacena información de contexto en relación con los
• Todo-as-a-service (XaaS): Un modelo de servicio todo-as-a-es muy e fi
datos del sensor, lo que facilita su interpretación. Sensibilidad al contexto
ciente, escalable y fácil de usar [62]. El modelo XaaS ha inspirado la
(especialmente en el contexto temporal y espacial) juega un papel vital en la
detección como un enfoque de servicios en WSNs [63], [64], y esto puede
conducta adaptativa y autónoma de las cosas en la IO [20], [58]. Tal
dar lugar inevitablemente la IO hacia un modelo XaaS. A medida que más
comportamiento ayudará a eliminar la mediación humana centradas en la IO, lo
cosas se conectan, el cobro de los servicios también es probable que
que finalmente hace que sea más fácil para llevar a cabo la comunicación M2M,
crezca, y se han hecho accesibles en línea, que estará disponible para su
un elemento central de la visión de la IO.
uso y re-uso.
• Mayor seguridad Ataque de la superficie: Si bien existe un enorme potencial para

• Inteligencia: De acuerdo con la visión de Intel IO, los dispositivos o las cosas
la IO en diferentes dominios, también hay preocupación por la seguridad de las
inteligentes y sistemas inteligentes de sistemas son los dos elementos clave
aplicaciones y redes. El IO necesita conectividad y accesibilidad global, lo que
de la IO [59]. En la red dinámica y abierta de la IO, estas entidades
significa que cualquier persona puede acceder a él en cualquier momento y de
inteligentes, junto con otras entidades tales como servicios web (WS),
cualquier manera. Esto aumenta enormemente las superficies de ataque
orientada al servicio
cosas Diario
para las aplicaciones y las redes de la IO. La complejidad inherente de proporciona un middleware y requisitos no funcionales (por ejemplo, fiabilidad, seguridad,
la IO complica aún más el diseño y despliegue de e fi ciente, disponibilidad) de soporte de QoS captura o Formance per- cuestiones.
interoperables y mecanismos de seguridad escalables.
La vista de un middleware en este documento es uno que proporciona servicios

• Las fugas de privacidad: El uso de la IO, las aplicaciones pueden recopilar
comunes o genéricas a múltiples diferentes dominios de aplicación. En esta sección,
información acerca de las actividades diarias de las personas. Como la información
no se hace ningún intento de capturar dominio o requisitos de aplicación especí fi
reflejando dichas actividades (por ejemplo, rutas de viaje, los hábitos de compra, el
cos, como el foco está en genérico o común funcional queridos, de la siguiente
uso diario de energía) es considerado por muchas personas como privada, la
manera:
exposición de esta información podría afectar la privacidad de las personas. El uso
de la computación en la nube hace que el problema de la fuga de privacidad aún • Detección de recursos: recursos de la IO incluyen dispositivos heterogéneos de
peor. Cualquier aplicación de la IO no cumple con los requisitos de privacidad podría hardware (por ejemplo, etiquetas RFID, sensores, mote sensor, teléfonos
estar prohibido por la ley (por ejemplo, en la UE [65]), ya que violan la privacidad de inteligentes), la potencia y la memoria dispositivos, análogo a los dispositivos
los ciudadanos. digitales del convertidor (A / D), el módulo de comunicaciones disponibles en esos
dispositivos, y el nivel de infraestructura o red información (por ejemplo, la topología
de la red, tocoles pro), y los servicios proporcionados por estos dispositivos.
suposiciones relacionadas con el conocimiento global y determinista de la
disponibilidad de estos recursos no son válidos, como la infraestructura y el medio
ambiente de la IO es dinámica. Por necesidad, la intervención humana para el
descubrimiento de recursos no es factible, y por lo tanto un requisito importante para
la búsqueda de recursos es que se puede automatizar. Es importante destacar que,
cuando no hay una red de infraestructura, cada dispositivo debe anunciar su
IO presencia y los recursos que ofrece. Este es un modelo diferente a los sistemas
distribuidos centralizados, donde publicación de recursos, el descubrimiento y la
comunicación son generalmente administrados por un servidor dedicado.
mecanismos de descubrimiento también tienen que escalar bien, y no debe ser e fi
ciente dis- tribución de la carga descubrimiento, dada la composición de los
dispositivos con recursos limitados de la IO.
Fig. 3. Las aplicaciones potenciales de la IO [66].
• Administracion de recursos: Se espera que una calidad de servicio aceptable para

todas las aplicaciones, y en un entorno donde los recursos que están restringidas
B. Middleware en la IO y sus requisitos impacto en la calidad de servicio, tales como la IO, es importante que las
En general, un middleware abstrae las complejidades del sistema o hardware, aplicaciones disponen de un servicio que administra esos recursos. Esto significa
permitiendo que el desarrollador de aplicaciones para enfocar todo su esfuerzo en la que el uso de recursos deben ser controlados, los recursos asignados o
tarea a resolver, sin la distracción de las preocupaciones ortogonales en el sistema aprovisionado de una manera justa y recursos conflictos re resuelto. En las
o el hardware de nivel [67]. Tales complejidades pueden estar relacionados con las arquitecturas de la IO, especialmente en orientada al servicio o arquitecturas
preocupaciones de comunicación o a la computación más general. Un middleware virtuales basados en máquinas, necesidades middleware para facilitar recurso
proporciona una capa de software entre las aplicaciones, el sistema operativo y las potencialmente espontánea (de servicio) (re) composición, para satisfacer las
capas de comunicaciones de red, que faci- itates y coordina algún aspecto de necesidades de aplicación.
procesamiento cooperativo. Desde la perspectiva informática, un middleware
proporciona una capa entre el software de aplicación y software del sistema. En la • Gestión de datos: Los datos son clave en las aplicaciones de la IO. En la IO, los datos se
IO, no es probable que sea considerable heterogeneidad tanto en las tecnologías de refiere principalmente a los datos detectados o cualquier información infraestructura de la
la comunicación de uso, así como las tecnologías de nivel de sistema, y un red de interés para aplicaciones. Un middleware IO necesita proporcionar vicios de
middleware debe apoyar ambas perspectivas como sea necesario. Sobre la base de gestión de datos ser- a las aplicaciones, incluyendo la adquisición de datos,
las características anteriormente descritas de la infraestructura de la IO y las procesamiento de datos (incluyendo pre-procesamiento), y almacenamiento de datos.
aplicaciones que dependen de ella, una serie de requisitos para un middleware para procesamiento previo puede incluir fi ltrado de datos, compresión de datos, y la
apoyar la IO se perfila. En la siguiente manera, estos requisitos se agrupan en dos agregación de datos.
conjuntos: primero, los servicios de un middleware, que debería ofrecer, y segundo,

la arquitectura del sistema debería apoyar. • Gestión de eventos: Hay potencialmente un número masivo de los eventos
generados en las aplicaciones de la IO, que debe ser manejada como una parte
integral de un dleware mediados de la IO. La gestión de eventos transforma
eventos observados simples en eventos significativos. Se debe proporcionar un
análisis en tiempo real de datos de alta velocidad para que las aplicaciones
1) Requisitos del servicio Middleware: requisitos de servicio Middleware posteriores son impulsados por la información precisa en tiempo real y la
para la IO se pueden categorizar como funcional y no funcional. Requisitos inteligencia.
funcionales capturan los vicios o funciones Ser- (por ejemplo, abstracciones,
gestión de recursos) • Gestión de código: La implementación de código en un ENTORNO IO
cosas Diario
Los usuarios o aplicaciones de la IO

Mayor seguridad superficie de ataque
Tiempo real Inteligencia
diversas aplicaciones
Todo-as-a-service
Consciente del contexto Las fugas de privacidad
Middleware para la IO
Requisitos del servicio middleware Requisitos arquitectónicos Características de la IO
Abstracción de programación
Requerimientos funcionales Características de la IO Requerimientos no funcionales Características de la IO
heterogéneos y
Detección de recursos Recursos limitados, dinámico, sin Aplicaciones diversas., Ultra Red grande, heterogéneo interoperable red
escalabilidad
infraestructura, Tiempo real dispositivos y la red, el número de eventos
Administracion de recursos Inteligencia, dinámico, sensible al contexto, con recursos
sensibles al contexto
limitados, basadas en la localización
Seguridad Mayor seguridad superficie de ataque
Gestión de datos Ultra-grande de datos a escala
Recursos limitados, dinámico, sin infraestructura Autónoma

Las interacciones espontáneas grande disponibilidad Inteligencia, dinámico, sensible al contexto, con
Gestión de eventos número de eventos, Tiempo real recursos limitados, sin Infraestructura
Recursos limitados, dinámico, sin infraestructura adaptativo
dispositivos heterogéneos y de red, y Aplicaciones
fiabilidad
Gestión de código diversas
Tiempo real Tiempo real , Gran número de eventos orientada a servicios Todo-as-a-service
Intimidad Las fugas de privacidad Ligero Diversos recursos limitados Aplicaciones. dispositivos
leyendas: El texto rojo: directamente relacionado

El texto negro: indirectamente relacionados
Repartido Distribuido, dinámico, sin infraestructura
Consciente de la ubicación Los dispositivos heterogéneos recursos limitados Mayor seguridad superficie de ataque big Data Dinámica
Las interacciones espontáneas Un gran número de eventos Repartido sin Infraestructura Ultra grandes redes Las redes heterogéneas
dispositivos redes
Infraestructura para la IO
Fig. 4. Las relaciones entre las aplicaciones de la IO y la infraestructura y sus requisitos de middleware.
ción es un reto, y debe ser soportado directamente por el middleware. En bilidad, que incluye comunicación, datos, tecnologías y dispositivos de
particular, se requieren servicios de asignación de código y migración de código. todas las capas.
asignación de código selecciona el conjunto de dispositivos o nodos de sensores • Disponibilidad: Un middleware apoyo aplicaciones de un IO, especialmente los de
para ser utilizado para realizar una tarea nivel de usuario o aplicación. misión crítica, debe estar disponible, o aparecen disponibles en todo momento.
transferencias migración de código un nodo / código de dispositivo a otro, Incluso si hay un fallo en alguna parte del sistema, su tiempo de recuperación y la
potencialmente la reprogramación de los nodos de la red. El uso de los servicios frecuencia de la insuficiencia deben ser lo suficientemente pequeño como para
de migración de código, el código es portátil, lo que permite el cálculo de datos lograr la disponibilidad deseada. Los requisitos de fiabilidad y disponibilidad deben
para ser re-situado. Llave no funcional requisitos de la IO middleware de trabajar juntos para asegurar la más alta tolerancia a fallos requerida desde una
seguimiento: aplicación.
• Seguridad y Privacidad: La seguridad es fundamental para el funcionamiento de la

• escalabilidad: Un middleware de la IO debe ser escalable para adaptarse al
IO. En la IO middleware, la seguridad debe ser considerada en todos los bloques
crecimiento de la red y aplicaciones / servicios de la IO. Teniendo en
funcionales y no funcionales que incluyen la aplicación a nivel de usuario.
cuenta el tamaño de la red de la IO, IPv6 es una solución muy escalable
Contexto-conciencia en middleware puede revelar información personal (por
para direccionabilidad, ya que puede hacer frente a un gran número de
ejemplo, la ubicación de un objeto o una persona). Al igual que la seguridad, cada
cosas que deben ser incluidos en la IO [68]. acoplamiento y / o la
bloque de middleware, que utiliza información personal, tiene que preservar la
virtualización sueltos en middleware es útil para mejorar la escalabilidad,
privacidad del usuario.
especialmente la aplicación y la escalabilidad de nivel de servicio, ocultando
la complejidad de la lógica de hardware o servicio subyacente y aplicación.
• La facilidad de despliegue: Desde un middleware de la IO (o, más probablemente, las
actualizaciones del middleware) es típicamente desplegados por el usuario (o el
propietario del dispositivo), el despliegue no debe requerir conocimiento o apoyo de
• En tiempo real o la actualidad: Un middleware debe proporcionar servicios en
expertos. procedimientos de instalación y configuración complicados deben ser
tiempo real cuando la corrección de una operación que SUP- puertos depende
evitados.
no sólo de su corrección lógica, sino también en el momento en que se realiza.
• Popularidad: Un middleware de la IO (al igual que cualquier otra solución de
A medida que la IO se ocupará de muchas aplicaciones en tiempo real (por
software) debe ser apoyado y ampliado continuamente. Por lo general, esta
ejemplo, el transporte, la salud), la entrega a tiempo de información o servicios
facilidad se proporciona dentro de una comunidad de desarrolladores e
en aquellas aplicaciones es crítico. información o servicios retrasada en tales
investigadores. Si bien esto no es necesariamente un requisito, un gran número
aplicaciones pueden hacer que el sistema inútil e incluso peligroso.
de usuarios que adoptan una tecnología particular motiva pruebas y desarrollo
futuro.
• Confiabilidad: Un middleware debe permanecer en funcionamiento durante la 2) Requisitos de arquitectura: Las exigencias arquitectónicas incluidos en esta
duración de la misión, incluso en presencia de fallos. La fiabilidad del middleware sección están diseñados para apoyar a los desarrolladores de apli- cación. Ellos
de última instancia, ayuda en el logro de fiabilidad a nivel de sistema. Cada incluyen los requisitos para abstracciones de programación, y otras preocupaciones a
componente o servicio en un middleware necesita ser confiable para lograr fiabi- nivel de aplicación.
general • Abstracción de programación: Proporcionar una API para aplica-
cosas Diario
desarrolladores ción es un requisito funcional importante para cualquier ofertas de servicios esenciales a los usuarios.
middleware. Para el desarrollador de la aplicación o servicio, interfaces de • Autónomo: Autónoma significa auto-gobernados. vicios / tecnologías /
programación de alto nivel necesitan para aislar el desarrollo de las aplicaciones de- participan activamente en los procesos de la IO y ellos
aplicaciones y servicios de las operaciones proporcionadas por los deberían ser capaces de interactuar y comunicarse entre sí sin
subyacentes, las infraestructuras de IO heterogéneos. El nivel de intervención hu- directa [5], [73]. El uso de la inteligencia incluyendo
abstracción, el paradigma de la programación, y el tipo de interfaz todos agentes autónomos, inteligencia integrada [74], predictivo y enfoques
necesitan ser considerados cuando se de fi nir una API. El nivel de proactivos (por ejemplo, un motor de predicción) en middleware pueden
abstracción se refiere a cómo el desarrollador de aplicaciones ve el sistema ful fi l este requisito [75].
(por ejemplo, nivel de nodo / dispositivo individual, nivel de sistema). El
paradigma de programación (por ejemplo, publicación / suscripción) ofertas • Repartido: / dispositivos / usuarios de un sistema IO a gran escala Aplicaciones-
con el modelo de desarrollo o programación de las aplicaciones o servicios. (redes por ejemplo, WSNs, Vehicular ad hoc) el intercambio de información y
El tipo de interfaz define el estilo de la interfaz de programa- ción. Por colaboran entre sí. Tales aplicaciones / dispositivos / usuarios son susceptibles de
ejemplo, las interfaces descriptivos ofrecen lenguajes tipo SQL para la ser distribuidos geográfi- camente, y así una visión centralizada o aplicación
consulta de datos [69], middleware no serán su fi ciente para soportar muchos servicios distribuidos o
aplicaciones. Un middleware Implementation necesita para apoyar las funciones que
se distribuyen a través de la infraestructura física de la IO. La Figura 4 presenta las
• interoperable: Un middleware debe trabajar con dispositivos / relaciones entre los requisitos dleware mediados de la IO y sus características
aplicaciones / tecnologías heterogéneas, sin adiciones esfuerzo cional infraestructurales y de aplicación. Como se muestra en la figura, la mayor parte de
desde el desarrollador de la aplicación o servicio. componentes las exigencias están directamente relacionados (texto de color rojo) a uno o más
heterogéneos deben ser capaces de intercambiar datos y servicios. carac- terísticas de la IO. Algunos de ellos también están vinculados indirectamente
Interoperabilidad en un middleware se puede ver desde la red, (texto negro) a una o más características de la IO. Para postura in-, el requisito de
sintácticos y semánticos perspectivas, cada una de las cuales deben ser comportamiento en tiempo real está directamente relacionada con las características
atendidas en un IO. Una red deberían intercambiar información a través en tiempo real de la aplicación e indirectamente a la gran cantidad de eventos.
de diferentes redes, potencialmente el uso de diferentes tecnologías de Además, algunos de los requisitos de middleware (por ejemplo, la localización de
comunicación. interoperación sintáctica debe permitir de formato y recursos, gestión de recursos) capturan conjuntamente el mismo conjunto de
codificación de estructuras heterogéneas de cualquier intercambia características de la IO.
información o servicio. la interoperabilidad semántica se refiere al
significado de la información o un servicio, y debería permitir el
intercambio entre la siempre creciente y cambiante conjunto de
dispositivos y servicios de la IO.
III. O ISIÓN DE trabajo existente
Middleware en la IO es un área de investigación muy activa. Muchas soluciones se han

propuesto e implementado, especialmente en el último par de años. Estas soluciones son
muy diversos en sus enfoques de diseño (por ejemplo, basado en eventos, bases de datos),
el nivel de abstracciones de programación (por ejemplo, a nivel local o nodo, de nivel
• basada en los servicios: Una arquitectura de middleware debe ser ofrecer alta mundial o de la red), y dominios de aplicación (por ejemplo, redes inalámbricas de sensores,
flexibilidad basada en el servicio cuando las nuevas y avanzadas funciones RFID, M2M, y SCADA).
necesitan ser añadido a un middleware de la IO. Un middleware basado en

servicio proporciona abstracciones del hardware subyacente complejo a través En este estudio, las soluciones de middleware existentes se agrupan para la discusión sobre
de un conjunto de servicios (por ejemplo, gestión de datos, fiabilidad, seguridad) la base de sus enfoques de diseño, como a continuación:
necesarios por las aplicaciones. Todos estos y otros servicios avanzados se • Basado en Eventos
pueden diseñar, implementar, y se integran en un marco basado en los • orientada a servicios
servicios para ofrecer un entorno flexible y fácil fl para desarrollo de • basada en la máquina virtual
aplicaciones. • Agente de base
• Tupla-espacios
• Adaptado: Un middleware debe ser adaptable para que pueda evolucionar para • Base de datos orientada
encajar en sí en cambios en su entorno o las circunstancias. En la IO, la red y • Application-específica

su entorno de es- es probable que cambien con frecuencia. Además, las Algunos middleware utilizan una combinación de diferentes enfoques de diseño. Por
demandas de nivel de aplicación o el contexto también son susceptibles de ejemplo, muchos middlewares servicio orientado (por ejemplo, SOCRADES, Servilla) también
cambiar con frecuencia. Para asegurar la satisfacción del usuario y eficacia de emplean máquinas virtuales en su diseño y desarrollo. Por lo general, los enfoques
la IO, un middleware necesita adaptarse dinámicamente o ajustarse para híbridos funcionan mejor que sus categorías individuales de diseño mediante la adopción
encajar todas estas variaciones. de las ventajas de múltiples enfoques.
• Sensible al contexto: Sensibilidad al contexto es un requisito clave en la En el interés del espacio, la discusión de cada obra destaca únicos puntos
construcción de sistemas adaptativos y también para establecer el valor de los clave, sin capturar exhaustivamente su rendimiento frente a todas las
datos detectados. middleware arquitectura de la IO tiene que ser consciente del necesidades. Para cada grupo, los trabajos correspondientes se presentan en
contexto de usuarios, dispositivos, y el medio ambiente y el uso de estos para orden cronológico. Ver las Tablas I, II y III para un resumen completo.
efectiva y
cosas Diario
Middlewares basado en eventos A. EMMA [ 27] es una adaptación de Java Message Service (JMS) para entornos
móviles ad hoc. Está diseñado para sistemas de comunicación de vídeo multipartidista
Capa de aplicación
usuarios como el chat de vídeo, donde varias secuencias de vídeo se distribuyen de forma
<Suscribirse> simultánea en redes superpuestas [80]. EMMA está disponible, fiable y autónoma a
capa de middleware través de un mecanismo de recuperación rápida, que también hace que sea tolerante a
tematema fallos. Además, EMMA ofrece múltiples estilos de mensajería. Con el fin de poner en
Tema
práctica los diferentes niveles de su confiabilidad, EMMA golosinas persistentes y
mensajes no persistentes de manera diferente. EMMA proporciona muy buen
<Publicar> rendimiento en términos de relación de distribución y la latencia. Sin embargo, el
Capa fisica equilibrio entre el enrutamiento a nivel de aplicación y el uso de recursos no se toma en
consideración. Además, debido a su enfoque de diseño, EMMA
IO Infraestructura (Publishers)
Fig. 5. modelo de diseño general para un Middleware Event-Based.
es deficiente no-ef energía. Además, el apoyo para la fiabilidad es limitada.

En el middleware basado en eventos, componentes, aplicaciones y todos los
demás participantes interactúan a través de eventos. Cada evento tiene un tipo, así VERDE [ 81] es un tiempo de ejecución, gurable fi altamente acondicionado y recon fi
como un conjunto de parámetros con tipo cuya específico valores describir la especí middleware basado en eventos gurable desarrollado para soportar aplicaciones de
cambio fi c a estado del productor. Los eventos se propagan a partir de los computación ubicua que utilizan redes heterogéneas y dispositivos heterogéneos. VERDE
componentes de las aplicaciones que envían (productores), a los componentes de la está desarrollado para funcionar en diversos tipos de red (es decir, MANETs y WANs).
aplicación que reciben (consumidores). Un sistema de eventos (servicio de evento), También soporta Pub tipos conectables / Sub de interacción tales como, basándose
puede consistir en un número potencialmente grande de componentes de aplicaciones tema-, basado en el contenido, el contexto, eventos compuestos. La alta evento flujo en el
(entidades) que producen y consumen eventos [76]. Orientado a mensajes middleware sistema se proporciona mediante la sustitución de la interacción basada contenido- con
(MOM) es un tipo de middleware basado en eventos. En este modelo, la comunicación una interacción basada en el tema. VERDE si- mínimos de aproximación de Lancaster a la
se basa en los mensajes, que incluyen metadatos extra en comparación con los construcción de re fi gurable con-medianos mercancías plataformas. Está construido
eventos. En general, los mensajes llevan direcciones de remitente y receptor y que utilizando el modelo de componentes no distribuido ligero. VERDE 's fortalezas son el
son entregados por un determinado subconjunto de los participantes, apoyo a la programabilidad re y puede operar sobre los tipos de trabajo Net-
heterogéneos. Su estructura de componentes es ligero y permite un comportamiento
dinámico. Sin embargo, VERDE No es autónoma y tiene soporte para la interoperabilidad
limitada. Además, su apoyo para la adaptación se limita al nivel de red. Además, el uso de
Típicamente, Basado en Eventos middleware usos el redes superpuestas trae serios desafíos en el cumplimiento de los requisitos de
publicar / patrón suscribirse. Este modelo contiene un conjunto de abonados y un middleware de la IO.
conjunto de editores (como se muestra en la Fig. 5). Los abonados están provistos
de acceso a flujos de datos de las editoriales a través de una base de datos común
y que están registrados para eventos particulares. Los cationes notificada acerca de
los eventos se envían posteriormente y de forma asíncrona a los abonados [77], RUNAS [ 82] es un middleware basado en componentes para gran escala y
[22]. Este enfoque de diseño se ocupa de los requisitos no funcionales, tales como ampliamente distribuida red heterogénea de los sistemas de ded embed-. Se
la fiabilidad, disponibilidad, introduce una arquitectura estandarizada capaz de auto-organización y la adaptación
tiempo real dinámica a un entorno cambiante. Me gusta VERDE, RUNES 'S arquitectura sigue el
el rendimiento, la escalabilidad y la seguridad [78]. enfoque de Lancaster, que reduce el acoplamiento de componentes de middleware y
Hermes [ 79] es un middleware basado en evento creado para las aplicaciones admite la adición de nuevos componentes en tiempo de ejecución.
distribuidas a gran escala. Hermes eventos pueden ser ya sea basada en atributos
basados en tipo o. Se utiliza un algoritmo escalables mecanismos ing rout- y de tolerancia RUNES este proyecto se centra en el diseño de un marco donde los nuevos componentes se
a fallos que pueden tOL- tipos diferentes erate de fallos en el software intermedio. pueden instalar en tiempo de ejecución. Sin embargo, no está claro si esto se puede hacer
Además de la escalabilidad, que aborda los requisitos de interoperabilidad y fiabilidad. Hermesde forma remota, una vez que se ha desplegado el middleware. También, RUNES no
tiene dos componentes, clientes y corredores de eventos de eventos. En su arquitectura, Hermes
proporciona una visión integral de las necesidades de middleware de la IO y no considera los
tiene las siguientes capas: la capa middleware, la capa basada en eventos, basado en el dispositivos en recursos ricos en entornos heterogéneos.
tipo y la basada en atributos Pub / capa sub, superposición de encaminamiento de capa
de red y la capa de red. La capa de middleware basada en eventos proporciona una API El vapor [ 76], MiSense [ 83], [84], PSWare [ 85], TinyDDS [ 86] son otros ejemplos de
que los programadores utilizar para implementar aplicaciones. La capa de middleware middleware basadas en eventos. Vapor es un servicio de middleware basado en
consta de varios módulos que implementan funcionalidades tales como tolerancia a fallos, eventos, diseñado para el dominio de la informática móvil. Utiliza diferentes tipos de
entrega de eventos fiable, tipo de evento descubrimiento, la seguridad, las transacciones. eventos para hacer frente a los problemas relacionados con la dinámica de
La movilidad está limitada en términos de una topología de red dinámica. Hermes no reconfiguración de la red, la escalabilidad de un sistema y la entrega en tiempo real de
soporta eventos compuestos o almacenamiento persistente para eventos. Además, su los acontecimientos. MiSense es un peso ligero en capas middleware basado en
apoyo para la adaptación se limita al nivel de red. clúster que separa semántica de aplicación del hardware subyacente, el sistema
operativo, y la infraestructura de red. En
MiSense, cada nodo posee un corredor que gestiona los mensajes rados
generaciones. Esto sobrecarga el nodo, y hace que la
cosas Diario
recursos-ine fi ciente de middleware. PSWare es un middleware basado en tiempo ampliamente utilizado.
real por eventos de WSN, desarrollado para apoyar eventos compuestos. Mires [ 88] es otra MOM para WSNs. Usando el patrón o l pu- / suscripción, Mires permite
Proporciona abstracciones de alto nivel, y logra una alta expresividad y la suscribe para seleccionar los flujos de datos que les interesa y recibir datos directamente
disponibilidad. TinyDDS [ 86] middleware en- Ables interoperabilidad entre redes de los sensores solicitados. Mires permite a los sensores para llevar a cabo la agregación
inalámbricas de sensores y redes de acceso. Proporciona lenguaje de de datos local para reducir el número de transmisiones de mensajes y consumo de
programación e interoperabilidad protocolo basado en el servicio de distribución de energía. Mires ha sido diseñado para facilitar el desarrollo de aplicaciones a través de
datos estándar (DDS) espec- i fi cación. los TinyDSS marco permite aplicaciones redes inalámbricas de sensores. Sin embargo, Mires
WSN tengan control sobre el nivel de aplicación y propiedades no funcionales a
nivel de middleware. Simulación y resultados de las evaluaciones empíricas no ofrece soporte para mensajes persistentes. Además, no es compatible con
mostraron que TinyDDS es ligero y tiene poca memoria. Sin embargo, TinyDDS no una topología de red dinámica y no tolera errores. El trabajo realizado con
proporciona una visión integral de las necesidades de la IO y no aborda los respecto a un middleware de la IO es limitado y Como SensorsBus, se centra Mires
requisitos clave de la IO como la adaptación. Además, no ofrece un mecanismo de sólo en ciertos requisitos y no proporciona una visión integral de las
control de topología. Vapor, PSWare, MiSense, necesidades de middleware de la IO.
Junto a las madres, hay corredores MQ, que ofrecen apoyo a las
y TinyDDS no se refieren a la heterogeneidad de una infraestructura de la IO. Estas soluciones comunicaciones M2M entre los servicios o proveedores de servicios y los
de middleware se han diseñado sólo para redes inalámbricas de sensores o dispositivos abonados al servicio, la conversión entre diferentes protocolos de transporte y
móviles. homogeneización de flujos mensaje entre abonados y proveedores. WebSphere
PRISMA [ 29] es un middleware basado en eventos orientados al recurso para MQ [ 89] y mosquitto [ 90] son ejemplos de este enfoque.
WSN. Al proporcionar un alto nivel y una interfaz estandarizada para el acceso a
datos, PRISMA apoya la interoperabilidad de las tecnologías de redes heterogéneas. WebSphere MQ, Actualmente conocido como IBM MQ [ 91], mantiene las colas de
PRISMA es pop-ular entre los desarrolladores, y alienta a los primeros usuarios. los mensajes, las relaciones entre los programas y las colas, manipulación reinicia la
red y que se mueven los mensajes por la red. La gestión de los recursos se centra
PRISMA diseño despliega una arquitectura en capas, compuesto por tres capas: en la gestión de colas, que establece la comunicación BE- tween varios gestores
acceso, servicios y aplicaciones. La capa de acceso gestiona la comunicación, de colas. Los eventos son tratados como datos no interpretados, lo que implica
adquisición de datos, la verificación de los requisitos de calidad de servicio y recon fi que WebSphere MQ no admite la sensibilidad al contexto. Además, no es
guración. Reconfiguración se apoya en varios casos (por ejemplo, fallo del dispositivo). compatible con eventos compuestos o complejos mensajes de manipulación. mosquitto
La capa de servicio proporciona un componente de descubrimiento de recursos. La es un corredor MQTT que permite la comunicación entre los abonados y los
capa apli- cación ofrece apoyo para la extracción de programación y es responsable de editores a través de una suscripción tema. Su objetivo principal es la creación de
recibir y administrar mensajes de aplicaciones. PRISMA asume una WSN heterogénea canales de comunicación y qué no trata a los requisitos de la IO. Recientemente,
y jerárquica, con tres niveles: Gateway, Cabeza de clústeres y nodo sensor. Sin se han propuesto muchas soluciones de agente de MQ. Sin embargo, estos no
embargo, este enfoque centralizado crea cuellos de botella en los nodos del fregadero. fueron diseñados para un entorno de la IO.
La versión actual no es compatible con fuerza en tiempo real o adaptación dinámica.
Además, el enfoque de descubrimiento de servicios centralizados no escala bien en la
IO. Además, proporciona un apoyo limitado a la interoperabilidad ya que utiliza una
plantilla de descripción de servicio personalizado. Además, fue diseñado e middleware basados en eventos son apropiadas en sistemas donde la movilidad y
implementado en una plataforma Arduino. El trabajo futuro se propone volver a diseñar los fracasos son comunes. Una ventaja principal de este enfoque es el apoyo a una
la arquitectura de PRISMA para habilitar el soporte para la dinámica de reconfiguración fuerte disociación entre los productores y los suscriptores. Aunque muchos desafíos son
fi en tiempo de ejecución. abordados por la mayoría de los middleware basadas en eventos, su apoyo no es
totalmente satisfactorio, en particular, la interoperabilidad, adaptabilidad, Liness tiempo
y sensibilidad al contexto no se abordan adecuadamente. middleware basados en
eventos también son raramente autónoma. El paradigma de la programación de
SensorBus [ 87] es una madre para redes inalámbricas de sensores. Permite ex middleware basadas en eventos no es su fi cientemente flexible en muchos casos.
cambio libre de más de un mecanismo de comunicación entre los nodos de sensores. protocolos apropiados y modelos para la seguridad y la privacidad deben ser
Para responder a la solicitud de servicio de aplicaciones en varios contextos, SensorBus desarrollados.

proporciona servicios de personalización a través de metadatos. Su arquitectura tiene
tres capas, desarrollado para servicios de aplicaciones, el mensaje y el contexto. La
capa de servicios de aplicaciones proporciona una API que simplifica el desarrollo de Middlewares Orientadas a Servicios B.
aplicaciones. Esta capa también despliega filtros de aplicaciones para agregar datos El paradigma de diseño orientada a servicios construye software o aplicaciones
interna, lo que reduce los datos de flujo en la obra NET, lo que lleva a la reducción de en forma de servicios. Orientada al servicio ing computa- (SOC) se basa en la
consumo de energía en los nodos sensores. La capa de servicio de mensajes es arquitectura orientada a servicios (SOA) y se ha utilizado tradicionalmente en los
responsable de proporcionar la comunicación y coordinación de los componentes sistemas de TI corporativos. Las características de SOC, como neutralidad de la
distribuidos, abstrayendo el desarrollador de estas cuestiones. La capa de servicio de tecnología, el acoplamiento flojo, reutilización servicio, servicio posability com-,
contexto gestiona los sensores heterogéneos que recopilan información del entorno. servicio de detectabilidad [92], son también potencialmente beneficioso para
No ofrece una visión integral de las necesidades de middleware de la IO, y no es aplicaciones de IO. Sin embargo, la red a gran escala, dispositivos de recursos
limitados, y terísticas ultra movilidad ticas de la IO hacen descubrimiento y
composición de servicios desafiante.
cosas Diario
Un middleware orientada a servicios (SOM) tiene el potencial para aliviar estos retos recursos informáticos. Estos problemas hacen que no sea adecuado para
mediante la provisión de funcionalidades apro- AP- (como se muestra en la Fig. 6) para entornos de IO, que son ultra gran escala, con redes heterogéneas y diversas
despliegues servicios ing, publicación / descubrimiento y el acceso en tiempo de ejecución. aplicaciones.
SOM también proporciona soporte para composiciones de servicios de adaptación cuando los MUSIC [ 70] middleware proporciona una arquitectura basada en
los servicios no están disponibles. Un gran número de middleware de la IO orientada a componentes auto-adaptativo para apoyar la construcción de sistemas en entornos
servicios están disponibles. Estos middlewares se pueden categorizar como SOM ubicuos y SOA, donde pueden ocurrir cambios dinámicos en proveedores de
independiente para la IO [93] - [97] o servicios de middleware proporcionados por la servicios y de servicios Los consumidores contextos. En particular, MÚSICA se
plataforma de computación en la nube como un modelo de servicio (PaaS) [98] - [100]. centra en los cambios en un sitio de proveedor de servicios, para el intercambio de
componentes y servicios que proporcionan la funcionalidad definida por el marco
de componentes. Para apoyar con QoS y adaptación dinámica basada en el
contexto, su arquitectura contiene un gestor de contexto, gerente de calidad de
Capa de aplicación
servicio, gerente de adaptación, repositorio plan, SLA negociador y monitorización,
Los consumidores de servicios
detección de servicios y estos componentes pro-vide diferentes funcionalidades
<Consulta> para el middleware. Por ejemplo, en la adaptación basada en la planificación, la
capa de middleware
planificación (disponible en un repositorio plan) está normalmente provocada por los
Datos Descubrimiento Servicio de Gestión de Servicio cambios de contexto detectados por el gestor de contexto. Con el apoyo de estos
Servicio de Gestión de Gestión de calidad de servicio componentes, las adaptaciones dinámicas funcionan automáticamente para
optimizar la utilidad de la aplicación en un contexto dado. Contexto puede contener
Capa fisica una gran cantidad de datos privados y sensibles (por ejemplo,
Nube
Registro distribuido Los productores de servicios (IO) Infraestructura
Fig. 6. El diseño del modelo general para un middleware orientado al servicio. TinySOA [ 105] es un SOM que ofrece un alto nivel de abstracción de la
infraestructura para el desarrollo de WSN aplicaciones. Proporciona una API simple
Hydra [ 101], que se conoce actualmente como LinkSmart [ 102], es un middleware para orientada al servicio a través del cual los desarrolladores de aplicaciones pueden
servicios y sistemas (IAM) inteligencia ambiental. Está construido sobre una arquitectura acceder a los recursos de sus aplicaciones WSN. Maneja WSN dispositivo y nivel de
SOA y la arquitectura basado en modelos. Su arquitectura se compone de una serie de comunicación heterogeneidad, y ofrece una fácil integración de aplicaciones de Internet
componentes de gestión, incluyendo un gestor de servicios, gestor de eventos, el con redes inalámbricas de sensores que les permiten recoger información de los
administrador de dispositivos, gestor de almacenamiento, gestor de contexto, y gerente sensores. TinySOA emplea mecanismos simples y deterministas para recurso WSN (por
seguridad. Estos componentes se agrupan en aplicaciones y dispositivos elementos, ejemplo, el nodo sensor) de registro y descubrimiento. Es compatible con sólo unos
cada uno de los cuales tiene una capa semántica, capa de servicio, la capa de red, y capa pocos los requisitos funcionales básicos (por ejemplo, abstracción, de localización y
de seguridad. Hidra proporciona interoperabilidad nivel sintáctico y semántico usando gestión de recursos).
servicios web semánticos. Además de un número de mentos funcionales requisitos (por
ejemplo, gestión de datos, la gestión de eventos, gestión de recursos), soporta los SOCRADES [ 93] middleware abstrae las cosas físicas como servicios
reconfiguración dinámica fi y auto-configuración con fi. Hidra 'S de recursos, los utilizando dispositivos Per fi l para Servicios Web (DPWS). Se ha extendido dos
administradores de dispositivo y la política hacen que sea ligero, optimizando el consumo trabajos anteriores [106], [107]. SOCRADES
de energía en dispositivos con recursos limitados. componentes de seguridad distribuida y simpli fi ca la gestión de dispositivos o cosas para las aplicaciones empresariales (por ejemplo,
la confianza social ofrecen una comunicación segura y confiable dentro de los automatización industrial) subyacente. Su arquitectura consiste en una capa de servicios de
dispositivos. Su solución de seguridad y privacidad utiliza zación virtual- y una aplicaciones (por ejemplo, almacenamiento de eventos) y una capa de servicios de dispositivo
implementación de mecanismos basados en WS ES- riched por la resolución semántica (por ejemplo, Administrador de dispositivos y del monitor, de descubrimiento de servicios, de
[101]. Sin embargo, su virtualización puede introducir problemas de seguridad (por gestión de ciclo de vida de servicio). Diferentes componentes en las fi l diferentes requisitos de
ejemplo, ataques de canal lateral). Además, las soluciones de seguridad y de dos capas ful de SOM. Por ejemplo, el componente de descubrimiento de servicios de la capa de
interoperabilidad semántica basada en ontologías es probable que sean inadecuados en servicios dispositivo, una contribución clave de SOCRADES middleware, descubre los servicios
la IO, ya que, actualmente, no existen estándares para las ontologías de ultra gran escala proporcionados por los dispositivos del mundo real o cosas, mientras que su administrador de
de la IO. dispositivos se encarga de la gestión de recursos (por ejemplo, acceso dispositivo). También
ofrece servicio de dispositivo y descubrimiento. La capa de servicios de aplicaciones proporciona
la gestión y almacenamiento de eventos. los SOCRADES Catálogo de Servicios Cruz-capa de
middleware, que se encuentra entre las capas de dispositivos y aplicaciones, es compatible con
los SenseWrap [ 103] middleware combina la conf Zero- [104] protocolos con la composición de servicios, que puede no ser totalmente dinámico, como la composición se
abstracción de hardware utilizando sensores virtuales. Un sensor virtual proporciona basa en predeter- fi nida bloques de construcción. el control de acceso basado en roles de la
descubrimiento transparente de los recursos, principalmente sensores, mediante el uso comunicación a los dispositivos de middleware y servicios de back-end, y viceversa, funciona
de tocoles pro- zeroconf, que las aplicaciones pueden utilizar para descubrir los como una solución de seguridad, sino que se limita a sólo la autenticación. Por otra parte, el
servicios sensores alojada. SenseWrap También proporciona una interfaz de comu- acceso directo a los dispositivos o sus servicios ofrecidos a través de este middleware aumenta
nicación estandarizado para ocultar los detalles fi c sensor-específico de las el riesgo de violaciónes de privacidad.
aplicaciones. Esta interfaz depende de modelado de sensor y envoltorios

personalizados (drivers) para cada modelo de sensor. Además, la virtualización se
aplica sólo a los sensores, no a los actuadores o
cosas Diario
SensorsMW [ 108] es un SOM flexible adaptable y fl de QoS con fi guración y en una WSN. La máquina virtual ejecuta tareas de aplicaciones Mientras que las descubre
gestión de redes inalámbricas de sensores. Se abstrae WSNs como un conjunto SPF-consumo y accede a los servicios, y el proveedor de SPF- anuncia y ejecuta
de servicios para una perfecta integración en un sistema de información servicios. Se explota el servicio dinámico vinculante y la semántica de vinculación para
empresarial. Esto permite una fácil y e fi ciente con fi guración de las redes apoyar el despliegue tarea dinámica y movilidad tarea. unión servicio dinámico
inalámbricas de sensores para la recopilación de información mediante servicios proporciona energía e fi ciente la colaboración dentro de la red entre los dispositivos
web. Recursos en una WSN son gestionados para cumplir con ciertos requisitos heterogénea. Una descripción del servicio lenguaje especializado facilita la adaptación
de calidad de servicio, de acuerdo con los SLA. Es importante destacar, que flexible entre las aplicaciones y los servicios que residen en el mismo o diferentes
ofrece una manera abstracta para acceder a estos recursos para aplicaciones de dispositivos, pero estos requisitos especializados de idiomas podría limitar la adopción
alto nivel para recon fi gura y mantener la red durante su vida. Por lo tanto, las más amplia de este middleware. Por otra parte, el acceso a nivel individual de los
aplicaciones pueden controlar y hacer compensaciones entre con fl problemas sensores podría introducir violaciónes de privacidad y las amenazas a la seguridad. Servilla
contradictorios (por ejemplo, vida útil y velocidad de muestreo). recon fi guración no se utiliza ampliamente.
de recursos y la gestión necesitan descubrimiento de recursos, especialmente
en la IO móvil, donde los recursos son dinámicos, y éstos no se tratan aquí.
Además, en aplicaciones críticas, Kasom [ 110] es un conocimiento-Aware y orientada a servicios Middleware (Kasom)
para redes embebidas generalizados, especialmente para WSANs. Su arquitectura se
compone de tres subsistemas jor ma-: Servicios de marco (por ejemplo, seguridad,
gestor de tiempo de ejecución), servicios de comunicación (por ejemplo, el monitor de
los SENSEI [ 109] middleware desarrolla una arquitectura para el futuro y el mundo recursos), y servicios de gestión del conocimiento (por ejemplo, servicio de reglas
real de Internet incluyendo la IO. Es una de las primeras propuestas que incluyeron composi- ción, recursos de contexto). Estos servicios ofrecen un SOA para entornos
un modelo de contexto, los servicios de contexto, las tareas de actuación, y la penetrantes a través del registro, el descubrimiento, la composición y orquestación de
posición com- servicio dinámico de ambos servicios primitivas y avanzadas para el servicios. La mayor parte de estos servicios se establecen en los mecanismos de
mundo real de Internet. El componente principal de este middleware es la capa de razonamiento complejo y protocolos basados en el modelo contextual de la WSAN, lo
recursos, que se encuentra entre la capa de capa de aplicación y servicios de que representa una descripción semántica de los recursos de bajo y alto nivel de los
comunicación. recursos en SENSEI utilizar ontologías para su modelado semántico. WSANs. implementaciones de la vida real en el hospital y la gestión de la salud
Actualmente, no existen estándares para las ontologías de ultra gran escala de la IO, muestran su potencial en términos de tiempo de respuesta, e fi ciencia y la fiabilidad. Sin
que es probable que haga SENSEI inadecuado para la IO. embargo, Kasom no proporciona la composición de servicios dinámicos en el móvil y de
recursos limitados infraestructuras IO debido a las reglas de composición de servicios
Ned prede fi proporcionadas por los agentes de la red. Por otra parte, la solución de
ubiSOAP [ 94] es un SOM que proporciona una red sin fisuras de los servicios web. seguridad propuesto por el control de acceso se limita a la autenticación única.
capa de recursos de la arquitectura contiene las funciones necesarias, incluyendo la
abstracción uni fi ed para dispositivos PLE sim- (por ejemplo, sensores, actuadores,
procesadores o componentes de software) para facilitar la interacción de aplicaciones y
servicios con los recursos. Un componente de servicios de apoyo permite el
descubrimiento y composición dinámica de los recursos (por ejemplo, servicios). CHOReOS [ 111], [112] permite coreografías o composiciones de servicios
Composición dinámica y la instanciación de nuevos servicios son facilitados por los adaptables, QoS-aware, y heterogéneos en la IO a gran escala. Se dirige a la
modelos semánticamente ricos y descripciones de sensores, actuadores y elementos de escalabilidad, interoperabilidad, movilidad, y los problemas de adaptabilidad en los
procesamiento. La capa de recursos también contiene funciones para la privacidad y la enfoques a través de los registros de servicio escalable como probabilísticos basados
seguridad (por ejemplo, la autenticación). Su capa de red de radio multi-gestiona los en la cosa y erie descu- [45], [97]. CHOReOS se compone de cuatro componentes:
recursos de red heterogéneos utilizando un esquema de direccionamiento de la red Servicio ejecutables Composición (XSC) para coordinar la composición de los servicios
agnóstica y ofrece conectividad de red agnóstica a los servicios. Esta capa también y las cosas, extensible servicio de acceso (XSA) para acceder a los servicios y las
ofrece la funcionalidad de (por ejemplo, el consumo de energía, la disponibilidad) de cosas, extensible Servicio Desven- covery (XSD) para gestionar protocolos y procesos
selección de red compatibles con QoS. En general, ubiSOAP SOM es un peso ligero que de descubrimiento de servicios y las cosas, y la nube y middleware Grid para gestionar
ofrece la gestión de recursos y la interoperabilidad a nivel de red mediante el apoyo a los los recursos computacionales e impulsa el despliegue de coreografías. MobIoT, un
dispositivos de red heterogéneos y tecnologías. La falta de sensibilidad al contexto en ubiSOAP
componente clave de CHOReOS [45], [97], es un SOM basados en cosa para la IO
podría ser un problema, ya que es clave en la conducta adaptativa y autónoma de las Mobile. A diferencia de la mayoría de los SOM existentes [94], [110], su descubrimiento
cosas. Además, su enfoque sólo en la autenticación para la seguridad y la privacidad es de servicios probabilístico basado en la cosa, el registro y consulta de protocolos y
una preocupación para muchas aplicaciones de la IO. algoritmos de escala bien en la IO móvil dinámico. Además, las composiciones de
servicios basados cosa- semántica son transparente y automática ejecutable por MobIoT
y CHOReOS, sin la participación de los usuarios finales, lo cual es altamente deseable
en la IO, especialmente en las comunicaciones M2M. Sin embargo, sus registros de
servicio probabilísticos y mecanismos de descubrimiento pueden fallar para
Servilla [ 95] facilita el desarrollo de aplicaciones en redes inalámbricas de sensores proporcionar soporte en tiempo real duro debido a las redundancias insu fi ciente en los
heterogéneos. Utiliza SOC para desacoplar el código de plataforma específico de aplicaciones registros de servicios y servicios descubiertos. Por la misma razón, la fiabilidad de
independientes de la plataforma. lo estructura AP- complicaciones como tareas estos middleware podría ser un problema. Además,
independientes de la plataforma que se enlazan dinámicamente a los servicios de plataforma
específica. Servilla 'S arquitectura consiste en una máquina virtual (VM) y un servicio
provisionalmente marco ing (SPF) y se ejecuta en los nodos de sensores individuales
cosas Diario
de la semántica basada en ontologías va a ser muy difícil en entornos apoyo para la evolución legado y seguridad excepcional. Similar a Xively, CarrIoTs y
heterogéneos de la IO. otras plataformas en la nube, su capacidad de interoperabilidad se limita dentro de Escalón
Mosden ( Sensor móvil Motor de Procesamiento de Datos) [46] es compatible con 'S y una lista específico de otro hardware. Siendo una nube privada, su seguridad es
una detección como un modelo de servicio [113], construido encima de GSN [ 21]. El mejor que
uso de una arquitectura plug-in mejora la escalabilidad y facilidad de uso del Xively, pero la confianza sigue siendo un problema para las aplicaciones sensibles IIoT.
middleware, como complementos para dispositivos heterogéneos son más fáciles de El middleware presentado por Faghih et al. [119] está diseñado para redes de
construir y disponible en lugares de fácil acceso (por ejemplo, Google Play). Mosden añadido
sensores multimedia, y apoya la escalabilidad y la red heterogeneidad nivel. WhereX [ 120]
un gestor de plugin y una capa plugin para GSN para apoyar y manipular los plugins. está diseñado para RFID y principalmente soporta la gestión de datos. Esta sección
También sustituye envolturas individuales de sensor dependiente de GSN con un no incluye un conjunto exhaustivo de los SOM disponibles para la IO. Una serie de
único contenedor genérico para manejar las comunicaciones. GSN emplea una recientes obras representativas (desde 2009) hayan sido objeto de presentar el
arquitectura descentralizada P2P [114] y prede fi reglas de composición NED estado de la técnica de servicios orientados a la IO middleware. Un estudio de los
disponible en los sensores virtuales, que puede no funcionar bien en grandes redes SOM fi c WSN-específica (de fecha mayormente pre 2009) está disponible en [121].
dinámicas y Ultra de IOT. Me gusta GSN, Mosden sufrirá en un entorno IO debido a
sus mecanismos de origen re- prede fi ned / descubrimiento de servicios y
composición de servicios. Como SOC por naturaleza soporte a la abstracción y no trata explícitamente de
código, SOM existentes no tienen en cuenta de manera explícita la abstracción y la
gestión de código. La mayoría de SOM existentes son WSNs centrada y su escala se
Muchas plataformas IO basados en la nube están disponibles [115], [116]. Para limita a WSNs, que es típicamente en el intervalo de miles, mucho menor que el de ultra
proporcionar una impresión del campo, unos pocos de estos se resumen en la gran escala (mm de) de la IO. La mayoría de estos descubrimiento middlewares'
siguiente, y para los otros, los lectores se hace referencia a [115] y las referencias en recursos y la gestión, y sus mecanismos de prede fi composición Ned y determinista, no
él. se escala bien en entornos de ultra grandes y dinámicas de la IO. Se requiere una
Xively [ 99] es un PaaS que proporciona servicios de middleware para crear global, escalable y comprensión de sintaxis y la semántica de servicios de la IO. La
productos y soluciones para la IO. basado en la nube pública mayoría de los SOM independientes existentes sólo ofrecen una seguridad limitada a
Xively ofrece a los desarrolladores basados en estándares de servicios de directorio, datos y través de la autenticación. Además, la seguridad de almacenamiento de plataforma en la
servicios de oficina. Los servicios de directorio ayudan a fi nd objetos apropiados con el permiso nube y la confianza podría ser una preocupación para muchas aplicaciones de la IO.
apropiado. vicios de gestión de datos ser-, utilizando un alto rendimiento y una base de datos de
series de tiempo, almacenar y recuperar datos de forma fiable. Sus herramientas basadas en la
web simplifican los datos, control y otras complejidades del desarrollo de aplicaciones de la IO.
servicios de negocios incluyen un vicio de gestión de ciclo de vida del dispositivo de ser-
incluyendo aprovisionamiento de dispositivos. Xively 'S bus de gestión del ciclo de vida del
C. virtuales Middlewares Máquina-Basado
dispositivo y mensajes en tiempo real soporta despliegues a gran escala y en tiempo real en la
IO. Es importante destacar, que ofrece apoyo a la seguridad de extremo a extremo en toda la Capa de aplicación
usuarios
plataforma para garantizar la integridad de las soluciones de la IO. La falta de seguridad de
<Consulta>
almacenamiento [117] puede ser un problema en muchas aplicaciones de la IO. Es compatible
capa de middleware
con múltiples formatos de datos, sin embargo, no homogeneizar los datos entrantes de modo de
capa Capa
procesamiento de datos debe hacerse de forma individual para cada fuente o que necesita un <Modularizar>
VM
01001
10011
proceso de mapeo antes de normalizarlo. Esto crea una sobrecarga en el sistema. Además,
soporta una lista de combinaciones de software y hardware necesarios para desarrollar <Implementar>
Nodo de servicios de
aplicaciones de la IO, pero su apoyo a la interoperabilidad es limitado.
01001
VM 01001
VM 01001
VM 01001
VM 01001
VM
10011 10011 10011 10011 10011
Capa fisica
CarrIoTs [ 98] es un middleware orientada al servicio basado en la nube para la IO,

especialmente para las comunicaciones M2M, y se centra en: el desarrollo de Infraestructura IO
aplicaciones coste M2M eficaz, escalabilidad y facilidad de uso. La principal ventaja de CarrIoTs
Fig. 7. Diseño de modelo general para un middleware basado en VM.
es que soporta la escalabilidad a nivel de red. Los usuarios pueden poner disparadores
en varias etapas del ciclo de procesamiento de datos para enviar datos a un sistema máquina virtual (VM) de diseño middleware orientado proporciona soporte de
externo. Me gusta Xively, CarrIoTs no normalizar los datos entrantes. Asimismo, no programación para un entorno de ejecución seguro para las aplicaciones de
garantiza la seguridad del almacenamiento, y ofrece soporte limitado para la usuario virtualizando la infraestructura. Las aplicaciones se dividen en pequeños
interoperabilidad [117]. Sin embargo, módulos separados, que se inyectan y distribuidos por toda la red. Cada nodo en
la red tiene un VM, que interpreta los módulos (como se muestra en la Fig. 7). Este
CarrIoTs y Xively se benefician de las comunidades en línea activos, y son populares entre enfoque aborda quirements re- arquitectónicos como abstracciones de
los desarrolladores y los nuevos adoptantes. programación de alto nivel, la autogestión y la adaptabilidad, mientras que el apoyo
Echelon [ 118] es una plataforma IIoT con un juego completo de fichas, pilas, transparencia en distribuidos infraestructuras IO heterogéneos [122], [123]. Las
módulos, interfaces y software de gestión de dispositivos en desarrollo y las máquinas virtuales se pueden dividir en dos categorías: (i) Middleware Nivel
comunidades P2P. A diferencia de las plataformas de la IO de consumo, se ocupa máquinas virtuales (VM se colocan entre el sistema operativo y aplicaciones) y
de los requisitos básicos para el IIoT, incluyendo el control autónomo, fiabilidad
industrial-fuerza,
cosas Diario
(Ii) Nivel sistema VMS (sustituto o sustituir todo el OS) [22], [122]. Middleware Nivel máquinas herramientas que necesitan ser adoptados crean una curva de aprendizaje para los usuarios y
virtuales añadir capacidades (por ejemplo, de concurrencia) a los sistemas operativos que desarrolladores [135].
subyace [124]. Nivel del sistema VM liberar recursos que de otra manera serían consumidos fi c máquinas virtuales de aplicación-Speci (ASVMs) [124] resuelven los problemas
por el sistema operativo. impuestos por las soluciones tradicionales de VM por limitar la generalidad de las máquinas
virtuales a los subconjuntos correspondientes al dominio de aplicación (s) [136]. Este tipo de
Esterae [ 125] es un middleware basado en VM para nodos sensores con máquina virtual minimiza la carga mediante la reducción del tamaño del código interpretado
recursos limitados. Estera mi se ha prestado aten- adicional y mediante el uso de un compilador y en-el-fi a código nativo. En el lado del hardware, la
ción de los investigadores y desarrolladores, ya que aborda las limitaciones en sobrecarga interpretación se reduce al mínimo el uso de CPU especí bytecode fi c.
proyectos anteriores (por ejemplo, Escila [ 126]), que se han centrado sólo en la
verificación de código de bytes y en-el-mosca compilación, e introduce un código del
intérprete de bytes que se ejecuta en TinyOS. Estera Esterami se ha extendido a un marco para la construcción de ASVMs. La nueva
mi maneja con eficacia los recursos manage- dirección código de direcciones de versión re- quirements y mejora la ejecución de
ment para la red de sensor (por ejemplo, ancho de banda o la energía) y proporciona soporte código y la propagación de código mediante la reducción del tamaño del código
para la adaptabilidad [35]. Otro de los objetivos clave de la interpretado [137]. Además, se añadió un componente del sistema de seguridad para
Esterami es la gestión de código, logrado al permitir cambios a las aplicaciones de máquinas evitar la propagación de programas maliciosos a través de la red [122].
virtuales. Estera mi 'S modelo de ejecución hereda de la
TinyOS modelo basado en eventos sincrónica. De acuerdo a Estera mi 's DVM [ 138] y Davim [ 139] se basan en los conceptos introducidos por Estera
desarrolladores, que simpli fi ca el desarrollo a nivel de aplicación por lo que es mi. Tanto adoptar un enfoque similar para DY-
menos propenso a errores que tratar con el concurso completo asíncrono noti fi namically actualizar sensor de máquinas virtuales. Me gusta * VM, DVM no ofrece soporte
cación. Sin embargo, esto hace Estera mi para la adaptabilidad. Comparado con DVM, Davim está diseñado como una plataforma
no es adecuado para aplicaciones WSN basados en eventos [127], que requieren un enfoque de de servicios adaptables ligero para redes de sensores [123]. También, Davim permite la
no bloqueo. Además, la propia máquina virtual no es compatible con la re-programación después ejecución simultánea de múltiples aplicaciones. Sin embargo, Davim está dirigido a
de la implementación [128]. Además, dispositivos ricos en recursos. Además, re-programación introduce una sobrecarga
Esterami no se puede ejecutar varias aplicaciones al mismo tiempo en un nodo [129]. adicional, ya que requiere cambios a todos los nodos de la red. Davim utiliza un
coordinador para realizar las tareas de gestión de código necesarias, y este componente
VM * [ 128] y melete [ 130] se basan en Estera mi y extender puede convertirse en un cuello de botella en el sistema.
sus capacidades de gestión de los códigos de activación de las actualizaciones de grano fino a ambas
las aplicaciones de máquinas virtuales y el software del sistema.
VM * agrega una capa de servicio, lo que mejora los recursos agement hombre- y facilita la SwissQM [ 140] es otro ASVM y simpli fi ca la programación WSN al aumentar el
implementación de la aplicación. Sin embargo, VM * nivel de abstracción de programación a través de un sistema de puerta de enlace que
no ofrece soporte para la adaptabilidad. melete mejora el soporte para aplicaciones acepta programas y consultas escritas en un lenguaje de alto nivel. El diseño principal
concurrentes. Además, melete añade un mecanismo de difusión código para preocupación de SwissQM es ofrecer un mejor soporte para la gestión de datos en
distribuir el código selectivamente y de forma reactiva [131]. Sin embargo, se comparación con soluciones de middleware anteriores. Las otras consideraciones di-
supone que la topología de red es un gráfico conectado, lo que significa que no seño incluyen el apoyo a la adaptabilidad, la gestión de recursos (proporcionando una,
puede manejar una topología de red dinámica. multi-usuario dinámico, el medio ambiente multi-programación a través de la ejecución
de consultas simultáneas) y el apoyo a la gestión de código (al ofrecer la posibilidad de
MagnetOS [ 132], chillido [ 133] y Sensorware [ 129] son otros ejemplos de las volver a programar dinámicamente SwissQM). Sin embargo, sólo un subconjunto de
soluciones tradicionales VM. MagnetOS es un sistema operativo distribuido para redes código de bytes de Java VM está disponible. Funcionalidades como arrays o múltiples
de sensores que abstrae toda la red como una sola, uni fi ed Java VM, que hace que las tipos de datos que faltan.
aplicaciones escritas para MagnetOS portátil. El objetivo principal de esta solución es
reducir el consumo de energía y aumentar la longevidad de la red. Similar a MagnetOS,
Squawk es una pequeña Java VM que soporta múltiples aplicaciones, ofrece punto-tipos TinyReef [ 123] y TinyVM [ 141] son otros ejemplos de ASVMs, que reducen costes
de conexión a punto, y utiliza código optimizado con el fin de reducir el consumo de de interpretación. TinyReef es un VM basado en registros para WSNs, que tiene un
memoria. Sensorware es otra solución que implementa un intérprete de guiones con el tamaño de código más pequeño y mayor velocidad de procesamiento en comparación
fin de proporcionar una forma de redes inalámbricas de sensores basados en con VM basado en la pila. Sin embargo, la unidad de procesamiento de datos utilizado
secuencias de comandos móviles programar. Sin embargo, MagnetOS, Graznido y Sensorware
por la máquina de pila interactúa sólo con los elementos superiores de la pila. Este fl ujo
no son adecuados para dispositivos comprimidos en recursos (es decir, tienen una base de trabajo mejora la velocidad de procesamiento de código y simpli fi ca el diseño del
de código grande y usan RMI, que es un mecanismo basado en Java, el peso pesado hardware significativamente [142]. TinyVM utiliza el código de máquina de comprimido,
[122] para la comunicación entre componentes). lo que evita la descompresión intensivo de la CPU y memoria- en motas. Sin embargo, TinyVM
no fue diseñado para un entorno de la IO. El trabajo realizado se centra principalmente
en el diseño y la evaluación de la compresión de código y la actuación de la intérprete.
Hay poca información disponible acerca de este proyecto, que es probable que hayan
Las características de recursos limitados de redes inalámbricas de sensores plantean una dado lugar a su baja popularidad entre los investigadores y desarrolladores.
limitación importante: las máquinas virtuales requieren significantes memoria y procesar los
recursos de energía, lo que hace factible ción virtualisa- sólo en dispositivos ricos en recursos
[22]. Código inter- pretación introduce un tiempo de ejecución fi cante sobrecarga significante en
comparación con código binario nativo [134]. Por otra parte, los nuevos lenguajes y Una obra fl ujo utilizado por ASVMs no es una solución viable para el apoyo a la
heterogeneidad de la infraestructura de la IO porque
cosas Diario
es el peso pesado, que no es compatible con una visión para pequeños y más baratos de mensajes supera estas limitaciones por los agentes de la migración a los nodos de
hardware [143]. Además, el comercio de la portabilidad para un rendimiento reduce la interés, usando enrutamiento aplicación controlado, en lugar de la comunicación de
flexibilidad y la posibilidad de re-asignación de tareas [22]. La investigación adicional para extremo a extremo entre nodos. La principal con- tribución de este middleware es la
hacer frente a los problemas de peso pesado está en curso, con Folliot et al. [144] flexibilidad alta en presencia de red dinámica con fi guraciones. Sin embargo, Los
proponiendo para virtualizar la máquina virtual [137]. mensajes inteligentes
no soporta múltiples aplicaciones. Además, se considera sólo los nodos con
recursos limitados, y no proporciona soporte para los cálculos más complejos
posibles en los dispositivos más ricos en recursos.
Middlewares basados en agentes D.
Capa de aplicación ActorNet [ 151] y Agilla [ 28] son también ejemplos WSN middleware basados en agentes. ActorNet
usuarios
es una plataforma de agentes móviles para redes inalámbricas de sensores diseñados para
<Consulta>
capa de middleware
mejorar la migración de código y ofrecer soporte para la interoperabilidad. ActorNet introduce
Mediador servicios como memoria virtual, el cambio de contexto y multitarea para permitir que el ex
<Modularizar>
ecution de aplicaciones de agentes móviles complejas, altamente dinámicos en entornos con
<Inyectar>
Capa fisica recursos limitados severamente. Un inconveniente de
Agente Agente Agente
ActorNet viene del mecanismo de descubrimiento de servicio utilizado, que es un protocolo

de difusión que presenta una sobrecarga adicional en la red. Agilla reduce su tamaño de
Agente Agente código y ofrece apoyo para la auto-adaptabilidad dentro de la WSN mediante el despliegue
<Migrar>
de múltiples agentes móviles autónomas en cada nodo cuando se desencadenan eventos
Infraestructura IO específicos. Cada agente utiliza una estructura de espacio de tuplas para asegurar la
Fig. 8. modelo de diseño general para un middleware basado en agentes. consistencia y escalabilidad en un entorno dinámico y para permitir el descubrimiento de
recursos. Sin embargo, Agilla no soporta un espacio de tuplas federados debido a las
En el enfoque basado en el agente para middleware, las aplicaciones se dividen limitaciones de energía y ancho de banda. Me gusta Los mensajes inteligentes, Agilla sólo
en programas modulares para facilitar la inyección y la distribución a través de la considera los nodos con recursos limitados, y no proporciona soporte para los cálculos
red usando los agentes móviles. Mientras que la migración de un nodo a otro, más complejos posibles en los dispositivos más ricos en recursos. Además, programación
agentes tengan (como se muestra en la Fig. 8) su estado de ejecución. Esto facilita y gestión de código plantean un desafío debido al bajo nivel de abstracción del lenguaje.
el diseño de sistemas descentralizados capaces de tolerar fallos parciales [145]. La Por otra parte, los agentes móviles son susceptibles a la pérdida de mensajes, lo que
investigación anterior en esta área ha presentado una serie de ventajas para el uso interfiere con las tareas de migración de código.
de agentes móviles en sistemas distribuidos genéricos [146], [147]. En el contexto
de los requisitos de middleware IO, estos son: la gestión de recursos (reducción de
carga de la red y la reducción de la latencia de red), la gestión de código (asíncrono
y autónomo ejecución y protocolo de encapsulación), la disponibilidad y la fiabilidad Ubiware [ 152] se dirige directamente a los requisitos de la IO y dominios, y desde
(robustez y tolerancia a fallos), la capacidad de adaptación y la heterogeneidad su creación se ha convertido en popular en la comunidad de búsqueda y desarrollo re.
[148]. Además, un agente puede participar en diálogos con otros agentes software Este middleware apoya la creación de sistemas industriales autónomas, complejas,
para reunir de forma proactiva de datos y actualizar sólo partes de la aplicación. flexibles y extensibles. Los principios fundamentales de Ubiware son para apo- puerto
Además, los enfoques basados en agentes consideran que los dispositivos con automático descubrimiento de recursos, el seguimiento, la composición, la invocación
recursos limitados [134]. y ejecución de aplicaciones diferentes. UN Ubiware
agente se distribuye en tres capas: un motor de comportamiento implementado en Java, un

medio-capa declarativa (modelos de comportamiento correspondientes a los roles de
impala [ 149] es una solución middleware para WSNs que permite modularidad agente), y una tercera capa, que contiene los recursos compartidos y reutilizables
aplicación, la adaptabilidad, y reparabilidad en WSNs. Esta solución middleware era interpretan como componentes de Java (sensores, actuadores, máquinas inteligentes y los
parte del proyecto Ze- Branet, un sistema de red de sensores móvil para la mejora dispositivos, los dispositivos RFID, servicios web, etc.). Ubiware agrega las políticas de
de la tecnología de seguimiento a través de los nodos de seguimiento deficiente-ef seguridad para soportar los requisitos de seguridad. La interoperabilidad se consigue
de energía y técnicas de comunicación P2P. impala adopta la programación por aire mediante la adaptación semántica y mediante la asignación de un agente proactivo para
para la gestión de código y describe una arquitectura de software más adecuado cada uno de los recursos. Esto es apoyado por el uso de metadatos y ontologías. Sin
para mejorar la e fi ciencia de los recursos de los nodos de recursos limitados. La embargo, el apoyo a la interoperabilidad es limitado. Por ejemplo, no cubre la
gestión de recursos, dad, la apertura, y los requisitos de escalabilidad movili- están interoperabilidad entre diferentes protocolos de descubrimiento de recursos.
soportados por la conmutación entre diferentes protocolos y modos de operación
dependiendo de las aplicaciones y condiciones de la red. Sin embargo, impala no
soporta datos de pre-procesamiento, que es un componente importante de la UbiROAD [ 153] es un middleware semántica para entornos viales inteligentes
gestión de datos. sensibles al contexto. Se trata de la interoperabilidad entre en el coche y dispositivos
heterogéneos borde de la carretera. La interoperabilidad semántica se logra por dos
capas: de interoperabilidad a nivel de datos y funcional de interoperabilidad a nivel de
Los mensajes inteligentes [ 150] propone una arquitectura de red autónoma protocolo y coordi- nación. UbiROAD es una plataforma especializada en los entornos
para sistemas integrados a gran escala, que se conocen como de recursos inteligentes trá fi co, pero también puede servir como un protocolo inteligente BE-
limitados, heterogénea, volátil. Inteligente
cosas Diario
interpolar la capa de dispositivos inteligentes de carreteras y futuras arquitecturas Fig. 9) en una puerta de enlace. Este enfoque se adapta a los dispositivos móviles en una infraestructura
orientadas a servicios. Es heterogéneos con respecto a los componentes, estándares, de la IO, ya que pueden compartir de forma transitoria los datos dentro de las limitaciones de
formatos y protocolos de datos. Es auto-adaptable por agentes ploying distribuido de- y conectividad de puerta de enlace.
asegura contexto-conciencia, y la composición gurable adaptativa / recon fi. Estos

Capa de aplicación
usuarios
requisitos se logran mediante la personalización, personalización, comportamiento
<Consulta>
dinámico y la autonomía de los servicios. gestión de la confianza autónoma se logra a
capa de middleware
través de la anotación semántica. UbiROAD garantiza un alto nivel de seguridad.
de capa Capa
<Espacio de tuplas federados> <Id, 1223> <O2, 9, 2> <gps, 9, 2> <en, 0>
AFME [ 154], MAPAS [ 155], MASPOT [ 147] y <MVN, 1>
TinyMAPS [ 156] son soluciones basadas en Java que permiten la programación

Nodo de servicios
orientado a agentes de aplicaciones WSN. AFME
es una solución de middleware diseñado para sistemas inalámbricos generalizados para <Gps, 9, 2>
<Id, 1223> <MVN, 1> <O2, 9, 2> <En, 0>
<Espacio de tuplas> mi
hacer frente a los problemas de rendimiento y gestión de los códigos asociados a los
agentes ejecutar sólo en dispositivos móviles. MAPAS se basa en una arquitectura de
agentes de peso ligero y ofrece un conjunto de servicios para apoyar la gestión del Capa fisica
agente.
MASPOT se extiende la generalidad de MAPAS y mejora sus capacidades de Infraestructura IO
migración de código. Sin embargo, el mecanismo de descubrimiento de servicios utiliza Fig. 9. modelo de diseño general para un middleware tupla-espacio.
en MASPOT emplea un protocolo de difusión, que introduce una sobrecarga adicional

en la red. TinyMAPS Las aplicaciones se comunican por escrito tuplas en un espacio de tuplas federados,
puertos MAPAS en dispositivos mucho más con recursos limitados que los utilizados y mediante la lectura a través de la especificación de la estructura de los datos que están
por Maps. TinyMAPS es un esfuerzo continuo para optimizar los mecanismos de interesados.
migración de comunicación y de código. Sin embargo, TinyMAPS no tiene en cuenta LIMA [ 160], TinyLIME [ 161] y TeenyLIME [ 162] son soluciones de middleware
la movilidad, que es una característica importante de una infraestructura de la IO. tupla-espacio, cada uno adaptado para un entorno específico, que van desde las redes
ad-hoc móviles para redes de sensores. LIMA es un middleware para MANET
Las soluciones de middleware basados en agentes presentados (es decir, desarrollados para hacer frente a las limitaciones de energía dispositivos móviles. LIMA toma
impala, Los mensajes inteligentes, Agilla, AFME, ActorNet, MAPS, MASPOT, TinyMAPS) no prestado y adapta el modelo de coordinación de Linda [163], y rompe el espacio de tuplas
se refieren a la heterogeneidad de una infraestructura de la IO. Estas soluciones han sido centralizado en la puerta de entrada en múltiples espacios de tuplas, cada uno unido de
diseñadas sólo para redes inalámbricas de sensores o dispositivos móviles. Todos han forma permanente a un componente móvil. El acceso al espacio de tuplas se lleva a cabo
sido probados en una ci fi co plataforma de hardware / software espe- (por ejemplo, Mica2, utilizando un conjunto extendido de operaciones espaciales tupla, incluyendo varios
MicaZ, TelosB TinyOS ejecutan, Hewlett-Packard / Compaq iPAQ Pocket PC con Linux, constructos diseñados para facilitar las respuestas en tiempo real flexible y FL a cambios. LIMA
manchas de sol). Por otra parte, estas soluciones de middleware no se abordan apoya buenas abstracciones de programación para la explotación de un contexto que
cuestiones como las garantías de tiempo real. La seguridad y la privacidad en general no cambia dinámicamente. Sin embargo, su sensibilidad al contexto es limitado (por
se consideran. En general, estos proyectos son muy populares, aunque los primeros ejemplo, no es consciente de la con fi guración del sistema). Ofrece soporte limitado para
usuarios están pidiendo soluciones diseñadas para un entorno de la IO. la gestión de recursos, gestión de eventos, y la escalabilidad y no proporciona ningún
mecanismo de seguridad o privacidad. Otra limitación es que una aplicación puede
acceder sólo a la tupla-espacio federados de los sensores en la proximidad. TinyLIME se
La visión de la IO es apoyar la conexión de varios objetos del mundo físico a una basa en LIMA mediante la adición de componentes especializados para redes de
infraestructura común, y DE- la firma de un sistema que permita esto, es un proceso sensores. Sin embargo,
complejo. El uso de sistemas basados en agentes puede reducir la complejidad del
diseño de tales sistemas por de fi nir algunas políticas de más alto nivel en lugar de
la administración directa. Sin embargo, la característica autónoma de agentes puede
conducir a la imprevisibilidad en el sistema en tiempo de ejecución. Los patrones y TinyLIME ofrece un apoyo limitado para la adaptación y no tiene ningún mecanismo de
los efectos de sus interacciones son inciertos [157]. Por otra parte, los agentes seguridad construido en. TeenyLIME es una extensión de LIMA y TinyLIME. Se
móviles son susceptibles a la pérdida de mensajes, especialmente en entornos con proporciona un modelo de programación más general abstracción mediante el
recursos limitados [158]. Esto impone muchas limitaciones para una solución despliegue de operaciones proactivas y reactivas. Limita el número de aplicación- nivel
middleware de la IO, incluyendo la capacidad de realizar tareas de gestión de utiliza mediante el control de vecindad de un salto de un dispositivo. Esto se hace para
código. reducir el consumo de energía y mejorar los datos sensibles al contexto de recolección.
Un inconveniente de CAL, TinyLIME y
TeenyLIME es que están diseñados para entornos en los que los clientes normalmente
sólo necesitan consultar los datos de los sensores locales. Los datos detectada se recoge
E. Tupla-Espacio Middlewares
sólo si los dispositivos están dentro de los límites de la conectividad de una puerta de
En middlewares tupla en el espacio, cada miembro de la infraestructura tiene una enlace. En un entorno de la IO, este enfoque no es su fi ciente para soportar servicios
estructura de espacio de tuplas local. Un espacio tupla es un repositorio de datos [159] que distribuidos o aplicaciones.
se puede acceder al mismo tiempo. Todos los espacios de tuplas forman un espacio de
tuplas federados (mostrado en TS-Mid [ 164] es otro middleware tupla-espacio para WSNs,
cosas Diario
que despliega un estilo de comunicación asíncrona y desacoplado tanto en el el desarrollo de un enfoque de sistemas de base de datos distribuida a interoperar.
tiempo y el espacio. Como en CAL, TinyLIME y
TeenyLIME, TS-Mid sigue el mismo enfoque de la recogida de datos en una puerta de SINA [ 166] maneja eventos y también puede hacer frente a la movilidad de la
enlace. Sin embargo, TS-Mid mejora la jerarquía de estructura de nodos mediante la consulta (sumidero) nodo [167]. Permite complicaciones sensores AP para realizar
creación de regiones lógicas (o grupos) para los nodos en la proximidad. Las tareas que consultas y tareas de mando, recoger las respuestas y resultados, y monitorear los
antes se realizaban en la puerta de entrada se realizan ahora en un nodo líder elegido cambios dentro de las redes. SINA
en el grupo. Cada nodo líder es responsable de la agregación de datos y transmisión al apoya la gestión de recursos a pesar de la vigilancia de los recursos. Es compatible con la
nodo destino. El nodo receptor, se consulta por los clientes. Este modelo es agregación de preprocesamiento de datos. SINA módulos, que se ejecuta en cada nodo
heterogénea con respecto a los lenguajes de programación, redes y sistemas sensor, proporcionan organización adaptativa de la información del sensor, y facilitan la
operativos. Es compatible con la gestión de datos a través de la agregación y de consulta, la supervisión de eventos, y capacidades de multitarea. Los nodos de sensores
almacenamiento de datos. Sin embargo, no es compatible con disco en tiempo real, la están agrupados de forma autónoma, que apoya e fi-ef energía y operaciones escalables.
seguridad o la privacidad. Por otra parte, el nodo líder se convierte en un cuello de Aun- que los requisitos de adaptación y autónomos, interoperabilidad y sensibilización del
botella en el grupo y no proporciona uniformidad del uso de energía. contexto no se resuelven en SINA. SINA no está asegurada o privada.
A3-TAG [ 165] sigue la estructura jerárquica nodo utilizado en TS-Mid, con el fin de PUMA [ 168], es otro middleware orientado a la base de datos. Es una extensión
hacer frente a la auto-adaptación y diseminación ción de nuevas tareas con fi guración para el sistema de base de datos relacional de objetos Cornell Predator. En PUMA, hay
a través de la comunicación de grupo. Sin embargo, A3-TAG presenta los mismos dos tipos de datos: los datos almacenados y los datos del sensor. funciones de
inconvenientes: el nodo líder se convierta en un cuello de botella en el grupo y no procesamiento de señal en cada nodo sensor generan datos de sensor, que es comu-
proporciona uniformidad de uso de energía. Por otra parte, debido al mecanismo de nicated o almacenado como relaciones en un sistema de base de datos. funciones de
comu- nicación emplea, A3-TAG direcciones en recursos dispositivos ricos. procesamiento de señal se modelan mediante el uso de tipos de datos abstractos.
consultas de larga duración se formulan utilizando un SQL-como el lenguaje. la
agregación de datos se refiere a la entrega de datos desde nodos de sensores
Las soluciones de tupla-espacios de middleware presentados aquí (es decir, distribuidos fuente a un nodo central para putation com-. PUMA proporciona acceso
LIMA, TinyLIME, TeenyLIME, TS-Mid, A3-TAG) han sido diseñados sólo para redes flexible y escalable fl a grandes colecciones de sensores. Desde el punto de requisitos
inalámbricas de sensores o dispositivos móviles. middleware tupla en el espacio se funcionales y no funcionales, que no soporta la gestión de eventos o código.
propusieron originalmente para tratar el problema de desconexiones frecuentes, y

para mejorar la comunicación asíncrona. Aunque tienen una arquitectura flexible
que permite middleware para ser usado en diferentes entornos, el oído debido a su
diseño cross-layer puede ser prohibitivo en la IO. Su modelo de programación por IrisNet [ 169] es una plataforma de base de datos orientada-, que despliega servicios
lo general no es gramable repro- y proporcionan un apoyo limitado a la capacidad heterogéneos en WSNs. IrisNet apoya el control de una red de sensores global, de área
de adaptación o escalabilidad. No obstante, son populares entre los investigadores. amplia mediante la realización de Internet- como consultas sobre esta infraestructura. Cada
consulta opera sobre los datos recogidos de la red de sensores mundial, y es compatible
con consultas simples y más complejos que involucran a los operadores aritméticos y de
bases de datos. Se distribuye y ligero. Se utiliza un enfoque centrado en la base de datos
para publicar los datos generados. La arquitectura de IrisNet es de dos niveles. sensores
F. Middlewares de base de datos orientada heterogéneos implementan una interfaz compartida común y son llamados agentes de
detección (SA). Los datos producidos por los sensores se almacenan en una base de datos
Capa de aplicación
usuarios
distribuida que se implementa en agentes organizadores (OA). Diferentes servicios de
<Consulta> detección funcionar simultáneamente en la arquitectura. A medida que los nodos de
capa de middleware
procesamiento siempre son alimentados,
consulta
del motor
IrisNet no está optimizado para el uso de energía. Muchos de los retos arquitectónicos no se
resuelven, tales como: la interoperabilidad, el conocimiento del contexto, el comportamiento

Capa fisica
autónomo, la capacidad de adaptación.
sensación [ 170] es middleware orientado a la base de datos-desarrollado para

consulta consulta consulta consulta consulta
del motor del motor del motor del motor del motor aplicaciones de WSN, y diseñado para proporcionar soporte para diferentes sensores, las
infraestructuras de red y middleware tec- gías. Este nivel de heterogeneidad se apoya a
través de una capa de abstracción. Sensación proporciona un alto nivel y modelo de
Infraestructura IO
programación intuitiva para aplicaciones sensibles al contexto generalizados. Es compatible
Fig. 10. Diseño modelo general para un middleware orientado a bases de datos. con la energía-conciencia y capacidad de ampliación. A través de sus peticiones síncrono
(consultas), que recupera los datos solicitados, y devuelve las respuestas correspondientes
En middleware orientado base de datos, una red de sensores es visto como un en tiempo real. Sensación está diseñado para el seguimiento periódico de los valores del
sistema de base de datos relacional virtual (como se muestra en la Fig. 10). Una sensor. Contexto- aplicaciones sensibles al uso de la programación orientada a eventos para
aplicación puede consultar la base de datos utilizando un lenguaje de consulta desencadenar acciones después de los eventos que se han generado a partir de la WSN.
SQL-como, que permite la formulación de consultas complejas [22]. La investigación en
esta área se ha centrado en
cosas Diario
IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero dieciséis
TinyDB [ 69], [171] es un sistema dleware mediados de procesamiento de consulta servicios en tiempo real.
distribuida basado en TinyOS. TinyDB proporciona Power-e fi ciencia en los sistemas de Una aproximación a la base de datos de middleware ve toda la obra de red según
procesamiento de consultas de la red que recopilan datos de los nodos de sensores un sistema de base de datos virtual. las interfaces fáciles de usar SUP- consultas de
individuales. al consumo reducido de energía se activa a través de la reducción del número los usuarios del puerto para redes de sensores para extraer datos de interés. Sin
de mensajes que deben ser intercambiados. Mientras TinyDB proporciona apoyo abstracción embargo, sólo se devuelven resultados aproximados. La mayoría de las aplicaciones
de programación y un modelo de agregación de datos, que no proporciona mucha de la IO son en tiempo real, donde el tiempo y el espacio son importantes.
funcionalidad de servicios de middleware, lo que las aplicaciones deben manejar estas middleware de base de datos no son compatibles con puntualidad. consumo de
funciones sí mismos. Tiene buenas datos agement hombre-, minimizando comunicación caro energía se reduce mediante la recopilación de datos de los nodos individuales.
mediante la aplicación de operaciones de agregación y fi ltrado dentro de la red de sensores. Mientras middleware de base de datos pueden proporcionar un buen apoyo
Es compatible con el procesamiento basado en eventos y sus procesos se puede optimizar abstracción de programación y tener un buen apoyo a la gestión de datos, el resto de
para el uso de energía. los requisitos de middleware de la IO se renunció. Además, el enfoque middleware
base de datos utiliza un modelo centralizado, lo que hace di fi culto para manejar
redes de sensores dinámica a gran escala. Por otra parte, middleware de base de
GSN [ 172] es un proyecto popular entre los desarrolladores e investigadores, y se ha datos generalmente no son compatibles con las aplicaciones de tiempo real,
integrado en otros proyectos (por ejemplo, OpenIoT). Utiliza sensores virtuales para
controlar prioridad de procesamiento, la gestión de los recursos y los datos
almacenados. El uso de especificaciones declarativas, sensores virtuales pueden ser
desplegados y reconstrucción fi gurado en GSN contenedores en tiempo de ejecución. GSN
crea entornos de procesamiento altamente dinámicos y permite que el sistema reaccione
Middlewares G. Application-especí fi co
rápidamente a las cambiantes necesidades de procesamiento y las condiciones
Capa de aplicación Aplicación / dominio
ambientales. gestión dinámica de recursos lleva a cabo tres tareas principales: Aplicación
intercambio de recursos, gestión de fallos y control de recursos explícita. Como el <QoS> <Consulta>
número de clientes aumenta, el tiempo promedio para cada cliente disminuye, lo que es capa de middleware
apto para la escalabilidad [26]. GSN proporciona un acceso simple y uniforme a la gran Capa de red
cantidad de tecnologías heterogéneas disponibles y es fácil de implementar. GSN es

configuración de la red <Ajuste>
adaptativo, pero no es autónomo y no ofrece soporte para la interoperabilidad, la
<Seleccionar> <Implementar>
seguridad o la privacidad.
Capa fisica
Infraestructura IO
KSpot + [ 173] es un middleware distribuido centrada en los datos archi- tecture para Fig. 11. Modelo de diseño general para un middleware aplicación específica.
WSN. Es capacidades de red y es compatible con la semántica de consulta avanzadas
para la agregación de datos. KSpot + es un marco de middleware de código abierto que Una aplicación específica (es decir, la aplicación de guiado) enfoque de middleware
se puede utilizar en los dominios de aplicación OU numer- incluyendo control centra en el apoyo de gestión de recursos (es decir, soporte de QoS) para una aplicación
medioambiental, control estructural, monitoreo urbano y vigilancia de la salud. en particular o dominio de aplicación mediante la implementación de una arquitectura que
fi ne-sintoniza la red o infraestructura (como se muestra en la Fig. 11) en base a los
KSpot + proporciona un descubrimiento de recursos mecanismo descentralizado. Varios requisitos de la aplicación o dominio de aplicación.
desafíos se han tenido en cuenta, tales como la modularidad, e fi-ef energía,
disponibilidad, distribución y comportamiento autónomo, escalabilidad y tolerancia a AutoSec [ 175] y Adaptativo Middleware [ 176] son algunos ejemplos de este
fallos. Se prestó especial atención a la escalabilidad, para asegurar que el rendimiento enfoque. AutoSec utiliza un corredor de servicio dinámico para la gestión de
de KSpot + mantiene los estándares de calidad de servicio aceptables recursos en un sistema distribuido. Esto se hace mediante la combinación
independientemente de aumento de tamaño de la red. No es compatible con la adecuada de políticas de información lection y aprovisionamiento de recursos
privacidad, o código o gestión de eventos. No es en tiempo real, sensible al contexto, COL- en base a las condiciones actuales del sistema y los requisitos de la
dinámico o adaptativo. aplicación. AutoSec es aplicación específica en el sentido de que admite sólo una
aplicación a la vez. adaptativo Middleware explora la compensación entre el gasto
HyCache [ 174] es un middleware de caché en el nivel de aplicación para fi sistemas de recursos y calidad durante la recogida de la información. El objetivo principal es
LE distribuidas basadas en el diseño orientado a la base de datos. Distribuido sistemas fi reducir las transmisiones entre nodos de sensores sin comprometer el resultado
le están desplegados en la parte superior de HyCache en todos los nodos de datos. HyCache global.
'S estrategia es alcanzar sencillo alta, y escalable, escribiendo flujo. Esto se logra si el
cliente escribe datos sólo para su almacenamiento local, que proporciona una gestión de middleware de adaptación es autónoma y ofrece apoyo para la adaptación, aunque ha
almacenamiento de datos. HyCache soporta la agregación de preprocesamiento de datos sido diseñado especialmente para aplicaciones sensibles al contexto de origen
y logra un fl óptima ow asociando todas las escribe con la E / S locales flujo. HyCache apoya SMART.
distribuida de recursos descubrimiento y gestión de recursos de supervisión. Proporciona Milán [ 177] es similar a Adaptativo Middleware, aunque
abstracciones de programación dinámica. Se utiliza dispositivos de almacenamiento Milán explora el concepto de adaptación proactiva con el fin de responder a las
heterogéneos para fi l sistemas distribuidos y trabaja completamente en el espacio de necesidades de aplicación. Milán permite a las aplicaciones para especificar sus
usuario. No se ocupa de los problemas de seguridad y privacidad, o con la gestión de requisitos de calidad de servicio y ajustar la con fi guración de la red en tiempo de
código. No proporciona ejecución. Los ajustes se hacen sobre la base de información obtenida de la
aplicación, el usuario, la red y el sistema en general. Ambos adaptativo Middleware
cosas Diario
y Milán requiere el conocimiento acerca de los sensores exactas. En entornos encuesta indica que ha habido avances significativos en hacer frente a muchos
informáticos dinámicos y penetrantes, el número y los tipos de sensores a disposición de desafíos para el middleware en un entorno IO, con los siguientes desafíos
las aplicaciones pueden variar. No es práctico para incluir el conocimiento acerca de abiertos restante.
todos los nodos de sensores disponibles que una aplicación puede utilizar
potencialmente. Además,
A. Problemas relacionados con los requisitos funcionales de Recursos
Milán no tiene en cuenta el coste de adquisición de información. Además, no se
Descubrimiento: La naturaleza dinámica y ultra-gran escala de la
ocupa de la movilidad. Milán fue diseñado para el asesoramiento y supervisión
infraestructura de la IO invalida registros de recursos centralizada y enfoques
medica.
de descubrimiento. Sin embargo, decidir tween BE- puramente distribuida y
TinyCubus [ 178] es un marco de cross-layer implementado en la parte superior de TinyOS.
soluciones híbridas es complicado. Una desventaja es necesaria entre la
Propone un marco flexible genérico, extensible y fl que puede gestionar nuevos requisitos de
distribución de registro y el número de registros. Menos registros proporcionan
la aplicación. Los requisitos de la aplicación especí fi c son satis fi ed mediante la
descubrimiento consistente y rápida de los recursos en circunstancias
personalización de componentes genéricos. Sin embargo, el diseño de la capa transversal
normales, pero no se escalan bien cuando hay un gran número de consultas
produce una sobrecarga adicional, que es perjudicial para el uso de energía. Además, esta
de descubrimiento de servicios en aplicaciones de IO. recurso probabilístico
solución de software no es escalable. TinyCubus fue diseñado para el seguimiento de los
puentes por los defectos estructurales y para los sistemas de asistencia al conductor.
(por ejemplo, servicio) registros y descubrimiento [45], [97], [180] puede ser
escalable, aunque no puede funcionar bien en aplicaciones (por ejemplo,
aplicaciones de misión crítica) que necesidad garantizada descubrimiento de
MidFusion [ 179] se basa en los conceptos presentados en Milán recursos con alta precisión.
y Adaptativo Middleware. El propósito de esta solución de middleware es evitar el

mantenimiento de los conocimientos acerca de los sensores exactas disponibles
mediante el uso de la teoría bayesiana y Decisión para proporcionar una abstracción
portátil de la infraestructura para la aplicación. Comparado con Milán y Adaptativo Administracion de recursos: de recursos frecuentes conflictos ocurrir en aplicaciones
Middleware, MidFusion utiliza el coste de adquisición de información como criterio de de IO que comparten recursos (por ejemplo, actuadores). Se requerirá la resolución de
selección de la mejor conjunto de sensores o agentes de sensores. conflictos para resolver los conflictos en la asignación de recursos entre múltiples servicios
simultáneos o aplicaciones. Esto no se considera en la mayoría de las soluciones de
MidFusion fue diseñado para aplicaciones que realizan la fusión infor- mación (por middleware existentes, excepto ubiSOAP [ 94] (Tabla I y IV). Hay claramente un margen
ejemplo, un sistema de detección de intrusos). significativo para el trabajo futuro en esta área. enfoque de cooperación basado en
Soluciones de aplicación especí fi c no abordan la heterogeneidad de una agentes para la resolución de conflictos [181] podría ser un buen punto de partida para la
infraestructura de la IO, ya que es ajustado acoplamiento entre las aplicaciones y la gestión autónoma con fl icto.
capa de middleware. Además, el enfoque aplicación específica crea soluciones

solamente especializados medianos Ware [30] en lugar de soluciones de uso general. Gestión de datos: Una gran cantidad de datos en bruto recogió continuamente
Esto no satisface los requisitos de middleware de la IO desde una solución IO debe necesita ser convertida en conocimiento útil, lo que implica los datos agregados y se filtró.
soportar múltiples aplicaciones. Además, todas las soluciones de middleware fi La mayoría de los encuestados middleware ofrecen soporte para la agregación de datos,
aplicación de C-especí presentados utilizan un mecanismo de descubrimiento de pero no tienen en cuenta los datos de fi ltrado. fi ltrado de datos es probable que se
recursos centralizado, que no es un enfoque viable para una solución de la IO encuentran en los enfoques de aplicación especí fi cos ya que el middleware está
distribuida tolerante a fallos. Por otra parte, estos inconvenientes hacen que este tipo diseñado para una aplicación en particular o grupo de aplicaciones. Por otra parte, hay un
de soluciones de middleware poco atractivos para los adoptadores de tecnología. enfoque ofrece compresión de datos. Esto sigue siendo un problema importante para la
investigación, ya que muchos dispositivos IO-son recursos limitados y la transmisión de
datos es más caros que los siva procesamiento local [87].
Tablas I, II, y III se resumen las capacidades funcionales, no funcionales y

arquitectónicas de los dlewares mediados encuestados. En poblar las tablas, se
utilizan algunas leyendas comunes (por ejemplo, el apoyo (S), no compatible (NS), Gestión de eventos: Un gran número de eventos se generan proactiva y reactiva en la
no hay información (NI) - si no hay información disponible acerca de la exigencia), IO. Debido a esto, se espera que los componentes de middleware pueden convertirse en
junto con leyendas fi requisito específico (por ejemplo, para el peso ligero cuellos de botella en el sistema. La mayor parte del middleware encuestados no puede
requisitos: memoria necesaria (M) y e fi ciencia energética (e)). manejar o no han sido probados en contra de este requisito. Además, los eventos pueden
ser primitivo (es decir, simple) o compleja. La mayoría de middleware estáticamente
pre-de fi ne cómo se maneja un evento. Más trabajo debe tener en cuenta
acontecimientos complejos y cómo controlar eventos desconocidos. Por otra parte, el
IV. O BOLÍGRAFO R NVESTIGACIONES do Y ESAFÍOS F UTURO
trabajo presentado no tiene en cuenta la diferencia entre discreto (por ejemplo, se abre
re IRECTIONS
una puerta, encender una luz) y citas continuas (por ejemplo, conducir un coche).
Aunque los middleware presentados en este documento abordan muchas cuestiones y
requisitos en la IO, todavía hay algunos retos de búsqueda reabrir. En particular, se necesita
investigación en el área de descubrimiento dinámico de recursos heterogéneos y com- Gestión de código: Reprogramación es uno de los principales desafíos no sólo en la IO,
posición, escalabilidad, fiabilidad, interoperabilidad, sensibilidad al contexto, la seguridad y la sino también en el desarrollo de software. Actualizaciones o cambios en la lógica de
privacidad con la IO middleware. Es importante destacar que la mayoría de middleware negocio deben ser apoyadas por cualquiera de los componentes de la IO. basada en
actuales abordan redes inalámbricas de sensores, mientras que otras perspectivas (por agentes, middleware basados en máquinas y aplicación especí fi cos virtuales ofrecen
ejemplo, M2M, RFID y SCADA) rara vez se abordan. Esta soporte para la gestión de código. Sin embargo, su apoyo para la asignación de código y
cosas Diario
TABLA I
S RESUMEN DE LA IOT Middlewares: REQUISITOS FUNCIONALES APOYADAS
Requerimientos funcionales
Detección de recursos Administracion de recursos Gestión de datos Gestión de eventos Gestión de código
Evento-Based Approach
Hermes [79] CD-DD RM DPF LS NI
EMMA [27] CD-DED, CD-SD RM DS SS California
GREEN [81] DD-ND RM DS, DPF LS California
RUNES [82] CD-DED, CD-SD RM, RCA DPA SS California
PRISMA [29] CD-DD RM DS, DPA SS California
SensorBus [87] CD-DED RM NS SS NI

Mires [88] CD-DED, CD-SD RM DPA SS California
Orientada a Servicios enfoque

Hydra [101] DD-DED, DD-SD RA, RM, RCP DS SS NS
SenseWrap [103] DD-DED, DD-SD NI NI SS NS
MUSIC [70] DD-SD RA, RM, RCA NS NS NS
TinySOA [105] DD-DED, DD-SD REAL ACADEMIA DE BELLAS ARTES DS NS NS
SOCRADES [93] DD-DED, DD-SD RA, RM, RCP NI LS NS
SENSEI [109] DD-DED RA, RM, RCA DS, DPA NI NS
ubiSOAP [94] DD-DED, DD-ND RA, RM, RCA, RCL NI SS NS
Servilla [95] DD-SD RA, RM, RCA DPC SS CA, CM
Kasom [110] DD-SD RA, RM, RCA NS LS NS
CHOReOS [112] DD-DED, DD-SD RA, RM, RCA DPA SS NS
Mosden [46] DD-DED, DD-SD RA, RM, RCP DS, DPA NI NS
Xively [99] DD-DED, DD-SD RA, RM DS, DPA NI NI
Carriot [98] DD-DED, DD-SD RA, RM DS, DPA NI NI
Echelon [118] DD-DED, DD-SD RA, RM DS, DPA NI NI
Enfoque Virtual Machine
Esterae [125] DD-DED RA, RM DS, DPA LS California
VM * [128] DD-DED RM DS, DPA LS California
Melete [130] DD-DED RA, RM, RCA DS, DPA LS CA, CM

MagnetOS [132] DD-DED RA, RM, RCA DS, DPA LS California
Squawk [133] DD-DED RA, RM DS, DPA NI California
Sensorware [129] DD-DED RA, RM, RCA DS, DPA LS CA, CM

Extended Mat' e [137] DD-DED RA, RM DS, DPA LS California
DVM [138] DD-DED RA, RM, RCL DS, DPA SS California
Davim [139] CD-DD RA, RM DS, DPA SS California
SwissQM [140] DD-DED, DD-SD RA, RM, RCA DS, DPA, DPF LS California
TinyVM [141] NI NI DPA NI NI

TinyReef [123] NI NS DS, DPA SS California
Enfoque basado en agente

Impala [149] DD-DED RA, RM DPA LS CA, CM
Mensajes inteligentes [150] DD-ND RA, RM DPA SS CA, CM
ActorNet [151] DD-DED REAL ACADEMIA DE BELLAS ARTES DPA SS CA, CM
Agilla [28] DD-DED RA, RM, RCA DPA LS CA, CM
Ubiware [152] DD-DED, DD-SD RA, RM, RCA DPA LS CA, CM
UbiROAD [153] CD-SD RM DS LS CA, CM
AFME [154] CD-DD REAL ACADEMIA DE BELLAS ARTES DPA SS CM
MAPS [155] DD-DED RA, RM DPA LS CA, CM
MASPOT [147] DD-DED RA, RM, RCA DPA LS CA, CM
TinyMAPS [156] DD-DED RCA DPA, DPF LS CA, CM
Enfoque tupla-Espacio
CAL [160] CD-DED, CD-SD RM DS SS CM
TeenyLIME [162] CD-DED, CD-SD RM DS, DPA SS CM
TinyLIME [161] CD-DED, CD-SD RM DPA SS CM
TS-Mid [164] CD-DED, CD-SD RM DS, DPA SS NS
A3-TAG [165] CD-DED, CD-SD RM DS, DPA SS NS
Enfoque de la base de datos
SINA [166] DD-DED RM DS, DPA SS NS

PUMA [168] DD-ND RM DS, DPA LS NS
IrisNet [169] DD-SD RA, RM, RCL DS, DPA, DPF SS CA, CM
Sensation [170] CD-DED RM DS, DPA SS NS
TinyDB [69], [171] DD-DED RM DS, DPA, DPF SS NI
GSN [172] DD-Ded, DD-SD RA, RM DS, DPF LS California
KSpot + [173] DD-SD RM DS, DPA NS NS

HyCache [174] DD-DED RM DS, DPA NS NS
Enfoque Application-Speci fi c
AutoSec [175] CD-SD RA, RM, RCA, RCL DS, DPA, DPF LS CA, CM
Adaptativo Middleware [176] CD-SD RA, RM DS, DPA LS California
Milán [177] CD-SD RA, RM, RCA DS, DPA LS CA, CM

TinyCubus [178] CD-SD RA, RM DS, DPA LS California
MidFusion [179] CD-SD RA, RM, RCA DS, DPA, DPC, DPF LS California
Leyenda Descubrimiento centralizado (CD) Asignación de recursos (RA) El almacenamiento de datos (DS) Soportado Asignación de código
No soportado (NS) Descubrimiento distribuido (DD) Monitor de recursos (RM) Preprocesamiento de datos (DP) - Gran Escala (LS) (CALIFORNIA)
Sin información (NI) Detección de dispositivos (DED) Composición de recursos (RC) - Agregación (A) - Pequeña Escala (SS) Migración código
Descubrimiento de red (ND) - adaptable (A) - compresión (C) (CM)
Descubrimiento de Servicio (SD) - Prede definida (P) - filtrado (F)
Con fl icto de recursos (RCL)
cosas Diario
TABLA II
S RESUMEN DE LA IOT Middlewares: APOYADAS requisitos no funcionales
requerimientos no funcionales
escalabilidad Seguridad Disponibilidad Confiabilidad Tiempo real Intimidad Popularidad
Hermes [79] AL, NLIoTS NI S CR, DR HRT NI METRO
EMMA [27] NLWSNS NI S CR SRT NI METRO
GREEN [81] NLIoTS NI S NI SRT NI METRO
RUNES [82] NLWSNS NS NI NI HRT NS H

PRISMA [29] NLWSNS NI S CR SRT NI H
SensorBus [87] NLWSNS NI NI NI HRT NI L
Mires [88] AL, NLWSNS NI S CR SRT NI METRO

Hydra [101] AL, NLWSNS S NI NI SRT NS H
SenseWrap [103] AL, NLIoTS do NI NI SRT NS L
MUSIC [70] AL, NLWSNS NS S DR NI NS METRO
TinySOA [105] AL, NLWSNS NS NS NS HRT NS METRO
SOCRADES [93] AL, NLIoTS do NI NI SRT NS H

SENSEI [109] AL, NLWSNS do NI NI SRT S H
ubiSOAP [94] AL, NLWSNS NS S NS NI NS METRO
Servilla [95] AL, NLWSNS NS S NI NI NS L

Kasom [110] AL, NLWSNS do S CR HRT NI METRO
CHOReOS [111] AL, NLIoTS NI S NI NI NS H

Mosden [46] AL, NLWSNS NS S NS NI NS H
Xively [99] AL, NLIoTS do S NS SRT NS H
Carriot [98] AL, NLIoTS C, A S NI HRT NI H
Echelon [118] AL, NLIoTS C, A S NI HRT NI H
Esterae [125] AL, NLWSNS NI S CR SRT NI H
VM * [128] AL, NLWSNS NI S CR SRT NI L
Melete [130] AL, NLWSNS do NI CR SRT S L
MagnetOS [132] AL, NLWSNS NI S CR SRT NI L
Squawk [133] AL, NLWSNS NI NI CR, DR SRT NI METRO
Sensorware [129] NLWSNS NI NI NI SRT NI METRO
Extended Mat' e [137] NLWSNS NI S CR, DR SRT NI H

DVM [138] NLWSNS NI S DR SRT NI L
Davim [139] AL, NLWSNS NI S DR SRT NI L
SwissQM [140] AL, NLIoTS UN S CR, DR NRT NI L
TinyVM [141] NI NI NI NI NI NI L
TinyReef [123] NLWSNS NI NI CR SRT NI L
Impala [149] AL, NLWSNS IA NS DR SRT S H
Mensajes inteligentes [150] NLWSNS UN S NI SRT NS METRO
ActorNet [151] NLWSNS NI NI DR NRT NI L

Agilla [28] NLWSNS NS S DR SRT NS METRO
Ubiware [152] AL, NLIoTS C, A S NI SRT NS H

UbiROAD [153] AL, NLIoTS do S NS NRT S L
AFME [154] NLWSNS NI S CR, DR SRT NI L
MAPS [155] AL, NLWSNS NI NI CR SRT NI METRO
MASPOT [147] AL, NLWSNS NI S CR SRT NI METRO
TinyMAPS [156] AL, NLWSNS NI S CR, DR SRT NI METRO
CAL [160] NLWSNS NS NS NS SRT NI H
TeenyLIME [162] NLWSNS NS NS NS SRT NI H
TinyLIME [161] NLWSNS UN NS NS SRT S H
TS-Mid [164] NS NI S S NRT NI L
A3-TAG [165] NLWSNS NI S S SRT NI L
SINA [166] NLWSNS NS NS NS NRT NS METRO
PUMA [168] NLWSNS yo S NI SRT S L

IrisNet [169] NLWSNS do S NS SRT S L
Sensation [170] NLWSNS NS S NI NRT NS L
TinyDB [69], [171] NLWSNS NS NS NS NRT NS H
GSN [172] Alabama yo S NI SRT NS H
KSpot + [173] NLWSNS yo S NI NRT NS L
HyCache [174] Alabama NI NS DR NRT NI METRO
AutoSec [175] NLIoTS NI S CR, DR HRT NI METRO
Adaptativo Middleware [176] NLWSNS NI S CR, DR HRT S L

Milán [177] NLWSNS NI S CR HRT NI METRO
TinyCubus [178] NLWSNS NS S DR HRT NS L

MidFusion [179] NLWSNS NI S CR HRT NI L
Leyenda Nivel de Aplicación (AL) Confidencialidad (C) Apoyado (S) Comunicación duro en tiempo real Soportado Altamente
No soportado (NS) nivel de red (NL) Integridad (I) (CR) (HRT) (S) (H)
Sin información (NI) - Escala de la IO (IOT) Disponibilidad (D) Datos Suave en tiempo real moderadamente
- WSN Scale (WSNS) (DR) (SRT) (METRO)
No en tiempo real Menos
(NRT) (L)
cosas Diario
TABLA III
S RESUMEN DE LA IOT Middlewares: Requisitos arquitectónicos APOYADAS
requisitos arquitectónicos
Abstracción interoperable Consciente del contexto Autónomo Adaptado basada en los servicios Ligero Repartido
Hermes [79] S Nei, SeI norte Y DA Y METRO Y
EMMA [27] S Nei, SeI norte Y SA Y E, H Y
GREEN [81] S Nei Y norte DA Y METRO Y
RUNES [82] S Nei Y Y DA Y E, H Y
PRISMA [29] S Nei Y norte SA Y mi Y
SensorBus [87] S Nei Y NI NI Y E, H Y
Mires [88] S Nei norte norte NI Y mi Y
Hydra [101] S Nei, SI, SeI Y NI DA Y mi Y
SenseWrap [103] S Nei NI NI SA Y METRO Y
MUSIC [70] S Nei Y Y DA Y norte Y
TinySOA [105] S Nei NS NS NI Y E, H Y
SOCRADES [93] S Nei Y Y DA Y NI Y
SENSEI [109] S Nei, SeI Y NI DA Y NI Y
ubiSOAP [94] S Nei NS NI DA Y mi Y
Servilla [95] S Nei NS NI DA Y E, H Y
Kasom [110] S Nei, SeI Y NI DA Y E, H Y
CHOReOS [111] S Nei, SeI Y NI DA Y norte Y
Mosden [46] S Nei, SeI Y NI DA Y E, H Y
Xively [99] S Nei Y NI DA Y NI Y
Carriot [98] S Nei NS NI DA Y mi Y
Echelon [118] S Nei NS NI DA Y mi Y
Esterae [125] S Nei Y Y DA Y E, H Y
VM * [128] S Nei NI Y NS Y METRO Y
Melete [130] S Nei No Y DA NI METRO Y
MagnetOS [132] S Nei, SeI NI Y DA Y E, H Y
Squawk [133] S Nei NI Y NI NI METRO Y
Sensorware [129] S Nei Y Y DA Y norte Y
Extended Mat' e [137] S Nei, SI, SeI Y Y DA Y METRO Y
DVM [138] S Nei norte Y NS Y E, H Y
Davim [139] S Nei Y Y DA Y METRO Y
SwissQM [140] S SeI norte Y DA Y METRO Y
TinyVM [141] S NI NI NI NI NI E, H Y
TinyReef [123] S NI NI NI NI NI METRO Y
Impala [149] S Nei Y Y DA Y mi Y
Mensajes inteligentes [150] S Nei norte Y DA Y NI Y
ActorNet [151] S Nei norte Y DA Y E, H Y
Agilla [28] S Nei, SI, SeI Y Y DA Y METRO Y
Ubiware [152] S Nei, SI, SeI Y Y DA Y NI Y
UbiROAD [153] NI SI Y Y NI Y NI Y
AFME [154] S Nei Y Y DA Y METRO Y
MAPS [155] S Nei, SeI norte Y DA Y METRO Y
MASPOT [147] S Nei, SeI Y Y DA Y METRO Y
TinyMAPS [156] S Nei, SeI Y Y DA Y E, H Y
CAL [160] S Nei Y norte NS Y METRO Y
TeenyLIME [162] S Nei Y norte NI Y E, H Y
TinyLIME [161] S Nei Y norte norte Y mi Y
TS-Mid [164] S Nei Y Y DA Y mi Y
A3-TAG [165] S Nei Y Y DA Y E, H Y
SINA [166] S NS norte Y DA norte mi Y

PUMA [168] S NS norte norte NI norte METRO Y
IrisNet [169] S NS norte norte NS Y METRO Y
Sensation [170] S SI Y Y NS NI NI Y
TinyDB [69], [171] S NI NI norte DA norte mi Y
GSN [172] S NI NI NI SA Y METRO Y
KSpot + [173] S Nei norte Y NS NI mi Y
HyCache [174] S NI NI NI NI norte NS Y
AutoSec [175] NS Nei Y Y DA Y E, H Y
Adaptativo Middleware [176] NS Nei Y Y DA Y E, H Y
Milán [177] NS Nei, SeI Y Y DA Y mi Y
TinyCubus [178] S Nei Y Y SA Y mi Y
MidFusion [179] NS Nei Y Y DA Y norte Y
Leyenda Soportado Red (NE) Si) Si) Dinamicamente Si) Energía (E) Si)
No soportado (NS) (S) Sintáctica (SI) No n) No n) (DA) No n) Memoria (M) No n)
Sin información (NI) No soportado Semántica (SEI) Inactivamente No n)
(NS) (SA)
cosas Diario
migración de código es limitado. Muchos no se distinga entre el código de lógica de Popularidad: El crecimiento de una comunidad en línea activa en torno a un
negocio (es decir, el código de aplicación) o fi rmware código. Por otra parte, ninguno proyecto de software es una tarea difícil. El proyecto necesita para proporcionar un
maneja ambos casos. Muchos middleware con- dispositivos sólo homogéneos sidered, valor clara (por ejemplo, material, intelectual, el reconocimiento, la competitividad tivo)
aunque la máquina virtual se acerca a abordar este tema a través de la migración y la a los contribuyentes. Por ejemplo, Xively [ 99], ha llegado a ser popular tras el
asignación de código interpretado, en lugar de código compilado. Sin embargo, reducir accidente nuclear en Fukushima, cuando las personas utilizan esta plataforma para
el tamaño del código interpretado en comparación con el código compilado es todavía monitorear los niveles de radiación en todo el país. En este trabajo, la metodología
un reto. para evaluar la popularidad se basó en: la existencia de un depósito en línea en la
que se puso a disposición de los usuarios el código fuente, el número de citas del
documento que describe el middleware, y la existencia de comunidades activas en
torno a estos middleware . Un gran número de citas (es decir, más de 50) y la
B. Problemas relacionados con los requisitos no funcionales Escalabilidad: Como la mayoría de
existencia de un repositorio de código fuente o un sitio web dedicado refleja un
middleware existentes son WSNs céntrica, su escalabilidad a nivel de red también está limitado a
middleware altamente popular. A pocos (es decir, menos de
redes inalámbricas de sensores. Probablemente se realizan mal en red a gran escala de ultra de la
IO. Es importante destacar que, la escalabilidad es un requisito de todo el sistema, cada
componente (por ejemplo, descubrimiento de recursos, solución de seguridad, sensibilidad al

5) o hay citas, sin repositorio y no tiene sitio web dedicado, indica un middleware
contexto) de las necesidades de middleware ser escalable para lograr escalabilidad de todo el menos popular. Las obras en el medio, son moderadamente popular. Sin embargo,
sistema. un análisis completo de la cantidad de usuarios es más allá del alcance del papel.
Tiempo real: Las aplicaciones y servicios se basan en estar directamente conectado con el
mundo físico. La obtención de información en tiempo real sobre el estado del mundo real sigue
C. Desafíos relacionados con los requisitos arquitectónicos Programación de abstracción:
siendo una tarea difícil. Algunos enfoques de middleware son, por naturaleza, no en tiempo real
La mayoría de middleware ofrecen apoyo abstracción programa- ción. Sin embargo, los
(por ejemplo, bases de datos o tupla en el espacio middleware), mientras que el resto proporcionar
servicios en tiempo real, al menos suaves. Duro en tiempo real puede ser proporcionada por el nuevos lenguajes y herramientas que necesitan ser adoptados tienen una curva de
enfoque de middleware fi co-aplicación específica y unos pocos middleware basado en eventos. aprendizaje para los desarrolladores y usuarios. El apoyo a este requisito se puede
soluciones de middleware actuales deben tener en cuenta la composición de servicios en tiempo mejorar.
real o auto adaptabilidad.
interoperabilidad: interoperabilidad de las redes está bien apoyado por la mayoría

Confiabilidad: La fiabilidad no se trata en la mayoría de las propuestas de middleware existentes, pero muchos carecen de sustentación para la
existentes. Para lograr fiabilidad middleware, cada componente o servicio de un interoperabilidad semántica y sintáctica. la interoperabilidad semántica es muy difícil
middleware tiene que ser perfectamente capaz de sustitución. Existe una clara en la IO debido a la heterogeneidad y la falta de norma en ontologías. De todas las
dependencia entre la fiabilidad y otros requisitos (por ejemplo, la compresión de la catego- rías de middleware, el enfoque orientado al servicio ofrece el mejor soporte
gestión de datos, ligero / energía e fi ciencia), que debería ser mejor comprensión para la interoperabilidad semántica. Sin embargo, el apoyo a la interoperabilidad
de pie y explotado. Existe un margen significativo para el trabajo futuro en esta área. sintáctica es limitado. Por ejemplo, en los enfoques orientados al servicio, sólo se Hydra
[ 101] ofrece apoyo para este tipo de interoperabilidad. Se requiere investigación sobre
global, escalable y comprensión de sintaxis y la semántica de servicios de la IO.
Disponibilidad: Maximizando la disponibilidad del sistema y rápida recupera- ción de los
fracasos son desafíos que no son especí fi cos de la IO, sino a cualquier sistema distribuido.
En el contexto de la IO, la disponibilidad de las cosas y servicios que se ofrecen es basada en los servicios: La mayoría de los middleware son a base de servicio.
importante. Los dispositivos de hardware fallan periódicamente y cualquier servicio que Descripción del servicio ha de ser global, pero la energía e fi ciente para convertirse
prestan no estarán disponibles cuando fallan. la prestación de servicios debe ser adecuado para recursos limitados dispositivos. Además, el descubrimiento y la
transparente al obtener el servicio requerido desde un dispositivo diferente. composición de servicios deben ser autónomos y dinámicamente adaptativa.
Seguridad y privacidad: Todas las preocupaciones de seguridad, la privacidad y la confianza Adaptado: En una serie de enfoques, la adaptación de toma de decisiones no es
en todas las tecnologías (por ejemplo, Internet tradicional, redes inalámbricas de sensores, modificable y requiere volver a compilar y redeploy- ing del sistema o una parte del
comunicaciones M2M, RFID, SCADA, y la computación en la nube) utilizados en la IO están sistema. Donde la adaptación es más dinámicos, políticas, reglas o QoS se utilizan de fi
claramente presentes en el contexto de la IO. Sin embargo, la seguridad, la privacidad y la niciones, que se pueden cambiar en tiempo de ejecución para crear un nuevo
confianza no están completamente resueltos en estas tecnologías. Las soluciones de seguridad comportamiento. A pesar de que la mayoría de middleware utilizan un enfoque dinámico,
parcial basada en la mayoría de autenticación existentes Middlewares' son insuficientes para una las normas, las políticas de calidad de servicio y de fi niciones son en su mayoría no
serie de aplicaciones de la IO. Investigación para una solución de seguridad integral que se modificable y no son sensibles al contexto. En la IO, este enfoque no es escalable. Por otra
encarga de sistema, así como los aspectos de seguridad y privacidad de nivel intermedio es parte, middleware única aplicación especí fi c adaptan dinámicamente de acuerdo con los
necesario. requisitos de QoS, pero esto introduce un acoplamiento entre los componentes de
middleware. La investigación es necesaria para un modelo de adaptación más flexible,
La facilidad de despliegue: Implementación, posterior a la implementación, y dinámico y sensibles al contexto.
capacidad de programación re son tareas importantes en el ciclo de vida de middleware
IO. La reducción de la interacción humana en estas etapas y tener la posibilidad de
desplegar de forma remota el software intermedio sin ningún pre-con fi guración del Sensibilidad al contexto y el comportamiento autónomo: Los diferentes tipos de
dispositivo sigue siendo un reto interesante. middleware se han aprovechado de un cierto nivel de conciencia del contexto. Por
ejemplo, MUSIC [ 70] explota contexto para
cosas Diario
TABLA IV
S RESUMEN DE LA IOT MIDDLEWARE enfoques: IOT Requisitos del middleware
Funcional No Funcional Arquitectónico

Evento-Based CD-DED, RM, DPA, SS, CA NLWSNS, A, CR, HRT ABS, CW, Sb, E, H, DIST
Orientada a Servicios DD-DED, DD-SD, RA, RM, RCA, DS, DPA, SS AL, NLWSNS, NLIoTS, C, A, SRT ABS, Nei, CW, DA, Sb, E, H, DIST
VM-Based DD-DED, RA, RM, RCA, DS, DPA, LS, CA AL, NLWSNS, A, CR, SRT ABS, Nei, AUTO, DA, Sb, M, DIST
Basado en Agentes DD-DED, RA, RM, DPA, LS, CA, CM AL, NLWSNS, A, CR, DR, SRT ABS, Nei, SeI, CW, AUTO, DA, Sb, M, DIST
Tupla-Espacio CD-DED, CD-SD, RM, DS, DPA, SS, CM NLWSNS, SRT ABS, CW, M, DIST
Base de Datos Orientada DD-DED, RM, DS, DPA, SS NLWSNS, A, NRT ABS, E, DIST
Application-Speci fi c CD-SD, RA, RM, DS, DPA, DPF, LS, CA NLWSNS, A, CR, HRT Nei, CW, AUTO, DA, Sb, E, DIST
Leyenda AC / SC (Asignación de Código / Migración) A (Seguridad - Disponibilidad) ABS (Abstracción Supported)
CD / DD (centralizado / Descubrimiento Distribuida) AL (Escalabilidad: Nivel de Aplicación) AUTO (Autónomo)
DeD / SD (Dispositivo / Descubrimiento de servicios) AS (disponibilidad Supported) CW (Context Aware)
DPA / DPC / DPF (pre-procesamiento de datos - C (Seguridad - confidencialidad) DA (dinámicamente adaptativa)
Agregación, compresión, filtrado) CR (Fiabilidad - Comunicación) DIST (distribuido)
DS (almacenamiento de datos) DR (Fiabilidad - Datos) E (Ligero - Energía)
LS / SS (Grande / Pequeña Escala de Gestión de Eventos) I (Seguridad - Integridad) M (Ligero - Memoria)
ND (Network Discovery) TRH (Hard Real-Time) Nei (Red de Interoperabilidad)
RA (asignación de recursos) NLIoTS / NLWSNS (Escalabilidad: Nivel de Red SA (estáticamente adaptativa)
RCA (Recurso de Adaptive Composición) IO / escala WSN) SeI (Interoperabilidad Semántica)
RCL (El conflicto de recursos) NRT (no en tiempo real) SI (sintáctica Interoperabilidad)
RCP (Prede fi Ned Recursos Composición) P (Privacidad Supported) Sb (basada en servicios)
RM (Monitor de recursos) SRT (Soft en Tiempo Real)
auto-adaptación para mantener una QoS satisfactorios. Los usos comunes de contexto (por Tabla IV resume cada categoría middleware en términos de sus requisitos funcionales, no
ejemplo, descubrimiento de recursos sensible al contexto, la composición consciente del funcionales y arquitectónicos compatibles. En general, orientada al servicio, agente basan, y enfoques de
contexto, de gestión de datos sensible al contexto) [182], [183] a partir de otros campos diseño basados en VM dirección Más requisitos de IO que otros. Los enfoques de servicios orientada y
están desaparecidos. Además, el enfoque de ciclo de vida de contexto necesita ser basada en el VM apoyan la abstracción y de la red y la capacidad scal- nivel de aplicación también.
estandarizada. Esto mejorará la interoperabilidad entre los diferentes componentes de Además, estos enfoques son compatibles recursos agement hombre- través de composiciones de
middleware, así como la reutilización y la aplicabilidad de la información de contexto recursos, y la mayoría de los casos, estas composiciones pueden ser prede fi nido, especialmente en los
extraído. enfoques basados en VM. Sin embargo, prede fi Ned y mecanismos de composición determinísticos no
se escala bien en ambientes de ultra grandes y dinámicas de la IO. El enfoque de diseño basado en el
La mayoría de middleware existentes no son adecuados para sistemas con propiedades de agente es bueno en la gestión de recursos y de código debido a su naturaleza móvil y distribuida, pero
auto * (por ejemplo, la auto-adaptativo) M2M comunicaciones incluyendo. Junto con la esto significa que las soluciones de seguridad y privacidad son di fi culto. Por otro lado, middleware
explotación más amplia de contexto, inte- gración y la explotación de la inteligencia y las basado en la tupla-espacios se distribuyen y relativamente más fiable que otros debido a sus
propiedades auto- * en el sistema de middleware de la IO es una rica, área de investigación características de redundancia de datos. Al igual que los enfoques basados en agentes, middleware
abierta. basados en el espacio-tupla tendrán di fi cultades con la seguridad y la privacidad. enfoques de diseño
de bases de datos se comportan bien en la gestión de datos y responder con rapidez, asumiendo las
respuestas en tiempo no real son sufi- ciente fi. En general, un enfoque de base de datos no puede
V. S RESUMEN Y F UTURO W TRABAJO
proporcionar respuestas en tiempo real a la detección en tiempo real. middleware basados en eventos
El middleware es necesaria para facilitar el desarrollo de las diversas aplicaciones funcionan bien en aplicaciones móviles y reactivos, pero han limitado la interoperabilidad, adaptabilidad y
y servicios en la IO. Muchas propuestas se han centrado en este problema. Las sensibilidad al contexto. Finalmente, middleware de aplicación especí fi c están optimizados para una
propuestas son diversas e implican diferentes enfoques de diseño middleware y aplicación o un grupo de aplicaciones, y puede no ser adecuado y efectivo para otras aplicaciones.
soportan diferentes requisitos. En este trabajo se pone a estas obras en perspectiva y middleware basado en la tupla-espacios se distribuyen y relativamente más fiable que otros debido a sus
presenta una visión holística del campo. Al hacer esto, las carac- terísticas principales características de redundancia de datos. Al igual que los enfoques basados en agentes, middleware
de la IO y los requisitos de middleware de la IO se identifican. En base a estos basados en el espacio-tupla tendrán di fi cultades con la seguridad y la privacidad. enfoques de diseño
requisitos, un estudio exhaustivo de estos sistemas middleware que se centran en la de bases de datos se comportan bien en la gestión de datos y responder con rapidez, asumiendo las
corriente, ha sido presentada por el estado de la investigación de punta. Por último, respuestas en tiempo no real son sufi- ciente fi. En general, un enfoque de base de datos no puede
los temas de investigación abiertas, retos y líneas de investigación recomendadas proporcionar respuestas en tiempo real a la detección en tiempo real. middleware basados en eventos
posibles futuros se describen. funcionan bien en aplicaciones móviles y reactivos, pero han limitado la interoperabilidad, adaptabilidad y
sensibilidad al contexto. Finalmente, middleware de aplicación especí fi c están optimizados para una
aplicación o un grupo de aplicaciones, y puede no ser adecuado y efectivo para otras aplicaciones. middleware basado en la t
Esta encuesta clasifica a los middleware existentes accord- ing a sus enfoques de Aunque las soluciones de middleware existentes abordan muchos requisitos asociados
diseño: basada en eventos, orientada al servicio, basada en agentes, tupla en el con el middleware en IOT, algunos de los requisitos y las cuestiones relacionadas con la
espacio, basada en VM, base de datos orientada-y-aplicaciones específicas. Cada investigación siguen siendo explorado relativamente un-, tales como el descubrimiento
categoría tiene muchas propuestas de middleware, que se presentan en escalable y dinámica de recursos y la composición, la escalabilidad de todo el sistema, la
consecuencia. La mayoría de estos propuestas han sido revisados y que se resumen fiabilidad, la seguridad y la privacidad, la interoperabilidad , la integración de la inteligencia y la
en términos de sus exigencias funcionales, no funcionales y arquitectónicos sensibilidad al contexto. Existe un margen significativo para el trabajo futuro en estas áreas.
compatibles (Tabla I, II, y III). Los resúmenes muestran que cada middleware apoya
plenamente o parcialmente dos o más de los requisitos enumerados de cada tipo de
requisito (por ejemplo, PRISMA UN CKNOWLEDGMENT
Este trabajo es apoyado por la Fundación Científica de Irlanda (SFI) bajo el proyecto
parcialmente soporta la gestión de código a través de la asignación de código). Ninguno es compatible llamado SURF: el trabajo en red centrada en el servicio para los sistemas de retroalimentación
con todos los requisitos enumerados. escala urbana.
cosas Diario
R EFERENCIAS [30] S. y N. Hadim Mohamed, “Middleware: retos y Middleware

enfoques para redes de sensores inalámbricos” IEEE sistemas distribuidos en línea, vol. 7, no.
[1] M. Uusitalo, “Visión global para el futuro mundo inalámbrico de la 3, p. 1, 2006.
WWRF” Revista Vehicular Technology, IEEE, vol. 1, no. 2, pp. 4-8, [31] M.-M. Wang, J.-N. Cao, J. Li y S. Dasi “, Middleware para inalámbrico
2006. redes de sensores: Una encuesta,” Revista de Ciencias de la Computación y Tech- nology, vol.
[2] A. Gavras, A. Karila, S. Fdida, M. mayo, y M. Potts, “Future 23, no. 3, pp. 305-326, 2008. [32] DC Schmidt, “Middleware para sistemas embebidos en tiempo
búsqueda en Internet y la experimentación: la iniciativa fuego” Revisión del ordenador real y,”
Comunicación, vol. 37, no. 3, pp. 89-92, 2007. [3] K. Paridel, E. Bainomugisha, Y. Vanrompay, Communications of the ACM, vol. 45, no. 6, pp. 43-48, 2002. [33] N. Mohamed y J.
Y. bereberes, y WD Al-Jaroodi, “Una encuesta sobre media orientada a servicios
Meuter, “Middleware para el internet de las cosas, objetivos de diseño y desafíos” Comunicaciones WARE redes de sensores inalámbricos” Servicio de Informática y aplicaciones orientadas, vol.
electrónicas del EASST, vol. 28, 2010. [4] P. Bellavista, G. Cardone, A. Corradi, y L. Foschini, 5, no. 2, pp. 71-85, 2011. [34] J. Radhika y S. Malarvizhi, “Middleware enfoques para
inalámbrico
“Convergencia de
redes de sensores: Una visión general” IJCSI International Journal of Com- puter Temas
Manet y WSN en escenarios urbanos de la IO,” Sensores Journal, IEEE, vol. 13, no. 10, págs.
3.558-3.567, octubre de 2013.
científicos, vol. 9, no. 6, 2012. [35] X. Li y S. Moh, “sistemas de middleware para redes de sensores
inalámbricos:
[5] J. Gubbi, R. Buyya, S. Marusic, y M. Palaniswami, “Internet de
Un estudio comparativo” Ciencias de la Ingeniería contemporáneos, vol. 7, no. 13, pp.
Cosas: Una visión, elementos arquitectónicos, y las direcciones futuras” Futura generación
649-660, 2014.
de sistemas informáticos, vol. 29, no. 7, pp 1645-1660, 2013. [6] L. Atzori, A. Iera, y G. Morabito,.
[36] B. Bhuyan, HKD Sarma, y N. Sarma, “Una encuesta sobre middleware
“Internet de las cosas: Una encuesta,”
para redes de sensores inalámbricos” Diario de las redes inalámbricas y las
Red de computadoras, vol. 54, no. 15, pp. 2787-2805, 2010. [7] D. Le-Phuoc, A. Polleres, M.
Comunicaciones, vol. 4, no. 1, pp 7-17, 2014. [37] J. Al-Jaroodi, J. Aziz, y N. Mohamed,
Hauswirth, G. Tummarello, y C. mor-
“Middleware para sistemas fi d r.:
Bidoni, “El prototipado rápido de semánticas mash-ups a través de tuberías de web
Una visión general “, en COMPSAC '09. 33a Annual IEEE International,
semántica”, en Actas de la 18ª Conferencia Internacional sobre el World Wide Web. Nueva
vol. 2, julio de 2009, pp. 154-159. [38] NC
York, NY, EE.UU.: ACM, 2009, pp 581-590.. [8] A. Dohr, R. Modre-Opsrian, M. Drobics, D.
g Aitan, VG g Aitan, s. G. Pentiuc, I. Ungurean, y E. Dodiu,
Hayn, y G. Schreier,
“Middleware modelo basado de sistemas heterogéneos para SCADA dis- aplicaciones
“Internet de las cosas de la vida cotidiana asistida,” en Tecnología de la Información:
Tributado” Los avances en aparatos eléctricos y Engineer- ordenador ING, vol. 10, no. 2, pp.
Nuevas Generaciones (ITNG), 2010 Séptima Conferencia Internacional sobre, Abril de 2010, pp.
121-124, 2010. [39] D. Niyato, L. Xiao, y P. Wang, “comunica--máquina a máquina
804-809. [9] Contiki. [En línea]. Disponible: http://www.contiki-os.org/ [10] Brillo. [En línea].
Disponible: https://developers.google.com/brillo/ [11] mbed. [En línea]. Disponible:
ciones para el sistema de gestión de la energía en el hogar red inteligente” comunicaciones Magazine,
http://mbed.org/technology/os/ [12] antidisturbios. [En línea]. Disponible: http://www.riot-os.org/
IEEE, vol. 49, no. 4, pp. 53-59, 2011. [40] “La combinación de tecnologías de servicios heterogéneos para la
[13] FreeRTOS. [En línea]. Disponible: http://www.freertos.org/ [14] Linux embebido. [En línea].
construcción de una internet
Disponible: http://elinux.org [15] OpenWSN. [En línea]. Disponible: http://openwsn.atlassian.net
de las cosas middleware” Equipo de comunicaciones, vol. 35, no. . 4, pp 405-417, 2012.
TinyOS [16]. [En línea]. Disponible: http://www.tinyos.net/
[41] E.-J. Kim y S. Youm, “arquitectura de la plataforma de máquina a máquina

para la integración del servicio horizontal,” EURASIP Diario de Comunicaciones y Redes
Inalámbricas, vol. 2013, no. 1, pp. 1-9, 2013. [42] L. Roalter, M. Kranz, y A. M
[17] A. Katasonov, O. Kaykova, O. Khriyenko, S. Nikitin, y VY Oller, “Un middleware para inteligentes
Terziyan, “middleware semántico inteligente para el Internet de las cosas.” INSTICC Press, ambientes y el internet de las cosas “, en Actas de la 7ª Conferencia Internacional sobre
2008, pp. 169-178. Inteligencia y Ubiquitous Computing.
[18] Y. Ni, U. Kremer, A. Stere, y L. Iftode, “Programación ad-hoc Berlín, Heidelberg: Springer-Verlag, 2010, pp 267-281.. [43] Z. Song, A. Cardenas, y R.
redes de dispositivos móviles y con recursos limitados” No SIGPLAN., Masuoka, “middleware Semántica para la
vol. 40, no. 6, pp. 249-260, Jun. 2005. [19] H. Zhou, La Internet de las cosas en la nube: un Internet de las cosas “, en Internet de las Cosas (IOT), 2010, Nov pp. 1-8. [44] Y. Hong, “Un
middleware pectivas marco middleware orientado-recurso para heterogéneo
tiva, 1st ed. CRC Press, Inc., 2012. Internet nea de las cosas,”en Cloud y Servicio de Informática (CSC), 2012 Conferencia
[20] C. Perera, AB Zaslavsky, P. Christen, y D. Georgakopoulos, Internacional sobre, Nov 2012, pp. 12-16. [45] T. Teixeira, S. Hachem, V. Issarny, y N.
“Computación sensibles al contexto para la Internet de las cosas: Una encuesta,” Corr, Georgantas, “Servicio
vol. abs / 1305.0982, 2013. middleware orientado para el Internet de las cosas: Una perspectiva “, en
[21] K. Aberer y M. Hauswirth, “apoyo Middleware para el” internet de Actas de la 4ª Conferencia Europea sobre Hacia una Internet basada servicio-. Springer-Verlag,
cosas”,” 2006. 2011, pp. 220-229. [46] C. Perera, PP Jayaraman, A. Zaslavsky, P. Christen, y D. Geor-
[22] A. Azzara, S. Bocchino, P. Pagano, G. Pellerano, y M. Petracca,
“Las soluciones de middleware en WSN: El enfoque orientado a la IO en el proyecto ICSI”, en Software, gakopoulos, “Mosden: Una Internet de las cosas middleware para recursos limitados
Telecomunicaciones y Redes de Ordenadores, 2013 21ª Conferencia Internacional sobre. dispositivos móviles”, en Actas de la 47ª Hawaii 2014 Conferencia Internacional sobre
IEEE, 2013, pp. 1-6. Ciencias de Sistemas. Washington, DC, EE.UU.: IEEE Computer Society, 2014, pp
[23] V. Issarny, N. Georgantas, S. Hachem, A. Zarras, P. Vassiliadist, M. Au- 1053-1062.. [47] S. Bandyopadhyay, M. Sengupta, S. Maiti, y S. Dutta, “El papel de
Tili, MA Gerosa, y AB Hamida, “middleware orientada a servicios para el futuro de Internet:
estado de las direcciones artísticas y de investigación,” Diario de Servicios de Internet y middleware para Internet de las cosas: Un estudio,” En t. Revista de Ciencias de la Computación
aplicaciones, vol. 2, no. 1, pp. 23-45, 2011. [24] S. Bandyopadhyay, M. Sengupta, S. Maiti, y S. e Ingeniería de la encuesta, vol. 2, no. 3, pp. 94-105, 2011. [48] I. Moor
Dutta, “Un estudio de y Estrategia, “En cuanto al comportamiento segmentación el
middleware para Internet de las cosas “, en Tendencias recientes en Redes Inalámbricas y Móviles. Internet de Cosas (IOT),” 2013. [En línea]. Aprovechar-
Springer Berlin Heidelberg, 2011, vol. 162, pp. capaz: http://www.moorinsightsstrategy.com/wp-content/uploads/2013/ 10 /

288-296. Conductualmente-Segmentación-la-IO-por-Moor-Insights-Strategy.pdf [49] CP Greg Gorbach y
[25] FC Delicato, PF Pires, y T. Batista, Las soluciones de middleware para el A. Chatha, “la planificación de los sectores industrial
Internet de las Cosas. Springer, 2013. Internet de las cosas “, 2014. [En línea]. Disponible: http://www.arcweb.com/ folletos /
[26] K. Aberer, M. Hauswirth, y A. Salehi, “Las redes de sensores globales planificación-para-el-industrial-internet-de-things.pdf [50] M. Scott y R. Whitney, “El industrial
middleware para e fi ciente y el despliegue flexible y la interconexión de las redes de internet de las cosas”
sensores,”Tech. Rep., 2006. 2014. [En línea]. Disponible: http://www.mcrockcapital.com/uploads/1/0/ 9/6 / 10.961847
[27] M. Musolesi, C. Mascolo, y S. Hailes, “Emma: mensajería epidemia millones / mcrock industrial internet de las cosas informan 2014.pdf [51] Comisión TE, “Internet de
middleware para redes ad hoc” Personal y la computación ubicua, las cosas en el año 2020”, 2008. [ En línea].
vol. 10, no. 1, pp. 28-36, 2005. Disponible: http://www.caba.org/resources/Documents/IS-2008-93.pdf [52] PF Harald
[28] C.-L. Fok, G.-C. Romano y C. Lu “, Agilla: Un agente móvil media Sundmaeker, Patrick Guillemin y S. Woelf fl' mi, Visión
cerámica para redes de sensores inalámbrica auto-adaptativo,” ACM Transactions on y Desafíos para darse cuenta de la Internet de las cosas. Publicaciones O fi cina de la Unión
Autónoma y Sistemas Adaptativos (TAAS), vol. 4, no. 3, p. 16, 2009. [29] JR Silva, F. C Delicato, Europea, 2010. [En línea]. Disponible: http: // www. internet-of-things-research.eu/pdf/IoT
L. Pirmez, P. F Pires, J. MT Portocarrero, Clusterbook marzo de 2010.pdf [53] V. Ovidiu y F. Peter, Internet de las cosas: La convergencia
T. C Rodrigues, y T. V Batista, “Prisma: Una publicación-suscripción y middleware de las tecnologías
orientado-recurso para redes de sensores inalámbricos,” en AICT para Smart ambientes y ecosistemas integrados, 2013.
2014, 2014, pp. 87-97. [54] Unión de TI, “Itu informe de Internet 2005: El Internet de las cosas”, 2005.
cosas Diario
[55] ECHELON, “Requisitos para la Internet de las Cosas Industrial” [80] T. Yamashita, H. Yamaguchi, K. Yasumoto, T. Higashino, K. Taniguchi
2013. [En línea]. Disponible: http://media.digikey.com/Resources/ et al., “Middleware Emma: Una infraestructura de multidifusión de nivel de aplicación para la
Echelon / IIoT-WP.PDF comunicación de video multi-partido”, en Proc. del 15 Int. Conf. en Computación Paralela y
[56] Gartner, “” Gartner dice que la Internet de los objetos base instalada crecerá Distribuida y Sistemas (PDCS 2003), 2003, pp. 416-421.
a 26 mil millones de unidades en 2020, 2013”.
[57] Más de 30 mil millones de dispositivos de forma inalámbrica la conexión a internet de [81] T. Sivaharan, G. Blair, y G. Coulson, “Green: A gurable con fi y re-
todo en 2020. [En línea]. Disponible: https://www.abiresearch.com/ prensa / más-que-30 mil con fi gurable publicación-suscripción middleware para la computación ubicua,”en En el
millones de dispositivos de voluntad de forma inalámbrica-conne [58] V. Cristea, C. Dobre, y F. pop “, paso a sistemas significativos de Internet 2005: CoopIS, DOA, y ODBASE. Springer, 2005, pp.
entornos sensibles al contexto para 732-749. [82] P. Costa, G. Coulson, R. oro, M. Lad, C. Mascolo, L. Mottola,
el internet de las cosas “, en Internet de las cosas y Tecnologías Computacionales
INTERCOOPERATIVO de la inteligencia colectiva. Saltador GP Picco, T. Sivaharan, N. Weerasinghe, y S. Zachariadis, “El middleware runas para los
Berlin Heidelberg, 2013, vol. 460, pp. 25-49. sistemas integrados en red y su aplicación en un escenario de gestión de desastre” en Pervasive
[59] Grupo de IIS, “Internet de las cosas comienza con la inteligencia Computing y Comunicaciones, 2007. PerCom'07. Quinta Conferencia Internacional IEEE
adentro “, 2014. [En línea]. Disponible: http://www.intel.com/newsroom/ kits / internetofthings / sobre Anual.
pdfs / Presentation.pdf Día de la IO IEEE, 2007, pp. 69-78.
[60] G. Kortuem, F. Kawsar, D. Fitton, y V. SUNDRAMOORTHY, “ob- inteligente [83] K. Khedo, Kavi y R. Subramanian, “Misense: Una energía genérico
Jects como bloques de construcción para el Internet de las cosas” Internet Computación, IEEE, vol. 14, no. fi ciente arquitectura middleware ef para redes de sensores inalámbricos “, en ceedings pro de
1, pp. 44-51, enero de 2010. segunda Conferencia Internacional sobre Comunicación inalámbrica y redes de sensores
[61] D. Kyriazis y T. Varvarigou, “Smart, autónomo y fiable (WCSN-2006). IEEE, 2006, pp. 207-215.
Internet de las Cosas," Procedia Ciencias de la Computación, vol. 21, no. . 0, pp 442-448, 2013. [84] KK Khedo y R. Subramanian, “Meeca: energía Misense e fi ciente
algoritmo de agrupamiento “, en Comunicación inalámbrica y Net-sensor funciona, 2007.
[62] P. Banerjee, R. Friedrich, C. Bash, P. Goldsack, B. Huberman, J. Hombre- WCSN'07. Tercera Conferencia Internacional sobre. IEEE,
ley, C. Patel, P. Ranganathan, y A. Veitch, “todo como servicio: Alimentación de la nueva 2007, pp. 31-35.
economía de la información” Computadora, vol. 44, no. 3, pp. 36-43, marzo de 2011. [85] S. Lai, J. Cao, y Y. Zheng, “Psware: una publicación / suscripción middleware
apoyo de eventos compuestos en red de sensores inalámbricos,”en Pervasive Computing y
[63] A. Zaslavsky, C. Perera, y D. Georgakopoulos, “Sensing como un servicio Comunicaciones, 2009. PerCom 2009. IEEE Conferencia Interna- cional sobre.
y los datos grandes,” arXiv arXiv: 1301.0159, 2013. IEEE, 2009, pp. 1-6.
[64] D. Tracey y C. Sreenan, “Una arquitectura integral para internet [86] P. Boonma y J. Suzuki, “Tinydds: Un interoperable y con fi g-
de las cosas, los servicios de detección y grandes datos “, en Clúster, Cloud y Grid Computing urable” Principios y aplicaciones de sistemas basado en eventos distribuidos, pag. 206, 2010.
(CCGrid), 2013 13 IEEE / ACM Simposio Internacional sobre, Mayo de 2013, pp. 546-553.
[87] AR Ribeiro, F. Silva, LC Freitas, JC Costa, y CR Franc ES,
[65] Comisión TE, “La protección de los datos personales”, 2012. [En línea]. “Sensorbus: un modelo de middleware para redes de sensores inalámbricos,” en ceedings pro
Disponible: http://ec.europa.eu/justice/data-protection/ [66] Vivante Internet de las Cosas de la tercera conferencia internacional IFIP / ACM Latinoamericana de Redes. ACM, 2005, pp.
(IOT) Soluciones. [En línea]. Disponible: 1-9. [88] E. Souto, G. Guimaraes, G. Vasconcelos, M. Vieira, N. Rosa, C. Ferraz,
http://bensontao.wordpress.com/2013/10/06/vivante-internet-of-things/ [67] S. Neely, S.

y J. Kelner, “Mires: una publicación / suscripción middleware para redes de sensores,” Personal
Dobson, y P. Nixon, “middleware Adaptativo para auto-
y la computación ubicua, vol. 10, no. 1, pp. 37-44, 2006.
micas, sistemas” Annales Des T ' comunicaciones electrónicas, vol. 61, no. 9-10,
Pp. 1099-1118, 2006.
mq [89] Websphere. [En línea]. Disponible: http://www-03.ibm.com/software/
[68] L. Atzori, A. Iera, y G. Morabito, “Internet de las cosas: Una encuesta,”
productos / en / websphere-mq [90] mosquitto. [En línea]. Disponible:
Red de computadoras, vol. 54, no. 15, pp. 2787-2805, 2010. [69] TinyDB. [En línea].
http://mosquitto.org/ mq [91] IBM.
Disponible: http://telegraph.cs.berkeley.edu/tinydb/ [70] R. Rouvoy, P. Barone, Y. Ding, F. Eliassen,
[En línea]. Disponible: http://www-03.ibm.com/software/
S. Hallsteinsen, J. Lorenzo,
productos / es / IBM-MQ
A. Mamelli, y U. Scholz, “apoyo Middleware para la auto-adaptación en ambientes ubicuos y
orientada a servicios,” en La ingeniería de software para sistemas de auto-adaptativo. Springer, [92] M. Papazoglou, “computación orientada a servicios: conceptos, características
y las direcciones “, en Web Sistemas de Información Ingeniería de 2003. WISE
2009, pp. 164-182. [71] A. Katasonov, O. Kaykova, O. Khriyenko, S. Nikitin, y VY
2003. Actas de la Cuarta Conferencia Internacional sobre, Dic
2003, pp. 3-12.
Terziyan, “middleware semántico inteligente para el Internet de las cosas.” En
ICINCO-OISC. INSTICC Press, 2008, pp. 169-178. [93] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, y D. Savio, “Interact-
ción con la Internet basada en SOA de cosas: Descubrimiento, consulta, selección, y bajo
[72] M. Bakillah, SHL Liang, A. Zipf, y MA Mostafavi, “A dinámico
servicio y sensible al contexto semántico de mediación para el descubrimiento y la fusión de datos de
demanda de provisión de servicios web” Servicios de Computación, IEEE Transactions on, vol.
sensores heterogéneos “. J. Información Espacial Ciencia, 3, no. 3, pp 223-235, julio de 2010. [94] M. Caporuscio, PG Raverdy, y V. Issarny, “UbiSOAP:.
vol. 6, no. 1, pp. 155-185, 2013. A servicio-

middleware orientado a redes ubicuas” IEEE Transactions on servicios de computación, vol.
[73] H. Wang, X. Zhou, X. Zhou, W. Liu, W. Li, y A. Bouguettaya,
“Composición de servicios adaptativo basado en el aprendizaje por refuerzo,” en
5, no. 1, pp 86-98, 2012. [95] CL Fok, GC romano, y C. Lu, “Servilla:. Un servicio flexible
Orientada a Servicios de Informática. Springer, 2010, pp. 92-107. [74] G. Bin, Z. Daqing, y W.
aprovisionamiento de middleware para redes de sensores heterogéneos” Ciencia de la
Zhu, “Living with Internet de las cosas:
La aparición de la inteligencia integrada “, en Internet de las cosas (iThings / CPSCom) de programación informática, vol. 77, no. 6, pp. 663-684, 2012. [96] N. Reijers, K.-J. Lin, Y.-C.
2011 y la Conferencia Internacional sobre la 4ª Conferencia Internacional sobre cibernética, Wang, C.-S. Shih y JY Hsu “, Diseño
física y la informática social, Oct de un middleware inteligente para flexibles sensor de con fi guración de los sistemas M2M.”En SENSORNETS,
2011, pp. 297-304. 2013, pp. 41-46.
[75] K. Modukuri, S. Hariri, NV Chalfoun, y M. Yousif, “Autónoma [97] S. Hachem, “middleware orientada a servicios para el móvil a gran escala
marco middleware para redes de sensores,”en ICPS'05, pp. 17-26. [76] R. Meier y V. Cahill, Internet de las cosas “, Tesis, Universit' e de Versailles-Saint Quentin en
Yvelines, Feb. de 2014.
“Steam: middleware basado en eventos para inalámbrico
redes ad hoc “, en Distributed Computing Systems Talleres, 2002. Proceedings. 22ª [98] Carriots. [En línea]. Disponible: https://www.carriots.com/ [99] Xively. [En línea]. Disponible:
Conferencia Internacional sobre. IEEE, pp. 639-644. https://xively.com/ [100] Sicsthsense. [En línea]. Disponible: http://sense.sics.se/ [101] M.
[77] PT Eugster, PA Felber, R. Guerraoui, y A.-M. Kermarrec, “El Eisenhauer, P. Rosengren, y P. Antolín, “Hydra: Un desarrollo
muchas caras de publicación / suscripción” ACM Computing Surveys (CSUR),
vol. 35, no. 2, pp. 114-131, 2003. plataforma para la integración de dispositivos y sensores inalámbricos en los sistemas de inteligencia
[78] V. Issarny, M. Caporuscio, y N. Georgantas, “Una perspectiva sobre la ambiental “, en La Internet de las cosas. Springer Nueva York,
futuro de la ingeniería de software basado en middleware,”en 2007 Futuro de la Ingeniería de 2010, pp. 367-373.
Software. IEEE Computer Society, 2007, pp. 244-258. portal middleware [102] LinkSMART. [En línea]. Disponible: https://linksmart.eu [103] P. l. Evensen y
[79] PR Pietzuch, “Hermes: un middleware basado en eventos escalable” H. Meling, “Un middleware orientado a los servicios con
Universidad de Cambridge, Laboratorio de ordenadores, Tech. Rep. UCAM- CL-TR-590, virtualización del sensor y con fi guración,”en ISSNIP 2009, pag. 261.
Jun. 2004. [En línea]. Disponible: http://www.cl.cam.ac.uk/ techreports / [104] D. Steinberg y S. Cheshire, Cero Con fi guración de una red: La
UCAM-CL-TR-590.pdf Guía definitivo de. O'Reilly Media, Inc., 2005.
cosas Diario
[105] E. Avils-López y J. García-Macas, “Tinysoa: a archi- orientada a servicios [130] Y. Yu, LJ Rittle, V. Bhandari, y JB LeBrun, “Apoyando
tecture para redes de sensores inalámbricos” Servicio de Informática y aplicaciones orientadas, vol. aplicaciones simultáneas en redes de sensores inalámbricos,”en Actas de la 4ª Conferencia
3, no. 2, pp. 99-108, 2009. Internacional sobre Sistemas de sensores incorporados en red. ACM, 2006, pp. 139-152. [131]
[106] H. Bohn, A. Bobek, y F. Golatowski, “infraestructura de servicio para real W. Horr'
tiempo incrustado dispositivos conectados en red: un marco orientado al servicio para e, N. Matthys, S. Michiels, W. Joosen, y P. Verbaeten, “Un
diferentes dominios,”en CIE / icons / MCL, Abril de 2006, pp. 43-43. [107] S. de Deugd, R. Carroll, encuesta de middleware para redes de sensores inalámbricos” Informes CW, 2007.
K. Kelly, B. Millett, y J. Ricker, “Soda: [132] CM Kirsch, MA Sanvido, y TA Henzinger, “A pro-

Arquitectura Orientada a Servicios dispositivo” Pervasive Computing, IEEE, microkernel gramable para sistemas de tiempo real “, en Actas de la primera ACM /
vol. 5, no. 3, pp. 94-96, julio de 2006. conferencia internacional USENIX en entornos de ejecución virtuales. ACM, 2005, pp. 35-45.
[108] GF Anastasi, E. Bini, A. Romano, y G. Lipari, “Un servicio orientado [133] D. Simon, C. Cifuentes, D. Cleal, J. Daniels, y D. White, “Java
arquitectura de QoS con fi guración y gestión de redes de sensores inalámbricos “, en Tecnologías

Emergentes y Automatización de Fábrica (ETFA), 2010 IEEE Conferencia sobre. en el metal desnudo de los dispositivos de sensores inalámbricos: La máquina virtual Java de
IEEE, 2010, pp. 1-8. sirena “, en Actas de la 2ª Conferencia Internacional sobre Entornos de Ejecución virtuales. NY,
EE.UU.: ACM, 2006, pp 78-88.. [134] J. Cec'ılio y P. Furtado, “soluciones de middleware
[109] V. Tsiatsis, A. Gluhak, T. Bauge, F. Montagut, J. Bernat, M. Bauer,
existentes para inalámbrico
C. Villalonga, P. Barnaghi, y S. Krco, El real de Arquitectura de Internet Mundial sensei,
redes de sensores, en” Sensores inalámbricos en heterogéneos Networked Systems, 2014, pp.
“Hacia la Internet del Futuro - Tendencias de Investigación Europea”.
39-59.
IOS Press, 2010, pp. 247-256.
[135] J. Ellul y K. Martínez, “compilación en tiempo de ejecución de código de bytes en sensor
[110] I. Corredor, JF Mart'ınez, MS familiar, y L. L' opez, “el Conocimiento
redes “, en Tecnologías de sensores y aplicaciones (SENSORCOMM), 2010 Cuarta
conscientes y middleware para el despliegue de servicios generalizados orientada al
Conferencia Internacional sobre, Julio de 2010, pp. 133-138. [136] Z. Song, M. Lazarescu, R.
servicio,” Diario de Red y Aplicaciones Informáticas, vol. 35, pp. 562-576, 2012.
Tomasi, L. Lavagno, y M. Spirito, “High-
nivel de Internet de las cosas el desarrollo de aplicaciones utilizando las redes de sensores inalámbricos “,
[111] A. Ben Hamida, F. Kon, G. Ansaldi Oliva, CEM Dos Santos, J.-P.
en Internet de las Cosas, 2014, vol. 9, pp. 75-109.
Lorr' e, M. Autili, G. De Angelis, A. Zarras, N. Georgantas, V. Issarny,
[137] P. Levis, D. Gay, y D. Culler, “redes de sensores activa”, en Pro-
y A. Bertolino, “El futuro de Internet”, 2012, pp. 81-92. [112] A. Ben Hamida, F. Kon, N. Lago,
ceedings de la segunda conferencia sobre Simposio sobre diseño de sistemas en red e
A. Zarras, D. Athanasopoulos,
Implementación-Volumen 2. USENIX Asociación de 2005. [138] R. Balani, C.-C. Han, RK
D. pilios, P. Vassiliadis, N. Georgantas, V. Issarny, G. Mathioudakis,
Rengaswamy, I. Tsigkogiannis, y M. Sri-
G. Bouloukakis, Y. Jarma, S. Hachem, y A. Pathak, “choreos Integrado de middleware -
vastava, “Multi-nivel de reconfiguración de software Fi para redes de sensores,” en Actas de
permitiendo a gran escala, con QoS ographies chore- de adaptación,” Sep. de año 2013.
la sexta conferencia de ACM y la IEEE Internacional sobre el software embebido. ACM, 2006,
pp. 112-121. [139] S. Michiels, W. Horr'
[113] C. Perera, A. Zaslavsky, P. Christen, y D. Georgakopoulos, “Sensing
E, W. Joosen, y P. Verbaeten, “Davim: Un dynam-
como un modelo de servicio para las ciudades inteligentes apoyados por Internet de las cosas”
máquina virtual camente adaptable para redes de sensores,”en Actas del Taller
Las operaciones de consulta de Telecomunicaciones Tecnologías, vol. 25, no. 1, pp. 81-93,
Internacional sobre Middleware para redes de sensores.
2014. [114] E. Meshkova, J. Riihij¨ ACM, 2006, pp. 7-12.
arvi, M. Petrova, y P. M AHonen, “Una encuesta [140] R. Mueller, G. Alonso, y D. Kossmann, “Swissqm: Siguiente generación
en los mecanismos de descubrimiento de recursos, peer-to-peer y los marcos de descubrimiento de el procesamiento de datos en redes de sensores.”En CIDR, 2007, pp. 1-9.
servicios,” Comput. Netw., vol. 52, no. 11, agosto de 2008. [115] Top 49 herramientas para el Internet de las [141] K. Hong, J. Park, S. Kim, T. Kim, H. Kim, B. Burgstaller, y
cosas. [En línea]. Disponible: B. Scholz, “Tinyvm: una infraestructura de ejecución deficiente-ef de energía para redes de
http://blog.pro fi tbricks.com/top-49-tools-internet-of-things/ [116] OpenIoT. [En línea]. sensores” Software: La práctica y la experiencia, no. 10, 2012. [142] S. Bosse, “computación basada en
Disponible: http://www.openiot.eu/ [117] S. Satyadevan, B. Kalarickal, y M. Jinesh, “Seguridad, agentes Distribuido en el material de embebido
confianza y sistemas de redes de sensores con la arquitectura de agente en chip,” Sensores Journal,
Limitaciones de la implementación de plataformas de la IO prominentes “, en FICTA 2014, IEEE, vol. 14, no. 7, pp. 2159-2170, 2014. [143] P. Winterbottom y R. Pike, “El diseño de la
2015, vol. 328, pp. 85-95. inferno virtual
[118] plataforma IOT industrial. [En línea]. Disponible: http://www.echelon.com/ [119] MM Faghih y máquina “, en IEEE Compcon, vol. 97, 1997, pp. 241-244. [144] B. Folliot, I. Piumarta, y F.
ME Moghaddam, “SOMM: Un nuevo servicio orientado Riccardi, “A dinámicamente con fi gurable,
middleware para redes de sensores inalámbricos multimedia genéricos basados en la multi-idioma plataforma de ejecución “, en Actas de la octava ACM SIGOPS Taller Europeo
movilidad código” sensores, vol. 11, pp. 10 343 a 10 371, 2011. [120] A. Pulia fi a, A. Cucinotta, A. sobre el apoyo para la composición de aplicaciones distribuidas. ACM, 1998, pp. 175-181. [145]
Minnolo, y A. Zaia, “Making the M. Mamei y F. Zambonelli, Coordinación basados en campos para generalizado
Internet de las cosas en una realidad: La solución wherex,”en La Internet de las cosas. Springer
Nueva York, 2010, pp. 99-108. Sistemas Multiagente. Springer-Verlag New York, Inc., 2005. [146] DB Lange y M. Oshima,
“Siete buenas razones para agentes móviles”
[121] N. Mohamed y J. Al-Jaroodi, “Una encuesta sobre media orientada a servicios
Commun. ACM, vol. 42, no. 3, pp 88-89, marzo de 1999. [147] R. Lopes, F. Assis, y C.
WARE redes de sensores inalámbricos” Servicio de Informática y aplicaciones orientadas, vol.
Montez, “Maspot:. Un sistema de agente móvil
5, no. 2, pp. 71-85, 2011.
para el punto del sol “, en ISADS 2011, De marzo, pp. 25-31. [148] F. Aiello, G. Fortino, y A.
[122] N. Costa, A. Pereira, y C. Serodio, “máquinas virtuales aplicados a
Guerrieri, “Uso de agentes móviles como
WSN de: El estado de la técnica y clasificacion,”en ICSNC 2007, Ago
permite la tecnología para redes de sensores inalámbricos “, en SENSORCOMM '08, Aug de 2008.
2007, pp. 50-50.
[123] I. Marques, J. Ronan, y N. Rosa, “Una máquina virtual basado en registros
[149] T. Liu y M. Martonosi, “Impala: Un sistema de middleware para manag-
para redes de sensores inalámbricos,”en Sensores, 2009, pp. 1423-1426. [124] PA Levis,
ing sistemas de sensores autónomos, paralelas “, en Avisos ACM, SIGPLAN
“aplicación determinada máquinas virtuales: Sistema operativo
vol. 38, no. 10. ACM, 2003, pp. 107-118. [150] P. Kang, C. Borcea, G. Xu, A. Saxena, U.
soporte para programación SensorNet a nivel de usuario “, Ph.D. disertación, Berkeley, CA,
Kremer, y L. Iftode, “Smart
EE.UU., 2005. [125] P. Levis y D. Culler, “Mat'
Mensajes: Una plataforma de computación distribuida para redes de sistemas embebidos,” El
e: Una máquina virtual pequeña para el sensor
Diario del ordenador, Special Focus-Mobile y Pervasive Computing, vol. 47, pp 475-494, 2004.
redes” SIGARCH Comput. Archit. Noticias, vol. 30, no. 5, octubre de 2002. [126] P.
[151] Y. Kwon, S. Sundresh, K. Mechitov, y G. Agha, “Actornet:. Un actor
Stanley-Marbell y L. Iftode, “Scylla: Una máquina virtual inteligente
para sistemas embebidos móviles “, en Sistemas de Computación Móvil y Aplicaciones, plataforma para redes de sensores inalámbricos,”Tech. Rep., 2005. [152] N. Michal, K.
2000 IEEE Tercer Taller sobre. IEEE, 2000, pp. 41-50. [127] FC Delicato, PF Pires, y AY Artem, K. Oleksiy, N. Sergiy, S. Michal, y T. Vagan,
Zomaya, “plataformas Middleware: “Desafíos de middleware para el internet de las cosas”, en Control de Automatización -
Estado del arte, nuevos temas y tendencias futuras “, en El arte de redes inalámbricas de Teoría y Práctica. InTech de 2009.
sensores. Springer Berlin Heidelberg, 2014, pp. 645-674. [128] J. Koshy y R. Pandey, “Vm *: [153] V. Terziyan, O. Kaykova, y D. Zhovtobryukh, “middleware Semántica
síntesis de en- tiempo de ejecución escalable para entornos de carreteras inteligentes sensibles al contexto “, en RICIA, pp. 295-302. [154] C.
vironments para redes de sensores, en” En en Actas de la Tercera Conferencia Muldoon, G. OHare, R. Collier, y M. OGrady, “fábrica Agente
Internacional sobre Sistemas de sensores incorporados en red (Sensys. ACM Press, 2005, Micro Edition: Un marco para aplicaciones ambientales,”en ICCS 2006.
pp. 243-254. Springer Berlin Heidelberg, vol. 3993, pp. 727-734. [155] F. Aiello, A. Carbone, G. Fortino, y
[129] A. Boulis, C.-C. Han, R. Shea, y MB Srivastava, “Sensorware: S. Galzarano “, basado en Java-
Programación de las redes de sensores más allá de actualización de código y consulta” plataformas de agentes móviles para redes de sensores inalámbricos,”en IMCSIT, Oct
Penetrante y la informática móvil, vol. 3, no. . 4, pp 386-412, 2007. 2010, pp. 165-172.
cosas Diario
[156] F. Aiello, G. Fortino, S. Galzarano, y A. Vittorioso, “Tinymaps:

Un sistema ligero basado en Java de agentes móviles para redes de sensores inalámbricos “, en Distributed
Computing inteligente V. Springer Berlin
Heidelberg, 2012, vol. 382, pp. 161-170.
[157] NR Jennings, “Un enfoque basado en agentes para la construcción de soft- complejo
sistemas de mercancías,” comunicaciones, Pp. 35-41, 2001.
[158] E. Pignaton de Freitas, “Un estudio sobre el middleware adaptable para inalámbrica
redes de sensores,”2008.
[159] L. Mottola, AL Murphy, y GP Picco, “juegos generalizados en una
mote a habilitar mundo virtual usando el middleware espacio de tuplas,”en Quinto SIGCOMM ACM. ACM,
2006, p. 29.
[160] AL Murphy, GP Picco, y G. Romano, “Cal: Un middleware para
movilidad física y lógica “, en Distributed Computing Systems, 2001. 21ª Conferencia
Internacional sobre. IEEE, 2001, pp. 524-533.
[161] C. Curino, M. Giani, M. Giorgetta, A. Giusti, AL Murphy, y GP
Picco, “El middleware TinyLime” Penetrante y la informática móvil,
vol. 1, no. 4, pp. 446-469, 2005.
[162] P. Costa, L. Mottola, AL Murphy, y GP Picco, “Teenylime: tran-
siently compartida tupla middleware espacio para las redes de sensores inalámbricos “, en Middleware
para redes de sensores. ACM, 2006, pp. 43-48. [163] D. Gelernter, “comunicación generativo en
Linda,” TOPLAS, vol. 7,
no. 1, pp. 80-112, 1985.
[164] R. de Cassia Acioli Lima, NS Rosa, e IRL Marques, “TS-
mediados: Middleware para redes de sensores inalámbricos basados en espacio de tuplas,”en AINAW
2008, pp. 886-891.
[165] L. Baresi, S. Guinea, y P. Saeedi, “El logro de la auto-adaptación a través
gestión dinámica de grupo “, en Garantías para los sistemas de auto-adaptable.
Springer, 2013, pp. 214-239.
[166] C.-C. Shen, C. Srisathapornphat, y C. Jaikaeo “, la información del sensor
arquitectura de redes y aplicaciones” Las comunicaciones personales, IEEE, vol. 8, no. 4, pp.
52-59, 2001.
[167] K. Henricksen y R. Robinson, “Un estudio de middleware para el sensor
redes: el estado de la técnica y la orientación futura “, en Middleware para redes de sensores. ACM,
2006, pp. 60-65.
[168] P. Bonnet, J. Gehrke, y P. Seshadri, “Hacia base de datos de sensor
sistemas “, en Administración de datos móviles. Springer Berlin Heidelberg,
2001, vol. 1987, pp. 3-14.
[169] PB Gibbons, B. Karp, Y. Ke, S. Nath, y S. Seshan, “Irisnet: Un
arquitectura para una red de sensores en todo el mundo” Pervasive Computing, IEEE,
vol. 2, no. 4, pp. 22-33, 2003.
[170] P. Hasiotis, G. Alyfantis, V. Tsetsos, O. Sekkas, y S. Hadjiefthymi-
Ades, “Sensación: Una plataforma de integración de middleware para aplicaciones generalizadas en las
redes de sensores inalámbricos”, en Sensor de redes inalámbricas,
2005, pp. 366-377.
[171] SR Madden, MJ Franklin, JM Hellerstein, y W. Hong, “TinyDB:
un sistema de procesamiento de consultas acquisitional para redes de sensores” ACM
Transactions on sistemas de bases de datos, vol. 30, no. 1, pp. 122-173, 2005. [172] K. Aberer, M.
Hauswirth, y A. Salehi, “A middleware para una rápida
y el despliegue de redes de sensores flexible “, en Actas de la 32ª Conferencia Internacional
sobre muy grandes bases de datos, 2006, p. 1199.
[173] P. Andreou, D. Zeinalipour-Yiazti, P. Chrysanthis, y G. Samaras,
“Hacia un middleware consciente de la red de redes de sensores inalámbricos,” en DMSN 2011, 2011.
[174] D. Zhao y I. Raicu, “Hycache: un middleware de nivel de usuario para el almacenamiento en caché
distribuido sistemas de archivo,”en IPDPSW 2013, pp. 1997-2006. [175] P. ¿Han y N.

Venkatasubramanian, “AutoSec: Un mediados integrada
dleware marco para la intermediación de servicios dinámicos” IEEE Sistemas Distribuidos en
línea, vol. 2, no. 7, pp. 22-31, 2001.
[176] MC Huebscher y JA McCann, “middleware Adaptativo para contexto-
Las aplicaciones compatibles en hogares inteligentes “, en Middleware para Ad-hoc y Pervasive
Computing, 2004, pp. 111-116.
[177] W. Heinzelman, A. Murphy, H. Carvalho, y M. Perillo, “Middleware
para soportar aplicaciones de redes de sensores” Red, pp 6-14, 2004. [178] A.
Lachenmann,. “Tinycubus: Publications, 2011”.
[179] H. Alex, M. Kumar, y B. Shirazi, “Midfusion: Un mediados adaptativo
dleware para la fusión de información en aplicaciones de redes de sensores,” Inf. Fusión, vol. 9, no.
3, pp. 332-343, Jul. De 2008.
[180] A. Nedos, K. Singh, R. Cunningham, y S. Clarke, “dis- Probabilístico
covery de contenido semánticamente diversa en MANET,” Mobile Computing, IEEE
Transactions on, vol. 8, no. 4, pp. 544-557, abril de 2009. [181] SA Nwana, L. Lee, y NR
Jennings, “Coordinación en el software
sistemas de agentes “, 1996.
[182] K. Fujii y T. Suda, “servicio dinámico consciente del contexto basada en Semántica
composición “, en Instrumentación remota y laboratorios virtuales.
Springer Estados Unidos, 2010, pp. 293-311.
[183] W. Rong y K. Liu, “Una encuesta del contexto de descubrimiento de servicios web en cuenta:
Desde la perspectiva del usuario “, en SOSE 2010, pp. 15-22.

10 - IEEE - Middleware For Internet of Things - A Survey - Español

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

10 - IEEE - Middleware For Internet of Things - A Survey - Español

Transféré par

Droits d'auteur :

Formats disponibles

publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final.

información de referencia: DOI 10.1109 / JIOT.2015.2498900, IEEE Internet de las

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 1

Middleware para Internet de las cosas: una Encuesta

Términos del Índice -WSNs, RFID, M2M Comunicación, SCADA,

Considerando la importancia de la IO en varios dominios, este artículo tiene

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 2

Cualquier cosa Cualquier servicio

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 3

-End medio de dispositivos de computación (por

Las limitaciones de recursos cada vez más escasos y aumenta el dinamismo

Fig. 2. Ejemplos de heterogeneidad de dispositivos en la IO.

• Mayor seguridad Ataque de la superficie: Si bien existe un enorme potencial para

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 4

La vista de un middleware en este documento es uno que proporciona servicios

Fig. 3. Las aplicaciones potenciales de la IO [66].

• Administracion de recursos: Se espera que una calidad de servicio aceptable para

conjuntos: primero, los servicios de un middleware, que debería ofrecer, y segundo,

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 5

Los usuarios o aplicaciones de la IO

Recursos limitados, dinámico, sin infraestructura Autónoma

leyendas: El texto rojo: directamente relacionado

• Seguridad y Privacidad: La seguridad es fundamental para el funcionamiento de la

general • Abstracción de programación: Proporcionar una API para aplica-

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 6

Middleware en la IO es un área de investigación muy activa. Muchas soluciones se han

necesitan ser añadido a un middleware de la IO. Un middleware basado en

pueden diseñar, implementar, y se integran en un marco basado en los • orientada a servicios

aplicaciones. • Agente de base

encajar en sí en cambios en su entorno o las circunstancias. En la IO, la red y • Application-específica

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 7

es deficiente no-ef energía. Además, el apoyo para la fiabilidad es limitada.

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 8

recursos-ine fi ciente de middleware. PSWare es un middleware basado en tiempo ampliamente utilizado.

Para responder a la solicitud de servicio de aplicaciones en varios contextos, SensorBus desarrollados.

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 9

ofrece servicio de dispositivo y descubrimiento. La capa de servicios de aplicaciones proporciona

la gestión y almacenamiento de eventos. los SOCRADES Catálogo de Servicios Cruz-capa de

aplicaciones. Esta interfaz depende de modelado de sensor y envoltorios

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 10

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 11

CarrIoTs [ 98] es un middleware orientada al servicio basado en la nube para la IO,

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 12

las aplicaciones de máquinas virtuales y el software del sistema.

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 13

Capa fisica recursos limitados severamente. Un inconveniente de

Agente Agente Agente

ActorNet viene del mecanismo de descubrimiento de servicio utilizado, que es un protocolo

agente se distribuye en tres capas: un motor de comportamiento implementado en Java, un

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 14

asegura contexto-conciencia, y la composición gurable adaptativa / recon fi. Estos

AFME [ 154], MAPAS [ 155], MASPOT [ 147] y <MVN, 1>

TinyMAPS [ 156] son ​soluciones basadas en Java que permiten la programación

en MASPOT emplea un protocolo de difusión, que introduce una sobrecarga adicional

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 15

propusieron originalmente para tratar el problema de desconexiones frecuentes, y

resuelven, tales como: la interoperabilidad, el conocimiento del contexto, el comportamiento

sensación [ 170] es middleware orientado a la base de datos-desarrollado para

cantidad de tecnologías heterogéneas disponibles y es fácil de implementar. GSN es

IEEE INTERNET DE LOS OBJETOS Journal, vol. 0, NO. 0, 201X enero 17

y Adaptativo Middleware. El propósito de esta solución de middleware es evitar el

capa de middleware. Además, el enfoque aplicación específica crea soluciones

Tablas I, II, y III se resumen las capacidades funcionales, no funcionales y

TinyMAPS [ 156] son soluciones basadas en Java que permiten la programación