UNIVERSIDADE FEDERAL DA PARAÍBA CENTRO DE … · Computação Pervasiva centraliza suas aplicações no usuário, formando um ambiente de computação comunicável e distribuída

0

FOR-ALL 1.0: UMA PROPOSTA DE ARQUITETURA PARA REDES DE SENSORES SEM FIO

BASEADA NA COMPUTAÇÃO UBÍQUA, PERVASIVA E NA ORIENTAÇÃO A SERVIÇOS

UNIVERSIDADE FEDERAL DA PARAÍBA

CENTRO DE CIÊNCIAS EXATAS E DA NATUREZA

BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

ELENILSON VIERA DA SILVA FILHO

FOR-ALL 1.0: UMA PROPOSTA DE ARQUITETURA PARA REDES DE SENSORES SEM

FIO BASEADA NA COMPUTAÇÃO UBÍQUA, PERVASIVA E NA OR IENTAÇÃO A

SERVIÇOS

João Pessoa - PB

2010

1



UNIVERSIDADE FEDERAL DA PARAÍBA

CENTRO DE CIÊNCIAS EXATAS E DA NATUREZA

BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

ELENILSON VIERA DA SILVA FILHO


FIO BASEADA NA COMPUTAÇÃO UBÍQUA, PERVASIVA E NA OR IENTAÇÃO A

SERVIÇOS

Monografia apresentada ao curso de

Bacharelado em Ciência da Computação,

UFPB, em cumprimento às exigências da

disciplina de Trabalho de Conclusão de

Curso – TCC, como requisito para

obtenção do grau de Bacharel em Ciência

Computação.

ORIENTADOR: Prof. Dr. Alisson

Vasconcelos de Brito

João Pessoa - PB

2010

2



ELENSILSON VIERA DA SILVA FILHO


FIO BASEADO NA COMPUTAÇÃO UBÍQUA, PERVASIVA E NA ORIENTAÇÃO À

SERVIÇOS

Monografia apresentada ao curso de

Bacharelado em Ciência da Computação,

UFPB, em cumprimento às exigências da

disciplina de Trabalho de Conclusão de

Curso – TCC, como requisito para

obtenção do grau de Bacharel em Ciência

Computação.

Aprovado no dia ____, dezembro de 2010

BANCA EXAMINADORA

Prof. Dr. Alisson Vasconcelos de Brito

Prof. Dr. Hamilton Soares da Silva

Profa. Dra. Tatiana Aires Tavares

3



Dedico esse trabalho à minha querida avó que infelizmente não viveu tempo

suficiente para acompanhar a minha graduação.

4



AGRADECIMENTOS

A Deus, por eu estar vivo e com saúde.

Aos meus pais por me darem as bases para que meus esforços fossem

transformados em sucesso.

A minha tia Genilza por ser a minha segunda mãe durante todos esses anos de

ajuda a mim e aos meus pais.

Ao meu tutor do PET, o professor Dr. Leonardo Vidal Batista, por seus ensinamentos

durante esses três anos como petiano.

Ao professor doutor Alisson Vasconcelos de Brito por ter aceitado orientar o meu

trabalho e por todos os contatos que me fizeram ter sucesso enquanto Embaixador

de Campus da Sun.

Ao PET.Com pelas oportunidades e conhecimentos adquiridos.

Aos meus amigos por estarem sempre presentes nos momentos bons e ruins da

minha vida.

A todos que um dia me apoiaram, eu não esqueci e um dia os recompensarei.

5



Graças a Deus a esse estado de fraqueza

Eu já tô imunizado, minha nação é nordestina

E trás no sangue o suor dessa caatinga

E tem no peito o alimento da fé

Embora a seca tenha secado o seu pranto

O mundo agora vai ter que ouvir meu canto

Sou renitente, continuo dizendo oxente.

(Geraldinho Lins)

6



RESUMO

O avanço nas redes de sensores sem fio possibilitou sua utilização no

monitoramento, rastreamento, coordenação e processamento em diferentes

contextos, formando ambientes específicos, chamados de ambientes inteligentes. A

Computação Pervasiva centraliza suas aplicações no usuário, formando um

ambiente de computação comunicável e distribuída. Unindo a utilização de sensores

e a computação pervasiva e ubíqua em uma plataforma orientada a serviços é

possível o desenvolvimento de uma arquitetura para a criação e gerenciamento

desses serviços de forma ágil e simplificada. Uma grande dificuldade está em

gerenciar os dispositivos usados para formar este ambiente, bem como, a

comunicação entre eles e suas aplicações. A intenção da plataforma proposta neste

trabalho está na oferta e gerência de tais serviços computacionais a qualquer tempo

e lugar, com todas as funcionalidades desejadas e do modo desejado. Com esses

serviços disponíveis, aplicações poderão ser desenvolvidas focadas no

monitoramento de ambientes como: casas, carros e fábricas ou ainda, por exemplo,

podem ser desenvolvidos sistemas de segurança para monitoramento de máquinas

ou entrada de funcionários. O objetivo deste trabalho foi fazer uma análise da atual

situação do For-All, propor uma nova arquitetura e faze uma implementação parcial

a fim de oferecer as funcionalidades moldadas pelo usuário, em todo tempo e

independente do local, através de uma arquitetura geral para o desenvolvimento,

gerência e monitoramento de ambientes. Com a nova arquitetura proposta, uma

implementação parcial foi desenvolvida com a realização de testes que tiveram

resultados satisfatórios e é possível concluir que a plataforma abstrai problemas de

montagem e comunicação com os dispositivos.

Palavras-chave: Pervasividade, Ubiquidade, For-All, Redes de Sensores Sem Fio,

Serviços, SOA.

7



ABSTRACT

The advances in wireless sensor networks had permitted their use in monitoring,

tracking, coordination and processing at different contexts, forming specific

environments called intelligent environments. The Pervasive Computing centralizes

their applications on the user, forming a computing environment also communicable

and distributed. Joining together the use of sensors and pervasive and ubiquitous

computing in a service-oriented platform is possible the development of an

architecture for creation and management of these services at an agile and simplified

way. A great difficulty is to manage the devices that were used to create this

environment, as well as the communication between them and their applications. The

intent of the proposed platform in this work is the supply and management of such

computational services at any time and any place with all the desired features and

the way desired. With these services available, applications will be able to be

developed focused on monitoring some kind of environments such as homes, cars

and factories, or, for example, can be developed security systems for machine

monitoring or input employees. The aim of this work was to analyze the current

situation of the For-All propose a new architecture and make a partial code

development to provide the features shaped by the user in any time and regardless

of location, through a general architecture for development, management, and

monitoring of environments. With the new architecture proposed, a partial code

development was done, and, with the realization of tests with satisfactory results, this

work concluded that the platform prescinds mounting problems and communication

with devices.

Keywords: Pervasiveness, Ubiquity, For-All, Wireless Sensors Network, Services,

SOA.

8



LISTA DE FIGURAS

Figura 1. Arquitetura de um Sistema Pervasivo ........................................................ 18

Figura 2: Relação da Computação Ubíqua com a Computação Pervasiva e Móvel

(ARAÚJO, 2003) ....................................................................................................... 20

Figura 3: Redes de sensores sem fio devem se tornar cada vez mais disponíveis nas

mais diferentes aplicações (LOUREIRO, 2003) ........................................................ 22

Figura 4: Estabelecimento de rede de sensores (OTHMAN, 2007) .......................... 23

Figura 5: Arquitetura de colaboração SOA (ENDREI, 2004) ..................................... 25

Figura 6: Arquitetura Geral do For-All ....................................................................... 31

Figura 7: Arquitetura do sistema básico que é executado em cada Sun SPOT ........ 32

Figura 8: Diagrama de Classes do For-All ................................................................ 33

Figura 9: Código de execução de um alarme genérico (AbstractAlarm) ................... 34

Figura 10: Tela inicial de seleção de serviço e operação .......................................... 35

Figura 11: Tela com resultado do monitor de temperatura ........................................ 35

Figura 12: Tela de resultado do serviço solicitado (alarme de temperatura) ............. 36

Figura 13: Visão geral da arquitetura e suas camadas (VIEIRA, 2010) .................... 39

Figura 14: Detalhamento da comunicação entre as camadas (VIEIRA, 2010).......... 44

Figura 15: Aplicação desenvolvida para solicitação de serviços ............................... 47

Figura 16: Resultado de uma consulta de temperatura ............................................. 48

9



LISTA DE SIGLAS

DI Departamento de Informática

GW Gateway

IOT Internet of Things

IP Internet Protocol

JRE Java Runtime Environment

MANET Mobile Ad hoc Network

PDA Personal Digital Assistant

PET.Com Programa de Educação Tutorial do Bacharelado em Computação

RSSF Redes de Sensores sem Fio

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

Sun SPOT Sun Small Programmable Object Technology

TCP Transmission Control Protocol

TI Tecnologia da Informação

UFPB Universidade Federal da Paraíba

XML Extensible Markup Language

10



