MONITORAMENTO REMOTO DO CONSUMO DE ÁGUA UTILIZANDO O PADRÃO DE COMUNICAÇÃO SEM FIO IEEE 802.15.4 (REDES ZIGBEE) Andrei Salomão 1 ; Wilson Cabral de Sousa Jr. 2 ; Elaine Nolasco Ribeiro 3 RESUMO - Uma parte do projeto HIDROAER consiste no desenvolvimento de uma rede de monitoramento remoto do consumo de água para o Aeroporto Internacional de São Paulo. Para isso, são utilizados módulos eletrônicos acoplados a hidrômetros que geram pulsos a uma relação de saída (pulso / x litros) determinada. Nestes módulos, um microcontrolador interno avalia os sinais recebidos, reconhece a direção da vazão de água (fluxo ou refluxo) e calcula os valores de medição baseados na quantidade de pulsos gerados em um determinado intervalo de tempo. Os dados são armazenados localmente e também transmitidos para uma central remota, utilizando o padrão de comunicação sem fio IEEE 802.15.4, através de redes ZigBee. ABSTRACT - Part of the HIDROAER project is the development of a network for remote monitoring of water consumption for the International Airport of Sao Paulo. For this, electronic modules are used coupled to flow-meters that generates pulses at a determined output ratio (pulses / "x" liters). In these modules, an internal microcontroller receives the signal, determines the direction of water flow (flux or reflux) and calculates the values of measurement based on the quantity of pulses generated in a given period of time. The data is stored locally and is also transmitted to a central remote, using the wireless communication standard IEEE 802.15.4, through ZigBee networks. Palavras chave: Redes sem fio WPAN - ZigBee
1. INTRODUÇÃO O ZigBee tem por finalidade ser utilizado em aplicações onde baixas taxas de transferência são suficientes e onde um baixo consumo de potência é necessário ou desejável. Com essas características, o padrão ZigBee se torna ideal para implementar redes de sensores e microcontroladores, como o caso do presente projeto, onde o consumo de água é medido por hidrômetros eletrônicos localizados em diversos pontos de interesse e transmitido sem fio para uma central remota. Algumas características principais do ZigBee são mostradas abaixo: Rede do tipo Low-Rate Wireless Personal Area Network (LR-WPAN); Utilizado em Controle Residencial, Automação Predial e Industrial, Monitoramento Remoto, etc; Consumo de potência reduzido; Custo reduzido; Taxa de transferência de até 250 Kbps; Alcance ponto a ponto aproximado em 100 metros, dependendo da potência dos equipamentos, de características ambientais (obstáculos físicos, interferência eletromagnética etc) e da topologia da rede (pode-se criar uma rede muito extensa dependendo da topologia escolhida). Os dispositivos que utilizam o padrão ZigBee podem operar em três freqüências distintas, com taxas de transferências específicas para cada freqüência: 868 MHz (Europa) a uma taxa máxima de 20 Kbps; 915 MHz (América) a uma taxa máxima de 40 Kbps; 2.4 GHz (Global) a uma taxa máxima de 250 Kbps. Em uma rede ZigBee existem várias topologias possíveis. As mais usuais são as seguintes: Topologia star; Topologia cluster tree; Topologia mesh.
A Fig. 1.1 apresenta as diferentes topologias. Figura 1.1. Topologias para redes ZigBee. A topologia star é a mais simples, com o coordenador da rede se comunicando com um ou mais end devices sem opção de roteamento. Em teoria, até 65.536 end devices podem ser inseridos na rede. Na cluster tree existe um coordenador de rede se comunicando com roteadores e/ou end devices. Com a adição de roteadores, é possível desenvolver uma rede mais extensa devido ao roteamento das mensagens entre dispositivos que não estão em alcance direto. Por fim, na topologia mesh, o roteamento da rede permite a criação de caminhos diferentes da fonte de dados para o destino. Esta é uma topologia ideal para redes que possuem nós móveis. O coordenador de rede tem a função de iniciar a rede (definindo o canal de comunicação), gerenciar os nós e armazenar informações sobre eles. Os roteadores são responsáveis pelo encaminhamento das mensagens entre os nós da rede. E os end devices são dispositivos simples que se comunicam apenas com um nó da rede e têm capacidade para permanecer no estado dormindo por boa parte do tempo, fazendo com que o consumo de energia seja muito reduzido. 2. REDE DESENVOLVIDA PARA O PROJETO HIDROAER A rede utilizada para o projeto HIDROAER opera em 2.4 GHz e foi desenvolvida utilizando a topologia cluster tree. A Fig. 2.1 apresenta a topologia escolhida.
Figura 2.1. Topologia da rede desenvolvida para o projeto HIDROAER. A rede é composta por um coordenador, responsável por receber os dados enviados por end devices (dispositivos responsáveis por coletar os dados e transmiti-los) e roteadores (responsáveis pelo roteamento das mensagens, possibilitando a extensão da área da rede). Os dados são enviados pelo coordenador via USB para um PC (central remota). Os dados coletados e enviados são diversos (para controle e manutenção da rede) e serão detalhados em seções posteriores. Nesta rede, existe o conceito de pai-filho entre os dispositivos. A rede é formada, como sempre, pelo coordenador da rede. Quando um novo dispositivo (end device ou roteador) se associa ao coordenador, ele se torna filho do coordenador e este se torna pai do novo dispositivo. Caso um segundo dispositivo entre em alcance do primeiro (e podendo ou não estar dentro do alcance do coordenador), este segundo dispositivo pode se associar à rede como filho do primeiro. Os dispositivos associados podem ter vários filhos (e vários netos ), mas apenas um pai. A Fig. 2.2 apresenta a estrutura de uma rede cluster e as relações pai-filho. Figura 2.2. Rede cluster e as relações pai-filho [1].
2.1. Roteamento para a topologia cluster Como na topologia cluster os dispositivos tem condições de saber os enlaces que estão em sua área, o roteamento neste tipo de rede pode ser mais eficiente do que o roteamento para redes flat. A Fig. 2.3 mostra um algoritmo de roteamento para redes do tipo cluster. Figura 2.3. Roteamento para redes do tipo cluster. O algoritmo assume que os dispositivos devem armazenar uma tabela de roteamento. Seguindo o algoritmo mostrado na Fig. 2.3, primeiro o dispositivo deve checar se existe alguma informação do dispositivo de destino em sua tabela. Caso exista, a mensagem é transmitida diretamente para o destino. Caso não exista, a mensagem é transmitida para o pai do dispositivo fonte, que, por sua vez, está mais próximo do coordenador e deve ter informação adicional sobre o roteamento da rede. Uma vantagem das redes do tipo cluster é o tamanho reduzido das tabelas de roteamento se comparado com as tabelas nas redes flats. Em redes flats, uma entrada na tabela é necessária para cada destino em potencial. Para uma rede cluster, a tabela de roteamento pode ser muito reduzida pois destinos não encontrados na tabela ainda podem ser roteados através do pai do dispositivo. Uma tabela de roteamento reduzida significa redução na memória dos dispositivos, o que pode ser fator decisivo na escolha da topologia da rede. 2.2. Operação básica da rede e estrutura dos frames Os fluxogramas que serão mostrados adiante mostram uma visão básica e geral da operação de cada dispositivo pertencente à rede. Detalhes específicos e mais complexos foram omitidos por questões práticas e para obter uma visão mais clara de toda a operação. O fluxograma contendo a operação básica do coordenador da rede é mostrado na Fig. 2.4.
Figura 2.4. Fluxograma contendo a operação básica do coordenador da rede. A Fig. 2.5 mostra o fluxograma contendo a operação básica dos end devices.
Figura 2.5. Fluxograma contendo a operação básica do end device. A operação básica dos roteadores é mostrada na Fig. 2.6.
Figura 2.6. Fluxograma contendo a operação básica do roteador. Nota-se que os roteadores também podem ser utilizados como end devices, porém não devem ser alimentados com baterias, já que não possuem capacidade para operar no estado dormindo. Suas baterias se esgotariam em poucos dias, portanto uma alimentação AC deve ser providenciada. A rede foi projetada para operar praticamente sem intervenção humana, com capacidade de se re-organizar automaticamente em diversos eventos de falhas, como enlaces quebrados, queda de energia do coordenador ou roteadores etc. Os módulos conectados aos hidrômetros possuem um sistema de gerenciamento de energia otimizado, com capacidade para operar com baterias comuns por meses, dependendo da média de vazão do ponto de interesse em questão. As informações de nível de tensão das baterias também são enviados à central, tornando possível a geração de alarmes quando o nível estiver crítico. Ao total, são enviados 11 bytes em cada frame. O coordenador recebe e interpreta o frame, da forma mostrada na Fig. 2.7.
Ident. do Ident. do Informações Qtde. pulsos acumulados Reservado pacote dispositivo adicionais 1 2 3 4 5 6 7 8 9 10 11 Figura 2.7. Frame enviado pelo end device ao coordenador. Identificação do pacote (bytes 1 e 2): Este campo contém o valor 0xADAE e é utilizado para identificar o tipo de frame. Identificação do dispositivo (bytes 3 e 4): Cada dispositivo possui um Id. único e invariável. Este campo varia entre os valores 0x0001 e 0xFFFF. Utilizado para identificar precisamente o dispositivo que originou a mensagem (dispositivo fonte). Informações adicionais (bytes 5 e 6): O byte 5 contém informações a respeito do nível de tensão das baterias do dispositivo fonte. O byte 6 contém informação sobre fraude magnética do sensor do hidrômetro (depende da capacidade do hidrômetro em relatar esse tipo de informação). Qtde. pulsos acumulados (bytes 7, 8, 9 e 10): Pulsos acumulados recebidos pelo hidrômetro. Utilizado para o cálculo da vazão instantânea e/ou acumulada, de acordo com a relação de saída de cada hidrômetro (pulsos/litro). Reservado (byte 11): Reservado para futuras aplicações. Os dados são recebidos pelo coordenador, validados e enviados pela interface USB para a central remota. O frame enviado para a central via USB é mostrado na Fig. 2.8. Ident. do Ident. do Network Informações Qtde. Pulsos Reservado pacote dispositivo Address adicionais Acumulados 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Figura 2.8. Frame enviado pelo coordenador à central remota via USB. Identificação do pacote (bytes 1 e 2): Este campo contém o valor 0xADAE e é utilizado para identificar o tipo de frame. Identificação do dispositivo (bytes 3 e 4): Cada dispositivo possui um Id. único e invariável. Este campo varia entre os valores 0x0001 e 0xFFFF. Utilizado para identificar precisamente o dispositivo que originou a mensagem (dispositivo fonte). Network Address (bytes 5 e 6): Cada dispositivo possui um endereço na rede que pode variar de acordo com a necessidade. Utilizado para gerenciar as mensagens entre os dispositivos. Informações adicionais (bytes 7, 8 e 9): O byte 7 contém informações a respeito da qualidade do enlace, chamado de link quality indicator (LQI). Com essa informação, é possível verificar a qualidade de todos os enlaces da rede, possibilitando um novo dimensionamento da rede caso necessário. O byte 8 contém informações a respeito do nível de tensão das baterias do
dispositivo fonte. O byte 9 contém informação sobre fraude magnética do sensor do hidrômetro (depende da capacidade do hidrômetro em relatar esse tipo de informação). Qtde. pulsos acumulados (bytes 10, 11, 12 e 13): Pulsos acumulados recebidos pelo hidrômetro. Utilizado para o cálculo da vazão instantânea e/ou acumulada, de acordo com a relação de saída de cada hidrômetro (pulsos/litro). Reservado (byte 14): Reservado para futuras aplicações. Este frame é analisado pelo software residente na central remota e, com essas informações, os dados são apresentados ao usuário em forma de gráficos, tabelas, desenhos e etc. Os dados coletados pelos end devices, além de enviados para o coordenador, são armazenados localmente em uma memória, com a data (hh:mm:ss, dd/mm/aaaa) de cada evento. O relógio e o calendário dos módulos são atualizados regularmente pelo coordenador da rede, que por sua vez possui um relógio interno que também é atualizado regularmente pela central remota. Em caso de falha no coordenador, os módulos conectados aos hidrômetros ativam seu relógio interno e continuam a funcionar normalmente, gravando os dados em sua memória, com a respectiva data, sem perda de dados. Com a volta do coordenador, este poderá solicitar aos módulos os dados contidos em sua memória. O frame enviado pela central remota para a atualização do relógio do coordenador é mostrado na Fig. 2.9. Ident. do pacote hh:mm:ss dd/mm/aaaa Final pacote 1 2 3 4 5 6 7 8 9 10 Figura 2.9. Frame enviado pela central remota ao coordenador para atualização do relógio. Identificação do pacote (bytes 1 e 2): Este campo contém o valor 0x3F54 e é utilizado para identificar o tipo de frame. hh:mm:ss (bytes 3, 4 e 5): O byte 3 contém o valor atual das horas. O byte 4 contém o valor atual dos minutos e o byte 5 o valor atual dos segundos. dd/mm/aaaa (bytes 6, 7, 8 e 9): O byte 6 contém o dia atual. O byte 7 contém o mês atual e os bytes 8 e 9 contêm o valor do ano atual. Final pacote (byte 10): Utilizado para indicar o final do pacote, contendo o valor 0x40. Outro frame que poderá ser enviado ao coordenador pela central é o frame solicitando um reset a algum dispositivo. Alguns eventos poderão ser tratado simplesmente com a requisição de um reset ao dispositivo (ex: por algum erro, o coordenador associou o mesmo endereço de rede para dois dispositivos diferentes). O frame de reset é mostrado na Fig. 2.10.
Ident. do Ident. do Final pacote pacote dispositivo 1 2 3 4 5 Figura 2.10. Frame de reset enviado pela central remota ao coordenador. Identificação do pacote (bytes 1 e 2): Este campo contém o valor 0x3F52 e é utilizado para identificar o tipo de frame. Identificação do dispositivo (bytes 3 e 4): Cada dispositivo possui um Id. único e invariável. Este campo varia entre os valores 0x0001 e 0xFFFF. Utilizado para identificar precisamente o dispositivo que deverá iniciar o processo de reset, que consiste basicamente em realizar um pedido de re-associação ao coordenador. Final pacote (byte 5): Utilizado para indicar o final do pacote, contendo o valor 0x40. Como comentado anteriormente, os end devices possuem um gerenciamento de energia otimizado, tornando possível a operação com baterias comuns por grandes períodos de tempo. Para isso, os dispositivos permanecem dormindo até a ocorrência de algum evento, como a geração de um pulso pelo hidrômetro. O dispositivo então acorda, mas ainda permanece com seu rádio desligado e apenas armazena a informação deste pulso. Após um certo número de pulsos (dependendo basicamente da relação de saída pulso/litro de cada hidrômetro) ou após um determinado período de tempo, o end device acorda, liga seu rádio e envia um frame ao coordenador. Aproveitando o fato de estar acordado, o coordenador então envia um frame ao end device, contendo a atualização do relógio e a informação se o dispositivo deve iniciar o procedimento de reset. Este frame é mostrado na Fig. 2.11. Ident. do pacote hh:mm:ss dd/mm/aaaa Informações adicionais 1 2 3 4 5 6 7 8 9 10 11 12 Figura 2.11. Frame enviado pelo coordenador ao end device para atualização do relógio e informações adicionais. Identificação do pacote (bytes 1 e 2): Este campo contém o valor 0xCAED e é utilizado para identificar o tipo de frame. hh:mm:ss (bytes 3, 4 e 5): O byte 3 contém o valor atual das horas. O byte 4 contém o valor atual dos minutos e o byte 5 o valor atual dos segundos. dd/mm/aaaa (bytes 6, 7, 8 e 9): O byte 6 contém o dia atual. O byte 7 contém o mês atual e os bytes 8 e 9 contêm o valor do ano atual. Informações adicionais (bytes 10, 11 e 12): O byte 10 indica se o relógio do coordenador está confiável, ou seja, se o coordenador recebeu ao menos uma atualização da central após ser
ligado (valor 0x01 para confiável e 0x00 para não confiável). O byte 11 indica se o respectivo end device deve iniciar o procedimento de reset (0x01 para reset e 0x00 para não reset). O byte 12 informa ao end device se este deve enviar as informações contidas em sua memória (dados não recebidos por falha no coordenador ou software desligado na central etc.). O frame que será enviado pelo end device ao coordenador contendo as informações da sua memória ainda será analisado e desenvolvido. 3. RESULTADOS Antes da implantação da rede no Aeroporto Internacional de São Paulo, testes foram realizados utilizando 4 hidrômetros instalados em um laboratório da infra-estrutura aeronáutica no Instituto Tecnológico de Aeronáutica (ITA). A rede então era composta por 1 coordenador, 4 end devices e 1 roteador. Durante dias, além da vazão de água, outros dados foram coletados e analisados para demonstrar a confiabilidade, robustez e a capacidade de se auto-organizar em caso de falhas nos enlaces. Os resultados foram extremamente satisfatórios, mostrando que os eventos de falhas foram cobertos ao máximo, reduzindo a quase zero a probabilidade de perda de dados. Mesmo no caso de interferências e enlaces quebrados, os módulos foram capazes de se re-associar à rede sem intervenção humana em todos os casos, re-transmitindo os dados à central remota. A possibilidade de coexistência entre redes ZigBee e redes WiFi também foi analisada e comprovada. Os módulos ZigBee foram colocados em ambientes com tráfego intenso de redes WiFi e em nenhum momento a interferência foi significativa. Apesar de ambas as redes operarem em 2.4 GHz, os canais utilizados podem ser separados facilmente. Antes de iniciar a rede ZigBee, o coordenador escolhe o canal com menor energia (menor atividade), fazendo com que a possibilidade de interferência com canais WiFi seja bastante reduzida. 4. CONSIDERAÇÕES Para o desenvolvimento de uma rede mais extensa e com um número menor de roteadores necessários, seria interessante utilizar os chamados módulos High Power, com uma potência de transmissão de até 100mW. Os módulos que estão sendo utilizados para os testes são provenientes do kit de desenvolvimento 1321x EVK da Freescale e operam em 2.4 GHz. Estes módulos possuem uma baixa potência de transmissão (no máximo 1mW). Então surgiu a idéia do desenvolvimento de um módulo com maior potência na transmissão (de 1mW até 100mW, controlado por software) e maior sensibilidade na recepção (-103 dbm contra -92 dbm dos módulos da Freescale). A escolha dos componentes foi criteriosa, o esquemático e o layout do circuito impresso foram desenvolvidos e o
módulo deve ser fabricado e montado em breve. Tendo uma maior potência de transmissão e uma maior sensibilidade na recepção, o alcance ponto a ponto da rede deverá ser consideravelmente aumentado, reduzindo assim o número de roteadores necessários para a implementação da rede no Aeroporto Internacional de São Paulo. As características básicas do módulo em desenvolvimento são mostradas abaixo: Alimentação por baterias comuns (Ex.: 2 x AA) ou por fontes de 5 a 12 V com opção de baterias de backup para o caso de perda de energia; Potência de transmissão: 1mW até 100mW (controlado por software); Sensibilidade na recepção: -103 dbm; Microcontrolador e transceptor integrados em um único chip: MC13213; 16 canais na banda de 2.4 GHz; Amplificador de potência externo; LNA (Low noise amplifier) externo; Interface USB; Memória externa EEPROM para armazenamento dos dados (data-logger); 16 pinos de I/O para uso geral (2 podem ser utilizados como Rx e Tx para USART); 3 Pushbuttons (1 para Reset e 2 para uso geral); 3 LEDs (1 verde e 2 vermelhos); Opção para antena externa ou impressa no próprio circuito. O primeiro protótipo deverá ser fabricado e montado em breve, onde poderá ser testado quanto à performance do circuito RF, potência de transmissão, sensibilidade, harmônicas e capacidade para co-existir com outras redes operando em 2.4 GHz sem interferências. Outra questão interessante é a possibilidade de se ajustar a potência de transmissão por software. Tendo a informação de link quality indicator (LQI), um algoritmo pode ser desenvolvido para ajuste dinâmico da potência de transmissão, possibilitando a redução ainda maior do consumo de energia de cada módulo. 5. CONCLUSÃO As redes ZigBee são ideais para aplicações que não necessitam alta taxa de transferência e onde um baixo consumo de potência ou um tempo de acesso mínimo à rede é fator crítico. Fica claro que a escolha da topologia de rede depende de diversos fatores, entre eles: aplicação a que se destina, quantidade de dispositivos necessários para a rede, quantidade de memória de cada dispositivo (para o armazenamento das tabelas de roteamento), extensão da rede, entre outros.
Todos os requisitos foram devidamente analisados e a rede atual se encontra muito estável e robusta. Os possíveis eventos de falhas foram cobertos ao máximo, fazendo com que não haja perda de dados em momento algum. BIBLIOGRAFIA GUTIÉRREZ, J. A.; CALLAWAY JR., E. H.; BARRET JR., R. L. (2003). Low-Rate Wireless Personal Area Networks Enabling Wireless Sensors with IEEE 802.15.4, IEEE. WILLIAM, C. C. (2004). ZigBee: Wireless Control that Simply Works, ZMD America, Inc. ZigBee Alliance, ZigBee Specification V1.0. Freescale, 802154EVKUG, Freescale Semiconductor Inc., 2004. Freescale, MC13192SARDUG, Freescale Semiconductor Inc., 2004. Freescale, 802154MPSRM, Freescale Semiconductor Inc., 2004. ALEXANDER, B. E. (2005). 802.11 Wireless Network Site Surveying and Installation, Cisco Press. KARL, H.; WILLIG, A. (2007). Protocols and Architectures for Wireless Sensor Networks, John Wiley & Sons, Ltda.