DroidLar - Automac¸ao residencial atraves de um celular android.pdf

Michel Vinicius de Melo Euzebio

DroidLar - Automacao residencial atraves de umcelular Android

Sao Jose – SC

agosto / 2011

Michel Vinicius de Melo Euzebio

DroidLar - Automacao residencial atraves de umcelular Android

Monografia apresentada a Coordenacao doCurso Superior de Tecnologia em Sistemasde Telecomunicacoes do Instituto Federal deSanta Catarina para a obtencao do diploma deTecnologo em Sistemas de Telecomunicacoes.

Orientador:

Prof. Emerson Ribeiro de Melo, Dr.

CURSO SUPERIOR DE TECNOLOGIA EM SISTEMAS DE TELECOMUNICACOES

INSTITUTO FEDERAL DE SANTA CATARINA

Sao Jose – SC

agosto / 2011

Monografia sob o tıtulo “DroidLar - Automacao residencial atraves de um celular An-

droid”, defendida por Michel Vinicius de Melo Euzebio e aprovada em 12 de agosto de 2011,

em Sao Jose, Santa Catarina, pela banca examinadora assim constituıda:

Prof. Emerson Ribeiro de Melo, Dr.Orientador

Prof. Tiago Semprebom, M. Eng.IFSC

Prof. Marcos Moecke, Dr. Eng.IFSC

As pessoas raramente reconhecem a oportunidade

porque ela surge disfarcada em trabalho arduo.

H. L. Mencken

Agradecimentos

Dedico meus sinceros agradecimentos a Deus e a minha famılia que me deram forca para

vencer os obstaculos e chegar ate aqui.

Agradeco tambem ao professor Emerson, que me proporcionou um grande aprendizado me

orientando nas bosas de iniciacao tecnologica e tambem nesse trabalho, que me ajudaram a

encontrar a direcao que eu deveria seguir na minha vida profissional. Por fim, agradeco aos

amigos e colegas que convivi nesses anos de curso.

Resumo

Sistemas de automacao residencial permitem que os usuarios controlem os eletroeletronicosde sua residencia atraves de interfaces de controle como paineis afixados em paredes. Apopularizacao dos telefones inteligentes se deu pelo fato de possuırem configuracoes de hard-ware superiores aos telefones convencionais, e tambem sistemas operacionais complexos quepermitem o desenvolvimento de aplicacoes mais sofisticadas. O sistema operacional Androide um projeto de codigo aberto desenvolvido para dispositivos moveis e por isso esta presenteem diversos telefones inteligentes. O protocolo ZigBee e utilizado em redes sem fio de baixataxa de transmissao e possibilita uma economia de energia por parte dos transmissores. Astransmissoes na rede ZigBee nao possuem longo alcance porem, nesse protocolo e possıvelque os transmissores encaminhem as mensagens da rede aumentando a extensao desta. Nessetrabalho e apresentado o DroidLar, um sistema de automacao residencial completo que utilizauma aplicacao rodando em telefones Android como interface de controle. Os controladores dedispositivos desse sistema se comunicam por uma rede ZigBee.

Abstract

Home automation systems allow the users to control of electronics of a residence throughcontrol interfaces like fixed panels on the walls. The smart phones become popular becausehave superior hardware settings compared to conventional mobile phones and because havemore complex operating systems allowing development of sophisticated applications. The ope-rating system Android is an open source project developed for mobile devices and is present inso many smart phones. The ZigBee protocol is used in wireless networks with low transmis-sion rate and provides energy safe by the transmitters. The transmissions in ZigBee networksdon’t have long-range but this protocol allows the transmitters forward messages in network,increasing the length it. In this paper we presents the DroidLar, a complete home automationsystem that uses an application running on Android phones as a control interface. The devicescontroller of this system communicate over a ZigBee network.

Sumario

Lista de Figuras

Lista de Tabelas

1 Introducao p. 12

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

1.3 Organizacao do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

2 Revisao Bibliografica p. 15

2.1 Automacao Residencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.1.1 X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.1.2 Insteon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

2.1.3 Z-Wave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

2.1.4 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

2.1.5 Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.2 Padrao IEEE 802.15.4 e ZigBee . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.2.1 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

2.3 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

2.4 XBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32

2.5 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32

3 DroidLar p. 35

3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35

3.1.1 Controladores de Dispositivos . . . . . . . . . . . . . . . . . . . . . p. 35

3.1.2 SAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37

3.1.3 Cliente Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40

3.2 Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.2.1 Cliente Android – SAR . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.2.2 Cliente Android – SAR – Controladores . . . . . . . . . . . . . . . . p. 46

3.2.3 SAR – Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

3.3 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

4 Conclusoes p. 53

4.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

Lista de Abreviaturas p. 55

Referencias Bibliograficas p. 57

Lista de Figuras

2.1 Transmissao sincronizada no nıvel zero AC (EUROX10, 2011). . . . . . . . . p. 16

2.2 Transmissao nas tres fases (EUROX10, 2011). . . . . . . . . . . . . . . . . . p. 17

2.3 Topologia da rede Insteon (DARBEE, 2005). . . . . . . . . . . . . . . . . . p. 19

2.4 Mensagens do protocolo Insteon. . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.5 Quadro de mensagem(IEEE, 2006). . . . . . . . . . . . . . . . . . . . . . . p. 26

2.6 Pilha do protocolo ZigBee. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

2.7 Topologias da rede ZigBee. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

2.8 Elementos de um kit Arduino (HERRADOR, 2009). . . . . . . . . . . . . . p. 30

2.9 Codigo para piscar um LED no Arduino. . . . . . . . . . . . . . . . . . . . . p. 31

2.10 Configuracao de modulos no X-CTU . . . . . . . . . . . . . . . . . . . . . . p. 33

2.11 Arquitetura do Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

2.12 Aplicacao Android utilizando Java e XML. . . . . . . . . . . . . . . . . . . p. 34

3.1 Elementos do DroidLar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

3.2 Prototipos do DroidLar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

3.3 Configuracao dos circuitos nos Kits. . . . . . . . . . . . . . . . . . . . . . . p. 37

3.4 Interface principal e de configuracao do SAR . . . . . . . . . . . . . . . . . p. 40

3.5 Interfaces para configuracao dos dispositivos e perfis . . . . . . . . . . . . . p. 41

3.6 Mensagem de controle padrao. . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.7 Mensagem de controle usada na autenticacao. . . . . . . . . . . . . . . . . . p. 42

3.8 Mensagem de autenticacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43

3.9 Mensagem de requisicao das informacoes de todos os dispositivos. . . . . . . p. 43

3.10 Mensagem de requisicao das informacoes de dispositivos pelo tipo. . . . . . . p. 44

3.11 Mensagem de requisicao do ID da lista de perfis. . . . . . . . . . . . . . . . p. 44

3.12 Mensagem de atualizacao de perfis. . . . . . . . . . . . . . . . . . . . . . . p. 45

3.13 Mensagem de requisicao da lista de perfis. . . . . . . . . . . . . . . . . . . . p. 45

3.14 Mensagem de configuracao dos nomes. . . . . . . . . . . . . . . . . . . . . p. 45

3.15 Mensagem de configuracao da varredura periodica. . . . . . . . . . . . . . . p. 46

3.16 Mensagem de controle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

3.17 Mensagem de varredura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

3.18 Mensagem com as informacoes. . . . . . . . . . . . . . . . . . . . . . . . . p. 48

3.19 Mensagem de atualizacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

3.20 Diagrama de casos de uso da aplicacao. . . . . . . . . . . . . . . . . . . . . p. 49

Lista de Tabelas

2.1 Comparativo entre os protocolos. . . . . . . . . . . . . . . . . . . . . . . . . p. 25

12

1 Introducao

1.1 Motivacao

Os sistemas de automacao residencial presentes atualmente no mercado oferecem como

interfaces de controle paginas Web que podem ser acessadas de qualquer computador pes-

soal. Com a disseminacao dos telefones celulares em todo mundo, tornou-se possıvel que eles

tambem tivessem acesso a essas paginas Web, porem, com uma interface mais simples por conta

das limitacoes de hardware e software desses telefones.

O surgimento dos telefones inteligentes possibilitou uma melhor utilizacao de dispositivos

moveis como interfaces de controle para sistemas de automacao residencial. Esses telefones

possuem recursos como maior quantidade de memoria e poder de processamento, aliados a

sistemas operacionais mais sofisticados, se comparados ao celulares comuns.

Esse trabalho foi motivado pela possibilidade de utilizar uma aplicacao rodando em celula-

res Android (OPEN HANDSET ALLIANCE, 2008) como interface de controle de um sistema

de automacao residencial, a fim de substituir as limitadas paginas Web utilizadas pelos siste-

mas atuais. A utilizacao de aplicacoes em telefones inteligentes possibilita usufruir de recursos

como manipulacao de arquivos, reproducao de audio e vıdeo, alem de construcao de interfaces

graficas avancadas com uma facilidade maior do que em paginas Web.

O protocolo ZigBee (ZIGBEE ALLIANCE, 2005) possibilita a criacao de redes sem fio que

nao exijam uma taxa de transferencia alta. Por isso, os dispositivos que se comunicam utilizando

esse protocolo necessitam de pouca energia para operar. Uma das causas dessa economia e o

curto alcance das transmissoes. Porem, o ZigBee previne essa limitacao permitindo que os nos

da rede possam encaminhar as mensagens uns aos outros.

Sistemas de automacao residencial contem dispositivos que sao conectados aos eletroe-

letronicos da residencia e executam efetivamente os comandos do usuario. Esses dispositivos

precisam estar disponıveis o tempo todo para receberem as mensagens da rede e executar os

comandos. As caracterısticas apresentadas pelo protocolo ZigBee sao ideias para sistemas de

1.2 Objetivos 13

automacao residencial, e por isso ele foi utilizado nesse trabalho.

1.2 Objetivos

Este trabalho tem o objetivo de apresentar o DroidLar, um sistema de automacao residen-

cial controlado por telefones Android que contem recursos semelhantes aos apresentados pelos

sistemas encontrados no mercado. No desenvolvimento desse trabalho os seguintes objetivos

especıficos foram propostos:

• Desenvolvimento de um dispositivo capaz de controlar os eletronicos de uma residencia

com a utilizacao de kits Arduino que se comuniquem pela rede ZigBee;

• Desenvolvimento de uma aplicacao servidora que encaminhe mensagens provenientes da

aplicacao cliente pela rede IP para os controladores de dispositivos pela rede ZigBee.

Essa aplicacao tambem permite a execucao de comandos agendados pelo usuario;

• Desenvolvimento de uma aplicacao cliente que rode em telefones Android e sirva como

interface de controle para os eletronicos da residencia. Essa aplicacao tambem possibilita

o agendamento de comandos no servidor.

1.3 Organizacao do texto

O texto esta organizado da seguinte forma: No Capıtulo 2 sao descritos os principais pro-

tocolos utilizados em sistemas de automacao residencial, como tambem produtos comerciais

que as utilizam. E estudada tambem a plataforma Arduino. Iniciando com suas principais ca-

racterısticas, sua integracao com redes ZigBee atraves do modulo XBee e terminando com um

exemplo de codigo.

Outro assunto abordado nesse capıtulo e o protocolo ZigBee. E feita uma analise de sua

arquitetura e tambem descrito seu funcionamento, os papeis de cada tipo de dispositivo na rede

e tambem, os motivos pela sua utilizacao nesse trabalho ao inves de outros protocolos de rede

mais populares. Alem desses assuntos, tambem e apresentado o sistema operacional Android,

sua arquitetura e a estrutura basica de uma aplicacao.

No Capıtulo 3 e apresentado o DroidLar, o sistema de automacao residencial resultante

