Sensor Network for Animal Husbandry

Aplicações para Sistemas Embebidos 2013/2014

Telma Fernandes, 70490

Tiago Francisco, 70635

Abstract Após a experiência com a aplicação TinyOS, adquirida através do uso do TOSSIM nas aulas de

laboratório, foi-nos proposto o design de uma rede de sensores para monitorização de animais.

Cada animal será representado por um node, que contém um sistema embebido, na forma de

colar, constituído por vários módulos. O protocolo de rede desenvolvido consiste em 3 fases, a

fase de descoberta, funcionamento normal e actualização.

O protocolo faz ainda uso de mecanismos semelhantes a cache para evitar enviar mensagens

desnecessárias e manter a replicação dos dados. Em relação ao hardware escolhido, uma das

principais considerações foi o consumo energético do mesmo, de modo a maximizar o tempo

de uso do sistema.

Introdução Os desafios crescentes na área agrícola moderna advêm da necessidade de monitorizar grandes

quantidades de animais, possuindo estes liberdade de movimentação.

Para lidar com este tipo de cenário podemos destacar as soluções associadas a redes de sensores

sem fios. Estas soluções têm bastantes vantagens, mas por outro lado também estão associadas

a desafios, mais concretamente a nível de comunicação e energia. A nossa solução tenta superar

estes desafios, tirando o máximo de partido da tecnologia.

Arquitectura A arquitectura do nosso sistema consiste num módulo GPS, que se limita apenas a detectar a

posição actual do animal, um módulo RFID que permite que o feeding spot se aperceba que o

animal se aproximou e saiba a quantidade de comida que deve fornecer, um módulo de Radio

Frequency, que permite que os animais comuniquem entre si de modo a que possam saber as

informações que necessitem para eventuais pedidos do cliente e ainda por um memória,

responsável pelo processamento e gestão/alojamento temporário de informação.

Deste modo, é possível guardar informações relevantes para o processamento do protocolo,

como por exemplo, nodes adjacentes de modo a minimizar o número de pacotes enviados (para

não ser preciso efectuar um broadcast sempre que o node queira enviar alguma informação).

A figura abaixo ilustra todos os módulos, componentes e respectivas ligações usados na

arquitectura da nossa solução.

O ficheiro de configuração geral é o SensorMoteAppC. Tal como podemos observar na figura, é

aí que estão definidos todos os componentes que vão ser usados e as ligações entre os vários

módulos da nossa arquitectura. Os componentes são os seguintes: MainC,

GPSCoordinateSensorC (modulo de GPS), RadioFrequencySensorC (modulo de

RadioFrequência), MemoryC (modulo de memória), TimerMilliC (as Timer), ActiveMessageC,

AMSenderC, AMReceiverC e RFIDSensorC (módulo de RFID). Comecemos por analisar o modulo

de GPS. Este módulo usa a interface Receive e fornece a interface GPSCoordinateSensor. Deste

modo, os módulos que usem a interface GPSCoordinateSensor têm acesso aos comandos que o

mesmo implementa na interface.

No nosso caso estes comandos servem para aceder às coordenadas actuais, ou seja, é o meio

do modulo de GPS comunicar as coordenadas a outros módulos do sistema do node em questão.

Adicionalmente existe ainda um comando que permite que sejam feitas chamadas ao módulo

GPS para que este actualize as coordenadas, mas este só tem sentido no âmbito da simulação,

visto que numa situação real o GPS só por si actualizava a posição automaticamente. Quanto ao

uso da interface Receive, é utilizada para que o módulo GPS seja injectado com posições

aleatórias quando o sistema arranca. Dentro de cada cluster é definido um limite para este valor

random, para que as posições dentro do cluster não difiram muito. Este Receive é ligado no

ficheiro SensorMoteAppC ao componente AMReceiverC. Quanto ao módulo de RFID, este é

bastante simples e as interfaces usadas são meramente simulatórias. Isto porque numa situação

real, a interacção do módulo RFID com o resto do sistema é praticamente nula. Este limita-se a

ser detectado pelo feedingSpot, e a comida é disponibilizada.

