1

Middlewares para espaços ativos com ciência de contexto

Rafael Ramos de Oliveira

Departamento de Informática PUC - Rio

e0412089@grad.inf.puc-rio.br

Abstract. Developments in middleware for modern active spaces present a rea-

sonable variety of technologies in respect to the analysis and processing of con-

text. The present work tries to show as how three middlewares with context

science carry through the mentioned tasks and when possible makes a compara-

tive analysis between these systems.

Resumo. Desenvolvimentos em middleware para espaços ativos modernos a-

presentam uma variedade razoável de tecnologias em respeito à análise e proces-

samento de contexto. O presente trabalho busca mostrar como três middlewares

com ciência de contexto realizam as tarefas mencionadas e quando possível faz

uma análise comparativa entre estes sistemas.

Introdução

Atualmente, os modelos de interação que temos com um computador são extre-mamente limitados. Somente a partir de algumas variações de entradas de termi-nais, como teclados e mouses, podemos informar ao sistema processante as nossas escolhas (entradas explícitas), e este nos retorna também por um conjunto limitado de aparatos como monitores e impressoras (saídas explicitas). Tal limitação vem do cenário que a computação possuía em tempos anteriores, onde se focava no que o computador podia fazer e não no que nós podemos fazer. Hoje, porém, avanços na tecnologia nos auxiliam a mudar tal paradigma, pois as limitações computacionais presentes nos anos anteriores estão sendo contornadas: a eletrônica evolui na dire-ção de construir sistemas integrados cada vez menores; técnicas e algoritmos mais eficientes nos permitem analisar e interpretar sinais de voz e nos permite também produzi-las a partir de texto; sensores para aspectos físicos variados como tempera-tura, luminosidade e aceleração possuem um circuito eletrônico associado cada vez menor a ponto de tais censores serem praticamente imperceptíveis ao ambiente onde estão, etc.

Esse avanço vem tornando o computador cada vez mais integrado à vida coti-diana, e um modelo a que chamamos de “Computação Ubíqua” vem sendo vis-lumbrado há alguns anos. Os produtos gerados por tal ciência possuem um nível de integração elevado, onde não somente um nó processante é o responsável por entradas e saídas explicitas, e sim uma rede de nós colaborando e processando in-formações de saída explícitas e de entrada explícitas e implícitas. Ao ambiente onde essa infra-estrutura é montada dá-se o nome de “espaço ativo” (para exemplos mais concretos vide referência [10]), e ao novo conjunto de entradas implícitas dá-se o nome de “contexto”. Desenvolvimentos na parte de “ciência do contexto“ de um middleware ciente de contexto seriam então estudos visando facilitar o enten-dimento e a manipulação de contexto.

Este trabalho consiste no estudo de três middlewares em desenvolvimento com ciência de contexto (CoBrA, Campus e Gaia) e busca mostrar seus principais meca-nismos relacionados à análise e manipulação de contexto de forma comparativa.

2

1 CoBrA

O Context Broker Architecture é um middleware com uma ênfase maior no compar-tilhamento das informações de contexto e privacidade. A preocupação com privacida-de seria mais uma conseqüência do alto grau de compartilhamento desse sistema. Já a ênfase no compartilhamento faz com que esse middleware ganhe mais cenários “open door” do que outros sistemas que focam mais cenários locais como uma sala ou auditó-rio.

Fundamentando-se na Web Semântica para o compartilhamento de informações com fontes externas ao middleware, esse middleware modela contexto através de onto-logias escritas em OWL (Web Ontology Language) e com isso também constrói seu sis-tema de inferência. Até a versão 0.2, CoBrA declara 41 classes e 36 propriedades orga-nizadas em quatro categorias: conceitos para definir espaços físicos, para definir agen-tes (explicado mais tarde), conceitos para definir a localização de agentes e conceitos para definir as atividades de uma agente. Com tal ontologia definida, os elementos do sistema (agentes) podem se comunicar trocando informações dessa natureza.

É importante observar que a escolha no OWL faz com que os elementos do sistema se comuniquem de maneira relativamente fácil com elementos externos ao sistema, o que é uma boa característica para que o CoBrA seja facilmente integrado à Web Semân-tica.

Tabela 1: Lista completa das classes e propriedades da ontologia de CoBrA v0.2

