uma infraestrutura semÂntica para economizar … · ração para rede de sensores sem fio...

Pós-Graduação em Ciência da Computação

“UMA INFRAESTRUTURA SEMÂNTICA PARA

ECONOMIZAR ENERGIA EM REDE DE SENSORES SEM

FIO”

Por

Kalil Araujo Bispo

Tese de Doutorado

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, 2015

Universidade Federal de Pernambuco

CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Kalil Araujo Bispo

“UMA INFRAESTRUTURA SEMÂNTICA PARA

ECONOMIZAR ENERGIA EM REDE DE

SENSORES SEM FIO"

ORIENTADOR: Prof. Paulo Roberto Freire Cunha

CO-ORIENTADOR: Prof. Nelson Souto Rosa

RECIFE, 2015

Este trabalho foi apresentado à Pós-Graduação em Ciência da

Computação do Centro de Informática da Universidade Federal de

Pernambuco como requisito parcial para obtenção do grau de Doutor em

Ciência da Computação.

Catalogação na fonteBibliotecária Jane Souto Maior, CRB4-571

B623i Bispo, Kalil Araujo Uma infraestrutura semântica para economizar energia em

rede de sensores sem fio / Kalil Araujo Bispo. – Recife: O Autor,2015.

120 f.: il., fig., tab.

Orientador: Paulo Roberto Freire Cunha. Tese (Doutorado) – Universidade Federal de Pernambuco.

CIn, Ciência da computação, 2015. Inclui referências.

1. Sistemas distribuídos. 2. Rede de sensores sem fio. 3. Middleware. 4. Ontologia. I. Cunha, Paulo Roberto Freire (orientador). II. Título.

004.36 CDD (23. ed.) UFPE- MEI 2015-156

Tese de Doutorado apresentada por Kalil Araujo Bispo à Pós-Graduação em Ciência da

Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o

título “UMA INFRAESTRUTURA SEMÂNTICA PARA ECONOMIZAR ENERGIA

EM REDE DE SENSORES SEM FIO” orientada pelo Prof. Paulo Roberto Freire

Cunha e aprovada pela Banca Examinadora formada pelos professores:

______________________________________________ Prof. Carlos André Guimarães Ferraz

Centro de Informática / UFPE

_____________________________________________ Prof. Paulo Romero Martins Maciel Centro de Informática / UFPE _____________________________________________ Prof. Kelvin Lopes Dias Centro de Informática / UFPE

_____________________________________________ Profa. Cláudia Maria Fernandes Araújo Ribeiro Instituto Federal de Educação, Ciência e Tecnologia/RN _____________________________________________ Profa. Jeísa Pereira de Oliveira Domingues Departamento de Estatística e Informática/ UFRPE

Visto e permitida a impressão.Recife, 24 de agosto de 2015

___________________________________________________Profa. Edna Natividade da Silva BarrosCoordenador da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.

Aos meus pais (Arnaldo e Luiza)

Agradecimentos

Primeiramente a Deus, pela saúde, pela força que tive durante a elaboração desta tese,por tudo que conquistei e que ainda conquistarei.

Em especial, gostaria de agradecer aos meus pais (Arnaldo e Luiza) e irmãos (Abdule Farid), que estiveram sempre ao meu lado nesse período e me ensinaram as coisas maisimportantes que sei hoje. Muito obrigado a vocês! E também a Mayka, a irmã de 4 patas, queesteve presente durante todo o doutorado, mostrando sua felicidade através de lambidas.

A Joana Morato, por sempre estar ao meu lado, incentivando, cuidando e estando presentenos momentos mais difíceis e também nos alegres. Agradeço pela paciência e compreensão.Saiba que essa conquista é de nós dois. Te amo!

A Celso e Ione Morato, pelo incentivo, torcida e por todo o apoio que me deram duranteesse período.

Ao meu orientador Paulo Cunha, por me dar a oportunidade de participar deste programade Doutorado. A Nelson Rosa, pela grande ajuda no desenvolvimento desse trabalho, comideias, conselhos e muita paciência. Agradeço pelo apoio, disponibilidade, pelos comentáriosimprescindíveis e por terem acreditado em mim e no meu trabalho.

Aos amigos de Aracaju, de Recife, os de perto e os de longe. Aos que resolveram ficar eaos que resolveram partir. Todos vocês tornaram o meu doutorado mais alegre.

A todos os professores da UFS, hoje meus colegas de trabalho, por acreditarem em meupotencial durante a graduação e por terem me incentivado a seguir esse caminho.

Enfim, gostaria de registrar meus sinceros agradecimentos como reconhecimento dadedicação de muitas pessoas que, direta ou indiretamente, contribuíram para a realização destetrabalho.

Resumo

As Redes de Sensores Sem Fio (RSSFs) são redes com recursos limitados, como proces-samento, largura de banda, memória e, o mais importante, energia. Dessa forma, as aplicaçõespara nós sensores devem criar condições de realizar suas operações de sensoriamento e processa-mento no maior tempo possível, como também mecanismos que possam ajudar na economia deenergia, por exemplo, a utilização de melhores algoritmos, agregação de dados, mecanismos deauto-gerenciamento, dentre outros, respeitando as limitações de recursos das RSSF. Algumaspesquisas na área mostram que solucionar esse tipo de problema não é uma tarefa fácil de serresolvida.

Sendo assim, este trabalho propõe uma solução de economia de energia para RSSF e umaforma comum de compartilhamento de dados entre aplicações e redes diferentes, baseada em umaInfraestrutura Semântica para RSSF chamada SITRUS. Ela utiliza reconfiguração paramétricanos nós sensores em tempo de execução, a partir de dados de sensoriamento processados forada RSSF, utilizando ontologias desenvolvidas com esse propósito para o processamento dessesdados.

SITRUS é formada por duas partes importantes: o Middleware Ciente de Reconfigu-ração para Rede de Sensores Sem Fio (RAMSES), responsável pelo transporte de dados egerenciamento de serviços das aplicações que são executadas nos nós sensores; e o Módulo deProcessamento Semântico da Informação (SIP), que tem por finalidade categorizar os dados paraa geração da base de dados semântica. Esta base de dados servirá para a tomada de decisões dereconfiguração dos nós sensores e para o processamento de consultas sobre as RSSFs.

A escolha por esse modelo se deve ao fato de que o processamento referente à reconfi-guração da RSSF não sofre intervenção humana. O processamento é determinado pelo SIP eexecutado pelo RAMSES. Dessa forma, segue-se um modelo baseado em semântica formal.

Pretende-se também que a SITRUS favoreça a integração de diferentes aplicações pelocompartilhamento de dados relativos a um mesmo contexto. Os benefícios desta abordagemincluem o enriquecimento dos dados pela associação de seu significado, e não apenas pela sintaxedos dados, facilitando assim o seu acesso e eliminando ambiguidades.

Como forma de demonstrar a eficiência da SITRUS, uma avaliação experimental doconsumo de energia com algumas aplicações e diferentes cenários foi realizada, mostrando emseus resultados que a SITRUS atende ao que foi proposto no que diz respeito ao gerenciamentodo consumo de energia.

Palavras-chave: Infraestrutura Semântica. Rede de Sensores Sem Fio. Middleware. Ontologiae Web Semântica. Consumo de Energia. Reconfiguração de Software.

Abstract

Wireless Sensor Networks (WSNs) are networks with limited resources such as proces-sing, bandwidth, memory, and most importantly, energy. Thus, applications for sensor nodesmust create conditions to perform their sensing and processing operations as long as possible,as well as mechanisms that can help to save energy, for example, such as the use of betteralgorithms, data aggregation, self-management mechanisms, among others, in compliance theresource limitations of WSN. Some research in the area show that solving this problem is not aneasy task to be addressed.

Thus, this paper proposes a power saving solution for WSN and a common way ofsharing data between different applications and networks based on a Semantic Infrastructure forWSN called SITRUS. It uses parametric reconfiguration in sensor nodes at runtime, from sensingdata processed outside the WSN using ontologies developed for this purpose for processing suchdata.

SITRUS consists of two major parts: RAMSES, responsible for data transport andservice management applications that run on the sensor nodes; and SIP, which is intended tocategorize the data for generating the semantic database. This database will serve for decisionmaking on the reconfiguration of sensor nodes and for query processing on WSNs.

The choice for this model is due to the fact that the processing related to the reconfigura-tion of WSN does not suffer human intervention. Processing is determined by SIP and performedby RAMSES. Thus, it follows a model based on formal semantics.

It is intended that the SITRUS encourages the integration of different applications bysharing data on a same context. The benefits of this approach include the enrichment of the databy the association of its meaning, and not only by the syntax of the data, thus facilitating theiraccess and eliminating ambiguities.

In order to demonstrate the effectiveness of SITRUS, an experimental evaluation ofpower consumption with some applications and different scenarios was performed, and theresults shows that SITRUS serves to what has been proposed in regard to management of theenergy consumption.

Keywords: Semantic Infrastructure. Wireless Sensor Network. Middleware. Ontology andSemantic Web. Power Consumption. Software Reconfiguration.

Lista de Figuras

2.1 Arquitetura da Web Semântica (BERNERS-LEE, 2000) . . . . . . . . . . . . . 262.2 Namespace de uma Ontologia para Pizza . . . . . . . . . . . . . . . . . . . . . 272.3 Classes da Ontologia para Pizza com a classe owl:Thing . . . . . . . . . . . . 282.4 Declaração de Classes em OWL . . . . . . . . . . . . . . . . . . . . . . . . . 282.5 Declaração de Propriedades em OWL . . . . . . . . . . . . . . . . . . . . . . 292.6 Consulta Simples em SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . 302.7 Ambiente Monitorado por uma Rede de Sensor Sem Fio . . . . . . . . . . . . 312.8 Visão Geral do Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 Cenário de Uso de Monitoramento de Ambiente Usando a SITRUS . . . . . . . 423.2 Cenário de Uso de Consulta de Dados da RSSF Usando a SITRUS . . . . . . . 423.3 Cenário de Uso de Reconfiguração de um Nó Sensor Usando a SITRUS . . . . 433.4 Arquitetura SITRUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1 Arquitetura do Middleware RAMSES . . . . . . . . . . . . . . . . . . . . . . 514.2 Formato de um pacote em Low Power Listening . . . . . . . . . . . . . . . . . 534.3 Código Utilizado para Inicialização de um Nó Sensor Usando Low Power Listening 544.4 Configuração da Interface LowPowerListening por Tipo de Plataforma . . . . . 554.5 Componente Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6 Componente TransportLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.7 Código Utilizado para Transmissão de Dados Utilizando o RAMSES . . . . . . 574.8 Componente DistributionLayer . . . . . . . . . . . . . . . . . . . . . . . . . . 584.9 Diagrama de Sequência para Anúncio e Assinatura de Tópico . . . . . . . . . . 594.10 Diagrama de Sequência para Publicação de uma Mensagem . . . . . . . . . . . 604.11 Componente ServiceLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.12 Diagrama de Sequência para Agregação de Dados . . . . . . . . . . . . . . . . 614.13 Diagrama de Sequência para as Mensagens Recebidas do SIP para Reconfiguração 62

5.1 Arquitetura do Módulo de Processamento Semântico da Informação (SIP) . . . 665.2 Taxonomia da Ontologia do SIP . . . . . . . . . . . . . . . . . . . . . . . . . 685.3 A Classe SensorNode da Ontologia do SIP . . . . . . . . . . . . . . . . . . . . 695.4 Propriedade isReachable sendo utilizada a partir de regras para definir existência

de rota entre dois nós sensores . . . . . . . . . . . . . . . . . . . . . . . . . . 695.5 A Classe Power da Ontologia do SIP . . . . . . . . . . . . . . . . . . . . . . . 705.6 A Classe Device da Ontologia do SIP . . . . . . . . . . . . . . . . . . . . . . 705.7 A Classe LogicalRegion da Ontologia do SIP . . . . . . . . . . . . . . . . . . 71

5.8 A Classe SensorType da Ontologia do SIP . . . . . . . . . . . . . . . . . . . . 715.9 A Classe WSN da Ontologia do SIP . . . . . . . . . . . . . . . . . . . . . . . 725.10 A Classe Measurement da Ontologia do SIP . . . . . . . . . . . . . . . . . . . 725.11 Diagrama de Classes UML do Componente de Comunicação . . . . . . . . . . 745.12 Código Utilizado para Envio de Mensagens de Reconfiguração . . . . . . . . . 745.13 Código Utilizado para Reconfiguração da Taxa de Amostragem . . . . . . . . . 755.14 Diagrama UML da Classe OWLIndividual . . . . . . . . . . . . . . . . . . . . 765.15 Diagrama UML das Classes MyFactory e OWLModel . . . . . . . . . . . . . 765.16 Código Java para Recuperar Uma Instância Específica da Classe SensorNode . 765.17 Diagrama UML da Classe Ontology . . . . . . . . . . . . . . . . . . . . . . . 775.18 Código SPARQL para Determinar os Dados de Medição de um Nó Sensor . . . 775.19 Diagrama de Sequência da Classe SIPReasoner e do Método startReasoner . . 785.20 Código Java da classe Scenario para Receber os Dados das RSSFs e Instanciá-los 79

6.1 Esquema de Medição do Consumo de Energia . . . . . . . . . . . . . . . . . . 826.2 Código para Configuração do processo de medição . . . . . . . . . . . . . . . 836.3 Trace de Reconfiguração da Taxa de Amostragem . . . . . . . . . . . . . . . . 856.4 Componentes da Aplicação RadioCountToLeds com e sem o Middleware . . . 866.5 Consumo de Energia para a Aplicação RadioCountToLeds Utilizando os Cená-

rios Propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.6 Componentes da Aplicação RadioSenseToLeds com e sem o Middleware . . . 896.7 Consumo de Energia para a Aplicação RadioSenseToLeds . . . . . . . . . . . 906.8 Componentes da Aplicação Temperature com e sem o Middleware . . . . . . . 916.9 Consumo de Energia para a Aplicação Temperature . . . . . . . . . . . . . . . 926.10 Componentes da Aplicação Oscilloscope com e sem o Middleware . . . . . . . 936.11 Consumo de Energia para a Aplicação Oscilloscope . . . . . . . . . . . . . . . 946.12 Componentes da Aplicação AntiTheft com e sem o Middleware . . . . . . . . 966.13 Consumo de Energia para a Aplicação AntiTheft . . . . . . . . . . . . . . . . 97

Lista de Tabelas

6.1 Utilização de Memória da Aplicação RadioCountToLeds . . . . . . . . . . . . 876.2 Utilização de Memória da Aplicação RadioSenseToLeds . . . . . . . . . . . . 896.3 Utilização de Memória da Aplicação Temperature . . . . . . . . . . . . . . . . 926.4 Utilização de Memória da Aplicação Oscilloscope . . . . . . . . . . . . . . . . 956.5 Utilização de Memória da Aplicação AntiTheft . . . . . . . . . . . . . . . . . 98

7.1 Sumário da Discussão sobre Middleware Para Rede de Sensores Sem Fio . . . 1027.2 Sumário da Discussão sobre Ontologia em Rede de Sensores Sem Fio . . . . . 1057.3 Sumário da Discussão sobre Sistemas Adaptativos para Rede de Sensores Sem Fio109

Lista de Acrônimos

AMALGHMA Advanced Measurement Algorithms for Hardware Architecture . . . . . . . . . . . 82

CCA Clear Channel Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

EPO Extension Plugins Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

MiLAN Middleware Linking Applications and Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 101

OWL Web Ontology Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

QoS Qualidade de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

RAMSES Middleware Ciente de Reconfiguração para Rede de Sensores Sem Fio . . . . . . 20

RDF Resource Description Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

RDFS Resource Description Framework Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

RSSF Rede de Sensores Sem Fio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

SDO Sensor Data Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

SHO Sensor Hierarchy Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

SIP Módulo de Processamento Semântico da Informação . . . . . . . . . . . . . . . . . . . . . . 20

SITRUS Infraestrutura Semântica para Rede de Sensores Sem Fio . . . . . . . . . . . . . . . . . . . 22

SPARQL SPARQL Protocol and RDF Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

SLA Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

SUMO IEEE Suggested Upper Merged Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

SWASN Semantic Web Architecture for Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 103

TinyOS Tiny Microthreading Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

XML eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

W3C World Wide Web Consortion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Sumário

1 Introdução 151.1 Contexto e Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Caracterização do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4 Objetivos e Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.5 Estrutura da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Conceitos Básicos 232.1 Ontologia e Web Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1.1 A Linguagem OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.2 Estrutura de uma Ontologia OWL . . . . . . . . . . . . . . . . . . . . 272.1.3 Linguagem de Consulta SPARQL . . . . . . . . . . . . . . . . . . . . 29

2.2 Rede de Sensores Sem Fio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.1 Desafios no Desenvolvimento de Aplicações para RSSF . . . . . . . . 312.2.2 TinyOS e nesC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.1 Requisitos para o Desenvolvimento de um Middleware . . . . . . . . . 362.3.2 Middleware para Rede de Sensores Sem Fio . . . . . . . . . . . . . . . 38

2.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 SITRUS: Infraestrutura Semântica para Rede de Sensores Sem Fio 403.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2 Cenários de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.1 Monitoramento do Ambiente . . . . . . . . . . . . . . . . . . . . . . . 413.2.2 Consulta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.3 Reconfiguração dos Nós Sensores . . . . . . . . . . . . . . . . . . . . 43

3.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3.1 Camada de Dados das Redes de Sensores . . . . . . . . . . . . . . . . 443.3.2 Camada Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.3 Camada de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4 Soluções Envolvendo a SITRUS . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.1 Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.2 Anulação das Restrições Sintáticas nas Consultas . . . . . . . . . . . . 473.4.3 Reconfiguração Paramétrica . . . . . . . . . . . . . . . . . . . . . . . 473.4.4 Economia de Energia . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


4 RAMSES: Middleware Ciente de Reconfiguração para Rede de Sensores Sem Fio 494.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.1 Camada de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.2 Camada de Distribuição . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.3 Camada de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.1 Low Power Listening . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.3.2 Componente Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 554.3.3 Componente TransportLayer . . . . . . . . . . . . . . . . . . . . . . . 564.3.4 Componente DistributionLayer . . . . . . . . . . . . . . . . . . . . . 574.3.5 Componente ServiceLayer . . . . . . . . . . . . . . . . . . . . . . . . 60


5 SIP: Módulo de Processamento Semântico da Informação 645.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.1 Componente de Comunicação . . . . . . . . . . . . . . . . . . . . . . 665.2.2 Camada Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.2.1 Subcamada do Motor de Raciocínio . . . . . . . . . . . . . . 675.2.2.2 Subcamada de Regras . . . . . . . . . . . . . . . . . . . . . 675.2.2.3 Subcamada de Consultas SPARQL . . . . . . . . . . . . . . 675.2.2.4 Subcamada da Base de Dados . . . . . . . . . . . . . . . . . 68

5.3 Ontologia do SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.1 Descrição das Classes e suas Propriedades . . . . . . . . . . . . . . . . 685.3.2 Checagem de Consistência das Classes . . . . . . . . . . . . . . . . . 73

5.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.4.1 Componente de Comunicação . . . . . . . . . . . . . . . . . . . . . . 735.4.2 Camada Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.4.3 Subcamada da base de Dados . . . . . . . . . . . . . . . . . . . . . . 78


6 Avaliação Experimental 816.1 Procedimento de Medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.2.1 Aplicação RadioCountToLeds . . . . . . . . . . . . . . . . . . . . . . 856.2.1.1 Consumo de Energia . . . . . . . . . . . . . . . . . . . . . . 856.2.1.2 Memória Utilizada . . . . . . . . . . . . . . . . . . . . . . . 87

14

6.2.2 Aplicação RadioSenseToLeds . . . . . . . . . . . . . . . . . . . . . . 886.2.2.1 Consumo de Energia . . . . . . . . . . . . . . . . . . . . . . 886.2.2.2 Memória Utilizada . . . . . . . . . . . . . . . . . . . . . . . 89

6.2.3 Aplicação Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . 906.2.3.1 Consumo de Energia . . . . . . . . . . . . . . . . . . . . . . 916.2.3.2 Memória Utilizada . . . . . . . . . . . . . . . . . . . . . . . 92

6.2.4 Aplicação Oscilloscope . . . . . . . . . . . . . . . . . . . . . . . . . . 936.2.4.1 Consumo de Energia . . . . . . . . . . . . . . . . . . . . . . 946.2.4.2 Memória Utilizada . . . . . . . . . . . . . . . . . . . . . . . 95

6.2.5 Aplicação AntiTheft . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.2.5.1 Consumo de Energia . . . . . . . . . . . . . . . . . . . . . . 966.2.5.2 Memória Utilizada . . . . . . . . . . . . . . . . . . . . . . . 97


7 Trabalhos Relacionados 997.1 Middleware Para Redes de Sensores sem Fio . . . . . . . . . . . . . . . . . . . 99

7.1.1 Middleware Orientado a Mensagens . . . . . . . . . . . . . . . . . . . 997.1.2 Middleware Baseado em Espaços de Tuplas . . . . . . . . . . . . . . . 1007.1.3 Middleware Dirigido à Aplicação . . . . . . . . . . . . . . . . . . . . 1017.1.4 Discussão Sobre os Trabalhos . . . . . . . . . . . . . . . . . . . . . . 101

7.2 Ontologia em Redes de Sensores sem Fio . . . . . . . . . . . . . . . . . . . . 1027.2.1 SWASN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.2.2 Ontologia Universal para RSSF . . . . . . . . . . . . . . . . . . . . . 1037.2.3 Aplicações de Monitoramento . . . . . . . . . . . . . . . . . . . . . . 1047.2.4 Discussão Sobre os Trabalhos . . . . . . . . . . . . . . . . . . . . . . 105

7.3 Sistemas Adaptativos para RSSF . . . . . . . . . . . . . . . . . . . . . . . . . 1067.3.1 Maté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.3.2 Impala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.3.3 Durin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.3.4 KSpot+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.3.5 Discussão Sobre os Trabalhos . . . . . . . . . . . . . . . . . . . . . . 108


8 Conclusão e Trabalhos Futuros 1108.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118.3 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Referências 114

151515

1Introdução

Este capítulo tem como objetivo introduzir o presente trabalho no contexto de recon-figuração de nós sensores em tempo de execução a partir de uma infraestrutura semântica.Inicialmente, será apresentado o contexto e a motivação do trabalho, incluindo o emprego dasRedes de Sensores Sem Fio (RSSFs) no contexto atual de aplicações distribuídas. Em seguida,os principais desafios envolvidos no desenvolvimento de aplicações para Rede de Sensores SemFio serão descritos. Na sequência, serão apresentados os trabalhos relacionados e a propostadesse trabalho. Por fim, será apresentada a estrutura da tese.

1.1 Contexto e Motivação

As Redes de Sensores Sem Fio (RSSFs) ganharam muita atenção nos últimos anos,com os nós sensores se tornando cada vez menores, baratos e com implantação cada vezmais fácil, o que possibilitou o desenvolvimento de diversos tipos de aplicações (GILBERT;KALIAPERUMAL; RAJSINGH, 2012; HADIM; MOHAMED, 2006a). Mas estes ambientessão muito dinâmicos, escaláveis e com problemas específicos relacionados à sua natureza, o queaumenta consideravelmente a complexidade de desenvolvimento de aplicações.

Uma RSSF é composta por um conjunto de nós sensores (dezenas, centenas ou atémilhares) que são colocados em regiões em que se quer monitorar determinados tipos de fenôme-nos, como temperatura, pressão, luminosidade, umidade, ruído, presença ou ausência de certostipos de objetos, medidas de posição, velocidade e aceleração de um objeto, concentração desubstâncias, dentre outros. Esses nós sensores realizam o sensoriamento do ambiente, processamos dados e enviam esses dados processados para um nó especial, chamado de estação base. Aestação base pode atuar como um gateway para outras redes, tem um poder de processamentomaior e oferece um ponto de acesso para outras aplicações e também para intervenção humana.Os nós sensores podem ser usados para o sensoriamento contínuo ou apenas para detecção deum evento.

Essas redes têm um grande potencial para diversas aplicações em cenários como moni-toramento médico, aplicações militares, segurança de escritórios e residências, agricultura de

1.1. CONTEXTO E MOTIVAÇÃO 16

precisão, localização, monitoramento animal, dentre outros (DURISIC et al., 2012; ARAMPAT-ZIS; LYGEROS; MANESIS, 2005; AKYILDIZ et al., 2002a). Com todas essas possibilidades,suas aplicações tornam-se cada vez mais numerosas, gerando também um grande volume dedados, que são normalmente processados pelas suas próprias aplicações. A ausência de umaforma comum de comunicação entre diferentes aplicações limita o compartilhamento de dadosentre as RSSFs.

De forma geral, as RSSFs operam essencialmente sem intervenção humana direta, poispodem ser instaladas em lugares de difícil acesso, hostis ou remotos, onde a substituição oumanutenção do dispositivo pode ser inviável. Por conta disso, o ideal é que as RSSFs tenhammecanismos de auto-gerenciamento (auto-configuração, auto-manutenção, auto-organização,auto-proteção e assim por diante), devido também à pouca capacidade computacional individualdos nós sensores e sua topologia dinâmica (RUIZ et al., 2004; AKYILDIZ et al., 2002a).

Devido às restrições de carregamento de baterias e da falta de intervenção humana,pode-se dizer que a principal diz respeito ao seu consumo de energia. Em cenários como matasfechadas ou de guerra, por exemplo, a recarga de baterias torna-se quase impossível. Assim, osnós sensores devem gastar o mínimo de energia para realizar suas tarefas, tentando maximizarseu tempo de funcionamento o quanto possível. Idealmente, os dispositivos devem ser mantidosem modos de funcionamento que minimizem o custo da energia, sendo aplicados apenas quandonecessário, a partir da utilização de melhores algoritmos, componentes que gastem menos energiaou reconfiguração em tempo de execução.

Com relação à disseminação de dados, quanto mais dados gerados, mais dados sãotransmitidos e mais energia é consumida, degradando assim toda a rede. Dessa forma, aeficiência energética1 sempre deve ser levada em consideração no desenvolvimento de umaaplicação para RSSF. Além disso, eficiência energética não deve ser pensada apenas para umúnico nó sensor, mas para toda a rede.

Como apresentado em pesquisas anteriores em ANASTASI et al. (2009), a transmissão deum bit pela rede pode consumir mais energia do que o processamento de milhares de instruções,pois o subsistema de comunicação tem um consumo muito mais elevado de energia do queo subsistema de computação. Por essa razão, a comunicação pode ser melhorada através depré-processamentos antes da disseminação dos dados. Outra importante característica das RSSFé que o subsistema de sensoriamento pode ser uma significativa fonte de consumo de energia e,por essa razão, os dados de sensoriamento devem ser adquiridos apenas quando necessário (LIUet al., 2010), evitando também processamento desnecessário.

Uma RSSF tende a ser dependente da aplicação a que se destina, ou seja, os requisitos dehardware e software e os mecanismos de operação variam de acordo com a aplicação. Devido aessas características tão específicas e diversos tipos de restrições, o uso de middleware (HADIM;MOHAMED, 2006b; BERNSTEIN, 1996) faz-se necessário para dar suporte ao desenvolvimento

1Eficiência energética: estratégias para maximizar o tempo de vida da RSSF a partir de um consumo mínimo deenergia

1.2. CARACTERIZAÇÃO DO PROBLEMA 17

de aplicações para nós sensores, possibilitando ainda a abstração da complexidade envolvida emserviços.

O uso de middleware fornece às aplicações uma abstração dos mecanismos de comuni-cação e possibilitam que estas tenham acesso aos serviços disponibilizados pelo seu ambientede execução, sem que seja necessário um conhecimento dos detalhes de baixo-nível envolvi-dos, como também resolver limitações de heterogeneidade de dados e aplicações (HADIM;MOHAMED, 2006b).

Diante desse cenário, as aplicações para sensores devem criar condições para realizarsuas operações de sensoriamento e processamento o maior tempo possível, como também utilizarmecanismos que possam ajudar na economia de energia, por exemplo, na utilização de melhoresalgoritmos de roteamento, agregação de dados, mecanismos de auto-gerenciamento em tempode execução, dentre outros, respeitando as limitações de recursos das RSSFs (BAPAT; ARORA,2006; AKYILDIZ et al., 2002a). Além disso, as aplicações para sensores devem tambémdisponibilizar uma forma comum de compartilhamento de informações entre diversas RSSFsdiferentes, sem que isso comprometa o consumo de energia.

1.2 Caracterização do Problema

Como mencionado anteriormente, as RSSFs consistem de nós sensores operando compouca memória, largura de banda limitada, baixo poder de processamento e severas restrições deenergia. Muitas vezes, as RSSFs são instaladas em lugares de difícil acesso, onde a substituiçãoou manutenção dos dispositivos pode se tornar inviável. Além dessas restrições, as RSSFs sãodependentes das aplicações a que se destinam, tornando-se restrito o compartilhamento de dadosentre redes ou entre aplicações de forma direta sem algum tipo de mecanismo que favoreça essatarefa.

Dessa forma, o problema que este trabalho trata é como reduzir o consumo de energia emRSSF, além de apresentar uma forma comum para compartilhamento de dados entre aplicações eredes diferentes. Neste cenário, a semântica (estruturas ou padrões formais sobre determinadoconteúdo, atribuindo um significado a esse conteúdo, de forma que seja perceptível tantopelos humanos como pelos computadores) se torna um fator importante para a solução dessesproblemas tão complexos.