De modo a mantermos o sistema coerente, permitimos que o módulo de RFID fornecesse a

interface que nos permite mandar o animal comer, que usasse a interface

RadioFrequencySensor do módulo de radio, para chamar o comando que propaga os updates

da quantidade de comida restante num determinado feeding spot, e ainda que usasse a

interface Memory do módulo de memória de modo a que se actualize a quantidade de comida

que comeu / restante nos feeding spots. A interface Receive deste módulo também é ligada ao

AMReceiverC.

Quanto ao modulo de rádio, usa as interfaces Boot (fornecida pelo MainC), SplitControl

(fornecido pelo ActiveMessageC), Packet (fornecida pelo AMSenderC), AMPacket (fornecida

pelo AMSenderC), Receive (fornecida pelo AMReceiverC), GPSCoordinateSensor (fornecida pelo

modulo de GPS), Memory (fornecida pelo modulo de memória), AMSend (fornecida pelo

AMSenderC), PacketAcknowledgements (fornecida pelo AMSenderC) e Timer<TMilli> (fornecida

pelo Timer). Fornece ainda a interface RadioFrequencySensor, que permite que outros módulos

façam chamadas de modo a propagar informação sobre a quantidade de comida ingerida pelo

animal e restante no feeding spot. É neste módulo que está definido o protocolo de comunicação

e que são analisados os vários tipos de mensagens recebidas através de métodos da interface

Receive. Duas das interfaces mais significativas deste módulo são o AMSend e a

PacketAcknowledgements que permitem controlar se a mensagem foi entregue ou não, através

dos métodos requestAck, wasAcked e sendDone. Por último temos o módulo de Memória. Este

módulo não usa nenhuma interface, apenas fornece a interface Memory. Isto deve-se ao facto

da memória não necessitar de nenhum dos outros módulos, a sua função é apenas permitir que

os módulos consigam aceder aos seus próprios dados. Possui comandos de acesso e actualização

de dados relativos, por exemplo, aos nodes adjacentes, aos nodes sobre os quais o node em

questão guardou informação, à quantidade de comida ingerida pelo animal e à quantidade de

comida restante nos vários feeding spots.

Note-se que no mapeamento para o hardware, não vai existir nenhum modulo de memória mas

sim um microcontrolador, que já trás memória incluída. A memória foi uma abstracção para

facilitar a leitura do código, visto que é a esse módulo que cada node acede sempre que quer

informações que guardou posteriormente.

Protocolo Quando o utilizador se aproxima de um node com o seu laptop e pede informação de um dado

node, o protocolo opera de acordo com as seguintes três fases:

Fase de Descoberta: Nesta fase, nenhum dos nodes conhece a topologia da rede. Analogamente poderia pensar-se

que o sistema estaria a ser ligado pela primeira vez. Quando o node que recebe o request

proveniente do gestor, verifica que realmente é o primeiro request que recebe, limita-se apenas

a emitir em broadcast a sua informação (juntamente com o identificador do node sobre o qual

o gestor quer informações) de modo a dar-se a conhecer aos seus vizinhos e propagar o pedido

ao mesmo tempo. Estes, em resposta, enviam também em broadcast a sua informação de modo

a que, quando todos os nodes tiverem feito broadcast, cada um fique a saber o(s) seu(s)

vizinho(s). Adicionalmente, é ainda passado um valor que representa a hierarquia do node, valor

esse que vai sendo incrementado à medida que as mensagens são transmitidas. Inicialmente o

valor de hierarquia dos nodes é 0.

Quando um node recebe um request do gestor (pela primeira vez), o pedido que vai transmitir

aos outros nodes vai já ter valor hierárquico 1. Á medida que os nodes recebem estas mensagens

de descoberta de rede em broadcast comparam o seu valor de hierarquia com o que vem no

pedido e caso o valor que vem no pedido seja maior que o seu, ficam com esse valor de

hierarquia. Quando, por sua vez, forem enviar o broadcast (mecanismo de descoberta descrito

imediatamente acima) incrementam o valor hierárquico da mensagem que vai ser transmitida

