“
UMA INFRAESTRUTURA SEMÂNTICA PARA ECONOMIZAR ENERGIA EM REDE DE SENSORES SEMFIO
”
Por
Kalil Araujo Bispo
Tese de Doutorado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
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 fonte
Bibliotecá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.
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 Barros
Coordenador da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
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 (Abdul e Farid), que estiveram sempre ao meu lado nesse período e me ensinaram as coisas mais importantes que sei hoje. Muito obrigado a vocês! E também a Mayka, a irmã de 4 patas, que esteve 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 presente nos 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 durante esse período.
Ao meu orientador Paulo Cunha, por me dar a oportunidade de participar deste programa de Doutorado. A Nelson Rosa, pela grande ajuda no desenvolvimento desse trabalho, com ideias, conselhos e muita paciência. Agradeço pelo apoio, disponibilidade, pelos comentários imprescindí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 e aos 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 meu potencial durante a graduação e por terem me incentivado a seguir esse caminho.
Enfim, gostaria de registrar meus sinceros agradecimentos como reconhecimento da dedicação de muitas pessoas que, direta ou indiretamente, contribuíram para a realização deste trabalho.
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ções para 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 de energia, por exemplo, a utilização de melhores algoritmos, agregação de dados, mecanismos de auto-gerenciamento, dentre outros, respeitando as limitações de recursos das RSSF. Algumas pesquisas na área mostram que solucionar esse tipo de problema não é uma tarefa fácil de ser resolvida.
Sendo assim, este trabalho propõe uma solução de economia de energia para RSSF e uma forma comum de compartilhamento de dados entre aplicações e redes diferentes, baseada em uma Infraestrutura Semântica para RSSF chamada SITRUS. Ela utiliza reconfiguração paramétrica nos nós sensores em tempo de execução, a partir de dados de sensoriamento processados fora da RSSF, utilizando ontologias desenvolvidas com esse propósito para o processamento desses dados.
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 e gerenciamento de serviços das aplicações que são executadas nos nós sensores; e o Módulo de Processamento Semântico da Informação (SIP), que tem por finalidade categorizar os dados para a geração da base de dados semântica. Esta base de dados servirá para a tomada de decisões de reconfiguraçã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 e executado 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 pelo compartilhamento de dados relativos a um mesmo contexto. Os benefícios desta abordagem incluem o enriquecimento dos dados pela associação de seu significado, e não apenas pela sintaxe dos dados, facilitando assim o seu acesso e eliminando ambiguidades.
Como forma de demonstrar a eficiência da SITRUS, uma avaliação experimental do consumo de energia com algumas aplicações e diferentes cenários foi realizada, mostrando em seus resultados que a SITRUS atende ao que foi proposto no que diz respeito ao gerenciamento do consumo de energia.
Palavras-chave: Infraestrutura Semântica. Rede de Sensores Sem Fio. Middleware. Ontologia e 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 nodes must 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 better algorithms, data aggregation, self-management mechanisms, among others, in compliance the resource limitations of WSN. Some research in the area show that solving this problem is not an easy task to be addressed.
Thus, this paper proposes a power saving solution for WSN and a common way of sharing data between different applications and networks based on a Semantic Infrastructure for WSN called SITRUS. It uses parametric reconfiguration in sensor nodes at runtime, from sensing data processed outside the WSN using ontologies developed for this purpose for processing such data.
SITRUS consists of two major parts: RAMSES, responsible for data transport and service management applications that run on the sensor nodes; and SIP, which is intended to categorize the data for generating the semantic database. This database will serve for decision making 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 intervenreconfigura-tion. Processing is determined by SIP and performed by RAMSES. Thus, it follows a model based on formal semantics.
It is intended that the SITRUS encourages the integration of different applications by sharing data on a same context. The benefits of this approach include the enrichment of the data by the association of its meaning, and not only by the syntax of the data, thus facilitating their access and eliminating ambiguities.
In order to demonstrate the effectiveness of SITRUS, an experimental evaluation of power consumption with some applications and different scenarios was performed, and the results shows that SITRUS serves to what has been proposed in regard to management of the energy consumption.
Keywords: Semantic Infrastructure. Wireless Sensor Network. Middleware. Ontology and Semantic Web. Power Consumption. Software Reconfiguration.
2.1 Arquitetura da Web Semântica (BERNERS-LEE,2000) . . . 26
2.2 Namespacede uma Ontologia para Pizza . . . 27
2.3 Classes da Ontologia para Pizza com a classe owl:Thing . . . 28
2.4 Declaração de Classes em OWL . . . 28
2.5 Declaração de Propriedades em OWL . . . 29
2.6 Consulta Simples em SPARQL . . . 30
2.7 Ambiente Monitorado por uma Rede de Sensor Sem Fio . . . 31
2.8 Visão Geral do Middleware . . . 36
3.1 Cenário de Uso de Monitoramento de Ambiente Usando a SITRUS . . . 42
3.2 Cenário de Uso de Consulta de Dados da RSSF Usando a SITRUS . . . 42
3.3 Cenário de Uso de Reconfiguração de um Nó Sensor Usando a SITRUS . . . . 43
3.4 Arquitetura SITRUS . . . 44
4.1 Arquitetura do Middleware RAMSES . . . 51
4.2 Formato de um pacote em Low Power Listening . . . 53
4.3 Código Utilizado para Inicialização de um Nó Sensor Usando Low Power Listening 54 4.4 Configuração da Interface LowPowerListening por Tipo de Plataforma . . . 55
4.5 Componente Middleware . . . 55
4.6 Componente TransportLayer . . . 56
4.7 Código Utilizado para Transmissão de Dados Utilizando o RAMSES . . . 57
4.8 Componente DistributionLayer . . . 58
4.9 Diagrama de Sequência para Anúncio e Assinatura de Tópico . . . 59
4.10 Diagrama de Sequência para Publicação de uma Mensagem . . . 60
4.11 Componente ServiceLayer . . . 61
4.12 Diagrama de Sequência para Agregação de Dados . . . 61
4.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) . . . 66
5.2 Taxonomia da Ontologia do SIP . . . 68
5.3 A Classe SensorNode da Ontologia do SIP . . . 69
5.4 Propriedade isReachable sendo utilizada a partir de regras para definir existência de rota entre dois nós sensores . . . 69
5.5 A Classe Power da Ontologia do SIP . . . 70
5.6 A Classe Device da Ontologia do SIP . . . 70
5.8 A Classe SensorType da Ontologia do SIP . . . 71
5.9 A Classe WSN da Ontologia do SIP . . . 72
5.10 A Classe Measurement da Ontologia do SIP . . . 72
5.11 Diagrama de Classes UML do Componente de Comunicação . . . 74
5.12 Código Utilizado para Envio de Mensagens de Reconfiguração . . . 74
5.13 Código Utilizado para Reconfiguração da Taxa de Amostragem . . . 75
5.14 Diagrama UML da Classe OWLIndividual . . . 76
5.15 Diagrama UML das Classes MyFactory e OWLModel . . . 76
5.16 Código Java para Recuperar Uma Instância Específica da Classe SensorNode . 76 5.17 Diagrama UML da Classe Ontology . . . 77
5.18 Código SPARQL para Determinar os Dados de Medição de um Nó Sensor . . . 77
5.19 Diagrama de Sequência da Classe SIPReasoner e do Método startReasoner . . 78
5.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 . . . 82
6.2 Código para Configuração do processo de medição . . . 83
6.3 Trace de Reconfiguração da Taxa de Amostragem . . . 85
6.4 Componentes da Aplicação RadioCountToLeds com e sem o Middleware . . . 86
6.5 Consumo de Energia para a Aplicação RadioCountToLeds Utilizando os Cená-rios Propostos . . . 87
6.6 Componentes da Aplicação RadioSenseToLeds com e sem o Middleware . . . 89
6.7 Consumo de Energia para a Aplicação RadioSenseToLeds . . . 90
6.8 Componentes da Aplicação Temperature com e sem o Middleware . . . 91
6.9 Consumo de Energia para a Aplicação Temperature . . . 92
6.10 Componentes da Aplicação Oscilloscope com e sem o Middleware . . . 93
6.11 Consumo de Energia para a Aplicação Oscilloscope . . . 94
6.12 Componentes da Aplicação AntiTheft com e sem o Middleware . . . 96
6.1 Utilização de Memória da Aplicação RadioCountToLeds . . . 87
6.2 Utilização de Memória da Aplicação RadioSenseToLeds . . . 89
6.3 Utilização de Memória da Aplicação Temperature . . . 92
6.4 Utilização de Memória da Aplicação Oscilloscope . . . 95
6.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 . . . 102
7.2 Sumário da Discussão sobre Ontologia em Rede de Sensores Sem Fio . . . 105
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 MiddlewareCiente 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
1 Introdução 15 1.1 Contexto e Motivação . . . 15 1.2 Caracterização do Problema . . . 17 1.3 Estado da Arte . . . 18 1.4 Objetivos e Contribuições . . . 20 1.5 Estrutura da Tese . . . 21 2 Conceitos Básicos 23 2.1 Ontologia e Web Semântica . . . 23
2.1.1 A Linguagem OWL . . . 25
2.1.2 Estrutura de uma Ontologia OWL . . . 27
2.1.3 Linguagem de Consulta SPARQL . . . 29
2.2 Rede de Sensores Sem Fio . . . 30
2.2.1 Desafios no Desenvolvimento de Aplicações para RSSF . . . 31
2.2.2 TinyOS e nesC . . . 33
2.3 Middleware . . . 35
2.3.1 Requisitos para o Desenvolvimento de um Middleware . . . 36
2.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 40 3.1 Visão Geral . . . 40
3.2 Cenários de Uso . . . 41
3.2.1 Monitoramento do Ambiente . . . 41
3.2.2 Consulta de dados . . . 42
3.2.3 Reconfiguração dos Nós Sensores . . . 43
3.3 Arquitetura . . . 44
3.3.1 Camada de Dados das Redes de Sensores . . . 44
3.3.2 Camada Semântica . . . 45
3.3.3 Camada de Aplicação . . . 45
3.4 Soluções Envolvendo a SITRUS . . . 46
3.4.1 Interoperabilidade . . . 46
3.4.2 Anulação das Restrições Sintáticas nas Consultas . . . 47
3.4.3 Reconfiguração Paramétrica . . . 47
3.5 Considerações Finais . . . 48
4 RAMSES: Middleware Ciente de Reconfiguração para Rede de Sensores Sem Fio 49 4.1 Visão Geral . . . 49 4.2 Arquitetura . . . 50 4.2.1 Camada de Transporte . . . 50 4.2.2 Camada de Distribuição . . . 51 4.2.3 Camada de Serviços . . . 52 4.3 Implementação . . . 52
4.3.1 Low Power Listening . . . 53
4.3.2 Componente Middleware . . . 55
4.3.3 Componente TransportLayer . . . 56
4.3.4 Componente DistributionLayer . . . 57
4.3.5 Componente ServiceLayer . . . 60
4.4 Considerações Finais . . . 63
5 SIP: Módulo de Processamento Semântico da Informação 64 5.1 Visão Geral . . . 64
5.2 Arquitetura . . . 65
5.2.1 Componente de Comunicação . . . 66
5.2.2 Camada Semântica . . . 66
5.2.2.1 Subcamada do Motor de Raciocínio . . . 67
5.2.2.2 Subcamada de Regras . . . 67
5.2.2.3 Subcamada de Consultas SPARQL . . . 67
5.2.2.4 Subcamada da Base de Dados . . . 68
5.3 Ontologia do SIP . . . 68
5.3.1 Descrição das Classes e suas Propriedades . . . 68
5.3.2 Checagem de Consistência das Classes . . . 73
5.4 Implementação . . . 73
5.4.1 Componente de Comunicação . . . 73
5.4.2 Camada Semântica . . . 75
5.4.3 Subcamada da base de Dados . . . 78
5.5 Considerações Finais . . . 79 6 Avaliação Experimental 81 6.1 Procedimento de Medição . . . 81 6.2 Resultados . . . 84 6.2.1 Aplicação RadioCountToLeds . . . 85 6.2.1.1 Consumo de Energia . . . 85 6.2.1.2 Memória Utilizada . . . 87
6.2.2 Aplicação RadioSenseToLeds . . . 88 6.2.2.1 Consumo de Energia . . . 88 6.2.2.2 Memória Utilizada . . . 89 6.2.3 Aplicação Temperature . . . 90 6.2.3.1 Consumo de Energia . . . 91 6.2.3.2 Memória Utilizada . . . 92 6.2.4 Aplicação Oscilloscope . . . 93 6.2.4.1 Consumo de Energia . . . 94 6.2.4.2 Memória Utilizada . . . 95 6.2.5 Aplicação AntiTheft . . . 95 6.2.5.1 Consumo de Energia . . . 96 6.2.5.2 Memória Utilizada . . . 97 6.3 Considerações Finais . . . 98 7 Trabalhos Relacionados 99 7.1 Middleware Para Redes de Sensores sem Fio . . . 99
7.1.1 MiddlewareOrientado a Mensagens . . . 99
7.1.2 MiddlewareBaseado em Espaços de Tuplas . . . 100
7.1.3 MiddlewareDirigido à Aplicação . . . 101
7.1.4 Discussão Sobre os Trabalhos . . . 101
7.2 Ontologia em Redes de Sensores sem Fio . . . 102
7.2.1 SWASN . . . 103
7.2.2 Ontologia Universal para RSSF . . . 103
7.2.3 Aplicações de Monitoramento . . . 104
7.2.4 Discussão Sobre os Trabalhos . . . 105
7.3 Sistemas Adaptativos para RSSF . . . 106
7.3.1 Maté . . . 106
7.3.2 Impala . . . 107
7.3.3 Durin . . . 107
7.3.4 KSpot+ . . . 108
7.3.5 Discussão Sobre os Trabalhos . . . 108
7.4 Considerações Finais . . . 109
8 Conclusão e Trabalhos Futuros 110 8.1 Conclusão . . . 110
8.2 Contribuições . . . 111
8.3 Limitações . . . 111
8.4 Trabalhos Futuros . . . 112
15 15 15
1
Introduçã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 das Redes 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 Sem Fio serão descritos. Na sequência, serão apresentados os trabalhos relacionados e a proposta desse 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 vez
mais fácil, o que possibilitou o desenvolvimento de diversos tipos de aplicações (GILBERT;
KALIAPERUMAL; RAJSINGH,2012;HADIM; MOHAMED,2006a). Mas estes ambientes são muito dinâmicos, escaláveis e com problemas específicos relacionados à sua natureza, o que aumenta 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 certos tipos de objetos, medidas de posição, velocidade e aceleração de um objeto, concentração de substâncias, dentre outros. Esses nós sensores realizam o sensoriamento do ambiente, processam os dados e enviam esses dados processados para um nó especial, chamado de estação base. A estação base pode atuar como um gateway para outras redes, tem um poder de processamento maior 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 de um 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
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 de dados, que são normalmente processados pelas suas próprias aplicações. A ausência de uma forma comum de comunicação entre diferentes aplicações limita o compartilhamento de dados entre as RSSFs.
De forma geral, as RSSFs operam essencialmente sem intervenção humana direta, pois podem ser instaladas em lugares de difícil acesso, hostis ou remotos, onde a substituição ou manutenção do dispositivo pode ser inviável. Por conta disso, o ideal é que as RSSFs tenham mecanismos 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 individual
dos 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 matas fechadas ou de guerra, por exemplo, a recarga de baterias torna-se quase impossível. Assim, os nós sensores devem gastar o mínimo de energia para realizar suas tarefas, tentando maximizar seu tempo de funcionamento o quanto possível. Idealmente, os dispositivos devem ser mantidos em modos de funcionamento que minimizem o custo da energia, sendo aplicados apenas quando necessário, a partir da utilização de melhores algoritmos, componentes que gastem menos energia ou reconfiguração em tempo de execução.
Com relação à disseminação de dados, quanto mais dados gerados, mais dados são transmitidos e mais energia é consumida, degradando assim toda a rede. Dessa forma, a
eficiência energética1 sempre deve ser levada em consideração no desenvolvimento de uma
aplicaçã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 emANASTASI et al.(2009), a transmissão de
um 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 que o subsistema de computação. Por essa razão, a comunicação pode ser melhorada através de pré-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 (LIU
et 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 de hardware e software e os mecanismos de operação variam de acordo com a aplicação. Devido a
essas 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 de
1.2. CARACTERIZAÇÃO DO PROBLEMA 17 de aplicações para nós sensores, possibilitando ainda a abstração da complexidade envolvida em serviç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 ambiente de 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 realizar suas operações de sensoriamento e processamento o maior tempo possível, como também utilizar mecanismos que possam ajudar na economia de energia, por exemplo, na utilização de melhores algoritmos de roteamento, agregação de dados, mecanismos de auto-gerenciamento em tempo
de 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ém disponibilizar uma forma comum de compartilhamento de informações entre diversas RSSFs diferentes, 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 com pouca memória, largura de banda limitada, baixo poder de processamento e severas restrições de energia. Muitas vezes, as RSSFs são instaladas em lugares de difícil acesso, onde a substituição ou manutenção dos dispositivos pode se tornar inviável. Além dessas restrições, as RSSFs são dependentes das aplicações a que se destinam, tornando-se restrito o compartilhamento de dados entre redes ou entre aplicações de forma direta sem algum tipo de mecanismo que favoreça essa tarefa.
Dessa forma, o problema que este trabalho trata é como reduzir o consumo de energia em RSSF, além de apresentar uma forma comum para compartilhamento de dados entre aplicações e redes diferentes. Neste cenário, a semântica (estruturas ou padrões formais sobre determinado conteúdo, atribuindo um significado a esse conteúdo, de forma que seja perceptível tanto pelos humanos como pelos computadores) se torna um fator importante para a solução desses problemas tão complexos.
As RSSFs são redes em que a especificidade das aplicações torna-se um fator comum devido aos vários tipos de restrições. Sendo assim, o desenvolvimento de uma aplicação para esse tipo de rede não é trivial e deve ser sempre pensado em manter a rede o maior tempo possível ativa, evitando sobrecarga de determinados nós sensores ou uma drenagem de bateria por conta de um algoritmo com processamento elevado. Idealmente, os nós sensores devem manter seu funcionamento apenas para realizar uma tarefa específica, sendo suas ações aplicadas
apenas quando necessário para resolver alguns eventos do sistema (ANASTASI et al.,2009;
Apesar de ter tantas restrições, as RSSFs continuamente coletam e geram um grande volume de dados, que normalmente são entregues e processados por suas aplicações. A falta de um 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 o estado da rede. A eficiência energética é algo que deve ser sempre priorizado no desenvolvimento de 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 de
dados (TRIPATHI; GUPTA; CHOURASIYA,2014;KRISHNAMACHARI; ESTRIN; WICKER,
2002a). Outra solução seria utilizar uma representação semântica de uma RSSF, adotando uma organização hierárquica da informação. O uso de ontologias promove a integração de diferentes aplicações pelo compartilhamento de dados em um mesmo contexto e, dessa forma, sobrepõe às
limitações sintáticas de troca de mensagens e comunicação dessas aplicações (NIKOLI´c et al.,
2011;EID; LISCANO; EL SADDIK,2006).
Em um cenário tão complexo como esse, com um grande volume de dados a ser transportado, redes heterogêneas em um mesmo ambiente de monitoramento, serviços de pré-processamento e o aproveitamento da representação semântica das RSSFs, a utilização de 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 de
middlewarepara 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 da comunicação e da disponibilização de serviços. Dessa forma, o middleware fica responsável por resolver 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ção dos 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 de
baixo-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 em RSSF. No entanto, pouca atenção tem sido dada à representação semântica das RSSFs para o consumo de energia. A ideia de introduzir conceitos de Web Semântica e criar sistemas de
informação baseados em ontologia para RSSFs foi introduzido emAVANCHA; PATEL; JOSHI
(2004). Com este trabalho, os autores mapearam em uma ontologia características importantes
1.3. ESTADO DA ARTE 19
O trabalho proposto porAVANCHA; PATEL; JOSHI(2004) serviu de base para diversos
trabalhos mesclando RSSF e semântica, mas muitos desses trabalhos usaram ontologias apenas para prover dados com semântica, construir uma base de dados e melhorar as respostas das consultas, mas sem uma preocupação em reutilizar esses dados para melhorias na rede. Em
EID; LISCANO; EL SADDIK(2007) eHUANG; JAVED(2008) são definidas ontologias para descrever conceitos e relacionamentos das RSSFs a partir dos dados da rede, além de melhorar
a precisão das consultas. EmGAO; BRUENIG; HUNTER(2014), os dados provenientes das
RSSFs para monitoramento do ambiente são utilizados para a classificações de perigo de incêndio aplicando tecnologias de Web Semântica para o processamento de fluxos de dados, que permitem a especialistas de domínio especificar e adaptar as regras para o cálculo de índices de incêndio.
Já emSAWANT; ADINARAYANA; DURBHA(2014), Web Semântica é utilizada em RSSF
para aplicações de agricultura de precisão. Com isso, os autores conseguiram trabalhar com interoperabilidade entre diferentes sistemas de sensoriamento de forma padronizada.
Por outro lado, existem também diversas soluções voltadas para a redução do consumo
de energia em RSSF. EmSAMUEL et al.(2011), os autores utilizam técnicas de clusterização
para diminuir a quantidade de transmissões de dados entre os nós sensores, maior responsável pelo consumo de energia. Para isso, é calculado o nó com maior conectividade para determinar quem será o cluster head da região lógica. Apesar de haver uma preocupação com o consumo de energia, o processamento para a escolha do cluster head é feito pela própria RSSF, o que també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 autores
utilizam uma abordagem para avaliar o consumo de energia em RSSF utilizando modelos de simulaçã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 deANASTASI et al.(2009) mostra como é o consumo de energia em vários
componentes de hardware diferentes em um nó sensor e discute as principais formas para conservação de energia, apresentando também uma taxonomia abrangente dos sistemas de
conservação de energia. O trabalho deSIVAGAMI et al.(2010) calcula, a partir de modelos,
uma estimativa de consumo de energia para motes IRIS2. A abordagem para estimar a energia
consumida é feita medindo o tempo gasto pelo rádio e o status do microcontrolador do mote.
No trabalho deANDREOU et al.(2014), os autores desenvolveram um framework que
melhora 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 as etapas realizadas para essa economia são processadas pelos nós sensores.
Os trabalhos citados tratam diversos aspectos no que se refere ao consumo de energia e representação dos dados em RSSF. Ainda assim, existem muitos desafios para prover um
solução para RSSFs que trate aspectos, por exemplo, a adoção de uma metodologia de adaptação da RSSF em tempo de execução para prover economia de energia e uma forma comum de compartilhamento de dados entre diferentes RSSFs.
1.4
Objetivos e Contribuições
Tendo em vista o contexto apresentado e os problemas citados, este trabalho tem como objetivo 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 o tempo de vida útil dos mesmos.
Sendo assim, este trabalho propõe uma solução de economia de energia para RSSF e uma forma comum de compartilhamento de dados entre aplicações e redes diferentes, baseada em uma infraestrutura 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 de dados processados fora da RSSF, usando ontologias desenvolvidas com esse propósito para o processamento 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 de sobrepor as limitações sintáticas dos dados, eliminar ambiguidades e possíveis falsos positivos e
negativos 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 de Processamento 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 dados semântica. Esta base servirá para a tomada de decisões de reconfiguração dos nós sensores e para o processamento de consultas sobre as RSSFs.
Além dos benefícios relativos à economia de energia, a infraestrutura foi projetada para favorecer a integração de diferentes aplicações pelo compartilhamento de dados relativos a um mesmo contexto. Os benefícios desta abordagem incluem o enriquecimento dos dados pela associação de seu significado, e não apenas pela sintaxe dos dados, facilitando assim o seu acesso e eliminando ambiguidades.
Com os dados obtidos a partir do sensoriamento do ambiente e metadados dos nós sensores, uma base de dados semânticos é gerada. Assim, não há necessidade de consultas perió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 na RSSF.
1.5. ESTRUTURA DA TESE 21 dos nós sensores em tempo de execução, trocando parâmetros que alteram o comportamento dos mesmos. A decisão da alteração de algum parâmetro é determinada fora da RSSF, pelos dados armazenados na ontologia e processados pelo SIP. Por exemplo, a partir dos dados coletados pelos nós sensores de uma RSSF, percebe-se uma repetição dos dados de sensoriamento de um nó sensor particular durante um determinado período de tempo. Assim, a taxa de amostragem deste 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 os nós sensores. O processamento é determinado pelo Módulo de Processamento Semântico da Informação (SIP) e executado pelo Middleware Ciente de Reconfiguração para Rede de Sensores Sem Fio (RAMSES).
De forma sumarizada, as principais contribuições deste trabalho são:
Uma Infraestrutura Semântica para RSSF, com uma arquitetura que trabalha com
dados 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 de serviços (comunicação, agregação de dados, reconfiguração, dentre outros), de forma transparente para a aplicação;
Um serviço de reconfiguração paramétrica para nós sensores que funciona em tempo
de execução, baseado em dados transmitidos pelos nós sensores e armazenados em uma base de dados semântica, fora da RSSF;
Um módulo de processamento semântico que realiza todo o processamento dos
dados 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 de reconfiguração;
Um mecanismo de consulta do estado das RSSFs realizado através de uma base
de dados semântica, de forma comum entre diferentes redes e aplicações, sem ambiguidades 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 seguinte forma:
O Capítulo 2 introduzirá os conceitos básicos necessários para o entendimento desse
trabalho. Com este intuito, serão apresentadas as definições, principais elementos e características das RSSFs, conceitos relacionados aos sistemas de middleware e sua utilizaçã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 Sem
Fio (SITRUS). Neste capítulo, será abordada a visão geral da infraestrutura, sua arquitetura, as principais partes que a constituem e como interagem entre si e suas funcionalidades.
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 com as informações geradas pelas RSSFs e com os serviços disponibilizados para as aplicações. Dessa forma, serão abordados no capítulo a visão geral do middleware e em seguida sua arquitetura, com a interação entre as camadas que a compõe, bem como as funcionalidades inerentes de cada uma delas. Por fim, será apresentada a implementaçã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ão abordados 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 ontologia desenvolvida para a SITRUS e, por fim, sua implementação.
Como forma de demonstrar a aplicabilidade da SITRUS, será apresentado no Capítulo
6 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. Os
principais trabalhos na área de RSSF, middleware, ontologia e reconfiguração para sensores 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,
23 23 23
2
Conceitos 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 e Web 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ão discutidos os principais conceitos referentes aos sistemas de middleware, bem como sistemas de
middlewarepara 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 a
partir 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 aplicadas
são previamente e explicitamente definidos. Formal refere-se ao fato de que se espera que uma ontologia seja processável por um computador, o que exclui definições em linguagem natural, por exemplo. Finalmente, uma ontologia é compartilhada porque descreve um conhecimento consensual, que é utilizado por mais de um indivíduo e aceito por um grupo.
SegundoNOY; MCGUINNESS(2001), as ontologias são importantes para:
Compartilhar entendimento comum da estrutura de informação entre pessoas e
agentes 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
O compartilhamento do entendimento comum da estrutura da informação entre pessoas e 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ível que outras aplicações possam reutilizá-la. Além disso, pode-se construir uma ontologia maior a partir 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õem esse 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 dizer que a ontologia, que representa o conhecimento de domínio, está representada separadamente da aplicação que utiliza essa ontologia. Dessa forma, aplicações distintas podem utilizar uma mesma 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. Essa análise é importante para verificar se a ontologia atende às necessidades identificadas para a representação do conhecimento sobre um referido domínio. Além disso, é importante constatar se alterações podem ser efetuadas na sua estrutura e, com isso, aumentar a possibilidade de reutilizaçã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 do domí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 de domí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 mais
genéricos e abstratos dessa área;
Ontologias Gerais (ou de Topo): Trazem definições abstratas necessárias para a
compreensã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
2.1. ONTOLOGIA E WEB SEMÂNTICA 25 O conhecimento de um domínio em uma ontologia é formalizado a partir da utilização
de quatro tipos de componentes (USCHOLD et al.,1996):
Classes: Representam um conjunto ou tipo de objetos, conceitos ou categoria de
conceitos, normalmente organizadas em taxonomias;
Instâncias: Materialização dos objetos do domínio;
Propriedades: Representam as características das classes e instâncias, estabelecendo
relacionamento entre as classes; e
Restrições: Restringem os relacionamentos, que são interligações entre os conceitos
de um domínio;
As ontologias são comumente ilustradas como grafos, em que os vértices representam as classes e instâncias, e as arestas representam os relacionamentos entre esses vértices. As ontologias 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 em
eXtensible Markup Language(XML).
2.1.1
A Linguagem OWL
OWL é uma linguagem textual para instanciar e definir ontologias. Ela representa explicitamente os significados dos termos de um vocabulário, bem como o relacionamento desses termos. Essa capacidade de representação de expressões e suas relações é o que definem OWL
como uma linguagem ontológica (MCGUINNESS; HARMELEN,2004).
A Web Semântica (BERNERS-LEE; HENDLER; LASSILA,2001) busca adicionar
significado aos dados publicados na Web, para que, a partir disso, os computadores possam efetuar processamento sobre esses dados, extraindo assim resultados semânticos deles. O objetivo principal 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ógico que permita o compartilhamento global de conhecimento assistido por máquinas. A integra-ção das linguagens ou tecnologias XML, RDF, arquiteturas de metadados, ontologias, agentes computacionais, 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 sua arquitetura, onde cada camada explora e utiliza recursos das camadas inferiores. Ela mostra como 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 Web clássica baseada em hipertexto.
User interface and applications Trust Proof Cryptogr aphy Unifying Logic Querying: SPARQL Ontologies:
OWL RIF/SWRLRules:
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), um
modelo de representação de dados recomendado pelo World Wide Web Consortion (W3C) que utiliza metadados para possibilitar a descrição de recursos (imagens, informações pessoais, redes sociais, entre outros) e com isso, proporcionar uma semântica aos recursos descritos. Além de
RDF, 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., as
que não possuem axiomas nem estruturas de relacionamento sofisticadas. Sendo assim, ela suporta restrições mais simples, por exemplo, cardinalidade.
OWL DL: Foi projetada para se obter a máxima expressividade possível enquanto
mantém a completude computacional (para todas as computações se garante tempo finito), 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 DL inclui todas as construções de linguagem OWL, mas elas podem ser usadas somente sob certas restrições (por exemplo, restrições numéricas não podem ser colocadas em propriedades transitivas). OWL DL é assim chamada devido a sua correspondência com as lógicas de descrição, base formal da OWL.
2.1. ONTOLOGIA E WEB SEMÂNTICA 27
OWL Full: Foi projetada para ter máxima expressividade e liberdade sintática do
RDF sem nenhuma garantia computacional. É baseada em uma semântica diferente da OWL Lite ou OWL DL e projetada para preservar alguma compatibilidade com o RSF Schema. Por exemplo, em OWL FULL uma classe pode ser tratada simultaneamente como uma coleção de indivíduos e como um indivíduo em si mesmo. Ela permite que uma ontologia aumente o vocabulário pré-definido de RDF ou OWL. OWL FULL é indecidível, de modo que nenhum raciocinador é capaz de executar de forma completa para ele.
2.1.2
Estrutura de uma Ontologia OWL
Um documento OWL consiste em declarações de namespaces, um cabeçalho opcional que se refere à ontologia e definições de classes, propriedades e indivíduos. Os namespaces são importantes para fazer referência aos termos definidos em diferentes ontologias, além de ser um meio 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. Na
linha 6 é atribuída à variável rdf a url http://www.w3.org/1999/02/22-rdf-syntax-ns, que contém a definição de uma ontologia já existente, e dessa forma, os elementos definidos dessa ontologia podem ser referenciados no desenvolvimento de uma nova ontologia, a partir do uso dessa variável. O mesmo com as variáveis rdfs e owl, definidas respectivamente nas linhas 8 e 9.
1 <rdf:RDF 2 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 da taxonomia. 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 no documento 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 ser definidas a partir do elemento owl:Class (Linhas 1 e 3) e seus nomes são identificados pelo atributo 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 estabelecer relacionamentos entre indivíduos ou entre indivíduos e valores de dados. Estes relacionamentos permitem afirmar fatos gerais sobre os membros das classes e podem também especificar fatos
sobre 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 e
valores 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.
2.1. ONTOLOGIA E WEB SEMÂNTICA 29 Além disso, ambas são subclasses da classe RDF rdf:Property. O domínio e sua imagem são definidos respectivamente pelos elementos rdfs:domain e rdfs:range, como apresentado pela Figura 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 o relacionamento da propriedade isToppingOf com a classe PizzaTopping é realizada a partir do elemento rdfs:domain (Linha 8).
Os indivíduos de uma ontologia são também conhecidos como instâncias. Os indivíduos podem ser referenciados como instâncias de classes. Eles representam objetos no domínio de interesse. 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 uns dos 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)) proporciona acesso aos dados representados em documentos baseados em RDF. Essa linguagem é baseada em triplas 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 a ontologia 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 classe
Pizzae a classe PizzaTopping. A consulta está dividida em duas partes: a cláusula SELECT, que
identifica as variáveis que aparecerão no resultado da consulta, e a cláusula WHERE, onde são realizadas as restrições para a execução da consulta.
1 SELECT ?subject ?object
2 WHERE {
3 ?subject or:hasTopping ?object
4 }
Figura 2.6: Consulta Simples em SPARQL
SPARQL permite a realização de consultas mais complexas, a partir do uso de operadores ló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 últimos anos, principalmente devido às inovações tecnológicas introduzidas pelo avanço em microeletrô-nica, mecâmicroeletrô-nica, comunicação sem fio e eletrônica digital. Este tipo de rede é formada geralmente por centenas ou milhares de dispositivos autônomos que tendem a ser projetados com pequenas
dimensõ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érias restrições se comparadas aos modelos de redes tradicionais, como por exemplo, capacidade computacional reduzida, pouca memória disponível, comunicação de curto alcance, possibilidade reduzida 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ço
colaborativo 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 realizam processamento local e disseminam as informações para um ponto de acesso em um esquema de comunicação de múltiplos saltos (multi-hop) ou um salto (one-hop), podendo cooperar e permitir a distribuição de tarefas e o transporte de dados de uma forma eficiente quanto ao consumo de energia.
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 eles se 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 entre a 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,
2.2. REDE DE SENSORES SEM FIO 31
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 uso
de 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 de produtos, brinquedos interativos, estruturas inteligentes com sensores embutidos, instrumentação em 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 superar as diferenças entre as tecnologias de hardware, as restrições de consumo de energia e, ao
mesmo tempo, atender a um amplo domínio de aplicações (AKYILDIZ et al.,2002b). Outra
característica importante das RSSFs é que elas devem ser escaláveis, permitindo que novos nós sejam incorporados à rede. Além disso, em uma RSSF, as posições de cada nó não precisam ser pré-determinadas ou pré-calculadas. Assim, a posição do sensor é algo aleatório e deve ser tratada pelos protocolos de comunicação e gerenciamento da rede.
O desenvolvimento de aplicações para uma RSSF envolve uma série de fatores a serem considerados, 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, uma unidade 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 adaptativo ao ambiente.
Consumo de Energia: Economia de energia constitui parte fundamental no projeto de uma RSSF, devido à escassez de recursos de bateria, que na maioria dos tipos de sensores são
insubstituíveis. Inúmeras pesquisas (SHA; HACKMANN; LU,2013;ANASTASI et al.,2009;
PANTAZIS; VERGADOS,2007;SHI,2007;RHEE; SEETHARAM; LIU,2004) têm sido feitas para 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 saber lidar com elas de maneira automática e natural. Sensores podem falhar por diversos motivos como falta de energia, falta de visibilidade para outro nó da rede ou até mesmo algum dano físico. Como eles são dispostos em grandes quantidades no campo a ser sensoreado, a falha de alguns 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 variar das centenas aos milhares. Em algumas aplicações específicas podendo até atingir a casa dos milhõ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 com que os sensores estão espalhados na região a ser sensoreada. Esta densidade pode variar muito e os mecanismos de transmissão devem ser capazes de lidar com esta variação e utilizá-la a seu favor.
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 manuteninterven-ção da topologia da rede é algo fundamental para o seu funcionamento. A manutenção da rede pode ser dividida em três fases: a fase de implantação dos nós (maneira como os nós serão dispostos em sua área de cobertura), pós implantação (onde manutenção na topologia pode acontecer devido à mudança na posição dos nós, alcance, energia disponível, mau funcionamento, detalhes da tarefa a ser desempenhada pela rede) e a fase de implantação de novos nós (em que nós adicionais podem ser dispostos a qualquer momento para reposição de nós com problemas, seja por destruição ou por falta de energia, mudando assim a topologia da rede).
Meio de Transmissão: A comunicação entre os nós é tipicamente realizada por rádio frequência. Isto cria liberdade na implementação ao mesmo tempo em que cria um problema no funcionamento dos nós, devido à possíveis interferências provocadas por outros aparelhos que utilizem a mesma faixa de frequência. Outras opções de comunicação em RSSF incluem a utilização de infravermelho e a comunicação óptica.
2.2. REDE DE SENSORES SEM FIO 33
2.2.2
TinyOS e nesC
Sistemas operacionais para sensores são projetados de forma a economizar o máximo de energia possível. Além disso, eles devem ser eficientes em termos de consumo de memória e processamento e ágil o suficiente para permitir que várias aplicações usem simultaneamente os 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 bastante
utilizado e projetado para RSSF, e implementado na linguagem de programação nesC (GAY
et al.,2003).
O TinyOS é um sistema operacional que respeita rigorosamente as características de baixa capacidade computacional e de armazenamento dos nós sensores. Ele foi desenvolvido para oferecer um gerenciamento de hardware de diversos fabricantes e fornecer uma abstração de algumas partes do hardware para as aplicações.
O sistema operacional provê interfaces e componentes para hardware com atividades em comum, tais como pacotes de comunicação, ativação, sensoriamento e armazenamento. Isso facilita o desenvolvimento de aplicativos, visto que não é necessário desenvolver algoritmos diferentes 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, diversas implementações do mesmo serviço, evolução do hardware e adaptabilidade aos requisitos de aplicações. A principal característica do nesC é a visão holística do sistema. As aplicações dos nós sensores são bastante dependentes do hardware, e cada nó executa apenas uma aplicação por vez.
NesC é uma linguagem orientada a componentes com um modelo de execução baseado em eventos. Os componentes nesC possuem uma certa similaridade com os objetos de uma linguagem orientadas a objetos no sentido em que ambos encapsulam estado e interagem entre si 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 suas interações são determinados em tempo de compilação ao invés de tempo de execução, evitando com isso o desperdício de recursos alocados e não usados ou mesmo falhas que porventura venham a ocorrer em tempo de execução. Dessa forma, nesC tenta compilar tantas decisões quanto for possível.
Uma grande vantagem desse modelo orientado a componentes é o fato do desenvolvedor poder construir a aplicação utilizando um conjunto de componentes existentes e adicionando código extra, quando necessário, à execução da aplicação. Assim, ao invés de ser um SO de propósito geral, TinyOS comporta-se como um framework que permite a construção de um novo TinyOS específico, evitando o uso de componentes que não são necessários para a execução da aplicação.
Outra característica bastante interessante no nesC é o suporte a modelos de concorrência do 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 baixa sobrecarga, ao contrário do modelo de concorrência baseado em thread, em que a pilha de
threadsrequer grande consumo de memória. Entretanto, como qualquer sistema concorrente,
condições de corrida (race conditions), starvation, deadlock, e não-determinismo são fontes possíveis de bugs. Tentando evitar esses problemas de concorrência, o TinyOS tenta identificar e assegurar a ausência das condições de corrida em tempo de compilação. Além da detecção de condição de corrida, o compilador realiza ainda a criação de componentes estaticamente e eliminação de código morto.
Um programa TinyOS é um grafo de componentes, onde cada componente é uma entidade
computacional independente que encapsula serviços definidos por uma ou mais interfaces (LEVIS
et 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, enquanto tarefas 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érmino do 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 podem ser bloqueantes. A execução de um serviço, isto é, a requisição de um serviço (comando) e a sinalização de conclusão (evento correspondente) são desacopladas. Em uma operação como essa, 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 uso de 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. Uma aplicaçã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 que a aplicação usa.
Um componente tem dois tipos de interfaces: aquela que ele provê e a que ele usa. Estas interfaces definem como o componente interage diretamente com outros componentes. Uma interface 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ção de 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 de funções a serem implementadas pelo provedor da interface (comandos) e também pelo usuário dessas interfaces (eventos), o que permite que uma simples interface represente uma complexa interação entre componentes.
