S3OiA: Propuesta de Arquitectura para la Interoperabilidad en la Internet de las Cosas Mario Vega Barbas, Diego Casado Mansilla, Juan R. Velasco Departamento de Autom´atica, Grupo de Ingenier´ıa en Servicios Telem´aticos Universidad de Alcal´a Campus Universitario, 28805, Alcal´a de Henares, Espa˜na. {m.vega, diego.casadom, juanramon.velasco}@uah.es

Resumen—El trabajo presentado pretende realizar una aportaci´on hacia la estandarizaci´on y la interoperabilidad, a trav´es de sistemas abiertos y accesibles, de los diferentes actores y tecnolog´ıas en el Internet del Futuro. Para ello se presenta S3 OiA, una arquitectura orientada a servicios que permite integrar cualquier tipo de objeto o dispositivo en la Internet de las Cosas, y utilizar los recursos que ofrecen como sustrato para ´ la generaci´on autom´atica de aplicaciones din´amicas. Estas ser´an capaces de evolucionar y de adaptarse al contexto de ejecuci´on mediante un sistema de gesti´on de dependencias, basado en eventos, entre dominios remotos. El contexto en el que se pretende aplicar el trabajo cubre todos los a´ mbitos susceptibles de involucrar al ser humano como la dom´otica, la inm´otica o los smart-grid. Palabras Clave—Internet de las cosas, Internet del Futuro, arquitectura software, SOA, interoperabilidad, espacio inteligente, objeto cotidiano inteligente.

I.

E STADO ACTUAL

La Internet de las Cosas (IdlC) presenta un escenario novedoso donde, la capacidad de c´omputo y generaci´on de informaci´on se incrementa considerablemente gracias a la inclusi´on de un n´umero elevado de actores computacionales. Adem´as, en este futuro modelo se pretende ofrecer un canal de comunicaci´on com´un, Internet, a trav´es del cual los citados actores puedan comunicarse y ofrecer recursos de forma transparente y uniforme. Resulta casi imposible determinar la inmensidad de actores que formar´an parte de la Internet del Futuro (IdF). Un informe reciente [1] augura m´as de quince mil millones de objetos intercomunicados en los pr´oximos diez a˜nos, con una media de seis dispositivos por habitante. Esto es posible gracias a los avances en la industria de circuitos integrados, que permiten que dichos dispositivos tengan un menor tama˜no gracias a la miniaturizaci´on de sus componentes [2] (p. ej. nanotecnolog´ıa, microcomputadores y sistemas embebidos) con un menor coste y sin decrementar su capacidad computacional. Adem´as, dichos dispositivos disponen, en la mayor´ıa de los casos, de interfaces de comunicaci´on que permiten enviar y recibir informaci´on, y realizar tareas m´as complejas mediante su asociaci´on en sistemas distribuidos, sistemas de rejilla, redes malladas, clusters, etc. Un ejemplo tipo son las redes de sensores (WSN). Debido a la naturaleza heterog´enea de estos actores, las capacidades y recursos que ofrecen ser´an diferentes. Dicha heterogeneidad debe ser entendida desde el punto de vista computacional de cada objeto, de los protocolos empleados

para la comunicaci´on, de la representaci´on de los recursos que ofrecen, y de los mecanismos usados para la interpretaci´on de la informaci´on. En el a´ mbito y literatura sobre la IdlC aparecen gran n´umero de conceptos y t´erminos de uso com´un. Por tanto, uno de los objetivos del este trabajo es presentarlos, y realizar un posicionamiento claro de los autores sobre dicha terminolog´ıa, definiendo adem´as, las necesidades y retos que deben ser abordados en el ins´olito modelo de comunicaci´on. Realizado el an´alisis de los nuevos espacios de interacci´on, este trabajo contribuye a la comunidad investigadora presentando una aproximaci´on de arquitectura software, que permita la integraci´on, la comunicaci´on y la interoperabilidad de esta cantidad ingente de nuevos elementos involucrados. El trabajo se organiza de la siguiente manera: la secci´on II representa un primer posicionamiento sobre conceptos tales como espacio inteligente y objeto cotidiano inteligente; la secci´on III, muestra la visi´on del nuevo modelo de interacci´on que los autores han definido para el a´ mbito de aplicaci´on de la IdlC; y la secci´on IV describe los retos que deben se extraen y deben ser abordados en la Internet del Futuro (IdF). En las secciones V y VI, se presenta y analiza la arquitectura S3 OiA compar´andola con algunos trabajos relacionados. Finalmente, en la secci´on VII se realiza una conclusi´on sobre el texto y se tratan las l´ıneas de trabajo que los autores consideran de inter´es para el futuro. II.

P OSICIONAMIENTO

El an´alisis de la literatura en el a´ mbito de la computaci´on ubicua, la inteligencia ambiental, y ahora en la IdlC, desprende un elevado uso de dos conceptos: objeto inteligente y espacio inteligente. En general, estas definiciones resultan vagas y dispersas, sin existir una convergencia clara hacia una interpretaci´on com´un [3], [4], [5]. Por tanto, consideramos fundamental ofrecer nuestra visi´on sobre dichos t´erminos con el fin de facilitar la comprensi´on del texto y de la arquitectura que se expone en la secci´on V. II-A.

Objeto cotidiano inteligente

El concepto de objeto inteligente debe ser extendido para abarcar a todos los objetos que son susceptibles de ofrecer cierta informaci´on (p. ej. localizaci´on f´ısica, origen, estado, utilizaci´on, etc.), llevando este concepto m´as all´a del dispositivo electr´onico como electrodom´esticos, dispositivos m´oviles, o incluso aquellos productos de alto desarrollo tecnol´ogico e industrial como los veh´ıculos [6]. La idea que se persigue

