de incertidumbre
Consciencia del Contexto Orientado a Servicios (SOCAM)
Esta arquitectura fue creada por Gu et al. (2004a, 2004b) con la finalidad de facilitar el desarrollo rápido de servicios conscientes del contexto. Los autores denominaron a esta arquitectura SOCAM (Service-Oriented Context-Aware Middleware).
Primeramente los autores crearon un modelo del contexto basado en ontologías y escrito en el lenguaje OWL (Lenguaje de ontologías para Web, Web Ontology Language). Las ontologías permiten establecer un vocabulario para la representación y el intercambio de contexto en dominios computacionales, incluyendo definiciones de los conceptos básicos y las relaciones entre ellos dentro del dominio de la aplicación que puedan ser interpretadas por la computadora. Para representar el contexto, los autores utilizan un modelo de predicados de primer orden de la forma Predicado(sujeto, valor). Donde el sujeto puede ser personas, lugares u objetos; El valor son el conjunto de opciones que el sujeto puede tener como: en un cuarto, abierto, cerrado, vacío, etc. Los predicados pueden ser localizado en, tiene un estatus de, entre otros. Por ejemplo, Location(John, bathroom) significa que John se encuentra localizado en el baño, Temperature(kitchen, 60) la temperatura en la cocina es de 60º C.
Con la finalidad de permitir la reutilización de las definiciones del contexto, se diseñaron las ontologías en dos niveles jerárquicos. En el primer nivel se presentan los dominios computacionales específicos, divididos en varios subdominios, por ejemplo, dominio del hogar, dominio de oficina, dominio de vehículo, etc. En un nivel superior, se definió una ontología que describe los conceptos generales, los cuales están ligados con la ontología del contexto del nivel inferior, como se muestra en la Figura 14. La ontología del dominio específico puede ser dinámicamente adaptada a la ontología general de la parte superior cuando el dominio del contexto cambia. Por ejemplo, cuando un usuario sale de su casa y se sube a manejar su automóvil, el dominio del hogar cambia a un dominio de automóvil.
Figura 14. Modelo de ontología basado en una jerarquía de dos niveles. (Tomada de Gu et al. (2004a)).
Basado en el modelo del contexto descrito anteriormente, los autores diseñaron la arquitectura mostrada en la Figura 15. La arquitectura convierte el contexto adquirido desde el espacio físico a un espacio semántico, en donde puede ser fácilmente compartido y accedido por los servicios conscientes del contexto. La arquitectura se encuentra integrada por diferentes módulos que administran el contexto: los proveedores, los intérpretes, la base de datos, los servicios de localización y los servicios conscientes del contexto (aplicaciones).
Figura 15. Arquitectura SOCAM. (Tomada de Gu et al. (2004b)).
A continuación describiremos cada uno de los elementos que integran la arquitectura SOCAM:
Proveedores de contexto (Context Provider). Separan la obtención del contexto de bajo nivel de la manipulación del de alto nivel. Cada proveedor de contexto debe ser registrado como un servicio en el módulo de localización de servicios, y se dividen en internos y externos. Los proveedores externos obtienen el contexto de fuentes externas, por ejemplo, la información del clima obtenida de un servidor que distribuye esta información, o la información del tráfico generada por un servidor de tránsito local. Los proveedores internos adquieren el contexto directamente de los sensores existentes dentro del dominio de la aplicación, por ejemplo, en un dominio de vehículo, un proveedor de localización puede obtener la ubicación de un receptor GPS instalado en el auto del usuario.
Intérpretes del contexto (Context Interpreter). Se encargan de transformar el contexto de bajo nivel a alto nivel. También actúan como proveedores ya que generan contexto de alto nivel que es utilizado por los servicios conscientes del contexto. Consiste en un motor de
razonamiento y en una base de conocimientos del contexto. El motor de razonamiento tiene la funcionalidad de deducir el contexto, resolver sus conflictos y mantener la consistencia de la base de conocimientos. En los intérpretes es posible incorporar diferentes lógicas de razonamiento para deducir el contexto de alto nivel. Los autores han implementado el razonamiento basado en reglas y el razonamiento RDFS.
La base de datos del contexto (Context Database). Provee de una serie de métodos que permiten agregar, modificar o eliminar el contexto y contiene las ontologías del subdominio de la aplicación y sus instancias. Estas instancias pueden ser contexto definido o percibido, el primero de ellos es especificado por los usuarios de manera directa y se mantiene con poco cambio durante la ejecución del sistema, por ejemplo, el perfil del usuario; el segundo corresponde al adquirido por los proveedores del contexto, el cual por lo regular es dinámico y cambia constantemente durante la ejecución del sistema. Las ontologías y las instancias del contexto definido son cargadas durante la inicialización del sistema; las instancias del contexto percibido se cargan en tiempo de ejecución.
Servicio de localización de servicios (Service Locating Service). Permite a los usuarios, agentes y aplicaciones localizar diferentes proveedores de contexto. El servicio puede localizar proveedores internos y externos. Por ejemplo, un servicio que proporciona el clima puede estar localizado físicamente en una red externa. El servicio de localización puede rastrear y adaptarse de manera dinámica a los cambios en los proveedores del contexto, por ejemplo, un proveedor interno cambia el tipo de contexto generado debido a modificaciones en su estructura física al añadir o eliminar algún sensor, el servicio de localización reconoce estos cambios y adapta su información para mantener la integridad de la información proporcionada. Los proveedores del contexto registran en el servicio de localización, el tipo y el formato que pueden proporcionar. Para ello, utilizan expresiones en el lenguaje OWL.
Una aplicación que quiera encontrar algún contexto ejecuta una consulta al servicio de localización, por ejemplo para conocer la ubicación de “MiCarro” se ejecuta “socam:locatedIn(MiCarro ¿x)”. El servicio de localización carga la ontología del contexto
almacenada en la base de datos y las instancias de contexto anunciadas por diferentes proveedores, y posteriormente aplica una comparación semántica para buscar a los proveedores que proporcionan este contexto; en caso de encontrarlo, se transfiere la referencia del proveedor a la aplicación.
Los servicios conscientes del contexto. Son las aplicaciones y servicios que hacen uso del contexto y adaptan su comportamiento de acuerdo al contexto actual. Estas aplicaciones utilizan la localización de servicios para buscar los proveedores registrados que proporcionan el contexto que necesitan. Las consultas son de manera directa al proveedor o se mantienen a la escucha de los eventos generados por el mismo proveedor.
Los componentes de SOCAM están diseñados como componentes de servicios independientes los cuales pueden estar distribuidos e interactuar unos con otros.
Introducción del mecanismo de administración de incertidumbre
En la arquitectura SOCAM se puede observar una separación entre la adquisición y el procesamiento del contexto. Lo primero es realizado por los proveedores de contexto (Context Provider) y lo segundo se realiza en los intérpretes del contexto (Context Interpreter). Esta característica de la arquitectura permite la integración con nuestra metodología para la administración de la incertidumbre. De tal manera que es posible incluir en la arquitectura original elementos que permitan la administración de incertidumbre en las aplicaciones conscientes del contexto que sean creadas con esta arquitectura. Los elementos pueden ser colocados en los lugares señalados en la Figura 16.
Figura 16. Arquitectura SOCAM con manejo de incertidumbre. (Basada en Gu et al. (2004b)).
Como se describió en los párrafos anteriores los elementos de la arquitectura que se encuentran relacionados con la fuente de generación del contexto son los proveedores del contexto. Ellos son responsables de adquirir el contexto de bajo nivel y transferirlo a los intérpretes del contexto. Por lo tanto al hacer la relación con nuestra metodología es en estos elementos en donde se pueden incluir los mecanismos de administración de incertidumbre que atienden los riesgos de incertidumbre original.
Por otro lado tenemos que las capacidades de consciencia del contexto con las que cuenta la aplicación creado con la arquitectura SOCAM son proporcionadas por los intérpretes del contexto, en donde se incluye el motor de razonamiento del contexto. Por esta razón los intérpretes del contexto son el elemento indicado en donde se puede incluir los mecanismos de administración de incertidumbre creados para tratar los problemas generados por la incertidumbre derivada.
Arquitectura “The Context Toolkit”
Esta arquitectura fue creada por Dey et al. (2001) con la finalidad de definir una metodología para la creación de aplicaciones conscientes del contexto. La metodología es una referencia completa que incluye la definición formal de contexto, las categorías de la información contextual, la caracterización del comportamiento de las aplicaciones conscientes del contexto, las herramientas y pautas para el rápido desarrollo de aplicaciones conscientes del contexto (Dey et al., 2001).
Primeramente los autores establecen la definición de contexto: “es cualquier información que puede ser utilizada para caracterizar la situación de una entidad (persona, lugar, u objeto) que es considerada relevante para la interacción entre un usuario y una aplicación” (Dey, 2001). Esta es la definición más ampliamente utilizada en ubicomp. Ellos establecen tres categorías de contexto: Los lugares, que son regiones espacio geográfico, tales como, cuartos, oficinas, edificios, calles, etc.; Las Personas, las cuales pueden ser un solo individuo o grupos de personas reunidos en un solo lugar o distribuidos geográficamente; Las cosas, que representan objetos físicos y artefactos del mundo real o componentes de software que pertenecen al mundo digital.
Al mismo tiempo definieron cuatro características principales que debe tener el contexto: La identidad, la localización, el estatus (o actividad) y el tiempo. La identidad se refiere a la habilidad de asignar un identificador único a una entidad. La localización es más que solo una coordenada en 2-D, debe incluir orientación y elevación, así como cualquier información que pueda ser utilizada para deducir la relación espacial entre las entidades, por ejemplo, proximidad. El estatus o la actividad, representa características intrínsecas de la entidad, por ejemplo, para un lugar, puede ser la temperatura actual, la luz ambiental o nivel de ruido; para una persona, puede referirse a factores fisiológicos tales como signos vitales, cansancio o la actividad que está realizando la persona, leer o hablar; del mismo modo para un grupo de personas, el estatus es una característica del grupo como su entusiasmo, estado de ánimo general o una descripción de su actividad, como escuchar una conferencia o tener una reunión; para componentes de software, el estatus básicamente hace
referencia a cualquier atributo del componente que puede ser consultado, por ejemplo, el tiempo de actividad o carga de un CPU, la existencia de archivos o el estado de un componente de software como una solicitud. Finalmente, el tiempo es la información que ayuda a caracterizar una situación; permite aprovechar la riqueza y el valor de la información histórica; es utilizado para indicar un instante o período durante el cual alguna información contextual es válida o pertinente.
También los autores señalan que para realizar una administración eficiente del contexto, desde una perspectiva del diseño de las aplicaciones, se deben cumplir los siguientes requerimientos: separación de las fuentes de adquisición, interpretación eficiente, canales de comunicación de datos transparentes y distribuidos, disponibilidad del contexto, su almacenamiento y el descubrimiento de recursos.
Ellos establecen como principio fundamental de diseño la separación entre la adquisición y la utilización del contexto. Afirman que este principio permite a las aplicaciones conscientes del contexto controlar los procesos de adquisición, colección y administración de manera totalmente independiente de la aplicación, facilitando la escalabilidad, reutilización y robustez de las aplicaciones.
Con base en este principio de diseño y en los requerimientos para la administración del contexto, los autores crearon la arquitectura mostrada en la Figura7, la cual definieron como “The Context Toolkit”. Esta arquitectura tiene dos capas, la primera se refiere a la
arquitectura del contexto, que se centra en tres componentes principales: el mecanismo de contexto que es el encargado de percibir el contexto de los sensores, el agregador que recopila el contexto relacionado con una entidad y el intérprete que realiza conversiones entre diferentes tipos de contexto. En la segunda capa se encuentran las aplicaciones que hacen uso del contexto.
Figura 17. Arquitectura “The Context Toolkit” (Tomada de Dey y Mankoff (2005)).
A continuación mencionaremos cada uno de los elementos que integran la arquitectura y una breve descripción de los mismos:
Los mecanismos de contexto (Context Widget), son los responsables de la adquisición del contexto, se encuentran relacionados directamente con la fuente de generación del elemento contextual. Realizan la encapsulación del contexto y facilitan su utilización por las aplicaciones de manera simultánea. En ellos se almacena información detallada del tipo, la precisión y la exactitud del sensor que se utiliza, y del tipo de dato que es percibido. También permiten mantener el control sobre la configuración de los sensores utilizados para la percepción del contexto. Algunos ejemplos son un mecanismo que determina quien está presente en un lugar particular, un mecanismo de temperatura que obtiene la temperatura de un lugar, un mecanismo de nivel de sonido que percibe el nivel de ruido en un espacio determinado y un mecanismo de actividad que establece la actividad que se encuentra realizando un individuo en particular.
Los intérpretes del contexto (Context Interpreter), son los responsables de elevar la abstracción del contexto, por lo regular convierten contexto de bajo nivel en contexto de alto nivel que es utilizado por las aplicaciones. Por ejemplo, la localización obtenida de un
sensor en coordenadas geográficas puede ser transformada a una localización de más alto nivel como podría ser el nombre de una calle. También pueden utilizar múltiples piezas de contexto para inferir contexto de alto nivel, por ejemplo, si un cuarto contiene varios ocupantes y el nivel de ruido en el lugar es alto, el intérprete puede combinar estas dos piezas de contexto y generar una nueva que represente la realización de una reunión de trabajo en ese cuarto. Un intérprete generalmente toma contexto de uno o múltiples fuentes y produce una nueva pieza. Los intérpretes pueden ser utilizados por varias aplicaciones de manera simultánea.
Los Agregadores (Aggregator), se refiere a la recolección en un repositorio común de múltiples piezas de información contextual que se encuentran lógicamente relacionadas. La necesidad de recolectar el contexto en un solo lugar, obedece a que por naturaleza la información contextual se encuentra distribuida en diferentes sitios, esto debido a que por lo regular el contexto es generado por sensores repartidos en todo el entorno del usuario. Un agregador recopila información relevante para la aplicación, la cual se encuentra lógicamente relacionada y la hace disponible a través de un simple componente de software. Además los agregadores simplifican la inferencia de información contextual de alto nivel, debido a que las piezas del contexto necesarias para realizar la inferencia se encuentran disponibles en un solo lugar. Por ejemplo, una aplicación puede adaptar su comportamiento cuando se reúnan las siguientes condiciones de contexto: un individuo está feliz, se encuentra en la cocina y está cocinando la cena; si no existieran los agregadores, la aplicación tendría que combinar suscripciones y solicitudes a diferentes mecanismos de contexto para determinar cuándo esas condiciones se cumplan. Esta situación puede ser muy compleja y difícil de modificar si las condiciones de contexto cambian. Al existir un agregador que reúna el contexto relacionado para cumplir con esa condición, la aplicación únicamente tiene que comunicarse con este componente para conocer esa información. En este sentido el agregador es un mecanismo de contexto pero que genera exclusivamente contexto de alto nivel.
Las aplicaciones (Applications), son los consumidores del contexto. Se refiere a todas las aplicaciones conscientes del contexto. En las aplicaciones es en donde se implementa la
utilización del contexto. En esta capa se define el comportamiento de la aplicación de acuerdo al contexto del usuario.
Introducción del mecanismo de administración de incertidumbre
Como se mencionó en los párrafos anteriores, Dey et al. (2001) autores de esta arquitectura establecen una clara separación entre la adquisición del contexto y la utilización del mismo. Esta característica se encuentra muy relacionada con nuestra propuesta para la administración de incertidumbre, en donde señalamos una separación entre los riesgos de incertidumbre original y riesgos de incertidumbre derivada. Tomando en consideración estas similitudes la arquitectura original puede modificarse para incluir los mecanismos administradores de incertidumbre como se muestra en la Figura 18.
Figura 18. Arquitectura “The Context Toolkit” con manejo de incertidumbre (Basada en Dey y Mankoff (2005)).
Como podemos observar en la Figura anterior, existen dos elementos de la arquitectura que se encuentran relacionados con la fuente de generación del contexto: los widget, que crean contexto de bajo nivel y los agregadores, que generan contexto de alto nivel. En este
sentido, al hacer la analogía con nuestra metodología para administración de incertidumbre, es aquí en donde se pueden incluir los mecanismos que sean creados para tratar los riesgos de incertidumbre original.
Ahora bien, como se mencionó anteriormente, en la capa de la arquitectura que los autores denominaron “de aplicación” es el lugar en donde se establece la manera en que el contexto es utilizado por la aplicación consciente del contexto y los mecanismos que le proporcionan la consciencia del contexto a la aplicación. En este sentido, de acuerdo a nuestra metodología, en este elemento de la arquitectura es el lugar en donde se deben incluir, en caso de existir, los mecanismos creados para atender los riesgos de incertidumbre derivada. Recordemos que una de las sugerencias de diseño establecidas en nuestra metodología es evitar al máximo incrementar la complejidad de las aplicaciones, por lo que el creador de la aplicación debe analizar la mejor manera de incluir los mecanismos en la aplicación respetando lo establecido por la arquitectura utilizada.
Arquitectura Gaia
El proyecto Gaia consiste en el diseño e implementación de un meta sistema operativo que permita la administración de los recursos contenidos en un espacio activo. El sistema Gaia provee las funcionalidades de un sistema operativo tradicional a espacios físicos como cuartos, aulas, oficinas, casas, edificios y aeropuertos (Gaia, 2009; Ranganathan y Campbell, 2003a, 2003b; Román et al., 2002). Al mismo tiempo el sistema Gaia provee inteligencia a estos espacios al incluir capacidades de administración de contexto, consciencia de localización, utilización de dispositivos móviles y dispositivos controladores (como seguros de puertas, ventanas, controles de luz, de volumen o de temperatura) con la finalidad de apoyar al usuario que se encuentra en dentro de estos espacios. La arquitectura Gaia es la mostrada en la Figura 19.
Figura 19. Arquitectura del meta sistema operativo Gaia (Tomada de Gaia (2009)).
El sistema operativo Gaia convierte un espacio físico y todos los dispositivos de cómputo ubicuo contenidos dentro de él en un sistema computacional programable. Ofrece servicios de administración y programación del espacio. Gaia contiene un núcleo central de servicios, en donde se incluyen activación y ejecución de eventos, descubrimiento y localización de entidades (dispositivos, usuarios y servicios). El núcleo central de servicios inicia junto con la infraestructura Gaia a través de un protocolo de arranque ligero. Gaia implementa el cómputo distribuido a través de CORBA (Common Object Requesting Broker Architecture). En Gaia todas las tareas y servicios que permiten el funcionamiento del espacio activo son realizados por agentes. Existen agentes asociados a dispositivos que pueden ser parte del medio ambiente. Cada usuario es asociado a un agente que mantiene su información personal y actúan como intermediario en una gran variedad de operaciones. También existen agentes de aplicaciones que ayudan a los usuarios a realizar diversas tareas dentro del espacio activo.