2014.1 Filipe Souza Santana

(1)

BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO

FILIPE SOUZA SANTANA

DESENVOLVIMENTO DE UM FRAMEWORK HARDWARE/SOFTWARE PARA REDES DE SENSORES SEM FIO VOLTADAS PARA MONITORAMENTO DE

AMBIENTES DIVERSOS

FEIRA DE SANTANA 2014

(2)

DESENVOLVIMENTO DE UM FRAMEWORK HARDWARE/SOFTWARE PARA REDES DE SENSORES SEM FIO VOLTADAS PARA MONITORAMENTO DE

AMBIENTES DIVERSOS

Trabalho de Conclusão de Curso apresentado ao Colegiado de Engenharia de Computação como requisito parcial para obtenção do grau de Bacharel em Engenharia de Computação da Universidade Estadual de Feira de Santana.

Orientador: Thiago Cerqueira de Jesus

FEIRA DE SANTANA 2014

(3)

Redes de Sensores sem Fio têm avançado muito desde seu surgimento e vem se mostrando útil em diversas aplicações, desde a área industrial até a residencial. Microcontroladores e sensores também são áreas nas quais ocorreram grandes progressos na atualidade. Desta forma, este documento descreve o desenvolvimento de um framework para RSSF. Foi desenvolvida também uma Rede de Sensores sem Fio experimental voltada para monitoramento de ambientes diversos a partir das tecnologias citadas acima. A rede foi construída utilizando-se como base o protocolo ZigBee e o dispositivo XBee para comunicação sem fio. Um software também foi desenvolvido para que o usuário realize remotamente o controle de toda a rede.

Palavras-chave: RSSF. Monitoramento. Sem Fio. Controle. Microncotrolador.

(4)

Wireless Sensor Networks have been advancing since its creation and have proved to be useful in several applications, from industrial to residential fields. Microcontrollers and Sensors also have been improved. Thus, this document describes the development of a framework for WSN. Also, it was developed an experimental Wireless Sensor Network focused on environmental monitoring employing the technologies quoted above. The network was built using the ZigBee protocol and a XBee device for wireless communication. Also, a software was designed so the user can remotely control the network.

(5)

Figura 1 Diagrama básico de um nó de uma RSSF 14

Figura 2 Duas Redes de Sensores Sem Fio 15

Figura 3 Comparação entre ZigBee, Bluetooth e 802.11b 17

Figura 4 Detalhamento das camadas do ZigBee e 802.15.4 17

Figura 5 RSSF em topologia estrela 19

Figura 6 RSSF em topologia árvore 20

Figura 7 RSSF em topologia Árvore Cluster 21

Figura 8 RSSF em topologia Malha 21

Figura 9 Dispositivos XBee e tipos de antena 24

Figura 10 Exemplos de dispositivos XBee operantes em diferentes frequências 24

Figura 11 Exemplo transmissão no modo Transparente 25

Figura 12 Exemplo recepção no modo Transparente 25

Figura 13 Estrutura de Comando AT 27

Figura 14 Exemplo de Comando AT local no modo API 28

Figura 15 Exemplo de Comando AT remoto no modo API 29

(6)

Figura 18 Módulo XBee ZB low power - wire 41

Figura 19 Pinos do módulo XBee ZB low power 41

Figura 20 Placa de prototipação para XBee e protoboard 42

Figura 21 Diagrama de um nó sensor 43

Figura 22 Sensor de temperatura LM35 DZ 44

Figura 23 LM35 - Alimentação simétrica 44

Figura 24 LM35 - Alimentação simples 44

Figura 25 Encapsulamentos do LM35 45

Figura 26 LDR 45

Figura 27 Microcontrolador PIC16F877A 46

Figura 28 Adaptador CON-USBEE XPlus 47

Figura 29 Esquema do software no envio de pacotes 49

Figura 30 Esquema do software no recebimento de pacotes 50

Figura 31 Tela de configuração do módulo XBee 51

Figura 32 Tela de configuração dos pinos de entrada/saída do módulo XBee 52 Figura 33 Uso do terminal do X-CTU para envio de comandos AT 52

(7)

Figura 35 Esquema da camada de Hardware 56

Figura 36 Nó da rede em protoboard 56

Figura 37 Tela do sistema: Nós da rede 57

Figura 38 Tela do sistema: Acesso e controle de nó específico 58 Figura 39 Pacote: Mensagem enviada e recebida com sucesso 59

(8)

Tabela 1 Comparação dos dispositivos XBee série 1 e 2 (versões regulares) 23

Tabela 2 Estrutura básica de pacotes em modo API 26

Tabela 3 Tabela comparativa dos modos API e Transparente 26

Tabela 4 Exemplos de Comandos AT e Suas Respostas 27

Tabela 5 Tipos de pacotes API nos módulos XBee/XBee-Pro ZB 30

Tabela 6 Formato API para comandos AT 30

Tabela 7 Pacote de Resposta ao Comando AT ’NI’ 31

Tabela 8 Pacote de requisição de transmissão 33

Tabela 9 Pacote de Estado de Transmissão 34

Tabela 10 Pacote de requisição de comando AT remoto 35

Tabela 11 Formato de indicador de amostra de In/Out 37

Tabela 12 Características do módulo XBee ZB low power - wire 41

Tabela 13 Funções dos pinos do módulo XBee ZB low power 42

Tabela 14 Referências de luminosidade 46

Tabela 15 Características elétricas do LDR em relação à luz 46

(9)

(10)

1 INTRODUÇÃO. . . 10 1.1 MOTIVAÇÃO . . . 11 1.2 OBJETIVOS . . . 11 1.2.1 OBJETIVO GERAL . . . 11 1.2.2 OBJETIVOS ESPECÍFICOS . . . 11 2 FUNDAMENTAÇÃO TEÓRICA . . . 13

2.1 REDES DE SENSORES SEM FIO . . . 13

2.2 O PADRÃO 802.15.4 E ZIGBEE . . . 16

2.2.1 ENDEREÇAMENTO . . . 18

2.2.2 TIPOS DE COMPONENTES EM REDES ZIGBEE . . . 18

2.3 TOPOLOGIAS DE REDE . . . 18

2.3.1 TOPOLOGIA ESTRELA . . . 18

2.3.2 TOPOLOGIA ARVORE . . . 19

2.3.3 TOPOLOGIA ARVORE CLUSTER . . . 20

2.3.4 TOPOLOGIA DE MALHA . . . 20

2.4 XBEE . . . 21

2.4.1 CARACTERÍSTICAS DOS DISPOSITIVOS XBEE . . . 22

2.4.2 INTERFACES SERIAIS XBEE (MODOS DE OPERAÇÃO) . . . 24

2.4.2.1 MODO TRANSPARENTE . . . 24

2.4.2.2 MODO API . . . 25

2.4.2.3 COMPARAÇÃO ENTRE OS MODOS TRANSPARENTE E API . . . 26

2.4.3 COMANDOS AT . . . 27

2.4.3.1 COMANDOS AT NO MODO TRANSPARENTE . . . 27

2.4.3.2 COMANDOS AT NO MODO API . . . 28

2.4.4 TIPOS DE PACOTE NO MODO API . . . 29

2.4.4.1 COMANDOS AT . . . 29

2.4.4.2 RESPOSTA DE COMANDO AT . . . 29

2.4.4.3 REQUISIÇÃO DE TRANSMISSÃO ZIGBEE E PACOTE ZIGBEE RECEBIDO . . . 32

2.4.4.4 ESTADO DE TRANSMISSÃO . . . 32

2.4.4.5 REQUISIÇÃO DE COMANDO AT REMOTO . . . 32

2.4.4.6 RESPOSTA DE COMANDO AT REMOTO . . . 36

(11)

2.5 SENSORES . . . 38

2.6 MICROCONTROLADORES . . . 38

2.6.1 MICROCONTROLADORES PIC . . . 39

3 METODOLOGIA . . . 40

3.1 MÓDULO XBEE . . . 40

3.1.1 ADAPTADOR PARA PROTOBOARD . . . 42

3.2 NÓS SENSORES . . . 43 3.2.1 SENSOR DE TEMPERATURA LM35 . . . 43 3.2.2 SENSOR DE LUMINOSIDADE LDR . . . 45 3.2.3 MICROCONTROLADOR PIC16F877A . . . 46 3.2.4 MICROCONTROLADOR PIC18F4550 . . . 47 3.3 ESTAÇÃO BASE . . . 47 3.3.1 SOFTWARE . . . 48

3.3.1.1 BIBLIOTECA XBEE - API . . . 48

3.4 X-CTU . . . 48 4 RESULTADOS. . . 53 4.1 HARDWARE . . . 53 4.1.1 FIRMWARE . . . 53 4.1.2 MONTAGEM NA PROTOBOARD . . . 55 4.2 SOFTWARE . . . 56 4.3 COMUNICAÇÃO . . . 58 4.4 COMANDOS . . . 59 4.5 TESTES . . . 60 4.5.1 TESTES DE DISTÂNCIA . . . 60 5 CONCLUSÃO . . . 62 5.1 TRABALHOS FUTUROS . . . 62 REFERÊNCIAS . . . 63

