Implementação de uma aplicação ubíqua no Context Toolkit

Implementação de uma aplicação ubíqua no Context

Toolkit: problemas e uma proposta de extensão

Bianor G. de Lima Neto1, Cláudio Trindade2, Gustavo Laires1, Frederico Lopes3,

Carlos Eduardo da Silva³, Nelio Cacho2

1Departamento de Engenharia Elétrica (DEE)

2Departamento de Informática e Matemática Aplicada (DIMap)

3Instituto Metrópole Digital (IMD)

Universidade Federal do Rio Grande do Norte (UFRN)

Caixa Postal 1524 ± 59078-970 ± Natal ± RN ± Brasil

{10.bianor,claudiotrintade.cc, neliocacho}@gmail.com,

[email protected], {fred,kaduardo}@imd.ufrn.br

Resumo. A Computação ubíqua é um paradigma computacional que aproxima

a realidade natural de uma sociedade à interação impercetível e harmoniosa

com os dispositivos computacionais. A dinamicidade do contexto de execução

é uma importante característica das aplicações ubíquas. Este artigo apresenta

uma aplicação construída utilizando o Context Toolkit. Nesta aplicação, foi

criado um protótipo para coleta, envio e processamento das informações do

ambiente para tratamento através do referido framework. Além disso, o

artigo descreve várias limitações do framework citado e, finalmente, sugere

uma extensão para tal framework.

��,QWURGXomR

O termo Computação Ubíqua foi usado pela primeira vez por Mark Weiser (Weiser, M.

1991). Esse paradigma computacional aproxima a realidade natural de uma sociedade à

interação imperceptível e harmoniosa com os dispositivos computacionais. Esse

conceito passa o real sentido da palavra, ubíqua, que tem o significado de algo que está

ao mesmo tempo e em toda a parte. Na época em que Weiser propôs o termo, várias

tecnologias atuais ainda não estavam disponíveis para a sociedade, como por exemplo,

os dispositivos móveis, tecnologias de comunicação sem fio, plataforma Arduino1, entre

outras diversas tecnologias atuais. Assim, naquela época a construção de aplicações

ubíquas era, de certo modo, vista como futurista. Já com as tecnologias atuais, essas

aplicações começaram a se popularizar no dia-a-dia das pessoas. Essa popularização

resultou no surgimento de vários outros termos que, direta ou indiretamente, remete aos

conceitos da computação ubíqua: Ambientes Inteligentes (Cook D. J. E Sajal, K., 2007),

Internet das Coisas (França, T.; Pires, P.; et al., 2011), entre outros.

Uma característica importante das aplicações ubíquas é a dinamicidade do

contexto de execução das aplicações, onde contexto SRGH�VHU�GHILQLGR�FRPR�³TXDOTuer

informação que pode ser usada para caracterizar a situação de uma entidade (pessoa,

local ou objeto) a qual é considerada relevante para a interação entre o usuário e a

1 www.arduino.cc

Anais da VII Escola de Computação e suas Aplicações - EPOCA 2014

159

DSOLFDomR��LQFOXLQGR�R�SUySULR�XVXiULR�H�D�DSOLFDomR´�(Dey, A., Abowd, G. et al., 2001).

Isso porque em tal paradigma os dispositivos podem ser móveis, entrando e saindo

frequentemente da área de abrangência de uma dada rede; conexões sem fio são sujeitas

a interrupções e oscilações da intensidade do sinal transmitido; parâmetros físicos como

temperatura e luminosidade podem mudar com alta frequência; bem como as atividades,

o humor e as necessidades dos usuários podem mudar com o decorrer do tempo.

Portanto, aplicações executadas em ambientes ubíquos precisam lidar com

características dinâmicas e, de preferência, explorar tais características para prover

serviços de melhor qualidade e com maior valor agregado para o usuário final. Dessa

forma, dois importantes requisitos das aplicações ubíquas são (i) a capacidade de

conhecer o contexto passado e atual ao redor do usuário (ciência de contexto) e (ii)

capacidade de adaptar seu comportamento de acordo com as mudanças no contexto

(sensível ao contexto). Assim, dizemos que as aplicações ubíquas, em geral, são

sensíveis ao contexto. Assim, aplicações sensíveis ao contexto são aquelas que