em relação ao seu valor hierárquico. Deste modo, à medida que os pedidos em broadcast se vão

propagando pelo cluster, o nível de hierarquia vai aumentado conforme a distância (medida em

hops) ao pc do gestor.

Deste modo, cada node tem uma noção da topologia, ou mais concretamente, quem está perto

de si para receber e enviar mensagens. Neste exemplo o node 1 tem informação do 2 e do 3, o

node 2 tem informação do 1 e do 3, o node 3 tem informação do 1, 2, 4 e do 5, o node 4 tem

informação do 3 e do 5 e o node 5 tem informação do 4 e do 3.

A figura abaixo mostra a ordem cronológica de mensagens que são trocadas numa versão

simplificada de uma solução durante esta fase de descoberta:

Fase de Funcionamento Normal: Após o conhecimento da topologia da rede e após algum node ter reconhecido que um dado

pedido realmente é direccionado a ele próprio (pela comparação do id que vem no pedido e o

id do próprio node, ou seja, cada node tem noção do seu próprio id) então a mensagem de

resposta é enviada para trás até ao node que desencadeou toda a troca de mensagens. A

maneira de isto ser feito com o menor número de troca de mensagens possível é devido a um

valor, que chamamos de nível de hierarquia, que é passado nas mensagens de broadcast. Um

node, na fase de resposta, após receber uma mensagem encaminha-a para o node com o nível

de hierarquia acima do seu em unicast Isto vai acontecendo até a resposta chegar ao node que

desencadeou o pedido, neste caso o node contactado pelo gestor. Como o node que

desencadeou o pedido é o que tem o nível de hierarquia mais baixo, a mensagem quando chegar

lá já não vai ser mais retransmitida, porque já chegou ao destino. Durante esta troca de

mensagens em unicast é usado o mecanismo de acknowledgment de modo a garantir que o

node com quem estamos a tentar comunicar, efectivamente recebeu a mensagem.

À medida que os nodes retransmitem a resposta até ao node que desencadeou o pedido, vão

guardando essa informação (caso tenham espaço, porque cada animal guarda no máximo

informação sobre 100 animais. Este valor foi tido em conta devido ao hardware usado,

especificado mais à frente). Deste modo, caso o pedido seja repetido, a resposta é devolvida

quase instantaneamente pelo ultimo node que guardou essa informação. Este mecanismo

comporta-se de certa forma como uma cache e permite poupar mensagens, tornando o sistema

mais eficiente. Além disso permite que exista replicação dos dados, para caso algum node falhe

temporariamente.

Pegando no exemplo da figura anterior e assumindo que o node pedido é o node 5, após a fase

de descoberta, quando o node 4 recebe a informação do 5 propaga a mensagem para trás como

resposta até chegar ao node que iniciou o pedido. A seguinte figura ilustra o caminho que essa

resposta efectuaria até ao node de origem:

De notar que o node 4 soube qual o caminho mais rápido para chegar ao node no topo da

hierarquia, uma vez que se limitou a enviar a resposta ao node com o valor de hierarquia menor

que o seu. Esse node por sua vez envia ao node com valor de hierarquia menor que o seu e por

ai adiante até a resposta chegar ao node com hierarquia 1, que representa o topo da hierarquia.

Note-se que o topo da hierarquia tem o valor hierárquico mais baixo, que é 1, logo, à medida

que se sobe na hierarquia (em direcção ao topo), os valores hierárquicos vão diminuindo.

O objectivo desta abordagem é concentrar a informação pedida o mais alto possível na nossa

árvore de hierarquia e por consequente fazer com que a informação chegue ao node com nível

1 (ou seja, o que recebe directamente o pedido do utilizador).

Caso o gestor faça pedidos a seguir ao pedido inicial, como a topologia já é conhecida, os nodes

tentam primeiro relacionar o pedido com os nodes que conhecem ou sobre os quais tenham

informação e se isto não for possível, o pedido é enviado em broadcast para níveis de valor

hierárquico maior. Quando o pedido chegar a um node que tenha informações sobre o node