desse trabalho. Inicialmente e descrita a sua arquitetura e as tecnologias utilizadas em cada

parte do sistema. Posteriormente e estudado o protocolo utilizado na comunicacao do sistema

1.3 Organizacao do texto 14

atraves da analise das possıveis sequencias de mensagens trocadas na rede. E finalizando o

capıtulo, sao apresentadas as possıveis acoes que um usuario pode executar enquanto estiver

utilizando o sistema. Por fim, no Capıtulo 4 serao apresentadas as conclusoes desse trabalho e

tambem os trabalhos futuros que podem ser desenvolvidos a partir deste.

15

2 Revisao Bibliografica

2.1 Automacao Residencial

Sistemas de automacao sao sistemas capazes de executar comandos, obter medidas, regular

parametros e controlar funcoes automaticamente. Esses sistemas comecaram a ser utilizados

na decada de 70 em aplicacoes industriais. Consolidados no setor industrial sua utilizacao

expandiu-se tambem para o comercio com o surgimento dos chamados “predios inteligentes”,

originando os sistemas de automacao predial (PINHEIRO, J. M. S., 2004).

A automacao predial consiste em equipar predios, normalmente com funcoes comerciais,

com sistemas automatizados de iluminacao, seguranca, ar condicionado, controle de acessos

e etc. Apenas na decada de 90, com o avanco das tecnologias computacionais e das redes

de comunicacao, os sistemas usados em predios comecaram a ser utilizados tambem em do-

micılios, dando origem a automacao residencial (PINHEIRO, J. M. S., 2004).

A automacao residencial tem como principais objetivos fornecer conforto e comodidade

aos usuarios, porem ela tambem pode ser utilizada para outros objetivos como a economia e

a seguranca. Esses sistemas sao tipicamente formados por um dispositivo de gerenciamento

centralizado e dispositivos micro controlados conectados aos eletroeletronicos da residencia.

O usuario envia os comandos aos dispositivos controladores atraves de interfaces de controle

como, por exemplo, paineis afixados em paredes. Existem diversos protocolos de comunicacao

para sistemas de automacao residencial, eles diferem-se pelo custo, meio fısico que utilizam

para as transmissoes e complexidade. Nas proximas secoes serao apresentados alguns destes

protocolos e tambem, solucoes presentes no mercado de automacao que fazem uso deles.

2.1.1 X10

O X10 (SARASWAT et al., 2008) foi um dos primeiros protocolos a serem utilizados em

automacao residencial. Desenvolvido na decada de 70 pela empresa escocesa Pico Electro-

nics, tem como principal caracterıstica a utilizacao da rede eletrica da residencia como meio

2.1 Automacao Residencial 16

de comunicacao, o que oferece economia ao usuario, pois, e utilizada uma infraestrutura ja

instalada. Por possuir um baixo custo e ser de facil instalacao tornou-se muito popular nos Es-

tados Unidos e na Europa. Em 1997 expirou a patente da Pico Electronics sobre o X10, o que

tornou o protocolo acessıvel gratuitamente a qualquer fabricante, motivando ainda mais a sua

popularizacao.

O protocolo X10 pode funcionar de forma descentralizada, ou seja, as interfaces de con-

trole, normalmente paineis afixados em paredes, se comunicam diretamente com os dispositi-

vos controladores. Esse protocolo suporta no maximo 256 enderecos de rede, alem disso, um

mesmo endereco pode ser compartilhado por diferentes dispositivos. Nesse caso, quando uma

mensagem e enviada para um endereco compartilhado por mais de um dispositivo, todos eles

executaram a acao determinada por essa mensagem.

As mensagens sao enviadas em direcao unica, ou seja, as interfaces de controle enviam as

mensagens aos dispositivos e nao recebem nenhuma confirmacao. Isso ocorre porque o X10

nao possui um protocolo de acesso ao meio, o que possibilita colisoes entre mensagens, sendo

isso uma desvantagem, quando comparado a outras tecnologias para automacao residencial.

As mensagens sao transmitidas atraves da rede eletrica da residencia, sendo que os bits de

valor “1” sao enviados na forma de pulsos de 120 Khz a cada cruzamento pelo valor zero de

tensao Corrente Alternada (CA), ja os bits “0” sao caracterizados pela ausencia desses pulsos,

como mostra a Figura 2.1 (CHUNDURU; SUBRAMANIAN, 2006).

Figura 2.1: Transmissao sincronizada no nıvel zero AC (EUROX10, 2011).

Os pulsos sao enviados a cada 60◦ da tensao CA para que o protocolo seja compatıvel

com potencias trifasicas e, assim, receber o bit pela fase que estiver em melhor estado naquele

momento (Figura 2.2), resultando numa melhora na relacao sinal/ruıdo. O protocolo X10 ainda

preve o envio de um segundo bit que e o complemento do original (Figura 2.2) aumentando,

assim, a imunidade a ruıdos do sistema (DA SILVA, A. A. J. P., 2005).

As mensagens do X10 sao formadas por uma sequencia de 13 bits. Os 4 primeiros bits


Figura 2.2: Transmissao nas tres fases (EUROX10, 2011).

indicam o inıcio da mensagem, os 4 bits subsequentes indicam o codigo da casa e os outros 5

variam de acordo com o tipo de mensagem. Desses 5 bits variaveis, o quinto bit mais signifi-

cativo indica se a mensagem e do tipo Address ou do tipo Function. Quando um usuario envia

um comando para determinado dispositivo, primeiramente e enviada uma mensagem do tipo

Address que informa o endereco para o qual sera enviada a proxima mensagem. Em seguida

e enviada uma mensagem do tipo Function que contem o comando que o dispositivo devera

executar.

Quando e enviada a mensagem Address, os 4 bits variaveis indicam o codigo do dispositivo.

Esse codigo juntamente com o codigo da casa podem ser usados para o enderecamento dos dis-

positivos, resultando no total de 256 enderecos possıveis na rede. No envio de uma mensagem

Function os 4 bits variaveis sao usados para indicar o tipo de comando. Esses 4 bits limitam a

quantidade de comandos em 16, alem disso, os comandos do X10 sao predefinidos como, por

exemplo, On, Off e Dim que servem para ligar, desligar e diminuir a intensidade de energia

do dispositivo, respectivamente, tornando o X10 menos flexıvel comparado a outros protocolos

para automacao (DA SILVA, A. A. J. P., 2005).

No X10 as interfaces de controle e os dispositivos normalmente sao conectados a rede

eletrica por meio de cabos, o que impede a mobilidade no sistema. Isso e um grande problema,

pois, hoje em dia existem varias tecnologias que fazem o transporte dos dados por uma rede

sem fio. Pensando nisso alguns fabricantes de produtos para o X10 utilizam um adaptador que

recebe as mensagens dos paineis de controle por um receptor de Radiofrequencia (RF) e as

envia pela rede eletrica.

Apesar da utilizacao de adaptadores de RF amenizar o problema do X10 quanto a mobili-

dade, outros fatores ainda o tornam inviavel para aplicacoes mais complexas e que requeiram

uma confiabilidade maior do sistema tais como: mensagens em direcao unica, limite de 256


enderecos e comandos predefinidos, como ja explicado nessa secao. Alem disso, a propria

utilizacao da rede eletrica na transmissao das mensagens pode acarretar problemas aos disposi-

tivos devido a quedas de energia e descargas eletromagneticas, por exemplo. Como ja visto o

X10 e compatıvel com potencias trifasicas mas para que os dispositivos ligados em diferentes

fases possam se comunicar e necessario a instalacao de um equipamento adicional ou mesmo a

utilizacao de capacitores para interligar essas fases (SENA, 2005).

Siatron

Desenvolvido pela Siatron Automacao1, o Siatron e um sistema de automacao residencial

no qual o usuario pode controlar eletroeletronicos de sua residencia, que estao conectados a

dispositivos X10, por interfaces de controle como paineis, uma pagina Web ou mesmo um

telefone celular, tanto localmente como pela Internet.

A comunicacao entre as interfaces de controle, que utilizam redes Internet Protocol (IP)

para se comunicar, e os dispositivos X10 e feita atraves de um software da mesma empresa que

roda em um computador pessoal e encaminha as mensagens entre essas duas redes distintas.

Esse software ainda permite o agendamento de comandos aos dispositivos para horarios pre-

determinados pelo usuario.

O Siatron e comercializado em forma de modulos tais como o Siatron Biometria, que con-

trola o acesso a residencia atraves de identificacao biometrica e o Siatron Iluminacao, que per-

mite que o usuario acenda ou apague as lampadas da sua residencia.

2.1.2 Insteon

O Insteon (DARBEE, 2005) e um protocolo de rede para automacao residencial criado pela

Smarthome Technology - maior distribuidora de dispositivos X10 do mundo - em 2001. Ele e

considerado o sucessor do X10, pois, assim como ele, tambem utiliza a rede eletrica existente

da residencia como meio de comunicacao. Entretanto, diferente do X10, o Insteon tambem

preve a comunicacao de dispositivos utilizando RF, o que so e possıvel no X10 com a utilizacao

de adaptadores de terceiros como ja mencionado na Secao 2.1.1.

Os dispositivos da rede podem se comunicar utilizando a instalacao eletrica, atraves de RF

ou por ambos. Isso permite que uma mensagem que foi perdida por ruıdos na rede eletrica, por

exemplo, seja recebida atraves do receptor de RF. Outra caracterıstica que torna a comunicacao

na rede mais segura e a retransmissao de mensagens, ela ocorre quando nao e recebida uma

1http://www.siatron.com.br


confirmacao da mensagem enviada. A Figura 2.3 apresenta um exemplo de uma rede Insteon

com dispositivos atuando tanto na rede eletrica quanto por RF. E possıvel ver que podem ser

utilizados dispositivos hıbridos, que transmitam tanto por RF quanto pela rede eletrica, como

ponte para a comunicacao de dispositivos conectados a diferentes fases da rede eletrica.

Figura 2.3: Topologia da rede Insteon (DARBEE, 2005).

O Insteon utiliza uma rede do tipo par a par, sendo que todos os modulos podem receber,

enviar ou repetir as mensagens (Figura 2.3). A repeticao de mensagens aumenta ainda mais a

protecao do sistema contra perdas, ja que elas tem varios caminhos possıveis para chegar ao

destino. Nao ha configuracoes de rotas na rede, ou seja, todos os modulos repetirao todas as

mensagens que receberem. Para evitar uma repeticao infinita de mensagens na rede, o Insteon

limita em 3 o numero de repeticoes de uma mesma mensagem.

Existem dois tipos de mensagens no protocolo Insteon: a mensagem Standard (Figura 2.4(a))

que contem 10 bytes e a mensagem Extended (Figura 2.4(b)) que contem os mesmos 10 by-

tes da Standard acrescidos de 14 bytes para preenchimento com quaisquer informacoes que

o usuario queira. Esses 10 bytes comuns nas duas mensagens sao divididos em cinco campos:

endereco de origem; endereco de destino; flags; comandos 1 e 2 e por ultimo Cyclic Redundancy

Check (CRC) (DARBEE, 2005).

Os campos endereco de origem e de destino ocupam 3 bytes da mensagem cada, ou seja, na

rede Insteon existem 16.777.216 enderecos unicos possıveis. Esses enderecos sao configurados


(a) Mensagem do tipo Standard(DARBEE, 2005).

(b) Mensagem do tipo Extended(DARBEE, 2005).

Figura 2.4: Mensagens do protocolo Insteon.

durante a fabricacao dos dispositivos e, por isso, nao podem ser alterados. O campo flags

ocupa 1 byte e contem informacoes como o tipo de mensagem que e enviada, ja o campo

comandos ocupa 2 bytes, um para cada comando, e contem os comandos predeterminados que

