Summary of the dissertation

Con el fin de enriquecer la informaci´on que proporcionan a trav´es de la Plataforma USN las redes de sensores y dispositivos inteligentes que se conectan a ella, se desarroll´o una extensi´on experimental de la plataforma. Su objetivo fue permitir el procesamiento de los datos de bajo nivel que proporcionan las redes de sensores en busca de representaciones de mayor nivel sem´antico, aproxim´andose as´ı a las soluciones propuestas por la Semantic Sensor Web. Para lograr este fin se propuso el uso de statecharts implementadas con el lenguaje SCXML que, tal y como discutimos en la secci´on 3.3, presenta una capacidad y flexibilidad suficiente para tratar con el procesamiento de fuentes contextuales. Por este motivo, en la secci´on 7.3.1 se presenta una arquitectura de procesamiento de datos de los sensores basada en SCXML, para abordar en la secci´on 7.3.2 su integraci´on en la Plataforma USN de Telef´onica.

7.3.1. Arquitectura de procesamiento basada en SCXML

Las capacidades que ofrece el lenguaje SCXML para el procesamiento de informaci´on con- textual se describieron profundamente en la secci´on 3.3 y se evaluaron sobre nuestro Entorno Experimental en la secci´on 4.3.3. Bas´andose en estas capacidades, la figura 7.3 presenta una arquitectura de dos niveles para procesar datos de sensores (y redes de sensores) y proporcionar informaci´on de mayor nivel sem´antico, que se desarroll´o utilizando las tecnolog´ıas de nuestro En- torno Experimental. Esta nueva informaci´on permitir´a por una lado suministrar con informaci´on contextual de mayor nivel a aplicaciones sensibles al contexto (y entre ellas, a sistemas HMI) y por otro lado dotar a las redes de sensores de un componente sem´antico.

En la capa del nivel inferior, la DSSA (Domain-Specific Sensor Annotation Layer), se procesan las fuentes heterog´eneas de sensores mediante m´aquinas SCXML que integran informaci´on de un dominio espec´ıfico. As´ı, siguiendo el escenario del veh´ıculo y considerando que existen tres dominios independientes que describen el contexto global del escenario de la conducci´on que se consideraron en la secci´on 3.3, la DSSA incluir´ıa m´aquinas de estado recogiendo la informaci´on del conductor, del veh´ıculo y del entorno. Estas m´aquinas tienen que dise˜narse bas´andose en ontolog´ıas locales, de manera que puedan anotar sem´anticamente los eventos relacionados con datos de sensores espec´ıficos sobre los que est´a interesado. Para ello, como se vio en la secci´on 6.3.1, puede utilizarse herramientas de anotaci´on sem´antica como el RDFa, que permita introducir los atributos del RDF dentro del XML, o el XLink, que es propuesto por el SSN-XG como lenguaje de anotaci´on sem´antica para los est´andares de la Sensor Web.

En un segundo nivel, la SSP (Semantic Sensor Processing Layer), se usan las funcionalidades proporcionadas por SCXML para procesar informaci´on de diferentes dominios locales, generando

Figura 7.3– Arquitectura de dos niveles de procesamiento de la informaci´on contextual de redes de sensores

informaci´on sem´antica de mayor nivel. As´ı, volviendo a los ejemplos de la secci´on 3.3, el nivel SSP incluir´ıa m´aquinas de estados como la de RoadConditions o DrivingBehavior. Del mismo modo que en el nivel DSSA, las m´aquinas de estado tienen que ser dise˜nadas sobre ontolog´ıas espec´ıficas, pero esta vez representando dominios m´as globales. Asimismo, en este nivel la informaci´on sem´antica puede enlazarse a otras ontolog´ıas o conjuntos de datos sem´anticos existentes en la Web como la DBpediautilizando los principios del Linked Data. El nivel SSP puede proporcionar dos tipos de resultados:

Datos de sensores anotados sem´anticamente. Puesto que el nivel SSP procesa datos de sensores ya anotados sem´anticamente en el nivel DSSA, un posible resultado es extender autom´aticamente esta informaci´on a˜nadiendo otra del mismo dominio. As´ı, por ejemplo, ante una observaci´on de la velocidad del veh´ıculo, que ya fue anotada sem´anticamente por la DSSA con informaci´on como su unidad de medida, el momento de obtenci´on de la medida (sampling time) o el lugar en la que se ha obtenido (observation location), podr´ıa utilizar otra informaci´on del mismo dominio (veh´ıculo) como la del giro del volante para marcar la velocidad como inapropiada (ver figura 7.4).

Datos de sensores virtuales anotados sem´anticamente. Debido a que el SSP puede integrar o procesar datos sem´anticos de sensores de diferentes dominios locales del nivel DSSA, en esta capa se pueden identificar situaciones que describen informaci´on del mundo real que no se encontraba inicialmente en los dominios inferiores. Esta nueva informaci´on

Figura 7.4– Procesamiento en el nivel SSP

puede considerarse como observaciones producidas por un sensor virtual. De este modo, como se muestra en la figura 7.4, el SSP podr´ıa utilizar informaci´on de los dominios del entorno y del veh´ıculo para generar una observaci´on sobre el veh´ıculo como entidad de inter´es indicando que est´a llevando una conducci´on peligrosa.