que o gestor pretende ou a um dos adjacentes desse node, a resposta é transmitida em unicast

(neste caso, vai no sentido inverso ao pedido e portanto passa por níveis de hierárquica cada

vez menores até chegar ao node a que o gestor fez o pedido).

Este comportamento acontece apenas quando o nó requisitado é desconhecido ou está distante

da área de aglomeração de informação próxima do gestor. Após isto acontecer, e tal como já foi

referido, a informação requisitada anteriormente fica guardada ao longo dos nodes que servem

de caminho às respostas. Isto permite que o sistema tenha um desempenho cada vez melhor ao

longo da sua utilização, pois o mecanismo de cache vai sendo cada vez mais eficiente.

Fase de Actualização Durante esta fase, quando um animal come de um feeding spot (que estamos a considerar ser

aleatório) envia uma mensagem de broadcast a todos os seus nodes adjacentes. Estes após a

recepção da mensagem fazem o mesmo. Quando um node recebe a mensagem de actualização

e verifica que os valores que ela contém já correspondem à informação que tem então esse

node pára a propagação da actualização. Deste modo evitamos que a propagação entre em loop

infinito. Optámos por enviar logo em broadcast porque queremos que todos os nodes saibam

da alteração o mais rapidamente possível e porque esta fase pode acontecer numa altura em

que a topologia possa já ter sido alterado.

Existe um pequeno tradeoff nesta abordagem uma vez que estamos a gastar imenso ao enviar

as mensagens em broadcast, em contrapartida garantimos que todos os nós são actualizados

quase em tempo real e como no caso do projecto podem existir no mínimo 10 000 nodes que

representam os animais, não podemos gastar tempo com mensagens em unicast para todos os

nodes adjacentes (conhecidos) que possivelmente iriam estar sempre a perder-se e teríamos

que voltar sempre a retransmiti-las, acabando por se obter um resultar com um consumo

energético pior que esta abordagem em broadcast.

Além do que foi referido anteriormente, de 500 em 500 ticks fazemos uma redescoberta

da topologia da rede, de modo a que, caso o gestor ainda esteja perto de algum node e faça

algum pedido, esse node vai novamente mandar mensagens em broadcast, isto é, a fase de

descoberta é feita novamente. Neste caso, como não é a primeira vez que se está a fazer o

reconhecimento, todas as mensagens que um node receba durante esta fase, caso

correspondam a informações de nodes que ele já sabia, em vez de adicionar de novo irá

actualizar. Assim, mesmo que um animal se afaste do cluster, a ultima posição conhecida dentro

do cluster em questão é conhecida pelo nó que lhe estava adjacente, embora não tenha sido

actualizada devido ao facto do próprio animal se ter afastado e portanto, quando o mesmo fez

broadcast para conhecer a rede essa informação não chegou aos seus antigos adjacentes.

Optámos por esta abordagem porque assumimos que os animais estão em constante

movimento, de modo que achámos uma má prática propagar as notificações sempre que se

moviam.

O movimento foi implementado nos animais de modo pseudo-aleatório, ou seja, eles movem-

se de 100 e 100 ticks. Deste modo, permitimos que os animais andem durante algum tempo e

depois sim, actualizamos a topologia bem como o estado que tínhamos anteriormente dos

nodes conhecidos. Este tempo de actualização pode ser configurável do modo mais flexível

possível, por exemplo, se o gestor fizer os requests durante a noite, período em que os animais

estão mais inactivos, o tempo entre mensagens broadcast de redescoberta da rede pode ser

maximizado. O sistema, se não detectar actividade durante algum tempo, entra em modo de

inactividade, de modo a poupar o máximo de energia possível. Isto evita que, por exemplo,

estejam a ser trocadas mensagens um dia inteiro, sem o gestor ir lá.

Hardware MÓDULO RFID: Uma das componentes do sistema embebido é o módulo RFID. Este módulo não

tem inteligência propriamente dita, apenas permite que o feeding spot detecte o animal caso

este se aproxime do local próprio para comer. Deste modo, de acordo com o que foi dito agora