es dotar a elementos tales como mobiliario, ropa, comida, o materiales de construcci´on, de una identificaci´on virtual u´ nica, capacidad de comunicaci´on (mediante RFID, NFC, etc.), y/o de procesado de informaci´on (mediante transductores y microcontroladores embebidos). Con ello se consigue aumentar virtualmente objetos f´ısicos mediante tecnolog´ıas de la informaci´on, e integrarlos as´ı dentro del ecosistema de la IdlC con el fin obtener el m´aximo beneficio al unir el mundo f´ısico con el mundo digital [7]. Se puede, por tanto, hablar de objetos cotidianos inteligentes, y es posible hacer un s´ımil con el t´ermino spime, definido por B. Sterling [8]. De hecho, dichos objetos inteligentes son los actores principales para realizar el sue˜no que ya persegu´ıa M. Weisser [9] y que ahora florece con la IdlC. II-B.

Espacio inteligente

La inclusi´on de cierta capacidad de c´omputo dentro de los objetos de la vida cotidiana, no ofrece el objetivo final de obtener un sistema hol´ıstico e inteligente con capacidad de procesar y razonaar sobre las diferentes fuentes de informaci´on en pro del beneficio humano. Para conseguirlo, los objetos deber´ıan integrarse dentro del entorno f´ısico donde residen, conformar un entorno virtual, ser capaces de ofrecer sus recursos o funcionalidades, e interoperar de forma din´amica con otros objetos inteligentes. Siguiendo este patr´on, se crear´ıa un nuevo concepto de espacio de interacci´on virtual, donde confluyen a´ tomos y bits, al que denominamos espacio inteligente. La integraci´on de estos espacios en Internet, sumado a las t´ecnicas de agregaci´on de informaci´on, ampl´ıan enormemente las fuentes de datos que son generadas en un dominio f´ısico aislado por los objetos que lo conforman. Por tanto, se define un nuevo tipo de objeto al que denominamos virtual, que no posee presencia f´ısica en dichos espacios, pero que es capaz de comportarse como si la tuviera. Como ejemplos se pueden citar: los sensores virtuales [10], la agregaci´on de funcionalidades ofrecidas por objetos f´ısicos en una u´ nica virtual, fuentes externas de informaci´on (servicios Web), etc. Estos objetos virtuales no deben confundirse o ser incluidos en la definici´on de objeto cotidiano inteligente, debido a que su naturaleza es diferente y est´an u´ nicamente orientados a extender la funcionalidad de los objetos f´ısicos, mediante t´ecnicas de composici´on, agregaci´on o fusi´on de informaci´on. En definitiva, los espacios inteligentes deben brindar entornos m´ınimos de interacci´on, que extiendan el principio de localidad, que sean din´amicos, en continua evoluci´on y adaptaci´on, y que sean proactivos en si mismos. III.

IdlC, donde se definen sistemas de interacci´on e informaci´on centrados en el usuario [12], y donde los usuarios no son los u´ nicos consumidores y generadores de informaci´on sino cualquier elemento que sea capaz de hacerlo. Por tanto, un aspecto importante que se debe afrontar al tratar la IdF, es el rol que debe desempe˜nar el usuario. La cantidad de elementos involucrados en los espacios inteligentes hace realmente complicado que el usuario cree una imagen mental de ellos. Esto, unido a su caracter´ıstica de ubicuidad impide que el ser humano sea capaz de organizar dichos sistemas sin limitar y degradar su potencial. En cambio, resulta sencillo definir una visi´on global de los mismos, mediante abstracciones, y controlar si el funcionamiento y los resultados obtenidos, son los esperados. De esta forma se puede definir un nuevo cometido para los usuarios, el rol de supervisi´on [13], que permita seguir el ciclo de proceso de estos sistemas sin condicionarlos y por consiguiente, maximizando sus capacidades. La IdlC persigue integrar esta nueva forma de procesar y generar la informaci´on en la vida diaria de las personas, con el objetivo de conseguir el m´aximo beneficio [14]. Los autores del trabajo presentado han definido un modelo de interacci´on no intrusivo desde el punto de vista de relaci´on entre los usuarios y los sistema inteligentes: la intenci´on. Una intenci´on representa lo que un usuario desea realizar, define qu´e es lo que se quiere hacer y una serie de requisitos que deben ser cumplidos, en la medida de lo posible. El usuario no decide c´omo llevar a cabo la acci´on o qu´e mecanismos son necesarios para su consecuci´on, ser´a el sistema, el entorno inteligente, el que decida esto. Los usuarios deben entender los espacios inteligentes como cajas negras con las que pueden interactuar, y al mismo tiempo, estos sistemas deben hacer part´ıcipes a los usuarios mediante retroacciones. El diagrama de la Figura 1 muestra este proceso de interacci´on. Los entornos inteligentes adaptan la informaci´on generada para construir reportes sem´anticamente comprensibles, ya que estos ser´an ofrecidos al usuario, con el fin de mantenerle informado de c´omo se est´a desarrollando la actividad. Esta acci´on permite por tanto la supervisi´on activa de de los usuarios.

S ISTEMAS CENTRADOS EN EL USUARIO

La evoluci´on de Internet, desde el punto de vista del usuario, ha transformado la Web de ser un simple medio, donde entes especializados ofrec´ıan informaci´on de forma unidireccional, a convertirse en una herramienta para la gesti´on directa de la informaci´on. De hecho, actualmente son los usuarios los encargados de generar y consumir la informaci´on, de forma cooperativa, y desempe˜nan un papel director. El principal problema que encontramos con este enfoque se concreta en la regla 90-9-1 [11], es decir, el 90 % de las personas consumen, un 9 % modifica y s´olo un 1 % genera. En contraposici´on a esta regla, se sit´ua el siguiente salto evolutivo que persigue la

Figura 1. Diagrama de interacci´on basado en intenciones.