En resumen, tal y como se observa en la figura 7.3, la anotaci´on sem´antica llevada a cabo en los niveles DSSA y SSP puede considerarse como un mecanismo para exponer los datos de la Sensor Web en la Semantic Sensor Web. Por otro lado la detecci´on del contexto y la interpretaci´on de ciertas situaciones proporciona informaci´on valiosa de alto nivel que puede alimentar a aplicaciones sensibles al contexto. Por ´ultimo, cabe se˜nalar que los datos anotados sem´anticamente podr´ıan ser ´utiles para aplicaciones sensibles al contexto que desarrollan sus propias estrategias basadas en los principios de la Web Sem´antica.

7.3.2. Integraci´on con la Plataforma USN

Una de las principales motivaciones a la hora de utilizar SCXML en la arquitectura anterior fue su exitosa aplicaci´on en plataformas de prestaci´on de servicios (SDPs - Service Delivery Platforms), donde se han demostrado muy buenos resultados de rendimiento en la composici´on de servicios en tiempo real (Moro et al., 2008). De especial relevancia es elFOKUS Service Broker que, basado en OSGi, proporciona orquestaci´on y ejecuci´on de servicios de telecomunicaci´on desarrollados en SCXML bajo restricciones de tiempo real (Blum and Schreiner, 2009).

Con el fin de desarrollar un an´alisis exploratorio de las capacidades y limitaciones de la arquitectura anterior, se desarroll´o una implementaci´on experimental en la que se integraba en la Plataforma USN. Para ello, tal y como se ilustra en la figura 7.5, la arquitectura SCXML se introdujo como una extensi´on natural de la entidad de procesamiento de datos (Data Processing Entity) de la Plataforma USN. Los principales problemas de implementaci´on que se abordaron fueron los siguientes:

Figura 7.5 – Integraci´on de la arquitectura de procesamiento SCXML en la Plataforma USN de

Telef´onica

La arquitectura SCXML se desarroll´o sobre la tecnolog´ıa OSGi. De este modo el servicio EventAdmin de OSGi tuvo que enlazarse con la funcionalidad de publicaci´on/suscripci´on de la Plataforma USN (m´odulo Publish/Subscribe) para que, cuando un sensor notificase una observaci´on al USN-Enabler, el evento correspondiente se comunicara a la capa DSSA, provocando la ejecuci´on de toda la arquitectura de procesamiento descrita en 7.3.1. En este mecanismo de adaptaci´on, los datos de sensores de la USN, que son modelados usando el lenguaje O&M, son guardados en el propiodatamodel del SCXML.

El proceso de anotaci´on sem´antica tambi´en se ha ampliado para que, cuando la actualizaci´on de la representaci´on haya finalizado, los datos de sensores anotados, que se encuentran almacenados en eldatamodel, sean devueltos al Registro de Observaciones (Observation Storage Entity en la figura). De este modo, los datos anotados pueden compartirse con aplicaciones de terceros a trav´es de su funcionalidad de publicaci´on/suscripci´on. Conse- cuentemente, adem´as de los datos de los sensores, se publican los enlaces sem´anticos entre los datos y descripciones formales basadas en ontolog´ıas. Por lo tanto se puede decir en este punto que, adem´as de continuar prestando servicio a las aplicaciones USN para las que inicialmente se desarroll´o, la Plataforma USN se convierte en una plataforma de redes de sensores sem´anticas (Semantic Sensor Network Platform).

Figura 7.6– Ejemplo del protocolo de anotaci´on sem´antica y notificaci´on de contexto

La ´ultima cuesti´on est´a relacionada con la publicaci´on de las situaciones de alto nivel que se obtienen como resultado del procesamiento SCXML en la capa SSP. Para ello se desarroll´o unbundle de comunicaci´on que permitiera publicar tales situaciones como datos de sensores virtuales a los que pudieran acceder aplicaciones interesadas a trav´es del mecanismo de publicaci´on y suscripci´on que la Plataforma USN proporciona. Esta funci´on se implement´o como un proceso externo que era invocado dentro de los estados SCXML que representaban dichas situaciones.

La figura 7.6 presenta el protocolo de comunicaci´on que tiene lugar entre la arquitectura SCXML y la Plataforma USN cuando un sensor notifica una observaci´on y una aplicaci´on se suscribe a cierta informaci´on proporcionada por la plataforma. El proceso comienza cuando la arquitectura de procesamiento SCXML recibe un evento de notificaci´on de un sensor a trav´es de la entidad de publicaci´on/suscripci´on de la Plataforma USN. A continuaci´on la capa DSSA enriquece los datos O&M recibidos del sensor con anotaciones sem´anticas y las almacena en el Registro de Observaciones (Observation Storage). Entonces, se notifica esta informaci´on a las aplicaciones interesadas, que estaban suscritas a ella a trav´es del m´odulo de publicaci´on/suscripci´on. Finalmente, si alg´un cambio en la capa DSSA provoca que las m´aquinas de estados de la capa SSP ejecuten transiciones a otros estados que detectan nuevas situaciones relevantes, se actualiza el Registro de Observaciones y se notifica esta nueva informaci´on a la misma aplicaci´on en el caso de que estuviera suscrita a ella.