Sua peça central para processamento e de fluxo de contexto é baseada em agentes de software, cada um responsável por uma entidade no sistema. (sejam dispositivos, pessoas, áreas, etc.) Na figura 1 segue uma visão geral da arquitetura, que tem como centro um tipo especial de agente de software: os Context Brokers (CB).

3

Figura 1: Visão geral do middleware CoBrA, com o Context Broker como centro de processamento

Os CBs são responsáveis por centralizar as informações de contexto de uma área, para que outros agentes interessados em tais informações de contexto saibam onde a-chá-las e/ou sejam achados pelos CBs, além disso, o CB também obtém as informações de agentes dispostos a fornecer contexto, como agentes de sensores ou agente pessoais disponibilizando as intenções da pessoa a ele responsável.

Os agentes interessados em obter o contexto de alguma área iriam até o CB e se inscreveriam, mas o que normalmente ocorre é que um CB obtém a informação de lo-calização de um agente de um sensor de localização sobre a posição de um agente pes-soal. O CB então informa aos agentes inscritos as informações de contexto da área a qual é responsável em função das políticas de privacidade.

A inferência de contexto é então realizada na maioria das vezes no próprio CB, pa-ra que o banco de informações disponíveis aos demais agentes seja maior e mais flexí-vel. Porém a inferência não é o forte do sistema, por não possuir técnicas mais comple-tas. Há somente dois níveis de inferência: uma utilizando lógica em cima das ontologi-as e outra utilizando heurísticas. Mesmo com essas duas técnicas, resultados para con-textos incertos (freqüentes em aplicações de ciência de contexto) não podem ser alcan-çados.

As políticas de privacidade são informadas pelos agentes que disponibilizam con-texto para os CBs e descrevem o que há permissão por parte dos agentes ou não. Por exemplo, considere uma sala de apresentações onde há somente três dispositivos: uma lâmpada, um detector de presença (indicando quantas pessoas tem na sala) e um proje-

4

tor. Em um momento inicial, os agentes dos três dispositivos entram em contato com o CB e então o enviam as suas políticas de privacidade. Depois o palestrante ingressa na sala com seu dispositivo móvel (este carregando o agente pessoal do palestrante, que guarda as informações de contexto dele). O agente do detector de presença informa ao CB a entrada de uma pessoa na sala. O CB então estabelece uma conexão com o agente pessoal do palestrante, e este envia de volta suas informações de contexto, ou seja, que é um agente de um palestrante, que o palestrante deseja dar uma aula de informática e que o palestrante deseja utilizar um projetor para uso de uma apresentação de slides. (o agente pessoal envia também suas informações de privacidade, porém para este e-xemplo não vem ao caso). O CB verifica então nas políticas de privacidade que obteve de outros agentes se há algo compatível (faz isso navegando pelas ontologias de con-texto de todos os agentes) e nota que o projetor permite que somente palestrantes po-dem ter acesso a ele. A partir de então, o agente pessoal do palestrante envia ao agente do projetor os slides de sua apresentação. Se outra pessoa, não palestrante entra na sa-la, o CB já não permite esta conexão, já que só palestrantes podem ter acesso ao proje-tor.

Figura 2: cenário do exemplo acima

É notável nesse sistema a centralidade nos CBs, o que cria um ponto de falha críti-ca, ou seja, se o CB tiver problemas em sua execução, a área por ele responsável ficará comprometida, apesar de isso poder ser contornado mudando a estrutura de CBs, co-mo por exemplo, criando uma rede P2P de CBs redundantes para uma mesma área.

Com as características que foram comentadas, os autores dividiram os focos de es-tudos nos CBs nas seguintes áreas:

5

CoBrA Ontology (COBRA-ONT):

Define o conjunto de ontologias que será usado pelos agentes do sistema para descrever e compartilhar informação de contexto. Como a linguagem escolhida pa-ra tal é a OWL, a inclusão das informações de contexto do middleware para Web2 será direta. Alguma inferência já é realizada a partir da ontologia corrente do sis-tema, mas somente inferência por indução (ex: Tiago carrega um celular que está na sala A, logo Tiago está na sala A).

Context Reasoning Engine (CoRE):