Toda la funcionalidad del sistema enfocada a resolver los problemas y restricciones presentadas en el proceso de interacci´on persona - entorno inteligente est´a contemplada y definida en un m´odulo concreto de la arquitectura propuesta en la secci´on V. El proceso de retroalimentaci´on del sistema hacia

el usuario puede resultar complejo debido, principalmente, a las capacidades f´ısicas y ps´ıquicas de cada persona. Para solventar los problemas que puedan desprenderse de ello se propone el uso de interfaces de usuario inteligentes multidispositivo [15]. Adem´as, mediante t´ecnicas de combinaci´on de dispositivos de entrada y salida, es posible lograr un nivel o´ ptimo de interacci´on [16]. De igual forma que se tiene en cuenta el uso de objetos cotidianos para la composici´on de los entornos inteligentes, es necesario extender el concepto de interfaz de usuario inteligente a todos los objetos de la vida cotidiana susceptibles a reportar informaci´on: televisores, espejos, luces, timbres, tel´efonos, aud´ıfonos, etc. IV.

R ETOS EN LA I DL C Y LA I NTEROPERABILIDAD EN E SPACIOS I NTELIGENTES

El nuevo modelo de comunicaci´on e interacci´on de la IdF presenta m´ultiples retos y concepciones que han de ser abordadas por las futuras tecnolog´ıas. La introducci´on de un n´umero incalculable de objetos con capacidades dispares dentro de las redes de comunicaci´on requiere el plantearse una serie de necesidades y requisitos funcionales en las nuevas propuestas de arquitectura. Por tanto, es obvio que tanto fabricantes como alianzas y grupos de estandarizaci´on, se est´en replanteando la modificaci´on y adaptaci´on de los protocolos actuales que permiten la integraci´on, la comunicaci´on y la interoperabilidad entre dispositivos. A continuaci´on se definen los principales retos de la IdlC. De cada uno de ellos se enumeran algunas problem´aticas a abordar, y por u´ ltimo se presentan una serie de propuestas y pistas, que no har´an sino conducir la definici´on y dise˜no de la arquitectura presentada en este trabajo de investigaci´on. IV-A.

Integraci´on en Internet

El principal objetivo que se persigue en el a´ mbito de la IdlC es doble, al igual que lo es el nombre del concepto. Por un lado la visi´on centrada en las Cosas, focaliza todo el esfuerzo en dotar al mayor n´umero de objetos f´ısicos de la capacidad de ser un´ıvocamente identificados. Adem´as, en el mejor de los casos, se proveer´ıa a los objetos de capacidad de procesamiento y de reportar informaci´on del entorno donde se encuentran. La otra visi´on, centrada en Internet, argumenta que no es suficiente tener objetos identificados de forma u´ nica, si estos se muestran aislados y sin capacidad de relacionarse con sistemas. Por tanto esta visi´on, que est´a respaldada por la ITU [17], persigue ofrecer un canal de comunicaci´on global y com´un, que integre y permita la comunicaci´on entre los diferentes dispositivos, objetos, servicios. De estas dos visiones se extr´aen una serie de retos y necesidades a abordar: Para conseguir que los objetos se integren en Internet, estos deber´ıan, por si mismos, ser capaces de incorporar la pila de protocolos IP. Sin embargo, el inconveniente principal radica en que en la mayor´ıa de los casos, los objetos presentan bajos recursos computacionales donde las memorias, el procesador y la bater´ıa son los factores de restricci´on.

Actualmente, los dispositivos que interaccionan dentro de un entorno son, por lo general, homog´eneos y comparten un canal de comunicaci´on y de identificaci´on com´un. Las nuevas arquitecturas han de tener en cuenta que dicho supuesto no ser´a v´alido y, por tanto, deber´an proponerse mecanismos de unificaci´on y traducci´on de los diferentes protocolos de comunicaci´on (p. ej. ZigBee, BlueTooth, RFID, NFC, Z-Wave, DASH7, etc.). Para que los objetos puedan integrarse f´acilmente dentro de un dominio de red, son necesarios una serie de servicios a nivel de aplicaci´on (p. ej. DHCP) y requieren de gesti´on experta. En ocasiones dichos mecanismos no est´an presentes. Si se asume que dispositivos heterog´eneos son capaces de cooperar, su interacci´on se suele limitar un dominio o a´ mbito espec´ıfico. Resulta pues compleja la fusi´on de diferentes dominios a trav´es de mecanismos como la encapsulaci´on, o las redes virtuales privadas, ya se que se requiere igualmente de un administrador de red. Desde el IETF1 hay un gran n´umero de grupos en activo para conseguir adaptar la pila IP a dichas limitaciones. Algunos ejemplos son 6LoWPAN2 y Roll3 . Sin embargo, dichos protocolos s´olo se centran en dispositivos programables con capacidades limitadas, olvidando una cantidad enorme de objetos, que son firmes candidatos a integrarse en los espacios de interacci´on (p. ej. dispositivos de protocolos propietarios). Para dar soluci´on a dichos requisitos, se requerir´ıan mecanismos de tipo Plug and Play que permitiesen la integraci´on de cualquier tipo de objeto en Internet, sin necesidad de gesti´on o administraci´on por parte del usuario. Para ello, se han de usar objetos de mayor capacidad de c´omputo, gateways, que han de formar parte de las arquitecturas de red como elementos integradores. Dichos gateways deben abstraer de las diferentes heterogeneidades que los objetos subyacentes presentan. Los gateways crear´an instancias virtuales de objetos que no tienen capacidad de conectarse por s´ı mismos a Internet, dotandoles de direcciones IPv6 virtuales, un identificador u´ nico, y expondr´an globalmente sus funcionalidades y recursos de manera uniforme y estandarizada. De igual forma, estos nodos de control han de implementar mecanismos de balanceo de carga, gesti´on de acceso concurrente y caching en favor de los objetos de pocos recursos. IV-B.

