Subcamada da base de Dados

Com todos os dados das RSSFs categorizados na ontologia, a base de dados semântica é gerada pelas instâncias criadas e encontra-se em memória, para acesso as consultas e para a criação de novas instâncias. A escolha desse método para armazenar a base de dados semântica

5.5. CONSIDERAÇÕES FINAIS 79 1 p u b l i c v o i d r e c e i v e M e a s u r e m e n t s ( A p p l i c a t i o n M s g msg ) { 2 O n t o l o g y o n t o l o g y = O n t o l o g y . g e t I n s t a n c e ( ) ; 3 M y F a c t o r y o n t o l o g y F a c t o r y = new M y F a c t o r y ( o n t o l o g y . g e t M o d e l ( ) ) ; 4 D a t e d a t e = new D a t e ( ) ; 5 6 C o l l e c t i o n s e n s o r N o d e s C o l l e c t i o n = 7 o n t o l o g y F a c t o r y . g e t A l l S e n s o r N o d e I n s t a n c e s ( ) ; 8 C o l l e c t i o n s e n s i n g C o l l e c t i o n = 9 o n t o l o g y F a c t o r y . g e t A l l S e n s i n g I n s t a n c e s ( ) ; 10 11 o n t o l o g y . s e t S e n s o r N o d e ( ( S e n s o r N o d e ) s e n s o r N o d e s C o l l e c t i o n . 12 t o A r r a y ( ) [ msg . g e t _ n o d e i d ( ) − 1 ] ) ; 13 o n t o l o g y . s e t S e n s i n g ( ( S e n s i n g ) 14 s e n s i n g C o l l e c t i o n . t o A r r a y ( ) [ 0 ] ) ; 15 16 o n t o l o g y . s e t M e a s u r i n g ( o n t o l o g y F a c t o r y . 17 c r e a t e M e a s u r e m e n t ( " M e a s u r i n g _ " + measurementNumber + + ) ) ; 18 19 o n t o l o g y . g e t M e a s u r e m e n t ( ) . a d d H a s S e n s i n g ( o n t o l o g y . g e t S e n s i n g ( ) ) ; 20 o n t o l o g y . g e t M e a s u r e m e n t ( ) . a d d H a s S e n s o r N o d e ( 21 o n t o l o g y . g e t S e n s o r N o d e ( ) ) ; 22 o n t o l o g y . g e t M e a s u r e m e n t ( ) . a d d V a l u e ( msg . g e t _ d a t a ( ) ) ; 23 o n t o l o g y . g e t M e a s u r e m e n t ( ) . addTime ( d a t e . g e t T i m e ( ) ) ; 24 }

Figura 5.20: Código Java da classe Scenario para Receber os Dados das RSSFs e Instanciá-los

em memória foi apenas por uma facilidade na implementação. Valse salientar que os processos de consulta e criação de instâncias não sofreriam mudanças caso se optasse por outro meio de armazenamento, devido à forma como as classes foram implementadas.

5.5

Considerações Finais

Este capítulo apresentou o Módulo de Processamento Semântico da Informação (SIP) da SITRUS, responsável pela manipulação dos dados das RSSFs, a fim de categorizá-los e instanciá- los de forma adequada na ontologia proposta para ele. Com todos os dados instanciados, a base de dados semântica gerada é utilizada para as consultas e tomada de decisões no processo de reconfiguração dos nós sensores.

No início do capítulo, uma visão geral do funcionamento do SIP foi apresentada, a fim de contextualizar o seu funcionamento e sua importância. Em seguida, foi apresentado sua arquitetura e como os seus componentes e camadas se comunicam, inclusive com a SITRUS, apresentando com isso suas funcionalidades e responsabilidades.

em especial os mecanismos de reconfiguração e economia de energia, foi apresentada a ontologia desenvolvida para o SIP, com uma discussão sobre suas propriedades e relacionamentos atribuídos às classes. A ontologia proposta contém uma hierarquia que define uma RSSF, descrevendo suas características e capacidades.

Por fim, tanto o desenvolvimento da ontologia quanto da manipulação dos dados em Java foi discutido, com seus relacionamentos, diagramas e códigos apresentados para facilitar o entendimento.