Sistema de inferência da arquitetura, dividida em duas camadas. A primeira camada faz o que for descrito acima: utilizando a ontologia criada chega-se a con-clusões por indução. O contexto obtido por inferência é então guardado na base de dados. Após isso, para ter mais informações, uma segunda camada é utilizada, des-ta vez usando heurísticas do sistema. Parte-se do princípio, por exemplo, que um palestrante carregará seu celular com sensor de posicionamento no momento da palestra, que já tem um horário definido, com isso, se o CB da sala de palestras ob-serva o celular do palestrante no momento da palestra, este infere que o palestrante está na sala e que está apresentando sua palestra. Essa forma rígida de inferência acaba por não refletir a realidade decentemente, portanto é foco dos autores melho-rarem essa parte do middleware.

Module for Privacy Protection (MoPP):

Esse módulo é justamente a parte do middleware que lida com as políticas de privacidade. Possui um conjunto de regras pré-estabelecidas primeiramente para manter o sentido do sistema (por exemplo, o palestrante não pode acessar o proje-tor se não estiver dentro da sala de apresentação, mesmo que seja no horário da a-presentação) e também as regras de controle de acesso em si (somente o palestrante acessa o projetor, os alunos não têm essa permissão).

Protótipos já foram implementados utilizando Jade, um framework escrito em Java cujo propósito é auxiliar o desenvolvimento de sistemas de software orientados a agen-tes. Testes de desempenho não estão disponíveis, porém é esperado que o sistema exija um bom desempenho em matéria de hardware, pois além de sua relativa complexida-de, há a carga de processamento da máquina virtual Java e do framework Jade.

resumo: esta arquitetura possui uma grande ênfase no compartilhamento de dados devido à ba-se forte em ontologias e o uso da OWL visando a Web Semântica, o que aumenta os cenários de escalabilidade. Sua arquitetura orientada a agentes possibilita uma maior extensibilidade, pois permite que agentes sejam implementados para qualquer tipo de entidade. Problemas surgem na parte de inferência de contexto, pois as técnicas utilizadas lidam somente com um grau de certeza alto, o que não reflete bem a realidade. Sua centralidade nos CBs também é uma desvan-tagem, porém dada a quantidade de elementos desse tipo que podem existir em uma área isso é contornado.

6

2 Campus

Este middleware apresenta uma arquitetura simples e sem muitas abstrações e modelos. Basicamente, o sistema consiste de uma coleção de sensores físicos, sensores de posicionamento, serviços da infra-estrutura (banco de dados e afins) e os aplicativos que usufruem as informações de contexto. Nesse sistema, os testes e desenvolvimentos são mais limitados ao contexto físico do que qualquer outro tipo de contexto.

Sua arquitetura, chamada de Distributed Rule Environment (DiRET), é baseada na manipulação de sistemas de regras independentes para se ter a informação de con-texto. Uma regra consiste em um trio de informações:

Eventos:

Lista de nomes que identificam uma regra, ou seja, se for desejado testar a vali-dade de uma regra, referencia-se essa regra por tal nome, e todas as regras que possuírem esse nome na lista de eventos serão testadas, ou até mesmo dispara-das sem a verificação da condição.

Condição:

Condição para que o evento seja disparado. É simplesmente um predicado boo-leano que se retornar verdadeiro terá um evento disparado, desempenhando então uma ação.

Ação:

Desempenha uma mudança no contexto do sistema e/ou notifica ao conjunto de componentes (aplicações) interessados no evento disparado (função de call-back).

Tendo então o interesse em alguma informação de contexto, o desenvolvedor da aplicação deve gerar um conjunto de regras independentes que mantém seu sistema informado do contexto desejado. Esse conjunto de regras é gerado a partir de uma lin-guagem própria, possuindo um compilador e um ambiente de execução. A aplicação está ligada aos disponibilizadores de contexto através dos componentes gerados pela compilação das regras. (Figura 3)

Figura 3: conjunto de regras compilado gera código que faz

a ponte entre os elementos que dispõem contexto da aplicação

7

Figura 4: Arquitetura DiRET do middleware Campus

O código gerado não utiliza diretamente os recursos dos sensores. Como pode ser visto na figura 4, existe um centralizador de informações de contexto, na forma de um espaço de tuplas. Este último é encarregado de manter certa transparência para a-cesso a informações de contexto. Dessa forma, qualquer fonte de contexto irá enviar suas informações para este nó principal.