As RSSFs são redes em que a especificidade das aplicações torna-se um fator comumdevido aos vários tipos de restrições. Sendo assim, o desenvolvimento de uma aplicação paraesse tipo de rede não é trivial e deve ser sempre pensado em manter a rede o maior tempopossível ativa, evitando sobrecarga de determinados nós sensores ou uma drenagem de bateriapor conta de um algoritmo com processamento elevado. Idealmente, os nós sensores devemmanter seu funcionamento apenas para realizar uma tarefa específica, sendo suas ações aplicadasapenas quando necessário para resolver alguns eventos do sistema (ANASTASI et al., 2009;MAHFOUDH; MINET, 2008; PANTAZIS; VERGADOS, 2007).

1.3. ESTADO DA ARTE 18

Apesar de ter tantas restrições, as RSSFs continuamente coletam e geram um grandevolume de dados, que normalmente são entregues e processados por suas aplicações. A falta deum modo comum de comunicação entre RSSFs limita o compartilhamento de dados coletados.Além disso, à medida que mais dados são gerados, mais energia é consumida, degradando oestado da rede. A eficiência energética é algo que deve ser sempre priorizado no desenvolvimentode aplicações para RSSF.

Para melhorar a eficiência energética, um pré-processamento dos dados antes do envioé fundamental. Existem algumas técnicas de pré-processamento, por exemplo, agregação dedados (TRIPATHI; GUPTA; CHOURASIYA, 2014; KRISHNAMACHARI; ESTRIN; WICKER,2002a). Outra solução seria utilizar uma representação semântica de uma RSSF, adotando umaorganização hierárquica da informação. O uso de ontologias promove a integração de diferentesaplicações pelo compartilhamento de dados em um mesmo contexto e, dessa forma, sobrepõe àslimitações sintáticas de troca de mensagens e comunicação dessas aplicações (NIKOLIc et al.,2011; EID; LISCANO; EL SADDIK, 2006).

Em um cenário tão complexo como esse, com um grande volume de dados a sertransportado, redes heterogêneas em um mesmo ambiente de monitoramento, serviços depré-processamento e o aproveitamento da representação semântica das RSSFs, a utilizaçãode middleware se torna uma alternativa interessante, embora o uso de sistemas de middleware

tradicionais em geral requeiram uma grande capacidade de memória e poder de processamento,tornando-os pouco indicados para serem empregados em RSSF. Sendo assim, uma solução demiddleware para RSSF deve levar em consideração suas características e limitações (GUIMA-RAES et al., 2006), pois ela adiciona uma camada ao nó sensor, abstraindo a complexidade dacomunicação e da disponibilização de serviços. Dessa forma, o middleware fica responsável porresolver problemas relacionados à heterogeneidade de dados e adição de serviços à aplicação,por exemplo, serviços de agregação de dados, comunicação e reconfiguração.

Para os desenvolvedores de aplicações para RSSF, o middleware fornece uma abstraçãodos mecanismos de comunicação e possibilita que estes tenham acesso aos serviços disponibili-zados pelo seu ambiente de execução, sem que seja necessário um entendimento dos detalhes debaixo-nível envolvidos e da heterogeneidade de dados e aplicações (MOTTOLA; PICCO, 2012;HADIM; MOHAMED, 2006b).

1.3 Estado da Arte

Diversos trabalhos desenvolvidos mesclam as teorias de ontologia e Web Semântica emRSSF. No entanto, pouca atenção tem sido dada à representação semântica das RSSFs parao consumo de energia. A ideia de introduzir conceitos de Web Semântica e criar sistemas deinformação baseados em ontologia para RSSFs foi introduzido em AVANCHA; PATEL; JOSHI(2004). Com este trabalho, os autores mapearam em uma ontologia características importantesde um nó sensor, que descrevem suas funcionalidades e seu estado atual.

1.3. ESTADO DA ARTE 19

O trabalho proposto por AVANCHA; PATEL; JOSHI (2004) serviu de base para diversostrabalhos mesclando RSSF e semântica, mas muitos desses trabalhos usaram ontologias apenaspara prover dados com semântica, construir uma base de dados e melhorar as respostas dasconsultas, mas sem uma preocupação em reutilizar esses dados para melhorias na rede. EmEID; LISCANO; EL SADDIK (2007) e HUANG; JAVED (2008) são definidas ontologias paradescrever conceitos e relacionamentos das RSSFs a partir dos dados da rede, além de melhorara precisão das consultas. Em GAO; BRUENIG; HUNTER (2014), os dados provenientes dasRSSFs para monitoramento do ambiente são utilizados para a classificações de perigo de incêndioaplicando tecnologias de Web Semântica para o processamento de fluxos de dados, que permitema especialistas de domínio especificar e adaptar as regras para o cálculo de índices de incêndio.Já em SAWANT; ADINARAYANA; DURBHA (2014), Web Semântica é utilizada em RSSFpara aplicações de agricultura de precisão. Com isso, os autores conseguiram trabalhar cominteroperabilidade entre diferentes sistemas de sensoriamento de forma padronizada.

Por outro lado, existem também diversas soluções voltadas para a redução do consumode energia em RSSF. Em SAMUEL et al. (2011), os autores utilizam técnicas de clusterizaçãopara diminuir a quantidade de transmissões de dados entre os nós sensores, maior responsávelpelo consumo de energia. Para isso, é calculado o nó com maior conectividade para determinarquem será o cluster head da região lógica. Apesar de haver uma preocupação com o consumode energia, o processamento para a escolha do cluster head é feito pela própria RSSF, o quetambém gera um consumo de energia no processo de escolha.

Já em DÂMASO; ROSA; MACIEL (2014a,b) e DÂMASO et al. (2013), os autoresutilizam uma abordagem para avaliar o consumo de energia em RSSF utilizando modelos desimulação. Com o resultado, o desenvolvedor de aplicações tem predições suficientes para esco-lher o módulo que gaste menos energia para sua aplicação, ainda durante seu desenvolvimento,mas durante a execução, nenhum comportamento da aplicação pode ser alterado.

O trabalho de ANASTASI et al. (2009) mostra como é o consumo de energia em várioscomponentes de hardware diferentes em um nó sensor e discute as principais formas paraconservação de energia, apresentando também uma taxonomia abrangente dos sistemas deconservação de energia. O trabalho de SIVAGAMI et al. (2010) calcula, a partir de modelos,uma estimativa de consumo de energia para motes IRIS2. A abordagem para estimar a energiaconsumida é feita medindo o tempo gasto pelo rádio e o status do microcontrolador do mote.

No trabalho de ANDREOU et al. (2014), os autores desenvolveram um framework quemelhora a eficiência energética da RSSF, combinando componentes de balanceamento de carga,minimização de recepção de dados ineficientes e um módulo de processamento de consultas,que utiliza processamento semântico. Mesmo com um redução no consumo de energia, todas asetapas realizadas para essa economia são processadas pelos nós sensores.

Os trabalhos citados tratam diversos aspectos no que se refere ao consumo de energiae representação dos dados em RSSF. Ainda assim, existem muitos desafios para prover um

2O Datasheet do mote IRIS está disponível em http://www.memsic.com/wireless-sensor-networks/

1.4. OBJETIVOS E CONTRIBUIÇÕES 20

solução para RSSFs que trate aspectos, por exemplo, a adoção de uma metodologia de adaptaçãoda RSSF em tempo de execução para prover economia de energia e uma forma comum decompartilhamento de dados entre diferentes RSSFs.

1.4 Objetivos e Contribuições

Tendo em vista o contexto apresentado e os problemas citados, este trabalho tem comoobjetivo a utilização de ontologias como mecanismo externo das RSSFs para tomada de decisões,para que os nós sensores possam ser reconfigurados em tempo de execução, aumentando assim otempo de vida útil dos mesmos.

Sendo assim, este trabalho propõe uma solução de economia de energia para RSSF e umaforma comum de compartilhamento de dados entre aplicações e redes diferentes, baseada em umainfraestrutura semântica chamada SITRUS (acrônimo em inglês para Semantic Infrastructure

for Wireless Sensor Networks). Essa solução utiliza reconfiguração paramétrica, a partir dedados processados fora da RSSF, usando ontologias desenvolvidas com esse propósito para oprocessamento desses dados.

Dessa forma, a SITRIS promove a adaptação do software (aplicação e/ou middleware)do nó sensor em tempo de execução. Além disso, ela utiliza ontologias como uma forma desobrepor as limitações sintáticas dos dados, eliminar ambiguidades e possíveis falsos positivos enegativos nos resultados das consultas (EID; LISCANO; EL SADDIK, 2006).

A SITRUS é formada por duas partes importantes: o Middleware Ciente de Reconfigu-ração para Rede de Sensores Sem Fio (RAMSES) (acrônimo em inglês para Reconfiguration

Aware Middleware for Wireless Sensor Networks), responsável pelo transporte de dados e ge-renciamento de serviços das aplicações que são executadas nos nós sensores; e o Módulo deProcessamento Semântico da Informação (SIP) (acrônimo em inglês para Semantic Information

Processing Module), que tem por finalidade categorizar os dados para a geração da base de dadossemântica. Esta base servirá para a tomada de decisões de reconfiguração dos nós sensores epara o processamento de consultas sobre as RSSFs.

Além dos benefícios relativos à economia de energia, a infraestrutura foi projetada parafavorecer a integração de diferentes aplicações pelo compartilhamento de dados relativos a ummesmo contexto. Os benefícios desta abordagem incluem o enriquecimento dos dados pelaassociação de seu significado, e não apenas pela sintaxe dos dados, facilitando assim o seu acessoe eliminando ambiguidades.

Com os dados obtidos a partir do sensoriamento do ambiente e metadados dos nóssensores, uma base de dados semânticos é gerada. Assim, não há necessidade de consultasperiódicas na própria rede, apenas na base de dados semânticos gerada. Como consequência, háa possibilidade de economia de energia pela diminuição das consultas realizadas diretamente naRSSF.

Outra característica importante sobre a SITRUS é que ela trabalha com reconfiguração

1.5. ESTRUTURA DA TESE 21

dos nós sensores em tempo de execução, trocando parâmetros que alteram o comportamento dosmesmos. A decisão da alteração de algum parâmetro é determinada fora da RSSF, pelos dadosarmazenados na ontologia e processados pelo SIP. Por exemplo, a partir dos dados coletadospelos nós sensores de uma RSSF, percebe-se uma repetição dos dados de sensoriamento de umnó sensor particular durante um determinado período de tempo. Assim, a taxa de amostragemdeste nó sensor pode ser alterada, economizando energia do nó sensor.

A escolha por esse modelo se deve ao fato de que o processamento referente à recon-figuração da RSSF não sofre intervenção humana e nem fica a cargo da interação entre osnós sensores. O processamento é determinado pelo Módulo de Processamento Semântico daInformação (SIP) e executado pelo Middleware Ciente de Reconfiguração para Rede de SensoresSem Fio (RAMSES).

De forma sumarizada, as principais contribuições deste trabalho são:

� Uma Infraestrutura Semântica para RSSF, com uma arquitetura que trabalha comdados das RSSFs e ontologias, promovendo a comunicação entre redes diferentes;

� Um serviço de comunicação, baseado em um middleware orientado a mensagens,que realiza a comunicação interna entre os nós sensores e o gerenciamento deserviços (comunicação, agregação de dados, reconfiguração, dentre outros), de formatransparente para a aplicação;

� Um serviço de reconfiguração paramétrica para nós sensores que funciona em tempode execução, baseado em dados transmitidos pelos nós sensores e armazenados emuma base de dados semântica, fora da RSSF;

� Um módulo de processamento semântico que realiza todo o processamento dosdados das RSSFs, a fim de categorizá-los e instanciá-los de forma correta na onto-logia proposta, além de servir de base para as tomadas de decisões no processo dereconfiguração;

� Um mecanismo de consulta do estado das RSSFs realizado através de uma basede dados semântica, de forma comum entre diferentes redes e aplicações, semambiguidades e utilizando uma semântica formal; e

� Uma ontologia para RSSF, com o objetivo de mapear os principais conceitos referen-tes aos nós sensores e consumo de energia deles.

1.5 Estrutura da Tese

O restante deste trabalho está dividido em mais 7 capítulos, organizados da seguinteforma:

1.5. ESTRUTURA DA TESE 22

� O Capítulo 2 introduzirá os conceitos básicos necessários para o entendimento dessetrabalho. Com este intuito, serão apresentadas as definições, principais elementos ecaracterísticas das RSSFs, conceitos relacionados aos sistemas de middleware e suautilização em RSSF, além do sistema operacional para RSSF, o TinyOS. Finalmente,serão apresentados os principais conceitos relacionados à ontologia e Web Semântica.

� O Capítulo 3 apresenta a Infraestrutura Semântica para Rede de Sensores SemFio (SITRUS). Neste capítulo, será abordada a visão geral da infraestrutura, suaarquitetura, as principais partes que a constituem e como interagem entre si e suasfuncionalidades.

� O Capítulo 4 apresenta o Middleware Ciente de Reconfiguração para Rede de Sen-sores Sem Fio (RAMSES), um middleware orientado a mensagens que lida comas informações geradas pelas RSSFs e com os serviços disponibilizados para asaplicações. Dessa forma, serão abordados no capítulo a visão geral do middleware eem seguida sua arquitetura, com a interação entre as camadas que a compõe, bemcomo as funcionalidades inerentes de cada uma delas. Por fim, será apresentada aimplementação do middleware.

� Já no Capítulo 5 será apresentado o Módulo de Processamento Semântico da Infor-mação (SIP), parte integrante da SITRUS que lida com a ontologia. Assim, serãoabordados temas como a visão geral do módulo e sua arquitetura, com a interação en-tre todas as camadas e suas funcionalidades. Além disso, será apresentada a ontologiadesenvolvida para a SITRUS e, por fim, sua implementação.

� Como forma de demonstrar a aplicabilidade da SITRUS, será apresentado no Capítulo6 uma avaliação experimental do consumo de energia em vários cenários diferentes,com o procedimento de medição utilizado, sua implementação e os resultados obtidos.

� Já no Capítulo 7 é feita uma análise dos principais trabalhos relacionados. Osprincipais trabalhos na área de RSSF, middleware, ontologia e reconfiguração parasensores serão apresentados e avaliados com relação ao que está sendo proposto.

� Por fim, o Capítulo 8 apresenta as considerações finais desta tese, suas contribuições,limitações e possíveis melhorias a partir dos trabalhos futuros.

232323

2Conceitos Básicos

Neste capítulo serão introduzidos conceitos referentes às Redes de Sensores Sem Fio(RSSFs), Middleware, Ontologia e Web Semântica, que são os elementos básicos para a re-alização desse trabalho. Em princípio, serão discutidos conceitos relacionados à ontologia eWeb Semântica. Em seguida serão apresentados conceitos referentes às RSSFs, suas aplicações,projeto e o sistema operacional utilizado para o desenvolvimento de aplicações. Por fim, serãodiscutidos os principais conceitos referentes aos sistemas de middleware, bem como sistemas demiddleware para Rede de Sensores Sem Fio.

2.1 Ontologia e Web Semântica

Em Ciência da Computação, ontologia (um artefato da Web Semântica) é uma conceitua-lização explícita, formal e compartilhada de uma área de conhecimento (USCHOLD et al., 1996;GRUBER, 1995). Essa conceitualização refere-se a um modelo abstrato de algum fenômeno apartir de conceitos relevantes que foram identificados sobre ele (STUDER; BENJAMINS; FEN-SEL, 1998). Explícito significa que o conjunto de conceitos utilizados e as restrições aplicadassão previamente e explicitamente definidos. Formal refere-se ao fato de que se espera que umaontologia seja processável por um computador, o que exclui definições em linguagem natural,por exemplo. Finalmente, uma ontologia é compartilhada porque descreve um conhecimentoconsensual, que é utilizado por mais de um indivíduo e aceito por um grupo.

Segundo NOY; MCGUINNESS (2001), as ontologias são importantes para:

� Compartilhar entendimento comum da estrutura de informação entre pessoas eagentes de software;

� Permitir reuso de conhecimento de domínio;

� Obter compreensão explícita de domínio;

� Separar conhecimento de domínio e conhecimento operacional; e

� Analisar conhecimento de domínio.

2.1. ONTOLOGIA E WEB SEMÂNTICA 24

O compartilhamento do entendimento comum da estrutura da informação entre pessoase agentes de software é um dos mais comuns objetivos para o desenvolvimento de ontologias(GRUBER, 1995). A partir da definição de reutilização de conhecimento de domínio, é possívelque outras aplicações possam reutilizá-la. Além disso, pode-se construir uma ontologia maior apartir da integração de um conjunto de outras ontologias.

É também de fundamental importância tornar a compreensão de um domínio explícito,assim, torna-se possível uma explicação e uma melhor manutenção dos termos que compõemesse domínio. Outra característica relevante está ligada à possibilidade de realização de infe-rências sobre as informações representadas no domínio, através da forma como os conceitos,relacionamentos e as demais características do domínio foram definidas e também implementa-das.

A separação do conhecimento de domínio do conhecimento operacional implica dizerque a ontologia, que representa o conhecimento de domínio, está representada separadamenteda aplicação que utiliza essa ontologia. Dessa forma, aplicações distintas podem utilizar umamesma ontologia e assim obterem uma mesma compreensão sobre esta ontologia.

Por fim, deve ser possível a realização de uma análise do conhecimento do domínio. Essaanálise é importante para verificar se a ontologia atende às necessidades identificadas para arepresentação do conhecimento sobre um referido domínio. Além disso, é importante constatarse alterações podem ser efetuadas na sua estrutura e, com isso, aumentar a possibilidade dereutilização de ontologias já existentes.

Existem várias categorias diferentes de tipos de ontologias. ROUSSEY et al. (2011)utilizam um sistema de classificação baseado no escopo da ontologia e na granularidade dodomínio. As categorias de ontologia são as seguintes:

� Ontologias de Domínio: Tratam de um domínio mais específico de uma área gené-rica de conhecimento;

� Ontologias Locais/Aplicação: Ontologias locais ou de aplicação procuram solucio-nar um problema específico de um domínio e são especializações de ontologias dedomínio, onde não poderia haver consenso ou a partilha de conhecimentos;

� Ontologias Centrais: Definem os ramos de estudo de uma área e/ou conceitos maisgenéricos e abstratos dessa área;

� Ontologias Gerais (ou de Topo): Trazem definições abstratas necessárias para acompreensão de aspectos do mundo, como tempo, processos, papéis, espaço, seres,coisas, dentre outros; e

� Ontologias de Representação: Definem as primitivas de representação, como fra-mes, axiomas, atributos e outros, de forma declarativa.


O conhecimento de um domínio em uma ontologia é formalizado a partir da utilizaçãode quatro tipos de componentes (USCHOLD et al., 1996):

� Classes: Representam um conjunto ou tipo de objetos, conceitos ou categoria deconceitos, normalmente organizadas em taxonomias;

� Instâncias: Materialização dos objetos do domínio;

� Propriedades: Representam as características das classes e instâncias, estabelecendorelacionamento entre as classes; e

� Restrições: Restringem os relacionamentos, que são interligações entre os conceitosde um domínio;

As ontologias são comumente ilustradas como grafos, em que os vértices representamas classes e instâncias, e as arestas representam os relacionamentos entre esses vértices. Asontologias podem ser representadas de forma textual, a partir do uso de linguagens como:Resource Description Framework (RDF) (LASSILA, 2004), Resource Description Framework

Schema (RDFS) (LASSILA, 2004) e Web Ontology Language (OWL) (MCGUINNESS; HAR-MELEN, 2004). Essas linguagens textuais para especificação de ontologias são expressas emeXtensible Markup Language (XML).

2.1.1 A Linguagem OWL

OWL é uma linguagem textual para instanciar e definir ontologias. Ela representaexplicitamente os significados dos termos de um vocabulário, bem como o relacionamento dessestermos. Essa capacidade de representação de expressões e suas relações é o que definem OWLcomo uma linguagem ontológica (MCGUINNESS; HARMELEN, 2004).

A Web Semântica (BERNERS-LEE; HENDLER; LASSILA, 2001) busca adicionarsignificado aos dados publicados na Web, para que, a partir disso, os computadores possamefetuar processamento sobre esses dados, extraindo assim resultados semânticos deles. O objetivoprincipal da Web Semântica não é treinar as máquinas para que se comportem como pessoas,mas sim desenvolver tecnologias e linguagens que tornem a informação legível para as máquinas.

A finalidade da Web Semântica passa pelo desenvolvimento de um modelo tecnológicoque permita o compartilhamento global de conhecimento assistido por máquinas. A integra-ção das linguagens ou tecnologias XML, RDF, arquiteturas de metadados, ontologias, agentescomputacionais, entre outras, favorece o aparecimento de serviços Web que garantam a interope-rabilidade e cooperação.

A Figura 2.1 apresenta a hierarquia de linguagens da Web Semântica que formam suaarquitetura, onde cada camada explora e utiliza recursos das camadas inferiores. Ela mostracomo as tecnologias que são padronizadas para a Web Semântica estão organizados para fazê-la


possível. Ela também mostra que Web Semântica é uma extensão, e não a substituição da Webclássica baseada em hipertexto.

User interface and applications

Trust

Proof

Cry

pto

gra

phy

Unifying Logic

Querying:

SPARQL

Ontologies:OWL

Rules:RIF/SWRL

Taxonomies:RDFS

Data interchange:RDF

Syntax:XML

Identifiers: URI Character Set:UNICODE

Figura 2.1: Arquitetura da Web Semântica (BERNERS-LEE, 2000)

A linguagem OWL é baseada na sintaxe da linguagem RDF (LASSILA, 2004), ummodelo de representação de dados recomendado pelo World Wide Web Consortion (W3C) queutiliza metadados para possibilitar a descrição de recursos (imagens, informações pessoais, redessociais, entre outros) e com isso, proporcionar uma semântica aos recursos descritos. Além deRDF, OWL também é baseada na linguagem DAML + OIL (CONNOLLY et al., 2001).

Atualmente, a linguagem OWL possui 3 sub-linguagens, que diferem pela suas expressi-vidades:

� OWL Lite: Suporta a criação de hierarquias simplificadas e suas restrições, i.e., asque não possuem axiomas nem estruturas de relacionamento sofisticadas. Sendoassim, ela suporta restrições mais simples, por exemplo, cardinalidade.

� OWL DL: Foi projetada para se obter a máxima expressividade possível enquantomantém a completude computacional (para todas as computações se garante tempofinito), decidibilidade (há um procedimento eficaz para determinar se uma computa-ção é derivável ou não) e da disponibilidade de algoritmos de raciocínio. A OWL DLinclui todas as construções de linguagem OWL, mas elas podem ser usadas somentesob certas restrições (por exemplo, restrições numéricas não podem ser colocadas empropriedades transitivas). OWL DL é assim chamada devido a sua correspondênciacom as lógicas de descrição, base formal da OWL.


� OWL Full: Foi projetada para ter máxima expressividade e liberdade sintática doRDF sem nenhuma garantia computacional. É baseada em uma semântica diferente daOWL Lite ou OWL DL e projetada para preservar alguma compatibilidade com o RSFSchema. Por exemplo, em OWL FULL uma classe pode ser tratada simultaneamentecomo uma coleção de indivíduos e como um indivíduo em si mesmo. Ela permiteque uma ontologia aumente o vocabulário pré-definido de RDF ou OWL. OWLFULL é indecidível, de modo que nenhum raciocinador é capaz de executar de formacompleta para ele.

2.1.2 Estrutura de uma Ontologia OWL

Um documento OWL consiste em declarações de namespaces, um cabeçalho opcionalque se refere à ontologia e definições de classes, propriedades e indivíduos. Os namespaces sãoimportantes para fazer referência aos termos definidos em diferentes ontologias, além de ser ummeio de acesso aos elementos da ontologia que estiver sendo definida. O uso de namespaces

evita colisões de nomes comuns em vocabulários distintos.A Figura 2.2 é um exemplo de namespace de uma ontologia que define uma pizza,

encontrada como exemplo na documentação da ferramenta Protégé (NOY; MCGUINNESS,2001). A linha 10 identifica o namespace associado à ontologia que está sendo definida. Nalinha 6 é atribuída à variável rdf a url http://www.w3.org/1999/02/22-rdf-syntax-ns, que contém adefinição de uma ontologia já existente, e dessa forma, os elementos definidos dessa ontologiapodem ser referenciados no desenvolvimento de uma nova ontologia, a partir do uso dessavariável. O mesmo com as variáveis rdfs e owl, definidas respectivamente nas linhas 8 e 9.

1 <rdf:RDF2 xmlns:xsp="http://www.owl-ontologies.com/2005/08/07/xsp.owl#"3 xmlns:swrlb="http://www.w3.org/2003/11/swrlb#"4 xmlns:swrl="http://www.w3.org/2003/11/swrl#"5 xmlns:protege="http://protege.stanford.edu/plugins/owl/protege#"6 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"7 xmlns:xsd="http://www.w3.org/2001/XMLSchema#"8 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"9 xmlns:owl="http://www.w3.org/2002/07/owl#"

10 xmlns="http://www.co-ode.org/ontologies/2005/10/18/pizza.owl#"11 xmlns:daml="http://www.daml.org/2001/03/daml+oil#"

Figura 2.2: Namespace de uma Ontologia para Pizza

Em um documento OWL, classe é um conceito base para a definição de uma ontologia.Considerando a ontologia uma representação taxonômica, as classes representam a raiz dataxonomia. Por padrão, todas as definições em uma ontologia são membros da classe owl:Thing,que é a classe raiz. Sendo assim, toda classe definida em uma ontologia é subclasse de owl:Thing.


A Figura 2.3 apresenta um exemplo de representação de classes com parte de sua hierarquia.

Country Spiciness

Mild

IceCream PizzaTopping

owl:Thing

Hot

Pizza

DeepPanBase

PizzaBase

DomainConcept

ThinAndCrispyBase Medium

ValuePartition

Figura 2.3: Classes da Ontologia para Pizza com a classe owl:Thing

As classes de uma ontologia são declaradas através de uma simples nomeação nodocumento OWL. A Figura 2.4 mostra um exemplo de como essas declarações podem ser feitas.

Conforme representado na Figura 2.4, as classes em um documento OWL podem serdefinidas a partir do elemento owl:Class (Linhas 1 e 3) e seus nomes são identificados peloatributo rdf:ID. Assim, a classe Pizza, que é subclasse de DomainConcept, uma vez definida,pode ser utilizada no documento OWL que a define ou em qualquer outro documento externo,desde que haja referência ao namespace onde a classe está definida.

1 <owl:Class rdf:ID="Pizza">2 <rdfs:subClassOf>3 <owl:Class rdf:ID="DomainConcept"/>4 </rdfs:subClassOf>

Figura 2.4: Declaração de Classes em OWL

Em OWL, propriedades são relações binárias que podem ser usadas para estabelecerrelacionamentos entre indivíduos ou entre indivíduos e valores de dados. Estes relacionamentospermitem afirmar fatos gerais sobre os membros das classes e podem também especificar fatossobre indivíduos (MCGUINNESS; HARMELEN, 2004).

A OWL distigue entre duas categorias principais de propriedades:

� Propriedades de dados tipados (datatype properties): Relação entre indivíduos evalores de dados.

� Propriedades de objetos (object properties): Relação entre indivíduos.

Uma propriedade de objeto é definida como instância da classe owl:ObjectProperty.Uma propriedade de dado tipado é definida como uma instância da classe owl:DatatypeProperty.


Além disso, ambas são subclasses da classe RDF rdf:Property. O domínio e sua imagem sãodefinidos respectivamente pelos elementos rdfs:domain e rdfs:range, como apresentado pelaFigura 2.5.

1 <owl:ObjectProperty rdf:ID="isToppingOf">2 <owl:inverseOf>3 <owl:ObjectProperty rdf:about="#hasTopping"/>4 </owl:inverseOf>5 <rdfs:subPropertyOf>6 <owl:ObjectProperty rdf:ID="isIngredientOf"/>7 </rdfs:subPropertyOf>8 <rdfs:domain rdf:resource="#PizzaTopping"/>9 <rdfs:range rdf:resource="#Pizza"/>

10 </owl:ObjectProperty>

Figura 2.5: Declaração de Propriedades em OWL

O uso do elemento owl:ObjectProperty na Linha 1 define a propriedade isToppingOf,com uma imagem da classe Pizza, e a relaciona com a classe PizzaTopping, que é o domínio.A definição da imagem é realizada a partir do elemento rdfs:range (Linha 9), enquanto que orelacionamento da propriedade isToppingOf com a classe PizzaTopping é realizada a partir doelemento rdfs:domain (Linha 8).

Os indivíduos de uma ontologia são também conhecidos como instâncias. Os indivíduospodem ser referenciados como instâncias de classes. Eles representam objetos no domínio deinteresse. Isto significa que nomes diferentes podem remeter ao mesmo indivíduo. Por exemplo,pizza sem carne e pizza vegetariana podem ser referências ao mesmo indivíduo da classe Pizza.Em OWL, deve-se declarar explicitamente que os indivíduos são os mesmos, ou diferentes unsdos outros, a partir de propriedades de equivalência ou disjunção.