o dispositivo devera executar. O ultimo byte contem o valor de CRC utilizado para deteccao de

erros.

Os sinais que carregam as mensagens na rede eletrica tem frequencia de 131,65 Khz e, as-

sim como no X10, sao sincronizados no nıvel zero de tensao CA. Esses sinais sao modulados

utilizando-se a modulacao Binary Phase Shift Keying (BPSK) o que garante uma boa perfor-

mance do sistema na presenca de ruıdos. Ja os sinais enviados por radiofrequencia utilizam a

faixa de 902 a 924 Mhz dentro da banda Industrial, Scientific and Medical (ISM) e sao trans-

mitidos a uma taxa de 38,4 Kbps.

O protocolo X10 e compatıvel com o protocolo Insteon, ou seja, os dois sistemas podem

operar na instalacao eletrica da mesma residencia sem causar interferencias entre si. Porem, as

mensagens do Insteon e do X10 nao sao compatıveis, por isso, os fabricantes foram autorizados

a desenvolver dispositivos hıbridos - que operem nas duas redes - o que permite a integracao de

uma nova rede Insteon com uma rede X10 ja instalada.

O Insteon resolveu varios dos problemas existentes no X10, porem, por utilizar a rede

eletrica para a transmissao de comandos os problemas decorridos dessa utilizacao tambem

encontram-se nele. Mesmo com a utilizacao de dois meios de transmissao evitando a perda

das mensagens devido a atenuacoes ou ruıdos na rede, nem todos os dispositivos presentes no

mercado tem a capacidade de utilizar os dois meios.


iHome

Desenvolvido pela IHC Technologies2, o iHome e uma solucao para automacao residen-

cial composta pelo iHomeClub e por hardwares, que controlarao os eletroeletronicos, tambem

desenvolvidos pela IHC. O iHomeClub e o aplicativo utilizado como interface de controle e

foi desenvolvido para dispositivos moveis que rodem o sistema operacional iOS3 como iPhone,

iPod Touch e iPad.

No iHome o usuario pode controlar diferentes setores da sua residencia. Na parte de

iluminacao e possıvel acender e apagar lampadas, agendar o horario de funcionamento delas

e a dimerizacao da intensidade das luzes. Tambem e possıvel o controle dos aparelhos de som,

televisores e Home Theaters da residencia. Alem disso, ele permite o controle de sistemas

adicionais como: ar condicionado; lareiras; persianas entre outros.

Alem do protocolo Insteon, o iHome suporta outros protocolos para automacao residen-

cial como Global Cache, Lutron, AMX, Creston e outros. Os dispositivos que controlarao os

equipamentos da residencia sao vendidos separadamente em representantes comerciais da IHC

Technologies, ja o aplicativo iHomeClub pode ser baixado gratuitamente no site iTunes.com.

2.1.3 Z-Wave

A transmissao de informacoes pela instalacao eletrica da residencia fornece um metodo sim-

ples e barato para a infraestrutura de uma rede de comunicacao. Entretanto, com a exposicao

dos dados da rede aos problemas inerentes a rede eletrica buscou-se criar uma infra-estrutura

propria, separada da fiacao eletrica, para serem utilizados em sistemas de automacao. Com esse

intuito foi criado o Z-Wave(Z-WAVE ALLIANCE, 2004), um protocolo proprietario desenvol-

vido pela empresa Zensys que utiliza comunicacao sem fio para a troca de mensagens entre os

dispositivos da rede.

No Z-Wave os dados sao transmitidos a uma taxa de 40 Kbps - 9,6 Kbps nos dispositivos

antigos - utilizando a banda ISM de 902 a 928 Mhz. Na comunicacao entre os dispositivos da

rede, o raio de alcance das mensagens pode chegar a 30 metros. Para evitar colisoes no meio

onde as mensagens sao transmitidas, o Z-Wave utiliza uma solucao bastante simples, quando

um dispositivos quer enviar uma mensagem pela rede ele primeira escuta o meio e caso ele

esteja ocupado espera um tempo aleatorio para tentar mandar a mensagem novamente, se o

meio estiver ocioso entao a envia.2http://www.ihclub.com.br3http://www.apple.com/ios


Numa rede Z-Wave podem haver 232 dispositivos ativos na rede, o que pode ser pouco

dependendo da residencia e da complexidade do sistema em que forem instalados. Para diminuir

essa limitacao foi incluıdo no protocolo uma funcionalidade bem interessante que sao os nos

virtuais. Um dispositivo Z-Wave com a funcionalidade de controle pode servir como ponte

para varios outros dispositivos. O interessante disso e que esses dispositivos podem pertencer a

outros tipos de rede como TCP/IP e X10, e para o restante da rede serao vistos como dispositivos

Z-Wave. Essa funcionalidade permite um numero acima de 125 nos virtuais na rede Z-Wave e

possibilita a integracao do protocolo com sistemas pre-instalados numa residencia.

Os dispositivos na rede Z-Wave podem rotear mensagens formando uma rede em malha

o que resulta num aumento do alcance de suas transmissoes. As mensagens enviadas podem

carregar no maximo 64 bytes de informacao, alem disso, quando um dispositivo recebe uma

mensagem ele envia para a origem uma mensagem do tipo acknowledge para confirmar o rece-

bimento com sucesso. Para a protecao contra ruıdos ou interferencias no meio, as mensagens

enviadas contem um campo que guarda um valor de checksum para que o dispositivo de destino

possa verificar a integridade das informacoes recebidas. Quando uma mensagem e enviada e

nao e recebida uma confirmacao de recebimento ou quando e identificado um erro durante a

verificacao do valor de checksum, e feita uma retransmissao dessa mensagem.

Numa rede Z-Wave existem varios tipos de dispositivos dependendo da funcao que exercem

na rede. Toda rede Z-Wave tera um unico dispositivo do tipo Controlador Primario, que sera

responsavel por iniciar a rede e por funcoes como a inclusao e exclusao de dispositivos da rede.

Os dispositivos podem ser do tipo Controlador, que tem a funcao de gerenciar a rede, porem

so executa acoes de modo indireto, ou seja, mediante comandos do Controlador Primario. Os

dispositivos podem tambem ser do tipo Escravo, sao eles quem enviam, recebem e encaminham

as mensagens na rede. Os dispositivos do tipo Controlador podem ainda ser classificados como

Portateis ou Estaticos. Os Controladores Portateis tem a capacidade se movimentar na rede,

pois, podem modificar a tabela de roteamento atualizando suas posicoes nela automaticamente.

Os Controladores Estaticos exercem a funcao de ponte para nos virtuais e para isso devem ter

pouca mobilidade na rede, pois para atualizar suas posicoes na tabela de rotas deve haver um

evento externo, como um aperto de botao por exemplo.

Modest Solution

A empresa Modest Solution4 dispoe de uma solucao para automacao residencial onde e

possıvel controlar cameras, iluminacao, climatizacao, sonorizacao e eletroeletronicos como te-

4http://www.modestsolution.com.br


levisores e home theaters. Para a comunicacao das interfaces de controle e dos dispositivos que

controlarao os eletros da casa e utilizado o protocolo Z-Wave para residencias ja construıdas e

cabeamento estruturado para residencias ainda em fase de projeto.

O sistema de automacao da Modest Solution funciona de forma descentralizada, ou seja,

nao existe qualquer equipamento mediando a comunicacao entre os controles e os dispositivos

terminais. Isso cria uma certa limitacao no sistema, ja que nao havendo um servidor ativo o

tempo todo na rede se perde funcionalidades como o agendamento de tarefas aos dispositivos.

Nesse sistema tambem ha a opcao da criacao de cenarios. Esses cenarios permitem que

diferentes tipos de dispositivos tais como, lampadas, televisores e persianas, sejam controlados

na mesma tela da interface de controle. Um exemplo dessa funcionalidade seria a criacao de

cenarios especıficos para cada comodo da residencia.

2.1.4 ZigBee

Um grupo de varias empresas entre elas Philips, Texas Instruments, Intel, Cisco e AT&T

formam a ZigBee Alliance5. Esse grupo desenvolveu o ZigBee (ZIGBEE ALLIANCE, 2005),

um protocolo criado para sistemas sem fio especıficos, que nao necessitem de altas taxas de

transmissao tais como sistemas de controle e automacao. O ZigBee foi construıdo sobre o

padrao IEEE 802.15.4 (IEEE, 2006) que define as redes pessoais sem fio com baixa taxa de

transmissao, e por isso produtos de diferentes fabricantes sao mais compatıveis entre si do que

em outros protocolos.

O ZigBee utiliza as bandas ISM de 868 e 915 Mhz alem da banda de 2,4 Ghz, para a

transmissao dos dados que pode chegar a taxa de 250 Kbps. O alcance dessas transmissoes

atinge em media 50 metros dependendo do ambiente onde e realizada e dos dispositivos utiliza-

dos. Porem, e possıvel estender esse alcance configurando os nos da rede ZigBee para atuarem

como roteadores. Nessa configuracao as mensagens podem ser encaminhadas por diversos nos

ate chegarem ao destino.

Para a transmissao das mensagens e feito uso do protocolo Carrier Sense Multiple Ac-

cess With Collision Avoidance (CSMA/CA), que escuta o meio antes de enviar a mensagem,

e caso ele esteja ocupado, toma medidas para evitar colisoes na rede. Outra medida tomada

e a utilizacao da tecnica Direct Sequence Spread Spectrum (DSSS) para alargar o espectro de

frequencias do sinal e, consequentemente, aumentar a imunidade dele a ruıdos.

O protocolo ZigBee suporta no maximo 65.536 redes coabitando a mesma area. Ele ainda

5http://www.zigbee.org


preve dois tamanhos para enderecos, os mais curtos de 16 bits - para reduzir o tamanho do

pacote - que possibilitam a quantidade de 65.536 enderecos unicos na rede, e os de 64 bits que

possibilitam mais de 18x1018 de enderecos. Os enderecos dos modulos ZigBee vem gravados

desde a sua fabricacao e nao podem ser alterados.

No ZigBee e possıvel garantir a seguranca na transferencia das mensagens utilizando crip-

tografia. Ja a confiabilidade dessa troca de informacoes e conseguida utilizado-se um esquema

de deteccao de erros para verificar a integridade dos dados recebidos, caso seja identificado

um erro, entao sera realizada uma retransmissao da mensagem. Alem disso, para toda mensa-

gem enviada - exceto as de broadcast - deve ser recebida uma mensagem de confirmacao de

recebimento com sucesso do destino, caso contrario, tambem ocorrera a retransmissao dessa

mensagem.

Control4

A empresa americana Control46, especializada em solucoes na area de automacao, desen-

volveu um sistema de automacao residencial completo onde e possıvel controlar desde equi-

pamentos mais simples como luminarias, ate equipamentos eletronicos mais complexos como

televisores, equipamentos de ar-condicionado, aparelhos de som e home theaters.

O usuario pode utilizar como interface de controle paineis com telas sensıveis ao toque,

controles remotos convencionais e ainda pode utilizar aplicativos disponıveis para dispositivos

moveis rodando iOS e tambem para computadores pessoais e laptops. Os dispositivos que con-

trolam os eletros utilizam a rede ZigBee no envio dos comandos, ja as interfaces de controle

utilizam a rede Wi-Fi, com excecao dos controles remotos convencionais que tambem utili-

zam ZigBee. Para a comunicacao entre as interfaces de controle e os dispositivos, a Control4

desenvolveu um equipamento denominado Controller que integra os dois tipos de rede.

Essa solucao tambem disponibiliza o Composer Home Edition, um software para compu-

tadores pessoais que permite, entre outras coisas, a criacao de cenarios personalizados para o

controle dos dispositivos e tambem o agendamento de eventos como acendimento de lampadas