Para a comunicação entre os conjuntos de regras independente, há ainda um sistema global de regras. Este disponibiliza a API necessária para comunicação entre esse conjunto de regras. O propósito principal é modularizar e organizar os códigos de regras, para assim, por exemplo, criarmos um arquivo de conjunto de regras para uma sala de aula, outro conjunto de regras para o corredor, outro para a entrada do prédio e mesmo assim mantermos a ligação entre estes componentes como desejado, podendo haver troca de contexto entre eles.

A inferência de contexto ocorre intrinsecamente pelo ambiente de execução, e é fundamentada na teoria de conjuntos fuzzy. Contexto é modelado em um conjunto fuzzy 𝜙𝑖 da seguinte forma:

𝜙𝑖 = 𝑒𝑖(𝑑𝑖 , 𝑞𝑖 , 𝑠𝑖)

Onde 𝑑𝑖 é um conjunto de dados que o sensor lida, 𝑞𝑖 é um vetor de qualidade de contexto (QoC) cuja forma pode ser, por exemplo, {precisão, resolução, etc.}, e por fim 𝑠𝑖 é justamente um vetor que define a situação atual do sensor, por exemplo, da forma {temperatura, localização}.

Na prática, 𝑑𝑖 e 𝑞𝑖 são parâmetros constantes a maioria das vezes, e mudam somente em função do uso do sensor (tempo normalmente degrada a qualidade do sensor, por exemplo) e de mudanças na infra-estrutura do ambiente em que o sensor está, ou seja, são valores que devem ser mapeados antes do uso. Já 𝑠𝑖 é o parâmetro de análise, portanto é normalmente variável.

Com esse conjunto fuzzy 𝜙𝑖 temos modelado então todo o universo de valores obtidos por um sensor de forma probabilística, e dessa forma o sistema pode criar re-gras do tipo: {EventoTeste, prob (nívelSonoro (sensorDaSalaAC) ==20dB) >0.75, callback ()}

8

Para tornar mais concreto, segue um exemplo: considere dois sensores de tem-peratura t1 e t2 (já calibrado, portanto 𝑑𝑖 e 𝑞𝑖 já estão definidos). Para definirmos o con-junto di basta dizer os limites, isto é, no caso da sala onde estão os sensores, a tempera-tura não descerá mais do que 0º e não será mais alta que 50º. Para definirmos o vetor de qualidade de contexto qi, fazemos uma rápida análise da qualidade de cada um. Supo-nha aqui que o sensor t2 é mais preciso que o sensor t1. Por enquanto, sem considerar a posição de ambos os sensores, observamos que o sensor t1 indica 19º e o sensor t2 indica 20º.

Com todas as constantes definidas (di e qi) e com os valores si dados pelo sensor (s1 = 19º e s2 = 20º) a função de associação 𝑒𝑖 (membership function) passa ser visuali-zada em ℝ2 da seguinte forma:

Da maneira que foi modelado o QoC dos dois sensores, suas funções de socie-

dade possuem esta forma. Podemos ver que como o sensor t1 é menos confiável, a ve-racidade do valor 19º está associada a uma probabilidade de 80%, além disso, a proba-bilidade de que o sensor na verdade esteja medindo 19,5º ou 18,5º é o mesmo 80%. Po-rém, a confiabilidade em t1 é tal que 18º e 20º são valores com 0% de chance de ocorrer. A mesma interpretação vale para t2: como a confiabilidade é maior, temos quase que 100% de chance de que a temperatura seja 20º.

Afinal, qual seria o melhor valor para inferirmos como temperatura da sala? Não podemos dizer que é ao do sensor mais confiável, pois a idéia de confiabilidade está ligada sempre a probabilidades, pode ser que a temperatura seja efetivamente 19º graus apesar de t2 ser mais confiável.

Os autores consideraram como valor representativo a ordenada do centróide

𝐶 = (𝑠𝑖 , 𝑔𝑟𝑎𝑑𝑒 ) da função resultante 𝐸(𝑑𝑖 , 𝑞𝑖 , 𝑠𝑖) =∨ (𝑒𝑖 (𝑑𝑖 , 𝑞𝑖 , 𝑠𝑖)) onde ∨ (𝑒𝑖) é a ope-ração de união definida para conjuntos fuzzy. (na verdade, é

𝐸 𝑥𝑗 = 𝑀𝑎𝑥 𝑒𝑖 𝑥𝑗 ∀ 𝑥𝑖 ∈ 𝑑𝑖). Para este exemplo, temos então como valor representa-

