sensor network for animal husbandry · sensor network for animal husbandry aplicações para...
TRANSCRIPT
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