conhecem e se adaptam de acordo com informações sobre o usuário e o ambiente como,

por exemplo, a localização do usuário, suas atividades, ambiente físico no qual o

mesmo está inserido (Huebscher e Maccann, 2005), dentre outras.

Existem vários frameworks e plataformas construídas para facilitar o

desenvolvimento de aplicações ubíquas, como por exemplo, o Context Toolkit (Salber,

D., et al., 1999), SOCAM (Gu, Pung et al., 2005), e o MUSIC (Rouvoy, Barone et al.,

2009). Nesse trabalho apresentamos uma aplicação construída utilizando o Context

Toolkit. Selecionamos tal framework baseado em algumas razões, dentre elas porque é

um dos frameworks ou plataformas mais referenciadas na literatura; também porque é

uma das poucas que oferece o executável e ainda o código fonte; e ainda porque possui

uma pequena curva de aprendizado. Além da aplicação supracitada, esse artigo

apresenta ainda uma extensão que, quando implementada, resolverá vários problemas e

limitações que o Context Toolkit apresenta como desafios aos desenvolvedores de

aplicações ubíquas.

O restante do artigo está estruturado da seguinte forma: a Seção 2 apresenta os

conceitos básicos abordados neste artigo; a Seção 3 apresenta a aplicação desenvolvida

utilizando o Context Toolkit; a Seção 4 discute sobre as dificuldades encontradas no

desenvolvimento de tal aplicação; a Seção 5 apresenta uma proposta de extensão do

Context Toolkit; e por fim, a Seção 6 apresenta as conclusões.

��&RQFHLWRV�%iVLFRV

2.1. Context Toolkit

O Context Toolkit é um framework que suporta o desenvolvimento de aplicações

sensíveis a contexto, permitindo que os desenvolvedores centrem seus esforços nas

regras de negócio das aplicações. Isso é possível uma vez que tal framework abstrai

diferentes tipos de componentes e a comunicação entre eles, que juntos, compõem as

aplicações ubíquas. Tais componentes são projetados sobre uma arquitetura de rede

distribuída, permitindo que sejam executados em diferentes máquinas e múltiplas

plataformas. O Context Toolkit permite o encapsulamento e reuso dos componentes que

provêm acesso aos sensores, dos processadores de informações de contexto e dos

componentes que proveem acesso aos atuadores.


160

O Context Toolkit atualmente está na versão 2.02, e tem como principais

componentes: (i) Discoverer; (ii) Widget; (iii) Enactor; e (iv) Service. A Figura 1

apresenta tais componentes, que são detalhados em seguida:

Figura 1 - Componentes do Context Toolkit (Salber , D., et al., 1999)

(i) Discoverer: Em uma aplicação sensível a contexto onde os dispositivos

(sensores e atuadores) estão fisicamente separados (distribuídos), manter a comunicação

entre esses dispositivos não é uma tarefa trivial. Isso porque para adicionar um novo

dispositivo é necessário avisar sobre o mesmo a todos os demais dispositivos existentes.

Para solucionar esse problema, o Context Toolkit disponibiliza o componente

Discoverer, responsável por centralizar as informações sobre componentes presentes na

rede, mantendo informação de endereçamento de cada dispositivo. O discoverer permite

armazenar, consultar, notificar e cancelar o registro de todo e qualquer componente no

ambiente.

(ii) Widget: são componentes que ficam ligados aos sensores e actuadores

existentes no ambiente. Os widgets são responsáveis por fornecer acesso a informações

de contexto para outros componentes ou aplicações, abstraindo os detalhes de

implementação dos sensores e actuadores existentes no ambiente. O widget notifica os

componentes ou aplicações interessadas sempre que o contexto do ambiente mudar e/ou

se tais mudanças atenderem as condições informadas na subscrição. Por exemplo, se um

componente está interessado em saber quando a temperatura de uma sala está superior a

25ºC, se subscreve ao widget ligado ao sensor de temperatura do ambiente e, uma vez

que a temperatura ultrapasse os 25ºC, o widget notifica o referido componente. Os

widgets podem receber subscrições de diversos componentes simultaneamente,

permitindo assim serem reutilizados por diversas aplicações. Por exemplo, um widget