e com os requisitos deste projecto optámos por usar o módulo RI-INL-W9QM-30 da Texas

Instruments, que cumpre os requisitos e é bastante simples. É um módulo de forma circular e

está de acordo com as normas ISO/IEC 11784/11785, pelo que se adapta bastante bem ao

contexto do problema. Opera na gama de frequência de 134.2kHz e não necessita de qualquer

tipo de bateria, sendo fornecida energia durante o processo de leitura/detecção do animal à

chegada ao feeding spot (batteryless). Esta característica é uma mais-valia, na medida em que

não existe a preocupação de trocar baterias de X em X tempo.

O intervalo de temperaturas suportado para o bom funcionamento deste módulo vai desde -

25ºC a 70ºC, o que em princípio não vai ser afectado com factores ambientais, porque

assumimos que os animais não estão em condições muito hostis.

Quanto à memória, os 80bit deste módulo correspondem a um dos valores mais baixos

disponíveis em mercado para este tipo de módulo. Acaba por ser benéfico porque queremos

minimizar o desperdício de recursos e 80bit é suficiente para conter o ID do animal e a

quantidade de comida que o mesmo pode comer. Dado que o feeding spot não tem memória,

são os próprios animais que contêm a informação da quantidade que podem comer e esse valor

pode sofrer alterações, daí termos escolhido um módulo com características read/write.

Após o animal comer, actualiza a sua informação sobre a quantidade de alimento que ficou

disponível no feeding spot e propaga essa informação aos outros animais. Esta informação não

está guardada neste módulo, mas sim na memória, descrita mais à frente. O preço deste RFID

tag é de aproximadamente 1.80€. A figura abaixo (adaptada do datasheet do vendedor) contém

as especificações técnicas deste módulo, parte das quais já foram descritas acima.

MÓDULO GPS: Outra das componentes deste sistema embebido é o módulo GPS. Optámos pelo

FGPMMOPA6H da GlobalTop. Este pequeno módulo (16mm x 16mm x 5mm e 4 gramas) oferece

alta sensibilidade (-165 dBm), inclui uma antena embutida e permite ter até 10 updates de

posição por segundo (10 Hz). No contexto do nosso problema não há necessidade de manter

esta taxa ao máximo, sendo neste caso vantajoso operar a 1Hz ou pouco mais, mantendo o

compromisso gasto de energia/fidelidade da informação. Isto porque não existem grandes

restrições à posição exacta dos animais e os mesmos não se movem a grandes velocidades, não

necessitando assim de tantos updates por segundo. A diferença de potencial suportada em

operação é entre 3.0 e 4.3 V, sendo 3.3 V o valor recomendado Quanto ao consumo, temos

25mA na aquisição e 20mA durante o tracking. Estes valores foram tidos em conta durante a

escolha do módulo, de modo a maximizar o intervalo de tempo entre troca de baterias. Uma

das features deste módulo é a sua função de previsão de rotas. Quando o módulo obtém sinal,

está apto para prever as informações de órbita, no máximo até três dias, isto é, se por alguma

razão o módulo não conseguir obter sinal num instante de tempo, o gestor consegue à mesma

obter essa informação.

Dado que o gasto de energia é uma das principais preocupações num sistema embebido,

tivémos ainda em consideração outra feature importante deste modulo. Além das indicações

técnicas indicarem que o módulo já gasta muito pouco, o algoritmo é ainda adaptável para as

mais diversas necessidades, tendo como consequência diferentes níveis de gastos

energéticos. O gráfico abaixo mostra diferentes actividades, que podem ser facilmente

mapeadas para o nosso cenário, excluindo logo à partida por exemplo, o cenário da auto-

estrada.

O preço unitário deste médulo é de 10.8 €. De modo a completar as informações referidas até

aqui, segue em anexo a tabela de especificações deste módulo.

MICROCONTROLADOR: Em relação ao processamento, optámos por um microcontrolador da

família MSP430 da Texas Instruments, mais especificamente o MSP430F148 - 16 bit. Esta gama

