ii - repositorium.sdum.uminho.pt · gerir remotamente e de forma seletiva os nós sensores ... com...
TRANSCRIPT
i
ii
iii
Agradecimentos
Eu gostaria de agradecer aos meus orientadores, o Professor Paulo Carvalho e
Professor Óscar Gama, pela ajuda, disponibilidade e orientação ao longo deste
trabalho, essencial para a realização desta dissertação.
Gostaria também de agradecer ao Departamento de Engenharia Informática da
Universidade de Coimbra, nomeadamente ao Professor Jorge Sá Silva e ao
Departamento de Eletrónica Industrial da Universidade do Minho, em especial ao
Professor José Augusto Afonso, pela disponibilidade e material cedido para a
realização deste trabalho.
iv
Resumo
As Redes de Sensores Sem Fios (RSSFs) têm uma vasta área de aplicabilidade,
sendo constituídas por um grande número de nós que podem diferenciar bastante
na sua constituição e capacidade. Estas redes podem operar por longos períodos de
tempo, muitas vezes em locais de difícil acesso. Neste sentido, a capacidade de
gerir remotamente e de forma seletiva os nós sensores torna-se crucial neste tipo de
redes. Contudo, dos sistemas operativos mais utilizados nas RSSFs apenas o TinyOS
oferece nativamente um protocolo de reprogramação (Deluge). A natureza
epidémica do Deluge, sem suportar uma reprogramação seletiva, compromete o
potencial de aplicação das RSSFs. Esta dissertação propõe um novo protocolo como
uma extensão ao Deluge, permitindo reprogramar seletivamente os nós de uma rede
com base no seu tipo de plataforma ou na sua identificação única. São levados em
consideração aspetos como a fiabilidade e eficiência no desenho e na construção
do protocolo, ao mesmo tempo que são preservadas todas as funcionalidades
originais do Deluge. O protocolo proposto permite uma maior versatilidade e
flexibilidade na implementação de RSSFs, pois permite a reprogramação de redes
que possuam diferentes plataformas e aplicações.
v
Abstract
Wireless sensor networks (WSNs) have a vast range of applicability, being
composed by a large number of nodes that may differ greatly in constitution and
capability. These networks can operate for long periods of time, often in places of
difficult access. In this way, the ability to reprogram remotely and selectively sensor
nodes becomes crucial in the maintenance and management of this type of
networks. However, from the operating systems mostly used in WSNs only TinyOS
supports natively a reprogramming protocol (Deluge). The epidemic nature of
Deluge, without supporting selective programming, compromises the potentially vast
application of WSNs. This paper proposes a new protocol as an extension to Deluge,
allowing selective reprogramming of sensor nodes based on platform type or node
identifier. Aspects such as reliability and efficiency are taken into account in the
protocol design and implementation, while preserving all the basic features of
Deluge. The solution was tested in a real environment with multiple scenarios to
ensure its functionality. The proposed protocol provides the required flexibility for
deploying versatile WSNs, allowing reprogramming networks comprising different
types of nodes and applications.
vi
Índice de conteúdos
Agradecimentos .............................................................................................. iii
Resumo .......................................................................................................... iv
Abstract ........................................................................................................... v
Índice de conteúdos ........................................................................................ vi
Lista de Figuras .............................................................................................. ix
Lista de acrónimos.......................................................................................... xi
1. Introdução...............................................................................................1
1.1 Introdução ................................................................................................ 1
1.2 Motivação e objetivos .............................................................................. 2
1.3 Contribuições ........................................................................................... 3
1.4 Estrutura da dissertação.......................................................................... 4
2. Redes de Sensores Sem Fios ..................................................................5
2.1 Caraterísticas das Redes de Sensores Sem Fios ................................... 5
2.2 Comunicação ........................................................................................... 7
2.2.1 Normas ............................................................................................. 7
2.2.1.1 ZigBee ......................................................................................... 8
2.2.1.2 WirelessHart ............................................................................... 9
2.2.1.3 6LoWPAN ................................................................................. 11
2.2.2 Topologias ...................................................................................... 11
2.3 Sistemas Operativos nas Redes de Sensores Sem Fios ...................... 13
2.3.1 Contiki ............................................................................................. 13
vii
2.3.2 LiteOS ............................................................................................. 15
2.3.3 Mantis ............................................................................................. 17
2.3.4 Nano-RK ......................................................................................... 18
2.3.5 TinyOS ............................................................................................ 20
2.4 Aplicabilidade ........................................................................................ 23
2.4.1 Monotorização de Ambientes ........................................................ 23
2.4.2 E-Health .......................................................................................... 24
2.4.3 Outras áreas de aplicação ............................................................. 25
2.5 Sumário .................................................................................................. 26
3. Reprogramação remota de Redes de Sensores Sem Fios ....................... 27
3.1 Desafios da reprogramação remota nas RSSFs................................... 27
3.2 Tipos de reprogramação ....................................................................... 28
3.2.1 Reprogramação Modular ............................................................... 30
3.2.2 Máquinas virtuais ........................................................................... 31
3.2.3 Reprogramação ao nível do sistema ............................................. 33
3.2.3.1 Estratégias baseadas na distribuição de toda a imagem do
código ……………………………………………………………………………………………..33
3.2.3.2 Estratégias baseadas na distribuição de diferenças entre
imagens de código .......................................................................................... 36
3.3 Sumário .................................................................................................. 37
4. Desenho e Implementação do Protocolo ............................................... 38
4.1 Reprogramação com o Deluge ............................................................. 38
4.1.1 Deluge 2.0 ...................................................................................... 38
4.1.2 Disseminação e o DRIP ................................................................. 40
viii
4.1.3 TosBoot ........................................................................................... 43
4.1.4 Tos-Deluge...................................................................................... 45
4.1.5 Análise e discussão ........................................................................ 46
4.2 Discussão e Implantação de uma extensão ao Deluge ...................... 47
4.2.1 Planeamento da solução ............................................................... 47
4.2.2 Detalhes da implementação .......................................................... 50
4.2.2.1 Reprogramação Seletiva através da Plataforma ..................... 51
4.2.2.2 Reprogramação Seletiva através do NodeID .......................... 52
4.2.3 Otimização do protocolo ................................................................ 54
4.2.4 Modo de atualização ...................................................................... 58
4.3 Sumário .................................................................................................. 60
5. Resultados e discussão ......................................................................... 61
5.1 Cenário de testes ................................................................................... 61
5.2 Testes e análise de resultados .............................................................. 63
5.2.1 Reprogramação através do tipo de plataforma ............................ 64
5.2.2 Reprogramação através do NodeID .............................................. 66
5.2.3 Modo de atualização ...................................................................... 69
5.3 Análise e discussão ............................................................................... 71
5.4 Sumário .................................................................................................. 72
6. Conclusões e Trabalho Futuro ............................................................... 74
6.1 Conclusões ............................................................................................. 74
6.2 Trabalho futuro ...................................................................................... 75
Referências Bibliográficas .............................................................................. 77
ix
Lista de Figuras
FIGURA 2.1:ARQUITETURA DE UM NÓ SENSOR. .................................................................. 6
FIGURA 2.2: MERCADO DOS NÓS SENSORES AO LONGO DO TEMPO [6]. ............................... 7
FIGURA 2.3: ARQUITETURA DO ZIGBEE E PILHA PROTOCOLAR [7]. ...................................... 9
FIGURA 2.4 ARQUITETURA E COMPONENTES DO WIRELESSHART [6]. ............................... 10
FIGURA 2.5: TOPOLOGIAS MAIS COMUNS NAS RSSFS. (A) TOPOLOGIA EM ESTRELA; (B)
TOPOLOGIA EM MALHA; E (C) TOPOLOGIA EM CLUSTER. ............................................. 13
FIGURA 2.6: ARQUITETURA DO CONTIKI [9]. ................................................................... 15
FIGURA 2.7: ARQUITETURA DO LITEOS [10]. .................................................................. 16
FIGURA 2.8: ARQUITETURA EM CAMADAS DO MANTIS. ................................................... 18
FIGURA 2.9: ARQUITETURA DO SISTEMA OPERATIVO NANO-RK [12]. ............................... 20
FIGURA 2.10: ARQUITETURA DO SISTEMA OPERATIVO TINYOS [9]. ................................... 23
FIGURA 4.1:SEGMENTAÇÃO DA IMAGEM DE CÓDIGO NO PROCESSO DE DISSEMINAÇÃO DA
MESMA. .................................................................................................................. 39
FIGURA 4.2: ESTRUTURA DO PACOTE ENVIADO POR DEFEITO PELO DELUGE [5]. ................ 43
FIGURA 4.3: FLUXOGRAMA DE FUNCIONAMENTO DO TOSBOOT. ........................................ 45
FIGURA 4.4: COMPONENTES UTILIZADOS PELO DELUGE NA REPROGRAMAÇÃO REMOTA. ..... 47
FIGURA 4.5: PACOTES CRIADOS PARA A REPROGRAMAÇÃO SELETIVA [5]. ........................... 50
FIGURA 4.6: COMPONENTES DE CÓDIGO ALTERADOS (INDICADO A VERMELHO) E CRIADOS
(INDICADO A VERDE). ............................................................................................... 51
FIGURA 4.7: PROCESSO DE EMPACOTAMENTO NA ESTAÇÃO BASE [5]................................. 54
FIGURA 4.8: PROCESSO DE REPROGRAMAÇÃO SELETIVA [5]. ............................................ 56
FIGURA 4.9: PROCESSO DE REPROGRAMAÇÃO SELETIVA NO NÓ [5]. .................................. 57
FIGURA 4.10: FIM DO PROCESSO DE DISSEMINAÇÃO NA REPROGRAMAÇÃO SELETIVA E O
MODO ATUALIZAÇÃO [5]. ......................................................................................... 60
FIGURA 5.1:CENÁRIO EXPERIMENTAL. ............................................................................. 62
FIGURA 5.2: FLUXOGRAMA DA APLICAÇÃO ALTERADA PARA A CRIAÇÃO DOS FICHEIROS DE LOG
DE DADOS. .............................................................................................................. 63
x
FIGURA 5.3:DISTRIBUIÇÃO TEMPORAL DOS PACOTES NA REPROGRAMAÇÃO COM O DELUGE
ORIGINAL. ............................................................................................................... 65
FIGURA 5.4: DISTRIBUIÇÃO TEMPORAL DOS PACOTES NA REPROGRAMAÇÃO SELETIVA POR
PLATAFORMA. ......................................................................................................... 65
FIGURA 5.5: REPROGRAMAÇÃO SELETIVA DOS NÓS 5, 55 E 7 COM PACOTES DE. .............. 68
FIGURA 5.6: REPROGRAMAÇÃO SELETIVA DOS NÓS 5, 55 E 7 COM PACOTES DF. .............. 68
FIGURA 5.7: REPROGRAMAÇÃO SELETIVA DOS NÓS 10, 55 E 7 COM O NÓ 7 INACESSÍVEL. . 69
FIGURA 5.8: REPROGRAMAÇÃO SELETIVA DOS NÓS 5, 55 E 7 E O MODO DE ATUALIZAÇÃO. . 70
xi
Lista de acrónimos
6LoWPAN IPv6 over Low-power Wireless Personal Area Network
API Application Programming Interface
CRC Cyclic Redundancy Check
ELF Executable and Linkable Format
FIFO First In First Out
HART Highway Addressable Remote Transducer
I.C.T Information and Communications Technology
IETF Internet Engineering Task Force
iHEX Intel HEX
ISM Industrial Medicine Scientific
MAC Media Access Control
MANTIS MultimodAl System for NeTworks of In-situ wireless Sensors
MOAP Multihop Over-the-Air Programming
PHY Physical Layer
RSSFs Redes de Sensores Sem Fios
SNMS Sensor Network Management System
SO Sistema Operativo
TDMA Time Division Multiple Access
WFDs WirelessHart Field Devices
1
1. Introdução
1.1 Introdução
Com a rápida evolução dos dispositivos eletrónicos, nomeadamente na área dos
sensores, e com estes cada vez mais pequenos, as Redes de Sensores Sem Fios
(RSSFs) têm assegurado um lugar de destaque no que toca à monitorização e
controlo de dados nas mais diversas áreas de atividade. O conceito subjacente a
este tipo de redes é ter um conjunto de nós constituídos por sensores, um
microprocessador e um módulo de comunicação sem fios. Estes nós, apesar de
terem uma capacidade individual de computação e comunicação limitada, quando
trabalham em conjunto permitem alcançar e monitorizar diversos ambientes com
um custo de implementação e manutenção reduzidos.
Estas redes muitas vezes acabam por ser colocadas em cenários e situações em
que é humanamente difícil alcançar os nós, pelo que a existência de uma gestão e
reprogramação remota é crucial. A necessidade de reprogramar uma RSSF pode
dever-se a diversos fatores, como: mudanças no meio ambiente, atualizações de
software, melhorias de segurança e alterações nos objetivos aplicacionais. A
reprogramação remota de RSSFs tira partido da comunicação sem fios dos nós
utilizando estratégias de disseminação para alcançar todos os nós da rede.
Devido à grande heterogeneidade de aplicações e de plataformas que podem
existir numa RSSF, é esperado que a reprogramação da rede possa ser feita de
forma seletiva. Desta forma, é possível selecionar quais os nós a serem
reprogramados e que tipo de aplicação vai ser afetada, tornando o processo de
reprogramação mais flexível e eficiente. No entanto, o desenho e a implementação
deste tipo de estratégias de reprogramação e disseminação de código é uma tarefa
bastante complexa devido aos poucos recursos que os nós apresentam (e.g.
comunicação, energia, processamento e armazenamento).
2
Os sistemas operativos mais utilizados nas RSSFs, como o TinyOS [1] e o
Contiki [2] suportam poucos ou nenhuns protocolos de reprogramação por defeito,
e muitos desses protocolos apresentam um claro défice de desempenho e
funcionalidade. O caso mais evidente é o do TinyOS [1], visto que é na atualidade
o sistema operativo mais utilizado nas RSSFs [3] e apenas suporta um protocolo de
reprogramação por defeito, o Deluge [4]. Este protocolo, por ser o único protocolo
de reprogramação que o TinyOS oferece, acaba por ser a primeira e muitas vezes a
única forma que os utilizadores têm de reprogramar uma RSSF. O Deluge permite
reprogramar uma rede de sensores de forma simples, contudo, não permite uma
reprogramação seletiva da mesma. Com este protocolo a reprogramação é total, ou
seja, todos os nós da rede são reprogramados com a mesma aplicação, acabando
por limitar a versatilidade e potencial de uma RSSF.
Neste contexto, este trabalho propõe e implementa um novo protocolo como
uma extensão ao Deluge que permite uma reprogramação seletiva dos nós da rede
através do tipo de plataforma ou do identificador de cada nó (NodeID). A solução
proposta aumenta claramente a funcionalidade do Deluge contribuindo para a
reprogramação seletiva de RSSFs que possuam heterogeneidade de plataformas e
aplicações.
1.2 Motivação e objetivos
A reprogramação remota das RSSFs possibilita a gestão e implementação destas
redes em locais onde de outra forma estas tarefas seriam impossíveis. A
reprogramação da rede pode ser feita reprogramando todos os nós, ou apenas parte
deles, através de uma reprogramação seletiva. A capacidade de escolher
separadamente que nós se vão reprogramar e com que aplicação este processo será
feito torna possível gerir e reprogramar RSSFs com múltiplas plataformas e
aplicações, elevando assim o seu potencial de aplicação.
Apesar do TinyOS ser o sistema operativo mais utilizado nas RSSFs [3], apenas
permite uma reprogramação total da rede através do único protocolo de
3
reprogramação remota que possui, o Deluge. Esta falta de versatilidade no processo
de reprogramação implica que todos os nós da rede partilhem o mesmo tipo de
plataforma e aplicação. Isto compromete severamente o potencial de aplicação das
RSSFs limitando a composição da rede a nós e aplicações homogéneas.
Este trabalho tem como principal objetivo criar uma extensão ao Deluge de
forma a aumentar a sua versatilidade na reprogramação. Neste sentido, a extensão
criada deve permitir reprogramar seletivamente os nós de uma RSSF. No entanto,
como objetivo adicional, a solução encontrada deve garantir que o comportamento
original do Deluge não seja afetado ao mesmo tempo que deve assegurar fiabilidade
e eficiência no processo de reprogramação.
1.3 Contribuições
A principal contribuição deste trabalho consiste no desenho, implementação e
teste de uma extensão ao Deluge e DRIP que permite a reprogramação seletiva de
RSSFs. Esta extensão consiste na alteração do modo de funcionamento do DRIP,
dando origem a um novo protocolo que permite reprogramar os nós da rede através
do seu identificador ou do tipo de plataforma. Uma vez que o protocolo criado tem
a capacidade de controlar a informação que circula na rede durante o processo de
reprogramação, é possível manter em circulação apenas a informação necessária
para que a reprogramação seja possível. Isto é feito através de uma série de
procedimentos nomeadamente: (i) a atualização constante da lista de nós que se
pretende reprogramar; e (ii) a prioridade na comunicação ganha pelos nós com uma
lista mais atualizada. Isto permite diminuir a quantidade de energia gasta na
transmissão durante o processo de reprogramação.
Graças ao modo de atualização do protocolo desenvolvido, o tráfego relativo à
reprogramação deixa de circular na rede quando todos os nós se reprogramam com
sucesso. Isto não acontecesse na reprogramação oferecida por defeito pelo Deluge.
Além disto, o protocolo permite a atualização de nós que se encontrem
desatualizados sobre o estado da reprogramação seletiva, mesmo depois de esta ter
4
terminado. Desta forma, o protocolo criado permite de um forma fiável e eficiente
reprogramar seletivamente uma RSSF. Isto traduz-se num claro aumento da
funcionalidade do Deluge e consequente melhoria das opções de reprogramação
oferecidas pelo TinyOS, permitindo aos utilizadores uma maior versatilidade na
construção e implementação de RSSFs.
O trabalho desenvolvido culminou na escrita de um artigo científico [5], que à
data de submissão desta dissertação se encontra ainda em processo de revisão.
1.4 Estrutura da dissertação
Esta secção descreve a estrutura da dissertação. Assim sendo, o Capítulo 2
oferece uma visão geral sobre as RSSFs, nomeadamente sobre as características
dos nós, a comunicação, os sistemas operativos mais utilizados e áreas de
aplicação.
O Capítulo 3 apresenta os desafios da reprogramação remota nas RSSFs bem
como os trabalhos que têm vindo a ser desenvolvidos nesta área.
O Capítulo 4 oferece os detalhes do desenho e implementação do protocolo
criado que permite a reprogramação seletiva dos nós de uma rede de sensores
através do seu tipo de plataforma ou do seu identificador único.
No Capítulo 5 está presente a descrição do cenário de testes utilizado bem como
a análise e discussão do comportamento do protocolo nos diversos testes realizados.
Finalmente, o Capítulo 6 apresenta as conclusões e perspetivas finais, bem
como as possíveis direções a tomar para trabalhos futuros.
5
2. Redes de Sensores Sem Fios
As RSSFs têm vindo a evoluir constantemente, diferenciando-se bastante na sua
constituição e nas áreas de aplicação. Neste capítulo são identificadas as
características dos nós que compõem uma RSSF, bem como o suporte à
comunicação que estas redes oferecem relativamente às normas e topologias. É
ainda feito um levantamento sobre os sistemas operativos mais utilizados e as
diversas áreas de aplicação onde as RSSFs estão a ser uma mais-valia.
2.1 Caraterísticas das Redes de Sensores Sem Fios
As RSSFs são compostas por sistemas individuais denominados de nós que são
capazes de interagir com o meio através de diversos sensores, processar informação
localmente e comunicar esta informação para os seus vizinhos através de uma
ligação sem fios. Esta informação pode corresponder a leituras feitas pelos sensores
sobre meio ambiente onde estão inseridos ou ao estado de atuadores. Normalmente,
um nó é constituído por quatro tipos de módulos principais que podem ser
encontrados no mesmo circuito integrado ou em circuitos separados sendo eles:
módulo de comunicação sem fios, microcontrolador, sensores e o módulo de
energia, ver Figura 2.1. A estes componentes base podem ainda ser adicionados
componentes adicionais como memória ou outros módulos de comunicação que
permitem, por exemplo, a comunicação por cabo com um computador.
6
Figura 2.1:Arquitetura de um nó sensor.
Os nós podem servir diferentes propósitos consoante o seu poder de
processamento. Os nós com reduzida capacidade de processamento e memória são
normalmente implementados em grande número para realizar tarefas de
monitorização do meio e fornecer uma infraestrutura de comunicação. Por outro
lado, os nós com mais recursos podem ser utilizados para executar tarefas mais
exigentes, como gestão da rede ou tratamento de dados antes de estes chegarem
ao utilizador.
O tipo de nós a utilizar depende das aplicações que estes vão suportar. O
utilizador pode construir os nós à medida, escolhendo os componentes que vão
integrar cada módulo, ou pode utilizar um nó já construído que ofereça os recursos
que pretende. Ao longo do tempo, vários tipos de nós têm chegado ao mercado
oferecendo um vasto leque de escolhas aos utilizadores. Na Figura 2.2, estão
representados vários tipos de nós que têm surgido no mercado ao longo do tempo,
como é referido em [6].
7
Figura 2.2: Mercado dos nós sensores ao longo do tempo [6].
2.2 Comunicação
2.2.1 Normas
A grande variedade de plataformas de nós existente para RSSFs provoca
problemas de compatibilidade na construção de aplicações. Desta forma, a
estandardização de certos aspetos como a comunicação é crucial para que este tipo
de tecnologias possa proliferar. Neste sentido, foi criada pelo IEEE a norma
802.15.4 com o objetivo de fornecer especificações para a camada física (PHY) e
de controlo de acesso ao meio (MAC) para dispositivos com uma tecnologia de
comunicação sem fios, de baixa taxa de transferência, com pouca complexidade e
com grandes preocupações energéticas.
O IEEE 802.15.4 ópera na gama de frequências denominada ISM (Industrial
Medicine Scientific) de 868 MHz (Europa), 915 MHz (EUA) e 2.4 GHz (Global)
sendo esta última a mais utilizada.
É conhecido que normas como o Bluetooth e Wi-Fi não são apropriados para
dispositivos com restrições energéticas, pelo que através do 802.15.4 foram
construídos várias normas ou padrões que tentam resolver este problema. De
seguida são discutidos algumas dessas normas que mais se destacam na
comunicação em RSSFs.
8
2.2.1.1 ZigBee
O padrão ZigBee [7] foi desenvolvido pela ZigBee Alliance com o intuito de
colmatar a necessidade do mercado na existência de um padrão para a
comunicação sem fios com baixas taxas de transmissão que oferecesse pouco
consumo energético, segurança e fiabilidade.
O ZigBee é definido em conjunto com a norma IEEE 802.15.4. Apesar de serem
muitas vezes confundidos estas normas definem camadas diferentes da pilha
protocolar. Como se pode verificar na Figura 2.3, o IEEE 802.15.4 define as duas
primeiras camadas, a camada física e a camada de controlo de acesso ao meio,
enquanto o ZigBee define a camada de rede e um framework aplicacional. Assim
sendo, para suportar uma grande variedade de aplicações foram definidos três tipos
de tráfego de dados [6]. O primeiro tipo, tráfego de dados periódicos, é originado
por aplicações de monitorização onde as aplicações enviam dados de forma regular,
independentemente de fenómenos externos que possam ocorrer. O segundo tipo,
tráfego de dados intermitente, é originado por aplicações que geram tráfego com
base em eventos despoletados pela própria aplicação ou por fenómenos externos.
Finalmente o terceiro tipo de tráfego, o tráfego repetitivo de baixa latência, diz
respeito a ações que têm de ser feitas num determinado período de tempo. Este tipo
de tráfego é definido pelo IEEE 802.15.4, através da estrutura da trama utilizada
para polling.
A camada de rede definida pelo ZigBee oferece as funcionalidades de gestão da
rede referentes à criação de uma nova rede e a junção ou não dos dispositivos à
mesma. Como os dispositivos que utilizam o ZigBee podem fazer parte de várias
redes ao longo do seu tempo de vida, a norma também oferece um mecanismo de
endereçamento flexível. Assim sendo, o coordenador da rede atribui endereços ao
dispositivo à medida que estes se vão juntando à mesma. Desta forma, em vez de
ser utilizada a identificação única de cada dispositivo na comunicação, são
utilizados endereços mais curtos aumentado a eficiência energética [6].
9
Figura 2.3: Arquitetura do ZigBee e pilha protocolar [7].
2.2.1.2 WirelessHart
O WirelessHart [6] tem sido desenvolvido como uma extensão sem fios do
protocolo Highway Addressable Remote Transducer (HART). Este protocolo é
largamente utilizado por aplicações da indústria e automação que requerem suporte
em tempo real. O HART disponibiliza um modelo de comunicação do tipo
primário/secundário, onde podem ser utilizados até dois primários. Desta forma, os
dispositivos ligados a este sistema podem ser monitorizados e controlados de forma
permanente. O WirelessHart foi lançado como fazendo parte da especificação HART
7, visando a monitorização de processos e aplicações de controlo. Este protocolo
baseia-se na especificação da camada física do IEEE 802.15.4 para frequências de
2.4 GHz.
A Figura 2.4 representa a arquitetura do WirelessHart como é apresentada em
[6]. É possível verificar a existência de cinco tipos de componentes sendo eles:
WirelessHart Field Devices (WFDs): são os dispositivos sensores e de
controlo;
10
Gateways: oferecem a comunicação entre a parte com cabos e a parte
sem fios da infraestrutura;
Network Managers: mantêm a comunicação da rede através da definição
dos espaços temporais em que cada dispositivo pode transmitir, a
determinação das tabelas de encaminhamento e a monitorização do
estado da rede;
WirelessHart Adapters: oferecem comunicação entre dispositivos HART,
que não possuem comunicação rádio, com a rede sem fios;
Handhelds: são dispositivos que possuem comunicação rádio e
permitem interagir diretamente com os WFDs;
Baseado nestes componentes, o WirelessHart oferece uma pilha protocolar que
utiliza o padrão IEEE 802.15.4 na camada física e um protocolo MAC baseado em
TDMA (Time Division Multiple Access) na cama de ligação de dados.
Figura 2.4: Arquitetura e componentes do WirelessHart [6].
11
2.2.1.3 6LoWPAN
Os padrões desenvolvidos para a comunicação nas RSSFs tornam possível a
comunicação entre os nós. Contudo, estas redes não podem ser facilmente
integradas com a Internet, visto que os protocolos de comunicação baseados no
IEEE 802.15.4 não são compatíveis com o IP. Desta forma, os nós sensores não
podem comunicar facilmente com dispositivos que se encontram na Internet como
servidores ou browsers. Isto obriga que sejam utilizadas gateways que têm como
função fazer a interligação entre as RSSFs e a Internet. Esta estratégia traz algumas
desvantagens, pois permite que se crie um único ponto de falhas na rede além de
sobrecarregar os nós vizinhos da gateway com todo o tráfego que necessita de ser
encaminhado para a Internet [6].
Para tentar resolver este problema, a IETF (Internet Engineering Task Force)
desenvolveu o 6LoWPAN (IPv6 over Low-power Wireless Personal Area Network)
[8]. Esta norma define a implementação da pilha protocolar IPv6 sobre o IEEE
802.15.4, permitindo assim que qualquer dispositivo das RSSFs possa ter
conectividade IP.
Os principais desafios na integração destes dois protocolos estão principalmente
no encaminhamento e transporte de tráfego devido às diferentes estruturas de
endereçamento. O IPv6 disponibiliza 40 bytes para o cabeçalho, incluindo
endereçamento, enquanto o IEEE 802.15.4 disponibiliza um total de 127 bytes
para toda a trama, incluindo cabeçalho e conteúdo (payload) [6].
2.2.2 Topologias
Na implementação de uma RSSF podem ser utilizadas diferentes topologias
dependendo do tipo de aplicações que vão ser utilizadas e dos recursos que os nós
possuem. Basicamente cada topologia define o tipo de infraestrutura que dará
suporte à comunicação na RSSF. Entre outras, as topologias mais comuns são:
Topologia em estrela: Uma topologia em estrela permite que uma estação
base envie e receba dados de todos os nós que estejam dentro do seu
12
alcance rádio. Estes nós só podem comunicar com a estação base, não lhes
sendo assim permitido trocar dados entre si, ver Figura 2.5 (a). As vantagens
deste tipo de topologia são: (i) a sua simplicidade; e (ii) a redução dos gastos
energéticos dos nós na transmissão, pois estes só têm de comunicar com a
estação base. Por outro lado, neste tipo de topologia a estação base tem de
estar obrigatoriamente dentro do alcance rádio de todos os nós na rede. Além
disso, o fato de todas as comunicações terem de passar por um único nó,
implica um único ponto de falha que pode comprometer toda a comunicação
da rede.
Topologia em malha: Este tipo de topologia permite a um nó comunicar com
todos os nós da rede através de uma comunicação multi-salto. Neste caso,
quando existe a necessidade de comunicação de um nó com outro nó que
esteja fora do seu alcance rádio, são utilizados nós intermédios para fazer o
encaminhamento da mensagem até ao destino, ver Figura 2.5 (b). Esta
topologia tem a vantagem de oferecer uma maior redundância e
escalabilidade. Desta forma, se um nó intermedio falhar, o caminho do
emissor até ao recetor pode ser alterado através da utilização de outros nós
intermédios. A grande desvantagem desta topologia é o elevado consumo
energético dos nós, pois estes têm de suportar protocolos de
encaminhamento. Além deste fato, quanto maior for o número de nós
intermédios, maior será o tempo que a mensagem demora a chegar ao
destino.
Topologia em cluster: Esta topologia é uma estratégia híbrida entre a
topologia em malha e a topologia em estrela, proporcionando uma estratégia
robusta e versátil para a comunicação enquanto tenta reduzir o consumo
energético. Nesta topologia, os nós com menos recursos não podem ser
utilizados como nós intermédios, ou seja, não encaminham mensagens,
permitindo assim que estes poupem energia. Por outro lado, os nós com
mais recursos são utilizados como nós intermédios fazendo o
13
encaminhamento das mensagens dos nós com poucos recursos para o resto
da rede, ver Figura 2.5 (c).
Figura 2.5: Topologias mais comuns nas RSSFs. (a) Topologia em estrela; (b) Topologia em
malha; e (c) Topologia em cluster.
2.3 Sistemas Operativos nas Redes de Sensores Sem Fios
2.3.1 Contiki
O Contiki [2] é um sistema operativo (SO) leve e modular que suporta o
carregamento dinâmico e substituição individual de programas e serviços. O seu
Kernel é baseado em eventos e oferece opcionalmente a utilização de preemptive
threadings. Este SO é construído em linguagem C e foi implementado em várias
plataformas com diferentes arquiteturas de CPUs. O único nível de abstração
fornecida pelo seu Kernel é a multiplexação do CPU e o carregamento dinâmico de
programas e serviços. Uma abstração adicional é também fornecida através de
bibliotecas com acesso total à camada de hardware. Os programas são carregados
para o SO utilizando um formato binário modificado que contém informações sobre
a sua relocalização, sendo que esta é feita em tempo de execução.
O Contiki permite a utilização de proto-threads, que funcionam como uma
camada de abstração, fornecendo a possibilidade de escrever programas utilizando
14
threads, apesar de o Kernel ser baseado em eventos. As grandes vantagens dos
proto-threads passam por estes terem um overhead pequeno (apenas 2 bytes de
memória), não necessitarem de uma pilha de processamento separada e serem
altamente portáveis. Como alternativa às proto-threads, o Contiki disponibiliza
também, como já foi referido, o modelo de preemptive threading implementado
através de uma biblioteca opcional. Neste caso, são utilizadas diferentes pilhas para
cada thread que são acedidas pela CPU consoante a sua prioridade.
No Contiki, um processo é uma aplicação ou um serviço que podem ser
substituídos em tempo de execução. A comunicação entre serviços é implementada
usando eventos disponibilizados pelo Kernel.
No que diz respeito aos protocolos de comunicação, as aplicações no Contiki
podem utilizar ambas as versões do protocolo IP (IPv4 e IPv6) e uma
implementação da pilha protocolar TCP/IP para pequenos microcontroladores de 8
bits com a denominação de µIP. O µIP consiste na implementação do mínimo de
funcionalidades necessárias para ter uma pilha protocolar TCP/IP completamente
funcional, suportando TCP, UDP, ICMP e os protocolos IP. Além deste protocolo, o
Contiki fornece ainda um outro protocolo leve de comunicação chamado Rime. Este
protocolo suporta comunicação single-hop unicast, single-hop broadcast e
multihop, bem como a transmissão com garantia de entrega ou em melhor-esforço
(best-effort).
Relativamente à portabilidade, para colocar o Contiki a funcionar com diferentes
plataformas é necessário escrever o código específico dessa plataforma no que diz
respeito aos drivers dos dispositivos, carregamento dinâmico dos programas
específicos dessa arquitetura e contextualização para o uso do modelo de
preemptive threading. O Kernel e a camada de serviços são independentes da
plataforma. Apesar da portabilidade deste SO para novas plataformas ser
parcialmente eficaz, na medida que o código referente ao MCU pode ser reutilizado,
a abordagem do Contiki é copiar e duplicar código mesmo entre plataformas que
partilham o mesmo código base. Por esta razão, os programas para este SO são
relativamente pesados pois usam vários kBytes de memória RAM e o código fonte
15
tem mais de 10 kBytes de tamanho. Nesta perspetiva, a portabilidade do Contiki
poderia ser melhorada através da criação de regras para o desenho e construção de
arquiteturas, onde um código base pudesse ser partilhado e reutilizado entre
diferentes plataformas. Na Figura 2.6 está representada a arquitetura do Contiki [9].
Figura 2.6: Arquitetura do Contiki [9].
2.3.2 LiteOS
O LiteOS [10] segue uma arquitetura modular escrita com uma programação
orientada a objetos, o LiteC++ (baseada em C++), oferecendo um nível de
abstração que se assemelha ao Unix. Este sistema operativo é composto por três
subsistemas: LiteShell, LiteFS, e o Kernel. O LiteShell é uma interface baseada em
Unix que permite gerir ficheiros, processos, depuração e dispositivos. Um aspeto
interessante do LiteOS é que o LiteShell reside na estação base ou no computador
onde a estação base está ligada. Este fator permite executar tarefas mais complexas,
visto que, a estação base possui mais recursos (e.g. energia). O LiteFS interpreta
todos os nós vizinhos a um salto como ficheiros, tendo uma visão da rede como
16
uma diretoria onde cada ficheiro é um nó. O utilizador na estação base pode utilizar
esta estrutura de diretorias como se tratasse de uma diretoria em Unix para executar
comandos. O Kernel reside em cada nó e oferece concorrência de processos na
forma de multithreading suportando carregamento dinâmico, registo de eventos
através de funções callBack e sincronização. O escalonador utilizado segue um
modelo baseado em prioridades e/ou Round Robin. Na Figura 2.7 está representada
a arquitetura do LiteOS como é apresentada em [10].
A comunicação no LiteOS é baseada em ficheiros, na medida que são criados
ficheiros que correspondem a todos os dispositivos que o nó possui. Desta forma, é
criado um ficheiro referente à interface rádio e sempre que é necessário enviar
alguma informação, os dados são colocados neste ficheiro sendo posteriormente
transmitidos. Da mesma forma, quando um nó recebe um pacote através da sua
comunicação rádio, esses dados são colocada no ficheiro da interface rádio, sendo
depois entregue à respetiva aplicação através da identificação da porta contida no
pacote recebido.
O código fonte é específico para a plataforma AVR 8-bits, sendo que desta forma
a portabilidade deste SO é reduzida.
Figura 2.7: Arquitetura do LiteOS [10].
17
2.3.3 Mantis
O MANTIS (MultimodAl System for NeTworks of In-situ wireless Sensors) [11]
é um sistema operativo leve e eficiente desenvolvido em linguagem C. Utiliza
preempite multithreading, permitindo aos nós executar tarefas mais complexas de
compressão, agregação e processamento de dados, mantendo um footprint inferior
a 500 Bytes de memória RAM, incluindo Kernel, escalonadores e comunicação.
Este SO segue uma arquitetura baseada em camadas como mostra a Figura 2.8.
Numa arquitetura de camadas, os serviços são implementados por camada, onde
um serviço de uma camada superior apenas utiliza os serviços de camadas
inferiores sem saber os detalhes da sua implementação.
No MANTIS, o Kernel apenas lida com as interrupções geradas pelo
temporizador, sendo que todas as outras interrupções são enviadas diretamente
para os drivers dos dispositivos. Quando os drivers recebem uma interrupção, é
ativado um thread que será responsável por lidar com os eventos que causaram a
mesma.
A comunicação no MANTIS é dividida em duas partes. A primeira parte da pilha
protocolar de comunicação é implementada no espaço do utilizador, como se
verifica na Figura 2.8. Esta parte contém a implementação dos protocolos da
camada de rede e superiores. A razão de isto acontecer, é para garantir uma maior
flexibilidade, na medida que, se uma aplicação quiser utilizar o seu próprio protocolo
de encaminhamento, este pode ser implementado no espaço do utilizador. A
desvantagem desta estratégia é a redução do desempenho, uma vez que o protocolo
de comunicação terá que utilizar a API (Application Programming Interface)
fornecida pelo MANTIS em vez de comunicar diretamente com a API do hardware.
A segunda parte da pilha protocolar de comunicação é implementada na camada
COMM, cuja sua principal função é garantir a sincronização e implementação das
funcionalidades da camada MAC. A camada COMM fornece uma interface unificada
para a comunicação com os drivers dos dispositivos (e.g. comunicação série, USB
e dispositivos de rádio).
18
O MANTIS não suporta comunicação em grupo (multicast) nem aplicações em
tempo-real, não suportando nenhum protocolo deste género na sua pilha protocolar.
Contudo, como já foi referido, este SO facilita a implementação de protocolos de
encaminhamento e de transporte sobre a camada MAC, sendo assim possível criar
e implementar protocolos para aplicações em tempo-real e/ou orientadas à
comunicação em grupo.
Uma das maiores vantagens do MANTIS é a sua portabilidade entre diferentes
plataformas, incluindo PDAs e PCs, permitindo criar redes híbridas entre nós reais
e virtuais (simulados em um ou mais PCs).
Figura 2.8: Arquitetura em camadas do MANTIS.
2.3.4 Nano-RK
O Nano-RK [12] é um SO baseado em preeptive multitasking com suporte a
aplicações em tempo-real que utiliza 2 kBytes de memória RAM e 18 kBytes de
memória ROM. O Nano-RK segue uma arquitetura monolítica, Figura 2.9. Um dos
19
objetivos do Nano-RK é o de facilitar o desenvolvimento de aplicações por parte dos
programadores, permitindo-lhes trabalhar com o paradigma que lhes é familiar,
denominado multitarefa (multitasking). Isto resulta numa curva de aprendizagem
menor, aumentado a rapidez de desenvolvimento de aplicações e consequente
aumento de produtividade.
O Nano-RK disponibiliza uma pilha protocolar de comunicação leve, com um
nível de abstração similar aos sockets. Na comunicação tradicional quando uma
aplicação pretende enviar dados, esta abre um socket e depois começa a
comunicação através do mesmo. Da mesma forma, quando a aplicação quer
receber dados, esta abre um socket numa determinada porta e fica à “escuta”. Para
uma melhor gestão da memória, os buffers utilizados para enviar e receber dados
não são geridos pelo SO mas sim pela própria aplicação, garantindo assim que esta
apenas reserva a memória que necessita.
O Nano-RK fornece uma API às aplicações para que estas possam reservar
largura de banda consoante os seus requisitos de qualidade de serviço. Assim
sendo, são disponibilizadas dois tipos de APIs: uma para reservar largura de banda
do ponto de vista do emissor e outra para o ponto de vista do recetor. Num
determinado período, uma aplicação pode somente enviar ou receber dados,
consoante o nível da sua reserva de largura de banda. A cada novo período, a
reserva de largura de banda para cada aplicação é renovada.
O Nano-RK não suporta nenhum algoritmo de encaminhamento em grupo, nem
nenhum protocolo de gestão de grupos.
Em relação à portabilidade, o Nano-RK suporta a plataforma MicaZ e FireFly,
não oferecendo detalhe sobre o seu grau de portabilidade para outras plataformas.
20
Figura 2.9: Arquitetura do sistema operativo Nano-RK [12].
2.3.5 TinyOS
O TinyOS [1] é um sistema operativo para as RSSFs substancialmente testado
e estável, possuindo uma grande comunidade de utilizadores e colaboradores.
Assim sendo, constitui uma referência na programação das RSSFs. Na Figura 2.10
está representada a sua arquitetura como é apresentada em [9].
O TinyOs segue uma arquitetura monolítica e utiliza um modelo baseado em
componentes, que dependendo dos requisitos da aplicação, são interligados entre
si de forma a criarem uma imagem estática que irá correr no nó. Um componente
é uma identidade computacional independente que disponibiliza uma ou mais
interfaces. Dividir os serviços do TinyOS em componentes traz uma grande
vantagem, pois permite que os serviços não usados sejam excluídos da aplicação.
Os componentes têm três abstrações computacionais diferentes: comandos, eventos
e tarefas. Um comando é um pedido para executar um serviço enquanto o evento
assinala realização do mesmo. As tarefas são mecanismos computacionais adiados.
O TinyOS oferece um modelo simples de concorrência baseado em tarefas e
eventos. As tarefas não interferem entre si, ou seja, não há preempção entre as
mesmas. Uma vez escalonada, uma tarefa é executada até terminar. Os
21
componentes podem iniciar a execução de tarefas através de comandos, chamando
a este procedimento fazer “post” de uma tarefa. Como não há preempção entre as
tarefas, o código executado deve ser curto, de forma a evitar que uma tarefa fique
em execução indefinidamente. Além disso, para garantir que uma tarefa termine
sempre, esta não pode bloquear recursos nem entrar em espera ocupada. O
escalonador de tarefas é configurado para escalonar as tarefas para execução
sempre que o processador estiver disponível. A disciplina FIFO (First In First Out) é
usada como padrão.
O TinyOS oferece apenas uma pilha protocolar que é partilhada por todos os
processos e não faz separação do Kernel e do espaço do utilizador. A linguagem
utilizada neste SO é uma linguagem orientada a eventos específica para RSSFs
derivada da linguagem C, denominada NesC.
Relativamente à comunicação, o TinyOS disponibiliza duas abstrações básicas
de encaminhamento multihop [13]: árvore de coleta e de disseminação. Na árvore
de coleta, os nós organizam-se entre si numa árvore de encaminhamento centrada
num único nó, o nó raiz, que normalmente é uma estação base. Todas as
mensagens enviadas na árvore, automaticamente até ao nó raiz. As árvores de
coleta são normalmente utilizadas para coletar dados de uma rede de sensores.
Na disseminação, é distribuído de forma eficaz um valor, ou uma estrutura de
dados com vários campos, para todos os nós da rede. Posteriormente, cada nó pode
atualizar esse valor e a rede eventualmente acabara por receber a versão mais
atualizada do mesmo. A disseminação é normalmente utilizada para alterar
configurações em tempo de execução das aplicações que correm nos nós.
No que diz respeito à camada MAC, o TinyOS oferece uma implementação dos
seguintes protocolos: um protocolo de comunicação single-hop com TDMA, o
protocolo híbrido (TDMA/CSMA) Z-MAC, o protocolo B-MAC e uma implementação
opcional de segurança na camada MAC mantendo a compatibilidade com o IEEE
802.15.4.
22
Embora o TinyOS seja portável para outras plataformas, este tem uma curva de
aprendizagem relativamente grande. As grandes razões subjacentes à complexidade
do TinyOS são:
A natureza baseada em eventos do TinyOS: a programação baseada em
eventos é mais complexa para os programadores, na medida que é
necessário ter em mente que várias operações estão a ser executadas ao
mesmo tempo.
Arquitetura modelar: muito código com elevado nível de modularidade faz
com que a lógica do programa fique distribuída em muitos componentes.
Cada nova funcionalidade pode requerer alterações em vários componentes,
exigindo um conhecimento profundo do sistema interno de estruturas do
NesC, que é pouco familiar até para programadores experientes em C e
sistemas embutidos.
Estas limitações são ao nível do desenho do próprio SO pelo que não têm uma
solução simples. A alternativa mais conveniente e mais usada é a utilização de
middleware sobre o TinyOS, de forma simplificar o desenvolvimento de aplicações
aos programadores iniciantes.
23
Figura 2.10: Arquitetura do sistema operativo TinyOS [9].
2.4 Aplicabilidade
Com a evolução do hardware, os nós sensores são cada vez mais capazes de
efetuar tarefas complexas sem afetar a sua eficiência energética. Está também
disponível uma grande quantidade de sensores que permitem medir vários fatores
do meio como: temperatura, humidade, pressão, luminosidade, ruído, a presença
ou falta de determinados compostos químicos etc. Esta grande variedade de opções
de monitorização faz com que as RSSFs possam ser utilizadas em variadíssimas
aplicações desde a monotorização de ambientes até à segurança de espaços. De
seguida, são dados alguns exemplos de áreas de aplicação onde as RSSFs estão a
ser uma mais-valia.
2.4.1 Monotorização de Ambientes
A monitorização ambiental é uma das primeiras e principais áreas de aplicação
das RSSFs. Neste tipo de aplicações, muitas vezes devido à grande área de
monitorização ou ao difícil acesso à mesma, é impraticável utilizar sensores
24
tradicionais com ligações estruturadas assentes em cabos. Assim sendo, a utilização
de uma tecnologia como as RSSFs tem sido amplamente adotada. Sonoma Dust
[14] é uma RSSF constituída por 120 Mica2dot que foi instalada no condado de
Sonoma para monitorizar o habitat das árvores de madeira vermelha. Estes nós
sensores correm o TinyOS e estão programados para medir condições ambientais
como temperatura, humidade e luminosidade a cada 5 minutos. Esta informação é
depois enviada através de uma topologia em malha até à estação base, que envia
a informação para um computador a 70 Km de distância. Em [15] é utilizada uma
RSSF para monitorizar o vulcão Tungurahua no centro do Equador. São utilizados
5 nós sensores, onde 3 possuem um microfone especial para captar sons infra-
sónicos originados por vulcões quando entram em erupção.
2.4.2 E-Health
O termo “e-Health” é utilizado para referir o uso de tecnologia de informação e
comunicação (ICT) na prestação de serviços de saúde [16], tendo sido uma área
muito procurada para projetos de investigação e desenvolvimento. Uma das
vertentes mais exploradas passa pela monitorização de pacientes fora do ambiente
hospitalar. Devido ao seu tamanho reduzido, os nós sensores podem ser embutidos
em peças de vestuário tornando-se ideais para esta tarefa. Em [17], Wan-Young
apresenta um sistema ubíquo, não-intrusivo, que permite monitorizar os níveis de
oxigénio no sangue (SpO2), a atividade cardíaca através de um eletrocardiograma
(ECG), e os movimentos do paciente através de acelerómetros. O sistema transmite
esta informação para um terminal ligado a um computador onde os dados podem
ser acedidos através de aplicações externas.
O ALARM-NET é apresentado em [18] como um sistema que permite uma
monitorização não-intrusiva e adaptativa do estado de saúde de um paciente. Este
sistema implementa uma RSSF que recolhe os sinais vitais do paciente e cria um
historial de saúde. Esta informação é utilizada por pessoas autorizadas e ligadas à
área da medicina para monitorizar o estado de saúde dos pacientes de uma forma
constante, sem que estes tenham de se deslocar ao hospital.
25
A monitorização dos sinais vitais pode ser feita não só por razões ligadas à saúde
mas também para a melhoria do desempenho desportivo, quer de atletas
profissionais quer de amadores. Em [19] é apresentada a arquitetura e a
implementação de um sistema de apoio a corredores de corta-mato baseado em
RSSFs. Neste sistema são utilizados nós sensores no atleta e ao longo da pista que
este está a percorrer. Os nós no atleta recolhem informação do seu estado físico
como o ritmo cardíaco, oxigénio no sangue e a velocidade a que este está a correr.
Por outro lado, os nós que estão espalhados pela pista recolhem dados do meio
ambiente como a temperatura, humidade e velocidade do vento. O objetivo é utilizar
esta informação para determinar o percurso que o atleta deve seguir para que os
seus sinais vitais se mantenham nos níveis desejados. Outro exemplo é apresentado
na em [20], onde foi desenvolvido e testado um sistema que recolhe dados do
ambiente e do utilizador. Esta informação é utilizada para sugerir exercícios
baseados no perfil do utilizador de forma a melhorar a sua performance.
2.4.3 Outras áreas de aplicação
As RSSFs estão a ser aplicadas nas mais diversas áreas devido à sua grande
versatilidade e baixo custo. Um dos exemplos é a indústria, que sempre esteve
interessada em sistema económicos de monitorização que permitissem aumentar a
sua produtividade e segurança. A monitorização do estado de “saúde” das máquinas
através das medições de determinados aspetos (e.g. vibração, desgaste e
lubrificação), permite detetar anomalias e evitar falhas no funcionamento das
mesmas. A utilização das RSSFs permite uma rápida instalação de equipamento
capaz de fazer esta monitorização, podendo ser colocadas em locais de difícil acesso
onde redes com cabos seriam impossíveis. O projeto GINSENG é um exemplo da
integração das RSSFs na indústria, tendo participação de investigadores
portugueses [21] . Uma área também em expansão é a da monitorização estrutural
de edifícios. Neste tipo de aplicações, os nós sensores são colocados juntamente
com os materiais de construção do próprio edifício, permitindo assim, monitorizar
em tempo-real a integridade física do edifício [22] [23].
26
A área militar é sem dúvida também uma área onde as RSSFs fornecem uma
mais-valia devido à sua facilidade de implementação, grande densidade e custo
reduzido. Desta forma, nós podem ser lançadas em cenários hostis de forma a
fornecer informações valiosas sobre o campo de batalha [24].
2.5 Sumário
Neste capítulo foram analisadas as características de uma RSSF no que diz
respeito à constituição típica dos nós e à comunicação suportada neste tipo de redes
relativamente às normas e topologias. Foi ainda feito um levantamento dos sistemas
operativos mais utilizados nas redes de sensores focando a sua arquitetura, suporte
à comunicação e portabilidade. Por fim, foram identificados alguns trabalhos
relacionados com a implementação de RSSFs em diversas áreas, destacando-se a
monitorização de ambientes e a área da saúde.
O próximo capítulo aborda as questões relacionadas com a reprogramação
remota nas RSSFs, nomeadamente os principais desafios que esta área apresenta
e os principais trabalhos que têm sido propostos ao longo do tempo.
27
3. Reprogramação remota de Redes de Sensores Sem Fios
Neste capítulo são abordados os trabalhos que têm vindo a ser desenvolvidos
na área da reprogramação remota de RSSFs. Assim sendo, numa primeira secção
são identificados e discutidos os principais desafios da reprogramação remota nas
redes de sensores. Numa segunda secção, são identificados alguns trabalhos
relacionados com a reprogramação remota de RSSFs com base no tipo de
reprogramação que utilizam.
3.1 Desafios da reprogramação remota nas RSSFs
A reprogramação das RSSFs é essencial para garantir a versatilidade deste tipo
de redes. As necessidades de reprogramação prendem-se com as mais variadas
razões como por exemplo, atualizações de software, melhorias de segurança ou
alterações nos objetivos aplicacionais. Para tal, há necessidade de disseminar o
código que se pretende instalar nos nós utilizando a comunicação sem fios pois,
muitas vezes, esta é a única forma de alcançar os nós depois de estes terem sido
colocados no meio.
Reprogramar remotamente os nós de uma RSSF levanta uma série de desafios,
pois tratam-se de plataformas com recursos muito limitados. Todas as operações
que são feitas no nó gastam energia, sendo que a receção e o envio de dados através
da comunicação sem fios são as que mais consomem. Na reprogramação remota
dos nós as atualizações de código devem chegar a todos os nós da rede na sua
totalidade (sem erros nem perdas). Outro fator a ter em conta é que os nós também
possuem severas restrições ao nível da memória e processamento. Neste sentido,
como se espera que a reprogramação seja um serviço suportado por todos os nós
28
da rede, esta deve ter pouco impacto na memória dos mesmos deixando assim
espaço para a lógica aplicacional e do sistema operativo.
Apesar do impacto energético que a reprogramação remota tem nos nós ser uma
preocupação assente nesta área, quanto mais se otimiza a reprogramação ao nível
energético, por norma mais se compromete a flexibilidade da solução. Esta
flexibilidade diz respeito à portabilidade da solução para diferentes plataformas e à
alteração de funcionalidades da própria solução (e.g. otimizações da solução), que
estão diretamente ligadas à forma como a reprogramação é feita nos próprios nós.
A reprogramação pode ser feita de duas formas: (i) uma reprogramação total, onde
todos os nós são reprogramados com a mesma aplicação; ou (ii) uma
reprogramação seletiva, onde apenas um conjunto especifico de nós é
reprogramado. A reprogramação seletiva é fundamental, na medida que permite que
uma RSSF possua múltiplas aplicações e plataformas, aumentando assim a sua
versatilidade e aplicabilidade.
Assim sendo, os principais desafios na reprogramação remota prendem-se
sobretudo com o fato de encontrar soluções que tenham um bom desempenho com
baixo impacto nos recursos dos nós das redes de sensores, ao mesmo tempo que
devem oferecer um bom nível de flexibilidade.
3.2 Tipos de reprogramação
O primeiro passo na reprogramação sem fios dos nós é saber quando existe a
necessidade de reprogramar e que parte do código necessita ser alterado, todo ou
parcial. Esta decisão pode ser tomada pelo utilizador ou automaticamente pela rede.
No primeiro caso, a ordem para se iniciar a reprogramação em cada nó é sempre
dada pelo utilizador, enquanto os nós comportam-se simplesmente como “escravos”
executando as ordens recebidas. Nesta forma de reprogramação, o utilizador decide
quando quer reprogramar cada nó baseado nas suas decisões ou então pode utilizar
um sistema especifico para inferir o estado de cada nó e determinar se existe a
necessidade de reprogramação. O SNMS (Sensor Network Management System)
29
[25] é um exemplo deste tipo de sistemas, fornecendo um protocolo que permite
criar uma árvore da topologia da rede e um sistema de perguntas que permite inferir
o estado e desempenho da mesma. Estas respostas são armazenadas e caso exista
necessidade de alterar o código nos nós, é utilizada esta árvore juntamente com o
DRIP1. A vantagem deste tipo de sistemas, que utilizam árvores, é que não existe a
necessidade dos nós terem nas suas tabelas de encaminhamento todos os vizinhos,
pois só precisam de saber qual a sua posição na árvore e qual o próximo salto. A
desvantagem é que este tipo de sistemas só funciona em redes onde os nós são
estáticos.
No segundo caso, onde a decisão de reprogramação é tomada pela própria rede,
o utilizador transmite a nova versão do código para pelo menos um nó. Neste caso,
os nós comunicam uns com os outros, avaliam se a sua versão de código está
desatualizada e se necessário iniciam a disseminação e atualização do código. Este
tipo de abordagem é sem dúvida a mais utilizada, pois permite reconfigurar todo o
tipo de nós, móveis e estáticos, além de permitir uma maior autonomia à rede.
Existem muitos protocolos que permitem a reprogramação de RSSFs que
diferem na forma como tratam as questões da disseminação do código e da técnica
que utilizam na reprogramação dos nós. No processo de disseminação podem ser
utilizadas diferentes abordagens de forma a maximizar o seu desempenho,
nomeadamente: (i) seleção dos nós que vão transmitir os dados (e.g. ter muitos nós
a transmitir localmente ao mesmo tempo aumenta a probabilidade de colisões e
não garante a otimização dos recursos); (ii) gestão da fragmentação dos dados, de
forma a ter em conta o limite de memória e recursos dos nós; e (iii) esquemas de
garantia de fiabilidade que permitem detetar perdas e gerir as retransmissões (e.g.
podem ser feitas por unicast, broadcast ou multicast, podendo também ser
utilizadas técnicas como Forward Error Correction). Contudo, estas abordagens vão
depender do tipo de reprogramação que está a ser utilizada, ou seja, a forma como
1 DRIP-Protocolo de disseminação que oferece uma camada de transporte para que os canais
possam fazer a disseminação do código.
30
a reprogramação é feita no próprio nó, que tem influência direta no que é enviado
na disseminação e como é que esta é feita.
As métricas para avaliar os protocolos de reprogramação prendem-se
principalmente com: (i) questões de sobrecarga (overhead); (ii) o gasto energético,
que tem influência direta no tempo de vida dos componentes da rede; (iii) a latência
na deteção da necessidade de atualizações; e (iv) o tempo da própria disseminação.
Em seguida são apresentados e discutidos os trabalhos desenvolvidos na área
da reprogramação das RSSFs com base nos tipos de reprogramação utilizados.
3.2.1 Reprogramação Modular
A arquitetura modular é ideal para a reprogramação sem fios dos nós. Ao
contrário das arquiteturas monolíticas, qualquer mudança no sistema é local e assim
sendo, somente os módulos modificados necessitam de ser transmitidos. Os
sistemas que suportam reprogramação modular consistem num loader e num linker.
O loader é responsável por identificar e alocar a memória necessária para os novos
módulos, enquanto o linker, resolve qualquer referência feita pelos módulos ao
kernel, bibliotecas comuns ou qualquer outro módulo do sistema.
O Contiki [2] é o primeiro sistema operativo que suporta reprogramação
modular. O seu núcleo, à exceção do bootloader, é um componente não
reprogramável não suportando alterações ao kernel, tabelas de símbolos e interfaces
de comunicações. Contudo, um conjunto de funcionalidades como suporte ao
sistema de ficheiros, interface, gestão de energia, etc., são módulos reprogramáveis.
O Contiki permite a reprogramação com linking e loading dinâmico do código nativo
através do uso de ficheiros ELF (Executable and Linkable Format). Este tipo de
ficheiros não são só um padrão nos objetos de formato binário em muitos
computadores, como também, podem ser utilizados em sistemas embebidos com
recursos limitados. Utilizando o padrão ELF, o linker dinâmico do Contiki pode
dinamicamente ligar, realocar e carregar novos módulos.
O LiteOS [10] utiliza a mesma estratégia de relocação de memória que o Contiki,
contudo, ao contrário deste, o LiteOS utiliza o formato Intel HEX (iHEX) para guardar
31
a informação referente à realocação. Os ficheiros do tipo iHEX requerem menos
espaço de memória que os ELF. Apesar de o LiteOS ter um nível de abstração similar
aos sistemas UNIX, a reprogramação modular acaba por ser bastante simples para
o utilizador.
Apesar dos sistemas modulares facilitarem a reprogramação, estes possuem
grandes desvantagens como o uso de grandes quantidades de memória e execução
lenta. A fiabilidade pode também ser um problema, visto que, módulos que
possuam algum erro ou tenham sido pouco testados podem afetar o funcionamento
de toda a rede.
3.2.2 Máquinas virtuais
Uma máquina virtual fornece um ambiente completo para a execução de
programas escritos na sua linguagem própria (geralmente linguagem de script). A
máquina virtual disponibiliza um conjunto de instruções da sua linguagem para que
sejam criadas aplicações, e em tempo de execução, essas instruções são
interpretadas e executadas na plataforma alvo. A reconfiguração de software numa
máquina virtual é realizada de forma simples, sendo necessário apenas o envio das
instruções que compõem a aplicação.
Maté [26] é uma máquina virtual que é executada sobre o sistema operativo
TinyOS. Esta disponibiliza 8 instruções (bytecodes) que podem ser interpretadas.
Os bytecodes limitam o número de aplicações que podem ser construídas e
possuem um tamanho menor do que o código nativo, diminuindo o consumo de
energia na transferência dos dados. Entretanto, para aplicações que executam
durante um longo período, a energia gasta para interpretar o código supera essa
vantagem.
O SensorWare [27] provê uma máquina virtual que suporta a programação dos
nós através de uma linguagem de script para sensores com maior poder de
processamento e memória. O SensorWare ocupa 179 kBytes de memória divididos
pelo interpretador da linguagem baseada em Tcl, o Kernel do SensorWare e o código
32
dependente da plataforma, sendo utilizados comandos para replicar ou migrar o
código e dados de um nó para outros nós sensores da rede através de scripts.
A VM* [28] é um framework que permite a construção de uma máquina virtual
capaz de interpretar aplicações escritas em linguagem Java. Foram feitas
otimizações para reduzir o sobrecusto introduzido pela máquina virtual. A
framework é formada por um interpretador que executa os bytecodes em Java, uma
pequena API para o acesso aos dispositivos e um sistema operativo para suportar o
escalonamento de tarefas e alocação dinâmica de memória. A máquina virtual provê
instruções (e.g. copy, run e add) pare executar uma atualização. O suporte para
reconfiguração dinâmica é fornecido por um linker incremental e um bootloader,
sendo introduzidos no sistema somente se a atualização de código for necessária.
Para reduzir o efeito de uma atualização quando ocorre o deslocamento de código
(e.g. aumento de código numa função), são deixados espaços de memória em
branco entre as funções. Assim, quando uma função cresce, não existe a
necessidade de trocar a função de posição na memória. Contudo, esta abordagem
aumenta o consumo de memória.
A Tapper [29] é uma máquina virtual que utiliza a sua própria linguagem de
script e não necessita de um ambiente de execução, como um sistema operativo,
para ser executada. Esta máquina virtual é composta por um gestor de espaço de
armazenamento (buffers), um interpretador e componentes do sistema como
temporizador, ADC, SPI, etc. A Tapper foi implementada em diferentes plataformas
de sensores e diversos tipos de microcontroladores, variando desde uma arquitetura
AVR de 8-bits com 4 kBytes de RAM até a Freescale 16-bits com o protocolo TCP/IP.
O tamanho do código da máquina virtual varia de 3 kBytes a 11 kBytes e os dados
de 230 Bytes a 1.5 kBytes dependendo da arquitetura. O processo de
reconfiguração é executado pelas instruções “+” e “-”. Por exemplo, a instrução
+func carrega a função “func” no sistema enquanto a instrução -func faz
precisamente o contrário. Estas instruções são executadas na estação base que
possui o conhecimento sobre a memória e o código em cada nó da rede.
33
3.2.3 Reprogramação ao nível do sistema
A reprogramação ao nível do sistema continua a ser a forma mais fácil e mais
comum de reprogramar uma rede de sensores sem fios. Neste tipo de
reprogramação, a aplicação que corre no nó é substituída na íntegra por uma
imagem binária da nova aplicação, juntamente com o código relativo ao sistema
operativo. Desta forma, a substituição é completa não só a nível aplicacional como
a nível do sistema operativo. Neste processo, a nova imagem é guardada na
memória flash externa sendo depois copiada para a memória interna do
microcontrolador através de um bootloader. Os sistemas com uma arquitetura
monolítica, como o TinyOS [1] e o Nano-RK [12], graças à sua imagem estática,
enquadram-se perfeitamente neste tipo de estratégia de reprogramação.
Esta técnica de reprogramação pode-se enquadrar em dois tipos de abordagens
diferentes no que diz respeito ao envio do novo código. Uma das abordagens
consiste em enviar todo o código para os nós enquanto a outra passa pelo envio das
diferenças entre versões de código (delta). Na primeira abordagem é utilizada a
funcionalidade básica da reprogramação onde o nó recebe o código e inicia
imediatamente a sua reprogramação. Contudo, na segunda abordagem, o nó recebe
apenas o delta e utiliza esta informação para gerar o novo código e só depois inicia
a sua reprogramação.
3.2.3.1 Estratégias baseadas na distribuição de toda a imagem do código
Apesar de esta abordagem ser bastante simples e robusta é também ineficiente,
pois o grande tamanho das imagens do código implicam um maior gasto energético
na transmissão. Além disso, mesmo uma pequena alteração no código obriga a que
seja gerada uma nova e completa imagem de código para ser transmitida para a
rede, e assim se efetuar a reprogramação dos nós.
O Crossbow Network Reprogramming Protocol (XNP) [30] é o módulo de
reprogramação utilizado no TinyOS versão 1.1. Este implementa a função básica de
reprogramação fazendo broadcast do novo código para múltiplos nós por
34
comunicação single-hop bidirecional, dentro do raio de alcance da estação base.
Contudo, este protocolo não suporta métodos para reduzir o tamanho das imagens
do código, nem comunicação multihop.
O Deluge [4] utiliza anúncios de versões de código para detetar a necessidade
de atualizações na rede. Além disto, este protocolo divide o código a ser transmitido
num conjunto de páginas com tamanho fixo. Esta rigidez no tamanho do conteúdo
a ser transmitido permite multiplexação espacial, pois cada página é encarada como
um objeto independente. Desta forma, a propagação do código é feita mais
rapidamente.
O Stream [31] é baseado no Deluge e otimiza o que é enviado pelo canal de
comunicação. No Stream, é instalado em cada nó o protocolo de reprogramação
antes de este ser colocado no meio. Este processo é feito através da segmentação
da memória flash. A vantagem é que, ao contrário do que acontece no Deluge onde
é enviado a imagem do código e o protocolo de reconfiguração, no Stream é enviada
a imagem do código e apenas a informação sobre qual o protocolo de reprogramação
a utilizar. Isto faz com que a sobrecarga da rede diminua bastante, tornando-o assim
mais eficiente a nível energético e mais rápido. Este protocolo é implementado no
TinyOs na família Mica.
O DStream [32] é um protocolo híbrido que tem a capacidade de reprogramação
single-hop e multihop. É baseado no Stream tirando partido de todas as suas
vantagens em relação ao tamanho do código a ser enviado e à segmentação da
memória. Os autores concluíram que, tal como seria espectável, a reprogramação
single-hop pode ser mais rápida e energeticamente mais eficiente que a
reprogramação multihop em determinados cenários. Assim sendo, foram utilizadas
análises matemáticas e cenários simulados e reais para identificar as condições que
favorecem a reprogramação single-hop e multihop. Os autores concluíram que para
redes onde as ligações são bastante fiáveis, a reprogramação multihop é favorecida;
contudo, para redes que sejam lineares (ou próximo de lineares) a reprogramação
singe-hop tende a ser melhor.
35
O Infuse [33] é um protocolo fiável de disseminação que utiliza o TDMA como
estratégia de acesso ao meio. O Infuse utiliza comunicação multihop e permite: (i)
selecionar o algoritmo para lidar com a recuperação de erros inesperados
provenientes do canal de transmissão (e.g. erro na receção das mensagens,
variações da força do sinal); e (ii) especificar quando um nó deve ouvir um conjunto
de nós vizinhos de forma a reduzir o tempo de escuta. Baseado nas opções tomadas,
é possível obter quatro modos de operação do Infuse.
O OAP-SW [34] é apresentado pelos autores como sendo um protocolo que
utiliza características de pequeno mundo (Redes de pequeno mundo2) para
melhorar a reconfiguração da rede. Este protocolo cria atalhos dentro da rede até
aos nós que têm maior capacidade de processamento e utiliza-os na reprogramação.
Provou-se que os tempos de reconfiguração foram drasticamente reduzidos e que o
consumo energético da rede não foi consideravelmente afetado com o uso de um
pequeno conjunto de nós mais potentes.
O Gappa [35] é um protocolo epidémico multihop, onde alguns nós recebem
uma parte do novo código por um canal e transmitem aos vizinhos o que acabaram
de receber por um canal distinto. Ao explorar a comunicação por multi-canal e a
técnica de pipeline, o Gappa possibilita uma elevada concorrência em diferentes
canais e em diferentes localizações, permitindo assim uma rápida transmissão de
dados. Para reduzir as colisões em cada canal, o Gappa utiliza um algoritmo de
seleção de emissor multi-canal que tenta garantir que, em qualquer vizinhança, está
a transmitir no máximo um emissor de cada vez por canal. Durante este processo
existe uma tentativa de dar preferência aos emissores que tenham mais impacto na
rede. Se um emissor não conseguir transmitir num canal, pode tentar escolher outro
canal e, caso não consiga em nenhum, o nó deixa de enviar pedidos de autorização
da transmissão. Durante este tempo, o nó pode escolher receber o código, deixando
2 Redes de pequeno mundo: é um tipo de grafo matemático no qual grandes partes das conexões são estabelecidas
entre os vértices mais próximos, apresentando se como um mundo pequeno. Neste tipo de rede, a distância média entre
quaisquer dois vértices não ultrapassa um número pequeno de vértices.
36
para isso o seu módulo de comunicação ligado, ou desligado caso esteja a funcionar
só como emissor e tenha pouca bateria. Desta forma o Gappa diminui também o
tempo em que o módulo de comunicação de cada nó está ativo, diminuindo assim
o consumo energético durante a reprogramação.
O Multihop Over-the-Air Programming (MOAP) [36] é um mecanismo de
distribuição de código especialmente construído para os nós Mica-2. O MOAP foi
desenhado para ser eficiente ao nível da memória e da energia à custa do aumento
da latência. As escolhas no desenho foram baseadas em três áreas: protocolo de
disseminação, mecanismos de retransmissão e gestão de armazenamento dos
segmentos de código.
3.2.3.2 Estratégias baseadas na distribuição de diferenças entre imagens de
código
Esta abordagem tenta resolver os problemas inerentes ao envio de toda a
imagem do novo código. Neste caso, a estação base gera e envia um delta que
consiste nas diferenças entre o código que está instalado nos nós e o novo código
que se pretende colocar nos mesmos. Os nós recebem este delta e geram a nova
imagem de código com base na informação do próprio delta e do código que estão
a correr.
O Rsync [37] é um protocolo bem conhecido de atualizações incrementais
usado em computadores e servidores. O Rsync divide o programa em diferentes
blocos e calcula o valor de hash para cada um deles. Os valores calculados são
depois utilizados para determinar se se trata de uma inserção, eliminação ou
modificação de um bloco.
O Zephyr [38] é apresentado como sendo um protocolo de reprogramação
incremental. Neste protocolo, é enviado um delta para cada nó quando existe a
necessidade de uma atualização. Em [39], os autores do Zephyr apresentam o
Hermes, como sendo uma melhoria do Zephyr. Este protocolo reduz o tamanho do
37
delta utilizando técnicas para atenuar o efeito de mudanças em funções e variáveis
globais causadas pelas diferenças no código.
O R2 [40] reduz o tamanho do delta através da utilização eficiente de módulos
dinâmicos de loading e linking. No R2 são utilizados metadados que são enviados
para os nós de forma a eliminar a utilização de uma jump table (que é um requisito
no Hermes [39] e Zephyr [38]) e um bootloader complexo. Este protocolo foi
implementado no TinyOS 2.1 sendo comparado com o Deluge [4], o Zephyr e o
Hermes, onde mostrou uma redução no custo de transmissão de 65% quando
comparado com o Deluge e 20% quando comparado com o Zephyr e Hermes.
Através da utilização do delta, a quantidade de informação que é enviada para
a rede diminui consideravelmente. Contudo, a grande desvantagem deste tipo de
estratégia é que são executados algoritmos complexos e pesados nos nós para criar
a nova imagem de código com base no delta.
3.3 Sumário
Neste capítulo foram identificados e discutidos os principais desafios da
reprogramação remota nas RSSFs. Foram ainda identificados alguns trabalhos na
área da reprogramação remota das redes de sensores com base no tipo de
reprogramação que utilizam, tendo sido dado mais destaque aos trabalhos
relacionados que utilizam o mesmo tipo de reprogramação que o Deluge, ou seja,
a reprogramação ao nível do sistema.
No próximo capítulo são discutidos os detalhes de desenho e implementação
de um protocolo que permite a reprogramação seletiva de uma RSSF.
38
4. Desenho e Implementação do Protocolo
Este capítulo trata as questões de desenho e implementação de uma extensão
ao Deluge e DRIP. Numa primeira secção é feito um estudo sobre a forma como a
reprogramação é originalmente feita com o Deluge. Desta forma, são identificados
todos os componentes que são utilizados durante o processo de reprogramação
juntamente com o Deluge. Com base neste estudo prévio, na segunda secção são
discutidos os detalhes de desenho e implementação de uma extensão ao Deluge e
DRIP que funciona como um novo protocolo sempre que se pretende uma
reprogramação seletiva da rede.
4.1 Reprogramação com o Deluge
O primeiro passo para a construção de uma extensão ao Deluge que permitisse
uma reprogramação seletiva foi analisar e estudar o comportamento do próprio
Deluge. Este processo é fundamental, pois só assim é possível identificar as funções
e os componentes que necessitam ser alterados.
Esta secção é destinada à análise do funcionamento do Deluge e dos
componentes que este usa no processo de reprogramação.
4.1.1 Deluge 2.0
O Deluge é um protocolo epidémico que utiliza a interface rádio dos nós para
disseminar uma imagem de código (binário de uma aplicação) por toda a rede. Para
tal, o Deluge divide a imagem do código em páginas de tamanho fixo e cada página
num conjunto de pacotes a enviar, ver Figura 4.1. Combinando esta característica
com um bootloader e uma série de comandos que podem ser executados através
da estação-base, é possível reprogramar os nós com novas aplicações sem recorrer
ao método tradicional de ligação cablada.
39
A versão atual do Deluge suportada por defeito no TinyOS é a 2.0, e tem como
principal objetivo a fiabilidade e robustez. As plataformas que este protocolo suporta
nativamente são Telos B [41], Micaz [42], Epic [43], Iris [44] e TinyNode [45].
Figura 4.1:Segmentação da imagem de código no processo de disseminação da mesma.
O Deluge corre paralelamente à aplicação principal que está a ser executada em
cada nó. O processo para a aquisição de uma nova imagem de código ou parte dela
é o seguinte:
1. Os nós enviam periodicamente anúncios em broadcast contendo o
número da versão da imagem de código e a informação de que página
dessa imagem possuem. O tempo entre anúncios pode ser alterado para
conservar energia elétrica e largura de banda.
2. Quando um nó, através dos anúncios recebidos, determina que
necessita de fazer o upload de alguma parte da nova imagem, espera
um determinado período de tempo enquanto escuta todos os anúncios
dos vizinhos. Este tempo de espera permite que sejam utilizadas
heurísticas para escolher o melhor transmissor vizinho.
40
3. Quando o período de escuta termina, o nó envia um pedido ao vizinho
que foi escolhido indicando a página e as secções requeridas dentro
dessa página.
4. Quando o vizinho recebe um pedido deste género envia a informação
solicitada em broadcast.
5. Após o nó receber o último pacote que completa a página de código que
foi pedida, e antes de pedir o resto das páginas ao vizinho, este envia
um anúncio em broadcast sobre a nova página que acaba de receber.
Esta estratégia permite que seja utilizada multiplexagem espacial.
As imagens de código recebidas pelos nós são guardadas na sua memória
externa, em espaços denominados de volumes (volumes 0, 1, 2 e 3). Por defeito,
o Deluge está configurado para suportar no máximo 3 imagens de código ao mesmo
tempo, já que o volume 0 é reservado para a GoldenImage. Esta imagem de código
específica é uma aplicação disponibilizada pelo TinyOS que apenas possui o
Deluge, sendo utilizada para colocar o nó num estado que possa ser reprogramado
remotamente quando ocorrem falhas.
Quando os nós contêm as imagens corretas do código, o controlo da
reprogramação é feito através de um protocolo de disseminação para pequenas
quantidades de dados, denominado DRIP, que será explicado na secção seguinte.
4.1.2 Disseminação e o DRIP
A disseminação é um protocolo básico nas redes de sensores que tem como
objetivo entregar de forma fiável um conjunto de dados a todos os nós da rede. Este
protocolo permite alcançar a coerência de um valor de uma determinada variável
partilhada na rede. A variável partilhada pode ser de qualquer tipo, desde um
simples inteiro a uma estrutura de dados mais complexa. O serviço de disseminação
permite avisar os nós quando o valor dessa variável foi alterado e trocar pacotes,
denominados anúncios, de forma que esta informação chegue a todos os nós na
rede. Esta capacidade de entregar de forma fiável um conjunto de dados a todos os
41
nós da rede viabiliza tarefas de reconfiguração e reprogramação de uma rede de
sensores. Ao contrário dos protocolos epidémicos, que apenas têm a preocupação
de fazer chegar a informação a toda a rede não garantindo que todos os nós a
receberam corretamente, nos protocolos de disseminação é garantido que todos os
nós vão eventualmente receber a informação correta. Isto é feito através da troca
regular de anúncios que permitem a deteção dos nós que não possuam a
informação pretendida.
Dependendo da quantidade de dados, os protocolos de disseminação
diferenciam-se no seu modo de operação. Disseminar de forma eficiente dezenas
de kBytes requer um protocolo diferente de uma situação em que apenas se
pretende disseminar um inteiro de 2 Bytes. Assim, os protocolos de disseminação
podem ser divididos em dois tipos consoante o tamanho das unidades que estão a
disseminar, sendo referidos como tráfego de controlo, e tráfego de dados [46]. Ao
contrário do que acontece no tráfego de dados, onde o tamanho dos dados varia
consideravelmente, no tráfego de controlo os dados tendem a ser do mesmo
tamanho.
O TinyOs oferece diferentes tipos de protocolos de disseminação para tráfego de
controlo, sendo um deles o DRIP. Este protocolo é utilizado pelo Deluge na
reprogramação da rede.
Neste tipo de disseminação de tráfego de controlo, podem existir várias variáveis
partilhadas na rede, onde os valores de cada uma são envidados em anúncios
identificados por um par Chave/Número de Sequência. A Chave identifica a variável
partilhada e o Número de Sequência a versão do valor que está a ser disseminado.
Devido à pouca memória RAM dos nós nas redes de sensores, o DRIP, tal como os
outros protocolos de disseminação do TinyOS, apenas propaga o valor com a versão
mais atual. A disseminação é controlada por um algoritmo chamado Trickle [47],
que gere a quantidade de anúncios feitos por um nó ao longo do tempo. De uma
forma simples, o Trickle oferece uma gestão de anúncios através de um
temporizador que assinala quando deve ser feito um anúncio. O intervalo de tempo
definido pelo temporizador vai aumentando sempre que é enviado um anúncio ou
42
o nó recebe de um vizinho um anúncio com a mesma versão do que está a anunciar.
Desta forma, um nó começa a anunciar o novo valor mas deixa de o fazer quando
recebe dos vizinhos o mesmo anúncio. Isto faz com que exista um grande número
de anúncios numa fase inicial da disseminação. Porém, ao longo do tempo a rede
vai convergindo para um estado de manutenção, onde apenas alguns anúncios são
feitos ao longo do tempo. Quando existir um valor mais atual a ser disseminado,
todo o processo recomeça sabendo que os valores a disseminar não podem exceder
o tamanho máximo de um pacote. No TinyOS, o Trickle é implementado através de
um TimerTrickle, sendo que no DRIP cada variável partilhada tem o seu próprio
TimerTrickle que gere a disseminação dos seus valores.
O Deluge utiliza o DRIP de forma a alcançar todos os nós da rede, para que
estes executem uma determinada tarefa, como, por exemplo, uma reprogramação.
A Figura 4.2 apresenta a estrutura do pacote utilizado na reprogramação do Deluge.
Os primeiros 6 Bytes dizem respeito ao protocolo DRIP, onde os dois primeiros Bytes
correspondem à Chave e os outros 4 Bytes ao Número de Sequência. Os restantes
10 Bytes dizem respeito a dados de reprogramação do Deluge, onde o 1 Byte
identifica a ação a ser executada no nó e os restantes 9 Bytes identificam
inequivocamente a aplicação a que a ação diz respeito. As ações a serem
executadas podem ser a de disseminação de uma aplicação ou a de disseminação
e reprogramação. Na primeira, quando um nó recebe um anúncio verifica se possui
a aplicação que deve disseminar, utilizando para isso a informação sobre aplicação
contida no anúncio recebido. Caso este não possua a aplicação correta, pede ao
vizinho que fez o anúncio para lhe enviar a aplicação para que este a possa depois
disseminar para outros nós. Na ação de disseminar e reprogramar o processo é o
mesmo que o anterior, no entanto, o nó reprograma-se imediatamente após ter a
aplicação correta
O Deluge permite apenas reprogramação total da rede garantindo que
eventualmente todos os nós vão receber a ordem do utilizador. Os nós que possam
estar desconetados da rede, quando voltarem a ter conetividade, podem
43
eventualmente receber um anúncio atualizado de um vizinho graças ao estado de
manutenção do DRIP.
Figura 4.2: Estrutura do pacote enviado por defeito pelo Deluge [5].
4.1.3 TosBoot
O Deluge por si só não é capaz de reprogramar o microcontrolador com uma
imagem guardada na memória externa. Para tal, é utilizado o bootloader do TinyOS,
ou seja, o TosBoot [48], que possui um conjunto de mecanismos que tornam este
processo possível.
O TosBoot é um programa independente que só pode ser instalado no nó através
de uma ligação com cabo e é sempre executado quando o nó sai do estado de reset,
ou seja, quando este se liga. O fato de ser um programa independente significa que
nenhum estado não-volátil deixado pelo microcontrolador antes de este ter sido
reiniciado vai afetar a sua execução. Desta forma, todos os parâmetros passados ao
TosBoot são passados através de memória não-volátil, garantindo assim um correto
funcionamento mesmo quando o nó tem uma falha de energia quando está a iniciar.
Os parâmetros passados ao TosBoot incluem: (i) o número de interrupções
consecutivas ao correto arranque do TosBoot; (ii) se existe necessidade de
programar o microcontrolador; e (iii) a localização na memória externa da imagem
de código com a qual se deve reprogramar o microcontrolador.
É possível ver quando o TosBoot está instalado no nó através de uma contagem
decrescente sinalizada por LEDs (caso existam) sempre que o nó é iniciado. Quando
44
a contagem decrescente termina, o TosBoot verifica se deve reprogramar o
microcontrolador. Caso isso se verifique, este apaga a memória interna do
microcontrolador que corre a aplicação e de seguida escreve a nova imagem,
copiando a aplicação pretendida da memória externa para a memória interna do
microcontrolador. Quando este processo termina, é feito um reset ao bit responsável
por assinalar a necessidade de reprogramação e o TosBoot passa para o seu estado
inicial. O funcionamento do TosBoot está representado na Figura 4.3. Durante este
processo, o TosBoot faz um conjunto de procedimentos para proteger o nó de um
possível conjunto de falhas, tais como:
1. É verificado se a corrente elétrica que a bateria fornece ao
microcontrolador está acima de um determinado valor. Isto é feito pois
muitos microcontroladores necessitam de um determinado nível de
corrente para se reprogramarem corretamente.
2. É efetuada a deteção de erros da imagem (método CRC3) antes de ser
feita a reprogramação. Caso seja detetado algum erro, o TosBoot aborta
o processo de reconfiguração e o nó é iniciado normalmente.
3. O endereço de memória é sempre verificado antes de se reprogramar o
microcontrolador, para que o TosBoot não comece a reescrever por cima
do seu próprio código. Apesar de alguns microcontroladores oferecerem
zonas da memória protegidas contra a escrita, existem alguns que não
oferecem esta funcionalidade, pelo que esta verificação é sempre
necessária.
4. Caso exista um erro enquanto a programação do microcontrolador está a
decorrer, o TosBoot irá tentar mais algumas vezes. Caso o erro persista,
o TosBoot vai tentar reprogramar o microcontrolador com a GoldenImage,
de forma que este passe para um estado em que possa ser reprogramado
remotamente.
3 Cyclic Redundancy Check: método para identificação de erros nos bits transmitidos.
45
Figura 4.3: Fluxograma de funcionamento do TosBoot.
4.1.4 Tos-Deluge
A partir do momento que os nós estão a correr o Deluge, é possível utilizar um
script em Python chamado Tos-Deluge que corre no PC e que permite ao utilizador
controlar todo o processo de reprogramação. Para isto ser possível é necessário ter
um nó diretamente ligado à máquina que corre o script, sendo denominado de
“estação-base”. A estação-basse corre um programa que apenas contém o Deluge
com a opção de estação base ativada, permitindo que este receba comandos pela
interface de comunicação série. A sua principal função é receber as instruções do
utilizador através do Tos-Deluge e funcionar como gateway entre este e a rede.
46
O script Tos-Deluge permite gerir as aplicações que estão nos volumes da
estação base permitindo ao utilizador injetar ou apagar uma imagem de código de
um dos volumes. As imagens de código são criadas após uma compilação feita com
sucesso, e ao código da aplicação é adicionado um conjunto de metadados
incluindo: nome da aplicação, data de compilação, ID do utilizador que realizou a
compilação, o tamanho e a plataforma para qual a aplicação foi desenvolvida, etc.
Esta informação é enviada juntamente com a imagem de código e é geralmente
utilizada para identificar a aplicação. Depois de as imagens de código estarem
corretamente colocadas nos volumes da estação base, o Tos-Deluge permite ao
utilizador controlar o processo de reprogramação da rede através das ações:
disseminar; disseminar e reprogramar; e parar a disseminação.
4.1.5 Análise e discussão
O Deluge utiliza o Tos-Deluge, o DRIP e o TosBoot com o objetivo de tornar o
processo de reprogramação dos nós o mais simples e transparente possível. O Tos-
Deluge, juntamente com a estação base, permite ao utilizador controlar a
reprogramação através de um conjunto de comandos. O DRIP é utilizado para
garantir que as ordens dadas pelo utilizador chegam a todos os nós da rede. O
TosBoot é responsável pela reprogramação do nó, copiando a aplicação da memória
externa para a memória flash do microcontrolador. Desta forma, é possível verificar
que a reprogramação remota dos nós oferecida pelo Deluge só é possível devido à
utilização de outros componentes como o Tos-Deluge, o DRIP e o TosBoot,
conforme indicado na Figura 4.4.
Como já foi dito, o do Deluge encara a rede como sendo uma única unidade,
ou seja, as ordens dadas pelo utilizador através da estação base vão afetar todos os
nós de igual modo, sem diferenciação. Outro especto a realçar é o fato de o Deluge
não oferecer nenhuma informação de estado sobre a reprogramação garantindo
apenas que eventualmente todos os nós vão ser reprogramados graças ao estado de
manutenção do DRIP.
47
Figura 4.4: Componentes utilizados pelo Deluge na reprogramação remota.
4.2 Discussão e Implantação de uma extensão ao Deluge
4.2.1 Planeamento da solução
Para possibilitar a reprogramação seletiva é necessário identificar os nós que se
pretende reprogramar e fazer chegar esta informação aos mesmos. Num cenário
onde não existiu nenhum planeamento na identificação específica de um conjunto
de nós (e.g. utilização de endereços de grupo) a pensar na reprogramação, a única
forma de selecionar um determinado nó é utilizando algo que o identifique
inequivocamente. O uso do identificador do nó (NodeID) é uma dessas formas, daí
ser utilizado no protocolo proposto para identificar o nó que se pretende
reprogramar. Para se reprogramar um conjunto específico de nós é necessário
adicionar à informação referente à aplicação que deve ser utilizada na
reprogramação, a lista de NodeIDs que devem executar esta operação. Esta
informação deve ser tratada cuidadosamente devido às limitações no tamanho dos
48
pacotes. Como já foi dito, no DRIP a informação que se pretende disseminar não
deve exceder o tamanho máximo do conteúdo de um pacote. Por defeito, o TinyOS
define o tamanho máximo do conteúdo de um pacote como sendo de 28 Bytes,
mas dependendo da plataforma este tamanho pode ser estendido até ao limite
máximo permitido pela norma IEEE 802.15.4. Assim sendo, para reprogramar
seletivamente um nó seria necessário adicionar ao conteúdo do pacote da Figura 1
a lista de nós a serem reprogramados. Atendendo ao tamanho do conteúdo do
pacote pode-se verificar que apenas restam 12 Bytes livres para a lista de NodeIDs,
caso o tamanho do conteúdo seja o utilizado por defeito (28 Bytes). Cada NodeID
ocupa 2 Bytes, pelo que, apenas se poderiam reprogramar seletivamente um
máximo de seis nós. Como é óbvio, a possibilidade de reprogramar seletivamente
apenas seis nós tornaria inviável a reprogramação seletiva, visto que o número de
nós nas redes de sensores é por norma mais elevado. Dadas estas limitações do
DRIP duas abordagens podem ser consideradas: (i) utilizar o tamanho padrão do
pacote e reprogramar seletivamente seis nós de cada vez, esperando que os
primeiros seis se reprogramem para depois voltar a disseminar nova ordem com
mais seis nós e assim sucessivamente até que todos os nós pretendidos sejam
reprogramado; e (ii) aumentar o tamanho do pacote para o valor máximo suportado
pelas plataformas que funcionam com o Deluge. No respeitante à primeira
abordagem, um dos potenciais problemas imediatos seria o longo período de tempo
que demoraria a reprogramação, visto que seria necessário esperar e ter a certeza
que o primeiro pacote chegou a todos os nós da rede para se iniciar a disseminação
do segundo pacote e assim sucessivamente. Outro grande problema seria o grande
aumento de informação irrelevante a circular na rede, visto que, no conteúdo de
cada pacote enviado após o primeiro, apenas a lista de nós não seria informação
redundante, pois a informação sobre a aplicação seria sempre a mesma.
Relativamente à segunda abordagem, referente ao aumento do tamanho máximo
do conteúdo dos pacotes a enviar, o número máximo de nós que se poderiam
reprogramar seletivamente continuaria limitado, além de que esta alteração no
tamanho do pacote seria feita para todas as comunicações do nó podendo, por
49
ventura, interferir com outras aplicações que já estivessem a correr na rede e não
utilizassem o Deluge.
Assim sendo, nenhuma das abordagens mais diretas ao problema permitem
uma reprogramação seletiva eficiente e generalizada para todos os cenários. Desta
forma, optou-se pela construção de uma extensão ao protocolo DRIP e do Deluge.
Esta extensão funciona como um novo protocolo sempre que é utilizada a
reprogramação seletiva.
O primeiro passo na construção do novo protocolo foi criar dois tipos de pacotes
distintos, que permitissem conciliar o funcionamento normal do Deluge com a
reprogramação seletiva, conforme indicado na Figura 4.5. As denominações de DE
e DF são para uma melhor identificação ao longo da dissertação, e dizem respeito
ao fato de estes serem os valores hexadecimais da Chave de cada pacote. Como se
pode verificar pela Figura 4.5, o pacote DE diz respeito ao pacote originalmente
enviado na reprogramação, mas com algumas alterações ao seu conteúdo. Estas
alterações passam pelo acréscimo de 1 Byte utilizado para identificar o tipo de
reprogramação, 1 Byte para indicar o tamanho da lista de nós que está a ser enviada
no pacote e os restantes 10 Bytes dizem respeito aos NodeIDs. Relativamente ao
pacote DF, este foi criado para transportar apenas os NodeIDs em excesso que não
podem ser transportados no pacote DE, servindo apenas para sustentar a
reprogramação seletiva. Neste pacote, os primeiros 6 Bytes são utilizados pelo DRIP
tal como acontece no pacote DE, sendo que no restante conteúdo o primeiro Byte é
utilizado para identificar o pacote, o segundo Byte diz respeito ao número de
NodeIDs transportados no mesmo, e os restantes Bytes são usados para os NodeIDs
dos nós que se pretendem reprogramar. Cada pacote DF pode transportar no
máximo dez NodeIDs, podendo ser criados tantos pacotes quantos os necessários
para acomodar toda a lista de NodeIDs que o utilizador pretende reprogramar.
50
Figura 4.5: Pacotes criados para a reprogramação seletiva [5].
4.2.2 Detalhes da implementação
Um dos principais requisitos a ter em conta na construção de uma extensão ao
Deluge que permita a reprogramação seletiva, é garantir compatibilidade com o
funcionamento original do mesmo. Desta forma, tanto o DRIP como o Deluge
deveriam funcionar de igual modo sempre que não fosse utilizada a reprogramação
seletiva. Aliado a este fator, a solução encontrada deverá ter o menor impacto
possível no tráfego da rede e oferecer um elevado grau de fiabilidade.
Assim sendo, com o protocolo criado é possível reprogramar a rede de duas
formas, sendo elas: a reprogramação de toda a rede suportada por defeito pelo
Deluge e a reprogramação seletiva através do tipo plataforma ou do NodeID. O tipo
de reprogramação é identificado pelo parâmetro ReprogramType permitindo aos nós
efetuar os devidos procedimentos consoante o tipo de reprogramação pretendida.
51
Um dos grandes desafios na construção do novo protocolo foi o fato de o TinyOS
ser um sistema operativo assente na linguagem NesC, que apresenta um grande
nível de modularidade em virtude do código ser formado por vários componentes.
Este fator aliado à falta de comentários no código complicou a tarefa de identificação
dos componentes que teriam de ser alterados, o que obrigou a um estudo
pormenorizado do funcionamento do Deluge. A Figura 4.6 mostra todos os
componentes de código que foram alterados e criados de forma a tornar possível a
reprogramação seletiva.
Figura 4.6: Componentes de código alterados (indicado a vermelho) e criados (indicado a verde).
4.2.2.1 Reprogramação Seletiva através da Plataforma
Numa reprogramação seletiva por plataforma são apenas reprogramados os nós
que partilham o mesmo tipo de plataforma de funcionamento. Este processo utiliza
52
apenas pacotes DE onde o ReprogramType especifica qual a plataforma que deve
efetuar a reprogramação. Neste caso, é utilizado o funcionamento normal do DRIP
para disseminar a informação para toda a rede. Quando os nós recebem este pacote,
a aplicação que corre no nó verifica que tipo de reprogramação se trata, e neste
caso, apenas os nós cuja plataforma é a indicada pelo ReprogramType iniciam a
sua reprogramação. Para que uma aplicação seja capaz de identificar a plataforma
onde está a correr foi necessário alterar o processo de compilação da mesma. Desta
forma, na altura da compilação a informação da plataforma é colocada numa
constante que pode ser acedida em tempo de execução pela própria aplicação. A
Figura 4.6 ilustra os dois componentes de código que foram alterados para satisfazer
o objetivo proposto.
A alteração consiste em utilizar as diretivas do compilador nesC quando uma
aplicação é compilada, para identificar de que plataforma se trata. Como exemplo,
sendo a plataforma Telosb, quando o utilizador compila a aplicação através o
comando “make telosb” (o target é “telosb”), é colocado um valor inteiro que
corresponde a esta plataforma numa constante chamada TOS_PLATFORM. Esta
constante pode depois ser acedida pela aplicação em tempo de execução durante o
processo de reprogramação.
4.2.2.2 Reprogramação Seletiva através do NodeID
Quando o utilizador pretende uma reprogramação seletiva através do NodeID, é
sempre utilizado um pacote DE onde o ReprogramType indica que se trata de uma
reprogramação seletiva através do NodeID, significando que será enviada a lista de
NodeIDs a serem reprogramados. Caso a lista de NodeIDs seja maior do que cinco,
significa que não cabem todos num pacote DE e o excesso será colocado em pacotes
DF. Cada pacote DF será identificado por um identificador único (PacketID), de
forma a diferenciar os pacotes com diferentes conteúdos, e será atribuído um
Número de Sequência no cabeçalho do DRIP igual ao Número de Sequência do
pacote DE. Isto permite relacionar os pacotes DF com o pacote DE correspondente
53
que possui a informação sobre a aplicação com a qual os nós se devem
reprogramar. Da mesma forma, este procedimento garante que nenhum pacote DF
com Número de Sequência diferente do último pacote DE recebido será levado em
consideração. Esta operação de empacotamento é realizada na estação-base
conforme indicado na pela Figura 4.7.
No funcionamento normal do DRIP, um pacote que seja recebido com o mesmo
Número de Sequência do anterior é considerado duplicado, sendo descartado e
levando ao incremento do TimerTrickle. Desta forma, pacotes DF que possuíssem o
mesmo Número de Sequência mas conteúdos diferentes seriam descartados, pois
só o primeiro pacote a chegar seria considerado válido enquanto os outros seriam
considerados duplicados. Para que a reprogramação seletiva através do NodeID
fosse possível, foi necessário alterar o modo de funcionamento do DRIP quando é
utilizado pelo Deluge. Desta forma, foi criado um gestor de pacotes DF que corre
em cada nó e é responsável por gerir e diferenciar pacotes DF com informação
relevante dos pacotes duplicados. Quando um pacote DF é recebido por um nó, o
seu PacketID é verificado de forma a verificar se já foi rcebido um pacote igual. Caso
o pacote recebido seja o primeiro, o seu conteúdo é guardado e é iniciado um
TimerTrickle para gerir a disseminação deste pacote. Caso o pacote recebido seja
duplicado, isso significa que já existe um TimerTrickle a correr e, portanto, este é
incrementado. Para cada pacote armazenado, seja do tipo DE ou DF, é verificado
se o NodeID do nó que recebeu o pacote consta da lista de NodeIDs a serem
reprogramados, e caso isso se confirme o nó inicia a sua reprogramação. Sempre
que um nó recebe um pacote DE com um Número de Sequência superior ao do
pacote DE que este tem guardado, todas as disseminações de pacotes DE e DF com
Número de Sequência inferior são interrompidas. No caso de o ReprogramType do
pacote DE recebido indicar que se trata de uma reprogramação seletiva através dos
NodeIDs, o gestor de pacotes DF prepara-se para receber os novos pacotes DF
iniciando novamente todo o processo.
54
É de salientar que com esta alteração ao funcionamento do DRIP é possível
disseminar ao mesmo tempo vários pacotes com a mesma Chave mas conteúdos
diferentes, havendo para cada pacote uma gestão individual da sua disseminação.
Figura 4.7: Processo de empacotamento na estação base [5].
4.2.3 Otimização do protocolo
À medida que a reprogramação dos nós vai acontecendo, a lista de nós a
reprogramar vai ficando desatualizada, pois contém NodeIDs de nós que já se
reprogramaram. De forma a diminuir a redundância da informação relativamente à
lista de NodeIDs que circula durante o processo de disseminação e reprogramação,
cada nó reprogramado com sucesso retira o seu NodeID da lista de nós a
55
reprogramar. Assim sendo, na próxima vez que um nó reprogramado enviar um
anúncio aos nós vizinhos, a lista de NodeIDs a reprogramar será menor pois já não
consta o seu NodeID. Um nó vizinho sempre que recebe um pacote, seja do tipo
DE ou DF, que possua uma lista de NodeIDs menor do que a do pacote que está a
disseminar, este automaticamente atualiza a lista de NodeIDs do pacote que tem
guardado. Desta forma, na próxima vez que o nó enviar o pacote que tem guardado,
a sua lista de NodeIDs já está atualizada. Para isto ser possível foi necessário alterar
o DRIP para que este suporte a disseminação de pacotes com tamanhos diferentes.
Desta forma, à medida que diminui a lista de NodeIDs também diminui o tamanho
dos pacotes, reduzindo tanto os custos energéticos associados à transmissão como
o volume de tráfego na rede.
De forma a garantir que a rede converge rapidamente para a disseminação da
lista de NodeIDs atualizada, é dada prioridade na transmissão aos nós que têm
informação mais relevante, ou seja, é dada prioridade aos nós que se reprogramam
e retiram o seu NodeID da lista de nós a reprogramar. A prioridade é dada através
da manipulação da incrementação ou não do TimerTrickle. Isto permite diminuir o
número de pacotes com informação desatualizada o mais rápido possível. Na Figura
4.8, está representado o processo de reprogramação seletiva bem como o conteúdo
dos pacotes trocados durante a mesma. A topologia da rede é também apresentada
no painel 0 da Figura 4.8 mostrando a disposição dos nós e o alcance dos seus
sinais de rádio. A Figura 4.9 apresenta o processo de reprogramação no nó.
56
Figura 4.8: Processo de Reprogramação Seletiva [5].
57
Figura 4.9: Processo de reprogramação seletiva no nó [5].
No funcionamento normal do Deluge o intervalo entre anúncios vai
aumentando, contudo estes anúncios nunca deixam de ser realizados devido ao
estado de manutenção do DRIP. Isto acontece pois pretende-se que nós, que por
qualquer razão ficaram sem conetividade com a rede, quando a retomarem, sejam
informados da ordem de reprogramação ou disseminação dada pelo utilizador. Na
reprogramação seletiva, pretende-se que um conjunto específico de nós se
reprograme, e portanto, quando esse objetivo for alcançado, não há necessidade de
existir mais tráfego na rede relativo á ordem de reprogramação. Este aspeto não se
verifica no funcionamento normal do Deluge.
58
Contudo, para que se possa parar a disseminação de pacotes DF e DE é
necessário saber quando todos os nós se reprogramaram e fazer chegar esta
informação a toda a rede. Assim sendo, como já foi dito, no protocolo criado a lista
de NodeIDs vai diminuindo conforme os nós se vão reprogramando. Desta forma, o
último nó da lista que se reprogramou deve assinalar o fim da disseminação do
pacote onde estava contido o seu NodeID. Se o NodeID do último nó que se
reprogramou chegou num pacote DE, o nó utiliza o parâmetro ReprogramType para
assinalar fim da disseminação. Caso o seu NodeID tenha chegado dentro de um
pacote DF, este apenas retira o seu NodeID da lista e o fim da disseminação é
assinalado por uma lista de NodeIDs com tamanho zero. A razão de no pacote DE
ser utilizado o ReprogramType para assinalar o fim da disseminação, deve-se a
questões de eficiência. De fato, caso se utilizasse o parâmetro ListLentgh como
acontece nos pacotes DF, este implicaria o acréscimo de um Byte ao conteúdo do
pacote.
Um nó apenas retira o seu NodeID da lista de NodeIDs a reprogramar caso se
tenha reprogramado com sucesso. Esta preocupação assegura ao utilizador e aos
restantes nós da rede uma informação de estado fiável sobre o desenrolar da
reprogramação seletiva.
4.2.4 Modo de atualização
Para que a informação do fim da disseminação de um determinado pacote
chegue a toda a rede de forma eficiente, cada nó apenas pode transmitir este tipo
de pacote uma vez, entrando depois em modo de atualização. É de salientar que a
retransmissão é feita em broadcast e não existem retransmissões em caso de perdas.
Caso um nó intermédio receba um segundo pacote a assinalar o fim da
disseminação antes de ter feito a retransmissão do mesmo, este não envia nenhum
pacote e entra logo em modo de atualização. O fato de um nó poder retransmitir
uma vez o pacote de fim de disseminação e não passar diretamente para o modo
de atualização permite que numa rede multihop esta informação possa chegar mais
rapidamente aos nós mais distantes. Quando um nó está em modo de atualização,
59
este só envia o pacote a indicar o fim da disseminação caso se aperceba que um
vizinho está desatualizado e ainda não sabe que determinado pacote DE ou DF já
não precisa ser disseminado. Mesmo nas situações em que vários nós se apercebam
que um vizinho está desatualizado, apenas um responde com o pacote assinalando
o fim da disseminação. Um nó apercebe-se que um vizinho está desatualizado pois
recebe dele um pacote com ReprogrmType diferente do número decimal onze (nos
pacotes DE) ou um ListLength diferente do número decimal 0 (nos pacotes DF).
Um nó pode estar desatualizado por variadas razões, sendo uma delas a perda de
conetividade com a rede fazendo com que este não estivesse a par do processo de
reprogramação.
A Figura 4.10 representa um cenário em que toda a rede se reprogramou com
sucesso, sendo o nó 4 o último a se reprogramar, e portanto, é a ele que cabe a
responsabilidade de assinalar o fim da disseminação. Para tal, o nó 4 envia o pacote
P4 aos vizinhos em broadcast a assinalar o fim da disseminação e entra em modo
de atualização. Tanto o nó 5 como o nó 3 recebem esta notificação do nó 4, e como
já foi dito, sempre que um nó recebe um anúncio a assinalar o fim da disseminação
de um pacote, este deve retransmiti-lo. Neste caso, o nó 3 foi o primeiro a
retransmitir o pacote. Como o envio é em brodcast todos os seus vizinhos vão
receber esta notificação, o que no caso do nó 5 vai fazer com que este passe
diretamente para o modo de atualização. O processo repete-se até que todos os nós
estejam em modo de atualização. No cenário 5 o nó 7, que se encontra
desatualizado, envia um pacote aos seus vizinhos. Como todos os vizinhos já se
encontram em modo de atualização um deles, neste caso o nó 5, vai atualizar o nó
7 enviando um pacote P4. O nó 3 ao receber o pacote P4 vai cancelar a atualização
que iria fazer ao nó 7. Antes de passar ao modo de atualização o nó 7 faz a
retransmissão do pacote P4 como esperado.
60
Figura 4.10: Fim do processo de disseminação na Reprogramação Seletiva e o modo atualização
[5].
4.3 Sumário
Neste capítulo foram abordados os detalhes de desenho e implementação de
um protocolo que possibilita a reprogramação seletiva de uma RSSF. Para tal,
analisou-se a forma como a reprogramação é originalmente executada pelo Deluge,
identificando todos os componentes que este utiliza, nomeadamente o DRIP, o
TosBoot e o Tos-Deluge. Com base nesta análise foi planeada uma solução que
permite a reprogramação seletiva de uma rede de sensores, sendo especificados os
detalhes de implementação relativamente: (i) reprogramação seletiva por tipo de
plataforma ou NodeID; (ii) questões te otimização do protocolo; e (iii) modo de
atualização.
O próximo capítulo diz respeito aos testes efetuados ao protocolo criado, bem
como à análise e discussão dos resultados.
61
5. Resultados e discussão
Neste capítulo é feita uma descrição do cenário de testes utilizado,
nomeadamente a topologia, componentes e metodologia adotada. De seguida são
apresentados os resultados sendo feita uma análise e discussão dos mesmos. Por
fim, é feita uma análise final ao protocolo testado onde são realçadas algumas das
suas características de funcionamento de maior relevância.
5.1 Cenário de testes
Como cenário de testes utilizou-se uma topologia em malha completa, com
quatro nós Telosb e dois nós MicaZ. Neste tipo de topologia todos os nós da rede
estão ligados diretamente entre si, existindo uma ligação ponto-a-ponto entre cada
nó e os demais. A opção de uma topologia deste tipo deveu-se ao fato de existirem
poucos nós disponíveis para a construção de um cenário multihop.
O cenário experimental está representado na Figura 5.1, onde se pode verificar
que se encontram dois TelosB ligados ao PC: um é utilizado como estação base
enquanto o outro é usado como sniffer para fazer a captura dos pacotes que
circulam na rede. A estação base também comunica com todos os nós da rede à
distância de um salto. O TelosB utilizado para captura de tráfego corre uma
aplicação que funciona como gateway entre a rede e o PC, ou seja, faz o
encaminhamento dos pacotes que são captados pelo recetor de rádio para a porta
série do PC.
62
Figura 5.1:Cenário experimental.
O TinyOS disponibiliza uma aplicação chamada Listen.java que permite mostrar
na linha de comandos o conteúdo dos pacotes que são recebidos na porta série
através do gateway descrito anteriormente. Alterou-se esta aplicação para que fosse
possível filtrar os pacotes relativos à reprogramação. A informação sobre o conteúdo
dos pacotes é depois colocada num ficheiro juntamente com a informação temporal
de quando estes foram recebidos, criando assim um ficheiro de registo de dados
(vulgo “log de dados”) relativo ao processo de reprogramação, Figura 5.2. O
processo de filtragem é feito com base nos primeiros 4 Bytes do conteúdo de cada
pacote, que devem corresponder ao valor das Chaves hexadecimais do DRIP
utilizadas na reprogramação. Desta forma, apenas os pacotes com as Chaves DE e
DF são filtrados e colocados num ficheiro específico juntamente com a informação
temporal de quando foram recebidos.
63
Figura 5.2: Fluxograma da aplicação alterada para a criação dos ficheiros de log de dados.
5.2 Testes e análise de resultados
Foram realizados vários testes ao processo de reprogramação seletiva em
diferentes situações de forma a verificar se o comportamento do protocolo
desenvolvido era o espectável. É de salientar que os testes dizem respeito ao
processo de reprogramação depois de todos os nós possuírem as diferentes imagens
de código nos seus volumes de armazenamento.
64
Utilizou-se a ferramenta Gnuplot [49] no tratamento dos dados contidos nos
ficheiros de registo, nomeadamente na geração dos gráficos ilustrativos do processo
de reprogramação.
5.2.1 Reprogramação através do tipo de plataforma
Começou-se por analisar o processo de reprogramação da rede quando é
utilizado o Deluge na sua forma original. A Figura 5.3 representa o número de
pacotes relativos à reprogramação que circulam na rede durante 2 minutos. Foi
definido o intervalo de tempo de 2 minutos visto que não afeta os resultados obtidos,
nem prejudica a resolução temporal do gráfico. Como já foi referido, a disseminação
das ordens do Deluge é feita através do DRIP. Desta forma, seria expectável uma
grande quantidade de pacotes no início da reprogramação indo diminuindo
gradualmente até chegar a um estado onde apenas alguns pacotes são enviados
esporadicamente (estado de manutenção do DRIP). Este comportamento pode ser
verificado na Figura 5.3 a partir dos 10 segundos. Antes deste tempo, existe uma
grande quantidade de pacotes a serem enviados mas apenas nos primeiros 3
segundos existindo depois um período de aproximadamente 7 segundos onde
apenas um pacote é enviado. Isto acontece porque mal os primeiros pacotes são
enviados pela estação base, os nós iniciam a sua reprogramação e só depois de se
reprogramarem é que começam novamente o processo de disseminação.
No segundo teste foi utilizado uma reprogramação seletiva através do tipo de
plataforma. A plataforma selecionada para a reprogramação foi o TelosB. Como o
funcionamento do DRIP neste tipo de reprogramação é o mesmo de quando é
utilizada a reprogramação original do Deluge, o processo de disseminação é
portando muito semelhante, como pode ser constatado pela Figura 5.4. A única
diferença é que apenas os nós TelosB se vão reprogramar.
65
Figura 5.3:Distribuição temporal dos pacotes na reprogramação com o Deluge original.
Figura 5.4: Distribuição temporal dos pacotes na reprogramação seletiva por plataforma.
66
5.2.2 Reprogramação através do NodeID
Os gráficos relativos à reprogramação seletiva por NodeID mostram não só os
pacotes que circulam na rede durante o processo de reprogramação, mas também
dados adicionais como a origem do pacote, tamanho e conteúdo da lista de
NodeIDs. Estas informações são necessárias para se poder validar o correto
funcionamento do protocolo criado.
Inicialmente realizou-se uma reprogramação seletiva dos nós 5, 55 e 7, sendo
recolhidos os pacotes relativos à reprogramação durante 40 segundos, ver Figura
5.5. Neste teste foi definido o intervalo de tempo de 40 segundos visto que não
afeta os resultados obtidos, nem prejudica a resolução temporal do gráfico. Foram
utilizados pacotes DE na reprogramação. Como se pode verificar pela figura, a
disseminação inicia-se tal como previsto, ou seja, com um grande número de
pacotes a serem enviados numa primeira fase da reprogramação (primeiros 5 seg.).
Inicialmente os pacotes contêm toda a lista de NodeIDs a serem reprogramados e
não existe nenhum pacote enviado por um nó que seja alvo da reprogramação. Isto
acontece, pois os primeiros pacotes enviados pela estação base iniciam de imediato
a reprogramação dos nós alvo, impossibilitando portanto que estes participem na
fase inicial da disseminação. Assim que a reprogramação dos nós alvo é concluída
com sucesso, sempre que estes nós recebem um pacote retiram o seu NodeID da
lista, caso esta ainda não esteja atualizada. Isto provoca uma diminuição gradual
da mesma, até que o último nó da lista retira o seu NodeID e anuncia o fim da
disseminação. Como se pode verificar pela Figura 5.5, o nó 5 foi o que anunciou o
fim da disseminação. Como já foi referido anteriormente, quando um nó recebe a
informação do fim da disseminação deve retransmitir o pacote uma vez e entrar em
modo de atualização. Pode-se verificar que esta situação acontece
aproximadamente aos 15 segundos, quando um nó faz a retransmissão do pacote
que anuncia o fim da disseminação. Apenas um nó faz esta retransmissão, pois
este pacote vai chegar a todos os nós da rede fazendo com que entrem de imediato
em modo de atualização.
67
Outro aspeto importante que se pode verificar pela Figura 5.5 é que a partir dos
14 segundos, os nós alvo da reprogramação assumem o destaque no processo de
disseminação. Isto deve-se ao fato de que os nós alvo ao retirarem o seu NodeID
da lista de NodeIDs a reprogramar, passam a ter uma lista de NodeIDs mais
atualizada, e, portanto, antecipam-se no envio dos pacotes ganhando prioridade na
comunicação sobre os vizinhos.
Repetiu-se o mesmo teste mas com a lista de nós a reprogramar inserida num
pacote DF, ver Figura 5.6. Como o cenário de testes tem poucos nós (apenas 6)
utilizaram-se NodeIDs fictícios de forma a preencher um pacote DE e colocar os
NodeIDs 5, 55 e 7 num pacote DF. Como era esperado, o processo de
reprogramação e disseminação através do pacote DF tem um comportamento
similar ao processo de reprogramação com pacotes DE que é ilustrado na Figura
5.5. No entanto, a Figura 5.6 permite constatar que pacotes DF e DE enviados ao
mesmo tempo têm um processo de disseminação independente. Pode-se ainda
verificar que devido ao fato dos NodeIDs do pacote DE não existirem, nenhum nó é
reprogramado e portanto o tamanho da lista de NodeIDs mantém-se a mesma
fazendo com que o processo de disseminação deste pacote siga o padrão original
do DRIP, como exemplificado na Figura 5.3.
68
Figura 5.5: Reprogramação seletiva dos nós 5, 55 e 7 com pacotes DE.
Figura 5.6: Reprogramação seletiva dos nós 5, 55 e 7 com pacotes DF.
Na Figura 5.7, é representada a reprogramação seletiva aos nós 10, 7 e 55
através de um pacote DE, contudo, o nó 7 encontra-se desligado. Este teste tenta
simular situações em que os nós por alguma razão se encontram sem conetividade.
69
Assim sendo, é possível verificar que os nós que se encontram conectados, ou seja,
os nós 10 e 55, são reprogramados com sucesso e retiram os seus NodeIDs da lista
de nós a reprogramar. Contudo, tal como esperado, a disseminação não termina,
sendo enviado o pacote destinado ao nó 7 com um desfasamento temporal cada
vez maior até ao eventual estado de manutenção oferecido pelo DRIP. Quando o nó
7 voltar a ter conetividade vai receber eventualmente o pacote com a ordem de
reprogramação. Nesse momento o nó irá efetuar a sua reprogramação e anunciar o
fim da disseminação de forma a acabar com o estado de manutenção do DRIP.
Figura 5.7: Reprogramação seletiva dos nós 10, 55 e 7 com o nó 7 inacessível.
5.2.3 Modo de atualização
De forma a verificar o funcionamento do modo de atualização, foi efetuada uma
reprogramação seletiva aos nós 5, 55 e 7. Assim que a estação base envia os
primeiros pacotes DE e os respetivos nós iniciam a sua reprogramação, retirou-se o
nó 10 da rede para que este ficasse fora do alcance de todos os nós da rede, ficando
assim isolado. Depois de todos os nós se terem reprogramado e entrado em modo
de atualização, voltou-se a integrar o nó 10 na rede de forma que este voltasse a
70
ter conetividade. Consultando a Figura 5.8, pode-se verificar que todos os nós alvo
se reprogramaram corretamente e 18 segundos depois do primeiro pacote com a
ordem de reprogramação ter sido enviado para a rede, todos os nós entraram em
modo de atualização. Por volta dos 51 segundos, o nó 10 envia um pacote com
uma lista que contém três NodeIDs. Isto deve-se ao fato de este nó ter estado isolado
da rede durante o processo de reprogramação desconhecendo que esta já terminou.
Como esperado, os vizinhos que se encontram já em modo de atualização detetam
que o nó 10 está desatualizado e enviam um pacote com a informação do fim da
disseminação. Pode-se verificar que isto aconteceu por volta do segundo 52, onde
o nó 7 envia um pacote ao nó 10 assinalando o fim da disseminação para que este
entre também em modo de atualização. Como esperado o nó 10 faz a retransmissão
desse pacote e entra em modo de atualização.
Figura 5.8: Reprogramação seletiva dos nós 5, 55 e 7 e o modo de atualização.
71
5.3 Análise e discussão
Após a realização de todos os testes verificou-se que o funcionamento do
protocolo decorreu de acordo com os objetivos definidos na sua conceção, sendo
desta forma possível reprogramar seletivamente um conjunto de nós através do tipo
de plataforma ou do NodeID. Foi ainda possível verificar, que durante o processo
de reprogramação seletiva por NodeID o protocolo executa um conjunto de
mecanismos de forma a assegurar eficiência e fiabilidade no processo de
reprogramação. Neste sentido, destacam-se os seguintes aspetos:
1. Diminuição da lista de NodeIDs: Os nós que se reprogramam enviam
uma lista de NodeIDs atualizada. Desta forma, a lista de nós a reprogramar vai
diminuindo ao longo do processo de reprogramação, causando uma diminuição
no tamanho dos pacotes a circular na rede. Isto permite diminuir tanto os gastos
energéticos associados à transmissão como o tráfego a circular na rede.
2. Prioridade na comunicação: Os nós que retiram o seu NodeID da lista
de NodeIDs ganham prioridade na comunicação sobre os vizinhos. Desta forma,
a lista de NodeIDs a ser disseminada é sempre a mais atualizada possível
diminuindo a quantidade de informação desatualizada durante o processo de
reprogramação.
3. Estado de manutenção do DRIP: Com o estado de manutenção do DRIP,
os nós alvo da reprogramação que estejam sem conetividade, quando a
restabelecerem, poderão receber a ordem de reprogramação dada pelo
utilizador. A utilização desta característica do DRIP na reprogramação seletiva
garante uma elevada fiabilidade na reprogramação.
4. Anúncio do fim da disseminação: Quando o último nó da lista de
NodeIDs se reprograma assinala o fim da disseminação do pacote onde estava
contido o seu NodeID. Os vizinhos que recebem este tipo de pacote rapidamente
fazem a sua retransmissão e entram em modo de atualização. Contudo, caso
um nó receba de um vizinho um segundo pacote a assinalar o fim da
72
disseminação antes de fazer a retransmissão do mesmo, este entra logo em
modo de atualização cancelando a retransmissão. Isto permite que numa rede
multihop a informação do fim da disseminação chegue rapidamente aos nós
mais distantes, enquanto numa rede single-hop (rede utilizada no cenário de
testes) apenas é necessário ser feita uma retransmissão do pacote a assinalar o
fim a disseminação para colocar todos os nós em modo de atualização.
5. Modo de atualização: Depois dos nós entrarem no modo de atualização
apenas são enviados pacotes relativos à reprogramação caso seja detetado que
um nó vizinho está desatualizado. A atualização de um nó desatualizado é feita
por um nó vizinho através do envio de um pacote com a informação de fim da
disseminação. Este pacote não só atualiza o nó desatualizado como avisa os
restantes vizinhos de que já foi feita a atualização, e portanto, estes não
precisam de a fazer.
6. Informação de estado sobre a reprogramação seletiva por NodeID: Os
nós alvos apenas retiram os seus NodeIDs da lista de nós a reprogramar depois
de se terem reprogramado com sucesso. Este fator aliado à rápida convergência
da rede para a lista de NodeIDs mais atualizada, permite ao utilizador (ou
aplicação) e aos nós da rede ter uma informação de estado fiável sobre o
processo de reprogramação.
5.4 Sumário
Neste capítulo foi testado e analisado o comportamento do protocolo criado.
Foi descrito o cenário utilizado nos testes, nomeadamente a topologia, os
componentes e a forma como a recolha dos pacotes relativos à reprogramação
é feita. Foi também analisado o processo de reprogramação quando é utilizada
a reprogramação total da rede, oferecida por defeito pelo Deluge. Esta análise
serviu para verificar o processo normal de disseminação oferecido pelo DRIP.
De seguida, foi testada a reprogramação seletiva por tipo de plataforma e por
NodeID, sendo os seus resultados analisados individualmente. Na
73
reprogramação por NodeID foram utilizados diferentes cenários para verificar a
fiabilidade e robustez do protocolo. Por último, foi feita uma análise geral do
protocolo criado evidenciando os aspetos mais relevantes do funcionamento do
mesmo na reprogramação seletiva por NodeID.
O próximo capítulo diz respeito às conclusões e considerações finais sobre
esta dissertação e às possíveis direções futuras a serem tomadas.
74
6. Conclusões e Trabalho Futuro
6.1 Conclusões
A reprogramação remota é crucial para a gestão e implementação de uma RSSF,
não só porque permite a reprogramação de nós que se encontram em locais de
difícil acesso mas também porque permite agilizar o processo de deteção de erros e
teste de uma aplicação ou serviço.
Esta dissertação propõem uma extensão ao protocolo DRIP aumentando
consideravelmente a funcionalidade do Deluge na reprogramação de RSSFs. Para
tal, foi necessário alterar completamente o modo de funcionamento do DRIP, dando
origem a um novo protocolo capaz de reprogramar seletivamente os nós de uma
RSSF. Foram utilizados vários mecanismos para assegurar que apenas a informação
relevante e mais atualizada circula na rede durante o processo de reprogramação.
Combinando estes mecanismos com o estado de manutenção do DRIP, foi possível
obter um protocolo que oferece fiabilidade e eficiência durante o processo de
reprogramação ao mesmo tempo que são mantidas todas as funcionalidades
originais do Deluge. Desta forma, todos os objetivos inicialmente propostos nesta
dissertação foram cumpridos. A solução encontrada permite uma reprogramação
mais versátil do que a oferecida originalmente pelo Deluge, permitindo reprogramar
seletivamente os nós da rede através do tipo de plataforma ou do Node ID.
Um dos maiores desafios na construção deste protocolo deveu-se ao elevado
nível de modularidade do código do Deluge e DRIP, fazendo com que a sua lógica
aplicacional esteja espalhada por vários componentes. Este fator aliado à escassez
de documentação do código torna difícil qualquer alteração, visto que muitas vezes
o acréscimo de uma pequena funcionalidade obriga à alteração de vários
componentes.
Outro aspeto a realçar é relativo à bibliografia referente aos trabalhos
relacionados sobre a reprogramação remota das RSSFs que se encontra bastante
75
dispersa e com uma clara falta de rigor na sua estruturação. Assim, procurou-se
analisar e sistematizar o valor acrescentado do trabalho relacionado para o tema em
estudo.
Em resumo, salientam-se como principais contribuições decorrentes do trabalho
realizado: (i) análise e organização dos principais trabalhos relacionados permitindo
uma melhor distinção dos protocolos de reprogramação com base no tipo de
reprogramação usada; e (ii) proposta de uma extensão protocolar que aumenta a
funcionalidade do Deluge, permitindo uma maior flexibilidade e versatilidade na
implementação das RSSFs através da reprogramação seletiva de redes com
diferentes plataformas e aplicações.
6.2 Trabalho futuro
Nesta última secção identificam-se possíveis direções futuras de investigação e
desenvolvimento de forma a melhorar e consolidar o protocolo desenvolvido.
A identificação dos nós no protocolo criado é feita através do NodeID. Contudo,
em cenários onde exista um grupo de nós a ser reprogramados em conjunto, deve
ser possível utilizar outra forma de identificação, como, por exemplo, endereços de
grupo. Neste sentido, os pacotes DF e DE deverão ser capazes de transportar outros
dados como alternativa à lista de NodeIDs, de forma a aumentar ainda mais a
versatilidade do processo de reprogramação.
A abstração das funcionalidades do protocolo criado para funções genéricas
deve também ser um objetivo futuro. Desta forma, seria possível utilizar o DRIP no
controlo da reprogramação de outros protocolos distintos do Deluge e que sofressem
da mesma lacuna em termos de reprogramação seletiva.
Por fim, refira-se que o protocolo criado não é assumido como definitivo,
podendo ser feitas várias otimizações ao seu funcionamento. Contudo, o que fica
subjacente com este trabalho é o conceito de uma extensão ao DRIP que pode ser
76
utilizada e implementada de forma similar em diferentes protocolos de
reprogramação.
77
Referências Bibliográficas
[1] P. Levis, S. Madden, and J. Polastre, “TinyOS: An operating system for sensor networks,” Ambient Intell., pp. 115–148, 2005.
[2] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki-a lightweight and flexible operating system for tiny networked sensors,” in Local Computer Networks, 2004. 29th Annual IEEE International Conference on, 2004, pp. 455–462.
[3] G. Strazdins, A. Elsts, K. Nesenbergs, and L. Selavo, “Wireless Sensor Network Operating System Design Rules Based on Real-World Deployment Survey,” J. Sens. Actuator Networks, vol. 2, no. 3, pp. 509–556, Aug. 2013.
[4] A. Chlipala, J. Hui, and G. Tolle, “Deluge: data dissemination for network reprogramming at scale,” Univ. California, Berkeley, Tech. Rep, 2004.
[5] E. Lima, Ó. Gama, and P. Carvalho, “A Protocol Extension for Selective Reprogramming of WSNs.” 2015 IEEE Int. Conf. Commun. (Artigo submetido em revisão)
[6] I. F. Akyildiz and M. C. Vuran, Wireless sensor networks, vol. 4. John Wiley & Sons, 2010.
[7] P. Baronti, P. Pillai, V. W. C. Chook, S. Chessa, A. Gotta, and Y. F. Hu, “Wireless sensor networks: A survey on the state of the art and the 802.15.4 and ZigBee standards,” Comput. Commun., vol. 30, no. 7, pp. 1655–1695, May 2007.
[8] Z. Shelby and C. Bormann, 6LoWPAN: The wireless embedded Internet, vol. 43. John Wiley & Sons, 2011.
[9] M. O. Farooq and T. Kunz, “Operating systems for wireless sensor networks: a survey.,” Sensors (Basel)., vol. 11, no. 6, pp. 5900–30, Jan. 2011.
[10] Q. Cao, T. Abdelzaher, J. Stankovic, and T. He, “The LiteOS Operating System: Towards Unix-Like Abstractions for Wireless Sensor Networks,” 2008 Int. Conf. Inf. Process. Sens. Networks (ipsn 2008), pp. 233–244, Apr. 2008.
[11] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald, A. Torgerson, and R. Han, “MANTIS OS: An Embedded
78
Multithreaded Operating System for Wireless Micro Sensor Platforms,” Mob. Networks Appl., vol. 10, no. 4, pp. 563–579, Aug. 2005.
[12] A. Eswaran, A. Rowe, and R. Rajkumar, “Nano-rk: an energy-aware resource-centric rtos for sensor networks,” in Real-Time Systems Symposium, 2005. RTSS 2005. 26th IEEE International, 2005, p. 10–pp.
[13] P. Levis and D. Gay, TinyOS Programming. Cambridge: Cambridge University Press, 2009.
[14] G. Tolle, J. Polastre, and R. Szewczyk, “A macroscope in the redwoods,” in Proceedings of the 3rd international conference on Embedded networked sensor systems, 2005, pp. 51–63.
[15] G. Werner-Allen and K. Lorincz, “Deploying a wireless sensor network on an active volcano,” Internet Comput. IEEE, vol. 10, no. 2, pp. 18–25, 2006.
[16] Ó. Gama, P. Carvalho, J. Afonso, and P. Mendes, “Wireless sensor networks with QoS for e-health and e-emergency applications,” 2008.
[17] W.-Y. Chung, Y.-D. Lee, and S.-J. Jung, “A wireless sensor network compatible wearable u-healthcare monitoring system using integrated ECG, accelerometer and SpO2.,” Conf. Proc. IEEE Eng. Med. Biol. Soc., vol. 2008, pp. 1529–32, Jan. 2008.
[18] A. Wood, G. Virone, T. Doan, Q. Cao, L. Selavo, Y. Wu, L. Fang, Z. He, S. Lin, and J. Stankovic, “ALARM-NET: Wireless sensor networks for assisted-living and residential monitoring,” Univ. Virginia Comput. Sci. Dep. Tech. Rep., vol. 2, 2006.
[19] P. Lopez-Matenci, J. V. Alonso, F. J. Gonzalez-Castano, J. L. Sieiro, and J. J. Alcaraz, “Ambient intelligence assistant for running sports based on k-NN classifiers,” 3rd Int. Conf. Hum. Syst. Interact., pp. 605–611, May 2010.
[20] P. Castillejo, J.-F. Martinez, J. Rodriguez-Molina, and A. Cuerva, “Integration of wearable devices in a wireless sensor network for an E-health application,” Wirel. Commun. IEEE, vol. 20, no. 4, 2013.
[21] “GINSENG.” [Online]. Available: https://www.cisuc.uc.pt/projects/show/108. [Accessed: 30-Sep-2014].
[22] S. W. Arms and C. P. Townsend, “Wireless Strain Measurement Systems–Applications & Solutions,” in Proceedings of NSF-ESF Joint Conference on Structural Health Monitoring, Strasbourg, France, 2003.
79
[23] S. W. Arms, C. P. Townsend, and M. J. Hamel, “Validation of remotely powered and interrogated sensing networks for composite cure monitoring,” in 8th International Conference on Composites Engineering (ICCE/8), Tenerife, Spain, 2001.
[24] M. Pejanovi and Z. Tafa, “A Survey of Military Applications of Wireless Sensor Networks,” 2012.
[25] G. Tolle and D. E. Culler, “Design of an application-cooperative management system for wireless sensor networks.,” in EWSN, 2005, vol. 5, pp. 121–132.
[26] P. Levis and D. Culler, “Maté: A tiny virtual machine for sensor networks,” ACM Sigplan Not., 2002.
[27] A. Boulis, C.-C. Han, R. Shea, and M. B. Srivastava, “Sensorware: Programming sensor networks beyond code update and querying,” Pervasive Mob. Comput., vol. 3, no. 4, pp. 386–412, 2007.
[28] J. Koshy and R. Pandey, “VMSTAR: synthesizing scalable runtime environments for sensor networks,” in Proceedings of the 3rd international conference on Embedded networked sensor systems, 2005, pp. 243–254.
[29] Q. Xie, J. Liu, and P. H. Chou, “Tapper: a lightweight scripting engine for highly constrained wireless sensor nodes,” 2006 5th Int. Conf. Inf. Process. Sens. Networks, pp. 342–349, 2006.
[30] J. Jeong, S. Kim, and A. Broad, “Network reprogramming,” Univ. Calif. Berkeley, Berkeley, CA, USA, 2003.
[31] R. K. Panta, I. Khalil, and S. Bagchi, “Stream: Low overhead wireless reprogramming for sensor networks,” in INFOCOM 2007. 26th IEEE International Conference on Computer Communications. IEEE, 2007, pp. 928–936.
[32] R. Panta, S. Bagchi, I. Khalil, and L. Montestruque, “Single versus multi-hop wireless reprogramming in sensor networks,” in Proceedings of the 4th International Conference on Testbeds and research infrastructures for the development of networks & communities, 2008, p. 34.
[33] S. S. Kulkarni and M. Arumugam, “Infuse: A TDMA Based Data Dissemination Protocol for Sensor Networks,” Int. J. Distrib. Sens. Networks, vol. 2, no. 1, pp. 55–78, 2006.
[34] G. Maia, D. L. Guidoni, A. L. L. Aquino, and A. A. F. Loureiro, “Improving an over-the-air programming protocol for wireless sensor networks based on
80
small world concepts,” in Proceedings of the 12th ACM international conference on Modeling, analysis and simulation of wireless and mobile systems, 2009, pp. 261–267.
[35] L. Wang and S. Kulkarni, “Gappa: Gossip based multi-channel reprogramming for sensor networks,” Distrib. Comput. Sens. Syst., pp. 119–134, 2006.
[36] T. Stathopoulos, J. Heidemann, and D. Estrin, “A remote code update mechanism for wireless sensor networks,” 2003.
[37] A. Tridgell and P. Mackerras, “The rsync algorithm,” no. June, 1996.
[38] R. K. Panta, S. Bagchi, and S. P. Midkiff, “Efficient incremental code update for sensor networks,” ACM Trans. Sens. Networks, vol. 7, no. 4, pp. 1–32, Feb. 2011.
[39] R. K. Panta and S. Bagchi, “Hermes: Fast and Energy Efficient Incremental Code Updates for Wireless Sensor Networks,” IEEE INFOCOM 2009 - 28th Conf. Comput. Commun., pp. 639–647, Apr. 2009.
[40] W. Dong, Y. Liu, C. Chen, J. Bu, C. Huang, and Z. Zhao, “R2: Incremental reprogramming using relocatable code in networked embedded systems,” Comput. IEEE Trans., vol. 62, no. 9, pp. 1837–1849, 2013.
[41] “TelosB Datasheet.” [Online]. Available: http://www.memsic.com/userfiles/files/Datasheets/WSN/6020-0094-02_B_TELOSB.pdf. [Accessed: 31-Oct-2014].
[42] “MicaZ Datasheet.” [Online]. Available: http://www.memsic.com/userfiles/files/Datasheets/WSN/6020-0060-04-B_MICAz.pdf. [Accessed: 31-Oct-2014].
[43] “EPIC.” [Online]. Available: http://www.cs.berkeley.edu/~prabal/projects/epic/. [Accessed: 31-Oct-2014].
[44] “IRIS Datasheet.” [Online]. Available: http://www.memsic.com/userfiles/files/Datasheets/WSN/6020-0124-01_B_IRIS.pdf. [Accessed: 31-Oct-2014].
[45] H. Dubois-Ferrière, L. Fabre, R. Meier, and P. Metrailler, “TinyNode: a comprehensive platform for wireless sensor network applications,” in Proceedings of the 5th international conference on Information processing in sensor networks, 2006, pp. 358–365.
81
[46] P. Levis and G. Tolle, “TEP 118 Dissemination,” Core Work. Group, TinyOS Community, pp. 1–4, 2007.
[47] P. Levis, N. Patel, D. Culler, and S. Shenker, Trickle: A self regulating algorithm for code propagation and maintenance in wireless sensor networks. 2003.
[48] J. Hui, “Deluge 2.0-TinyOS network programming,” found Feb. 2007 http//www. cs. berkeley. edu/jwhui/research/deluge/deluge-manual. pdf, 2005.
[49] T. Williams and C. Kelley, “Gnuplot 4.4: an interactive plotting program,” Off. gnuplot Doc. http//sourceforge. net/projects/gnuplot, 2010.