SUMÁRIO

INTRODUÇÃO .......................................................................................................... 12

Objetivos ................................................................................................................ 13

Contribuição Esperada .......................................................................................... 13

Estrutura da Monografia ........................................................................................ 14

CAPÍTULO 1: Fundamentação Teórica ..................................................................... 15

1.1 Computação Pervasiva ................................................................................ 15

1.1.1. Arquitetura de um Sistema Pervasivo ....................................................... 18

1.2. Computação Ubíqua .................................................................................... 19

1.3. Redes de Sensores sem Fio ........................................................................ 21

1.4. Arquitetura Orientada a Serviços ................................................................. 24

1.5. Sun Small Programmable Object Technology (Sun SPOT) ........................ 27

CAPÍTULO 2: Trabalhos Relacionados ..................................................................... 28

2.1. Ninja ............................................................................................................. 28

2.2. Projeto Middleware Orientado a Servico ...................................................... 28

2.3. Aura .............................................................................................................. 29

2.4. Gaia .............................................................................................................. 29

2.5. Oxygen ......................................................................................................... 29

CAPÍTULO 3: O antigo For-All .................................................................................. 30

3.1. A plataforma ................................................................................................. 30

3.2. Arquitetura Geral .......................................................................................... 30

3.3. Software Base nos Dispositivos ................................................................... 32

3.4. Operações de Gerência ............................................................................... 32

3.5. Resultados e Discussão ............................................................................... 34

CAPÍTULO 4: Uma proposta para o FOR-ALL 1.0 ................................................... 37

4.1. Materiais ....................................................................................................... 37

4.2. For-All 1.0 ..................................................................................................... 37

4.3. Visão Geral da Arquitetura ........................................................................... 38

4.4. Visão Detalhada das Camadas da Arquitetura ............................................ 40

4.4.1. Agente....................................................................................................... 40

4.4.2. Comunidade .............................................................................................. 41

11



4.4.3. Gateway .................................................................................................... 43

4.4.4. Aplicações ................................................................................................. 43

4.5. Comunicação entre as camadas .................................................................. 44

4.6. Visão de Implantação ................................................................................... 45

CAPÍTULO 5: Implementação Parcial ....................................................................... 46

CAPÍTULO 6: Resultados e Discussão ..................................................................... 48

CONCLUSÕES ......................................................................................................... 49

REFERÊNCIAS ......................................................................................................... 50

12



INTRODUÇÃO

Atualmente há uma crescente necessidade de informação em todos os

lugares de forma rápida e simples. Essa necessidade vai desde uma simples

informação da falta ou não do abastecimento de água em um determinado local até

a temperatura de uma sala com importantes servidores. O acesso a essas

informações deve ser feito através de serviços disponibilizados que precisam ser de

fácil acesso para que, desse modo, uma resposta possa ser gerada rapidamente.

Com a Internet das Coisas (IOT - Internet of Things) é possível fazer com que

qualquer dispositivo do mundo real tenha uma existência própria no mundo virtual

(MELOAN, 2003), onde objetos do mundo físico possuem um identificador único e

uma descrição bem simples, o que facilita a interação e o acesso a eles

(SIORPAES, 2006). Esses objetos estarão interligados em rede e serão capazes de

detectar mudanças na qualidade física das coisas usando tecnologias sensoriais.

Dessa forma será possível criar um ambiente próprio, chamado de ambiente

inteligente, moldável às situações do ambiente em que o usuário se encontra.

Com a disponibilização de serviços é possível o desenvolvimento de

aplicações com foco no monitoramento de ambientes com a coleta de dados feita

através da solicitação de serviços, tais como: temperatura, luminosidade,

movimentação, etc. Esse monitoramento pode ser feito em ambientes imóveis

(casas, fábricas, etc.) e móveis (carros, caminhões, navios, etc.) ou ainda, podem

ser construídos sistemas de segurança para monitoramento de máquinas críticas ou

entrada de funcionários em uma empresa.

As melhores tecnologias são aquelas que desaparecem, se misturam ao meio

a ponto de não serem percebidas (WEISER, 1991). Dessa forma tem-se a

pervasividade do computador, onde não é mais o usuário que entra no mundo

virtual, mas o computador que entra no mundo do usuário. A computação ubíqua

surge como um novo paradigma, permitindo aos usuários acesso aos seus

ambientes computacionais de todo o lugar, o tempo todo (SAHA, 2003). A

computação pervasiva é hoje uma realidade (YAMIN, 2004).

A plataforma proposta por este trabalho possibilita a manipulação e a

configuração de dispositivos que estão distribuídos em um ambiente inteligente,

13



disponibilizando serviços computacionais como base para a computação pervasiva.

Tais serviços devem ser oferecidos e utilizados por qualquer tipo de dispositivo

independente de tecnologia e protocolo. O projeto For-All visa exatamente à

universalização dos dispositivos e a transparência da troca informações através dos

serviços.

Objetivos

O objetivo geral dessa monografia é propor uma arquitetura que comporte a

implantação da Internet das Coisas, proporcionando abstrações e facilidades da

criação e manutenção de ambientes inteligentes. A arquitetura deve ser de baixa

complexidade e fácil implantação.

Os objetivos específicos são:

• Encontrar falhas na arquitetura atual do For-All

• Fazer uma revisão bibliográfica para as técnicas mais atualizadas e

integrá-las ao For-All

• Propor uma especificação para o For-All 1.0

• Fazer uma implementação parcial

Contribuição Esperada

Espera-se que, ao final deste trabalho, a especificação da plataforma seja

implementada e possa contribuir de forma significativa para a implantação da

Internet das Coisas e para a otimização na criação de ambientes inteligentes.

Outra contribuição é de que as aplicações desenvolvidas seguirão a mesma

estrutura. Isso pode acabar por facilitar sua manutenção.

Também pode-se destacar a potencial contribuição deste trabalho em

trabalhos futuros, uma vez que foi feita uma revisão de alguns serviços e aspectos

operacionais particulares.

14



Estrutura da Monografia

No Capítulo 1 é feita uma revisão bibliográfica onde são mostrados conceitos

que a arquitetura tem como base. No Capítulo 2 são expostos trabalhos

relacionados. No capítulo 3 estão descritos os materiais. No capítulo 4 é descrita a

plataforma atual do For-All. No capítulo 5 é feita uma proposta para o For-All 1.0. No

capítulo 6 é descrita uma implementação parcial do For-All 1.0. No capítulo 7 há

resultados e discussão da implementação parcial. Por fim são feitas considerações

finais.

15



CAPÍTULO 1: FUNDAMENTAÇÃO TEÓRICA

Este capítulo apresenta os conceitos teóricos para o desenvolvimento do

trabalho.

1.1 Computação Pervasiva Na década de 80, Mark Weiser descreveu sua visão sobre o futuro da

tecnologia. Segundo ele, o futuro seria de tecnologias invisíveis, ou seja, se

misturariam com o meio a ponto de não serem percebidas (WEISER, 1991). A

tecnologia invade o mundo real se torna parte dele.

Com a evolução da tecnologia, percebe-se que o computador está cada vez

mais fazendo parte do cotidiano, estando presente em: celulares, máquinas

fotográficas, PDAs, carros, sem contar os computadores pessoais e portáteis. Com o

crescimento da internet, a redução dos custos com hardware e o aperfeiçoamento

de redes sem fio, a computação pervasiva tornou-se uma realidade (YAMIN, 2004).

À medida que os dispositivos computacionais foram diminuindo, novas áreas

foram desenvolvidas para englobar tais mudanças. Uma delas é a Computação

Baseada no Contexto na qual as tarefas são realizadas de acordo com a situação

atual das pessoas ou do ambiente. Esta possibilidade trouxe vários novos termos e

conceitos, dentre eles o de “Computação Pervasiva” (GEYER, 2005; LOKE, 2007).

É necessário encontrar uma maneira de abstrair do usuário quais tecnologias

são utilizadas no dia-a-dia. Neste ponto, surgem quatro desafios:

• O uso efetivo de ambientes inteligentes para permitir a união dos

mundos virtual e real;

• A invisibilidade para que se torne totalmente fora da consciência do

usuário;

• Escalabilidade é um ponto crítico na sofisticação do projeto;

• O mascaramento de condições adversas para permitir que o usuário

manipule informações sem se preocupar com a heterogeneidade das

tecnologias utilizadas.

Os ambientes inteligentes da Computação Pervasiva usam as informações do

seu contexto. Estas são geradas pelo ambiente (temperatura, tempo, condições de

16



meteorologia), por pessoas (gostos, preferências, localização) e dispositivos (estado

e disponibilidade) sendo então usados para caracterizar a situação de uma entidade

(pessoa, lugar, objeto). Essas informações são compartilhadas entre diferentes

dispositivos (ESCOBEDO, 2006).

Entende-se o conceito de computação pervasiva como sendo a interação

entre os dispositivos computacionais e as pessoas, obtida de tal forma a não permitir

que seja percebida. Desse modo os dispositivos seriam incorporados ao ambiente