que detecta a presença de uma pessoa em um determinado ambiente pode ser utilizado

por uma aplicação que simplesmente acende a luz quando alguém entra no ambiente e

por outra aplicação que é responsável por regular a temperatura ideal de sistema de

refrigeração de acordo com as preferências de cada pessoa.

(iii) Enactor: componente responsável por gerenciar a lógica de negócio de uma

aplicação sensível a contexto. Com base nas informações de contexto entregue por um

widget, um ou mais enactors processam as informações de acordo com suas regras,

modelos ou padrões, e invoca os serviços (abstrações de actuadores, apresentados a

seguir) que irão desempenhar uma ação especifica. Enactors implementam técnicas de

2 https://code.google.com/p/contexttoolkit/


161

aprendizado de máquinas e reconhecimento de padrões, e utiliza regras lógicas definida

pelos programadores para a tomada de decisão sobre atuação no ambiente.

(iv) Service: componente responsável por executar comportamento (ação) de

acordo com um determinado contexto. Isso é, em geral eles são invocados/acionados

pelos enactors ou aplicações para permitir a atuação no ambiente. Para isso, um service

é ligado, através de um widget, a um atuador instalado no ambiente. Por esse motivo, o

service é instanciados pelo próprio widget e pode ser acionado com base nas regras

definidas nos enactors ou mesmo diretamente por uma aplicação. Por exemplo, em uma

aplicação que acende as lâmpadas quando o nível de luminosidade do ambiente diminui

ao decorrer do dia, o service é o componente responsável por se comunicar com o

dispositivo (atuador) que fisicamente acende a lâmpada.

2.2. XBee

O Xbee3 é um módulo projetado para permitir a comunicação entre nós de sensores sem

fio. O XBee pode rotear a comunicação entre os nós utilizando diversos protocolos,

como por exemplo, 802.15.4 (IEEE Computer Society 2006) e ZigBee (ZigBee

Standards Orgazination 2008). O protocolo ZigBee, que é o utilizado no estudo de caso,

que será apresentado na Seção 3. O referido protocolo foi projetado para oferecer os

recursos desejados à uma aplicação de sensoriamento remoto como baixa latência,

otimização para baixo consumo de energia, possibilidade de implementação de redes

com elevado número de dispositivos e baixa complexidade dos nós de rede

(Monsignore, F., 2007).

2.3. Arduino

O arduino é uma plataforma eletrônica de prototipagem open-source projetado para ser

de fácil aprendizagem, fácil utilização e ter flexibilidade de hardware e software. A ele é

possível plugar diversos dispositivos eletrônicos, permitindo receber dados de uma

variedade de sensores, controlar luzes, motores e outros atuadores. Projetos feitos em

Arduino podem ser stand-alone ou podem fazer a comunicação com softwares

instalados no computador. As placas Arduino podem ser feitas a mão ou compradas pré-

montadas. Já as APIs são disponibilizadas gratuitamente na internet.