(12)

1 INTRODUÇÃO

Redes de Sensores Sem Fio (RSSF) vêm introduzindo uma revolução na forma de monitorar e controlar diversos ambientes, possuindo aplicações nas mais diversas áreas econômicas e militares. Os avanços nas áreas de redes sem fio, microcontroladores e sensores abriram um leque de possibilidades para desenvolvimento de RSSF que se aplicam em várias áreas: monitoramento ambiental, saúde, monitoramento de tráfego, diagnósticos em indústrias, distribuição de água, automação residencial, dentre outras (ZHAO; GUIBAS, 2004).

Para realizar o monitoramento e controle de um ambiente de forma remota, é necessária a troca de informações até que esta seja visualizada pelo usuário final, que pode ser um centro de controle que utiliza estes dados para estudos e tomada de decisões, ou até mesmo disponibilizar estas informações em um banco de dados online. Um exemplo de sistemas de controle são os SCADA (Supervisory Control And Data Acquisition), que se configuram como sistemas de monitoramento à distancia de processos industriais (BAILEY; WRIGHT, 2003). A tarefa de transferência de informações pode ser facilmente feita utilizando cabos, passando através destes a informação, de um ponto à outro; porém para a utilização de cabos, é necessário lidar com diversos problemas e limitações, como alto custo de cabeamento para interligar os componentes da rede, a difícil manutenção para grande número de componentes da rede, difícil mobilidade e fios podem restringir a proximidade dos sensores aos fenômenos observados por estes (KARL; WILLIG, 2005). Esses problemas podem ser resolvidos utilizando comunicação sem fio. Surge então a ideia de Redes de Sensores Sem Fio como abordagem para monitoramento de ambientes remotos e de difícil acesso, e/ou com muitos pontos de aquisição de dados por parte dos sensores. É importante ressaltar que devido à comunicação sem fio nas RSSF, surgem problemas como segurança de dados e privacidade, autonomia energética, roteamento e manutenção da rede.

Uma RSSF é composta por diversos sensores espalhados em um ambiente, próximo ou dentro do fenômeno a ser observado por estes sensores. Estes fenômenos podem ser atividades vulcânicas, sísmicas, focos de incêndio em florestas, dentre diversos eventos que se desejam observar em um ambiente. Estes sensores são componentes que traduzem uma informação do “mundo real” em um sinal que pode ser processado e analisado por sistemas computacionais. Em uma RSSF, juntamente com estes sensores estão componentes capazes de realizar algum processamento (microcontroladores, por exemplo), componentes de energia (baterias)

(13)

e de transmissão de dados (antena). Um nó de uma RSSF é capaz de capturar as informações do fenômeno, mas também pode se comunicar com outros nós da rede, buscando e relacionando informações coletadas por estes. Estes nós sensores também se comunicam com uma estação base, que, operada ou não por um usuário, pode requerer dados de toda a rede para visualização, análise e armazenamento (DARGIE; POELLABAUER, 2010).

1.1 MOTIVAÇÃO

RSSF é uma área relativamente recente de pesquisa, adequada para as mais diversas aplicações em diferentes áreas. Como a maioria das redes possuem uma estrutura de implementação em comum, pode-se automatizar o processo de implementação da rede e de diversas funcionalidades. Assim, é proposto para este trabalho o desenvolvimento de uma coleção de funcionalidades para estruturar RSSF. 1.2 OBJETIVOS

1.2.1 Objetivo Geral

Neste trabalho é proposto o desenvolvimento de um framework e uma estrutura que auxilie na implementação e utilização de RSSF. Com este framework será implementada uma RSSF experimental voltada para o monitoramento de ambientes utilizando-se o padrão ZigBee. Este trabalho possui um segmento de Hardware, que provê uma interface com os sensores para aquisição e pré-processamento de dados; e um segmento de Software, provendo uma aplicação para o usuário realizar o controle dos sensores da RSSF.

Este trabalho limita-se ao desenvolvimento de uma RSSF com funcionalidades implementadas em Hardware e Software, garantindo a troca de dados entre os elementos da rede, porém não há implementação de algoritmos de segurança e de economia energética.

1.2.2 Objetivos Específicos

• Pesquisar os padrões de comunicação sem fio. • Pesquisar as arquiteturas de RSSF.

• Implementar a aquisição de dados de sensores em microcontroladores.

• Implementar a comunicação entre microcontroladores utilizando um padrão de comunicação sem fio.

(14)

• Implementar coleção de funcionalidades em firmware para microcontrolador • Implementar software para controle e manutenção da rede

• Implementar a especificidade de RSSF: identificação dos nós da rede (endereçamento) e roteamento para troca de dados entre os nós.

(15)

2 FUNDAMENTAÇÃO TEÓRICA

A seção a seguir descreve a pesquisa em cima dos tópicos que foram necessários para a construção da RSSF. Serão descritos os assuntos: RSSF, ZigBee, o dispositivo XBee, sensores e microcontroladores.

2.1 REDES DE SENSORES SEM FIO

O avanço nas tecnologias de circuitos integrados, sensores, microcontroladores, microprocessadores e nas comunicações sem fio possibilitou a criação de RSSF, que pode ser aplicada nas mais diversas áreas, de utilidade militar até doméstica.

Essa nova tecnologia promete redefinir a interação entre o homem e o meio em que se vive (casa, trabalho, trânsito, natureza e outros), já que no futuro próximo, muitos destes estarão providos de muitos sensores, que fornecerão a possiblidade de monitorar fenômenos que acontecem nesses ambientes (GUIBAS; ZHAO, 2004). RSSF podem ser definidas como redes autônomas que têm como tarefa monitorar diversas condições de um determinado ambiente como temperatura, pressão, vibrações e poluição. Assim, a rede, de forma cooperativa, transmite esses dados para uma base que analisará esses dados (MATIN; ISLAM, 2012).

Com todos os estudos e avanços nas RSSF, estas podem ser aplicadas em diversas áreas, realizando tarefas de monitoramento. Algumas das aplicações são para monitoramento ambiental, como por exemplo: observação de focos de incêndio em reservas florestais, eventos sísmicos, oceanos, vulcões e mensuração de qualidade do ar. Outras áreas em que pode-se utilizar RSSF são agricultura e pecuária, para controle de irrigação e monitoramento de pastos, por exemplo. Além disso, podem ainda ser utilizadas em ambientes industriais (monitoramento de maquinário de difícil acesso humano) e no trânsito. Outra área que muito se tem utilizado RSSF é a chamada “casa inteligente”, em que se pode obter informações de toda a casa (temperatura, presença, luz, gás, etc.) e controlá-la através de um dispositivo como um “smartphone”.

Uma RSSF é composta por diversos sensores espalhados em um ambiente, próximo do fenômeno a ser observado por estes sensores. Estes sensores são componentes que traduzem uma informação do “mundo real” (temperatura, pressão, umidade, dentre outras informações) em um sinal que pode ser processado e analisado (tensão elétrica, por exemplo). Um fenônemo pode ser qualquer evento

(16)

ocorrido em um ambiente, por exemplo atividades vulcânicas, sismícas, ou até mesmo focos de incêndio florestais.

Como pode ser visto na figura 1, um nó sensor é composto de diversos componentes junto ao(s) sensor(es). Há um módulo de fornecimento de energia que pode ser uma bateria ou uma célula solar, por exemplo. O nó sensor também possui uma unidade de processamento, que pode realizar diversas funções à depender da necessidade da aplicação, podendo ser um microcontrolador ou uma FPGA por exemplo. O módulo de comunicação é o dispositivo que implementa o padrão a ser utilizado na rede, e realiza o envio e captação de mensagens, ou seja, a interação de um nó com o restante da rede. Um nó pode também conter, caso necessário, um componente de memória para armazenar dados coletados pelos sensores e/ou demais informações sobre este nó.

Figura 1: Diagrama básico de um nó de uma RSSF.

Fonte: Autoria própria

Um nó de uma RSSF é capaz de capturar as informações do fenômeno observado, mas também pode se comunicar com outros nós da rede, buscando e relacionando informações coletadas por estes. Estes nós sensores também se comunicam com uma estação base, que, operada ou não por um usuário pode requerer dados de toda rede para visualização, análise e armazenamento (DARGIE; POELLABAUER, 2010). Há um nó especial chamado de nó sorvedouro, que é responsável por requerer da rede os dados mensurados pelos seus nós sensores, e transmiti-los à uma estação base que analisará estes dados. O nó sorvedouro pode estar diretamente conectado à estação base (um computador, por exemplo) ou por meio de um gateway de Internet. A figura 2 mostra duas redes de sensores sem fio distintas: uma que o nó sorvedouro está diretamente conectado à estação base (notebook), e a outra em que nó sorvedouro está conectado por meio da internet. É possível que duas RSSF que monitoram locais geograficamente distintos, enviem