e a mudanca de temperatura dos equipamentos de ar-condicionado, em horarios especıficos.

Na solucao para automacao residencial da Control4 os dispositivos que controlam os eletros

e o Controller podem ser adquiridos separadamente de acordo com a necessidade do usuario. Os

aplicativos para dispositivos moveis e computadores podem ser baixados gratuitamente, porem,

o usuario tera que adquirir uma licenca de funcionamento para cada dispositivo usado como

6http://www.control4.com

2.2 Padrao IEEE 802.15.4 e ZigBee 25

interface de controle.

2.1.5 Comparativo

Na Secao 2.1 foram apresentados importantes protocolos da automacao residencial seja

pelo aspecto historico ou seja pela grande utilizacao no mercado. Alem disso, foram apre-

sentados exemplos de produtos de automacao residencial presentes no mercado que utilizam

esses protocolos. Foram descritas caracterısticas desses protocolos como o meio e a taxa de

transmissao que utilizam, e outras como topologias de rede e funcionalidades de seguranca que

possuem. Na Tabela 2.1 essas caracterısticas sao postas lado a lado.

X10 Insteon Z-Wave ZigBeeMeio Fısico Rede Eletrica Rede Eletrica e RF Radiofrequencia RadiofrequenciaBandas de RF —— 902 MHz 902 MHz 868, 915 MHz e 2,4 GHzTaxa Maxima 60 bps 38,4 Kbps 40 Kbps 250 KbpsTopologias Estrela Malha Malha Estrela, Malha, ArvoreQtd. de Info. 4 bits 2 bytes 64 bytes VariavelSeguranca —— —— Baseada na AES 128 bits AES 128 bitsCaracterıstica Instal. simples Hıbrido Roteamento Baixo consumo

Tabela 2.1: Comparativo entre os protocolos.

E possıvel perceber que o X10, mesmo tendo a caracterıstica de ser utilizado diretamente na

rede eletrica da residencia, e bastante simples e nao possibilita a formacao de topologias de rede

mais complexas ou mesmo possui recursos de seguranca. Em contrapartida, o ZigBee se mostra

o protocolo mais completo, dos apresentados na tabela, possibilitando diversas topologias e

bandas para transmissao, alem de possuir funcionalidades sofisticadas de seguranca e economia

de energia.

2.2 Padrao IEEE 802.15.4 e ZigBee

Com a popularizacao das redes sem fio em ambientes comerciais e residenciais, onde um

longo alcance e uma alta taxa de transferencia de dados sao caracterısticas desejaveis, tornou-se

necessario o desenvolvimento de uma tecnologia voltada para redes especıficas, como as in-

dustriais e de automacao. Essas redes nao necessitam de grandes taxas de transmissao, porem,

elas requerem dispositivos que tenham um baixo consumo de energia. Por essa razao foi de-

senvolvido o padrao IEEE 802.15.4. Esse padrao define a Low-Rate Wireless Personal Area

Network (LR-WPAN) e pode ser aplicado em sistemas de automacao industrial e residencial,

militares, de monitoramento sem fio, entre outros.


No 802.15.4 sao utilizadas as bandas ISM de 868 Mhz (Europa somente), 902 Mhz e 2,4

Ghz para as transmissoes de dados. Na Banda de 868 Mhz e utilizado apenas um canal de

transmissao e consegue-se taxas de no maximo 40 Kbps, na banda de 902 Mhz sao utilizados

ate 8 canais que possibilitam taxas de ate 40 Kbps, ja na banda de 2,4 Ghz sao dispostos 16

canais e a taxa maxima salta para 250 Kbps. Quando se utiliza bandas com varios canais, os

dispositivos que controlam a rede podem ser configurados para escolher automaticamente o

canal que estiver ocioso, isso permite que possam coexistir varias redes sem fio numa mesma

area.

Numa rede 802.15.4 existem dois tipos de dispositivos: os Full Function Devices (FFD)

e os Reduced Function Devices (RFD). Os FFDs sao dispositivos que podem se comunicar

com qualquer outro tipo de dispositivo, ou seja, FFDs e RFDs. Esses dispositivos podem ainda

exercer funcoes de controle e gerenciamento da rede. Em contrapartida, os RFDs podem se

comunicar apenas com os FFDs e nao exercem quaisquer funcoes extras na rede.

As mensagens do 802.15.4 sao transmitidas em forma de pacote. Como mostra a Fi-

gura 2.5, o pacote e dividido em tres partes: o Medium Access Control Header (MHR), a

informacao enviada (Medium Access Control Payload (MAC Payload)), e um Medium Access

Control Footer (MFR). No MHR estao contidos o campo delimitador de quadro (Frame Con-

trol), indicando o inıcio do pacote, um campo com o numero de sequencia do pacote, e os

campos de enderecamento. O campo MAC Payload tem o comprimento variavel e seu tamanho

maximo varia de fabricante pra fabricante. No MFR esta contido o valor do Frame Checksum

Sequence (FCS). Esse valor serve para verificar a integridade das informacoes recebidas, e caso

seja encontrado algum erro, entao sera requisitada uma retransmissao do pacote ao dispositivo

de origem.

Figura 2.5: Quadro de mensagem(IEEE, 2006).

Para o envio das mensagens e possıvel utilizar enderecos de 16 ou 64 bits. O endereco

de 16 bits e atribuıdo ao dispositivo quando este se conecta a rede, ja o de 64 bits e fixo e

exclusivo para cada dispositivo ZigBee fabricado. Para a troca de mensagens na rede e utilizado

o endereco de 16 bits, porem, como ele e facilmente mutavel, na montagem dos pacotes deve

ser utilizado o endereco de 64 bits. Durante o envio da mensagem, a rede ZigBee utilizara


esse endereco de 64 bits para descobrir o endereco mais curto atual do dispositivo de destino e,

assim, evitar perdas de pacotes.

2.2.1 ZigBee

O padrao IEEE 802.15.4 define as camadas Physical Layer (PHY) e Medium Access Con-

trol Layer (MAC Layer) para as LR-WPANs, entretanto, as camadas superiores precisam ser

definidas pelas especificacoes que utilizarem essa base. O ZigBee e uma delas, ele utiliza a

base definida pelo 802.15.4 e adiciona outras duas camadas, as camadas de rede e de aplicacao

a qual pertence a sub-camada de suporte a aplicacao, como visto na Figura 2.6.

Aplicação(AF)

Subcamada de Suporte a Aplicação(APS)

Camada de Rede(NWK)

Camada de Controle de Acesso ao Meio(MAC)

Camada Física(PHY)

IEEE802.15.4

PlataformaZigBee

Aplicaçõesdo Usuário

Figura 2.6: Pilha do protocolo ZigBee.

A camada de rede e responsavel por funcoes como o gerenciamento de inclusao/exclusao de

dispositivos e a descoberta e manutencao de rotas na rede. Ja a camada de aplicacao fornece as

instrucoes necessarias para o desenvolvimento dos servicos. Nessa camada ainda estao contidos

servicos como os de seguranca, os da fabricante do dispositivo e tambem servicos do usuario.

Numa rede ZigBee um dispositivos pode ter a funcao de roteador, coordenador ou pontos

finais. Os roteadores sao dispositivos montados sobre a arquitetura FFD do 802.15.4, eles po-

dem enviar, receber e encaminhar mensagens na rede. Em uma rede ZigBee sempre deve haver

um unico roteador com funcao de coordenador, e ele quem inicia e gerencia a rede. Ja os pon-

tos finais sao projetados sobre a arquitetura RFD, eles sao as terminacoes da rede, por isso, so

enviam e recebem mensagens.

Os pontos finais nao necessitam estar o tempo todo funcionando, eles podem entrar em

modo de hibernacao, fazendo-os ficar parcialmente desligados, e de tempos em tempos acordar

para se comunicar na rede. Operando nesse modo, eles consomem pouca energia podendo ser

alimentados, inclusive, por baterias durante meses e ate anos. Esse baixo consumo de energia


torna o ZigBee mais apropriado para sistemas de automacao se comparado a outras tecnologias

mais populares de rede sem fio como o Wi-Fi (IEEE, 2007).

No ZigBee as redes podem ser implantadas utilizando-se as topologias em forma de estrela,

em arvore ou em malha, como mostra a Figura 2.7. A topologia em estrela e formada por um

roteador - atuando como coordenador - e varios pontos finais, sendo que todas as mensagens da

rede passarao por esse roteador para chegarem ao seu destino. A topologia em arvore funciona

como uma arranjo de varias topologias em estrela. Ja na topologia em malha, o nucleo da rede

e formado por roteadores e podem haver pontos finais nas bordas. Nesse caso, as mensagens

podem passar por quantos dispositivos forem necessarios para chegar ao destino. Essa capa-

cidade de encaminhamento das mensagens do ZigBee permite a transmissao de mensagens a

distancias maiores que outras tecnologias de rede sem fio que tambem possibilitam baixo con-

sumo energetico como, por exemplo, o Bluetooth (BLUETOOTH, 1998) onde nao e possıvel

topologias em malha.

Rede em estrela

Rede em árvore

Rede em malha

Coordenador ZigBee

Roteador ZigBee

End-device ZigBee

Figura 2.7: Topologias da rede ZigBee.


Seguranca

A seguranca nas redes ZigBee e uma das caracterısticas que mais o destacam em comparacao

a seus concorrentes. Para garantir a seguranca na troca de mensagens, estao presentes nele

funcionalidades como o controle de acesso, integridade das mensagens, confidencialidade das

mensagens, e protecao contra ataques de repeticao. Essas funcionalidades sao implementadas

na MAC Layer e sao manipuladas pelos servicos da camada de aplicacao (SASTRY; WAGNER,

2004).

O controle de acesso previne que dispositivos intrusos se comuniquem numa rede privada, ja

a integridade das mensagens, garante que as mesmas nao sejam alteradas no meio do percurso

de transmissao. Para garantir essas funcionalidades, e incluıdo em cada pacote um Message

Authentication Code (MAC). O MAC funciona como um codigo de checksum criptografado.

Ele e gerado na origem utilizando-se uma chave secreta, e quando recebe o pacote, o destino

recalcula o MAC utilizando essa mesma chave secreta. Se o MAC recebido no pacote e o MAC

calculado no destino forem diferentes, significa que o pacote nao foi enviado por um dispositivo

pertencente a rede, ou que ele foi alterado (SASTRY; WAGNER, 2004).

Para garantir a confidencialidade das informacoes contidas nos pacotes, o ZigBee utiliza

criptografia. Essa confidencialidade, alem de garantir que um intruso nao tenha acesso a essas

informacoes, tem que garantir tambem que ele nao consiga acessar nenhuma parte delas. A

criptografia das mensagens no ZigBee e feita de modo simetrico, ou seja, os dispositivos de

origem e destino utilizam a mesma chave para criptografar e descriptografar as mensagens.

Para isso e utilizado o padrao AES (DAEMEN; RIJMEN, 2002) com chaves de 128 bits. Uma

unica chave pode ser compartilhada por todos os nos da rede, ou ainda, pode utilizar-se uma

chave distinta para cada par de nos que se comunicam.

Ataques de repeticao sao feitos repetindo-se mensagens de um no valido na rede sem altera-

las. Um exemplo seria a captura de uma mensagem de pagamento de uma pessoa destinada a

uma instituicao financeira. Quem capturou essa mensagem poderia enviar ela repetidas vezes,

e entao seriam efetuados diversos pagamentos. Para evitar isso, os pacotes da rede ZigBee

tem um campo onde e inserido um numero de sequencia, como visto na Figura 2.5, e caso um

dispositivo receba um pacote com o mesmo numero de sequencia de uma mensagem recebida

anteriormente, esse pacote sera descartado.

2.3 Arduino 30

