Tese de Disserta o - Autenticação · Implementação de Serviços de Aquisição de Dados numa...
75
Implementação de Serviços de Aquisição de Dados numa Rede de Sensores sem Fios Nuno Miguel de Sousa Fonseca Dissertação para obtenção do Grau de Mestre em Engenharia Electrotécnica e de Computadores Júri Presidente: Prof. Doutor Mário Serafim dos Santos Nunes Orientador: Prof. Doutor Renato Jorge Caldeira Nunes Vogais: Prof. Doutor António Manuel Raminhos Cordeiro Grilo Setembro de 2007
Transcript of Tese de Disserta o - Autenticação · Implementação de Serviços de Aquisição de Dados numa...
Implementação de Serviços de Aquisição de Dados
numa Rede de Sensores sem Fios
Nuno Miguel de Sousa Fonseca
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Júri
Presidente: Prof. Doutor Mário Serafim dos Santos Nunes
Orientador: Prof. Doutor Renato Jorge Caldeira Nunes
Vogais: Prof. Doutor António Manuel Raminhos Cordeiro Grilo
Setembro de 2007
i
Agradecimentos
A realização deste trabalho não teria sido possível sem a ajuda e a prestimosa colaboração de
todos aqueles que se empenharam neste projecto e cuja colaboração merece os meus mais
sinceros agradecimentos.
Ao Professor Renato Nunes, pela oportunidade que me concedeu de realizar a presente tese e
pela constante disponibilidade ao longo da sua execução.
Aos meus pais, pela formação pessoal e percurso académico. Sem a sua contribuição, não
teria sido possível a concretização deste projecto de vida. Obrigado pelo apoio e preocupação
que sempre demonstraram.
À minha Princesa, pela força, paciência e carinho desde o dia em que nos conhecemos. “A
noite em que as gaivotas eram bóias e as pedras eram quadros…”.
À minha irmã, a minha companheira de vida desde que nasceu, pelo diálogo subtil e inteligente
que sempre me incitou à continuação de um trabalho desta natureza.
A minha gratidão estende-se ainda às minhas avós e tios, por acreditarem em mim.
Ao Hugo, pela troca de ideias que estabelecemos ao longo dos últimos 12 meses; e aos
amigos e colegas, a paciência disponibilizada nas fases mais críticas de dúvidas e incertezas...
À professora Joaquina, sempre atenta a um discurso que poderia “ferir” de forma contundente
a língua de Camões.
ii
Resumo
Actualmente a tecnologia de redes de sensores sem fios está em franca expansão. A sua
utilização tem vindo a crescer em diversas áreas de aplicação, como por exemplo nas
relacionadas com a domótica, agricultura, indústria, aplicações militares, entre outras. Este
trabalho propõe a definição e implementação de um conjunto de serviços que facilitem e
simplifiquem o desenvolvimento de aplicações baseadas em redes de sensores que envolvam
a monitorização de grandezas físicas, com a possibilidade de definição de alarmes e
actuações.
A camada de serviços proposta realiza uma abstracção entre a aplicação e os serviços
específicos de comunicação e monitorização de dados implementados na rede de sensores, os
quais, no protótipo desenvolvido, foram realizados sobre TinyOS 2.0. Essa camada é
responsável pela uniformização e simplificação de um conjunto de serviços de forma a
apresentar uma solução genérica para ser aplicada em múltiplas áreas, evitando a
necessidade de desenvolver soluções de raiz específicas para cada aplicação.
Os serviços de monitorização são responsáveis pela aquisição de dados de diversos sensores
(por exemplo, temperatura, luminosidade, presença) e pela actuação de diversos dispositivos
(por exemplo, alarmes sonoros, lâmpadas). Os serviços de aquisição permitem vários tipos de
leituras dos dados recolhidos pelos sensores: leitura a pedido, leitura periódica e notificação
quando certos limites pré-definidos são atingidos. Os serviços de notificação e os serviços de
comunicação, que suportam agregação de dados, permitem reduzir o número de mensagens
que circulam na rede, oferecendo benefícios óbvios em termos de economia de energia.
Palavras Chave
Rede de Sensores sem Fios, Aquisição de Dados, Middleware, Serviços de Suporte a
Aplicações, Domótica.
iii
Abstract
The technology of wireless sensors networks is reaching its full development. Its use has been
increasing in several areas, ranging from domotics, agriculture and industry to military
equipments. This work proposes the definition and implementation of a set of services which
facilitate and simplify the development of appliances based upon networks of sensors which
involve both the monitoring of physical phenomena and the possibility for a definition on alarms
and actuators.
The proposed layer of services establishes a abstraction between the application and the
services of the specific communication and monitoring of available and implemented data in the
network of sensors, which, in the present prototype were based on TinyOS 2.0. This service
synthesises and simplifies a set of services which offer a generic solution of applications in
multiple areas excluding the use of a different solution for each specific application.
The monitoring services include both the acquisition of data from diverse sensors, for example:
temperature, luminosity and presence and the work of several devices, for example: round
alarms or lamps. The acquisition services enable diverse types of reading from the data
collected by the sensors requested and periodic reading, even a notice whenever predefined
limits are reached. The notice and communication services resulting from the totality of data,
possibility the reduction of the number of messages in the network which results on energy
saving.
Key Words
Wireless Sensors Network, Data Acquisition, Middleware, Applications Support Services,
domotics.
iv
Índice
Agradecimentos .............................................................................................................................. i
Resumo .......................................................................................................................................... ii
Palavras Chave ............................................................................................................................. ii
Abstract ......................................................................................................................................... iii
Key Words .................................................................................................................................... iii
Índice ............................................................................................................................................ iv
Lista de Figuras ............................................................................................................................ vi
Lista de Tabelas .......................................................................................................................... vii
Lista de Abreviações ................................................................................................................... viii
1. Introdução ............................................................................................................................... 1
1.1. Objectivos ..................................................................................................................... 2
1.2. Organização da Tese ................................................................................................... 3
2. Redes de Sensores Sem Fios ................................................................................................ 4
2.1. Arquitectura .................................................................................................................. 4
2.1.1. Infra-estrutura ........................................................................................................ 5
2.1.2. Pilha de Protocolos ................................................................................................ 8
2.1.3. Aplicações .............................................................................................................. 9
2.2. Restrições da rede de sensores sem fios .................................................................. 12
2.2.1. Tempo de vida ..................................................................................................... 12
2.2.2. Cobertura ............................................................................................................. 13
2.2.3. Tempo de Resposta............................................................................................. 13
2.3. Camada de Serviços .................................................................................................. 14
2.4. Optimização de energia ............................................................................................. 16
2.4.1. Optimização do Nó sensor .................................................................................. 16
2.4.2. Optimização Global.............................................................................................. 18
2.5. TinyOS 2.0.................................................................................................................. 19
2.5.1. Modelo de Funcionamento .................................................................................. 20
2.5.2. Linguagem de Programação nesC ...................................................................... 22
3. Hardware .............................................................................................................................. 23
3.1. Características do MICAz ........................................................................................... 25
3.2. Bateria ........................................................................................................................ 27
3.3. Placa MTS310 ............................................................................................................ 28
3.3.1. Sensor de Temperatura e Luminosidade ............................................................ 28
3.3.2. Microfone ............................................................................................................. 29
3.3.3. Actuador de Som ................................................................................................. 29
3.3.4. Acelerómetro ........................................................................................................ 30
3.4. Componente de Rádio Frequência ............................................................................ 31
3.4.1. Received Signal Strength Indication (RSSI) ....................................................... 31
v
3.4.2. Link Quality Indicator (LQI) ................................................................................. 32
3.4.3. Radio Frequency Transmission Power (RF Power) ........................................... 32
3.4.4. Low Power Listening (LPL) ................................................................................. 33
4. Serviços de Monitorização Desenvolvidos ........................................................................... 34
4.1. Serviços Disponibilizados ........................................................................................... 35
4.2. Operadores Básicos ................................................................................................... 39
4.2.1. Operador GET ..................................................................................................... 40
4.2.2. Operador SET ...................................................................................................... 40
4.2.3. Operador REPORT .............................................................................................. 41
4.3. Protocolos de Comunicação ...................................................................................... 42
4.3.1. Disseminação de Dados ...................................................................................... 43
4.3.2. Colecção de Dados.............................................................................................. 44
4.4. Estrutura das Mensagens .......................................................................................... 47
4.4.1. Envio de Pedidos ................................................................................................. 47
4.4.2. Envio de Dados Simples ...................................................................................... 48
4.4.3. Envio de Dados Agregados ................................................................................. 49
4.5. Camada de Serviços do Nó Sensor ........................................................................... 50
4.5.1. Serviços de Aquisição e Actuação ...................................................................... 51
4.5.2. Serviços de Comunicação ................................................................................... 54
4.6. Serviços do Nó Saída ................................................................................................. 55
5. Programa de Demonstração ................................................................................................ 57
6. Conclusão ............................................................................................................................. 60
Referências .................................................................................................................................. 62
Anexo ........................................................................................................................................... 65
vi
Lista de Figuras
Figura 1 - Representação de uma Rede de Sensores sem Fios .................................................. 5
Figura 2 - Esquema de hardware do nó sensor. ........................................................................... 7
Figura 3 - Pilha de Protocolos ....................................................................................................... 8
Figura 4 - Exemplo monitorização vulcânica [4]. ......................................................................... 11
Figura 5 - Esquema de optimização energética de um nó sensor. ............................................. 17
Figura 6 - Modelo de funcionamento do sistema operativo TinyOS 2.0 ..................................... 20
Figura 7 - Camadas de abstracção do TinyOS 2.0 ..................................................................... 21
Figura 8 - Evolução dos motes. ................................................................................................... 23
Figura 9 - MICAz .......................................................................................................................... 25
Figura 10 - Esquema de funcionamento do MICAz .................................................................... 25
Figura 11 - Placa MTS310. .......................................................................................................... 28
Figura 12 - Características do Acelerómetro. .............................................................................. 30
Figura 13 - Camada de Serviços ................................................................................................. 35
Figura 14 - Estrutura da mensagem de envio de pedidos. ......................................................... 47
Figura 15 - Estrutura da mensagem de envio de dados simples. ............................................... 49
Figura 16 - Estrutura da mensagem de envio de dados agregados. .......................................... 49
Figura 17 - Esquema descritivo dos serviços do nó sensor. ....................................................... 50
Figura 18 - Esquema descritivo do acesso os componentes da placa MTS310. ....................... 51
Figura 19 - Componente de configuração mts300DomoBusC .................................................... 52
Figura 20 - Esquema de acesso aos protocolos de comunicação. ............................................. 54
Figura 21 - Esquema descritivo das ligações do nó saida. ......................................................... 55
Figura 22 - Janela do programa de demonstração. .................................................................... 57
vii
Lista de Tabelas
Tabela 1 - Características do MICAz. .......................................................................................... 25
Tabela 2 - Consumo de cada componente do MICAz. ............................................................... 27
Tabela 3 - Correspondência entre os valores lidos de RF Power de valores dBm..................... 32
Tabela 4 - Comandos e Eventos das interfaces.......................................................................... 36
Tabela 5 - Vantagens e desvantagens do serviço de agregação de dados ............................... 37
Tabela 6 - Parâmetros de entrada dos operadores da camada de middleware. ........................ 39
Tabela 7 - Parâmetros dos campos dinâmicos Prop 1 e Prop 2. ................................................ 48
Tabela 8 - Descrição dos componentes utilizados ...................................................................... 53
Tabela 9 - Comandos e eventos das interfaces getF, setF e reportF ......................................... 54
Tabela 10 - Descrição dos painéis da janela do programa de demonstração ............................ 58
Tabela 11 - Tabela de parâmetros e os seus significados de cada operador. ........................... 59
viii
Lista de Abreviações
MAC – Medium Access Control
DVS – Dynamic Voltage Scaling
DPM – Dynamic Power Management
SSP – Scalable Signal Processing
nesC – Network Embedded Systems C
FIFO – First In First Out
MEMS – Micro-Electro Mechanical Systems
ADC – Analog Digital Converter
RSSI – Received Signal Strength Indicator
LQI – Link Quality Indicator
RF Power – Radio Frequency Transmission Power
LPL – Low Power Listening
CTP – Collection Tree Protocol
ETX – Expected Transmission
ACK – Acknowledgments
LEEP – Link Estimator Exchange Protocol
1
1. Introdução
A área das redes de sensores sem fios constitui actualmente um campo de pesquisa
emergente. Estas redes podem ser usadas nos mais diversos domínios, tais como na
domótica, na segurança de edifícios e pessoas, na agricultura, entre outros. Estas redes
possuem capacidades únicas de capturar fenómenos físicos do mundo real e transportá-los
para o mundo digital. Em particular oferecem grandes vantagens na recolha de dados de
fenómenos físicos em locais de difícil acesso.
Uma rede de sensores sem fios é um sistema distribuído de sensores cujo objectivo principal
se centra na recolha e entrega de dados às aplicações clientes. Este sistema em rede é
constituído por dispositivos autónomos que cooperam entre si e que se encontram dispersos
em diversos locais de modo a monitorizar, por intermédio de sensores, diversos fenómenos
físicos, tais como pressão, temperatura, som ou vibrações.
As redes de sensores sem fios podem ser compostas por centenas de pequenos dispositivos
de reduzida capacidade de processamento equipados com diversos sensores. Estes
dispositivos são capazes de adquirir, processar e transmitir a informação recolhida pelos
diversos sensores. Estes dispositivos são denominados por nós sensores e a sua integração
na rede baseia-se na cooperação entre eles, extraindo os dados ambientais e transmitindo-os
para um ou mais nós de saída da rede, chamados nós saída, para serem armazenados e
processados. Estes dispositivos podem ser instalados em locais pré-definidos, ou de modo
anárquico, dependendo do objectivo da aplicação.
A principal característica que diferencia os elementos que constituem uma rede de sensores
sem fios das redes com fios é o facto de apresentarem, por norma, grande autonomia e
independência do exterior. Deste modo estes componentes electrónicos podem ser incluídos
em redes densas ou esparsas conforme a aplicação pretendida. Por exemplo, no caso da
monitorização de grandes espaços agrícolas, esta rede tenderá a ser pouco densa, ao
contrário de um sistema interior num ambiente fabril, onde tenderá a ser muito densa nas
zonas mais críticas de produção.
Esta tecnologia tem enormes potencialidades ao nível dos serviços disponibilizados, que
aumentam naturalmente com o incremento das capacidades individuais de cada sensor,
principalmente ao nível do processamento, do armazenamento dos dados lidos e do tempo de
vida das baterias. Os serviços que uma rede com estas características oferece ultrapassam em
muito os serviços de um único nó. Permitem, por exemplo, a recolha de dados estatísticos de
uma grandeza física (humidade, temperatura, etc.), de uma zona agrícola ou a definição de
alarmes muito úteis em áreas de aplicação ligadas à domótica e segurança.
2
1.1. Objectivos
A presente tese propõe uma camada de serviços que realize uma abstracção entre a aplicação
e os serviços específicos de comunicação e monitorização de dados implementados na rede
de sensores. Os serviços actuam como uma camada de middleware, que escondem às
aplicações grande parte dos detalhes de configuração da rede e das decisões de baixo nível.
Assim, esta camada de serviços tem por objectivo simplificar os esforços de desenvolvimento
de aplicações baseadas em redes de sensores sem fios, oferecendo um conjunto genérico de
serviços que podem ser usados em diferentes áreas de aplicação.
Actualmente, para cada domínio de aplicação em que se pretenda usar uma rede de sensores
sem fios, são feitos desenvolvimentos específicos. Isto acarreta dificuldades de adaptabilidade
a possíveis alterações ao nível da estrutura da rede, levando a um aumento do custo. Este
trabalho pretende desenvolver um conjunto de serviços que permitam que uma rede de
sensores possa ser usada em diferentes aplicações, bastando para isso configurá-la. Esta
configuração baseia-se na definição de diferentes serviços fornecidos por cada sensor, ou
actuador, e o tipo de comunicação utilizada.
Os serviços de aquisição disponibilizados baseiam-se na leitura, envio de dados e na definição
de diversos tipos de alarmes. Assim, esta camada de serviços propõe vários modos de leitura
de dados, nomeadamente a leitura a pedido, leitura periódica e notificação quando certos
limites pré-definidos são atingidos. Os serviços de comunicação permitem a agregação de
dados possibilitando deste modo reduzir o número de mensagens a circular na rede e levando
assim à poupança de energia consumida por cada elemento da rede.
A camada de serviços de comunicação foi estruturada de modo a que no futuro possam vir a
ser englobados outros protocolos, disponibilizando, por exemplo, serviços de segurança e cifra.
No entanto, no presente trabalho não foram abordadas todas estas vertentes de comunicação
devido à sua complexidade e extensão. Assim, por razões de simplificação, foram apenas
abordados dois tipos de protocolos de comunicação: Disseminação e Colecção de dados, os
quais se revelaram bastante eficazes.
Estes serviços propostos são implementados sobre uma plataforma especificamente
desenvolvida para redes de sensores sem fios - TinyOS 2.0 -; e sobre dispositivos de hardware
MICAz. No entanto, os serviços disponibilizados podem ser aplicados noutras plataformas e
noutros dispositivos de hardware, sendo necessário para tal realizar a adaptação dos serviços
utilizados na camada de middleware.
3
1.2. Organização da Tese
O próximo capítulo contém a descrição de todos os aspectos teóricos do trabalho
desenvolvido. São apresentados vários conceitos relacionados com a arquitectura,
funcionamento e optimizações de uma rede de sensores sem fios. São igualmente abordados
os diferentes aspectos que os serviços de uma rede deste tipo deve fornecer.
No capítulo 3 são apresentadas as principais características do hardware utilizado (MICAz),
bem como o funcionamento básico dos sensores e actuadores presentes na placa de interface
MTS310. São abordadas igualmente neste capítulo as diferentes características do nó,
nomeadamente as que se referem à comunicação por rádio frequência e ao consumo
energético.
No capítulo 4 é apresentada a arquitectura da camada de serviços desenvolvidos. São
descritos e justificados os critérios e opções adoptadas neste projecto bem como os diferentes
protocolos usados.
No capítulo 5 é apresentado o programa levado a cabo para demonstrar o funcionamento dos
diversos serviços disponibilizados pela camada de middleware desenvolvida. São descritos os
pormenores específicos de utilização e de instalação.
Por fim, no capítulo 6 são apresentados os resultados e conclusões da presente tese, sugere-
se trabalho futuro que seria interessante realizar para completar a nossa abordagem.
4
2. Redes de Sensores Sem Fios
As redes de sensores sem fios constituem um novo domínio de redes de sensores distribuídos,
que nos últimos anos foram alvo de vários projectos de pesquisa e desenvolvimento. Estas
redes são fortemente limitadas pela eficácia das fontes de energia de cada nó, afectando as
capacidades de armazenamento, processamento e ligações através da rede sem fios. Sendo o
principal objectivo destas redes a recolha, colecção e entrega de dados a uma determinada
aplicação cliente, diversos protocolos foram desenvolvidos. Os dados recolhidos pelos diversos
sensores da rede são encaminhados automaticamente pela rede para nós saída, onde estes
podem ser tratados e analisados.
Nesta secção estão apresentados todos os conceitos básicos que tiveram por detrás do
desenvolvimento deste trabalho. Em 2.1, é abordada a arquitectura de uma rede de sensores
sem fios, em que são explicados os diferentes aspectos de hardware, protocolos e aplicações.
Em 2.2 são explicadas as restrições básicas de uma rede deste tipo; enquanto em 2.3 é
descrito o conceito básico de um middleware aplicado a redes de sensores sem fios. Em 2.4
são abordadas as diferentes optimizações energéticas; e, por último, em 2.5 é feita uma
pequena abordagem ao sistema operativo utilizado no desenvolvimento deste trabalho.
2.1. Arquitectura
As redes de sensores sem fios têm uma estrutura organizacional com três vectores básicos: a
infra-estrutura, a pilha de protocolos e a aplicação ou observador [1]. A infra-estrutura é
composta por todos os sensores físicos e as respectivas características intrínsecas e de
instalação presentes numa rede de sensores sem fios. As suas características intrínsecas
aludem à sua autonomia, armazenamento e processamento, enquanto as características de
instalação mencionam o local e o modo de instalação de cada dispositivo da rede. A pilha de
protocolos reporta-se às diversas camadas de protocolos presentes em cada nó da rede. Por
fim, a aplicação traduz os interesses e objectivos finais para os quais a rede foi desenvolvida.
A aplicação deve definir o modelo de entrega de dados que mais se adequa aos seus
objectivos. Para tal existem vários modelos que podem ser divididos em entregas contínuas,
dirigidas a eventos, iniciadas pelo nó ou híbridas. Para realizar cada modelo de entrega,
existem vários protocolos ao nível da rede que encaminham, de forma eficiente, o tráfego dos
dados desde o nó origem ao nó destino, um exemplo disto são os protocolos de disseminação
e colecção de dados utilizados neste trabalho.
5
2.1.1. Infra-estrutura
Uma rede de sensores sem fios é construída para suprir uma necessidade, para tal é
necessário montar e instalar a rede que melhor se adequa á natureza do problema. A infra-
estrutura de uma rede de sensores define todos os nós e as suas respectivas características
de instalação como, por exemplo, a sua localização, o tipo de memória, os sensores a que
estão acoplados, etc. Regra geral, todas as redes possuem pelo menos um nó de acesso,
estes tipos de nós são denominados nós saída.
A rede também é constituída por nós denominados sensores que têm a função de reunir e
transmitir todas as informações dos sensores a que estão acoplados para os seus nós
adjacentes. Estes nós podem ser constituídos por diversos sensores de vários tipos, toda a
informação recolhida tem de ser agregada pelo nó para poder ser enviada para os nós
requerentes, assim este tipo nó tem capacidades adaptadas à sua função.
Figura 1 - Representação de uma Rede de Sensores sem Fios
Na rede de sensores sem fios, os nós nós saída, adquirem um papel de ligação entre a rede e
o exterior. Este tipo de nós está ligado a um sistema com uma elevada capacidade
computacional e de armazenamento. Este sistema externo à rede, pode ser um computador ou
um PDA, responsável pela execução de algoritmos de decisão sobre os dados recolhidos.
Estes algoritmos consistem principalmente no armazenamento e tratamento dos diferentes
dados enviados pelos nós sensores. Estes tipos de nós realizam duas tarefas essenciais para
o funcionamento de uma rede de sensores, a tarefa de envio dos pedidos requisitados pelo
sistema externo à rede e a respectiva tarefa de recolha da informação dos outros nós.
6
O nó saída, além de coleccionar toda a informação que circula na rede, pode ainda alterar
parâmetros desta em tempo real. Os dados recolhidos pelo nó são apresentados ao utilizador
por intermédio de um computador ou por outro tipo de dispositivo electrónico. Deste modo,
assume-se que estes nós, devido à proximidade de componente deste tipo, não têm o factor
energético como uma limitação, uma vez que podem ser alimentados externamente por uma
fonte inesgotável de energia, por exemplo, a partir da rede eléctrica.
Do ponto de vista mais geral, os nós saída actuam como fornecedores de serviços para o
ambiente externo, isto é, fornecem acesso aos serviços da rede. Ao mesmo tempo comportam-
-se como solicitadores de serviços para os nós sensores, requisitando serviços especializados
de modo a responder às exigências de cada aplicação.
Os nós saída têm um papel totalmente transparente do ponto de vista da aplicação, uma vez
que não processam nem armazenam qualquer informação que passe por eles. Tudo o que lhes
chega é reencaminhado para o outro sistema, ou seja, as mensagens que são enviadas pela
porta série são colocadas na rede; em sentido oposto, as mensagens que circulam na rede que
têm como destino o nó saída são encaminhadas para a porta série.
Cada nó sensor pode ser dividido em quatro segmentos diferentes, sensores e actuadores,
processador e armazenamento, a energia e comunicação. Estes nós são compostos por
dispositivos sensoriais e pelos respectivos conversores analógicos digitais. Hoje em dia
existem os mais variados tipos de sensores e actuadores. A estes nós podem ser acoplados
diferentes tipos de sensores, por exemplo, sísmicos, magnéticos, térmicos, visuais,
infravermelhos, acústicos, radares etc.. Por isso, estes sensores são capazes de captar uma
grande gama de grandezas e facultar uma grande versatilidade às redes de sensores sem fios.
Os sensores submetem os dados analógicos recolhidos para a unidade de processamento
através do conversor analógico digital. O processador e a unidade de armazenamento são
responsáveis pela execução dos protocolos de comunicação e pela gestão da aquisição de
dados dos sensores. Os actuadores são usados para modificar o ambiente envolvente, a acção
de comando destes pode ser efectuada localmente, através do processamento dos dados
recolhidos, ou pela rede, através de um nó saída.
7
Figura 2 - Esquema de hardware do nó sensor.
A constituição do módulo de comunicação depende do tipo e função do nó, normalmente é
utilizado um sistema de comunicação de rádio frequência de curto alcance para comunicar com
os nós vizinhos. Este é composto por um transceiver, por uma antena e por um conjunto de
características discretas do sistema físico, tal como sensibilidade e intensidade do sinal.
Focalizando apenas no funcionamento básico do transceiver, este tem três modos de
funcionamento, recepção, transmissão, sleep [2].
A fonte de energia dos nós é constituída por baterias e por um conversor DC-DC. A duração da
bateria depende de vários factores, tais como a dimensão, o material que a constitui, etc.. O
conversor DC-DC é um dispositivo electrónico que recebe uma tensão e DC e coloca à saída
uma outra tensão DC de nível diferente. Este conversor é responsável pela durabilidade da
bateria e pela tensão constante à entrada do sensor.
Os nós sensor obedecem a uma arquitectura baseada na recolha e envio de dados para o nó
de saída. Estes nós são responsáveis pelo envio das informações adquiridas pelos diferentes
sensores que lhe estão acoplados. As informações que são enviadas são previamente
requisitadas através do nó saída pela aplicação.
O processamento típico para este tipo de nós é muito reduzido, devido à sua reduzida
dimensão e capacidade energética. Se quisermos uma rede de sensores sem fios que seja
eficiente e duradoura, temos de abdicar de tudo o que consuma energia inútil. Assim, os
processadores destes mecanismos são arquitectados apenas para corresponder às exigências
de aquisição e comunicação básicas de cada nó.
Cada nó sensor pode ser composto por um número limitado de sensores. Esta restrição advém
das limitações físicas de cada dispositivo, principalmente devido ao número limitado de
ligações físicas disponibilizadas pelo hardware, ou até às limitações energéticas inerentes ao
consumo de cada sensor.
8
2.1.2. Pilha de Protocolos
A pilha de protocolos usada nos nós sensores está apresentada na figura 3. Esta pilha é
constituída por cinco camadas horizontais (Aplicação, Transporte, Rede, Ligação, Física) e três
planos verticais (Energia, Mobilidade, Tarefas) [3]. Esta pilha de protocolos integra a eficiência
enérgica com a comunicação e promove esforços em cooperação de todos os nós.
Camada de Aplicação
Camada de Transporte
Camada de Rede
Camada de Ligação
Camada Física
Gestão de Energia
Gestão de C
onectividade
Gestão de Tarefas
Figura 3 - Pilha de Protocolos
A camada de transporte ajuda a manter o fluxo de dados da camada de aplicação. O
encaminhamento dos pacotes desses dados é assegurado pela camada de rede. A camada de
ligação assegura as ligações confiáveis numa rede de comunicação. Utilizando fluxos
multiplexados de dados, detecção de quadros, acesso ao meio e controlo de erros. O uso do
protocolo de acesso ao meio MAC (Medium Access Control) minimiza as colisões entre nós
vizinhos que podem ser móveis e inseridos em ambientes ruidosos. Existem muitos protocolos
baseados em MAC, mas poucos têm em conta as características necessárias para uma rede
de sensores sem fios, sendo a poupança de energia um vector fundamental para esses
protocolos MAC. Os principais factores para o desperdício de energia são as colisões, a
recepção de pacotes que não lhe são endereçados e a espera ociosa.
A camada física é responsável pela transmissão, recepção e modulação usada na rede. A
transmissão e recepção são responsáveis pela maior parte do consumo de energia em redes
de sensores sem fios. Assim, a decisão sobre quais as características de transmissão a utilizar
deve ter sempre em atenção o factor energético, tais como a frequência, os mecanismos de
detecção de sinal e a modulação utilizados.
Os planos horizontais permitem coordenar todos os nós sensores na realização de tarefas
sensoriais no controlo do consumo global de energia da rede, de forma a minimizá-lo. O plano
de gestão de energia possibilita gerir a forma como cada nó gasta a sua fonte energética. A
gestão de conectividade detecta e regista o movimento dos nós sensores, de modo a poder
9
determinar em cada instante a informação dos nós vizinhos. Assim, é possível guardar
informação sobre as rotas para cada nó da rede.
O plano de gestão de tarefas tem por objectivo o escalonamento sensorial em áreas
específicas a monitorizar, o que possibilita o acesso a tarefas dos nós sensores de uma região
específica, evitando deste modo a sobrecarga da rede. Este escalonamento tem em conta o
nível energético e o grau de importância de cada nó na realização de uma determinada tarefa.
Deste modo, é possível numa região específica, separar os nós de acordo com a sua
importância para a realização de uma tarefa.
Os planos de gestão permitem que os nós sensores cooperem entre si de uma forma eficiente
em termos energéticos. Sem estes planos cada sensor funcionava individualmente, em
prejuízo da eficácia dos serviços da rede. Assim, do ponto de vista das redes de sensores sem
fios é importante que os seus sensores trabalhem em conjunto para que o tempo de vida da
rede seja optimizado da melhor forma e as tarefas sejam compridas eficazmente.
2.1.3. Aplicações
Como já foi referido anteriormente cada nó sensor tem a capacidade de reter a informação de
cada sensor a que está acoplado, sendo a acção deste determinada pelas características dos
sensores. O nó sensor possibilita diferentes modos de acesso aos dados dos sensores,
nomeadamente, a leitura a pedido, a leitura periódica e a notificação quando certos limites pré-
definidos são atingidos. Assim, o uso destes modos de acesso fornece serviços que podem ser
utilizados numa ampla gama de aplicações.
Sendo a aplicação parte integrante da rede, esta é responsável pela submissão de um conjunto
de consultas e interesses que descrevem os diversos fenómenos físicos a que a rede está
habilitada. Os interesses devem indicar, entre outros: o tipo de dados pretendidos; a frequência
com que os dados devem ser recolhidos e os eventos que podem despoletar algum
comportamento particular da rede.
As redes de sensores sem fios podem ser inseridas em diversas áreas de aplicação, das quais
se destacam: a área militar, área ambiental, área de saúde, área da Domótica, área industrial
entre outras. De referir que estas redes também podem ser aplicados em ambientes em que
qualquer falha do sistema pode pôr em risco vidas humanas, por exemplo, na exploração
espacial, no socorro de vítimas de desastres, etc..
As redes de sensores sem fios têm características que se podem adaptar facilmente em
ambientes militares, devido à sua rápida instalação, a capacidade de auto-organização e
tolerância a falhas. Neste cenário a destruição de um conjunto de nós da rede, por parte do
inimigo, não significará a total destruição da rede, uma vez que esta tem uma adaptação
10
automática. Desta forma, esta característica é um trunfo importante na aplicação em sistemas
militares de comando, de controlo, de comunicação, de computação e de vigilância.
As aplicações ambientais consistem, essencialmente, na monitorização do movimento de
animais ou das condições ambientais que afectam, por exemplo, uma colheita, o controlo de
irrigação, a detecção química e biológica, detecção de incêndios florestais, pesquisa
meteorológica e geofísica, entre outros. Relativamente à área da saúde, existem várias
aplicações de entre as quais se destacam a monitorização de pacientes, realização de
diagnósticos, administração de fármacos. Nomeadamente, existem outras aplicações ligadas à
área industrial, por exemplo, a monitorização da fadiga do material, monitorização de qualidade
de produtos, controlo ambiental de edifícios inteligentes.
Actualmente, a área da Domótica está em franco desenvolvimento, existindo inclusive diversos
sistemas por fios que realizam tarefas, tais como: ligar electrodomésticos; abrir e fechar
persianas; rega; ligar e desligar iluminação. Têm igualmente a capacidade de se integrarem
com redes externas como a internet ou telefone. Assim, no caso específico da domótica, as
redes de sensores sem fios pressupõe a passagem de uma rede com fios para uma rede sem
fios, criando novos serviços e aperfeiçoando os já existentes noutras tecnologias com fios. O
principal trunfo das redes de sensores sem fios nesta área centra-se essencialmente na
facilidade de instalação sem a necessidade de realização de modificações nas casas.
Como ficou demonstrado nesta secção, a aplicação de uma rede de sensores sem fios, no
mundo real, é muito vasta. Este facto levanta questões desafiantes, nomeadamente na
integração dos serviços disponibilizados pela rede, de modo a corresponder às necessidades
dos diferentes tipos de aplicação.
Na figura 4 está apresentado um exemplo de uma aplicação real apoiada pela Universidade de
Harvard, em que é usada uma rede de sensores sem fios para realizar a monitorização dos
diferentes fenómenos físicos de vulcões activos [4]. Cada nó sensor é equipado com um
sensor sísmico, um sistema de localização GPS, sensor de inclinação, sensor térmico óptico e
um medidor de fluxo de gás. Estes sensores permitem o acesso a variáveis físicas
fundamentais para o estudo dos fenómenos vulcânicos. Em particular nesta aplicação, o nó de
saída comunica com o observatório por uma ligação de rádio de longa distância, uma vez que
o observatório se situa normalmente distante do vulcão por razões de segurança.
11
Figura 4 - Exemplo monitorização vulcânica [4].
Este exemplo realça a ampla gama de aplicações desta tecnologia, nomeadamente neste caso
em que o acesso aos locais é tremendamente difícil. Neste caso particular o uso de uma
tecnologia por fios seria ineficaz, pois a lava expelida pelo vulcão poderia atingir os cabos
inactivando de imediato a rede, o que não acontece com a rede de sensores sem fios uma vez
que, mesmo que sejam destruídos vários nós, a rede pode funcionar. Neste exemplo, os nós
podem ser lançados por helicóptero, caso se trata de locais inacessíveis, de forma a adquirir
dados que, através de outra tecnologia, não seriam possíveis de aceder.
12
2.2. Restrições da rede de sensores sem fios
Apesar das virtudes da utilização de uma rede de sensores sem fios serem muitas, é
necessário adaptar as limitações deste sistema a cada tipo de aplicação. As restrições de uma
rede de sensores sem fios dependem de cada aplicação como, por exemplo, para aplicações
de domótica, o consumo energético não é um factor limitativo uma vez que os dispositivos
podem estar ligados directamente à rede eléctrica.
Nesta secção são apresentados diferentes factores que restringem normalmente o uso de uma
rede de sensores sem fios em determinadas aplicações. Essas restrições baseiam-se
principalmente nos efeitos colaterais de uma má política de gestão energética. Deste modo na
secção 2.2.1. analisam-se os factores que afectam o tempo de vida da rede, enquanto em
2.2.2 é analisada a cobertura global da rede e, por fim, são dissecados os factores que afectam
o tempo de resposta aos pedidos da rede.
2.2.1. Tempo de vida
O principal factor limitativo do tempo de vida é a energia, sendo que habitualmente esse
fornecimento é feito por baterias ou afins que são limitadas em termos energéticos. Cada nó
deverá gerir e optimizar da melhor forma o recurso energético, de modo a minimizar o consumo
e assim maximizar o tempo de vida da rede. Na maioria das aplicações o tempo de vida
mínimo de cada nó é mais valorizado do que o tempo médio de vida, pois o tempo médio de
vida pode nunca vir a ser atingido. Particularmente, em aplicações de segurança, a quebra de
funcionamento de algum dos nós pode implicar a falha de segurança de toda a rede.
Na maioria das aplicações os nós são alimentados por baterias internas, isso implica que os
nós terão de armazenar energia suficiente para o seu funcionamento ou terão de ser capazes
de gerar energia através do ambiente, por exemplo, a partir de painéis solares ou geradores
piezoeléctricos. Em qualquer dos casos é indispensável que o consumo de cada nó seja
optimizado.
A técnica que geralmente é utilizada na poupança de energia em cada nó baseia-se em
desligar por breves instantes um determinado componente de hardware do dispositivo,
usualmente o componente de rádio frequência. Deste modo, o componente durante o período
sleep não poderá realizar qualquer acção. Esta técnica é bastante eficaz em termos
energéticos mas, no entanto, é necessário ter em atenção o desempenho dos serviços que
utilizem o dispositivo. Por exemplo, no caso do componente de rádio utilizar protocolos
baseados em múltiplos saltos, os pacotes enviados demoram mais tempo a serem
recepcionados pois têm de esperar pelo período activo de cada nó presente no caminho até ao
nó destino.
13
2.2.2. Cobertura
A cobertura da rede é outro factor crítico importante nas redes de sensores sem fios. Quanto
maior for a área de cobertura da rede, mais serviços serão disponíveis às diversas aplicações.
Apesar de cada rede ser composta por vários nós, nem todos eles, necessariamente, têm a
mesma cobertura individual.
A comunicação em múltiplos saltos ou multi-hop tem a capacidade de estender, na teoria até
ao infinito, a cobertura da rede para além da simples cobertura da comunicação rádio de cada
nó. Este protocolos requerem uma baixa densidade de nós da rede o que leva ao aumento do
custo de desenvolvimento.
A necessidade do aumento do conhecimento do ambiente obriga a um aumento do número de
nós na rede e o consequente incremento do número de dados a ser transmitidos pela rede.
Este facto origina um maior desgaste dos nós principais da rede, reduzindo o tempo de vida útil
do sistema. Os nós mais importantes do sistema são aqueles que sofrem maior desgaste ao
longo do tempo, que são os nós mais próximos do nó saída. Assim, o aumento da cobertura da
rede aumenta os serviços disponibilizados em prejuízo do tempo de vida útil da rede.
2.2.3. Tempo de Resposta
O tempo de resposta é um factor crítico para certas aplicações que se baseiam em sistemas de
alarme. A ocorrência de um alarme, pré definido pela aplicação, deve ser sinalizada o mais
rápido possível à aplicação. Ou seja, os nós devem ser capazes de fornecer uma imediata
comunicação das mensagens de alarme à aplicação. Por natureza, a ocorrência de situações
denunciadas pelos alarmes acontecem com baixa frequência e surgem em qualquer momento
sem qualquer aviso prévio. Por exemplo, o tempo de resposta é um factor decisivo para
aplicações em ambiente fabril, onde esta tecnologia é usada para controlar o funcionamento de
diferentes tipos de máquinas. Assim, neste tipo de cenários, as redes de sensores sem fios só
são usadas se forem capazes de garantir uma resposta às ocorrências em tempo útil.
A capacidade de ter rapidez de resposta influencia negativamente outro recurso crítico do
sistema, o tempo de vida útil da rede. Para aumentar o tempo de vida são utilizados
mecanismos que se baseiam em desligar o rádio dos nós num curto espaço de tempo. Isto tem
implicações óbvias no tempo de resposta do sistema. Em sentido contrário, para aumentar o
tempo de resposta do sistema, o componente de rádio dos nós tem de ficar ligado durante todo
o tempo. Assim, os nós são capazes de receber e reencaminhar as mensagens quando
necessário.
14
2.3. Camada de Serviços
Entre os diversos níveis da pilha de protocolos (apresentado na secção 2.1.2.) existe um
grande acoplamento, de modo a tornar o sistema eficiente e robusto. Este acoplamento pode,
no entanto, gerar um sistema rígido e pouco versátil, isto é, pode gerar redes específicas
apenas para atender poucas aplicações. Esta inflexibilidade da pilha não é desejável a médio e
longo prazo, devido aos custos do seu desenvolvimento.
A existência de uma camada de serviços denominada por middleware, entre a pilha de
protocolos e a aplicação, é benéfica para o sistema uma vez que permite uma maior
flexibilidade e torna quer os serviços de comunicação, quer os de acesso aos dados dos
sensores mais acessíveis. Esta camada fornece à aplicação os requisitos específicos de cada
tipo de rede e facilita a integração da aplicação no sistema.
A camada de middleware apresenta, através de uma interface de alto nível, funcionalidades de
acesso aos dados realizando a tradução dos requisitos de rede. Estes requisitos baseiam-se
na escolha dos protocolos que definem a topologia e a lógica da recolha dos dados
pretendidos. Devido às características dinâmicas de uma rede deste tipo, o middleware deve
pôr à disposição da aplicação mecanismos que permitam a configuração, inspecção e a
adaptação a este comportamento dinâmico da rede.
O reduzido poder computacional e a limitação energética de cada nó da rede obriga o
middleware a fornecer mecanismos de optimização destas características. Em geral, a
topologia da rede não se mantém fixa, tal como acontece nas redes fixas. Esse dinamismo
advém da desconexão de nós por destruição, por escassez de recursos energéticos ou mesmo
por falta de comunicação. Assim, a topologia da rede é alterada em conformidade com as
medidas tomadas pelos protocolos utilizados, estes podem decidir desligar um sensor ou ligar
outro em virtude da poupança de energia e do interesse da aplicação. Estas características
revelam um alto nível de dinamismo e elevado grau de disponibilidade dos nós e do contexto
de execução da rede.
O middleware de uma rede de sensores sem fios deve actuar em três planos: Energia;
Mobilidade e Tarefas. A função principal do middleware baseia-se no suporte ao
desenvolvimento e execução de aplicações sensoriais e na gestão dos recursos da rede.
A camada de middleware abstrai à aplicação os protocolos de comunicação e as
características de infra-estrutura. Tendo em conta os diferentes requisitos definidos pela
aplicação, esta deve escolher de forma transparente os protocolos de comunicação e de infra-
estrutura que melhor se adapta às necessidades e exigência da aplicação. Essa abstracção
deverá fornecer uma interface de alto nível encapsulando diferentes protocolos de
comunicação.
15
A selecção dos nós que participam na realização de cada tarefa de aquisição de dados,
também é da responsabilidade do middleware. Essa escolha deverá sempre ter em conta aos
requisitos da aplicação e a optimização do consumo global de energia da rede.
O conhecimento da aplicação é fundamental para o middleware em decisões de
encaminhamento e agregação de dados. O compromisso entre o grau de especificidade e a
generalidade do middleware tem de ser considerado para cada tipo de aplicação, isto é, para
um determinado middleware deverá servir uma ampla gama de aplicações. Deste modo, na
prática utiliza-se a construção de um perfil onde é definido um conjunto de características de
uma determinada aplicação, e assim cada perfil pode ser interpretado pelo middleware para
direccionar as suas operações de modo a satisfazer, da melhor maneira, a aplicação desse
perfil.
No ambiente dinâmico em que, tipicamente, uma rede de sensores sem fios se insere, o
middleware, para manter a qualidade dos serviços, deve alterar os seus parâmetros de
configuração ao longo do tempo de modo a compensar as alterações. Assim, o contexto de
execução de um middleware não pode ser estático, deve ser continuamente monitorizado de
modo a que as aplicações sejam cientes do contexto e participem das tomadas de decisão.
Neste caso, as aplicações podem participar nas decisões de infra-estruturas e da activação de
estratégias de adaptação.
16
2.4. Optimização de energia
O consumo de energia de uma rede de sensores sem fios não pode ser desprezada, uma má
gestão deste recurso pode levar à ineficiência total da rede anulando as principais vantagens
do uso deste tipo de redes. Se os nós não gerem a sua energia de forma eficiente, torna-se
necessário substituir a sua fonte energética frequentemente. Este factor é importante em casos
em que os nós estão localizados em sítios de difícil acesso. Assim, é fácil imaginar um cenário
em que sempre que num dos nós se esgotava a energia, corria-se o risco de perder a utilidade
global da rede, muito embora existam ainda nós operacionais.
Caracteristicamente, as aplicações de redes de sensores sem fios requerem tempos de vida de
meses ou até anos. Nesta situação, o consumo de energia deve ser minorado, uma vez que é
o principal factor responsável pelo tempo de vida da rede.
Todos os factos apresentados servem para demonstrar a importância da conservação
energética. Assim, a maximização do tempo de vida está intimamente ligada à minimização do
consumo energético e deste modo requer o uso de metodologias holísticas estruturadas. É
importante que todas as operações transversais desde do hardware até ao software da
aplicação tenham em conta o ponto de vista energético. Os protocolos de rede devem então
incluir mecanismos que possibilitem o racionamento do uso da energia, tendo sempre em
atenção o desempenho e a fidelidade operacional.
2.4.1. Optimização do Nó sensor
A optimização do consumo de energia global depende essencialmente da política individual
adoptada por cada nó. No ponto de vista do hardware existem diversos avanços tecnológicos,
nomeadamente, em micro controladores de baixo consumo que podem ser incorporados em
nós sensor. Ainda assim o uso da gestão dinâmica de energia (DPM - Dynamic power
management) [5] pode aumentar o tempo de vida da bateria. Esta gestão dinâmica baseia-se
em desligar os componentes que estão no estado sleep. Assim, o nó sensor é desligado ou
colocado num estado de baixo consumo se nenhum evento ocorrer. Torna-se assim fulcral
definir a política de transição de estados, uma vez que diferentes estados conduzem a
diferentes consumos de energia e a energia de comutação entre eles não é de desprezar.
17
Figura 5 - Esquema de optimização energética de um nó sensor.
Existe igualmente técnicas de poupança de energia que se baseiam na redução dinâmica da
voltagem (DVS - Dynamic Voltage Scaling) [6] que alimenta cada componente. Em geral, a
carga computacional no micro controlador nunca é a mesma ao longo do tempo, sendo que
nem sempre o pico máximo de processamento é atingido. Deste modo, aproveitando esta
característica, o DVS adapta a voltagem de alimentação e a frequência de operação de modo a
fornecer unicamente ao micro controlador a capacidade de processamento necessária em cada
instante. O uso desta técnica é bastante eficaz comparando com a DPM, pois não desliga
completamente o componente do dispositivo.
Existem técnicas de escalonamento de modelação (DMS – Dynamic modulation scaling) [7],
que possibilitam a adaptação dinâmica do nível de modulação da portadora em cada instante à
carga instantânea de tráfego. Uma gestão coordenada de energia utilizando, de forma
inteligente, estas três técnicas leva a um aumento do rendimento da rede de sensores sem
fios.
A maior eficiência energética é atingida quando o hardware é desenvolvido especificamente
para uma determinada aplicação. Assim, não sendo possível esse desenvolvimento específico
para cada aplicação de redes de sensores sem fios, o sistema operativo tem de assumir o seu
papel fulcral neste aspecto. Os sistemas operativos têm uma grande responsabilidade em
termos da gestão energética, podendo controlar os recursos de hardware e possibilitando
negociar o desempenho com o consumo energético da melhor maneira.
Uma parcela muito grande do consumo de energia de cada nó sensor é consumida na
comunicação da rede de sensores sem fios. Por conseguinte, é importante tirar o máximo de
proveito do compromisso desempenho/consumo energético, definindo e actuando nos factores
que influenciam de uma forma mais significativa este compromisso.
18
2.4.2. Optimização Global
A optimização de energia, a nível global de uma rede de sensores sem fios, fixa-se
principalmente nos protocolos de encaminhamento dos dados entre os diferentes nós da rede.
Os nós sensores estão distantes dos nós saída, tornando inevitável a ocorrência de múltiplos
saltos entre nós intermédios. Assim, a alta densidade de nós que normalmente podemos
encontrar neste tipo de redes, potencia a ocorrência de múltiplos saltos entre os diferentes nós
que estejam localizados entre os nós de origem e destino. Em particular, os nós mais próximos
do nó saída sofrem maior desgaste, uma vez que a informação de toda a rede tem de passar
directamente por eles. Deste modo, é importante desenvolver politicas de gestão de rotas.
Existem diversos estudos que retratam a problemática energética de uma rede de sensores
sem fios. O autor de [8] defende que, do ponto de vista energético, quando a distância de
transmissão aumenta, é vantajoso aumentar o número de nós intermediários. Os dados são
enviados por diferentes nós sensores e podem ser agregados nos nós intermédios, de modo a
reduzir a redundância, a minimizar o tráfego de dados que circulam na rede e a diminuir o
consumo total de energia.
O aumento da densidade de nós de uma rede não significa directamente um aumento do
tempo de vida, uma vez que o consumo do rádio no estado sleep difere muito do consumo dos
outros estados de recepção e transmissão, conforme é defendido por [9]. Para diminuir o
consumo é possível desligar um determinado componente, no entanto esta passagem requer
uma gestão bastante cuidada, uma vez que, ao passar para este estado, os nós passam a
estar temporariamente inactivos alterando a topologia da rede.
Uma técnica simplista que visa a poupança enérgica global da rede é a agregação ou fusão de
dados. Consiste em combinar os dados oriundos de diferentes fontes (nós ou sensores), de
forma a ampliar e a concentrar informação. Deste modo, consegue-se eliminar dados
redundantes e diminuir os pacotes que circulam na rede, desta forma consegue-se economizar
energia.
Resumindo, de maneira a aumentar o tempo global de vida da rede deve-se garantir que o
tráfego é distribuído entre os nós de uma forma eficiente do ponto de vista energético. É
importante adquirir estratégias inteligentes de encaminhamento e de manutenção da topologia
baseadas, por exemplo, em técnicas de agregação de dados em determinados nós ou mesmo
a redução do número e dimensão dos pacotes de dados.
19
2.5. TinyOS 2.0
Actualmente, na versão 2.02, o TinyOS é um sistema operativo desenvolvido especificamente
para corresponder de forma eficiente às exigências específicas de uma rede de sensores sem
fios. O TinyOS é um sistema operativo que se baseia na execução de eventos, foi desenhado
especificamente para ser energeticamente eficiente e modular. Este sistema operativo permite
que um dispositivo de escassas capacidades contenha elevados níveis de concorrência, em
contraste com os sistemas operativos baseados em threads, que exigem a reserva de espaço
por cada contexto de execução.
O TinyOS é um sistema operativo open-source desenvolvido especificamente para plataformas
de redes de sensores sem fios. Trata-se de um sistema operativo embebido, escrito na
linguagem de programação nesC [10], sendo capaz de gerir tarefas e processos. O TinyOS é
desenvolvido por um consórcio liderado pela Universidade da Califórnia e pela Intel
Corporation.
Como já tinha sido referido, o TinyOS é um sistema operativo orientado a eventos, ou seja,
camadas de baixo nível têm a capacidade de enviar eventos às camadas acima. Assim, não
contém um ciclo de espera, uma vez que o tempo de espera de um evento é muito pequeno. O
TinyOS realiza a integração completa com hardware.
Este sistema operativo é igualmente dirigido a interrupções. Existem dois tipos de interrupções;
por relógio e por rádio. As interrupções por relógio acontecem quando se está a usar um
temporizador, quando este dispara é gerado uma interrupção no processador que é
interpretada pela camada mais baixa do sistema operativo, sinalizando às camadas de cima
até chegar a aplicação. O mesmo se passa nas interrupções por rádio, a aplicação é sinalizada
quando um pacote chega por rádio.
O TinyOS foi desenvolvido de modo a ser modular, isto é, cada componente é responsável
apenas pelos serviços que oferece. Então, um componente é uma peça do sistema que só
depende de outros componentes que lhe fornecem serviços. Isto faculta uma grande
flexibilidade ao sistema, pois cada componente é independente da aplicação, sendo possível
utilizar vários componentes ao mesmo tempo.
20
2.5.1. Modelo de Funcionamento
O modelo de execução do sistema operativo TinyOS 2.0 baseia-se em comandos e eventos
oriundos dos diferentes módulos. Os eventos são originados pela acção do hardware em
resposta de um comando. O sistema está desenvolvido para que a resposta de algum evento
detectado pelo hardware chegue à aplicação através de uma cadeia de eventos entre os
diferentes módulos. Então, uma aplicação em TinyOS é composta por um conjunto de
componentes ligados entre si e dois níveis de escalonamento.
Figura 6 - Modelo de funcionamento do TinyOS 2.0
O componente é composto por quatro partes inter-relacionadas: uma lista de comandos; uma
lista de eventos; uma frame e um conjunto de tarefas (Tasks). A frame trata-se de uma parte de
memória estática que contém o estado do componente. Por sua vez, os comandos e eventos
são funções chamadas através dos componentes que fornecem uma resposta de sucesso ou
falhanço. Os comandos requisitam execuções de mais baixo nível e não são bloqueáveis.
Sendo que cada componente de baixo nível possui controladores que correspondem aos
pedidos vindos da camada acima. Por outro lado, os eventos são invocados de modo a lidarem
directamente com os eventos de hardware directa ou indirectamente. Os componentes de
baixo nível são responsáveis por lidar com as interrupções de hardware, podendo executar um
pequeno processamento e gerar outros eventos. Assim, a execução de um componente
baseia-se no envio para baixo nível dos comandos e a geração de eventos para as camadas
acima.
As tarefas ou Tasks fornecem a capacidade de incluir a computação arbitrária num sistema
dirigido a eventos. Estas são atómicas em relação às outras tarefas mas não possibilitam a
preempção com os eventos. As Tasks podem ser chamadas em qualquer altura mas só são
21
executadas quando nenhuma outra operação está a correr. Em particular, no TinyOS 2.0 foi
adicionado ao sistema de preempção das tarefas um novo escalonamento capaz de
interromper uma tarefa não crítica começando por executar a tarefa de maior prioridade.
O TinyOS é, actualmente, composto por dois níveis de escalonamento. O primeiro nível é
responsável por gerir os comandos e eventos. As interrupções por hardware devem notificar as
aplicações o mais rapidamente possível, assim apenas é permitido efectuar pequenos
processamentos associados a estas. O segundo nível é responsável pelo controlo das tarefas.
Assim, quando uma tarefa é chamada dentro de um evento ou comando, esta é posta numa fila
de espera do tipo FIFO (First In First Out). Deste modo, as tarefas só são executadas quando
o processador não está a executar qualquer evento ou comando. Contudo, a execução destas
podem ser interrompidas por hardware. Quando não existe nenhuma tarefa, evento ou
comando a executar, o processador é colocado em modo sleep, enquanto os periféricos
continuam operacionais de modo a permitirem que o sistema possa acordá-lo quando alguma
interrupção por hardware ocorra.
O sistema operativo TinyOS pode ser classificado em três grupos de componentes [11] (ver
Figura 7). O primeiro grupo é constituído pelos componentes que formam uma fina abstracção
do hardware, por exemplo, o relógio. Os componentes que fazem parte do segundo grupo
actuam como substitutos de um hardware não existente, por exemplo, os componentes ao
nível do byte do rádio. E, por fim, o terceiro grupo é composto por componentes software de
alto nível responsáveis pelo controlo da aplicação.
Figura 7 - Camadas de abstracção
22
2.5.2. Linguagem de Programação nesC
A linguagem de programação nesC (network embedded systems C) [10] é uma extensão da
linguagem C desenhada especificamente para a plataforma de TinyOS. As bibliotecas e as
aplicações do sistema operativo TinyOS são escritas nesta linguagem de programação.
O nesC tem uma sintaxe semelhante à linguagem C, embora suporte o modelo deste sistema
operativo. Assim, fornece mecanismos de estruturação, ligação e nomeação de componentes
de software. Esta linguagem permite aos programadores construir de forma simples sistemas
simultâneos completos. Neste trabalho utilizou-se a versão 1.2 do nesC, a qual é um requisito
de instalação do TinyOS 2.0.
As aplicações construídas em nesC baseiam-se em ligações entre diferentes componentes
através de interfaces. Assim, um componente fornece e usa interfaces. Estas interfaces são
bidireccionais, contêm comandos e eventos. Os componentes fornecedores da interface
implementam os comandos, enquanto os utilizadores implementam os eventos.
A separação da definição das interfaces dos componentes fornecedores e utilizadores
possibilita a existência de interfaces standard, proporcionando componentes reutilizáveis e
mais flexíveis. Assim, um componente pode utilizar e fornecer o mesmo tipo de interface ou,
até mesmo, fornecer múltiplas instâncias da mesma interface.
Em nesC existem dois tipos de componentes: módulo e configuração. Os componentes de
módulo fornecem o código da aplicação e implementam uma ou mais interfaces. Os
componentes de configuração são usados para definir as interfaces que realizam as ligações
entre os diferentes componentes. Assim, todas as aplicações em nesC são descritas em alto
nível por um componente de configuração responsável pela ligação de todos os componentes
que são utilizados.
23
3. Hardware
O primeiro passo para o desenvolvimento de uma rede de sensores sem fios é a definição do
hardware que melhor se adequa ao ambiente e ao papel que a rede terá de desempenhar.
Existem diversas famílias hardware desenvolvidos especificamente para este tipo de redes por
pesquisadores da Universidade da Califórnia. Estes componentes de hardware foram
desenvolvidos tendo em conta principalmente o seu consumo energético e a sua dimensão,
são geralmente conhecidos como motes.
Nesta secção são apresentados os componentes de hardware utilizados no desenvolvimento
deste trabalho, nomeadamente, o mote MICAz e a placa de sensores MTS310, ambos
desenvolvidos pela empresa Crossbow Tecnology, Inc [12]. Pretende-se com esta referência
revelar as características que tiveram por base algumas escolhas adoptadas ao longo do
presente projecto.
A evolução do hardware específico para redes de sensores sem fios tem vindo a acompanhar o
crescente interesse por esta tecnologia. Na figura 8 pode-se verificar a crescente evolução num
curto espaço de tempo da tecnologia aplicadas aos motes. Pode-se conferir ainda a
impressionante evolução na dimensão dos motes Speck, aumentado deste modo, a gama de
aplicações desta tecnologia.
WeC (1998)
René (1999)
Dot (2000)
Mica (2001)
Mica2Dot (2002)
Mica2 (2002)
Telos (2004)
Speck (futuro)
Figura 8 - Evolução dos motes.
24
Actualmente, além dos utilizados neste trabalho, existem outros motes compostos por
diferentes componentes de rádio e micro controlador, por exemplo, MICA2, MICA2DOT,
TmoteSky e TELOSB. Os Motes MICA2 e MICA2DOT partilham com o MICAz o mesmo micro
controlador ATMega128L, no entanto têm componentes de rádios diferentes. Ao contrário, o
TELOSB difere do MICAz apenas o processador TI MSP430 e a possibilidade de ligação
directamente a um computador através do USB.
Neste capítulo são apresentados os diferentes aspectos dos motes MICAz utilizados no
desenvolvimento deste trabalho. Em 3.1 são descritas as características gerais; em 3.2 a
bateria; enquanto a placa da sensores MTS310 é abordada em 3.3.. Os parâmetros que podem
ser definidos e retirados no componentes de rádio CC2420 presente neste Mote são
aclarados em 3.4..
25
3.1. Características do MICAz
Este trabalho foi desenvolvido especificamente para aplicação em motes MICAz [13] da
Crossbow Tecnology, Inc. [12]. O mote MICAz, ou também conhecido por MPR2400, usa um
dispositivo de rádio frequência CC2420, seguindo o protocolo de comunicação ZigBee. Este
mote combina a tecnologia de rádio transferência ZigBee com um micro controlador
ATMega128L e uma memória flash de 512 kb.
Figura 9 - MICAz
Figura 10 - Esquema de funcionamento do MICAz
Micro Processador
Modelo ATMega128L Tipo 7.37 MHz, 8 bit ROM 128 kB SRAM 4 kB
Placa de Sensores
Tipo 51 pinos ADC de 10 Bit 0,7 V a 3 V de entrada
UART 2 Outras interfaces DIO, I2C
Rádio
Chip CC2420 Frequência 2400 MHz
Débito Máximo 250 kbits/sec Conexão MMCX
Memoria Flash Chip AT45DB014B
Conexão SPI Tamanho 512 kB
Fonte de Energia Tipo AA, 2x
Capacidade típica 2000 mA-hr
Tabela 1 - Características do MICAz.
26
A tecnologia de transferência de dados por rádio frequência ZigBee foi arquitectada para
interligar pequenas unidades de comunicação em áreas muito limitadas. Esta tecnologia sem
fios diferencia-se das outras como as WI-FI ou Bluetooth pelo seu baixo consumo e alcance
reduzido (aproximadamente 10 metros). Sendo deste modo ideal para o uso em aplicações no
âmbito das redes de sensores sem fios.
A potência de transmissão das antenas de rádio frequência pode ser modificada em tempo de
execução, tendo em conta sempre o seu consumo e as necessidades da aplicação e o
ambiente em que se insere. Assim, é possível fornecer potências entre os 0 dBm até -25 dBm.
O alcance e o desempenho são factores importantes no posicionamento e colocação da
antena.
27
3.2. Bateria
A alimentação do MICAz é feita por duas pilhas do tipo AA, no entanto qualquer outro tipo de
alimentação que forneça 2.7 VDC a 3.6 VDC pode ser utilizada [13]. Quando os recursos de
um mote são bem geridos, as baterias podem ter um tempo de vida até aproximadamente 17
meses, dependendo do tipo de gestão da bateria realizado pela aplicação. O acesso ao rádio e
ao processador é responsável pelo maior gasto de energia do sistema, nomeadamente, a
transmissão de dados e a escrita em memória. O incorrecto uso deste recurso leva a um
elevado consumo de energia e consequentemente à perda de tempo de vida do mote. Assim,
deve-se aumentar ao máximo o período em que cada recurso está no estado sleep.
Componente Consumo
Processador 0.0879 mA-hr
Rádio 0.0920 mA-hr
Acesso a Memória 0.0020 mA-hr
Placa de Sensores 0.0550 mA-hr
Total 0.2369 mA-hr
Tabela 2 - Consumo de cada componente do MICAz.
O MICAz possui uma referência interna de voltagem ( voltsVref 223.1= ) que pode ser
utilizada na gestão da voltagem da bateria. O micro controlador ATMega128L monitoriza a
voltagem da bateria através de um conversor analógico digital de 10 bits. O valor de saída
deste permuta de acordo com a mudança verificada na voltagem da bateria. De modo a
traduzir fielmente estes valores, o fabricante disponibiliza uma equação que traduz o valor lido
para unidades internacionais Volt.
SaidaADC
VV
ref
BAT
1024×= (1)
28
3.3. Placa MTS310
Este trabalho foi aplicado sobre o hardware da placa MTS310 desenvolvido pela Crossbow
Tecnology, Inc [14]. Trata-se de uma placa flexível com uma ampla capacidade de captar
fenómenos físicos variados. Tem a capacidade de detectar veículos, sismos de pequena
intensidade, movimento, ruído e outros fenómenos. A esta placa estão associados diversos
sensores, no entanto neste trabalho apenas são utilizados o sensor de temperatura e de
luminosidade, o microfone e o acelerómetro. Está associado igualmente um actuador de som
mais conhecido por Sounder ou Buzzer.
Figura 11 - Placa MTS310.
3.3.1. Sensor de Temperatura e Luminosidade
O sensor de temperatura é composto por uma simples fotocélula CdSe. Com um comprimento
de onda igual a 690 nm, o sensor de luminosidade atinge a sensibilidade máxima [14]. A
resistência da luminosidade varia de 2 kΩ quando exposto à luz e 512 kΩ no escuro. Os
valores podem ser convertidos em graus kelvin pela equação 2. Estes dois sensores partilham
o mesmo conversor analógico digital, não sendo possível realizar leitura simultânea dos dois
sensores.
[ ]3843 )ln(109)ln(1014381.21030705.1)(
1thrthr RR
KT××+××+×=
−−− (2)
SaidaADC
SaidaADCRthr
)1023(10000
−= (3)
29
3.3.2. Microfone
O microfone pode ser usado em dois tipos de aplicação: para gravar a acústica do ambiente ou
como detector de acústica (Tone Detector) [14]. A gravação da acústica ambiental requer que
os dados sejam gravados em memória flash, o que provoca um elevado consumo energético.
O circuito amplifica, em baixo nível, a tensão de saída do microfone. O valor do factor de
amplificação do circuito deve ser definido quando o microfone é inicializado. A saída do
microfone pode alimentar directamente o conversor analógico digital, sendo utilizado
geralmente em modo de gravação. Os dados recolhidos por este método são armazenados na
memória flash para serem posteriormente analisados.
O detector de acústica é alimentado por um filtro activo que se situa entre a saída do microfone
e o Tone Detector. O LM567 CMOS Tone Detector IC é responsável por transformar o sinal
analógico num sinal digital de dois níveis quando um som de 4 kHz está presente no ambiente.
Assim, é capaz de detectar os sons gerados pelo actuador de som.
3.3.3. Actuador de Som
O actuador de som é o único sistema actuador presente na placa de sensores MTS310
utilizada no desenvolvimento deste trabalho. O actuador de som, também denominado por
Sounder ou Buzzer, é um simples dispositivo piezoeléctrico ressonante que gera um som com
frequência de 4 kHz, a mesma frequência do Tone Detector do microfone [14]. A activação do
actuador de som é feita por uma linha de entrada por hardware que tem a capacidade de ligar
e desligar o actuador.
30
3.3.4. Acelerómetro
O acelerómetro presente nesta placa é um MEMS (Micro-Electro-Mechanical Systems) de dois
eixos. De acordo com o seu fabricante, tem uma corrente de consumo baixa (<1 mA) e uma
resolução de 10 bits [14]. Este sensor pode ser usado na detecção de inclinações, movimentos
e vibrações. Os sinais dos eixos são adquiridos por dois conversores analógicos digitais
diferentes (ADC 3 e ADC 4), possibilitando a realização de leituras simultâneas de ambos os
eixos.
Canais X (ADC 3), Y (ADC 4)
G-range ±2 g (1 g = 9.81m/s2 )
Largura de Banda DC-50Hz
Resolução 2 mG(0.002 G) RMS
Sensibilidade 167 mV/G ± 17 %
OffSet 2.5 V ± 0.4 V
Figura 12 - Características do Acelerómetro.
31
3.4. Componente de Rádio Frequência
O sistema operativo TinyOS 2.0 permite o acesso e a definição de algumas características do
componente de rádio frequência CC2420 utilizado neste trabalho, nomeadamente o RSSI
(Received Signal Strength Indication), LQI (Link Quality Indicator), RF Power (Radio Frequency
Transmission Power) e LPL (Low Power Listener). Em função destas características, as
aplicações podem facilmente adaptar-se e retirar o máximo de eficácia de cada nó da rede,
facilitando o incremento do tempo de vida da rede de sensores sem fios.
3.4.1. Received Signal Strength Indication (RSSI)
Actualmente, os modernos receptores de rádio são capazes de receber e amplificar sinais
muito fracos de um emissor distante. A sensibilidade do receptor define-se como o mais fraco
sinal que o receptor consegue receber com uma taxa de erro aceitável. O RSSI elimina a
necessidade da existência de hardware adicional nos pequenos dispositivos sem fios,
melhorando o desempenho aos níveis energético e de custo.
A variável RSSI (Received Signal Strenght Indication) é uma medida de força do sinal de rádio
recebido, referindo-se apenas à energia do sinal e não à qualidade deste. É uma métrica
genérica presente nos receptores de rádio comuns, normalmente invisível ao utilizador do
receptor de rádio, mas bastante relevante para utilizadores de tecnologias de redes sem fios.
Se um emissor distante é deslocado para mais próximo do receptor, a força do sinal transmitido
na antena receptora aumenta. A medição da força do sinal de recepção é um dos métodos de
determinação da qualidade da ligação.
Apesar de os sistemas de localização pela força de sinal, usando o protocolo IEEE 802.15.4
[15], despertarem grande interesse, existe, contudo, uma falta de caracterização dos factores
fundamentais que contribuem para a variação da força do sinal. Há diversos trabalhos que
abordam a caracterização da variação do sinal de rádio [16].
A medida de RSSI, disponibilizada pelo sistema operativo TinyOS 2.0, é um valor de 8 bits que
varia entre 0 e 255. O valor 1 indica a força mínima do sinal detectável pelo receptor, enquanto
o valor 0 indica a inexistência de sinal.
32
3.4.2. Link Quality Indicator (LQI)
O LQI (Link Quality Indicator) é um indicador de força e/ou de qualidade da ligação sem fios
entre os nós vizinhos. O LQI foi introduzido no protocolo de comunicação Zigbee e é fornecido
pelo componente de rádio CC2420, a exemplo do indicador RSSI. O LQI é representado por
um inteiro de 8 bits, podendo os valores variar entre 0 e 255, correspondendo respectivamente
ao valor de qualidade mais baixo e mais elevado que o receptor consegue detectar (entre -100
dBm e 0 dBm).
3.4.3. Radio Frequency Transmission Power (RF Power)
A potência de transmissão do rádio pode ser definida desde -25 dBm até 0 dBm (1 mW). O uso
do rádio em baixa potência é bastante vantajoso, nomeadamente na redução das interferências
e no baixo consumo energético de 17,5 mA para 8,5 mA. Deste modo, para aumentar o tempo
de vida de cada dispositivo, é necessário reduzir a distância entre eles, ou seja, tornar a rede
menos esparsa. A potência do componente de rádio frequência CC2420 é controlada por uma
variável de 8 bits, em que a correspondência entre os valores obtidos na leitura e os valores
em unidades dBm está apresentada na tabela 3.
RF Power
(Valores Obtidos)
RF Power
(dBm)
31 0
27 -1
23 -3
19 -5
15 -7
11 -10
7 -15
3 -25
Tabela 3 - Correspondência entre os valores lidos de RF Power de valores dBm.
33
3.4.4. Low Power Listening (LPL)
Nos protocolos de múltiplos saltos os nós intermédios da rede são responsáveis pela recepção
e propagação das mensagens para o nó destino. Em estado de escuta, o rádio consome quase
tanta energia como na transmissão. Assim, mesmo quando não existe comunicações, os
gastos de energia na procura do próximo pacote são muito elevados.
Actualmente, estão a ser realizados diversos projectos no âmbito do desenvolvimento de
protocolos de alto nível que reduzam a energia consumida pelo nó quando este não está a
transmitir. Uma das soluções existentes é a aplicação de janelas temporais onde são definidos
períodos de comunicação e outros em que o rádio está ocioso.
O sistema operativo TinyOS 2.0 fornece uma interface de controlo assíncrono do período de
funcionamento do componente de rádio CC2420, baseado na gestão dinâmica de energia
(DPM). Neste caso, a recepção não é sincronizada com a transmissão, obrigando o emissor a
enviar repetidamente a mensagem até que a janela de recepção do nó receptor esteja activa.
De referir que, quando o receptor aceita uma mensagem, a janela de recepção é prolongada
ligeiramente de maneira a possibilitar que outra mensagem, que esteja encadeada com a
primeira, seja igualmente recepcionada. Este mecanismo possibilita às aplicações de mais alto
nível o acesso directo ao período em que o componente de rádio está ligado.
A escolha do período de funcionamento é da responsabilidade do programador que desenvolve
a aplicação de alto nível. A escolha do valor depende do tipo de aplicação e dos seus
objectivos, sendo que o desempenho global da rede de sensores depende em grande parte da
escolha deste valor.
Neste trabalho optou-se pelo uso da variável de Duty Cycle para definir o período em que o
rádio deverá estar em modo sleep. A variável Duty Cycle define a percentagem do período
definido pelo TinyOS 2.0 de 5 segundos, em que o componente de rádio deverá estar ligado.
Na equação 4 está apresentado o factor de conversão utilizado pelo TinyOS 2.0 para definir o
período de sleep.
DutyCycle
DutyCycleepPeriodoSle
)10000(5 −⋅= (4)
34
4. Serviços de Monitorização Desenvolvidos
Este trabalho propõe uma camada de serviços aplicada a uma rede de sensores sem fios,
capaz de centralizar os serviços de comunicação e monitorização disponíveis no sistema
operativo TinyOS 2.0. Este trabalho apresenta um conjunto de serviços que actuam como uma
camada de middleware escondendo as particularidades do hardware.
A camada de middleware proposta pretende fornecer uma ampla gama de serviços, na qual a
rede sem fios é a fornecedora e a aplicação é o consumidor. A inexistência de uma camada
deste tipo provoca um elevado grau de dependência entre as aplicações e os diferentes
protocolos, tornando as implementações rígidas. Assim, as aplicações desenvolvidas sem o
auxílio de nenhuma camada de middleware apenas podem ser utilizadas nas redes para que
foram concebidas, isto é, sem auxílio desta camada, a adaptação de uma aplicação numa rede
de sensores para o qual não foi projectada é dificultada, uma vez que redes de sensores
diferentes podem conter características distintas como, por exemplo: processadores, sensores,
actuadores etc.
A camada de serviços apresentada isola as aplicações das características específicas da rede
e dos protocolos. Consente uma configuração dinâmica de rede de acordo com os requisitos
da aplicação, de modo a garantir o uso eficiente dos recursos de comunicação. O middleware
desenvolvido foi construído de forma a corresponder às características de robustez e tolerância
a falhas e aos requisitos mínimos de processamento e armazenamento. Fornece mecanismos
sensoriais de alto nível, comunica as tarefas para a rede, realiza a agregação de dados e
coordena os nós de modo a corresponder de forma eficaz aos pedidos.
Neste capítulo é apresentada a descrição geral do middleware proposto neste trabalho. Em
4.1. são explicados os diferentes serviços presentes na camada de middleware proposta. No
capítulo 4.2. são apresentados os diferentes comandos disponibilizados pela camada de
middleware; em 4.3. e 4.4. estão descritos os protocolos de comunicação utilizados e as
respectivas mensagens usadas. Em seguida, é apresentada uma descrição geral do
middleware que se divide em duas abordagens, uma direccionada para o nó sensor e outra
para o nó saída.
O nó sensor é abordado em 4.5. onde são descritos os componentes mais importantes do
middleware para este nó específico, nomeadamente, a integração dos protocolos de
comunicação e o modo como é realizada a aquisição de dados dos diferentes sensores. Em
4.6. é explicado o modelo do nó saída, abordando os seus protocolos e o modo como estes se
interligam.
35
4.1. Serviços Disponibilizados
Os serviços disponibilizados pela camada de middleware consideram as necessidades típicas
das aplicações, nomeadamente serviços de aquisição, actuação, comunicação e notificação.
Estes serviços são compostos por outros de mais baixo nível que providenciam o acesso aos
componentes de hardware. A junção dos serviços de aquisição, actuação, comunicação e
notificação fornecidos pelo TinyOS 2.0 representam um esforço transversal de economia
energética que resulta numa cooperação e simplificação entre os diferentes serviços
disponibilizados.
A camada de serviços possibilita o acesso a todos os serviços da rede (aquisição, actuação e
comunicação) através de três operadores diferentes: GET, SET e o REPORT. Cada operador
oferece um conjunto de serviços associados a um diferente comando local no mote.
• GET – Fornece o serviço de aquisição de dados, sendo possível definir o período de
aquisição, o numero de dados a adquirir e a escolha do tipo do modo de envios de
dados (envio único ou agregados).
• SET – Possibilita a definição de um valor de actuação ou a definição de uma
determinada variável de estado de algum componente presente no mote.
• REPORT – Permite a definição de notificações ou alarmes, definindo os valores limites
e o operador relacional para os quais a aplicação deverá ser notificada.
ComunicaçãoAquisição Actuação
Rede de Sensores sem Fios
Camada de Serviços
AplicaçãoAplicação
InterfaceSensorDomoBusF
Interface
NodeDomoBusF
Figura 13 - Camada de Serviços
36
A camada de middleware desenvolvida fornece à aplicação as interfaces bidireccionais
SensorDomoBusF e NodeDomoBusF. A interface SensorDomoBusF oferece o acesso aos
serviços de aquisição de dados e actuação através dos comandos (get, set, report)
responsáveis pelo acesso aos serviços, enquanto a interface NodeDomoBusF fornece o
acesso aos serviços de comunicação por intermédio dos comandos send e send_aggr.
Interfaces Comandos Eventos
SensorDomoBusF
• get
• set
• report
• reportCancel
• getDone
• setDone
• reporting
NodeDomoBusF
• send
• send_aggr
• rcv_get
• rcv_set
• rcv_report
Tabela 4 - Comandos e Eventos das interfaces
O serviço de aquisição de dados é disponibilizado pela interface SensorDomoBusF através do
comando get. O serviço de comunicação faculta, através da interface NodeDomoBusF, dois
tipos de envio de dados dos sensores: o envio da resposta a pedido (utilizando o comando
send) e o envio da resposta agregada (utilizando send_aggr da interface NodeDomoBusF).
Os eventos são chamadas de retornos (callbacks) que realizam o sentido ascendente da
informação dos diferentes componentes de hardware, conferindo à interface a característica de
bidireccionalidade. Os eventos notificam as camadas superiores quando um determinado
componente de hardware executa uma interrupção. Neste caso, a aplicação é notificada da
recepção via rádio dos operadores GET, SET e REPORT, através dos eventos rcv_get,
rcv_set, rcv_report, presentes na interface NodeDomoBusF, enquanto no caso dos sensores,
as leituras são remetidas pelos eventos getDone e setDone e as notificações de alarme pelo
reporting através da interface SensorDomoBusF.
No serviço de envio a pedido, a resposta é encaminhada para o nó saída da rede quando o
dado pedido é adquirido, isto faculta rapidez de resposta mas, no entanto, em caso extremo,
pode sobrecarregar a rede de pacotes levando a um grande desgaste dos nós do caminho.
Para evitar este desgaste da rede, foi criado o serviço de agregação de dados, quando a
37
aplicação requer a aquisição periódica de um dado sensor, a mensagem de resposta contém
até um máximo de seis dados adquiridos na mesma mensagem, em vez de conter um só dado.
Vantagens Desvantagens
• Evita a sobrecarga de pacotes a circular
na rede.
• Poupança energética dos principais nós
da rede.
• Aumento do tempo de vida da rede.
• Diminuição de envio de informação
redundante. Por exemplo: informação do
par (nó, sensor), cabeçalhos dos pacotes
etc.
• Maior tempo de resposta aos pedidos da
aplicação.
• Aumento do impacto da perda de
mensagens.
• Aumento do tamanho individual de cada
mensagem.
Tabela 5 - Vantagens e desvantagens do serviço de agregação de dados
Na tabela 5 estão apresentadas as diferentes vantagens e desvantagens do uso do serviço de
envio de dados agregados. A opção da utilização do uso deste serviço é da responsabilidade
da aplicação, pois a camada de middleware fornece serviços genéricos não podendo ser esta
camada a decidir o melhor serviço para cada aplicação específica.
O programador da aplicação deve ter em conta o impacto de cada factor positivo e negativo de
modo a decidir qual o serviço que melhor se encaixa às suas exigências. O uso do serviço de
agregação é aconselhado em cenários de recolha estatística em que o tempo de vida útil do
sistema é fundamental, por exemplo, na recolha estatística das condições ambientais
(temperatura, humidade etc.) de uma floresta de difícil acesso.
Esta camada de serviços fornece ainda serviços de acesso a variáveis de estado de diversos
componentes dos motes. Nomeadamente, as variáveis que contêm a informação da voltagem
da bateria e do rádio (RSSI, LQI, RF Power e Radio Duty Cycle). O acesso a estas variáveis é
feito, tal como na aquisição de dados dos sensores, pelo operador GET. Deste modo o acesso
é realizado colocando no parâmetro de entrada do operador GET o par de endereços
nó/característica. Uma vez que localmente as características de cada nó são tratadas de
maneira semelhante aos dados adquiridos pelos sensores, estas terão um endereço local à
semelhança dos sensores.
O acesso às diferentes características do nó são muito úteis para a gestão transversal de
energia uma vez que possibilita às camadas de software de nível superior o acesso a
38
característica de baixo nível, como é o exemplo do RF Power, que representa a potência de
transmissão do rádio.
O operador REPORT disponibilizado pela interface SensorDomoBusF implementa um serviço
de notificação semelhante a um alarme, realizando aquisições consecutivas de 200
milissegundos até ser atingido o tempo de cessação pré-definido. Este serviço notifica a
aplicação, por intermédio do evento reporting, a ocorrência de um determinado acontecimento
previamente definido através dos parâmetros do comando report da interface
SensorDomoBusF. Este comando fornece a capacidade de definir a notificação por tempo
limitado ou ilimitado conforme os interesses da aplicação, sendo assim é possível cancelar a
notificação pré definida em qualquer altura usando para tal o comando reportCancel. O envio
da notificação para o nó saída da rede é feito pelo comando send.
O serviço de actuação disponibilizado pela camada de middleware proposta efectua a definição
de uma variável, sobre a qual o actuador deverá actuar de modo a respeitá-la. Por exemplo, a
definição de um valor de temperatura. Devido à limitação física e computacional dos motes
disponíveis no mercado, não é possível efectuar, por intermédio destes, o controlo de
actuadores complexos como, por exemplo, o controlo do ar condicionado.
O nó saída tem a responsabilidade de informar a rede, por intermédio do protocolo de colecção
de dados, de que se trata de um nó desse tipo, assim este nó pode ter qualquer endereço de
rede. Todos os serviços disponíveis desta camada de middleware assumem a existência de um
único nó saída.
39
4.2. Operadores Básicos
A camada de middleware concebida visa obter o máximo de independência possível em
relação ao hardware. Assim, os operadores adquirem um papel fundamental na estrutura do
middleware, pois são eles os responsáveis pela normalização dos serviços disponibilizados.
Neste contexto, o trabalho desenvolvido centrou-se na busca da melhor representação de
todos os serviços de rede. Foi desenvolvida uma camada de serviços que apenas fornece à
aplicação três tipos de operadores diferentes para o acesso aos sensores. Os operadores
fornecidos pela camada de middleware desenvolvida são: GET, SET e REPORT. Estes foram
projectados de modo a abstrair as características específicas de cada nó e sensor.
Cada sensor da rede é alcançado pelo endereço de rede do nó e pelo endereço local do
sensor. Este par de endereços torna qualquer sensor presente na rede alcançável à aplicação.
Cada par nó/sensor é identificado univocamente, pois na rede não existe dois nós com o
mesmo endereço e num nó não existe dois sensores com o mesmo endereço local. Os
operadores são independentes do tipo de sensor, no entanto, existem sensores que não
disponibilizam certos operadores devido às suas características específicas.
Quando a aplicação requisita a aquisição de informação de um determinado sensor, essa
intenção é enviada para a rede utilizando o nó saída, ligado ao computador através da porta
série. O pedido vai progredindo na rede até encontrar o nó destino. Este nó encaminha o
pedido para o respectivo sensor através do seu endereço local. Após a aquisição dos dados,
estes são enviados finalmente para o nó saída.
GET SET REPORT
Luminosidade Período de Aquisição Número de Amostras Flag de Agregação
Duração
Operador comparativo Valor comparativo
Temperatura Período de Aquisição Número de Amostras Flag de Agregação
Duração
Operador comparativo Valor comparativo
Microfone Período de Aquisição Número de Amostras Flag de Agregação
Ganho Duração
Operador comparativo Valor comparativo
Acelerómetro Período de Aquisição Número de Amostras Flag de Agregação
Duração
Operador comparativo Valor comparativo
Sounder Período de funcionamento
Tabela 6 - Parâmetros de entrada dos operadores da camada de middleware.
40
4.2.1. Operador GET
O operador GET é reservado à aquisição de dados de um determinado sensor/nó. Este
operador é específico para aplicações de monitorização e aquisição de dados. Tem como
parâmetros, além do par de endereços, todos os eventuais pedidos de aquisição que a
aplicação pode requisitar, tais como, o período de aquisição e o número de dados que se
pretende adquirir.
Os dados de resposta a este operador são enviados assim que estes tenham sido adquiridos
correctamente. Os nós sensores têm responsabilidade de realizar o envio dos dados recolhidos
para o nó saída. Os factores energéticos e de largura de banda influenciaram a escolha dos
tipos de parâmetros de entrada escolhidos para este operador.
Os dados adquiridos podem ser enviados em agregação, dependendo da aplicação. A escolha
é enviada ao nó sensor através de uma flag passada como parâmetro do operador. Este modo
de envio específico é bastante útil para aplicações de monitorização que não exijam uma
resposta imediata dos dados adquiridos. Por exemplo, em aplicações agrícolas em que a
monitorização é feita ao longo de vários dias, não sendo necessário que cada dado recolhido
seja imediatamente enviado à aplicação. A agregação de dados potencia a poupança
energética da rede, diminuindo enormemente os pacotes a circular na mesma.
O operador GET pode ser usado no acesso a dados de funcionamento de um actuador. No
entanto, é natural que em determinados actuadores, esta utilização seja dispensada, a
exemplo do actuador de som presente na placa MTS310.
4.2.2. Operador SET
O operador SET é utilizado para definir um ou mais parâmetros específicos de um determinado
sensor de rede. Pode ser utilizado, por exemplo, na inicialização de um ganho de algum
sensor, ou actuar directamente sobre um actuador.
Os parâmetros de entrada do operador SET são o par de endereços que identificam o
nó/sensor e o valor que se pretende inicializar ou actuar. No caso particular deste trabalho, o
operador SET é utilizado para definir o ganho do microfone e para activar um sinal sonoro no
actuador de som da placa de sensores MTS310.
41
4.2.3. Operador REPORT
O operador REPORT possibilita à aplicação receber notificações quando um determinado
sensor confirma uma comparação pré-definida. Esta função é bastante útil em ambientes em
que é necessária uma rápida reacção à ocorrência de algum fenómeno, por exemplo, em
aplicações ligadas à segurança de edifícios, entre outras.
Além do par de endereços que identifica o sensor na rede, o operador tem como parâmetros de
entrada o período de varrimento do sensor, o período de funcionamento do REPORT, o valor a
ser comparado e o operando relacional. Quando o sensor reporta uma dada ocorrência pré
definida, o nó sensor envia esse alarme para o nó saída e consequentemente para a aplicação.
Os operandos relacionais utilizados neste operador são o “maior ou igual” (≥) e “menor ou
igual” (≤). Deste modo, possibilita à aplicação a recepção de uma vasta gama de notificações.
De salientar que à semelhança dos outros operadores, os parâmetros de entrada são iguais
para todos os sensores.
42
4.3. Protocolos de Comunicação
A comunicação é um aspecto fundamental para o correcto funcionamento de uma rede de
sensores sem fios. Os protocolos mais comuns são os de disseminação (paradigma “um para
todos”) e o de colecção (paradigma “todos para um”). A comunicação ponto a ponto
(paradigma “um para um”) é predominante em sistema de redes em que é utilizado na grande
maioria dos sistemas de internet, no entanto, nas redes de sensores esta comunicação é muito
pouco utilizada, exceptuando algumas aplicações de controlo que são muito funcionais e pouco
documentais.
Neste trabalho são utilizados dois protocolos de comunicação: a disseminação e colecção de
dados. Estes protocolos já fazem parte do sistema operativo TinyOS 2.0 e não necessitam de
qualquer alteração para serem englobados neste projecto. Depois de diferentes testes,
concluiu-se que estes protocolos apresentavam a fiabilidade necessária às exigências da
camada de middleware desenvolvido.
No contexto deste projecto, o protocolo de disseminação de dados é responsável por remeter
os pedidos da aplicação a todos os nós sensores, enquanto o protocolo colecção de dados
realiza a entrega dos dados adquiridos pelos diferentes nós sensores. Os serviços de
comunicação e aquisição de dados são acedidos por interfaces diferentes permitindo a
integração de outros protocolos de comunicação.
A gestão dinâmica de energia do componente de rádio CC2420 (Low Power Listening) ainda
não foi integrada formalmente nos protocolos de colecção e de disseminação fornecidos pelo
TinyOS 2.0. Assim, quando os componentes de rádio dos nós estão desligados muito tempo, é
normal que cause atrasos na propagação dos dados pela rede, podendo mesmo em casos
extremos perder-se os pacotes de comunicação.
43
4.3.1. Disseminação de Dados
O protocolo de disseminação de dados [17] é um protocolo básico de rede de sensores sem
fios, que permite à aplicação reconfigurar, pedir, questionar e reprogramar todos os nós da
rede. A disseminação fornece uma entrega fiável de dados, tornando a operação robusta a
desconexões temporárias ou perdas de pacotes típicas de uma rede deste tipo. Ao contrário
dos protocolos de inundação, a disseminação fornece fiabilidade na entrega de dados usando
uma aproximação contínua que pode detectar a falta de dados num determinado nó.
O protocolo de disseminação de dados é composto por uma parte de controlo (Control Traffic)
e outra de dados (Data Traffic). O tráfego de controlo tem de se manter ao longo do tempo de
vida da rede, ao contrário do tráfego de dados que pode ser separado devido à sua dimensão.
Este protocolo é bastante útil em redes de sensores, dado que possibilita ao administrador
injectar na rede pequenos programas, comandos ou configurações.
Devido à limitação da memória RAM nos dispositivos de rede, os dados do protocolo de
disseminação são descritos como “versões”. O protocolo de disseminação só propaga a
“versão” mais recente, isto permite que, quando um novo nó entra na rede, receba de imediato
a “versão” mais actualizada da mesma.
O protocolo de disseminação disponibilizado pelo TinyOS 2.0 e utilizado neste trabalho baseia-
-se em redes de Trickles [18]. O seu funcionamento é descrito pelos seguintes passos:
• Cada nó periodicamente envia dados em broadcast descrevendo a “versão” do código
que possui.
• O nó não executa qualquer acção se escutar uma “versão” idêntica à sua.
• O nó actualiza a “versão” da rede quando escuta uma “versão” mais antiga que aquela
que possui.
• O nó actualiza a sua “versão” se escutar uma versão mais recente a circular na rede.
No entanto, é necessário ter em atenção algumas limitações deste protocolo, uma vez que não
é possível a um nó desactualizado enviar uma nova actualização da “versão”. Para além do
facto anteriormente referido, quando dois nós realizam a actualização da “versão” em
simultâneo com valores diferentes, apenas um deles é correctamente difundido. Assim, é
necessário coordenar as actualizações de todos os nós da rede.
44
4.3.2. Colecção de Dados
A colecção de dados [19] é um processo de envio de dados de múltiplas fontes para um nó
saída, podendo ser denominado por covergecast. Muitas aplicações de aquisição de dados e
de detecção de eventos utilizam este protocolo para transferir os dados para fora da rede. Os
protocolos de colecção existentes diferem entre si através dos seguintes aspectos:
• Cálculo da qualidade da ligação.
• A escolha do próximo salto.
• O algoritmo em árvore, utilizado.
• A maneira de lidar com os ciclos infinitos (loops) e com a perda de ligações.
• A abstracção à comunicação que fornecem (datagram ou stream).
Existe uma grande diversidade de protocolos de colecção de dados divididos pelas
características apresentadas anteriormente. O protocolo MintRoute fornece um serviço de
datagram de melhor esforço (best-effort). Este protocolo serve de base para o protocolo
Collection Tree Protocol (CTP) [20] disponibilizado pelo TinyOS 2.0 e utilizado neste trabalho.
O protocolo MultiHopLQI é semelhante ao protocolo anterior mas utiliza um estimador de
qualidade da ligação e uma estratégia de gestão da tabela dos nós vizinhos mais simples que o
MintRoute.
O protocolo de colecção de dados baseia-se em árvores, sendo que os nós requerentes são os
nós saída e as folhas os nós sensores. Em particular, neste trabalho foi usado apenas um nó
saída. A colecção de dados de um nó de base é um requisito comum em redes de sensores
sem fios. A abordagem mais geral de uma rede de sensores sem fios é constituída por uma ou
mais árvores ligadas ao mesmo nó saída.
O protocolo colecção é responsável, em cada nó sensor, por enviar e retransmitir informação
dos diferentes sensores, de modo a reunir todos estes dados de rede num nó saída. Os nós
sensores estão, assim, encarregues de enviar os dados disponíveis para a árvore, de modo a
chegar até ao nó saída. Da mesma forma quando recebe dados originários de outros nós,
encaminha-os na direcção do nó saída. A rede de sensores sem fios pode ser composta por
vários nós de base comportando-se como múltiplas árvores, uma “floresta”. A entrega dos
pacotes de comunicação é realizada em múltiplos saltos a qualquer nó saída da árvore, trata-
se então de um protocolo anycast.
O protocolo colecção oferecido pelo TinyOS 2.0 e utilizado neste trabalho foi o CTP (Collection
Tree Protocol). Trata-se de um protocolo de endereço livre, isto significa que um nó não envia
um pacote para um nó saída em particular, em vez disso escolhe implicitamente o nó saída a
partir da selecção do próximo salto. Os nós geram rotas para a raiz usando um gradiente de
rotas (routing gradient). Assim, este protocolo usa um campo em cada nó ETX (Expected
45
Transmission) como gradiente da rota, sendo que a raiz tem o valor de zero. Assim, a escolha
do próximo salto é feita por cada nó, tendo por base a ligação com menor valor de ETX.
Não obstante, este protocolo também apresenta limitações, uma vez que não existem garantias
de entrega dos dados de uma forma ordenada ao nó saída, ou podendo mesmo não chegar.
Para além destes aspectos, os ciclos infinitos (loops) e os pacotes duplicados também se
podem constituir como um problema. Os ciclos infinitos acontecem quando o pacote de dados
possui um gradiente menor que o do nó receptor. A duplicação de pacotes ocorre quando um
ACK de confirmação de entrega, enviado pelo nó receptor não chega em tempo útil ao nó
emissor, assim, o mesmo pacote é reenviado, podendo conduzir a um crescimento exponencial
de duplicação. Esta situação pode ocorrer numa rede de sensores sem fios muito esparsa em
que as falhas de comunicação são uma constante.
A implementação do CTP é dividida em três partes:
• Estimador da qualidade da ligação – Responsável por estimar, num único salto, o ETX
da comunicação para os nós vizinhos à distância de um salto.
• Gerador de caminhos – Usa o estimador de ligação e a informação ao nível da rede
para decidir o próximo salto para um dos nós vizinhos.
• Gerador de encaminhamento - Responsável principalmente por encaminhar o tráfego
de dados e integrar os dados do nó na rede. Mantém a fila de pacotes a serem
enviados, decide quando e como os deverá enviar.
O estimador de qualidade da ligação utiliza dois mecanismos de cálculo distintos; o protocolo
LEEP (Link Estimation Exchange Protocol) [21] e os pacotes de dados. O protocolo LEEP é
usado pelos nós para estimar e trocar a informação sobre a qualidade de ligação para os nós
vizinhos.
Este estimador envia a todos os nós vizinhos pacotes LEEP, estes são usados para actualizar
a tabela de nós vizinhos através dos valores bidireccionais de ETX. A frequência de envio
destes pacotes LEEP é adaptada ao dinamismo da rede por um algoritmo semelhante ao
trickle [18] usado no protocolo de disseminação.
O gerador de caminhos é responsável pela escolha do próximo salto para a transmissão dos
dados. Este mantém a informação dos diversos valores de ETX do subconjunto dos nós
mantidos pela tabela de estimação da qualidade da ligação. Assim, o ETX do caminho é a
soma dos ETX das ligações ao longo de todo o caminho.
46
O gerador de encaminhamento assume as seguintes responsabilidades:
• Transmissão dos pacotes para o próximo salto retransmitindo-os, caso seja necessário,
e passar a informação do estimador da ligação.
• Decidir quando deverá efectuar a transmissão do próximo salto.
• Detectar inconsistências e informar o gerador de caminhos.
• Manter a fila de pacotes a transmitir, a qual pode ser composta por pacotes gerados
localmente ou pacotes encaminhados.
• Detectar duplicação de transmissões de um único salto causado pela perda de
acknowledgments (ack).
47
4.4. Estrutura das Mensagens
As estruturas das mensagens de dados desenvolvidas para este trabalho foram criadas de
modo a corresponder às necessidades típicas dos serviços de uma rede de sensores sem fios.
Neste trabalho optou-se por desenvolver três estruturas de dados de comunicação diferentes,
duas para comunicação dos dados recolhidos pelos sensores e outra para a submissão de
interesses da aplicação.
Os dados recolhidos pelos nós sensores podem ser comunicados para o nó saída, agrupando
vários dados na mesma mensagem, ou, simplesmente, colocando em cada mensagem um
único dado adquirido. Assim, cada tipo de comunicação é composto por distintas estruturas de
dados.
A opção de fornecer dois tipos de mensagens de envio de dados surge em resposta da
necessidade de implementação de um mecanismo que facultasse uma poupança energética e,
ao mesmo tempo, libertasse a rede de excesso de mensagens. Com a criação deste novo
serviço de agregação de dados, os programadores da aplicação podem escolher qual é o
serviço de comunicação de dados que melhor se adapta às características de cada aplicação.
4.4.1. Envio de Pedidos
A estrutura de dados de comunicação de 96 bits destinada ao envio de pedidos é composta por
quatro campos de identificação:
• O Source indica ao nó destino o endereço do nó que enviou o pedido;
• O campo Node ID identifica o nó da rede.
• O campo Sensor ID identifica o sensor a que o pedido se refere;
• O campo Operator informa o nó destino da actividade pretendida.
Figura 14 - Estrutura da mensagem de envio de pedidos.
48
A estrutura de mensagem representada na figura 14 foi desenvolvida de modo a ser capaz de
responder às necessidades de todos os operadores disponibilizados pelo middleware. No
entanto, o factor limitativo de energia e sobrecarga da rede levou a que o tamanho da
mensagem fosse o mais reduzido possível. Assim, foram englobados os campos Prop 1 e Prop
2, com significados diferentes para cada operador.
Desta forma, o campo Period corresponde ao período de aquisição de 32 bits, uma vez que
este valor dirige-se ao temporizador do sistema operativo; e os campos Prop 1 e Prop 2
correspondem a diferentes características de actividade, tendo, no entanto, a mesma dimensão
de 16 bits.
GET SET REPORT
Prop 1 Número de Dados Requisitados Valor da Definição Valor Limite de Sinalização
Prop 2 Flag de Agregação Operando Relacional
Tabela 7 - Parâmetros dos campos dinâmicos Prop 1 e Prop 2.
Conforme ilustra a tabela 7, o campo Prop 1 é utilizado pelos três operadores. Para os
operadores SET e REPORT, este campo adquire, respectivamente, o valor da definição e o
valor a partir do qual o nó sinaliza o evento para a aplicação. No operador GET o campo Prop 1
representa o número de dados a adquirir pelo sensor. O campo Prop 2 é usado pelo operador
REPORT para informar o nó sensor do tipo de operando que este deverá usar na sinalização
da aplicação. No operando GET, o campo Prop 2 da mensagem é utilizado para comunicar ao
nó se este deve enviar os dados agregados para o nó saída.
4.4.2. Envio de Dados Simples
A comunicação de cada dado individual recolhido pelos sensores é feita pelos nós,
preenchendo uma estrutura de dados que contém os campos BaseStation, Operator, Node ID,
Sensor ID e Value. A estrutura de envio de dados individuais tem a dimensão de 48 bits, destes
apenas 16 bits são destinados ao valor recolhido pelo sensor.
49
Figura 15 - Estrutura da mensagem de envio de dados simples.
O campo BaseStation de 8 bits é reservado para o endereço do nó saída que requereu estes
dados, o campo Operator indica o modo de funcionamento em que estes dados foram
recolhidos. O par de endereços (Node ID e Sensor ID) faculta a identificação unívoca na rede
do sensor que efectuou as leituras. O campo Value está reservado para o dado adquirido pelo
sensor. É este o campo que contém a informação relevante para a aplicação. Nesta estrutura
foi reservado um campo de 16 bits para o valor recolhido pelo sensor, porque todos os
sensores da placa MTS310 devolvem dados de 16 bits.
4.4.3. Envio de Dados Agregados
A estrutura de dados utilizada para o envio de dados agregados é composta pelo par de
identificação do sensor da rede (Node ID e Sensor ID), o modo de aquisição e o endereço do
nó saída. Esta estrutura tem a capacidade de agrupar, na mesma mensagem, até seis dados
recolhidos pelo mesmo sensor.
Figura 16 - Estrutura da mensagem de envio de dados agregados.
O tamanho total desta estrutura de dados é 128 bits. No entanto, para enviar a mesma
informação pelo envio simples (sem agregação), são necessários ao todo 576 bits. Assim, a
agregação de dados é ideal para aplicações que não necessitem que os dados sejam
imediatamente interpretados, por exemplo, para aplicações de recolha estatística.
50
4.5. Camada de Serviços do Nó Sensor
A aplicação do nó sensor é responsável pela união de todos os serviços de comunicação e de
aquisição disponíveis na rede. As interfaces NodeDomoBusF e SensorDomoBusF fornecem
respectivamente os serviços de comunicação e aquisição de dados. A aplicação efectua a
ponte entre os pedidos que chegam através da interface NodeDomoBusF e os dados
recolhidos pelos sensores que chegam pela interface SensorDomoBusF.
APLICAÇÃO
PLACA DE SENSORES (MTS300DOMOBUSC)
MÓDULO DE COMUNICAÇÃO
(NODEDOMOBUSC)
SensorDomoBusFNodeDomoBusF
SENSORES
GET
SET
REPORT
PROTOCOLOS DE COMUNICAÇÃO
SEND
RECEIVE
CARACTERÍSTICAS DE RÁDIO CC2420
ACTUADORES
GET
SET
GET
SET
Middleware
Figura 17 - Esquema descritivo dos serviços do nó sensor.
O componente mts300DomoBusC é responsável pela unificação de todos os serviços
disponíveis na placa de sensores MTS310. No entanto, o middleware desenvolvido neste
trabalho possibilita o uso de outras placas de sensores, sendo que, para cada placa, é
necessário desenvolver um componente específico capaz de efectuar a tradução entre os
serviços disponibilizados e os operadores fornecidos pelo middleware. Toda a comunicação do
nó é gerida pelo módulo de comunicação NodeDomoBusC, o qual é responsável pela gestão
dos protocolos de comunicação de uma forma eficaz e pelo acesso às diferentes
características do rádio CC2420.
As interfaces NodeDomoBusF e SensorDomoBusF desempenham um papel fundamental na
integração dos serviços fornecidos pela rede de sensores sem fios e a aplicação. São estas
que assumem a total responsabilidade do acesso aos diferentes serviços. A interface
NodeDomoBusF fornece todas as notificações de recepção de operadores e envio das
respostas. A interface SensorDomoBusF é responsável por fornecer os diferentes pedidos de
aquisição e actuação. Por exemplo, quando um operador é recepcionado pelo rádio, o módulo
NodeDomoBusC notifica através da interface NodeDomoBusF a aplicação. Esse pedido é
51
satisfeito pela aplicação, acedendo através da interface SensorDomoBusF ao serviço
correspondente. A resposta é encaminhada em sentido contrário à chamada até ao
componente de comunicação que utiliza a interface Send para enviar os dados através de um
protocolo da comunicação.
A ponte entre o acesso aos sensores e a aquisição de dados é da responsabilidade da
aplicação, isto permite um maior controlo de todos os pedidos recebidos e enviados, bem como
uma maior flexibilidade. Esta ponte não pode ser feita pelo middleware pois iria limitar em
grande parte o sistema, uma vez que podia existir aplicações que pretendessem aceder e tratar
os dados antes de os enviar. Deste modo, a camada de middleware proposta fornece uma total
responsabilidade às aplicações sobre o modo de resposta aos pedidos recebidos.
4.5.1. Serviços de Aquisição e Actuação
Uma rede de sensores sem fios baseia-se na recolha de dados dos diferentes nós sensores da
rede, sendo o acesso a esses dados de capital importância para a concretização do objectivo
final da aplicação.
A camada de serviços foi desenvolvida para englobar o acesso a todos os sensores/actuadores
da placa MTS310. Os operadores fornecidos pela rede (GET, SET e REPORT) são suportados
pelo sistema através da camada de middleware, que realiza a tradução dos operadores de
rede em comandos locais específicos para cada tipo de sensor.
APLICAÇÃO
SOUNDERMICROFONE
Get Set Report
Sensores Actuador
Get Report
ACELERÓMETRO
Get Set Report Get Report Get Set
mts300DomoBusP
Placa MTS310
SENSOR DE TEMPERATURA E LUMINOSIDADE
Figura 18 - Esquema descritivo do acesso os componentes da placa MTS310.
O controlador mts300DomoBusP tem a função de mediar os pedidos da rede para os
componentes dos sensores. Este fornece os comandos e eventos dos diferentes sensores
52
presentes na placa MTS310. Cada configuração dos sensores fornece diferentes interfaces
baseadas nos operadores de rede GET, SET e REPORT.
Uma vez que os sensores de temperatura e luminosidade partilham o mesmo conversor
analógico digital, limitando deste modo o acesso aos dados de cada um, optou-se por unificar o
tratamento dos pedidos aos sensores de temperatura e luminosidade, de modo a simplificar e a
tornar o acesso aos dados mais eficaz. O acelerómetro é composto por dois eixos, cada um
fornece o par de operadores GET e REPORT. O microfone fornece os três operadores pois,
além de fornecer os serviços de GET e REPORT, necessita da inicialização do ganho do
amplificador.
O actuador de som, ou simplesmente Sounder, fornece apenas o operador SET. Com o auxílio
de um temporizador do sistema, realiza a função de ligar/desligar o som, de modo a fornecer
um efeito sonoro do tipo sirene. Para o efeito sonoro está predefinido um factor de 0.5 e com
um período definido pelo operador SET. Quando a aplicação pretende desligar o Sounder,
basta colocar o valor nulo no campo data do operador GET.
Figura 19 - Componente de configuração mts300DomoBusC
O componente de configuração mts300DomoBusC define as interfaces de ligação aos
componentes que realizam a ligação aos sensores. Ao componente PhotoTempDomoBusC
estão ligadas duas interfaces getF de modo a aceder ao sensor de temperatura e
luminosidade. O componente AccDomoBusC também fornece quatro interfaces (duas getF e
reportF) devido ao facto do acelerómetro possuir dois eixos. O componente de
MicroDomoBusC é o único que fornece três interfaces distintas de acesso ao microfone, uma
vez que necessita de um valor de inicialização para o ganho (realizado através da interface
setF). Na tabela 8 estão descritos as funções de cada componente na camada de serviços
desenvolvida.
O microfone, por intermédio do módulo MicroDomoBusC, proporciona dois tipos de serviços; a
simples aquisição dos dados acústicos do ambiente, e o detector de som ou Tone Detector. A
53
aquisição de dados é feita por intermédio da interface getF, enquanto o serviço de notificação é
realizado pelo Tone Detector através do comando reportF. O Tone Detector notifica as
camadas superiores quando detecta um som de 4 kHz no ambiente, logo para este caso
particular, não é necessário definir as condições para as quais o serviço REPORT deverá
notificar a aplicação. O setF é responsável pela inicialização. É esta interface que define o valor
do ganho do amplificador do microfone. De realçar que esta inicialização demora
aproximadamente 1,2 segundos até que o microfone esteja pronto a adquirir informação.
As interfaces Mts300Sounder e Read (ver figura 18) são duas interfaces fornecidas pelo
sistema operativo TinyOS 2.0, estas têm a tarefa de efectuar o acesso ao actuador de som
(Sounder) e a voltagem da bateria (Voltage). De referir que os módulos Sounder e Voltage são
igualmente fornecidos pelo TinyOS 2.0, não sofrendo nenhuma intervenção neste trabalho.
Componente Descrição
mts300DomoBusC Providencia o acesso a todos os sensores da placa MTS310.
mts300DomoBusP Realiza a tradução dos todos os pedidos de acesso aos dados dos
sensores/actuadores da placa MTS310.
PhotoTempDomoBusC Efectua as necessárias ligações aos sensores de luminosidade e
temperatura.
PhotoTempDomoBusP Módulo de acesso aos diversos pedidos de luminosidade e temperatura.
reportPhotoTempC Providencia o acesso às ligações aos sensores de luminosidade e
temperatura para o operador REPORT
reportPhotoTempP Realiza a função REPORT nos sensores de luminosidade e temperatura
efectuando a tradução dos pedidos para a camada inferior
MicroDomoBusC Efectua as ligações de acesso às funcionalidades do microfone.
MicroDomoBusP Efectua a tradução dos pedidos ao microfone.
AccDomoBusC Efectua as ligações ao acelerómetro.
AccDomoBusP Efectua a tradução dos pedidos ao acelerómetro.
Tabela 8 - Descrição dos componentes utilizados
Na tabela 9 estão apresentados os comandos e eventos das interfaces utilizadas nos serviços
de aquisição e actuação da camada de middleware desenvolvida. Assim, as interfaces getF,
setF e report fornecem os comandos (get, set e report) e os respectivos eventos (getDone,
setDone e reporting).
54
Interfaces Comandos Eventos
getF • get • getDone
setF • set • setDone
reportF • report
• reportCancel
• reporting
Tabela 9 - Comandos e eventos das interfaces getF, setF e reportF
A interface getF fornece o serviço de aquisição de dados, esse serviço é acedido ao chamar o
operador GET, a resposta do hardware é consumada pelo evento getDone. A interface reportF
fornece ainda o comando reportCancel, este possibilita o cancelamento de uma determinada
notificação pré definida.
Os restantes serviços de actuação e de notificação de uma ocorrência pré definida são
realizados pelas interfaces setF e reportF, com os seus respectivos comandos e eventos
apresentados na tabela 9.
4.5.2. Serviços de Comunicação
A gestão e coordenação dos protocolos de comunicação usados neste trabalho são feitas pelo
controlador de comunicação NodeDomoBusP, representado na figura 20. O protocolo de
disseminação é responsável pela recepção dos pedidos no nó sensor através da interface
DisseminationValue. Em contrapartida, o protocolo de colecção utiliza a interface Send para
enviar os dados para o nó saída.
PROTOCOLO DE DISSEMINAÇÃO
PROTOCOLO DE COLECÇÃO
SERVIÇO DE COMUNICAÇÃO
Controlador de Comunicação(NodeDomoBusP)
SendReceive
DisseminationValue Send
REDE DE SENSORES SEM FIO
Figura 20 - Esquema de acesso aos protocolos de comunicação.
55
4.6. Serviços do Nó Saída
O nó saída, apesar de desempenhar um papel neutro neste sistema, desempenha um papel
fundamental para o funcionamento de uma rede de sensores sem fios. Este papel no entanto
pode ser desempenhado por outros dispositivos electrónicos (por exemplo, PDA) sendo
necessário que consigam comunicar correctamente com os protocolos de rede.
O nó saída realiza a ligação entre os serviços de rede e o exterior. Assim, neste nó é
implementado um esquema de encaminhamento de dados em ambos os sentidos; do exterior
para a rede e da rede para o exterior. O nó saída está ligado ao exterior através de uma
ligação por porta série, através do respectivo protocolo. A ligação entre o nó saída e a rede é
feita pelo rádio frequência CC2420, através do protocolo de disseminação.
PROTOCOLO DE DISSEMINAÇÃO
PROTOCOLO DE COLECÇÃO
PROTOCOLO PORTA SERIE
Controlador de comunicação(DomoBusRootC)
REDE DE SENSORES SEM FIOS
ReceiveDisseminationUpdate
Receive Send
NÓ RAIZ
Porta Série
Aplicação
Figura 21 - Esquema descritivo das ligações do nó saída.
De acordo com a figura 21, quando o exterior pretende utilizar um serviço da rede, este envia
os pedidos através da porta série para o nó saída; em seguida, são enviados para a rede
através do controlador de comunicação DomoBusRootC, utilizando o protocolo de
disseminação de dados, através da interface DisseminationUpdate. Esta interface permite
actualizar a “versão” de rede que contém os diversos pedidos.
56
O protocolo de colecção de dados é responsável pela reunião de todos os dados enviados
pelos nós sensores da rede. No módulo DomoBusRootC, quando o nó é inicializado, é definido
que este é o nó saída do protocolo de colecção de dados, fazendo que sejam encaminhados
para este nó todos os dados recolhidos e enviados através deste protocolo. Assim, este tipo de
nós apenas realiza a recepção através do protocolo de colecção de dados.
57
5. Programa de Demonstração
Com o objectivo de demonstrar o funcionamento da camada de serviços desenvolvido neste
trabalho, foi construído um programa, em linguagem de programação java, que possibilita a
interacção e visualização do estado da rede de sensores sem fios em qualquer altura.
Este programa dá ao utilizador uma flexível interacção com todos os operadores básicos e
respectivos parâmetros da camada de serviços (GET, SET e REPORT). É composto por uma
janela que permite definir os operadores, os respectivos parâmetros e a visualização do estado
da rede. Deste modo, a janela é dividida por dois grandes painéis; um painel onde é possível
definir os pedidos e outro destinado à visualização das respostas da rede de sensores sem
fios.
Figura 22 - Janela do programa de demonstração.
Cada painel apresentado nesta janela define um parâmetro diferente do pedido à rede. Os
operadores são definidos no painel Operator e o par nó/sensor, responsável pela identificação
unívoca do sensor na rede, é definido, respectivamente, em Node e Sensor. Na tabela 10 estão
apresentados todos os painéis e as respectivas descrições.
58
Painéis da janela Descrição
Sensor
• Neste painel é definido o sensor/actuador presentes na placa
MTS310.
Node Settings
• Este painel permite definir e consultar as características do rádio
CC2420 (Rssi, Lqi, RF Power e Rádio Duty Cycle).
• Permite consultar a voltagem da bateria (Voltage) e os nós estão
ligados à rede (Nodes Connected).
Operator
• Escolha dos três operadores básicos dos serviços do middleware
desenvolvido (SET, GET, REPORT).
Report Settings
• Este painel define o operando relacional do operador REPORT.
• Neste trabalho são oferecidos apenas dois: “o maior ou igual”
(Upper) e “o menor ou igual” (Lower).
Get Settings
• A agregação de dados apenas está disponível no operador GET
através da selecção do campo Aggregation presente na janela
do programa.
Interval
• No operador GET define o período de aquisição.
• No operador REPORT define o tempo de actividade das
notificações.
Num
Samples(GET)/Value(SET)
• No operador GET define o número de dados a adquirir pelo
sensor.
• No operador SET define o valor da actuação.
• No operador REPORT define o valor de comparação.
Node
• Neste painel é definido o nó a que se destina o pedido.
• Ao seleccionar o All Nodes o operador definido é enviado a todos
os nós da rede.
Tabela 10 - Descrição dos painéis da janela do programa de demonstração
Na tabela 10 é sintetizada a aplicação de todos os painéis da janela. Existem alguns que só
são utilizados em determinados operadores. Nomeadamente, no operador SET não é utilizado
o Interval uma vez que este serviço não realiza a aquisição de dados; enquanto no caso do
operador REPORT, o campo Num Samples(GET)/Value(SET) é ignorado. As características de
rádio são interpretadas como se de um sensor se tratasse. Deste modo são acedidas pelo
operador GET e definidas pelo operador SET (apenas o RF Power e o Rádio Duty Cycle).
59
Painéis disponíveis na janela do programa
Node Sensor/Node Settings Number of
Samples(GET)/Value(SET) Interval
GET
Nó
Sensor
Sensor/Actuador/Característica
Número de dados adquiridos Intervalo de aquisição
SET Valor de inicialização/actuação
REPORT Sensor Valor de comparação Duração
Tabela 11 - Tabela de parâmetros e os seus significados de cada operador.
Na tabela 11 estão descritos brevemente os parâmetros de cada operador. Os parâmetros
Sensor e Node Settings estão unidos na tabela porque a camada de serviços trata da mesma
forma os pedidos dirigidos aos sensores, ao actuador e às características do nó.
Os motes são programados para que, sempre que iniciem a sua actividade, notifiquem o
programa de demonstração a correr no computador, enviando uma mensagem de dados
simples contendo a informação que está a entrar na rede. Sempre que um nó saída entra na
rede, envia uma mensagem dirigida a todos os nós da rede de modo a notificá-los da sua
presença. Em resposta, os nós sensor ligados enviam uma mensagem de resposta para
informar, ao programa demonstrador, a sua existência.
60
6. Conclusão
No contexto do presente trabalho foi proposta uma camada de serviços que simplificam o
desenvolvimento de aplicações baseadas em redes de sensores sem fios. Para atingir este
objectivo foram estudados vários aspectos relacionados com as redes de sensores para que
deste modo os serviços desenvolvidos correspondessem às diferentes necessidades das
aplicações.
Os serviços desenvolvidos constituem uma camada de middleware de suporte às aplicações,
integrando os diferentes serviços de aquisição e comunicação de dados já disponibilizados
pela rede de sensores. Para além da unificação dos serviços, foram também criados novas
operações que unificam e simplificam os serviços de aquisição e comunicação no contexto do
TinyOS 2.0.
Os serviços de aquisição, actuação e notificação oferecidos pela camada de middleware
possibilitam o acesso aos dados dos sensores, a definição de variáveis e de alarmes através
dos operadores (GET, SET e REPORT). Os serviços de aquisição permitem vários tipos de
leituras dos dados recolhidos pelos sensores: leitura a pedido, leitura periódica e notificação
quando certos limites pré-definidos são atingidos. Os serviços de notificação e os serviços de
comunicação suportam agregação de dados o que permite reduzir o número de mensagens
que circulam na rede, oferecendo benefícios óbvios em termos de economia de energia. Deste
modo concluiu-se que estas funcionalidades oferecidas pela camada de middleware são
apropriadas ao uso numa gama diversificada de aplicações envolvendo a monitorização de
diferentes fenómenos físicos.
A camada de middleware desenvolvida também permite às aplicações inspeccionar o estado
da rede e participar activamente em diversos processos de configuração da mesma.
Especificamente, possibilita o acesso aos diferentes componentes de cada nó permitindo, por
exemplo, alterar características de funcionamento do rádio (CC2420) e conhecer o estado da
bateria do módulo. A utilização adequada destes serviços pode conduzir a uma maior eficiência
energética e, consequentemente, um maior tempo de vida da rede.
Para testar o funcionamento da camada de serviços desenvolvidos neste trabalho, foi
produzido um programa de demonstração em PC. Este programa possibilita a interacção e
visualização do estado da rede de sensores sem fios em qualquer altura. Este programa foi
testado numa rede de sensores sem fios composta por cinco MICAz, um deles
desempenhando o papel de nó de saída (sink). Os resultados obtidos pelos diversos testes
realizados através deste programa revelaram que os serviços respondem adequadamente aos
diferentes pedidos efectuados. No entanto, para valores do ciclo de funcionamento do rádio
(Radio Duty Cycle) menores de 80%, a fiabilidade de comunicação é bastante baixa, tendo
conduzido ao aumento do tempo de comunicação e por vezes à perda de mensagens. Assim, a
61
utilização da gestão dinâmica de energia pode gerar algumas falhas, especialmente quando se
coloca o rádio no estado de sleep por períodos longos, devendo por isso ser usada com algum
cuidado.
Gostaríamos de salientar que, para além dos serviços desenvolvidos, foi necessário também
intervir ao nível dos próprios módulos do TinyOS. Isso deveu-se ao facto de termos usado a
versão 2.0 que ainda não está completamente estabilizada e obrigou à realização de diversas
adaptações, nomeadamente aos módulos de acesso aos sensores da placa MTS310.
Devido às restrições temporais associadas ao presente trabalho e complexidade dos temas
envolvidos, não foi possível aprofundar os serviços de comunicação, nomeadamente a criação
de mecanismos de selecção do protocolo de comunicação que melhor se adapta a cada
pedido. Assim, seria muito interessante integrar serviços capazes de gerir o tráfego da rede e
oferecer várias alternativas de protocolos, mas isso deverá ser objecto de trabalho futuro.
Outra sugestão de desenvolvimento em futuros trabalhos refere-se à possibilidade de esta
camada de serviços permitir a existência de múltiplos nós de saída, bem como a capacidade
de expandir o número de nós para além da limitação actual de 255 endereços diferentes. Isto
pode ser efectuado com a criação de redes internas em que estas se comportam como redes
individuais comunicando entre si através dos nós de saída de cada uma.
Em seguida é apresentada uma lista de possíveis serviços que poderão ser desenvolvidos no
âmbito deste projecto em futuros trabalhos:
• Serviços que possibilitem a sincronização de todos os elementos da rede e assim criar
um tempo global de rede, permitindo deste modo associar o instante da aquisição aos
dados recolhidos.
• Integração de algoritmos de localização com base na interpretação dos diferentes
dados de rádio de modo obter a localização física de cada nó da rede.
• Introdução de técnicas de encriptação de dados nos protocolos de comunicação
melhorando-os deste modo em termos de desempenho e robustez.
Actualmente as redes de sensores sem fios constituem uma importante área de investigação.
Esta área possui enormes potencialidades e os seus desenvolvimentos podem ser aplicados
em múltiplos projectos e em diversos domínios. A capacidade de recolher e processar
grandezas físicas através de uma rede de sensores completamente autónoma, leva a que se
preveja a sua aplicação futura em diferentes áreas da sociedade. Espera-se com este trabalho
ter dado um contributo, ao facilitar o desenvolvimento de novas aplicações que usem redes de
sensores, e que isso contribua a sua maior divulgação e aplicação prática.
62
Referências
[1] S. Tilak, N. B. Abu-Ghazaleh, W. Heinzelman, “Infrastructure tradeoffs for sensor
networks”. In: Proceedings of the First ACM International Workshop on Wireless Sensor
Networks and Applications, USA, September 2002.
[2] I. Akyildiz, “Wireless sensor networks: a survey”. Computer Networks v. 38, n. 4, pp. 393–
422, Março 2002.
[3] I. Akyildiz, W. SU, Y. Sankarasubramaniam, E. Cayirci, ”A Survey on Sensor Network”,
IEEE Communications Magazine, Georgia Institute of Technology, August 2002.
[4] G. Werner-Allen, J. Johnson, M. Ruiz, J. Lees and M., Welsh, “Monitoring Volcanic
Eruptions with a Wireless Sensor Network”, European Workshop on Sensor Networks
(EWSN'05), January 2005.
[5] T. Simunic, L. Benini, P. Glynn, G. De Micheli, "Dynamic Power Management of Portable
Systems", MOBICOM 2000.
[6] T. Simunic, "Dynamic Management of Power Consumption", in Power Aware Computing,
editado por R. Graybill, R. Melhem, Kluwer Academic Publishers, 2002.
[7] C. Schurgers, M. Srivastava, “Modulation scaling for energy aware communication
systems”, Proc. International Symposium on Low Power Electronics and Design (ISLPED’01),
Huntington Beach, CA, pp.96-99, August 2001.
[8] Q. Gao, K. J. Blow, D. J. Holding, I. W. Marshall and X. Peng, ” Routing Analysis and
Energy Efficiency in Wireless Sensor Networks”, 6th IEEE CAS Symp. on Emerging
Technologies: Frontiers of Mobile and Wireless Communications, June 2004.
[9] V Raghunathan, C Schurgers, S. Park, M. B. Srivastava, “Energy-Aware Wireless
Microsensor Networks”, IEEE Signal Processing Magazine, March 2002.
[10] P. Levis, “TinyOS Programming”, July 2006.
[11] D. Gay, P. Levis, R. von Behren, “The nesC Language: A Holistic Approach to Networked
Embedded Systems”, Programming Language Design and Implementation (PLDI), 2003.
[12] Crossbow Technology, Inc., http://www.xbow.com
[13] CrossBow Technology, Inc, “MPR/ MIB User’s Manual”, Rev. A, Document 7430-0021-
07, September 2005.
63
[14] CrossBow Technology, Inc, “MTS/MDA Sensor and Data Acquisition Board, User’s
Manual”, Rev. B, Document 7430-0020-03, April 2005.
[15] “Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless Personal Area Networks (WPANs)”, IEEE Computer
Society, IEEE Std 802.15.4™, 2006.
[16] D. Lymberopoulos, Q. Lindsey, A. Savvides, “An Empirical Characterization of Radio
Signal Strength Variability in 3-D IEEE 802.15.4 Networks Using Monopole Antennas”, in
EWSN 06, pp. 326–341, 2006.
[17] P. Levis, G. Tolle, “TEP 118: Dissemination”, Core Working Group, TinyOS Community.
[18] P. Levis, N. Patel, D. Culler, S. Shenker, "Trickle: A Self-Regulating Algorithm for Code
Maintenance and Propagation in Wireless Sensor Networks.", In Proceedings of the First
USENIX/ACM Symposium on Networked Systems Design and Implementation (NSDI 2004),
2004.
[19] R. Fonseca, O. Gnawali, K. Jamieson, P. Levis, ”TEP 119: Collection”, Core Working
Group, TinyOS Community.
[20] R. Fonseca, O. Gnawali, K. Jamieson, S. Kim, P. Levis, A. Woo, “TEP 123: The
Collection Tree Protocol (CTP)”, Core Working Group, TinyOS Community.
[21] O. Gnawali, “TEP 124: The Link Estimation Exchange Protocol (LEEP)”, Core Working
Group, TinyOS Community.
[22] S. Coleri, M. Ergen, T. John Koo, “Lifetime Analysis of a Sensor Network with Hybrid
Automata Modelling”, WSNA, September 2002.
[23] P. Levis, C. Sharp,” TEP 106: Schedulers and Tasks”, Core Working Group, TinyOS
Community.
[24] P. Levis, ”TEP 107: TinyOS 2.x Boot Sequence”, Core Working Group, TinyOS
Community.
[25] K.Klues, P. Levis, D. Gay D. Culler, V. Handziski, “TEP 108: Resource Arbitration”, Core
Working Group, TinyOS Community.
[26] P. Levis, “TEP 111: message_t”, Core Working Group, TinyOS Community.
[27] B. Greenstein, P. Levis, “TEP 113: Serial Communication”, Core Working Group, TinyOS
Community.
[28] P. Levis, “TEP 116: Packet Protocols”, Core Working Group, TinyOS Community.
64
[29] P. Buonadonna, J. Hui, “TEP 117: Low-Level I/O”, Core Working Group, TinyOS
Community.
65
Anexo
O middleware apresentado e o respectivo programa de demonstração foi desenvolvido
no simulador de Unix, em ambiente Windows, Cygwin. A instalação do sistema TinyOS sobre
Cygwin está explicada no site http://www.tinyos.net/tinyos-2.x/doc/html/install-tinyos.html.
A versão do sistema operativo TinyOS 2.0, ao momento da conclusão deste trabalho,
ainda não se encontrava completamente estável, nomeadamente os componentes de ligação à
placa de sensores MTS310 utilizada neste trabalho. Assim, na elaboração deste trabalho teve
de se adaptar alguns componentes pertencentes ao sistema, componentes esses que podem
ser encontrados na directoria /mycomponets. Para que o middleware desenvolvido possa ser
executado correctamente, é necessário seguir os dois passos seguintes:
• Copiar a directoria /mycomponets para a directoria do sistema opt/tinyos-2.x/tos.
• Substituir o ficheiro .platform presente na pasta opt/tinyos-2.x/tos/platforms/micaz pelo
ficheiro com mesmo nome presente na pasta do trabalho.
A compilação e instalação dos Motes são realizadas pelos métodos apresentados na
tabela abaixo. Quando é instalado o programa compilado para o Mote é definido o seu
endereço de rede. No entanto, deve-se evitar definir mais do que um nó para cada endereço,
os endereços são definidos por uma variável de 8 bits sendo que pode representar 255
endereços diferentes.
Comando Descrição
make micaz Compilação com as características do MICAz.
make micaz install, <número do nó>
ex: make micaz install,1
Compilação e instala no Mote, definindo o seu
endereço de rede.
make micaz, reinstall, <número de nó> Instala no Mote o programa já compilado
anteriormente.
make micaz docs Compilação e a criação gráfica de todas as
ligações