(17)

seus dados para um mesmo local de análise e processamento. Figura 2: Duas Redes de Sensores Sem Fio.

As RSSF possuem características peculiares, que podem variar de acordo com a aplicação. Por exemplo, a depender da aplicação, pode ser necessário identificar cada nó sensor unicamente. Assim, é possível ter conhecimento do seu local de atuação, por exemplo em um sistema de casa inteligente que cada sensor monitora e controla um cômodo da casa; já em outros casos, os nós não precisam desse endereçamento individual. Outra característica é a mobilidade dos sensores, que em algumas aplicações podem ser móveis (mudam de localidade), por exemplo em uma RSSF para monitoramento de animais em fazendas pecuaristas (LOUREIRO et al., 2004).

Um parâmetro crítico em RSSF é o consumo de energia, já que normalmente os nós sensores estão em locais de difícil acesso e a energia é fornecida por uma bateria ou algo similar, possuindo assim uma fonte de alimentação “finita”, e um nó tem que operar por um tempo máximo possível (KARL; WILLIG, 2005). Além disso, trocar uma bateria, pode não ser uma tarefa fácil, podendo até ser impossível, caso o local em que se encontrem estes sensores seja de difícil acesso humano.

Como um nó sensor pode ter seu fornecimento interrompido por falta de energia, ou por outro motivo qualquer, é necessário que a rede seja tolerante à falha de nós; estas falhas podem ser contornadas com a utilização de mais nós do que seria estritamente necessário (KARL; WILLIG, 2005).

(18)

2.2 O PADRÃO 802.15.4 E ZIGBEE

Com as características e necessidades peculiares envolvidas em RSSF como endereçamento de nós, tolerância à falhas e baixo consumo de energia, se fez necessária a criação de um novo padrão de comunicação sem fio.

A partir dessas necessidades especiais, criou-se o padrão IEEE 802.15.4 que especifica as camadas físicas e de controle de acesso (modelo OSI). Este padrão define uma tecnologia de relativo curto alcance, baixa complexidade, baixo custo, baixo consumo de energia e a possibilidade de transmissão de taxas de dados pequenas (BURATTI, 2011) suprindo algumas das necessidades de uma RSSF.

A camada física define a transmissão com o meio físico, ou seja, a transmissão e recepção física dos dados. Nesta camada é definido o controle de ativação e desativação do transceptor de rádio, detecção de energia, indicação de qualidade da conexão (CHENG, 2007). Também é responsável por outras tarefas, como a transmissão dos dados, o estabelecimento da conexão entre dois dispositivos, a sincronização entre o transmissor e o receptor, a modulação e demodulação dos bits e a sincronização de pacotes (BURATTI, 2011).

Após a criação do padrão 802.15.4, foi criado pela ZigBee Alliance o padrão ZigBee, que surgiu visando uma fatia de mercado de controle e monitoramento de redes de sensores sem fio, que possuem necessidades supridas por este padrão, como alta confiança, baixo custo, baixo consumo de energia, e um protocolo aberto e padronizado (GISLASON, 2008).

Pode-se notar pela figura 3 que o padrão ZigBee propõe um baixo custo, baixa complexidade, e baixo consumo de energia quando comparado com as tecnologias Bluetooth e 802.11b. Assim o ZigBee torna-se uma boa escolha de padrão para aplicações de RSSF (FARAHANI, 2008).

A especificação ZigBee define as camadas no modelo OSI acima daquelas definidas pelo padrão 802.15.4, sendo elas: camada de rede e de aplicação conforme mostrado na figura 4.

A camada de rede (Network Layer) define as topologias que podem ser implementadas em redes ZigBee, sendo estas: estrela, árvore ou Mesh (malha), além de definir mecanismos para a entrada e a saída de dispositivos da rede, segurança e roteamento (BURATTI, 2011).

A camada de aplicação é subdividida em Application Support, Application Framework e ZigBee Device Object. A subcamada Application Support é responsável pela manutenção de tabelas de grupos e endereços, possuindo informação para

(19)

Figura 3: Comparação entre ZigBee,Bluetooth e 802.11b

Fonte: FARAHANI, S. 2008, p.3

Figura 4: Detalhamento das camadas do ZigBee e 802.15.4.

Fonte: FARAHANI, S. 2008, p.5

filtrar pacotes para dispositivos não registrados. A subcamada ZigBee Device Object é incumbida por definir o papel do dispositivo na rede podendo ser coordenador, roteador ou dispositivo final (explicado na seção a seguir); descobrir e estabelecer conexões com os dispositivos da rede. A subcamada Application Framework define como as aplicações interagem com o ZigBee (BURATTI, 2011).

(20)

2.2.1 Endereçamento

O padrão IEEE 802.15.4 define dois métodos de endereçamento para identificar univocamente os dispositivos em uma RSSF. Assim um nó da rede possui um endereço de 64bits e outro de 16bits. A camada de rede do protocolo ZigBee atribui um endereço de rede de 16bits a cada dispositivo na rede (FARAHANI, 2008).

2.2.2 Tipos de Componentes em Redes ZigBee

Uma RSSF ZigBee possui diversos nós sensores, porém estes componentes podem assumir algumas funções diferenciadas a depender da sua configuração e da topologia de rede em que estes estão inseridos. As funções são de coordenador, roteador e dispositivo final.

O coordenador é responsável por toda a manutenção e controle da rede; este permite ou nega a entrada de um dispositivo à rede, faz escolha do canal utilizado pela rede, endereça os dispositivos da rede e guarda uma lista de todos os dispositivos da rede. Um roteador tem a função de verificar a melhor rota para transferir um pacote para o destino final, funcionando como uma espécie de ligação entre o remetente e o destino; assim, estes expandem a cobertura da rede. Os dispositivos finais são os mais simples, projetados para consumir menos energia, e responsáveis apenas para transmitir suas informações para um roteador ou coordenador, sem nenhuma função de manutenção da rede (ELAHI; GSCHWENDER, 2009).

2.3 TOPOLOGIAS DE REDE

A topologia de rede representa a organização dos componentes e os direcionamentos de comunicação entre estes. Ou seja, a interligação entre os componentes. As RSSF podem ser configuradas com uma das diversas topologias de rede existente, a depender do suporte fornecido pelas tecnologias utilizadas. Por exemplo, o padrão IEEE 802.15.4 define as topologias de estrela, árvore, árvore cluster e malha. Porém, destas topologias, o ZigBee apenas suporta estrela, árvore e malha (ELAHI; GSCHWENDER, 2009).

2.3.1 Topologia Estrela

Esta topologia define que todos os nós sensores da rede se comunicam diretamente com o nó coordenador (figura 5).

(21)

Figura 5: RSSF em topologia estrela.

Pode-se perceber algumas limitações com o uso desta topologia, como pouca escalabilidade e robustez (KRISHNAMACHARI, 2006), já que o coordenador pode receber muitas informações de todos os sensores ao mesmo tempo, ou em um espaço de tempo muito curto, constituindo assim um gargalo no sistema. Além disso, a distância entre os nós e o coordenador é limitada, o que inviabiliza uma RSSF aplicada à uma área maior do que o alcance de comunicação entre os nós e o coordenador, ou uma área que possua diversos obstáculos, bloqueando a comunicação nó -coordenador.

2.3.2 Topologia Arvore

Esta topologia comporta-se como uma árvore, havendo um nó raiz, que possui "filhos", outros nós que também possuem "filhos", e outros que não os possuem, sendo chamados de folhas (figura 6).

Assim, na topologia estrela, a raiz é o coordenador da rede. Outros nós ligados à raiz encaminham dados dos nós de níveis mais inferiores da árvore, ou seja, estes dispositivos tem a função de estender a cobertura da rede (ELAHI; GSCHWENDER, 2009). Logo, diferente de uma configuração em estrela, esta topologia consegue cobrir uma área de monitoramento relativamente grande, utilizando dispositivos intermediários que "repassam" a informação até que se chegue ao coordenador. Ressalta-se que o coordenador também pode estar conectado diretamente à dispositivos que não são intermediários, ou seja, que não possuem nós "filhos".

O uso desta topologia implica em algumas desvantagens: se o funcionamento de um dispositivo "pai" for interrompido, todos os filhos conectados à este perderão a comunicação com o nó coordenador; e ainda que dois nós estejam muito próximos

(22)

Figura 6: RSSF em topologia árvore.

um do outro, mas não possuam a hierarquia pai - filho, estes dois não podem se comunicar (ELAHI; GSCHWENDER, 2009).

2.3.3 Topologia Arvore Cluster

Esta topologia nada mais é do que um arranjo especial da organização em árvore, na qual há o nó raiz e seus diversos filhos, que na topologia Árvore Cluster são chamados de clusters (figura 7).

