Software utilizado

4.2.2.1 Protocolos de roteamento

A rede experimental incorpora o protocolo XMesh (XMESH, 2010) em seus nós. Este protocolo, baseado nas especificações do padrão ZigBee, permite que as redes sejam auto-organizáveis, multi-hop e ad hoc19_{. Uma rede XMesh é constituída}

por nós (mote20 _{e placa sensora), os quais coletam dados e os encaminham por}

meio da rede até chegar na estação base, conhecida também como gateway, dispositivo que permite transmitir os dados coletados pelos nós ao computador. Na Figura 14 é mostrada uma rede XMesh.

Figura 14 - Diagrama de uma rede XMesh. Extraído de Willow Technologies (2010).

19 Uma rede é ad hoc quando não depende de uma infraestrutura prévia (roteadores) para o seu funcionamento.

20 A Universidade de Berkeley denomina mote a suas plataformas desenvolvidas, constituídas pelos módulos de rádio e processamento (mote MICAz, por exemplo).

A seguir são detalhadas as características de operação do protocolo XMesh (XMESH, 2010):

 possibilidade de implementar diferentes topologias: estrela, malha e híbrida

(estrela – malha);

 opção de operação em modo Low Power para estender o tempo de vida dos

nós;

 tempo de sincronização da rede de +/- 1 ms;

 roteamento em ambos sentidos (desde a rede até a estação base e em

sentido contrário);

 capacidade TrueMesh, a qual se refere à habilidade dos nós em procurar,

dinamicamente, novas rotas para encaminhar seus dados, permitindo assim, que a rede seja tolerante a falhas.

Uma rede XMesh pode ser configurada nos seguintes modos de operação:

High Power (HP):

 capacidade TrueMesh;

 cada nó na rede é um roteador;  alta largura de banda, baixa latência;

 rádios dos nós permanecem sempre ligados.

Low Power (LP):

 capacidade TrueMesh;

 cada nó na rede é um roteador;

 baixa largura de banda, alta latência, sendo ideal para aplicações de

monitoramento ambiental;

 os módulos de rádio normalmente permanecem no estado sleep21, mudando

ao estado wake-up periodicamente para a avaliação do tráfego no canal de comunicação (8 vezes por s);

 o intervalo de amostragem é de 3 min (default), porém eles podem ser

reprogramados para diferentes intervalos de amostragem.

4.2.2.2 Software para gerenciamento dos dados

Os dados, coletados pelos nós da RSSF, são armazenados em um banco de dados PostgreSQL (POSTGRESQL, 2010) por meio do software MoteView 2.0F, fornecido pela MEMSIC. Este software permite visualizar esses dados na tela do computador (seja em forma de tabelas numéricas ou gráficos estatísticos) e exportá- los em diferentes formatos para sua análise posterior (xml, sql, cvs), existindo também a possibilidade de visualizar os dados de desempenho da rede e a sua topologia (MOTEVIEW, 2010). Nas Figuras 15, 16, 17 e 18 apresentam-se exemplos de telas do software MoteView 2.0F.

Figura 16 - Tela para visualizar os dados coletados pelos nós em forma de gráfico.

Figura 18 - Tela para visualizar a topologia da rede.

4.2.2.3 Ambiente para programação dos nós

No ambiente de trabalho foi instalado o sistema operacional TinyOS 1.1.14 (TINYOS, 2010), por sua compatibilidade com os nós utilizados (plataforma MICAz e placa sensora MTS400/MTS420), de forma a se avaliar o aplicativo a ser usado nos experimentos relacionados à avaliação da qualidade do enlace.

O TinyOS (TINYOS, 2010) é um sistema operacional de código aberto, desenvolvido especialmente para ser utilizado nos nós em função dos seus recursos limitados (memória, capacidade de processamento, etc.). O TinyOS está escrito com base na linguagem de programação NesC (NESC, 2010), uma extensão da linguagem C. A arquitetura do TinyOS é baseada em componentes, as bibliotecas que ele incorpora incluem protocolos de rede, serviços distribuídos, controladores para sensores e ferramentas para aquisição de dados, que podem ser utilizadas em uma aplicação customizada.

Para a programação dos nós nos diferentes modos de operação, High Power (HP) ou Low Power (LP), bem como para a instalação do aplicativo que permita a coleta dos dados ambientais utilizou-se o software MoteWorksTM

ambiente de desenvolvimento de aplicações para RSSFs, fornecido pela MEMSIC (MOTEWORKS, 2010). Tanto o TinyOS 1.1.14 como o MoteWorksTM _foram

acessados por meio do Cygwin, que emula um ambiente Linux no sistema operacional Windows (CYGWIN, 2010). Na Figura 19 é mostrada a estrutura de diretórios do TinyOS 1.X.

Figura 19 - Estrutura de diretórios do TinyOS 1.X. Baseado em Moteworks (2010).

4.2.2.4 Aplicativo utilizado para realizar a coleta dos dados ambientais

A MEMSIC disponibiliza diferentes tipos de aplicativos para o funcionamento dos nós, dependendo da placa sensora a ser utilizada. Esses aplicativos, desenvolvidos em NesC (NESC, 2010), fazem parte do MoteWorksTM

; para o caso da placa MTS400/MTS420 é utilizado o XMTS400, o qual pode ser programado nos modos HP ou LP, já explicados no item 4.2.2.1.

Na Figura 20, gerada a partir do aplicativo XMTS400 utilizando o comando “make micaz docs” no shell do cygwin, descrevem-se os componentes que fazem parte do XMTS400: o programa principal (módulo e configuração), o GenericCommPromiscuous (para envio e recepção de pacotes), os controladores para os sensores da placa MTS400, o protocolo de roteamento XMesh, os recursos

(timer, leds e buffer), o XCommand (para envio de comandos da estação base para os nós) e o conversor analógico digital. Este aplicativo pode ser modificado para coletar somente as variáveis necessárias, dependendo da aplicação a ser implementada, modificações que permitirão economizar espaço para o armazenamento dos dados, além de um menor consumo de energia por ser enviado um pacote de dados menor.

4.2.2.5 Aplicativo utilizado para avaliar a qualidade do enlace entre o nó e a estação base

O sistema operacional TinyOS 1.1.14 disponibiliza um aplicativo para avaliar a qualidade do enlace entre um nó e a estação base, que é o Pong (PONG, 2010). Este aplicativo foi desenvolvido em NesC e permite a coleta de dois tipos de dados: o indicador de intensidade de sinal recebida (RSSI) e o indicador de qualidade de enlace (LQI). Na Figura 21 apresenta-se o diagrama de componentes do Pong, gerado utilizando o comando “make micaz docs” no shell do Cygwin, dentro desses componentes podem ser citados: o programa principal (módulo e configuração), os recursos (timer e leds) e o GenericComm (para envio e recepção dos pacotes de dados).

Figura 21 - Diagrama de componentes do aplicativo Pong.

Na Figura 22 é mostrada a interface do aplicativo Pong, na qual visualizam- se os dados de RSSI e LQI de ambos os dispositivos que participam na comunicação (nó fonte e destino); para isso, é necessário instalar o aplicativo em um nó sensor e na estação base. Para a visualização dos valores de RSSI e LQI é utilizada uma ferramenta desenvolvida em Java que vem junto com o aplicativo, acessada por meio do comando “java PingPong” no shell do Cygwin.

Figura 22 - Interface do aplicativo Pong.