��(VWXGR�GH�FDVR

O estudo de caso apresentado nesse artigo consiste no controle pervasivo dos

equipamentos presentes no ambiente, ou seja, o ambiente deve se adequar

automaticamente as necessidades do usuário. O ambiente escolhido foi baseado nos

dispositivos que podem ser controlados e que estão presentes nas salas de aula do

Instituto Metrópole Digital. A Figura 2 ilustra o ambiente utilizado neste estudo de

caso: uma sala de aula que possui dispositivos como lâmpadas, computadores e um

sistema de ar-condicionado. Para o controle destes dispositivos, são coletados dados de

temperatura, luminosidade e número de pessoas presentes no ambiente.

Já a Figura 3 apresenta uma visão global da aplicação, onde as informações de

várias salas de aula são enviadas a um servidor, possibilitando então, o acesso a tais

informações através de dispositivos como notebooks, tablets e celulares. Nesse cenário,

3 www.digi.com/xbee


162

o arduino ficou responsável tanto pela coleta dos dados através dos sensores como

controle dos dispositivos e comunicação com o servidor utilizando os módulos XBee.

Também propomos uma alternativa a comunicação por fios direta entre o arduino e

possíveis dispositivos controladores, que é quando o próprio dispositivo já possui

alguma interface sem fio, como por exemplo, o infravermelho presente no ar-

condicionado. Nesta comunicação, como o arduino é um hardware versátil, bastaria

adiciona-lo um módulo de comunicação infravermelho.

Figura 2. Sala de Aula

Figura 3. Conjunto de Salas e Servidor

3.1. Implementação

Com base no que foi exposto na seção anterior e utilizando as tecnologias citadas na

Seção 2, criamos uma aplicação para simular o controle dos dispositivos presentes em

um ambiente de sala de aula. A aplicação foi implementada em Java, utilizando as

abstrações proporcionadas pelo Context Toolkit. Para alimentar a aplicação com dados

reais, foi feito um protótipo para realizar a coleta das informações do ambiente,

utilizando o arduino, um sensor LDR para luminosidade, um sensor LM35 para


163

temperatura e por ainda não encontramos uma forma eficiente de identificação de

pessoas no ambiente, nesta simulação a identificação das pessoas é realizada

manualmente através de uma interface gráfica. A comunicação entre o arduino e a

aplicação em Java é feita através de módulos Xbee, utilizando protocolo ZigBee, onde

um módulo foi conectado ao arduino e outro módulo foi conectado ao servidor.

A Figura 4 apresenta os componentes Context Toolkit (widgets, enactors e

services) implementados nesse estudo de caso. Os widgets Temperatura, Presença e

Luminosidade estão abstraindo a aquisição de dados pelos respectivos sensores. Tais

widgets enviam as informações sensoriadas para o widget central, que centraliza todas

as informações e as repassam, de acordo com a necessidade, para os enactors

responsáveis pelas regras de utilização do sistema de som, de ar-condicionado, lâmpada

e computador. Utilizamos as seguintes regras no enactors: (i) enactor Lâmpada ± se a

sala está vazia (P = 0) ou a luminosidade é maior que 150 (L > 150), valor proporcional

a saida do LDR, a lâmpada deve ser apagada, caso contrário, a lâmpada deve ser ligada;

(ii) widget Ar-condicionado ± se a sala está vazia ou a temperatura ambiente é menor

que que 22° (T < 22), o ar-condicionado deve ser desligado, caso contrário, o ar-

condicionado é ligado; (iii) widget PC ± se a sala está vazia, o computador devem ser

desligado, caso contrário, são ligados; e (iv) widget Sistema de Som ± se a sala está

vazia, os sistema de som deve ser desligado, caso contrário, deve ser ligado.

Implementamos ainda alguns widgets que instanciam os serviços que abstraem os

atuadores presentes no ambiente, sendo eles, o controlador de som, controlador de

computador, controlador do ar-condicionado e controlador da lâmpada.

Figure 4: Arquitetura dos componentes da aplicação

3.1. Simulação

Uma vez que a aplicação foi implementada, simulamos a sua execução. A Figura 5

ilustra mudanças de estados das variáveis de ambiente da sala de aula e como a

aplicação se comportou com relação a elas durante a simulação. Por exemplo, o


164

acionamento das lâmpadas é observado através da mudança do background da sala nos

três momentos ilustrados abaixo. Primeiro (esquerda da figura) a sala se encontra vazia

e consequentemente com os equipamentos desligados. Em seguida, ao detectar a

presença de pessoas na sala, a lâmpada, o ar-condicionado, o computador e o sistema de

som foram ligados (meio da figura). Por fim, o lado direito da figura ilustra o momento

em que a lâmpada é desligada uma vez que a luminosidade externa é maior que 150.

Figura 5. Sala de aula em três momentos distintos

Nessa primeira simulação observamos que a aplicação faz as mudanças no

ambiente real de acordo com as regras pré-estabelecidas. Além disso, a comunicação

sem fio através dos módulos XBee ocorreu com sucesso, não provocou perdas de

informações, e a velocidade que os dispositivos virtuais foram acionados foi

imperceptível. Concluída a simulação inicial com sucesso, foram feitas alterações na

aplicação em Java para que ela, ao acionar as lâmpadas simuladas, também enviasse um

pacote de dados ao arduino através do módulo Xbee. Assim, lâmpadas reais instaladas

no ambiente foram acionadas. Diferentemente da simulação inicial (com lâmpadas

simuladas), apesar da comunicação sem fio através do XBee tenha ocorrido com

sucesso, o acionamento da lâmpada real apresentou um atraso de aproximadamente 10

segundos.

��'LILFXOGDGHV�HQFRQWUDGDV

Identificamos vários problemas e dificuldades no Context Toolkit durante a

implementação do estudo de caso apresentado na seção anterior. Além disso,

encontramos também dificuldades na integração do Context Toolkit com o Arduino, e

com o XBee. Tudo isso influenciou bastante na implementação e na arquitetura do

referido estudo de caso. Descrevemos a seguir as principais dificuldades encontradas.

4.1. Context Toolkit

Durante a fase de implementação da aplicação, encontramos dificuldades para realizar a

descentralização da informações de contexto, pois a arquitetura do framework utilizado

não foi desenvolvida para atender esse requisito. Os enactors, componentes o quais são

responsáveis por gerenciar toda lógica da aplicação, executando operações com base

nos dados de contexto, só permitem executar apenas uma operação com base nas

informações de apenas um único widget, ou seja, apenas um conjunto restrito de

informações pode ser avaliado por cada enactor. Dessa forma, para que uma operação

que leve em consideração todos os dados de contexto da aplicação fosse executada,

tivemos que driblar a limitação do Context Toolkit criando um widget central que é

atualizado pelos demais widgets (sensores) e serve como entrada para todos os enactors,

como ilustrado na Figura 4.


165

A centralização das informações gerou vários outros problemas como, aumento

de código, diminuição de desempenho e confiabilidade. Isso porque para cada widget

(sensor) será necessário criar um enactor e um service para realizar apenas a atualização

dos dados de contexto deste widget para o widget central. Dessa forma, aumentando o

numero de operações que serão executadas em cada ação, consequentemente haverá

diminuição do desempenho. A centralização de todas as informações em um único

widget também diminui a confiabilidade da aplicação, pois a mesma está sujeita a pane

caso ocorra algum problema tanto de hardware como de software na maquina onde o

widget central esteja sendo executado, problema esse que seria contornado com a

descentralização das informações. Caso a máquina que esteja executando um

determinado widget deixe de funcionar, apenas as operações que necessitam desse

widget não seriam executadas, não comprometendo a aplicação como um todo.

4.2. XBee

A utilização de comunicação wireless através do módulo XBEE não foi de implantação

simples como tínhamos idealizado inicialmente. A seguir, listamos tais dificuldades: (i)

os tipos de dispositivos ZigBee (Coordenador, Roteador ou Dispositivo Final) assim

como alguns modo de operação, são gravados no firmware da placa Xbee. Esse

firmware é apenas alterado com adaptador USB específico, o qual não possuíamos, isso

nos levou a fazer alterações apenas em algumas características da rede e trabalhar com o

disposivo ZigBee que já estava na placa. (ii) já com relação ao protocolo ZigBee, foi

visto que ele é bastante robusto e totalmente compatível com o tipo de conexão por nós

desejada. Entretanto, é preciso recuperar a informação no nível de bit da mensagem

enviada ou recebida o que acarreta em aumento da curva de aprendizado necessária para

um tratamento eficiente de informações.

4.3. Arduino

Durante as simulações podemos ver que a integração do Arduino com a módulo Xbee e

a integração do módulo XBee com a aplicação Java foi satisfatória. Entretanto tivemos

algumas dificuldades na integração do arduino com outros módulos do sistema: (i) em

relação a comunicação entre estas plataformas, apesar do Arduino e o PC utilizarem de

comunicação assíncrona, tivemos alguns problemas de sincronização de dados. No

primeiro momento chegamos a ter delays de aproximadamente 10 segundos entre

acionamento da simulação e acionamento de lâmpada real. Esse atraso não é desejável

para uma aplicação de controle de ambientes, porém, após revisões do código

implantado no Arduino, esse delay foi diminuído para cerca de 4 segundos. Estamos

trabalhando na direção de tornar tal atraso imperceptível ao usuário, tornando tal

transição instantânea; e ii) No que se refere ao acionamento de cargas de potência mais