A utilização de ontologias em conjunto com um projeto para RSSF se mostra bastante interessante, pois os dados consultados não sofrem mais problemas de ambiguidades ou falso positivo/negativo, além do que essas consultas não são mais realizadas diretamente na RSSF, mas na base de dados semântica, economizando com isso energia das RSSFs.

Outro ponto importante a ser mencionado é o mecanismo de reconfiguração, pois todo o processamento de tomada de decisão é realizado fora da RSSF, pelo SIP, deixando os nós sensores livres para processamento de suas funções internas.

81 81 81

6

Avaliação Experimental

Como as aplicações para Rede de Sensores Sem Fio (RSSF) devem criar condições para realização de suas atividades de sensoriamento e processamento o maior tempo possível, o objetivo desta avaliação experimental é apresentar o consumo de energia em diversas aplicações com diferentes níveis de processamento interno, em cenários onde se utilizam a aplicação original e sua versão portada para a SITRUS.

Toda avaliação do consumo de energia foi feita utilizando motes Crossbow MICAz1.

Para realizar as medições, foi utilizado um método sistemático de avaliação do consumo de energia nos próprios nós sensores, a partir de medições reais.

As próximas seções apresentam o procedimento de medições e sua implementação, as diferentes aplicações e suas características e, por fim, os resultados obtidos e a discussão deles.

6.1

Procedimento de Medição

Todas as aplicações em nesC utilizadas para o experimento foram implantadas em um mote MICAz, conectado a uma base MTS300. Elas foram compiladas pelo nesC Versão 1.3.4, utilizando a versão 2.1.2 do TinyOS. Além disso, todos os nós sensores estavam conectados via rádio frequência a um nó sensor com uma base MIB520, que funcionava como estação base e que estava conectada diretamente ao PC com o SIP instalado.

Para realizar os experimentos, foi utilizada uma abordagem sistemática para medir

de forma precisa o consumo de energia em um nó sensor (SILVA et al., 2014; TAVARES;

SILVA; MACIEL,2008). O sistema de medição é apresentado pela Figura 6.1, que tem como componentes um osciloscópio (Agilent DSO03202A), usado para medir a variação de tensão de um nó sensor, e uma fonte de energia (iCEL Manaus PS-5000), para garantir sempre a mesma voltagem durante a execução dos experimentos.

Um computador foi conectado ao osciloscópio, que captura a variação de tensão através de um resistor de 1 Ohm, pelo Channel 2. O outro canal, Channel 1, captura a atividade dos LEDS do nó sensor conectado ao osciloscópio, que a partir do estado de ligado ou desligado,

sinalizam o início ou fim da execução do experimento. A informação capturada pelo osciloscópio é usada como entrada para uma ferramenta responsável por todo o cálculo do consumo de energia, o Advanced Measurement Algorithms for Hardware Architecture (AMALGHMA).

Figura 6.1: Esquema de Medição do Consumo de Energia

Como apresentado pela Figura 6.1, apenas 1 nó sensor tem o seu consumo de energia cal- culado, mas existe a interação entre todos os nós sensores que fazem parta da RSSF, transmitindo e recebendo mensagens.

O AMALGHMA automatiza a medição e transforma os dados capturados pelo osciloscó- pio em informações (tempo de processamento, potência, valor da corrente elétrica, entre outras coisas). Com esses dados, é possível calcular o tempo médio de execução, o consumo de energia e outras estatísticas relacionadas.

O controle do início e fim do experimento, ou seja, ter os LEDS ligados ou desligados, é uma mensagem enviada do SIP para os nós sensores, fazendo parte do serviço de reconfiguração oferecidos pelo RAMSES. O código utilizado para configuração e realização de um experimento é apresentado na Figura 6.2. Como pode-se observar, a ideia é deixar o AMALGHMA pronto para execução, mas sem iniciar ainda o processo de medição (linha 3 e linha 4); configurar a aplicação no nó sensor (linha 5 e linha 6), para que o processo de medição sempre comece com as mesmas configurações; e só depois disso, dar início ao processo de medição (linha 9 e linha 10).

Todas as aplicações executadas nos nós sensores iniciaram com o mesmo tempo de taxa de amostragem para sensoriamento do ambiente, que são de 250 ms, e tiveram uma período