2.1.3 Linguagem de Consulta SPARQL

A linguagem de consultas SPARQL (HUANG; ABADI; REN, 2011; PÉREZ; ARENAS;GUTIERREZ, 2009)(SPARQL Protocol and RDF Query Language (SPARQL)) proporcionaacesso aos dados representados em documentos baseados em RDF. Essa linguagem é baseada emtriplas RDF (recurso, propriedade, valor) e lembra muito uma consulta SQL para banco de dados.A Figura 2.6 mostra um exemplo de uma consulta simples em linguagem SPARQL, utilizando aontologia da Pizza.

A consulta retorna o valor de todas as instâncias de pizzas com suas respectivas coberturas,a partir da propriedade hasTopping, ou seja, a partir do relacionamento existente entre a classePizza e a classe PizzaTopping. A consulta está dividida em duas partes: a cláusula SELECT, queidentifica as variáveis que aparecerão no resultado da consulta, e a cláusula WHERE, onde sãorealizadas as restrições para a execução da consulta.

2.2. REDE DE SENSORES SEM FIO 30

1 SELECT ?subject ?object2 WHERE {3 ?subject or:hasTopping ?object4 }

Figura 2.6: Consulta Simples em SPARQL

SPARQL permite a realização de consultas mais complexas, a partir do uso de operadoreslógicos, relacionais e expressões regulares, por exemplo.

2.2 Rede de Sensores Sem Fio

As Redes de Sensores Sem Fio (RSSFs) têm sido alvo de diversas pesquisas nos últimosanos, principalmente devido às inovações tecnológicas introduzidas pelo avanço em microeletrô-nica, mecânica, comunicação sem fio e eletrônica digital. Este tipo de rede é formada geralmentepor centenas ou milhares de dispositivos autônomos que tendem a ser projetados com pequenasdimensões chamados nós sensores (AKYILDIZ et al., 2002b).

As RSSFs são normalmente formada por milhares de pequenos nós e contêm sériasrestrições se comparadas aos modelos de redes tradicionais, como por exemplo, capacidadecomputacional reduzida, pouca memória disponível, comunicação de curto alcance, possibilidadereduzida de intervenção humana e bateria geralmente não recarregável e com pouca capacidade.Individualmente, possuem pouca capacidade computacional e de energia, mas um esforçocolaborativo entre os mesmos permite a realização de grandes tarefas (RUIZ et al., 2004).

Nós sensores podem ser lançados sobre áreas remotas e hostis e, sem intervenção humana,formar uma rede sem fio ad-hoc que coleta dados sobre os fenômenos de interesse. Eles realizamprocessamento local e disseminam as informações para um ponto de acesso em um esquema decomunicação de múltiplos saltos (multi-hop) ou um salto (one-hop), podendo cooperar e permitira distribuição de tarefas e o transporte de dados de uma forma eficiente quanto ao consumo deenergia.

O ponto de acesso é o elemento através do qual a rede se comunica com outras redes,com outros pontos de acesso ou outros observadores. Ele pode ser implementado em um nósensor, que será chamado de nó sorvedouro (sink node), estação base (base station) ou gateway.

Os nós sensores são distribuídos geralmente em um campo de sensoriamento, onde elesse comunicam entre si, trocam informações e disseminam seus dados, como mostra a Figura 2.7.Nesta figura é possível observar a existência de um nó sensor que funciona como gateway entrea RSSF e a rede cabeada.

Redes de sensores podem possuir vários tipos de sensoriamento, tais como: temperatura,pressão, umidade, luminosidade, níveis de ruído, presença e ausência de objetos, dentre outros.Tais sensores podem ser usados para sensoriamento contínuo ou apenas detecção de um evento,


Figura 2.7: Ambiente Monitorado por uma Rede de Sensor Sem Fio

além da possibilidade de acionarem atuadores locais. Todas estas características permitem o usode RSSF em um amplo espectro de aplicações (ARAMPATZIS; LYGEROS; MANESIS, 2005;AKYILDIZ et al., 2002a), tais como aplicações militares, ambientais, médicas, domésticas,monitoramento de fadiga de materiais, gerência de inventários, monitoramento da qualidade deprodutos, brinquedos interativos, estruturas inteligentes com sensores embutidos, instrumentaçãoem fábricas, monitoramento de tráfego de animais, suporte à logística, dentre outros.

2.2.1 Desafios no Desenvolvimento de Aplicações para RSSF

Dentre os grandes desafios das RSSFs, podemos citar o fato de que elas têm que superaras diferenças entre as tecnologias de hardware, as restrições de consumo de energia e, aomesmo tempo, atender a um amplo domínio de aplicações (AKYILDIZ et al., 2002b). Outracaracterística importante das RSSFs é que elas devem ser escaláveis, permitindo que novos nóssejam incorporados à rede. Além disso, em uma RSSF, as posições de cada nó não precisamser pré-determinadas ou pré-calculadas. Assim, a posição do sensor é algo aleatório e deve sertratada pelos protocolos de comunicação e gerenciamento da rede.

O desenvolvimento de aplicações para uma RSSF envolve uma série de fatores a seremconsiderados, dentre eles:

Restrições de Hardware: Um nó sensor é composto de quatro componentes básicos:uma unidade de sensoriamento, uma unidade de processamento, uma unidade de transmissão/-recepção e uma unidade de energia. Ele pode também possuir, dependendo da aplicação, umaunidade de localização, uma unidade de geração de energia e uma unidade de movimentação,sendo que algumas dessas unidades podem conter ainda subunidades, e geralmente todas essas


unidades devem ter tamanhos diminutos.Além do tamanho, há algumas outras restrições para os nós. Esses nós devem possuir

consumo de energia extremamente baixo, ter baixo custo de produção, ser autônomo e adaptativoao ambiente.

Consumo de Energia: Economia de energia constitui parte fundamental no projeto deuma RSSF, devido à escassez de recursos de bateria, que na maioria dos tipos de sensores sãoinsubstituíveis. Inúmeras pesquisas (SHA; HACKMANN; LU, 2013; ANASTASI et al., 2009;PANTAZIS; VERGADOS, 2007; SHI, 2007; RHEE; SEETHARAM; LIU, 2004) têm sido feitaspara melhorar os algoritmos responsáveis pela transmissão e encaminhamento de dados na rede,além da criação de novos tipos de transmissores, mais eficientes quanto à utilização de energia.

Tolerância à Falha: Em uma RSSF falhas são possíveis e aceitáveis e a rede deve saberlidar com elas de maneira automática e natural. Sensores podem falhar por diversos motivoscomo falta de energia, falta de visibilidade para outro nó da rede ou até mesmo algum danofísico. Como eles são dispostos em grandes quantidades no campo a ser sensoreado, a falha dealguns poucos não deve atrapalhar o funcionamento do resto da rede.

Escalabilidade: A ordem de grandeza do número de nós de uma RSSF pode variardas centenas aos milhares. Em algumas aplicações específicas podendo até atingir a casa dosmilhões. Os novos esquemas devem ser capazes não somente de lidar com este número de nós,mas também de utilizá-los em todo o seu potencial. Isto também tem a ver com a densidade comque os sensores estão espalhados na região a ser sensoreada. Esta densidade pode variar muito eos mecanismos de transmissão devem ser capazes de lidar com esta variação e utilizá-la a seufavor.

Topologia de Rede: Com um número tão alto de nós que devem funcionar sem interven-ção e sujeitos a falhas frequentes, a manutenção da topologia da rede é algo fundamental para oseu funcionamento. A manutenção da rede pode ser dividida em três fases: a fase de implantaçãodos nós (maneira como os nós serão dispostos em sua área de cobertura), pós implantação (ondemanutenção na topologia pode acontecer devido à mudança na posição dos nós, alcance, energiadisponível, mau funcionamento, detalhes da tarefa a ser desempenhada pela rede) e a fase deimplantação de novos nós (em que nós adicionais podem ser dispostos a qualquer momento parareposição de nós com problemas, seja por destruição ou por falta de energia, mudando assim atopologia da rede).

Meio de Transmissão: A comunicação entre os nós é tipicamente realizada por rádiofrequência. Isto cria liberdade na implementação ao mesmo tempo em que cria um problemano funcionamento dos nós, devido à possíveis interferências provocadas por outros aparelhosque utilizem a mesma faixa de frequência. Outras opções de comunicação em RSSF incluem autilização de infravermelho e a comunicação óptica.


2.2.2 TinyOS e nesC

Sistemas operacionais para sensores são projetados de forma a economizar o máximode energia possível. Além disso, eles devem ser eficientes em termos de consumo de memóriae processamento e ágil o suficiente para permitir que várias aplicações usem simultaneamenteos recursos de comunicação. Dessa forma, será apresentado nessa seção o Tiny Microthreading

Operating System (TinyOS) (LEVIS et al., 2005), um sistema operacional open source bastanteutilizado e projetado para RSSF, e implementado na linguagem de programação nesC (GAYet al., 2003).

O TinyOS é um sistema operacional que respeita rigorosamente as características debaixa capacidade computacional e de armazenamento dos nós sensores. Ele foi desenvolvidopara oferecer um gerenciamento de hardware de diversos fabricantes e fornecer uma abstraçãode algumas partes do hardware para as aplicações.

O sistema operacional provê interfaces e componentes para hardware com atividades emcomum, tais como pacotes de comunicação, ativação, sensoriamento e armazenamento. Issofacilita o desenvolvimento de aplicativos, visto que não é necessário desenvolver algoritmosdiferentes para equipamentos distintos.

A linguagem de implementação do TinyOS, o nesC (GAY et al., 2003), foi desenvol-vida tendo como desafios prioritários a robustez, pouca disponibilidade de recursos, diversasimplementações do mesmo serviço, evolução do hardware e adaptabilidade aos requisitos deaplicações. A principal característica do nesC é a visão holística do sistema. As aplicações dosnós sensores são bastante dependentes do hardware, e cada nó executa apenas uma aplicação porvez.

NesC é uma linguagem orientada a componentes com um modelo de execução baseadoem eventos. Os componentes nesC possuem uma certa similaridade com os objetos de umalinguagem orientadas a objetos no sentido em que ambos encapsulam estado e interagem entresi através de interfaces bem definidas. Contudo, há algumas diferenças bastante significativas.NesC não possui certas características tais como herança, alocação dinâmica e ligação dinâmica(Dynamic dispatch). Isto se deve basicamente ao fato de que o conjunto de componentes e suasinterações são determinados em tempo de compilação ao invés de tempo de execução, evitandocom isso o desperdício de recursos alocados e não usados ou mesmo falhas que porventuravenham a ocorrer em tempo de execução. Dessa forma, nesC tenta compilar tantas decisõesquanto for possível.

Uma grande vantagem desse modelo orientado a componentes é o fato do desenvolvedorpoder construir a aplicação utilizando um conjunto de componentes existentes e adicionandocódigo extra, quando necessário, à execução da aplicação. Assim, ao invés de ser um SO depropósito geral, TinyOS comporta-se como um framework que permite a construção de um novoTinyOS específico, evitando o uso de componentes que não são necessários para a execução daaplicação.


Outra característica bastante interessante no nesC é o suporte a modelos de concorrênciado TinyOS, realizando otimização e detecção de concorrência de dados em tempo de compilação.Trata-se do modelo simplificado de concorrência, o qual permite concorrência com baixasobrecarga, ao contrário do modelo de concorrência baseado em thread, em que a pilha dethreads requer grande consumo de memória. Entretanto, como qualquer sistema concorrente,condições de corrida (race conditions), starvation, deadlock, e não-determinismo são fontespossíveis de bugs. Tentando evitar esses problemas de concorrência, o TinyOS tenta identificare assegurar a ausência das condições de corrida em tempo de compilação. Além da detecçãode condição de corrida, o compilador realiza ainda a criação de componentes estaticamente eeliminação de código morto.

Um programa TinyOS é um grafo de componentes, onde cada componente é uma entidadecomputacional independente que encapsula serviços definidos por uma ou mais interfaces (LEVISet al., 2003). Componentes têm três abstrações computacionais: comandos, eventos e tarefas.Comandos e eventos são mecanismos que permitem a comunicação entre componentes, enquantotarefas são usadas para expressar concorrência em um componente.

Um comando é tipicamente um pedido para um componente executar algum serviço,tal como a inicialização de leitura de um sensor, enquanto que eventos sinalizam o términodo serviço. Eventos podem também ser sinalizados assincronamente, por exemplo, devido àinterrupções de hardware ou pela chegada de mensagens. Comandos e eventos não podemser bloqueantes. A execução de um serviço, isto é, a requisição de um serviço (comando) e asinalização de conclusão (evento correspondente) são desacopladas. Em uma operação comoessa, o comando retorna imediatamente e a conclusão será sinalizada com um evento.

Além disso, comandos e eventos podem adiar a computação de um serviço com o usode tarefa. Isto permite que o controle seja retornado imediatamente para comandos e eventos,enquanto que concedem uma extensiva computação para tarefas.

O modelo de programação do TinyOS provido pelo nesC centraliza a noção de compo-nentes que encapsulam um conjunto específico de serviços, especificado por interfaces. Umaaplicação é construída conectando componentes independente da implementação dos mesmos.Essa especificação de conexão de componentes define o conjunto completo de componentes quea aplicação usa.

Um componente tem dois tipos de interfaces: aquela que ele provê e a que ele usa. Estasinterfaces definem como o componente interage diretamente com outros componentes. Umainterface geralmente modela algum serviço (e.g, envio de mensagem) e é definida por um tipo.A separação da definição do tipo da interface do seu uso em componentes promove a definiçãode interfaces padrões, fazendo componentes mais reusáveis e flexíveis.

Interfaces são bidirecionais e contém comandos e eventos. Elas definem um conjunto defunções a serem implementadas pelo provedor da interface (comandos) e também pelo usuáriodessas interfaces (eventos), o que permite que uma simples interface represente uma complexainteração entre componentes.

2.3. MIDDLEWARE 35

A linguagem nesC suporta dois tipos de componentes: módulos e configurações. Módu-los proveem o código da aplicação, implementando uma ou mais interfaces. Por outro lado, aconfiguração é usada para unir os componentes, conectando interfaces usadas pelos componentescom interfaces providas por outros. Cada aplicação é descrita por uma configuração num nívelmais abstrato que une todos os componentes usados.

2.3 Middleware

Os principais fatores que contribuíram para que as organizações levassem a ter umagrande variedade de aplicações com heterogeneidade de hardware, sistemas operacionais e delinguagens de programação foram o desenvolvimento acelerado nas tecnologias de hardware,software, telecomunicações e as facilidades encontradas no uso de sistemas corporativos. Issosignifica que esses sistemas legados adquiridos ao longo dos anos devem trabalhar em conjuntocom outros novos sistemas (VINOSKI, 2002). Como resultado, a integração dessas aplicaçõestorna-se uma tarefa não trivial e complexa. Visando resolver esses problemas, foram desenvol-vidos serviços distribuídos tais como comunicação, segurança, gerenciamento de informações,dentre outros, que possuem protocolos e interfaces de programação padrões. Esses serviços sãochamados serviços de middleware (BERNSTEIN, 1996).

Os componentes de middleware, localizados entre o sistema operacional e a aplicação,têm várias propriedades que, em conjunto, geralmente deixam claro que o componente não éum aplicativo ou serviço específico da plataforma. Eles são genéricos através de aplicações,são executados em múltiplas plataformas, são distribuídos, possuem protocolos e interfaces deprogramação padrões e abstraem a complexidade e heterogeneidade dos ambientes (VINOSKI,2002; BERNSTEIN, 1993).

O middleware deve prover primitivas de alto nível que simplifiquem a construção deaplicações distribuídas. Ele implementa as camadas de sessão e apresentação do Modelo deReferência ISO/OSI, e assim como a pilha de protocolo de redes, ele pode ser decomposto emmúltiplas camadas (SCHMIDT; BUSCHMANN, 2003), como apresentado na Figura 2.8:

� Camada de Infraestrutura - Esta camada abstrai as peculiaridades dos sistemasoperacionais, facilitando o desenvolvimento de aplicações em rede. Além disso,encapsula e melhora os mecanismos nativos dos sistemas operacionais;

� Camada de Distribuição - Permite o desenvolvimento e integração de aplicaçõesremotas de forma transparente, abstraindo de sua localização, linguagens de pro-gramação, sistema operacional, protocolos de comunicação e também o hardwareutilizado. Ela define modelos de programação de alto nível cujo reuso de APIs e obje-tos otimizam e estendem os mecanismos nativos do sistema operacional encapsuladospela camada de infraestrutura;

2.3. MIDDLEWARE 36

Figura 2.8: Visão Geral do Middleware

� Camada de Serviços - A camada de serviços pode ser dividida em Serviços Co-

muns e Serviços Específicos. Os Serviços Comuns definem serviços reusáveis dealto nível e independentes do domínio da aplicação. Esses serviços permitem aosdesenvolvedores de aplicações focarem apenas na lógica do negócio. Serviços Co-

muns de middleware fornecem, por exemplo, serviços de transação, segurança, pool

de conexão com banco de dados e reuso de componentes com múltiplas threads.Serviços Específicos usados em determinados domínios de aplicações, como porexemplo, telecomunicações, comércio eletrônico, computação móvel, etc. Visto queos serviços oferecidos por essa camada incorporam conhecimento de um domínio,eles possibilitam incrementar a qualidade e reduzir o esforço necessários para odesenvolvimento de particulares tipos de aplicações.

Como mencionado anteriormente, o middleware é uma camada de software entre aaplicação e o sistema operacional que oferece serviços e abstrai a complexidade da distribuição.Seus serviços devem atender a uma grande variedade de aplicações, ser implementados de formaa possibilitar a execução em múltiplas plataformas, possibilitar o acesso remoto a outros serviçose aplicações, suportar um protocolo padrão, por exemplo, TCP, suportar uma API padrão, dentreoutros.

2.3.1 Requisitos para o Desenvolvimento de um Middleware

Devido à natureza das aplicações distribuídas, um sistema de middleware deve abstrairdos desenvolvedores de aplicações detalhes de baixo nível, tais como: comunicação, controlede concorrência, gerenciamento de transações, dentre outros. O suporte a estes requisitos variade um middleware para outro de acordo com a sua complexidade e abrangência (EMMERICH,2000).

2.3. MIDDLEWARE 37

� Comunicação em Rede: Diversos componentes de um sistema distribuído podemresidir em diferentes hosts. Para que um sistema distribuído apresente vantagenscomputacionais, esses componentes devem se comunicar uns com os outros. Estacomunicação apenas pode ser conseguida através da utilização de protocolos de rede.Sistemas distribuídos são geralmente construídos em cima de camadas mais baixasprovidas pelos sistemas operacionais, como a camada de transporte, por exemplo.

Se a comunicação entre sistemas distribuídos é realizada neste nível de abstração,os desenvolvedores de aplicação precisam implementar a camada de sessão e apre-sentação da pilha de protocolos da rede. Entretanto, essa tarefa requer tempo epode promover o aparecimento de erros. Ao invés disso, os desenvolvedores deaplicação deveriam ser capazes de solicitar serviços parametrizados dos componentesremotos de modo a executá-los como transações atômicas e isoladas, deixando aimplementação das camadas de sessão e apresentação para o middleware.

Assim, os sistemas de middleware normalmente usam a camada de transporte paraimplementar a troca de dados via rede. Cabe aos sistemas de middleware proveremcomplexos mecanismos de conversão de estruturas de dados de alto nível, recebidasdos aplicativos, em bytes a serem enviados através da rede para um outro aplicativo.

� Coordenação: Os sistemas distribuídos têm múltiplos pontos de controle, em virtudedos componentes residirem em diferentes hosts. Componentes localizados no mesmohost executam tarefas concorrentemente, levando à necessidade de sincronizaçãoquando esses componentes comunicam-se uns com os outros. Essa sincronizaçãoprecisa ser implementada na camada de sessão pelo middleware.

O middleware deve prover aos desenvolvedores de aplicações mecanismos básicospara dar suporte aos vários tipos de sincronização entre componentes remotos. Alémdisso, mais de um componente pode estar envolvido em uma requisição. Isto fre-quentemente acontece quando vários componentes estão interessados em eventos queocorrem em algum outro componente.

Adicionalmente, o middleware deve fornecer mecanismos que permitam aos pro-gramadores determinar políticas de ativação e desativação de componentes comoforma de gerenciar os recursos dos hosts, gerenciar o armazenamento do estadodos componentes anterior a sua desativação e, posteriormente, restaurar esse estadodurante sua ativação.

Dado que componentes executam concorrentemente em hosts distribuídos, um com-ponente servidor pode ser requisitado por diferentes componentes clientes ao mesmotempo. Dessa forma, o middleware deve suportar diferentes mecanismos para definircomo os componentes devem reagir a tais requisições concorrentes.

� Confiabilidade: Os protocolos de rede possuem vários níveis de confiabilidade.

2.3. MIDDLEWARE 38

Entretanto, não necessariamente existe a garantia de que todo pacote transmitidoé entregue ao receptor e nem mesmo a ordem em que são enviados é preservada.Dessa forma, a implementação de um sistema distribuído deve prever mecanismospara detecção e correção de erros, mesmo que isso cause uma perda de desempenho.Logo, diferentes níveis de serviços de confiabilidade são necessários para permitiruma negociação entre esses requisitos.

� Escalabilidade: Este requisito define a capacidade de uma solução se adaptar aum aumento de carga de forma uniforme ou estar preparado para um crescimentofuturo de carga, sem causar grandes impactos na solução. O desafio da escalabilidadequando se trata da construção de um sistema distribuído é oferecer suporte à alocaçãode componentes sem alterações na arquitetura do sistema ou no projeto e código dealgum componente.

� Heterogeneidade - Um sistema distribuído pode ser constituído de componenteslegados e novos, implementados em diferentes tecnologias. Como resultado, essescomponentes são geralmente heterogêneos. Esta heterogeneidade existe em diferen-tes dimensões: hardware, sistemas operacionais, linguagens de programação e nomiddleware em si.

2.3.2 Middleware para Rede de Sensores Sem Fio

Apesar das pesquisas em middleware estarem bem estabelecidas em sistemas de compu-tação distribuída, as RSSFs adicionaram novos desafios de pesquisa para a área. Os sistemas demiddleware tradicionais requerem muita memória e grande poder de processamento do hardware,o que os torna inadequados para o uso em RSSF (GUIMARAES et al., 2006; SOUTO et al.,2004). Portanto, uma solução de middleware para RSSF deve considerar características própriasa essa nova classe de aplicações, a fim de prolongar o tempo de vida dessas redes. Dessaforma, um projeto de middleware para RSSF tem como desafios os seguintes itens (HADIM;MOHAMED, 2006b,a):

� Gerenciamento de energia e recursos limitados: Uma RSSF consiste de um con-junto de nós com pouca memória, reduzido poder computacional e severas restriçõesde energia, normalmente instalados em lugares de difícil acesso, o que inviabilizaa substituição ou manutenção dos dispositivos. Então, o middleware deve provermecanismos para o uso eficiente da memória e bateria e ao mesmo tempo baixoconsumo de energia durante a comunicação.

� Heterogeneidade: O middleware deve prover um modelo de programação de baixonível que permita a integração entre diferentes tecnologias de hardware e redes,aplicações escritas em diversas linguagens de programação e sistemas operacionais.

2.4. CONSIDERAÇÕES FINAIS 39

� Escalabilidade, topologia dinâmica da rede e mobilidade: A topologia das RSSFsé sujeita à frequentes mudanças devido a diversos fatores, tais como mau funciona-mento, falhas, mobilidade devido a mudanças físicas dos sensores ou de algoritmosde distribuição. Além disso, a rede deve ser flexível o suficiente para permitir a adiçãode novos nós garantindo um nível aceitável de desempenho. Um middleware deveprover ainda tolerância a falhas e auto-gerenciamento dos nós (MOLLA; AHAMED,2006; RUIZ et al., 2004; AKYILDIZ et al., 2002a).

� Agregação de dados: O serviço de agregação de dados possibilita economia deenergia e recursos, pois os dados capturados e agregados, provenientes de diferentesregiões da RSSF ou padronizados para um formato de mais alto nível, permitem aeliminação de redundância de dados e minimiza o número de transmissões para aestação base.

Alguns mecanismos utilizados no desenvolvimento de middleware para RSSF podemauxiliar na diminuição no consumo de energia. Entre esses mecanismos, além da agregaçãode dados citada anteriormente, podem ser: a formação regiões lógicas na rede, onde apenas orepresentante desta região (cluster header) se comunica com os demais nós sensores da rede;a utilização de protocolos de roteamento multi-saltos; a diminuição do número de mensagenstransmitida na RSSF; e a comunicação assíncrona entre os componentes remotos, dentro outros.

2.4 Considerações Finais

Este capítulo introduziu um resumo dos conceitos que fundamentam o desenvolvimentodo presente trabalho. Neste sentido, a seção inicial descreveu os principais conceitos relativo aontologia e Web Semântica. Em seguida, foi discutida a linguagem OWL para definir, manipulare instanciar ontologias, além de apresentar a estrutura de uma ontologia OWL. Por fim, foidescrita a linguagem de consulta que proporciona acesso aos dados representados em documentosbaseados em RDF, o SPARQL.

404040

3SITRUS: Infraestrutura Semântica para Redede Sensores Sem Fio

Este capítulo apresenta a SITRUS (acrônimo em inglês para Semantic Infrastructure for

Wireless Sensor Networks) (BISPO; ROSA; CUNHA, 2012), uma infraestrutura desenvolvidapara Rede de Sensores Sem Fio que tem como metas o compartilhamento de informações deforma mais fácil, inclusive entre redes diferentes, e o auxílio na redução do consumo de energiados nós sensores. Além disso, ela trabalha de forma a diminuir o processamento dos nós sensorese eliminar ambiguidades das mensagens que foram transmitidas.

As próximas seções discutem o funcionamento da SITRUS, dando inicialmente umavisão geral de todo o processo envolvido. Em seguida, serão apresentados seus cenários de uso.Depois, será descrita sua arquitetura, como suas partes se comunicam e suas funcionalidades.Em seguida, serão descritas algumas soluções envolvendo a SITRUS. Por fim, serão apresentadasas considerações finais da SITRUS.

3.1 Visão Geral

Como discutido anteriormente na Seção 2.2, as RSSFs são redes que têm recursoslimitados e a energia consumida por um nó sensor é uma preocupação constante. Levandoem consideração que intervenções humanas para troca de baterias são cenários incomuns, adepender do tipo de aplicação ou dos algoritmos utilizados, alguns nós sensores podem ficarsobrecarregados e ter sua energia consumida com mais facilidade, e no pior caso, deixandoalgumas áreas da RSSF sem conectividade. Uma boa prática seria deixar a rede ser auto-gerenciada com mecanismos de economia de energia, a fim de evitar que nós sensores sejamsobrecarregados, mantendo assim a rede ativa por mais tempo.

Com o objetivo de promover o compartilhamento de dados de forma transparente entreaplicações e redes, e o mais importante, auxiliar na redução do consumo de energia das RSSFs,será apresentada neste capítulo a SITRUS, uma infraestrutura semântica para Rede de SensoresSem Fio.

3.2. CENÁRIOS DE USO 41

Além de cuidar de alguns tipos de heterogeneidade, que serão discutidos na Seção 3.4.1,SITRUS trata os dados enviados pela rede de forma semântica, utilizando ontologias, com oobjetivo de proporcionar uma semântica formal e sem ambiguidade a esses dados. As ontologiasservem para expressar conhecimento dos dados provenientes da rede, enriquecendo esses dadospela associação de seu significado e pela inferência de novos dados a partir de dados já existentes.

Além disso, SITRUS trabalha com mecanismos de reconfiguração paramétrica a partirdos dados processados semanticamente, economizando energia por tirar esse processamento daprópria RSSF, deixando o processo de reconfiguração sem nenhum tipo de intervenção humanae baseado em semântica formal.

Para poder executar essa infraestrutura semântica para RSSF, a SITRUS é formada porduas partes distintas: Módulo de Processamento Semântico da Informação (SIP), e Middleware

Ciente de Reconfiguração para Rede de Sensores Sem Fio (RAMSES). As duas partes alimentamuma base de dados semântica, gerando informações sobre o estado da rede e os nós sensores,dando suporte para o modelo de reconfiguração paramétrica, além de permitir consultas so-bre esses dados gerados, utilizando um modelo formal e padronizado de informações, sem anecessidade de fazer perguntas frequentes na própria RSSF.

3.2 Cenários de Uso

Esta seção apresenta alguns cenários onde é utilizada a SITRUS, para melhor esclarecero funcionamento da infraestrutura semântica e facilitar o entendimento da proposta.

3.2.1 Monitoramento do Ambiente

O primeiro cenário diz respeito a uma aplicação de monitoramento de um ambienteque gera dados constantemente e os envia para uma estação base. Como podemos observarpela Figura 3.1, mais de uma RSSF pode estar funcionando ao mesmo tempo em um mesmoambiente, gerando dados sobre esse ambiente monitorado. Além disso, essas redes podemtrabalhar inclusive com sensoriamentos diferentes ou aplicações diferentes umas das outras.