tivo T como segue (onde t é a variável „temp‟ do gráfico em º):

𝑇 = 𝑡𝑑𝑡

1.6𝑡−28.8

0

18.5

18+ 𝑡𝑑𝑡

0.8

0

19.5

18.5+ 𝑡𝑑𝑡

−1.6𝑡+32

0

19.75

19.5+ 𝑡𝑑𝑡

3.3 𝑡−65

0

19.8

19.75+ 𝑡𝑑𝑡

1

0

20.2

19.8+ 𝑡𝑑𝑡

−3.3 𝑡+68.3

0

20.5

20.2

𝐸 𝑡 𝑑𝑡20.5

18

O que resulta em aproximadamente T=19.78º, essa seria então a melhor apro-ximação da medição desses dois sensores. A base para os autores chegarem nessa con-

Gráfico 1: as duas funções de sociedade dos sensores t1 e t2, respectivamente, dado di, qi e si

9

clusão não é oferecida nas leituras, porém isso provavelmente se baseia na ponderação da probabilidade de cada ponto em função da quantidade de sensores.

A partir disso, podemos então ter um valor aproximado para n sensores com uma variedade de características, e quanto mais precisa é a modelagem da função de associação, mais preciso será o resultado. Esse exemplo partiu do princípio que os dois sensores encontram-se idealmente no mesmo lugar, o que obviamente é impossível. Deve-se levar então a localização em consideração também.

Como um exemplo de indução, podemos ter como o vetor si o par {temperatu-ra, localização}, e assim inferir uma temperatura ótima com os sensores dispostos em um ambiente físico com precisão. O gráfico 2 mostra a função de associação de t1 agora levando em consideração a localização, repare como agora devemos mapear di e qi pa-ra obtermos detalhes da distância. Ao marcar 19º, além de podermos concluir o mesmo que no exemplo anterior, ganhamos um no conjunto de inferências como, por exemplo, a probabilidade de certeza de estar 19º a 5 metros do sensor é de aproximadamente 70%. Temos 0% de certeza acima de 10 metros e abaixo de 0 metro por não estarmos mais tratando do espaço da sala em questão.

Gráfico 2: função de associação do sensor t1 levando em

consideração a posição real do sensor na sala

Gráfico 3: Função de associação da união das funções de associação de t1 e t2

10

Podemos executar novamente a operação de união para termos a função resul-

tante E (t, d). O gráfico 3 nos mostra tal união, é interessante observar que a qualidade

da inferência aumentou já que aumentamos a quantidade de sensores. Em alguns pon-

tos estamos mais próximos de 100% do que no gráfico 2 devido à região 10, onde se

encontra o sensor t2.

Para inferir a temperatura na região 6 quando temos t1=19º e t2=20º, por exem-

plo, obtemos a função de associação do gráfico 4. Podemos inferir com os mesmos cál-

culos do exemplo anterior o centróide dessa função, para assim obtermos 19.5º.

Gráfico 4: Corte do gráfico 3 na região 6.

O propósito desses cálculos é achar então um valor razoável para a inferência levando em consideração vários sensores. Quanto melhor a qualidade de contexto e mais forem os sensores, melhor será o resultado final.

Fica claro que, no entanto, há a necessidade de um conjunto de valor que pos-sua ordem e a imprecisão deve estar relacionada a isso para a manipulação com esta técnica. Esta é uma técnica muito boa para modelar incertezas e inferir condições em uma área onde não se encontra os sensores, porém para um contexto mais abstrato, como por exemplo, Alberto foi detectado por um sensor da sala de aula logo Alberto está na sala de aula, isso na verdade deve ser feito pela aplicação.

Concluímos então que esse middleware possui uma ênfase mais na ajuda das partes mais complexas na análise de contexto do que abrir cenários de extensibilidade, escalabilidade, segurança, etc. Ele se propõe somente facilitar e enriquecer a informa-ções vindas de sensores, principalmente os de contexto físico, e oferecer um mecanismo de regras com a qual a aplicação irá mais facilmente ser atualizada sobre as informa-ções de contexto.