de processadores foi desenvolvida segundo o conceito de ultra-low power e, tal como nos outros

componentes, isso foi tido em conta devido às necessidades críticas relativas ao fornecimento

de energia que os sistemas desta natureza possuem. Segundo os dados mais significativos em

relação à energia, o consumo dos microcontroladores desta família é no geral <100 μA/MHz,

<1μA em RTC Mode e 0.1μA em RAM retention. Estes valores não se afastam das características

do microcontrolador escolhido, excepto um parâmetro, este processador consome 280

µA/MHz. A configuração será ajustada para trabalhar com a mínima frequência possível, de

modo a minimizar os gastos. Tendo em conta estes valores, o contexto, as necessidades do

nosso problema (onde se assume que o microcontrolador não está sempre activo) e a estatística,

o tempo de vida da bateria neste componente seria > 20 anos. Note-se que, tal como é comum,

é usada uma simples pilha circular do tipo CR20xx (coin cell battery).

Por exemplo, se fosse usada a bateria ENERGIZER CR2032, com capacidade de 240 mAh, o

microcontrolador poderia estar a trabalhar em carga máxima mais de 257 horas (240/0.28). Tal

como foi dito, para fazer face às necessidades do problema não é necessário manter o

microprocessador sempre activo, o que se vai reflectir num consumo mais económico. Isto é

possível devido aos modos de funcionamento do processador, que não são mais que

optimizações feitas no mesmo, que permitem activar recursos apenas quando são estritamente

necessários. Deste modo o Digitally Controlled Oscillator (DCO) mantém o microcontrolador em

modos de baixo consumo tanto tempo quanto possível, de modo a não comprometer o

desempenho esperado do sistema. Este mesmo DCO é também programável, caso o sistema

tenha necessidades mais estritas e seja necessário ajustar as heurísticas ligadas aos modos de

poupança de energia. Este microcontrolador tem memória FLASH incluída, o que é uma mais-

valia na medida em que se reduzem alguns custos de integração. A figura seguinte descreve

algumas das especificações técnicas deste microcontrolador, bem como o preço (equivalente a

3.1 €). Abaixo segue as características do microcontrolador:

Segue-se o diagrama de blocos, que ilustra a arquitectura do microprocessador escolhido:

Tendo em conta a implementação escolhida, em que cada animal tem possibilidade de aceder

no máximo a informações de 100 animais (já incluindo os seus adjacentes) calculámos o

tamanho máximo que o stack poderia alcançar. Este valor é de ( (16 * 4) + 8 ) * 100 bits , ou seja,

cada animal no pior dos casos (acedendo a todas as variáveis referentes aos 100 animais sobre

os quais detém informação) fica com uma stack de 7200 bits, ou seja, 900 bytes.

Assumindo que o TinyOS tem uma ocupação de 400 bytes e sabendo que o microcontrolador

escolhido tem uma capacidade de 2048 bytes, ficamos com uma margem de 748 bytes, que são

suficientes para a memória global e variáveis auxiliares que não foram tidas em conta neste

cálculo, devido a não serem muito relevantes pelo seu tamanho/quantidade de acessos.

MÓDULO DE RÁDIO FREQUÊNCIA: Em relação ao módulo de RF optámos pelo XBee 802.15.4 (XB24-

API-001), da Digi. O consumo é de 50 mA em recepção e em transmissão é 45 mA (boost mode)

ou 35 mA (normal mode). Em modo inactivo consome < 10 uA. Oferece um débito máximo de

250kbps e a tensão recomendada para funcionamento é de 3.3V. Este módulo opera na gama

dos 2.4 GHz. Quanto ao seu tamanho é de 2.438 cm x 2.761 cm. Escolhemos este módulo porque

adapta-se bem ao contexto do problema, na sua relação consumo/débito. Dado que não são

requisitos ter altas velocidades de transmissão, e a quantidade de dados a transmitir também

não é de grandes dimensões este módulo consegue colmatar as nossas necessidades. O preço

unitário destes módulos é 15,36 €. Podem ser observadas mais especificações técnicas deste

módulo na tabela seguinte.