O problema maior neste cenário é como utilizar os dados de todas as RSSFs, que estãosendo gerados sobre um mesmo ambiente, de forma que eles estejam acessíveis para consultasfuturas, além de ter mecanismos que as façam se comunicar. Para viabilizar esse cenário, a únicarestrição para todos os nós sensores é que devem estar executando o RAMSES. Dessa forma,temos uma plataforma comum que esconde a heterogeneidade do sistema e proporciona ummodelo de comunicação único para todos os nós sensores de uma mesma rede, mesmo que suasaplicações sejam diferentes ou trabalhem com sensoriamentos diferentes.

Este é um cenário típico para Redes de Sensores Sem Fio que fazem coleta e envio dedados sobre o monitoramento de ambientes. A diferença aqui está na utilização do RAMSESpara comunicação dos nós sensores e também no fato de que todos os dados são transmitidos


Figura 3.1: Cenário de Uso de Monitoramento de Ambiente Usando a SITRUS

para o Módulo de Processamento Semântico da Informação (SIP), onde serão processados,categorizados e armazenados em uma base de dados semântica.

3.2.2 Consulta de dados

Com todos os dados já categorizados, tratados semanticamente e armazenados emuma base de dados semântica, o segundo cenário apresenta um modelo de consulta de dadosutilizando-se da SITRUS, como podemos observar pela Figura 3.2.

Figura 3.2: Cenário de Uso de Consulta de Dados da RSSF Usando a SITRUS

Dentro dos diversos tipos de limitações das RSSFs, podemos citar o fraco desempenhoem pesquisas de dados das RSSFs, ocorrendo com isso casos de falso positivo e falso negativo


(EID; LISCANO; EL SADDIK, 2006), devido à utilização exclusiva da sintaxe em sua execução.Técnicas de busca fazendo casamento de padrões em strings pode não ter resultados relevantes,porque alguns termos podem ter significados diferentes, e situações como essa comprometem osmecanismos de busca.

Outro problema em consultas sobre o sensoriamento dos nós das RSSFs é que em geralas consultas são realizadas diretamente sobre a RSSF, o que implica dizer que quanto maisconsultas são feitas, mais energia é consumida, pois exige-se mais transmissões de dados eprocessamento.

Neste cenário, todas as consultas são realizadas exclusivamente na base de dados se-mântica, de forma que evita-se ambiguidades e sobrepõem as limitações sintáticas para troca demensagens. Dessa forma, as consultas são realizadas de forma mais precisa e sem a necessidadede intervenção na RSSF, economizando assim energia, além de resolver os problemas sintáticos.

3.2.3 Reconfiguração dos Nós Sensores

Além de armazenar dados, o Módulo de Processamento Semântico da Informação (SIP)da SITRUS monitora o comportamento de cada nó sensor em sua determinada rede a partir dosdados enviados. Caso o SIP, através de suas consultas, identifique algum ponto crítico na rede,por exemplo, algum nó sensor enviando informações redundantes em um determinado períodode tempo, o SIP envia para este nó sensor uma mensagem de reconfiguração. Assim, o RAMSESprocessa essa mensagem e modifica o comportamento do nó sensor, corrigindo o estado críticoatingido. Esse cenário pode ser visualizado na Figura 3.3.

Figura 3.3: Cenário de Uso de Reconfiguração de um Nó Sensor Usando a SITRUS

Esse cenário é o mais impactante no que diz respeito à redução do consumo de energia.Todo o processo de tomada de decisão sobre o comportamento de um determinado nó sensor é

3.3. ARQUITETURA 44

realizado fora da RSSF, pelo Módulo de Processamento Semântico da Informação. Assim, o nósensor fica responsável apenas por realizar as operações necessárias à execução de sua aplicação,deixando outras operações, inclusive a de transmissão e recepção de dados, de forma transparentepara ele. Além disso, todas as mensagens de reconfiguração para alteração do comportamentovisam a redução do consumo de energia.

3.3 Arquitetura

Nesta seção, será apresentada a arquitetura proposta para a SITRUS. A partir do usode ontologias, a arquitetura proposta permite que máquinas tenham conhecimento dos dadostransportados pelas RSSFs, onde todos os dados são processados e adaptados às exigências dasaplicações. Como mostra a Figura 3.4, a arquitetura é dividida em 3 camadas, que serão descritasa seguir.

Figura 3.4: Arquitetura SITRUS

3.3.1 Camada de Dados das Redes de Sensores

A Camada de Dados das Redes de Sensores consiste de RSSFs heterogêneas formadaspor diferentes nós sensores com hardware e aplicações diferentes. Os dados de cada uma dasRSSFs são agrupados em suas estações base e transmitidos para a Camada Semântica, paraque possam ser processados por ela. Além disso, a Camada Semântica oferece o suporte aoserviço de reconfiguração paramétrica da Camada de Dados das Redes de Sensores, enviandomensagens de reconfiguração para nós sensores que atingiram algum ponto crítico determinado.

3.3. ARQUITETURA 45

A única restrição para essa camada é que todos os nós sensores adaptem o seu softwarelegado ou construam novas aplicações usando o RAMSES, garantindo assim um mesmo meca-nismo de comunicação entre os componentes remotos e a utilização dos serviços disponíveis deforma transparente.

Nesta camada, a economia de energia acontece pelo uso do modelo de comunicaçãoadotado pelos nós sensores, pela execução do serviço de reconfiguração paramétrico e pelautilização de mecanismos de baixo consumo de energia desenvolvido para o RAMSES.

Todos os detalhes de implementação e utilização da Camada de Dados das Redes de

Sensores serão apresentados no Capítulo 4.

3.3.2 Camada Semântica

Uma vez que todos os dados dos nós sensores estão disponíveis através de suas respectivasestações base, é preciso instanciar esses dados em ontologias, a fim de categorizar e armazenaros dados em uma base de dados semântica. Portanto, a segunda camada da arquitetura se refereà Camada Semântica para RSSF.

Além das RSSFs compartilharem a utilização do RAMSES, compartilham também autilização da mesma ontologia para mapear os seus dados, o que facilita o desenvolvimento parageração de conhecimento entre RSSFs diferentes, uma vez que a base de dados semântica e osconceitos mapeados são os mesmos por todas as RSSFs.

A Camada Semântica é a camada que mapeia e processa os dados provenientes dasRSSFs, criando um modelo simples em RDF (LASSILA, 2004) ou um modelo de ontologia emOWL (MCGUINNESS; HARMELEN, 2004), e assim, os dados dos nós sensores podem entãoser armazenados na base de dados semântica. A camada também oferece um mecanismo de con-sulta em linguagem SPARQL (HUANG; ABADI; REN, 2011; PÉREZ; ARENAS; GUTIERREZ,2009), que é responsável pela consulta de dados dos nós sensores. Da mesma forma, utiliza-sede um motor de raciocínio e regras para realizar inferências sobre esses dados armazenados.

Nesta camada, a economia de energia encontra-se na utilização da base de dados semân-tica como forma de suporte à realização de consultas de dados sobre as RSSFs, evitando assim ouso desnecessário de mensagens na RSSF. Além disso, essa camada realiza todo o processamentopara tomada de decisão sobre o processo de reconfiguração dos nós sensores.

Todos os detalhes de implementação e uso da Camada Semântica serão apresentados noCapítulo 5.

3.3.3 Camada de Aplicação

A Camada de Aplicação consiste em diferentes aplicações de clientes que requisitaminformações sobre os nós sensores através dos dados que se encontram na base de dadossemântica. Os dados dos nós sensores estão à disposição desses aplicativos através de qualquerservidor Web da Internet.

3.4. SOLUÇÕES ENVOLVENDO A SITRUS 46

Como apresentado nessa arquitetura, nenhuma consulta é realizada diretamente sobrequalquer RSSF, apenas sobre a base de dados semântica. Além disso, o resultado de uma consultapode ser a combinação dos resultados de mais de uma RSSF ao mesmo tempo, pois os dados daCamada Semântica são o resultado da combinação de várias RSSFs e seus sensoriamentos.

3.4 Soluções Envolvendo a SITRUS

A partir da arquitetura descrita anteriormente, serão descritos nesta seção a descrição dosproblemas solucionados pela SITRUS.

3.4.1 Interoperabilidade

Integração de dados de nó sensores é uma tarefa desafiadora, especialmente no caso defontes de dados heterogêneas como são as RSSFs. Nos trabalhos de WANG; TOLK; WANG(2009); DIALLO; CHAMPEAU; LAGADEC (2013) foram identificados 4 níveis diferentes deheterogeneidade:

� Sistemas: Hardware e sistemas operacionais diferentes.

� Sintaxe: Linguagens de programação e representação de dados diferentes.

� Estrutura: Modelos de dados diferentes.

� Semântica: Significados diferentes de um termo em um contexto especial.

Tecnologias em diferentes níveis e vários sistemas de middleware foram desenvolvidaspara resolver este problema de heterogeneidade. Além disso, a linguagem XML tem sido adotadacomo sintaxe comum para a troca de informações heterogêneas (HUANG; JAVED, 2008).Infelizmente, XML não fornece mecanismos suficientes para anexar semântica (significado) aosdados.

Nesse contexto, a SITRUS fornece interoperabilidade em nível de sistema e sintaxe apartir da utilização de um middleware de comunicação, o RAMSES. Ao mesmo tempo, forneceinteroperabilidade em nível de estrutura e semântica a partir do Módulo de Processamento Se-mântico da Informação, que fornece uma estrutura que permite que dados sejam compartilhadose reutilizados.

Por utilizar os conceitos da Web Semântica a partir do uso de ontologias, os dados daSITRUS podem ser efetivamente compartilhados por diferentes usuários e podem ser facilmenteprocessados por máquinas.

3.4. SOLUÇÕES ENVOLVENDO A SITRUS 47

3.4.2 Anulação das Restrições Sintáticas nas Consultas

Dentre as limitações das RSSFs, podemos citar o fraco desempenho em pesquisas dedados sobre a RSSF por conta da utilização exclusiva da sintaxe, ocorrendo com isso casos defalso positivo e falso negativo em seus resultados (EID; LISCANO; EL SADDIK, 2006).

A representação semântica dos dados de uma RSSF permite uma visão estruturada esem ambiguidades. Em um cenário em que existem várias RSSFs diferentes em um mesmoambiente, com vários sensores com identificadores iguais entre elas, mas com diferentes tiposde sensoriamento, as consultas que utilizam apenas a sintaxe podem ter resultados não muitoconfiáveis, pois a ambiguidade gerada atrapalha os resultados.

Dessa forma, a SITRUS provê resultados sem as restrições sintáticas das linguagens esem ambiguidades, e com isso, resultados mais confiáveis, a partir da utilização da base de dadossemântica para a realização das consultas.

Outro ponto importante é a utilização de um motor de inferência na ontologia utilizada.Com a possibilidade da utilização de dados combinados de várias RSSFs e com sensoriamentosdiferentes, novos dados podem ser gerados pelo relacionamento entre eles, facilitando assim oacesso à informação.

3.4.3 Reconfiguração Paramétrica

Um ponto importante dessa infraestrutura é o seu esquema de reconfiguração. A própriaSITRUS decide em que momento os nós sensores devem alterar o seu comportamento a fim deeconomizar energia. Todo o procedimento é realizado em tempo de execução e sem intervençãohumana. Dessa forma, o modelo proposto de reconfiguração, adaptado a partir dos trabalhos deMCKINLEY et al. (2004), pode ser feito de 3 maneiras diferentes:

� Nível de Aplicação: Mudança de parâmetros que influenciam a execução da aplica-ção, por exemplo, o tempo de amostragem para coletar dados de sensoriamento deum sensor.

� Nível de Middleware: Modificação dos algoritmos internos e serviços do middleware,por exemplo, algoritmo de agregação de dados e a taxa de agregação.

� Nível de Rede: Alterações na topologia da rede, nos algoritmos de roteamento ouna hierarquia de disseminação de dados, a partir de utilização de regiões lógicas ouno desligamento de determinado grupo de sensores, deixando a rede ativa, mas comuma quantidade mínima de nós sensores funcionando.

Todo o modelo de reconfiguração para os nós sensores é determinado pelo Módulode Processamento Semântico da Informação (SIP) e executado pelo RAMSES, a partir doprocessamento de mensagens enviadas através da rede.


3.4.4 Economia de Energia

A última solução envolvendo a SITRUS é o seu mecanismo de economia de energia,que está implementado em todos os seus módulos, desde a tomada de decisão fora da RSSF, osistema de consultas a partir de uma base de dados semântica e o esquema de reconfiguraçãoparamétrica para os nós sensores.

Além disso, o RAMSES foi desenvolvido utilizando-se do conceito de baixo consumode energia proporcionado pelo TinyOS (LEVIS et al., 2005), onde a antena fica acessível apenasem momentos controlados pela aplicação, que também pode ter seu tempo de acessibilidadealterado pelo esquema de reconfiguração da Infraestrutura.

Outro ponto a ser observado é o modelo de distribuição assíncrona de passagem de men-sagens desenvolvida para o RAMSES, que é o mais adequado para um modelo de disseminaçãode dados, o que contribui para o gerenciamento de energia.


Este capítulo descreveu os principais detalhes sobre a Infraestrutura Semântica paraRede de Sensores Sem Fio (SITRUS). No início do capítulo, foi exposta uma visão geral doseu funcionamento, a fim de contextualizar e apresentar melhor a sua importância. A seguir,os diferentes cenários de uso da Infraestrutura foram discutidos. Depois, foi apresentada a suaarquitetura e como as partes se comunicam para formar a SITRUS. Por fim, foram descritas asfuncionalidades a partir da arquitetura definida e dos cenários de uso.

494949

4RAMSES: Middleware Ciente de Reconfi-guração para Rede de Sensores Sem Fio

Este capítulo apresenta o RAMSES (acrônimo em inglês para Reconfiguration Aware

Middleware for Wireless Sensor Networks) (BISPO; ROSA; CUNHA, 2014), uma parte impor-tante da SITRUS, que é responsável pelo transporte de dados e gerenciamento de serviços dasaplicações que são executadas nos nós sensores. Dentre os serviços oferecidos pelo RAMSES, oserviço de reconfiguração é o mais importante e é baseado em mensagens enviadas pelo Módulode Processamento Semântico da Informação (SIP).

As próximas seções descrevem o funcionamento do RAMSES de forma mais detalhada.Primeiro, uma visão geral será apresentada para contextualizar a sua importância. Em seguida,será discutida como sua arquitetura e suas camadas se comunicam para formar o RAMSES.Depois, a implementação da arquitetura é descrita a partir de suas funcionalidades e diagramas.Por fim, são discutidas as considerações finais do RAMSES.

4.1 Visão Geral

Middleware Ciente de Reconfiguração para Rede de Sensores Sem Fio (RAMSES) éum middleware orientado à mensagem para RSSF. Ele foi desenvolvido para interagir com aCamada de Dados das Redes de Sensores da SITRUS. Assim, o RAMSES é o responsável pelotransporte de dados, pelo gerenciamento de serviços disponibilizados às aplicações executadasnos nós sensores, além de executar os mecanismos de reconfiguração desses nós sensores.

Devido à escassez de recursos, tais como memória, processamento, armazenamentoe energia, desenvolver um projeto de middeware para RSSF não é uma tarefa trivial. Aocontrário das plataformas de middleware tradicionais, que possuem diversos serviços, o projetode middleware para RSSF inclui um número reduzido deles, por exemplo, o serviço de agregaçãode dados e reconfiguração. Mesmo tendo limitações de hardware e serviços reduzidos, osbenefícios da utilização de middleware em um cenário tão complexo como são as RSSFs setornam bastante viáveis (HADIM; MOHAMED, 2006b; MOLLA; AHAMED, 2006).

4.2. ARQUITETURA 50

Um projeto de middleware para RSSF deve sempre considerar as restrições impostaspelo hardware e mecanismos internos dos sistemas operacionais, a fim de esconder essascomplexidades dos desenvolvedores de aplicações. Entretanto, como o desenvolvimento deum middleware deve suportar e otimizar uma grande classe de aplicações, o “tradeoff ” entreo grau de generalidade do middleware e o grau de especialização devem ser explorados (YU;KRISHNAMACHARI; PRASANNA, 2004).

Nesse contexto, o RAMSES aparece como uma alternativa aos sistemas de middleware

para RSSF, por apresentar um serviço de comunicação orientado a mensagens, serviços degerenciamento de recursos com preocupações constantes na economia de energia e um serviço dereconfiguração paramétrica, baseado em informações processadas e transmitidas por uma infra-estrutura semântica. Desta forma, os serviços providos pelo RAMSES atendem às necessidadesdas aplicações e se adequam aos ambientes das RSSFs e da SITRUS.

O RAMSES foi construído para nós sensores que executam o TinyOS (LEVIS et al.,2005), utilizando assim seu modelo de execução orientado a componentes, o que facilita odesenvolvimento.

As próximas seções detalham o funcionamento de cada uma das etapas do processo dedesenvolvimento do RAMSES, bem como descrevem a implementação de cada umas das etapas.

4.2 Arquitetura

A arquitetura do RAMSES, apresentada na Figura 4.1, é uma arquitetura em 3 camadas,com funcionalidades distintas entre elas, mas que se comunicam oferecendo serviços umas paraas outras. De acordo com a arquitetura apresentada, o RAMSES está posicionado acima dosistema operacional, encapsulando seus detalhes internos e fornecendo serviços de alto nívelpara a aplicação do nó sensor.

4.2.1 Camada de Transporte

A Camada de Transporte lida com os detalhes de transporte de dados providos peloTinyOS, encapsulando assim toda a complexidade de transmissão de dados do sistema operacio-nal. Por ser a camada que lida com a comunicação, é a responsável pela transmissão e aquisiçãodas mensagens do Módulo de Processamento Semântico da Informação (SIP).

Toda vez que uma nova mensagem é enviada do SIP para um nó sensor ou uma deter-minada RSSF, esta mensagem é encaminhada da Camada de Transporte para a Camada de

Serviços, para que possa ser processada pelo serviço de reconfiguração. No sentido inversode comunicação, sempre que um novo dado de sensoriamento é gerado e está pronto para sertransmitido, a aplicação envia esses dados para o middleware para serem processados, até chegarna Camada de Transporte e ser enviado.

4.2. ARQUITETURA 51

Figura 4.1: Arquitetura do Middleware RAMSES

4.2.2 Camada de Distribuição

A Camada de Distribuição é a camada que lida com o modelo de comunicação publish/-

subscribe, publicando as mensagens e intermediando a comunicação entre os demais serviços domiddleware. Além disso, ela permite a comunicação entre clientes remotos de forma transparente,abstraindo a localização, protocolo de comunicação e hardware utilizado.

O serviço de comunicação do RAMSES é baseado em um modelo assíncrono de pas-sagem de mensagens (RADHIKA; MALARVIZHI, 2012; YONEKI, 2003), mais adequado aomodelo de disseminação de informações requerido pelas aplicações de RSSF. Neste tipo decomunicação, um fornecedor de informação (publisher) publica as mensagens que são enviadasa um ou mais assinantes (subscribers).

A comunicação assíncrona é a principal vantagem deste modelo de comunicação nocontexto de ambientes ad-hoc e difuso, como são as RSSFs. Além disso, uma extensão domodelo foi utilizada, permitindo que mensagens sejam associadas a tópicos (SOUTO et al., 2005).Neste caso, para economizar energia, somente as mensagens referentes aos tópicos assinados sãotransmitidas.

A escolha do modelo publish/subscribe deve-se ao fato de que as aplicações em RSSFssão essencialmente baseadas em eventos (event-driven), o que sugere um modelo de comunicaçãomais adequado do que o modelo request/response tradicional, que é síncrono. Dessa forma, ummodelo de comunicação mais adequado para disseminação de informações (SILVA et al., 2014;KRISHNAMACHARI; ESTRIN; WICKER, 2002b) é o modelo assíncrono, necessário paraaplicações de RSSFs (YONEKI, 2003).

4.3. IMPLEMENTAÇÃO 52

A quantidade de informações geradas em uma rede fisicamente dispersa com inúmerosnós sensores trocando dados é imensa. Neste cenário, nem sempre alguns nós sensores e algumasestações base estão ativos na rede ao mesmo tempo e se comunicando. Dessa forma, nem semprea comunicação síncrona, baseada no modelo request/response é adequada para satisfazer a taisrequisitos.

O modelo de distribuição publish/subscribe será apresentado com maiores detalhes naSeção 4.3.4.

4.2.3 Camada de Serviços

A Camada de Serviços fornece serviços a outras camadas do middleware e às aplicações.O serviço de agregação de dados, por exemplo, permite a redução do volume de dados na rede.

Com a agregação de dados, cada nó sensor espera por uma quantidade de mensagenspré-determinada (valor configurável), agregando todos os dados recebidos durante esse período,e em seguida os envia para Camada de Distribuição, para que possam ser associados ao tópicocorreto, sendo transmitidos pela Camada de Transporte.

O serviço de agregação tem a finalidade de reduzir o número de transmissões na rede,agregando seus dados a partir de alguma função pré-determinada, por exemplo a média, moda oumediana. A implementação deste serviço no RAMSES é parametrizada, deixando para o serviçode reconfiguração a quantidade de dados que serão agregados e qual função de agregação a serescolhida.

Outro serviço fornecido é o serviço de reconfiguração. Todas as mensagens enviadas doSIP para um nó sensor são processadas por esse serviço, modificando assim o comportamentoda aplicação executada, da RSSF ou do próprio middleware. Como exemplo, podemos citar aalteração da taxa de amostragem ou o período que cada nó pode ficar com a antena ligada.

Todas as ações de reconfiguração visam reduzir o consumo e são baseadas em mensagensenviadas pelo SIP, a partir do processamento semântico de mensagens enviadas pelos nóssensores das RSSFs. Assim, todo o processo de tomada de decisão para alterar determinadocomportamento fica fora da RSSF, economizando energia.

4.3 Implementação

O projeto do RAMSES foi realizado visando a sua customização e extensão de formasimples. Portanto, toda a implementação foi dividida em interfaces e componentes com respon-sabilidades distintas, que possibilitam uma fácil adição de novos recursos, seguindo a arquiteturaproposta para o RAMSES. Para prover essas características, o middleware é baseado no modelode componentes do TinyOS, usando a linguagem de programação nesC, uma linguagem orientadaa eventos usada para construir aplicações para o TinyOS.

Por fazer parte da SITRUS, o desenvolvimento do RAMSES foi realizado com uma


preocupação constante em reduzir o consumo de energia a partir de seus componentes ou comoaproveitar melhor os componentes já existentes, alterando apenas parâmetros em seus algoritmos.

Assim, todos os serviços desenvolvidos para o RAMSES são parametrizáveis, de formaque o serviço de reconfiguração possa atuar e alterar o comportamento do nó sensor durantesua execução. Outro procedimento importante utilizado visando a economia de energia foi autilização de mecanismos de baixo consumo para a transmissão de dados, tendo em vista que ocomponente de hardware que mais consome energia é a antena (ANASTASI et al., 2009), comsuas transferências e aquisições de dados.

4.3.1 Low Power Listening

O gerenciamento de energia do RAMSES é auxiliado pela utilização da interface Low

Power Listening, fornecida pelo TinyOS. Ela gerencia de forma mais eficiente as operações decontrole de acesso ao meio (MAC), em que o rádio é desligado durante uma percentagem dotempo e apenas ligado periodicamente.

A implementação se baseia no método Clear Channel Assessments (CCA) (JOGI;VIDHATE, 2013), para determinar se há um transmissor nas proximidades, verificando seo canal de comunicação está livre, evitando assim colisões. Isso permite ao receptor desligar orádio e determinar que não há transmissores em um período muito curto de tempo ao invés dedeixar o rádio ligado tempo suficiente para receber um pacote completo.

Os transmissores realizam a entrega de mensagens por transmitir o pacote completorepetidas vezes pelo dobro da duração do período de atividade (duty cycle) do receptor. Transmitirpelo dobro do tempo aumenta a probabilidade de que a mensagem será detectada pelo receptor epermite ao receptor diminuir o tempo que necessita para manter o seu rádio ligado.

Tipicamente, um pacote transmitido usando a interface Low Power Listening segue oformato apresentado pela Figura 4.2. O Backoff é o período necessário para fazer a checagemdo meio de transmissão e verificar se o canal está livre para envio de dados. Já o Ack Wait é operíodo necessário para o receptor enviar uma mensagem de confirmação.

+−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−+| Backof f | P a c k e t Tx | Ack Wait |

+−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−+

Figura 4.2: Formato de um pacote em Low Power Listening

Para diminuir a quantidade de tempo necessária para uma verificação de recebimento, ocanal deve ser modulado pelo transmissor sempre que possível. O único período onde o canal émodulado é durante a fase de transmissão de pacotes. O receptor deve constantemente realizaramostras de leitura no CCA por um momento maior que o período de Backoff e Ack Wait juntos,para sobrepor o período de transmissão de pacotes.


Ao fazer o período de Backoff o mais curto possível, pode-se diminuir a quantidade detempo que o rádio do receptor deve estar ligado enquanto executa uma verificação de recebimento.No entanto, isto também aumenta a probabilidade de colisão ou captura do canal.

Se dois transmissores tentam transmitir utilizando a interface Low Power Listening, umtransmissor pode capturar o canal se o seu período de Backoff está muito curto. Nós sensorestransmitindo ao mesmo tempo irão causar interferência e impedir outros nós sensores de entregarcom sucesso as suas mensagens para o destinatário pretendido.

Usar essa interface tipicamente envolve definir um duty cycle para os nós sensores apartir do evento Boot.booted() em uma aplicação nesC (linha 2). Esse evento é disparado logono início da aplicação para configuração do nó sensor e inicialização das atividades da antena derádio (linha 3). Para cada pacote que a aplicação precisa enviar, o duty cycle do seu nó destino éentão especificado como um metadado, de modo que o número correto de preâmbulos possa serestabelecido para ele. O trecho de código apresentado pela Figura 4.3 demonstra esse padrão deuso.

1 e v e n t vo id Boot . boo t e d ( ) {2 c a l l LowPowerLis ten ing . s e t L o c a l S l e e p I n t e r v a l ( INTERVAL ) ;3 c a l l R a d i o C o n t r o l . s t a r t ( ) ;4 }5

6 e v e n t vo id R a d i o C o n t r o l . s t a r t D o n e ( e r r o r _ t e ) {7 i f ( e != SUCCESS)8 c a l l R a d i o C o n t r o l . s t a r t ( ) ;9 }

Figura 4.3: Código Utilizado para Inicialização de um Nó Sensor Usando Low PowerListening

A interface RadioControl, fornecida pelo componente CC2420ActiveMessageC, é usadapara permitir as operações de rádio em Low Power Listening a partir de antenas CC2420, quesão as adotadas em motes MICAz e TelosB.

Uma vez que o comando RadioControl.start() seja concluído, o rádio começa a seu duty

cycle, conforme especificado pelo parâmetro para o comando setLocalSleepInterval().O middleware RAMSES foi implementado de forma mais genérica possível, tentando

contemplar uma quantidade razoável de hardwares diferentes executando o mesmo middleware.Dessa forma, é apresentado na Figura 4.4 um código de configuração do componente Active-

Message para transmissão de dados utilizando a interface Low Power Listening correta paratipos diferentes de motes (TelosB, TMote, MICAz, Z1, MICA2, IRIS e UCMINI), como podeser observado nas linhas 1, 2, 7 e 12, associado aos seus hardwares de transmissão de rádiocorrespondentes (CC2420 e CC1000), nas linhas 3, 8 e 13.


1 # i f d e f i n e d (PLATFORM_TELOSB) | | d e f i n e d (PLATFORM_TMOTE) | | \2 d e f i n e d (PLATFORM_MICAZ) | | d e f i n e d (PLATFORM_Z1)3 components CC2420ActiveMessageC as LPLProv ider ;4 App . LPL −> LPLProv ider ;5 # e n d i f6

7 # i f d e f i n e d (PLATFORM_MICA2)8 components CC1000CsmaRadioC as LPLProv ider ;9 App . LPL −> LPLProv ider ;

10 # e n d i f11

12 # i f d e f i n e d ( PLATFORM_IRIS ) | | d e f i n e d (PLATFORM_UCMINI)13 components Act iveMessageC as LPLProv ider ;14 App . LPL −> LPLProv ider ;15 # e n d i f

Figura 4.4: Configuração da Interface LowPowerListening por Tipo de Plataforma

4.3.2 Componente Middleware

O componente Middleware, apresentado na Figura 4.5, encapsula os componentes daCamada de Serviços e da Camada de Distribuição da arquitetura proposta, oferecendo para aaplicação suporte aos serviços do middleware e o modelo de distribuição desenvolvido. Ao fazerisso, a complexidade do modelo de distribuição e os serviços providos pelo middleware sãooferecidos de forma transparente.

Middleware

MiddlewareM

Middleware

ServiceLayerC

ServiceLayer

DistributionLayerC

DistributionLayer

OscilloscopeC

Oscilloscope

Figura 4.5: Componente Middleware

Este componente fornece duas operações em sua interface: sendData e createTopic. O