resumo: Campus possui um modelo de simples abstrações, porém de estrutura complexa. O de-

senvolvedor tem que possuir conhecimento para aproveitar ao máximo a linguagem e as ferra-

mentas que esse middleware possui. O sistema de regras permite que aplicação tenha controle

das informações de contexto sem levar em consideração questões de privacidade, o que é uma

desvantagem. O sistema de inferência baseado em conjuntos fuzzy tem um embasamento ma-

temático que nos possibilita uma precisão muito boa na inferência de conjuntos que possuem

relação de ordem. Esse middleware pretende somente abstrair a obtenção e análise de contexto

e não possui maiores cenários.

11

3 Gaia

A parte de ciência de contexto na verdade é só uma das partes desse middleware. Ele envolve toda uma infra-estrutura de suporte à computação ubíqua, como canais de eventos e sistema de componentes de software. A arquitetura procura também possibi-litar a integração de aplicações de forma mais dinâmica oferecendo ferramentas para tal.

A arquitetura é fortemente baseada no paradigma de componentes de software e, portanto, tem sua base preparada para isso. O Component Management Core (CMC) provê uma infra-estrutura se software para carregar, instanciar e conectar componentes utilizando a arquitetura CORBA (Common Object Request Broker). Até presentes im-plementações o Middleware foi escrito em C++, o que garante um desempenho de ní-vel ótimo.

Figura 5: Visão geral do middleware Gaia

A parte de ciência de contexto do middleware é oferecida pelo conjunto de en-tidades definidas no serviço de contexto, que é o foco desse tópico.

No Gaia, contexto é modelado a partir de predicados estruturados em ontologi-as, diferentemente da arquitetura CoBrA que modela contexto diretamente em classes em ontologias. Os predicados são uma forma mais precisa e uniforme de representar contexto sem necessariamente estar ligado a uma linguagem. Um predicado é expresso da seguinte forma:

Tipo de Contexto (Informação de contexto)

Onde a informação de contexto é um vetor de palavras que produzem uma sin-taxe coerente, por exemplo:

Localização(Rafael,longe, casa do Rafael) Localização(Rafael,indo para, 511RDC)

Luz(Active Classroom ,50%) Escritório(Markus, 503)

Atividade(LabGrad, conversa de trabalho)

12

É importante observar duas heurísticas tiradas desse modelo de predicado, al-guns tipos de contexto têm uma natureza mais concreta, como luz e escritório, portanto são normalmente certos. Por outro lado, localização e atividade têm uma natureza mais abstrata, com isso são normalmente incertos. Predicados incertos têm a característica de serem mais complexos do que os certos no momento de inferir. Para se ter então como modelar tais predicados computacionalmente, os predicados incertos são relacionados a valores entre 0 e 1, e os certos passam a ser um caso específico dos incertos, onde o valor relacionado é 1. Tal como no Campus, a modelagem probabilística passa existir no sistema para podermos executar inferência, está explicada mais tarde.

Dado o tipo de contexto, pode ser feita uma amarração com os tipos de infor-mação. Assim quando predicados forem usados em rotinas de inferência, podemos re-duzir o conjunto de informações para só as que fizerem sentido sintático. Por exemplo, podemos amarrar o tipo de contexto „localização‟ para ser o vetor (<Sujeito>, <Advér-bio>,<Objeto>), então dos exemplos dados acima só o primeiro passaria na verificação de tipos do sistema. Modelar as ontologias torna-se mais fácil também com essa verifi-cação de tipos.

A infra-estrutura de software que lida com contexto e dividida em várias enti-dades, porém todas elas possuem idéias semelhantes à de outros middlewares, somen-te com nomes e detalhes diferentes. Tais entidades são:

Context Providers: Componentes que disponibilizam contexto como, por exemplo, de sensores. Es-tes componentes permitem que outros componentes (Context Consumers ou Context Synthesizers) conectem-se a ele para obter suas informações. Há tam-bém a possibilidade de utilizar canais de eventos providos pela arquitetura. Dessa forma, consumidores se registram no componente em questão e este os atualiza quando há uma mudança em seu estado. Muitas vezes, quando há a característica de incerteza nos dados gerenciados por eles, os Context Providers associam neles mesmos o valor probabilístico da informação.