Com esta topologia é possível dividir uma área grande em diversas zonas de monitoramento, em que cada zona possui um endereçamento do cluster (KRISHNAMACHARI, 2006).

2.3.4 Topologia de Malha

Uma topologia de malha é composta por um coordenador, que se conecta à diversos nós que também podem se comunicar a diversos outros nós. Assim forma-se uma rede em que os dados podem ser conduzidos até o destino por uma ou mais rotas, passando por diversos (ou um) dispositivos (figura 8).

Esta forma de organização de rede possui diversas vantagens: Tolerante à falhas, pois caso um dispositivo venha a falhar, será mais fácil para encontrar uma nova rota para a entrega de dados; fácil adição e remoção de nós, e com essa facilidade, para aumentar a área de monitoramento, é preciso apenas colocar mais nós na rede (ELAHI; GSCHWENDER, 2009).

(23)

Figura 7: RSSF em topologia Árvore Cluster.

Figura 8: RSSF em topologia Malha.

2.4 XBEE

Diversos fabricantes produzem módulos baseados no 802.15.4 e no ZigBee. Um desses que se destaca no mercado são os módulos XBee, fabricado pela Digi

(24)

International.

Há diversas versões do módulo de rádio XBee, adequados para diversas aplicações de RSSF. Dentre estas diversas versões dois grupos de hardware se destacam, sendo: XBee Series 1 e XBee Series 2.

O XBee Series 1 utiliza como padrão o IEE 802.15.4, mas não implementa o ZigBee. Assim, fornece suporte para simples comunicação ponto a ponto, e também uma rede de malha utilizando um padrão proprietário da Digi International (FALUDI, 2010), chamado de DigiMesh. Já o XBee Series 2 utiliza o ZigBee como base (logo, também baseia-se no 802.15.4) e fornece suporte à todos os tipos de rede suportados pelo ZigBee. Os dispositivos desta série são mais potentes que a série 1, pois possuem um alcance maior de comunicação. Vale ressaltar também que os dispositivos da série 1 não se comunicam com os dispositivos da série 2 (FALUDI, 2010). As diferenças podem ser vistas na Tabela 1.

Além das séries, os XBee’s estão disponíveis nas versões regulares e PRO. A versão PRO é mais robusta em potência, ou seja, é capaz de maior alcance de transmissão, porém consome mais energia quando comparada com a versão regular. 2.4.1 Características dos Dispositivos XBee

Os diferentes modelos e séries do XBee possuem diversas características que são passíveis de observação para se fazer a escolha do tipo de dispositivo mais adequado para o tipo de projeto de RSSF (ou mesmo que seja simplesmente uma comunicação entre dois dispositivos).

Um dos pontos a ser observado é o tipo de antena utilizada pelo módulo, já que cada uma supre um alcance e requer uma potência diferente. A antena chip é exatamente como o nome sugere, sendo achatada e "embutida" com o módulo XBee ocupando um pequeno espaço físico, porém o sinal não possui uma cobertura grande. Há também a opção de se utilizar um XBee com conector U.FL ou RPSMA (XBee series 2), que permite a conexão de uma antena externa (DIGI, 2007). Uma solução intermediária no quesito espaço - alcance é a antena do tipo whip, que apresenta uma pequena antena no corpo do módulo. Estes módulos e suas antenas podem ser vistas na figura 9.

Também há a frequência de operação. Em sua maioria, os dispositivos operam em 2.4GHz, porém há modelos variantes de 868MHz, 865MHz e 900MHz (figura 10). Os dispositivos que operam em menor frequência possuem maior penetração de sinal (maior alcance, que pode ser aumentado ainda mais com antenas de alto ganho);

(25)

Tabela 1: Comparação dos dispositivos XBee série 1 e 2 (versões regulares).

Característica Série 1 Série 2

Alcance Típico (ambientes fechados, urbanos) 30 metros 40 metros

Melhor Alcance 100 metros 200 metros

Corrente de Transmissão e Recepção 40/50 mA 40/40 mA

Firmware Típico 802.15.4 Ponto a

Ponto

ZB ZigBee Mesh Pinos de Entradas/Saídas Digitais 8 (mais uma

somente entrada) 11

Pinos de Entrada Analógicos 7 4

Pinos de Saída Analógicos (PWM) 2 Nenhum

Baixo Consumo, Pequena Largura de Banda, Pequeno Custo, Endereçável, Padronizado, Pequeno, Popular

Sim Sim

Roteamento de Malha Interoperáveis, Criação de Redes Ad Hoc, Tolerância à falhas (Self-Healing)

Não Sim

Topologias Ponto a Ponto, Estrela Sim Sim

Topologias Malha, Árvores Cluster Não Sim

Firmware Único Para Todos os Modos Sim Não

Necessário Nó Coordenador Não Sim

Configuração Ponto a Ponto Simples Mais Envolvido

Redes Baseadas em Padrões Sim Sim

Aplicações Baseadas em Padrões Não Sim

Chipset Freescale Ember

Firmware Disponível

802.15.4 (IEEE

standard), ZB (ZigBee 2007),ZNet DigiMesh

(proprietário)

2.5 (obsoleto)

Suporte e Atualizações Sim Sim

(26)

Figura 9: Dispositivos XBee e tipos de antena.

porém a taxa de transmissão daqueles que operam em 2.4GHz é maior. Deve-se observar que algumas frequências não são permitidas em diversos países, como o caso de 900MHz. Além disso, não se pode utilizar dispositivos que operam em diferentes frequências na mesma rede (SPARKFUN, 2013).

Figura 10: Exemplos de dispositivos XBee operantes em diferentes frequências.

Além dos XBee que implementam o 802.15.4 (somente), ou 802.15.4 com ZigBee; também há um XBee que utiliza o 802.11bgn (WiFi) como base.

2.4.2 Interfaces Seriais XBee (Modos de Operação)

Os dispositivos XBee podem ser configurados para operar em um dos dois modos disponíveis: Transparente e API (Application Programming Interface).

2.4.2.1 Modo Transparente

Quando o XBee funciona no modo de operação transparente, todos os dados recebidos via RS232 pelo pino DIN são transmitidos via Rádio Frequência (RF), como pode ser visto na figura 11. Quando os dados são recebidos via RF, estes são transmitidos através do pino DOUT (DIGI, 2009). Isto pode ser visto na figura 12.

(27)

Figura 11: Exemplo transmissão no modo Transparente.

Figura 12: Exemplo recepção no modo Transparente.

2.4.2.2 Modo API

O modo API é uma alternativa ao modo transparente. Uma API, de forma genérica, é um conjunto de interfaces que permitem um software interagir com outro, ou seja, pode fazer com que um computador "fale" eficientemente com outro (FALUDI, 2010).

Quando dispositivos XBee operam em modo API todos os dados recebidos e transmitidos estão contidos em pacotes. Assim, uma aplicação pode enviar dados em pacotes que contém informações adicionais, como endereço de destino, status de entrega do pacote, dentre outros.

O modo API facilita as operações como: enviar dados para diversos destinatários; conhecimento sobre o sucesso da chegada do pacote ao destino; para cada pacote recebido, é possível saber o endereço remetente (DIGI, 2009).

(28)

Tabela 2: Estrutura básica de pacotes em modo API.

Delimitador de Início Tamanho Dados Checksum

byte 1 byte 2 e byte 3 byte 4 ... byte n byte n+1 Fonte: (DIGI, 2009)

básica (tabela 2), separando-se os bytes em um delimitador de início, bytes definindo o tamanho do pacote, bytes dos dados enviados, e o checksum (cálculo realizado para verificação da integridade dos dados do pacote) (FALUDI, 2010).

2.4.2.3 Comparação Entre Os Modos Transparente e API

Cada modo de operação possui suas vantagens, limitações e problemas. É necessário fazer a escolha do modo a partir do estudo da aplicação da RSSF e do papel do dispositivo XBee na rede. O modo Transparente é mais simples e rápido de configurar-se, porém não oferece tantas funcionalidades como o modo API, que em contrapartida possui uma configuração e uso mais trabalhosos que o modo Transparente. Em resumo, as diferenças "API x Transparente" pode-se traduzir em "Simplicidade x Funcionalidades". A comparação entre os modos pode ser vista na tabela 3.

Tabela 3: Tabela comparativa dos modos API e Transparente.

Modo Transparente Modo API

Interface Simples Fácil suporte para envio de dados para mútiplos destinos

Fácil Suporte Possibilidade de conhecimento dos remetentes de dados recebidos Pode receber dados de entradas e saídas de dispositivos XBee remotos Configuração remota de dispositivos XBee

Fonte: (DIGI, 2009)