2.3 Arduino

A plataforma Arduino7 foi desenvolvida em 2005 no Interaction Design Institute Ivrea na

Italia com o intuito de ser utilizada como uma ferramenta simples e facil de usar mesmo para

leigos em programacao e eletronica. Essas caracterısticas tornaram ela uma plataforma muito

utilizada para o desenvolvimento de prototipos. Por se tratar de uma plataforma aberta de hard-

ware e software, qualquer fabricante pode montar e vender kits Arduino baseados no original

sem precisar pagar por isso.

O kit padrao do Arduino e composto por uma placa de silıcio na qual e soldado um micro-

controlador da famılia Atmega8, que contem o codigo a ser executado, alem de conectores para

as portas do microcontrolador e para conexoes externas (p. ex. USB). Esse microcontrolador

contem portas de entrada e saıda digitais, portas para comunicacao serial, portas de entrada

analogicas e de saıda PWM (Power Wave Modulation), onde e possıvel controlar o nıvel de

tensao da saıda, entre outras, como mostra a Figura 2.8. Nessas portas de entrada e saıda e

possıvel conectar botoes, sensores, LEDs ou quaisquer outros dispositivos eletricos, tornando

inumeras as possibilidades de uso para o kit.

Figura 2.8: Elementos de um kit Arduino (HERRADOR, 2009).

A expansao das funcionalidades do kit Arduino pode ser feita com a utilizacao de shields,

os quais, consistem de placas que devem ser acopladas aos kits e podem conter, entre outros

dispositivos, interfaces Ethernet ou Wi-Fi para se comunicarem pela rede IP, ou mesmo trans-

missores ZigBee o que tornaria esses kits nos dessa rede.

Para permitir que kits Arduino se comuniquem numa rede ZigBee podem ser utilizados os7http://www.arduino.cc8http://www.atmel.com

2.3 Arduino 31

modulos XBee (DIGI INTERNATIONAL INC., 2009). Esses modulos devem ser acoplados

a um XBee Shield9 e sao configuraveis para exercerem funcionalidades ja mencionadas na

Secao 2.2.

Para a programacao dos microcontroladores, o Arduino utiliza uma linguagem, baseada no

Wiring10, que e implementada em C/C++. Por esse motivo, a linguagem do Arduino encapsula

diversos aspectos de baixo-nıvel da programacao do microcontrolador como, por exemplo, a

manipulacao de registradores. Isso torna a programacao do Arduino mais amigavel se compa-

rada a outras plataformas(WADDINGTON; TAYLOR, 2007).

Para o desenvolvimento de projetos no Arduino foi criada uma Integrated Development

Environment (IDE) onde o usuario pode escrever e compilar seus codigos. Alem disso, ela

possui uma ferramenta chamada Serial Monitor onde e possıvel enviar dados pela porta serial

do Arduino e visualizar os dados recebidos. Na IDE tambem estao disponıveis codigos com

exemplos de utilizacao dos mais variados dispositivos eletricos.

A Figura 2.9 mostra um dos exemplos de codigo disponıveis na IDE. Apos ser compilado

e instalado no microcontrolador, ele faz com que o mesmo acende e apague um LED, que

deve estar conectado na porta digital. Todos os programas escritos para a plataforma Arduino

deverao conter as funcoes setup() e loop(). A funcao setup() e sempre chamada no inıcio da

execucao, antes de qualquer outra e pode ser utilizada para inicializar variaveis e configurar

as portas do microcontrolador. A funcao loop() e chamada em seguida, ela e repetida infinitas

vezes, portanto, e nela que devera ficar toda a logica do programa. Outras funcoes podem ser

criadas, porem, elas so poderao ser chamadas de dentro das funcoes setup() ou loop().

1 void setup() {

2

3 // inicializando a porta digital como saida

4 // A porta 13 tem um LED conectado a ela na maioria dos kits Arduino:

5 pinMode(13, OUTPUT);

6 }

7

8 void loop() {

9

10 digitalWrite(13, HIGH); // acende o LED

11 delay(1000); // espera por um segundo

12 digitalWrite(13, LOW); // apaga o LED

13 delay(1000); // espera por um segundo

14 }

Figura 2.9: Codigo para piscar um LED no Arduino.

9http://www.libelium.com10http://wiring.org.co

2.4 XBee 32

2.4 XBee

Os modulos XBee foram desenvolvidos pela Digi International11 - membro da ZigBee Al-

liance - com o intuito de permitir que dispositivos eletronicos de todos os tipos se comuniquem

pela rede ZigBee. Esses modulos consistem em pequenas placas onde estao presentes transmis-

sores que se comunicam em redes ZigBee utilizando radiofrequencia. As informacoes recebidas

pelo radio podem, inclusive, ser passadas para o dispositivo que faz uso do modulo atraves da

comunicacao serial existente entre eles.

Existem duas versoes de modulos XBee, denominadas Series 1 e 2, sendo a principal

diferenca entre as duas a capacidade de roteamento de mensagens, presente apenas na Series

2. Existe ainda uma versao PRO de cada Serie, que basicamente tem a potencia de transmissao

maior do que as versoes comuns, porem, resultando num consumo maior de energia.

Os modulos XBee podem operar tanto no modo AT quando no modo Application Program-

ming Interface (API). No modo AT a comunicacao com os outros modulos e feita de forma

transparente, ou seja, os dados sao enviados como se os dois modulos - transmissor e receptor

- estivessem conectados por uma interface serial. Ja no modo API os dados sao enviados em

forma de pacote que, alem dos dados, carregam informacoes como endereco de origem e de

destino.

Para a configuracao dos modulos XBee pode ser feito uso do aplicativo X-CTU12, tambem

desenvolvido pela Digi. Inicialmente e necessario escolher as configuracoes da comunicacao

serial como a porta em que o modulo esta conectado e a taxa de comunicacao, que deve ser igual

a utilizada pelo modulo (Figura 2.10(a)). Concluindo as configuracoes iniciais ja e possıvel

configurar o modulo no menu, mostrado na Figura 2.10(b), com as caracterısticas desejadas,

tais como o identificador da rede, seu endereco, o canal utilizado na comunicacao, opcoes de

criptografia, entre outras.

2.5 Android

Os telefones inteligentes se tornaram populares, contudo, seus sistemas operacionais pro-

prietarios dificultam o desenvolvimento de uma mesma aplicacao para diferentes dispositivos

moveis. Por essa razao, um grupo de empresas lideradas pelo Google formaram a Open Handset

Alliance. Essa alianca tem como objetivo o desenvolvimento do Android (OPEN HANDSET

11http://www.digi.com12http://www.digi.com/support/kbase/kbaseresultdetl.jsp?kb=125

2.5 Android 33

(a) Configurar comunicacao serial do X-CTU (b) Gravar configuracoes no modulo

Figura 2.10: Configuracao de modulos no X-CTU

ALLIANCE, 2008), um sistema operacional de codigo aberto, e por isso, pode ser utilizado por

qualquer fabricante de dispositivos moveis.

Como mostra a Figura 2.11, na base da arquitetura do Android encontra-se um Kernel Li-

nux. Sobre ele estao as bibliotecas C/C++ de varios componentes do sistema como a biblioteca

de mıdia, a do banco de dados SQLite13, a de gerenciamento da tela, entre outras. Sobre o Ker-

nel tambem roda a Dalvik, uma maquina virtual Java otimizada para dispositivos moveis que

possui recursos para economia de memoria e implementa a compilacao JIT (Just In Time) para

economia de processamento. Rodando sobre a maquina virtual e fazendo uso das bibliotecas

estao as aplicacoes do sistema e as aplicacoes do usuario.

Para o desenvolvimento das aplicacoes para Android o Google disponibilizou um Software

Development Kit (SDK). Esse kit contem, entre outras ferramentas, um emulador de telefone

celular - onde e possıvel testar as aplicacoes, codigos com diversos exemplos de aplicacoes

e ferramentas de depuracao. Para a escrita dos codigos e recomendado a utilizacao da IDE

Eclipse14, onde, alem de escrever, e possıvel compilar e instalar aplicacoes no emulador de

maneira simples gracas a um plugin disponibilizado pela propria Google para a integracao da

SDK com o Eclipse.

Para a programacao de software e utilizada a linguagem Java, entretanto, para a criacao

13www.sqlite.org14www.eclipse.org

2.5 Android 34

Aplicações Android

Arcabouço de Aplicações

Bibliotecas

Dalvik VM

Kernel Linux

ActivityManager

WindowManager

NotificationManager

ViewSystem

MediaFramework

SQLite

OpenGLSurfaceManager

Ambientede execução

... ...

... ... ...

Figura 2.11: Arquitetura do Android.

das interfaces graficas pode ser utilizada tambem a linguagem Extensible Markup Language

(XML), deixando o codigo Java apenas com a logica de programacao. Quando se utiliza XML

na criacao da interface grafica, e necessario atribuir aos objetos nesses arquivos um valor de

identificacao para que eles possam ser convertidos para objetos Java, como e mostrado na Fi-

gura 2.12.

Descrição da interface em XMLInterface da aplicação Classe Java com a lógica

Figura 2.12: Aplicacao Android utilizando Java e XML.

35

3 DroidLar

Os sistemas de automacao residencial apresentados na Secao 2.1 oferecem muitas opcoes

de configuracao, alem disso, os mais sofisticados possibilitam a utilizacao de aplicativos em

telefones inteligentes. Em contrapartida, as suas infraestruturas proprietarias limitam as opcoes

do usuario na hora de substituir um dispositivo, ou mesmo, ampliar a automacao na residencia.

O DroidLar consiste num sistema de automacao residencial completo, onde e possıvel controlar

eletroeletronicos de uma residencia utilizando como interface de controle celulares Android.

3.1 Arquitetura

A arquitetura do DroidLar foi construıda de forma centralizada, ou seja, um servidor central

gerencia toda a rede. Este e capaz de se comunicar tanto com as interfaces de controle quanto

com os dispositivos controladores. Como e possıvel ver na Figura 3.1, o DroidLar e dividido

em tres partes: cliente Android, Servidor de Automacao Residencial (SAR), e kits Arduino.

O cliente Android atua como uma interface de controle no sistema e se comunica pela rede

IP, os kits Arduino funcionam como controladores de dispositivos e utilizam ZigBee para a

comunicacao, ja o SAR e o servidor central, ele se comunica tanto pela rede IP quanto por

ZigBee e tem como principal funcao transferir as mensagens entre essas duas redes.

3.1.1 Controladores de Dispositivos

Os controladores de dispositivos, na automacao residencial, tem a funcao de executar os

comandos enviados pelas interfaces de controle nos eletroeletronicos da residencia tais como

acender lampadas, fechar cortinas e alterar a temperatura de aparelhos de ar-condicionado. Nor-

malmente, esses dispositivos sao constituıdos de microcontroladores e realizam acoes de acordo

com o comando recebido.

Nesse trabalho foram utilizados kits Arduino para a prototipagem dos controladores de

dispositivos, devido as suas caracterısticas apresentadas na Secao 2.3. A Figura 3.2 e uma

3.1 Arquitetura 36

Figura 3.1: Elementos do DroidLar.

fotografia desses kits, nela e possıvel ver que em cada matriz de contato estao dispostos tres

LEDs e tres botoes, alem de fios conectados as portas do microcontrolador presente no Arduino.

Os LEDs fazem o papel das lampadas controladas de uma residencia. Estes estao conectados

nas saıdas Pulse Width Modulation (PWM) do microcontrolador. Os botoes estao conectados

nas entradas digitais e fazem a funcao de interruptores das “lampadas” (Figura 3.3).

Kit Arduino

Kit Arduino

Módulo do SAR

Figura 3.2: Prototipos do DroidLar.