Abaixo segue uma imagem com as características deste módulo:

MEMÓRIA FLASH: Em relação à memória FLASH, estamos a usar apenas a que vem incluída no

microprocessador para guardar o executável. Os dados estão acessíveis quando o

microprocessador está activo, a partir da SRAM. No código criámos um módulo chamado

memória apenas por questões organizacionais, para cada módulo aceder aos seus dados a partir

do seu módulo de memória, facilitando a leitura do código. Deste modo, os dados dos animais

não são guardados persistentemente, apenas são disponibilizados quando o gestor os requisita,

mantendo-se em SRAM até o sistema ser desligado. Futuramente, caso haja necessidade de

guardar logs dos vários eventos que ocorreram no sistema ou guardar até informações de animal

em específico persistentemente poderá ser usado um simples chip de memória FLASH.

Manual de Utilizador Para testar a solução descrita no relatório é necessário estar na directoria src do mesmo. Após

isso compila-se o código (make micaz sim) e introduz-se o comando python test.py. Isto irá abrir

o script interactivo que será descrito daqui em diante. De acordo com o contexto do problema,

o gestor tem de conseguir alcançar no mínimo um animal para iniciar o processo de

comunicação. Deste modo, o primeiro input a colocar no programa é o id do animal que o gestor

escolheu, dentro do cluster em questão, para enviar o request. Imediatamente a seguir, o

utilizador é deparado com um menu, com opções numeradas de 1 a 7. Nesta altura, para ter

sucesso nas próximas operações é necessário fazer com que todos os nodes arranquem. Isto é

feito escolhendo a opção 1. Após isto, todos os nodes estão activos. A opção 2 permite saber

informação de um animal específico, isto é, a sua localização e a quantidade de comida que já

comeu. Clicando nesta segunda opção, o único input que precisamos de fornecer é o id do

animal sobre o qual queremos informação. Ao fornecer este input, o gestor envia um pacote de

request ao animal escolhido e fornecido como primeiro input. Nesta fase o gestor enviou o

primeiro pacote de request e deu-se início à propagação de mensagens no cluster. A resposta

aparece destacada na consola. A partir daqui pode escolher-se a opção 2 sempre que necessário,

ou seja, pode questionar-se o sistema sobre outro animal qualquer até se ter toda a informação

desejada. Quanto à opção 3, permite mudar a quantidade de comida de um determinado

feeding spot. Quando um animal come, essa quantidade é decrementada automaticamente mas

para mudar directamente o valor basta inserir o ID do feeding spot e a quantidade de comida

que queremos que ele passe a ter. Quanto à opção 4 permite mudar a quantidade de comida

que um animal pode comer. Basta dar como input o ID do animal e a quantidade de comida que

ele vai passar a poder ingerir e a mensagem é enviada a esse mesmo animal. A opção 5 permite

saber a quantidade de comida existente num dado feeding spot. Basta dar como input o id do

feeding spot sobre o qual queremos saber o nível de comida e a informação será apresentada.

A opção 6 desliga todos os nodes e sai do programa gestor (script). Quanto à opção 7, permite

que um animal se alimente num feeding spot aleatório. Basta fornecer o id do animal que

queremos alimentar.

Problema e Desafios Um dos desafios com que lidámos foi relacionado com a entrega das mensagens com sucesso.

Isto porque o ruido gerado muitas vezes fazia com que as mensagens se perdessem. Face a isto

resolvemos usar mecanismos de Acknowledge, para garantir que caso a mensagem não

chegasse, voltasse a ser enviada. Outro dos desafios foi a identificação das mensagens, através

do seu tamanho, porque sentimos necessidade de ter vários tipos de mensagens e alguns eram

muito similares entre si. Deste modo, os parâmetros de cada tipo de mensagem tiveram de ser

ajustados e configurados para que o receptor soubesse exactamente o tipo de mensagem que

tinha recebido e o seu resultado.

Tivémos ainda um problema, relacionado com loops na entrega de mensagens, ou seja, os nodes