A DIGI recomenda que se utilize o modo de operação API quando um dispositivo necessitar enviar dados para múltiplos destinatários; configurar remotamente dispositivos da rede; necessidade de conhecimento dos remetentes dos dados recebidos; e dar suporte à identificações de clusters. Caso estas condições não se apliquem, é provável não haver necessidade de uso do modo API, sendo o Transparente suficiente. Então, em uma RSSF com dispositivos XBee, é possível fazer uma mescla de dispositivos no modo de operação API outros no modo Transparente (DIGI, 2009).

(29)

Tabela 4: Exemplos de Comandos AT e Suas Respostas.

Comando AT Ação do Comando Resposta (XBee / XBee Pro)

+++ Entra no modo de comando OK ATMY Retorna-se o endereço de rede do módulo 200 ATNI COORD Modifica o nome identificador do módulo para "COORD" OK ATWR Escreve as modificações na memória do módulo OK ATCN Requisita saída do modo de comando OK

2.4.3 Comandos AT

Os módulos XBee podem ser configurados através de comandos AT. No modo de operação transparente é possível configurar o dispositivo XBee local via RS-232; já o modo de operação API permite configurar módulos tanto locais quanto remotos. 2.4.3.1 Comandos AT No Modo Transparente

É possível enviar informações para configuração do XBee, no formato de comandos AT, que serão recebidos através da interface serial do módulo. Como, no modo transparente, todos os dados via RF endereçados para um módulo XBee é capturado por este, se faz necessário distinguir quando se trata de um comando AT. Assim, para entrar em modo de configuração, envia-se a sequência de caracteres "+++" para o XBee, que responde com a sequência "OK˚" pelo pino DOUT. A partir deste ponto, o módulo estará esperando, por um determinado tempo, comandos AT de configuração . A estrutura geral de um comando AT pode ser visto na figura 13.

Figura 13: Estrutura de Comando AT.

Para cada comando recebido pelo módulo, este envia uma resposta. Caso o comando seja executado com sucesso, será enviado um "OK"; caso ocorra algum erro, será enviado um "ERROR". Outras respostas podem ser enviadas pelo XBee, a depender do que foi-lhe requisitado. Alguns exemplos podem ser vistos na tabela 4.

(30)

Para sair do modo de comando envia-se para o XBee uma mensagem com os caracteres "ATCN", ou então o próprio módulo sai do modo de comando caso não receba alguma requisição por um determinado tempo (especificado pelo parâmetro Command Mode Timeout).

2.4.3.2 Comandos AT No Modo API

No modo de operação API é possível que os comandos AT sejam executados tanto localmente quanto remotamente. Porém, o grau de complexidade aumenta, pois é necessário o empacotamento dos dados. Tanto para o envio de comandos AT locais, quanto remotos, é enviado um pacote para o módulo XBee destino, e em seguida, recebe-se um pacote de resposta. Cada pacote tem formatos diferentes (na próxima seção serão discutidos tipos e formatos de pacotes). Para configurar um dispositivo XBee local é necessário que se realize o empacotamento dos dados a serem transmitidos. Neste pacote estão algumas informações essenciais como o tipo de pacote API (comando AT local) e o comando AT. Este pacote é então transmitido por um microcontrolador ou computador, e enviado para o XBee através do pino DIN. Após recebido pelo módulo, este envia um pacote de resposta através do pino DOUT (figura 14).

Figura 14: Exemplo de Comando AT local no modo API.

O modo API possui a vantagem de se configurar um módulo XBee remotamente. O procedimento é muito parecido com a execução de comandos AT locais; porém neste caso, além de um microcontrolador ou computador montar o pacote e enviar a um módulo XBee local, este transmitirá via RF o pacote para o módulo remoto endereçado neste. Assim, o módulo remoto transmitirá via RF um pacote de resposta para o XBee que requisitou o comando AT (figura 15).

Para requisitar comandos AT no modo API não é necessário utilizar a sequência de caracteres "+++", pois no próprio pacote há um Byte para identificação do tipo de pacote, podendo ser um Byte identificador de Comando AT. Também, com

(31)

Figura 15: Exemplo de Comando AT remoto no modo API.

esse identificador é possível fazer com que o XBee remoto aplique o comando AT imediatamente, ou que enfileire-o na memória e espere um comando AT para execução dos demais comandos enfileirados.

2.4.4 Tipos de Pacote No Modo API

Nos pacotes utilizados pelos módulos XBee para transmissão de dados, há um byte que identifica o tipo desse pacote (4o _{byte), já que é possível enviar dados} diversos, comandos AT, dentre outras requisições, e é preciso diferenciar os tipos de pacotes para assim serem propriamente tradados pelos módulos XBee.

Os módulos XBee/XBee-Pro ZB suportam 17 tipos de pacotes, cada um indicando um tipo de dado e uma ação específica a ser realizada pelo XBee. Os tipos de pacotes podem ser vistos na tabela 5.

Nas seções a seguir, serão tratados apenas os principais tipos de pacotes API utilizados pelos módulos XBee/Xbee-Pro ZB.

2.4.4.1 Comandos AT

Este tipo de pacote determina um comando AT para um dispositivo XBee local. A tabela 6 mostra este tipo de pacote construído.

Na tabela 6 foi utilizado o identificador "0x08" para o tipo de pacote, indicando que o comando AT deve ser executado logo ao receber o pacote. Caso se quisesse enfileirar o comando, utilizaria-se o identificador "0x09".

2.4.4.2 Resposta de Comando AT

Todo comando AT local enviado para um XBee fará com que este envie uma resposta de volta. Esta conterá o estado do comando e opcionalmente algum valor requisitado pelo comando (FALUDI, 2010). O formato deste tipo de pacote pode ser visto na tabela 7.

(32)

Tabela 5: Tipos de pacotes API nos módulos XBee/XBee-Pro ZB.

Descrição Código do pacote (Hexadecimal) Comando AT (executar imediatamente) 0x08

Comando AT (enfileirar) 0x09

Requisição de Transmissão ZigBee 0x10 Comando de endereçamento ZigBee explícito 0x11 Requisição de comando remoto 0x17

Criar rota 0x21

Resposta ao comando AT 0x88

Status de modem 0x8A

Status de transmissão ZigBee 0x8B

Pacote recebido 0x90

Indicador RX 0x91

Indicador de amostra de In/Out 0x92 Indicador de leitor de sensor 0x94 Indicador de identificação de nó 0x95

Resposta à comando 0x97

Status de atualização de Firmware 0xA0 indicador de gravador de rotas 0xA1 Fonte: (DIGI, 2009)

Tabela 6: Formato API para comandos AT.

Campos Índice Exemplo Descrição

Delimitador de início 0 0x7E

Tamanho do pacote MSB 1 0x00 Número de bytes entre o tamanho e o Checksum

LSB 2 0x04

Tipo de pacote 3 0x08 Indica o tipo de pacote API (Comando AT) ID do pacote 4 0x01 Identificação que pode

ser relacionada com uma resposta de acknowledge (ACK). Caso configurado em 0x00, nenhuma resposta de ACK é enviada

Comando AT 5 0x4E (’N’) Caracteres ASCII que identificam o comando AT

6 0x49 (’I’)

Parâmetro (opcional) Parâmetro para o comando AT

Checksum 0x5B 0xFF subtraído pela

soma dos bytes do índice 3 até o byte anterior à este

(33)

Tabela 7: Pacote de Resposta ao Comando AT ’NI’.

Tamanho do pacote MSB 1 0x00 Número de bytes

entre o tamanho e o Checksum

LSB 2 0x07

Tipo de pacote 3 0x88 Indica o tipo

de pacote API (Resposta comando AT)

ID do pacote 4 0x01 Identificação que

pode ser relacionada com uma resposta de acknowledge (ACK). Caso configurado em 0x00, nenhuma resposta de ACK é enviada

Comando AT 5 0x4E (’N’) Caracteres ASCII

que identificam o comando AT 6 0x49 (’I’) Estado do comando 7 0x00 0: OK 1: ERROR 2: Comando Inválido 3: Parâmetro Inválido 4: Falha de Transmissão

Dados do comando 8 0x53 (’S’) Retorna um valor

caso tenha sido realizada uma consulta.

0x31 (’1’)

Checksum 10 0x5B 0xFF subtraído pela

soma dos bytes do índice 3 até o byte anterior à este Fonte: (DIGI, 2009)

(34)

2.4.4.3 Requisição de Transmissão ZigBee e Pacote ZigBee Recebido

Com este tipo de pacote é possível fazer com que um módulo XBee envie dados para outro módulo XBee remoto. Na tabela 8 está um exemplo de um envio de mensagem "HELLO" para de um módulo XBee para outro.

