5.4 Implementação
6.2.2 Aplicação RadioSenseToLeds
A segunda aplicação avaliada, a RadioSenseToLeds4, faz amostragem do ambiente a
partir de um sensor padrão utilizado pela plataforma de sensoriamento, gerando e transmitindo os dados de sensoriamento sempre que um novo valor é coletado. Além disso, os dados transmitidos, recebidos ou erros de transmissão são sinalizados por seus 3 LEDS, como acontecia na aplicação anterior. Dessa forma, existe consumo de energia pela transmissão de dados, processamento interno e pelo subsistema de sensoriamento. Essa aplicação é útil para demonstrar como funcionam os mecanismos de comunicação, temporizadores e o subsistema se sensoriamento padrão do TinyOS.
O diagrama de componentes, apresentado na Figura 6.6, mostra como seus componentes se relacionam para formar a aplicação, bem como a diferença entre sua versão original e aquela com o RAMSES. Como aconteceu na aplicação anterior, os componentes de comunicação (AMReceiverC e AMSenderC) da aplicação original foram retirados em sua versão com o RAM- SES e foram adicionados os componentes MiddlewareC e CC2420ActiveMessageC. Além disso, percebe-se a utilização do sensor padrão de sensoriamento a partir do componente DemoSensorC.
6.2.2.1 Consumo de Energia
Os resultados do consumo de energia em todos os cenários utilizados para a aplicação estão sumarizados na Figura 6.7. Como pode ser observado, a aplicação original e sua versão com o RAMSES não tem uma diferença significante em relação ao consumo de energia, com valores sendo quase os mesmos. Dessa forma, mostra que o RAMSES consegue adicionar serviços para a aplicação a um custo energético quase nulo se comparado a aplicação original, devido a sua implementação.
Já a comparação entre a versão original da aplicação com sua versão com toda a SITRUS sendo executada apresentou uma diferença significativa, com uma redução no consumo de energia de 71,25%. Esse resultado se justifica pela utilização dos componentes de baixo consumo de energia implementados pelo RAMSES, bem como pela alteração na taxa de amostragem, enviada por mensagem pelo SIP.
O teste de hipótese entre as amostras da aplicação RadioSenseToLeds em sua versão pura e sua versão com a SITRUS foi realizado, evidenciando que os dois resultados são diferentes,
com um p-value apresentando um valor menor que 2,2*10−16no teste. Assim, conclui-se que
existem evidências suficientes para mostrar que os dois resultados são diferentes.
6.2. RESULTADOS 89 RadioSenseToLedsC MainC Boot AMReceiverC Receive AMSenderC AMSend Packet ActiveMessageC SplitControl LedsC Leds TimerMilliC Timer<TMilli> DemoSensorC Read<uint16_t>
(a) Aplicação RadioSenseToLeds
RadioSenseToLeds RadioSenseToLedsC RadioSenseToLeds MainC Boot ActiveMessageC SplitControl Packet LedsC Leds TimerMilliC Timer<TMilli> DemoSensorC Read<uint16_t> MiddlewareC Middleware CC2420ActiveMessageC LowPowerListening
(b) Aplicação RadioSenseToLeds com o RAMSES
Figura 6.6: Componentes da Aplicação RadioSenseToLeds com e sem o Middleware
6.2.2.2 Memória Utilizada
A Tabela 6.2 apresenta os valores de utilização de memória da aplicação RadioSenseTo-
Ledsem todos os cenários utilizados nos experimentos.
Como pode ser observado, a aplicação RadioSenseToLeds ocupa 8,08% de RAM e 10,30% de ROM do mote MICAz, com 331 e 13.496 bytes, respectivamente. Já os valores uso de memória obtidos da aplicação com o RAMSES mostram que o consumo de RAM é de 11,99% e de ROM 10,45%, com 491 e 13.702 bytes, respectivamente. Assim como ocorreu na aplicação anterior, essa aumento do consumo ocorre devido à introdução das camadas do RAMSES na aplicação.
Tabela 6.2: Utilização de Memória da Aplicação RadioSenseToLeds
RAM (bytes) % RAM ROM (bytes) % ROM
RadioSenseToLeds 331 8,08 13.496 10,30
RadioSenseToLeds + RAMSES 491 11,99 13.702 10,45
RadioSenseToLeds + SITRUS 546 13,33 15.566 11,88
Já com a utilização de toda a SITRUS na aplicação original, os valores de uso de memória obtidos passaram a ser de 13,33% de RAM e 11,88% de ROM, com valores de 546 e 15.566 bytes, respectivamente.
Assim como ocorreu na aplicação anterior, mesmo com um aumento de consumo de RAM e ROM, existe espaço suficiente para a inclusão de novos serviços e diferentes implementações
Aplicação Aplicação + RAMSES Aplicação + SITRUS
Aplicação RadioSenseToLeds
Consumo de Energia (Joules)
0 1 2 3 4 3.4804095 3.48070556 1.00075108
Figura 6.7: Consumo de Energia para a Aplicação RadioSenseToLeds
dos serviços já existentes no middleware, como mostra a utilização de memória Tabela 6.2.
6.2.3
Aplicação Temperature
A terceira aplicação avaliada difere das anteriores por utilizar um sensoriamento espe- cífico da placa MTS300, que é o sensoriamento de temperatura do ambiente. Para devolver o resultado do sensoriamento em graus Celsius, um processamento interno de conversão pre- cisa ser realizado a cada leitura realizada. Tanto o sensoriamento como o processamento de conversão para Celsius são fontes extras de consumo de energia. Além disso, a sinalização de transmissão e recepção dos dados é feita por 2 de seus 3 LEDS disponíveis. Essa é uma aplicação útil para demonstrar o funcionamento de sensoriamentos específicos, conversão de dados dos sensoriamentos, mecanismos de comunicação e temporizadores.
O diagrama de componentes da aplicação Temperatura é apresentado na Figura 6.8. Por ela, pode ser observada a utilização do componente TempC, que é o componente utilizado para capturar a temperatura do ambiente. Da mesma forma que ocorreu anteriormente, os componen- tes responsáveis pela comunicação da aplicação original foram substituídos pelo componente MiddlewareC, além da adição do componente CC2420ActiveMessageC, para controle de energia na transmissão de dados, em sua versão do RAMSES.
6.2. RESULTADOS 91 TemperatureC MainC Boot AMReceiverC Receive AMSenderC AMSend Packet ActiveMessageC SplitControl LedsC Leds TimerMilliC Timer<TMilli> TempC Read<uint16_t>
(a) Aplicação Temperature
Temperature TemperatureC Temperature MainC Boot ActiveMessageC SplitControl Packet LedsC Leds TimerMilliC Timer<TMilli> TempC Read<uint16_t> MiddlewareC Middleware CC2420ActiveMessageC LowPowerListening
(b) Aplicação Temperature com o RAMSES
Figura 6.8: Componentes da Aplicação Temperature com e sem o Middleware
6.2.3.1 Consumo de Energia
Os resultados da avaliação do consumo de energia da aplicação Temperature estão sumarizados na Figura 6.9. Por utilizar mais processamento interno no processo de conversão para graus Celcius e por utilizar um sensoriamento de temperatura, seus resultados mostram um consumo de energia maior se comparado às aplicações anteriores. Ainda assim, o mesmo comportamento apresentado anteriormente se repete, ou seja, a adição do RAMSES na aplicação original, com todas as suas camadas e serviços disponíveis, tem um custo de energia muito baixo se comparados os dois cenários.
Já a comparação da aplicação original com sua versão utilizando toda a SITRUS mostra uma diferença significativa de consumo de energia, com uma redução de 70,79%. Essa redução ocorre devido ao uso dos serviços de reconfiguração implementados no RAMSES, com tomadas de decisões no SIP, além da utilização da interface Low Power Listening para comunicação a um custo energético mais baixo.
O teste de hipótese realizado entre as amostras da aplicação Temperature e sua versão com a SITRUS evidencia que os dois resultados são diferentes, com um p-value apresentando
um valor menor que 2,2*10−16no teste. Assim, conclui-se que existem evidências suficientes
Aplicação Aplicação + RAMSES Aplicação + SITRUS
Aplicação Temperature
Consumo de Energia (Joules)
0 1 2 3 4 3.87207392 3.86481869 1.13111803
Figura 6.9: Consumo de Energia para a Aplicação Temperature
6.2.3.2 Memória Utilizada
A Tabela 6.3 apresenta um sumário de utilização de memória da aplicação Temperature, com todas os cenários utilizados no cálculo de consumo de energia.
Como pode ser observado, a aplicação original utiliza 368 bytes de memória RAM e 16.786 bytes de memória ROM, ocupando 8,98% e 12,81% de sua capacidade total, respec-
tivamente. Com a introdução das camadas de software do RAMSES na aplicação original, o consumo passou a ser de 555 bytes de RAM e 17.098 de ROM, ocupando 13,55% e 13,04 da capacidade total de bytes, respectivamente.
Tabela 6.3: Utilização de Memória da Aplicação Temperature
RAM (bytes) % RAM ROM (bytes) % ROM
Temperature 368 8,98 16.786 12,81
Temperature + RAMSES 555 13,55 17.098 13,04
Temperature + SITRUS 610 14,89 19.066 14,55
Ja com toda a SITRUS sendo utilizada pela aplicação original, que utiliza mais compo- nentes, e com isso, mais memória é utilizada, o consumo de RAM em bytes passou a ser de 610 e de ROM 19.066 bytes, totalizando 14,98% e 14,55% da capacidade total, respectivamente.
Da mesma forma que ocorreu com as aplicações anteriores, existe espaço para a inclusão de novos serviços e diferentes implementações dos serviços já existentes no middleware, como mostra a tabela de utilização de memória da aplicação Temperature.
6.2. RESULTADOS 93
6.2.4
Aplicação Oscilloscope
A aplicação Oscilloscope5é uma aplicação que realiza um pré-processamento dos dados
coletados antes da transmissão. Para isso, a aplicação Oscilloscope realiza periodicamente o sen- soriamento de luminosidade do ambiente, outro sensoriamento específico da placa MTS300, mas apenas transmite os dados quando o conjunto de 10 amostras dessas leituras forem completadas. Essas leituras podem ser recebidas pela estação base e ter seus dados agregados e exibidos pela aplicação Java de mesmo nome, que faz parte das aplicações exemplo do TinyOS.
Como fonte maior de consumo de energia, temos o processamento e transmissão do conjunto de 10 amostras e o sensoriamento de luminosidade. Essa aplicação difere das demais pois, ao invés de enviar apenas uma amostra coletada, a aplicação envia um conjunto com 10 amostras, deixando que a agregação seja realizada por outro nó sensor ou por outra aplicação.
OscilloscopeC MainC Boot ActiveMessageC SplitControl AMSenderC AMSend AMReceiverC Receive TimerMilliC Timer<TMilli> PhotoC (Sensor) Read<uint16_t> LedsC Leds
(a) Aplicação Oscilloscope
Oscilloscope OscilloscopeC Oscilloscope MainC Boot ActiveMessageC SplitControl TimerMilliC Timer<TMilli> PhotoC (Sensor) Read<uint16_t> LedsC Leds MiddlewareC Middleware CC2420ActiveMessageC LowPowerListening
(b) Aplicação Oscilloscope com o RAMSES
Figura 6.10: Componentes da Aplicação Oscilloscope com e sem o Middleware
O diagrama de componentes da aplicação Oscilloscope é apresentado na Figura 6.10. Como pode ser observado pelo diagrama, o componente PhotoC é utilizado para capturar a luminosidade do ambiente. Da mesma forma que ocorreu com todas as aplicações anteriores, os componentes responsáveis pela comunicação da aplicação original foram substituídos pelo com- ponente MiddlewareC, além da adição do componente CC2420ActiveMessageC, para controle de energia na transmissão de dados, em sua versão do RAMSES.
6.2.4.1 Consumo de Energia
Os resultados de consumo de energia para todos os cenários propostos da aplicação
Oscilloscope estão sumarizados na Figura 6.11. Como pode ser observado, mesmo com a
inclusão do RAMSES na aplicação original, o consumo de energia foi praticamente o mesmo, mostrando novamente que o RAMSES tem um bom desempenho energético quando comparado às aplicações portadas para ela.
Aplicação Aplicação + RAMSES Aplicação + SITRUS
Aplicação Oscilloscope
Consumo de Energia (Joules)
0 1 2 3 4 3.58035499 3.5603773 0.489601269
Figura 6.11: Consumo de Energia para a Aplicação Oscilloscope
Da mesma forma que ocorreu nos experimentos anteriores, a aplicação utilizando a SITRUS obteve uma considerável redução no consumo de energia, desta vez com 86,33% de economia em relação a aplicação original. Essa diferença ocorre pela forma como os dados são processados. Enquanto a aplicação original coleta 10 amostras e envia o conjunto de dados coletados, a aplicação com a SITRUS agrega esses dados em um único dado, diminuindo assim a quantidade de bits em uma transmissão. Além disso, o middleware faz uso da interface Low Power Listening, o que diminui o consumo de energia a partir da interface de transmissão.
Mais uma vez, o teste de hipótese entre as amostras foi realizado, evidenciando que a aplicação pura e sua versão com a SITRUS são realmente diferentes, com um p-value apresen-
tando um valor menor que 2,2*10−16. Assim, conclui-se que existem evidências suficientes para
6.2. RESULTADOS 95
6.2.4.2 Memória Utilizada
A Tabela 6.4 apresenta um sumário de utilização de memória da aplicação Oscilloscope, com todas os cenários envolvidos na avaliação experimental do consumo de energia.
Como pode ser observado, a aplicação original utiliza 398 bytes de memória RAM e 15.104 bytes de memória ROM, ocupando 9,72% e 11,52%, respectivamente, da capacidade total do MICAz. Com a inclusão do RAMSES na aplicação original, o consumo passou a ser de 476 bytes de RAM e 14.920 de ROM, ocupando 11,62% e 11,38 da capacidade total de bytes, respectivamente.
Tabela 6.4: Utilização de Memória da Aplicação Oscilloscope
RAM (bytes) % RAM ROM (bytes) % ROM
Oscilloscope 398 9,72 15.104 11,52
Oscilloscope + RAMSES 476 11,62 14.920 11,38
Oscilloscope + SITRUS 558 13,62 17.060 13,02
Já com a utilização total da SITRUS, o consumo de RAM passou a ser de 610 bytes e de ROM 17.060 bytes, totalizando 13,62% e 13,02% da capacidade total, respectivamente.
Como pode ser observado, existe espaço para a inclusão de novos serviços e diferentes implementações dos serviços já existentes no RAMSES, como mostra a tabela de utilização de memória da aplicação Oscilloscope.
6.2.5
Aplicação AntiTheft
A última aplicação avaliada é uma aplicação real de monitoramento de ladrões em ambientes. Para detectar se um ladrão se encontra em um ambiente, o nó sensor que executa a aplicação identifica o nível de luz do ambiente (se luz do ambiente não existe, significa que esse nó sensor foi roubado e que foi colocado em um lugar escuro, ou seja, está dentro do bolso ou uma mochila, provavelmente) ou pela aceleração (um nó sensor roubado é um nó sensor que se movimenta). Para reportar um roubo, o nó sensor liga o LED vermelho como alerta, emite um som e reporta aos outros nós sensores o ocorrido, através de mensagens pela rede.
Tanto o sensoriamento de luz quanto do som do ambiente são feitos pela placa MTS300. Para reportar os dados pela rede, a aplicação AntiTheft utiliza dois protocolos diferentes: O protocolo Dissemination, que dissemina um valor para todos os nós da RSSF, e o protocolo Collection, que permite a um nó sensor reportar um valor ao seu nó root.
Essa é uma aplicação útil para demonstrar o funcionamento de mais de um sensoriamento específico sendo executado a mesmo tempo, diferentes protocolos de rede trabalhando em conjunto e a ação de temporizadores.
O diagrama de componentes da aplicação AntiTheft é apresentado pela Figura 6.12. Nela pode ser observada a utilização dos componentes PhotoC e SounderC, que são os componentes de monitoramento de luminosidade e alerta sonoro. O componente AccelXStreamC é o componente
AntiTheftC MainC Boot TimerMilliC (MyTimer) Timer<TMilli> LedsC Leds ActiveMessageC SplitControl CC2420ActiveMessageC LowPowerListening PhotoC Read<uint16_t> AccelXStreamC ReadStream<uint16_t> SounderC Mts300Sounder DisseminationC StdControl DisseminatorC DisseminationValue<settings_t> CollectionSenderC (AlertSender) Send CollectionC StdControl AMSenderC (SendTheft) AMSend AMReceiverC (ReceiveTheft) Receive
(a) Aplicação AntiTheft
AntiTheft AntiTheftC AntiTheft MainC Boot TimerMilliC Timer<TMilli> LedsC Leds ActiveMessageC SplitControl CC2420ActiveMessageC LowPowerListening PhotoC Read<uint16_t> AccelXStreamC ReadStream<uint16_t> SounderC Mts300Sounder MiddlewareC Middleware
(b) Aplicação AntiTheft com o RAMSES
Figura 6.12: Componentes da Aplicação AntiTheft com e sem o Middleware
que identifica movimentação nos nós sensores. Já os componentes DisseminationC e CollectionC são os componentes dos protocolos de comunicação utilizados pela aplicação. Para a adição do RAMSES, os componentes responsáveis pela comunicação da aplicação original foram substituí- dos pelo componente MiddlewareC, além da adição do componente CC2420ActiveMessageC, para controle de energia na transmissão de dados, em sua versão do RAMSES.
6.2.5.1 Consumo de Energia
Os resultados da avaliação do consumo de energia da aplicação AntiTheft estão sumariza- dos na Figura 6.13. Mesmo utilizando protocolos de rede que visam um melhor aproveitamento de energia, a aplicação AntiTheft tem um alto consumo se comparado às aplicações anteriores, devido aos processamentos internos e ao uso de 2 tipos diferentes de sensoriamento. Quando se adicionam as camadas de middleware à aplicação original e se trocam os mecanismos de comunicação pelos do RAMSES, o consumo de energia tem uma leve redução.
Já a comparação da aplicação original com sua versão utilizando toda a SITRUS mos- tra uma diferença significativa de consumo de energia, com uma redução de 78,78%. Essa redução ocorre devido ao modelo de distribuição utilizado, pelo serviços de reconfiguração implementados no RAMSES com tomadas de decisões no SIP e pela utilização de mecanismos de comunicação a um custo energético mais baixo, a partir da interface Low Power Listening.
O teste de hipótese realizado entre as amostras da aplicação AntiTheft e sua versão com a SITRUS evidencia que os dois resultados são diferentes, com um p-value apresentando um valor
menor que 2,2*10−16no teste realizado. Assim, conclui-se que existem evidências suficientes
6.2. RESULTADOS 97
Aplicação Aplicação + RAMSES Aplicação + SITRUS
Aplicação AntiTheft
Consumo de Energia (Joules)
0 1 2 3 4 3.7787425 3.63197084 0.80185279
Figura 6.13: Consumo de Energia para a Aplicação AntiTheft
6.2.5.2 Memória Utilizada
A Tabela 6.5 apresenta um sumário de utilização de memória da aplicação AntiTheft, com todas os cenários utilizados no cálculo de consumo de energia.
Como pode ser observado, de todas as aplicações analisadas, essa foi a aplicação que mais utilizou recursos de memória RAM e ROM. A aplicação original utiliza 1708 bytes de memória RAM e 26.310 bytes de ROM, o que corresponde a 41,70% e 20,07%, respectivamente. Esse consumo elevado pode ser explicado pela quantidade de componentes utilizados para desenvolver a aplicação, como pode ser observado pela Figura 6.12a. Com a introdução de novos componentes do RAMSES na aplicação original e a substituição de alguns outros componentes, como pode ser observado pela Figura 6.12b, houve uma redução tanto de RAM quanto de ROM. O consumo passou a ser de 579 bytes de RAM e 17.928 de ROM, totalizando um valor de 14,14% de RAM e 13,68% de ROM. Essa redução ocorreu devido substituição dos componentes da aplicação original pelos componentes utilizados pelo RAMSES, o que demonstra que mesmo com a introdução de novas camadas de software, a memória RAM e ROM tem um consumo baixo de recursos utilizados.
Já com toda a SITRUS sendo utilizada, temos um aumento de consumo de memória em relação a sua versão com o RAMSES, mas ainda assim, um consumo menor se comparado com a aplicação original. O consumo de RAM em bytes passou a ser de 634 e de ROM 20.176 bytes, totalizando 15,48% e 15,39% da capacidade total, respectivamente.
Tabela 6.5: Utilização de Memória da Aplicação AntiTheft
RAM (bytes) % RAM ROM (bytes) % ROM
AntiTheft 1708 41,70 26.310 20,07
AntiTheft + RAMSES 579 14,14 17.928 13,68
AntiTheft + SITRUS 634 15,48 20.176 15,39
anteriores, existe espaço para a inclusão de novos serviços e novas implementações de serviços já existentes para o RAMSES, como mostra a ocupação total de memória apresentado pela Tabela 6.5.
6.3
Considerações Finais
Este capítulo apresentou a avaliação experimental que analisa o consumo de energia de 5 aplicações a partir da SITRUS. No início do capítulo foi apresentada uma visão geral dos experimentos que seriam realizados. Em seguida, foi apresentado o procedimento sistemático de medição em conjunto com a metodologia aplicada para os experimentos, com o funcionamento das aplicações a serem testadas e os diferentes cenários que seriam medidos. Por fim, os resultados dos experimentos foram apresentados, com a discussão de seus resultados.
As aplicações utilizadas nos experimentos, diferem tanto no nível de processamento interno, nos mecanismos de sensoriamento e nos mecanismos de transmissão de dados, que são os 3 fatores que mais contribuem para o consumo de energia.
Dessa forma, este experimentos serviram para apresentar que a SITRUS tinge o objetivo proposto no que se refere ao controle do consumo de energia, mostrando que sua implementação é mais eficiente utilizando esse tipo de infraestrutura do que o envio de pacotes individuais em uma taxa constante com a antena sempre ligada, além dos benefícios da utilização de serviços de
99 99 99
7
Trabalhos Relacionados
Este capítulo apresenta os principais trabalhos na área de ontologia, middleware para Rede de Sensores Sem Fio (RSSF) e mecanismos para reconfiguração de software em aplicações para RSSF. Estes trabalhos estão classificados e apresentados de acordo com alguns dos diferentes tipos de middleware, dos trabalhos relacionados com ontologia em RSSFs e dos sistemas de reconfiguração encontrados na literatura.
7.1
Middleware Para Redes de Sensores sem Fio
Atualmente, existem diversos trabalhos de pesquisa desenvolvidos na área de middleware
para Rede de Sensores Sem Fio (BHUYAN; SARMA; SARMA,2014;RUBIO; DÍAZ; TROYA,
2007). O principal objetivos dos sistemas de middleware é suportar o desenvolvimento de
aplicações distribuídas .
Dentre os diversos modelos de middleware existentes na literatura, 3 modelos desenvol- vidos a partir dos diferentes tipos de middleware para RSSFs são descritos neste trabalho.