para auxiliar atividades humanas e poderiam comunicar-se entre si melhorando o

desempenho. Para obter tal resultado a computação pervasiva deve lançar mão das

seguintes funcionalidades:

• Sentir - envolve sensores que respondem a estímulos ou sinais como,

por exemplo, térmico, luminoso, sonoro, dentre outros. Sua resposta é

enviada como um sinal elétrico e pode reagir a qualquer coisa, como

uma mudança no ambiente.

• Pensar - representa a tomada de decisão. É onde as informações

enviadas pelos sensores são processadas para gerar dados que

possam ser usados ou mostrados na aplicação.

• Agir - são as ações realizadas de acordo com a aplicação e que devem

levar em consideração o desempenho, o controle de usuário e o

planejamento.

Para tanto, é necessário que informações sejam coletadas do meio, gerando

uma resposta própria e imediata. O uso de dispositivos variados e de comunicação

distribuída é uma necessidade, como também é necessária uma computação

distribuída que forme uma grade pervasiva (GEYER, 2005).

Desta forma, as aplicações pervasivas precisam ser inerentemente

distribuídas, ter mobilidade lógica e física e ser adaptativa ao contexto em que serão

processadas.

A utilização em massa de ambientes inteligentes acarretará uma integração

de dois mundos, o real e o virtual, onde o controle do primeiro será feito através do

segundo e possibilitará a automatização de tarefas que antes exigiam atuação

explícita do usuário. Este não deve se preocupar em saber como fazer o sistema

funcionar e simplesmente operá-lo de forma subconsciente.

17



Os dispositivos são de natureza heterogênea e isso demandará

adaptabilidade das aplicações para as diversas condições fornecidas.

Vale salientar que alguns problemas deverão ser contornados, dentre eles

estão: os recursos locais nos dispositivos móveis (peso, tamanho, consumo de

energia, poder de processamento e capacidade de armazenamento) são limitados

em comparação com os sistemas fixos de custo similar. Além disso, a infra-estrutura

de suporte é altamente variável (conectividade, recursos remotos), principalmente

quando é feita uma comparação com dispositivos estáticos comumente utilizados.

Dessa forma, desenvolver aplicações móveis se torna uma tarefa difícil, pois o

projetista deve conhecer os domínios em que as aplicações se encontram. Por

essas razões, pesquisadores concordam que as aplicações móveis devem ser

adaptativas: dependendo das características do ambiente de execução, aplicações

alteram seu comportamento e o modo como utilizam os recursos. Linguagens,

bibliotecas ou middlewares podem auxiliar na tarefa de adaptação (YAMIN, 2004).

Diante dessa perspectiva, os componentes que integram o meio de execução

(dados, equipamentos e serviços) deverão ser gerenciados por um ambiente de

execução que permita um acesso independente do equipamento utilizado, do local e

do momento de acesso.

18



1.1.1. Arquitetura de um Sistema Pervasivo

De forma genérica, um sistema pervasivo deve possuir a arquitetura mostrada

na Figura 1, podendo ser genérica, ou específica para determinada aplicação.

Figura 1. Arquitetura de um Sistema Pervasivo

19



1.2. Computação Ubíqua

Mark Weiser foi o pioneiro na Computação Ubíqua e seus estudos iniciais são da

década de 80. Nestas pesquisas, Weiser relacionou questões, tais como: interface

humano-computador, realidade virtual e agente inteligente de software (WEISER,

1991).

Nessa área o esquema de uma pessoa e um computador pessoal não é mais

válido. O que se tem é a distribuição de dispositivos eletrônicos e móveis com

capacidades computacionais pelo ambiente, mas sem que a presença dos

dispositivos seja notada, ou seja, permitir o uso da tecnologia de forma natural, sem

que o usuário perceba ou precise dedicar sua atenção à utilização (ARAYA, 1995).

Nesse contexto, a área foi denominada Computação Ubíqua e seu objetivo é obter

uma computação espalhada pelo ambiente, onipresente e de uso natural, ou seja,

não invasiva (SARANUMMI, 2008; ADESLTEIN, 2005).

A Computação Ubíqua também é conhecida como Computação Invisível e define

uma nova linha de pesquisa tecnológica baseada na difusão da informática. Estas

investigações buscam tornar transparente e ampliar a integração entre objetos

comuns, dispositivos e serviços para a criação dos chamados ambientes inteligentes

(REMAGNINO, 2005; SARANUMMI, 2008).

Alguns pontos são essenciais para sua implantação:

• Comunicação entre dispositivos: estes tem a capacidade de

comunicação não apenas com o usuário, mas também com os

demais objetos integrados ao ambiente ubíquo;

• Memória: proporcionar uma melhor resposta baseada em fatos

anteriores;

• Ser sensível ao contexto: possibilidade de adaptação às diversas

situações e preferências do usuário, atuando de forma

dependente no contexto que se trata;

• Ser reativo: perceber o quando for gerado qualquer evento em

seu entorno mediante o uso de sensores ou da interação com

outros dispositivos e tomar uma ação baseada numa regra.

(AVELAR, 2008, p. 1-2)

Para tanto, alguns fatores físicos se tornam cruciais para fazer a Computação

Ubíqua ser passível de implementação e a principal delas é a miniaturização dos

matriais utilizado na fabricação dos dispositivos e sensores (CAHILL, 2004).

20



Apesar de parecidos, Computação Ubíqua é diferente de Computação Pervasiva,

de forma que computação pervasiva define os modelos dos dispositivos com alto

grau de acoplação e baixo grau de mobilidade, enquanto que Computação Ubíqua

define os modelos dos dispositivos com alto grau de acoplamento e alto grau de

mobilidade (LYYTINEN, 2002). O termo ainda é confundido com a Computação

Móvel (ADELSTEIN, 2005). Apesar dessa proposta de diferenciação, nota-se que

não há uma distinção bem definida.

A Ubiquidade integra a Pervasividade com a Mobilidade, ou seja, qualquer

dispositivo, em posse de um usuário em movimento, pode construir, dinamicamente,

modelos do ambiente em que está inserido e configurar seus serviços dependendo

da necessidade. O que há de fato é que a computação está fora das estações de

trabalhos, ou seja, computadores comuns utilizados atualmente saem desse

ambiente e tornam-se pervasivos no cotidiano dos indivíduos. Weiser visionou que

os computadores estariam presentes nos mais comuns objetos do cotidiano, tais

como: etiqueta de roupas, xícaras de café, televisores, luz, canetas, embalagens de

alimentos, etc. de forma imperceptível aos usuários. Para Weiser é necessários uma

adaptação, não mais há apenas interação com eles, mas também a interação e a

imersão deles no mundo real (WEISER, 1991).

Figura 2: Relação da Computação Ubíqua com a Comput ação Pervasiva e

Móvel (ARAÚJO, 2003)

21



1.3. Redes de Sensores sem Fio

A área de Redes de Sensores Sem Fio (RSSF) está em ascensão com diversas

aplicações a fim de prover a conexão entre os meios digital e físico. A obtenção

desse objetivo permitirá que os sensores forneçam medições detalhadas e

simplificadas, medições essas que são difíceis de obter com o uso de técnicas de

tradicionais. Apesar de muitas vantagens, novos desafios são criados. (CARLESSO,

2006).

RSSFs contém geralmente muitos dispositivos de baixo custo e tamanhos

reduzidos capazes de realizar sensoriamento, processamento e transmissão de

informação através de enlaces sem fio. Os sensores devem operar sem assistência

humana por longos períodos de tempo e normalmente são alimentados por baterias

não recarregáveis. Como a maior fonte de consumo de energia nos sensores é a

transmissão de dados, os protocolos de comunicação para RSSFs visam propor

soluções a fim de diminuir os gastos de energia e estender o tempo necessário para

substituição das baterias. A grande maioria dos protocolos são baseados na

comunicação utilizando múltiplos saltos (multi-hop) de curto alcance e adota algum

mecanismo de agregação de dados com o intuito de reduzir os pacotes transmitidos

(LOUREIRO, 2002).

As RSSFs são diferentes das tradicionais redes de computadores em muitos

aspectos. Normalmente essas redes possuem um vasto número de nodos

distribuídos, têm restrições de energia, possuem mecanismos para configuração

automática e adaptação devido a problemas, tais como: falhas de comunicação e

perda de nodos. A não ser pela fonte de alimentação, uma RSSF tende a ser

praticamente autônoma e requer um alto grau de cooperação para a execução das

suas tarefas. Para tanto, algoritmos distribuídos tradicionais e protocolos de

comunicação devem ser revistos para esse novo ambiente. Os desafios para o

desenvolvimento de RSSFs vão muito além das redes tradicionais (LOUREIRO,

2003), por exemplo: preocupação com gasto de energia, otimização na transmissão

dos pacotes de modo a ter menos dados enviados por menos tempo, entre outros.

Essas preocupações até existem nas redes tradicionais, mas não com tamanha

importância como com as RSSFs.

22