Percebe-se que neste tipo de pacote têm-se os endereços do destinatário, sendo dois tipos de endereços: 64-bit e 16-bit. O endereçamento de 64-bit é um endereço único para cada módulo XBee, definido pelo fabricante (vindo impresso no fundo do módulo XBee) (FALUDI, 2010). Pode-se ainda definir este endereço no pacote como sendo valor ’0’ para enviar dados ao coordenador; ou valor ’0x000000000000FFFF’ para broadcast, ou seja, enviar para todos os nós da rede. Já o endereçamento de 16-bit é o endereço do módulo XBee que pode ser configurado pelo usuário; e colocar seu valor no pacote é opcional, porém ao fazê-lo, irá aumentar a velocidade de entrega dos dados ao destino (FALUDI, 2010). Quando um XBee remetente envia uma mensagem, o destinatário a recebe e um pacote de recebimento de dados é montado pelo módulo destino, e este é enviado pelo pino DOUT. Caso este módulo esteja em modo Transparente, será enviado por este pino somente os dados ("HELLO", neste exemplo). O formato do pacote de Recebimento ZigBee de dados é semelhante ao mostrado na tabela 8, porém no lugar do endereço de 64-bit e 16-bit estará o endereço do remetente. Também o byte de opções é diferente, sendo que ’0x01’ indica pacote reconhecido e ’0x02’ indica pacote de broadcast. Além disso, não há byte para raio de broadcast, e o tipo de pacote possui valor "0x90".

2.4.4.4 Estado de Transmissão

Uma vantagem do modo API é que é possível obter uma resposta a respeito da entrega do pacote enviado. Se a transmissão em que o ID de pacote receber valor diferente de zero, é recebido no módulo remetente um pacote indicando o estado de transmissão, reportando quaisquer problemas (FALUDI, 2010). Este tipo de pacote pode ser visto na tabela 9.

2.4.4.5 Requisição de Comando AT Remoto

Como já foi mostrado, é possível executar comandos AT em módulos XBee remotos. O formato de pacote para tal aplicação é mostrado na tabela 10, sendo um exemplo de alteração do endereço de 16 bits do XBee remoto.

Assim, como é feito para uma requisição de transmissão de dados, o endereço de 64-bit pode ser utilizado como valor ’0’ para endereçamento do coordenador, ou

(35)

Tabela 8: Pacote de requisição de transmissão.

LSB 2 0x19

Tipo de pacote 3 0x10 Indica o tipo de pacote API (Requisição de transmissão)

ID do pacote 4 0x01 Identificação que pode ser relacionada com uma resposta de acknowledge (ACK). Para 0x00: Nenhuma resposta ACK

Endereço do

destinatário (64-bits) MSB 5 0x00 Endereço de 64 bits dodo destinatário.

6 0x13 7 0xA2 8 0x00 9 0x40 10 0xA8 11 0x3F LSB 12 0x8E Endereço de

destinatário (16-bit) MSB13 0xFF Endereçobits do destinatário.de 16 Desconhecido ou broadcast: 0xFFFE

LSB 14 0xFE

Raio de broadcast 15 0x00 Valor máximo de saltos em uma transmissão broadcast.Valor ’0’: Máximo de Saltos

Opções 16 0x00 Opções extras:

0x01 - Desabilitar ACK 0x20 - Habilitar encriptação APS (caso EE = 1)

0x40 - Utilizar tempo limite máximo para este destinatário 0x00 - Não utilizar nenhuma opção extra Dados 17 0x48 (’H’) Dados à enviar para o

módulo destino 18 0x45 (’E’)

19 0x4C (’L’) 20 0x4C (’L’) 21 0x4F (’O’)

Checksum 22 0x13 0xFF subtraído pela soma dos bytes do índice 3 até o byte anterior à este

(36)

Tabela 9: Pacote de Estado de Transmissão.

LSB 2 0x07

Tipo de pacote 3 0x8B Indica o tipo de pacote API (Requisição de transmissão)

ID do pacote 4 0x01 dentificação que pode ser relacionada com uma resposta de acknowledge (ACK). 0x00: Nenhuma ACK enviada

Endereço do destino

(16-bit) MSB 5 0x00 Caso o pacote tenhasido entregue com sucesso, aqui estará o endereço para o qual o pacote foi entregue. Caso contrário, este valor será o mesmo do pacote de requisição de transmissão

LSB 6 0x40

Tentativas de

transmissão 7 0x00 Número de tentativarde retransmitir o pacote

Estado da entrega 8 0x00 0x00 - Entregue com sucesso 0x01 - Falha de MAC ACK 0x15 - Destinatário Inválido 0x21 - Falha de ACK da rede 0x22 - Não entrou na rede 0x23 - Endereçado a si mesmo 0x24 - Endereço não encontrado 0x25 - Rota não encontrada ...

Estado de descoberta 9 0x01 0x00 - Nenhuma sobrecarga de descoberta 0x01 - Descoberta de endereço 0x02 - Descoberta de rota 0x03 - Endereço e rota 0x40 - Tempo limite de descoberta

Checksum 0x32 0xFF subtraído pela

soma dos bytes do índice 3 até o byte anterior à este

(37)

Tabela 10: Pacote de requisição de comando AT remoto.

LSB 2 0x16

Tipo de pacote 3 0x17 Indica o tipo de pacote API (Requisição de transmissão)

Identificação que pode ser relacionada com uma resposta de acknowledge (ACK). 0X00: Nenhuma resposta configurada ID do pacote 4 0x01 Endereço do

destinatário (64-bit) MSB 5 0x00 Endereço de 64 bits dodestinatário.

6 0x13 7 0xA2 8 0x00 9 0x40 10 0xA8 11 0x3F LSB 12 0x8E Endereço de

destinatário (16-bit) MSB 13 0xFF Endereço de 16 bits dodestinatário. Endereço desconhecido ou broadcast: 0xFFFE

LSB 14 0XFE

Opções 15 0x02 Campo para habilitar

algumas opções dos comandos remotos: 0x01 - Desabilitar ACK 0x02 - Aplicar configurações (Caso não utilize esta opção, é necessário enviar um comando ’AC’ para aplicar as configurações) 0x40 - Utilizar tempo limite de transmissão extendido 0x00 - Nenhuma opção

Comando AT 16 0x4D (’M’) Caracteres ASCII do nome do comando 17 0x59 (’Y’)

Parâmetro 18 0x20 Parâmetro adicional do comando (caso se utilize)

Checksum 19 0xB8 0xFF subtraído pela soma dos bytes do índice 3 até o byte anterior à este

(38)

’0x000000000000FFFF’ para transmissão de broadcast. 2.4.4.6 Resposta de Comando AT Remoto

Como todo comando AT gera uma resposta pelo XBee que o recebeu, este também monta um pacote referente à resposta do comando AT. Este pacote possui formato semelhante ao visto na seção 2.4.4.2 (Resposta de comando AT), a diferença é que nesse caso também virá no pacote o endereço de 64-bit e de 16-bit do módulo que está enviando a resposta do comando AT.

2.4.4.7 Indicador de Amostra de In/Out

Com o módulo Xbee/Xbee-Pro ZB é possível obter amostras digitais e analógicas através de seus pinos de Entrada/Saída. O pacote de indicador de amostra é uma extensão do pacote de dados recebidos, porém ao invés de conter dados arbitrários, este pacote contém dados de amostras analógicas e digitais. O formato do pacote pode ser visto na tabela 11. Ressalta-se que apenas dispositivos em modo API podem receber essas amostras (FALUDI, 2010).

É possível configurar o XBee para enviar periodicamente amostras recebidas por seus pinos de Entrada/Saída, para tal configuração utiliza-se o comando "IR" juntamente com o número de milissegundos que serão enviadas amostras. Outra forma de obter essas amostras é configurar o módulo para monitorar os estados dos pinos, e com qualquer mudança, enviar uma amostra para um módulo XBee destino. Por último, também é possível requisitar amostras enviando o comando "IS" para um módulo (DIGI, 2009).

2.4.5 Segurança

Além dos diversos desafios a serem resolvidos em RSSF, para algumas aplicações há o problema de segurança. Algumas RSSF necessitam de confidencialidade, integridade e autenticação, porém estes requisitos podem ser algo de difícil tratamento. Por exemplo, como o canal de comunicação é público, torna-se fácil para dispositivos interceptarem estas informações (LóPEZ; ZHOU, 2008). Desta forma, a depender da aplicação, a segurança pode ser um ponto crucial de uma RSSF, em um meio que há ataques em potencial contra a rede. Muitos dos protocolos e algoritmos de tratamento de rede poderão não ser eficazes em ambientes com problemas de segurança (LIU; NING, 2007). Para ajudar com a segurança dos dados transmitidos pela rede, os módulos XBee/XBee-Pro ZB fornecem algumas

(39)

Tabela 11: Formato de indicador de amostra de In/Out.

Tamanho do pacote MSB 1 0x00 Número de bytes entre o tamanho e o Checksum LSB 2 0x14 Tipo de pacote 3 0x92 Endereço do remetente(64-bit) MSB 4 0x00 5 0x13 6 0xA2 7 0x00 8 0x40 9 0xA8 10 0x3F LSB 11 0x83 Endereço de remetente(16-bit) MSB 12 0x7D LSB 13 0x84 Opções 14 0x01 0x01 - Pacote confirmado 0x02 - Pacote proveniente de broadcast