6.1. PROCEDIMENTO DE MEDIÇÃO 83 1 p u b l i c v o i d M e a s u r e m e n t s ( l o n g t i m e , i n t p e r i o d i c S a m p l i n g ) { 2 t r y { 3 d a t a M a n a g e r . stopAmalghma ( ) ; / / L e d s l i g a d o s 4 d a t a M a n a g e r . s e n d M e s s a g e T o S e n s o r s ( ) ; 5 d a t a M a n a g e r . s e t P e r i o d i c S a m p l i n g ( p e r i o d i c S a m p l i n g ) ; 6 d a t a M a n a g e r . s e n d M e s s a g e T o S e n s o r s ( ) ; 7 T h r e a d . s l e e p ( 5 0 0 ) ; 8 9 d a t a M a n a g e r . s t a r t A m a l g h m a ( ) ; / / L e d s d e s l i g a d o s 10 d a t a M a n a g e r . s e n d M e s s a g e T o S e n s o r s ( ) ; 11 T h r e a d . s l e e p ( t i m e ) ; / / Tempo do e x p e r i m e n t o 12 d a t a M a n a g e r . stopAmalghma ( ) ; / / L e d s l i g a d o s 13 d a t a M a n a g e r . s e n d M e s s a g e T o S e n s o r s ( ) ; 14 15 } c a t c h ( I n t e r r u p t e d E x c e p t i o n ex ) { 16 L o g g e r . g e t L o g g e r ( S c e n a r i o D e f a u l t . c l a s s . getName ( ) ) . 17 l o g ( L e v e l . SEVERE , n u l l , ex ) ; 18 } 19 }

Figura 6.2: Código para Configuração do processo de medição

de 4 minutos entre o início e o fim do experimento. Com esse tempo, foi possível verificar as mudanças de comportamento nas reconfigurações dos nós sensores.

A razão para a utilização de um período de 4 minutos é fazer com que a diferença entre o consumo de energia para diferentes cenários se torne evidente, além da adequação do tempo de medição com a janela de medição do osciloscópio.

O consumo de energia é uma média de consumo de 100 experimentos realizados para cada cenário utilizado, com um intervalo de confiança de 95%.

Além disso, testes de hipótese foram realizados para comparar cada resultado, a fim de verificar se a média da diferença entre eles é zero, ou seja, os consumos de energia eram iguais. Quando o valor de p-value é menor que 0,05, a hipótese nula é rejeitada, indicando que os resultados obtidos dos consumos de energia são estatisticamente diferentes. Caso contrário, isto é, valor de p-value é maior do que 0,05, não há nenhuma evidência para dizer que a diferença entre as médias é estatisticamente significativa.

Com relação às aplicações, cinco foram utilizadas no processo de medição, com carac- terísticas e níveis de processamento diferentes umas das outras. Todas elas se encontram nas

aplicações de exemplo do TinyOS2

Para cada uma das aplicações, 3 cenários diferentes foram utilizados para calcular o consumo de energia:

 Aplicação: A aplicação não utiliza nenhum recurso de gerenciamento de energia e

nenhum serviço de reconfiguração. Dessa forma, a aplicação inicia da mesma forma que termina, sem nenhuma alteração em seu comportamento. Esse será o cenário base para a comparação com os outros cenários.

 Aplicação + RAMSES: A mesma aplicação é executada utilizando os serviços do

RAMSES. Assim, toda a transmissão de dados entre os nós sensores e os serviços de reconfiguração são garantidos pelo middleware, de forma transparente para a aplicação. A aplicação fica responsável apenas pela coleta e transmissão de dados a partir da interface definida pelo middleware. Fora a adição da camada de middleware, todo o código de transmissão e aquisição de dados foi retirado da aplicação original, deixando essa execução para o middleware. Mesmo tendo suporte para os serviços de reconfiguração, nenhuma é realizada. Este cenário serve para avaliar o impacto de se adicionar o RAMSES em uma aplicação.

 Aplicação + SITRUS: Neste cenário, a SITRUS é utilizada em sua totalidade. O