Context Synthesizers: Componentes que tem o papel de mediadores entre os Context Providers e os Context Consumers. Todo o sistema de inferência de Gaia está implementado nesses componentes. Os Context Consumers com isso possuem duas opções, ou acessar diretamente os Context Providers obtendo um conjunto de informações mais “cru”, ou então ir aos Context Synthesizers, onde podem obter informa-ções mais precisas e outras que só podem ser descobertas por inferência. O se-gundo método seria o recomendado, porém em nível de desempenho ou então de simplicidade (caso o Context Consumer só deseje um simples valor que po-de ser dado diretamente pelo Context Provider), o primeiro método seria o in-dicado.

Context Consumers: Estes componentes são a porta de entrada das aplicações ao middleware Gaia.

Context Provider Lookup Service: Serviço no qual os Context Providers utilizam para disponibilizar informações do tipo de informação que eles disponibilizam. Através desse serviço, os de-mais componentes do sistema sabem com que componente se comunicar para no caso, por exemplo, que um Context Synthesizer deseje obter informações de luminosidade.

13

Context History Service: Serviço de log de informações de contexto para que os demais componentes possam a recorrer a acontecimentos do passado se desejarem.

Ontology Server: Serviço que centraliza toda ontologia de uma sala ativa, para facilitar a explora-ção de contexto e recursos da sala a partir dela.

Cada espaço ativo possui vários Context Providers, Context Synthesizer e Con-text Consumers, porém somente um Context Provider Lookup Service, Context His-tory Service e Ontology Server. Segue na figura 6 a idéia deste serviço em um espaço ativo qualquer.

Figura 6: Modelo do serviço de contexto do middleware Gaia

Para a inferência e manipulação de incertezas, Gaia utiliza várias técnicas de es-

timação e cálculos probabilísticos não tanto diferentes de outras arquiteturas: indução através de ontologias é feito como no middleware CoBrA; não diretamente conjuntos fuzzy, mas sim manipula incertezas através da lógica fuzzy, teoria derivada do estudo de conjuntos fuzzy, utilizando Prolog ou HiLog (modelo mais simples que o do mid-dleware Campus), etc.

O que diferencia Gaia nas técnicas de inferência é o uso de redes Bayesianas.

Redes Bayesianas são na verdade grafos dirigidos acíclicos onde cada nó possui uma variável randômica e os arcos codificam dependências relativas entre os nós. A-lém disso, a probabilidade da intercessão de seus nós deve poder ser dada pelo produ-to das probabilidades condicionais como:

Onde xi é um nó e parents(xi) são os pais desse nó. E pai possui a definição pa-drão de grafos dirigidos, ou seja, de onde vem um arco. Se o nó não possuir pai, sua probabilidade condicional e dada por ele mesmo.

14

Para exemplificar, considere a seguinte situação:

Há dois motivos pelos quais a grama de um jardim poderia estar molhada: o O “sprinkler” está ligado o Está chovendo

Suponha também que a chuva influência no uso do “sprinkler”, ou seja, é difícil que este esteja ligado se estiver chovendo. Dado isso podemos modelar uma rede ba-yesiana da seguinte forma: (as probabilidades são um exemplo também)

Repare então que com este modelo podemos obter informações do tipo: qual a probabilidade de estar chovendo dado que a grama está molhada? A resposta é dada pela probabilidade condicional a seguir:

Onde R indica chuva, G indica grama molhada, S indica sprinkler ligado, e cada variável dessa pode admitir dois valores: verdade (T) ou falso (F).

Com uma rede Bayesiana montada, podemos inferir algum acontecimento dado a probabilidade de eventos aprendidos por experiência. Como no exemplo dado acima, considere agora um exemplo mais específico aos cenários propostos por Gaia:

Figura 7: rede Bayesiana usada na inferência de atividade em uma sala

15

Primeiramente, a rede deve ser treinada para obter uma “precisão razoável” (lembrando que como estamos lidando com cálculos probabilísticos, precisão seria en-tão um número a se basear...). Por exemplo, definimos um período de tempo qualquer, porém satisfatório, para analisarmos as atividades da sala e quanto tempo tais rotinas costumam durar. No final desse tempo estipulado, temos então a probabilidade de um