Para a comunicacao com o SAR pelo protocolo ZigBee (ZIGBEE ALLIANCE, 2005) fo-

ram acoplados aos kits Arduino modulos XBee1 utilizando shields. Esses modulos recebem as

mensagens pela rede sem fio e as transferem para o microcontrolador utilizando uma conexao

serial. Os modulos XBee foram configurados em modo API (DIGI INTERNATIONAL INC.,

2009) e, por isso, recebem as mensagens em forma de pacote. No microcontrolador e feito

o mapeamento desses pacotes para tornar as suas informacoes legıveis e entao, executar um

1http://www.digi.com

3.1 Arquitetura 37

determinado procedimento.

Figura 3.3: Configuracao dos circuitos nos Kits.

Os kits Arduino possuem apenas duas funcoes: (1) executar efetivamente os comandos

recebidos no eletroeletronico conectado a uma de suas portas; (2) enviar ao SAR uma mensagem

contendo o estado dos dispositivos que controla, por exemplo, a quantidade de dispositivos, o

tipo de dispositivo e se estao ligados ou nao. A primeira e executada toda vez que e recebida

uma mensagem do SAR com a requisicao do comando, ja a segunda, e executada sempre que o

dispositivo controlador e ligado e, tambem, quando e recebida uma mensagem de varredura do

SAR.

Na escrita do codigo do Arduino, foi utilizada uma API, implementada em C/C++, para

facilitar a manipulacao das mensagens ZigBee 2. Ela simplifica o processo de montagem dos

pacotes enviados e o mapeamento dos pacotes recebidos. Alem disso, nessa API estao contidas

instrucoes que possibilitam facilmente a obtencao de campos importantes dos pacotes como a

informacao recebida e o endereco de origem.

Para a configuracao dos modulos XBee foi utilizado o aplicativo X-CTU3. Foi escolhido

54 Mbytes para o tamanho maximo do conteudo dos pacotes. A criptografia foi desabilitada e,

por isso, nao sera utilizado espaco extra dos pacotes. A comunicacao serial entre o modulo e o

microcontrolador, foi configurada com a taxa de 9,6 Kbps e o sinal de radiofrequencia para ser

transmitido com aproximadamente 3 dBm de potencia.

3.1.2 SAR

O SAR e o servidor central do DroidLar. Ele e capaz de comunicar-se tanto pelas redes Zig-

Bee quanto pelas redes IP. Isso se deve ao fato de ter sido utilizado redes ZigBee na comunicacao

2http://code.google.com/p/xbee-arduino3http://www.digi.com/support/kbase/kbaseresultdetl.jsp?kb=125

3.1 Arquitetura 38

dos controladores de dispositivos, por causa das caracterısticas ja descritas na Secao 2.2, e os

telefones inteligentes presentes no mercado nao poderem se comunicar nessas redes, sendo ca-

pazes de se comunicar apenas nas redes IP. Por essa razao, cabe ao SAR a transferencia das

mensagens entre essas duas redes.

O servidor de automacao residencial deve permanecer operando constantemente, pois, alem

de gerenciar as mensagens trocadas entre os membros da rede, ele e responsavel tambem por

executar tarefas agendadas pelo usuario como acender ou apagar as luzes de determinadas

lampadas em determinadas datas.

O SAR foi implementado em forma de um software rodando num computador pessoal. Para

essa aplicacao se comunicar com o cliente no Android e necessario que esse computador esteja

conectado em alguma rede IP, ja para a comunicacao com os kits Arduino, e necessario que

haja um modulo XBee, assim como nos Arduinos, conectado em uma das portas USB desse

computador (Figura 3.2). Esse modulo XBee tem que estar configurado como coordenador da

rede ZigBee e, assim, ser o responsavel pelas configuracoes dessa rede.

Uma alternativa para a comunicacao na rede IP por parte da aplicacao servidora, e a utilizacao

de sockets Transmission Control Protocol (TCP) diretamente. Sockets sao interfaces, acessıveis

na camada de aplicacao, que permitem criar conexoes na rede IP utilizando um endereco dessa

rede e uma porta TCP. A utilizacao deles e bastante simples e, por isso, sistemas que tenham

uma grande quantidade de conexoes simultaneas terao que implementar uma logica adicional

para suportar essa demanda.

Aplicacoes servidoras de grande porte e que necessitem que tarefas complexas sejam exe-

cutadas em segundo plano, podem ser implementadas fazendo uso de aplicacoes Web. Essas

aplicacoes funcionam como extensoes de servidores Web e, por isso, procedimentos como o

controle de acessos, manutencao de sessoes das conexoes e manipulacao de mensagens de pro-

tocolos da camada de aplicacao, sao transparentes ao desenvolvedor durante a escrita destas

aplicacoes.

Uma das tecnologias para aplicacoes Web testadas nesse trabalho foram os Servicos Web.

Eles tem como principal caracterıstica a comunicacao multiplataforma, ou seja, servicos ope-

rando em sistemas distintos podem comunicar-se diretamente. Essa transparencia e conseguida

pelo fato dos dados, de ambos os lados, serem enviados por meio de XML. A utilizacao de

XML implica num numero maior de bytes na troca de mensagens se comparada a transmissao

de mensagens contendo informacao pura. Outra caracterıstica dos Servicos Web e que eles nao

guardam o estado das variaveis do seu codigo, sendo necessaria a utilizacao de servicos adi-

cionais, como banco de dados, para isso, o que pode ser um incomodo na fase inicial de um

3.1 Arquitetura 39

projeto.

Para a implementacao do SAR foi utilizado um Servlet. Os Servlets sao programas escritos

em Java utilizados em aplicacoes Web. Eles tem o acesso direto as requisicoes HTTP recebidas

pelo servidor Web, portanto, podem interagir com qualquer aplicacao cliente que tambem utilize

HTTP para se comunicar. Diferentemente dos servicos Web, eles consistem em classes Java

instanciadas uma unica vez - quando o servidor Web e iniciado - o que os permite memorizar as

variaveis dos seus codigos e mante-las durante todo o tempo de execucao.

A aplicacao Web na qual consiste o SAR deve rodar sobre um servidor Web que suporte

esse tipo de tecnologia e, consequentemente, atue como uma interface de acesso a rede externa

para esta. No projeto DroidLar foi utilizado o servidor de aplicacao GlassFish4 porem, outros

servidores de aplicacao que tambem oferecem esse tipo de suporte poderiam ser utilizados,

como por exemplo o Apache Tomcat5.

Para a escrita da logica para a comunicacao com os kits Arduino pela rede ZigBee, foi

utilizada uma API6 em Java. Essa API, assim como a utilizada para a programacao dos Ar-

duinos, possibilita de maneira simples acessar os dados dos pacotes recebidos tais como seu

endereco de origem, a funcao desse dispositivo na rede ZigBee (se e roteador ou end-device)

e as informacoes, propriamente ditas. Alem disso, ele possibilita o envio de comandos AT

ao modulo conectado ao SAR, o que possibilita o acesso por codigo das configuracoes desse

modulo.

O SAR possui a funcionalidade de executar varreduras na rede ZigBee. Essa acao e tomada

toda vez em que ele recebe uma requisicao do cliente Android. O SAR entao envia uma men-

sagem para todos os dispositivos da rede ZigBee e os que estiverem ativos respondem com suas

informacoes e, assim, e possıvel atualizar as listas com os dados conhecidos pelo servidor.

O SAR pode, ainda, receber tanto mensagens de controle quanto mensagens de gerencia-

mento. As mensagens de controle sao enderecadas aos controladores de dispositivos para to-

marem acoes como a de acender parcialmente determinada lampada, tendo o SAR a funcao de

recebe-las da rede IP e transferi-las para a rede ZigBee e vice-versa. Ja as mensagens de geren-

ciamento sao trocadas apenas entre o SAR e os clientes Android e podem ser para autenticacao

ou edicao de perfis.

4http://glassfish.java.net5http://tomcat.apache.org6http://code.google.com/p/xbee-api

3.1 Arquitetura 40

3.1.3 Cliente Android

Com a popularizacao dos telefones inteligentes foi possıvel a criacao de interfaces de con-

trole para sistemas de automacao residencial mais sofisticadas e com uma usabilidade maior

para o usuario. Por isso, no DroidLar foi utilizado como interface de controle uma aplicacao

disponıvel para telefone inteligentes que rodem Android.

Essa aplicacao atua como um cliente enviando requisicoes ao servidor, para executar suas

funcoes. Ela utiliza as conexoes de rede disponıveis em telefones Android como 3G e Wi-Fi,

para se conectar a uma rede IP. Quando esta conectado a uma rede IP, a aplicacao pode enviar as

mensagens com os comandos ao SAR utilizando o protocolo HTTP, como visto na Secao 3.1.2.

A aplicacao cliente nao necessita estar o tempo todo conectada ao SAR, mas somente quando

for enviar algum comando.

Quando o usuario acessa a aplicacao e exibida a ele a tela mostrada na Figura 3.4(a). Nela

estao presentes todas as funcoes que o usuario pode executar no sistema. Para executar qualquer

funcionalidade no sistema, o usuario precisa estar autenticado no servidor. Por isso, na primeira

vez que o usuario acessa o aplicativo, a tela mostrada e a de configuracoes (Figura 3.4(b)).

Nessa tela o usuario deve inserir seus dados de identificacao e senha, alem do endereco IP e

porta utilizados pelo SAR. Caso queira fazer alteracoes nesses dados, o usuario pode clicar no

botao com um ıcone de engrenagem na tela inicial.

(a) Tela inicial (b) Informacoes sobre o servidor

Figura 3.4: Interface principal e de configuracao do SAR

3.1 Arquitetura 41

A Figura 3.5(a) demonstra uma tela para o controle de lampadas. Nela o usuario pode

acender ou apagar quaisquer lampadas da lista apenas clicando no seu ıcone, ou pode confi-

gura-las com um nıvel intermediario de luminosidade arrastando o dedo na barra horizontal

correspondente a essa lampada.

O controle de lampadas e baseado no envio de valores numericos, correspondentes ao estado

em que se queira configurar a lampada, aos controladores de dispositivos. Em valores percen-

tuais seriam 0% para apagar totalmente uma lampada e 100% para acende-la. Dessa forma, e

possıvel utilizar esse sistema de valores para controlar diversos itens da residencia como persi-

anas e portoes eletronicos. A unica diferenca esta no equipamento acoplado as saıdas do con-

trolador, que no caso das lampadas, tem apenas que reduzir ou aumentar a tensao proveniente

da rede eletrica da residencia.

Outra funcionalidade presente no cliente Android e o gerenciamento de perfis. Ele pode

ser iniciado clicando-se no botao com um ıcone de relogio na tela principal, encaminhando o

usuario para a tela mostrada na Figura 3.5(b). Nela, o usuario pode criar, editar e excluir perfis.

Esses perfis sao grupos de dispositivos que serao acionados na mesma data. Os dispositivos per-

tencentes a algum perfil possuem um horario inicial para serem configurados com determinado

valor e um horario final para configurar outro valor. Mesmo sendo executados na mesma data,

dispositivos pertencentes a um mesmo perfil podem ser executados em horarios diferentes.

(a) Controle dos dispositivos (b) Configuracao dos perfis

Figura 3.5: Interfaces para configuracao dos dispositivos e perfis

3.2 Protocolo 42

3.2 Protocolo

Para a comunicacao entre as tres partes do DroidLar, foi necessaria a criacao de um pro-

tocolo na camada de aplicacao. As mensagens desse protocolo podem ter destinos diferentes

dependendo do seu tipo. Como visto anteriormente, elas sao transmitidas pelo cliente Android e

recebidas pelo SAR utilizando o protocolo HTTP, por isso, os dados sao passados como strings.