Os nodos dessas redes são equipados com diversos sensores, tais como: vídeo-

câmera, calor, temperatura, pressão, movimentação, etc. Esses nodos podem ser

organizados em grupos (clusters) e deve poder detectar um evento em suas

proximidades (LOUREIRO, 2003). Isso possibilita das tarefas e a otimização dos

resultados, uma vez que cada nós se torna específico.

Figura 3: Redes de sensores sem fio devem se tornar cada vez mais

disponíveis nas mais diferentes aplicações (LOUREIR O, 2003)

As RSSFs podem ser vistas como um tipo especial de rede móvel ad hoc

(MANET – Mobile Ad hoc Network). Numa rede tradicional, a comunicação

entre os elementos computacionais é feita através de estações base de rádio,

que constituem uma infra-estrutura de comunicação. Esse é o caso da

Internet. Por outro lado, numa rede móvel ad hoc os elementos

computacionais trocam dados diretamente entre si. Do ponto de vista de

organização, RSSFs e MANETs são idênticas, já que possuem elementos

computacionais que comunicam diretamente entre si através de enlaces de

comunicação sem fio. No entanto, as MANETs têm como função básica

prover um suporte à comunicação entre esses elementos computacionais,

que individualmente, podem estar executando tarefas distintas. Por outro

lado, RSSFs tendem a executar uma função colaborativa onde os elementos

(sensores) provêem dados, que são processados (ou consumidos) por nodos

especiais chamados de sorvedouros (sink nodes) (LOUREIRO, 2003, p. 2).

23



Figura 4: Estabelecimento de rede de sensores (OTHM AN, 2007)

A Figura 4 mostra as fases do estabelecimento de uma RSSF, onde há a

inserção dos sensores, depois estes se organizam formando uma rede própria e

logo estão trocando dados, elegendo nós mestres e se auto configurando.

24



1.4. Arquitetura Orientada a Serviços

Uma Arquitetura Orientada a Serviços (SOA – Service Oriented Architecture) é a

evolução da computação distribuída com base em pedido/resposta para uma

concepção síncrona e assíncrona de aplicações, sendo um estilo de arquitetura de

software cujo princípio fundamental preconiza que as funcionalidades

implementadas pelas aplicações devem ser disponibilizadas na forma de serviços

(VIEIRA, 2010).

Uma arquitetura de software trata basicamente de como os componentes

fundamentais de um sistema se relacionam intrinsecamente e extrinsecamente. Uma

arquitetura orientada a serviços tem como seu componente fundamental o conceito

de serviços. SOA é um meio para organizar as soluções que promovem o reuso,

crescimento e interoperabilidade. Ela não é uma solução para os problemas do

domínio, mas um paradigma para organização e disponibilização de serviços. Esta é

uma promessa de uma nova arquitetura, pois cada elemento de um SOA pode ser

movido, substituído e modificado. Cada serviço ainda pode ser montado e

remontado em diferentes formas para diferentes propósitos e circunstâncias.

SOA possui uma excelente abordagem para o desenvolvimento de sistemas

distribuídos que visam atender as novas tendências do mercado: agilidade e

flexibilidade. De forma única, a proposta SOA aceita (JOSUTIS, 2007):

• Manter a flexibilidade em grandes sistemas distribuídos;

• Suportar a heterogeneidade;

• Descentralização;

• Tolerância a falhas.

Construir aplicações baseadas em SOA requer uma nova forma de pensar e

desenvolver sistemas (JOSUTTIS 2007). SOA é um paradigma para organização e

utilização de competências que estão distribuídas e em diferentes domínios (OASIS,

2006).

Para que seja possível a interação entre os serviços que implementam as

competências e necessidades das entidades é necessário a colaboração,

conforme Figura 5. Nesta arquitetura observamos três serviços: 1)

consumidor: aplicação ou outro serviço que necessita de um serviço e o

executa de acordo com o contrato de interface; 2) provedor: entidade que

aceita e executa as requisições dos consumidores, este publica seus serviços

25



e os registra por meio de um contrato de interface; e 3) registro: contém um

repositório de serviço no qual permite a procura deste. A colaboração entre

estes serviços segue o paradigma de encontrar, conectar e invocar. Neste o

consumidor realiza uma localização dinâmica do serviço requisitado,

publicado anteriormente por um provedor. Esta localização é realizada por

meio de consulta no serviço de registro e depois de encontrado, o consumidor

conecta e invoca o serviço solicitado (ENDREI, 2004).

Figura 5: Arquitetura de colaboração SOA (ENDREI, 2 004)

A habilidade de compor aplicações a partir desses serviços, combinando com

a reutilização e os padrões baseados em interoperabilidade, prover a flexibilidade

necessária para a utilizações em Redes de Sensores Sem Fio. (ERICK 2006).

Na SOA, os programadores criam serviços. As organizações que focalizam os

seus esforços de desenvolvimento em torno da criação dos serviços obterão muitos

benefícios. A utilização da SOA nas aplicações, além de tornar mais fácil a

implementação, acarretará em algumas vantagens (KODALI 2008):

• Aumento da mobilidade;

• Maior segurança;

• Prestação de serviços;

• Melhoria da manutenção;

• Melhor escalabilidade.

26



Serviços são uma das bases fundamentais para a implementação de um sistema

baseado no paradigma SOA. Entretanto, para utilizar este recurso alguns pontos

precisam ser considerados para prover sua flexibilidade e manutenção. São elas

(ENDREI, 2004):

• Prover conectividade entre provedor e consumidor;

• Quando necessário transformar os formatos das mensagens entre o

consumidor e o provedor;

• Converter protocolos entre consumidor e provedor;

• Realizar o correto e eficiente roteamento da requisição do consumidor ao

provedor do serviço solicitado.

27



1.5. Sun Small Programmable Object Technology (Sun SPOT)

O Projeto For-All utiliza a Computação Pervasiva juntamente com a tecnologia

Sun Small Programmable Object Technology (Sun SPOT) (SUN, 2009), unida à

Zigbee (ZIGBEE, 2009) para a comunicação, levando em consideração o contexto

físico computacional do ambiente e dos usuários para realizar tais processamentos.

A facilidade de programação, a arquitetura única, o baixo consumo de energia e a

maior segurança foram alguns dos motivos para a utilização da tecnologia Sun

SPOT no projeto.

O Sun SPOT utiliza um dispositivo do tamanho da palma da mão que é acionado

por um Software Java, com intuito de formar RSSFs. Capacitado com chips ZigBee,

tornando possível a configuração de redes adaptáveis capazes de rotear pacotes

através de qualquer dispositivo e se adaptar à possíveis falhas em qualquer

dispositivo. Aplicações na área de redes de sensores e de computação pervasiva

são potencias utilizações da tecnologia Sun SPOT que são exploradas neste

trabalho.

Estas tecnologias unidas provêm diversas possibilidades de aplicações para

facilitar o dia-a-dia, onde pessoas vão interagir com vários tipos equipamentos

(máquinas, computadores, eletrodomésticos) e também outras pessoas; Sem

perceber toda a complexidade por trás dos serviços utilizados, de forma fácil e

amigável para o usuário final.

28



CAPÍTULO 2: TRABALHOS RELACIONADOS

Neste capítulo serão descritos alguns trabalhos relacionados com o For-All.

2.1. Ninja

O projeto Ninja (GRIBBLE, 2001) possui objetivos semelhantes em termos de

arquitetura, onde procura habilitar uma inovação ampla em serviços distribuídos na

internet. Sua arquitetura consiste de quatro elementos básicos: as bases, que são

poderosos terminais com ambientes aglomerados usando um software como

plataforma que simplifica a construção de serviços; unidades, que são os

dispositivos pelos quais os usuários acessam os serviços; active proxies, são

elementos de transformação que são usados pelas unidades ou adaptação de

serviços específicos; e o path, que é uma abstração. O For-All tem como principais

vantagens uma maior simplicidade e clareza, além da grande abstração que é

provida sobre os protocolos de comunicação (VIEIRA, 2010).

2.2. Projeto Middleware Orientado a Servico

O projeto Middleware Orientado a Servico para uma RSSF (DELICATO, 2004)

propõe um middleware para o desenvolvimento de aplicações utilizando Redes de

Sensores Sem Fio. O projeto visa fornecer uma representação padrão, de alto nível,

para interesses da aplicação, dados gerados pelos sensores e funções de

agregação a serem realizadas na rede. Tal representação é baseada no conceito de

serviços e adota XML (W3C, 2008b) como a linguagem de descrição e codificação.

Simple Object Access Protocol (SOAP) (W3C, 2008a) é adotado como o protocolo

para formatar e transportar as mensagens usando um protocolo de rede subjacente

centrado em dados. Esse projeto contribuiu para o For-All utilização do XML para

comunicação, o que torna muito mais transparente e com a interoperabilidade a

troca de informações.

29



2.3. Aura

O projeto Aura preconiza que o mais precioso recurso em um sistema de

computador não é processador, memória, disco ou rede: é o usuário. Os atuais