Interoperabilidad

Si se parte de la asunci´on de que millones objetos heterog´eneos est´an integrados, y poseen capacidad de identificaci´on y direccionamiento u´ nico en Internet, se dar´ıa un paso important´ısimo hacia la homogeneizaci´on y la interoperabilidad, pero no suficiente. En ese supuesto, se conseguir´ıa disponer backbone-IP donde, como mucho, se podr´ıan desarrollar aplicaciones orientadas a la gesti´on de red mediante protocolos de tipo ICMP o SNMP. Sin embargo, uno de los principales retos hacia la interoperabilidad en la IdlC, es que dos o m´as objetos puedan comunicarse de forma aut´onoma y cooperar (Machine-toMachine - M2M). 1 http://www.ietf.org/ 2 http://datatracker.ietf.org/wg/6lowpan/charter/ 3 http://datatracker.ietf.org/wg/roll/

Por tanto, se requieren tecnolog´ıas y nuevas arquitecturas de comunicaci´on orientadas a servicios ya que, en la mayor´ıa de los casos, lo que se busca es la informaci´on, los datos o recursos, en lugar del host u objeto que los ofrece. IV-B1. Arquitecturas Orientadas a Servicios Din´amicos: Las arquitecturas orientadas a servicios (SOA) suelen estar restringidas a dominios u´ nicos y/o privados. En e´ stas, las b´usquedas de recursos para crear aplicaciones, suelen ser bajo demanda, y adem´as dirigidas hacia un broker central siguiendo el paradigma Publicaci´on, B´usqueda, Binding [18]. El reto de la IdlC es que dichos mecanismos sean descentralizados, aut´onomos, din´amicos y escalables hacia diferentes espacios de interacci´on. Una arquitectura de este tipo requiere, que en el momento que un nuevo actor se introduce en un espacio inteligente se ofrezcan: i) mecanismos de abstracci´on que gestionen las funcionalidades descubiertas, ii) m´etodos de especificaci´on y exposici´on uniforme y iii) notificaci´on distribuida a los objetos potencialmente interesados que conforman dicho espacio u otros remotos. La principal problem´atica en el desarrollo de estas arquitecturas radica en la falta de generalizaci´on y de flexibilidad, pues las soluciones propuestas se centran en un contexto espec´ıfico. A continuaci´on se detallan algunos de las limitaciones y retos que se plantean en el marco de la IdlC: Los mecanismos de Descubrimiento de Servicios (DdS) suelen estar limitados al a´ mbito local. Adem´as, encontramos dos metodolog´ıas que, o bien no son escalables, como aquellas que usan direcciones multicast para la notificaci´on de eventos, ZeroConf4 o SLP [19]; o bien presentan un servidor central, broker, que representa un u´ nico punto de fallo y de f´acil sobrecarga - UDDI5 . Los objetos de capacidad limitada no ofrecen ni soportan mecanismos de DdS de alto coste computacional como pueden ser los utilizados por el protocolo UPnP6 . Al existir un gran n´umero de dispositivos dentro de un entorno, se pueden ofrecer mecanismos diversos de DdS, y por tanto no existe la posibilidad de comunicarse ni cooperar. Algunas especificaciones ofrecen proxies de notificaci´on hacia el exterior [20], pero en su mayor´ıa s´olo son v´alidos para alcanzar repositorios centralizados y previamente conocidos. Estas restricciones hacen evidente la necesidad de dise˜nar una arquitectura SOA de notificaci´on basada en eventos descentralizada, distribuida entre dominios, y que permita el desarrollo, despliegue y la evoluci´on din´amica de aplicaciones. IV-B2. Formato, Modelo de Datos y Sem´antica: La tecnolog´ıa de mayor impacto en los u´ ltimos 20 a˜nos ha sido sin ´ duda la Web. Esta gener´o una aceptaci´on generalizada debido a que permite la distribuci´on de informaci´on, contenidos y recursos a trav´es de un lenguaje com´un basado en hipertexto. A´un m´as con la posterior llegada de la Web 2.0, y su sencillo dise˜no centrado en la interoperabilidad, la cooperaci´on y reutilizaci´on de los contenidos que la forman.

El objetivo y la necesidad fundamental para hacer realidad la IdlC se centra en la estandarizaci´on de protocolos. De ah´ı que los futuros dise˜nos y soluciones planteadas no sean aislados, ni de aplicabilidad espec´ıfica o reducida, ya que, a pesar de ser elegantes o presentar un buen rendimiento, no jugar´ıan un papel integrador con los recursos y las fuentes de informaci´on que ahora conocemos. A continuaci´on se presentan algunas de las barreras que dificultan el poder llevar a cabo los objetivos y argumentos citados: Fabricantes y grupos de estandarizaci´on no llegan a un acuerdo para normalizar ni el formato de datos, ni los formalismos de representaci´on de objetos, recursos y servicios ofrecidos. Existe un amplio n´umero de plataformas implementadas para la IdlC, pero la mayor´ıa de ellas ofrece soluciones propietarias o no sujetas a est´andares. Los actuales servicios y recursos se crean por el usuario con el objetivo de ser usados e interpretados por e´ ste. Sin embargo, el salto evolutivo en el paradigma de interacci´on, nos lleva a un aumento de las relaciones que no tienen a las personas como mediadores (comunicaciones M2M, Servicio-M´aquina o Sistema-M´aquina). Se necesitan pues, nuevos modelos de interacci´on. Se ilustra dicha problem´atica mediante un ejemplo: Imaginemos dos objetos, una l´ampara con tecnolog´ıa Zigbee y un interruptor Bluetooth, que desean interoperar. Suponiendo que pudiesen comunicarse mediante abstracciones (p. ej.: IP+WADL7 +HTTP). La pregunta es obvia, ¿C´omo el interruptor podr´ıa interpretar que el tipo de datos a enviar con valor ”1”, significa encendido? Desde el punto de vista del ser humano, parece obvio, pero ¿y entre m´aquinas?. Las ontolog´ıas y sem´antica generadas en diferentes proyectos de investigaci´on son de dominio espec´ıfico. Habr´ıa que plantear el tipo de formalismo sem´antico para definir los objetos y el entorno inteligente donde se relacionan. Adem´as, no existe una taxonom´ıa, ni un modelo relacional definido para los objetos inteligentes. De hecho, si este se realizase, se encontrar´ıan conceptos comunes entre diferentes entornos de interacci´on y los objetos. Esto facilitar´ıa sustancialmente la b´usqueda y el encaminamiento de fuentes de informaci´on a cualquier dominio. Por consiguiente, se requieren lenguajes est´andar para el formato de datos y de recursos ofrecidos (por ejemplo: EMML, IDL, WSDL o WADL), as´ı como mecanismos de representaci´on e interpretaci´on sem´antica de dicha funcionalidad (RDFS, OWL, RIF) adaptados a los nuevos actores. De igual forma se precisa un protocolo a nivel de aplicaci´on, que sea est´andar para el acceso a estos (e.g. HTTP, XMPP). Desde el IETF se ha propuesto un protocolo de aplicaci´on ´ para dispositivos con recursos limitados llamado CoAP8 . Este est´a basado en HTTP y que sigue el modelo arquitect´onico REST. IV-B3. Aplicaciones en la IdlC: Las aplicaciones desarrolladas en de la IdlC pueden abarcar campos de aplicaci´on muy