As mensagens entre o SAR e os controladores, que trafegam pela rede ZigBee, sao enviadas em

forma de valores do tipo inteiro. Para evitar erros, os campos das mensagens que passarem

pelas duas redes foram padronizados com valores numericos.

3.2.1 Cliente Android – SAR

As mensagens trocadas entre o cliente Android e o SAR servem para configurar as funci-

onalidades extras do DroidLar. Funcoes de seguranca, agendamento de perfis e configuracoes

dos dispositivos, agregam recursos ao sistema e aumentam as possibilidades de uso do mesmo,

alem do simples acender e apagar de lampadas. Com excecao das mensagens de autenticacao,

essas mensagens sao divididas nos seguintes campos: Tipo, Endereco, Conteudo, e Opcional

(Figura 3.6). Porem, para as mensagens a seguir (exceto a de autenticacao) serao utilizados

apenas os campos Tipo e Conteudo.

Tipo Conteúdo OpcionalEndereço

Figura 3.6: Mensagem de controle padrao.

Autenticacao

A mensagem de autenticacao e indicada pela constante MSG AUTENTICACAO. Para o

envio dos dados de usuario e senha sao utilizados os campos de Endereco e Conteudo presentes

nas demais mensagens, como e mostrado na Figura 3.7.

Tipo Senha OpcionalUsuário

Figura 3.7: Mensagem de controle usada na autenticacao.

Quando o aplicativo cliente deseja se conectar no sistema, ele simplesmente envia uma

mensagem MSG AUTENTICACAO contendo seus dados. Ao receber essa mensagem o SAR ira

verificar se esses dados pertencem a algum usuario ja cadastrado no sistema. Se ele encontrar,

o usuario recebera uma mensagem de confirmacao, apenas com o campo Tipo preenchido com

3.2 Protocolo 43

a constante MSG SUCESSO, indicando que esta apto a operar as funcoes do sistema, caso

contrario, recebera uma mensagem de erro, contendo apenas a constante MSG ERRO como

tipo (Figura 3.8).

Figura 3.8: Mensagem de autenticacao.

Requisicao de Dispositivos

Para montar a lista de dispositivos que serao controlados ou mesmo adicionados em algum

perfil, o cliente Android utiliza informacoes contidas no SAR, ou seja, elas nao ficam armaze-

nadas no dispositivo movel, sempre que for necessario o cliente fara uma requisicao ao SAR

dessa lista contendo as informacoes dos dispositivos.

O cliente Android pode requisitar a lista completa de dispositivos contida no SAR, para isso

e enviada uma mensagem com o tipo definido pela constante REQUEST DISP. Em seguida o

servidor envia a lista com as informacoes de todos os dos dispositivos ativos (Figura 3.9). Em

determinados momentos a aplicacao necessita apenas das informacoes de determinados tipos

de dispositivos, para isso, e enviada uma mensagem do tipo REQUEST TIPO (Figura 3.10).

Figura 3.9: Mensagem de requisicao das informacoes de todos os dispositivos.

3.2 Protocolo 44

Figura 3.10: Mensagem de requisicao das informacoes de dispositivos pelo tipo.

Alteracao de Perfis

A sequencia da Figura 3.11 e executada sempre que o usuario acessa a tela de configuracoes

de perfis no cliente Android. Primeiramente uma mensagem do tipo REQUEST PERFIL UUID

e enviada solicitando o valor de identificacao da atual versao de perfis configurados no SAR. Se

esse valor for diferente do valor contido na aplicacao cliente significa que as configuracoes de

perfis presentes nesse cliente nao sao as mais recentes. Quando isso acontecer, sera requisitado

ao usuario sobrescrever as suas configuracoes locais com as do servidor, ou o processo contrario,

sobrescrever as configuracoes do servidor com as suas.

Figura 3.11: Mensagem de requisicao do ID da lista de perfis.

Quando quiser enviar suas configuracoes de perfis ao SAR o usuario deve enviar uma men-

sagem do tipo MSG PERFIL inserindo no campo Conteudo uma string formatada contendo

essas configuracoes (Figura 3.12).

Se o usuario optar em receber os perfis configurados no servidor, entao, a aplicacao enviara

uma mensagem do tipo REQUEST PERFIL. Como resposta sera recebida uma string formatada

com as configuracoes de perfis atuais do SAR (Figura 3.13).

Configurar Nomes

A configuracao dos nomes pode ser efetuada apenas por usuarios que contenham permissao

de superusuario. Para alterar os nomes dos dispositivos configurados na aplicacao Android

no SAR, e enviada a ele uma mensagem do tipo MSG SET NOME com o campo Conteudo

3.2 Protocolo 45

Figura 3.12: Mensagem de atualizacao de perfis.

Figura 3.13: Mensagem de requisicao da lista de perfis.

preenchido com uma string contendo os novos nomes dos dispositivos. Em caso de sucesso,

sera recebida uma mensagem de confirmacao do tipo MSG SUCESSO, caso contrario, se o

usuario autenticado nao possuir privilegios de superusuario, entao, sera recebida a mensagem

do tipo MSG ERRO (Figura 3.14).

Figura 3.14: Mensagem de configuracao dos nomes.

Configurar Varredura Periodica

Outra funcionalidade configurada apenas por superusuarios e a varredura periodica. Para

isso, e enviada uma mensagem do tipo SET VARREDURA inserindo no campo Conteudo um va-

3.2 Protocolo 46

lor correspondente ao intervalo de tempo entre as varreduras. Como resposta sera recebida uma

mensagem do tipo MSG SUCESSO, se o usuario possuir privilegios de superusuario, senao,

sera recebida uma mensagem do tipo MSG ERRO (Figura 3.15).

Figura 3.15: Mensagem de configuracao da varredura periodica.

3.2.2 Cliente Android – SAR – Controladores

Controle

A principal funcionalidade do cliente Android e a possibilidade de controle dos eletro-

eletronicos da residencia. Atraves do envio de mensagens do tipo MSG CONTROLE e realizado

esse controle. No campo Endereco e inserido o endereco de 64 bits da rede ZigBee do contro-

lador que devera executar esse comando. O campo Conteudo e preenchido com o valor que o

dispositivo controlado devera assumir, sendo 0 para totalmente desligado e 255 para totalmente

ligado. Ja o campo Opcional nao tem funcao especıfica. Nesse trabalho os kits Arduino foram

configurados para controlar ate tres dispositivos, por isso, o campo Opcional foi utilizado para

indicar a qual desses tres eletros controlados se destinava ocomando (Figura 3.16).

Varredura

A mensagem de varredura tem como objetivo recolher informacoes dos controladores ati-

vos no sistema de forma automatica. Para isso, e necessario o envio de uma mensagem do tipo

MSG VARREDURA. Quando essa mensagem e recebida pelo SAR, o mesmo envia uma men-

sagem, do tipo REQUEST INFO, em broadcast pela rede ZigBee requisitando as informacoes

dos dispositivos. Os controladores que estiverem ativos na rede responderao ao SAR enviando

mensagens do tipo RESPONSE INFO. O servidor utilizara essas mensagens para atualizar suas

listas com as informacoes dos controladores. Ao inves dessas informacoes, o cliente Android re-

3.2 Protocolo 47

Figura 3.16: Mensagem de controle.

cebera como resposta do SAR apenas uma mensagem de confirmacao, ja que essas informacoes

recebidas serao requisitadas posteriormente (Figura 3.17).

Figura 3.17: Mensagem de varredura.

3.2.3 SAR – Controladores

Informacoes Iniciais

Sempre que um controlador de dispositivos e ligado ele tenta se conectar na rede ZigBee e

enviar suas configuracoes ao SAR tais como seu endereco, quantos e que tipo de dispositivos

ele controla. Para isso, o controlador envia uma mensagem do tipo RESPONSE INFO, a mesma

que ele envia durante a varredura, para o endereco zero, correspondente ao coordenador da rede

ZigBee, utilizado pelo modulo XBee do SAR (Figura 3.18).

Atualizacao de Estado

Quando o usuario altera o estado de um dispositivo sem utilizar a aplicacao do Android,

como por exemplo acender a luz utilizando um interruptor, e enviado ao SAR uma mensagem

3.3 Casos de Uso 48

Figura 3.18: Mensagem com as informacoes.

contendo esse novo estado do eletroeletronico. Essa mensagem e do tipo UPDATE ESTADO

e serve para manter as interfaces de controles sempre atualizadas, mesmo quando ocorrerem

alteracoes externas (Figura 3.19).

Figura 3.19: Mensagem de atualizacao.

3.3 Casos de Uso

A Figura 3.20 contem o diagrama com as possibilidades de uso da aplicacao, ou seja, as

acoes que um usuario pode executar enquanto estiver utilizando o cliente Android. E possıvel

perceber que um pre-requisito para todos os casos e a autenticacao do usuario no sistema, inclu-

sive como superusuario, nos casos “Alterar os nomes das lampadas” e “Configurar a varredura

periodica”.

Autenticar no sistema

Na primeira vez em que abrir a aplicacao ou selecionando a opcao configuracoes, no menu

inicial da aplicacao, o usuario sera encaminhado para a interface de configuracoes do aplicativo.

Nela, o usuario deve inserir seus dados de usuario e senha, alem do endereco IP e porta do

servidor. Depois de inserir as informacoes, o usuario deve clicar no botao “Salvar” para o

aplicativo memoriza-las.

Acender e apagar lampadas

O usuario abre a aplicacao e seleciona a opcao de controlar as lampadas, entao, e exibida

a ele a interface com uma lista de lampadas carregadas do servidor, para serem controladas.

Quando ele clica num dos ıcones de lampadas, a mesma inverte seu estado, ou seja, se estava

apagada acende e vice-versa.

3.3 Casos de Uso 49

Controlar a intensidade das lampadas



Quando ele arrasta uma das barras de controle a intensidade de luz se altera, indo de totalmente

acesa a completamente apagada.

Figura 3.20: Diagrama de casos de uso da aplicacao.

Sincronizar perfis

O usuario abre a aplicacao e seleciona a opcao de perfis, entao, e exibida a ele a interface

para o gerenciamento de perfis. Quando a interface e exibida a aplicacao envia, automatica-

mente, ao servidor uma mensagem para verificar se o mesmo contem uma lista de perfis mais

atual. Caso exista, sera requisitado ao usuario escolher entre sobrescrever os seus perfis com os

do servidor, ou sobrescrever os do servidor com os seus. Depois de feita a verificacao, e exibida

3.3 Casos de Uso 50

ao usuario a lista de perfis.

Adicionar perfis

O usuario esta na interface de gerenciamento de perfis, apos ter sincronizado seus perfis

com o servidor. Ele abre o menu de opcoes da aplicacao e seleciona a opcao “Criar Perfil”. E

exibida a ele uma interface onde deve ser inserido um nome para o perfil e, tambem, deve ser

selecionado os dias da semana ou do mes que esse perfil deve ser executado. Por fim, ele deve

confirmar a criacao do perfil clicando no botao “Criar”. Em seguida ele voltara para a interface

de configuracao de perfis. Para salvar as alteracoes dos perfis no servidor, o usuario deve abrir

o menu de opcoes e selecionar a opcao “Salvar Perfis”.

Remover perfis


com o servidor. Ele abre o menu de contexto de um determinado perfil da lista e seleciona

a opcao “Remover Perfil”. Entao, quando ele for requisitado se deseja confirmar a exclusao

do perfil deve responder que sim. Em seguida ele voltara para a interface de configuracao de

perfis. Para salvar as alteracoes dos perfis no servidor, o usuario deve abrir o menu de opcoes e

selecionar a opcao “Salvar Perfis”.

Alterar perfis

O usuario esta na interface de gerenciamento de perfis, apos ter sincronizado seus perfis com