não tinham “consciência” que estavam a enviar mensagens uns aos outros em loop infinito (até

acabar o tempo de execução). Resolvemos esta situação usando uma flag que é passada na

mensagem e usando também um valor hierárquico, que dá aos nodes a noção de hierarquia, ou

seja, os nodes sabem através da flag, se a mensagem em questão necessita retransmissão e, se

necessitar, sabem exactamente a que nodes reenviar essa mensagem através dos valores

hierárquicos. Por exemplo, no caso de um node receber uma mensagem com a flag que lhe

indica que aquele tipo de mensagem é uma resposta direccionada ao gestor, sabe que tem que

a retransmitir a nodes hierarquicamente menores, de modo a que a mensagem chegue ao

destino.

Por último, mas não menos importante, sentimos que a escolha do hardware foi um desafio.

Isto porque não tínhamos muita experiência na escolha ou comparação de componentes para

sistemas embebidos, e o contacto com estes últimos também não tinha sido frequente até agora

(pelo menos em relação a componentes individuais). Face a isto decidimos iniciar uma pesquisa,

inicialmente para ter uma ideia concreta dos vários componentes que existiam e que poderiam

ser usados. Após isto a pesquisa evolui para a fase de avaliar quais dos componentes existentes

(resultantes da fase de pesquisa anterior) se adaptavam melhor às nossas necessidades. Por

ultimo escolhemos, entre os que melhor se adaptavam, aqueles que nos ofereciam um consumo

energético e preço mais favoráveis, tendo em conta o contexto do nosso projecto. Durante esta

pesquisa, ao analisar os vários componentes e as suas funcionalidades, facilmente conseguimos

fazer o mapeamento entre os conceitos abordados nas aulas teóricas e a sua aplicação no

hardware que estávamos a analisar. Isto foi uma vantagem, na medida em que pudemos usar

conhecimentos adquiridos nas aulas como um interveniente no processo de selecção dos vários

módulos. O feedback de outros utilizadores, relativo ao desempenho dos vários módulos que

ponderámos usar, encontrado durante o processo de pesquisa também foi tido em conta

durante o processo de selecção.

Conclusão A solução proposta, de modo a fazer frente aos desafios de monotorização na agricultura

moderna, consiste num sistema embebido, que está associado a cada animal, e num protocolo

de comunicação. O sistema embebido inclui módulos de GPS, RFID, Radio Frequency e uma

unidade de processamento. O protocolo de comunicação consiste em três fases, isto é, fase de

descoberta, funcionamento normal e actualização. São usados mecanismos que tentam

minimizar o número de mensagens trocadas, mantendo a informação actualizada dentro das

linhas temporais que foram definidas. O Hardware usado foi escolhido tendo em consideração

principalmente o consumo energético do mesmo, sendo esta uma área de grande foco.

Referências http://www.cs.berkeley.edu/~culler/papers/ai-tinyos.pdf

http://www.csee.umbc.edu/~younis/Publications/JAdHoc/SensNetRouting.pdf

http://www.ece.iastate.edu/~kamal/Docs/kk04.pdf

http://www.ti.com/lit/sg/slab034x/slab034x.pdf

http://www.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf

http://www.farnell.com/datasheets/662939.pdf

http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-

modules/point-multi

point-rfmodules/xbee-series1-module#specs

http://www.tinyos.net/tinyos-2.1.0/doc/nesdoc/micaz/

http://www.digi.com/pdf/ds_xbeemultipointmodules.pdf

http://www.tinyos.net/papers/nesc.pdf

http://www.comsys.rwth-aachen.de/fileadmin/papers/2010/2010-05-icc-munawar-

DynamicTinyOS.pdf

http://www.cs.ucla.edu/classes/fall03/cs211/papers/tinyos.pdf

http://tinyos.stanford.edu/tinyos-wiki/index.php/TinyOS_Tutorials

https://fenix.tecnico.ulisboa.pt/downloadFile/3779580627866/nesc-1.3.1.pdf

http://tinyos.stanford.edu/tinyos-wiki/index.php/TOSSIM

Anexos ANEXO 1: Especificações técnicas do módulo de GPS