Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Topologia Árvore (Cluster Tree) - é um avanço da topologia estrela, onde são adicionados
dispositivos routers que se comunicam com o coordinator, permitindo aumentar o
número de nós que podem ser adicionados a rede. Desta forma, um nó pode se ligar a red
e através do router, porém um dispositivo ligado ao router não pode se comunicar diret
amente com o coordinator, mas apenas por intermédio do router ao qual está ligado. A
topologia árvore pode ser vista na Figura 28.
49
Figura 28 - Topologia árvore. Fonte: LATTIBEAUDIERE.
Topologia MESH - similar a topologia árvore, sendo que a única mudança é que na rede MES
H, os dispositivos FFD´s podem se comunicar uns com os outros, independentes de se
guir a estrutura da rede, mas os RFD´s devem obrigatoriamente se comunicar com os
Coordinator’s ou Router’s aos quais estão conectados. A vantagem desta topologia é que o
tempo de latência das mensagens pode ser reduzido, e os nós ficam menos propícios a f
alhas. A Figura 29 ilustra esta topologia.
Figura 29 - Topologia MESH. Fonte: LATTIBEAUDIERE.
A pilha de demonstração do protocolo ZigBee pode ser baixada diretamente do site da
Microchip (www.microchip.com), sem custos. A mesma é disponibilizada
50
em um arquivo executável, que instala os arquivos da pilha em um conjunto de pasta
s, como pode ser visto na Figura 30. Nesta figura temos também a organização da pilha
ZigBee na janela de projeto do software MPLAB IDE, utilizado para a compilação dos p
rogramas e gravação dos microcontroladores PIC.
Figura 30 - Pilha de demonstração do protocolo ZigBee.
51
Analisando estes arquivos, pode-se ver que a pilha de demonstração do protocolo ZigB
ee é composta de 24 arquivos (todos com os nome iniciado pela letra “z”, de forma a di
ferenciá-los dos demais arquivos de configuração do microcontrolador), sendo que estes
arquivos são comuns a todas as aplicações e que cada arquivo responde por uma camada
do protocolo, ou seja, o arquivo “zAPL.h” responde pela camada de aplicação, os arquivos
“zAPS.c” e “zAPS.h” respondem pela subcamada de suporte ás aplicações, os arquivos “zMAC.h
.h” respondem pelas camadas MAC e PHY respectivamente, etc. A arquitetura do proto
colo ZigBee com suas respectivas camadas pode ser visto na Figura 31.
Figura 31 - Camadas do protocolo ZigBee. Fonte: LATTIBEAUDIERE.
A pilha de demonstração do protocolo ZigBee possui seis projetos direcionados a duas
famílias de microcontroladores, os microcontroladores da família PIC18F e os microc
ontroladores da família PIC24F. Cada família de
52
microcontrolador possui 3 projetos, cada um direcionado a um tipo de dispositivo
: um dispositivo Coordinator, um dispositivo Router e um dispositivo RFD (end de
vice). Visto que neste projeto esta sendo utilizando o kit de demonstração FBee, que
possui um microcontrolador PIC18F4620, será descrito então os projetos direcionados
a família PIC18F, que são: DemoPIC18Coordinator – Projeto direcionado ao dispositivo
coordenador da rede. DemoPIC18Router – Projeto direcionado aos dispositivos rotead
ores da rede. DemoPIC18RFD – Projeto destinado aos dispositivos end devices da red
e.
Embora todos os arquivos sejam abertos a modificações, estas serão efetuadas apenas no
arquivo principal de cada projeto. Cada projeto possui um arquivo principal de
mesmo nome do projeto, como por exemplo, o projeto “DemoPIC18Coordinator” possui o a
rquivo principal “Coordinator.c”. Estes arquivos principais possuem a seguinte arqui
tetura de programação: Inicio do programa; Configuração do dispositivo; Declaração da
antes e variáveis utilizadas no programa; Início da aplicação; o Inicialização do Watchdo
o Inicialização dos dispositivos de hardware; o Inicialização da pilha ZigBee; o Process
amento do programa; Processamento da função Primitive corrente; Determinação da próxi
nção Primitive; Execução das funções não relacionas a pilha ZigBee;
o Fim do processamento do programa. Fim da aplicação; Funções Primitives; Funções não
;
O protocolo ZigBee é executado através de suas funções Primitives, que são utilizadas para
a formação da rede e/ou ingresso em uma rede já formada,
53
descoberta de rotas de acesso aos dispositivos, envio e recebimento de dados, et
c. Algumas das funções Primitives declaradas na pilha de demonstração do protocolo ZigBe
e, bem como as respostas destas funções, podem ser vistas na tabela apresentada na F
igura 32.
Figura 32 - Funções Primitives e suas respostas. Fonte: LATTIBEAUDIERE
Para o projeto, as únicas alterações necessárias são no envio e recebimento de dados. Para
isso, vamos utilizar a função Primitive “APSDE_DATA”, que é utilizada para efetuar o envi
o e o recebimento dos dados entre os dispositivos da rede.
54
O envio de dados é efetuado carregando o vetor de dados através da função: TxBuffer[TxDa
ta++] = “dado a ser transmitido”;
Após isto, configuram-se os dados referentes ao dispositivo de destino: params.APS
DE_DATA_request.DstAddress.ShortAddr.v[1] = GetMACByte(); params.APSDE_DATA_requ
est.DstAddress.ShortAddr.v[0] = GetMACByte(); params.APSDE_DATA_request.RadiusCo
unter = DEFAULT_RADIUS; params.APSDE_DATA_request.DiscoverRoute=ROUTE_DISCOVERY_
SUPPRESS; params.APSDE_DATA_request.TxOptions.bits.acknowledged = 1; params.APSD
E_DATA_request.SrcEndpoint = 1; params.APSDE_DATA_request.DstEndpoint = 240; par
ams.APSDE_DATA_request.ProfileId.Val = 0x7f01; params.APSDE_DATA_request.Cluster
Id.Val = “função implementada”; A função “params.APSDE_DATA_request.DstAddress” é utilizada
ndicar o endereço do dispositivo de destino, e a função “GetMACByte()” é utilizada para efe
uar a captura do endereço de destino a partir da porta serial do dispositivo. A fu
nção “params.APSDE_DATA_request.RadiusCounter” é utilizada para indicar o número máximo de
tos (retransmissões entre os dispositivos) que pode ocorrer até o dispositivo destin
o. A função “params.APSDE_DATA_request.DiscoverRoute” é utilizada para habilitar ou desabi
litar a descoberta de rotas entre os dispositivos que estão se comunicando. A função “pa
rams.APSDE_DATA_request.TxOptions.bits.acknowledged” é utilizada para requerer uma c
onfirmação de recebimento dos dados. As funções “params.APSDE_DATA_request.SrcEndpoint” são
ilizadas para indicar e os “params.APSDE_DATA_request.DstEndpoint”
endereços individuais referentes aos dispositivos que estão se comunicando. A função “para
ms.APSDE_DATA_request.ProfileId.Val” é utilizada para identificar o perfil de comuni
cação a ser utilizado. A função “params.APSDE_DATA_request.ClusterId.Val” é utilizada para
ntificar a função de grupo que está sendo utilizada.
55
Após carregado o vetor de dados e configurado o endereço de destino do dispositivo,
efetuamos a transmissão chamando a função Primitive através do comando: currentPrimitive
= APSDE_DATA_request;
O recebimento de dados é efetuado pela leitura da função Primitive “APSDE_DATA_indicatio
n:” que retorna o número “1” quando o dispositivo recebeu algum dado. Desta forma, podem
os montar uma lógica para efetuar uma tarefa quando houver o recebimento de dados,
como por exemplo: case APSDE_DATA_indication: { WORD_VAL clusterID=params.APSDE
_DATA_indication.ClusterId; switch( clusterID.Val ) { case “função implementada” { //efe
tua uma tarefa } } }
Esta lógica funciona do seguinte modo: quando há o recebimento de dados, o dispositi
vo verifica a função de grupo que a mensagem está requerendo e efetua a tarefa referen
te a esta função. Estas alterações deverão ser efetuadas nos programas dos dispositivos Co
ordinator e RFD, não sendo necessárias mudanças no dispositivo Router, visto que este
dispositivo tem por função apenas retransmitir os dados que recebeu. Sendo assim, se
rão feitas modificações no programa do dispositivo Coordinator de forma a possibilitá-lo
efetuar a requisição dos dados referentes à leitura do medidor e apresentar estes dad
os através da porta serial, bem como enviar um comando para ligar ou desligar a saíd
a do medidor. Começa-se por adicionar mais um item ao menu já existente na pilha de
demonstração do protocolo ZigBee.
56
/* Menu System */ ROM char * const menu = "\r\n "\r\n "\r\n "\r\n "\r\n "\r\n "\
r\n 1: Enable/Disable Joining by Other Devices" 2: Request Data From Another Dev
ice" 3: Request Data From a Group of Devices" 4: Send Data To Another Device" 5:
Send Data To a Group of Devices" 6: Add/Remove Device to/from a Group" 7: Dump
Neighborhood Information"
//*********************************************************** "\r\n 8: Funcoes d
e Leitura do Medidor"
//*********************************************************** ;
Após isto, programam-se as funções que serão executadas a partir deste novo item.
void ProcessMenu( void ) { BYTE c;
DISABLE_WDT(); /* Get the user s input from the keyboard. */ c = ConsoleGet(); C
onsolePut( c ); switch (c) { . . . //*******************************************
******************* /* Funções do Medidor*/ case 8 : printf("\r\n 1 - Efetuar a Lei
tura do Medidor");
57
printf("\r\n 2 - Ligar a Saida do Medidor"); printf("\r\n 3 - Desligar a Saida d
o Medidor"); while( !ConsoleIsGetReady()); c = ConsoleGet(); ConsolePut( c ); sw
itch (c) {
case 1 :
/* Efetuar a Leitura do Medidor */
TxBuffer[TxData++] = 0x00; ZigBeeBlockTx(); params.APSDE_DATA_request.DstAddrMod
e=APS_ADDRESS_16_BIT; printf("\r\nShort address of device: "); params.APSDE_DATA
_request.DstAddress.ShortAddr.v[1]=GetMACByte(); params.APSDE_DATA_request.DstAd
dress.ShortAddr.v[0]= GetMACByte(); params.APSDE_DATA_request.RadiusCounter=DEFA
ULT_RADIUS; params.APSDE_DATA_request.DiscoverRoute= ROUTE_DISCOVERY_SUPPRESS; #
ifdef I_SUPPORT_SECURITY params.APSDE_DATA_request.TxOptions.Val = 1; #else para
ms.APSDE_DATA_request.TxOptions.Val = 0; #endif params.APSDE_DATA_request.TxOpti
ons.bits.acknowledged = 1; params.APSDE_DATA_request.SrcEndpoint = 1; params.APS
DE_DATA_request.DstEndpoint = 240; params.APSDE_DATA_request.ProfileId.Val = 0x7
f01; params.APSDE_DATA_request.ClusterId.Val = 0X0099; currentPrimitive = APSDE_
DATA_request; break;
case 2 : /* Ligar a Saida do Medidor */ TxBuffer[TxData++] = 0x00; ZigBeeBlockT
x();
58
params.APSDE_DATA_request.DstAddrMode=APS_ADDRESS_16_BIT; printf("\r\nShort addr
ess of device: "); params.APSDE_DATA_request.DstAddress.ShortAddr.v[1]=GetMACByt
e(); params.APSDE_DATA_request.DstAddress.ShortAddr.v[0]= GetMACByte(); params.A
PSDE_DATA_request.RadiusCounter=DEFAULT_RADIUS; params.APSDE_DATA_request.Discov
erRoute= ROUTE_DISCOVERY_SUPPRESS; #ifdef I_SUPPORT_SECURITY params.APSDE_DATA_r
equest.TxOptions.Val = 1; #else params.APSDE_DATA_request.TxOptions.Val = 0; #en
dif params.APSDE_DATA_request.TxOptions.bits.acknowledged = 1; params.APSDE_DATA
_request.SrcEndpoint = 1; params.APSDE_DATA_request.DstEndpoint = 240; params.AP
SDE_DATA_request.ProfileId.Val = 0x7f01; params.APSDE_DATA_request.ClusterId.Val
= 0x0098; currentPrimitive = APSDE_DATA_request; break;
case 3 : /* Desligar a Saida do Medidor */ TxBuffer[TxData++] = 0x00; ZigBeeBlo
ckTx(); params.APSDE_DATA_request.DstAddrMode=APS_ADDRESS_16_BIT; printf("\r\nSh
ort address of device: "); params.APSDE_DATA_request.DstAddress.ShortAddr.v[1]=G
etMACByte(); params.APSDE_DATA_request.DstAddress.ShortAddr.v[0]= GetMACByte();
params.APSDE_DATA_request.RadiusCounter=DEFAULT_RADIUS; params.APSDE_DATA_reques
t.DiscoverRoute= ROUTE_DISCOVERY_SUPPRESS; #ifdef I_SUPPORT_SECURITY params.APSD
E_DATA_request.TxOptions.Val = 1; #else params.APSDE_DATA_request.TxOptions.Val
= 0;
59
#endif params.APSDE_DATA_request.TxOptions.bits.acknowledged = 1; params.APSDE_D
ATA_request.SrcEndpoint = 1; params.APSDE_DATA_request.DstEndpoint = 240; params
.APSDE_DATA_request.ProfileId.Val = 0x7f01; params.APSDE_DATA_request.ClusterId.
Val = 0x0097; currentPrimitive = APSDE_DATA_request; break; } break; break; //**
********************************************************************************
default: break; }
Podemos observar que as funções implementadas neste menu não estão enviando dados, mas a
penas requisitando ao dispositivo de destino que efetue uma função de grupo, de acor
do com o número que foi enviado através do comando “params.APSDE_DATA_request.ClusterI
d.Val”. As funções de grupo que estão sendo chamadas e os valores atribuídos às mesmas são:
r medidor: Ligar a saída do medidor: Desligar a saída do medidor: 0x0099; 0x0098; 0x
0097;
É muito importante guardar estes números, pois os mesmos deverão ser utilizados no pro
grama do dispositivo RFD. Também deve-se implementar uma função para receber os dados
referentes a leitura do medidor, tratá-los e apresentá-los pela saída serial.
case APSDE_DATA_indication: { .
60
. . default: //In this example every endpoint except Endpoint EP_ZDO is processe
d here { BYTE i; BYTE frameHeaderIndex = TxData; WORD_VAL clusterID = params.APS
DE_DATA_indication.ClusterId; frameHeader = 1; for(transaction=0; transaction<fr
ameHeader; transaction++) { BYTE PacketLen; BYTE transactionNumber; switch( clus
terID.Val ) { //****************************************************************
****************** case 0x0096: //Enviando Leitura { int LEITURA, Wh, AUX1, AUX2
, AUX3; LEITURA = APLGet(); LEITURA = APLGet(); printf("\r\nLeitura do Medidor "
); PrintChar(params.APSDE_DATA_indication.SrcAddress.ShortAddr.byte.MSB); PrintC
har(params.APSDE_DATA_indication.SrcAddress.ShortAddr.byte.LSB); printf(" = ");
Wh = ( LEITURA * 0.9 ); AUX1 = ( Wh / 10 ); AUX2 = ( AUX1 * 6 ); AUX3 = ( Wh + A
UX2 ); PrintChar ( AUX3 ); printf(" Wh \r\n"); } break; //**********************
************************************************************
61
Pode-se observar que os dados após serem recebidos passam por uma série de cálculos. E
stes cálculos têm por função converter o número de pulsos gerados pelos sensores na corres
pondente quantidade de Watts Hora consumida, e converter estes números do formato
hexadecimal utilizado na transmissão para o formato decimal utilizado na apresentação
dos dados pela saída serial. Efetuadas as modificações no programa do dispositivo Coor
dinator, deve-se efetuar as modificações no programa do dispositivo RFD de forma ao
mesmo reconhecer as funções que estão sendo evocadas pelo dispositivo Coordinator. Pri
meiramente deve-se tratar as 3 funções de grupo que foram
implementadas possibilitando ao dispositivo enviar a leitura e ligar ou desligar
a saída do medidor.
case APSDE_DATA_indication: { . . . default: { WORD_VAL clusterID = params.APSDE
_DATA_indication.ClusterId; frameHeader = 1; for(transaction=0; transaction<fram
eHeader; transaction++) { BYTE PacketLen; BYTE transactionNumber; switch( cluste
rID.Val ) { //******************************************************************
******** case 0x0098: //Ligar a Saida { LATAbits.LATA2 = 1; printf("\r\nSaida Li
gada\r\n"); } break;
62
case 0x0097: //Desligar a Saida { LATAbits.LATA2 = 0; printf("\r\nSaida Desligad
a\r\n"); } break;
case 0x0099: //Ler Medidor { printf("\r\n Enviando a Leitura!\r\n"); TxBuffer[Tx
Data++]= 0; TxBuffer[TxData++]= MEMORIA_MEDIDOR; /* don t bother sending data to
myself */ if(params.APSDE_DATA_indication.SrcAddress.ShortAddr.Val==(macP IB.ma
cShortAddress.Val)) { APSDiscardRx(); currentPrimitive = NO_PRIMITIVE; break; }
/* package and send response */ ZigBeeBlockTx(); params.APSDE_DATA_request.DstAd
drMode=params.APSDE_DATA_ indication.SrcAddrMode; params.APSDE_DATA_request.DstA
ddress.ShortAddr=params.APSD E_DATA_indication.SrcAddress.ShortAddr; params.APSD
E_DATA_request.RadiusCounter=DEFAULT_RADIUS; params.APSDE_DATA_request.DiscoverR
oute=ROUTE_DISCOVERY _SUPPRESS; #ifdef I_SUPPORT_SECURITY params.APSDE_DATA_requ
est.TxOptions.Val = 1; #else params.APSDE_DATA_request.TxOptions.Val = 0;
63
#endif i = params.APSDE_DATA_indication.SrcEndpoint; params.APSDE_DATA_request.S
rcEndpoint=params.APSDE_DATA_i ndication.DstEndpoint; params.APSDE_DATA_request.
DstEndpoint = i; params.APSDE_DATA_request.ClusterId.Val = 0x0096; currentPrimit
ive = APSDE_DATA_request; } //**************************************************
********************************
Observa-se que quando o dispositivo receber uma mensagem com uma das funções de grup
o implementadas no programa do dispositivo Coordinator, ele irá efetuar a tarefa c
orrespondente a este número. A primeira tarefa implementada (0x0098) é utilizada par
a ligar a saída do medidor. A segunda tarefa implementada (0x0097) é utilizada para
desligar a saída do medidor, e a terceira tarefa implementada (0x0099) é utilizada p
ara enviar os dados referentes à leitura do medidor. Na terceira tarefa estamos en
viando o conteúdo de uma variável denominada “MEMORIA_MEDIDOR”, que é a variável onde são s
dos os pulsos gerados pelos sensores. Esta variável deve ser declarada no começo do
programa, como uma variável global, possibilitando a sua utilização pelas diversas funções
do programa.
//******************************************************************************
int MEMORIA_MEDIDOR = 0;
//******************************************************************************
/* Menu System */ . . .
Finalmente, implementa-se a função responsável pela aquisição dos pulsos provenientes dos
sensores. Para esta função, utiliza-se um pino de entrada do microcontrolador, que p
ossui a característica denominada “interrupção externa”.
64
void UserInterruptHandler(void) { // *******************************************
****************************** // Place any application-specific interrupt proce
ssing here // ******************************************************************
******* if (INTCON3bits.INT1IF == 1) { MEMORIA_MEDIDOR++; printf("\r\nRecebido P
ulso do medidor\r\n"); INTCON3bits.INT1IF = 0; } //*****************************
***************************************************** Desta forma, sempre que ho
uver uma mudança do nível lógico “0” para o nível lógico “1” na entrada deste pino, o progr
regado no microcontrolador irá adicionar mais um pulso a variável “MEMORIA_MEDIDOR”. Est
as são as modificações necessárias para que os dispositivos possam efetuar as funções de le
tura e transmissão de dados.
4.3 Desenvolvimento do dispositivo de aquisição e transmissão de dados.
O dispositivo de aquisição e transmissão de dados tem por função atuar como uma interface
entre o medidor de energia elétrica e o sistema de monitoramento e controle centra
l. Este dispositivo é responsável por efetuar a leitura dos sensores instalados no m
edidor e transmitir estes dados através de uma rede de comunicação, bem como receber o
s dados provindos da rede de comunicação e executar alguma tarefa correlacionada a e
stes dados. Para proporcionar a utilização da pilha de demonstração do protocolo ZigBee
sem a necessidade de muitas alterações, o circuito eletrônico deste dispositivo de aqu
isição e transmissão de dados será baseado no circuito eletrônico do kit de desenvolviment
o PICDEM Z, com a adição de uma entrada digital para receber o
65
sinal proveniente dos sensores, e de uma saída digital para comandar um dispositiv
o externo. O circuito eletrônico do Kit de desenvolvimento PICDEM Z possui em sua
arquitetura várias funções que o habilitam ao desenvolvimento de sistemas para comunic
ação wireless. Este kit é baseado no microcontrolador PIC 18F4620 e no transceptor MRF
24J40, utilizado para comunicação wireless padrão IEEE 802.15.4. O circuito possui ta
mbém: Uma saída serial, com conector DB-9, utilizado para a comunicação serial entre o
icrocontrolador e o computador; Um conector de programação in-circuit, utilizado par
a carregar o programa do microcontrolador sem a necessidade de retirá-lo da placa
de desenvolvimento; Um push-button ligado ao pino de reset do microcontrolador,
possibilitando reiniciar o programa carregado neste microcontrolador. Dois LEDs
e dois push-buttons ligados aos pinos do microcontrolador, para serem usados no
desenvolvimento do programa de aplicação do Kit . Para a comunicação com os sensores ins
talados no medidor de energia elétrica, é adicionado a este circuito uma entrada dig
ital conectada a um pino do microcontrolador, que possui uma função denominada de in
terrupção externa. Esta função tem por característica permitir o reconhecimento de qualque
r alteração de nível lógico no pino ao qual está relacionada, garantindo assim que o micro
controlador irá efetuar a correta aquisição dos pulsos gerados pelos sensores. Para po
ssibilitar ao circuito comandar um dispositivo externo, também será acrescida ao mes
mo uma saída digital. Esta saída digital poderá ser utilizada para comandar um rele li
gado em série com o circuito elétrico do consumidor de energia elétrica, permitindo as
sim a execução do corte e religamento da energia elétrica deste consumidor de forma re
mota. O circuito eletrônico, com suas devidas modificações pode ser visto na Figura 33
.
66
Figura 33 - Circuito eletrônico do dispositivo de interface.
O circuito eletrônico é basicamente todo alimentado por uma tensão contínua de 3,2Vcc, c
om exceção do CI MAX232, que é alimentado por uma tensão contínua de 5Vcc. Para a execução
devidos testes, este circuito foi montado em um protoboard, como mostra a Figur
a 34.
Figura 34 - Circuito montado em protoboard.
67
4.4 Testes efetuados com os protótipos
Após o desenvolvimento dos sensores e do circuito de aquisição e transmissão de dados, o
s mesmos foram colocados em teste, efetuando-se assim uma avaliação de seus funciona
mentos. O primeiro teste efetuado foi para verificar o correto funcionamento dos
sensores desenvolvidos. Para isto, os mesmos foram ligados a uma fonte de tensão
de 3,2Vcc, com sua saída ligada a um Led. Com este teste, verificou-se que os sens
ores emitem um pulso limpo (sem o efeito Bounce) a cada passagem do furo contido
no disco de alumínio do medidor. Esta montagem pode ser vista na Figura 35.
Figura 35 - Teste dos sensores acoplados ao medidor.
68
O segundo teste efetuado, foi para verificar o correto funcionamento do protocol
o ZigBee no circuito de aquisição e transmissão de dados. Para isto, este circuito foi
programado de forma a operar em conjunto com as duas placas do Kit de desenvolv
imento FBee, utilizando os programas originais da pilha de demonstração do protocolo
ZigBee. Este teste foi executado da seguinte forma: Primeiramente, o circuito d
esenvolvido foi programado como um dispositivo RFD e as duas placas do Kit de de
senvolvimento FBee, foram programadas como dispositivos Coordinator e Router. Em
um segundo teste, o circuito desenvolvido foi programado como um dispositivo Co
ordinator, enquanto que as duas placas do Kit de desenvolvimento FBee foram prog
ramadas como dispositivos Router e RFD. Para completar este teste, o circuito de
senvolvido foi programado como dispositivo Router, enquanto que as placas do Kit
de desenvolvimento FBee foram programadas como dispositivos Coordinator e RFD.
Com estes testes, verificou-se o perfeito funcionamento da comunicação ZigBee entre
o circuito desenvolvido e as placas do Kit desenvolvimento FBee, como ilustra a
Figura 36.
Figura 36 – Teste do circuito de aquisição de dados
69
O teste final foi efetuado com os sensores acoplados ao circuito desenvolvido pa
ra a aquisição e transmissão de dados. Neste teste, o dispositivo de aquisição e transmissã
de dados foi programado como um dispositivo RFD, enquanto que uma das placas do
Kit de desenvolvimento FBee foi programada como dispositivo Coordinator. Neste
teste, foram utilizados os programas modificados para o envio e recebimento dos
dados referentes à leitura do medidor. Este teste apresentou um resultado muito sa
tisfatório, pois no mesmo foi observado que os circuitos desenvolvidos, juntamente
com as alterações efetuadas na pilha de demonstração do protocolo ZigBee, funcionam da
forma como se era esperado. A montagem deste teste pode ser observada na Figura
37.
Figura 37 – Teste final do protótipo desenvolvido
70
5 CONCLUSÃO
A automação de medidores tornou-se um tema de grande interesse para as concessionárias
de energia elétrica, pois as permite efetuar um melhor controle do fornecimento d
e energia a seus consumidores. Embora o foco principal desta automação esteja na lei
tura remota dos medidores, ela também proporciona diversas outras soluções, como por e
xemplo, o corte e religamento remoto, a tarifação sazonal e o controle de qualidade
da energia fornecida. O trabalho desenvolvido demonstra a possibilidade da utili
zação dos medidores de energia elétrica eletromecânicos nesta automação, representando assi
considerável redução nos custos da implantação deste sistema, visto que estes medidores já
se encontram em funcionamento, e sua troca acarretaria em um grande investimento
inicial. O trabalho demonstra também a possibilidade de uso do protocolo ZigBee n
a comunicação entre estes medidores, devido a sua facilidade de instalação e configuração,
ao seu baixo custo de implantação e manutenção. O reduzido consumo de energia que os tr
ansmissores apresentam e a possibilidade de serem alimentados por baterias, o to
rna propício a ser utilizado em ambientes de difícil conexão com a rede elétrica. Embora
o protocolo ZigBee tenha sido desenvolvido visando uma grande robustez contra i
nterferências eletromagnéticas, notou-se que a comunicação de aparelhos Bluetooth afeta
o desempenho da rede, indicando que ainda falta um estudo detalhado sobre as int
erferências de RF que o mesmo possa vir a sofrer ou provocar a outras tecnologias
de comunicação sem fio. Como todas as outras redes sem fio, a rede ZigBee também está su
jeita a ataques de pessoas mal intencionadas. Este inconveniente pode ser sanado
pela utilização de seu sistema de criptografia baseado no algoritmo AES de 128 bits
, porém, por se tratar de uma rede em desenvolvimento, ainda não se tem estudos dire
cionados a segurança que esta criptografia proporciona aos dados trafegados pela r
ede. Como propostas para trabalhos futuros, sugerimos a adição de algumas funcionali
dades ao circuito aqui desenvolvido, funcionalidades tais como a adição de
71
um relógio de tempo real para possibilitar aos medidores efetuar a leitura de form
a sazonal, a adição de um dispositivo capaz de medir a qualidade da energia que está c
hegando ao medidor e o desenvolvimento de uma fonte com bateria para permitir ao
s medidores transmitirem seus dados mesmo quando não houver energia elétrica na rede
de distribuição.
72
BIBLIOGRAFIA
ANFBee. Application Note FBee, Aplicação de redes Mesh, REV01_2009. 2009. Disponível e
m <www.fractum.com.br>. Acesso em 18 de Novembro de 2009.
ANEEL. Agencia Nacional de Energia Elétrica. 2009. Disponível em < http://www.aneel.
gov.br>. Acesso em: 20 de Novembro de 2009. CREDER, Hélio. Instalações Elétricas. 14. ed
. Editora LTC – Livros Técnicos e Científicos Editora S.A. Rio de Janeiro, 2002.
DAHLE, David. A brief history of meter companies and meter evolution. Dave s old
Watthour Meter webpage. 2009. Disponível em < http://www.watthourmeters.com/> Ace
sso em: 29 de Novembro de 2009.
LATTIBEAUDIERE, Derrick P. AN1232. Microchip ZigBee-2006 Residential Stack Proto
col. 2009. Disponível em <www.microchip.com>. Acesso em 09 de Novembro de 2009.
MEDEIROS FILHO, Solon de. Medição de Energia Elétrica. 3. ed. Editora Guanabara Dois S
.A. Rio de Janeiro, 1983. MICROCHIP. PICDEM™ Z, Demonstration Kit User’s Guide. 2008
. Disponível em <www.microchip.com>. Acesso em 17 de Março de 2010.
73
ANEXO A – ARQUIVO PRINCIPAL DO PROJETO DO DISPOSITIVO COORDINATOR
99
ANEXO B – ARQUIVO PRINCIPAL DO PROJETO DO DISPOSITIVO RFD