4 www.zeroconf.org 5 http://uddi.xml.org/

7 http://www.w3.org/Submission/wadl/

6 http://www.upnp.org/

8 http://datatracker.ietf.org/doc/draft-ietf-core-coap/

dispares y diversos. Estas han de tener en cuenta factores tales como la dinamicidad del entorno y las limitaciones computacionales y de comunicaci´on de los diferentes actores. Los principales campos de aplicaci´on tecnol´ogica son: medidores de energ´ıa inteligentes y smart grid, eficiencia energ´etica en infraestructuras, redes dom´oticas e inmoticas, trazabilidad de bienes f´ısicos, automatizaci´on de procesos industriales, etc. Algunos de los requisitos para conseguir dicho nivel de generaci´on de aplicaciones flexibles se listan a continuaci´on: Composici´on y agregaci´on de funcionalidades, recursos y servicios independientemente de su localizaci´on, fuente o naturaleza, y del espacio inteligente desde el cual las aplicaciones sean creadas. Mecanismos de persistencia y tolerancia a fallos entre los diferentes registros de servicios, con el fin de asegurar un grado de disponibilidad aceptable de los recursos. Resoluci´on de dependencias a nivel de servicio a trav´es de los diferentes dominios de interacci´on. Es m´as, en caso de no poder resolver las dependencias necesarias, se deben ofrecer mecanismos de composici´on din´amicos que ofrezcan funcionalidades similares a las requeridas. V.

A RQUITECTURA PARA LA INTEROPERABILIDAD EN LA I DL C Los retos presentados y analizados en la secci´on previa, marcan la definici´on y dise˜no de la arquitectura presentada, bautizada como S3 OiA, la cual debe permitir la interoperabilidad de todos los actores de los espacios inteligentes en el contexto de la IdlC. Esta arquitectura cubre desde las necesidades inmediatas marcadas por la integraci´on de elementos heterog´eneos y de capacidades reducidas en Internet, hasta futuros requisitos caracterizados por el uso de mecanismos de interpretaci´on de la informaci´on generada por ellos mismos u otros diferentes. Actualmente no existen est´andares para la interoperabilidad en la IdF, por lo que se ha tomado como interfaz de abstracci´on entre sistemas heterog´eneos y base de la comunicaci´on los servicios Web. Sin embargo, la arquitectura ofrece la posibilidad de extender las interfaces sint´acticas, permitiendo mecanismos de interacci´on centrados en la comprensi´on y el razonamiento de la informaci´on y los recursos ofrecidos. A´un m´as, el posicionamiento realizado sobre el concepto de espacio inteligente requiere que se tenga en cuenta el contexto donde la informaci´on es generada, lo que hace que la propuesta se distancie sustancialmente de una simple interoperabilidad a nivel de servicio Web. Debido a la capacidad limitada de la mayor´ıa de los actores de la IdlC, se considera vital disponer de nodos de recursos computacionales mayores, gateways, que puedan realizar funciones de control y gesti´on de los recursos, a favor de los dispositivos subyacentes. Por todo esto, la propuesta se fundamenta en tres niveles de abstracci´on, como se observa en la Figura 2. Un nivel de comunicaci´on f´ısico, un nivel de exposici´on de servicios localizados en un mismo entorno y una capa virtual de interacci´on, donde los servicios son agrupados en espacios inteligentes. La arquitectura propuesta se ha definido mediante un enfoque modular, donde la funcionalidad se agrupa en conjuntos m´ınimos, m´odulos, y se establecen interfaces de comunicaci´on entre estos. Una representaci´on gr´afica de la arquitectura se

Figura 2. Diagrama de capas.