comando sendData interage diretamente com o componente ServiceLayer, a partir dos algoritmosde agregação de dados. Caso o algoritmo de agregação esteja parametrizado para realizar a tarefa,os dados apenas serão repassados para a Camada de Distribuição após a conclusão da agregaçãode dados. Por exemplo, se algoritmo estiver parametrizado para utilizar como base de cálculo amédia e que 10 amostras serão utilizadas para o cálculo, apenas após o cálculo da média dessas10 amostras os dados são repassados para a Camada de Distribuição.

Já o comando createTopic interage diretamente com o componente DistributionLayer,associando um tópico para a aplicação. Por padrão, cada aplicação está associada a apenas umtópico, e por consequência, só poderá transmitir dados associados a esse tópico, economizandoassim energia na transmissão caso diversos tópicos diferentes estejam interagindo em uma mesmaRSSF.

O desenvolvedor de aplicações que deseja utilizar o RAMSES precisa apenas adicionaro módulo Middleware à sua aplicação para ter acesso à interface com as operações disponíveis.Dessa forma, a aplicação poderá utilizar o modelo de comunicação publish/subscribe e teracesso aos serviços de reconfiguração e agregação de dados, pois o Módulo de ProcessamentoSemântico da Informação (SIP) é quem decide o momento de alterar parâmetros de tais serviçose o RAMSES executa as ações de reconfiguração a partir dessas mensagens. Para a aplicação,esses serviços são executados de forma transparente.

4.3.3 Componente TransportLayer

O componente TransportLayer, apresentado na Figura 4.6, implementa a Camada de

Transporte da arquitetura proposta. Assim, ele é o responsável pela transmissão e aquisiçãode dados. Pare realizar tal tarefa, o TransportLayer interage diretamente com as primitivas detransporte de dados do TinyOS.

TransportLayer

TransportLayerM

TransportLayer

CC2420ActiveMessageC

LowPowerListening

AMReceiverC

Receive

AMSenderC

AMSend Packet

ServiceLayerC

ServiceLayer

Figura 4.6: Componente TransportLayer

Ele provê uma interface com duas operações: send e receive. O comando send, comseu código de transmissão de dados apresentado pela Figura 4.7, tem por finalidade montar a


mensagem que será enviada aos componentes remotos. Por fim, é feita uma chamada ao móduloAMSend, fornecido pelo TinyOS, para que os dados sejam enviados pela rede.

1 command vo id T r a n s p o r t L a y e r . send ( message_ t * b u f P t r , i n t 8 _ t s i z e ) {2 i f ( l o c k e d ) {3 r e t u r n ;4 } e l s e {5 c a l l LowPowerLis ten ing . s e t R x S l e e p I n t e r v a l ( b u f P t r , INTERVAL ) ;6 i f ( c a l l AMSend . send (AM_BROADCAST_ADDR, b u f P t r , s i z e ) == SUCCESS) {7 p a c k e t = b u f P t r ;8 l o c k e d = TRUE;9 } e l s e {

10 p o s t r e t r y S e n d T a s k ( ) ;11 }12 }13 }

Figura 4.7: Código Utilizado para Transmissão de Dados Utilizando o RAMSES

A invocação do comando setRxSleepInterval com um intervalo de suspensão específico,linha 5, permite enviar o número correto de preâmbulos para a mensagem especificada em sualista de parâmetros. Assim, o processo de transmissão de dados ocorre em Low Power Listening.

O comando receive tem por finalidade processar a aquisição de dados provenientes daestação base. Para realizar tal tarefa, é utilizado o módulo AMReceiver, também fornecido peloTinyOS.

Sempre que uma nova mensagem enviada pela estação base é recebida, ou seja, foitransmitida pelo Módulo de Processamento Semântico da Informação (SIP), essa mensagemé direcionada ao componente ServiceLayer, para que a mensagem possa ser processada e suareconfiguração executada.

Toda comunicação entre os nós da RSSF e a estação base é baseada no paradigma Active

Message (BUONADONNA; HILL; CULLER, 2001), usando baixo consumo de energia nacomunicação. De acordo com esse paradigma, cada mensagem contém um ID de uma rotina detratamento a ser invocada no nó sensor alvo e um payload contendo os dados a serem passadoscomo argumento. Esta comunicação baseada em eventos e orientada a mensagens faz do TinyOSuma boa solução para a construção de uma infraestrutura de comunicação publish/subscribe.

4.3.4 Componente DistributionLayer

O componente DistributionLayer, apresentado na Figura 4.8, implementa a Camada de

Distribuição da arquitetura proposta, provendo uma interface com três operações: createTopic,publish e subscribe.

Para que um pacote possa ser montado, ter seus dados lidos ou enviados para transmis-são, o componente DistributionLayer utiliza o componente CC2420ActiveMessageC em suaimplementação, que é responsável pelo acesso aos dados de um pacote. Todas essas operaçõessão realizadas utilizando baixo consumo de energia.


DistributionLayer

DistributionLayerM

DistributionLayer


Packet

TransportLayerC

TransportLayer

ServiceLayerC

ServiceLayer

Figura 4.8: Componente DistributionLayer

Sempre que uma mensagem está pronta para ser publicada, com todas as suas informaçõespreenchidas, é executado o comando Send do componente TransportLayer para transmissãodessa mensagem. Assim, todas as operações de aquisição e transmissão de dados ficam em umacamada diferente das operações de criação, assinatura e publicação de tópicos e mensagens, deforma que cada camada tenha suas responsabilidades bem definidas.

Antes de publicar uma mensagem, alguns metadados precisam ser preenchidos, porexemplo, a taxa de amostragem atual de um nó sensor e a quantidade de dados agregadospor mensagem. Esses metadados são utilizados pelo Módulo de Processamento Semântico daInformação (SIP) para o processamento sobre o estado atual do nó sensor.

O diagrama de sequência da Figura 4.9 mostra a interação entre diversas camadas domiddleware RAMSES e o SIP para o anúncio e assinatura de tópico dos nós sensores. Porpadrão, cada aplicação está associada a apenas um tópico, que também pode ser alterado durantea execução da aplicação. Assim, a partir da criação do tópico pelo nó sensor, imediatamente eleestá assinando sua participação.

A aplicação anuncia ao componente Middleware a operação de sensoriamento (tempe-ratura, umidade, luz, dentro outros) que está sendo realizada e envia como parâmetro atravésdo método createTopic, que por sua vez encaminha a mensagem para o componente Distributi-

onLayer. O anúncio de tópicos não é direcionado aos demais nós da rede, mas apenas para oSIP, que armazena essa informação em sua base de dados semântica. Para realizar tal tarefa, ocomponente DistributionLayer executa o método subscribe, com o tópico como parâmetro, parao componente TransportLayer, de modo que a mensagem possa ser transmitida até o SIP.

A interação na parte inferior da Figura 4.9 refere-se à ocorrência de alterações de tópicospelo SIP ou a não associação de um tópico pela aplicação sendo executada no nó sensor no inícioda execução. Para os dois casos, a execução é a mesma. Caso a aplicação altere seu tipo de


Figura 4.9: Diagrama de Sequência para Anúncio e Assinatura de Tópico

sensoriamento, como requisito da própria aplicação ou por reconfiguração enviada pelo SIP, seutópico também precisa ser alterado. Dessa forma, o SIP envia uma mensagem para o nó sensorcom as novas informações sobre o novo tópico. Essa mensagem é recebida pelo componenteTransportLayer e encaminhada para o componente ServiceLayer, a partir do comando receive.Após essa etapa, é feita uma chamada ao comando setTopic do componente DistributionLayer,e com isso, a partir do novo tópico que foi enviado por parâmetro, o nó sensor tem seus dadosatualizados com o novo tópico associado a ele.

A Figura 4.10 apresenta como os dados monitorados pelos nós sensores são publicadosna rede até sua chegada no SIP. A aplicação periodicamente coleta dados de sensoriamento e osenvia para o componente Middleware através do comando sendData. Com isso, os dados sãoencaminhados para o componente ServiceLayer, para que seus dados sejam processados pelosserviços existentes, por exemplo, o serviço de agregação de dados. Com esses dados processadose prontos para serem enviados, o comando publish é executado e a mensagem segue seu fluxoaté o SIP, a partir da estação base.

Finalmente, a interação na parte inferior da Figura 4.10 ocorre quando uma mensagemchega a um nó sensor a partir de outro nó sensor. O componente TransportLayer, ao receberuma mensagem, encaminha-a para o componente ServiceLayer, a partir do comando receive.Neste componente é feita uma comparação do tópico recebido pela mensagem com o tópicocorrespondente do nó sensor, a partir do comando getTopic do componente DistributionLayer.Caso sejam do mesmo tópico, a mensagem segue seu fluxo com a execução do comandopublish até chegar a outro nó sensor ou ao SIP, a partir da estação base. Caso o nó sensor nãoesteja associado à mensagem recebida, ela é descartada. Dessa forma, evita-se que mensagens


Figura 4.10: Diagrama de Sequência para Publicação de uma Mensagem

desnecessárias sejam enviadas e economiza-se energia a partir da transmissão de dados pela rede.

4.3.5 Componente ServiceLayer

O componente ServiceLayer, apresentado na Figura 4.11, implementa a Camada de

Serviços da arquitetura proposta. Ele provê uma interface com operações responsáveis pelachecagem e alteração da taxa de amostragem, com os comandos getPeriodicSampling e setPe-

riodicSampling; checagem e alteração da quantidade de dados agregados, com os comandosgetAggregationSize e setAggregationSize; por receber as mensagens do SIP e processar osseus dados, a partir do comando receive; e finalmente, enviar mensagens para o componenteDistributionLayer, para que essas possam ser enviadas pela RSSF, através do comando sendData.

Sempre que a aplicação precisa enviar seus dados de sensoriamento pela RSSF, estessão enviados pelo componente Middleware até chegar ao componente ServiceLayer, onde seusdados serão processados e, apenas depois dessa etapa, é que esses dados serão encaminhadospara o componente DistributionLayer, como apresentado anteriormente pela Figura 4.10.

Uma das responsabilidades do componente ServiceLayer é a execução do serviço deagregação de dados, apresentado pela Figura 4.12 a partir de suas interações. Sempre queum novo dado de sensoriamento é enviado do componente Middleware para o componenteServiceLayer, o serviço implementado pelo componente AggregationService é executado. Asmensagens que são transmitidas por outros nós sensores não são novamente agregadas, apenasrepassadas para o componente DistributionLayer após a verificação do tópico, como apresentado


ServiceLayer

ServiceLayerM

ServiceLayer

AggregationServiceC

AggregationService

DistributionLayerC

DistributionLayer

ConfigurationServiceC

ConfigurationService

MiddlewareC

Middleware

Figura 4.11: Componente ServiceLayer

anteriormente pela Figura 4.10.

Figura 4.12: Diagrama de Sequência para Agregação de Dados

Para realizar a execução do serviço de agregação, o comando aggregate é invocadocom os parâmetros do tamanho da amostra (size) e um vetor (sample) do tamanho da amostrapreenchido com dados de sensoriamento. Após a execução do serviço de agregação, com o dadoagregado já processado, ele segue o fluxo de publicação pelo componente DistributionLayer.

Toda mensagem transmitida do SIP para um determinado nó sensor é processada pelocomponente ServiceLayer para que o serviço de reconfiguração desse nó sensor seja executado,a partir do componente ConfigurationService. A Figura 4.13 apresenta a interação de como oprocesso de reconfiguração a partir de mensagens do SIP ocorre.

Faz parte das mensagens enviadas pelo middleware um campo numerado que correspondeao código de reconfiguração do SIP. O objetivo desse campo é definir que tipo de operação será


Figura 4.13: Diagrama de Sequência para as Mensagens Recebidas do SIP paraReconfiguração

executada pelo nó sensor no componente ServiceLayer, a partir do momento que receber umamensagem.

Durante a transmissão de dados entre nós sensores até a estação base, o valor dessecampo está configurado como 0, indicando que não existe nenhuma operação de reconfiguração aser executada. Qualquer outro valor significa que o SIP enviou uma mensagem de reconfiguraçãopara o nó sensor. O processo de reconfiguração pode ser observado pelo diagrama de sequênciaapresentado pela Figura 4.13. Por exemplo, se o campo correspondente for encaminhado com onúmero 3, indica que a taxa de amostragem deve ser alterada pelo novo valor também transmitidona mensagem.



Este capítulo apresentou o RAMSES, um Middleware Ciente de Reconfiguração paraRede de Sensores Sem Fio responsável pelo transporte de dados e gerenciamento de serviços dasaplicações executadas nos nós sensores.

646464

5SIP: Módulo de Processamento Semânticoda Informação

Este capítulo apresenta o SIP (acrônimo em inglês para Semantic Information Processing

Module) (BISPO; ROSA; CUNHA, 2012), o módulo da SITRUS responsável pela manipulaçãode dados das Redes de Sensores Sem Fio. O SIP categoriza e instancia os dados de formaadequada em uma ontologia, e gera a base de dados semântica utilizada para a tomada dedecisões de reconfiguração dos nós sensores e a realização de consultas.

As próximas seções apresentam o funcionamento do SIP de forma mais detalhada.Primeiro, uma visão geral do módulo será introduzida. Em seguida, será discutida sua arquiteturaem camadas e como elas se comunicam para formar o módulo de processamento semântico.Depois, será descrita a ontologia desenvolvida, com suas classes e relacionamentos. Além disso,a implementação da arquitetura é analisada a partir de suas funcionalidades e diagramas. Porfim, serão apresentadas as considerações finais do SIP.

5.1 Visão Geral

O Módulo de Processamento Semântico da Informação (SIP) interage com a Camada

Semântica da arquitetura da SITRUS. Por conta disso, o SIP tem que executar todo o processa-mento relacionado à ontologia, bem como estabelecer mecanismos relacionados às consultasrealizadas por aplicações.

O SIP foi totalmente desenvolvido em Java e todas as RSSFs são conectadas ao SIP apartir de suas respectivas estações base. Para poder prover comunicação com as RSSFs, foiutilizada uma API de comunicação e manipulação de dados do TinyOS (LEVIS et al., 2005), aTinyOS API, que transmite e recebe dados serializados pela rede.

Além da TinyOS API, outra ferramenta utilizada para construção do Módulo de Pro-cessamento Semântico da Informação, mais precisamente para manipulação das ontologias,foi o framework Jena1 (YU, 2014; MCBRIDE, 2002). O Jena é um framework de suporte ao

1Disponível em: http://jena.apache.org/

5.2. ARQUITETURA 65

uso da Web Semântica em aplicações Java, onde esse suporte inclui recursos para manipulaçãode linguagens Resource Description Framework (RDF) (LASSILA, 2004) e Web Ontology

Language (OWL) (MCGUINNESS; HARMELEN, 2004).Uma das funções básicas do Módulo de Processamento Semântico da Informação é a

geração da base de dados semântica, onde seu processamento é realizado após receber os dadosdas RSSFs. Todos os dados das RSSFs são enviados de suas respectivas estações base e possueminformações sobre o sensoriamento do ambiente (luminosidade, umidade ou temperatura, porexemplo) e metadados referentes ao estado dos nós sensores (quantidade de dados agregados donó sensor por mensagem, identificador do nó sensor, taxa de amostragem, dentro outros).

Após o processamento desses dados recebidos, o SIP instancia esses dados na onto-logia que foi desenvolvida para ele, assim, os dados obtidos das RSSFs são categorizados einstanciados na ontologia de forma correta. Dessa forma, podemos inferir novos dados, buscarrelacionamentos de dados dentro de uma mesma RSSF ou entre redes diferentes.

Com os dados recebidos, instanciados e processados para a construção da base de dadossemântica, outra função importante é o processamento de consultas. Consultas sobre a redenão mais precisam ser feitas diretamente sobre as RSSFs. Todas as consultas são realizadas nabase de conhecimento gerada, obtendo assim dados mais precisos e relacionados com outrasinformações, e evitando com isso ambiguidades, respostas incorretas e acesso direto à RSSF.

Uma questão importante sobre a base de dados semântica é por quanto tempo um dadoé considerado atual. Esse é um problema que envolve o tipo de aplicação, sensoriamento ou anecessidade da consulta a ser realizada. Assim, deixamos para o cliente (usuário, aplicação ou opróprio SIP) decidir a relevância temporal do dado a ser consultado.

Outra possibilidade do SIP é o processamento interno de consultas. O SIP tambémrealiza consultas automáticas sobre o estado das RSSFs e seus nós sensores. Com isso, podemoschecar se algum nó sensor atingiu algum limiar pré-estabelecido que determina um consumo deenergia desnecessário, e caso tenha alcançado, uma mensagem de reconfiguração será enviadapara este nó sensor, com o objetivo de normalizar seu comportamento. Por exemplo, se diversosnós sensores em uma mesma região estão coletados dados iguais de temperatura do ambiente,alguns desses nós serão desligados temporariamente, evitando assim a redundância de dados.

As próximas seções detalham o funcionamento de cada uma das etapas de desenvolvi-mento do Módulo de Processamento Semântico da Informação.

5.2 Arquitetura

Nesta seção, será apresentada a arquitetura do Módulo de Processamento Semântico daInformação (SIP). Como ilustrado na Figura 5.1, a arquitetura do SIP é dividida em camadas.Todas as camadas e suas funcionalidades serão discutidas a seguir.

5.2. ARQUITETURA 66

Figura 5.1: Arquitetura do Módulo de Processamento Semântico da Informação (SIP)

5.2.1 Componente de Comunicação

O componente de Comunicação do SIP é a camada que se comunica diretamente com aCamada de Dados das Redes de Sensores da arquitetura SITRUS. Dessa forma, ela recebe osdados das RSSFs e os envia para a Camada Semântica da arquitetura do SIP para processamento.Outra funcionalidade do Componente de Comunicação é o envio de mensagens de reconfiguraçãopara nós sensores, a partir do processamento realizado pela Camada Semântica da arquitetura doSIP.


A Camada Semântica do SIP é responsável pela manipulação da ontologia, ou seja,instanciação dos dados provenientes do Componente de Comunicação, consulta de dados a partirda Subcamada de Consultas SPARQL, utilização da motor de raciocínio pela Subcamada do

Motor de Raciocínio e das regras pela Subcamada de Regras.Por ser uma camada com diversas funcionalidades, a Camada Semântica foi dividida em

subcamadas, descritas a seguir.

5.2. ARQUITETURA 67

5.2.2.1 Subcamada do Motor de Raciocínio

É importante lembrar que ontologias não descrevem apenas conhecimento imediato,isto é, conhecimento obtido diretamente a partir da observação de um domínio, mas tambémconhecimento derivado, ou seja, conhecimento obtido através de inferência sobre o conhecimentoimediato disponível.

Dessa forma, a Subcamada do Motor de Raciocínio, a partir de seu motor de inferência,integra novos conhecimentos a partir dos conhecimentos já existentes, pela utilização de racio-cínio dedutivo, regras e relacionamentos. Com isso, podem-se fazer consultas incluindo comonovos dados os dados obtidos pelo motor de inferência, otimizando o desempenho da base dedados semântica.

A construção da Subcamada do Motor de Raciocínio é baseada em lógica descritiva,uma denominação geral para uma família de formalismos de representação do conhecimento.Dessa forma, ela fornece descrições formais de suas propriedades, tais como consistência.

5.2.2.2 Subcamada de Regras

Embora a linguagem OWL possua um conjunto relativamente rico para a construçãode classes, o tratamento de propriedades é pobre. Em particular, não há um construtor decomposição, tornando impossível capturar relações entre propriedades compostas, por exemplo,a relação entre composição das propriedades “pai” e “irmão” e a propriedade “tio”.

Dessa forma, a Subcamada de Regras trabalha em conjunto com a Subcamada do Motor

de Raciocínio, que não se limita a obter informações apenas relacionadas ao raciocínio dedutivode suas classes e relacionamentos, mas também em regras definidas pelo desenvolvedor daontologia.

Essas novas informações são geradas a partir da combinação entre os termos e seusrelacionamentos, rompendo assim a limitação das relações entre propriedades compostas egerando novos dados a partir de regras.

5.2.2.3 Subcamada de Consultas SPARQL

Além de inferir novos dados a partir de um conhecimento derivado, os motores deraciocínio também têm a capacidade de responder a vários tipos de consultas, baseados noconhecimento imediato ou nas inferências computadas.

Dessa maneira, pela utilização da Subcamada de Consultas SPARQL, diferentes clientespodem requerer informações sobre os dados dos nós sensores, inclusive em redes diferentes,realizando consultas com a utilização da linguagem SPARQL (HUANG; ABADI; REN, 2011;PÉREZ; ARENAS; GUTIERREZ, 2009).

5.3. ONTOLOGIA DO SIP 68

5.2.2.4 Subcamada da Base de Dados

Todos os dados instanciados pela ontologia são armazenados em uma base de dadossemântica. Dessa forma, a Subcamada da Base de Dados é a camada responsável por essearmazenamento, dando assim suporte para o funcionamento das outras camadas, por exemplo, asconsultas da Subcamada de Consultas SPARQL.

5.3 Ontologia do SIP

A ontologia desenvolvida para o SIP propõe um modelo de conhecimento para elementosdos nós sensores, aquisição de dados e energia, que são elementos importantes para representaruma RSSF.

Os conceitos que foram considerados relevantes para o desenvolvimento da SITRUS, emespecial os mecanismos de reconfiguração e economia de energia, foram mapeados em classes,com propriedades e relacionamentos atribuídos a essas classes. A ontologia proposta contémuma hierarquia que define uma RSSF, descrevendo suas características.

O desenvolvimento da ontologia proposta foi baseado na utilização de uma taxonomiade classes (VITAL; CAFÉ, 2011) para RSSFs, como pode ser visto na Figura 5.2. A taxonomiaestá relacionada às formas de organização da informação relativas às RSSFs, utilizadas nestetrabalho, que auxiliaram na organização sistemática das informações primárias.

owl:Thing

PartialPower

Device

LedPower

Measurement WSN Lifetime Power LogicalRegion SensorNode Neighbor

Sensing Hardware

SensorType

RadioPower

TotalPower

MCUPower

Figura 5.2: Taxonomia da Ontologia do SIP

5.3.1 Descrição das Classes e suas Propriedades

Em OWL, as propriedades são usadas para criar restrições, que são utilizadas pararestringir os indivíduos de suas classes. Dessa forma, a descrição das classes utilizadas no SIPsão baseadas em seus relacionamentos e suas restrições.

A classe SensorNode, apresentada na Figura 5.3, representa a identidade do nó sensorem uma determinada RSSF e inclui algumas informações básicas desses nós, por exemplo, ovalor do NodeID, que representa o identificador de um nó sensor em uma determinada RSSF, e


da forma que essa característica foi mapeada na ontologia, esse identificador é único para umamesma RSSF.

Figura 5.3: A Classe SensorNode da Ontologia do SIP

Essa unicidade fica explícita na utilização de uma propriedade funcional para o valor doNodeID, que garante que nessa relação pode existir no máximo um indivíduo, ou seja, apenasum NodeID para uma determinada RSSF. Qualquer outro valor leva a uma inconsistência naontologia. Dessa forma, podemos ter RSSFs diferentes com identificadores de nós iguais, semcausar ambiguidade.

Pela propriedade hasNeighbor da classe SensorNode, é realizado o mapeamento dosvizinhos diretos de um determinado nó sensor, bem como outros nós sensores alcançáveis porele, calculados por uma regra a partir da propriedade isReachable, como apresentado na Figura5.4. Por essa regra, se um indivíduo A tem um vizinho B e um indivíduo B tem um vizinho C,então A e C são alcançáveis, ou seja, compartilham um mesmo caminho na distribuição dosdados. Essa regra serve para definir uma rota entre dois nós sensores.

i s N e i g h b o r ( ?A, ?B) ^ i s N e i g h b o r ( ?B , ?C) −> i s R e a c h a b l e ( ?A, ?C)

Figura 5.4: Propriedade isReachable sendo utilizada a partir de regras para definirexistência de rota entre dois nós sensores

A propriedade hasPowerConsumption realiza o relacionamento entre as classes Sensor-

Node e Power. A classe Power serve para fazer o mapeamento da estimativa do consumo deenergia a partir dos componentes de Led, MCU e Radio, que compõe o hardware de um nó sensore são os responsáveis pelo consumo de energia. A hierarquia da classe Power é apresentada naFigura 5.5.

Para realizar o cálculo da estimativa do consumo de energia, o relacionamento hasDevice

da classe SensorNode com a classe Device, apresentado na Figura 5.6, determina qual o hardware


Figura 5.5: A Classe Power da Ontologia do SIP

e o tipo de sensoriamento de um determinado nó sensor. Na classe Device, os valores dosdatasheets dos dispositivos fornecidos pelos fabricantes são preenchidos, e com isso, a estimativapode ser calculada a partir do tempo de uso de cada componente.

Figura 5.6: A Classe Device da Ontologia do SIP

A classe LogicalRegion, apresentada na Figura 5.7, relaciona-se com a classe SensorNode

a partir de duas propriedades inversas, a contains e a insideOf. Essas propriedades são funcionale funcional inversa, respectivamente. Dessa forma, um nó sensor pode fazer parte de apenas umaregião lógica e uma região lógica não pode ter mais de um nó sensor com um mesmo NodeID deuma mesma RSSF inserido nela.

Uma região lógica é uma região em que um grupo de nós da RSSF colaboram entre sipara a coleta de informações, processamento e transmissão de dados para uma estação base,o que resulta em considerável economia de recursos (energia, processamento, por exemplo) e,consequentemente, um aumento no tempo de vida da rede. Nesse contexto, existe a possibilidadede definir quem são as regiões lógicas manualmente, a partir da instância dos nós sensores, ou deforma automática pela ontologia, já que os nós vizinhos e seus alcances são conhecidos por ela.

A classe Sensing, que é uma subclasse da classe Device, relaciona-se com a classe Sen-


Figura 5.7: A Classe LogicalRegion da Ontologia do SIP

sorType, apresentada na Figura 5.8, a partir da propriedade hasSensorType. A classe SensorType

define alguns tipos de sensoriamento que podem ser instanciados (temperatura, luminosidade eumidade). Outros valores que não esses, geram uma inconsistência na ontologia. Assim, umaconsulta referente a um determinado nó sensor, a partir dos seus relacionamentos, apresenta quetipo de sensoriamento está sendo usado no momento.

Figura 5.8: A Classe SensorType da Ontologia do SIP

A classe WSN, apresentada na Figura 5.9, mapeia as diversas RSSFs que fazem parteda SITRUS. Ela se relaciona com a classe SensorNode a partir de duas propriedades inversas,a hasSensorNode e isSensorNodeOf. Essas propriedades são funcionais e funcionais inversas,respectivamente, ou seja, um nó sensor pode fazer parte de uma única RSSF ao mesmo tempo.

Outro relacionamento existente da classe WSN é com a classe LogicalRegion, a partirda propriedade hasLogicalRegion. Com essa propriedade, que é funcional, garante-se que umaregião lógica pode fazer parte de uma única RSSF.

A classe Measurement, apresentada na Figura 5.10, representa o mapeamento das medi-ções das RSSFs associadas com a SITRUS. Ela se relaciona com a classe SensorNode através de


Figura 5.9: A Classe WSN da Ontologia do SIP

duas propriedades inversas e funcionais, hasSensorNode e isSensorNodeOf.Outra propriedade existente, a hasSensing, diz respeito ao tipo de sensoriamento que

um determinado nó sensor está realizando no momento. Esse relacionamento é realizado com aclasse Sensing.

Dessa forma, a classe Measurement mapeia os dados relativos aos nós sensores e seutipo de sensoriamento de forma direta, mas de forma indireta, através dos seus relacionamentoscom as outras classes, consegue mapear os dados relativos ao tipo de hardware, quem são osvizinhos, qual região lógica e RSSF faz parte um nó sensor e assim por diante.

Além disso, um informação importante é adicionada na classe Measurement, que é ocampo Time, utilizado para identificar o momento em que uma instância foi criada. Com isso,uma consulta pode ser realizada, por exemplo, com os dados dos últimos 5 minutos de umdeterminado nó sensor. Quem define a relevância do tempo para uma determinada consulta é ousuário e não o próprio SIP.

Figura 5.10: A Classe Measurement da Ontologia do SIP


5.3.2 Checagem de Consistência das Classes

Após a construção da ontologia, uma verificação de inconsistências foi realizada. Basica-mente, dois testes foram realizados: o teste de classificação e a checagem de consistência. Oprimeiro envolve teste de hierarquia de classe e se uma classe é uma subclasse de outra classe ounão.

O segundo teste é o teste lógico de checagem de consistência. Baseado na descrição(condições) de uma classe, o raciocinador pode verificar se é ou não possível para uma classe terqualquer instância. Uma classe é considerada inconsistente se ela não possui qualquer instância.Por exemplo, se duas classes são definidas como disjuntas e uma terceira classe é consideradaser subclasse de ambas, então é impossível ter uma instância dessa subclasse, assim, resultandoem erro de consistência lógica.

Em ambos os testes realizados na ontologia, verificou-se que ela é livre de inconsistências.

5.4 Implementação

O desenvolvimento do Módulo de Processamento Semântico da Informação (SIP) foirealizado usando uma proposta de customização e extensão do projeto de forma simples. Destaforma, toda a implementação segue a arquitetura proposta para o SIP.

Para o desenvolvimento do projeto, foi utilizada a ferramenta Protégé2 (NOY; MCGUIN-NESS, 2001) para o desenvolvimento da ontologia, o framework Jena (YU, 2014; MCBRIDE,2002) para manipulação das instâncias da ontologia e Java como linguagem de programação domódulo.