RAMSES utiliza seu gerenciamento de energia baseado na interface Low Power Listening, ligando e desligando a antena periodicamente para evitar o consumo desnecessário de energia, mas com tempo suficiente para detectar uma portadora e receber ou enviar todo o pacote que deseja. Além disso, todos os dados são enviados para o SIP, de forma que os dados sejam armazenados na base de dados semântica e os mecanismos de tomada de decisões para a reconfiguração possam ser utilizados. O serviço de reconfiguração escolhido para as aplicações, utilizado no cenário Aplicação + SITRUS, foi o de alteração da taxa de amostragem baseado na média das últimas amostras, ou seja, caso os valores fossem redundantes, a taxa era aumentada. Essa verificação ocorria a cada 1 minuto e o valor da taxa de amostragem é dobrado em caso de redundância.

Quando a taxa de amostragem é alterada, o serviço de gerenciamento de energia também é acionado, alterando seu período de tempo com a antena ligada/desligada, garantindo assim uma melhor eficiência no consumo de energia. Esse comportamento pode ser observado a partir de trace apresentado pela Figure 6.3.

Para todos os cenários, as informações enviadas para o Módulo de Processamento Semântico da Informação (SIP) dizem respeito ao tipo de sensoriamento, identificação do nó sensor, o valor do sensoriamento do ambiente e o valor da taxa de amostragem. Essas informações serão utilizadas para instanciar a ontologia, e com isso, servir de base para as consultas sobre o estado da rede e para o mecanismo de tomada de decisões do SIP.

6.2

Resultados

Para cada uma das aplicações escolhidas para o processo de avaliação, será feito uma breve descrição apresentando suas características e como elas foram alteradas para se adaptar ao

6.2. RESULTADOS 85 1 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 250 A g g r e g a t i o n : 0 SIP : 0 2 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 250 A g g r e g a t i o n : 0 SIP : 0 3 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 250 A g g r e g a t i o n : 0 SIP : 0 4 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 250 A g g r e g a t i o n : 0 SIP : 0 5 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 250 A g g r e g a t i o n : 0 SIP : 0 6 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 250 A g g r e g a t i o n : 0 SIP : 0 7 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 250 A g g r e g a t i o n : 0 SIP : 0 8 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 250 A g g r e g a t i o n : 0 SIP : 0 9 A l t e r a n d o t a x a de a m o s t r a g e m . . . 10 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 500 A g g r e g a t i o n : 0 SIP : 0 11 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 500 A g g r e g a t i o n : 0 SIP : 0 12 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 500 A g g r e g a t i o n : 0 SIP : 0 13 S e n s o r : 01 T e m p e r a t u r e : 28 S a m p l i n g : 500 A g g r e g a t i o n : 0 SIP : 0

Figura 6.3: Trace de Reconfiguração da Taxa de Amostragem

RAMSES. Com base nessas informações, a avaliação do consumo de energia será apresentada, bem como informações de memória utilizada pelas aplicações.

6.2.1

Aplicação RadioCountToLeds

A aplicação RadioCountToLeds é a aplicação mais simples com transmissão de dados

que se encontra nos exemplos do TinyOS3. Ela mantém um contador que é incrementado a

cada 250 ms, transmitindo o seu valor em um pacote sempre que seu valor é atualizado. Além da função de transmitir os dados da contagem, seus 3 LEDS são utilizados para sinalizar a transmissão, recepção ou algum tipo de erro. Uma característica dessa aplicação é que ela não utiliza o subsistema de sensoriamento, sendo assim, não consome energia nesse subsistema. Essa é uma aplicação útil para demonstrar como funcionam os mecanismos básicos de comunicação do TinyOS.

O diagrama de componentes da aplicação RadioCountToLeds e sua versão em con- junto com o RAMSES são apresentados pela Figura 6.4. Por essa Figura, percebe-se que os componentes de comunicação (AMReceiverC e AMSenderC) da aplicação original foram reti- rados em sua versão com o middleware, e foram adicionados os componentes MiddlewareC e CC2420ActiveMessageC, que são responsáveis pelos serviços de middleware e pelo controle de energia em antenas CC2420 (utilizadas nos motes MICAz), respectivamente.

6.2.1.1 Consumo de Energia