elevada ou com corrente alternada é necessário buscar soluções alternativas uma vez

que as saídas do Arduino possuem baixa potência.

��3URSRVWD�GH�H[WHQVmR�GR�&RQWH[W�7RRONLW

Considerando as dificuldades apresentadas na Seção 4, projetamos alguns componentes

que estenderão o Context Toolkit, com o objetivo de facilitar o desenvolvimento de

aplicações ubíquas com o Context Toolkit. A Figura 6 apresenta a nossa solução, a qual

ainda não foi implementada, mas é o próximo passo do projeto.


166

��&RQFOXV}HV

Esse artigo apresenta uma aplicação ubíqua construída utilizando o Context Toolkit.

Além disso, apresenta ainda as dificuldades encontradas na implementação de tal

aplicação. Tais dificuldades são resultados das limitações do referido framework. Desse

modo, apresentamos ainda uma proposta de extensão ao Context Toolkit para eliminar

as limitações encontradas. Um trabalho futuro a curto prazo é implementar a extensão

proposta. Além disso, um outro trabalho futuro é a criação de uma nova plataforma já

adaptada às tecnologias atuais de: comunicação, prototipação, representação de

contexto, de raciocínio e ainda de tomada de decisão.

5HIHUrQFLDV

Cook, Diane J., and Sajal K. Das. (2007) "How smart are our environments? An

updated look at the state of the art." Pervasive and mobile computing 3.2: 53-73

Dey, Anind K. "Understanding and using context." Personal and ubiquitous

computing´��2001.

Dey, A.; Abowd, G.; Salber, D. (2001) ³$�&RQFHStual Framework and a toolkit for

supporting the Rapid Prototyping od Context-DZDUH�$SSOLFDWLRQV´��-RXUQDl of Human-

Computer Interaction.

Faludi R. (2010��³%XLOGLQJ�:LUHOHVV�6HQVRU�1HWZRUNV´��2¶5HLOO\��1° Edição.

França, T.; Pires, P.; Pirmez, L.; Delicato, F.; Farias, C. (2011) ³:HE� GDV� &RLVDV��

&RQHFWDQGR�'LVSRVLWLYRV�)tVLFRV�DR�0XQGR�'LJLWDO´��6LPSyVLR�%UDVLOHLUR�GH�5HGHV�GH�

Computadores e Sistemas Distribuídos (SBRC). p. 1--8

+DOO��0�� )UDQN��(�� HW� DO�� ³7KH�:(.$�GDWD�PLQLQJ� VRIWZDUH�� DQ� XSGDWH³�� In:

ACM SIGKDD Explorations Newsletter, Volume 11 Issue 1, June 2009, Pages 10-18.

Huebscher, M.; Maccann, J. (2005) ³$Q�$GDSWLYH�0LGGOHZDUH�)UDPHZRUN�IRU�&RQWH[W-

DDUH�$SSOLFDWLRQV´��3HUVRQDO�DQG�8ELTXLWRXV�&omputing Journal. V.10, p.12²20.

IEEE Computer SRFLHW\��³,(((�6WG��´�

,UZLQ��-��³$QiOLVH�GH�FLUFXLWRV�HP�HQJHQKDULD´��0DNURQ�%RRNV��(GLomR�

0RQVLJQRUH��)��³6HQVRULDPHQWR�GH�DPELHQWH�XWLOL]DQGR�R�SDGUmR�=LJ%HH´�

Rouvoy, R. et al. (2009) ³MUSIC: Middleware Support for Self-Adaptation in

Ubiquitous and Service-Oriented (QYLURQPHQWV´. Software Engineering for Self-

Adaptive Systems, v.5525. p.164--182.

Salber, D., Dey, AK. and Abowd, GD. (1999) ³The context toolkit: aiding the

development of context-enabled applications ³��,Q��CHI '99 Proceedings of the SIGCHI

conference on Human Factors in Computing Systems, pages 434-441.

Sedra, A. (2007), Microeletrônica, Pearson Prentice Hall, 5ª Edição.

Weiser, M. (1991), ³The computer for the 21st century´, Scientific American, pp.94±104.

ZigBee Standards Orgazination ��³=LJ%HH�6SHFLILFDWLRQ�± 'RFXPHQW��U��´�


168

Documents

Implementação de uma aplicação ubíqua no Context Toolkit