5.4.1 Componente de Comunicação

Seguindo o desenvolvimento do SIP, a Figura 5.11 apresenta o diagrama de classes UMLdo Componente de Comunicação.

O Componente de Comunicação é responsável pela transferência e aquisição de dados.Assim, toda a parte de comunicação com a RSSF é realizada por esta camada. Ela também éresponsável por enviar os dados recebidos para a Camada Semântica da arquitetura do SIP ereceber dessa camada a mensagem de reconfiguração que será enviada para a RSSF. O código deenvio de mensagens para reconfiguração de um nó sensor específico é apresentado na Figura5.12.

Como pode ser observado na linha 3 do código, uma mensagem de reconfiguração,encapsulada pelo método getMessage, é enviado ao nó sensor passado como parâmetro pelométodo sendMessageToSensors.

2Disponível em http://protege.stanford.edu/


Figura 5.11: Diagrama de Classes UML do Componente de Comunicação

1 p u b l i c vo id sendMessageToSensors ( i n t sensorNode ) {2 t r y {3 mote . send ( sensorNode , ge tMessage ( ) ) ;4 } ca tch ( IOExcep t ion ex ) {5 Logger . g e t L o g g e r ( DataManager . c l a s s . getName ( ) ) .6 l o g ( Leve l . SEVERE , nul l , ex ) ;7 }8 }

Figura 5.12: Código Utilizado para Envio de Mensagens de Reconfiguração

Para realizar essas operações de transmissão e recepção dos dados, a classe MoteIF, quefaz parte da TinyOS API, fornece uma interface de alto nível, através de porta serial, conexãoTCP ou qualquer outro meio de conectividade. O uso padrão dessa classe é registrar um ou maisobjetos MessageListener, que serão acionados sempre que uma nova mensagem for recebida. Aclasse que instancia o objeto MoteIF, registra os objetos MessageListener e cuida do envio erecepção de mensagens para a rede é a classe DataManager.

A classe Message, que é mais uma classe da TinyOS API, é responsável por codificar edecodificar as mensagens enviadas e recebidas. Como ela possui métodos de escrita e leiturapara manipulação de bits, a classe ApplicationMsg a estende e se utiliza de seus métodos paramanipular os bits do payload da RSSF. A classe ApplicationMsg também possui métodos gets esets de todos os campos do payload, para facilitar a manipulação dos dados. Por conta disso,RSSF com payloads diferentes tem classes ApplicationMsg também diferentes.

Já a classe abstrata AbstractScenario configura o cenário de utilização do SIP, ou seja,cria as instâncias e disponibiliza métodos que serão usados no processo de medição, paraenvio, recepção e processamento das mensagens, que são os métodos receiveMeasurements econfigMeasurements.


Por fim, a classe abstrata DataManager implementa a interface MessageListener, sendoportanto a classe que intercepta a comunicação de dados entre o SIP e as RSSFs. Nessa classese encontram todos os métodos responsáveis pela manipulação de dados e reconfiguração, porexemplo, o método de reconfiguração da taxa de amostragem, apresentado na Figura 5.13. Essemétodo configura a taxa de amostragem mas não envia a mensagem de reconfiguração. Atransmissão somente é realizada pelo método sendMessageToSensors, apresentado pela Figura5.12, também da classe DataManager.

1 p u b l i c vo id s e t P e r i o d i c S a m p l i n g ( i n t pSampl ing ) {2 ge tMessage ( ) . s e t _ s a m p l i n g ( pSampl ing ) ;3 ge tMessage ( ) . s e t _ s i p M e s s a g e ( ( s h o r t ) 3 ) ;4 }

Figura 5.13: Código Utilizado para Reconfiguração da Taxa de Amostragem


A Camada Semântica é responsável pela implementação e manipulação da ontologia emJava. Esta implementação inclui interfaces e métodos para manipular de forma eficiente todasas propriedades, regras, axiomas e relacionamentos criados para todas as classes das ontologiaproposta.

A Camada Semântica é responsável também pelo uso do motor de inferência, com opropósito de inferir novos dados a partir dos dados coletados. Além disso, é responsável pelacomposição e manipulação de consultas dos dados armazenados na base de dados semântica.Com base nesses dados consultados é que a tomada de decisões a respeito dos nós sensores érealizada.

Todas as classes de ontologia desenvolvida para o SIP foram mapeadas em classesJava, apresentada pela Figura 5.14, facilitando assim o seu acesso e manipulação de dados. Asinterfaces que representam as classes da ontologia estendem a interface OWLIndividual, queé uma interface que representa um indivíduo ou instância de uma classe OWL. As interfacesdesenvolvidas e suas classes de implementação contêm o mesmo nome das classes da ontologia,com métodos para cada uma das propriedades e datatypes que fazem parte dessas classes.

Com todas as classes Java criadas a partir da ontologia, é necessário ter acesso a essesdados, de forma que eles possam ser manipulados. Com isso, a classe MyFactory tem essaresponsabilidade, utilizando a classe OWLModel como auxiliar nessa função. O relacionamentoentre as classes está representado na Figura 5.15.

A OWLModel é a classe que permite acesso a todos os elementos da ontologia emOWL. Dessa forma, a classe MyFactory utiliza a classe OWLModel para criar métodos que dãosuporte a criação de modelos OWL, queries, apagar ou criar recursos de vários tipos e utilizaros objetos retornados pelo OWLModel para operações específicas da ontologia em OWL. Um


Figura 5.14: Diagrama UML da Classe OWLIndividual

Figura 5.15: Diagrama UML das Classes MyFactory e OWLModel

código utilizado pela classe MyFactory, através do método getSensorNode, para recuperação deuma instância específica da classe SensorNode, é apresentado na Figura 5.16.

1 p u b l i c SensorNode ge tSenso rNode ( S t r i n g name ) {2 RDFResource r e s = owlModel . getRDFResource (3 OWLUtil . g e t I n t e r n a l F u l l N a m e ( owlModel , name ) ) ;4 i f ( r e s == n u l l ) { re turn n u l l ; }5 i f ( r e s i n s t a n c e o f SensorNode ) {6 re turn ( SensorNode ) r e s ;7 } e l s e i f ( r e s . h a s P r o t e g e T y p e ( g e t S e n s o r N o d e C l a s s ( ) ) ) {8 re turn new D e f a u l t S e n s o r N o d e ( owlModel , r e s . ge tFrameID ( ) ) ;9 }

10 re turn n u l l ;11 }

Figura 5.16: Código Java para Recuperar Uma Instância Específica da ClasseSensorNode

Com o objetivo de agregar todas as classes da ontologia em uma única classe Java, foidesenvolvida a classe Ontology, apresentada na Figura 5.17. Nessa classe, existem métodos paraler a ontologia a partir de seu arquivo OWL, salvar a ontologia com suas instâncias geradas a


partir de uma RSSF em um novo arquivo OWL e ter um acesso mais simplificado ao modeloOWL a partir da classe JenaOWLModel, uma implementação da classe OWLModel utilizando oframework Jena.

Figura 5.17: Diagrama UML da Classe Ontology

Utilizando-se de toda a infraestrutura criada para manipulação de ontologias, a classeOntologyQueries agrega todas as consultas utilizadas dentro do SIP, por exemplo, a apresentadapela Figura 5.18. Esta consulta em SPARQL é usada para determinar os dados de medição deum nó sensor. Um resultado como este é utilizado para a tomada de decisões sobre nós sensores.

1 S e l e c t ? x1 ? v a l u e2 Where {3 ? x1 ? y1 or : Measur ing .4 ? x1 or : v a l u e ? v a l u e .5 ? x1 or : hasSensorNode or : Node6 }

Figura 5.18: Código SPARQL para Determinar os Dados de Medição de um Nó Sensor

Uma parte importante do Módulo de Processamento Semântico da Informação é a suamáquina de raciocínio. Sua implementação foi baseada nas APIs do Protégé e do framework Jena.A classe SIPReasoner, que implementa os métodos para a máquina de raciocínio desenvolvidapara o SIP, oferece métodos para verificação de consistência da ontologia, classificação, bemcomo métodos para obter informação inferida por uma entidade OWL particular. O diagramade sequencia da classe SIPReasoner é apresentado na Figura 5.19, a partir do seu métodostartReasoner.

Existe a possibilidade de uso de vários raciocinadores diferentes usando a mesma API doProtégé, mas no caso específico do SIP, foi utilizado o raciocinador Pellet (SIRIN et al., 2007),


Figura 5.19: Diagrama de Sequência da Classe SIPReasoner e do Método startReasoner

um mecanismo de inferência específico em OWL DL, desenvolvido em Java e de código aberto.Ele tem uma implementação baseada no algoritmo de Tableaux, um método formal oriundo dalógica de primeira ordem. O Pellet dá suporte à especificação de tipos de dados que podem serdefinidos pelo usuário, incorpora heurísticas para detecção de ontologias OWL Full na tentativade expressá-las com OWL DL e identifica axiomas que causam inconsistências entre conceitos.

Para utilizar a classe de raciocínio, o primeiro passo é obter uma instância da classeProtegeReasoner a partir de um modelo OWL, fornecido pela classe Ontology. Essa instânciado raciocinador pode então ser usada para obter informações inferidas sobre o modelo. A fimde obter uma instância da classe ProtegeReasoner para um modelo OWL, a classe Reasoner-

Manager, que é uma classe singleton, precisa ser instanciada, e em seguida, executar o métodocreateProtegeReasoner para criar a instância do raciocinador.

Com o raciocinador instanciado e inicializado, a partir da utilização das classe SIPRe-

asoner, as consultas realizadas podem utilizar dados de conhecimento imediato ou optar porrealizar essas consultas a partir de conhecimento derivado, ou seja, conhecimento obtido atravésde inferência sobre o conhecimento imediato disponível.

Com toda a infraestrutura criada para manipular os dados da ontologia, o próximo passoseria receber os dados das RSSFs e instanciá-los. A classe responsável por essa tarefa é a classeScenario. Essa classe recebe os dados do Componente de Comunicação e associa os valoresrecebidos às classes adequadas da ontologia. O método receiveMeasurements é o responsávelpela instância desses dados, como pode ser observado na Figura 5.20.

5.4.3 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 acriação de novas instâncias. A escolha desse método para armazenar a base de dados semântica


1 p u b l i c vo id 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 Onto logy o n t o l o g y = Onto logy . g e t I n s t a n c e ( ) ;3 MyFactory o n t o l o g y F a c t o r y = new MyFactory ( o n t o l o g y . ge tModel ( ) ) ;4 Date d a t e = new Date ( ) ;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 ( ( SensorNode ) 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 ( " Measur ing_ " + measurementNumber + + ) ) ;18

19 o n t o l o g y . ge tMeasurement ( ) . addHasSens ing ( 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 . ge tMeasurement ( ) . addHasSensorNode (21 o n t o l o g y . ge tSenso rNode ( ) ) ;22 o n t o l o g y . ge tMeasurement ( ) . addValue ( msg . g e t _ d a t a ( ) ) ;23 o n t o l o g y . ge tMeasurement ( ) . addTime ( d a t e . ge tTime ( ) ) ;24 }

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

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


Este capítulo apresentou o Módulo de Processamento Semântico da Informação (SIP) daSITRUS, 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 basede dados semântica gerada é utilizada para as consultas e tomada de decisões no processo dereconfiguração dos nós sensores.

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

Com os conceitos que foram considerados relevantes para o desenvolvimento da SITRUS,


em especial os mecanismos de reconfiguração e economia de energia, foi apresentada a ontologiadesenvolvida 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 suascaracterísticas e capacidades.

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

A utilização de ontologias em conjunto com um projeto para RSSF se mostra bastanteinteressante, pois os dados consultados não sofrem mais problemas de ambiguidades ou falsopositivo/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 todoo processamento de tomada de decisão é realizado fora da RSSF, pelo SIP, deixando os nóssensores livres para processamento de suas funções internas.

818181

6Avaliação Experimental

Como as aplicações para Rede de Sensores Sem Fio (RSSF) devem criar condiçõespara realização de suas atividades de sensoriamento e processamento o maior tempo possível, oobjetivo desta avaliação experimental é apresentar o consumo de energia em diversas aplicaçõescom diferentes níveis de processamento interno, em cenários onde se utilizam a aplicação originale 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 deenergia 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, asdiferentes 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 ummote 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 viarádio frequência a um nó sensor com uma base MIB520, que funcionava como estação base eque estava conectada diretamente ao PC com o SIP instalado.

Para realizar os experimentos, foi utilizada uma abordagem sistemática para medirde 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 comocomponentes um osciloscópio (Agilent DSO03202A), usado para medir a variação de tensão deum nó sensor, e uma fonte de energia (iCEL Manaus PS-5000), para garantir sempre a mesmavoltagem durante a execução dos experimentos.

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

1O datasheet do mote MICAz está disponível em: http://www.memsic.com/products.html

6.1. PROCEDIMENTO DE MEDIÇÃO 82

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, transmitindoe 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 outrascoisas). Com esses dados, é possível calcular o tempo médio de execução, o consumo de energiae 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çãooferecidos 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 prontopara execução, mas sem iniciar ainda o processo de medição (linha 3 e linha 4); configurar aaplicação no nó sensor (linha 5 e linha 6), para que o processo de medição sempre comece comas mesmas configurações; e só depois disso, dar início ao processo de medição (linha 9 e linha10).

Todas as aplicações executadas nos nós sensores iniciaram com o mesmo tempo de taxade 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 vo id Measurements ( long t ime , i n t p e r i o d i c S a m p l i n g ) {2 t r y {3 da taManager . stopAmalghma ( ) ; / / Leds l i g a d o s4 da taManager . sendMessageToSensors ( ) ;5 da taManager . 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 da taManager . sendMessageToSensors ( ) ;7 Thread . s l e e p ( 5 0 0 ) ;8

9 da taManager . s t a r tAmalghma ( ) ; / / Leds d e s l i g a d o s10 da taManager . sendMessageToSensors ( ) ;11 Thread . s l e e p ( t ime ) ; / / Tempo do e x p e r i m e n t o12 da taManager . stopAmalghma ( ) ; / / Leds l i g a d o s13 da taManager . sendMessageToSensors ( ) ;14

15 } ca tch ( I n t e r r u p t e d E x c e p t i o n ex ) {16 Logger . 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 ( Leve l . SEVERE , nul 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 asmudanç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 oconsumo de energia para diferentes cenários se torne evidente, além da adequação do tempo demedição com a janela de medição do osciloscópio.

O consumo de energia é uma média de consumo de 100 experimentos realizados paracada 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 fimde verificar se a média da diferença entre eles é zero, ou seja, os consumos de energia eramiguais. Quando o valor de p-value é menor que 0,05, a hipótese nula é rejeitada, indicando que osresultados 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çaentre 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 nasaplicações de exemplo do TinyOS2

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

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

2Aplicações do TinyOS disponíveis em: http://www.tinyos.net/tinyos-2.x/apps/

6.2. RESULTADOS 84

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

� Aplicação + RAMSES: A mesma aplicação é executada utilizando os serviços doRAMSES. Assim, toda a transmissão de dados entre os nós sensores e os serviçosde reconfiguração são garantidos pelo middleware, de forma transparente para aaplicação. A aplicação fica responsável apenas pela coleta e transmissão de dados apartir 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çosde reconfiguração, nenhuma é realizada. Este cenário serve para avaliar o impacto dese adicionar o RAMSES em uma aplicação.

� Aplicação + SITRUS: Neste cenário, a SITRUS é utilizada em sua totalidade. ORAMSES utiliza seu gerenciamento de energia baseado na interface Low Power

Listening, ligando e desligando a antena periodicamente para evitar o consumodesnecessário de energia, mas com tempo suficiente para detectar uma portadora ereceber ou enviar todo o pacote que deseja. Além disso, todos os dados são enviadospara o SIP, de forma que os dados sejam armazenados na base de dados semântica eos 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, ouseja, caso os valores fossem redundantes, a taxa era aumentada. Essa verificação ocorria a cada 1minuto 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 assimuma melhor eficiência no consumo de energia. Esse comportamento pode ser observado a partirde trace apresentado pela Figure 6.3.

Para todos os cenários, as informações enviadas para o Módulo de ProcessamentoSemâ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çõesserão utilizadas para instanciar a ontologia, e com isso, servir de base para as consultas sobre oestado 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 umabreve descrição apresentando suas características e como elas foram alteradas para se adaptar ao

6.2. RESULTADOS 85

1 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 250 A g g r e g a t i o n : 0 SIP : 02 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 250 A g g r e g a t i o n : 0 SIP : 03 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 250 A g g r e g a t i o n : 0 SIP : 04 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 250 A g g r e g a t i o n : 0 SIP : 05 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 250 A g g r e g a t i o n : 0 SIP : 06 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 250 A g g r e g a t i o n : 0 SIP : 07 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 250 A g g r e g a t i o n : 0 SIP : 08 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 250 A g g r e g a t i o n : 0 SIP : 09 A l t e r a n d o t a x a de amostragem . . .

10 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 500 A g g r e g a t i o n : 0 SIP : 011 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 500 A g g r e g a t i o n : 0 SIP : 012 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 500 A g g r e g a t i o n : 0 SIP : 013 Se ns o r : 01 Tempera tu r e : 28 Sampl ing : 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 dadosque se encontra nos exemplos do TinyOS3. Ela mantém um contador que é incrementado acada 250 ms, transmitindo o seu valor em um pacote sempre que seu valor é atualizado. Alémda função de transmitir os dados da contagem, seus 3 LEDS são utilizados para sinalizar atransmissão, recepção ou algum tipo de erro. Uma característica dessa aplicação é que ela nãoutiliza 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çãodo 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 oscomponentes 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 eCC2420ActiveMessageC, que são responsáveis pelos serviços de middleware e pelo controle deenergia 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 apresentadosna Figura 6.5. Como pode ser observado, mesmo com a inclusão do middleware RAMSES naaplicação, o consumo de energia se mostrou praticamente o mesmo, mostrando assim que ele

3Aplicação RadioCountToLeds disponível em: http://www.tinyos.net/tinyos-2.x/apps/RadioCountToLeds/

6.2. RESULTADOS 86

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


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ádiofrequê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 ogerenciamento de energia também a partir do uso da interface Low Power Listening, além douso da reconfiguração da taxa de amostragem em tempo de execução, a redução do consumo deenergia foi de 69,10%. Mesmo sendo uma aplicação simples, a redução do consumo de energiafoi significativa.

O teste de hipótese entre as amostras da aplicação pura e sua versão com a SITRUS foirealizado, 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 suficientespara mostrar que os dois resultados são diferentes.

6.2. RESULTADOS 87

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

Aplicação RadioCountToLeds

Co

nsu

mo

de

En

erg

ia (

Jo

ule

s)

0

1

2

3

4

2.97970773 2.97581227

0.920842609

Figura 6.5: Consumo de Energia para a Aplicação RadioCountToLeds Utilizando osCená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 de128KB (interna ao microcontrolador ATmega128L) para memória de programas. Já a RAM doATmega128L é 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çãoRadioCountToLeds original ocupa 7,84% de RAM e 9,66% de ROM do mote MICAz. Já osvalores de memória utilizados pelo pela aplicação em conjunto com o RAMSES mostram que oconsumo de RAM é de 10,47% e de ROM 9,85%. Essa aumento de consumo ocorre devido aintroduçã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) % ROMRadioCountToLeds 321 7,84 12.660 9,66RadioCountToLeds + RAMSES 429 10,47 12.904 9,85RadioCountToLeds + 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 conjuntoe 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

6.2. RESULTADOS 88

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 desoftware oferecidos às aplicações.

6.2.2 Aplicação RadioSenseToLeds

A segunda aplicação avaliada, a RadioSenseToLeds4, faz amostragem do ambiente apartir de um sensor padrão utilizado pela plataforma de sensoriamento, gerando e transmitindo osdados 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çãoanterior. Dessa forma, existe consumo de energia pela transmissão de dados, processamentointerno e pelo subsistema de sensoriamento. Essa aplicação é útil para demonstrar comofuncionam os mecanismos de comunicação, temporizadores e o subsistema se sensoriamentopadrão do TinyOS.

O diagrama de componentes, apresentado na Figura 6.6, mostra como seus componentesse relacionam para formar a aplicação, bem como a diferença entre sua versão original e aquelacom 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.


Os resultados do consumo de energia em todos os cenários utilizados para a aplicaçãoestão sumarizados na Figura 6.7. Como pode ser observado, a aplicação original e sua versãocom o RAMSES não tem uma diferença significante em relação ao consumo de energia, comvalores sendo quase os mesmos. Dessa forma, mostra que o RAMSES consegue adicionarserviç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 SITRUSsendo executada apresentou uma diferença significativa, com uma redução no consumo deenergia de 71,25%. Esse resultado se justifica pela utilização dos componentes de baixo consumode 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 purae 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−16 no teste. Assim, conclui-se queexistem evidências suficientes para mostrar que os dois resultados são diferentes.

4Aplicação RadioSenseToLeds disponível em: http://www.tinyos.net/tinyos-2.x/apps/RadioSenseToLeds/

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


LowPowerListening

(b) Aplicação RadioSenseToLeds com o RAMSES

Figura 6.6: Componentes da Aplicação RadioSenseToLeds com e sem o Middleware


A Tabela 6.2 apresenta os valores de utilização de memória da aplicação RadioSenseTo-

Leds em 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 dememória obtidos da aplicação com o RAMSES mostram que o consumo de RAM é de 11,99% ede ROM 10,45%, com 491 e 13.702 bytes, respectivamente. Assim como ocorreu na aplicaçãoanterior, essa aumento do consumo ocorre devido à introdução das camadas do RAMSES naaplicação.

Tabela 6.2: Utilização de Memória da Aplicação RadioSenseToLeds

RAM (bytes) % RAM ROM (bytes) % ROMRadioSenseToLeds 331 8,08 13.496 10,30RadioSenseToLeds + RAMSES 491 11,99 13.702 10,45RadioSenseToLeds + 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óriaobtidos passaram a ser de 13,33% de RAM e 11,88% de ROM, com valores de 546 e 15.566bytes, respectivamente.

Assim como ocorreu na aplicação anterior, mesmo com um aumento de consumo de RAMe ROM, existe espaço suficiente para a inclusão de novos serviços e diferentes implementações

6.2. RESULTADOS 90


Aplicação RadioSenseToLeds

Co

nsu

mo

de

En

erg

ia (

Jo

ule

s)

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 devolvero 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 deconversão para Celsius são fontes extras de consumo de energia. Além disso, a sinalização detransmissã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 dossensoriamentos, mecanismos de comunicação e temporizadores.

O diagrama de componentes da aplicação Temperatura é apresentado na Figura 6.8. Porela, pode ser observada a utilização do componente TempC, que é o componente utilizado paracapturar 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 componenteMiddlewareC, além da adição do componente CC2420ActiveMessageC, para controle de energiana 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


LowPowerListening

(b) Aplicação Temperature com o RAMSES

Figura 6.8: Componentes da Aplicação Temperature com e sem o Middleware


Os resultados da avaliação do consumo de energia da aplicação Temperature estãosumarizados na Figura 6.9. Por utilizar mais processamento interno no processo de conversãopara graus Celcius e por utilizar um sensoriamento de temperatura, seus resultados mostramum consumo de energia maior se comparado às aplicações anteriores. Ainda assim, o mesmocomportamento apresentado anteriormente se repete, ou seja, a adição do RAMSES na aplicaçãooriginal, com todas as suas camadas e serviços disponíveis, tem um custo de energia muito baixose comparados os dois cenários.

Já a comparação da aplicação original com sua versão utilizando toda a SITRUS mostrauma diferença significativa de consumo de energia, com uma redução de 70,79%. Essa reduçãoocorre devido ao uso dos serviços de reconfiguração implementados no RAMSES, com tomadasde decisões no SIP, além da utilização da interface Low Power Listening para comunicação a umcusto energético mais baixo.

O teste de hipótese realizado entre as amostras da aplicação Temperature e sua versãocom a SITRUS evidencia que os dois resultados são diferentes, com um p-value apresentandoum valor menor que 2,2*10−16 no teste. Assim, conclui-se que existem evidências suficientespara mostrar que os dois resultados são diferentes.

6.2. RESULTADOS 92


Aplicação Temperature

Co

nsu

mo

de

En

erg

ia (

Jo

ule

s)

0

1

2

3

4 3.87207392 3.86481869

1.13111803

Figura 6.9: Consumo de Energia para a Aplicação Temperature


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 e16.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, oconsumo passou a ser de 555 bytes de RAM e 17.098 de ROM, ocupando 13,55% e 13,04 dacapacidade total de bytes, respectivamente.

Tabela 6.3: Utilização de Memória da Aplicação Temperature

RAM (bytes) % RAM ROM (bytes) % ROMTemperature 368 8,98 16.786 12,81Temperature + RAMSES 555 13,55 17.098 13,04Temperature + 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 610e 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ãode novos serviços e diferentes implementações dos serviços já existentes no middleware, comomostra 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 dadoscoletados 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, masapenas 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 pelaaplicaçã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 doconjunto de 10 amostras e o sensoriamento de luminosidade. Essa aplicação difere das demaispois, ao invés de enviar apenas uma amostra coletada, a aplicação envia um conjunto com 10amostras, 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


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 aluminosidade do ambiente. Da mesma forma que ocorreu com todas as aplicações anteriores, oscomponentes 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 controlede energia na transmissão de dados, em sua versão do RAMSES.

5Aplicação Oscilloscope disponível em: http://www.tinyos.net/tinyos-2.x/apps/Oscilloscope/

6.2. RESULTADOS 94


Os resultados de consumo de energia para todos os cenários propostos da aplicaçãoOscilloscope estão sumarizados na Figura 6.11. Como pode ser observado, mesmo com ainclusã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 Oscilloscope

Co

nsu

mo

de

En

erg

ia (

Jo

ule

s)

0

1

2

3

43.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 aSITRUS obteve uma considerável redução no consumo de energia, desta vez com 86,33% deeconomia em relação a aplicação original. Essa diferença ocorre pela forma como os dadossão processados. Enquanto a aplicação original coleta 10 amostras e envia o conjunto de dadoscoletados, a aplicação com a SITRUS agrega esses dados em um único dado, diminuindo assima 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 paramostrar que os dois resultados são diferentes.

6.2. RESULTADOS 95


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 e15.104 bytes de memória ROM, ocupando 9,72% e 11,52%, respectivamente, da capacidadetotal do MICAz. Com a inclusão do RAMSES na aplicação original, o consumo passou a ser de476 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) % ROMOscilloscope 398 9,72 15.104 11,52Oscilloscope + RAMSES 476 11,62 14.920 11,38Oscilloscope + 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 deROM 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 diferentesimplementações dos serviços já existentes no RAMSES, como mostra a tabela de utilização dememó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 emambientes. Para detectar se um ladrão se encontra em um ambiente, o nó sensor que executa aaplicação identifica o nível de luz do ambiente (se luz do ambiente não existe, significa que essenó sensor foi roubado e que foi colocado em um lugar escuro, ou seja, está dentro do bolso ouuma mochila, provavelmente) ou pela aceleração (um nó sensor roubado é um nó sensor que semovimenta). Para reportar um roubo, o nó sensor liga o LED vermelho como alerta, emite umsom 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: Oprotocolo Dissemination, que dissemina um valor para todos os nós da RSSF, e o protocoloCollection, 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 sensoriamentoespecífico sendo executado a mesmo tempo, diferentes protocolos de rede trabalhando emconjunto e a ação de temporizadores.

O diagrama de componentes da aplicação AntiTheft é apresentado pela Figura 6.12. Nelapode ser observada a utilização dos componentes PhotoC e SounderC, que são os componentes demonitoramento de luminosidade e alerta sonoro. O componente AccelXStreamC é o componente

6.2. RESULTADOS 96

AntiTheftC

MainC

Boot

TimerMilliC(MyTimer)

Timer<TMilli>

LedsC

Leds

ActiveMessageC

SplitControl


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


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 doRAMSES, 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.


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 aproveitamentode 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. Quandose adicionam as camadas de middleware à aplicação original e se trocam os mecanismos decomunicaçã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%. Essaredução ocorre devido ao modelo de distribuição utilizado, pelo serviços de reconfiguraçãoimplementados no RAMSES com tomadas de decisões no SIP e pela utilização de mecanismosde 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 aSITRUS evidencia que os dois resultados são diferentes, com um p-value apresentando um valormenor que 2,2*10−16 no teste realizado. Assim, conclui-se que existem evidências suficientespara mostrar que os dois resultados são diferentes.

6.2. RESULTADOS 97


Aplicação AntiTheft

Co

nsu

mo

de

En

erg

ia (

Jo

ule

s)

0

1

2

3

4 3.77874253.63197084

0.80185279

Figura 6.13: Consumo de Energia para a Aplicação AntiTheft


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 quemais utilizou recursos de memória RAM e ROM. A aplicação original utiliza 1708 bytes dememó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 paradesenvolver a aplicação, como pode ser observado pela Figura 6.12a. Com a introdução de novoscomponentes 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 de14,14% de RAM e 13,68% de ROM. Essa redução ocorreu devido substituição dos componentesda aplicação original pelos componentes utilizados pelo RAMSES, o que demonstra que mesmocom a introdução de novas camadas de software, a memória RAM e ROM tem um consumobaixo de recursos utilizados.

Já com toda a SITRUS sendo utilizada, temos um aumento de consumo de memória emrelação a sua versão com o RAMSES, mas ainda assim, um consumo menor se comparado coma 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.

Mesmo sendo uma aplicação mais complexa e que utiliza mais recursos que as aplicações


Tabela 6.5: Utilização de Memória da Aplicação AntiTheft

RAM (bytes) % RAM ROM (bytes) % ROMAntiTheft 1708 41,70 26.310 20,07AntiTheft + RAMSES 579 14,14 17.928 13,68AntiTheft + 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çosjá existentes para o RAMSES, como mostra a ocupação total de memória apresentado pela Tabela6.5.


Este capítulo apresentou a avaliação experimental que analisa o consumo de energia de5 aplicações a partir da SITRUS. No início do capítulo foi apresentada uma visão geral dosexperimentos que seriam realizados. Em seguida, foi apresentado o procedimento sistemático demedição em conjunto com a metodologia aplicada para os experimentos, com o funcionamentodas aplicações a serem testadas e os diferentes cenários que seriam medidos. Por fim, osresultados dos experimentos foram apresentados, com a discussão de seus resultados.

As aplicações utilizadas nos experimentos, diferem tanto no nível de processamentointerno, nos mecanismos de sensoriamento e nos mecanismos de transmissão de dados, que sãoos 3 fatores que mais contribuem para o consumo de energia.

Dessa forma, este experimentos serviram para apresentar que a SITRUS tinge o objetivoproposto 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 emuma taxa constante com a antena sempre ligada, além dos benefícios da utilização de serviços demiddleware em aplicações e semântica nos dados transmitidos pela rede.

999999

7Trabalhos Relacionados

Este capítulo apresenta os principais trabalhos na área de ontologia, middleware paraRede de Sensores Sem Fio (RSSF) e mecanismos para reconfiguração de software em aplicaçõespara RSSF. Estes trabalhos estão classificados e apresentados de acordo com alguns dos diferentestipos de middleware, dos trabalhos relacionados com ontologia em RSSFs e dos sistemas dereconfiguraçã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 deaplicaçõ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.

7.1.1 Middleware Orientado a Mensagens

O modelo de comunicação adotado pelos sistemas de middleware orientado a mensagemtem suporte naturalmente assíncrono, permitindo o fraco acoplamento entre transmissores ereceptores. Esta abordagem é adequada em ambientes pervasivos encontrado nas RSSFs, ondemuitas aplicações são baseadas em eventos (HADIM; MOHAMED, 2006a).

Dentre os sistemas de middleware orientados a mensagem encontrados na literatura,temos o Mires (SOUTO et al., 2004; GUIMARAES et al., 2006), que foi construído sobre oTinyOS e usa o mecanismo de mensagens ativas (BUONADONNA; HILL; CULLER, 2001),provido pelo TinyOS para implementar sua infraestrutura de comunicação baseada no modelo pu-

blish/subscribe. A arquitetura do Mires inclui um componente central, o serviço de comunicaçãopublish/subscribe, que coordena a comunicação orientada a mensagens entre os componentesremotos (anúncio de tópicos, manutenção da lista de tópicos e publicação de mensagens), além

7.1. MIDDLEWARE PARA REDES DE SENSORES SEM FIO 100

de intermediar a comunicação entre os demais serviços do middleware, como por exemplo, oserviço de agregação de dados.

A comunicação no Mires ocorre em quatro fases: estabelecimento, anúncio, assinaturae publicação da RSSF. Mensagens de configuração são trocadas com o objetivo de estabelecerrotas para o nó sorvedouro da rede. Essa etapa ocorre logo após a distribuição dos nós narede. O roteamento implementado no middleware é responsável por estabelecer a hierarquia deroteamento e adicionalmente, implementar o algoritmo de roteamento multi-hop utilizado para atroca e mensagens.

Após essa fase, a aplicação anuncia ao componente publish/subscribe sua capacidade demonitorar os dados relacionados a um determinado tópico (e.g., tipo de sensoriamento). Logo emseguida, o componente publish/subscribe dissemina essa informação aos outros nós conforme ahierarquia de roteamento definida na primeira fase. Este nó encaminha a aplicação cliente domiddleware os tópicos anunciados.

Uma vez anunciados os tópicos, inicia-se a fase de assinatura. A aplicação clienteemite uma mensagem contendo os tópicos de interesse e especificando as políticas e funções deagregação desejadas ao nó sorvedouro, que por sua vez, transmite essas informações para toda arede.

Posteriormente, a aplicação inicia a publicação dos dados monitorados. Periodicamente,essa aplicação coleta dados provenientes da leitura dos sensores e invoca o componente pu-

blish/subscribe que notifica os outros serviços (como o serviço de agregação) da chegada dostópicos de interesse assinados pela aplicação cliente. Dessa forma, o Mires apenas encaminhamensagens relacionadas aos tópicos assinados, permitindo com isso, uma diminuição no númerode transmissões e resultando em redução no consumo de energia.

7.1.2 Middleware Baseado em Espaços de Tuplas

Os sistemas de middleware baseados em espaço de tuplas adotam uma memória compar-tilhada, onde a coordenação entre processos é realizada através de um ambiente computacionalchamado espaço de tuplas.

Como exemplo deste tipo de middleware, podemos citar o TS-Mid (CASSIA ACI-OLI LIMA; ROSA; MARQUES, 2008), um middleware para RSSFs baseado em espaço detuplas.

Ao contrário da maioria dos sistemas de middleware, que em geral, centralizam a coletade dados em uma estação base, o TS-Mid visa o cenário em que um grupo de nós da RSSFcolaboram entre si para coleta de informações, processamento e transmissão do resultado parauma estação base. Para isso, o TS-Mid habilita a criação de regiões lógicas dentro das RSSFs.Essencialmente, uma aplicação (em geral, executada em um computador fora da rede) podeobter informações sobre uma região em particular, sem que a requisição seja enviada paratodos os nós da rede. Essas regiões podem ser muito úteis para aplicações de monitoramento,

7.1. MIDDLEWARE PARA REDES DE SENSORES SEM FIO 101

que particularmente requerem atenção especial em algumas regiões da RSSF. Por exemplo,uma aplicação de vigilância pode definir os limites da região como uma unidade crítica a sermonitorada.

O TS-Mid adota a especificação JavaSpaces, que oferece um simples e poderoso modelode coordenação entre os componentes, incluindo operações para escrita e leitura de entidades,juntamente com um mecanismo para notificação de eventos no espaço de tuplas e a possibilidadede criação de serviços JavaSpaces replicados na RSSF.

Com relação a topologia de rede, o TS-Mid define quais nós pertencem à cada regiãológica, e em seguida o nó sorvedouro pode transmitir requisições da aplicação cliente para o nólíder da região. O nó líder é responsável por direcionar as requisições de operações no espaçode tuplas para os outros membros da região, coletando respostas dos membros, processandoe transmitindo o resultado de volta para o nó sorvedouro. A transmissão de dados é semprealcançada através de tuplas em um algoritmo de roteamento one-hop.

7.1.3 Middleware Dirigido à Aplicação

Os sistemas de middleware dirigidos à aplicação têm a característica de permitir aosdesenvolvedores negociarem com a RSSF os requisitos de Qualidade de Serviço (QoS) exigidospela aplicação (HADIM; MOHAMED, 2006a).

Dentre esse tipo de middleware, podemos citar o Middleware Linking Applications and

Networks (MiLAN) (HEINZELMAN et al., 2004). O MiLAN foca em detalhes de alto nível,através de uma interface a qual as aplicações para RSSF definem o mínimo de QoS necessário,e então, ajusta as características da rede para atender a essa qualidade. Por exemplo, númeromínimo de nós sensores que fazem cobertura de uma área. Essa abordagem provê um eficientemecanismo para suportar dinamismo em RSSF e permitir aplicações mais escaláveis.

De forma diferente dos sistemas de middleware tradicionais, os quais se situam entrea aplicação e o sistema operacional, o MiLAN tem uma arquitetura que estende a pilha deprotocolos da rede, cuja finalidade é atender vários tipos de redes, semelhantes à redes IEEE802.11 e redes bluetooth. Para isso, uma camada de abstração é provida, permitindo que pluginspara uma rede específica convertam comandos do middleware para comandos da rede. Com isso,a RSSF pode ser constituída de sensores heterogêneos para prover melhor qualidade de serviçopara aplicação.

7.1.4 Discussão Sobre os Trabalhos

A comparação com os diversos trabalhos encontrados na literatura e que serviram debase para o desenvolvimento do RAMSES se encontra sumarizada na Tabela 7.1.

Como pode ser observado, o RAMSES, assim como o Mires, trabalha com serviços deagregação de dados, comunicação orientada a mensagens, além de tratar do problema de consumode energia, apenas seguindo abordagens diferentes. Enquanto o RAMSES trabalha em conjunto

7.2. ONTOLOGIA EM REDES DE SENSORES SEM FIO 102

Tabela 7.1: Sumário da Discussão sobre Middleware Para Rede de Sensores Sem Fio

Controle de Energia ReconfiguraçãoPré-Processamento

dos DadosProcessamentoFora da RSSF

ProcessamentoSemântico dos Dados

InformaçõesSeletivas

RAMSES * * * * * *Mires * *TS-MID * * * *Milan * *

com o Módulo de Processamento Semântico da Informação (SIP), fazendo a reconfiguraçãoparamétrica dos nós sensores com o processamento da tomada de decisão fora da rede, o Mirestrabalha com mecanismos onde o processamento de assinatura, publicação e anúncio de tópicosé realizado entre os nós sensores, diminuindo o número de transmissões dos dados coletados,mas aumentando o processamento interno.

Ao contrário do que acontece com o TS-Mid, o RAMSES não utiliza um modelo decomunicação baseado em espaços de tuplas, como também não centraliza seus dados em umaestação base. Mas, de forma similar ao TS-Mid, a obtenção de informações pode ser feitapor uma aplicação sendo executada em um computador externo à RSSF, favorecendo assim omonitoramento. Outro ponto em comum é que a obtenção de informações no TS-Mid é seletiva,ou seja, sobre uma região em particular e não sobre a RSSF toda, da mesma forma que ocorre noprocesso de reconfiguração utilizado pelo RAMSES, a partir de mensagens enviadas pelo SIP aum nó sensor em particular.

De forma similar ao MiLAN, o RAMSES adapta continuamente as configurações darede, sempre que necessário. A diferença entre os dois sistemas de middleware está na formacomo eles trabalham para alcançar tal resultado, pois enquanto no MiLAN o processamento éfeito dentro da RSSF, no RAMSES é feito pelo SIP, o que contribui para a economia de energia.

7.2 Ontologia em Redes de Sensores sem Fio

Diversas pesquisas têm sido realizadas na área de ontologia e Web Semântica, maspouca atenção tem sido dada para representação semântica dos dados provenientes de RSSF.A ideia de se utilizar um sistema orientado a ontologia em RSSF surgiu com o trabalho deAVANCHA; PATEL; JOSHI (2004). Com este trabalho, os autores mapearam em uma ontologiacaracterísticas importantes de um nó sensor, que descrevem suas funcionalidades e seu estadoatual, a fim de apresentar uma forma de compreender as mais importantes características dos nóssensores.

O trabalho proposto por AVANCHA; PATEL; JOSHI (2004) serviu de base para diversostrabalhos mesclando RSSF e semântica, mas muitos desses trabalhos usaram ontologias apenaspara prover dados com semântica, construir uma base de dados e melhorar as respostas dasconsultas, mas sem uma preocupação em reutilizar esses dados para melhorias na rede.

As próximas seções apresentam alguns trabalhos desenvolvidos a partir do uso deontologias em RSSF.


7.2.1 SWASN

O trabalho desenvolvido em (HUANG; JAVED, 2008) apresentou o Semantic Web Archi-

tecture for Sensor Networks (SWASN), que propõe o enriquecimento semântico das informaçõesprovenientes de uma RSSF, a fim de que aplicações e serviços possam ser desenvolvidos de formaindependente de uma RSSF em particular. Essa arquitetura, orientada à informação, permiteque os dados sejam entendidos e processados da melhor forma possível por uma variedade deaplicações com diferentes propósitos.

A arquitetura SWASN é dividida em quatro camadas:

a) Camada de dados da RSSF. Essa primeira camada corresponde aos dados proveni-entes de RSSF heterogêneas, com nós sensores e formatos de mensagens diferentesumas das outras.

