TECNOLOGÍAS PARA LA GESTIÓN DEL CONTEXTO
Nota 3.1 Comprenhensive Structured Context Profiles.
4.3 Implementación de la fusión de datos en plataformas para posicionamiento y provisión de
4.3.1 Context Toolkit
Principales investigadores involucrados: Anind Dey, Gregory Abowd et al. Instituciones: Georgia Institute of Technology
Fecha aproximada: 2000
URL: http://contexttoolkit.sourceforge.net/
a) Contexto y objetivos.
La fusión de datos no estaba entre los requisitos de diseño de Dey (Dey et al., 2001) cuando propuso la arquitectura del Context Toolkit (Wu, 2003). Por ello, el sistema presenta las siguientes limitaciones:
• No tiene soporte intrínseco para indicar la incertidumbre del contexto (por defecto, cualquier información contextual es correcta y no ambigua).
• No tiene soporte a la fusión directa de sensores. Una aplicación necesita preguntar o suscribirse a todos los widgets (aplicaciones que “envuelven” los sensores disponibles) y es ella misma la que decide si hay algún solapamiento o conflicto.
CAPÍTULO 4 • • •
104
• Es difícil de escalar. Si el número de sensores es elevado, no es sencillo para una aplicación seguir todos los sensores para que todos los posibles proveedores de contexto colaboren.
b) Arquitectura del sistema.
La arquitectura multicapa del Context Toolkit (CTK) está formada por diversos componentes, que sirven de elementos “contenedores” de las diferentes funcionalidades que necesita la aplicación. La estructura básica del CTK proporciona dichos elementos, junto con un sistema de comunicación basada en eventos, y mecanismos de control centralizado que facilita el control de recursos por parte de las aplicaciones.
El elemento más representativo de la arquitectura es el widget de contexto, elemento software que abstrae un sensor como flujo de datos, implementando las tareas básicas de adquisición o simplemente, estableciendo comunicación con servicios middleware externas que lleven a cabo este proceso. Una aplicación desarrollada con el CTK estará formada de varios widgets que recabarán la información procedente de los diferentes sensores disponibles, tanto físicos como virtuales. Además, el sistema utiliza intérpretes de contexto (context interpreter), que proporcionan el mapeado de un tipo de elemento de contexto a otro (realizan tareas de filtrado y conversión, fundamentalmente). Los agregadores (aggregators), por su parte, “fusionan” flujos de datos procedentes de diferentes widgets de contexto y de los intérpretes. Las aplicaciones más complejas utilizan, además, un elemento denominado discoverer, en el cual se encuentran registrados todos los recursos (widgets, interpreters, aggregators) que se pueden utilizar.
En el Capítulo 7 de esta Tesis, se presenta el desarrollo de un sistema contextual para asistencia a las personas mayores en su hogar, que se ha realizado utilizando el CTK como plataforma de soporte. Para una descripción más completa de la arquitectura del sistema y de los modos de desarrollo de aplicaciones, el lector puede avanzar hasta la sección 7.3.4 o, por supuesto, acudir a las fuentes originales (Dey, 2000).
Figura 4.4 Arquitectura del Context Toolkit original (Dey, 2001) y, a su derecha, arquitectura de fusión
propuesta por Wu (2003).
Wu (2003) propone una metodología sistemática de fusión de sensores implementada sobre el Context Toolkit. El autor propone utilizar la teoría de la evidencia Dempster- Shafer como una solución de fusión de sensores generalizable, ya que entiende que en muchas ocasiones es necesario manejar información subjetiva, observaciones de sensores de las que se desconoce su función densidad de probabilidad, y un alto grado
• • • ARQUITECTURA DE FUSIÓN MULTISENSOR PARA LA PROVISIÓN DE SERVICIOS CONTEXTUALES
de variabilidad en contenido y configuración. La fusión de sensores se realiza ponderando las aportaciones de información de cada sensor y realimentado los “pesos” de ponderación en base al resultado. Wu incluye el factor de que la incertidumbre y la ambigüedad son propiedades intrínsecas de la información. Su propuesta de arquitectura en tres niveles modifica la primera del CTK y queda como sigue:
• La capa inferior de la arquitectura consiste en widgets de sensores que se comportan como agentes (recogen los datos para generar estimaciones de “hipótesis”).
• La segunda capa es la de los mediadores de fusión, que consolidan las estimaciones de hipótesis de widgets de sensores relevantes para cada uno de los ítems de información de contexto predefinidos. Los mediadores de fusión de sensores utilizan la regla de combinación de evidencias Dempster-Shafer para reevaluar confianzas asociadas, combinar evidencias compatibles y resolver conflictos.
• La capa superior es la de los servidores de información de contexto y la base de datos dinámica de contexto. Los servidores recogen información relevante sobre el contexto de objetos específicos y la base de datos dinámica proporciona almacenamiento centralizado para todo el contexto disponible. Los intérpretes transfieren formatos de descripción de contexto y derivan contextos de más alto nivel. La confianza de la estimación se mejora superponiendo la información, mientras que las señales conflictivas reducen la estimación de confianza.
En el sistema de demostración, Wu estudia la actividad en el entorno de una sala de reuniones. Para conseguir determinar el “foco de atención” de los asistentes, utiliza dos sensores (de audio y de vídeo) que envuelve en sus respectivos widgets, y un mediador de fusión de “focos de atención” que realiza fusión competitiva. El objetivo es conocer qué está sucediendo en el espacio.
La propuesta de Wu proporciona al CTK un sistema de razonamiento más complejo que el que tradicionalmente admite, basado en reglas.
4.3.2 ActiveCampus
Principales investigadores involucrados: William G. Griwold et al. Instituciones: University of California, San Diego
Fecha aproximada: 2002
URL: http://activecampus.ucsd.edu/
a) Contexto y objetivos.
ActiveCampus es un proyecto49 de la Universidad de California-San Diego orientado a proporcionar servicios basados en localización en campus universitarios y estudiar cómo se utilizan estos servicios. Desde que se inició (alrededor de 2002), se han implementado varias aplicaciones (Griswold, 2004), entre las que destacan ActiveCampus Explorer, que proporciona información de personas y eventos en un entorno cercano, y ActiveClass, enfocada a fomentar la participación en las aulas
49
CAPÍTULO 4 • • •
106
(facilitando las preguntas anónimas, la participación en encuestas o proporcionando realimentación sobre la clase).
b) Arquitectura del sistema.
La plataforma ActiveCampus está basada en un modelo cliente-servidor, que utiliza llamadas a procedimientos remoto (remote procedure call, RPC) SOAP para detectar y notificar la posición. ActiveCampus localiza utilizando las medidas de potencia de señal WiFi (802.11b) recogidas por la PDA. Mejora el uso de métodos geométricos (basados en propagación de señal y altura de las plantas, por ejemplo) a través de la interacción con los usuarios; éstos pueden realizar correcciones de localización en el mapa que son guardadas en informes y utilizadas para refinar las inferencias de posición (Bhasker et al., 2004).
ActiveCampus utiliza actualmente la plataforma PlaceLab (que se comenta en el siguiente apartado) para posicionar.
4.3.3 PlaceLab
Principales investigadores involucrados: Jeffrey Hightower, Gaetano Borriello et al. Instituciones: Intel Research Seattle et al.
Fecha aproximada: 2003 URL: http://www.placelab.org/
a) Contexto y objetivos.
PlaceLab50 es un sistema de posicionamiento en cliente basado en el escaneo de balizas fijas (puntos de acceso 802.11 y estaciones base de telefonía móvil) y en la comparación de las señales recibidas con aquellas almacenadas en una base de datos residente en el terminal. Es decir, PlaceLab se centra en la gestión de la posición y lo hace desde el cliente.
Los creadores del sistema (Hightower , 2006) explican que prefirieron diseñar un sistema basado en terminal por motivos de privacidad; como requisitos de sistema, decidieron que éste tendría que funcionar tanto en interiores como en exteriores y sobre dispositivos convencionales y, además, debería soportar interfaces de programación estándar. El sistema conjugaría la obtención de información precisa con la disponibilidad del servicio. El resultado fue la arquitectura multicapa PlaceLab, una arquitectura de fusión que tiene por objetivo “separar los diferentes aspectos del procesado de datos en componentes lógicos que pueden ser independientemente mejorados, reemplazados o combinados” (Sohn, 2005). PlaceLab sigue las líneas generales de una arquitectura multicapa de fusión de streaming producido por eventos. Los autores reconocen que los componentes de PlaceLab están inspirados en los del Context Toolkit, y que como ActiveCampus, utilizan intensivamente el patrón de diseño de mediador híbrido (Riva et al., 2006).
50
• • • ARQUITECTURA DE FUSIÓN MULTISENSOR PARA LA PROVISIÓN DE SERVICIOS CONTEXTUALES
b) Arquitectura del sistema.
A continuación, se extrae de Sohn (2005) la explicación de cómo es la arquitectura del sistema PlaceLab.
Figura 4.5 Arquitectura de Place Lab. Las líneas punteadas son eventos, las sólidas son llamadas.
En cada capa de la arquitectura existe un Tracker de posición, que recibe los objetos de medida (Measurement) de la capa inferior (p.e. {marca temporal, identificador de baliza, potencia de señal}) y los correla con los meta datos de posición persistentes que están almacenados en el repositorio llamado Mapper (p.e. {identificador de la baliza, {latitud, longitud}}). De este proceso, infiere una posición, que publica un evento denominado Estimate cuando se incluye la posición actual (p.e. {marca temporal, latitud, longitud, error}). Alimentando a los Trackers están uno o más Spotters, los cuales recogen las salidas de los sensores y las abstraen como eventos de medida iniciales. De forma opcional, es posible conectar un adaptador separado para configurar un interfaz estándar para localización (p.e. un emulador de puerto serie GPS). En la última capa de la pila, las aplicaciones de localización procesan un stream de eventos de localización desde el servicio o directamente desde el objeto Placelab. En su versión más simple, PlaceLab puede instanciarse a través de un Spotter GPS y ningún tracker, por ejemplo. Los trackers se pueden apilar para hacer intersecciones (IntersectionTracker), calcular centroides (CentroidTracker), suavizar muestras (SmoothingTracker), etc.
Los Trackers son los componentes de la arquitectura que producen las estimaciones de posición: toman los datos crudos de los Spotters, construyendo objetos de medida (Measurement) y junto con los datos persistentes de los Mappers calculan una estimación de posición (Estimate). Los trackers pueden ejecutar fusión de sensores combinando datos de diferentes tipos de sensores (desde calcular centroides hasta efectuar estimaciones basadas en RSS, modelos de propagación, información del entorno, etc.). Las aplicaciones se registran para recibir la información de los trackers, y éstos anuncian los cálculos realizados.
En PlaceLab, la fusión de datos incluye cualquier tipo de transformación de medidas básicas a información de posición (coordenadas o nombre de un lugar). Los algoritmos de fusión pueden desarrollarse para funcionar síncrona o asíncronamente, y pueden soportar el acceso a un solo tipo de sensor o a varios, realizándose la fusión en el mismo
CAPÍTULO 4 • • •
108
dispositivo o en un sistema externo. En la implementación de PlaceLab se incluyeron cuatro Spotters estándar (802.11, Bluetooth, GSM y GPS).
Algunas singularidades del sistema son las siguientes:
1) Tanto Spotters como Trackers disponen de interfaces alternativas de sincronización de eventos para poder ofrecer a las aplicaciones actualizaciones de la información de posición según sus exigencias (algunas aplicaciones necesitan actualizar la información de forma síncrona y otras lo hacen bajo demanda del usuario, por ejemplo).
2) Como funcionalidad adicional, cuando un Tracker crea un nuevo estimador, adjunta las medidas o estimaciones que contribuyeron a obtenerlo. Es decir, cada Estimate guarda referencias a sus orígenes, estando estos datos disponibles para todos los trackers.
3) Los Mappers pueden fusionarse cuando se instancian, si es necesario, en una tabla hash, en una base de datos con tablas múltiples o en una almacén de tuplas secuenciales.
4.3.4 Location Stack
Principales investigadores involucrados: Jeffrey Hightower, Gaetano Borriello et al. Instituciones: University of Washington
Fecha aproximada: 2002
URL: http://portolano.cs.washington.edu/projects/location/
a) Contexto y objetivos.
La Location Stack (que evoluciona dentro del proyecto PlaceLab) es, según su primer autor, Jeffrey Hightower “un modelo software multicapa para gestionar el proceso de posicionamiento”. En su última versión, gestiona sensores de diverso tipo: infrarrojos (de VersusTech y SICK Inc.), RF ad hoc (utilizando los motes de Berkeley – hoy comercializados por CrossBow), ultrasonidos (sistema Cricket de MIT, hoy comercializado por Crossbow), lectores y etiquetas RFID (de Alien Technology), GPS, potencia de señal 802.11 y varios sensores de movimiento.
La Location Stack está reconocidamente inspirada en los siete niveles de la pila OSI (Open System Interconnect). Para configurarla, se han asumido en ella tipos fundamentales de medida y formas estándar para combinarlos. Por ejemplo, los tipos de datos que proporcionan los sensores pueden ser de distancia, ángulo, proximidad, posición declarada o características no geométricas (nivel de luz o características electromagnéticas de una habitación); por otra parte, cada medida tiene una incertidumbre derivada del sensor empleado.
Entre los criterios de diseño del modelo están (Graumann, 2003):
1) Configurar una interfaz uniforme para que las aplicaciones puedan tener acceso a la información de posición, bien en modalidad push o pull. Se desea que la información de posición sea proporcionada de manera flexible.
• • • ARQUITECTURA DE FUSIÓN MULTISENSOR PARA LA PROVISIÓN DE SERVICIOS CONTEXTUALES
fusión multisensor.
3) Hacer que el sistema pueda escalar en cuanto a tipos de tecnologías de posicionamiento sin que tenga que ser rediseñado y sin tener que modificar el código de la aplicación.
El Intel Universal Location Framework (Lara, 2003) está parcialmente basado en esta propuesta51.
b) Arquitectura del sistema.
La Location Stack trata de establecer niveles funcionales e interfaces a partir de una aproximación bottom-up al problema: la primera capa, considera los sensores; la segunda, los algoritmos; la tercera, la fusión de resultados; la cuarta, el razonamiento de relaciones; la quinta, la fusión con otros parámetros del contexto externos; la sexta, la relación de los datos con los servicios y la séptima, las intenciones de los usuarios.
Actividades Fusión de contexto
Capas de Adaptación manejo de Fusión contexto (no loc) Medidas Sensores
Figura 4.6 Location Stack.
En Hightower et al. (2002) se comenta qué contiene cada capa del modelo (Tabla 4.2) y qué exporta a la siguiente capa.
Tabla 4.2 Capas del modelo Location Stack. Capa Contiene Exporta
Sensores Hardware de sensores y drivers software para detectar fenómenos lógicos y físicos (medidas GPS, píxels blob de una cámara, tiempo de vuelo, login en un PC, proximidad…)
Datos sin procesar en variedad de formatos
Medidas Algoritmos que transcriben los datos sin procesar en tipos canónicos de medida, junto con la representación de incertidumbre basada en el modelo para el sensor.
Un stream de distancia, ángulo, proximidad, posición o medidas no geométricas.
Fusión Un método general para combinar streams de medidas y lograr una representación probabilística de posiciones y representaciones de objetos.
Una petición (query) o interfaz de eventos que proporciona las posiciones inmediatas de los objetos y las incertidumbres asociadas. Se puede incluir, también, otro tipo de información compleja (velocidad, aceleración, históricos).
Adaptación Un motor de razonamiento probabilístico sobre las relaciones entre dos o más objetos. También convierte información
Una petición (query) o interfaz de eventos hacia las relaciones entre dos o más objetos que son individualmente
51 Según se explica en Lara (2003), el Marco Universal de Localización (Universal Location Framework) de Intel es
un sistema que permite la agregación de múltiples tecnologías de localización y la transición seamless entre ellas, además de disponer de una Interfaz de Programación (API) basada en la Location Stack. La API está realizada según el paradigma de orientación a objetos y se presenta utilizando diagramas UML (Unified Modeling Language). El objetivo de ULF es constituir un sistema que pueda facilitar la creación de aplicaciones y servicios innovadores y rentables.
CAPÍTULO 4 • • •
110
de posición entre coordenadas absolutas y relativas.
localizables utilizando la capa de Fusión.
Fusión contextual
Sistema para combinar datos de posición con otros datos de información contextual (calendarios, correos electrónicos, listas de contactos, colores, temperatura, nivel de luz, etc.)
Una interfaz que ofrece a las aplicaciones reconocer estados de interés o situaciones susceptibles de originar una acción predicativa o de respuesta.
Actividades Sistema para asociar toda la información de contexto disponible, incluyendo la posición, a actividades. Las actividades son estados semánticos definidos por una determinada aplicación. Las actividades son diferentes del contexto en tanto en cuanto éstas son una interpretación del estado del mundo específica para una aplicación.
Una interfaz particular de aplicación tal y como un sistema de eventos activados por reglas que proporcionan diferentes escenarios de aplicación.
Intenciones Los deseos cognitivos de los usuarios que identifican lo que un sistema de computación ubicua debería hacer cuando una tarea está en progreso.
N/A
En la capa de Fusión se combinan los informes de medidas de tal forma que éstos produzcan el mejor estimador (belief) de posición. La capa de Fusión actúa en tres etapas diferentes, a saber: Gestión de Sensores, Modelado del Movimiento y Filtrado de Partículas. Cada una de estas etapas tiene diferentes objetivos (Figura 4.7):
• En la etapa de Gestión de Sensores se interroga al sensor y se valora el informe de localización que se envía a otras etapas. Se realiza un filtrado para evitar informes de localización desfasados, informes de GPS cuando no se visualiza ningún satélite, etc.
• El Modelo de Movimiento se aplica al estado interno del filtro de partículas. Se utiliza un modelo de movimiento dinámico que incluye velocidad y el rumbo provisto por los sensores, en caso de que esta información esté disponible. Si no lo está, se asume un proceso estocástico de movimiento de alguien que camina. • Etapa de fusión. Un filtro bayesiano se implementa a través de un filtro de
partículas, que usa los modelos probabilísticos definidos en la capa de medidas (Measurements).
Algunas singularidades de la arquitectura son:
• La representación interna de las medidas siguió la norma WGS-84 (World Geodetic System)52.
• La abstracción de la Location Stack no considera la posibilidad de gestionar el sistema de fusión para ahorrar energía en los dispositivos porque, como todos los modelos multicapa, proporciona separación de problemas pero dificulta la gestión entre niveles.
52
Latitud, longitud, altitud, velocidad con respecto al suelo, desviación respecto al norte magnético (rumbo- derrota…), arco elíptico o incertidumbre poligonal a lo largo del plano tangencial local de la tierra, incertidumbre por elevación, tipo de tecnología y marca temporal.
• • • ARQUITECTURA DE FUSIÓN MULTISENSOR PARA LA PROVISIÓN DE SERVICIOS CONTEXTUALES
Figura 4.7 Arquitectura Location Stack.
c) Fuentes de adquisición de datos.
Graumann et al. (2003) explican la implementación de un demostrador basado en el uso de tres tecnologías de posicionamiento -GPS, 802.11 y motes (de UC Berkeley)- que se integraron externamente en ordenadores tipo tablet. Las tecnologías consideradas proporcionan localización en interiores (WiFi y motes –éstos últimos se utilizaron para simular la información que podría dar un sensor Bluetooth y para simular el proceso de localización por proximidad) y exteriores (GPS). En el piloto se implementaron las tres capas inferiores de la Location Stack (Sensores, Medidas y Fusión).
d) Interacción con las aplicaciones.
La API que se encuentra sobre la capa de fusión ofrece informes de posición a la aplicación (timestamp, posición, incertidumbre). El filtro de partículas proporciona valores simples de posición y precisión derivados del radio medio de la forma geométrica creada por la distribución de las partículas, dando también un descriptor de forma geométrica extraído de la probabilidad total estimada.
La API proporciona información de posición bajo demanda, periódicamente o cuando nueva información está disponible, mediante tres tipos de informes diferentes: automáticos (generados siempre que la capa de fusión tiene información nueva), manuales (lanzado como respuesta a una petición) y periódicos (generados en un intervalo de tiempo definido por la aplicación).
CAPÍTULO 4 • • •
112
4.3.5 Location Service
Principales investigadores involucrados: Gregory D. Abowd, Agathe Battestini, Thomas O’Connell Instituciones: Georgia Institute of Technology
Fecha aproximada: 2002 URL:
a) Contexto y objetivos
Entre los autores del Location Service figura Gregory Abowd, que ya participó el desarrollo del Context Toolkit, por lo que este trabajo está influenciado por las experiencias con el sistema anterior.
El objetivo de este servicio es “proveer un medio uniforme y basado en condiciones geométricas, para manejar la amplia variedad de tecnologías de localización destinadas a seguir entidades de interés, al mismo tiempo que se proporciona una técnica simple y extensible para que los desarrolladores de aplicaciones puedan acceder a la información de localización de la forma más conveniente para sus necesidades”53 (Abowd et al., 2002). El Location Service persigue, de esta manera, la integración de múltiples tecnologías de localización en un marco que minimice los requisitos de conocimiento del programador de aplicaciones acerca de las tecnologías de adquisición de datos.