TECNOLOGÍAS PARA LA GESTIÓN DEL CONTEXTO
Nota 4.2 La determinación de contexto como problema de clasificación.
Salvo por los tres conceptos expresados en el último párrafo (calidad de contexto para calidad de servicio, control de recursos y experiencia de usuario), el problema de estimación de la imagen de contexto se convierte en un problema clásico conocido, que admite una formulación estadística de reconocimiento de patrones, en términos de la calidad con la que se miden los observables (su función de distribución) y de la función F (cuya construcción en sí misma puede realizarse mediante aprendizaje automático). La clasificación de patrones puede ser de tipo numérico-estadístico, en caso de que la función haga corresponder valores numéricos de las variables de entrada a valores discretos de contexto, y también puede ser de tipo simbólico-sintáctico, basado en las relaciones estructurales entre las características. En buena parte de las aplicaciones contextuales, la función de reconocimiento de patrones tiene que manejar los dos tipos de parámetros, ya que éstos serán valores continuos (escalares o variables en el tiempo) y de valor discreto (binarios o no). Volviendo al ejemplo de la imagen de contexto que atribuye al usuario objetivo de un AHCS un estado de “dormido”, se puede observar que ésta ha sido estimada a partir de señales continuas (como el electrocardiograma que permite extraer la frecuencia cardiaca) y discretas (como la señal de un sensor de presión que simplemente determina si hay algo encima o no).
Otro concepto importante en el planteamiento que en esta Tesis se hace de la calidad de contexto está relacionado con la forma en la que se definen las imágenes de contexto, que se deberán diseñar como parte de jerarquías. El motivo es que la relación de la calidad de contexto con la gestión optimizada de recursos nos indica que no debe aspirarse a tener y mantener la máxima granularidad de contexto en toda situación, si este objetivo implica consumo de recursos y/o necesidad (demasiado frecuente) de solicitar al usuario información o medidas que, al final, no tendrán un impacto directo sobre la decisión. De esta forma, en función de sus “misiones” particulares, las aplicaciones o sistemas contextuales deberán definir sus imágenes de contexto de forma anidada, para poder refinarlas iterativamente.
Por ejemplo, la localización de un usuario que dispone de un terminal móvil puede realizarse (siempre que el dispositivo disponga de las tecnologías integradas) a través de un sistema de posicionamiento WiFi basado en terminal o de etiquetas/lectores RFID/NFC que detecten el paso de los usuarios por lugares precisos (p.e., puertas). Un sistema híbrido basado en Bluetooth y WiFi puede proporcionar una estimación de posición con un error medio de aproximadamente 2 m., siempre que el usuario disponga de conectividad permanente. Por su parte, el despliegue de etiquetas RFID/NFC
• • • ARQUITECTURA DE FUSIÓN MULTISENSOR PARA LA PROVISIÓN DE SERVICIOS CONTEXTUALES
disparará eventos discretos cuando el usuario atraviese un punto de paso determinado. En términos de disponibilidad, el sistema Bluetooth-WiFi podrá proporcionar una estimación de la posición cuando se le requiera (y el terminal tenga conectividad), mientras que el sistema RFID/NFC tendrá que acogerse a la última posición determinada, no pudiendo garantizar la actualidad de la información. Si se supone que los lectores NFC se encuentran en todos los dinteles de las puertas, utilizando esta tecnología puede tenerse una estimación simbólica de la sala en la que se encuentra el usuario. Esta información puede ser suficiente para un buen número de aplicaciones. Sin embargo, si la superficie de las salas es extensa (imagine el lector una sala de un museo, y un servicio contextual que pretende proporcionar información sobre obras concretas cuando el usuario se encuentre en sus inmediaciones), otro buen número de aplicaciones puede necesitar una estimación más precisa del lugar de la sala en el que se encuentra el usuario. No obstante, el conocimiento de la sala ya delimita el esfuerzo de cómputo que los posibles algoritmos de posicionamiento tendrán que realizar. Por tanto, la gestión anidada del parámetro de contexto “posición”, puede seguir una jerarquía edificio- planta-sala-zona-coordenada, que podrá solventarse habitualmente con la estimación simbólica proporcionada por la tecnología RFID/NFC, y sólo bajo demanda –cuando la aplicación lo defina-, activar el posicionamiento vía sistema Bluetooth y WiFi, y ejecutar los algoritmos de fusión definidos para obtener la información precisa. El coste computacional resulta determinante a la hora de optar por una solución (de localización, en este caso) u otra, o llevar al uso de un sistema híbrido que ofrezca una solución adaptativa que controle el coste en recursos.
Los patrones de contexto, entonces, se anidarán en niveles sucesivos de granularidad creciente y abstracción decreciente, con el objetivo de acelerar el proceso de construcción de contexto y limitar el coste (en términos de recursos y de tiempo) que supone inferir el contexto. Por ejemplo, el reconocimiento de patrones podrá utilizarse para obtener, a partir de los datos, características o features de contexto concretas (p.e. la posición, la humedad, la frecuencia cardiaca, etc.). A su vez, esos descriptores se combinarán para reconocer contextos/estados “de primer nivel” (como “usuario dormido” y “escape de gas”), que servirán de input para la deducción de metacontextos (como “emergencia”). Los contextos se irán infiriendo iterativamente, y la instanciación de algunos llevará a la recogida de datos para verificar los siguientes (por ejemplo, la definición de “emergencia” podrá activar la recogida de datos de sensores biométricos o domóticos que antes permanecían inactivos).
Las jerarquías de contextos han de diseñarse conjuntamente con las acciones de adquisición que se tienen que llevar a cabo para lograr instanciar dichas imágenes de contexto. El objetivo es lograr una jerarquía que satisfaga las necesidades de las aplicaciones, para así poder manejar aplicaciones que requieran diferentes niveles de información, teniendo en cuenta el consumo de recursos y el coste, en términos de computación y tiempo. Como ya se ha comentado, en el caso de un sistema de posicionamiento que gestiona diferentes algoritmos de localización, los cuales arrojan resultados con diferentes precisiones, será necesario evaluar el coste de la ejecución de cada algoritmo, con el fin de ajustar en tiempo real la operación para, ante la disponibilidad de varios algoritmos, elegir el que proporciona una precisión suficiente para la aplicación consumidora con un menor coste.
Por tanto, la propuesta de operación funcional en la estimación de contexto es la siguiente:
CAPÍTULO 4 • • •
158
“Los contextos en un sistema context-aware deben clasificarse y anidarse, en lo posible, en familias sucesivas de granularidad creciente, con necesidades crecientes y distinguibles de información, que permitan minimizar el consumo de recursos y mejorar la experiencia de usuario, recurriendo a la combinación de tecnologías adecuadas para ello y a la intervención del usuario para asegurar la calidad de contexto requerida por la calidad del servicio contextual.”
La Figura 4.32 ilustra el concepto. El sistema usa la cantidad de información necesaria y suficiente para hacer una clasificación del contexto en grandes familias. Sólo en caso de que la pertenencia a alguna de esas familias recomiende iniciar la adquisición con algún otro sensor, se iniciarán o activarán los procedimientos necesarios para adquirir o completar la información de contexto (bien interactuando con el usuario o bien gestionando directamente los recursos de infraestructura). Por ejemplo, el proceso de construcción de la imagen de contexto en un sistema automático de asistencia al mayor en su hogar puede establecer que, en situación normal, la frecuencia cardiaca de un usuario se envíe cada cierto tiempo. Mientras que ese parámetro (y otros que se determinen) estén estables, la imagen de contexto corresponderá a una situación de “normalidad”. En el momento en que se detecte una alteración en la FC, la situación de “normalidad” a “emergencia”; la detección de la nueva situación implicará la activación del envío de un electrocardiograma continuo en tiempo real.
Figura 4.32 El problema de obtención de contexto como uno de clasificación.
Para terminar, es importante destacar que es posible integrar el proceso de refinamiento de calidad de la estimación en la arquitectura presentada en la Sección 4.4.3, en la etapa de Evaluación de la Calidad de Servicio, en la que la incertidumbre en relación al contexto tiene que ver con la incertidumbre en la determinación de la familia, a su vez consecuencia de la incertidumbre en las medidas de determinadas características o features (por ejemplo, la posición). Se puede suponer que en determinados sistemas context-aware es factible mejorar la estimación, por ejemplo, aumentando el número de parámetros medidos o activando algunos sistemas extra de medida. El objetivo es, si la calidad requerida en la estimación del contexto por parte de la aplicación es superior a la que se tiene, y en ese momento y lugar las tecnologías lo permiten o se estima adecuado, interactuar con la infraestructura (y sus sensores) o con el usuario para ajustar la adquisición de los datos de contexto y construir imágenes menos costosas e igual de eficientes desde el punto de vista de la aplicación.
F … = n C C C C M 2 1 ˆ n C C C ′ ′ ′ M 2 1 Refinamiento en contexto Refinamiento en la estimación Solicitud de mayor precisión Características … …
• • • ARQUITECTURA DE FUSIÓN MULTISENSOR PARA LA PROVISIÓN DE SERVICIOS CONTEXTUALES
4.6 Conclusiones.
En este Capítulo se propone la conceptualización del problema de provisión de servicios basados en contexto como uno de fusión de información, dado el uso intensivo de sensores heterogéneos que es necesario realizar para instanciar una “imagen de contexto” que permita a la aplicación tomar decisiones adecuadas que resulten en una respuesta aceptable desde el punto de vista de usuario.
La “imagen de contexto”, que generalmente incluye información de situación de un usuario dado (datos personales, ambientales, biométricos, de actividad, etc.) e información de relación (peers o recursos cercanos y carácter del vínculo existente con ellos), es un concepto dinámico y adaptativo. Su composición y granularidad viene determinada por las características de la aplicación y por el momento de operación en el que ésta se encuentra. El objetivo de un sistema de apoyo a la provisión de servicios contextuales es instanciar en tiempo real la imagen de contexto, con un coste mínimo de recursos, y con el propósito de permitir que la aplicación consiga una determinada calidad de servicio. La calidad de servicio dependerá, entonces, de la capacidad de estimar correctamente el contexto (“calidad de contexto”) y de la capacidad de las aplicaciones de tomar decisiones correctas sobre dicha instancia de contexto (“calidad de la toma de decisiones”). Ya que la capacidad de decisión de las aplicaciones queda fuera del mismo sistema de provisión de servicios contextuales (por su diferente naturaleza, las aplicaciones divergirán en sus funcionalidades y en el proceso de toma de decisiones que las habilitan), asumiremos que las aplicaciones decidirán correctamente y que la “calidad de servicio” dependerá decisivamente de la “calidad de contexto”. Es decir, siempre que se consiga instanciar una imagen de contexto completa y correcta, se supondrá que la aplicación decidirá adecuadamente, y logrará la calidad de servicio deseada de cara al usuario final.
La consecución de una cierta “calidad de contexto” conlleva un cierto coste (de recursos, computacional y de interacción con el usuario). Si imaginamos un entorno en el que varias aplicaciones contextuales conviven y deben satisfacer sus necesidades de información simultáneamente, es lógico pensar en la necesidad de coordinar el proceso de adquisición y de hacerlo para lograr una cierta granularidad de información (el concepto de granularidad se puede asimilar, hasta cierto punto, con el de “precisión”). Generalmente, se puede vincular una mayor granularidad a un mayor coste (aunque esta afirmación es siempre dependiente de la disponibilidad de las tecnologías y de los requisitos de interacción con el usuario). Parece coherente, pues, pensar en el proceso de construcción de una instancia de contexto como un proceso iterativo de complejidad creciente, que permita componer y posteriormente instanciar “imágenes de contexto” con un grado de precisión de la información vinculado a las necesidades de la aplicación, con el objetivo de minimizar el uso de recursos.
En este punto, se propone plantear el problema de reconocimiento del contexto como uno de reconocimiento de patrones, en el que los contextos (o más bien, sus instancias) se definan, se clasifiquen y se aniden previamente en familias sucesivas de granularidad creciente, que permitan satisfacer las necesidades de las aplicaciones y minimizar el consumo de recursos. De esta manera, sólo bajo petición de las aplicaciones el sistema instanciará imágenes de contexto más complejas (asociadas a un mayor coste).
CAPÍTULO 4 • • •
160
Sobre estos conceptos, el Capítulo detalla una arquitectura funcional, inspirada en el modelo de fusión JDL. Formada por tres niveles (subsistemas de Adquisición de Contexto, Instanciación de la Imagen de Contexto y Razonamiento y Decisión) que contienen diferentes bloques funcionales, la arquitectura trata de servir como marco de análisis en el momento del diseño de una nueva aplicación o sistema contextual, o de su constitución a partir de sistemas/aplicaciones ya disponibles.
Aunque flexible, el modelo JDL imprime a la solución una visión fundamentalmente centralizada. Esta aproximación es adecuada para ciertos tipos de entornos de aplicación en el ámbito de los servicios contextuales. En concreto, aquellos cuyo elemento central es el usuario con su dispositivo móvil y cuya estrategia reside en gestionar los dispositivos en movimiento para cumplir una misión esencialmente colaborativa (búsqueda de entidades, asignación de recursos, establecimiento de grupos por proximidad, etc.). En muchas ocasiones, la misión del sistema contextual requiere construir una imagen de información global, sobre la cual el sistema es posteriormente capaz de razonar. Pero muchas otras aplicaciones requieren soluciones distribuidas, donde la adquisición y los procesos de razonamiento no se llevan a cabo en un controlador central sino de forma distribuida entre los diferentes nodos de la red.
A pesar de esta herencia que proviene de un mundo de problemas “centralizados”, la arquitectura propuesta no está restringida únicamente a éstos. La agrupación funcional no es dependiente de la implementación lógica, tanto sistemas centralizados como distribuidos englobarán muchas de las funcionalidades expuestas, alojándolas o identificándolas sobre distintos componentes lógicos.
Por otra parte, la consideración en la arquitectura del control de la “calidad del contexto” puede apoyar y optimizar los procesos de fusión y razonamiento, a la vez que permitirá establecer acciones correctivas en caso de que se detecte que el sistema no responde a los requisitos de calidad que necesitan las aplicaciones consumidoras. Las técnicas de control de calidad de la información de contexto se ejecutarán a varios niveles. Por ejemplo, en la fase de adquisición, se podrán componer estimadores de error para los datos adquiridos; en la fase de razonamiento, si por ejemplo se trata de estimar la actividad de un usuario, se podrá valorar la certidumbre de la inferencia en función de los descriptores utilizados para ello. Al final, la “calidad del contexto” dependerá de si el sistema es capaz de estimar la “instancia de contexto” que necesita la aplicación para razonar adecuadamente.
En la arquitectura propuesta, a pesar de existir una unidad cuyo nombre y orientación fundamental es el razonamiento y la toma de decisiones, el razonamiento no está únicamente alojado en este módulo. En general, se encuentra distribuido en diferentes unidades funcionales, que infieren conclusiones en sus niveles de decisión (a nivel de datos, señal, proposición, etc.).
Por otra parte, existen algunas funcionalidades que están presentes en numerosas unidades del sistema, y que podrían considerarse unidades horizontales de servicio. Son: • Privacidad y seguridad. La satisfacción de los requisitos de privacidad requiere el establecimiento de métodos que tienen que mantenerse durante el transcurso de todo el proceso de adquisición y transformación del contexto, adaptando su ejecución a las peculiaridades del sistema real. Por ejemplo, si la infraestructura
• • • ARQUITECTURA DE FUSIÓN MULTISENSOR PARA LA PROVISIÓN DE SERVICIOS CONTEXTUALES
de comunicaciones y posicionamiento adopta un modo ad hoc, el sistema podrá establecer políticas de compartición de recursos a la operación basadas en confianza (p.e. colaboración en procesos de enrutamiento o de localización). Si se trata de un sistema centralizado, las políticas de privacidad establecerá el uso de pseudónimos (que se mantendrá durante gran parte del proceso) o se controlará la precisión de la información de contexto (por ejemplo, precisión del proceso de posicionamiento).
• Apoyo al aprendizaje. El problema de clasificación (reconocimiento de patrones) surge en diferentes ocasiones y a diferentes niveles en la arquitectura de fusión propuesta: lo hace, por ejemplo, a la hora de estimar la posición de un usuario en una zona o posición simbólica, o cuando es necesario determinar la pertenencia a un grupo, sólo considerando datos de preferencias o de actividad. Aunque no es un tema que se aborde en esta Tesis, los procesos de aprendizaje (supervisado o no supervisado) pueden apoyar los procesos de instanciación y realimentar los procesos para mejorar su actuación.
Como ya se ha comentado, la descripción funcional realizada no condiciona la arquitectura lógica de implementación del sistema. Los bloques funcionales pueden adaptarse para ser íntegramente implementados sobre un dispositivo móvil de usuario, haciendo que éste sea capaz de adquirir la información y de instanciar su propia imagen, incluyendo también sus propios mecanismos de razonamiento y esquemas de decisión y decidiendo interacciones con el entorno, que pueden ir destinadas a cubrir faltas de información.
La arquitectura tampoco trata de definir los mecanismos de comunicación y publicación entre los diferentes bloques funcionales, ya que estos procesos serán altamente dependientes del diseño del sistema: por ejemplo, el proceso de adquisición de contexto puede implementarse bajo un modelo de pizarra (en el que todos los sensores publican su información en una estructura centralizada, y servicios de fusión consumidores capturan de esta pizarra la información que necesitan) o estar basado en el despliegue de widgets controlados por una entidad central, que se ocupa de gestionar las comunicaciones con las aplicaciones, proporcionándole a cada una los datos de interés. Asimismo, hay que resaltar que la arquitectura no concreta la forma de modelar el contexto. Los modelos de contexto son tan variados como las aplicaciones; muchas aplicaciones contextuales pueden resolverse manejando modelos tupla-valor, mientras que otras más complejas, pueden requerir el diseño de ontologías específicas sobre las que después aplicar motores de razonamiento.
Son, pues, muchos los aspectos que no trata de resolver la propuesta de arquitectura que se recoge en este Capítulo. El análisis del problema de adquisición y gestión del contexto, tal y como se ha abordado, tiene un marcado carácter funcional; su objetivo no es determinar un diseño lógico, recomendar un lenguaje de desarrollo o sugerir un modelo de contexto, sino proporcionar al diseñador del sistema o de la aplicación contextual un conjunto global de funcionalidades dirigidas a gestionar cooperativamente las tecnologías disponibles y a sustentar la óptima operación del sistema. De la misma manera, la aproximación adoptada en este Capítulo insta al diseñador a pensar en un catálogo de patrones de contexto, jerárquicos y anidados, de granularidad creciente, que después permitirán la gestión del proceso de adquisición para optimizar el coste (computacional, en término de recursos y de interacción con el usuario), a la vez que se
CAPÍTULO 4 • • •
162
garantiza a la aplicación una cierta “calidad de contexto” que permite que ésta, a su vez, proporcione al usuario una determinada calidad de servicio.