b) Camada da Ontologia. A segunda camada corresponde à ontologia para nós senso-res. Por essa arquitetura, cada RSSF tem sua própria ontologia, usando termos quedefinem as classes da RSSF de forma global. Essa abordagem permite uma maiorflexibilidade e extensibilidade para outras redes se conectarem a essa arquitetura, sema necessidade de modificação das ontologias locais ou do vocabulário compartilhado.

c) Camada de processamento Web Semântico. A terceira camada interage direta-mente com a camada de ontologia, a partir do framework Jena. Com a utilizaçãodesse framework, os dados mapeados são colocados em memória ou persistidos emuma base de dados, onde são construídos grafos RDF da ontologia, para criação demodelos OWL e manipulação de queries a partir desses dados.

d) Camada de Aplicação. A quarta e última camada dessa arquitetura consiste dediferentes aplicações que se utilizam dos dados da rede. Esses dados processadospodem estar disponíveis através de um Web Service, onde a interação da aplicação évia HTTP.

Essa arquitetura é centrada na descrição de informação para nós sensores, e para darsuporte ao desenvolvimento da arquitetura, várias tecnologias de Web Semântica são utilizadas.

7.2.2 Ontologia Universal para RSSF

No trabalho desenvolvido por EID; LISCANO; EL SADDIK (2007), são apresentadoso desenvolvimento e a avaliação de uma ontologia para buscas distribuídas e heterogêneas emdados de RSSFs.

Eles propuseram um protótipo de ontologia em duas camadas, que utiliza o IEEE

Suggested Upper Merged Ontology (SUMO) (NILES; PEASE, 2001) como base de definição deconceitos gerais e associações. O objetivo é adotar uma ontologia de alto nível, no caso o SUMO,


que irá prover a interoperabilidade, busca e recuperação de informação, inferência automáticae extensibilidade. Diferentes domínios de RSSFs podem definir suas próprias ontologias eassociá-las a ontologia SUMO.

A ontologia proposta nesse trabalho é composta por quatro elementos: A ontologiaSUMO, a Sensor Hierarchy Ontology (SHO), a Sensor Data Ontology (SDO) e a Extension

Plugins Ontologies (EPO). As ontologias SHO e SDO referenciam e estendem a ontologiaSUMO com o objetivo de facilitar a fusão automática de dados e inferência em ambientes desensoriamento distribuídos e heterogêneos.

A ontologia SUMO foi criada pela utilização de conteúdo ontológico em uma estruturaúnica, coesa e geral. O uso de uma ontologia padrão implica em menos ciclos de desenvol-vimento e uma integração mais fácil e rápida com outros conteúdos. A SHO inclui modelosde conhecimento para elementos dos nós sensores, aquisição, processamento e transmissão dedados. A SDO é uma ontologia que tem por objetivo descrever as propriedades dinâmicas e ob-servacionais dos dados dos nós sensores. Esse modelo descreve o contexto de um nó sensor, comconsideração a observações temporais e espaciais. O último elemento é o EPO, um plugin quepermite a integração de ontologias de domínio com ontologias universais. Toda essa abordagempermite uma melhor precisão nas buscas realizadas na RSSF, evitando com isso falsos positivose falsos negativos.

7.2.3 Aplicações de Monitoramento

Dentre as aplicações de monitoramento, uma arquitetura multi-agente para gerenciamentode RSSF foi proposta por GATANI; LO RE; ORTOLANI (2005), onde ontologias são utilizadaspara representar modelos de entidade de software e hardware, que formam a infraestruturade comunicação, eventos e tráfego de rede. Essa arquitetura tem o objetivo de explorar ascaracterísticas intrínsecas das linguagens de programação lógica e metodologias de inteligênciaartificial.

Com o objetivo de produzir um modelo de rede capaz de captar as relações de causa eefeito e eventos dinâmicos, ontologias são utilizadas para incorporar conhecimento detalhadosobre o domínio específico considerado. Com o objetivo de capturar o comportamento dinâmicode rede, programas monitoram os nós sensores, a fim de determinar o estado da rede. Além disso,os nós sensores irão guardar esses valores, que serão acessados por demanda pelo raciocinadorlógico, para se obter um panorama global da rede de resposta a estímulos externos.

Com a utilização de ontologia e lógica de raciocínio, o sistema proposto é capaz derealizar tarefas de gestão de alto nível e lidar com situações incomuns de rede melhor do quesistemas tradicionais de gestão.

Outra aplicação de monitoramento é sobre a utilização de RSSF na prevenção de incên-dios. Índices meteorológicos de fogo são um método amplamente adotada para medir o risco deincêndio e que desempenham um papel significativo na emissão de avisos de incêndios florestais


e na antecipação de demanda por recursos de gerenciamento de incêndios florestais.Os sistemas existentes que calculam índices de tempo de incêndio são limitadas devido

à baixa resolução espacial e temporal. Redes de Sensores Sem Fio, por outro lado, recolhemdados de medição contínua de variáveis como temperatura do ar, umidade relativa, precipitação evelocidade do vento em altas resoluções. No entanto, a utilização de RSSF para estimar índicesde tempo de fogo é um desafio devido a problemas de qualidade de dados, falta de formatos dedados padrão e da falta de acordo sobre limites e métodos de cálculo dos índices meteorológicosfogo.

Na pesquisa desenvolvida por GAO; BRUENIG; HUNTER (2014), os dados provenientesdas RSSFs para monitoramento do ambiente são utilizados para a classificação de perigo deincêndio aplicando tecnologias de Web Semântica para o processamento de fluxos de dados,que permitem que especialistas de domínio especifiquem e adaptem as regras para o cálculo dosíndices de incêndio.

Já em SAWANT; ADINARAYANA; DURBHA (2014), foi utilizada a Web Semânticaem RSSF para aplicações de agricultura de precisão. Com isso, ela permitiu a interoperabilidadeentre diferentes sistemas de sensoriamento padronizados. Atualmente, os sistemas desenvolvidosde monitoramento tem heterogeneidade sintática e semântica, além de enfrentarem limitaçõessubjacentes para assegurar a interoperabilidade entre os sistemas de sensoriamento distribuídos.Assim, foi desenvolvido o KrishiSense, um sistema de monitoramento ciente de semântica paraaplicações de agricultura de precisão, possibilitando a interoperabilidade entre diversos sistemasde sensoriamento.

O KrishiSense age como a interligação entre vários usuários (pesquisadores, agricultorese a comunidade) através de vários protocolos e plataformas Web conectados de forma distribuída,promovendo assim a participação humana no monitoramento.


Os trabalhos que serviram de base para o desenvolvimento de um mecanismo semânticopara trabalhar em conjunto com as Redes de Sensores Sem Fio, provendo reconfiguração emtempo de execução, estão sumarizados na Tabela 7.2.

Tabela 7.2: Sumário da Discussão sobre Ontologia em Rede de Sensores Sem Fio

RepresentaçãoSemântica dos Dados Interoperabilidade

Melhorias nasConsultas

Reaproveitamento do dadospara a RSSF

Preocupação com oConsumo de Energia

SITRUS * * * * *SWASN * *SUMO * * *Gatani et. al. * *Gao et. al. * * *KrishiSense * * *

Assim como a SITRUS, o SWASN trabalha com o enriquecimento semântico dos dadosprovenientes da RSSF, mapeando esses dados em uma ontologia com classes que as definem.

7.3. SISTEMAS ADAPTATIVOS PARA RSSF 106

A diferença entre eles está na forma como esses dados são processados. Na SITRUS, os dadostransmitidos das RSSFs até o Módulo de Processamento Semântico da Informação (SIP) servemcomo base para a tomada de decisões da reconfiguração paramétrica da própria RSSF, enquantoque no SWASN, os dados das RSSFs são trabalhados em um nível mais alto, onde aplicaçõescliente se utilizam desses dados para obter informações das RSSFs, sendo que essa possibilidadetambém existe na SITRUS a partir da Camada de Aplicação proposto na arquitetura.

EID; LISCANO; EL SADDIK (2007) também trabalha com o enriquecimento semânticodos dados, de forma similar à SITRUS, trabalhando com redes diferentes e dados oriundosde fontes distribuídas. Além disso, em ambos os trabalhos existe uma preocupação com umamaior precisão nas buscas. A diferença entre as duas abordagens é que EID; LISCANO;EL SADDIK (2007) trabalham com duas ontologias de domínio, que estendem uma ontologiauniversal, enquanto que na SITRUS apenas uma ontologia de aplicação é utilizada, facilitando aimplementação mas limitando o seu uso, mas com um objetivo maior, que é a reconfiguraçãoparamétrica das RSSFs.

Já GATANI; LO RE; ORTOLANI (2005) trata os dados da RSSF em uma ontologia como objetivo de realizar tarefas de gestão, relações de causa e efeito e eventos dinâmicos na rede,mas sem o intuito de utilizar esses dados como base para uma possível economia de energia daRSSF, como acontece na SITRUS.

Por fim, os trabalhos de GAO; BRUENIG; HUNTER (2014) e SAWANT; ADINA-RAYANA; DURBHA (2014) apresentam formas de como as ontologias em conjunto com asRSSFs podem trabalhar em conjunto de forma efetiva, eliminando problemas de interoperabili-dade e realizando processamento semântico dos dados coletados.

7.3 Sistemas Adaptativos para RSSF

Uma característica interessante para RSSF é a capacidade de reconfiguração em tempode execução. Essa reconfiguração pode ser simples, com a mudança de alguns parâmetros, oucomplexa, com a mudança de toda a aplicação. Muitos estudos tem sido feito com esse intuito,como a elaboração de novos protocolos para habilitar a reconfiguração (BAPAT; ARORA, 2006).

7.3.1 Maté

Maté (LEVIS; CULLER, 2002), um interpretador bytecode construído sobre o TinyOS,propõe um esquema de reprogramabilidade de aplicações a partir de ajustes de parâmetros paraobter atualizações de programas completos. Ele é um componente do TinyOS que é colocado notopo de vários componentes do sistema, dentre eles os nós sensores e a camada de rede.

Os programas desenvolvidos para o Maté são divididos em cápsulas com capacidadepara 24 instruções. Este limite permite que uma cápsula possa ser transmitida em único pacotedo TinyOS, e dessa forma, programas maiores podem ser compostos de múltiplas cápsulas,


facilmente injetáveis na rede. Cada código da cápsula contém informações sobre seu tipo enúmero de versão.

Maté define quatro tipos de código de cápsula: para o envio de mensagens, para recepçãode mensagens, de tempo e de sub-rotinas, que permitem programas mais complexos. Estascápsulas podem se auto propagar através da RSSF a partir de uma simples instrução. Asinstruções contidas nas cápsulas ocultam o modelo assíncrono e o tratamento de concorrência doTinyOS.

Outra característica importante do Maté é sua capacidade de atualização dos programasna rede. Quando esse sistema recebe uma versão mais recente de uma cápsula de um tipoespecífico do que a existente, ele executa a instalação. Após um nó executar a cápsula, ela podeser transmitida para outros nós vizinhos. De tempos em tempos, o novo código é disseminadopela da rede, via broadcast.

7.3.2 Impala

O Impala LIU; MARTONOSI (2003), um middleware adaptável para RSSF, propõeuma camada assíncrona baseada em eventos que utiliza módulos de programas (agentes móveis)compilados em instruções binárias. Ele garante adaptação da aplicação em tempo de execuçãoe pode discernir automaticamente ajustes necessários dos parâmetros ou da aplicação. Novosprotocolos podem ser conectados a qualquer momento e a alternância entre os protocolos podemser realizados sempre que necessário.

O Impala adota um sistema baseado no módulo com um número de versão, onde cadaaplicação contém o seu número. Antes de realizar as atualizações de software, os nós sensoresprimeiro trocam os índice dos módulos dos aplicativos, e em seguida, apenas solicitam osmódulos com mudanças de índice para a transmissão, economizando largura de banda. Ummódulo de programa, que antes de ser transmitido é compilado em instruções binárias, não serávinculado ao programa principal para a instalação até que toda a atualização esteja concluída.

Impala fornece adaptação de aplicações em tempo de execução pelo seu modelo dearquitetura, e garante a segurança contra erros de programação. O middleware Impala temuma abordagem autônoma, é auto-organizável e utiliza mecanismos para escolher e alternarentre protocolos adequados. Ele usa atualizações usando pequenos módulos e apresenta poucasobrecarga de transmissão.

7.3.3 Durin

Durin (MARQUES; SILVA TEÓFILO; ROSA, 2013), um ambiente para apoiar o desen-volvimento, manutenção e implantação de aplicativos para RSSF, tem como objetivo forneceruma solução para atualização de software dos nós sensores em tempo de execução. Ele utilizaum compilador para programação de alto nível para o desenvolvimento de aplicações para RSSF,uma máquina virtual baseada em registros para RSSF, a TinyReef Virtual Machine (MARQUES;


RONAN; ROSA, 2009), além de um gerenciador para enviar atualização de aplicações para osnós sensores.

A TinyReef é uma máquina virtual baseada em registro (register-based) para RSSFconstruída para TinyOS. Por ser uma arquitetura register-based, em vez de um baseado em pilha,programas exigem menos instruções para realizar uma tarefa. Desta forma, o programa torna-semenor, reduzindo o custo interpretação da máquina virtual.

O fluxo de desenvolvimento do Durin consiste nas seguintes etapas, que vão da compila-ção do código à sua interpretação pela máquina virtual:

� O primeiro passo é compilar o código-fonte de uma linguagem em alto nível para alinguagem suportada pelo TinyReef.

� O próximo passo consiste em converter o arquivo gerado pelo compilador em umarquivo mais compacto, removendo partes desnecessárias para a interpretação. Isso éfeito para reduzir a quantidade de dados transmitidos pela rede, diminuindo assim oconsumo de energia.

� Em seguida, existe a transmissão de dados da aplicação a ser interpretada peloTinyReef.

� Por fim, o último passo é a interpretação da aplicação pelo TinyReef.

7.3.4 KSpot+

No trabalho de ANDREOU et al. (2014), os autores desenvolveram um framework queotimiza o uso da RSSF, combinando componentes de balanceamento de carga, minimizaçãode recepção de dados ineficientes e um módulo de processamento de consultas, que utilizaprocessamento semântico.

Para realizar tal tarefa, os autores otimizaram a eficiência da rede através da combinaçãode 3 fatores:

� Balanceamento da topologia da rede, que equilibra a carga de trabalho de cada nósensor através de construção de topologias mais eficientes.

� Módulo de balanceamento de carga, que minimiza as ineficiências de recepção dedados, sincronizando os intervalos de atividade de rede de sensores.

� Módulo de processamento de consultas, que suporta semântica processamento deconsultas semânticas avançadas.


Alguns trabalhos que comentam sobre sistemas adaptativos em Rede de Sensores SemFio foram comparados com a SITRUS e seus resultados foram sumarizados na Tabela 7.3.


Tabela 7.3: Sumário da Discussão sobre Sistemas Adaptativos para Rede de SensoresSem Fio

Toda a AplicaçãoReconfiguração

ParamétricaReconfiguração

por MódulosProcessamentoFora da RSSF

ProcessamentoSemântico dos Dados

Preocupação com oConsumo de Energia

SITRUS * * * *Maté * * *Impala * * *Durin * * *KSpot+ * * *

Assim como o Maté, a SITRUS suporta adaptação dinâmica a partir de ajustes deparâmetros e tem uma preocupação com a economia de energia. Mas, diferentemente do Maté, aadaptação na SITRUS pode ser feita de forma individual nos nós da rede, e não apenas da redecomo um todo.

O Impala é um middleware adaptativo, assim como o RAMSES. A diferença entreambos está na forma da atualização. Enquanto no Impala existe a possibilidade da mudançacompleta da aplicação, através da transmissão de seus módulos pela rede, no RAMSES só existea possibilidade da mudança de parâmetros da aplicação ou do próprio middleware. No entanto, oImpala não suporta heterogeneidade em termos de plataforma de hardware, sendo projetadaspara executar apenas em HP/Compac iPAQ Pocket executando Linux.

O Durin utiliza uma máquina virtual, a TinyReef, para auxiliar na atualização de softwareque ocorre em tempo de execução. A utilização de uma arquitetura baseada em registros torna asaplicações menores, mas com um processamento mais alto para decodificação das instruções emrelação à utilização de uma arquitetura baseada em pilha. Como a codificação para o TinyReef érealizada fora da RSSF e transmitida pelo gerenciador, o processo torna-se menos dispendiosopara a RSSF. O Durin e a SITRUS se assemelham no objetivo de reconfigurar o nó sensor emtempo de execução e de ter parte do seu processamento fora dos nós sensores, mas trabalhandode formas distintas para realizarem seus objetivos.

Por fim, no KSpot+, mesmo com um ganho nas reduções de consumo de energiaapresentados na pesquisa, todas as etapas para economia de energia são processadas pelos nóssensores, além de que a ontologia apenas é utilizada para realização das consultas, sem utilizá-lapara reconfigurar a rede.