sistemas distraem o usuário e, por consequência, reduzem sua efetividade. O Aura

repensa o sistema na tentativa de solucionar esse problema com o objetivo de

prover a cada usuário, independentemente de localização, uma auréola invisível de

computação e serviços de informação (AURA, 2007). A principal contribuição do

projeto Aura foi na maneira de focar com o usuário, dando prioridade em seu

conforto para melhores resultados nas aplicações.

2.4. Gaia

Nesse projeto foi defendida uma visão onde o espaço habitado pelas pessoas

será interativo e programável, chamado de espaços ativos (Active Spaces). Os

usuários interagem com esses espaços (escritórios, casa, carros, etc.) para

requisitar informações, beneficiar-se de seus recursos e configurar seu

comportamento. Para isso, dados e tarefas estão sempre acessíveis e são

mapeados dinamicamente para os recursos solicitados. Gaia coordena as entidades

de software e dispositivos em rede dentro dos espaços ativos, exporta os serviços

para pesquisa e utilização dos recursos, acessar e usar o contexto corrente, e

também fornece um framework para desenvolvimento de aplicações (GAIA, 2007).

2.5. Oxygen

O projeto Oxygen prevê a computação como livre e disponível em qualquer lugar,

como o oxigênio do ar. Baseia-se em uma infra-estrutura de dispositivos

estacionários e móveis, conectados por uma rede se configura automaticamente.

Essa infra-estrutura fornece computação e comunicação em larga escala e são

intrínsecas ao sistema a fim de satisfazerem as necessidades dos usuários

(OXYGEN, 2007).

30



CAPÍTULO 3: O ANTIGO FOR-ALL

Neste capítulo é descrito a plataforma For-All produzida antes que a pesquisa

proposta por esse trabalho fosse iniciada.

3.1. A plataforma

O projeto For-All objetiva a democratização do acesso à informação, oferecendo

os serviços computacionais a qualquer tempo para todas as pessoas nos mais

diversos lugares. Visa à captação rápida de informações sobre mudanças nas

características normais de um ambiente, sendo também capaz de tomar decisões

em tempo hábil, repassando as decisões tomadas instantaneamente para as

pessoas interessadas.

Como estudo de caso, a tecnologia Sun SPOT é utilizada e a idéia é possuir

dispositivos distribuídos, independentes e ao mesmo tempo controlados,

configurados e monitorados pela plataforma For-All, podendo ser adaptados a

quaisquer necessidades que as aplicações venham requisitar.

3.2. Arquitetura Geral

A arquitetura é formada basicamente de agentes gerenciáveis (representados por

Sun SPOTs) que possuem serviços os quais podem ser solicitados a qualquer

momento pelo Gateway (GW). Desta forma, ela é composta por três camadas: a

primeira camada é responsável pela coleta de dados (Camada de Sensoriamento)

do ambiente que são passados para a segunda camada responsável pela tomada

de decisão (Camada de Tomada de Decisão). Na última camada situam-se as

aplicações (Camada de Aplicação) que tanto poderão acessar os dados coletados,

como configurar a tomada de decisão.

FOR-ALL 1.0: UMA PROPOSTA DE ARQUBASEADA NA COMPUTAÇÃO UBÍQUA

Figura

Os Sun SPOTs (Camada de Sensoriame

monitoram características relevantes à aplicação (temperatura, movimentação,

posição, presença de pessoas etc.) e envia

segunda camada que é composta pelas estações base (base stations) ligadas a

computadores pessoais, que por sua vez,

los em informação para transmitir à terceira camada, responsável por distribuí

para os usuários da forma desejada.

UMA PROPOSTA DE ARQUITETURA PARA REDES DE SENSORES SEM FIO

COMPUTAÇÃO UBÍQUA, PERVASIVA E NA ORIENTAÇÃO A SERVIÇOS

Figura 6: Arquitetura Geral do For-All

Os Sun SPOTs (Camada de Sensoriamento), através da tecnologia Zig

características relevantes à aplicação (temperatura, movimentação,

posição, presença de pessoas etc.) e enviam dados pré-processados para a


computadores pessoais, que por sua vez, ficam encarregados de tratar e transformá

los em informação para transmitir à terceira camada, responsável por distribuí

para os usuários da forma desejada.

31

E SENSORES SEM FIO ENTAÇÃO A SERVIÇOS

nto), através da tecnologia ZigBee,