puede analizar en la Figura 3. Este dise˜no modular permite la evoluci´on arquitect´onica a trav´es del desarrollo paralelo y la reutilizaci´on de sus elementos. S3 OiA es una arquitectura orientada a servicios din´amicos, lo que significa: i) un acoplamiento d´ebil entre los servicios que se pueden llegar a ofrecer por medio de e´ sta, ii) un enlazado de dependencias en tiempo de ejecuci´on (late-binding) y iii) reutilizaci´on de servicios y de recambio por otros de funcionalidad similar. Si adem´as se contempla el uso de s´uper-nodos, gateways, que gestionen uno o m´as dominios de interacci´on, se podr´ıa dise˜nar una red distribuida de tipo peer-to-peer o federada, la cual permitiese la b´usqueda de servicios autom´atica, y la comunicaci´on de eventos a trav´es de dominios remotos en favor de las aplicaciones creadas. Los nodos involucrados deber´ıan cooperar y comunicarse bajo el paradigma de paso de mensajes as´ıncrono publicaci´on-subscripci´on. Es posible concentrar los m´odulos que definen la arquitectura en cinco grupos funcionales: Descubrimiento de dispositivos y servicios. La arquitectura dispone de un conjunto de m´odulos centrados en realizar el descubrimiento de elementos que ofrecen y/o consumen alg´un tipo de servicio. Este grupo funcional contempla dos casos: comunicaci´on entre dispositivos capaces de implementar protocolos como DPWS y UPnP; y comunicaci´on entre estos y otros sin dicha capacidad, que han de ser abstra´ıdos por gateways. De esta forma se permite que en los espacios locales, la comunicaci´on sea lo m´as descentralizada posible, a trav´es de una interacci´on m´aquina-m´aquina. Por tanto, se limita la funcionalidad de los nodos principales a tareas de abstracci´on y traducci´on de protocolos. Sem´antica de primer nivel y acceso a servicios. Conjunto de m´odulos encargados de completar las descripciones de las interfaces de acceso a los servicios descubiertos. Los metadatos utilizados para completar dicha descripci´on se extraen de la informaci´on de contexto local. Se generar´a pues una descripci´on formal de los servicios no estandarizados permitiendo su almace-

 





  

 

  

  

  



  

  

  

 

 

  

                 

Figura 3. Arquitectura compleja para la interoperabilidad en la IdlC.

namiento y su traducci´on a servicio Web. Repositorio de servicios y resoluci´on de dependencias. Este grupo se encarga principalmente de gestionar los servicios disponibles y de solventar las dependencias extra´ıdas de la composici´on de aplicaciones en el entorno f´ısico local (ver Figura 4, ejemplo a)). Adem´as, como toda arquitectura orientada a servicios, se contempla la definici´on de un m´odulo de gesti´on de eventos. Por tanto se facilita la creaci´on de aplicaciones y la composici´on de servicios por medio del paradigma de publicaci´on y subscripci´on. Por su parte, el repositorio de servicios representa una instancia de almacenamiento de informaci´on del conjunto global distribuido.

Figura 4. a)Resoluci´on de dependecias en local y b)remoto.

Sem´antica de segundo nivel e interacci´on. Los m´odulos agrupados en este conjunto se centran en la resoluci´on de los problemas y necesidades de alto nivel

cercanas al usuario. En concreto se definen aqu´ı los m´odulos de feedback y contexto global. Estos m´odulos ser´an los encargados de gestionar el nuevo modelo de interacci´on descrito en la secci´on III. La sem´antica de segundo nivel es la introducida por el usuario en el proceso de retroalimentaci´on y que resulta sumamente u´ til en el proceso de adaptaci´on de la informaci´on en funci´on del contexto global. Composici´on, tolerancia a fallos y dependencias externas. Finalmente, al mismo nivel que el grupo anterior se sit´uan los m´odulos encargados de llevar a cabo la composici´on de servicios y la resoluci´on de conflictos a nivel de entorno inteligente (Virtual Smart Space overlay, Figura 2). La arquitectura no es centralizada y por tanto, todas las dependencias no resueltas a nivel local deben ser elevadas a un espacio virtual, mediante un mecanismo de resoluci´on distribuido (ver Figura 4, ejemplo b)). Por u´ ltimo, a dicho nivel, se presentan dos m´odulos encargados de hacer frente a las inconsistencias, desconexiones o fallos que otros nodos de la red distribuida pudieran generar.

La evoluci´on de las TIC nos llevar´a a un escenario futuro donde todos los actores tendr´an capacidad computacional suficiente para realizar descubrimiento y ofrecimiento de servicios a trav´es de Internet. Por ello, la arquitectura presentada debe adaptarse, sin grandes costes, a dicha situaci´on. Como se puede observar en la Figura 5, los m´odulos de descubrimiento pueden ser obviados sin perjudicar el funcionamiento global, as´ı como los nodos de funcionalidad superior que hacen dichas funciones en favor de aquellos de pocos recursos. Las funcionalidades de alto nivel podr´ıan ser ofrecidas por entidades software mediante mecanismos de cloud-computing. El dise˜no modular en el que se ha basado la definici´on de la arquitectura ha de facilitar dicha transici´on.

 

   



  





  

  

 

 

  



Figura 5. Arquitectura futura para la interoperabilidad en la IdlC.

VI.

OTRAS PROPUESTAS HACIA LA I NTEROPERABILIDAD