Este capítulo apresentou os principais trabalhos relacionados com a SITRUS. Diversostrabalhos foram apresentados e as principais características descritas. Por fim, estes trabalhosforam comparados, ressaltando-se as principais diferenças entre eles.

110110110

8Conclusão e Trabalhos Futuros

Este capítulo apresenta as conclusões e as principais contribuições dessa tese, bemcomo seus aspectos mais relevantes. Além disso, serão destacadas as limitações existentes e ostrabalhos futuros a serem realizados em cima dessa linha de pesquisa.

8.1 Conclusão

Este trabalho apresentou um mecanismo de economia para Rede de Sensores Sem Fio(RSSFs) baseado em uma infraestrutura semântica, chamada de SITRUS. Ela tem por obje-tivo reduzir o consumo de energia a partir do uso de um middleware orientado a mensagenscom serviço de reconfiguração paramétrica, chamado de RAMSES, e do Módulo de Processa-mento Semântico da Informação, chamado de SIP. Com SITRUS, os dados tem enriquecimentosemântico e compartilhamento de dados sem ambiguidades a partir do uso de ontologias.

O RAMSES é o responsável pelo transporte de dados dos nós sensores, que são enviadospara o SIP para instanciação e processamento correto na ontologia desenvolvida para a SITRUS.O RAMSES é a parte da infraestrutura que controla todo o software executado nos nós sensorese além disso, cuida dos mecanismos de distribuição de dados, que é baseado em um modelopublish/subscribe. Quanto ao SIP, é um módulo usado para comunicação entre as RSSFs e aparte semântica da infraestrutura, que tem por objetivos gerar a base de dados semântica e geriro processo de tomada de decisões, que servem de base para o processo de reconfiguração dosnós sensores.

Como apresentado pela avaliação experimental utilizada para avaliar o consumo deenergia e apresentar também a quantidade de memória utilizada pelos aplicações, dentro doque foi proposto, a SITRUS atende bem as necessidades de controle do consumo de energia,mostrando que sua implementação é mais eficiente utilizando esse tipo de Infraestrutura doque o envio de pacotes individuais em uma taxa constante com a antena sempre ligada, alémdos benefícios da utilização de serviços de middleware em aplicações e semântica nos dadostransmitidos pela rede. Além disso, observou-se que existe espaço suficiente para implementaçãode novos serviços, devido ao uso de memória apresentada nos experimentos.

8.2. CONTRIBUIÇÕES 111

8.2 Contribuições

No desenvolvimento desta tese, foram utilizadas ontologias como mecanismo externodas Redes de Sensores Sem Fio para tomada de decisões, para que os nós sensores possam serreconfigurados em tempo de execução, aumentando assim o tempo de vida útil dos mesmos.Dessa forma, as principais contribuições desse trabalho as que seguem.

Como primeira contribuição, podemos citar a infraestrutura semântica para RSSFs, cha-mada de SITRUS, com uma arquitetura que trabalha com dados RSSFs e ontologias, promovendoa comunicação entre redes diferentes e dando suporte a consulta de dados sem ambiguidades.

Além disso, temos um serviço de comunicação baseado em um middleware orientado amensagens (RAMSES) que realiza a comunicação interna entre os nós sensores e o gerencia-mento de serviços (agregação de dados, comunicação, reconfiguração, dentre outros) de formatransparente para as aplicações.

Outra contribuição seria uma ontologia para RSSF que mapeia os principais conceitosreferentes aos nós sensores, aquisição de dados e consumo de energia desses nós sensores.

Para compor o conjunto de contribuições, temos também um serviço de reconfiguraçãoparamétrica para RSSFs que funciona em tempo de execução, baseado em dados transmitidospelos nós sensores e metadados desses mesmos nós, com o armazenamento ocorrendo em umabase de dados semântica, fora da RSSF.

Além disso, temos um módulo de processamento semântico (SIP) que realiza todo oprocessamento dos dados das RSSFs, a fim de categorizá-los e instanciá-los de forma corretana ontologia proposta, além de servir de base para as tomadas de decisões no processo dereconfiguração, utilizando os dados armazenados na base de dados semântica.

Por fim, um mecanismo de consulta do estado das RSSFs, a partir da Camada Semântica

da arquitetura do SIP, realizado através da base de dados semântica, com uma forma comumentre diferentes redes e aplicações, sem ambiguidades e utilizando uma semântica formal.

8.3 Limitações

Embora a infraestrutura apresentada neste trabalho atenda a importantes requisitos noque se refere a um mecanismo de reconfiguração paramétrica baseado em dados semântico paraeconomia de energia para RSSF, faz-se necessário destacar algumas limitações existentes.

Atualmente existem poucos serviços de middleware disponíveis para o RAMSES, comoo serviço de agregação de dados e o serviço de reconfiguração. Como pôde ser observado pelamemória utilizada nos experimentos realizados, existe espaço disponível para novos serviços enovas implementações.

No que diz respeito ao SIP, a ontologia proposta foi desenvolvida propondo um modelode conhecimento para elementos dos nós sensores, aquisição de dados e energia. Mesmo sendouma ontologia que atendeu bem as necessidades da infraestrutura, ela não representa muitas

8.4. TRABALHOS FUTUROS 112

entidades de software a hardware, o que limita a inclusão de novas soluções de forma fácil aSITRUS.

Outro ponto a ser destacado é sobre o método sistemático de verificação do consumode energia nos experimentos realizados. Por se tratar de um método que se utiliza de diversosequipamentos ao mesmo tempo, não existe uma forma eficaz de medir o consumo de toda umarede ao mesmo tempo, apenas de um nó sensor por vez.

8.4 Trabalhos Futuros

Em termos de trabalhos futuros, alguns itens considerados importantes podem ser obser-vados, separados por áreas de interesse, como se segue.

Com relação a utilização de mapas de energia, temos que a partir de alterações realizadasna ontologia e dos dados provenientes das RSSFs, seria interessante fazem um levantamento domapa de energia da rede, de modo que esse mapa possa ser usado para tomada de decisões maisapropriadas sobre os nós sensores e sobre as RSSFs.

Já com os protocolo de colaboração, poderiam ser definidos protocolos formais decolaboração para negociar serviços, elevando a questão de economia de energia para além dasRSSFs. O protocolo poderia definir mecanismos para negociação de requisitos de QoS queatendesse aplicações concorrentes. A Camada Semântica do SIP poderia ser utilizada pararegistrar as capacidades das RSSF e o resultado do protocolo de negociação em Service Level

Agreement (SLA).Com relação à semântica, podemos expandir a ontologia, com a inclusão de novas

classes, relacionamentos e propriedades, de forma que auxilie na inferência de novos dados sobrecapacidades das RSSFs, necessidade das aplicações e restrições, como consumo de energia.

Além disso, poderíamos criar uma relação entre regiões lógicas e regiões físicas dasRedes de Sensores Sem Fio na ontologia, gerando conhecimento de cada uma das áreas e fazendoum relacionamento entre elas, tentando elaborar com isso, o comportamento de determinadodispositivo.

Com a Internet das Coisas, a infraestrutura poderia ser modificada para se adaptar emum contexto maior, como Internet das Coisas, trabalhando com redes veiculares, redes desensoriamento diversos, celulares, computação vestível, dentre outros, em área compartilhadas.A SITRUS poderia detectar a sobreposição de redes e cuidar da comunicação e uso de dadosentre os componentes.

Com relação às medição por serviço do middleware, a realização de uma nova umaavaliação de desempenho onde os serviços fossem ligados individualmente para comparar oganho de cada um deles, como Low Power Listening, Reconfiguração, Agregação de dados,dentro outros, seria importante para avaliar o impacto de cada um deles na SITRUS.

Também teriam novos serviços de Middleware, pois como existe espaço suficiente dememória utilizada, como demonstrado pelos resultados dos experimentos, pode-se aumentar a

8.4. TRABALHOS FUTUROS 113

quantidade de serviços oferecidos pelo middleware, por exemplo, um serviço de segurança dedados ou serviço de roteamento baseado na ontologia.

Por fim, no que diz respeito às máquinas virtuais, poderíamos aumentar a capacidade dereconfiguração dos nós sensores, não apenas utilizando reconfiguração paramétrica, mas tambémreconfiguração de módulos, a partir de uso de uma máquina virtual, utilizando um código maiscompacto para a transmissão e interpretação dos módulos enviados.

114114114

Referências

AKYILDIZ, I. et al. A survey on sensor networks. IEEE Communications Magazine, [S.l.],v.40, n.8, p.102–114, 2002.

AKYILDIZ, I. F. et al. Wireless Sensor Networks: a survey. Computer Networks: TheInternational Journal of Computer and Telecommunications Networking, New York, NY,USA, v.38, n.4, p.393–422, 2002.

ANASTASI, G. et al. Energy conservation in wireless sensor networks: a survey. Ad HocNetworks, [S.l.], v.7, n.3, p.537–568, 2009.

ANDREOU, P. G. et al. A network-aware framework for energy-efficient data acquisition inwireless sensor networks. Journal of Network and Computer Applications, [S.l.], v.46,p.227–240, 2014.

ARAMPATZIS, T.; LYGEROS, J.; MANESIS, S. A Survey of Applications of Wireless Sensorsand Wireless Sensor Networks. In: IEEE INTERNATIONAL SYMPOSIUM ONINTELLIGENT CONTROL. MEDITERREAN CONFERENCE ON CONTROL ANDAUTOMATION. Anais. . . [S.l.: s.n.], 2005. p.719–724.

AVANCHA, S.; PATEL, C.; JOSHI, A. Ontology-driven adaptive sensor networks. In:INTERNATIONAL CONFERENCE ON MOBILE AND UBIQUITOUS SYSTEMS:NETWORKING AND SERVICES. Anais. . . [S.l.: s.n.], 2004. p.194–202. (MOBIQUITOUS2004).

BAPAT, S.; ARORA, A. Stabilizing reconfiguration in wireless sensor networks. In: IEEEINTERNATIONAL CONFERENCE ON SENSOR NETWORKS, UBIQUITOUS, ANDTRUSTWORTHY COMPUTING. Anais. . . IEEE Computer Society, 2006. v.1, p.52–59.

BERNERS-LEE, T. Semantic Web Architecture.http://www.w3.org/2000/Talks/1206-xml2k-tbl/slide10-0.html.

BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The Semantic Web A new form of Webcontent that is meaningful to computers will unleash a revolution of new possibilities. ScientificAmerican Magazine, [S.l.], p.34–43, 2001.

BERNSTEIN, P. A. Middleware An Architecture for Distributed System Services.Communications of the ACM, [S.l.], v.39, p.86–98, 1993.

BERNSTEIN, P. A. Middleware: a model for distributed system services. Communcations ofthe ACM, [S.l.], v.39, n.2, p.86–98, 1996.

BHUYAN, B.; SARMA, H. K. D.; SARMA, N. A Survey on Middleware for Wireless SensorNetworks. Journal of Wireless Networking and Communications, [S.l.], v.4, n.1, p.7–17,2014.

BISPO, K. A.; ROSA, N. S.; CUNHA, P. R. F. A semantic solution for saving energy in wirelesssensor networks. In: IEEE SYMPOSIUM ON COMPUTERS AND COMMUNICATIONS.Anais. . . [S.l.: s.n.], 2012. p.492–499. (ISCC ’12).

REFERÊNCIAS 115

BISPO, K. A.; ROSA, N. S.; CUNHA, P. R. F. A Semantic Message Oriented Middleware forWireless Sensor Networks. In: EURO AMERICAN CONFERENCE ON TELEMATICS ANDINFORMATION SYSTEMS, New York, NY, USA. Anais. . . ACM, 2014. p.1–4. (EATIS ’14).

BUONADONNA, P.; HILL, J.; CULLER, D. Active Message Communication for TinyNetworked Sensors. In: ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER ANDCOMMUNICATIONS SOCIETIES, 20., Anchorage, Alaska, EUA. Anais. . . IEEE ComputerSociety, 2001.

CASSIA ACIOLI LIMA, R. de; ROSA, N. S.; MARQUES, I. R. L. TS-Mid: middleware forwireless sensor networks based on tuple space. In: INTERNATIONAL CONFERENCE ONADVANCED INFORMATION NETWORKING AND APPLICATIONS, Washington, DC,USA. Anais. . . IEEE Computer Society, 2008. p.886–891. (AINAW ’08).

CONNOLLY, D. et al. DAML+OIL (March 2001) Reference Description. [S.l.]: The WorldWide Web Consortium (W3C), 2001. http://www.w3.org/TR/daml+oil-reference.

DÂMASO, A. et al. Evaluating the Power Consumption of Wireless Sensor NetworkApplications Using Models. Sensors, [S.l.], v.13, n.3, p.3473–3500, 2013.

DÂMASO, A.; ROSA, N.; MACIEL, P. Reliability of Wireless Sensor Networks. Sensors,[S.l.], v.14, n.9, p.15760, 2014.

DÂMASO, A.; ROSA, N.; MACIEL, P. Using Coloured Petri Nets for Evaluating the PowerConsumption of Wireless Sensor Networks. International Journal of Distributed SensorNetworks, [S.l.], v.2014, p.13, 2014.

DIALLO, P. I.; CHAMPEAU, J.; LAGADEC, L. A Model-Driven Approach to Enhance ToolInteroperability using the Theory of Models of Computation. In: INTERNATIONALCONFERENCE ON SOFTWARE LANGUAGE ENGINEERING, 6. Anais. . . Springer-Verlag,2013. (SLE 2013).

DURISIC, M. et al. A survey of military applications of wireless sensor networks. In:MEDITERRANEAN CONFERENCE ON EMBEDDED COMPUTING (MECO). Anais. . .IEEE Computer Society, 2012. p.196–199. (MECO ’2012).

EID, M.; LISCANO, R.; EL SADDIK, A. A Novel Ontology for Sensor Networks Data. In:INTERNATIONAL CONFERENCE ON COMPUTATIONAL INTELLIGENCE FORMEASUREMENT SYSTEMS AND APPLICATIONS. Anais. . . IEEE Computer Society, 2006.p.75–79. (CIMSA 2006).

EID, M.; LISCANO, R.; EL SADDIK, A. A Universal Ontology for Sensor Networks Data. In:INTERNATIONAL CONFERENCE ON COMPUTATIONAL INTELLIGENCE FORMEASUREMENT SYSTEMS AND APPLICATIONS. Anais. . . [S.l.: s.n.], 2007. p.59–62.(CIMSA 2007).

EMMERICH, W. Software Engineering and Middleware: a roadmap. In: CONFERENCE ONTHE FUTURE OF SOFTWARE ENGINEERING. Anais. . . ACM, 2000. p.117–129. (ICSE’00).

GAO, L.; BRUENIG, M.; HUNTER, J. Estimating Fire Weather Indices Via SemanticReasoning Over Wireless Sensor Network Data Streams. International Journal of Web &Semantic Technology, [S.l.], v.5, n.4, p.1–20, 2014.

REFERÊNCIAS 116

GATANI, L.; LO RE, G.; ORTOLANI, M. Monitoring wireless sensor networks through logicaldeductive processes. In: MILITARY COMMUNICATIONS CONFERENCE. Anais. . . IEEEComputer Society, 2005. p.93–98. (MILCOM 2005, v.1).

GAY, D. et al. The nesC language: a holistic approach to networked embedded systems. In:PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION. Anais. . . ACM, 2003.p.1–11. (PLDI 2003).

GILBERT, E. P. K.; KALIAPERUMAL, B.; RAJSINGH, E. B. Research Issues in WirelessSensor Network Applications: a survey. International Journal of Information andElectronics Engineering, [S.l.], v.2, n.5, p.702–706, 2012.

GRUBER, T. R. Toward Principles for the Design of Ontologies Used for Knowledge Sharing.International Journal of Human-Computer Studies, Duluth, MN, USA, v.43, n.5-6,p.907–928, 1995.

GUIMARAES, G. et al. Middleware para Redes de Sensores Sem-Fio: projeto, implementação eavaliação de consumo de energia. In: SIMPóSIO BRASILEIRO DE REDES DECOMPUTADORES, 24., Curitiba, Parana. Anais. . . [S.l.: s.n.], 2006. p.1–16.

HADIM, S.; MOHAMED, N. Middleware: middleware challenges and approaches for wirelesssensor networks. Distributed Systems Online, IEEE, [S.l.], v.7, n.3, March 2006.

HADIM, S.; MOHAMED, N. Middleware for Wireless Sensor Networks: a survey. In:COMMUNICATION SYSTEM SOFTWARE AND MIDDLEWARE, 2006. COMSWARE 2006.FIRST INTERNATIONAL CONFERENCE ON. Anais. . . IEEE Computer Society, 2006.p.1–7.

HEINZELMAN, W. B. et al. Middleware to support sensor network applications. IEEENetwork: The Magazine of Global Internetworking, Piscataway, NJ, USA, v.18, n.1, p.6–14,2004.

HUANG, J.; ABADI, D. J.; REN, K. Scalable SPARQL Querying of Large RDF Graphs. In:VERY LARGE DATA BASE ENDOWMENT INC. Anais. . . [S.l.: s.n.], 2011. n.11,p.1123–1134. (VLDB 2011, v.4).

HUANG, V.; JAVED, M. K. Semantic Sensor Information Description and Processing. In:SECOND INTERNATIONAL CONFERENCE ON SENSOR TECHNOLOGIES ANDAPPLICATIONS. Anais. . . IEEE Computer Society, 2008. p.456–461. (SENSORCOMM2008).

JOGI, S. S.; VIDHATE, A. Survey and Analysis of Medium Access Control Protocols forWireless Sensor Network. IOSR Journal of Computer Engineering, [S.l.], v.13, n.4, p.69–76,2013.

KRISHNAMACHARI, B.; ESTRIN, D.; WICKER, S. The impact of data aggregation inwireless sensor networks. In: INTERNATIONAL CONFERENCE ON DISTRIBUTEDCOMPUTING SYSTEMS WORKSHOPS. Anais. . . [S.l.: s.n.], 2002. p.575–578.

KRISHNAMACHARI, B.; ESTRIN, D.; WICKER, S. Modelling Data Centric Routing inWireless Sensor Networks. In: ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTERAND COMMUNICATIONS SOCIETIES, 21., Nova Iorque, NY, EUA. Anais. . . IEEEComputer Society, 2002.

REFERÊNCIAS 117

LASSILA, S. Resource Description Framework (RDF) Model and Syntax Specification.[S.l.]: World Wide Web Consortium Recommendation, 2004.http://www.w3.org/TR/REC-rdf-syntax/.

LEVIS, P.; CULLER, D. MatÉ: a tiny virtual machine for sensor networks. ACM SIGARCHComputer Architecture News, New York, NY, USA, v.30, n.5, p.85–95, 2002.

LEVIS, P. et al. TOSSIM: accurate and scalable simulation of entire tinyos applications. In:INTERNATIONAL CONFERENCE ON EMBEDDED NETWORKED SENSOR SYSTEMS,New York, NY, USA. Anais. . . ACM, 2003. p.126–137. (SenSys ’03).

LEVIS, P. et al. TinyOS: an operating system for sensor networks. In: AMBIENTINTELLIGENCE. Anais. . . Springer Berlin Heidelberg, 2005. p.115–148.

LIU, P. et al. Semantization Improves the Energy Efficiency of Wireless Sensor Networks. In:IEEE WIRELESS COMMUNICATION AND NETWORKING CONFERENCE. Anais. . .IEEE Computer Society, 2010. p.1–6.

LIU, T.; MARTONOSI, M. Impala: a middleware system for managing autonomic, parallelsensor systems. ACM SIGPLAN Notices, New York, NY, USA, v.38, n.10, p.107–118, 2003.

MAHFOUDH, S.; MINET, P. Survey of energy efficient strategies in wireless ad hoc and sensornetworks. In: SEVENTH INTERNATIONAL CONFERENCE ON NETWORKING. Anais. . .IEEE Computer Society, 2008. p.1–7.

MARQUES, I. L.; RONAN, J.; ROSA, N. S. TinyReef: a register-based virtual machine forwireless sensor networks. In: IEEE SENSORS. Anais. . . IEEE Computer Society, 2009.p.1423–1426.

MARQUES, I. L.; SILVA TEÓFILO, M. R. da; ROSA, N. S. Durin: a development environmentfor wireless sensor network. In: INTERNATIONAL WORKSHOP ON SOFTWAREENGINEERING FOR SENSOR NETWORK APPLICATIONS. Anais. . . IEEE ComputerSociety, 2013. p.19–23. (SESENA 2013).

MCBRIDE, B. Jena: a semantic web toolkit. IEEE Internet Computing, Los Alamitos, CA,USA, v.6, n.6, p.55–59, 2002.

MCGUINNESS, D. L.; HARMELEN, F. van. OWL Web Ontology Language Overview.[S.l.]: W3C Proposed Recommendation, 2004. http://www.w3.org/TR/owl-features/.

MCKINLEY, P. et al. Composing adaptive software. Computer, [S.l.], v.37, n.7, p.56–64, 2004.

MOLLA, M.; AHAMED, S. A survey of middleware for sensor network and challenges. In:INTERNATIONAL CONFERENCE WORKSHOPS ON PARALLEL PROCESSING. Anais. . .IEEE Computer Society, 2006. p.223–228. (ICPPW ’06).

MOTTOLA, L.; PICCO, G. P. Middleware for wireless sensor networks: an outlook. Journal ofInternet Services and Applications, [S.l.], v.3, n.1, p.31–39, 2012.

NIKOLIc, S. et al. Semantic Web Based Architecture for Managing Hardware Heterogeneity inWireless Sensor Network. In: INTERNATIONAL CONFERENCE ON WEB INTELLIGENCE,MINING AND SEMANTICS, New York, NY, USA. Anais. . . ACM, 2011. p.1–9. (WIMS ’11).

REFERÊNCIAS 118

NILES, I.; PEASE, A. Towards a Standard Upper Ontology. In: INTERNATIONALCONFERENCE ON FORMAL ONTOLOGY IN INFORMATION SYSTEMS, New York, NY,USA. Anais. . . ACM, 2001. p.2–9. (FOIS ’01).

NOY, N. F.; MCGUINNESS, D. L. Ontology Development 101: a guide to creating your firstontology. http://www.ksl.stanford.edu/people/dlm/papers/ontology-tutorial-noy-mcguinness-abstract.html.

PANTAZIS, N. A.; VERGADOS, D. D. A survey on power control issues in wireless sensornetworks. IEEE Communications Surveys & Tutorials, [S.l.], v.9, n.4, p.86–107, 2007.

PÉREZ, J.; ARENAS, M.; GUTIERREZ, C. Semantics and Complexity of SPARQL. ACMTransactions on Database Systems, New York, NY, USA, v.34, n.3, p.16:1–16:45, 2009.

RADHIKA, J.; MALARVIZHI, S. Middleware Approaches For Wireless Sensor Networks: anoverview. International Journal of Computer Science Issues, [S.l.], v.9, n.3, p.224–229,2012.

RHEE, S.; SEETHARAM, D.; LIU, S. Techniques for minimizing power consumption in lowdata-rate wireless sensor networks. In: WIRELESS COMMUNICATIONS ANDNETWORKING CONFERENCE. Anais. . . IEEE Computer Society, 2004. p.1727–1731.(WCNC 2004, v.3).

ROUSSEY, C. et al. An Introduction to Ontologies and Ontology Engineering. In:ONTOLOGIES IN URBAN DEVELOPMENT PROJECTS. Anais. . . Springer London, 2011.v.1, p.9–38.

RUBIO, B.; DÍAZ, M.; TROYA, J. M. Programming Approaches and Challenges for WirelessSensor Networks. In: INTERNATIONAL CONFERENCE ON SYSTEMS AND NETWORKSCOMMUNICATIONS. Anais. . . [S.l.: s.n.], 2007. p.25–31. (ICSNC 2007).

RUIZ, L. B. et al. Arquiteturas para Redes de Sensores Sem Fio. In: SIMPóSIO BRASILEIRODE REDES DE COMPUTADORES, 22. Anais. . . [S.l.: s.n.], 2004. p.167–218.

SAMUEL, K. D. et al. Improving Energy Efficiency in Wireless Sensor Network Using MobileSink. Advances in Networks and Communications, [S.l.], v.132, p.63–69, 2011.

SAWANT, S. A.; ADINARAYANA, J.; DURBHA, S. S. KrishiSense: a semantically aware webenabled wireless sensor network system for precision agriculture applications. In: IEEEINTERNATIONAL GEOSCIENCE AND REMOTE SENSING SYMPOSIUM. Anais. . . IEEEComputer Society, 2014. p.4090–4093. (IGARSS 2014).

SCHMIDT, D. C.; BUSCHMANN, F. Patterns, Frameworks, and Middleware: their synergisticrelationships. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING.Anais. . . IEEE Computer Society, 2003. p.694–704. (ICSE 2003).

SHA, M.; HACKMANN, G.; LU, C. Energy-efficient Low Power Listening for Wireless SensorNetworks in Noisy Environments. In: INTERNATIONAL CONFERENCE ONINFORMATION PROCESSING IN SENSOR NETWORKS, 12., New York, NY, USA.Anais. . . ACM, 2013. p.277–288. (IPSN ’13).

REFERÊNCIAS 119

SHI, Q. Power Management in Networked Sensor Radios A Network Energy Model. In:SENSORS APPLICATIONS SYMPOSIUM. Anais. . . IEEE Computer Society, 2007. p.1–5.(SAS ’07).

SILVA, B. et al. AMALGHMA - An environment for measuring execution time and energyconsumption in embedded systems. In: IEEE INTERNATIONAL CONFERENCE ONSYSTEMS, MAN AND CYBERNETICS. Anais. . . IEEE Computer Society, 2014.p.3364–3369. (SMC ’14).

SILVA, J. R. et al. PRISMA: a publish-subscribe and resource-oriented middleware for wirelesssensor networks. In: TENTH ADVANCED INTERNATIONAL CONFERENCE ONTELECOMMUNICATIONS. Anais. . . IARIA XPS Press, 2014. p.87–97. (AICT ’14).

SIRIN, E. et al. Pellet: a practical owl-dl reasoner. Web Semantics: Science, Services andAgents on the World Wide Web, Amsterdam, The Netherlands, The Netherlands, v.5, n.2,p.51–53, 2007.

SIVAGAMI, A. et al. Estimating the Energy Consumption of Wireless Sensor Node: iris.International Journal of Recent Trends in Engineering and Technology, [S.l.], v.3, n.4,p.141–143, 2010.

SOUTO, E. et al. A Message-oriented Middleware for Sensor Networks. In: WORKSHOP ONMIDDLEWARE FOR PERVASIVE AND AD-HOC COMPUTING, 2., New York, NY, USA.Anais. . . ACM, 2004. p.127–134. (MPAC ’04).

SOUTO, E. et al. Mires: a publish/subscribe middleware for sensor networks. PersonalUbiquitous Compututing, [S.l.], v.10, n.1, p.37–44, 2005.

STUDER, R.; BENJAMINS, V. R.; FENSEL, D. Knowledge Engineering: principles andmethods. Data & Knowledge Engineering, Amsterdam, The Netherlands, v.25, n.1-2,p.161–197, 1998.

TAVARES, E.; SILVA, B.; MACIEL, P. An Environment for Measuring and SchedulingTime-Critical Embedded Systems with Energy Constraints. In: SIXTH IEEEINTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING AND FORMALMETHODS. Anais. . . IEEE Computer Society, 2008. p.291–300.

TRIPATHI, A.; GUPTA, S.; CHOURASIYA, B. Survey on Data Aggregation Techniques forWireless Sensor Networks. International Journal of Advanced Research in Computer andCommunication Engineering, [S.l.], v.3, n.7, p.7366–7371, 2014.

USCHOLD, M. et al. Ontologies: principles, methods and applications. KnowledgeEngineering Review, [S.l.], v.11, p.93–136, 1996.

VINOSKI, S. Where is Middleware? IEEE Internet Computing, [S.l.], v.6, n.2, p.83–85,2002.

VITAL, L. P.; CAFÉ, L. M. A. Ontologias e taxonomias: diferenças. Perspectivas em Ciênciada Informação, [S.l.], v.16, n.2, p.115–130, 2011.

WANG, W.; TOLK, A.; WANG, W. The Levels of Conceptual Interoperability Model: applyingsystems engineering principles to m&s. In: SPRING SIMULATION MULTICONFERENCE,San Diego, CA, USA. Anais. . . Society for Computer Simulation International, 2009.p.168:1–168:9. (SpringSim ’09).

REFERÊNCIAS 120

YONEKI, E. Mobile applications with a middleware system in publish subscribe paradigm. In:WORKSHOP ON APPLICATIONS AND SERVICES IN WIRELESS NETWORKS, 3.Anais. . . [S.l.: s.n.], 2003.

YU, L. Example: using jena for development on the semantic web. In: A Developer’s Guide tothe Semantic Web. [S.l.]: Springer Berlin Heidelberg, 2014. p.669–710.

YU, Y.; KRISHNAMACHARI, B.; PRASANNA, V. Issues in designing middleware forwireless sensor networks. IEEE Network, [S.l.], v.18, n.1, p.15–21, 2004.

uma infraestrutura semÂntica para economizar … · ração para rede de sensores sem fio...

Documents