o servidor. Ele abre o menu de contexto de um determinado perfil da lista e seleciona a opcao

“Editar Perfil”. Sera exibida uma interface com o nome e os dias de execucao configurados

nesse perfil. O usuario tem apenas que alterar os dados que quiser e confirmar o salvamento das

informacoes clicando no botao “Salvar”. Em seguida ele voltara para a interface de configuracao

de perfis. Para salvar as alteracoes dos perfis no servidor, o usuario deve abrir o menu de opcoes

e selecionar a opcao “Salvar Perfis”.

Adicionar dispositivos


com o servidor. Ele abre o menu de contexto de um determinado perfil da lista e seleciona

a opcao “Adicionar Dispositivo”. Sera exibida a ele uma interface onde e possıvel escolher o

tipo de dispositivo que sera adicionado, a lista de dispositivos disponıveis do tipo escolhido

anteriormente, os horario iniciais e finais para a execucao desse dispositivo no perfil ao qual

pertence, juntamente com os valores inicial e final para o estado desse dispositivo. Depois de

configurar essas informacoes o usuario deve confirmar o salvamento delas clicando no botao

“Salvar”. Em seguida ele voltara para a interface de configuracao de perfis. Para salvar as

3.3 Casos de Uso 51

alteracoes dos perfis no servidor, o usuario deve abrir o menu de opcoes e selecionar a opcao

“Salvar Perfis”.

Remover dispositivos

O usuario esta na interface de gerenciamento de perfis, apos ter sincronizado seus perfis com

o servidor. Ele abre o menu de contexto de um determinado dispositivo da lista e seleciona a

opcao “Remover Dispositivo”. Entao, quando ele for requisitado se deseja confirmar a exclusao

do dispositivo deve responder que sim. Em seguida ele voltara para a interface de configuracao

de perfis. Para salvar as alteracoes dos perfis no servidor, o usuario deve abrir o menu de opcoes

e selecionar a opcao “Salvar Perfis”.

Alterar dispositivos


com o servidor. Ele abre o menu de contexto de um determinado dispositivo da lista e seleciona

a opcao “Editar Dispositivo”. Sera exibida uma interface com o tipo, os horarios e os valores

iniciais e finais configurados nesse dispositivo. O usuario tem apenas que alterar os dados

que quiser e confirmar o salvamento das informacoes clicando no botao “Salvar”. Em seguida

ele voltara para a interface de configuracao de perfis. Para salvar as alteracoes dos perfis no

servidor, o usuario deve abrir o menu de opcoes e selecionar a opcao “Salvar Perfis”.

Executar varredura

O usuario deve abrir o menu de opcoes na interface inicial da aplicacao e selecionar a opcao

“Fazer Varredura”. O aplicativo mandara a mensagem de varredura ao servidor que respondera

com uma mensagem de confirmacao do recebimento da mesma, sendo esta confirmacao visıvel

ao usuario em forma de um aviso na tela.

Alterar os nomes das lampadas



Quando o usuario abre um menu de contexto contido nos nomes das lampadas, e apresentada

a ele uma segunda interface contendo o nome atual da lampada. Depois de edita-lo o usuario

confirmar as alteracoes clicando no botao “OK”, fazendo-o voltar para a interface de controle

das lampadas. Para salvar as alteracoes nos nomes das lampadas no servidor, o usuario deve

abrir o menu de opcoes e selecionar a opcao “Salvar Nomes”.

Configurar a varredura periodica

O usuario deve abrir o menu de opcoes na interface inicial da aplicacao e selecionar a opcao

3.3 Casos de Uso 52

“Varredura Periodica”. Em seguida, sera exibida uma interface onde o usuario pode escolher o

tempo de intervalo entre as varreduras. O usuario pode ativar ou desativar a varredura periodica

no servidor clicando nos botoes “Ativar” ou “Desativar”.

53

4 Conclusoes

Os sistemas de automacao residencial atuais oferecem como interfaces de controle paineis

afixados em paredes, controles remotos, paginas Web ou aplicacoes para celulares. O sistema

operacional Android (OPEN HANDSET ALLIANCE, 2008) e um projeto aberto e por isso,

e utilizado em uma grande quantidade de telefones inteligentes. Ele possibilita a criacao de

aplicacoes tao complexas quanto as utilizadas em computadores pessoais.

Nesse trabalho foi apresentado o sistema de automacao residencial DroidLar. Ele permite

que um aplicativo rodando em celulares Android controle os eletroeletronicos de uma residencia

e possibilita tambem, o agendamento de comandos com a utilizacao de perfis. Esse sistema e

aberto, e seu codigo pode ser obtido em http://goo.gl/VZUYF.

Os controladores de dispositivos sao os elementos do sistema que executam os comandos

nos eletroeletronicos da residencia. Eles devem consumir pouca energia pois podem ser posi-

cionados em qualquer local da residencia podendo, inclusive, operar sem estarem conectados a

rede eletrica.

O protocolo ZigBee (ZIGBEE ALLIANCE, 2005) e tipicamente utilizado em redes de

baixa taxa de transmissao e com transmissores de baixa potencia. Por isso, ele se torna ener-

geticamente economico possibilitando que os dispositivos transmissores sejam alimentados por

baterias. Para aumentar a extensao da rede o ZigBee permite que dispositivos atuem como

roteadores e encaminhem as mensagens, formando uma topologia em forma de malha.

Essas caracterısticas do ZigBee foram decisivas na sua escolha como a tecnologia para

a comunicacao dos controladores de dispositivos. Para a prototipagem desses controladores

foram utilizados kits Arduino1. Esses kits fazem parte de uma plataforma aberta de hardware

que visa o desenvolvimento de uma ferramenta de facil utilizacao ate mesmo para leigos. Para

esses kits se comunicarem na rede ZigBee foram acoplados a eles modulos XBee2.

Como telefones inteligentes possibilitam a comunicacao em diversos tipos de rede sem

1http://www.arduino.cc2http://www.digi.com

4.1 Trabalhos Futuros 54

fio como Wi-Fi (IEEE, 2007) e 3G, mas nao se comunicam em redes ZigBee, foi necessario o

desenvolvimento de um servidor centralizado na rede. O SAR tem como principal funcao trans-

ferir as mensagens vindas do cliente Android pela rede IP para os controladores de dispositivos

na rede ZigBee.

4.1 Trabalhos Futuros

Esse trabalho tem o objetivo de ser o ponto de partida para a criacao de um sistema de

automacao residencial tao sofisticado quanto os presentes no mercado. Por se tratar de um

projeto de codigo aberto e que utiliza tecnologias abertas, sao inumeras as possibilidades de

adaptacoes, modificacoes e insercao de novos recursos.

Como trabalho futuro pode ser embarcado o SAR em um dispositivo micro controlado,

tornando o sistema mais economico, pois, evitaria a utilizacao de um computador pessoal ligado

constantemente. Alem disso, a utilizacao de um dispositivo menor traria mobilidade ao servidor.

Outro trabalho futuro seria a expansao dos tipos de dispositivos que podem ser controlados

atraves da aplicacao Android, pois, atualmente apenas lampadas sao suportadas. Esse processo

envolveria, alem da modificacao do codigo do cliente Android, a criacao de hardware extra

conectado aos controladores de dispositivos.

55

Lista de Abreviaturas

PWM Pulse Width Modulation

API Application Programming Interface

IP Internet Protocol

TCP Transmission Control Protocol

CA Corrente Alternada

RF Radiofrequencia

CRC Cyclic Redundancy Check

BPSK Binary Phase Shift Keying

ISM Industrial, Scientific and Medical

CSMA/CA Carrier Sense Multiple Access With Collision Avoidance

DSSS Direct Sequence Spread Spectrum

FFD Full Function Devices

RFD Reduced Function Devices

FCS Frame Checksum Sequence

MAC Message Authentication Code

IDE Integrated Development Environment

SDK Software Development Kit

XML Extensible Markup Language

MHR Medium Access Control Header

MFR Medium Access Control Footer

56

LR-WPAN Low-Rate Wireless Personal Area Network

MAC Layer Medium Access Control Layer

PHY Physical Layer

MAC Payload Medium Access Control Payload

57

Referencias Bibliograficas

BLUETOOTH, S. Bluetooth specification. 1998.

CHUNDURU, V.; SUBRAMANIAN, N. Effects of power lines on performance of homecontrol system. In: IEEE. Power Electronics, Drives and Energy Systems, 2006. PEDES’06.International Conference on. [S.l.], 2006. p. 1–6.

DA SILVA, A. A. J. P. Visaoweb - vigilancia e controlo remoto. In: . 2005. Disponıvelem: <http://repositorio-aberto.up.pt/bitstream/10216/11540/2/Texto%

20integral.pdf>. Acesso em: 16 mai. 2011.

DAEMEN, J.; RIJMEN, V. The design of Rijndael: AES–the advanced encryption standard.[S.l.]: Springer Verlag, 2002.

DARBEE, P. Insteon: The details. Smarthome Technology, p. 1–64, 2005.

DIGI INTERNATIONAL INC. Product manual v1.xex – 802.15.4 protocol. pdf. ieee802.15. 4 oem rf modules. 2009. Disponıvel em: <http://ftp1.digi.com/support/

documentation/90000982_B.pdf>.

EUROX10. Teoria da transmissao de sinais x-10. In: . 2011. Disponıvel em:<http://www.eurox10.com/Content/X10SignalTheory.htm>. Acesso em: 26 jul. 2011.

HERRADOR, R. E. Guıa de usuario de arduino. 2009. Disponıvel em: <http:

//www.uco.es/aulasoftwarelibre/wp-content/uploads/2010/05/Arduino_user_

manual_es.pdf>. Acesso em: 26 mai. 2011.

IEEE. Part 15.4: Wireless Medium AccessControl (MAC) and Physical Layer (PHY)Specifications for Low-Rate Wireless PersonalArea Networks (WPANs). [S.l.], jun. 2006.Disponıvel em: <http://www.http://standards.ieee.org/getieee802/download/

802.15.4-2006.pdf>.

IEEE. Wireless lan medium access control (mac) and physical layer (phy) specifications. IEEEStd 802.11-2007 (Revision of IEEE Std 802.11-1999), p. C1–1184, 12 2007.

OPEN HANDSET ALLIANCE. Android operating system. 2008. Disponıvel em:<http://www.android.com>.

PINHEIRO, J. M. S. Sistemas de automacao. In: . 2004. Disponıvel em: <http:

//www.projetoderedes.com.br/artigos/artigo_sistemas_automacao.php>. Acessoem: 8 mai. 2011.

SARASWAT, V. et al. The X10 language specification. [S.l.], 2008.

SASTRY, N.; WAGNER, D. Security considerations for ieee 802.15. 4 networks. In: ACM.Proceedings of the 3rd ACM workshop on Wireless security. [S.l.], 2004. p. 32–42.

Referencias Bibliograficas 58

SENA, D. Automacao residencial. 2005. Disponıvel em: <http://www2.ele.ufes.br/

~projgrad/documentos/PG2005_2/dianecristinasouzasena.pdf>.

WADDINGTON, N.; TAYLOR, R. Arduino & Open Source De-sign. 2007. Disponıvel em: <http://web.media.mit.edu/~mellis/

arduino-chi2007-mellis-banzi-cuartielles-igoe.pdf>.

Z-WAVE ALLIANCE. Z-wave technology. 2004. Disponıvel em: <http://www.z-wave.

com>.

ZIGBEE ALLIANCE. Zigbee specification. ZigBee Document 053474r06, Version, v. 1, 2005.

DroidLar - Automac¸ao residencial atraves de um celular android.pdf

Documents

Transcript of DroidLar - Automac¸ao residencial atraves de um celular android.pdf