evento ocorrer sendo o valor 𝑡𝑒𝑚𝑝𝑜 𝑑𝑎 𝑎𝑡𝑖𝑣𝑖𝑑𝑎𝑑𝑒

𝑡𝑒𝑚𝑝𝑜 𝑡𝑜𝑡𝑎𝑙 levando em consideração ocorrer ou não

os eventos pais (a probabilidade de não ocorrer é obviamente o complemento desse valor). Esses valores serão os inicias para o sistema de inferência, porém o ideal é que haja um componente que continue analisando tais acontecimentos para a rede estar sempre atualizada adequadamente.

Agora sim, podemos obter incertezas do tipo: qual a probabilidade do MP3 Player estar ligado dado que a sala está em atividade, ou então qual a probabilidade de uma apresentação em PPT esteja acontecendo dada a atividade na sala.

Esses cálculos são geralmente massivos para redes grandes, portanto é inviável como centro de um sistema de inferência, porém seus resultados são interessantes e quando usados em união com outras técnicas (o que o Gaia faz) produz bons resulta-dos.

resumo: Gaia é mais do que um middleware sensível a contexto, ele possui toda uma infra-estrutura para o auxílio no desenvolvimento de aplicações para espaços ativos. Implementado usando a tecnologia CORBA para componentes de software e a linguagem C++, ele possui um bom desempenho e cenários de escalabilidade, apesar de ter sido pensado para ambientes mais limitados e não para ambientes abertos como o CoBrA. Utiliza várias técnicas de inferência co-nhecidas e usadas por outros middlewares, porém adiciona a esse conjunto de ferramentas as redes Bayesianas, que apesar de exigirem uma grande carga de processamento, são úteis como técnicas auxiliares.

16

Encerramento

Três middlewares com ciência de contexto foram aqui apresentados. Os três apre-sentam tanto características semelhantes quanto disjuntas, devido principalmente a grande quantidade de tecnologias envolvidas no desenvolvimento de middlewares dessa natureza.

Os principais problemas dessa área são como modelar e inferir contexto. Aqui foi apresentado como cada uma dessas três arquiteturas o fazem. A indicação de qual con-junto de técnicas é o melhor não pode ser feita, dado que escolha que cada middleware escolheu admite frentes diferentes.

CoBrA possui uma ênfase na Web Semântica e espaços quaisquer.

Campus pretende facilitar a obtenção e análise de contexto sem focar em um ambiente.

Gaia busca criar um espaço ativo específico com tecnologias que garantem ro-bustez.

Apesar do que já foi desenvolvido até hoje na área de ciência de contexto, muitas características ainda precisam ser melhoradas para podermos ter uma possível conver-gência em um modelo ótimo e único, algo que hoje ainda não temos previsão de quan-do vai ocorrer e se vai ocorrer.

Agradecimentos

Agradeço a Luis Valente pelas sugestões e revisão.

17

Referências

[1] Campbell, R. H., Al-Muhtadi, J., Ranganathan, A., Reasoning about Uncertain Con-texts in Pervasive Computing Environments. Pervasive Computing, p. 62-70, jun. 2004.

[2] Román, M., Hess, C., Cerqueira, R., Ranganathan, A., Campbell, R. H.,Nahrstedt, K., A Middleware Infrastructure for Active Spaces. Pervasive Computing, p. 74-83, out./dez. 2002.

[3] Hisazumi, K., Nakanishi, T., Kitasuka, T., Fukuda, A., CAMPUS: A Context-Aware Middleware

[4] Hisazumi, K., Nakanishi, T., Kitasuka, T., Fukuda, A., CAMPUS, A Lightweight and Dependability Oriented Context-Aware Middleware

[5] Zadeh, L. A., Fuzzy Sets

[6] Chen, H., Finin, T.,Joshi, A., A Context Broker for Building Smart Meeting Rooms

[7] Chen, H., Finin, T.,Joshi, A., Using OWL in a Pervasive Computing Broker

[8] Wikipedia. 2007. Fuzzy set. Disponível em http://en.wikipedia.org/wiki/Fuzzy_set

[9] Wikipedia. 2007. Bayesian network. Disponível em http://en.wikipedia.org/wiki/Bayesian_network

[10] Weiser, M., The Computer for the 21st Century. Scientific American, Disponível em http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html