características relevantes à aplicação (temperatura, movimentação,

processados para a


ficam encarregados de tratar e transformá-

los em informação para transmitir à terceira camada, responsável por distribuí-las

FOR-ALL 1.0: UMA PROPOSTA DE ARQUBASEADA NA COMPUTAÇÃO UBÍQUA

3.3. Software Base nos Dispositivos

Figura 7 : Arquitetura do sistema

A camada de serviços separa

categorias, tais como Alarmes, Monitores e outras. Na camada de Comunicação

existe um elemento chamado Communication Manager que recebe todas as

requisições dos dispositivos (rádio, USB) as quais são analisadas e repassadas ao

serviço pertinente. Este funciona como um thread individual. Além disso, o

Communication Manager também é responsável por receber o resultado do serviço

e responder pela mesma via da requisição.

3.4. Operações de Gerência

A Figura 8 apresenta um Diagrama de Classes simplificado com as operações de

gerência dos serviços implementado

implementados são baseados na mesma interface

principais operações que podem ser realizadas com um serviço. Desse serviço duas

variantes foram criadas até o momento, o AbstractMonitor e o AbstractAlarm.

primeiro especifica como devem ser os monitores, entidades responsáveis por estar

UMA PROPOSTA DE ARQUITETURA PARA REDES DE SENSORES SEM FIO

COMPUTAÇÃO UBÍQUA, PERVASIVA E NA ORIENTAÇÃO A SERVIÇOS

Software Base nos Dispositivos

: Arquitetura do sistema básico que é execu tado em cad

A camada de serviços separa-os e agrupa-os de acordo com algumas






a via da requisição.

Operações de Gerência

apresenta um Diagrama de Classes simplificado com as operações de

rência dos serviços implementados até o momento. Todos os serviços

implementados são baseados na mesma interface ServiceIF


variantes foram criadas até o momento, o AbstractMonitor e o AbstractAlarm.


32

E SENSORES SEM FIO ENTAÇÃO A SERVIÇOS

tado em cad a Sun SPOT

os de acordo com algumas






apresenta um Diagrama de Classes simplificado com as operações de

ento. Todos os serviços

ServiceIF. Ela especifica as


variantes foram criadas até o momento, o AbstractMonitor e o AbstractAlarm. O


33



sempre monitorando alguma variável através da coleta de dados. A partir dessa

classe desenvolvemos monitores de temperatura (TemperatureMonitor),

luminosidade (LightMonitor) e movimento (MovimentMonitor). O segundo tipo de

serviço é o Alarme, representado pela classe AbstractAlarm. Esse serviço é sempre

agregado a um monitor. O monitor coleta os dados e o alarme verifica se esses

estão dentro de um limiar aceitável (configurado previamente por parâmetro). Caso

os dados coletados passem do limite estabelecido (seja para mais, ou para menos),

o alarme dispara um alerta para o dispositivo requisitante. Os serviços são sempre

solicitados via Rádio ou USB através da classe Request. O alarme lê os dados da

requisição dos serviços e utiliza um objeto resposta (Response) para gerar o alerta

exatamente para o dispositivo solicitante do serviço.

Figura 8: Diagrama de Classes do For-All

Os dispositivos não precisam ter todos os serviços configurados ao mesmo

tempo, todo serviço deve ser registrado no ServiceRegistry para que outros

dispositivos sempre o encontre quando requisitado pelo CommunicationManager. Só

assim a requisição é passada para o serviço específico que o executa. Se o serviço

gerar uma resposta imediata, a mesma é transformada num objeto Response e

34



passada para o CommunicationManager que irá utilizar o PackageSender para

enviá-la ao dispositivo solicitante do serviço.

Uma demonstração de como um alarme trabalha pode se r visto na Figura 9. Inicialmente o alarme inicia o monitor respectivo (linha 3) para que o

mesmo comece a monitorar a variável desejada (temperatura, por exemplo). De

tempos em tempos, o alarme verifica se o valor monitorado (linha 8) está fora da

faixa limite (linha 9). Caso isso aconteça, o CommunicationManager é acionado para

que um alerta seja enviado (linha 10) ao mesmo dispositivo que solicitou o serviço

(representado pelo objeto alarmRequest). O valor ultrapassado (value) também é

enviado para que haja uma idéia de quanto o limite estabelecido foi violado.

Figura 9: Código de execução de um alarme genérico (AbstractAlarm)

3.5. Resultados e Discussão

Nas implementações iniciais, foram desenvolvidos três serviços básicos: os

serviços dos níveis de temperatura, de luminosidade e de movimentação. Um

terceiro serviço de localização de serviço também (Service Discovery) foi

desenvolvido para possibilitar que SPOTs na região sejam localizados.

Uma pequena aplicação foi desenvolvida onde, através de um computador

pessoal, o usuário pode acessar os SPOTs e requisitar um dos três serviços

disponíveis. Nesta aplicação os serviços são acessados em três etapas.

Primeiramente, como é mostrado na Figura 10, os SPOTs são automaticamente

detectados pelo Service Discovery e apresentados num Painel de Controle.

35



Figura 10: Tela inicial de seleção de serviço e ope ração

Os endereços de cada dispositivo, juntamente com os serviços implementados

são apresentados para escolha do usuário. Serviços recém configurados, ou novos

dispositivos detectados são apresentados no Painel de Controle automaticamente.

Cada serviço é referenciado por seu nome, assim como uma lista de operações

disponíveis para aquele serviço, apresentados pelo nome do método respectivo.

Figura 11: Tela com resultado do monitor de tempera tura

A Figura 11 apresenta o resultado da execução do serviço de monitoramento de

temperatura, após a execução da operação getValue. Neste caso o resultado foi

32,75 graus Celsius. Já na Figura 8, um alarme de temperatura é executado, com o

valor de limite de 25 graus. Neste caso, sempre que a temperatura for maior do que

esse valor, uma mensagem (alarme) é enviada ao solicitante com a temperatura

atual. Neste exemplo a temperatura atual é de 33,25 graus Celsius, juntamente com

o tipo de serviço executado e o SPOT de origem.

36



Figura 12: Tela de resultado do serviço solicitado (alarme de temperatura)

37



CAPÍTULO 4: UMA PROPOSTA PARA O FOR-ALL 1.0

Neste capítulo são descritos os materiais e métodos utilizados para a a

proposta do For-All 1.0.

4.1. Materiais

Os materiais utilizados na implementação e testes foram:

4.1.1 Computador A

• Processador Intel Core 2 Quad

• Memória DDR2 800 4Gb

• Sistema Operacional Open Solaris 2009

4.1.2 Computador B

• Processador AMD Atlhon X2

• Memória DDR 2 667 2Gb

• Sistema Operacional GNU/Linux Debian 4

4.1.3 Sun SPOTs

• Foram utilizados Sun SPOTs na versão 2.0

4.2. For-All 1.0

O For-All 1.0 é uma arquitetura de rede que utiliza os conceitos de uma SOA

para integrar componentes que facilitem o processo de criação e montagem de

ambientes capazes de serem controlados e monitorados, ditos ambientes

inteligentes. Uma das principais finalidades da arquitetura é abstrair os protocolos de

comunicação utilizados entre os componentes e a aplicação utilizadora dos serviços

e os componentes, permitindo um maior foco no desenvolvimento do próprio

ambiente.

A arquitetura propõe a invisibilidade lógica da camada de sensoriamento, ou

seja, os serviços tem a possibilidade de serem implementados de tal forma a não

necessitarem da interação do usuário para tomarem uma ação. Propõe também a

mobilidade dessa camada, uma vez que os agentes podem estar imersos dentro de

38



dispositivos adequados a Redes de Sensores sem Fio. Dessa forma, a plataforma

possibilita a pervasividade e ubiqüidade da computação envolvida e se torna base

para a implantação de ambientes inteligentes.

4.3. Visão Geral da Arquitetura

A arquitetura é composta de quatro componentes intercomunicantes e, ao

mesmo tempo, independentes: agente, comunidade, gateway e aplicação. Esses

quatro componentes podem ser considerados camadas da arquitetura e cada um

tem finalidades específicas (VIEIRA, 2010).

39



Figura 13: Visão geral da arquitetura e suas camada s (VIEIRA, 2010)

A primeira e mais baixa das camadas é a dos Agentes, responsável por ser a

camada de sensoriamento, ou seja, pela coleta de dados do ambiente. Quando

incorporados a outros dispositivos, os agentes tornam estes acessíveis, portanto

controláveis e configuráveis. (VIEIRA, 2010)

A segunda camada é a camada das Comunidades, entidades capazes de

comunicar-se com os agentes seja qual for o protocolo utilizado. Essa camada tem

40



como principal finalidade a agrupação de agentes em uma entidade maior,

permitindo assim um melhor acesso e distribuição da camada anterior (VIEIRA,

2010).

A terceira camada é a camada do Gateway. Esta é responsável por agrupar as

comunidades e permitir a ela um acesso externo, ou seja, o gateway tem que ser

acessível pelos protocolos Transmission Control Procotol e Internet Protocol

(TCP/IP) (IETF, 1981) e é um elo de aplicações finais e os serviços disponibilizados

pelos agentes (VIEIRA, 2010).

A quarta e última camada é a das Aplicações. Essa camada tem como finalidade

se comunicar com os gateways e expor ao usuário as comunidades, agentes e

serviços cadastrados naquele gateway (VIEIRA, 2010).

4.4. Visão Detalhada das Camadas da Arquitetura

Nesta seção serão detalhadas todas as camadas da arquitetura e suas

especificações.

4.4.1. Agente

Os agentes são entidades que possuem serviços que serão disponibilizados pela

plataforma. Estes podem ser incorporados a outros dispositivos permitindo um

acesso e controle. Estes dispositivos podem ser equipamentos comuns que são

encontrados em um ambiente normal (micro-ondas, tvs, geladeiras, etc.) e os

agentes, uma vez inseridos, permitirão uma interação com estes.

Cada serviço deve ter uma identificação única entre os serviços de um mesmo

agente, mas sua identificação pode ser igual a identificação dos serviços de outros

agentes. Essa identificação deve ser um número inteiro sequencial. Além disso, um

serviço deve conter uma descrição e um nome. Este possui ao menos três

interações: iniciar, parar e executar uma ação. Esses três acessos devem ter

permissão apenas para serem controlados pelo agente que possui o serviço, sendo

o agente que intermedia a solicitação de serviços e a execução destes. O acesso de

execução de uma ação deve ter a possibilidade de ter entrada de dados a serem

41



processados e uma resposta deve ser retornada. O agente deve enviar essa

resposta ao solicitante.

Um agente deve ser registrado em uma única comunidade (vide tópico 4.4.2) e

conter uma identificação também única entre os agentes dessa comunidade. Essa

identificação será atribuída pela comunidade no ato do registro e será um número

inteiro. Além da identificação, o agente deverá conter um nome, uma descrição e

todos os serviços a serem disponibilizados.

O agente registra-se em alguma comunidade para poder ser acessível. Esse

pacote de registro a ser enviado deve conter seu nome, sua descrição e todos os

seus serviços disponíveis e deve ser a primeira ação a ser feita antes de qualquer

outra troca de mensagem. Em resposta a um sucesso no registro, o agente deve

receber sua identificação em relação àquela comunidade.

Para uma solicitação de serviço, a comunidade enviará um pacote que conterá a

identificação do serviço solicitado e parâmetros para esse serviço. Como resposta à

solicitação, o agente deve enviar um pacote com o resultado do processamento do

serviço.

O protocolo utilizado de comunicação agente-comunidade deverá ser feito

através de Redes de Sensores sem Fio para dá uma maior mobilidade aos agentes.

A comunicação com outros agentes deve ser feita apenas através da

comunidade ao qual o agente solicitado está cadastrado e essa comunicação deve

ser uma solicitação de serviço feita à comunidade. Não existe comunicação direta

com qualquer outra camada sem ser por intermédio da camada das comunidades.

A identificação em relação a outros agentes será dada pela comunidade por um

número inteiro. A identificação única será apenas em relação aos agentes

registrados em uma determinada comunidade, mas pode ser a mesma em relação a

agentes registrados em comunidades diferentes.

4.4.2. Comunidade

As comunidades são entidades responsáveis por agrupar os agentes. Sua

principal função é ser um elo entre o gateway (GW) e os serviços disponibilizados

pela camada inferior.

42



Uma comunidade deve ser registrada em um único GW e conter uma

identificação também única entre as comunidades desse GW. Essa identificação

será atribuída pelo GW no ato do registro e será um número inteiro. Além da

identificação, deverá conter um nome, uma descrição e todas as comunidades

registradas.

A comunidade receberá solicitações de registros dos agentes. Essa solicitação

deverá conter: nome, descrição e serviços disponibilizados e tem a opção de aceitar

ou não a solicitação de registro, após isso uma resposta deverá ser enviada. Em

caso de não aceitação, um pacote com essa informação deverá ser enviada e em

caso de aceitação um pacote com essa informação e uma identificação para o

agente entre os agentes registrados nessa.

Solicitações de serviços serão enviadas ao agente que detém o serviço com a

identificação do serviço solicitado e os parâmetros utilizados. O agente enviará uma

resposta com o resultado do processamento do serviço solicitado.

A comunidade registra-se em algum gateway para poder ser acessível e prover

acesso aos agentes nela registrados. Esse pacote de registro a ser enviado deve

conter seu nome, sua descrição e todos os seus agentes registrados e deve ser a

primeira ação a ser feita antes de qualquer outra troca de mensagem com o

gateway. Em resposta a um sucesso no registro, a comunidade deve receber uma

identificação em relação aquele GW.

O GW fará solicitações de serviços à comunidade. Essa solicitação conterá qual

o serviço solicitado (identificação do agente + identificação do serviço no agente) e

os parâmetros a serem passados ao serviço. A solicitação será enviada ao agente

que detém o serviço e a resposta recebida dele deverá ser enviada ao gateway

solicitante.

O protocolo utilizado deverá ser o TCP/IP onde o gateway aguarda conexões em

uma determinada porta.

A identificação da comunidade em relação a outras camadas será dada pelo GW

por um número inteiro. A identificação única será apenas em relação às

comunidades registradas em um determinado gateway, mas pode ser a mesma em

relação a comunidades registradas em gateways diferentes.

43



4.4.3. Gateway

Os gateways tem como principal finalidade prover acesso às comunidades com

seus agentes e respectivos serviços. Sua principal característica é ser acessível

pelas aplicações e pelas comunidades pelo protocolo TCP/IP.

Esses componentes tem como identificação um número IP e uma porta por onde

requisições de aplicações e comunidades devem ser tratadas, além de um nome e

uma descrição.

Na comunicação com a camada inferior, o gateway faz solicitações de registros

das comunidades. Essa solicitação deverá conter: nome, descrição e os agentes

com seus respectivos serviços disponibilizados. O GW tem a opção de aceitar ou

não a solicitação de registro e uma resposta deverá ser enviada. Em caso de não

aceitação, um pacote com essa informação deverá ser enviado e em caso de

aceitação um pacote com essa informação e uma identificação para a comunidade

entre as outras comunidades registradas nesse GW (essa identificação deverá ser

um número inteiro). Solicitações de serviços serão enviadas à comunidade que

detém o agente e serviço solicitado com a identificação do serviço e os parâmetros

utilizados. A comunidade enviará uma resposta com o resultado do processamento

do serviço solicitado. O protocolo utilizado para comunicação com as comunidades é

o TCP/IP onde o gateway deverá aguardar conexões em uma determinada porta.

A aplicação fará solicitações de serviços. Essa solicitação conterá qual o serviço

solicitado (identificação da comunidade + identificação do agente + identificação do

serviço no agente) e os parâmetros a serem passados ao serviço. A solicitação

deverá ser enviada à comunidade que detém o agente solicitado e a resposta

recebida dela deverá ser enviada à aplicação solicitante.

O protocolo utilizado deverá ser o TCP/IP onde o gateway estará esperando

conexões em uma determinada porta. Não há comunicação do gateway com outras

camadas exceto a das comunidades e aplicações.

4.4.4. Aplicações

A camada de aplicações é a camada solicitante de serviços. Essas solicitações

devem ser enviadas ao gateway.

44



Solicitações de serviços serão enviadas à comunidade que detém o agente e

serviço solicitado com a identificação do serviço e os parâmetros utilizados. A

comunidade enviará uma resposta com o resultado do processamento do serviço

solicitado. Não há comunicação com qualquer outra camada exceto a dos gateways.

4.5. Comunicação entre as camadas

Figura 14: Detalhamento da comunicação entre as cam adas (VIEIRA, 2010)

A comunicação deve ser feita através de entidades denominadas pacotes. As

solicitações de serviços serão pacotes menores com valores próprios a serem

enviados dentro dos pacotes de comunicação.

Os pacotes de comunicação devem ser organizados em uma estrutura de

arquivos XML, de forma que se possa recuperar facilmente o conteúdo transmitido e

as informações possam ser organizadas hierarquicamente.

Os pacotes devem conter um tempo de vida "X", de 300 segundos. Após esse

tempo o pacote deverá expirar, passando a não ter qualquer valor para a entidade.

Uma identificação entre outros pacotes em uma determinada entidade e essa

identificação deverá ser única durante o período "2X" (duas vezes o tempo de vida

do pacote) para evitar conflitos. Essa identificação deverá ser um número inteiro.

Cada pacote deverá informar se é resposta de algum outro pacote. Caso a

resposta seja positiva, a identificação do pacote ao qual ele é resposta deve ser

incluída. Caso a resposta seja negativa, um valor padrão indicando que ele não é

resposta de nenhum outro pacote deve ser incluído. Além disso, deverá conter um

campo com o valor da mensagem enviada e uma sub-identificação que informará

qual o tipo de pacote. Os valores possíveis são: login, logout, solicitação de serviço,

resposta de solicitação de serviço, mensagem.

Para o pacote de solicitação de serviços, a identificação do serviço será dada

pela junção das identificações de: comunidade, agente, serviço, ou seja, a

45



identificação de um serviço se dá de forma hierárquica. Além disso, o pacote conterá

um campo para serem enviados parâmetros ao serviço solicitado e um campo valor

de resposta será preenchido pelo agente com a resposta do serviço e o mesmo

pacote será enviado de volta ao solicitante.

4.6. Visão de Implantação

É importante ressaltar que o gateway utilizado na comunicação precisa ter um

endereço de IP público, acessível externamente ao ambiente do sistema. Ainda é

necessário que as aplicações localizadas nos gateways devem ser executadas como

serviços, para garantir que estejam sempre disponíveis a qualquer momento durante

um longo intervalo de tempo.

46



CAPÍTULO 5: IMPLEMENTAÇÃO PARCIAL

Nesta seção estão descritas quais partes da arquitetura foram implementadas

e de que forma.

A plataforma implementada parcialmente teve a construção das quatro

camadas, porém não foram seguidas todas as especificações. O objetivo da

implementação foi ter um exemplo prático do funcionamento do For-All e montar um

básico ambiente inteligente. Toda a implementação foi feita utilizando a linguagem

de programação Java (ORACLE, 2010).

A camada dos agentes foi construída tendo como base o Sun SPOT e suas

especificações. O agente se registra em uma comunidade enviando as informações

sobre seus serviços disponíveis.

Cada serviço possui um nome, uma descrição e lista de argumentos a serem

passados. Utilizando os sensores de movimentação, luminosidade e temperatura,

foram implementados dois tipos de serviços para cada sensor:

• Monitor: responsável por capturar dados do ambiente;

• Alarme: responsável por verificar se os dados capturados estão dentro

de limiares permitidos, caso contrário um evento de alarme é

disparado.

A camada das comunidades foi construída tendo como base de comunicação

a base-station do Sun SPOT. Esse base-station é responsável pela transferência

dos dados entre a comunidade e o agente. Cada instância dessa camada possui

identificação, descrição e lista de agentes cadastrados. A comunidade se comunica

com o gateway através de uma conexão TCP/IP e esta manda as informações de

agentes e serviços disponíveis.

O gateway recebe conexões das comunidades para o registro e guarda essas

conexões para a comunicação. Essa camada tem uma lista de comunidades com

todas as informações de agentes e serviços disponíveis para que as aplicações

possam ter acesso. Aplicações fazem conexão TCP/IP e fazem a solicitação de

serviço indicando a comunidade, o agente e o serviço desejado e recebe a resposta

do resultado do processamento do serviço. O pacote de comunicação é uma classe

Java e é enviada através de fluxo de bytes.

47



A aplicação desenvolvida tem como entrada inicial o IP do gateway para a

conexão. Ao estabelecer a conexão, a aplicação recebe do gateway todas as

informações de comunidades, agentes e serviços disponíveis, preenchendo a tela e

deixando-as acessíveis para a escolha do usuário. Ao selecionar a comunidade, são

exibidos seus respectivos agentes. Ao selecionar um agente são exibidos seus

respectivos serviços.

Figura 15: Aplicação desenvolvida para solicitação de serviços

48



CAPÍTULO 6: RESULTADOS E DISCUSSÃO

Nesta seção serão apresentados os resultados e a discussão sobre eles.

Figura 16: Resultado de uma consulta de temperatura

Como validação da arquitetura parcialmente implementada, foi posicionado

um agente - utilizando Sun SPOT – na sala do Programa de Educação Tutorial do

Bacharelado em Ciência da Computação (PET.Com), situado no Departamento de

Informática (DI) da Universidade Federal da Paraíba (UFPB). Uma solicitação de

temperatura foi feita e a resposta foi recebida com o valor de 33.5 graus Celsius com

tempo inferior a 1 segundo. Como trata-se de um piloto, a resposta foi adequada e

dada em um tempo razoável, porém otimizações precisam ser feitas.

O teste da aplicação cliente foi feito utilizando o Computador A (vide

materiais): Para o gateway, comunidade e agente foi utilizado o Computador B (vide

materiais):

49



CONCLUSÕES

Neste trabalho foram apresentados a pesquisa e o desenvolvimento parcial

de uma arquitetura ubíqua, pervasiva e orientada a serviços para o suporte a criação

e montagem de ambientes inteligentes.

Com o For-All será possível utilizar agentes para diversos tipos de fins, tais

como segurança (monitoramento de temperatura, movimentação), comodidade

(nível de caixa de água, possibilitando a informação à distância da falta do

abastecimento de água) e até mesmo a incorporação de dispositivos encontrados

em ambientes comuns (tv, luz, geladeira, etc) à Internet (inovação), proporcionando

o acesso e o controle destes. Na criação de ambientes inteligentes, o For-All surge

como alternativa para a abstração de problemas encontrados na comunicação e

arquitetura do local, proporcionando um maior foco no ambiente em si e nos seus

serviços. A plataforma provê uma abstração sobre os protocolos de comunicação e

proporciona a criação e montagem de ambientes inteligentes de forma simples e

eficaz.

Pôde ser feito um estudo comparativo com outros trabalhos relacionados e o

For-All aproveitou alguns pontos fortes de cada um deles e o que o torna prático e

com abstração de algumas dificuldades devido a clareza de sua arquitetura.

O For-All permite a utilização de qualquer tipo de agente, desde que ele tenha

a capacidade de comunicação com a comunidade. Isso favorece o acoplamento de

vários dispositivos já existentes à arquitetura, sua manutenibilidade e permite um

horizonte mais vasto de tecnologias a serem utilizadas.

Apesar da não completude no seu desenvolvimento, foi possível perceber que

a arquitetura proposta é válida devido aos bons resultados nas implementações

iniciais, porém sua completa implementação e implantação se faz necessária para a

detectação de possíveis incoerências, não eficiência ou até mesmo falhas.

50



REFERÊNCIAS

ADELSTEIN, F.; GUPTA, K. Fundamentals of Mobile and Pervasive Computing. Mc Graw-Hill. 2005. ARAÚJO, R. B. Computação Ubíqua: Princípios, Tecnologias e Desafios. In: Simpósio Brasileiro de Redes de Computadores. XXI. 2003. Natal, RN. ARAYA, A. Questioning ubiquitous computing. In: Proceedings of the 1995 ACM 23rd annual conference on Computer science. 1995. Nashville, TN, USA. AURA, project. Disponível em: <http://www.cs.cmu.edu/~aura/>. Acesso em: 20 nov. 2010. AVELAR, P., GARCIA, R. A Engenharia Clínica no Cenário da Computação Ubíqua. In: 21º Congresso Brasileiro de Engenharia Biomédica. 2008. Salvador, BA. CAHILL, A.; KINDBERG, T., NOBLE, B. Building and evaluating ubiquitous system software. IEEE Pervasive Computing. P. 20-21. 2004 CARLESSO, R. S. Redes de Sensores Sem Fio. Montes Claros. Universidade Estadual de Montes Claros. 2006. DELICATO, F., PIRES, P., LAGES, A., REZENDE, J., PIMEZ, L. Middleware orientado a serviços para redes de sensores sem fio. In: Simpósio Brasileiro de Redes de Computadores. 2003. Natal, RN. ENDREI, M., ANG, J., ARSANJANI, A., CHUA, S., COMTE, P., KROGDAHL, P., LUO, M., NEWLING, T. Patterns: Service-Oriented Architecture and Web Services. 1. ed. Redbooks. 2004. ERICK, U. P., HUGH, T. Understanding Enterprise SOA. Manning Publications. 2006. ESCOBEDO, E. P., KOFUJE, S. T. Introdução a Ambiente Inteligente. In Workshop de Redes de Sensores Sem Fio. Santos, São Paulo, SP. 2006. Disponível em: <http://www.pad.lsi.usp.br/humanlab/workshop.html>. Acesso em: 4 jun. 2009 GAIA, project. Disponível em: <http://gaia.cs.uiuc.edu/>. Acesso em: 20 nov. 2010. GEYER, C. F. R. Projeto GRADEp: Middleware para gerenciar um ambiente de grade pervasiva. In:Rede Nacional de Ensino e Pesquisa, Grupo de Trabalho (GT). 2005. Disponível em: <http://www.rnp.br/pd/gts2004-2005/grade_pervasiva.html>. Acesso em: 23 abril 2009. GRIBBLE, S. D. et. Al. The Ninja Architecture for Robust Internet-Scale Systems and Services. University of California at Berkeley. 2001. Disponível em:

51



<http://www.eecs.umich.edu/~zmao/Papers/ninjaArch.pdf>. Acesso em: 10 mai. 2009. IETF - The Internet Engineering Task Force. Transmission Control Protocol. 1981. Disponível em: <http://tools.ietf.org/html/rfc0793>. Acesso em: 24 nov. 2010. JOSUTIS, M. SOA in Pratice. The Art of Distributed System Design. 1. ed. O´Reilly. 2007. KODALI, R. R. What is Service-Oriented Architecture. 2008. Disponível em: <http://www.javaworld.com>. Acesso em: 11 ago. 2008. LOKE, S. Context-Aware Pervasive Systems: Architectures for a New Breed of Applications. 1. ed.. Auerbach Publications, 2007 LOUREIRO, A. A. F. et. AL. Redes de Sensores Sem Fio. In: Simpósio Brasileiro de Redes de Computadores. 2003. Natal, RN. LOUREIRO, A.; RUIZ, L.; NOGUEIRA, J.M.; R. MINI; NAKAMURA, E.; FIGUEIREDO, C. M.. Mini-curso: Redes de Sensores sem Fio. In: Jornada de Atualização em Informática - XXII Simpósio Brasileiro de Computação. 2002. Florianópolis, SC. LYYTINEN, K.; YOO, Y. Issues and Challenges in Ubiquitous Computing. Communications of the ACM. n. 12, p. 63-65. 2002. MELOAN, S. Toward a Global “Internet of Things”. 2003. Disponível em: <http://java.sun.com/developer/technicalArticles/Ecommerce/rfid/>. Acesso em: 10 fev. 2010. OASIS, C. Reference model for service oriented architecture. Version: 1.0. Technical report. 2006. ORACLE. Plataforma Oracle Java Standard Edition (JavaSE). 2010. Disponível em: <http://www.oracle.com/technetwork/java/javase/overview/index.html>. Acesso em: 24 nov. 2010. OTHMAN, N. Y., GLITHO, R. H., KHENDEK, F. The design and implementation of a web service framework for individual nodes in sink-less wireless sensor networks. In: IEEE Symposium on Computers and Communications. 2007 OXYGEN, project. Disponível em: <http://oxygen.csail.mit.edu/>. Acesso em: 20 nov. 2010. REMAGNINO, P., FORESTI, G.L., Ambient Intelligence: A New Multidisciplinary Paradigm. IEEE Transactions on Systems, Man and Cybernetics, Part A, Volume 35. p. 1-6. 2005.

52



SAHA, D., MUKHERJEE, A. Pervasive computing: a paradigm for the 21st century. In: IEEE Computer, v.36, n.3, p. 25–31, 2003. SARANUMMI, N. IT Applications for Pervasive, Personal, and Personalized Health. IEEE Transactions on Information Technology in Biomedicine, vol. 12, nº 1. 2008. SIORPAES, S., BROLL, G., PAOLUCCI, M., RUKZIO, E., HAMARD, J., WAGNER, M. e SCHMIDT, A. Mobile Interaction with the Internet of Things. In: International Conference on Pervasive Computing. 2006. Dublin, Irlanda. SUN Microsystems. Sun SPOT Project. 2009. Dispinível em: <http://www.sunspotworld.com>. Acesso em: 10 março 2009. VIEIRA, E. S. F., NEGREIROS, A. L. V. BRITO, A. V. For-All - Uma Plataforma para Sistemas Pervasivos Orientados a Serviço. In: Simpósio Brasileiro de Computação Ubíqua e Pervasiva. 2010. Minas Gerais, BH. W3C - World Wide Web Consortium. Simple Object Access Protocol (SOAP). Version 1.1. 2008. Disponível em: <http://www.w3.org/tr/soap/>. Acesso em: 12 maio 2008. W3C - World Wide Web Consortium. Extensible Markup Language (XML). Version 1.0. 2008. Disponível em: <http://www.w3.org/tr/rec-xml>. Acesso em: 10 out. 2008. WEISER, M. The Computer For TheTwenty-First Century. In Scientific American. p. 94-104, set, 1991. YAMIN, A. Arquitetura para um Ambiente de Grade Computacional Direcionado as Aplicações Distribuídas Móveis e Conscientes do Contexto da Computação Pervasiva. Tese (Doutorado em Ciência da Computação). Universidade Federal do Rio Grande do Sul, Porto Alegre, RS. 2004. YAMIN, A., AUGUSTIN, I., BARBOSA, J., SILVA, L., REAL, R., CAVALHEIRO, G. GEIYER, C. Towards merging context-aware, mobile and grid computing. In International journal of high performance computing applications. 2003, Londres, Reino Unido. ZIGBEE Alliance. 2009. Wireless Control that Simply Works. Disponível em: <http://www.zigbee.org>. Acesso em: 10 março 2009.

Documents

UNIVERSIDADE FEDERAL DA PARAÍBA CENTRO DE … · Computação Pervasiva centraliza suas aplicações no usuário, formando um ambiente de computação comunicável e distribuída