La arquitectura presentada no es la u´ nica que persigue objetivos similares y de hecho, en la literatura, encontramos un n´umero amplio de plataformas que ofrecen interoperabilidad entre sistemas heterogeneos. Sin embargo, S3 OiA aborda ciertas problem´aticas necesarias para la IdF como: dinamicidad de los recursos expuestos, evoluci´on y adaptabilidad de las aplicaciones creadas, escalabilidad gracias a la integraci´on de cualquier tipo de objeto, cooperaci´on intra y entre dominios remotos (espacios inteligentes), etc. Por tanto, la propuesta es mucho m´as ambiciosa que una simple arquitectura orientada a servicios y ofrece caracter´ısticas que otras soluciones no presentan. Las plataformas y arquitecturas de mayor similitud a la propuesta, son aquellos sistemas basados en middlewares [21] de abstracci´on que facilitan el intercambio de informaci´on, de forma distribuida, entre sistemas heterogeneos y ubicuos. Sin embargo, dichas soluciones presentan una clara limitaci´on a nivel de escalabilidad y aceptaci´on, pues s´olo est´an orientadas a dispositivos programables con capacidad de almacenar parte del software de abstracci´on (por ejemplo aquellas basadas en CORBA [22]). Otra limitaci´on se desprende de su prop´osito espec´ıfico, por ejemplo el a´ mbito del hogar con Jini y OSGi [23], [24] o el a´ mbito empresarial-industrial con aquellas soluciones basadas en SOAP-WS [25], [26]. A´un m´as, la mayor´ıa de los middlewares restringen su aplicabilidad a plataformas de caracter´ısticas hardware o software u´ nicas dispositivos de grandes recursos [27], sensores con sistemas operativos espec´ıficos [28], m´aquinas virtuales [29], [30], etc. Igualmente encontramos soluciones orientadas u´ nicamente a la monitorizaci´on y gesti´on de redes de sensores utilizando APIs espec´ıficas[31]. Al no haber un est´andar com´un se hace necesario crear mecanismos de traducci´on entre middleware diferentes si se desea que estos cooperen [32]. Se encuentran pocos trabajos pr´acticos que provean un traductor com´un y unificado entre las diferentes soluciones. Por tanto, S3 OiA pretende ofrecer una arquitectura est´andar, abierta y de prop´osito general, que integre y reutilice todas las capacidades de Internet y los recursos y fuentes de informaci´on del entorno Web. En este sentido encontramos una propuesta centrada en interoperabilidad entre servicios Web, DPWS9 . Sin embargo al igual que UPnP, utiliza el paradigma SOAP-WS, que adem´as de no ser ligero, ni f´acil de integrar en dispositivos de capacidades limitadas, est´a orientado hacia servicios empresariales. Al igual que DPWS, pero orientado a automatizaci´on de infraestructuras, est´a la especificaci´on oBIX10 que est´a considerada como nueva generaci´on de middleware para el hogar, pero que no 9 http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01 10 http://www.obix.org/

muestra mecanismos de b´usqueda y cooperaci´on din´amica entre servicios de espacios inteligentes remotos. S3 OiA permitir´a la creaci´on de aplicaciones gen´ericas y evolutivas, sobre servicios Web basados en el patr´on REST, para cualquier tipo de a´ mbito (dom´otica, inm´otica, automatizaci´on o smart grid) donde los usuarios puedan jugar un rol de supervisi´on activa. VII.

C ONCLUSIONES Y TRABAJO FUTURO

El desarrollo de la Internet del Futuro y la evoluci´on de las TIC hacia un paradigma m´as proactivo y ubicuo, exige enfocar los trabajos de investigaci´on hacia un nuevo modelo de interacci´on entre dispositivos, cada vez m´as numerosos, y personas. En este sentido la estandarizaci´on es primordial, ya que es necesario especificar uniformemente qu´e define un espacio inteligente, c´omo debe realizarse la comunicaci´on dentro de dicho espacio, c´omo se realiza la comunicaci´on entre espacios remotos, y c´omo se puede, en definitiva, dar soporte a todos los niveles de interoperabilidad. Para poder realizar dichos objetivos, se ha presentado el dise˜no de una arquitectura, din´amica, flexible y capaz de evolucionar y adaptarse a los avances de la IdlC. S3 OiA es una arquitectura de tres niveles orientada a la composici´on y cooperaci´on ad-hoc de servicios distribuidos y din´amicos, que est´an uniformemente descritos. Para ello se han definido una serie de m´odulos de gesti´on de dependencias y tracking de servicios que permiten que las aplicaciones creadas contin´uen ejecut´andose a pesar de cambios de contexto, o de cambios en los recursos utilizados. Las aplicaciones resultantes podr´an ser creadas por y/o para el usuario haciendo uso de una serie de dispositivos con mayor capacidad de c´omputo, gateways, que permiten la integraci´on, la exposici´on uniforme y uso de cualquier tipo de objeto y sus recursos entre dominios remotos. Adem´as los autores analizados en han ofrecido su propia visi´on y comprensi´on de t´erminos y conceptos de uso com´un, como son los espacios inteligentes y los objetos cotidianos inteligentes. La IdlC avanza a gran velocidad, y son muchos los grupos de inter´es, tanto acad´emicos como industriales, quienes han tomado la iniciativa para realizar una verdadera interoperabilidad a escala global. A continuaci´on se detallan algunos de los temas que los autores consideran de inter´es para futuras investigaciones: Se necesita un esperanto en la IdlC para soportar interoperabilidad entre diferentes dominios de interacci´on. Se deben definir modelos de datos comunes a m´ultiples aplicaciones y a´ mbitos. La sem´antica juega un papel vital para representar el mundo f´ısico. Se debe estudiar que tipo de sem´antica ha de aplicarse a ciertos campos e infraestructuras de interacci´on. Ser´a fundamental investigar en la relaci´on sem´antica entre las aplicaciones creadas, los a´ mbitos donde se generan, y los recursos que las conforman.