Número de amostras 15 0x01 Número de conjunto de amostras

Máscaras de canais

digitais 16 0x00 Indicação de quaiscanais estão habilitados (caso exista)

17 0x1C

Máscaras de canais

analógicos 18 0x02 Indicação de quaiscanais estão habilitados (caso exista)

Amostras digitais 19 0x00 Caso exista canais digitais habilitados, estes bytes contém amostras dos canais habilitados

20 0x14

Amostras analógicas 21 0x02 Caso exista canais analógicos habilitados, estes bytes contém amostras A/D dos canais habilitados. As amostras são de sequência dos canais AD0/DIO0 até AD3/DIO3.

22 0x25

Checksum 23 0xB2 0xFF subtraído pela soma dos bytes do índice 3 até o byte anterior à este

(40)

providências de segurança: Criptografia AES de 128-bit; duas chaves de segurança configuráveis; central de confiança; disposição de meios para garantir integridade, confidencialidade e autenticação (DIGI, 2009). Caso a funcionalidade de segurança seja ativada no firmware do módulo XBee, estes adquiriram uma chave quando entram na rede. Assim, as transmissões de dados são criptografadas utilizando esta chave. 2.5 SENSORES

A grande evolução de sensores foi uma peça chave na viabilização para a utilização de Redes de Sensores Sem Fio. Existe uma diversa gama de sensores para traduzir informações do mundo real. Alguns exemplos são sensores de temperatura, luminosidade, distância, presença, umidade e sensores de gases. Com esses diversos tipos de sensores, é possível ter-se uma grande quantidade de aplicações em monitoramento e controle.

Conceitualmente sensores são dispositivos que permitem o interfaceamento entre os eventos físicos e o mundo eletrônico. Ou seja, sensores convertem um fenômeno físico em uma informação que pode ser "entendida" por sistemas eletrônicos (sinal elétrico) (WILSON, 2005).

É necessário observar-se algumas características importantes relacionadas aos sensores quando utilizá-los em alguma aplicação: Tipos de saída (digital ou analógica); sensibilidade (razão entre sinal de saída e sinal de entrada); variação de erros de medida; linearidade, ou seja, relação "grandeza x valor de saída do sensor"; alcance (faixa de valores que podem ser mensurados); estabilidade e velocidade de resposta (THOMAZINI; ALBUQUERQUE, 2005).

2.6 MICROCONTROLADORES

Ocorreram muitos avanços na área de microcontroladores que possibilitou também o grande avanço em sistemas embarcados. Por exemplo, pode-ser notar diversos dispositivos que usam tecnologia de microcontroladores, como aparelhos de micro ondas, máquinas de lavar e filtros de água automáticos, controles remoto e diversos outros dispositivos. Microcontroladores são como microcomputadores, porém mais adequados para controle e automação, já que possuem diversos periféricos que preenchem a necessidade de aplicações nessas áreas. Ou seja, além de uma CPU (Central Processing Unit), memória, portas de entrada/saída, os microcontroladores podem contar ainda com timers e contadores, conversores analógico-digital, portas

(41)

seriais, lógica de interrupção, circuitos oscilatórios, dentre outros (DESHMUKH, 2005). 2.6.1 Microcontroladores PIC

Uma das mais famosas famílias de microcontroladores são os PIC, fabricados pela Microchip Technology. Nesta família há vários microcontroladores disponíveis no mercado, cada um com seu potencial e custo, que podem ser adequados à diferentes tipos de aplicações. Todos os microcontroladores PIC são baseados na arquitetura de Harvard (figura 16), possuindo assim diferentes memórias para programa e para dados. Alguns PICs ainda possuem uma memória EEPROM para armazenamento não volátil de dados. Os microcontroladores PIC são do tipo RISC (Reduced Instruction Set Computer), assim possuindo um número reduzido de instruções (PALLAS-ARENY; VALDES-PEREZ, 2009).

Figura 16: Arquitetura Harvard.

Fonte: PALLAS-ARENY; VALDES-PEREZ, 2009, p.10

Microcontroladores PIC tem diversos dispositivos de entrada/saída. Fazem parte do microcontrolador: Portas paralelas, timers, portas seriais síncronas e assíncronas, conversores analógico-digital e digital-analógico, moduladores por largura de pulso (PWM), dentre outros recursos (PALLAS-ARENY; VALDES-PEREZ, 2009).

(42)

3 METODOLOGIA

O objetivo do projeto proposto é criar um framework e uma estrutura que auxilie na implementação e utilização de RSSF. Este framework é composto de um firmware e um software desenvolvidos e utilizados nos nós sensores e na estação base, respectivamente. Assim, uma de Redes de Sensores sem Fio experimental foi desenvolvida. Esta rede se baseia no padrão ZigBee e foram utilizados módulos XBee. A rede é composta por uma estação base, conectada à um computador; e estações remotas (nós sensores) que colhem os dados de sensores, realizam um pré-processamento através do microcontrolador e os enviam à estação base na qual está instalada uma aplicação em software. Pode-se visualizar o diagrama de blocos do sistema proposto na figura 17.

Figura 17: Diagrama do Sistema Proposto

Fonte: Autoria prórpia

Nesta seção serão apresentados os materiais utilizados no desenvolvimento no projeto, bem como a metodologia empregada.

3.1 MÓDULO XBEE

Para o projeto da RSSF utilizou-se o módulo XBee ZB low power - Antena wire (figura 18), da Digi. Este módulo é ideal para aplicações em que o consumo de energia seja um fator crítico de projeto.

O XBee ZB opera com uma frequência de transmissão de 2,4 GHz, potência de transmissão normal de 1,25 mW e alcance máximo de 120 metros, variando de acordo com o ambiente. As demais características podem ser vistas na tabela 12.

O módulo XBee possui vinte pinos (Figura 19). Dentre estes, os principais para um funcionamento básico do módulo são: o pino de alimentação (Vcc), o comum (GND), o Dout e Din que são pinos de saída e entrada de dados, respectivamente,

(43)

Figura 18: Módulo XBee ZBlow power - wire.

Fonte: Autoria prórpia

Tabela 12: Características do módulo XBee ZBlow power - wire.

Frequência de transmissão 2,4GHz

Potência de transmissão

1,25mW

Alcance Máximo

120m

Corrente em modo Sleep

menor que 1 uA (25

o

C)

Taxa de dados

250 Kbps

Segurança

128-bit AES

Antena

wire

Alimentação

2.1 - 3.6VDC (usual de 3,3VDC)

Fonte: (DIGI, 2009)

através do módulo UART. Os demais pinos possuem mais de uma função, podendo ser configurados através de comandos AT. As funções exercidas por cada pino pode ser vista na tabela 13.

Figura 19: Pinos do módulo XBee ZBlow power.

(44)

Tabela 13: Funções dos pinos do módulo XBee ZBlow power.

Pino

Função

1 Alimentação (3,3V)

2 Saída UART

3 Entrada UART

4 Entrada - Saída digital 12

5 Reset

6 Saída PWM - Indicador de força do sina - entrada/saída digital 10

7 Entrada/saída digital 11

8 Reservado (não se pode conectar)

9 Controle do modo sleep - entrada/saída digital 8

10 Comum (GND)

11 Entrada/saída digital 4

12 Clear-to-send

13 Indicador de estado do módulo - entrada/saída digital 9

14 Não utilizado nesse dispositivo

15 Indicador de associação - entrada/saída digital 5

16 request-to-send Flow Control - entrada/saída digital 6

17 Entrada/saída digital ou analógica 3

18 Entrada/saída digital ou analógica 2

19 Entrada/saída digital ou analógica 1

20 Entrada/saída digital ou analógica 0

Fonte: (DIGI, 2009)

3.1.1 Adaptador para Protoboard

Como o projeto das estações remotas foram montados em protoboards e não há compatibilidade de conexão entre os pinos do dispositivo XBee e a protoboard. Assim, foi necessário o uso de um adaptador, que pode ser visto na figura 20.

Figura 20: Placa de prototipação para XBee e protoboard.

(45)

3.2 NÓS SENSORES

Os nós sensores (estações remotas) são aqueles que coletam dados de sensores e os enviam para a estação base por um intervalo de tempo pré-configurado, ou quando a estação coordenadora requisita dados. Os sensores acoplados nesta estação realizam mensurações de temperatura e luminosidade, sendo estes o LM35 e o LDR. Além destes sensores, também fizeram parte da estação remota: um microcontrolador PIC16F877A (futuramente substituído pelo PIC18F4550), o dispositivo XBee ZB, bateria e um regulador de tensão (3,3V). O esquema da estação remota pode ser visto na figura 21.

Figura 21: Diagrama de um nó sensor.