Os resultados do consumo de energia da aplicação RadioCountToLeds estão apresentados na Figura 6.5. Como pode ser observado, mesmo com a inclusão do middleware RAMSES na aplicação, o consumo de energia se mostrou praticamente o mesmo, mostrando assim que ele

RadioCountToLedsC MainC Boot AMReceiverC Receive AMSenderC AMSend Packet ActiveMessageC SplitControl LedsC Leds TimerMilliC Timer<TMilli>

(a) Aplicação RadioCountToLeds

RadioCountToLeds RadioCountToLedsC RadioCountToLeds MainC Boot ActiveMessageC SplitControl LedsC Leds TimerMilliC Timer<TMilli> MiddlewareC Middleware CC2420ActiveMessageC LowPowerListening

(b) Aplicação RadioCountToLeds com o RAMSES

Figura 6.4: Componentes da Aplicação RadioCountToLeds com e sem o Middleware

não é tão impactante no consumo de energia para esse tipo de aplicação.

Vale salientar que a quantidade de energia necessária para a transmissão de dados entre dois sensores é diretamente relacionada à distância entre eles. Além disso, por utilizar rádio frequência, quanto mais tempo a antena fica ligada, mais energia é consumida, mesmo que o nó sensor não esteja transmitindo ou recebendo algum pacote.

Por conta disso, existe uma diferença significativa no consumo de energia entre a apli- cação original e sua versão utilizando a SITRUS. Como a implementação do RAMSES visa o gerenciamento de energia também a partir do uso da interface Low Power Listening, além do uso da reconfiguração da taxa de amostragem em tempo de execução, a redução do consumo de energia foi de 69,10%. Mesmo sendo uma aplicação simples, a redução do consumo de energia foi significativa.

O teste de hipótese entre as amostras da aplicação pura e sua versão com a SITRUS foi realizado, evidenciando que os dois resultados são realmente diferentes, com um p-value apre-

sentando um valor menor que 2,2*10−16. Assim, conclui-se que existem evidências suficientes

6.2. RESULTADOS 87

Aplicação Aplicação + RAMSES Aplicação + SITRUS

Aplicação RadioCountToLeds

Consumo de Energia (Joules)

0 1 2 3 4 2.97970773 2.97581227 0.920842609

Figura 6.5: Consumo de Energia para a Aplicação RadioCountToLeds Utilizando os Cenários Propostos

6.2.1.2 Memória Utilizada

Com relação ao tipo de memória utilizado no MICAz, a ROM é uma memória Flash de 128KB (interna ao microcontrolador ATmega128L) para memória de programas. Já a RAM do ATmega128L é uma SRAM de 4KB, utilizada para armazenar os dados das aplicações.

A Tabela 6.1 apresenta os valores de uso de memória da aplicação RadioCountToLeds em todos os cenários utilizados nos experimentos. Como pode ser observado, a aplicação

RadioCountToLedsoriginal ocupa 7,84% de RAM e 9,66% de ROM do mote MICAz. Já os

valores de memória utilizados pelo pela aplicação em conjunto com o RAMSES mostram que o consumo de RAM é de 10,47% e de ROM 9,85%. Essa aumento de consumo ocorre devido a introdução das camadas do RAMSES na aplicação RadioCountToLeds.

Tabela 6.1: Utilização de Memória da Aplicação RadioCountToLeds

RAM (bytes) % RAM ROM (bytes) % ROM

RadioCountToLeds 321 7,84 12.660 9,66

RadioCountToLeds + RAMSES 429 10,47 12.904 9,85

RadioCountToLeds + SITRUS 484 11,82 14.692 11,21

Com a utilização de toda a SITRUS, ou seja, o SIP e o RAMSES trabalhando em conjunto e com todos os serviços disponíveis, os valores de memória utilizados passaram a ser de 11,82% de RAM e 11,21% de ROM. Esse aumento de memória se deve a disponibilidade de todos os

serviços para a aplicação RadioCountToLeds a partir do uso da SITRUS.

Como pode ser observado, o aumento de utilização de memória RAM e ROM não foram significativos, o que demonstra que vale a pena a adição de novas camadas e novos serviços de software oferecidos às aplicações.