La movilidad de los objetos es casi total en los escenarios y dominios de la IdlC y por tanto ha de gestionarse la presencia de dispositivos y recursos ofrecidos de forma global. Estandarizaci´on en el dise˜no de proxies y gateways de prop´osito general lo que ayudar´ıa a la interoperabilidad entre dominios de interacci´on globales. Los sistemas de la IdF requieren un componente de seguridad y privacidad alt´ısimo. Estos deben ser compatibles entre los diferentes actores sin importar su naturaleza. AGRADECIMIENTOS Este trabajo ha sido realizado al amparo del proyecto ITEA2 No 2008005, Do-it-yourself Smart Experiences, financiado por el Ministerio Espa˜nol de Industria y Comercio -AvanzaTSI-020400-2009-124. R EFERENCIAS [1] J. Morrish, “Internet 3.0: the internet of things,” Analysys Mason, Tech. Rep., 2010. [2] G. E. Moore, Cramming more components onto integrated circuits. Morgan Kaufmann, 2000, pp. 56–59. [3] G. Dalton, A. McDonna, and J. Bowskill, “The design of smart space: A personal working environment,” Personal and Ubiquitous Computing, vol. 2, no. 1, pp. 37–42, 1998. [4] I. Essa, “Ubiquitous sensing for smart and aware environments,” IEEE Personal Communications, vol. 7, no. 5, pp. 47–49, 2000. [5] R. Singh, P. Bhargava, and S. Kain, “State of the art smart spaces: Application models and software infrastrucutre,” ACM Ubiquity, vol. 7, no. 37, pp. 2–9, 2006. [6] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A surrey,” Comput. Netw., vol. 50, no. 15, pp. 2787–2805, 2010. [7] D. Casado, M. Vega, and M. L´opez, “Infraestructuras inteligentes en internet del futuro,” in 1st Encuentro de Investigadores en Infraestructuras Inteligentes (EI3), Guadalajara, Spain, 2011. [8] Shaping Things. MIT Press., 2005. [9] M. Weiser, The computer for the 21st century. Morgan Kaufmann, 1995, pp. 933–940. [10] S. Kabadayi, A. Pridgen, and C. Julien, “Virtual sensors: Abstraction data from physical sensors,” University of Texas, Tech. Rep., 2006. [11] J. Nielsen. (2006) Participation inequality: Encouraging more users to contribute. [Online]. Available: http://www.useit.com/alertbox/ participation\ inequality.html [12] Inmates Are Running the Asylum. Sams Publishing, 2004. [13] D. Tennnenhouse, “Proactive computing,” Communications of the ACM, vol. 45, no. 5, pp. 43–50, 2000. [14] M. Kuniavsky, Smart Things: Ubiquitous Computing User Experience Design. Morgan Kaufmann, 2010. [15] M. Vega and J. R. Velasco, “Intelligent multi-device user interfaces,” in PECCS 2011 - 1st International Conference on Pervasive and Embedded Computing and Comunications Systems, Vilamoura, Portugal, 2011. [16] M. Maybury and W. Wahlster, “Readings in intelligent user interface,” 1998. [17] I. T. Unit, “Itu internet reports 2005: The internet of things,” ITU, Tech. Rep., 2005. [18] M. Papazoglou and W. van den Heuvel, “Service-oriented design and development methodology,” Int. J. of Web Engineering and Technology (IJWET), 2006. [19] E. Guttman, C. Perkins, J. Veizades, and M. Day, “Service location protocol, version 2,” United States, 1999. [20] G. Moritz, E. Zeeb, S. Pr¨uter, F. Golatowski, D. Timmermann, and R. Stoll, “Devices profile for web services in wireless sensor networks: adaptations and enhancements,” in Proceedings of the 14th IEEE international conference on Emerging technologies & factory automation, ser. ETFA’09. Piscataway, NJ, USA: IEEE Press, 2009, pp. 43–50. [Online]. Available: http://portal.acm.org/citation.cfm?id= 1740954.1740961 [21] T. Nakajima, K. Fujinami, E. Tokunaga, and H. Ishikawa, “Middleware design issues for ubiquitous computing,” in Proceedings of the 3rd international conference on Mobile and ubiquitous multimedia, ser. MUM ’04. New York, NY, USA: ACM, 2004, pp. 55–62. [Online]. Available: http://doi.acm.org/10.1145/1052380.1052389

[22] F. M. Fern´andez, D. V. Alises, F. V. Molina, J. B. Romero, F. R. Calle, and J. L. L´opez, “Embedding standard distributed object-oriented middlewares in wireless sensor networks,” Journal on Wireless Communications and Mobile Computing, 2009. [23] S. Microsystem, “Jini specifications v1.2. - jini network technology,” 2010. [Online]. Available: http://www.sun.com/software/jini/specs/ [24] O. Alliance. (2010) Osgi service platform. [Online]. Available: http://www2.osgi.org/Specifications/HomePage [25] C. Mauro, J. Leimeister, and H. Krcmar, “Service oriented device integration: An analysis of soa design patterns,” in 43rd International Conference on System Sciences, Hawaii, USA, 2010. [26] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D. Savio, “Interacting with the soa-based internet of things: Discovery, query, selection, and on-demand provisioning of web services,” IEEE Transactions on Services Computing, vol. 3, no. 3, pp. 223–235, 2010. [27] V. Dhingra, “How to connect non ip devices into upnp.v1 fabric,” 2010. [Online]. Available: http://www.upnp.org/download/summitslides2003/ 01-13Echelon.ppt [28] E. Souto, G. Guimar˜aes, G. Vasconcelos, M. Vieira, N. Rosa, and C. Ferraz, “A message-oriented middleware for sensor networks,” in Proceedings of the 2nd workshop on Middleware for pervasive and ad-hoc computing, ser. MPAC ’04. New York, NY, USA: ACM, 2004, pp. 127–134. [Online]. Available: http://doi.acm.org/10.1145/ 1028509.1028514 [29] S. Michaelis, A. Wolff, and J. Shumutzler, “More-architecture and services,” EU Project MORE, Dortmund, Germany, Tech. Rep., 2007. [30] I. Mars´a, “Seth: A hierarchical, agent-based architecture for smart spaces,” University of Alcala, Tech. Rep., 2006. [31] S. Kunz, T. Uslander, and K. Watson, “A testbed for sensor service networks and the fusion sos: towards plug and measure in sensor networks for environmental monitoring with ogc standars,” in 18th World IMACS / MODSIM Congress, Cairns, Autralia, 2009. [32] C. Lee and K.-D. Moon, “Design of a universal middleware bridge for device interoperability in heterogeneous home network middleware,” in Consumer Electronics, 2005. ICCE. 2005 Digest of Technical Papers. International Conference on, 2005, pp. 371–372.