Inicialmente, o microcontrolador escolhido para compor o nó sensor foi o PIC16F877A, já que se trata de um dispositivo de relativo baixo custo e que possui as características e funcionalidades necessárias à este projeto. Porém, ao decorrer do desenvolvimento do sistema, a memória de programa deste microcontrolador não foi suficiente, assim houve a substituição para o PIC18F4550.

3.2.1 Sensor de Temperatura LM35

Para realizar as mensurações de temperatura utilizou-se o sensor LM35DZ (figura 22), fabricado pela National Semiconductor. Este sensor é de fácil uso pois não necessita de nenhuma calibração e possui tensão de saída linear com a temperatura. O LM35 já vem calibrado em graus Celsius, em que sua saída é dada em 10mV/oC. Pode ser utilizado de duas formas, com máxima extensão de mensuração de temperatura, que cobre de -55o_{C até 150}o_{C, assim sendo montado com}

(46)

Figura 22: Sensor de temperatura LM35 DZ.

alimentação simétrica (de 4V à 30V) como na figura 23. Alternativamente à esse modo de utilização, o LM35 pode ser utilizado com sua montagem básica, com alimentação simples (de 4V à 30V) (figura 24), assim a janela de mensuração cobre de 2o_{C à} 150o_C.

Figura 23: LM35 - Alimentação simétrica.

Fonte: www.ti.com/lit/ds/symlink/lm35.pdf

Figura 24: LM35 - Alimentação simples.

O LM35 é produzido em 4 tipos de encapsulamentos diferentes, como pode ser visto na figura 25. Esta variedade de encapsulamentos é necessária pois pode se adequar a forma e o material do dispositivo ao tipo de projeto.

(47)

Figura 25: Encapsulamentos do LM35: a) Metálico; b) Plástico; c) 8 conectores; d) plástico.

3.2.2 Sensor de Luminosidade LDR

Para a mensuração da luminosidade foi utilizado um LDR (figura 26) (Light Dependent Resistor, em português Resistor Dependente de Luz). Este sensor é um resistor que varia seu valor de resistência a partir da intensidade de luz incidente no mesmo.

Figura 26: LDR

A resistência varia para mais quanto menos luz incidir no LDR (na escuridão chega a Mega Ohms), e para menos quanto mais luz incidir no LDR (luz muito intensa chega a dezenas de Ohms). Como é mais fácil utilizar a tensão como informação, o LDR é comumente utilizado em um circuito divisor de tensão. As tabelas 14 e 15 mostram referenciais de intensidade luminosa e as características elétricas do LDR em relação à luminosidade, respectivamente.

(48)

Tabela 14: Referências de luminosidade. Fonte de Luz Iluminação (lux)

Sob o luar 0.1 Lâmpada de 60W à 1 metro 50 Luz Fluorescente 500 Luz do sol 300000 Fonte: www.biltek.tubitak.gov.tr/gelisim/elektronik/dosyalar/40/LDR_NSL19_M51.pdf Tabela 15: Características elétricas do LDR em relação à luz.

Parâmetro Condições (lux) Valores Típicos Unidade

Resistência em luz 1000 400 Ohms

Resistência em luz 10 9 KOhms

Resistência em escuridão 0.1 1 MOhms

Fonte:

www.biltek.tubitak.gov.tr/gelisim/elektronik/dosyalar/40/LDR_NSL19_M51.pdf

3.2.3 Microcontrolador PIC16F877A

O PIC16F877A (figura 27) é um microcontrolador com 40 pinos com memória de programa de 8Kbits, memória de dados de 368bytes, memória de dados EEPROM de 256bytes. Este dispositivo possui um total de 33 portas de entrada/saída, divididas em 5 conjuntos (A, B, C, D, E); três Timers (um de 16 bits e dois de 8 bits); dois comparadores analógicos; conversor AD de 10 bits de resolução com 8 canais de entrada; módulo de comunicação serial USART; e dentre outros periféricos. No nó sensor o microcontrolador é destinado a coletar os dados dos sensores e tratá-los para envio pela UART para o XBee.

Figura 27: Microcontrolador PIC16F877A

(49)

3.2.4 Microcontrolador PIC18F4550

O PIC18F4550 é um microcontrolador que possui 32Kbytes de memória de programa, 2Kbytes de memória SRAM (Static Random Access Memory) para armazenamento de dados. Há 35 portas de entrada/saída digitais, 13 canais de entrada analógicas e conversor AD de 10 bits. O PIC18F4550 possui ainda módulo CCP (Capture / Compare / PWM), 4 temporizadores, 2 comparadores e periféricos de comunicação serial (USB 2.0), além de implementar vários outros protocolos de comunicação: EUSART, SPI e I2C.

3.3 ESTAÇÃO BASE

A estação base é responsável por receber os dados coletados pelos nós sensores, e realizar a manutenção da rede. Esta estação é composta por um XBee, um adaptador USB para o XBee, um notebook com um software para controle da rede. O adaptador utilizado para conectar o XBee ao notebook é o CON-USBEE XPlus, da fabricante Rogercom (figura 28). Assim, os dados recebidos pelo XBee são serialmente transmitidos para o notebook que contém o software de controle da RSSF. Este adaptador contém um chip conversor USB/Serial; regulador de tensão LDO; LEDs indicadores de intensidade de sinal RF, transmissão e recepção e de módulo associado à uma rede; e um botão reset.

Figura 28: Adaptador CON-USBEE XPlus

Assim, a estação base conta com um software que permite receber leituras dos nós sensores, requisitar leituras, verificar quais nós estão associados, e realizar manutenção geral da rede. O dispositivo XBee dessa estação foi configurado em modo API, já que há necessidade de envio de informações para diversos nós da rede, de configuração dos nós sensores da rede; e conhecimento dos remetentes dos dados recebidos.

(50)

3.3.1 Software

Como mencionado anteriormente nesta seção, o software utilizado no projeto tem como função realizar a interface entre o usuário final, o XBee coordenador e os nós sensores da rede. Assim, este programa é responsável por receber todos os dados provenientes dos dispositivos da RSSF, apresentá-lo ao usuário; e também permitir que este usuário controle a rede. Para a construção deste software utilizou-se a linguagem JAVA, por ser uma tecnologia livre de custos, possui vasta e organizada documentação e é portátil, ou seja, pode ser executada em diversas plataformas com a mesma eficácia. Para desenvolver o código utilizou-se o ambiente Eclipse IDE, fornece ferramentas que agilizam e facilitam o desenvolvimento do software.

3.3.1.1 Biblioteca XBee - API

Os nós da RSSF enviam pacotes para o XBee coordenador que via RS-232 transmite esses pacotes que serão "capturados" pelo software de controle. Para fazer essa captura desses dados, utilizou-se duas bibliotecas desenvolvidas em JAVA, a XBee-API (https://code.google.com/p/xbee-api/) e a RX-TX (http://rxtx.qbang.org/). A primeira é uma biblioteca de interfaceamento com o dispositivo XBee, e a segunda biblioteca fornece ferramentas de comunicação serial e paralela. A XBee-API é construída utilizando-se da RX-TX. A biblioteca XBee-API destina-se à comunicação de dispositivos XBee da série 1 e série 2, para estes dispositivos configurados em modo API. Assim, esta biblioteca fornece métodos para montagem de pacotes no formato correto para cada um (comandos AT, requisição de transmissão e os demais). Também fornece métodos para envio e recebimento de pacotes. Na figura 29 é possível visualizar um esquema geral da interação entre rede e software no envio de pacotes, e na figura 30 o recebimento de pacotes.

3.4 X-CTU

Os dispositivos XBee necessitam de uma pré-configuração que foi realizada através do software da Digi chamado X-CTU. Com este dispositivo é possível ler e escrever os parâmetros de configuração dos dispositivos XBee, também enviar comandos AT, caracteres e/ou pacotes através de um terminal. Na figura 31 é mostrada a tela de configuração do módulo XBee, na qual é possível atribuir tipo de dispositivo (Coordenador, roteador ou dispositivo final), PAN ID (identificação da rede), endereço MY (análogo ao endereço IP), endereço de destino (para dispositivos

(51)

Figura 29: Esquema do software no envio de pacotes

em modo transparente), dentre outros parâmetros. Também é possível atribuir funções às diversas portas de entrada/saída do dispositivo (figura 32).

O X-CTU também oferece um terminal para que se possa "conversar" com o dispositivo XBee. Pode-se enviar caracteres aleatórios e enviar comandos AT (por caracteres quando em modo transparente). Na figura 32 visualiza-se comandos AT enviados para o dispositivo XBee através do terminal do X-CTU.

(52)

Figura 30: Esquema do software no recebimento de pacotes

(53)

Figura 31: Tela de configuração do módulo XBee

(54)

Figura 32: Tela de configuração dos pinos de entrada/saída do módulo XBee

Figura 33: Uso do terminal do X-CTU para envio de comandos AT: Comandos enviados em azul e respostas do XBee em vermelho