Embed Size (px)
Citation preview
TRABALHO DE GRADUAÇÃO
Central para Automação Residencial:
Controle por dispositivo portátil com rede
de sensores/atuadores sem fio.
Danilo Henrique Esteves – RA 610127
Prof. Dr. Galdenoro Botura Jr.
SOROCABA
2011
UNIVERSIDADE ESTADUAL PAULISTA
“JÚLIO DE MESQUITA FILHO”
Campus Experimental de Sorocaba
DANILO HENRIQUE ESTEVES
CENTRAL PARA AUTOMAÇÃO RESIDENCIAL: CONTROLE POR DISPOSITIVO
PORTÁTIL COM REDE DE SENSORES/ATUADORES SEM FIO
Trabalho de graduação apresentado ao Conselho de Curso de Engenharia de Controle e Automação, Universidade Estadual Paulista “Júlio de Mesquita Filho”, como requisito parcial para a obtenção do grau de Engenheiro de Controle e Automação. Orientador: Prof. Dr. Galdenoro Botura Jr.
SOROCABA
2011
FICHA CATALOGRÁFICA
Esteves, Danilo Henrique Central Para Automação Residencial: Controle Por Dispositivo Portátil Com Rede De Sensores/Atuadores Sem Fio – Sorocaba, 2011. 85 páginas
Orientador: Prof. Dr. Galdenoro Botura Jr. Trabalho de Graduação – UNESP Universidade Estadual Paulista “Júlio de Mesquita Filho”
1.Automação Residencial; 2. Redes sem fio; 3. Zigbee
À minha família e amigos por toda contribuição e apoio que fizeram com que
chegasse até o fim...
Ao meu avô, Henrique, que está no céu...
Dedico
AGRADECIMENTOS
Aos meus amigos e companheiros de projeto, Bruno e Pedro, sem os quais
o sistema não teria sido concluído.
Ao Prof. Dr. Galdenoro Botura Jr., pelas sábias orientações durante o
período de trabalho e durante a graduação.
À banca examinadora, escolhida devido à área de atuação dos profissionais
que a compõe, os quais transmitiram muito dos conhecimentos técnicos necessários
para o desenvolvimento deste trabalho.
“Aquilo que não me mata, só me fortalece.”
Friedrich Nietzsche.
SUMÁRIO
LISTA DE TABELAS ................................................................................................. X
RESUMO................................................................................................................... XI
ABSTRACT .............................................................................................................. XII
1 INTRODUÇÃO E OBJETIVOS ............................................................................. 1
2 APRESENTAÇÃO DAS TECNOLOGIAS ENVOLVIDAS .................................... 7
2.1 ZIGBEE .............................................................................................................. 7
2.1.1 Características técnicas .................................................................................. 7
2.1.2 Arquitetura Zigbee ......................................................................................... 10
2.1.3 Dispositivos em uma Rede Zigbee ................................................................ 11
2.1.4 Roteamento de Dados e Modos de Comunicação ........................................ 12
2.1.5 Frame de Dados ............................................................................................ 13
2.1.5.1 AT............................................................................................................... 14
2.1.5.2 API ............................................................................................................. 14
2.2 WI-FI ................................................................................................................. 16
2.2.1 Estrutura da rede ........................................................................................... 17
2.2.2 Distribution Systems ...................................................................................... 18
2.2.2.1 Distribution System Services ...................................................................... 18
2.2.2.2 Station Services ......................................................................................... 19
2.2.3 Camada Física .............................................................................................. 19
2.2.4 Camada de Data Link .................................................................................... 20
2.3 CLASSE SOCKETS ......................................................................................... 21
2.3.1 Conexões síncronas ...................................................................................... 21
2.3.2 Conexões Assíncronas.................................................................................. 21
2.4 CLASSE SERIALPORT .................................................................................... 22
2.5 MULTITHREADING.......................................................................................... 23
3 ESPECIFICAÇÃO ............................................................................................... 24
3.1 METODOLOGIA ............................................................................................... 28
4 ARQUITETURA DO SISTEMA ........................................................................... 30
4.1 DESCRIÇÃO DO PROJETO ............................................................................ 30
4.1.1 Aspectos gerais ............................................................................................. 30
4.1.2 Comunicação Zigbee .................................................................................... 31
4.1.2.1 X-CTU ........................................................................................................ 31
4.1.2.2 Frames de dados Zigbee ........................................................................... 33
4.1.2.3 Parametrização .......................................................................................... 37
4.1.2.4 Parametrização dos módulos para a aplicação .......................................... 38
4.1.3 Comunicação Wi-fi ........................................................................................ 40
4.1.3.1 Frame de dados Wi-fi ................................................................................. 41
4.1.4 Software desenvolvido .................................................................................. 43
4.1.4.1 Software – Xbee ......................................................................................... 47
4.1.4.1.1 Conexão .................................................................................................. 47
4.1.4.1.2 Manipulação ............................................................................................ 47
4.1.4.1.3 Envio ....................................................................................................... 48
4.1.4.2 Software – Wi-fi .......................................................................................... 49
4.1.4.2.1 Conexão .................................................................................................. 49
4.1.4.2.2 Loop de Leitura ....................................................................................... 50
4.1.4.2.3 Manipulação ............................................................................................ 51
4.1.4.2.4 Envio ....................................................................................................... 52
4.2 TESTES E SIMULAÇÕES ................................................................................ 53
4.2.1 Teste de comunicação com Zigbee ............................................................... 53
4.2.2 Testes de comunicação com Wi-fi ................................................................. 54
4.2.3 Teste das funções de análise e manipulação de dados ................................ 55
5 RESULTADOS .................................................................................................... 56
5.1 GRAPHIC USER INTERFACE ......................................................................... 56
5.2 COMUNICAÇÃO ZIGBEE ................................................................................ 57
5.3 COMUNICAÇÃO VIA WI-FI .............................................................................. 61
5.4 FUNÇÕES DE MANIPULAÇÃO ....................................................................... 62
5.5 TESTES GERAIS COM INTEGRAÇÃO DE SISTEMAS .................................. 64
6 CONCLUSÕES ................................................................................................... 65
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 68
APÊNDICE 1 - CÓDIGO FONTE DA APLICAÇÃO DESENVOLVIDA .................... 72
ANEXO 1 – LISTA DE COMANDOS AT .................................................................. 73
LISTA DE ILUSTRAÇÕES
FIGURA 1 - ARQUITETURA GERAL DO SISTEMA. .............................................................................. 5
FIGURA 2 - CONFIGURAÇÃO MESH DE UMA REDE ZIGBEE. (MESSIAS, 2009) .............................. 8
FIGURA 3 - MÓDULO XBEE DIGI. (ALBACORE, 2010) ........................................................................ 8
FIGURA 4 - REPRESENTAÇÃO DE NÓS SEM A CHAVE DE SEGURANÇA EM UMA REDE. (ALBACORE, 2010) ....................................................................................................... 10
FIGURA 5 - CAMADAS DA ARQUITETURA DE REDE ZIGBEE. ........................................................ 10
FIGURA 6 - TRANSMISSÃO BROADCAST. (ALBACORE, 2010) ........................................................ 13
FIGURA 7 - TRANSMISSÃO UNICAST. (ALBACORE, 2010) .............................................................. 13
FIGURA 8 – EXEMPLO DE MODO DE TRANSMISSÃO AT. (ALBACORE, 2010) .............................. 14
FIGURA 9 - FRAME PARA COMUNICAÇÃO API. (ALBACORE, 2010) ............................................... 15
FIGURA 10 - EXEMPLO DE REDE AD-HOC. ....................................................................................... 17
FIGURA 11 - REDE DE INFRAESTRUTURA. ....................................................................................... 18
FIGURA 12 - POSSÍVEIS CONFIGURAÇÕES DE ANTENAS. (ALBACORE, 2010) ........................... 26
FIGURA 13 - PLACAS USB (ESQUERDA) E SERIAL (DIREITA). ....................................................... 26
FIGURA 14 - ARQUITETURA DO SISTEMA PROPOSTO – GATEWAY.·........................................... 28
FIGURA 15 - AMBIENTE DE TRABALHO. ............................................................................................ 30
FIGURA 16 - TELA INICIAL E TERMINAL X-CTU. ............................................................................... 32
FIGURA 17 - TELAS DE PARAMETRIZAÇÃO DOS MÓDULOS X-CTU. ............................................ 33
FIGURA 18 - PARAMETRIZAÇÃO DO MÓDULO "JANELA"................................................................ 39
FIGURA 19 - PARAMETRIZAÇÃO DO MÓDULO "BANHEIRO". ......................................................... 40
FIGURA 20 - PARAMETRIZAÇÃO DO MÓDULO "PORTA". ................................................................ 40
FIGURA 21 - FLUXOGRAMA PARA COMUNICAÇÃO XBEE. ............................................................. 45
FIGURA 22 - FLUXOGRAMA PARA COMUNICAÇÃO WI-FI. .............................................................. 46
FIGURA 23 - HARDWARE MONTADO PARA TESTES. ...................................................................... 53
FIGURA 24 - ESQUEMA ELÉTRICO DO CIRCUITO REGULADOR DE TENSÃO. (MESSIAS, 2009) .............................................................................................................................. 54
FIGURA 25 - GUI PARA A APLICAÇÃO DESENVOLVIDA. ................................................................. 56
FIGURA 26 - MÓDULO DE TESTES API-AT ........................................................................................ 57
LISTA DE TABELAS
TABELA 1 - API IDENTIFIERS. (DIGI, 2010) ........................................................................................ 16
TABELA 2 - CARACTERÍSTICAS TÉCNICAS DOS MÓDULOS DIGI. (ALBACORE, 2010) ............... 25
TABELA 3 - RELAÇÃO DE PINO DOS MÓDULOS XBEE ZB E XBEE PRO ZB. (ALBACORE, 2010) .............................................................................................................................. 25
TABELA 4 - VARIÁVEIS MONITORADAS DO AMBIENTE DE TRABALHO. ....................................... 31
TABELA 5 - ESTRUTURA DE FRAME DE REMOTO AT COMMAND REQUEST. ............................. 35
TABELA 6 - FRAME ZIGBEE IO DATA SAMPLE RX INDICATOR. ..................................................... 37
TABELA 7 - FRAME DE DADOS WI-FI. ................................................................................................ 43
TABELA 8 - TESTES API-AT. ................................................................................................................ 58
TABELA 9 - TESTES API-API. ............................................................................................................... 59
TABELA 10 - FRAME WI-FI - TESTES. ................................................................................................. 63
TABELA 11 - FRAME XBEE - TESTES. ................................................................................................ 63
TABELA 12 - FRAME XBEE - TESTES 2. ............................................................................................. 63
TABELA 13 - FRAME WI-FI - TESTES 2. .............................................................................................. 64
RESUMO
Este Trabalho apresenta um sistema baseado em programação Visual C# para que
se estabeleçam e monitore duas redes sem fio voltado para realizar a automação de
uma residência. A primeira é baseada em protocolo TCP-IP com transmissão via Wi-
fi. Esta se conecta a um dispositivo móvel através de uma rede ponto-a-ponto Ad-
Hoc e a transmissão é realizada através de um frame de dados. A outra rede baseia-
se em protocolo Zigbee e foi implementada com os dispositivos Xbee da Digi
International e uma placa de interface USB para conexão ao computador que roda a
aplicação. A transmissão também ocorre por meio de quadros, frames, de dados. O
programa desenvolvido deve estabelecer as duas conexões, receber e tratar os
dados que chegam do dispositivo remoto via Wi-fi, e enviar instruções para executar
as devidas ações de forma que os módulos Xbee entendam e receber os dados de
campo dos módulos Xbee, manipula-los e enviá-los para o dispositivo móvel. O
propósito deste trabalho é a aplicação do programa desenvolvido em automação
residencial, no qual o dispositivo móvel conteria uma IHM e os módulos Xbee seriam
os nós de uma rede de sensores e atuadores no ambiente monitorado. Como
resultado, foi possível que a comunicação fosse estabelecida através das duas
tecnologias supracitadas, e uma User Interface mostrasse todo o fluxo de frames de
dados que chegam e que são enviados nas duas redes estabelecidas.
ABSTRACT
This project presents a system based on visual c# programming in order to establish
and monitoring two wireless networks in order to establish the automation of a house.
The first one is based on tcp-ip protocol and is transmitted via Wi-fi. It connects the
notebook in which the application runs to a remote device through an ad-hoc network
and all transmitted data happens through a data frame. The other one is based on
Zigbee protocol and was set with digi international’s Xbee radios and an interface
usb board to communicate with the notebook. The data transmission also is data-
frame based. The developed application have to establish both connections, receive
and manipulate the data frames that arrives from the remote device through Wi-fi and
send instructions to perform the proper actions in an understandable manner for the
Xbee modules. Besides that, it has to receive the field data from the Xbee modules,
manipulate them and send them back to the remote device. The propose of this
graduation project is the application of the developed software in a home automation
system, in which the remote device would carry the hmi and the Xbee modules would
be the nodes of a sensors and actuators network on the monitored environment. As a
result, it was possible to successfully establish Zigbee and Wi-fi connections and
develop a user interface that shows all data frame traffic that were sent and received
by the application.
1
1 INTRODUÇÃO E OBJETIVOS
Ao longo da história aparatos foram desenvolvidos para simplificar as tarefas diárias
do homem. Desde as ferramentas mais simples utilizadas pelos ancestrais dos
homens há milhões de anos, passando pela manipulação do fogo, o uso da roda, as
ferramentas construídas a partir de metais, a máquina a vapor, a eletricidade, a
eletrônica analógica, e chegando à eletrônica digital dos dias atuais, a tecnologia
andou lado a lado com a humanidade sempre em busca da melhora do seu
cotidiano.
Com o Boom dos parques tecnológicos nos anos 70 a 90 (Rangel, 2010) e a
evolução da microeletrônica impulsionada pelo vale do silício, os circuitos integrados
foram popularizados proporcionando o desenvolvimento de uma série de novos
aparelhos que cada vez ficavam mais versáteis, confiáveis e menores. Aparelhos
como rádios, televisores, telefones celulares, tocadores de musica digital se
tornaram mais presentes na vida do ser humano.
Atualmente é muito incomum encontrar um ambiente, seja ele doméstico,
corporativo ou industrial, que não possua nenhum tipo de rede de comunicação e
dispositivos que acessam esta rede pelo ar, over-the-air.
Cada tecnologia é indicada para um tipo específico de aplicação, e sempre a relação
entre alcance e velocidade é o gargalo para a escolha adequada para alcançar os
resultados esperados.
O Wi-Fi é indicado para trafego de dados para distâncias que vão desde as curtas às
médias e com um volume alto de informações por tempo. Por esse motivo, esta
tecnologia é utilizada em residências para compartilhamento de internet, a partir da
qual é possível transferir som e vídeo sem a limitação da velocidade. Por outro lado,
o seu alcance limita a aplicação em redes com maiores distâncias.
Já o Bluetooth, é indicado para distâncias curtas e volumes de dados que vão de
médios para baixos. Por isso é amplamente utilizado para troca de dados entre
celulares e computadores.
Esse contexto possibilitou o surgimento uma nova tecnologia a qual tinha como
missão se posicionar em um gap deixado pelas duas supracitadas: o Zigbee.
A origem do termo Zigbee vem da mistura de alguns pilares que o padrão adotou na
sua concepção: uma zona padrão global de intercomunicação (Zonal
2
Intercommunicaton Global-standard) com longa vida de Bateria (Battery), que fosse
de barata implementação (Economical) e que utilizasse os recursos de forma
eficiente (Efficient). Em outras palavras, surgiu pra ser um novo padrão de
comunicação com baixos custos e consumo de potência.
Enquanto os outros protocolos buscavam mais velocidade nas transmissões de
dados, o Zigbee surge na contramão deste processo. Foi projetado para ter uma
baixa transferência de dados e uma pilha bem compacta a qual possa ser
processada em microcontroladores de 8-bits. Os resultados disso foram o baixo
consumo de energia, a simplicidade que trouxe mais robustez e longa vida às
aplicações, num padrão aberto, com bom custo-benefício e transmissão de dados
altamente segura.
Com a interação dos sistemas de entretenimento nos chamados Media Center, a
internet e a comunicação sem fio em alta, novos conceitos foram surgindo nos
últimos anos a fim de integrar comandos das residências como iluminação,
temperatura, segurança e entretenimento para que o usuário tivesse a partir de uma
central o controle de diversos dispositivos sem a necessidade de acioná-los um por
vez.
Tal ramo da tecnologia é conhecido como Domótica, ou automação residencial, que
é descrita como a introdução da tecnologia nas casas para melhorar a qualidade de
vida de seus ocupantes, através da provisão de diferentes serviços como
monitoramento médico, entretenimento multimídia e economia de energia. (Bromley,
2003)
Igualmente, aliando a economia que a Domótica já pode trazer ao consumo de
energia com uma tecnologia que emergiu num passado muito recente, o Zigbee, é
possível o desenvolvimento um sistema que composto por uma rede de sensores
sem fio de baixo consumo que serve de ferramenta para o monitoramento e controle
de uma residência de maneira mais eficiente e confortável.
Existem diversos trabalhos na área de Domótica inclusive com aplicações do
protocolo Zigbee.
Um dos sistemas estudos propõe a implementação de uma rede Zigbee para
monitorar e controlar um ambiente através de um controle remoto Zigbee, qualquer
dispositivo que suporte a linguagem Java através da comunicação via Wi-fi ou até
mesmo através da internet. É um sistema flexível no que diz respeito à
3
interoperabilidade entre diversos fabricantes de dispositivos, proporcionada através
do uso de um hardware dedicado para fazer o papel de gateway na rede proposta.
Para o estabelecimento da topologia proposta quatro dispositivos Zigbee são
utilizados: o controle remoto supracitado, um acionamento de luz, um sensor
segurança – com sensores de temperatura, fumaça, monóxido de carbono e chamas
- e uma válvula para acionamento de um aquecedor. (Gill, 2009)
Outro estudo mostra um sistema desenvolvido a partir de um simulador de uma
residência baseado em linguagem Java para aquisição de dados do ambiente
utilizando-se uma rede Zigbee, a qual comunica-se por RS-232 com o computador
no qual o simulador é executado. (Bolzani, 2006)
Uma topologia um pouco diferente das anteriores é agora proposta para que ao
invés de acessar o sistema de automação por uma rede Wi-fi ou mesmo por
comunicação serial, a interface entre a IHM e o sistema é feita através da tecnologia
GPRS, para que a comunicação ocorra através da rede usada para celulares. (Jin,
2007)
Especificamente falando em comunicação via Zigbee existem algumas bibliotecas
API propostas. Estes códigos foram desenvolvidos com o objetivo de formar uma
coleção de funções para que fosse estabelecida uma conexão entre um computador
e módulos Zigbee da Digi International. Desta maneira, apesar de ser possível a
comunicação através das rotinas programadas, a interface do sistema não é
amigável por não ser gráfica e uma biblioteca visa dar ferramentas para o
desenvolvimento de uma aplicação especifica.
Duas delas utilizaram-se da linguagem C para programação do código
implementado. (Making Things, 2009) (Libxbee, 2011).
Outra biblioteca desenvolvida teve o Java como linguagem de programação escolha.
Este último é mais atrativo no sentido de utilizar uma linguagem orientada a objetos
a qual é muito vantajosa pelos conceitos envolvidos nessa linguagem:
encapsulamento, herança e o uso de objetos. (Raap, 2011)
Outro sistema mais simples, porém com topologia igualmente baseada em Zigbee,
foi proposto para monitoramento de nós remotos em uma rede sem fio. Nela há um
módulo fixo fazendo a interface com um PC através de uma placa de interface USB,
o qual faz o papel de coordenador da rede e dois nós remotos os quais possuem
sensores de aceleração, giro e temperatura. Os dados são obtidos por amostragem
4
com um taxa pré-definida e são interpretados por um programa desenvolvido em
plataforma do LabView, da National Instruments, a qual faz a manipulação,
interpretação e apresentação dos dados numa interface gráfica para o usuário. (Roa,
2010)
Em linhas gerais, o sistema de automação residencial aqui idealizado tem como
principais premissas a utilização de tecnologias novas e que possuem um alto
potencial de aplicação na área de domótica. A utilização de redes sem fio faz com
que a instalação desse sistema seja menos agressiva no que diz respeito a
alterações no ambiente onde o sistema será utilizado, minimizando a utilização de
fios, e por consequência reduzindo os custos da implementação.
O sistema tem como conceito a modularidade para que este seja facilmente
expandido a outros cômodos sem que exista a necessidade de modificações
bruscas tanto em hardware quando em software. Basicamente serão monitoradas e
controladas variáveis relacionadas à temperatura, luminosidade e segurança por
meio de módulos remotos os quais conterão os sensores e atuadores que fazem a
leitura e acionamento de dispositivos através de comandos enviados por um
dispositivo móvel, como, por exemplo, smartphones ou um tablets.
A atuação remota tem como objetivo prover mais conforto e facilidade para atuar no
ambiente através de uma interface homem-máquina extremante simples de se
utilizar a qual conterá botões, checkboxes e barras de rolagem, que são comumente
encontrados em praticamente todos os sistemas operacionais existentes no mercado
e, portanto, são familiares para praticamente todos que pretendem ter um sistema de
automação instalado em suas residências.
A figura 1 mostra a topologia proposta para este sistema, o qual pode ser separado
em três grandes blocos: a IHM, o gateway e os módulos remotos.
A IHM será formada pelo conjunto de um software e um dispositivo remoto com
conexão Wi-fi, a partir do qual será possível monitorar todas as variáveis do sistema
e atuar no ambiente para que o usuário deixe o cômodo da maneira que deseja.
O gateway, aqui representado por um notebook com Wi-fi e uma placa de interface
com a rede Zigbee, conterá uma aplicação que fará a gestão das duas redes sem fio
do sistema, recebendo os dados, os manipulando e reenviando para a outra rede.
Isto ocorrerá tanto ao receber um comando via Wi-fi da IHM para que se atue no
5
ambiente quanto ao receber os dados colhidos da rede de sensores e atuadores
Zigbee.
O terceiro bloco é o dos módulos remotos. O hardware desenvolvido para tal irá
conter todos os circuitos de alimentação e os sensores e atuadores necessários.
Dentre eles podemos citar sensores de temperatura, luminosidade, presença,
indutivos para verificação de status de abertura/fechamento de portas e janelas,
além de relés para acionamento de dispositivos eletrônicos, drives para controle de
motores de posicionamento de persiana e dimmers para controle de intensidade
luminosa.
FIGURA 1 - ARQUITETURA GERAL DO SISTEMA.
Diante de todos os benefícios que a automação residencial pode trazer a vida dos
seres humanos e o desenvolvimento de sistemas de automação que buscam suprir
uma necessidade que deve crescer no mercado, o qual preza por um baixo custo
(Teruel, 2007), propõe-se neste trabalho o projeto, implementação e integração de
duas redes sem fio de comunicação. A primeira utilizará o protocolo Zigbee para
interligar nós que estarão ligados a sensores e atuadores os quais irão compor uma
rede de aquisição de dados sem fio. A segunda será baseada em Wi-fi para que um
usuário possa acessar todos os dados colhidos e estados das variáveis através de
um dispositivo portátil.
Diferentemente dos trabalhos supracitados, o aqui proposto assume como
premissas o desenvolvimento de uma interface, mas não para a visualização final
6
dos dados e sim para o monitoramento do tráfego de informação. Soma-se às
diferenças a comunicação via Wi-fi e interpretação dos dados provenientes de uma
das redes e envio para a outra, de modo que tanto a interface com o usuário quanto
os módulos remotos se comuniquem com sucesso.
Este projeto visa, através da integração com dois outros trabalhos (Pilon, 2011) e
(Rosa, 2011), formar uma central de automação residencial de baixo custo o qual
alinharia tecnologias atuais para conceber um sistema robusto, seguro e que
proporcione conforto aos usuários.
2 APRESENTAÇÃO DAS TECNOLOGIAS ENVOLVIDAS
Este capítulo visa explicitar os principais conceitos necessários para o
desenvolvimento deste trabalho através da apresentação das tecnologias utilizadas,
as arquiteturas e vantagens proporcionadas por elas.
2.1 ZIGBEE
2.1.1 Características técnicas
Vários artifícios presentes na pilha do Zigbee endossam o aspecto de um dos pilares
deste protocolo: a confiabilidade. A presença do sistema CSMA-CA, do inglês
Carrier Sense Multiple Access Collision Avoidance, garante que não ocorra colisão
de dados e a mensagem chegue corretamente ao seu destino. O sistema verifica o
canal de transmissão e a transmissão do dado só ocorre quando este estiver
disponível.
O protocolo possui verificação redundante cíclica, CRC - cycle redundancy check, de
16 bits, mais conhecido como Frame Check Sum, o qual calcula o CS para cada
bloco de dados enviado e ao receber o pacote checa a soma para garantir que não
houveram distorções nos dados transmitidos. Também conta com DSSS – Direct
Sequence Spread Spectrum e O-QPSK – Offset-Quadrature Phase-Shift Keying para
obter sucesso em ambientes onde a relação entre ruído e sinal é alta.
Também é intrínseco do protocolo o reenvio por três vezes dos dados e
confirmações de recebimento – Acknowledgement – que são enviadas para o nó de
origem em caso de sucesso ou falha no envio. Além disso, os pacotes recebidos
duplicadamente já são automaticamente descartados.
A principal vantagem a se salientar neste ponto é a possibilidade de se estabelecer
uma rede malha, mesh, a partir da qual o alcance da rede é estendido com uma
topologia que permite que o dado seja transmitido ponto a ponto até o destino com
detecção automática de rota mais propensa a ter sucesso e a “auto cura”, o seja,
caso um dos nós da rede caia, automaticamente outra rota é encontrada para
garantir a comunicação. Este processo é totalmente transparente e é possível
8
rastrear os caminhos de transmissão. A figura 2 ilustra uma rede em configuração
mesh.
FIGURA 2 - CONFIGURAÇÃO MESH DE UMA REDE ZIGBEE. (MESSIAS, 2009)
Alguns pontos foram levados em consideração na concepção deste protocolo os
quais ajudaram a que a tecnologia fosse bem acessível e tivesse uma boa relação
de custo-benefício. O fato de utilizar-se a frequência de 2.4GHz, amplamente
utilizada em comunicação sem fio, fez com que o custo dos módulos fossem
reduzidos e, ainda, considerando o fato do protocolo ser livre de patente, projetos
com Zigbee apresentam um baixo custo de desenvolvimento.
Determinados fabricantes oferecem módulos prontos para operar, como por
exemplo, a DIGI International. Assim o tempo para um produto ser desenvolvido fica
muito mais amarrado a software, o que faz com que os produtos possam chegar
mais rápido ao mercado. A figura 3 mostra um módulo Xbee ZB da Digi.
FIGURA 3 - MÓDULO XBEE DIGI. (ALBACORE, 2010)
9
Ainda, com o desenvolvimento dos Perfis de Aplicação, Applications Profiles (AP), os
quais reúnem uma série de parâmetros voltados a aplicações voltadas a
determinados tipos de mercados, a interoperabilidade entre os fabricantes fica
assegurada com a padronização dos comandos para dispositivos que se enquadram
neste conceito. Entre os principais APs públicas podemos citar o Home Automation,
Smart Energy, Health Care, Telecommunication Service, por exemplo.
Conforme fora citado anteriormente, o Zigbee vai à contramão das tecnologias que
estão surgindo, na medida em que ele tem a baixa taxa de transmissão de 250kbps,
a qual ainda pode ser reduzida devido aos reenvios, retries, intrínsecos da pilha, a
configuração de rede mesh e a criptografia. Deste modo, o through-put chega a ser
de aproximadamente 25 Kbps.
Os transmissores são half-duplex, ou seja, não enviam e recebem simultaneamente
para diminuir o consumo e a rede opera com um ciclo de trabalho baixo (low duty-
cycle).
O protocolo opera em 16 canais separados fisicamente por 5mhz, para que seja
possível a transmissão em um ambiente o qual possua outros dispositivos na
mesma faixa de frequências. Ainda para economia de energia, end-devices tem a
capacidade de entrar em estado de espera, stand-by, até que seja necessário
acordar para enviar um pacote. Este sleep mode ocorre tanto em ciclos
programados ou por uma interrupção através de um pino físico.
A segurança também é uma das fortes características do protocolo. É utilizado o
AES-128 – Advanced Encryption Standards, o qual é amplamente reconhecido pelo
alto nível de segurança, além de ser livre de patentes e poder ser implementado em
sistemas com 8-bit. Tal segurança garante que módulos que não possuam a chave
de encriptação previamente definida e parametrizada nos módulos não consigam
nem ao menos detectar a rede criptografada, muito menos decifrar o conteúdo dos
pacotes de dados transmitidos. A figura 4 ilustra uma rede Zigbee com segurança
implementada.
10
FIGURA 4 - REPRESENTAÇÃO DE NÓS SEM A CHAVE DE SEGURANÇA EM UMA REDE. (ALBACORE, 2010)
2.1.2 Arquitetura Zigbee
O esquema que ilustra a arquitetura Zigbee é mostrado na figura 5 abaixo.
FIGURA 5 - CAMADAS DA ARQUITETURA DE REDE ZIGBEE.
As camadas presentes apresentam algumas semelhanças com as sete camadas
OSI, porém quatro camadas, Transport, Session, Pressentation e Application, são
representadas nesta topologia por apenas dois, a Application Framework e a Zigbee
Device Object. As três inicias Physical, Medium Access Layer e Network são as
mesmas presentes nas camadas OSI.
11
As camadas PHY e MAC são definidas pela especificação IEEE 802.15.4,
especificação originária da necessidade de interligação de dispositivos ao redor das
pessoas por meio de WLAN e WPAN, além de desenvolver um padrão de
comunicação sem fio de baixa potência, com curto alcance, baixo custo e tamanhos
reduzidos. As topologias estabelecidas pela 802.15.4 são a ponto-a-ponto e a ponto-
a-multiponto. A função da camada PHY é transmitir os dados, enquanto a camada
MAC é responsável por carregar os conceitos da rede, definir a PAN ID (nome da
rede) e coordenar as requisições e respostas das tentativas de juntar-se à rede.
As próximas duas camadas, APS e a NWK, já são específicas do protocolo
desenvolvido pela Zigbee Alliance, uma entidade que é responsável por gerenciar
esta tecnologia e garantir que o Zigbee possa ser viável no sentido de haver
interoperabilidade entre os produtos dos diversos fabricantes que fazem parte dela.
Estas definiram novas funcionalidades para o protocolo, fazendo com que além das
topologias fixadas pelas camadas inferiores, a rede pudesse operar no modo mesh.
Também foi determinado que cada dispositivo possuiria um endereço único
determinado pelo fabricante, o MAC address de 64-bit, e um IP dinâmico,
determinado pela rede, de 16-bit.
A camada NWK é responsável por operar a rede mesh, fazer a distribuição de
pacotes via broadcast, determinar a melhor rota para distribuições via unicast e
assegurar o transito dos pacotes pelos nós. Além disso, ela possui os comandos de
segurança da rede.
Já a camada APS faz a integração da aplicação, filtra as mensagens duplicadas e
mantém o registro contendo os nós ou grupos de nós que o nó de origem deseja
enviar uma mensagem. A camada ZDO, por fim, é responsável pelo gerenciamento
da rede e por descobrir os nós da rede e seus estados.
A camada que está no topo contém a aplicação programada e os Applications
Profile, os quais já foram previamente detalhados.
2.1.3 Dispositivos em uma Rede Zigbee
Uma rede Zigbee é formada basicamente por três tipos de dispositivos:
Coordenador, Roteador e End-Device.
12
O coordenador é o responsável por organizar a PAN, Personal Area Network. Ele
define o PAN ID, que é o nome único da rede e o canal de operação que se
concentrarão as transmissões.
Então, segue com uma varredura da área para encontrar os outros dispositivos
compatíveis, configurados com a mesma PAN ID. Geralmente este dispositivo está
sempre operante, e após a formação da rede ele passa a opera como um roteador
para a rede. Assim sendo, a operação com baterias não é aconselhada para estes
nós, e sim a ligação diretamente à rede elétrica. Só há um coordenador por rede.
O roteador assim como o coordenador está sempre operante. Basicamente a sua
função é ser um “repetidor” para que a rede consiga entregar os dados que são
passados nó a nó. Pode haver vários deste na rede.
Já o End-devices é o dispositivo mais simples. Eles podem somente se associar a
um nó, e, portanto, não roteiam dados. Todo o acesso à rede ocorre por meio de
seus parentes, que podem ser tanto um coordenador quanto um roteador os quais
armazenam as tabelas de roteamento necessárias para que as informações sejam
transmitidas de um ponto a outro com sucesso.
2.1.4 Roteamento de Dados e Modos de Comunicação
A comunicação do protocolo Zigbee é RF protocolada, ou seja, após o recebimento
de um pacote por um nó, este envia um ACK, aviso de recebimento, para o nó de
origem indicando que a transmissão foi realizada com sucesso. Além disso, é
intrínseco do protocolo o reenvio de três vezes do pacote, caso nenhum ACK seja
recebido.
No Zigbee existem três modos principais de transmissão.
No primeiro deles, o Broadcast, transmissão a qual não possui um endereço de
destino específico, o que faz com que os dados sejam recebidos por todos os
dispositivos da rede, inclusive end-devices em modo sleep, os quais receberão de
seus parentes assim que acordarem. A figura 6 ilustra tal caso.
13
FIGURA 6 - TRANSMISSÃO BROADCAST. (ALBACORE, 2010)
Um segundo modo é a transmissão unicast, na qual o dado é endereçado a um
dispositivo em particular. O Endereçamento é feito através da indicação do endereço
físico do dispositivo e do IP dinâmico do mesmo na rede. A figura 7 mostra um
exemplo de transmissão do tipo unicast.
FIGURA 7 - TRANSMISSÃO UNICAST. (ALBACORE, 2010)
O último modo é o groupcast, transmissão que ocorre para um grupo particular de
dispositivos, e os que não fazem parte do grupo não recebem a mensagem enviada
pelo nó.
2.1.5 Frame de Dados
O protocolo Zigbee possui dois tipos de comunicação: a comunicação tipo API e a
do tipo AT.
14
2.1.5.1 AT
A do tipo AT é o modo transparente de transmissão, ou seja, tudo que é colocado na
porta Din de um módulo, é transmitido pela sua antena, e recebido pelo Dout do
outro dispositivo. A figura 8 mostra exemplo típico para este modo.
FIGURA 8 – EXEMPLO DE MODO DE TRANSMISSÃO AT. (ALBACORE, 2010)
No caso da figura, uma leitora de códigos de barra faz a leitura, se comunica com o
módulo pelas Portas Din e Dout UART enviando o resultado da leitura, e essa
informação é enviada para a antena que transmite ao coordenado, o qual, através
do RS232, passa a informação de seu Dout para o terminal. Como o que se põe de
um lado é recebido do outro, podemos dizer que a comunicação AT é como se fosse
um cabo de comunicação.
A lista de comandos AT é exibida no Anexo 1.
2.1.5.2 API
A comunicação do tipo API é mais complexa e poderosa do que a do tipo AT. O
Application Programming Interface requer que a comunicação com o módulo seja
feita através de frames estruturados de uma forma específica. A figura 9 mostra um
frame genérico API.
15
FIGURA 9 - FRAME PARA COMUNICAÇÃO API. (ALBACORE, 2010)
O frame é formado por um byte de Start, dois de Length, o qual contém o
comprimento de todos os bytes com exceção do Start, ele próprio e o Checksum, o
frame data, que é dividido entre API identifier, Frame ID, AT command e parameter,
e por último o Checksum.
A tabela 1 mostra os tipos de comandos possíveis para os frames de transmissão.
O primeiro da lista, AT command, é utilizado quando se quer enviar ao módulo local
conectado no computador um comando do tipo AT, como, por exemplo, a alteração
ou leitura de algum parâmetro. Para que se faça o mesmo, envio de comandos AT
só que para nós remotos, utiliza-se o Remote Command Request, o qual envia
comandos para o nós especificado através dos endereços de 64bits e 16bits que
cada um possui na rede.
Outro comando muito utilizado é o Zigbee Transmit Request, a partir do qual
qualquer dado pode ser enviado de um nó a outro, como por exemplo, uma
mensagem de texto.
Os comandos podem ser acompanhados ou não por parâmetros.
16
TABELA 1 - API IDENTIFIERS. (DIGI, 2010)
O checksum é calculado somando todos os bytes, do bloco considerado Frame
Data, pegando os 8btis menos significativos e os subtraindo de 0xFF. Para conferir o
CS, somam-se todos os bytes do frame data e caso o resultado seja 0xFF o frame
está correto.
2.2 WI-FI
Esta tecnologia é baseada nas diretrizes estabelecidas pela IEEE 802.11. O Wi-fi, de
wireless fidelity, foi desenvolvido para prover acessos a redes independentemente
do local de instalação, para que toda infraestrutura de cabos necessária fosse
dispensada com a transmissão por ondas de rádio. Tal substituição tenha como
principal motivação a mobilidade dos usuários da rede.
As especificações da IEEE 802.11 surgiram como um padrão para redes sem fio no
ano de 1997, inicialmente com taxas de transmissão da ordem de 1 ou 2 Mbps e o
padrão era focado nas 2 primeiras camadas do modelo OSI, as camadas físicas e de
17
link. Tudo que rodaria numa rede Ethernet convencional seria compatível com o que
este padrão convencionou.
2.2.1 Estrutura da rede
Cada nó da rede Wi-fi ou WLAN – Wireless Local Area Network é chamado de
estação, e quando duas ou mais estações estão se comunicando uma BSS – basic
service set é formada, a qual é o bloco padrão de uma rede WLAN.
Esta BSS é classificada de acordo com a sua estrutura. Caso ela seja do tipo
Standalone, ou seja, não está conectada a uma rede cabeada, é chamada de IBSS,
Independent basic servisse set ou então de rede Ad-Hoc. A principal característica
deste arranjo é que as estações que formam a BSS só se comunicam ponto-a-ponto.
A figura 10 ilustra este tipo de configuração.
FIGURA 10 - EXEMPLO DE REDE AD-HOC.
Quando uma BSS está conectada a um sistema de distribuição (DS - Distribution
System), a partir do qual ocorre à interligação com outras BSSs, a rede recebe o
nome de rede de infraestrutura. As BSSs se conectam ao sistema de distribuição –
DS – através de dispositivos chamados de Access Points (AP), os quais são
endereçáveis e fazem a transmissão das informações entre a BSS e o DS. A figura
11 mostra um exemplo de rede de infraestrutura.
Redes maiores e complexas com muitas BSSs e DSs formam um ESS, ou Extended
servisse set, o qual faz com que a rede seja vista como um IBSS para a camada de
Logical Link Controler – LLC. Por consequência, as estações dentro da ESS podem
18
se comunicar ou se mover dentro das BSSs de modo transparente para esta
camada da rede.
FIGURA 11 - REDE DE INFRAESTRUTURA.
A interligação de rede cabeadas preexistentes com as redes sem fio estabelecidas
pela IEEE 802.11 é garantida pelo Portal, o qual desempenha o papel de uma ponte
entre os dois tipos de redes. O portal funciona como um Access point para a DS.
2.2.2 Distribution Systems
A implementação dos DS não é especificada no IEEE 802.11, mas estes padrões
especificam os serviços que a DS deve desempenhar.
2.2.2.1 Distribution System Services
Os serviços classificados como DSS são divididos em cinco: Associação,
reassociação, dissociação, distribuição e integração.
Os três primeiros são relacionados à mobilidade das estações, as quais recebem
três classificações de acordo com o tipo de movimento que faz. Caso a estação não
19
se mova ou não mude de BSS, a sua mobilidade é classificada como No-transition,
se a estação se move entre BSSs dentro da mesma ESS é uma BSS-transitivo e por
fim se a estação se desloca entre ESSs é uma ESS-transition. Ao se mover as
estações se desassociam e se associam aos APs, só podendo estar conectada a um
por vez, para que o DS sempre saiba a localidade de cada estação.
A associação só ocorre em mobilidade do tipo No-transition, quando for em uma
BSS-transition o serviço que é aplicável é a reassociação, o que faz com que a
estação mude de um AP para outro. Já a dissassociação ocorre quando a conexão
com o AP é encerrada. Sempre que uma estação precisar se mover entre ESSs, a
conexão será encerrada e deverá ocorrer novamente.
A distribuição é operacionalizar a transmissão de uma mensagem de uma estação,
associada a um AP, para outra estação, enquanto a integração é o serviço que
ocorre quando o AP é um portal, ou seja, ocorre a transmissão de um dado de uma
rede 802.11 para uma ethernet.
2.2.2.2 Station Services
Os Station services são relacionamentos com a segurança da rede. Considerando
que o meio físico não é limitado, por ser sem fio, uma série de medidas devem ser
tomadas para que uma estação possa se associar a um AP, e, portanto ao BSS.
Este processo é chamado de autenticação e pode ser feito de duas maneiras no
802.11: por Open System Authentication ou por Shared Key Authentication. No
primeiro qualquer solicitação de autenticação será atendida. Já no segundo só serão
atendidas as que tiverem um código, o shared secret que é implementado via WEP –
wired equivalente privacy. Quando uma estação quer terminar a conexão com um
AP, ocorre a desautenticação.
2.2.3 Camada Física
A IEEE definiu três tecnologias para a camada física, duas por técnica de espectro
estendido, FHSS e DSSS e uma por infravermelhos. As de espectro estendido além
de atender à 802.11 apresenta algumas vantagens como a confiabilidade, um
20
melhor through-put, e permite que diversos dispositivos compartilhem o espectro
sem que haja interferências.
A frequency hopping spread sprectrum (FHSS) opera em 2.4GHz dividida em 75
subcanais de 1MHz. Um padrão para os saltos de subcanais é adotado entre o
remetente e destinatário o que faz com que o espectro possa transmitir envios e
recebimentos de diversas estações simultaneamente, garantido que não ocorram
colisões.
Em direct sequence spread sprectrum (DSSS) a operação divide a banda de 2.4GHz
em 14 subcanais de 22 MHz. Um canal de operação é escolhido e toda transmissão
ocorre somente neste canal, sem saltos.
2.2.4 Camada de Data Link
Esta consiste em duas subcamadas a Logical Link Control (LLC) e a Media Access
Control (MAC). Apesar do 802.11 utilizar a mesma LLC das LAN para que a ponte
seja feita de modo mais simples com uma WLAN, a camada MAC é diferente.
A técnica utilizada para as transmissões é a Carrier Sense Multiple Access with
Collision Avoidance (CSMA/CA), a qual ao invés de só ouvir o meio de transmissão
para saber se pode enviar algum dado sem que haja colisões usa a estratégia de
pacotes de Acknowledgment (Ack), os quais confirmam à estação originária o
recebimento do dado enviado. A necessidade de transmissão de um pacote Ack faz
com que a rede WLAN seja mais lenta do que uma ethernet LAN.
Outra estratégia utilizada é a Request to send/Clear to sem (RTS/CTS). A estação
transmite um RTS para o AP e aguarda o recebimento de um CTS para iniciar a
transmissão de um dado e evitar qualquer chance de colisão.
Além disso, a camada MAC também utiliza-se de CRC checksum e fragmentação de
pacotes para otimizar as transmissões. O checksum é calculado e conferido para
que seja assegurada a integridade da informação recebida, enquanto a
fragmentação em menores pacotes melhora as chances de um dado não ser
corrompido na transmissão.
21
2.3 CLASSE SOCKETS
A linguagem de programação C# é muito atrativa no que diz respeito à vasta
biblioteca que possui. Uma de suas classes, a Sockets que pertence ao namespace
System.Net proporciona um conjunto de métodos e propriedades voltados para
comunicações síncronas ou assíncronas em redes com a utilização dos protocolos
TCP e UDP.
2.3.1 Conexões síncronas
Caso a aplicação não necessite tomar ações em paralelo com a escuta e
transmissão de dados pelo socket, geralmente utilizam-se as conexões síncronas.
Para o protocolo orientado a conexões TCP, após a definição de um IP end point,
com o IP e porta que devem ser escutados e a associação dele com o socket
através do método Bind, o servidor utiliza o método Listen para aguardar por
pedidos de conexões.
Quando um cliente, que está com o mesmo endereço de IP no IP end point que o
servidor usa, faz um pedido de conexão com o método Connect, o servidor utiliza-se
do método Accept para armazenar as informações do cliente num socket o qual será
utilizado para fazer todas as transmissões de dados com os métodos Send e
Receive. A partir deste ponto a conexão está estabelecida em ambas as partes.
Para o protocolo sem conexão UDP, não há necessidade de escutar e aguardar
conexão de clientes. Os métodos ReceiveFrom e SendTo são utilizados para enviar
ou receber sempre os frames de dados do cliente especificado.
2.3.2 Conexões Assíncronas
Para as aplicações que tenham a necessidade de rodar outros processos enquanto
a o envio e recebimento de informações da rede acontece, o mais indicado é o uso
de uma conexão assíncrona.
Para protocolo TCP, o socket é iniciado e a conexão é estabelecida pelo lado do
servidor através do método BeginAccept, que roda numa thread separada do resto
programa. Assim que um cliente tentar a conexão, as instruções especificadas num
“callback” da BeginAccept serão executadas e o servidor aceitará a conexão com o
22
cliente. O mesmo ocorre com os métodos para enviar e receber, BeginSend e
BeginReceive, os quais são iniciados e assim que houver a necessidade de enviar
ou receber um dado os seus respectivos “callback” são chamados para execução
das devidas ações.
Em suma, as conexões assíncronas diferem das síncronas por serem guiadas a
eventos. Desta maneira, a aplicação não é bloqueada enquanto o socket está sendo
escutado para realizar uma conexão ou receber um dado, fazendo com que o resto
do programa, que é executado em uma nova thread consiga rodar em paralelo,
normalmente.
2.4 CLASSE SERIALPORT
Outra classe que a rica biblioteca do C# dispõe é a SerialPort, a qual é utilizada para
estabelecer comunicação serial entre dispositivos. Ela utiliza suas propriedades e
métodos para setar os parâmetros necessários para transmissão e recebimento de
dados através da porta RS-232.
A vantagem é que toda a comunicação pode ser realizada de modo a ser guiada a
eventos, assim a aplicação pode continuar rodando enquanto a porta serial é varrida
a procura de dados recebidos.
Após a criação de um objeto do tipo serialPort, deve-se declarar um Event Handler,
no qual será indicada a subrotina que será acionada toda vez que chegar algum
dado ao buffer de entrada da porta serial. É então necessária a definição de
algumas propriedades do objeto serialPort para configuração da comunicação tais
quais PortName, BaundRate, Parity e StopBits, que são, respectivamente, o nome
da porta que será utilizada, a taxa de transmissão, o bit de paridade, e o bit de
parada.
Após a parametrização da conexão, o método Open é utilizado para que a porta
escolhida seja aberta e fique apta a receber. Sempre que algum dado chegar ao
buffer de entrada, a subrotina indicada no Event Handler será chamada e o
tratamento do dado e tomada de decisão pode ser realizado. Para enviar algum
dado é necessário simplesmente utilizar o método Send.
23
2.5 MULTITHREADING
O conceito de multithreading em computadores remete ao processamento paralelo
de rotinas em uma única CPU. É algo relativamente novo no âmbito de
desenvolvimento de software, mas que é amplamente utilizado nos sistemas atuais.
Thread é definido como um caminho sequencial para execução de um programa, e
em aplicações que utilizam de processamento em paralelo, as threads são
executadas simultaneamente para que nenhuma delas pare de responder durante a
execução de uma rotina que pode levar mais tempo para rodar por completo.
Para que as rotinas sejam executadas por um único processador o sistema faz uma
gestão do tempo de execução de cada thread definindo um tempo limite de
execução antes de mudar a rotina que está sendo processada. Quando esse tempo
é atingido o estado atual da tarefa é armazenado e o processador passa a executar
a outra atividade por um período de tempo. Desta maneira, com as atividades sendo
executadas em partes e sempre alterando o que está sendo processado, nenhuma
das atividades ficará travada e o usuário terá a impressão que tudo está sendo
executado ao mesmo tempo.
Os casos mais indicados de aplicação desta modalidade de processamento são os
que possuem uma interface gráfica e por trás dela executam tarefas que levam
bastante tempo para serem concluídas, como downloads, por exemplo. Num
programa uni thread enquanto a tarefa está sendo executada a interface gráfica fica
travada e não pode ser atualizada até que o processamento seja concluído e o
processador possa responder aos comandos provenientes da interação do usuário
com a interface. Com a utilização do multithreading, uma thread é responsável pela
interface enquanto outra é responsável pela tarefa que roda em segundo plano.
Desta maneira, o processamento é feito em partes e alternando entre as duas
threads para que nenhuma das aplicações seja bloqueada e o usuário consiga atuar
na interface gráfica sem problemas nem interrupções.
Outro exemplo típico é as aplicações do tipo servidor-cliente. Quando um cliente
envia uma solicitação ao servidor é muito mais conveniente que este dispare uma
thread para a execução desta tarefa para que continue escutando por outras
solicitações dos outros clientes da rede.
24
3 ESPECIFICAÇÃO
O objetivo deste trabalho é o desenvolvimento de um software para interfaceamento
e administração de duas redes sem fio de comunicação. A primeira será com a
utilização do Wi-Fi para que haja comunicação entre um dispositivo móvel e uma
central de controle, através da qual a interface homem-máquina será feita. Já a
segunda, será uma rede sem fio de sensores e atuadores utilizando a tecnologia
Zigbee, que transmitirá todos os dados colhidos no ambiente e para o ambiente.
Toda a programação foi desenvolvida na linguagem C# com o uso do Visual Studio.
A vasta biblioteca desta linguagem foi o motivo principal pela escolha. A classe
SerialPort foi utilizada para toda comunicação com os módulos Zigbee, através de
uma placa de interface USB, e a classe Socket foi utilizada para estabelecimento de
conexão com o dispositivo móvel por Wi-fi.
Por motivos de cunho financeiro optou-se por utilizar um notebook para rodar a
aplicação que fará a interface entre as duas redes e um notebook como dispositivo
móvel, o qual se conectará via Wi-fi com a aplicação. Este dispositivo móvel conterá
o software que foi desenvolvido no trabalho “Central para Automação Residencial:
desenvolvimento de um software de monitoramento e controle”. (Pilon, 2011)
Para a rede Zigbee optou-se pelos módulos produzidos pela Digi International, o
Xbee (Digi, 2010). Estes módulos são soluções que além de conter o radio Zigbee já
possuem alguns circuitos adicionais que fazem com que seja um dispositivo pronto
para operar, após a devida parametrização. Além desta versão, existe também o
Xbee PRO ZB, o qual tem uma potência de transmissão muito maior do que o
anterior. A tabela 2 mostra uma tabela comparativa entre eles.
Uma vantagem entre eles é que são compatíveis pino a pino, portanto caso a
aplicação demande um alcance maior após a PCB já ter sido confeccionada é
possível à troca do radio sem alterações físicas. A Tabela 3 mostra a pinagem dos
Xbee ZB. Os módulos possuem entradas e saídas digitais, 13 no total, quatro
entradas analógicas, para o conversor AD e entrada/saída UART. Os módulos da
DIGI possuem a opção entre quatro configurações de antenas, as quais podem ser
observadas na figura 12.
25
TABELA 2 - CARACTERÍSTICAS TÉCNICAS DOS MÓDULOS DIGI. (ALBACORE, 2010)
TABELA 3 - RELAÇÃO DE PINO DOS MÓDULOS XBEE ZB E XBEE PRO ZB. (ALBACORE, 2010)
26
FIGURA 12 - POSSÍVEIS CONFIGURAÇÕES DE ANTENAS. (ALBACORE, 2010)
Dependendo da aplicação, distancia entre rádios e o invólucro que o módulo estará
inserido, um tipo diferente é mais indicador. Por exemplo, a com o conector RPSMA
é indicada caso haja a necessidade de um alcance maior, e o módulo seja projetado
para ficar encostado na parede da caixa que está inserido, diferentemente do U.FI, o
qual por ter um prolongamento antes do conector não precisa estar próximo ao limite
da caixa para se ter a antena externa.
A interface entre o módulo e o computador é feita com placas USB ou Serial as
quais utilizam o RS232 para comunicar uma porta COM do PC com o módulo.
(Albacore, 2010)
FIGURA 13 - PLACAS USB (ESQUERDA) E SERIAL (DIREITA).
Elas já possuem alguns leds de indicação e botões os quais podem ser utilizados
para simular funcionalidades das saídas digitais, do conversor AD, ver o status da
comunicação serial e associação entre os módulos Zigbee.
Para o desenvolvimentento deste trabalho foram adquiridos: uma placa USB como a
da figura 13, dois módulos Xbee ZB S2 com antena wire e dois com conector
RPSMA para formar o lado Zigbee da rede. Todo hardware adicional, sejam
sensores, micro controladores, atuadores necessários para completar o projeto da
Central para Automação Residencial é escopo do trabalho “Central para automação
27
residencial: Hardware de aquisição de dados e comunicação com a central”. (Rosa,
2011)
A opção pelo Zigbee foi feita por algumas vantagens que este apresenta.
Primeiramente, por ser uma tecnologia nova e com amplo potencial de aplicação em
diversas áreas, entre elas a automação residencial. Uma vez que ela foi concebida
para que se tivesse um bom alcance, baixa taxa de transferência de dados, baixo
consumo de energia e baixo custo, esta tecnologia se torna muito atrativa para redes
de sensores.
Outrossim, o fato de se possuir end-devices que podem entrar em modo “sleep” e
opera com bateria fará com que alguns sensores desta rede como, por exemplo, o
sensor de abertura de portas ou janelas opere de modo satisfatório nesta aplicação.
Por fim, a possibilidade de uma rede mesh é indicada para o uso em aplicações de
automação residencial considerando que os dispositivos estarão espalhados pelos
cômodos e nem sempre o sinal enviado a partir de uma rede comum em topologia
estrela teria o alcance necessário para atingir todos os nós. Já na rede do tipo mesh,
os nós atuam como repetidores fazendo com que a informação possa dar saltos
entre eles e chegue ao destino final.
Já a rede Wi-Fi foi escolhida neste caso uma vez que praticamente todos os
dispositivos móveis disponíveis no mercado atualmente possuem acesso a esse tipo
de rede, sejam eles tablets, smartphones, PDAs, netbooks ou notebook. É também
uma tecnologia amplamente difundida e baseada em protocolos consolidados com
recursos avançados de segurança.
A figura 14 exibe em linhas gerais a arquitetura do sistema proposto para
desempenhar a função de gateway entre as rede Wi-fi e Zigbee.
28
FIGURA 14 - ARQUITETURA DO SISTEMA PROPOSTO – GATEWAY.·.
3.1 METODOLOGIA
Após o levantamento do estado da arte, os próximos passos foram a escolha da
linguagem de programação e a especificação do sistema em si, ou seja, quais
produtos seriam utilizados para fazer as transmissões tanto do lado da rede Zigbee
quando do lado da rede Wi-fi.
Com o sistema devidamente especificado, a etapa seguinte consistiu na fase de
desenvolvimento do código que para comunicação da central de automação via
Zigbee com os módulos remotos e também da comunicação da central com o
dispositivo móvel via Wi-fi.
Então, testes individuais foram conduzidos para verificar as transmissões, primeiro
via Zigbee e depois via Wi-fi.
A partir do momento que os dois lados da comunicação já tinham sido desenvolvidos
e testados, foi preciso criar todas as funções que fariam a análise e manipulação dos
dados que são recebidos dos módulos Zigbee, e enviá-los via Wi-fi para o dispositivo
remoto. Realizar o caminho contrário, dados provenientes do Wi-fi analisados e
manipulados para envio de informações aos módulos Zigbee, foi a etapa
subsequente.
Com os sistemas individuais testados, chegou-se ao momento a partir do qual a
interação com os trabalhos (Pilon, 2011) e (Rosa, 2011) iriam aumentar, uma vez
que ocorreria a integração dos três sistemas e testes de comunicação e das rotinas
29
de manipulação de dados, tanto para o Wi-fi quanto para o Zigbee. A partir da
análise dos resultados, otimizações foram propostas e implementadas para seguir
para a fase de testes finais e a conclusão do projeto.
4 ARQUITETURA DO SISTEMA
4.1 DESCRIÇÃO DO PROJETO
4.1.1 Aspectos gerais
Algumas premissas foram estabelecidas para que o sistema fosse concebido. A
figura 15 ilustra o ambiente controlado bem como suas variáveis.
FIGURA 15 - AMBIENTE DE TRABALHO.
As seguintes variáveis para o monitoramento e atuação no ambiente foram
escolhidas: luminosidade, temperatura e presença.
A luminosidade será controlada através de variação na potência entregue às
lâmpadas do ambiente interno. Há um sensor digital pra indicação de presença ou
não de luz no ambiente externo.
Já a temperatura é monitorada através de um sensor analógico tanto dentro quando
fora do ambiente de trabalho. Além disso, um atuador de temperatura, um ventilador,
31
foi utilizado para controle da temperatura, entretanto ele só possuirá dois estados:
ligado ou desligado.
Para o monitoramento de presença no cômodo um sensor infravermelho foi utilizado
o qual retorna zero caso não detecte presença e um se houver algum ser no quarto.
Este trabalho também inclui o monitoramento de abertura ou não de duas portas e
uma janela, os quais serão verificados com um sensor indutivo. Este é um sensor
digital que retorna zero quando está aberto e um caso esteja fechado.
Por fim, a persiana será automatizada com conjunto motor-encoder para que o
usuário varie a sua posição em quatro níveis, totalmente fechada, totalmente aberta,
e duas posições de abertura parcial.
TABELA 4 - VARIÁVEIS MONITORADAS DO AMBIENTE DE TRABALHO.
Variável Sensor ou atuador Tipo Range de operação
Temperatura Sensor Analógico e linear 0ºC a 100ºC
Temperatura Atuador Acionamento digital Ligado (1) / desligado (0)
Luminosidade Atuador Acionamento digital 8 intensidades (0 a 7)
Luminosidade Sensor Digital Luz (1) / Sem luz (0)
Persiana Atuador Acionamento digital 4 posições (0 a 3)
Aberto/fechado Sensor Digital (indutivo) Aberto(0) / fechado (1)
Presença Sensor Digital (infravermelho) Presença (1)/Ausência (0)
4.1.2 Comunicação Zigbee
O primeiro passo para viabilizar a comunicação Zigbee foi o profundo estudo do
módulo Xbee ZB da Digi adquirido para entender as suas características, funções e
modo de operação.
4.1.2.1 X-CTU
A configuração dos módulos é muito simples e pode ser feita através de um software
disponibilizado pela Digi chamado X-CTU. Esta aplicação é simples e permite que
seja feito upload de versões de firmware para os módulos, parametrizá-los além de
possuir um terminal para envio de comandos AT ou API.
32
FIGURA 16 - TELA INICIAL E TERMINAL X-CTU.
A figura 16 mostra a tela inicial do programa, na qual as configurações da porta
serial são definidas para que se inicie o reconhecimento e a configuração do módulo
pelo programa. A placa de interface Xbee USB é utilizada para a conexão do módulo
com o notebook.
A figura 17 mostra as telas de parametrização do software. Nesta etapa é possível
selecionar o tipo de firmware que será carregado no módulo. É através desta
escolha que a função do Xbee será determinada, tanto no que tange a tipo de
comunicação – AT ou API – quanto no tipo de dispositivo que o módulo será na rede
– Coordenador, roteador ou end-device. A figura mostra os parâmetros de um
módulo que é um coordenador API.
33
FIGURA 17 - TELAS DE PARAMETRIZAÇÃO DOS MÓDULOS X-CTU.
Para iniciar uma comunicação Zigbee, basicamente um parâmetro deve ser definido:
o PAN ID. Quando um coordenador inicia a rede, outros módulos que tenham o
mesmo PAN ID farão uma solicitação para se conectar e o coordenador os incluirá
na rede e lhes atribuirá um endereço, o MY, que é dinâmico e funciona como se
fosse o IP do módulo na rede.
A partir daí, a rede está formada e pronta para enviar e receber comandos.
4.1.2.2 Frames de dados Zigbee
Conforme explicado anteriormente existem dois modos de comunicação. O AT,
também conhecido como transparente, e o API. Este trabalho utilizou o protocolo
API já que o mesmo trabalha com transmissão de frames de dados estruturados o
que proporciona ao usuário mais possibilidades na comunicação e mais segurança
na transmissão dos dados, já que a transmissão é protocolada e os frames são
verificados com o uso de um checksum.
Ademais, por tratar-se de uma rede de sensores e atuadores sem fio, a função de
periodic sample dos módulos seria de grande utilidade por ser simples de se
configurar. Só é preciso parametrizar o tempo em milissegundos entre as amostras
34
desejado através do comando AT “IR” para que os módulos enviem um frame com
os estados de suas I/Os para o endereço configurado em sua parametrização.
Este projeto tem a necessidade de colher dados periódicos dos módulos, além de
enviar comandos AT para alterar o estado de saídas digitais dos módulos remotos.
Para tal são necessários dois tipo de frames de dados Zigbee.
Os frames de Remote AT Command Request são os utilizados para enviar
comandos AT para os módulos remotos que estão conectados à rede. A função API
0x17 é a que identifica este tipo de frame.
Conforme explicado anteriormente, a estrutura básica de um frame possui um
header formado por um byte de start – 0x7E sempre – e dois bytes de Length
(comprimento) do frame data. O frame data é formado por um byte que identifica a
função API – 0x17 para este caso – seguido por um que identifica o pacote, Frame
ID, através do qual se identificará o frame de retorno (ACK).
Os próximos oito bytes são do endereço físico de 64 bits do módulo de destino,
pelos dois bits do endereço dinâmico de 16 bits. O próximo é o byte de Remote
Command options – através do qual é possível desabilitar o ACK (0x01), aplicar as
mudanças de parâmetros imediatamente (0x02) ou então aguardar um comando AP
(apply changes) para que as modificações sejam aplicadas (0x00).
O comando AT propriamente dito vem logo em seguida em dois bytes. Estes podem
ou não possuir parâmetros, caso possuam o próximo byte contém o valor desejado
para o parâmetro do comando AT enviado.
Por fim, há o byte de checksum para verificação da integridade do pacote. A tabela 5
mostra os bytes, funções e posições no frame de dados.
A cada instrução enviada de um módulo a outro, um frame de resposta será gerado.
Este contém exatamente a mesma estrutura que o frame previamente descrito. As
diferenças evidenciam-se em três pontos: O frame type, o remote command options
e o parâmetro.
A cada frame type enviado (0x17), um frame de resposta será enviado de volta com
o tipo Remote Command Response (0x97), a não ser que o ACK tenha sido
desabilitado. O frame irá conter em sua estrutura o header, o frame type 0x97, o
frame ID, endereços de 64 e 16 bits, não apresentará o remote command options.
Ao contrário do anterior, após os endereços serão exibidos os bytes de AT
command, seguidos pelo de command status – que retorna 0x00 para transmissão
35
com sucesso, 0x01 para erro, 0x02 para comando inválido, 0x03 para parâmetro
inválido e 0x04 para transmissão com falha. Caso o comando AT enviado necessite
de um parâmetro como resposta, os bytes que apresentam esse parâmetro vêm logo
em seguida. E, por fim, o byte do checksum.
TABELA 5 - ESTRUTURA DE FRAME DE REMOTO AT COMMAND REQUEST. Posição Nome
Header
0 Start
1 Length
2
Frame Data
3 Frame Type
4 Frame ID
5
Endereço Físico-64bits
6
7
8
9
10
11
12
13 Endereço dinâmico-16bits
14
15 Remote Command Options
16 AT Command
17
18 Command Parameter
Checksum 19 Checksum
Por outro lado, os dados que serão recebidos periodicamente pelo módulo
coordenador serão do tipo Zigbee IO Data Sample Rx indicator (0x92). A estrutura
deste tipo de frame é composta pelo Header, com Byte de Start e Bytes de Length,
do Frame Data e por fim o checksum.
Neste caso, o frame data é estruturado de uma maneira diferente em relação ao
frame previamente exposto. O seu primeiro byte é o Frame type (0x92), seguidos
36
dos dois endereços do módulo de origem do frame, o de 64 bit e 16 bits,
respectivamente. O próximo byte representa o Receive options – retorna 0x01 para
pacotes com ACK e 0x02 para pacotes enviados via broadcast – seguidos por um
byte que indica o número de amostragens que foram enviadas, o qual é por default
sempre 0x01.
Os próximos quatro blocos do pacote são formados por dois bytes de Digital
Channel Mask, um byte para Analog Channel Mask, dois bytes para Digital Samples
(caso existam I/Os digitais ativas), e por último dois bytes para cada entrada
analógica ativa.
Os bytes referentes ao Digital Channel Mask representam quais saídas ou entradas
digitais estão ativas no módulo em referência. Os bits de 0 a 12 representam as
portas de D0 a D12, respectivamente. A única exceção são os bytes 8 e 9 que não
são aplicáveis uma vez que as portas D8 e D9 não são parametrizáveis nas versões
atuais dos firmwares. Os bits com valor 1 indicam I/Os que estão ativas e retornarão
o valor na porta, e os que possuem um 0 representam as inativas, que, portanto, não
retornarão valores.
Seguindo o mesmo princípio, o byte de Analog Channel Mask indicará através dos
bits de 0 a 4 quais as entradas analógicas estão ativas. Os bits de 4 a 6 não são
utilizados. Já o bit 7 indica a tensão de alimentação do módulo Xbee.
Caso existam I/Os digitais ativas, os próximos 2 bytes – Digital Samples – indicarão
os estados das portas digitais dos módulos seguindo os mesmos critérios e posições
estabelecidas na Digital Channel Mask.
Da mesma maneira, caso existam entradas analógicas ativas, haverá no pacote 2
bytes para representar cada valor analógico nas portas do módulo. As entradas
digitais usam 10 bits para representar os valores analógicos lidos, portanto o range
em hexadecimal vai de 0x00 a 0x3FF. Para que se converta o valor recebido para o
seu equivalente em mV é necessária a multiplicação do valor por 1200 e a divisão
por 1024.
A tabela 6 ilustra a estrutura de um frame de dados proveniente de uma amostragem
das I/Os de um módulo Xbee. Para fins de demonstração considerou-se que existem
37
I/Os digitais ativas e uma entrada analógica. Caso houvesse mais de uma entrada
analógica, haveriam mais 2 bytes para representar o estado de cada uma.
TABELA 6 - FRAME ZIGBEE IO DATA SAMPLE RX INDICATOR. Posição Nome
Header
0 Start
1 Length
2
Frame Data
3 Frame Type
4
Endereço Físico-64bits
5
6
7
8
9
10
11
12 Endereço dinâmico-16bits
13
14 Receive Options
15 Número de amostragens
16 Digital Channel Mask
17
18 Analog Channel Mask
19 Digital Samples (se
houver) 20
21 Analog Samples (se
houver) 22
Checksum 23 Checksum
4.1.2.3 Parametrização
A parametrização dos módulos utilizados neste trabalho foram todas realizadas com
o auxílio do X-CTU e da placa de interface dos módulos com o computador. Após a
38
conexão do módulo à placa, liga-se a placa ao computador por uma porta USB. No
X-CTU é possível visualizar todas as portas COM que estão ativas no computador.
Uma estará indicada como USB serial port e com o número da porta COM a qual o
módulo está conectado. Está deve ser selecionada.
Então, com a função Test/Query é possível checar se está realmente é a porta a
qual o módulo está conectado. Na aba de Modem Configuration, pressionando a
opção Read, a aplicação verificará que módulo está conectado, qual versão de
firmware está instalada nele, além de todos os parâmetros deste módulo. Os que
não estão escritos na cor preta são somente leitura, e os demais são editáveis.
Ao clicar nos parâmetros editáveis é possível alterar o valor default que vem pré-
programado no firmware dos módulos para adaptá-lo à aplicação necessária. No
caso do exemplo da figura 15, os parâmetros alterados foram o PAN ID (666) e o NI
– node identifier (COORDENADOR).
Porém diversos outros parâmetros podem ser alterados como, por exemplo, os que
dizem respeito as I/Os. Estas podem ser configuradas como entrada digital, saída
digital com default em baixo e saída digital com default em alto. As portas de D0 a
D3 podem desempenhar a função de entradas analógicas também. Algumas I/Os
têm opções exclusivas de parametrização, como, por exemplo, Commissioning
button e Associated indicator, as quais desempenhar função de início da rede e o
status de associação à uma rede.
As I/Os ainda tem a opção de inclusão de resistor de pull-up, selecionado para cada
porta em específico e ainda o envio de um frame por mudança de estado nas portas
digitais.
4.1.2.4 Parametrização dos módulos para a aplicação
Quatro módulos Xbee ZB foram utilizados neste projeto. O primeiro deles será o
coordenador da rede e ficará sempre conectado à placa USB e ao computador que
fará o papel de gateway e interpretação dos dados entre as redes Wi-fi e Zigbee. As
parametrizações deste módulo já foram apresentadas nas demonstrações das
funcionalidades do X-CTU nos itens anteriores.
O segundo módulo Xbee foi parametrizado de acordo com a figura 18. O firmware
utilizado foi o de roteador API. A PAN ID foi setada como 666, os parâmetros DH e
39
DL – destination address high e low – foram definidos como sendo o endereço físico
do Coordenador da rede, ou seja, DH=0013A200 e DL=402D2408, O NI foi definido
como JANELA. As I/Os foram parametrizadas de acordo com o disposto na figura,
na qual as saídas digitais são sempre com default em zero. A entrada digital D1 foi
também definida para detecção de mudança de estado, colocando o valor 0x01 no
parâmetro IC.
FIGURA 18 - PARAMETRIZAÇÃO DO MÓDULO "JANELA".
O terceiro módulo foi parametrizado de acordo com a figura 19. O firmware utilizado
foi o de roteador API. A PAN ID foi setada como 666, os parâmetros DH e DL –
destination address high e low – foram definidos como sendo o endereço físico do
Coordenador da rede, ou seja, DH=0013A200 e DL=402D2408, O NI foi definido
como BANHEIRO. As I/Os foram parametrizadas de acordo com o disposto na
figura, na qual as saídas digitais são sempre com default em zero. As entradas
digitais D1 e D5 foram também definidas para detecção de mudança de estado,
colocando o valor 0x22 no parâmetro IC.
O quarto e último módulo foram parametrizados de acordo com a figura 20. O
firmware utilizado foi o de router API. A PAN ID foi setada como 666, os parâmetros
DH e DL – destination address high e low – foram definidos como sendo o endereço
físico do Coordenador da rede, ou seja, DH=0013A200 e DL=402D2408, O NI foi
definido como PORTA. As I/Os foram parametrizadas de acordo com o disposto na
figura, na qual as saídas digitais são sempre com default em zero. As entradas
40
digitais D1, D3 e D5 foram também definidas para detecção de mudança de estado,
colocando o valor 0x2A no parâmetro IC.
FIGURA 19 - PARAMETRIZAÇÃO DO MÓDULO "BANHEIRO".
FIGURA 20 - PARAMETRIZAÇÃO DO MÓDULO "PORTA".
4.1.3 Comunicação Wi-fi
O estabelecimento da comunicação Wi-fi foi necessário para que o usuário
monitorasse os estados das variáveis descritas e pudesse através de um dispositivo
41
móvel alterá-las quando fosse necessário. A estratégia foi a utilização do protocolo
TCP-IP para que a comunicação ocorresse de modo Ad-Hoc entre as duas estações
que estarão presentes nesta rede: o dispositivo remoto e o computador com a
aplicação desenvolvida por este trabalho.
4.1.3.1 Frame de dados Wi-fi
Estratégia semelhante à utilizada nos frames dos módulos Zigbee foi aplicada às
transmissões via Wi-fi. Um frame de dados foi criado e é basicamente composto de
3 partes: um header, o frame data e o checksum.
O header segue exatamente a mesma estrutura do frame do Zigbee, possui um byte
de start (0x7E) e um byte de length, o qual contém o comprimento do frame data.
Neste caso o frame data não varia, pois sempre serão enviados os últimos dados
colhidos sobre todas as variáveis monitoradas e controladas à IHM. No caminho
inverso, sempre que uma variável for alterada pelo usuário na IHM, um frame
completo será enviado via Wi-fi pelo dispositivo móvel, mas somente o dado que fora
alterado será colocado no frame. Os espaços que ficariam em vazio serão
preenchidos com 0xFF.
O checksum faz a soma dos dados do frame data e subtrai o resultado de 0xFF,
assim como no Zigbee.
O frame data é formado por 15 bytes os quais representam todas as variáveis
monitoradas do sistema. A tabela 7 apresenta a disposição dos dados no frame. O
primeiro byte após o header é o de Tipo. Este fora considerado na criação do frame,
mas não há uma aplicação ainda para ele.
Os próximos 2 bytes, LA1 e LA2 representam os estados dos atuadores de
luminosidade do quarto e do banheiro, respectivamente. A IHM irá ler um valor de 0
a 100% que o usuário definiu, fazer uma adaptação para que os valores sejam
inteiros e variem de 0 a 70, e enviará os valores no frame de dados. Caso o usuário
opte por deixar o controle da luz no modo automático, ou seja, condicionado ao
estado do sensor de presença, o valor recebido será da intensidade acrescido de
100.
Os bytes PS1 e PS2 indicam a presença ou não no quarto e banheiro. Quando
estiverem em baixo (0), as portas estão fechadas, e quando estiverem em alto (1) as
42
portas estarão abertas. O byte PS2 foi adicionado ao frame para aplicações futuras e
não é utilizado nesta aplicação. O próximo byte, LSE, representa o status do sensor
de luminosidade externo. Quando for 1, há luz externa, e quando for 0 não há luz.
O próximo bloco de bytes representa a temperatura. TS1 e TSE têm 2 bytes cada e
indicam a tensão em mV equivalente à temperatura do quarto e externa,
respectivamente. Estes dados podem variar de 0x00 a 0x03FF. Há também um byte
destinado ao atuador de temperatura do quarto, TA1, o qual é binário e assume 1
quando está acionado e 0 quando está desligado.
Os próximos 3 bytes, SpS1, SpS2 e SjS1, representam o status dos sensores
indutivos que verificam se as portas e janelas monitoradas estão abertas (1) ou
fechadas (0).
Por fim, o byte SpeS1 é o status do sensor da persiana do quarto. Conforme
explicado anteriormente, ele pode assumir valores entre 0 e 3 para representar o
quão aberta está a persiana, sendo 0 totalmente aberta e 3 totalmente fechada.
43
TABELA 7 - FRAME DE DADOS WI-FI.
Posição Nome Range
Header 0 Start 0x7E
1 Length 0x0F(15 em hexa)
Data Frame
2 Tipo N/A
3 LA1 0x00 – 0xAA
4 LA2 0x00 – 0x07
5 PS1 0x00 ou 0x01
6 PS2 N/A
7 LSE 0x00 ou 0x01
8 TS1 0x00 – 0x03FF
9
10 TS2 0x00 – 0x03FF
11
12 TA1 0x00 ou 0x01
13 SpS1 0x00 ou 0x01
14 SpS2 0x00 ou 0x01
15 SjS1 0x00 ou 0x01
16 SpeS1 0x00 - 0x03
Checksum 17 Cksum calculado
4.1.4 Software desenvolvido
Após as definições de todas as variáveis envolvidas e o funcionamento das redes
Wi-fi e Xbee, o próximo passo foi o desenvolvimento de uma aplicação que atingisse
os seguintes objetivos:
Efetuasse uma conexão via Wi-fi com um dispositivo móvel e fosse capaz de enviar e
receber os frames de dados definidos;
Efetuasse uma conexão via Zigbee com os módulos remotos e fosse capaz de enviar e
receber os frames de dados definidos pelo Xbee;
Recebesse o frame de dados Wi-fi, manipulasse os dados, formasse e enviasse um
frame Xbee para execução das ações solicitadas;
44
Recebesse o frame de dados Xbee, manipulasse os dados, formasse e enviasse um
frame Wi-fi para atualização da IHM no dispositivo móvel.
Para tal, foram propostos os fluxogramas exibidos nas figuras 21 e 22, para o Zigbee
e para o Wi-fi, respectivamente. Todo o código desenvolvido está apresentado no
Apêndice 1, devidamente comentado.
45
FIGURA 21 - FLUXOGRAMA PARA COMUNICAÇÃO XBEE.
46
FIGURA 22 - FLUXOGRAMA PARA COMUNICAÇÃO WI-FI.
47
4.1.4.1 Software – Xbee
O programa do para comunicação com os módulos Xbee foi desenvolvido em
linguagem C#. A principal classe utilizada para a comunicação foi a SerialPort,
através da qual é possível se estabelecer a comunicação serial entre a porta serial
virtual criada pela placa de interface com o módulo Xbee. Um objeto do tipo
SerialPort é declarado o qual será usado para toda a comunicação.
4.1.4.1.1 Conexão
Todos os parâmetros padrão de comunicação serial foram mantidos. A partir do
momento que a porta COM é escolhida pelo usuário, a aplicação consegue
estabelecer uma conexão com o módulo. Para que ocorra o recebimento de dados,
uma subrotina é indicada no event handler que a SerialPort utiliza, desta maneira
ocorre uma conexão assíncrona que não estava a aplicação enquanto espera por
dados chegaram e cada vez que um dado for recebido a subrotina
xbeePortaRecebendo será chamada.
Basicamente, esta subrotina aguarda 50ms para que se tenha certeza que o frame
chegou ao buffer por completo, lê o número de bytes que chegaram, cria um byte
array com este comprimento e armazena os dados que chegaram nele. O frame é
exibido numa tela de logs para registro de acontecimentos.
Após a exibição a rotina xbeeFrameIn é chamada para que o frame de dados seja
desfragmentado em seus vários bytes para que a informação recebida possa ser
manipulada. Com a separação é possível verificar a integridade dos dados através
da conferência do checksum. Caso o frame apresente erros ele é descartado, se o
checksum conferir uma subrotina é chamada para a manipulação dos dados
recebidos.
4.1.4.1.2 Manipulação
A subrotina x_wManipula tem como função, a partir do módulo de origem dos
frames, tomar as devidas ações para cada tipo de dado. Caso o frame recebido seja
do módulo PORTA, outra condição é verificada para que seja distinguido o controle
do acionamento da luz pela IHM ou pelo sensor de presença. Caso seja via sensor,
48
a função sensorAutomático é chamada a qual analisa o status do sensor e manda
ou ligar a luz ou desligar.
Qualquer dado digital que chega ao frame deve ser interpretado de acordo com os
bit fields explicados no item 4.1.2.2. O byte array que representa os estados das I/Os
digitais é convertido para um array de bits, o qual irá conter para cada bit um valor
booleano (true ou false). Estes valores são convertidos para byte e armazenados
nas respectivas variáveis que serão enviadas no frame de dados Wi-fi.
Para os dados provenientes dos módulos BANHEIRO e JANELA há um fator que
dificulta um pouco a manipulação dos estados dos atuadores de luminosidade e o da
persiana. Como essas variáveis são representadas pela variação no estado de 3
saídas digitais, para a luminosidade, e 2 saídas digitais, para a persiana, um artifício
teve que ser usado para que os valores enviados ao frame Wi-fi representassem as
especificações iniciais, ou seja, fossem inteiros de 0 a 70 e inteiros de 0 a 3 para as
variáveis de luminosidade e persiana, respectivamente.
Os bits recebidos são armazenados num bit array, do mais significativo para o
menos significativo, para que então possam ser convertidos para um byte array e
copiados para as variáveis que formarão o frame Wi-fi.
A análise dos valores analógicos é um pouco mais simples. Tudo o que deve ser
feito é pegar o byte array que contem os valores e enviá-los aos bytes arrays das
variáveis que correspondem a estes dados no frame Wi-fi.
4.1.4.1.3 Envio
Ao fim da manipulação dos dados e armazenamento do estado atual das variáveis
nas variáveis que originarão o frame Wi-fi, a rotina wifiFrameOut é chamada para
montar o frame, calcular o checksum, exibir na tela de logs e chamar a função Send
(da classe sockets) para transmitir o pacote via Wi-fi.
Uma maneira manual de enviar os frames de dados foi prevista pela aplicação. Um
campo foi inserido no programa para que um frame Zigbee pudesse ser inserido e
enviado. Este frame inserido é devidamente convertido para bytes hexadecimais e a
rotina de envio pelo Zigbee xbeeEnvia é chamada para que a transmissão do frame
ocorra.
49
4.1.4.2 Software – Wi-fi
A parte do programa destinada a comunicação Wi-fi também foi toda desenvolvida
de linguagem C#. O destaque desta etapa de trabalho foi o uso de duas classes que
se tornaram essenciais para o funcionamento da aplicação: Sockets e a
BackGroundWorker. A classe socket já fora discutida anteriormente neste trabalho e
é ela que operacionaliza toda a comunicação TCP-IP que ocorre via Wi-fi.
A comunicação pode ocorrer de duas maneiras, síncrona ou assíncrona. O modo
mais indicado para este projeto é o de maneira assíncrona, uma vez que a
comunicação se tornaria guiada a eventos não fazendo com que a aplicação fosse
bloqueada para escutar o socket para aguardar conexão ou um dado. Entretanto
devido às dificuldades encontradas em estabelecer uma conexão assíncrona, optou-
se pela utilização do modo síncrono.
O problema oriundo dessa escolha foi contornado com a utilização da classe
BackGroundWorker. Esta é indicada para aplicações que demandam altíssimo
tempo e que não podem ter outras partes do programa bloqueadas, que é
exatamente o caso deste trabalho, uma vez que se a aplicação ficar somente na em
um dos lados da conexão, dados seriam perdidos no outro lado e o sistema não
seria confiável.
Basicamente esta classe executa uma operação num thread diferente para que a
que contém a user interface e as demais ações não seja bloqueada enquanto a
tarefa não termina.
4.1.4.2.1 Conexão
O programa se inicia ao acionar o botão conectar. Desta maneira o IP e porta aos
quais se deseja conectar são usados para a definição do IP endpoint. O próximo
passo é fase a inicialização do objeto da classe BackgroundWorker para que toda a
rotina de conexão e para escutar o socket de conexão sejam rodados em paralelo
com o resto do programa. Então o event handler DoWork é associado a uma
subrotina que será chamada assim que o método RunWokerAsync for chamado para
iniciar a aplicação em paralelo.
50
Além desse event handler, outro foi criado o ProgressChangedHandler, através do
qual é possível o envio de informações sobre o status da tarefa rodando em
background para a thread que contem a UI e o resto da aplicação. Esse event
handler foi associado com a subrotina worker_ProgressChanged.
Após a definição dos eventos, chama-se RunWorker Async, que faz com que a
subrotina DoWork seja chamada. Esta contém toda a estrutura necessária para
estabelecer a conexão e escutar o socket para receber os pacotes de bytes.
Uma vez que o objeto do tipo Socket já fora criado, o método Connect é chamado
com o IP endpoint previamente definido. O programa irá ficar nesta linha
aguardando um aceite do servidor para que a conexão seja efetuada. Este é o
primeiro ponto onde o BackgroundWorker importante. Enquanto ocorre esta espera,
o resto do programa que está no outra thread continuar a ser executado em paralelo
e o usuário não tem a sensação de que o programa está travado.
Assim que a conexão é aceita pelo servido um flag de status de conexão é
disparado e o método ReportProgress é chamado para que a UI possa ser
atualizada. Este método possui uma verificação de condições para que a flag de
status seja lida e caso ela seja true, o palavra “conectado” é mostrada no log de
registros, e após isso a flag é resetada.
4.1.4.2.2 Loop de Leitura
Para que uma verificação constante do socket fosse feita para procurar dados
recebidos, um loop infinito foi criado. Para se precaver de um possível problema
dentro do laço que faça com que aplicação trave, utilizou-se a estrutura com
try/catch, e caso o programa apresente algum problema uma mensagem de erro é
exibida e a aplicação termina.
Esse laço verifica através da propriedade Available do socket se há dado disponível
no buffer de entrada. Caso haja, o método Receive é utilizado e o frame é
armazenado na variável wifiIn. Então a função de desmontar frames Wi-fi,
wifiFrameIn, é chamada, uma flag de status de recebimento é setada e o
ReportProgress mostra no log de registros o frame recebido.
51
4.1.4.2.3 Manipulação
A função wifiFrameIn desmonta e armazena em variáveis cada byte array recebido
do frame e faz a verificação do checksum. Caso o frame seja validado, a função de
manipulação w_xManipula é chamada, caso contrário o frame é descartado e volta-
se ao laço que escuta o socket.
Considerando que o usuário só conseguirá alterar uma variável do programa por
vez, todos os frames Wi-fi que forem recebidos só irão conter um dado que irá
desencadear uma ação do código. Uma rotina de verificação de qual variável foi
alterada checa byte a byte qual é diferente de 0xFF. O índice do que for diferente é
armazenado, comparado com um string array que para cada índice do frame Wi-fi
armazena o nome da variável, ao contrário do frame que armazena os valores, e um
switch case é feito com o nome da variável alterada.
Só existem quatro variáveis que estão associadas a atuadores e, portanto, são
passíveis de alteração por parte do usuário: LA1, LA2, TA1 e SpeS1.
A manipulação dos dados de LA1 e LA2, atuadores de luminosidades do quarto e
banheiro, respectivamente, é a que demanda mais trabalho. O primeiro passo é a
verificação do dado para saber se o controle deve ser feito pela IHM ou via sensor. A
operação é simples: subtrai-se do valor recebido 100. Se o valor for positivo, indica
que o valor recebido estava entre 0 e 170, e entende-se que o controle deve
acontecer via sensor. Para tal, uma flag é setada para que quando o próximo frame
do Zigbee chegar com uma mudança de estado do sensor, a função
sensorAutomático seja chamada para as devidas ações, conforme explicado
anteriormente.
Caso o resultado seja negativo, significa que o valor enviado estava entre 0 e 70, e,
portanto o controle deve ser feito via software. A flag é resetada, para que o controle
seja feito desta maneira. Para ajustar o valor recebido de 0 a 70 para o range que o
módulo entenderia, através das 3 saídas digitais, é necessário que esse range seja
diminuído em escala para ficar entre 0 e 7. O dado recebido é então dividido por 10
e arredondado. O inteiro é então convertido para byte array e em seguida para um
bit array, no qual estarão armazenados nos 3 bits menos significativos os 3 valores
que booleanos que devem ser atribuídos às saídas digitais.
52
O bit array é convertido para string e armazenado num string array para que seja
feita a conversão de booleanos (true/false) para binários (1/0). Um laço do tipo for é
utilizado para que os valores que sejam iguais a 1 sejam convertidos para “05” e os
que são iguais a 0 sejam convertidos para “04”. Estes números são os parâmetros
utilizados pelos módulos Zigbee para que as saídas digitais fiquem em alto ou em
baixo.
O próximo passo é enviar para o módulo remoto o estados das 3 saídas digitais, um
frame por vez. Para que a mudança seja feita de uma vez só, o byte de Remote
Command Options é setado em 0x00, desta maneira as mudanças só serão
aplicadas quando um quarto frame com o comando AT “AC” for enviado. Após o
envio dos 3 frames, enviasse o ultimo contendo o “AC”.
O princípio de manipulação utilizado para SpeS1 é exatamente o mesmo que o
utilizado anteriormente com três exceções: não há necessidade de fazer qualquer
operação matemática com os dados que chegam, já que eles já estão no range
correto (0x00 a 0x03); A verificação para saber se o controle é via sensor ou IHM é
exclusivo do LA1, e, portanto não é necessário aqui; Ao invés de se trabalhar com
um dado de entrada para 3 saídas como no caso anterior, aqui são somente dois
dados de saída.
O modo de manipulação é o mesmo: conversão do byte array para bit array,
conversão de valores booleanos para binários, substituição de 1 ou 0 para “05” ou
“04”, envio de um frame para cada porta e, por fim, envio do comando “AC” para que
as mudanças sejam aplicadas.
O último dado a ser manipulado é o TA1, que é o atuador de temperatura que só
possui 2 estados: ligado e desligado. O procedimento é extremamente simples se
comparado com os anteriores. O byte array com o dado é transformado em um bit
array, o bit menos significativo é comparado: se for True, um frame é enviado com o
parâmetro “05” para a respectiva porta, caso seja False, o parâmetro enviado no
frame é o “04”.
4.1.4.2.4 Envio
Assim como para o Zigbee, há ainda uma maneira manual de enviar os frames de
dados que foi prevista pela aplicação. Um campo foi inserido no programa para que
53
um frame Wi-fi pudesse ser inserido e enviado. Este frame inserido é devidamente
convertido para bytes hexadecimais e o método Send do socket se encarrega de
enviar o frame via Wi-fi.
4.2 TESTES E SIMULAÇÕES
4.2.1 Teste de comunicação com Zigbee
A figura 23 mostra o hardware montado para testes. Este consiste em basicamente
quatro partes: Circuito de alimentação, Entradas e saídas digitais, entrada analógica,
e o módulo Xbee.
FIGURA 23 - HARDWARE MONTADO PARA TESTES.
O circuito de alimentação consiste em uma fonte de corrente contínua de 5V e um
circuito regulador de tensão, o qual utiliza um regulador linear para abaixar a tensão
54
para 3.3V, tensão de operação dos módulos Xbee. A figura 24 mostra os
componentes e esquema elétrico do regulador.
FIGURA 24 - ESQUEMA ELÉTRICO DO CIRCUITO REGULADOR DE TENSÃO. (MESSIAS, 2009)
As entradas e saídas digitais são simuladas por botões e Leds. Neste caso existem
3 entradas digitais e uma saída digital. Já as entradas analógicas são aqui
representadas através de um sensor linear de temperatura o LM35, o qual é
alimentado com 3.3V e o pino do meio retorna um valor em mV que é proporcional a
temperatura, só é necessário dividi-lo por 10 para obter-se a temperatura em graus
Celsius.
A primeira etapa de teste consistiu em utilizar a aplicação desenvolvida numa forma
mais simples, somente com as funções voltadas ao Zigbee ativas. Com o módulo
Xbee do protoboard como um router AT e o módulo conectado ao computador como
um coordenador API foi possível o envio de comandos AT e o recebimento dos
frames de ACK.
Na segunda etapa os testes foram feitos com ambos os módulos em modo API para
que fossem testadas as funções de Periodic sampling.
4.2.2 Testes de comunicação com Wi-fi
Os testes para comunicação via Wi-fi foram realizados com a aplicação em seu
estado mais simples, somente com as funções relacionadas ao Wi-fi ativas. O teste
consistiu em conectar ao servidor, enviar um dado, entrar no laço de espera para
aguardar o recebimento, receber e mostrar o dado recebido.
55
Uma rede Ad-Hoc entre dois notebooks foi estabelecida e a aplicação utilizava-se do
IP do servidor para aguardar a conexão, enquanto o servidor ouvia o socket que
estava com Bind em seu próprio IP.
4.2.3 Teste das funções de análise e manipulação de dados
O teste das funções de análise e manipulação de dados consistiu em forçar um
frame Wi-fi para que a análise fosse feita e o frame Xbee fosse gerado e o contrário,
forçar um frame Xbee para que a análise fosse feita e um frame Wi-fi fosse gerado.
56
5 RESULTADOS
5.1 GRAPHIC USER INTERFACE
Todo o cógido por trás das operações envolvidas para o recebimento, envio e
manipulação dos dados recebeu uma GUI – Graphic User Interface – para que fosse
observado os logs de eventos e os frames enviados e recebidos pela aplicação. A
figura 25 mostra a GUI desenvolvida.
FIGURA 25 - GUI PARA A APLICAÇÃO DESENVOLVIDA.
O lado esquerdo da tela contém todas as funcionalidades ligadas a comunicação via
Zigbee. Existem três campos para entrada de dados: Porta, Baudrate e um campo
para envio direto de data frames. Os únicos de preenchimento necessário são os
dois primeiros, os quais representam os parâmetros da comunicação serial com o
módulo conectado ao computados.
As funções dos 4 botões são autoexplicativas. O botão enviar envia o frame inserido
no campo logo ao lado, e o limpar apaga os dados armazenados na tela de registro
de logs, a qual está localizada logo acima deste botão. Os botões conectar e
desconectar possuem rotinas de verificação se a conexão já foi estabelecida ou não
para evitar erros ao tentar se conectar ou desconectar por uma segunda vez antes
de fazer a ação inversa.
57
O lado direito da tela apresenta exatamente a mesma estrutura e as mesmas
funcionalidades voltadas ao código de comunicação Wi-fi implementado.
A intenção era reunir poucos elementos para que o uso fosse rápido, intuitivo e para
que fosse o mais robusto possível, por isso a implementação de testes de conexão
antes de conectar novamente, ou desconectar. O objetivo principal era o
acompanhamento do tráfego de dados entre as duas redes, já que todos os frames
enviados e recebidos, sejam referentes a Wi-fi ou Zigbee, são exibidos nas
respectivas regiões de logs.
5.2 COMUNICAÇÃO ZIGBEE
A comunicação para a qual se deu mais atenção neste trabalho foi a com tecnologia
Zigbee. Esta escolha foi feita por se tratar de um protocolo muito conciso e completo
e por ser uma tecnologia relativamente nova, se comparada às demais que estão
presentes no mercado como, por exemplo, o Bluetooth.
Os primeiros testes foram mais básicos para entender a estrutura de frames
propostas pelo Xbee e algumas das suas principais funções. A figura 26 mostra a
configuração do módulo do protoboard para os testes.
FIGURA 26 - MÓDULO DE TESTES API-AT
A tabela 8 mostra os frames enviados de modo manual e os frames de resposta
recebidos.
58
TABELA 8 - TESTES API-AT.
Ação Frame enviado Frame resposta
Node discover 7E 00 04 08 01 4E 44 64 7E 001E 88 01 4E44 00 4DD5 0013A200406BF626 52454D4F544F00 FFFE 01 00 C105 101E 7E
Ler NI 7E 000F 17 01 0013A200406BF626 FFFE 02 4E49 D5
7E 0015 97 01 0013A200406BF626 4DD5 4E49 00 52454D4F544F 5C
Setar NI para "LED"
7E 0012 17 01 0013A200406BF626 FFFE 02 4E49 4C4544 00
7E 000F 97 01 0013A200406BF626 4DD5 4E49 00 32
Ler D1 7E 000F 17 01 0013A200406BF626 FFFE 02 4431 F8
7E 0010 97 01 0013A200406BF626 4DD5 4431 00 04 50
Acionar I/O D1
7E 0010 17 01 0013A200406BF626 FFFE 02 4431 05 F2
7E 000F 97 01 0013A200406BF626 4DD5 4431 00 54
O primeiro frame enviado foi um comando AT, Node Discover (NI) para o módulo
local. O frame enviado é formado pelo Start (7E), o Length (0004), a função API (08),
o frame ID (01), comando AT (444E) e por fim o checksum. Para este tipo de
comando, o comando de retorno é o 88. O frame resposta apresenta a mesma
estrutura do frame enviado até os bytes de comando. O byte seguinte, 00, significa
que a instrução foi executada com sucesso. Na sequencia são apresentados os
endereços de 16 e 64 bits, o NI que no caso é “REMOTO”, o endereço do pai deste
nó, o tipo de módulo (no caso router = 01), um byte reservado, a ID do profile e por
último do fabricante.
O segundo frame é um Remote AT Command Request. Ele pede ao nó de endereço
físico “0013A200406BF626” e de endereço dinâmico desconhecido, por isso “FFFE”, o
seu NI. O byte logo após os endereço é o para dar o “apply changes” imediato. Os
comandos 17 recebem como resposta frames do tipo 97. Novamente o frame tem a
estrutura muito semelhante ao que fora enviado, entretanto houveram algumas
mudanças. A função API mudou para 97, o endereço dinâmico correto do nome foi
informado (4DD5), o byte que indica sucesso na transmissão foi adicionado e o
parâmetro contendo o nome do módulo foi inserido antes do checksum. Aqui o nome
foi mantido como “REMOTO”.
O terceiro frame, assim como o anterior, é do tipo 17 e também utiliza o comando AT
NI. Mas desta vez a intenção é setar este parâmetro e para tal é necessário incluir
após o comando a nova palavra, em hexadecimal, que será considerada como Node
identifier. Neste caso utilizou-se a palavra “LED”. Observe o que o frame de retorno
confirma a instrução com o parâmetro 00.
59
Os próximos dois frames são os que seriam realmente interessantes para a maioria
das aplicações com módulos sem fio. É através da mudança dos parâmetros de D0
a D7, P0 a P2 que os estados das portas digitais são lidos ou modificados, e o
através dos parâmetros de D0 a D3 que os estados das portas analógicas são lidos.
O procedimento para envio destes frames é o mesmo que para outra alteração de
parâmetro. Observe que a estrutura dos frames são semelhantes às usadas para
leitura/gravação do parâmetro NI.
Para que varie o estado das saídas digitais é necessário que se altere o tipo de
saída digital que a porta desempenha. O X-CTU lhe permite escolher entre saída
digital com default em alto e com default em baixo, através dos parâmetros 0x05 e
0x04, respectivamente. Desta maneira, para que se faça uma saída digital ficar em
alto, basta enviar o comando referente à sua porta com o parâmetro 0x05, e para
que a saída vá para baixo é preciso enviar o comando AT da porta junto com o
parâmetro 0x04.
Para a próxima etapa, o firmware do módulo inserido no protoboard foi trocado para
ROUTER API para que pudesse ser testada a função de amostragem periódica. A
tabela 9 mostra os frames enviados e os recebidos nestes testes.
TABELA 9 - TESTES API-API.
Ação Frame enviado Frame resposta
Ler I/Os (IS) 7E 000F 17 01 0013A200406BF626 FFFE 02 4953 D0
7E 0017 97 01 0013A200406BF626 4DD5 4953 00 01 004B 04 0003 00C5 15
setar tempo sampling (IR)
7E 0011 17 01 0013A200406BF626 FFFE 02 4952 4E20 63
7E 000F 97 01 0013A200406BF626 4DD5 4952 00 2E
A simples mudança do tipo de firmware presento no nó remoto abre a possibilidade
do uso de uma função muito interessante dos módulos Xbee, a qual é ideal para
monitoramento de ambientes. Trata-se do Periodic Sample. Esta função permite
definir o intervalo de tempo que se deseja informações das I/Os do módulo. O
parâmetro que define o tempo é o IR, o qual recebe o valor em hexadecimal
equivalente ao tempo em milissegundos.
60
O primeiro frame apresentado na tabela 9 é referente ao comando AT IS, o qual é
uma amostragem forçada. A estrutura do frame segue o padrão adotado pelos
outros frames do mesmo tipo, 0x17. O grande diferencial está no argumento
recebido na resposta.
Após os bytes que indicam o comando requisitado e o status de execução do
comando, vêm os parâmetros da leitura que foi realizada nas I/Os dos módulos. O
primeiro byte corresponde ao número de amostragens no pacote, que por default é
0x01. Então os próximos 2 bytes indicam quais saídas digitais estão ativadas.
Transformando o hexa para binário obtem-se o seguinte valor: (1001011)b, valor que
indica que D0, D1, D3 e D6 estão ativas. O próximo byte contém quais entradas
analógicas estão ativas, neste caso a indicação 4 indica que a porta D2 está
recebendo dados.
Os próximos 4 bytes mostram o estado das variáveis em si. Os 2 primeiros indicam
os estados das portas digitais, enquanto os dois últimos indicam o estado da entrada
analógica. De acordo com o bitfield, D0 e D1 estão em alto, e estão sendo
fornecidos pelo sensor de temperatura 230mV – de acordo com a explicação prévia.
Como o sensor varia linearmente e é proporcional à tensão, dividindo-a por 10 já é
possível chegar ao valor de 23ºC.
O próximo frame mostra a manipulação do parâmetro que altera o intervalo de
amostragem dos módulos. O comando “IR” é enviado com parâmetro “4E20”, que é
20000 milissegundos em notação decimal. O frame de resposta segue o padrão dos
anteriores.
A partir da definição deste tempo de amostragem, a cada 20 segundos o módulo
Xbee enviará um frame quase idêntico ao recebido após a amostragem forçada. As
diferenças estão na função API que retornará, que será 92, e que estes frames não
irão conter os bytes relativos à função AT e nem o byte de status de execução da
ação. A interpretação dos dados é feita da mesma maneira que fora explanada.
Uma dificuldade foi notada em alguns momentos. Como tempo de amostragem
estava setado em 20 segundos, a chance do recebimento dos dados ao mesmo
tempo era baixa. Mas a medida que o tempo de amostragem se torna mais curto, ou
então frames decorrentes de mudanças de estados de portas de um dos módulos
começam a chegar surge a possibilidade de que o tempo de espera programado na
função de recebimento do Xbee, de 50ms, passe a ser o bastante para pegar o
61
número de bytes que aguardam no buffer de entrada que formam um frame
completo, entretanto caso após esse intervalo e antes de chamar a função read para
armazenar o frame na variável buffer cheguem mais dados na porta ocorrerão dois
problemas.
O primeiro é que um erro será anunciado uma vez que o número de bytes detectado
no primeiro momento é utilizado para criar um byte array para armazenar os dados
temporariamente, e se chegaram mais bytes após a definição desse número e antes
que ocorra a operação de armazenamento, o programa irá tentar armazenar um
dado num espaço menor do que o necessário, o que travará a aplicação.
O segundo é que durante essa transição é possível que ambos os frames sejam
perdidos, o que acabaria por diminuindo a confiabilidade da rede.
Neste momento não foi necessário tomar nenhum ação uma vez que o tempo é
grande o suficiente para que não ocorram problemas deste tipo.
5.3 COMUNICAÇÃO VIA WI-FI
Uma das preocupações no código desenvolvido era o comportamento das duas
redes atuando simultaneamente. Com o uso da classe BackgroundWorker foi
possível que a rotina de verificação do socket a procura de dados fosse rodada em
paralelo com a execução da GUI e da comunicação via Zigbee, fato que fez com que
não se tivesse problemas ao executar tarefas que demandam mais tempo, como por
exemplo, aguardar um servidor para conectar ou ficar verificando o buffer de entrada
do socket a todo instante.
Aparentemente o fato de não terem sido usadas os métodos da classe socket
voltados à comunicação assíncrona, a aplicação rodou de maneira semelhante, sem
que o programa travasse na execução de tarefas longas e mostrando-se ser
confiável.
Alguns testes foram feitos entre o programa aqui desenvolvido e o software
desenvolvido em (Pilon, 2011). Primeiro foi formada uma rede Ad-Hoc entre o
computador com esta aplicação e outro notebook o qual continha o lado do servidor
da comunicação via socket, além de possui toda IHM para variação das grandezas
automatizadas.
62
A conexão foi realizada com sucesso e a aplicação seguiu sem problemas para o
laço que verificaria constantente se existem dados no buffer de saída. O próximo
passo foi o envio de uma mensagem de um computador a outro. A palavra
escolhida, “TCC”, foi enviada com sucesso e ao recebê-la na outra ponta a mesma
foi exibida num dos campos de dados da IHM desenvolvida. O caminho contrário
também foi testado, e a aplicação aqui desenvolvida recebeu o dado com sucesso e
o exibiu na tela de registro de logs.
Para que fosse simulada uma ação em paralelo à rotina de recebimento de dados
para assegurar que as aplicações iriam rodar simultaneamente, sem prejuízo do
resto do programa, uma rotina foi inserida com uma laço do tipo for para que a cada
iteração um número fosse escrito na tela. A aplicação rodou em paralelo e não
prejudicou o recebimento de nenhum dados que vinha do Wi-fi. Entretanto, a GUI
ficou travada por um breve momento até que o laço fizesse todas as iterações
necessárias e atualizasse o log de registros.
Caso fosse necessária a presença de duas tarefas que demandam muito tempo de
execução neste programa, o caso ideal seria isolar a thread que executa e atualiza a
GUI das duas tarefas que demandam tempo e travariam a manipulação da interface.
Isso seria possível com a implementação de mais um objeto da classe
BackgroundWorker para rodas a outra aplicação, assim a thread principal só se
preocuparia com a GUI. Como só a rotina de verificação constante do buffer de
entrada do Wi-fi que trava o programa, todas as outras açoes do programa rodaram
na mesma thread do que a GUI, sem prejuízo de desempenho.
5.4 FUNÇÕES DE MANIPULAÇÃO
Os testes das funções de manipulação foram feitos de maneira isolada. Ao forçar-se
um frame de dados Wi-fi, o programa deveria conferí-lo, desmontá-lo, manipular
seus dados e atuar de forma a obedecer a instrução recebida. A tabela 10 mostra o
frame forçado no Wi-fi para que se formasse o frame Zigbee. Este frame indica que
a variável TA1 deve ser levada ao estado alto, ou seja, deve-se acionar o atuador de
temperatura. As variáveis com valores FF significa que não foram alteradas pelo
usuário.
63
TABELA 10 - FRAME WI-FI - TESTES. Start Length Tipo LA1 LA2 PS1 PS2 LSE TS1[0]
7E f 1 FF FF FF FF FF FF
TS1[1] TSE[0] TSE[1] TA1 SpS1 SpS2 SjS1 SpeS1 Cksum
FF FF FF 1 FF FF FF FF A
Após a desmontagem e verificação de checksum, além da identificação pelo
programa que a variável a ser manipulada é TA1, os parâmetros para formar o frame
Xbee já são definidos e chama-se a função de envio de frame. Como neste teste o
frame não será enviado, o programa coloca uma mensagem na tela de logs de que o
Wi-fi não está conectado e mostra o frame que seria enviado, o qual pode ser
observado na tabela 11 abaixo.
TABELA 11 - FRAME XBEE - TESTES.
Start Length Fç API frame ID Endereço 64bits
7E 00 10 17 01 00 13 A2 00 40 6B F6 26
End. 16bits Cmd Op AT cmd param Cksum
FF FE 02 44 35 05 EE
Este frame envia para o módulo “JANELA” a necessidade de levar a variável D5
para estado alto, a qual estará ligada aos circuitos de acionamentos do trabalho [5] e
irá acionar um ventilador.
O teste oposto também foi realizado. Um frame chega do Xbee e deve ser
interpretado para envio das informações via Wi-fi ao dispositivo móvel. A tabela 12
mostra o frame de amostragem recebido.
TABELA 12 - FRAME XBEE - TESTES 2.
Start Length Fç API Endereço 64bits End. 16bits
7E 00 11 92 00 13 A2 00 40 6E 09 E9 FF FE
Pck Digital Mask A. Mask Digital Channel Cksum
01 8 B2 00 00 01 5F
Ao receber o frame de amostragem, o programa prosseguirá com a verificação do
Checksum e a desmontagem. Após a triagem de origem dos dados, através da qual
concluíu-se que tratava-se de um frame do módulo “Banheiro”, os dados são
64
interpretados para montagem do frame Wi-fi. O frame indica que a sua porta D1 está
em nível alto, ou seja, SpS2 está indicando que a porta do banheiro está aberta.
Desta maneira a variável relativa a este sensor terá seu valor alterado para 1 e um
frame será montado com os últimos status recebidos das demais variáveis e
enviado. Já que pelo exemplo anterior o ventilador (TA1) estava ligado, o frame
enviado continuará a enviar esta informação até que seu estado mude para 0.
A tabela 13 mostra o frame enviado para o Wi-fi.
TABELA 13 - FRAME WI-FI - TESTES 2. Start Length Tipo LA1 LA2 PS1 PS2 LSE TS1[0]
7E FF 1 FF 0 0 FF 0 FF
TS1[1] TSE[0] TSE[1] TA1 SpS1 SpS2 SjS1 SpeS1 Cksum
FF FF FF 1 0 1 0 0 2
5.5 TESTES GERAIS COM INTEGRAÇÃO DE SISTEMAS
Devido à dificuldade de alinhamento de cronogramas deste projeto com os (Pilon,
2011) e (Rosa, 2011), não foi possível a conclusão dos testes envolvendo todas as
variáveis monitoradas e controladas. Alguns testes já foram realizados e obtiveram
sucesso em sua execução.
Os acionamentos do nível da persiana e do atuador da temperatura, os status dos
sensores de temperatura, interno e externo, além dos sensores indutivos de
abertura/fechamento de portas e janelas monitoradas foram devidamente testados e
os resultados foram positivos. Foi possível a visualização na IHM do dispositivo
remoto o status dos sensores e da persiana, além do acionamento do nível da
persiana e do atuador de temperatura, com as informações sendo transmitidas
através das redes Wi-fi e Zigbee.
6 CONCLUSÕES
A partir das premissas e objetivos assumidos na concepção deste trabalho
desenvolveu-se um software dentro dos objetivos iniciais. A ferramenta desenvolvida
é capaz de se comunicar com um dispositivo remoto através do protocolo TCP-IP e
com uso de sockets para a transferência dos frames de dados. O mesmo ocorre
para a outra rede sem fio implementada.
Ademais, todos os dados recebidos, tanto do dispositivo remoto quanto dos nós da
rede Zigbee, puderam ser manipulados para que a interação do usuário do sistema
de IHM desenvolvido em (Pilon, 2011) seja totalmente transparente. As instruções
recebidas são devidamente processadas e os parâmetros para as ações
necessárias são enviados às portas dos módulos Zigbee, às quais o hardware
desenvolvido em (Rosa, 2011) está conectado e usa essas informações para atuar
da maneira requerida pelo usuário no ambiente de trabalho.
Em comparação com outros projetos na área o sistema aqui desenvolvido mostrou-
se muito mais próximo à realidade dos sistemas de automação disponíveis no
mercado, no sentido de ter um dispositivo móvel para a atuação no ambiente o que
faz com que o usuário final não se limite a um terminal de comando fixo para utilizar
o sistema, e sim desfrute das facilidades que uma rede wireless pode trazer em
termos de mobilidade e conforto.
Por outro lado, a interface gráfica baseada numa planta é muito mais indicada
devido aos comandos intuitivos e uma melhor visão geral do sistema, aproximando a
interface de IHMs comumente encontradas em sistemas supervisórios de processos
industriais.
O sistema apresentado em (Gill, 2009) tem uma característica muito interessante.
Apesar de não possuir muitas variáveis controladas, ele proporciona o acesso da
rede existente de automação através da internet. Trata-se de um diferencial que
agrega muito valor a um possível produto introduzido no mercado.
Os dois pontos fortes identificados nos trabalhos supracitados são pontos de
desenvolvimento futuro para o projeto desenvolvido por este trabalho integrado ao
(Pilon, 2011) e (Rosa, 2011). São duas características que conforme fora citado
agregariam valor ao sistema de automação e sem dúvida seria uma vantagem
66
competitiva neste mercado que tem um potencial muito grande de crescimento, e
hoje já inclui 1 milhão de residências somente no Brasil. (Marques, 2011)
Alguns pontos podem ser aprimorados, particularmente nesta aplicação
desenvolvida. Para um ambiente contendo apenas 4 nós de uma rede Zigbee, as
funcionalidades de uma rede mesh não foram devidamente exploradas, em função
das curtas distâncias entre os módulos Xbee. Mas partindo do princípio que o
conceito concebido deste sistema de automação que foi aplicado a dois cômodos
pode ser estendido a uma residência por completo, esta topologia se mostra muito
atrativa, pois em um ambiente maior, com os “nós” da rede espalhados ao longo de
uma residência, não há possibilidade do coordenador da rede conectar-se
diretamente a cada módulo Xbee numa topologia estrela, fazendo com que a
mensagem tivesse que saltar entre alguns “nós” para até que chegasse ao de
destino.
Ainda, considerando o baixo número de módulos Xbee, o fluxo de dados não é tão
intenso. Desta maneira, não foi necessário para o desenvolvimento deste trabalho
uma estrutura de recebimento dos frames mais robusta. Mas com o aumento do
número de nós e do fluxo de informação, sem dúvidas este ponto deverá ser
aprimorado.
Além disso, as funcionalidades das comunicações que se utilizam de frames de
dados protocolados não foram completamente utilizadas. A única verificação
implementada foi de integridade dos dados recebidos através do uso de um
checksum. Para uma maior confiabilidade, os frames Wi-fi deveriam ter rotinas de
aguardo de pacotes do tipo Acknowledments para que haja a garantia de
recebimento de todos os frames enviados, ao contrário do Zigbee, o qual já tem essa
estrutura de verificação intrínseca da pilha desenvolvida.
Outro ponto que pode ser explorado numa próxima etapa é a utilização de
dispositivos do tipo End-devices. Devido ao tamanho do ambiente e a
disponibilidade de energia elétrica, não foram utilizados end-devices nesse projeto.
Entretanto, a economia de energia que um dispositivo que fica em períodos
programados de stand-by pode trazer é um ponto a se considerar pelo apelo à
sustentabilidade e economia.
Por fim, a Wi-fi entre o notebook e o dispositivo móvel foi implementada de modo
síncrono, porém em paralelo ao restante do programa. Desta maneira, o restante da
67
aplicação não para de rodar e é possível fazer a verificação constante de dados no
buffer de entrada do socket que estabelece a comunicação. Entretanto, a classe
sockets disponibiliza métodos, eventos e propriedades voltadas à comunicação
assíncronas. Estas foram estudadas, mas não foi possível obter resultados
satisfatórios nos testes. Considerando que o uso correto de um socket assíncrono
demanda menos poder de processamento e memória do que da maneira aqui
apresentada, é um ponto a se melhorar na programação. Ainda considerando o fato
de que o notebook deve ser substituído por um hardware dedicado, a menor
capacidade de processamento implica em menos custos para o projeto.
REFERÊNCIAS BIBLIOGRÁFICAS
ALBACORE. Manuais Placas de interface XBee. Disponível em: <
http://www.albacore.com.br/images/albacore/pdf/Manual_INT700_Adapter_Serial_U
SB_v1_04.pdf>. Acesso em Nov 2010.
ALBACORE. Material didático fornecido durante Treinamento “Start-up – Zigbee”.
Disponível em: < http://www.albacore.com.br/eventos2011/startup/zigbee/hotsite/ >.
Acesso em Mar, 2011.
Biblioteca MSDN. Disponível em: < http://msdn.microsoft.com/pt-br/pt-
br/library/default.aspx >. Acesso em Jan 2011.
BOLZANI, A. M.; MONTAGNOLI, C.; NETTO, M. L. Domotics Over IEEE 802.15.4 -
A Spread Spectrum Home Automation Application. IEEE Ninth International
Symposium on Spread Spectrum Techniques and Applications, 2006.
BRENNER, P. A Technical Tutorial on the IEEE 802.11 Protocol. Disponível em: <
www.sss-mag.com/pdf/802_11tut.pdf>. Acesso em Out 2010.
BROMLEY, K.; PERRY, M; WEBB, G. ."Trends in Smart Home Systems,
Connectivity and Services", Disponível em <www.nextwave.org.uk>, 2003.
Chauan, S. Basic concepts of threading: Part 1. Disponível em: < http://www.c-
sharpcorner.com/UploadFile/chauhan_sonu57/ThreadigPart101262006045547AM/T
hreadigPart1.aspx >. Acesso em Ago 2011.
De MENEZES C. V.; TIER D.; CAMPONAGARA A. C. Estabelecimento De Uma
Rede De Comunicação Utilizando Protocolo Zigbee Aplicada A Campo De Sensores.
XXI Congresso de iniciação científica e tecnologia em engenheira, 2006. Disponível
em: <
69
http://200.169.53.89/download/CD%20congressos/2006/CRICTE%202006/trabalhos/
441810-ege-01-09-112720.pdf >. Acesso em Jul, 2011.
DEITEL, P.; DEITEL, H. C# 2010 for Programmers. Boston: Pearson Educations,
Inc.,2010.
DIGI INTERATIONAL. XBee / XBee-PRO ZB RF Modules Manual. Disponível em: <
http://ftp1.digi.com/support/documentation/90000976_G.pdf >. Acesso em Set 2010.
Disponível em:< http://www.faludi.com/code/xbee-api-library-for-processing/>.
Acesso em Set 2010.
DORMAN, S. Sams teach yoursel Visual C# 2010: In 24 hours. Indianapolis: Sams
Publishing, 2010.
GILL, K.; YANG, S.H.; YAO, F.; LU, X. A ZigBee-Based Home Automation System.
IEEE Journal, Disponível em: <
ieeexplore.ieee.org/iel5/30/5174380/05174403.pdf?arnumber=5174403 >, 2009.
GISLASON, D. Zigbee Wireless Networking. New York: Newnes Publications, 2008.
HERESCU, R. R. Automação Residencial em Redes sem Fio. 2009. Trabalho de
diplomação (Graduação em Engenharia da Computação) – Universidade Federal do
Rio Grande do Sul, Rio Grande do Sul, 2009.
JIN, J. S.; JIN+, J.; WANG, Y. H.; ZHAO, K.; HU, J.J. Development of Remote-
Controlled Home Automation System with Wireless Sensor Network. Fifth IEEE
International Symposium on Embedded Computing, 2007.
KINNEY, P. ZigBee Technology: Wireless Control That Simply Works. In:
COMMUNICATIONS DESIGN CONFERENCE, 2003. Anais… Disponível em: <
70
http://www.zigbee.org/en/press_kits/2009_12_16/documents/white_papers/wp_zigbe
etechwireless_final.pdf>. Acesso em Ago 2010.
Libxbee. Disponível em:< http://code.google.com/p/libxbee/>. Acesso em Set 2010.
Making Things. Biblioteca Xbee API. Disponível em:<
http://www.makingthings.com/ref/firmware/html/xbee_8c-source.html>. Acesso em
Set 2010.
MARQUES, R. Automação residencial aquece o mercado em 2011. Disponível em: <
http://planetech.uol.com.br/2011/03/14/automacao-residencial-aquece-o-mercado-
em-2011/ >. Acesso em Mar 2011.
MESSIAS, A. R. Esquema elétrico do circuito regulador de tensão. Disponível em: <
www.rogercomm.com >. Acesso em Set, 2010.
PILON, B. C. Central para Automação Residencial: desenvolvimento de um software
de monitoramento e controle. 2011. Trabalho de graduação (Graduação em
Engenharia da Controle e Automação) – Universidade Estadual Paulista, Sorocaba,
2011.
RAAP, A. Xbee-api. Disponível em:< http://code.google.com/p/xbee-api/>. Acesso
em Set 2010.
RANGEL, Reilly. Parques Tecnológicos: caminho à inovação. Jornal Diário da
Manhã, Goiânia, Jul 2010.
ROA Y. H. H.; FRUETT F. Rede de sensores sem fio: uma abordagem prática. XVIII
Congresso Brasileiro de Automática, 2010. Disponível em: <
71
http://www.labplan.ufsc.br/congressos/CBA2010/Artigos/66171_1.pdf >. Acesso em
Jul, 2011.
ROSA, P. H. B. Central para automação residencial: Hardware de aquisição de
dados e comunicação com a central. 2011. Trabalho de graduação (Graduação em
Engenharia da Controle e Automação) – Universidade Estadual Paulista, Sorocaba,
2011.
TERUEL, E. C.; NOVELLI FILHO, A. Automação residencial: pesquisa quantitativa
para conhecer a necessidade do cliente. Disponível em:
<http://www.centropaulasouza.sp.gov.br/pos-graduacao/workshop-de-pos-
graduacao-e-
pesquisa/anais/2007/posteres/TERUEL,%20Evandro%20Carlos_2.pdf>. Acesso em
Jul/11.
United States of America. Zigbee Alliance. Zigbee Home Automation Public
Application Profile. Version 1.1. Rev 26. 2010.
WATSON, K.; NAGEL, C.; PEDERSEN, J. H.; REID, J.D.; SKINNER, M. Beginning
Visual C# 2010. Indianapolis: Wiley Publishing, 2010.
Wireless LAN (Wifi) Tutorial. Disponível em:< www.tutorial-reports.com/book/print/200 >.
Acesso em Out 2010.
72
APÊNDICE 1 - CÓDIGO FONTE DA APLICAÇÃO DESENVOLVIDA
Encontra-se em arquivo separado na mídia entregue.
73
ANEXO 1 – LISTA DE COMANDOS AT
Encontra-se em arquivo separado na mídia entregue.
![Clp [automação residencial com clp]](https://img.document.onl/doc/110x75/556bdec9d8b42ab2138b510c/clp-automacao-residencial-com-clp.jpg)
