Uma Proposta de Arquitetura de Redes de Sensores sem Fio ... · Allan Francisco Forzza Amaral Uma Proposta de Arquitetura de Redes de Sensores sem Fio Aplicada ao Monitoramento Térmico

Allan Francisco Forzza Amaral

Uma Proposta de Arquitetura de Redes de Sensores sem Fio Aplicada ao Monitoramento Térmico da Rede de Frios

VITÓRIA/ES

2016



Dissertação submetida ao Programa de Pós-graduação em Informática da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do título de Mestre em Informática.

Orientador: Prof. Dr. José Gonçalves Pereira Filho

VITÓRIA/ES

2016



Dissertação submetida ao Programa de Pós-graduação em Informática da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do título de Mestre em Informática.

Aprovada em 29 de Abril de 2016

COMISSÃO JULGADORA: __________________________________ Prof. Dr. José Gonçalves Pereira Filho Departamento de Informática - UFES Orientador __________________________________ Profa. Dra. Patrícia Dockhorn Costa Departamento de Informática – UFES __________________________________ Prof. Dr. Júlio Cesar Nardi Coordenadoria de Informática – Ifes Colatina

__________________________________ Profa. Dra. Silvana Rossetto Departamento de Ciência da Computação - UFRJ

Se fosse fácil achar os caminhos das pedras, tantas pedras no caminho não seria ruim.

Humberto Gessinger

Agradecimentos

Agradecer é uma tarefa complicada. Às vezes o menor dos atos faz toda

diferença no final e só observamos quando já é tarde. De qualquer forma, em minhas

lembranças sempre estarão pessoas que me apoiaram neste trabalho. Primeiramente a

Deus, que se concretiza na natureza humana e suas virtudes. Ao meu orientador José

Gonçalves, que abriu as portas para que eu pudesse experimentar este mundo novo que

é a ciência, pesquisa, discussão e também pelo apoio incondicional. Aos professores do

departamento de informática da UFES com os quais tive contato. Aos incansáveis

professores Igor e Júlio com os quais pude trocar experiências e discussões sobre este

trabalho. Ao filho que eu ainda não tive, Matheus, por horas e horas de trabalho em

conjunto e dedicação. Ao colega Isaac, pela contribuição com temas importantes sobre

este trabalho. Ao meu fisioterapeuta Maikon, que nos momentos de crise agiu com o

profissionalismo que a tarefa exige. A minha mãe Rachel, pelas palavras de incentivo. E

em memória de meu pai, José Amaral, que nos deixou no ano passado.

RESUMO

Com o novo paradigma da Internet das Coisas (IoT) os objetos físicos do mundo real

estão cada vez mais dotados de capacidades para se integrar ao mundo digital,

aumentando sua importância em diversos domínios de interesse, p. ex., na indústria, em

residências, cidades inteligentes, etc. Neste contexto, as Redes de Sensores sem Fio

(RSSF) se apresentam como uma das abordagens capazes de observar os fenômenos

que ocorrem nestes ambientes. O desenvolvimento de aplicações reais de RSSF/IoT

envolve várias questões tecnológicas que se apresentam como desafios ao preencher a

lacuna entre os aspectos conceituais e de implementação. Num cenário real, os desafios

se iniciam desde a concepção física da RSSF, passando pelos módulos computacionais

que representam os elementos que tratam a qualidade da informação e as situações das

entidades monitoradas até chegar à aplicação que consome os dados. Este trabalho

propõe uma arquitetura conceitual para redes de sensores sem fio com suporte à

qualidade da informação e gerenciamento de situações, além de refletir os conceitos da

ontologia Semantic Sensor Network e seus serviços. A arquitetura tem foco na avaliação

da qualidade da informação produzida pelos sensores e nos estados das entidades

monitoradas. A arquitetura conceitual proposta foi utilizada na construção de uma

aplicação que utiliza rede de sensores para capturar os dados das temperaturas em

câmaras de resfriamento e congelamento, permitindo armazenar, avaliar e informar

dados dos sensores das câmaras monitoradas.

Palavras-chave: Redes de Sensores; Sensores semânticos; Qualidade da

Informação; Situação e Contexto

ABSTRACT

With the new paradigm of Internet of Things (IoT) physical objects in the real world are

increasingly equipped with capabilities to integrate the digital world, increasing its

importance in various fields of interest, e. g., in industry, in homes, smart cities, etc. In

this context, the Wireless Sensor Networks (WSN) are presented as one of the

approaches able to observe the phenomena that occur in these environments. The

development of real applications of WSN/IoT involves several technological issues that

present themselves as challenges to bridge the gap between the conceptual and

implementation aspects. In a real scenario, the challenges begin from the physical

design of WSN, through the computational modules that represent the elements that

address the quality of information and situations of monitored entities to reach the

application that consumes the data. This paper proposes a conceptual architecture for

wireless sensor networks to support the quality of information and management

situations, and reflect the concepts of ontology Semantic Sensor Network and its

services. The architecture has focused on assessing the quality of information produced

by the sensors and the states of the monitored entities. The conceptual architecture

proposed was used to build an application that uses sensor network to capture the data

of temperatures in cooling chambers and freezing, allowing you to store, evaluate and

report sensor data of monitored cameras.

Keyworkds: Wireless Sensor Network, Semantic Sensors, Quality of

Information, Situation and Context.

Lista de Figuras

FIGURA 1 – SENSORES, NODOS SENSORES E INTERFACE DE COMUNICAÇÃO................................................ 9 FIGURA 2 – PILHA DE PROTOCOLOS EM REDES DE SENSORES. FONTE (AKYILDIZ E VURAN, 2010) ............. 11 FIGURA 3 – ENGINE DO PROTOCOLO CTP. FONTE (CHAWLA ET AL., 2013) ............................................... 12 FIGURA 4 – ONTOLOGIA SSN. ADAPTADO DE (COMPTON ET AL., 2012) ................................................... 16 FIGURA 5 – ORIGENS DE OUTLIERS EM REDES DE SENSORES SEM FIO E SUAS IDENTIDADES. FONTE: (ABID,

KACHOURI E MAHFOUDHI, 2014) .................................................................................................. 24 FIGURA 6 – TAXONOMIA DE TÉCNICAS DE DETECÇÃO DE OUTLIER PARA RSSF. FONTE: (KRIEGEL, KRÖGER

E ZIMEK, 2010) ............................................................................................................................. 25 FIGURA 7 – ARQUITETURA DE SISTEMAS BASEADOS EM REGRAS. FONTE (FRIEDMAN-HILL, 2003) ............ 29 FIGURA 8 – MODELO BÁSICO DE UMA ARQUITETURA ORIENTADA A SERVIÇOS. FONTE: (NAKAMURA, 2012)

.................................................................................................................................................... 32 FIGURA 9 – LEIAUTE DA RSSF PROPOSTO EM (BRUNO, 2013) ................................................................. 41 FIGURA 10 – ESTRATÉGIA DE IMPLANTAÇÃO WAPMS PROPOSTA EM (KHEDO ET AL., 2010)..................... 43 FIGURA 11 – FORMATO DE REGRAS DA ARQUITETURA PROPOSTA EM (SON ET AL., 2009) .......................... 44 FIGURA 12 – ARQUITETURA SEMSENSE PROPOSTA EM (MORARU ET AL., 2011) ........................................ 44 FIGURA 13 – SUBZONAS DE LARGA ESCALA E A LOCALIZAÇÃO DOS NODOS SENSORES PROPOSTA POR (ZHOU

ET AL., 2015) ................................................................................................................................. 45 FIGURA 14 – ARQUITETURA CONCEITUAL .............................................................................................. 50 FIGURA 15 – ARQUITETURA DA IMPLEMENTAÇÃO .................................................................................. 56 FIGURA 16 – FRAGMENTO DA BASE DE DADOS/METADADOS. ................................................................... 58 FIGURA 17 – POSICIONAMENTO E FUNÇÃO DO MÓDULO DE QOI NA ARQUITETURA DE IMPLEMENTAÇÃO ... 60 FIGURA 18 – FUNCIONAMENTO DO MÓDULO DE SITUAÇÕES NA ARQUITETURA DE IMPLEMENTAÇÃO ........ 61 FIGURA 19 – FRAGMENTO DA ONTOLOGIA SSN UTILIZADO PARA O DOMÍNIO DA REDE DE FRIOS ............... 62 FIGURA 20 – CENÁRIO DE APLICAÇÃO ................................................................................................... 65 FIGURA 21 – INTERFACE DE ACESSO AOS MÓDULOS DE GERENCIAMENTO E MONITORAMENTO .................. 66 FIGURA 22 – ARQUITETURA PROPOSTA NO CENÁRIO DE APLICAÇÃO ....................................................... 66 FIGURA 23 - FRAGMENTO DA ONTOLOGIA DE DOMÍNIO DESENVOLVIDA PARA O CENÁRIO. ........................ 67 FIGURA 24 – CONFIGURAÇÃO DOS PARÂMETROS DA ENTIDADE MONITORADA.......................................... 68 FIGURA 25 – INTERFACE GRÁFICA DO MONITORAMENTO DA REDE ........................................................... 70 FIGURA 26 - MODELO RELACIONAL DA APLICAÇÃO REFLETINDO AS ONTOLOGIAS SSN E DE DOMÍNIO ....... 70 FIGURA 27 – PROTÓTIPOS CONSTRUÍDOS PARA APLICAÇÃO NO CENÁRIO .................................................. 72 FIGURA 28 – LEITURAS DE TEMPERATURAS DE UM BALCÃO EXPOSITOR DE CONGELAMENTO ABERTO ....... 74 FIGURA 29 – LEITURAS DE TEMPERATURA DE UM BALCÃO EXPOSITOR DE RESFRIAMENTO FECHADO ......... 75 FIGURA 30 – LEITURAS DE TEMPERATURA DE UM BALCÃO EXPOSITOR DE CONGELAMENTO HÍBRIDO ........ 75 FIGURA 31 – FLUXO DE FUNCIONAMENTO DO MÓDULO DE QOI ............................................................... 77 FIGURA 32 – INTERFACE DE CONFIGURAÇÃO DO MÓDULO DE QOI........................................................... 78 FIGURA 33 – INTERFACE DE INSERÇÃO DE REGRAS.................................................................................. 80 FIGURA 34 – EXEMPLO DO CONTROLE DE SITUAÇÕES MODELADAS NO CENÁRIO INSTANCIADO ................. 81 FIGURA 35 – DIAGRAMA DO MÓDULO DE SITUAÇÃO ACOPLADO NA PLATAFORMA SCENE....................... 82 FIGURA 36 – REPRESENTAÇÃO DE UM WEB SERVICE CONTENDO A VARIAÇÃO DE TEMPERATURA DE UM

SENSOR ........................................................................................................................................ 83 FIGURA 37 – ESTRUTURA DO MECANISMO DE SERVIÇOS WEB.................................................................. 83 FIGURA 38 – CENTRAL DE MONITORAMENTO DAS ENTIDADES ................................................................. 84

Lista de Tabelas

TABELA 1 – PROTOCOLOS PARA RSSF. ADAPTADO DE (RUIZ ET AL., 2004) .............................................. 12 TABELA 2 – RELAÇÃO ENTRE OS REQUISITOS E OS ELEMENTOS DA ARQUITETURA PROPOSTA .................... 55 TABELA 3 – RESULTADOS DOS TESTES DO ALGORITMO ESTATÍSTICO EM SUAS RESPECTIVAS BASES DE

DADOS.......................................................................................................................................... 76 TABELA 4 – RESULTADOS DE FALSOS POSITIVOS DO MÓDULO DE QOI ..................................................... 79 TABELA 5 – RESULTADOS DOS VALORES ANÔMALOS DETECTADOS PELO MÓDULO DE QOI ....................... 79 TABELA 6 – COMPARAÇÃO ENTRE OS TRABALHOS REPORTADOS NA LITERATURA .................................... 92

Lista de Siglas/Acrônimos

RSSF - Redes de Sensores Sem Fio

MEMS - Micro Eletro-Mecanical Systems

RDF - Resource Description Framework

SSNO - Semantic Sensor Network Ontology

Sumário

1. Introdução ................................................................................................................. 1

1.1 - Motivação ......................................................................................................... 1

1.2 – Objetivos .......................................................................................................... 5

1.3 –Métodos de Pesquisa .......................................................................................... 6

1.4 - Organização do Trabalho ................................................................................... 7

2. Referencial Teórico ................................................................................................... 8

2.1 - Redes de Sensores Sem Fio ............................................................................... 8

2.2 - Arquiteturas para Redes de Sensores Sem Fio ................................................. 10

2.3 – Semântica em Redes de Sensores Sem Fio ...................................................... 13

2.4 – Qualidade da Informação (QoI)....................................................................... 18

2.4.1 - Detecção de Outliers ................................................................................. 23

2.5 – Situação e Contexto ........................................................................................ 26

2.5.1 – Sistemas Baseados em Regras .................................................................. 28

2.6 – Orientação a Serviço e RSSF .......................................................................... 30

2.7 - Considerações do Capítulo .............................................................................. 34

3. Trabalhos Relacionados .......................................................................................... 35

3.1 - Qualidade da Informação em Redes de Sensores ............................................. 35

3.2 - Gerenciamento de Situações e Sistemas de Regras .......................................... 37

3.3 – Sensoriamento como Serviços......................................................................... 38

3.4 - Sensores Semânticos ....................................................................................... 40

3.5 – Arquiteturas Propostas na Literatura ............................................................... 41


4. Arquitetura Proposta ............................................................................................... 47

4.1 – Introdução ...................................................................................................... 47

4.2 - Princípios e Requisitos .................................................................................... 48

4.3 - Arquitetura Conceitual .................................................................................... 50

4.4 – Arquitetura de Implementação ........................................................................ 55

4.4.1 - Elementos da Arquitetura .......................................................................... 56


5. Aplicação da Arquitetura Proposta na Rede de Frios ............................................... 64

5.1 - Cenário real de implementação ........................................................................ 64

5.2 - Mecanismos de Coleta de Dados na Rede de Sensores ..................................... 71

5.2.1 – Análise dos dados coletados ..................................................................... 73

5.2.2 - Análise dos dados disponibilizados ........................................................... 76

5.3 – Situações das entidades monitoradas ............................................................... 80

5.4 - Disponibilização dos dados ............................................................................. 83

5.5 – Considerações do capítulo............................................................................... 85

6. Discussão ................................................................................................................ 86

6.1 – Camada de tecnologia/infraestrutura ............................................................... 86

6.2 – Camada de dados ............................................................................................ 87

6.3 – Módulos de Gerenciamento ............................................................................ 88

6.4 – Comparação com outras propostas .................................................................. 90

7. Considerações Finais ............................................................................................... 93

8. Referências ............................................................................................................. 96

1

1. Introdução

Este capítulo apresenta a motivação, os objetivos e a organização deste trabalho.

São introduzidas questões relacionadas com as Redes de Sensores Sem Fio (RSSF) e

como elas se apresentam no paradigma da Internet das Coisas (Internet of Things –

IoT). Além disso, problemas como a conservação de energia da RSSF, qualidade das

informações providas pelos sensores e sensibilidade ao contexto das aplicações se

apresentam como novas demandas e problemas que surgem na construção de novas

classes de aplicações para domínios que utilizam IoT/RSSF e são aqui introduzidos.

Esses problemas e demandas, devidamente tratados de forma integrada, serviram de

base para a proposta de arquitetura desenvolvida neste trabalho.

1.1 - Motivação

Atualmente, o grande progresso no campo de dispositivos embarcados permite

que objetos físicos, tais como, eletrodomésticos, máquinas industriais, redes de

sensores, celulares, etc. se conectem a Internet. A consequência deste progresso pode

ser notada com a criação de novos paradigmas, como a Internet das Coisas (IoT) (Gubbi

et al., 2013). Sensores embarcados em entidades físicas e conectados à Internet criam

novas oportunidades de projetos para aplicações interativas as quais conterão

informação em tempo real referentes a lugares e objetos do mundo físico (França, de et

al., 2011).

Nesse contexto, as Redes de Sensores Sem Fio (RSSF) se destacam como uma

importante ferramenta para monitorar os fenômenos do mundo real. Estas redes são

formadas por nodos com capacidade de processamento, armazenamento, comunicação e

sensoriamento, permitindo aos usuários observarem com nível de detalhes os ambientes

ou entidades de interesse (p. ex., nível de CO2 de uma sala ou a umidade do solo numa

área irrigada). Se por um lado as RSSF são concebidas com características atrativas,

como o baixo custo e pequenas dimensões (permitindo monitorar espaços com elevado

grau de precisão e com maior granularidade), por outro estas redes têm algumas

restrições, como baixo poder computacional, matriz energética limitada e pouca largura

de banda (Gil, Santos e Cardoso, 2014). Isso faz com que a construção de novas classes

de aplicações leve em consideração tais restrições.

2

As pesquisas na área de RSSF têm como objetivo abordar estas restrições

introduzindo novos conceitos de design, criar ou melhorar os protocolos existentes,

construir novas aplicações e desenvolver novos algoritmos (Yick, Mukherjee e Ghosal,

2008). Normalmente estas pesquisas culminam em diferentes tipos de aplicações,

protocolos, arquiteturas e frameworks em que são apresentados diferentes soluções para

os problemas de restrições.

Num primeiro momento as pesquisas em RSSF concentraram-se no

desenvolvimento de infraestruturas de suporte, incluindo algoritmos, protocolos,

sistemas operacionais e linguagens, além de plataformas de hardware de sensoriamento.

Protocolos MAC (Shaik e Eswaran, 2012), protocolos de roteamento (Ko et al., 2011);

algoritmos de disseminação, difusão e sincronização; projetos de linguagens e sistemas

operacionais como nesC/TinyOS/Contiki (Akyildiz e Vuran, 2010); infraestruturas de

suporte a IP/IPv6/6LoWPAN (Hui, Culler e Chakrabarti, 2009); arquiteturas de

middleware (Bhuyan et al., 2014), e outras questões de infraestrutura direcionaram boa

parte das pesquisas.

Mais recentemente temos observado um movimento em direção ao

desenvolvimento de aplicações reais, geralmente tomando por base as infraestruturas de

suporte desenvolvidas ao longo dos últimos anos, por exemplo, em projetos específicos

tais como OpenIoT (Kefalakis et al., 2013), Almanac (Bonino et al., 2015) e

MakeSense (Casati et al., 2012). Cenários tais como Cidades Inteligentes, Healthcare,

Logística, dentre outros cenários reais, vem sendo explorados nestes e outros trabalhos

reportados na literatura.

As arquiteturas conceituais desenvolvidas nas infraestruturas de suporte

previamente apresentadas formam uma das questões centrais da pesquisa em IoT/RSSF.

Afinal, são elas que, em maior ou menor grau, são responsáveis pelo atendimento dos

requisitos impostos pelas aplicações e domínios de interesse no âmbito das pesquisas

desta área. Assim, a definição de modelos de domínio e padrões de representação de

sensores e suas observações, a existência de mecanismos de segurança e privacidade, a

introdução de arquiteturas orientadas a serviços e seus algoritmos de descoberta e

composição, a virtualização de sensores, etc., são exemplos de questões tratadas por

essas infraestruturas.

3

Como essas arquiteturas tratarão os novos requisitos que surgem,

particularmente no universo de IoT, são ainda um campo de pesquisa em andamento.

Além de questões tradicionais, como a preocupação com a conservação energética dos

nodos das redes, outras questões vêm sendo bastante discutidas atualmente. A análise

dos desafios atuais em Internet das Coisas tem revelado uma grande preocupação da

comunidade acadêmica com questões fundamentais, tais como a avaliação da qualidade

dos dados coletados pelos sensores (Bisdikian, Kaplan e Srivastava, 2013); a

necessidade de enriquecimento semântico dos dados provenientes dos sensores como

forma de promover a interoperabilidade (Barnaghi et al., 2012); o suporte à

sensibilidade ao contexto para a detecção automática de situações de interesse; o suporte

à definição de regras de alto nível para a descrição do comportamento reativo das

aplicações (Perera et al., 2012); a introdução de mecanismos que facilitem a integração

de IoT ao mundo dos processos de negócio (Meyer, Ruppen e Magerkurth, 2013), etc.,

se apresentando como questões que precisam ser tratadas de maneira integrada por tais

infraestruturas de suporte.

As infraestruturas de suporte normalmente são concebidas para tratar de

problemas em diversos cenários nos quais o uso de IoT/RSSF se mostra como uma das

possíveis alternativas para controlar/monitorar ambientes. Dentre estes cenários é

possível destacar desde aqueles mais amplos (p. ex., Smart Cities) até os mais limitados

(p. ex., controle de temperatura num determinado ambiente). Neste último caso pode-se

elencar, por exemplo, cenários nos quais o monitoramento da temperatura tem um papel

chave, sejam por questões de saúde (temperaturas adequadas no armazenamento de

alimentos, medicamentos, etc.) ou por questões econômicas (redução de prejuízos).

O cenário em que este trabalho é aplicado pertence ao domínio de rede de frios.

Neste caso, os equipamentos são dotados de mecanismos de refrigeração para

armazenar e manter os produtos a temperaturas adequadas para o uso ou consumo. Um

dos maiores problemas deste cenário é a perda ou degradação dos produtos pela

inexistência ou falha de um monitoramento constante da temperatura. O emprego de

baixas temperaturas tem sido muito utilizado para a conservação de alimentos com o

intuito de diminuir a velocidade das reações químicas e enzimáticas, retardar ou inibir o

crescimento e a atividade dos microrganismos. Como as alterações são consequências

dessas reações de microrganismos e enzimas, a vida útil de alguns alimentos pode ser

prolongada por meio do armazenamento sob refrigeração ou congelamento (Rodrigues

4

et al., 2014). Em termos práticos, pode-se dizer que um setor, como o supermercadista,

necessita monitorar suas instalações onde estão acondicionados produtos congelados e

refrigerados. Esse monitoramento deve ser constante e sistemático a fim de detectar os

momentos em que é necessária alguma intervenção a fim de manter a integridade dos

produtos. Com base nas necessidades deste cenário, a solução proposta precisa atender

um conjunto mínimo de requisitos. Por exemplo, o monitoramento dos equipamentos

deve ser constante e expressar, com certo grau de exatidão, a ocorrência de

determinados eventos em intervalos de tempo aceitáveis. Para atingir estes requisitos

alguns elementos precisam compor a rede de monitoramento para melhorar a

informação e o modo como ela é apresentada ao usuário consumidor dos dados. Dentre

estes elementos podemos destacar, por exemplo, aqueles que tratam a qualidade da

informação, que diz respeito a munir o usuário com dados relevantes e, ao mesmo

tempo, com certo grau de exatidão. Além disso, elementos que se preocupam se os

equipamentos estão funcionando dentro dos parâmetros estabelecidos também são

importantes, uma vez que permite ao usuário acompanhar ou ser avisado sobre a

ocorrência de determinadas situações de funcionamento da entidade monitorada (p. ex.,

a câmara de resfriamento/congelamento).

A união das necessidades do cenário abordado com o domínio de IoT/RSSF

propicia a concepção de uma arquitetura conceitual na qual os elementos podem ser

agrupados e organizados para atender os requisitos de ambos os domínios, isto é, no

domínio de rede de frios, no qual são estudados os problemas e soluções relativos ao

monitoramento e controle da temperatura e no domínio de IoT/RSSF, utilizado como

uma abordagem para facilitar a resolução de tais problemas. Questões como qualidade

da informação (QoI), situações/contexto e descrição semântica dos dados coletados dos

sensores constituem os pilares da arquitetura proposta. Em alguns cenários, sensores

podem produzir dados não relevantes e, no arcabouço de tecnologias o qual está

inserido, também podem produzir dados anômalos. Além disso, a natureza do

monitoramento tem como uma das metas detectar o estado nos quais as entidades

monitoradas se encontram. Adicionalmente, como parte do cenário de IoT/RSSF, estas

questões precisam refletir aspectos conceituais já consolidados e, portanto, melhorando

os problemas relacionados a interoperabilidade semântica. Esta organização tem sua

concretude numa arquitetura de implementação na qual os problemas previamente

apresentados são abordados.

5

Trabalhos propostos na literatura abordam algumas das questões discutidas até

agora, embora haja uma carência de soluções que as tratem de forma integrada,

particularmente no cenário de rede de frios. Estes trabalhos são guiados no sentido de

desenvolver arquiteturas que tem por objetivo apresentar soluções para o domínio ao

qual está inserido e tomam como base algumas das preocupações inerentes a IoT/RSSF.

Por exemplo, o trabalho descrito em (Bruno et al., 2013) aborda o uso de RSSF no

monitoramento térmico em Centros de Processamento de Dados; o trabalho proposto

em (Khedo et al., 2010) apresenta uma arquitetura de redes de sensores que tem suas

preocupações voltadas ao monitoramento da qualidade do ar e a arquitetura proposta em

(Son et al., 2009) aborda preocupações relacionadas às restrições das redes de sensores

em cenários de aplicações logísticas.

Os cenários dos trabalhos previamente listados podem ser melhorados através do

tratamento integrado das questões levantadas (QoI, situação/contexto, enriquecimento

semântico), contribuindo para a melhoria das soluções propostas. Estas melhorias estão

ancoradas em alguns elementos que podem ser integrados e utilizados para propor

soluções em algumas áreas nas quais as RSSF são utilizadas. Capturar fenômenos (p.

ex. temperatura, umidade, pressão, etc) em entidades (pessoa, lugar ou objeto) requer

que algumas preocupações sejam levadas em conta. Estas preocupações perpassam, por

exemplo, desde o momento da captura do fenômeno até a disponibilização da

informação para o consumidor dos dados.

1.2 – Objetivos

Este trabalho apresenta uma solução de RSSF para monitoramento de rede de

frios no qual as preocupações com esses novos requisitos – tratamento integrado de

conservação energética da RSSF, QoI, Situação/Contexto e Semântica – são abordados.

O trabalho está centrado numa proposta de uma arquitetura conceitual no qual os

elementos estão dispostos em camadas e integrados, além de prover transversalmente

mecanismos de gerenciamento visando atender os requisitos do cenário de estudo, como

o gerenciamento da qualidade das informações providas pelos sensores e o

gerenciamento de situações das entidades monitoradas. Em particular, a implementação

da arquitetura utiliza algoritmos estatísticos nos nodos sensores, algoritmos de

6

Qualidade da Informação (QoI), plataformas de situações e contexto, além de prover os

dados coletados como serviços.

A arquitetura proposta permite que uma RSSF forneça dados sobre os ciclos de

funcionamento das entidades monitoradas na rede de frios através da integração de

elementos capazes de prover dados confiáveis. Estes ciclos fornecem dados para uma

plataforma de situações integrada na arquitetura com o objetivo de obter o status de

operação das entidades utilizando uma plataforma de gerenciamento e acompanhamento

de situações.

1.3 –Métodos de Pesquisa

Além do estudo inicial dos temas de pesquisa relacionados ao trabalho, o método

de pesquisa de desenvolvimento da dissertação envolve o levantamento de requisitos

funcionais e não funcionais para o cenário abordado e, consequentemente, a execução

das seguintes atividades específicas:

Desenvolver um protótipo de uma RSSF que permita a aquisição de dados dos

ambientes monitorados;

Desenvolver e embarcar algoritmos que visam economizar a matriz energética

dos nodos sensores e, ao mesmo tempo, disponibilizar dados relevantes para os

usuários consumidores;

Enriquecer semanticamente os dados providos pelos nodos sensores através de

anotações espaciais e temporais tomando como base os conceitos das ontologias

de domínio das RSSF, p. ex., o padrão SSNO, do W3C;

Avaliar a Qualidade da Informação (QoI) disponibilizada pelos nodos da RSSF

como forma de prover aos consumidores dos dados relativa confiança nos

processos de tomada de decisão;

Integrar uma plataforma de suporte a situações na qual seja possível definir

regras/situações para o domínio apresentado;

Apresentar os dados dos nodos sensores através de interfaces legadas, como a

Web, por meio do consumo de serviços;

7

1.4 - Organização do Trabalho

Além desta introdução, o trabalho está organizado em mais sete capítulos, a

saber:

Capítulo 2: apresenta o referencial teórico abordando os conceitos tratados neste

trabalho. São descritos os conceitos de RSSF e suas arquiteturas, anotações

semânticas em dados de sensores, tratamento dos dados através da avaliação da

qualidade da informação, conceitos de situação/contexto e os serviços que são

prestados por estas RSSF.

Capítulo 3: discute os trabalhos e arquiteturas relacionadas com a proposta;

Capítulo 4: descreve a proposta da arquitetura conceitual e seus detalhes de

implementação;

Capítulo 5: apresenta um cenário real de implementação apontando os benefícios

do uso da arquitetura.

Capítulo 6: apresenta uma discussão do trabalho realizado à luz da

implementação do estudo de caso e dos experimentos realizados. O capítulo

posiciona ainda a arquitetura proposta comparando-a com outros trabalhos da

literatura;

Capítulo 7: conclui a dissertação, apresentando as considerações finais e as

perspectivas de trabalhos futuros;

8

2. Referencial Teórico

Este trabalho explora diferentes áreas de pesquisa, tais como redes de sensores

sem fio (RSSF), semântica em RSSF, qualidade e relevância das informações providas

pelos sensores, situações/contexto de entidades monitoradas e os serviços que estas

redes fornecem. O capítulo está organizado da seguinte forma: a seção 2.1 introduz as

redes de sensores sem fio, abordando suas características, restrições e aplicações. A

seção 2.2 apresenta as arquiteturas utilizadas em RSSF e como elas se integram. A

seção 2.3 aborda as questões semânticas relacionadas às RSSF. A seção 2.4 apresenta o

conceito de qualidade da informação e apresenta algumas técnicas que são utilizadas

nestas abordagens. A seção 2.5 introduz de forma geral os conceitos de

situações/contextos e sua relação com sistemas baseados em regras. A seção 2.6 traz o

conceito de serviços e como esta abordagem pode ser benéfica no paradigma de

IoT/RSSF.

2.1 - Redes de Sensores Sem Fio

O avanço que tem ocorrido na área de microprocessadores, novos materiais de

sensoriamento, microssistemas eletromecânicos (MEMS – Micro Electro-Mecanical

Systems) e comunicação sem fio têm estimulado o desenvolvimento e uso de sensores

“inteligentes” em áreas ligadas a processos físicos, químicos, biológicos, dentre outros.

É usual ter num único chip vários sensores que são controlados pela lógica do circuito

integrado, utilizando uma interface de comunicação sem fio.

Normalmente, o termo “sensor inteligente” é aplicado ao chip que contém um ou

mais sensores com capacidade de processamento de sinais e comunicação de dados. A

tendência é produzir esses sensores em larga escala, barateando o seu custo, e investir

ainda mais no desenvolvimento tecnológico desses dispositivos, levando a novas

melhorias e capacidades (Loureiro et al., 2003). Estes pequenos dispositivos podem ser

organizados e agrupados em diversas topologias formando uma comunicação

distribuída normalmente referenciada como Redes de Sensores Sem Fio (RSSF) ou

Wireless Sensor Networks (WSN) (Akyildiz et al., 2002). Estes pequenos dispositivos

são referenciados como nodos sensores que possuem, ainda que limitadas, capacidades

de processamento, memória e comunicação.

9

Elementos básicos de uma RSSF podem ser vistos na Figura 1. O nodo (b) é o

elemento da RSSF que é dotado de memória, capacidade de processamento e rádio. O

nodo representado por esta figura é um modelo IRIS da fabricante MEMSIC e possui

um slot para inserção de diversos tipos de sensores, p. ex., umidade, pressão, aceleração,

CO2, etc.

Figura 1 – Sensores, Nodos Sensores e interface de comunicação.

A função mais comum de um nodo sensor é observar propriedades físicas de um

ambiente. Isto é feito através de uma interface de sensoriamento normalmente acoplada

(junção de (a) com (b)) ou embutida no próprio nodo sensor (em caso de outros

modelos, p. ex., TelosB). Por exemplo, a Figura 1 (a) mostra a interface de

sensoriamento MDA100, que possui um sensor de temperatura e luminosidade, além de

uma área de prototipagem na qual é possível adicionar novos tipos de sensores.

Os dados coletados pelos sensores precisam ser transmitidos pelos nodos até

chegar a uma interface de comunicação apropriada para que sejam consumidos pelas

aplicações. Esta interface normalmente utiliza uma conexão serial (p. ex., USB) ou de

rede (p. ex., Ethernet). A Figura 1 (c) mostra uma interface de comunicação MIB520

USB na qual é conectado um nodo root, normalmente referenciado como sink na

literatura. Através da interface de comunicação, o nodo sink envia os dados para uma

estação base, normalmente representada por um microcomputador que processa e

armazena as informações providas pelas RSSF. De modo a possibilitar o intercâmbio de

dados entre a RSSF e uma rede tradicional TCP/IP, é necessário que haja um elemento

que seja capaz de se comunicar com os protocolos de ambas as redes. Este elemento é

conhecido como gateway.

10

Em muitas aplicações os sensores são colocados em áreas remotas, o que não

permite, facilmente, o acesso a esses elementos para manutenção. Neste cenário, o

tempo de vida de um sensor depende da quantidade de energia disponível. Aplicações,

protocolos e algoritmos para RSSF não podem ser escolhidos considerando apenas sua

“elegância” e capacidade, mas definitivamente a quantidade de energia consumida.

Assim, o projeto de qualquer solução para esse tipo de rede deve levar em consideração

o consumo, o modelo de energia e o mapa de energia da rede (Loureiro et al., 2003). O

modelo de energia representa os recursos físicos de um sensor e pode ser visto como um

modelo para os elementos consumidores que dependem de uma bateria que tem

capacidade finita de energia armazenada. Os elementos consumidores são compostos

pelo rádio, processador e sensores acoplados aos nodos.

A capacidade de processamento e transmissão de cada nodo está limitada pela

quantidade de energia disponível, observando-se que os nodos consomem diferentes

quantidades de energia dependendo se estão usando o rádio, lendo os sensores,

executando cálculos locais ou em estado adormecido. Por exemplo, a transmissão e

recepção de dados consomem três ou mais vezes energia do que qualquer outra

operação. Isso tem impacto direto na arquitetura e na operação dos protocolos usados

em redes de sensores sem fio (Souza, 2013).

2.2 - Arquiteturas para Redes de Sensores Sem Fio

Assim como nas arquiteturas de redes tradicionais, as RSSF têm características

que estão profundamente enraizadas na arquitetura: cada nodo é completamente

desenvolvido com todas as funcionalidades que vão da camada física até

funcionalidades da camada de aplicação, que se comportam coletivamente como um

sistema autônomo que executa várias funções de rede, como encaminhamento de dados

e controle de rede (Luo, Tan e Quek, 2012). O encaminhamento do dado sensoriado é

de fundamental importância numa RSSF e este fenômeno é normalmente tratado por

uma camada específica, que é a camada de rede. A literatura de RSSF cita vários

protocolos que tem como princípio básico traçar o caminho do dado sensoriado até um

nodo convergente, a que comumente chamamos de nodo sink. Adicionalmente,

dependendo do local monitorado, os sensores dispersos pelo ambiente podem estar fixos

ou serem móveis. Esta informação é de grande importância na escolha do protocolo de

roteamento. Estas questões evidenciam que as RSSF, por si mesmas, são compostas por

11

elementos arquiteturais semelhantes às redes tradicionais, entretanto, com problemas

específicos que precisam ser abordados, principalmente pelas restrições de CPU, rádio,

memória e energia que elas possuem.

A Figura 2 mostra, de maneira geral, a pilha de protocolos para redes de

sensores usadas tanto pelos nodos sensores quanto pelo nodo sink. Esta pilha combina

energia e roteamento, integra dados com protocolos de rede, utiliza comunicação de

rádio eficientemente e promove esforços cooperativos entre os nodos sensores. Assim

como nas redes tradicionais, as camadas física e enlace têm suas preocupações

relacionadas às técnicas de modulação, transmissão e recepção, controle de erros e

gerenciamentos de canais. Entretanto, dependendo das tarefas da rede, estes protocolos

podem ser modificados ou reconfigurados. Da mesma forma, a camada de rede tem o

cuidado de rotear os dados fornecidos pela camada de transporte. Adicionalmente, os

planos de energia, mobilidade e gerenciamento de tarefas monitoram a energia,

mobilidade e a distribuição de tarefas entre os nodos sensores. Mais detalhes sobre as

camadas podem ser obtidas em (Akyildiz e Vuran, 2010).

Figura 2 – Pilha de protocolos em redes de sensores. Fonte (Akyildiz e Vuran, 2010)

Vários protocolos das camadas citadas previamente são propostos na literatura

de RSSF. Estes protocolos são desenvolvidos visando, principalmente, economia dos

recursos da rede. A Tabela 1 sumariza alguns dos principais protocolos abordados na

literatura.

12

Tabela 1 – Protocolos para RSSF. Adaptado de (Ruiz et al., 2004)

Camada Protocolos

Transporte PFSQ, ESRT, RMST

Rede DD, SPIN, SAR, MULTI, STORM, PROC, TinyBeaconing, LEACH,

LEACH-C, TEEN, PEGASIS, ICA, GEOMOTE, GEAR, GPSR, CTP,

6LowPAN, RPL

Enlace S-MAC, ARC, T-MAC, BoX-MAC, DE-MAC, TRAMA

Física Transmissão em Rádio Frequência (RF), ótica e infravermelha.

Os protocolos apresentados previamente têm suas preocupações principalmente

voltadas para as questões do funcionamento da rede e gestão dos recursos. Por exemplo,

na camada de enlace o protocolo BoX-MAC (Moss e Levis, 2008) utiliza um

mecanismo que desativa o rádio dos nodos quando os mesmos não são usados,

economizando energia das baterias. Este mecanismo é ativado através de flags do tipo

Low Power Listening (LPL) quando a aplicação é compilada e embarcada nos motes.

Na camada de rede, O Collection Tree Protocol (CTP) é um dos protocolos coletores de

dados mais promissores em redes de sensores estáticas (Chawla et al., 2013). Trata-se

de um protocolo do tipo vetor-distância que calcula as rotas de cada nó até o nó raiz

(sink). O CTP é baseado em três componentes lógicos: Routing Engine (RE),

Forwarding Engine (FE) e Link Estimator (LE) conforme a Figura 3.

Figura 3 – Engine do Protocolo CTP. Fonte (Chawla et al., 2013)

13

O mecanismo RE se preocupa basicamente em transmitir beacons frames para

atualizar a tabela dos vizinhos. A lógica do FE basicamente encaminha pacotes de dados

da aplicação para os vizinhos, além de reparar rotas em loop e suprimir pacotes

duplicados. Por fim, o LE determina a qualidade do link com seus vizinhos

computando as estatísticas coletadas do número de beacons recebidos e o número de

pacotes transmitidos com sucesso.

No nível de aplicação, ainda incipiente, os esforços estão voltados em como

estabelecer padrões ou propor arquiteturas que facilitam a maneira de disponibilizar os

dados produzidos pelos sensores para os usuários consumidores. Arquiteturas como

SemSense (Moraru et al., 2011) são propostas na literatura com a finalidade de coletar

dados físicos do mundo real e disponibilizá-las na Web. A ideia é que este

desenvolvimento proverá novos serviços e permitirá novas direções para comunicação e

novos tipos de agentes envolvidos neste processo, p. ex., “things-to-persons” ou “thing-

to-thing”. Estas direções passam por questões como a interoperabilidade semântica

(Underwood et al., 2015). Dessa forma, componentes de enriquecimento semântico

podem usar ontologias como vocabulário comum para descrição semântica de dados e

metadados contidos, por exemplo, em componentes de armazenamento de dados.

Somadas a isso, há abordagens que buscam disponibilizar os dados dos sensores por

meio de serviços (Sensing as a Service - SenaaS). A ideia por trás deste conceito é

combinar o paradigma da Arquitetura Orientada a Serviços (SOA), já amplamente

utilizada por sua independência de plataforma, com as arquiteturas de redes de sensores.

2.3 – Semântica em Redes de Sensores Sem Fio

Objetos físicos e dispositivos estão se tornando cada vez mais objetos virtuais

devido as possibilidades de interconexão através da Internet. Com isso, há um potencial

interesse em adicionar sensoriamento do mundo real para a Internet e várias aplicações

e serviços web. A representação virtual de um objeto físico tem criado novos produtos e

serviços em diferentes domínios, como monitoramento ambiental e smart homes.

Conectar dispositivos físicos ao mundo digital representa um novo paradigma inspirado

na ideia de IoT, denominado Web of Things (WoT) (França, de et al., 2011). Esse novo

conceito se baseia em protocolos e padrões amplamente utilizado na Web, como HTTP

e URI e tem por objetivo alavancar a visão de conectividade entre o mundo físico e o

mundo digital englobando objetos do mundo físico (smart things) que passarão a ser

14

tratados da mesma forma que qualquer outro recurso Web. As pesquisas nesta área

envolvem esforços colaborativos da indústria, da academia e de comunidades como as

de Telecomunicações, Web Semântica e Informática. A proposição da Web Semântica

visa aprimorar os aspectos das buscas, da interoperabilidade de dados entre sistemas

Web e permitir que agentes possam processar automaticamente os dados e

conhecimento (Zhang e Hansen, 2008). Neste contexto, a Web Semântica é

caracterizada por representar o conteúdo e o conhecimento na forma de ontologias

(Filho, 2011). A introdução da semântica em Redes de Sensores Sem Fio (RSSF)

constitui-se como uma oportunidade de ir além ao se considerar sensores como fonte de

dados (Reddy e Morarjee, 2015). A semântica é importante, por exemplo, para questões

de interoperabilidade quando os interessados podem acessar e interpretar dados de

forma não ambígua ou pela possibilidade de raciocínio através da inferência de novas

informações e conhecimentos permitida pela sua representação formal (Barnaghi et al.,

2012).

Nesse contexto, as ontologias servem como um suporte para Web Semântica ao

capturar o conhecimento do domínio de interesse. Uma definição de ontologia

comumente utilizada na literatura é a encontrada em (Gruber, 1993), no qual uma

ontologia é definida como “uma especificação formal e explícita de uma

conceitualização compartilhada”. Segundo a W3C (w3.org), os conceitos das

ontologias devem prover descrições das classes, seus relacionamentos e suas

propriedades. Dessa forma, as considerações de (Guarino, 1998) sugerem o

desenvolvimento de diferentes tipos de ontologias de acordo com o nível de

generalidade, a saber:

Ontologias de alto nível: descrevem conceitos gerais como o espaço, tempo,

objetos, ações, eventos, etc., que são independentes de um problema

particular ou domínio. Pela natureza genérica, estes conceitos podem ser

reutilizados para compor novas ontologias;

Ontologias de domínio e de tarefas: descrevem, respectivamente, o

vocabulário relacionado a um domínio específico (como medicina ou

automóveis) ou atividades/tarefas (como diagnósticos ou vendas) através da

especialização dos termos da ontologia de alto nível;

Ontologias de aplicação: descrevem conceitos dependentes de um domínio

ou tarefa particular que são frequentemente especializações de ontologias de

15

domínio e/ou de tarefa. Estes conceitos correspondem, de maneira geral, a

papéis desempenhados por entidades do domínio quando realizam

determinada atividade;

Outro tipo de ontologia reportado na literatura é apresentado por (Scherp et al.,

2009). Trata-se de uma abordagem baseada em core ontologies. Esta abordagem é

caracterizada pelo alto grau de consenso e de precisão formal, sendo alcançada através

de bases das ontologias de fundamentação. Neste caso, este tipo de ontologia permite

reutilizar conhecimentos estruturados e definidos, possibilitando integrar-se ao

conhecimento do domínio existente. Dessa forma, o conhecimento estruturado de core

ontologies é claramente separado do conhecimento de um domínio específico.

A popularidade das ontologias existe devido a possibilidade do

compartilhamento e entendimento comum de algum domínio de conhecimento que

possa ser comunicado entre pessoas, sistemas e máquinas. Neste sentido, ontologias têm

sido desenvolvidas para facilitar o compartilhamento e reutilização de informações.

Utilizado como guia para comunicar e compartilhar os conceitos, a ontologia serve de

plano comum para diversas áreas e seus domínios. Com relação aos propósitos, as

ontologias podem ser classificadas como reference ontologies (ontologias de referência)

e operational ontologies (ontologias operacionais) (Falbo et al., 2013) e (Guizzardi,

2007). As ontologias de referência, como um modelo conceitual, é construída com o

objetivo de fazer a melhor descrição possível de um domínio na realidade,

representando um modelo consensual dentro da comunidade. Por outro lado, as

ontologias operacionais são desenhadas com objetivo de garantir as propriedades

computacionais desejáveis, uma vez que os usuários já concordaram com uma

conceptualização comum.

Os dados coletados por uma rede de sensores necessitam de enriquecimento

semântico que são extraídos dos domínios ao qual estão inseridos para que os

interessados possam interpretar os dados de forma não ambígua. Para tal fim, o uso de

ontologias do domínio de rede de sensores se mostra como um caminho para descrever

os conceitos que são aplicados a estes sistemas. Alguns esforços da comunidade para

criar padrões na captura do conhecimento em redes de sensores e propiciar um

tratamento semântico têm sido descritos na ontologia Semantic Sensor Network

Ontology (SSNO) desenvolvida pelo W3C.

16

Com o objetivo de iniciar o processo formal de desenvolver ontologias que

definem as capacidades de sensores bem como as redes de sensores, um grupo do W3C

iniciou, em 2009, os trabalhos para descrever a noção de sensores em termos de suas

capacidades, processos de medição, observações, implantações, suas características e

relacionamento entre os conceitos (Compton et al., 2012). Este esforço aumenta a

interoperabilidade e precisão devido à ausência de entrada de dados manual. Além

disso, esses erros podem ser evitados permitindo que o fabricante do hardware sensor

divulgue descrições dos sensores disponíveis usando ontologias para que

desenvolvedores de soluções da IoT/RSSF possam recuperá-los e incorporá-los (por

exemplo, mapeamento) em seu próprio sistema de software (Perera et al., 2013). Um

exemplo dos ganhos do uso desta ontologia é a busca semântica, como por exemplo,

realizar queries baseadas nas características do sensor, como os fenômenos que ele

observa (temperatura, umidade, velocidade, posição, etc).

A ontologia SSNO está organizada em 10 módulos, consistindo de 41 conceitos

e 39 propriedades de objetos. Na Figura 4 é possível observar um fragmento da

ontologia expressa em 4 módulos (Data, Stimulus-Sensor-Observation Pattern, Device

e MeasuringCapability). O centro desta ontologia é o Stimulus-Sensor-Observation

Pattern (SSO Pattern). Este modelo descreve os relacionamentos entre sensores,

estímulos e observações, fazendo um link entre os sensores, o que eles medem e os

resultados das observações. O SSO Pattern pode ser englobado dentro de 3 principais

perspectivas:

Figura 4 – Ontologia SSN. Adaptado de (Compton et al., 2012)

17

Perspectiva do Sensor: tem foco no que ele mede, como ele mede (processo

utilizado para medir um fenômeno), e o valor que é medido;

Perspectiva da Observação: com foco em dados de observação e metadados

correspondentes;

Perspectiva das Características e das Propriedades: tem o foco na medida de

uma propriedade particular ou quais observações têm sido feitas sobre uma

propriedade;

Alguns dos conceitos e propriedades dos objetos presentes na Figura 4 podem

ser descritos de acordo com as definições do grupo de trabalho (W3C Semantic Sensor

Network Incubator, 2011), a saber:

Sensor: um sensor pode fazer/implementar sensoriamento, isto é, um sensor

é qualquer entidade que pode seguir um método de sensoriamento e,

portanto, observar alguma propriedade (Property) de uma característica de

interesse (FeatureOfInterest). Sensores podem ser dispositivos físicos,

métodos computacionais, um setup de laboratório com uma pessoa seguindo

um método ou qualquer coisa que pode seguir um método de sensoriamento

(Sensing) para observar uma propriedade;

Property: uma qualidade observável de um evento ou objeto. Não se trata de

uma qualidade de uma entidade abstrata, mas um aspecto de uma entidade

que é intrínseca e não pode existir sem ela, sendo observável por um sensor;

MeasurementCapability: coleta as propriedades de medida

(MeasurementProperty) como a exatidão (accuracy), intervalo de medição

(MeasurementRange), precisão (precision), etc., e as condições ambientais

em que estas propriedades mantêm, representando uma especificação de

capacidades de um sensor nestas condições. As condições especificadas aqui

são aqueles que afetam as propriedades de medida, enquanto, por exemplo,

MeasurementRange representa as condições operacionais padrão do sensor,

incluindo as condições que não afetam as observações;

MeasurementProperty: uma característica observável e identificável das

observações do sensor ou a habilidade de fazer observações;

18

ObservationValue: o valor do resultado de uma observação. Uma observação

tem um resultado que é a saída (output) de algum sensor. O resultado é um

objeto de informação que codifica algum valor para uma propriedade;

A ontologia SSN tem sido amplamente utilizada em projetos como CityPulse

(Kolozali et al., 2014) e soluções para IoT, como OpenIoT (Serrano et al., 2015),

servindo de uma referência comum para anotações e modelos utilizados com o intuito

de representar equipamentos, entidades e informações de sensoriamento.

2.4 – Qualidade da Informação (QoI)

Sensores e dispositivos atuadores estão cada vez mais capazes e acessíveis e tem

dado origem ao rápido desenvolvimento de aplicações, os quais tem mudado a maneira

como as pessoas vivem, trabalham e interagem com o mundo físico em geral (Miorandi

et al., 2012).

Apesar dos grandes benefícios, estes sistemas representam novos desafios de

pesquisas, como o balanceamento entre a Qualidade da Informação (QoI) fornecida

pelos sensores e o consumo dos recursos dos sistemas. Conforme explicado em (Su,

2013), os sensores individuais não são confiáveis devido a várias razões, incluindo

observações incompletas, ruídos no ambiente e/ou em placas de circuito, baixa

qualidade dos sensores, falta de calibração do sensor e, até mesmo, a ação de um

usuário mal intencionado. Com isso, informações imprecisas ou mesmo falsas podem

induzir pessoas a erros no processo de tomada de decisão e, eventualmente, causar

prejuízos e perdas de valores inestimáveis. O tratamento de QoI é, portanto, uma

questão premente nas soluções baseadas em redes de sensores sem fio.

Para (Sachidananda et al., 2010), qualidade refere-se ao grau ou nota de

excelência e QoI como a qualidade experimentada/percebida pelo usuário considerando

informações recebidas que podem satisfazer plenamente seus requisitos enquanto poupa

recursos valiosos, como energia e largura de banda. As definições encontradas em

(Meyer, Sperner e Magerkurth, 2011) descrevem QoI como “qualquer metadado que

caracteriza a informação de contexto de tal maneira que ela possa ser usada para inferir

a confiabilidade da informação recebida”. Ambas as definições convergem, de certa

forma, para a valorização da informação enquanto atributo (p. ex., quão preciso ou

19

pontual é um dado), permitindo ou facilitando usuários/sistemas avaliarem o grau de

satisfação para com a informação de acordo com seus próprios requisitos.

QoI tem sido estudada tradicionalmente no contexto dos processos e sistemas de

gerenciamento de dados de corporações para suportar processos de negócios e tomadas

de decisão. Neste sentido, o trabalho de (Meyer, Sperner e Magerkurth, 2011) apresenta

uma abordagem que reflete QoI em recursos físicos, mapeando-os para as camadas mais

altas dos sistemas de informação das corporações, envolvendo Internet of Things (IoT) e

Business Process Model (BPM). Os autores argumentam que QoI é fundamental para

aplicações do mundo real, sendo parte das descrições dos recursos do mundo real. A

proposta dos autores é construir as relações entre IoT e BPM, relacionando alguns

conceitos dos recursos, como QoI. A qualidade deste recurso pode ser descrito com a

ajuda de metadados levando em consideração dimensões espaciais, temporais, de

confiabilidade e rastreabilidade.

Em alguns casos, as redes de sensores são avaliadas dentro de um contexto de

aplicações que necessitam de informações a respeito da exatidão, pontualidade,

relevância, completude, procedência, dentre outros. Em certo sentido, seu valor depende

das qualidades de informações que fornecem. Os pesquisadores têm usado vários

atributos para representar QoI nestes sistemas, entretanto, a escolha destes atributos é

determinada de acordo com sua relevância para aplicação que usa RSSF como fonte de

dados. Por exemplo, o trabalho em (Sachidananda et al., 2010) destaca a importância de

alguns atributos relativos a QoI para planejar uma aplicação e usá-los numa perspectiva

operacional. Dentre estes atributos estão:

Accuracy (Exatidão): é o grau de correção que fornece o valor que é a

imitação próxima ao valor real. A exatidão está relacionada às incertezas

sistemáticas de medição e pode ser avaliada através da calibração do

instrumento utilizado para observar um fenômeno, como por exemplo, a

temperatura. A calibração nada mais é do que o processo de descobrir,

experimentalmente, o erro sistemático (desvio constante);

Precision (Precisão): é o grau de reprodutibilidade dos valores medidos que

podem ou não estar próximos ao valor do mundo real. Neste caso, significa

que os valores indicados são muito próximos quando se mede o mesmo

20

fenômeno sob as mesmas condições. Assim, quanto maior o desvio padrão,

menor a precisão;

Timeliness (Pontualidade): é um indicador para o tempo necessário desde

quando a primeira amostra do dado é gerada na rede até chegar ao nó sink

para tomada de decisão;

Outro atributo destacado por (Sachidananda et al., 2010) é reusability

(reusabilidade). Este atributo é especialmente importante numa arquitetura na qual os

registros históricos dos dados observados são armazenados num banco de dados. Neste

caso, ele representa as características da informação que podem ser usadas durante o

ciclo de vida ou enquanto ela é relevante para futuras utilizações no contexto da RSSF.

Os atributos de QoI representam uma coleção de características de informação

que permitem as aplicações decidirem se a informação é útil para seus propósitos,

representados pelos metadados descritos anteriormente. O trabalho de (Bisdikian et al.,

2009) procura ir além destas características, considerando que os itens de informação

podem ser melhorados de acordo com o contexto operacional das aplicações. Isto é feito

através da adição de relevância no domínio de QoI. Os autores argumentam que este

atributo está implícito durante o desenvolvimento de aplicações baseadas em sensores e

que, em casos de desenvolvimentos dinâmicos, a relevância é um facilitador para

estabelecer um contexto operacional compatível com base nas propriedades espaciais e

temporais da informação procurada. Além disso, a relevância da informação

desempenha um papel importante para ambientes altamente dinâmicos, e esse papel

continua sendo importante durante toda a operação das aplicações baseadas em

sensores.

Outro aspecto importante é processo de avaliação de QoI. Este processo

determina o quão adequado é a informação para um uso particular, avaliando os dados

contra um número de dimensões de qualidades, p. ex., exatidão, disponibilidade,

pontualidade e relevância. A exatidão avalia o quão próximo está o valor observado se

comparado com o mundo real. A disponibilidade avalia o tempo entre a criação da

observação e a publicação no servidor. A pontualidade indica o frescor, isto é, o quão

atual é o dado observado. A relevância avalia a extensão na qual a observação descreve

o fenômeno no qual estamos interessados (Baillie, Edwards e Pignotti, 2012). Conceitos

similares das propriedades utilizadas na avaliação de QoI são apresentadas em

21

(Bisdikian, Kaplan e Srivastava, 2013), entretanto, utilizando as primitivas what, where,

when, why, who e how. A primitiva what representa tudo o que está relacionado ao

conteúdo da informação, tais como os valores das medidas, suas unidades e sua

precisão. As primitivas where e when representam o contexto físico, isto é, a localização

e o tempo que estão relacionados aos conteúdos das informações. As primitivas who e

how estão relacionadas com a procedência da informação, indicando a fonte e o

processo utilizado para realizar as observações. Finalmente, a primitiva why representa

para qual missão aquela informação é necessária dentro de um contexto específico.

Portanto, as primitivas what/where/when estão preocupadas com aspectos

relacionadas ao conteúdo, enquanto que as primitivas who/how estão relacionadas a

procedência. Já a primitiva why surge como a utilidade de um produto de informação

quando usado num contexto específico. Esta primitiva tem sido relacionada com o custo

de adquirir um produto de informação para reduzir incertezas na ausência de

conhecimentos durante o processo de tomada de decisão.

Alguns autores como (Fawzy, Mokhtar e Hegazy, 2013), (Kriegel, Kröger e

Zimek, 2010) e (Abid, Kachouri e Mahfoudhi, 2014) abordam a qualidade da

informação com base no conjunto de dados (univariados ou multivariados) produzidos

pelos nodos da RSSF. Isto é feito através de técnicas estatísticas, data mining,

inteligência artificial, aprendizado de máquina e teoria da informação. O termo

comumente utilizado no âmbito dessas técnicas é outlier. Este termo tem suas origens

na estatística e também é conhecido como anomalia. Um outlier é uma observação (ou

um subconjunto de observações) que parece ser inconsistente com o resto do conjunto

de dados. Nas RSSF, outliers podem ser definidos como as medidas que se desviam

significantemente do padrão normal dos dados sensoreados (Kriegel, Kröger e Zimek,

2010). Esta definição se baseia no fato de que, numa RSSF, os nodos sensores tem a

atribuição de monitorar o mundo físico que representa um padrão de comportamento

normal nos dados sensoriados. Em situações práticas é comum que um ou

possivelmente mais dados difiram do seu conjunto. Para tanto, técnicas estatísticas são

utilizadas para decidir se os valores devem ou não ser rejeitados. Dentre os testes mais

comuns para detecção de outliers destacam-se o teste de Dixon, Chauvenet e Grubbs

(Oliveira, 2008) e (Lucato, Couto e Luz, 2007), além do teste da Amplitude Interquartil

(ou teste dos Quartis) (NISHA et al., 2014). Os valores rejeitados normalmente são

associados a valores dispersos que são caracterizados como erros aleatórios, devendo

22

ser minimizado ao máximo para que valores como a média não fique distorcida

(Oliveira, 2008). Os valores dispersos necessitam ser investigados para encontrar causas

possíveis e identificar os problemas da medida. A seguir são apresentadas as técnicas

estatísticas dos Quartis definidas em (NISHA et al., 2014) e o Teste de Grubbs definido

em (Levine, 2008), (Neto, 2010) e (Oliveira, 2008) para detectar outliers e valores

dispersos:

Amplitude interquartil: os quartis dividem um conjunto de dados em partes

iguais (Q1, Q2 e Q3). O primeiro quartil (Q1) divide os 25% dos valores

mais baixos dos 75% que são maiores do que eles na amostra. O segundo

quartil (Q2) representa a mediana, ou seja, 50% dos valores são menores que

a mediana e 50% dos valores são maiores. O terceiro quartil (Q3) divide a

parcela correspondente dos 75% dos valores mais baixos dos 25% dos

valores que são maiores do que eles. Dessa forma, a Amplitude Interquartil

(Ai) pode ser definida como Ai = a3(Q3) – a1(Q1), onde a3 representa o valor

da amostra referente ao terceiro quartil (Q3) e a1 representa o valor da

amostra referente ao primeiro quartil (Q1). Outliers podem ser detectados

numa amostra utilizando Amplitudes Superiores (Asup) ou Amplitudes

Inferiores (Ainf), que são determinadas utilizando uma barreira b. A barreira

indica o grau de dispersão que se deseja aplicar ao conjunto de dados para se

detectar uma valor considerado como outlier. Dessa forma, a Amplitude

Inferior é determinada por Ainf = a1 – (b x Ai) e a Amplitude Superior por

Asup = a3 + (b x Ai). Assim, uma amostra testada (at) é considerada um

outlier quando at < Ainf ou at > Asup.

Teste de Grubbs: outro teste de detecção de outliers recomendado pelo

International Organization for Standardization (ISO) é o teste de Grubbs.

Este teste compara a distância, medida em desvios-padrão, do valor suspeito

em relação à média do conjunto de valores (o valor suspeito é incluído no

cálculo da média e do desvio-padrão). Se a distância for maior do que o

limite crítico tabelado, o valor suspeito é considerado um outlier. Os valores

críticos se referem à tabela de Grubbs, que leva em consideração o grau de

significância da amostra testada com relação ao total de amostras. A tabela

(Anexo I) contempla os índices de confiança e indicam os valores críticos

23

(Gc) relativos a 90%, 95%, 97,5%, 99% e 99,95%. O teste de Grubbs é dado

por:

퐺 = |푎 − 푎|

푠

A variável at representa a amostra testada, a representa a média e s o desvio

padrão. Por sua vez, o desvio padrão é obtido por:

∑ (푎푖 − 푎)푝

Neste caso, p representa o número de elementos da amostra. Dessa forma, o

valor G é calculado e comparado ao índice de significância α presente na

tabela. Sendo G o valor de Grubbs obtido e Gc o índice crítico, a amostra

testada at é um outlier se G > Gc.

2.4.1 - Detecção de Outliers

Atualmente, muitos trabalhos na área de redes de sensores sem fio têm seu foco

direcionado na melhoria de detecção de eventos e melhoria da qualidade dos dados

providos por estas redes. A discussão a seguir apresenta uma compilação de conceitos

relacionados com a detecção de outliers (anomalias/eventos) descritos em (Kriegel,

Kröger e Zimek, 2010), (Abid, Kachouri e Mahfoudhi, 2014) e (McDonald et al., 2013).

As redes de sensores não são apenas utilizadas para fornecer dados refinados

sobre o mundo real, mas também para detectar eventos críticos. Os dados medidos e

coletados pelas RSSF podem ser não confiáveis devido aos ruídos, erros, valores

duplicados ou inconsistências. Para (Subramaniam et al., 2006) as causas prováveis

destas anomalias são atribuídas a questões como baixa qualidade do sensor, restrições

de memória, CPU, largura de banda e, principalmente, por questões de esgotamento da

matriz energética do nodo. Por outro lado, eventos como incêndios florestais,

terremotos, derramamentos químicos, etc., ocorrem no mundo real e não podem ser

detectados com precisão utilizando dados imprecisos e incorretos. Portanto, é

importante garantir a confiabilidade e precisão dos dados antes do processo de tomada

de decisão.

24

Figura 5 – Origens de outliers em Redes de Sensores Sem Fio e suas identidades. Fonte: (Abid, Kachouri e Mahfoudhi, 2014)

A Figura 5 ilustra os desdobramentos dos conceitos de outliers em redes de

sensores. Neste caso, outliers podem ter origens a partir de falhas em nodos sensores, na

ocorrência de eventos no ambiente/entidade monitorada e em sistemas de detecção de

intrusão (IDS). É importante ressaltar que existem diferenças conceituais entre detecção

de eventos e detecção de outliers, a saber:

As técnicas de detecção de outliers não tem conhecimento prévio da

condição de disparo ou relação semântica de qualquer evento. Já as técnicas

de detecções de eventos mantêm uma condição de disparo ou a semântica de

determinado evento;

A detecção de outliers tem por meta identificar leituras anômalas

comparando as medidas obtidas pelos sensores umas com as outras,

enquanto detecção de eventos tem como objetivo especificar certo evento

comparando a medidas obtidas pelos sensores com as condições de disparo

ou padrão pré-definido;

O principal desafio enfrentado pelas técnicas de detecção de outliers para RSSF

é satisfazer os requisitos de precisão na mineração dos dados mantendo o consumo de

recursos dos nodos da rede ao mínimo. A questão principal é como processar tantos

dados quanto possível de forma descentralizada mantendo baixa sobrecarga de

comunicação, memória e processamento.

As técnicas de detecção de outliers não apenas identificam dados que não estão

em conformidade com o padrão normal como também provêm métodos específicos para

25

computar o grau em que o dado medido se desvia do padrão normal. Em RSSF, outliers

são medidos em duas escalas:

Escalar: é uma escala de classificação zero-ou-um que classifica o dado

medido dentro de uma classe normal ou numa classe outlier;

Outlier score: esta técnica atribui um score para os dados medidos

dependendo do grau em que a medida é considerada como um outlier,

fornecendo um ranking de outliers. Dessa forma, um analista pode escolher

analisar n outliers com o maior score ou utilizar um limite de corte para

selecionar outliers. Uma vez que este limite de corte é usualmente

especificado pelo usuário, a solução ótima é realizar testes de aprendizagem

no streams de dados obtidos;

A taxonomia descrita por (Kriegel, Kröger e Zimek, 2010) apresenta as técnicas

para detecção de outliers. Esta taxonomia é baseada nas disciplinas das quais as ideias

são adotadas e aborda as características chaves e análise de desempenho de cada técnica

de detecção de outlier.

Figura 6 – Taxonomia de técnicas de detecção de outlier para RSSF. Fonte: (Kriegel, Kröger e Zimek, 2010)

Na Figura 6 é possível observar as diferentes abordagens utilizadas para

detecção de outliers. Para os propósitos deste trabalho, apenas um subconjunto de

técnicas são apresentadas.

A abordagem baseada em estatísticas (statistical-based) são técnicas que

assumem ou estimam um modelo estatístico (distribuição probabilística) que capturam a

26

distribuição dos dados e avaliam suas instâncias para saber o quão ele cabe no modelo.

A técnica de modelagem pode trabalhar no modo não supervisionado, no qual um

modelo estatístico pode determinar se ele se adapta à maioria das observações mesmo

que uma pequena quantidade de outliers esteja entre os dados. Por sua vez, os modelos

estatísticos podem ser baseados em técnicas, como por exemplo, as técnicas não

paramétricas. Esta abordagem tipicamente define a distância medida entre uma nova

instância de teste e o modelo estatístico utilizado. Para alcançar seus objetivos, esta

abordagem utiliza algum tipo de threshold (limite) do qual o valor testado se distancia.

As abordagens baseadas em estatísticas são matematicamente justificáveis e

podem detectar outliers eficientemente se um modelo probabilístico correto for

utilizado. É importante notar que em muitos cenários da vida real não há o

conhecimento prévio da distribuição do stream de dados. Portanto, abordagens

paramétricas podem não ser úteis se a distribuição de dados providos pelo cenário não

seguir uma distribuição programada. Neste caso, técnicas não paramétricas são

atraentes pelo fato de que elas não fazem qualquer suposição sobre as características da

distribuição.

De acordo com os trabalhos descritos anteriormente é possível perceber que o

processo de avaliação da qualidade de informação é de grande importância em RSSF.

Esse processo tem um papel chave para questões como tomada de decisão ou para

indicar os estados nas quais uma entidade pode estar. Neste caso, outras plataformas

podem se beneficiar deste processo no momento de inferir ou informar determinadas

situações que ocorre no ambiente monitorado.

2.5 – Situação e Contexto

A questão central em sistemas reativos e proativos é a habilidade de relacionar

os eventos que ocorrem no ambiente e um particular estado de interesse sobre o qual um

sistema tem a capacidade de agir ou reagir. Neste cenário, surge o conceito de

“sensibilidade de contexto” (Dey, 2001), que permite explorar a construção de

aplicações sensíveis ao contexto. Tais aplicações são aquelas que usam e manipulam

informações contextuais para detectar situações de alto nível e que são usadas para

adaptar o comportamento da aplicação (Dockhorn Costa et al., 2007).

27

As definições de situação e contexto estão proximamente ligadas, entretanto,

elas estão relacionadas a conceitos diferentes. De acordo com (Dey, 2001), contexto é

qualquer informação que pode ser usada para caracterizar as situações de entidades.

Uma entidade é uma pessoa, lugar ou objeto que é considerado relevante para a

interação entre um usuário e uma aplicação, incluindo os próprios usuários e aplicações.

Exemplos de contexto relacionados a uma pessoa pode ser sua localização, estado

mental ou atividade. Relacionado ao conceito de contexto, tem-se o conceito de

situação, que representa um estado de interesse de uma aplicação sensível ao contexto

(Dockhorn Costa et al., 2007). Por exemplo, uma situação de febre pode ser definida

como a situação na qual uma pessoa (entidade) está com uma temperatura superior a

37°C.

Conforme as aplicações se tornam mais complexas e interconectadas há uma

necessidade definitiva de modelagem de contexto, tornando-se apropriadas para (i)

suportar o entendimento comum e a comunicação entre os vários interessados

envolvidos no desenvolvimento da aplicação, e para (ii) representar o contexto de forma

não ambígua (Costa, Almeida e Pires, 2006). Neste sentido, as situações devem estender

e estar em conformidade com os modelos contextuais. Por exemplo, uma situação pode

indicar que “John está a 50 metros de Alice”. No modelo de contexto, este exemplo

apenas define que uma pessoa pode estar próxima à outra. Dessa forma, a situação

“John está a 50 metros de Alice” caracteriza uma situação com propriedades similares,

indicando a proximidade entre ambos. Neste caso, p. ex., é possível definir um tipo de

situação, na qual a distância entre John e Alice é menor do que 50 metros.

As RSSF podem ser consideradas como fontes captadoras de contexto se elas

puderem usar este contexto para fornecer informação relevante para o usuário, para

outros sensores ou para ambos (Son et al., 2009). Isso possibilita obter dados de

propriedades na qual seja possível caracterizar tipos de situações. Dessa forma, com

base nos dados recebidos pela RSSF, é possível adaptar pró-ativamente ou reativamente

o comportamento das aplicações de acordo com a situação.

O conceito de percepções de situações pode ser explorado por sistemas proativos

ou reativos, tais como aplicações sensíveis ao contexto (context-aware). A adaptação do

comportamento das aplicações e serviços é possível com o uso de sistemas baseados em

regras, que se mostra como uma das abordagens para modelar situações (Friedman-Hill,

28

2003). Por exemplo, num cenário no qual há um aumento de concentração de CO2 e de

pessoas numa determinada sala, é possível que a aplicação reaja, por exemplo, ativando

um sistema de ventilação sem a necessidade de intervenção do usuário. Esta é a questão

central de sistemas reativos ou proativos, que tem a habilidade de construir uma ponte

entre os eventos que ocorrem no ambiente e um estado particular de interesse. Estes

sistemas utilizam linguagens que favorecem a construção de novas aplicações

abstraindo detalhes específicos de plataforma de hardware, p.ex., como soar um alarme

ou ligar uma bomba hidráulica. A seção seguinte descreve com mais detalhes os

conceitos e funcionamento de sistemas baseados em regras.

2.5.1 – Sistemas Baseados em Regras

Diferentemente dos sistemas que se apoiam na programação imperativa, em que

a resolução de um problema é feita com soluções algorítmicas, os sistemas baseados em

regras são sistemas computacionais que empregam o paradigma declarativo de

programação para a resolução de problemas (Hayes-Roth, 1985). Neste paradigma, o

conhecimento relativo ao domínio do problema é representado através de regras

(instruções) que são descritas na forma condição → ação, as quais são usadas para

derivar conclusões a partir de premissas (Friedman-Hill, 2003). A solução do problema

consiste em descrever o que deve ser feito, omitindo-se grande parte do como fazer,

cabendo ao sistema decidir qual a melhor escolha para uma solicitação específica.

Controle e monitoramento, diagnóstico, previsão, classificação, reconhecimento de

padrões e sensibilidade ao contexto, são exemplos de aplicações que podem se

beneficiar de uma abordagem declarativa.

Um sistema baseado em regras que são estruturados como if-then. A primeira

parte da estrutura é chamada de Left Hand Side (LHS) e contém as premissas

(condições, predicados) a serem satisfeitas, e a segunda parte (RHS – Right Hand Side)

contém as ações a serem realizadas, ou seja, as conclusões da regra. Por exemplo, na

ocorrência de uma condição específica descrita no LHS, o RHS pode conter chamadas

para serviços do sistema, tais como o envio de um e-mail ou um SMS. O domínio de

uma regra é definido como o conjunto de todas as informações no qual a regra pode

atuar. Os fatos representam as informações sobre o mundo.

29

Num sistema baseado em regras existe uma separação explícita das regras de

negócio, descritas numa linguagem declarativa, do restante da aplicação. É

responsabilidade de outro programa, a máquina de inferência ou de regras (rule engine),

determinar quando e quais regras de negócio serão executadas. Em geral, a arquitetura

de um sistema baseado em regras é composta dos seguintes subsistemas (Figura 7): uma

máquina de inferência (inference engine ou rule engine), uma base de regras (rule base)

e uma memória de trabalho (working memory). A máquina de inferência, por sua vez, é

subdividida em três componentes: pattern matcher, agenda e execution engine

(Friedman-Hill, 2003).

Figura 7 – Arquitetura de Sistemas baseados em regras. Fonte (Friedman-Hill, 2003)

A máquina de inferência, também chamada de interpretador de regras, controla

todo processo de aplicação das regras aos fatos contidos na working memory (local

destinado a manter os fatos que podem ser modificados ou retirados) com intuito de

obter os resultados do sistema e, geralmente, funciona em ciclos discretos. A cada ciclo

de processamento, as regras são comparadas pelo pattern matcher com os fatos

existentes na memória de trabalho, gerando um conjunto de regras a serem ativadas.

Este conjunto é chamado de conjunto conflito (conflict set), que é ordenado para formar

uma agenda usando um processo de resolução de conflitos (conflict resolution). A base

de regras (rule base) contém as regras do sistema, normalmente utilizando alguma

estrutura de dados eficiente, por exemplo, rete network (Forgy, 1982). Existem

atualmente diversas implementações de máquina de regras. Duas importantes

implementações são as providas pelos ambientes JESS (Friedman-Hill, 2003) e Drools

(Bali, 2013).

30

Alguns trabalhos advogam o uso de sistemas baseados em regras em redes de

sensores sem fio (Chu et al., 2007) (Terfloth, Wittenburg e Schiller, 2006). Uma das

justificativas é que o paradigma declarativo possibilita um maior nível de abstração que

o imperativo, tornando mais natural, simples e flexível para o desenvolvedor na

construção de regras. Além disso, toda alteração realizada na base de regras é aplicada

imediatamente a novos fatos. Entretanto, a máquina de regras pode demandar recursos

elevados de processamento e memória, o que pode comprometer o seu emprego em

ambientes com hardware limitado. Uma abordagem para este problema é hospedar o

sistema de regras em um ambiente com maior poder computacional. Essas teriam acesso

aos dados oriundos das redes de sensores como serviços escaláveis e com alta

disponibilidade, sem restrições quanto ao tamanho da base de regras e ao número de

dados coletados nas diversas redes envolvidas.

2.6 – Orientação a Serviço e RSSF

A computação orientada a serviços representa uma nova geração da plataforma

da computação distribuída. Ela abrange muitas coisas, como por exemplo, seu próprio

paradigma, linguagens-padrão, conceitos, tecnologias e frameworks. A computação

orientada a serviços se parece com um grande guarda-chuva: ela aprimora as

plataformas passadas da computação distribuída e adiciona novas camadas ao design e

um amplo conjunto de tecnologias de implementação preferidas (Kyusakov, 2012).

Para entender melhor a complexidade fundamental de uma típica plataforma de

computação orientada a serviços é preciso descrever alguns dos seus elementos. Dentre

estes elementos estão a Arquitetura Orientada a Serviços (SOA), Orientação a Serviços

e sua lógica associada e Serviços (Erl, 2009).

A Arquitetura Orientada a Serviços estabelece um modelo arquitetônico que visa

aprimorar a eficiência, a agilidade e a produtividade de uma empresa, posicionando os

serviços como os principais meios para que a solução lógica seja representada no

suporte à realização dos objetivos estratégicos associados à computação orientada a

serviços (Erl, 2009). SOA não é uma arquitetura concreta, não é um framework ou

ferramenta. SOA pode ser considerado um conceito ou paradigma que pode levar ao

projeto de uma arquitetura concreta de software, propondo um estilo arquitetural para a

construção de sistemas de informação através de serviços e suas combinações

(Nakamura, 2012). Como resultado, a arquitetura de tecnologia baseado em SOA forma

31

um ambiente adequado para a lógica projetada, alinhando-se com os princípios de

orientação a serviços. Neste sentido, SOA se mostra como uma abordagem adequada na

interconexão de sistemas e dispositivos heterogêneos, uma vez que esta arquitetura

normalmente se baseia em protocolos de redes abertos e codificações de dados padrão,

proporcionando a independência de plataforma (Kyusakov, 2012).

A orientação a serviços é um paradigma de design que abrange um conjunto

específico de princípios de design, resultando numa lógica orientada a serviços. A

unidade fundamental desta lógica é o serviço. Os serviços existem como programas de

software independentes. Cada serviço é uma unidade funcional e possui contexto

funcional distinto, cujas capacidades estão relacionadas a este contexto. Comumente,

estas capacidades estão expressas por um contrato de serviços público, semelhante a

uma API tradicional. A característica agnóstica de um serviço o torna capaz de

participar de múltiplas composições de serviços. Dessa forma, um conjunto de serviços

disponíveis pode ser combinado em composição de serviços num processo chamado

orquestração de serviços. A composição de serviços consiste num agregado combinado

de serviços e pode ser comparada a um aplicativo tradicional, uma vez que seu escopo

se associa a automação de um processo de negócio de uma corporação. O benefício

potencial da composição de serviço é que ele permite a rápida criação de novos

serviços, como a combinação de serviços básicos existentes, em vez de ser desenvolvida

a partir do zero (Silva, da, Pires e Sinderen, van, 2012).

No mercado atual, a tecnologia mais associada à realização de SOA é o Web

Service (WS). Segundo (Priyantha et al., 2008), Web Services são chamadas de métodos

web que permitem dados de objetos estruturados serem trocados com recursos remotos

e que sua descrição habilita maneiras de programação, permitindo assim expressar a

funcionalidade do dispositivo. WS são definidos por vários padrões da indústria

suportados por muitas comunidades de fornecedores. Uma das tecnologias para

implementar WS se baseia em Web Services Description Language (WSDL), Simple

Object Access Protocol (SOAP) e Universal Description, Discovery, and Integration

(UDDI). WSDL é um formato XML para descrever serviços de rede como um conjunto

de endpoints que operam em mensagens que contenham informações sobre documentos

ou informações orientadas para o procedimento e pode ser usado em conjunto com

SOAP, um protocolo para troca de informações estruturadas que baseia seu formato de

mensagem em XML e utiliza outros protocolos da camada de aplicação, como HTTP,

32

para transmissão de mensagens (Christensen et al., 2009). O UDDI é o serviço de

diretório pelo qual é possível publicar e descobrir por serviços web.

Figura 8 – Modelo básico de uma Arquitetura Orientada a Serviços. Fonte: (Nakamura, 2012)

A Figura 8 ilustra o modelo de SOA implementado para Web Services e seus

componentes. Nesta figura é possível destacar três entidades:

a. Provedor: entidade que oferece os serviços e os anunciam publicando a

descrição do serviço;

b. Cliente: entidade que procura pelo serviço para cumprir determinada tarefa ou

consumir dados do serviço;

c. Service broker: entidade corretora de serviços que aceita consultas a partir do

cliente, busca as descrições de serviços fornecidos pelo prestador e devolve

documentos Web Services Description Language (WSDL) com as melhores

combinações da busca;

Devido à complexidade de várias camadas da arquitetura SOAP e WSDL, uma

alternativa a esses protocolos de comunicação é o estilo arquitetural RESTful,

desenvolvida com base no funcionamento da Web e que segue os princípios do

Representational State Transfer (REST) (Dinh, 2012). Ao aplicar os princípios REST

no desenvolvimento de uma aplicação Web é possível explorar o uso do protocolo

HTTP e do Universal Resource Identifier (URI) de forma natural, tornando as

aplicações mais simples, leves e de alto desempenho.

33

A arquitetura REST possui foco na noção de recursos. Um recurso é qualquer

item de informação acessível através de um URI. Todo recurso possui uma ou mais

representações formadas pelos dados e metadados que o descreve. Dessa forma, os

recursos podem ser entendidos como métodos e podem ser acessados por URIs, onde

são manipulados através de transferências de representações entre cliente e servidor

utilizando a interface do protocolo HTTP, composta pelos elementos POST, GET, PUT

e DELETE (Kyusakov, 2012).

No cenário atual, cada vez mais dispositivos como smartphones e sensores estão

integrados e se comunicando através da Internet. Este cenário leva a pensar numa rede

global de dispositivos com características e facilidades de acesso na qual os sensores

podem ser descobertos e selecionados de acordo com suas funcionalidades. Dentro desta

ideia, os recursos providos pelos sensores (sensing) podem ser disponibilizados como

serviços.

Muitas soluções de IoT/RSSF adotam o design de orientação a serviços.

Exemplos disso são projetos como HYDRA (Zhang e Hansen, 2008), SENSEI (Presser

et al., 2008) e SOCRADES (Guinard et al., 2010). No futuro da Internet, dispositivos

do mundo real estarão aptos a ofertar suas funcionalidades via Web Services,

permitindo outros componentes interagirem com eles dinamicamente (Serrano et al.,

2013). A funcionalidade oferecida por estes dispositivos (p. ex., prover dados de

sensores on-line) está frequentemente relacionada aos serviços do mundo real (p. ex.,

sua localização por GPS) uma vez que eles são fornecidos por sistemas embarcados que

estão diretamente relacionados ao mundo físico. Dessa forma, dispositivos oferecendo

suas funcionalidades como Web Services podem ser usados por outras entidades tais

como aplicações corporativas ou mesmo por outros dispositivos.

De acordo com OnWorld (Kreegar et al., 2007), o mercado global de sistemas

de RSSF e serviços movimentou $ 8,2 bilhões em 2010, compreendendo 184 milhões de

dispositivos embarcados. Portanto, a oportunidade de negócios para serviços do mundo

real é promissora. Estes serviços levam vantagem na facilidade do consumo das

funcionalidades dos dispositivos e abre as portas para aplicações inovadoras que podem

gerar receitas e vantagens comerciais com a redução dos custos. Do ponto de vista

tecnológico, os principais desafios estão relacionados à integração dos serviços do

mundo real com as aplicações de negócios (Guinard et al., 2010).

34

De acordo com a ideia de integração de sistemas, o IoT/RSSF permite alto nível

de interoperabilidade e certo grau de flexibilidade. Isto permite o fluxo de comunicação

entre dispositivos heterogêneos, escondendo questões complexas de dispositivos fim-a-

fim dos serviços de comunicação (Mitton et al., 2012).

Com o intuito de implementar sensoriamento como serviços (SenaaS - Sensing

as a Service), sensores devem ser fornecidos como serviços através de camadas na qual

eles devem estar inscritos ou ainda através de outras plataformas elegíveis. Isto leva a

generalizações como virtual nodes, no qual seus proprietários ou administradores

disponibilizam ou utilizam seus recursos de acordo com suas necessidades. Dessa

forma, é possível argumentar que SenaaS está posicionado de modo a prover recursos

de suas capacidades utilizando-se de dados de suas redes de monitoramento. Tais

recursos podem ter diversas origens, por exemplo, através da exploração comercial de

Sensing Cloud Providers ou até mesmo de organizações públicas e privadas, como

empresas, administração pública, universidades, comunidades, etc., (Distefano, Merlino

e Puliafito, 2012).

2.7 - Considerações do Capítulo

Este capítulo apresentou os diversos conceitos relevantes para este trabalho com

foco principal nos temas Qualidade da Informação (QoI), Situações/Contexto,

Semântica/Ontologias de Sensores e Sensoriamento como Serviços. Neste trabalho

defende-se a ideia de que a proposta de uma arquitetura conceitual que combine estes

elementos pode ser aplicada a classes de aplicações na qual a utilização de IoT/RSSF se

apresenta como uma das alternativas possíveis.

35

3. Trabalhos Relacionados

O uso de aplicações de RSSF abrange uma variedade de domínios: transporte,

logística, medicina, meio ambiente, produção, etc. Por exemplo, em (TOSE et al., 2012)

é proposto uma RSSF para monitoramento dos equipamentos de uma Estação de

Tratamento de Esgoto (ETE). A ideia é monitorar a temperatura dos motores instalados

na ETE, possibilitando prever se determinando motor necessita de intervenção antes

mesmo da queima ou quebra devido a problemas mecânicos. Assim como o trabalho

previamente descrito, existem vários outros que aplicam RSSF para soluções em seus

respectivos domínios. Por exemplo, (Bruno et al., 2013) propõe um monitoramento

térmico em CPDs, (Khedo et al., 2010) apresenta uma proposta para monitorar a

qualidade do ar, (Zhou et al., 2015) propõe monitorar e controlar temperaturas em

ambientes indoor de larga escala. Muitos destes trabalhos exploram requisitos

considerados importantes no contexto de RSSF. Este capítulo tem como objetivo

apresentar trabalhos nos quais requisitos como QoI, situação/contexto e serviços são

temas de discussão além de abordar algumas arquiteturas propostas na literatura.

3.1 - Qualidade da Informação em Redes de Sensores

QoI é um dos temas de interesse da pesquisa desenvolvida nesta dissertação. Um

exemplo de aplicação de RSSF que explora este tema pode ser visto em (Zhou et al.,

2015). A proposta é utilizar RSSF para monitoramento da distribuição da temperatura

em ambientes indoor de larga escala. O trabalho tem como objetivo identificar o padrão

de distribuição de temperatura e realocar o fluxo de ar de acordo com o padrão da

temperatura identificada. Uma das preocupações do trabalho está relacionada com a

avaliação de qualidade da informação através da verificação da confiabilidade. Os

autores utilizam um algoritmo baseado em técnicas de detecção de outliers, remetendo

ao estudo sobre QoI em Redes de Sensores Sem Fio.

O trabalho de (Bisdikian, Kaplan e Srivastava, 2013) destaca que as métricas de

QoI que representam a informação são amplamente discutidas na literatura. No domínio

de RSSF, (Hossain, Atrey e Saddik, El, 2008) define QoI como o grau de bens de

informação que refletem os aspectos do ambiente físico observado pelos sensores. O

modelo proposto neste trabalho seleciona os recursos de sensoriamento apropriados

baseados nas informações do ambiente externo bem como o contexto determinado por

36

uma unidade de fusão de dados. Os dispositivos sensores selecionados enviam streams

de observações para o centro de fusão de dados, que processa a entrada e determina a

informação de alto nível através da fusão e, por fim, calcula o QoI. Além de calcular o

QoI, o modelo proposto determina um parâmetro de contexto quando aplicável (p. ex.,

condições de iluminação), que usa esta informação para selecionar os sensores. O

objetivo desta abordagem é melhorar a QoI considerando o contexto para gerenciar de

maneira eficaz os sensores num sistema multi-sensor.

O trabalho descrito em (Guo et al., 2015) propõe um framework para avaliação

de QoI. O framework é construído numa infraestrutura de um procedimento de

agregação de informação tomando como base algumas premissas sobre a rede. Neste

trabalho, dois modelos são adotados para avaliar a exatidão dos dados medidos em

baixo nível e a informação de decisão em alto nível sem a necessidade de se estabelecer

um valor de referência. Com isso, o framework explora dois respectivos modelos de

acordo com a categoria específica da pontualidade da informação em diferentes

aplicações sensíveis a atrasos. Para quantificar a pontualidade, um timestamp é utilizado

como método prático para determinar o tempo de aquisições das informações. Para a

concepção do framework, os autores argumentam que, dentre vários atributos, exatidão

e pontualidade são os atributos mais relevantes e úteis em RSSF.

Dados produzidos por nodos sensores podem se desviar significativamente de

um subconjunto previamente lido. Estes dados podem ser caracterizados como outliers.

Alguns trabalhos na literatura abordam mecanismos utilizados para detecção e

tratamento destas condições. O trabalho aplicado em (Amidi, Hamm e Meratnia, 2013)

realiza um estudo numa área localizada sobre Grand Saint Bernard, um ambiente

montanhoso localizado entre a Suíça e a Itália com elevação de 2300 a 2500 metros. O

trabalho explora os outliers em ambos os sentidos, isto é, os dados podem conter erros

ou informações potencialmente úteis. A ideia central do trabalho é utilizar RSSF como

estações climáticas (previsão do tempo), uma vez que elas são frequentemente caras e

têm dificuldades para obter dados com ampla cobertura espacial. Na abordagem, os

outliers são identificados através das comparações entre os padrões da RSSF e dados

obtidos de previsões. Como exemplo, dados climáticos utilizados no estudo são

fornecidos pelo Serviço Nacional de Meteorologia da Suíça (MeteoSwiss Forecast -

MF). Estes dados são utilizados como informações contextuais para detectar outliers

temporais. Na pesquisa, as medidas obtidas pela RSSF foram comparadas com os dados

37

de previsão da estação MF em termos de padrões temporais. A correlação temporal

entre sucessivos valores de MF e RSSF são utilizados para expor os padrões temporais a

fim de identificar potenciais outliers temporais.

O trabalho discutido no início desta seção e que é apresentado em (Zhou et al.,

2015), também utiliza um mecanismo de detecção de outliers para otimizar o fluxo de

ar em ambientes indoor de grande escala. A ideia é que, no momento de coletar e

processar os dados, seja utilizado um mecanismo para identificar e reconstruir dados

anormais. Os dados coletados da rede são processados a fim de garantir a confiabilidade

do dado mensurado. O processamento destes dados detectam dados anormais, incluindo

dados duplicados, dados perdidos e outliers. Os dados perdidos e outliers são

reconstruídos com base na análise de correção entre os nodos sensores. Os outliers são

detectados verificando a continuidade dos dados, e uma maneira simples que utiliza um

algoritmo baseado em Z-score modificado.

3.2 - Gerenciamento de Situações e Sistemas de Regras

O trabalho proposto em (Pereira, Costa e Almeida, 2013) apresenta uma

plataforma denominada SCENE para o gerenciamento de situações. Esta plataforma

utiliza a engine JBoss Drools e melhora suas funcionalidades, aproveitando os

benefícios dos conceitos de situações no âmbito do desenvolvimento de aplicações

sensíveis ao contexto. O trabalho contribui com suporte adequado ao design-time (para

especificar os tipos de situações) e run-time (para detectar e manter informações sobre

situações) através de uma infraestrutura de gerenciamento de situações. A plataforma

proposta permite especificação de situações baseadas em regras (rule-based) e a gestão

do ciclo de vida por meio de um simples padrão de regras. Com isso, funcionalidades

temporais são tratadas neste trabalho, fornecendo suporte para eventos run-time. Dessa

forma, situações que ocorrem dinamicamente, ou seja, em tempos aleatórios, podem ser

detectadas com o uso da plataforma.

Em (Rodríguez et al., 2015) os autores propõem uma arquitetura baseada em

Multi-Agent Systems (MAS) desenhada para gerenciar dados de RSSF e que foi testada

em residência de idosos. Como base, o sistema utiliza a arquitetura multi-agente

denominada PANGEA (Platform for Automatic coNstruction of orGanization of

intElligents Agents), que fornece um framework de alto nível para gerenciamento e

fusão de informações de redes de sensores e sistemas de localização em tempo real.

38

Além disso, o sistema provê respostas autônomas de acordo com o status do ambiente.

A arquitetura geral inclui, dentre outras, um sistema de raciocínio baseado em regras

para melhor compreensão dos resultados. A infraestrutura implantada como exemplo é

composta por nodos ZigBee, sensores de presença, de abertura de porta, de janela, de

temperatura e de fumaça, localizados em áreas específicas de uma casa de 600 m2

(banheiro, quarto, cozinha e entradas). As informações obtidas por estes sensores

permitem o desenvolvimento de um “serviço de assistência virtual” que pode ser

personalizada para cada pessoa. Essa personalização é possível uma vez que o sistema

pode adaptar as regras para cada pessoa monitorada e os tipos de sensores associados a

ela. O sistema de gerenciamento de alarmes é baseado no módulo comportamental que

utiliza o sistema de regras baseadas em Drools. Este sistema inclui um planejador de

atividades diárias e uma biblioteca de regras que geram alertas quando algo atípico

acontece no ambiente. Por exemplo, se a pessoa permanece na cama por mais de oito

horas, um alerta é gerado. O agente que detecta atividades atípicas é baseado no uso de

regras pré-definidas que são executadas sobre os dados. Estas regras são escritas em

arquivos textos e podem ser modificadas ou inseridas sem a necessidade de

reconstrução do código. Para isso, a proposta utiliza o sistema de produção de regras

Drools, uma engine de regras baseada em Java, responsável por aplicar regras de

negócios em aplicações. Uma das vantagens desta engine é a abstração do código e o

processamento dos objetos num nível relativamente mais elevado, uma vez que utiliza

uma linguagem mais simples e próxima da natural, separando as regras de ações. Além

disso, esta engine também é utilizada na proposta para gerenciamento de informações

dos sensores. Por exemplo, é possível saber o status do ambiente, além do instante de

tempo em que a mudança ocorreu.

3.3 – Sensoriamento como Serviços

Os dados e informações providas pelas RSSF precisam chegar ao usuário

consumidor de forma transparente, permitindo, por exemplo, a utilização de serviços

web. A ideia dessa abordagem é permitir que diversos serviços da rede de

sensoriamento estejam disponíveis para o usuário. Neste sentido, alguns trabalhos

propostos na literatura abordam estas questões.

O trabalho proposto em (Bimschas et al., 2011) apresenta um caso de uso para

provisionamento de serviços para IoT. O cenário considera estacionamentos controlados

39

por diferentes empresas e que todos os espaços do estacionamento são equipados com

nodos sensores que detectam se eles estão ocupados. Os nodos sensores são wireless e

estão conectados a um gateway que tem acesso a Internet. Com isso, a aplicação pode

fornecer, em tempo real, informações sobre a ocupação das vagas de estacionamento. A

informação pode ser para o proprietário (que pode saber quais vagas estão ocupadas ou

livres) ou simplesmente para indicar o status da vaga através de guias, p. ex.,

sinalizadores eletrônicos. A aplicação ainda pode ajudar os motoristas a encontrarem

vagas em estacionamento através do uso de dispositivos conectados a Internet, p. ex.,

smatphones ou dispositivos de navegação. Estes dispositivos executam uma query que

retornam vagas livres em sua vizinhança. Esta aplicação pode ser um serviço hospedado

em servidores na Internet utilizando alguma interface padrão, p. ex., um web site.

Outro cenário apresentado por (Jardak, Walewski e Ganz, 2013) envolve

serviços de IoT aplicados a Smart Home. A ideia é que, no futuro, as casas inteligentes

estarão cientes sobre o que acontece dentro dela, impactando principalmente em três

aspectos: uso de recursos (economia de água e energia), segurança e conforto. A meta é

alcançar melhores níveis de conforto enquanto reduz os desperdícios. Além disso, smart

homes também abordam questões de segurança por meio de complexos sistemas de

segurança de detecção de furto, incêndio ou entrada não autorizada. As partes

interessadas se constituem de um grupo muito heterogêneo. Diferentes atores podem

cooperar neste cenário: companhias de Internet, fabricantes de dispositivos, operadores

de telecomunicações, provedores de serviços, companhias de segurança, eletricidade,

etc. O trabalho de (Patel et al., 2011) também explora a ideia deste cenário e destaca

que um importante desafio a ser abordado no contexto de IoT é permitir que

especialistas do domínio desenvolvam aplicações rapidamente, com o mínimo suporte

necessário. Neste caso, os autores destacam que as RSSF e os smart appliances,

adicionados aos elementos da Internet (como web e servidores de banco de dados

tradicionais), expõem suas funcionalidades como serviços web. Nos cenários

abordados, uma possível solução para a integração de dispositivos IoT com a atual

Internet é o conceito de Service-Oriented Architecture (Spiess et al., 2009). A ideia é

interconectar dispositivos IoT com a Internet através de redes IPs ou através de soluções

que utilizam gateways. Com isso, o que se espera é que Web Services sejam utilizados

para acessar dados de sensores sem ter preocupações sobre detalhes de baixo nível para

acesso a rede.

40

3.4 - Sensores Semânticos

A disponibilização dos sensores como serviços requer que estes possuam algum

tipo de representação baseado no domínio ao qual estão inseridos. Muitos trabalhos

reportados na literatura abordam as questões de representação utilizando ontologias

especializadas e que tem como objetivo representar os conhecimentos de determinado

domínio. Portanto, há uma necessidade de prover semanticamente os significados para

descrever as informações dos sensores.

O trabalho de (Desai, Sheth e Anantharam, 2015) advoga que o enriquecimento

semântico dos dados/sensores utilizando mecanismos e vocabulários padronizados pode

fornecer interoperabilidade entre aplicações de IoT/RSSF. Além disso, os autores citam

que a comunidade da Web semântica tem criado e melhorado os padrões de ontologias

para as observações dos sensores, como por exemplo, usando a ontologia SSN. O

trabalho propõe o conceito de Semantic Gateway as a Service. A ideia é que os

gateways são providos de recursos computacionais suficientes que permitem

implementar tecnologias para fornecer interoperabilidade. A arquitetura proposta no

trabalho considera que os nodos sinks não são dotados de poder computacional e que os

dados são transferidos para os gateways em seu formato primitivo e sem qualquer

anotação semântica. Um dos componentes da arquitetura tem suas preocupações

voltadas para a anotação semântica dos dados, chamada de Semantic Annotation

Service. Este componente processa cada mensagem recebida pelo nodo sink antes de

encaminhá-la para o gateway. Este processo fornece padronização em três níveis: (i)

descoberta e descrição dos serviços; (ii) descrição dos sensores e suas observações; (iii)

descrições específicas do domínio. As observações e as descrições semânticas dos

sensores são fornecidas utilizando a ontologia SSN. No modelo de dados primário da

arquitetura proposta, cada mensagem é anotada com a descrição dos sensores usando a

ontologia SSN. Os autores defendem que a descrição semântica dos sensores ajuda

outros agentes de software operar no nível de abstração semântica, além de permitir

processamento e raciocínio sobre os dados. Para as várias aplicações do domínio

específico, como monitoramento da saúde, agricultura e monitoramento ambiental, a

arquitetura pode ser equipada com as ontologias do domínio específico. Tais ontologias

descrevem conceitos específicos da ontologia para os elementos de serviços.

41

3.5 – Arquiteturas Propostas na Literatura

Alguns trabalhos propostos na literatura abordam questões relacionadas com

IoT/RSSF discutidas até agora. Estes trabalhos objetivam desenvolver arquiteturas que

tem por objetivo apresentar soluções para o domínio ao qual estão inseridos e tomam

como base algumas das preocupações inerentes a IoT/RSSF.

O trabalho descrito em (Bruno et al., 2013) aborda o uso de RSSF no

monitoramento térmico em Centros de Processamento de Dados. Um dos grandes

desafios deste trabalho é conciliar a computação verde com a crescente demanda

computacional, uma vez que estes ambientes causam impactos ambientais devido ao

alto consumo energético, principalmente com relação aos sistemas de arrefecimento. A

ideia é que, para aumentar a eficiência dos sistemas de arrefecimento é preciso

monitorá-los para compreender seu comportamento. O monitoramento é feito de

maneira indireta e menos intrusiva através da instalação de uma RSSF no ambiente. A

Figura 9 ilustra a proposta da arquitetura do sistema para monitoramento

termoenergético de CPDs.

Figura 9 – Leiaute da RSSF proposto em (Bruno, 2013)

A proposta está dividida em três partes: Application Layer (Camada de

Aplicação), Event Manager (Gerenciador de Eventos) e Acquisition Layer (Camada de

Aquisição). A Camada de Aplicação possibilita monitorar o CPD através de aplicações

42

responsáveis pela exibição dos dados e é composta por cinco módulos: (i) Sensornet

Monitor, que é o responsável por monitorar o status da RSSF; (ii) User Interface, que

tem como objetivo exibir informações coletadas pela RSSF e as providas por outros

módulos; (iii) Anomaly Detector, um módulo responsável por detectar anomalias de

temperatura no ambiente; (iv) Temperature Forecaster, responsável pelas estimativas

(previsão) de temperatura no ambiente monitorado; (v) CRAC Optimizer, que faz

previsões térmicas de longo prazo em conjunto com o Temperature Optimizer para

determinar setpoints eficientes de operação do Computer Room Air Conditioning

(CRAC). Outra parte da arquitetura proposta é o Gerenciador de Eventos, que tem o

papel de controlar a circulação de mensagens no sistema e introduzir o mecanismo de

publish/subscribe, permitindo uma comunicação assíncrona entre produtores e

consumidores de mensagens. Por fim, a Camada de Aquisição fica como responsável

pela coleta e persistência dos dados providos pelo Sensornet, que representa a própria

RSSF (incluindo a estação-base). Nesta camada, os dados são agregados pelo Collector,

armazenados num Database e publicados num servidor de eventos. As aplicações

podem acessar a base de dados diretamente ou utilizar o Gerenciador de Eventos caso

precisem de dados em tempo real.

O trabalho proposto em (Khedo et al., 2010) apresenta uma arquitetura de redes

de sensores que tem suas preocupações voltadas ao monitoramento da qualidade do ar.

Um dos elementos constituintes desta arquitetura tem suas preocupações relacionadas à

agregação dos dados enviados pelos nodos sensores, reduzindo de forma geral o

congestionamento na rede. Um dos parâmetros utilizados neste trabalho é o Air Quality

Index (AQI), uma tabela na qual são indicadas seis categorias de qualidade do ar que

são expressas numericamente. Nesta proposta, o Wireless Sensor Network Air Pollution

Monitoring System (WAPMS) compreende uma matriz de nodos sensores e sistemas de

comunicação que permite os dados alcançar o servidor.

43

Figura 10 – Estratégia de implantação WAPMS proposta em (Khedo et al., 2010)

A proposta é simulada para pequenas regiões utilizando um protótipo como

mostrado na Figura 10 e depois estendida para a cidade de Port Louis, capital da

República Maurício (país insular do oceano Índico). Uma pequena área desta cidade foi

fracionada em seis partes nas quais são posicionados os nodos sensores e um nodo sink.

O Air Quality Index (AQI) utilizado na proposta é um indicador de qualidade do ar

baseado nos poluentes que tem efeitos adversos na saúde humana ou no meio ambiente.

As seis escalas deste índice são distribuídas em valores numéricos de 0 a 300 que

indicam o nível de preocupação. Por exemplo, valores entre 0 e 50 indicam qualidade

do ar satisfatória. Já valores entre 151 e 200 indicam que qualquer ser humano pode ter

sua saúde afetada.

A arquitetura proposta em (Son et al., 2009) aborda preocupações relacionadas

às restrições das redes de sensores em cenários de aplicações logísticas. A proposta se

baseia na construção de um formato de regras condicionais in-network baseadas em

contexto. Dentro destas regras de contexto, por exemplo, são definidos campos para

atribuir tipos aos sensores utilizados (p. ex., temperatura, umidade, luz, etc.) e condições

lógicas para verificar os limites estabelecidos (p. ex., “dentro do intervalo”, “maior do

que o limite”, “menor do que o limite”, “fora do intervalo”, etc.). A ciência de contexto

é a principal contribuição do trabalho e está dividida em seis subpartes:

44

Sensor: sensores internos e externos utilizados pelos nodos com a missão de

monitorar o ambiente;

Rule database: contém um conjunto de regras pré-configuradas;

Rule engine: executa todas as regras recuperadas da Rule database;

Configuration: contém a configuração para operação dos nodos sensores;

Command identification: usado para reconhecer os comandos que podem ser

usados para atualizar as regras;

Storage: para armazenar os pacotes caso seja necessário;

Como mostrado na Figura 11, as regras de formato de contexto formam um

quadro de 6 bytes nos quais são definidos os campos que tratam as regras de contexto.

Por exemplo, o campo Sensor Type indica a propriedade observada pelo sensor

(temperatura, umidade, luminosidade, etc.). Já o campo Condition contém a condição

lógica para validar os pacotes dentro do contexto pré-definido, p. ex., maior do que o

limite estabelecido.

Figura 11 – Formato de regras da arquitetura proposta em (Son et al., 2009)

O trabalho proposto por (Moraru et al., 2011) descreve uma arquitetura de redes

de sensores denominada SemSense, conforme mostra a Figura 12.

Figura 12 – Arquitetura SemSense proposta em (Moraru et al., 2011)

45

O propósito desta arquitetura é coletar dados do mundo real e publicá-los na

Web. Esta arquitetura é composta por quatro componentes: Coleta de Dados (Data

Collection), Armazenamento (Data Storage), Enriquecimento Semântico (Semantic

Enrichment) e Publicação (Data Publishing). A ideia é que, através destes

componentes, os dados do mundo real sejam coletados, processados, equipados com

informações semânticas e publicados na Web. Uma das contribuições deste trabalho é a

implementação de um protocolo de coleta de dados automático denominado Self

IDentification Protocol (SIDP). Quando um servidor de coleta de dados recebe as

medidas de um nodo sensor com identificador desconhecido, uma instância de

SIDP_srv é criada pelo servidor e enviada para o coordenador da rede cujo nodo está

atrelado. Ao receber a resposta do coordenador, o dado é registrado na base de dados.

O trabalho descrito em (Zhou et al., 2015) apresenta um sistema de

monitoramento de temperatura em ambientes indoor. A Figura 13 ilustra o ambiente no

qual a proposta é aplicada.

Figura 13 – Subzonas de larga escala e a localização dos nodos sensores proposta por (Zhou et al., 2015)

O trabalho tem como objetivo identificar o padrão de distribuição de temperatura

e realocar o fluxo de ar de acordo com o padrão identificado. A metodologia de

implementação desta RSSF considera que o espaço monitorado é dividido em subzonas,

permitindo que um ou mais sensores de temperatura sejam instalados nestas divisões.

Os dados coletados pela RSSF são tratados em busca de valores anômalos com a

46

finalidade de representar a temperatura de cada subzona de forma mais precisa. Com

isso, o fluxo de ar pode ser direcionado de acordo com os critérios pré-definidos.


Neste capítulo foram apresentados trabalhos reportados da literatura que

propõem abordagens relacionadas aos principais elementos descritos nesta dissertação.

Foram relacionados trabalhos que tem suas preocupações com a Qualidade da

Informação (QoI) e como é sua abordagem no contexto de RSSF. Também foram

descritas plataformas utilizadas para o tratamento de situações das entidades. No

contexto de RSSF, as entidades representam pessoas, objetos ou lugares que estão sendo

monitorados e quais os seus estados. Adicionalmente, trabalhos propostos da literatura

que abordam sensoriamento como serviços foram abordados. Neste caso, as

preocupações dos trabalhos se relacionam com as descrições semânticas dos sensores e

sua relação com o domínio abordado como facilitador da interoperabilidade semântica.

A análise destes trabalhos permitiu visitar as abordagens propostas na literatura e

sua importância no contexto dessa dissertação. Além disso, foi possível explorar as

propostas de outras arquiteturas e as soluções que elas utilizam para resolver os

problemas nos domínios aos quais estão inseridos. Com isso, foi possível avaliar as

opções de tecnologias além de servir como inspiração para a construção de elementos

da arquitetura proposta neste trabalho, apresentada em detalhes nos próximos capítulos.

47

4. Arquitetura Proposta

4.1 – Introdução

Como já descrito neste trabalho, as RSSF envolvem um conjunto de artefatos de

hardware e software devidamente combinados para atingir os objetivos e os requisitos

daqueles que consomem os dados, sejam eles uma aplicação ou usuário final. Numa

visão mais ampla, estas redes precisam ser constituídas de elementos que vão desde o

software de baixo nível embarcado nos nodos sensores até as aplicações de alto nível,

utilizada pelos usuários. Com esta visão, é possível observar que entre estes elementos

existe uma série de lacunas que precisam ser preenchidas de tal forma que a concepção

de uma RSSF atenda aos usuários consumidores dos dados que são produzidos por elas.

Muitos padrões têm sido criados e adotados com o objetivo de aumentar a flexibilidade

e estabelecer um plano comum quando se trata do uso e aplicação em RSSF, como o

desenvolvimento de arquiteturas conceituais (Moraru et al., 2011), uso de ontologias

(Perera et al., 2014), frameworks de avaliação de dados (Guo et al., 2015), framework

de serviços (Silva, da, Pires e Sinderen, van, 2012), tecnologias relacionadas ao

armazenamento e visualização de dados (Nakamura, 2012), etc. Normalmente estas

abordagens procuram atender requisitos não funcionais em termos de confiabilidade,

disponibilidade, manutenção, tecnologias envolvidas, etc., além de atender requisitos

funcionais de acordo com os domínios aos quais estão inseridos. Neste sentido, a junção

de elementos arquiteturais se apresenta como um caminho para tratar das várias

questões que envolvem as RSSF e seus requisitos funcionais e não funcionais.

Conforme descrito no Capítulo 1, em cenários nos quais são utilizadas RSSF, muitas

soluções de alto e baixo nível são disponibilizadas. Com isso, questões como a forma de

coleta, avaliação de confiabilidade, status da entidade monitorada, compartilhamento e

disponibilização dos dados precisam ser abordadas no sentido de satisfazer os requisitos

dos usuários ou de especialistas do domínio. Portanto, construir uma arquitetura que

trata destas funcionalidades de maneira integrada se apresenta como uma necessidade

para prover facilidades comuns para os usuários e aplicações.

48

4.2 - Princípios e Requisitos

A arquitetura proposta tem como base um conjunto de princípios e requisitos. Os

princípios, como bases fundamentais, guiam o design e evolução das arquiteturas, que

são organizadas num sistema que incorporam seus componentes, suas relações entre si e

com o meio ambiente (Lankhorst, 2009). Para esta proposta, os princípios têm suas

raízes em trabalhos como (Kobialka, Buyya e Deng, 2010) e (Henson et al., 2009), que

se preocupam com questões alinhadas com a abordagem proposta nesta dissertação, por

exemplo, combinando a infraestrutura legada da Web com SOA e RSSF para prover

acesso aos recursos dos sensores. Além disso, a abordagem segue os conceitos da

ontologia de sensores discutidos em (Compton et al., 2012) e (Perera et al., 2014), uma

vez que o emprego de tecnologias semânticas ajuda no gerenciamento, busca e

combinação de sensores e dados observados. Mesmo sendo um problema tradicional

das RSSF, a economia de recursos da rede também se constitui um princípio geral da

abordagem proposta, sendo amplamente discutida em (Li, 2010) e (Kriegel, Kröger e

Zimek, 2010). A escolha de protocolos das camadas de enlace e roteamento de rede, por

exemplo, segue este princípio.

Em resumo, a arquitetura conceitual proposta está centrada nos seguintes

princípios:

P1. Abordagem de alto nível para disponibilizar os dados coletados pelos

sensores da RSSF. A abordagem proposta deve possibilitar ao usuário

acesso aos dados utilizando plataformas legadas, como a Web. A arquitetura

deve prover mecanismos facilitadores e transparentes ao usuário;

P2. Economia dos recursos. A arquitetura deve prover mecanismos que

promovam a economia de recursos da rede, tais como largura de banda e a

energia dos nodos sensores;

P3. Alinhamento com os conceitos de redes de sensores. Os elementos

constituintes da arquitetura devem refletir ontologias de redes de sensores,

tais como a W3C Semantic Sensor Network Ontology (SSNO);

Os requisitos elencados na proposta, por sua vez, são resultados das observações

de problemas e soluções relatados em trabalhos da literatura de IoT/RSSF, os quais

serviram de inspiração para esta dissertação. Neste caso, os requisitos representam

49

características de algo que uma aplicação é capaz de fazer. Por exemplo, (Guo et al.,

2015) propõe um framework que tem preocupações voltadas ao tratamento de QoI com

foco na precisão e na pontualidade dos dados coletados. Em (Mashal et al., 2015) são

investigados vários esforços em diferentes perspectivas para a compreensão de IoT. Por

exemplo, (Atzori, Iera e Morabito, 2010) posiciona IoT com base em três visões. Uma

das visões está relacionada à perspectiva orientada a semântica, na qual um objeto, sua

representação, o armazenamento e o compartilhamento das informações tem um papel

importante. Em (Souza, Filho e Spessimille, 2014) são abordadas questões relacionadas

com as situações de entidades através do uso de uma arquitetura que permite a inserção

de regras por um especialista do domínio. O trabalho proposto em (Malatras, Asgari e

Baugé, 2008) explora os benefícios da integração dos serviços das RSSF com a rede

corporativa com propósitos de compartilhar a informação, monitorar, controlar e

gerenciar os ambientes corporativos.

Em resumo, a arquitetura proposta deve atender aos seguintes requisitos:

R1. Avaliar a Qualidade da Informação: a arquitetura proposta deve se

preocupar com a qualidade do dado e sua relevância para o contexto das

aplicações utilizadas pelos usuários;

R2. Manter os registros dos dados: a abordagem da arquitetura deve levar em

consideração que os dados coletados pela RSSF precisam ser armazenados

através de Sistemas Gerenciadores de Banco de Dados (SGBD);

R3. Semântica: os dados coletados pelos sensores precisam ser enriquecidos

semanticamente com dimensões espaciais e temporais, isto é, sua origem,

seu local e o tempo em que foi registrado. Além disso, os sensores precisam

ser descritos em termos de suas capacidades e propriedades conforme a

ontologia do domínio de redes de sensores;

R4. Gerenciar situações: a arquitetura deve ser capaz lidar com regras de

contexto estabelecidas dentro de um domínio específico. Com isso, a gestão

de situações deve ser capaz de expressar, em alto nível, a ocorrência de

eventos na entidade monitorada;

R5. Oferta de Serviços: dentro do domínio específico devem ser

estabelecidos os serviços úteis aos usuários consumidores e especialistas do

50

domínio. Tais serviços devem estar disponíveis utilizando interfaces

homogêneas e padronizadas, devidamente descritas e catalogadas;

R6. Gestão da rede: a infraestrutura deve prover um ambiente no qual um

administrador possa ter acesso aos metadados relacionados aos sensores que

formam a RSSF, preservando e prevenindo problemas relacionados ao

funcionamento geral dos nodos sensores;

4.3 - Arquitetura Conceitual

A Figura 14 ilustra a arquitetura conceitual proposta. Nesta arquitetura, os

elementos estão dispostos em quatro camadas que estão combinadas e expostas para

atendimento dos requisitos descritos anteriormente.

A arquitetura é concebida em camadas para preservar os componentes

tecnológicos implementados, possibilitando que modificações/inserções de elementos

não prejudique a arquitetura como um todo. Além disso, uma camada de gerenciamento

se acopla na arquitetura de modo transversal de modo a prover serviços de

gerenciamento necessários para a proposta. Adicionalmente, os elementos da arquitetura

refletem os conceitos estabelecidos nas ontologias de sensores, já descritos

anteriormente. A seção seguinte explora com mais detalhes os elementos que formam a

arquitetura proposta.

Figura 14 – Arquitetura Conceitual

51

A arquitetura é estruturada em quatro camadas sobrepostas de maneira que os

elementos (dispositivos, base de dados, serviços, etc.) das camadas mais baixas

suportam a operação das camadas mais altas. A arquitetura é projetada de modo que o

gerenciamento dos elementos da arquitetura se dê transversalmente, o que indica o

posicionamento dos seguintes módulos de gerenciamento: Network Monitoring

(Monitoramento de Rede – MR), QoI Management (Gerenciamento de Qualidade da

Informação - GQI) e Situation Management (Gerenciamento de Situação - GS). Além

disso, também de modo transversal, a arquitetura reflete os conceitos estabelecidos em

ontologias do domínio de RSSF, como a Semantic Sensor Network Ontology (SSNO). A

descrição das camadas da arquitetura e suas funções são detalhadas a seguir.

Camada de Tecnologia (Technologies/Infrastructure): se localiza no nível

mais baixo da arquitetura, onde são organizados elementos necessários para captura e

transmissão dos dados lidos relativos aos fenômenos observados, tais como dispositivos

e sensores. Nessa camada estão as preocupações inerentes à tecnologia de RSSF, tais

como protocolos de enlace e roteamento e o sistema operacional utilizado nos

dispositivos acoplados aos sensores. Por exemplo, a construção de artefatos de software

para prover as funcionalidades dos sensores requer conhecimento e escolha de alguns

elementos das arquiteturas, como a pilha de protocolos de enlace e roteamento, além da

construção da aplicação necessária para interagir com o Sistema Operacional do nodo,

por exemplo, o TinyOS (Gay, Levis e Culler, 2005). Nesta camada também existem

preocupações referentes à forma como os dados são capturados para que sejam

utilizados pelas aplicações. Em geral, uma RSSF possui um ou mais nodos de

escoamento de dados, chamados de sorvedouros (sink) e diversos nodos sensores.

Sorvedouros são nodos com maior poder computacional e sem restrições de energia.

Esses nodos fazem a interface entre a aplicação e a rede, servindo de ponto de entrada

para a submissão dos interesses da aplicação e de concentrador das informações

enviadas pelos nodos sensores (Delicato et al., 2004).

Camada de Dados (Collection): Essa camada é responsável por armazenar os

metadados e os dados coletados dos sensores. Esta abordagem permite o registro de

dados mantendo um histórico das medições e funcionamento da rede. Dependendo da

solução projetada, os dados coletados podem ser armazenados em mais de uma base de

dados, as quais podem estar integradas. De acordo com a necessidade, tais bases de

dados podem ser implementadas por meio de várias tecnologias, por exemplo, banco de

52

dados relacionais e/ou banco de dados de triplas (usando RDF). A semântica desses

dados pode ser mapeada num banco de dados através da captura dos conceitos da

ontologia de sensores, como Semantic Sensor Network (SSN) e também da ontologia

específica do domínio.

Camada de Serviços (Services): a arquitetura proposta visa fornecer uma

representação padrão para atender aos interesses dos usuários consumidores. Esta

representação é baseada no conceito de Web Services (WS), utilizando um protocolo da

arquitetura legada, como o HTTP. A junção da arquitetura legada (Web) com a

arquitetura orientada a serviços (SOA) é um caminho para disponibilizar dados dos

sensores aos usuários. Com isso, é possível construir e ofertar um conjunto de serviços

que sejam adequados as necessidades dos usuários. Portanto, esta camada tem como

função organizar e hospedar os serviços. Os serviços propostos na arquitetura são

agrupados de acordo com suas características, a saber: (i) Domain Services são serviços

que oferecem informações acerca do domínio em questão como, por exemplo,

temperatura média da entidade monitorada, já (ii) Common Services fornecem

informações acerca da infraestrutura de monitoramento como, por exemplo,

informações de sensores, entidades, etc.

Camada de Aplicação (Application): Esta camada, localizada no topo da

arquitetura, utiliza um conjunto de capacidades providas pela camada de serviços. Nessa

camada estão as aplicações construídas pelos desenvolvedores e disponibilizadas aos

usuários finais. Dessa forma, a arquitetura proposta permite que os sensores, acoplados

a entidades físicas, possam ser integrados a Web por meio de serviços, permitindo que

os usuários realizem pesquisas e reutilizem/combinem os recursos dos mesmos através

de aplicações de software. A título de exemplo, aplicações de monitoramento do

ambiente doméstico, de atividades físicas, de temperaturas em ambientes controlados,

etc., podem consumir os dados que são providos pelos sensores e fornecer informações

sobre os fenômenos ou atividades que são requisitadas pelos usuários.

Camada de Gerenciamento (Management): esta camada está posicionada

transversalmente na arquitetura, pois ela tem a função de prover funções de

gerenciamento para outras camadas. São definidos três módulos de gerenciamento, a

saber:

53

a. Gerenciamento de Qualidade de Informação (GQI): O monitoramento constante

de um ambiente indica possibilidades de acontecimento de eventos (p. ex.,

abertura de uma porta, aumento/queda da temperatura de um determinado

ambiente, etc.) que podem ser observados por meio de dados coletados na

camada de tecnologia. Estes dados precisam refletir, com certo grau de

confiabilidade, a realidade do evento. Assim, este módulo tem duplo papel na

arquitetura: na camada de tecnologia é o responsável por avaliar a relevância do

valor obtido pelo sensor para o domínio o qual é aplicado. Isto implica em

fornecer dados mais apropriados para os usuários consumidores, além de

economizar recursos da rede como energia e largura de banda. Na camada de

dados seu papel é realizar avaliações sobre os dados recebidos pelos sensores e

inferir, através de métodos empíricos e/ou estatísticos, a confiabilidade do dado.

Por exemplo, o metadado time pode expressar, juntamente com o valor

observado, as características temporais do fenômeno e indicar o momento em

que ele ocorreu. Outro exemplo é a exatidão do dado lido. Valores anômalos

podem indicar erro de leitura e, portanto, devem ser avaliados no contexto do

cenário aplicado. Assim, o Gerenciamento de Qualidade de Informação na

arquitetura tem como missão realizar avaliações sobre os dados e metadados e

construir informações de QoI sobre os atributos que são necessários para o

contexto do cenário aplicado.

b. Gerenciamento de Situações (GS): Este módulo da arquitetura tem suas

preocupações voltadas à sensibilidade ao contexto através do uso de informações

do ambiente (contexto) para disparar eventos de acordo com a necessidade ou a

situação atual do usuário. Situações podem ser detectadas realizando análises

quantitativas das informações recebidas pelo módulo que trata de QoI. Portanto,

ao detectar uma situação, precisa haver certo nível de confiança na informação

recebida pelos sensores. Uma situação pode ser inserida através de uma

linguagem de modelagem de situações que utiliza uma máquina de regras como

back-end. A declaração de uma regra define as condições e os efeitos de sua

ativação. As condições de ativação são chamadas de Left Hand Side (LHS) e os

efeitos da ativação Right Hand Side (RHS). Quando um conjunto de condições é

satisfeita no LHS, ações no RHS são invocadas. Com isso, uma instância da

situação é criada e o ciclo de vida passa a ser controlado. Dessa forma, é

possível especificar as situações de acordo com os requisitos do usuário e do

54

cenário aplicado, inserir situações utilizando uma plataforma de situações e

realizar o gerenciamento através deste elemento da arquitetura. Este

gerenciamento se traduz, por exemplo, na geração de serviços de alerts e/ou

warnings, que avisa ao usuário da ocorrência de determinadas situações,

cabendo a ele fazer as intervenções ou tomar as ações necessárias. Além disso, é

importante observar que a conclusão de uma regra não gera necessariamente um

serviço (p. ex., alerts/warnings), isto é, ela pode gerar situações que podem ser

utilizadas em conjunto com outras situações.

c. Monitoramento de Rede (MR): paralelamente aos elementos apresentados na

arquitetura, é necessário criar mecanismos para gerir o funcionamento da

camada responsável pela aquisição dos dados do ambiente monitorado. Uma vez

que as RSSF têm capacidades limitadas, é preciso monitorar seu status. É

possível capturar metadados da rede, por exemplo, o nível da bateria e o parent,

que representa momentaneamente a qual nodo um mote está conectado. Com

base nestas informações pode-se, por exemplo, criar serviços nos quais é

possível obter o status dos nodos da rede, como matriz energética e seus nodos

vizinhos.

Ontologia de Redes de Sensores e do domínio: as capturas dos conceitos das

ontologias relacionadas formam a base de conhecimento para que exista uma relação

mais consistente entre RSSF e o domínio específico. Semantic Sensor Network

Ontology (SSNO), do W3C, é uma ontologia amplamente utilizada e capaz de descrever

sensores em termos de capacidades, processos de medidas e observações para redes de

sensores. A construção da base de conhecimento é uma peça importante da arquitetura,

pois permite armazenar informações sobre sensoriamento, atuação, dispositivos,

modelos de dados, etc., descritas na forma de ontologias e que são úteis para os usuários

e aplicações. Tais ontologias contêm informações sobre como os conceitos físicos

diferentes se relacionam (ontologia de domínio) além de informações relacionadas aos

dispositivos físicos que podem existir na rede (Pires et al., 2015).

A descrição da arquitetura conceitual vai ao encontro destes princípios e atende

aos requisitos estabelecidos anteriormente. Dessa forma, é possível relacionar os

elementos até aqui descritos com as capacidades providas pela arquitetura. O Princípio

1 (P1) da arquitetura lida com questões da disponibilização transparente de dados aos

usuários consumidores. Este princípio é atendido através da camada de serviços, que

55

utiliza padrões de tecnologias legadas, como a Web. Além disso, a camada de aplicação

se beneficia da camada de serviços com o intuito de construir novos serviços

necessários ao domínio. O Princípio 2 (P2) se preocupa com questões relacionadas a

conservação de energia. Uma das preocupações do Gerenciamento de QoI é prover

dados relevantes para o domínio, evitando o uso desnecessário do rádio dos nodos

sensores ao avaliar que o dado observado não tem significância suficiente para os

usuários consumidores e/ou especialistas do domínio. O Princípio 3 (P3) advoga que a

arquitetura deve seguir conceitos de domínios já previamente estabelecidos, como

SSNO. Esta questão fica mais evidente no momento da concepção da camada de dados,

na qual são anotadas questões como propriedades e capacidades dos sensores, além do

enriquecimento espacial e temporal dos dados coletados pela RSSF.

De uma forma geral, os requisitos anteriormente descritos são satisfeitos pelos

elementos de acordo com a Tabela 2:

Tabela 2 – Relação entre os requisitos e os elementos da arquitetura proposta

Requisito Camada/Elemento da Arquitetura

R1 – Avaliar QoI Gerenciamento de QoI

R2 – Manter registro dos dados Camada de Dados

R3 – Enriquecimento semântico Camada de Dados

R4 – Detectar situações Gerenciamento de Situações

R5 – Prover serviços Camada de Serviços

R6 – Monitorar rede Monitoramento de Rede

4.4 – Arquitetura de Implementação

A arquitetura de implementação é mostrada na Figura 15, na qual é possível

destacar a estrutura tecnológica utilizada visando atender aos requisitos da arquitetura

conceitual descritos anteriormente. As escolhas tecnológicas visam atender diversos

cenários de aplicação e adota SSN como core ontology, permitindo sua expansão para

diversos domínios de aplicação na qual uma RSSF se faz necessária.

56

Figura 15 – Arquitetura da Implementação

4.4.1 - Elementos da Arquitetura

Esta seção descreve de forma detalhada os elementos que constituem a

arquitetura de implementação. Tais elementos estão associados às suas respectivas

camadas e são descritas a seguir:

Elementos da Camada de Tecnologia: Dentro da camada de tecnologia,

Devices/Sensors são os elementos responsáveis pelas observações e medidas

do ambiente monitorado. Um device pode ser, por exemplo, da família IRIS

ou MICAz, que possui suas capacidades (CPU, RAM, flash ROM e rádio)

descritas em (MEMSIC, 2010). Um sensor faz interface com o device e é

capaz de observar algum fenômeno (temperatura, umidade, aceleração,

localização, etc.). Exemplo de sensores é a família MDA/MTS, que tem suas

especificações descritas em (Crossbow, 2007). O device é o responsável por

hospedar o software embarcado, normalmente constituído de uma pequena

aplicação com interesses específicos, a pilha do protocolo de rede/enlace e o

Sistema Operacional TinyOS, um SO desenhado especificamente para

57

sistemas de rede embarcados (Gay et al., 2003). Uma vez que o valor é

observado e medido, o elemento Comunication é o responsável por realizar a

transmissão destes dados até um nó responsável por coletar todas as

transmissões da rede (sink). O sink age como uma raiz (root) e normalmente

está conectado ao gateway da aplicação por uma interface serial ou de rede.

Neste caso, o gateway tem um papel duplo: de um lado provê mecanismos

para se conectar ao root e coletar os dados e de outro abre conexões, como

por exemplo, serial ou TCP, para que as aplicações possam consumir e/ou

armazenar os dados. Além disso, este elemento da arquitetura tem

preocupações com a escolha e configuração dos protocolos de rede e enlace

utilizados para que os nós pertencentes a RSSF possam transmitir os dados

até chegar ao sink.

Elementos da Camada de Dados: conforme descrito anteriormente, o

gateway tem um papel duplo. Na camada de dados, este elemento tem o

papel de um Serial Fowarder (SF), permitindo conexões de aplicações para

que os dados fornecidos pela RSSF sejam consumidos e/ou armazenados na

estrutura provida pela arquitetura. O armazenamento dos dados segue um

database relacional SQL-like, no qual são mantidos os registros dos dados

providos pela RSSF. Além disso, esta estrutura é responsável por armazenar

os metadados relacionados às leituras que são providas pelos sensores.

Portanto, anotações temporais e espaciais são registradas nesta estrutura de

forma que possam ser recuperadas ou analisadas em tempo real. A

persistência dos dados da aplicação é feita a partir da utilização do

framework Hibernate através da interação com o banco de dados Mysql. O

Hibernate possui características que facilitam a manipulação dos dados

através da criação de classes, permitindo a inserção de uma nova linha na

tabela toda vez que for requisitado que um objeto do tipo seja salvo. A

Figura 16 ilustra um exemplo de um fragmento do modelo relacional dos

dados e metadados aplicáveis na arquitetura.

58

Figura 16 – Fragmento da base de dados/metadados.

Elementos da Camada de Serviços: conforme apresentado anteriormente, a

proposta utiliza o estilo arquitetural RESTful para projetar aplicações da

Web fracamente acopladas e que contam com recursos nomeados — em

forma de Uniform Resource Locator (URL), Uniform Resource Identifier

(URI) e Uniform Resource Name (URN), por exemplo — e não com

mensagens. O REST transporta a infraestrutura já validada e bem-sucedida

da Web — HTTP, alavancando aspectos deste protocolo (como os pedidos

GET e POST). O REST apresenta a possibilidade de se ter diversas

representações de um mesmo recurso. Por exemplo, uma entidade pode ser

representada em diferentes formatos, como JSON, XML, HTML e text/plain,

dependendo da requisição feita pelo cliente (Content-Negotiation). O REST

ainda oferece a possibilidade de navegar entre relacionamentos (links web)

de vários recursos de forma dinâmica seguindo a usabilidade de qualquer

sistema web. Nesta camada da arquitetura os Domain Services podem ser, p.

ex., uma URI com um gráfico representando os valores das temperaturas

observadas pelos sensores numa determinada entidade. Já Commom Services

podem explorar, p. ex., uma URI contendo os locais nos quais os sensores

estão instalados.

Elementos da Camada de Aplicação: o desenvolvimento da aplicação se

baseia numa tecnologia que ajuda os desenvolvedores de software a criarem

páginas web dinamicamente (baseadas em HTML ou XML). Neste cenário,

a tecnologia JavaServer Pages (JSP) é utilizada através de um servidor web

59

compatível, como o Glassfish. As páginas JSP são criadas e utilizadas de

modo a separar a lógica da aplicação do resultado do processamento de uma

requisição HTML, facilitando a alteração do formato do seu conteúdo.

Partindo do conceito do JSP, uma página com conteúdo HTML contém

elementos especiais que concedem um caráter dinâmico e ainda possuem a

recompilação automática, permitindo que alterações feitas no código da

página sejam automaticamente visíveis em sua apresentação sem que seja

necessária a interrupção do funcionamento da aplicação. Como o HTML é

uma linguagem estática, o JSP é o responsável por criar este dinamismo.

Além disso, uma aplicação desktop Java é responsável por executar os

módulos propostos neste trabalho além de prover uma GUI que permite ao

usuário acompanhar o monitoramento das entidades além de realizar

cadastros, configurações, etc.

Elementos Camada de Gerenciamento: esta camada é composta por três

módulos (QoI, Situações e Rede) que são responsáveis pelas seguintes

tarefas:

a. Gerenciamento de Qualidade de Informação (GQI): este módulo

é baseado em testes de valores extremos conhecidos como

outliers. Além disso, ele tem duplo papel na arquitetura: na

camada de tecnologia é o responsável por avaliar a relevância do

valor obtido pelo sensor no domínio o qual é aplicado. A

relevância é avaliada através da construção de um algoritmo

estatístico baseado no Teste de Grubbs (vide seção 2.4). Este

algoritmo utiliza a linguagem nesC e está embarcado no nodo

sensor juntamente com o sistema operacional TinyOS. Na camada

de dados, o módulo de QoI realiza avaliações da confiabilidade

do dado lido que está registrado na base. Esta avaliação utiliza

um algoritmo estatístico baseado nos quartis, que realiza a

avaliação de um dado perante um subconjunto de dados

previamente lidos e divididos em quatro partes. Dessa forma, os

valores que pertencem ao subconjunto dos dados que são maiores

ou menores do que determinada amplitude são anotados como

valores anômalos ou inválidos. Na Figura 17 é possível observar

a funcionalidade do Módulo de QoI. Em (1), o método connect( )

60

recebe os dados providos pelo sink e os registram na base de

dados. Em (2), o Módulo de QoI coleta as amostras e as avalia

contra seu próprio subconjunto em busca de valores anômalos.

Após isso, valores considerados anômalos são marcados e

desconsiderados por outros módulos, serviços ou pelas

aplicações.

Figura 17 – Posicionamento e função do Módulo de QoI na arquitetura de implementação

b. Gerenciamento de Situações (GS): este módulo tem por função

avaliar os fatos que ocorrem na entidade. Portanto, os fatos

podem revelar se determinadas situações estão ocorrendo ou não

no ambiente monitorado, p. ex., aumento/queda de temperatura,

mudança de posição, etc. Neste caso, os fatos são agnósticos e

refletem apenas os eventos que ocorrem nas entidades. A

concretude dos fatos é realizada através dos registros dos valores

observados pelos sensores que já foram avaliados pelo módulo de

QoI. A ação do GS se concretiza no momento da inserção das

regras pelo usuário ou pelo especialista do domínio utilizando a

máquina de regras Drools, já descrita neste trabalho. A Figura 18

ilustra o funcionamento. Em (3) os fatos (facts) são utilizados

pela engine do Drools e as regras (rules) são inseridas no Módulo

de Situações utilizando uma interface disponível. Regras de

61

situações podem servir de fatos para outras situações de acordo

com as necessidades do ambiente monitorado ou do usuário que

insere a regra.

Figura 18 – Funcionamento do Módulo de Situações na arquitetura de implementação

c. Monitoramento de Rede (MR): ao transmitir os valores

observados no domínio, metadados sobre a rede também são

coletados. O protocolo de rede Collection Tree Protocol (CTP),

embarcado no nodo juntamente com a aplicação, permite que

dados como ID do mote, seu vizinho (parent) e o Received Signal

Strength Indicator (RSSI) sejam capturados. Além disso, a

aplicação embarcada também permite a leitura da voltagem de

sua bateria. Todos estes metadados são enviados juntamente com

o pacote de dados para o nodo sink. Para um administrador, estas

informações permitem mapear a rede como um todo além de

fornecer os estado das baterias dos nodos que pertencem a RSSF.

Ontologia de Redes de Sensores e do domínio: Os dados observados pelos

sensores são apenas uma parte da informação. Neste caso, anotações

espaciais, temporais e temáticas são interessantes de serem adicionadas. As

anotações espaciais estão relacionadas com o local em que ocorrem os fatos,

isto é, onde os eventos observados pelos sensores ocorrem. As anotações

temporais indicam quando ele ocorreu e as anotações temáticas indicam, p.

62

ex., o tipo da ocorrência. Neste sentido, o uso de ontologias se apresenta

como uma abordagem na qual é possível realizar estas anotações através dos

conceitos que estão relacionados aos domínios. Como já descrito, a ontologia

SSN descreve os sensores em termos de suas capacidades e propriedades e é

considerada uma core ontology, que é independente do domínio. Com isso, é

possível enriquecer os dados dos sensores a partir de conceitos definidos pela

ontologia. Além disso, outras ontologias podem se integrar neste modelo.

Neste caso, uma ontologia de domínio se apresenta como uma forma de

compreender os conceitos que são tratados dentro do domínio monitorado. A

junção destas ontologias agrega conhecimentos que podem ser utilizadas

para modelar os cenários abordados. A Figura 19 exemplifica, através de um

fragmento da ontologia SSN, os conceitos que estão relacionados ao domínio

de rede de frios. Por exemplo, a temperatura de uma entidade pode ser obtida

por um sensor de temperatura que representa uma instância de uma classe

Sensing Device relacionada com a ontologia SSN. Propriedades e

Capacidades dos sensores (Sensor) são contextualizadas como conceitos que

são explorados pela ontologia e devidamente anotados como atributos em

suas classes.

Figura 19 – Fragmento da ontologia SSN utilizado para o domínio da rede de frios


Este capítulo apresentou a proposta da arquitetura conceitual introduzindo os

elementos responsáveis para satisfazer os princípios e requisitos previamente

estabelecidos. Tais elementos foram conceitualmente descritos e relacionados para

63

indicar a função de cada um deles dentro da proposta. A descrição arquitetural da

proposta mostra que os elementos destacados que compõem a arquitetura podem ser

combinados em camadas sobrepostas e transversais. De uma maneira integrada, a

arquitetura se propõe a tratar os problemas da matriz energética dos nodos sensores bem

como o enriquecimento semântico e a qualidade dos dados produzidos por eles. Além

disso, com base nos dados avaliados e enriquecidos, a arquitetura possibilita o

acoplamento de um módulo de situações, permitindo indicar estados de interesses de

uma determinada entidade monitorada. Essas descrições permitiram que a arquitetura

fosse instanciada num cenário real, apresentado no próximo capítulo.

64

5. Aplicação da Arquitetura Proposta na Rede de Frios

Este capítulo apresenta uma aplicação da arquitetura conceitual proposta para

um cenário real. A ideia é explorar os mecanismos apresentados nos elementos da

arquitetura como forma de experimento. A seção 5.1 descreve de maneira geral o

cenário de implementação e apresenta os elementos envolvidos no experimento. A

seção 5.2 aborda os mecanismos utilizados na coleta de dados dos sensores. A seção 5.3

discute questões relacionadas com as situações das entidades envolvidas no

experimento. A seção 5.4 apresenta o sensoriamento do cenário como serviços. A seção

5.5 relata as experiências ao instanciar a arquitetura num cenário real. A seção 5.5

apresenta as considerações do capítulo.

5.1 - Cenário real de implementação

Supermercados em geral são caracterizados pela comercialização de produtos

alimentícios resfriados e congelados. Muitos desses produtos são sensíveis as variações

de temperatura, o que requer níveis compatíveis de temperatura no armazenamento e

exposição desses produtos. O armazenamento e exposição de produtos desta natureza

são feitos em diversos tipos de equipamentos, como ilhas de congelamento, expositores,

balcões de resfriamento, etc. Há uma grande diversidade de produtos acondicionados

nesses locais e isso requer que os equipamentos sejam ajustados, adequados,

diagnosticados, observados e avaliados, pois a variação de alguns graus pode causar o

comprometimento da chamada “vida-de-prateleira” dos produtos. Além disso, falta de

manutenção, instalação inadequada dos equipamentos de refrigeração ou interrupções

de energia podem comprometer os produtos, ocasionando perdas e prejuízos tanto para

o supermercadista quanto para o consumidor. Dessa forma, uma solução tecnológica

que auxilie o monitoramento da temperatura contribui para a detecção de falhas dos

equipamentos com o propósito de identificar problemas e tomar ações para prevenir

prejuízos gerados por alguma falha ou funcionamento irregular. Para os propósitos deste

trabalho, o nome “entidade” ou “entidade física” aparece de forma recorrente no texto

para se referir aos diversos tipos de equipamentos de resfriamento e/ou congelamento

(ilhas, balcões, expositores, coldstores, etc.) cuja temperatura é monitorada.

A arquitetura conceitual apresentada no capítulo anterior foi instanciada em um

cenário real a fim de oferecer uma solução de monitoramento das entidades físicas em

65

umas das lojas de uma rede de supermercado. A Figura 20 ilustra, em linhas gerais, o

cenário abordado.

Figura 20 – Cenário de Aplicação

A Figura 20 apresenta as entidades físicas monitoradas dispersas pelo ambiente.

Em cada entidade é instalado um mote (nodo) o qual estão acoplados sensores de

temperatura. Estes sensores coletam a temperatura nas áreas onde estão instalados e

enviam estes valores para um nó sorvedouro (sink). O nó sink está conectado a um

gateway, que por sua vez possui uma aplicação que armazena os dados coletados num

banco de dados. Estes dados são disponibilizados para os usuários e gerentes através de

Web Services, utilizados por páginas web ou aplicativos para smartphone.

Uma aplicação desktop Java foi construída com o objetivo de executar os

módulos propostos na arquitetura (QoI e Situação), além de apresentar uma interface de

monitoramento de entidades. Esta aplicação, chamada de AS3N (Abstract Sensor

Situation Semantic Network), segue os princípios e requisitos previamente

estabelecidos. A Figura 21 ilustra a interface de acesso à aplicação.

66

Figura 21 – Interface de acesso aos módulos de gerenciamento e monitoramento

Além dos cadastros rotineiros, como sensores e entidades, a interface também

disponibiliza acesso aos módulos propostos na arquitetura. Em Ferramentas estão os

módulos de QoI, no qual é possível iniciar a execução da análise dos dados recebidos

pelos sensores, e o módulo Situation, no qual o usuário pode inserir regras on point time

para disparar eventos como warnings ou alerts. Em Monitoramento é possível acessar a

interface que indica os dados e os estados das entidades monitoradas. Esta solução é

baseada na arquitetura conceitual conforme a Figura 22, descrita a seguir.

Figura 22 – Arquitetura Proposta no Cenário de Aplicação

Na camada inferior, que trata das questões tecnológicas e de infraestrutura, estão

os motes acoplados nas entidades físicas. Estes motes contêm sensores que estão

coletando dados das temperaturas internas e externas destas entidades.

67

Com o intuito de modelar os conceitos tratados no domínio, foi desenvolvida

uma ontologia para o domínio de medição de temperatura. Tal ontologia especializa

conceitos da ontologia de redes de sensores SSN para esse trabalho, e estabelece as

relações com a ontologia de domínio através de instâncias. A Figura 23 apresenta o

fragmento da ontologia SSN utilizada e suas instâncias para o domínio da rede de frios.

Figura 23 - Fragmento da ontologia de domínio desenvolvida para o cenário.

A ontologia de domínio apresentada é resultado das observações relacionadas ao

cenário de câmaras frigoríficas e também com entrevistas com o especialista do

domínio. Estas observações também servem de suporte para a construção dos módulos

relacionados na arquitetura proposta. Por exemplo, ao criar regras de situações para as

entidades é necessário compreender questões como suas condições de operação e

também suas restrições. Portanto, munir as entidades com estes conceitos permite

realizar comparações com os dados coletados pelos sensores que estão acoplados e ela.

Além disso, a ontologia de domínio serve de referência conceitual para a alteração ou

inserção de novos módulos.

Na faixa inferior da Figura 23, representando os conceitos do domínio, observa-

se a capacidade de obter o fenômeno temperatura, que é expresso através do conceito

TemperatureSensor. Este conceito está diretamente relacionado ao Sensor, que na

Ontologia SSN indica qualquer entidade que pode implementar sensoriamento seguindo

68

um determinado método. Isso produz um resultado expresso pelo conceito Value,

relacionado ao conceito ObservationValue (da ontologia SSN), que expressa o valor do

resultado de uma observação. No domínio, Mote representa o conceito de Device, que é

um artefato físico de tecnologia composto por partes menores e/ou um sistema. As

observações dos sensores precisam levar em consideração certas propriedades como

capacidades de medidas e propriedades de medidas. Na ontologia SSN isso se traduz

nos conceitos de MeasurementProperty, que são características observáveis e

identificáveis das observações de um sensor como, por exemplo, precisão dos sensores

e exatidão dos dados. Para o domínio do monitoramento de temperatura das entidades

físicas alguns conceitos são específicos. O conceito OperationCondition indica as

condições em que o equipamento está operando. Por exemplo, a entidade física

monitorada (PhysicalEntity) pode estar na condição de congelamento (freezer),

resfriamento (colling) ou degelo (defrost). Além disso, este conceito pode expressar a

situação na qual a entidade se encontra, p. ex., aumentando ou diminuindo a

temperatura. Em linhas gerais, estas condições refletem os intervalos de operação

expressos pelo conceito OperatingRestriction, que limita as capacidades de

funcionamento do equipamento, seja por intervenção do usuário ou pela especificações

técnicas do equipamento. Estas limitações são expressas por especializações do conceito

mencionado anteriormente. Por exemplo, OperatingRestriction é uma restrição de

operação ajustada pelo usuário, o qual indica as faixas limites de temperatura de

operação da entidade física. A Figura 24 indica as restrições de configuração do

equipamento. Neste caso, setpoint indica o grau mínimo de funcionamento da entidade.

Fim de degelo indica a temperatura na qual a entidade pode estar no fim de um ciclo e

Diferencial indica um delta de funcionamento acima do setpoint.

Figura 24 – Configuração dos parâmetros da entidade monitorada

69

Na camada de technologies/infrastructure são tratadas as questões do hardware e

software utilizado na RSSF para sensoriamento da temperatura. O hardware é composto

por motes da família IRIS e sensorboard MDA100cb, conforme já descritos. O

sensorboard mencionado possui uma área de prototipagem na qual foi adicionada uma

sonda de temperatura do tipo Termistor NTC (Negative Temperature Coefficient). O

sink é composto por uma interface USB MIB520. O software embarcado no mote se

constitui de um Sistema Operacional, protocolos de rede/enlace e uma aplicação. Esse

acoplamento entre protocolos e aplicação é possível utilizando o TinyOS, um Sistema

Operacional open source que suporta várias famílias de microcontroladores e rádios e

que tem uma grande comunidade de usuários (Ganz et al., 2011). A configuração

completa do software da RSSF consiste em um pequeno programa composto de uma

aplicação e dos componentes do TinyOS. Na aplicação é definido um mecanismo para

capturar os valores das temperaturas, que são transmitidos até chegar ao nó sink e

posteriormente serem tratados pelas camadas superiores. Nos componentes são

configurados os protocolos de enlace, como Box-MAC-1 (Moss e Levis, 2008), com o

objetivo economizar energia desligando o rádio em casos de longa inatividade e o

protocolo de rede Collection Tree Protocol (CTP) (Chawla et al., 2013), que é

amplamente considerado como um protocolo de referência para coleta de dados em

RSSF estáticas. Ambos os protocolos são utilizados neste trabalho.

O módulo de Monitoramento de Rede utiliza os metadados da rede

disponibilizados pela aplicação e pelos protocolos. Ao transmitir o valor da temperatura

coletado pelo sensor, metadados também são coletados pelos protocolos utilizados.

Com isso é possível receber o identificador (ID) do mote (nodo) que gerou o dado, qual

seu vizinho (parent), a intensidade do sinal (RSSI) e o nível da bateria. A

disponibilização destes dados é feita através da construção de serviços comuns do

cenário. Dessa forma, uma aplicação pode representar o status dos nodos sensores

através de uma interface gráfica (Figura 25) e serviços como wsn graph, que constrói o

grafo da RSSF e wsn power, que informa os níveis de baterias dos motes.

70

Figura 25 – Interface gráfica do monitoramento da rede

Os dados e metadados capturados dos sensores chegam até à aplicação web por

meio de uma aplicação Java, que os recebe e os armazena em um SGBD (Sistema

Gerenciador de Banco de Dados) relacional. A fim de garantir interoperabilidade

semântica entre os termos do domínio e as informações armazenadas, o modelo

relacional do banco de dados é baseado nas ontologias de domínio e SSN. Assim,

tabelas, atributos e relações do banco de dados podem ser semanticamente mapeados

nos correspondentes das ontologias utilizadas. A Figura 26 apresenta o modelo

relacional construído com base no fragmento da ontologia SSN e a ontologia do

domínio.

Figura 26 - Modelo relacional da aplicação refletindo as ontologias SSN e de domínio

O módulo de Gerenciamento de QoI no cenário proposto lida com questões

temporais e de confiabilidade, como exatidão, relevância e pontualidade. A exatidão dos

dados coletados é garantida por meio da calibração do sensor e compensações dentro do

módulo do software que trata QoI. Além disso, este módulo provê mecanismos para

71

avaliar se determinado dado pertence a um conjunto regular de leituras, isto é, se o dado

reflete o fenômeno observado (p. ex., aumento/queda real da temperatura) ou se o dado

tem características de erro (p. ex., erros de leitura do sensor). Por meio desse módulo

busca-se aumentar a confiabilidade nas informações obtidas e armazenadas na base de

dados, as quais servem para a tomada de decisão. A relevância está relacionada ao grau

de importância de determinado dado para a aplicação levando em consideração os

requisitos dos usuários consumidores. A pontualidade está relacionada ao momento em

que o dado se tornou disponível para a aplicação. Questões como a relevância e

confiabilidade dos dados ficam mais evidentes no momento da coleta dos valores das

temperaturas das entidades físicas. Testes empíricos foram realizados em três entidades

presentes em dois supermercados de médio porte, coletando os valores de suas

temperaturas periodicamente. A seguir são apresentados os mecanismos utilizados para

coleta dos dados no cenário descrito previamente.

5.2 - Mecanismos de Coleta de Dados na Rede de Sensores

A coleta dos dados das temperaturas é realizada por sensores posicionados em

locais das entidades onde é possível aferir com maior eficácia a ocorrência dos

fenômenos observados. Para tanto, é necessário adequar os sensores de modo que os

mesmos permaneçam instalados dentro da entidade monitorada. No caso de balcões e

câmaras frigoríficas, as temperaturas podem chegar a -30°C, o que compromete a

instalação dos nodos sensores dentro das entidades, além do fato de ficarem expostos a

furtos, choques mecânicos, umidade, etc. Dessa forma, utilizando a família de motes

IRIS e sensorboard MDA100cb, um novo sensor de temperatura do tipo “chicote” NTC

foi instalado na protoboard disponibilizada pela placa de sensoriamento MDA100cb.

Além disso, um pequeno microcomputador x86-based, uma MIB520 e um nodo sink

(root) foram acondicionados numa caixa fechada e posicionada no local para capturar os

dados providos pelo protótipo.

72

Figura 27 – Protótipos construídos para aplicação no cenário

A imagem da Figura 27 mostra os componentes utilizados para monitorar as

temperaturas das câmaras e balcões de resfriamento do cenário explorado. Cada mote

(nodo) também está acondicionado numa caixa de proteção. A construção do protótipo

na placa de sensoriamento requer o desenvolvimento de um novo software do sensor

para que a aplicação TinyOS consiga obter as leituras de temperaturas providas por ele.

No Apêndice A está disponível o código em nesC bem como as particularidades

envolvidas na construção deste protótipo.

Visando atender aos requisitos dos usuários consumidores/especialistas do

domínio e também levando em consideração os recursos computacionais limitados da

RSSF (energia, memória, largura de banda), a aplicação nesC TinyOS-based embarcada

no nodo tem os seguintes comportamentos:

Analisa dados que são obtidos pelo sensor de temperatura do protótipo em

intervalos de 120s (sample interval);

Avalia a relevância deste dado levando em consideração as três últimas

leituras;

De acordo com o especialista em refrigeração, leituras feitas no intervalo de 2

minutos (sample interval = 120s) atende de forma satisfatória os requisitos do domínio,

uma vez que balcões e câmaras de congelamento/resfriamento não entram em estado

crítico em curtos ou médios períodos de tempo. A relevância do dado é avaliada através

73

de um método estatístico que decide se o último dado observado deve ou não ser

enviado para o sink. Esse comportamento da aplicação se espelha nas características de

um outlier, isto é, caso um valor obtido ultrapasse determinado nível de significância

em relação a um conjunto de dados previamente lidos, ele é transmitido para o sink.

Para o cenário apresentado, a aplicação se utiliza de um algoritmo baseado num método

estatístico univariado chamado Teste de Grubbs (explicado na seção 2.4). A próxima

seção analisa e apresenta os resultados obtidos com este teste.

5.2.1 – Análise dos dados coletados

Nesta seção são apresentados e analisados os métodos e os dados coletados pelo

protótipo instalado nas câmaras e balcões de resfriamento/congelamento. Em todos os

casos, os sensores estão acomodados dentro da área de armazenamento útil da entidade,

aferindo a temperatura em intervalos de 120s. A primeira parte da análise é a coleta dos

dados de temperaturas das entidades sem a aplicação do algoritmo. Com isso é possível

coletar uma base de dados que representa o comportamento real da temperatura em

câmaras e balcões. A segunda parte da análise é a aplicação de um algoritmo estatístico

na base obtida. O algoritmo utilizado nos dados coletados é baseado no teste de Grubbs,

que utiliza índices baseados em níveis de significância referentes a 90%, 95%, 97,5%,

99% ou 99,95%. A tabela contendo os índices de Grubbs está disponível no Anexo I.

Os testes aplicados sobre os dados coletados empiricamente permite estabelecer a

quantidade de amostras utilizadas bem como o nível de significância. Para todos os

testes apresentados nesta seção são considerados um subconjunto das três últimas

amostras obtidas e um índice de significância maior do que 90%. As análises a seguir

mostram os resultados obtidos pelo algoritmo.

74

Figura 28 – Leituras de temperaturas de um balcão expositor de congelamento aberto

A Figura 28 mostra um gráfico contendo as leituras realizadas num expositor de

congelamento aberto. A linha contínua Samples demonstra as leituras das temperaturas.

Os pontos destacados em preto indicam os Outliers encontrados pelo algoritmo

utilizado. Para este cenário, 1269 amostras foram coletadas totalizando,

aproximadamente, 42 horas de testes. O algoritmo estatístico utilizado indica a presença

de 635 outliers, isto é, para este caso, aproximadamente 50% das transmissões são

evitadas, economizando os recursos do nodo sensor, principalmente sua matriz

energética. Além disso, pelo gráfico é possível observar que os valores transmitidos

(outliers) não interferem nos cálculos como a média, máximo ou mínimo, sendo

possível atingir os requisitos dos usuários consumidores e do especialista do domínio

coletando os valores providos pelo algoritmo.

A Figura 29 ilustra o gráfico das leituras de temperaturas de um balcão de

resfriamento fechado. Para este caso, 846 leituras foram realizadas, totalizando

aproximadamente 28 horas de testes. Os dados analisados pelo algoritmo indicam a

presença de 246 outliers, indicados pelos pontos pretos no gráfico. Pelos valores obtidos

é possível notar que foi possível economizar, aproximadamente, 71% de transmissões e

manter a relevância dos dados para os usuários consumidores e especialistas do

domínio.

75

Figura 29 – Leituras de temperatura de um balcão expositor de resfriamento fechado

A Figura 30 destaca as leituras de temperatura realizadas num balcão de

congelamento híbrido (equipamento composto por uma parte aberta e outra fechada). Os

dados analisados pelo algoritmo indica a presença de 740 outliers de um total de 1279

amostras. Isto indica a economia de, aproximadamente, 42% do total de transmissões

realizadas pelo nodo sensor. Testes em outras entidades foram realizados e os resultados

estão descritos na Tabela 3.

Figura 30 – Leituras de temperatura de um balcão expositor de congelamento híbrido

76

Tabela 3 – Resultados dos testes do algoritmo estatístico em suas respectivas bases de dados

Tipo de Entidade Samples Outliers Economia de transmissões

Balcão expositor de resfriamento aberto

156 92 41%

Balcão expositor de resfriamento fechado

1331 797 40%

Balcão expositor de congelamento fechado

446 272 39%

Pelos gráficos é possível notar que as entidades monitoradas seguem ciclos de

refrigeração, representados pelas suas variações constantes de temperaturas. Estas

variações demonstram certos comportamentos das entidades, possibilitando observar

momentos de queda ou aumento de suas temperaturas. Estes fenômenos são previsíveis

para um especialista do domínio ou para o usuário consumidor dos dados e refletem os

eventos capturados pelos sensores. Entretanto, no que diz respeito a RSSF, os dados

coletados pelos sensores não fazem distinção entre evento e anomalia, ou seja, dados

anômalos (aqueles cujos valores se desviam consideravelmente de dados lidos

anteriormente) também são transmitidos pelos nodos sensores. Portanto, os dados que

são enviados para uso das aplicações necessitam, por exemplo, da avaliação de sua

confiabilidade. Neste caso, é necessário estabelecer se o dado coletado é confiável, isto

é, se ele pertence ou não a um subconjunto de dados coletados previamente. Esta

abordagem é importante, pois permite que os dados produzidos por um sensor sejam

comparados com dados produzidos por ele mesmo, sem a necessidade de envolver

outros sensores para a realização dos testes. A seção seguinte explora o mecanismo

utilizado para realizar esta análise.

5.2.2 - Análise dos dados disponibilizados

Uma vez que os nodos sensores não fazem distinção entre eventos e anomalias,

seja por causas intrínsecas das entidades ou por problemas nos motes/sensores, é

necessário realizar uma análise após o recebimento dos dados pela RSSF. De fato, em

todos os cenários em que o protótipo foi utilizado, não houve anomalias de leituras,

entretanto, é necessário buscar mecanismos para minimizar estes erros caso ocorram,

77

principalmente por questões relacionadas com a matriz energética do mote e/ou da

qualidade do sensor, que interferem diretamente nos resultados das observações.

Os dados obtidos pelo algoritmo estatístico do nodo conseguem descrever o

comportamento das entidades monitoradas sem comprometer os requisitos dos usuários

consumidores ou especialistas do domínio. Num nível mais alto, já dentro da aplicação

que consome os dados, um módulo de QoI precisa analisar se estes dados obtidos

correspondem a eventos ou anomalias. Na Figura 31 é possível observar o fluxo de

tratamento dos dados obtidos pelos sensores.

Figura 31 – Fluxo de funcionamento do Módulo de QoI

Conforme descrito anteriormente, os dados obtidos pelos sensores são avaliados

por um algoritmo embarcado no nodo sensor que decide se o dado deve ou não ser

enviado para o nodo sink. O nodo sink, por sua vez, repassa todos os dados recebidos

para uma aplicação que os avalia e armazena numa base de dados. O processo de

avaliação consiste em investigar se algum dado pertencente ao conjunto recebido pode

ser caracterizado como uma anomalia. Este processo é realizado através seguinte

metodologia:

Os dados observados pelo sensor são coletados em intervalos de 120s e

segue uma distribuição de tempo normalizada;

Os dados avaliados e transmitidos pelo nodo sensor não seguem uma

distribuição de tempo normalizada, isto é, seus intervalos são irregulares;

O módulo de QoI recebe estes dados e realiza uma normalização temporal

através de inferências relacionadas aos valores anteriores;

78

A Figura 32 mostra a interface de configuração do módulo de QoI. Nesta

interface é possível indicar a quantidade de amostras que serão avaliadas e o tipo de

outlier (extremo ou moderado). Outliers extremos são aqueles em que o valor testado se

distância 3x da amplitude da amostra. Já os outliers moderados se distanciam 1,5x da

amplitude amostral. Ambos os valores são considerados barreiras (b), devidamente

explicados na seção 2.4.

Figura 32 – Interface de configuração do Módulo de QoI

A normalização dos dados pelo Módulo de QoI garante equidade temporal das

leituras transmitidas pelo nodo sensor. Com isso, é possível avaliar o mesmo

subconjunto de dados observados pelos sensores em busca de dados anômalos. O

processo de avaliação utiliza a base de dados normalizada e aplica um algoritmo

estatístico em busca de valores extremos, isto é, tem como meta detectar aqueles que

não pertencem ao subconjunto da amostra. Valores extremos também são classificados

como outliers, seguindo o mesmo princípio do elemento de QoI proposto na arquitetura.

O algoritmo utilizado neste módulo utiliza uma técnica estatística univariada baseada na

amplitude interquartil do subconjunto de dados recebidos (vide seção 2.4).

Com propósitos de verificar o comportamento do algoritmo, três bases de dados

(de três entidades físicas diferentes) foram submetidas a testes sobre os dados já

normalizados. Neste primeiro momento não existem valores anômalos nas bases

testadas. Os resultados são mostrados de acordo com a Tabela 4.

79

Tabela 4 – Resultados de falsos positivos do Módulo de QoI

Entidade Amostras normalizadas Nº de Falsos Positivos Falsos Positivos

A 1269 13 1,02%

B 1279 9 0,7%

C 1331 0 0%

As bases de dados utilizadas nos testes da Tabela 4 foram normalizadas para

garantir equidade temporal. Com isso, é possível avaliar os dados em busca de valores

anômalos utilizando faixas de tempos fixas. Os testes mostram que o algoritmo detecta

uma pequena porcentagem de valores anômalos e, neste caso, são considerados como

falsos positivos.

A fim de verificar o comportamento do algoritmo na presença de valores

anômalos, 2,3% dos valores testados anteriormente foram substituídos aleatoriamente

por valores irregulares. Estes valores foram inseridos no subconjunto de dados testados

de tal forma que se distanciam se confrontados com os demais. Os resultados são

mostrados na Tabela 5.

Tabela 5 – Resultados dos valores anômalos detectados pelo Módulo de QoI

Entidade Amostras

Coletadas

Valores

Anômalos na

amostra

Valores

Anômalos

detectados

Falsos

Positivos

A 1269 2,36% 2,21% 0,79%

B 1279 2,35% 2,35% 0,47%

C 1331 2,25% 2,18% 0%

A Tabela 5 indica a porcentagem de valores anômalos na amostra, valores

anômalos detectados e falsos positivos. Os falsos positivos se constituem na

porcentagem de valores regulares que são detectados como anomalias. A porcentagem

de valores anômalos na amostra são aqueles que são substituídos por valores irregulares.

Os valores anômalos detectados se constituem na porcentagem de valores que são

irregulares e que são detectados pelo algoritmo.

80

5.3 – Situações das entidades monitoradas

Os eventos que ocorrem nas entidades são de natureza dinâmica. Este

dinamismo ocorre por que aumentos e quedas de temperaturas podem acontecer por

causa ciclo de funcionamento da entidade ou por causas externas, como desligamento,

funcionamento irregular, aumento da temperatura ambiente, etc. A captura destes

eventos se constituem como um caminho para a detecção das situações que ocorrem nas

entidades. Conforme descrito anteriormente, a engine Drools é utilizada como

mecanismo para gerenciamento de situações que ocorrem nas entidades. Os fatos se

constituem como a fonte de dados da RSSF e alimentam a máquina de regras.

Entretanto, a definição de regras nas quais são estabelecidos valores para os eventos são

on point time, isto é, reagem se determinada condição naquele ponto do tempo é

satisfeita. A Figura 33 mostra a interface de inserção de regras do módulo de situações

implementado na arquitetura proposta.

Figura 33 – Interface de inserção de regras

Esta interface permite ao usuário inserir a regra bem como qual ação ele deseja

executar quando ela for satisfeita (enviar um SMS, e-mail, etc.). Por exemplo, é

possível definir uma regra que emite um alerta quando a temperatura da entidade for

maior do que 10°C. Neste caso, a condição é satisfeita e a regra apenas volta a ser

executada caso este evento ocorra novamente. Outra abordagem para este cenário é

realizar o controle dos ciclos que ocorrem na entidade sem o conhecimento prévio dos

limiares estabelecidos nas regras. Dessa forma, controlar as atividades das situações,

isto é, se uma regra está ativada ou desativada, se apresenta como um caminho para a

compreensão dos fatos que se traduzem em eventos nas entidades. Por exemplo, a

81

variação de valores lidos pelos sensores de determinada entidade pode indicar a

ocorrência de algum fenômeno, tornando o cenário tão complexo quanto se queira.

Neste caso, a plataforma SCENE proposta em (Pereira, Costa e Almeida, 2013) se

acopla na arquitetura proposta neste trabalho para fornecer suporte ao gerenciamento do

ciclo de vida da situação através de ativação/desativação de regras de situação. Na

Figura 34 é possível observar os ciclos de ativação/desativação das situações criadas. O

ciclo representado de (1) até (2) representa um tipo de situação ativa denominada

IncreasingValue na qual a temperatura aumenta até que outra situação ocorra. O ciclo

representado de (3) até (4) indica outro tipo de situação denominada

DecreasingAfterIncreasing, representando a queda da temperatura após um aumento.

Neste caso, a situação IncreasingValue passa para o estado inativo. O ciclo de (5) a (6)

demonstra o tipo de situação DecreasingValue, indicando queda de temperatura. Por

fim, o ciclo de (7) a (8) indica o tipo de situação IncreasingAfterDecreasing,

demonstrando um aumento de temperatura após uma queda.

Figura 34 – Exemplo do controle de situações modeladas no cenário instanciado

Uma vez que os ciclos de funcionamento das entidades monitoradas são

dinâmicos, o gerenciamento do ciclo de vida da situação se mostra importante, pois é

possível identificar os momentos em que os tipos de situações ativam ou desativam.

Neste caso, a plataforma SCENE contribui através da criação de SituationTypes

permitindo detectar e manter informações sobre situações. Isto é particularmente

82

importante, pois mesmo que as entidades se comportem em ciclos temporais

estabelecidos, eventos externos podem interferir no funcionamento. Com isso, o

gerenciamento de situações se apresenta como uma abordagem independente das

configurações ou eventos temporais que ocorrem na entidade monitorada. Os tipos de

situações revelam um estado particular de interesse e serve de apoio para o especialista

do domínio.

A Figura 35 ilustra como o Módulo de Situação está acoplado na plataforma

SCENE. Quando o monitoramento inicia, uma instância de KnowledgeBase é criada

através do método createBase( ). Após isso, uma session é criada a partir de uma

instância StatefulKnowledgeSession, que permite a aplicação estabelecer uma interação

com a engine do Drools, alimentada pelos fatos na Working Memory. Posteriormente,

um evento é adicionado através do método addEventListner(SCENESessionListner)

para monitorar situações adicionadas na sessão (session). Uma Thread controla a

atualização da sessão em tempo de execução. Dessa forma, uma classe Situation é

instanciada e utiliza como atributos as classes que estendem SituationType (ST1, ST2,

ST3, ... STn) da plataforma SCENE. Uma interface FactHandle recebe a situação

(Situation) inserida na sessão (session).

O processo previamente descrito ocorre somente uma vez, ou seja, novos fatos

são atualizados pelo método update ( ), passando como parâmetro o FactHandle e a

Situation. Os tipos de situações (ST1, ST2, ... STn) refletem as classes anteriormente

citadas, p. ex., IncreasingValue, DecreasingValue, etc.

Figura 35 – Diagrama do módulo de Situação acoplado na plataforma SCENE

83

5.4 - Disponibilização dos dados

Além de estarem disponíveis em uma aplicação desktop tradicional, os dados

persistidos podem ser disponibilizados como serviços utilizando a arquitetura legada da

Web. Neste caso, serviços úteis aos usuários podem ser disponibilizados. Por exemplo,

serviços como a média, mínima ou máxima temperatura de uma entidade podem ser

disponibilizados como Web Services.

Figura 36 – Representação de um Web Service contendo a variação de temperatura de um sensor

Considere o gráfico representado pela Figura 36. Um Web Service

“Variacao_Temp_Dia” fornece os dados referentes a variação das temperaturas de um

sensor durante os períodos da manhã, tarde e noite. Esses dados são obtidos e plotados

em um gráfico, conforme apresentado. Os serviços previamente descritos são

implementados na arquitetura proposta, conforme mostra a Figura 37.

Figura 37 – Estrutura do mecanismo de serviços Web

84

O pacote Resources dá suporte à implementação dos serviços que foram criados

e estão sendo utilizados. Uma URI indica o nome do serviço Web que pode ser

utilizado. A utilização do Serviço provê uma anotation @GET e uma produces, que é a

forma como a qual o serviço vai ser produzido, por exemplo, XML ou JSON. O acesso

aos dados é feito pela API Criteria, que permite construir consultas estruturadas

utilizando Java. Do outro lado, páginas Java Server Page (JSP) recebem o resultado

acessando os serviços.

Uma aplicação na qual executam os módulos propostos nesta arquitetura

também disponibiliza uma interface de monitoramento. A Figura 38 ilustra a central de

monitoramento das entidades.

Figura 38 – Central de monitoramento das entidades

Nesta central é possível informar a situação das entidades, representada por

ícones ilustrativos (aumento/queda de temperatura), a última temperatura recebida, a

localização dos sensores, suas temperaturas máximas e mínimas (diárias), além de um

gráfico em tempo real.

85

5.5 – Considerações do capítulo

Este capítulo apresentou uma instância da arquitetura aplicada ao monitoramento

térmico de câmaras e balcões de congelamento/resfriamento. Os dados coletados pela

RSSF instalada nestas entidades permitiu analisar e avaliar características tanto do

ponto de vista dos sensores quanto das entidades monitoradas. No que diz respeito aos

nodos sensores, a aplicação construída buscou poupar recursos como largura de banda e

uso do rádio. Adicionalmente, questões como a qualidade da informação produzida pelo

sensor puderam ser avaliadas contra um subconjunto de dados produzidos por ele

mesmo, permitindo investigar valores anômalos reportados pelos sensores. Do lado da

entidade, situações puderam ser monitoradas com base em dados fornecidos pela RSSF,

permitindo indicar os estados nos quais as entidades se encontram. Além disso, o

cenário real de implementação reflete os conceitos estabelecidos na ontologia SSN e do

domínio da rede de frios, as quais servem de base para a construção da aplicação.

86

6. Discussão

O desenvolvimento de aplicações reais de RSSF/IoT envolve várias questões

tecnológicas que se apresentam como desafios ao preencher a lacuna entre as camadas

da arquitetura conceitual e a arquitetura de implementação. Após a validação da

arquitetura proposta no estudo de caso aplicado na rede de frios foi possível avaliar as

escolhas conceituais e tecnológicas adotadas, apontando os acertos, desafios e

dificuldades. Num cenário real, os desafios se iniciam desde a concepção do protótipo

da RSSF, passando pelos módulos computacionais que representam os elementos até

chegar à aplicação. As sessões seguintes discutem estas questões no contexto das

camadas e elementos propostos, além de posicionar a arquitetura proposta em relação a

alguns outros trabalhos semelhantes, de caráter experimental e prático, selecionados da

literatura.

6.1 – Camada de tecnologia/infraestrutura

O cenário instanciado é uma rede de frios, ou seja, as temperaturas monitoradas

oscilam entre -30°C a +10°C. Neste caso, o artefato de hardware utilizado para coleta

dos dados precisou ser construído, uma vez que os nodos sensores não podem ser

instalados nestes ambientes devido a baixa temperatura. Conforme descrito

anteriormente, um novo sensor do tipo NTC (sonda) foi adicionado no mote IRIS

utilizando uma interface de protótipos MDA100. Isso permitiu que os valores das

temperaturas da área de armazenamento das câmaras fossem coletados. As dificuldades

que surgiram nesta etapa estão relacionadas à existência de poucos trabalhos nos quais

essa abordagem foi utilizada. Com isso, estas dificuldades foram contornadas por meio

dos manuais dos sensores e dos motes que foram utilizados na concepção do protótipo.

Além disso, questões relacionadas aos artefatos de software do novo sensor também se

apresentaram como um desafio, uma vez que também há poucos trabalhos relacionados

nesta abordagem. A plataforma de programação utilizada nos nodos sensores é baseada

no Sistema Operacional TinyOS e utiliza a linguagem de programação nesC. A árvore

de desenvolvimento deste sistema (local onde fica hospedado toda a estrutura do

sistema, suas aplicações, atualizações, etc.) está em constante mudança e várias

interfaces de sensoriamento fazem parte desta estrutura. Além das dificuldades

tradicionais de programação em baixo nível, como por exemplo, desenvolvimento de

códigos para novos motes e sensores, a curva de aprendizado é maior por conta da

87

pouca documentação que, por vezes, é incompleta. Estas dificuldades foram superadas

pesquisando os códigos de baixo nível disponíveis na árvore do sistema. Com isso, foi

possível construir um novo código para o sensor adicionado.

Uma das preocupações tradicionais das RSSF é a economia dos recursos dos

nodos sensores, principalmente a bateria e a largura de banda, que são limitadas. Estas

preocupações foram abordadas de duas maneiras: (i) desligando o rádio quando o nodo

sensor estiver ocioso e; (ii) construindo uma aplicação que leva em consideração a

coleta de dados relevantes. Em (i) o protocolo BOX-MAC foi utilizado através da

configuração dos parâmetros low power listening nas flags do Makefile. Em (ii) foram

pesquisadas na literatura abordagens relacionadas às aplicações com os mesmos

propósitos. Uma das dificuldades desta abordagem é estabelecer thresholds ou deltas de

transmissão, uma vez que normalmente não se conhece o ambiente monitorado. Este

problema foi abordado através de técnicas estatísticas simulando algoritmos nas bases

de dados reais coletadas. Esta técnica foi utilizada por não haver necessidade de se

estabelecer um limiar de transmissão fixo, ficando este trabalho por conta do cálculo

estatístico realizado no nodo sensor. Com isso, espera-se que esta abordagem seja

flexível para aplicação em outros cenários. Em cada algoritmo, vários parâmetros foram

configurados em busca de uma solução que representasse economia de transmissões e,

ao mesmo tempo, dados relevantes para o consumidor final. Além disso, o algoritmo

precisa levar em consideração questões de recursos dos nodos sensores, como memória

e CPU. Neste cenário, o algoritmo baseado no Teste de Grubbs se mostrou como o mais

adequado, uma vez que utiliza uma codificação simples e, ao mesmo tempo, atinge os

objetivos previamente descritos. Por fim, o algoritmo da aplicação foi implementado em

nesC e embarcado no nodo juntamente com a nova interface do sensor e os módulos

operacionais que compõem o TinyOS.

6.2 – Camada de dados

A camada de dados implementada constitui-se de uma base de dados construída

com base nos conceitos e relações de um fragmento da ontologia SSN (neste caso,

representando uma core ontology) juntamente com os conceitos da ontologia do

domínio de rede de frios (domain ontology). Como já salientado, muitos trabalhos

reportados na literatura abordam a ontologia SSN da W3C, uma referência que é

amplamente utilizada. Dessa forma, o trabalho reflete estes conceitos mapeando a

88

ontologia SSN num diagrama de classes UML, que deu origem ao modelo relacional da

base de dados implementada. Com essa abordagem espera-se que novos cenários

possam ser explorados com menores esforços. Uma das dificuldades encontradas é o

preenchimento da lacuna entre os conceitos da camada de infraestrutura/tecnologia e do

software de armazenamento. Por exemplo, sensores acoplados aos nodos sensores

precisam ser identificados. Entretanto, sensores analógicos não possuem ID de série e

mais de um sensor pode se acoplar ao nodo. Estas dificuldades foram superadas através

da codificação em baixo nível dos sensores. Outra abordagem utilizada foi o

acoplamento de sensores digitais que não possuem estas restrições, entretanto, o código

de baixo nível para os sensores comumente utilizados não estão disponíveis na árvore

do TinyOS ou estão incompletos.

6.3 – Módulos de Gerenciamento

A arquitetura conceitual propõe módulos de gerenciamento transversais, como o

Gerenciamento de QoI, de Situações e Monitoramento de Rede. O Gerenciamento de

QoI é constituído de um algoritmo que tem por objetivo procurar valores anômalos nas

amostras. A preocupação com este módulo surgiu através de pesquisas em trabalhos

reportados da literatura que procuram abordar estes problemas. Muitos autores advogam

que os sensores físicos podem mensurar e reportar valores anômalos por questões da

qualidade do sensor. Além disso, alguns trabalhos demonstram que o nível baixo da

bateria dos nodos causa leituras anômalas dos sensores. Ainda que raros, foram

identificados valores anômalos enviados pelos sensores nos testes preliminares do

protótipo. Através da observação, chegou-se à conclusão que a causa provável era a

qualidade do sensor, uma vez que o nível da bateria estava adequado. O mecanismo

utilizado para abordar este problema com o intuito de procurar por valores anômalos nas

amostras foi o método estatístico baseado nos quartis. Neste caso, uma amostra é

ordenada e dividida em quatro partes. Os valores que fazem parte da amostra e que são

utilizados como referência nos testes possuem posições chave e são rotulados como Q1

e Q3. Quaisquer valores abaixo de Q1 ou acima de Q3 (considerando também uma

determinada amplitude) são anotados como valores anômalos. Outra abordagem deste

módulo é a normalização do tempo. Os nodos sensores transmitem os valores

observados com base nos eventos que ocorrem na entidade (neste caso, a câmara de

resfriamento), isto é, não seguem intervalos de tempos regulares. Na abordagem

proposta, o algoritmo normaliza os valores preenchendo as lacunas de tempo com os

89

valores anteriores nas quais nenhuma leitura foi registrada. Os testes realizados nas

bases de dados coletadas do cenário real mostram que essa abordagem detectou uma

quantidade valores anômalos menores do que 1% e são, portanto, considerados falsos

positivos. Uma porcentagem de 2 a 2,5% de valores anômalos foram inseridos na base

de dados para fins de testes do algoritmo. Neste caso, uma média de 95,26% destes

valores anômalos inseridos foram detectados.

O Gerenciamento de Situações tem o propósito de informar ao usuário

consumidor qual o estado da entidade monitorada. A abordagem proposta utilizou uma

plataforma baseada em máquina de regras, possibilitando inserir situações de interesse

on point time que são definidas pelo usuário (p. ex., enviar um alerta se temperatura de

uma entidade for maior do que 10°). Além disso, o cenário pode se tornar tão complexo

quanto se queira através do acompanhamento dinâmico dos eventos que ocorrem nas

entidades sem estabelecer limiares. Para esta abordagem, os tipos de situações foram

criados utilizando uma plataforma que controla o ciclo de ocorrências dos eventos nas

entidades. A plataforma SCENE se mostrou apropriada para o controle destes eventos,

permitindo acompanha-los de forma dinâmica através do monitoramento dos valores

lidos pelos sensores presentes nas entidades. Isso permitiu a criação de tipos de

situações como classes da plataforma e revelam os estados das entidades em tempo de

execução. A ideia é que a captura destas ocorrências sirvam de base para análise

posterior por um especialista do domínio. Além disso, acompanhar os ciclos de

situações que ocorrem nas entidades também trouxe benefícios, pois permitiu que as

ocorrências/situações nas entidades fossem registradas tanto de forma visual (através da

interface de monitoramento) quando textual (através de registros de logs).

O Monitoramento de Rede tem como objetivo informar ao instalador ou ao

usuário consumidor o status da rede e o nível de bateria dos nodos sensores. O CTP é o

protocolo de rede embarcado nos nodos sensores. Este protocolo permite a coleta de

metadados como o parent e o RSSI. O parent é importante no momento de identificar

os nodos e seus vizinhos. Já o RSSI indica a “força” do sinal. Esta informação pode ser

relevante para um instalador, pois permite identificar nodos cujos sinais estão

inadequados ou fora dos padrões, resultando em perdas de pacotes. Outra parte de

código embarcado nos nodos sensores permite a leitura da voltagem de suas baterias.

Essa informação serve de base para identificar o momento de substituir a bateria do

90

nodo sensor. Trabalhos reportados na literatura, p. ex., em (LIMA, 2014), indicam que

níveis de baterias abaixo de 2,4 volts tendem a produzir leituras anômalas.

O CTP é o protocolo de rede padrão utilizado pelo TinyOS e pode ser

comparado a outros protocolos de rede, como o RPL (Routing Protocol for Low-power

and lossy networks). Artigos reportados na literatura, p. ex., em (Ko et al., 2011)

apontam que o desempenho de ambos os protocolos são equivalentes. As

implementações do RPL no TinyOS interagem com as interfaces providas pelo BLIP

(Berkeley Low-power IP) que é a pilha de-facto IPv6/6LoWPAN para TinyOS na

versão 2.x.

6.4 – Comparação com outras propostas

Com a finalidade de avaliar a proposta apresentada, esta seção apresenta uma

comparação com alguns trabalhos relacionados com as arquiteturas de RSSF e o que

elas tratam. A ideia é discutir os elementos propostos neste trabalho comparando com

os trabalhos relacionados no Capítulo 3 (seção 3.5), que descreveu algumas propostas

de arquiteturas para RSSF da literatura e os elementos/módulos que elas implementam.

Uma breve revisita as estas propostas permite comparar o que elas tratam e sugerir

melhorias de acordo com as abordagens deste trabalho.

O trabalho de (Bruno et al., 2013) propôs uma arquitetura de RSSF para

monitoramento termoenergético em CPDs. Divida em três partes, a arquitetura trata das

aplicações, dos eventos que ocorrem no ambiente e da aquisição dos dados dos nodos

sensores. Dentro deste cenário, os sensores de temperatura estão posicionados em locais

estratégicos com a finalidade de capturar dados de temperaturas tanto na entrada quanto

nas saídas de ar onde se localizam os servidores. Na camada de aquisição dos dados

uma das preocupações é a precisão temporal da coleta, isto é, os dados são coletados a

cada 1s e as transmissões são realizadas caso um limiar (delta) de 0,5º seja alcançado.

Neste cenário outras questões podem ser investigadas. Por exemplo, questões como a

Qualidade da Informação (QoI) e o limiar de transmissão do nodo sensor se apresentam

como propostas que podem incrementar e/ou melhorar as soluções apresentadas pelo

trabalho. Com isso, os dados coletados pelos nodos sensores podem ser avaliados contra

um conjunto de dados previamente coletados a fim de investigar a existência de dados

anômalos produzidos pelos sensores. Além disso, o limiar de transmissão estabelecido

91

pode ser modificado utilizando técnicas estatísticas ao invés de estabelecer um

threshold estático, permitindo flexibilidade em outros cenários.

A arquitetura que foi proposta em (Khedo et al., 2010) está inserida no domínio

do controle da qualidade do ar. Além da preocupação com a agregação dos dados

providos pelos sensores, outra abordagem do trabalho é o uso de um índice de qualidade

do ar pela aplicação desenvolvida. Este índice, denominado Air Quality Index (AQI), é

um valor numérico escalar que indica as condições do ar (partículas e poluentes). O

cenário utilizado como exemplo pode ser enriquecido ou melhorado adicionando

componentes que se baseiam em regras que reagem de acordo com o índice AQI

utilizado (situações). Dessa forma, é possível posicionar um elemento que trata de

questões relacionadas com as situações da área observada através do uso de máquinas

de regras. Isto facilita, por exemplo, que um especialista do domínio insira ou

modifique alertas quando determinado nível AQI se apresentar satisfatório (ou

perigoso), utilizando a linguagem mais simples e natural provida pela engine Drools.

Adicionalmente, na proposta como um todo pode ser abordado o conceito de serviços,

munindo usuários e estações de monitoramento do ar com informações de forma mais

transparente.

A proposta que foi apresentada em (Son et al., 2009) descreve uma arquitetura

de mensagens nos quais os campos de controle dos pacotes são baseados em contexto,

isto é, propriedades e capacidades são atribuídas aos sensores de acordo com as regras

contidas numa rule database. Uma das alternativas para enriquecer este trabalho é

utilizar os conceitos abordados no domínio com os conceitos já estabelecidos na área de

RSSF, como o Semantic Sensor Network. Como benefício, os dispositivos, agentes de

software e serviços de diferentes entidades são dotados de uma mesma compreensão

semântica, melhorando sua interoperabilidade através do enriquecimento dos dados. Isto

é particularmente importante, pois adiciona metadados (p. ex., propriedades e

capacidades) dos sensores responsáveis pela geração dos dados. Além disso, regras de

negócios podem ser estabelecidas utilizando uma engine de regras que utiliza uma

linguagem de mais alto nível e mais próxima ao natural, como o Drools, apresentado

previamente.

A arquitetura denominada SemSense foi proposta por (Moraru et al., 2011).

Além de implementar o Self IDentification Protocol, responsável por identificar a

92

origem dos dados enviados pelos nodos sensores, a arquitetura tem por objetivo

armazenar os dados, enriquecê-los semanticamente e publicá-los na Web. O

componente de armazenamento da arquitetura descrita neste trabalho pode ser

melhorado com a introdução de um elemento de avaliação de QoI. Dessa forma, é

possível eliminar valores anômalos da base de dados e apresentar dados mais confiáveis

para o componente de publicação.

O trabalho que foi proposto em (Zhou et al., 2015) apresenta a aplicação de uma

RSSF que tem por objetivo monitorar a temperatura em ambientes indoor de larga

escala através do controle do suprimento de ar em determinadas zonas do cenário

utilizado. Uma das maneiras de contribuir com este trabalho é utilizar um módulo de

gerenciamento de situações. Isto possibilita ao usuário descrever as regras de

redirecionamento de fluxo de ar de acordo com as suas necessidades.

Tabela 6 – Comparação entre os trabalhos reportados na literatura

Abordagens

Trabalhos

Propostos

Ges

tão

de e

nerg

ia

Trat

amen

to d

e Q

oI

Prot

ocol

os d

e

desc

ober

tas

Trat

amen

to d

e

Situ

açõe

s

Mód

ulo

Pub/

Subs

crib

er

Mon

itora

men

to d

e

Red

e

Ont

olog

ias e

Sem

ântic

a

Sens

ing

as a

Ser

vice

(Bruno et al., 2013) (Khedo et al., 2010)

(Son et al., 2009) (Moraru et al., 2011) (Zhou et al., 2015)

Arquitetura proposta

A Tabela 6 sumariza as abordagens descritas anteriormente. As abordagens dos

trabalhos que foram marcados com um “x” não indicam necessariamente que a proposta

não aborda as questões destacadas, mas que não ficaram claras ou não descreveram os

elementos que tratam destas questões. Além disso, os trabalhos propostos e discutidos

93

nesta seção abordam questões voltadas aos domínios aos quais estão inseridos e,

portanto, tem preocupações relacionadas com a resolução dos problemas apresentados.

7. Considerações Finais

A Internet das Coisas (IoT) é uma realidade latente e caminha no sentido de

tornar os objetos do mundo físico acessíveis de modo transparente e pervasivo,

escondendo as complexidades inerentes ao processo de sensoriamento e trazendo à tona

a simplicidade de se observar os fenômenos que cercam os objetos do mundo real.

Neste sentido, podemos dizer que as RSSF são ferramentas eficazes e centrais desta

realidade, que se encaixam no universo IoT munindo o usuário de informações de

entidades que estão ao seu redor. As RSSF, assim como outros objetos que compõem o

universo de IoT trazem consigo, entretanto, todas as questões complexas inerentes às

tecnologias LoWPAN (Low Power Wireless Sensor Networks), como heterogeneidade,

matriz energética finita, limites restritos de processamento, memória e largura de banda,

dentre outros.

O desenvolvimento de aplicações reais de RSSF em cenários IoT acrescenta

outros desafios e novos requisitos não menos importantes e complexos: QoI,

Situação/Contexto, Semântica, etc. Este cenário abre um campo fértil para pesquisas

que explorem a criação de infraestruturas de apoio ao desenvolvimento de aplicações de

RSSF/IoT com suporte integrado a estes novos requisitos.

Este trabalho apresentou uma proposta de arquitetura conceitual e a sua

implementação, que trata de alguns destes desafios. O desenvolvimento da arquitetura e

a sua implementação tomou como referência um cenário real de monitoramento de uma

cadeia de frios. A solução proposta foi estruturada em camadas, considerando requisitos

de baixo nível, de ordem mais tecnológica até requisitos de mais alto nível, indicados

pelos usuários consumidores. A instanciação da arquitetura no domínio da cadeia de

frios permitiu observar, na prática, a necessidade de infraestruturas de suporte tais como

a desenvolvida nesta dissertação. Comparada com trabalhos similares reportados na

literatura, a abordagem se diferencia delas por apresentar suporte integrado a três

questões apontadas como de extrema relevância na literatura da área, considerando as

novas aplicações de RSSF/IoT: QoI, Sensibilidade de Contexto e Semântica em redes

de Sensores.

94

Além dessas, algumas questões tradicionais também foram tratadas na

arquitetura proposta, como a preocupação com a conservação energética dos nodos

sensores. Por exemplo, a concepção da aplicação embarcada no nodo sensor procurou

poupar os recursos já limitados dos motes. Isto foi possível através da utilização de

testes estatísticos que indicam se o dado tem ou não relevância perante outros dados

lidos no mesmo sensor. Além disso, o algoritmo precisa ser simples de modo a não

utilizar excessivamente recursos como CPU e memória. Neste caso, o algoritmo do teste

de Grubbs consumiu um pouco mais do que 30 linhas de código na linguagem nesC

através de funções simples. Há de se considerar que esta abordagem foi testada em

ambientes não críticos, ou seja, aqueles nos quais um tempo de resposta médio não

compromete os estados das entidades monitoradas. Neste sentido, considera-se como

um trabalho futuro a realização de testes mais elaborados da arquitetura em ambientes

críticos. Além disso, também é preciso avaliar o uso de protocolos que estão sendo

construídos e adotados no mundo IoT, como o já citado protocolo de rede RPL

(6LoWPAN IPv6) e o CoAP (Constrained Application Protocol), um protocolo da

camada de aplicação que adota as mesmas similaridades providas pelo protocolo de

aplicação HTTP, porém com menor overhead.

Ainda que de forma inicial, a proposta deste trabalho seguiu tendências que já

são/estão amplamente em discussão na academia. Exemplo disso é o uso da

conceitualização através da ontologia SSN. Dessa forma, o modelo UML e o

consequente modelo relacional que deu origem à base de dados refletiram, em maior ou

menor nível de detalhes, questões relacionadas aos sensores, como suas propriedades e

capacidades. Dado a natureza complexa dos diversos domínios aos quais as RSSF se

relacionam, faz-se necessário aprimorar e interconectar semanticamente estes conceitos

de modo a tornar os modelos também interpretáveis por máquinas. Além disso, uma vez

que SSN é utilizada como uma core ontology na arquitetura, trabalhos futuros podem

explorar modelos mais expressivos através da exposição de conceitos e relações não

abordados por esta proposta.

Outro aspecto trabalhado nesta proposta está relacionado à qualidade da

informação provida pelos sensores. Trabalhos reportados na literatura apontam que a

nova era da IoT conectará bilhões de dispositivos à Internet e muitos deles serão

providos por datacenters especializados em coletar/negociar/tratar os dados para

consumidores finais. Neste sentido, os dados reportados pelos sensores necessitam de

95

avaliação, uma vez que as leituras são suscetíveis a erros devido à natureza do sensor ou

por outros motivos, como defeitos, etc. Na abordagem proposta, estes testes foram

realizados levando em consideração um subset de dados previamente lidos. Isto

permitiu investigar o quão difere um dado de seu próprio subconjunto. Ainda que

funcional, esta abordagem não realiza comparações com dados lidos de outros sensores

(na mesma entidade, sob as mesmas condições). Neste caso, estabelecer relações entre

dados de sensores diferentes sob as mesmas condições se apresenta como uma proposta

de trabalho futuro. Além disso, questões como reputação dos sensores podem ser

abordadas em novos trabalhos, informando ao usuário consumidor qual o grau de

confiança que determinado sensor possui.

Caracterizar os estados de uma entidade também foi uma das abordagens deste

trabalho. Isto permitiu estabelecer limiares das entidades monitoradas e acompanhar os

seus ciclos de trabalho na linha do tempo. Consideramos que o cenário utilizado, apesar

de limitadas situações de contexto, ainda pode ser explorado através da adição de novos

componentes e novos sensores que, inter-relacionados, podem produzir novos fatos e,

com isso, caracterizar de forma mais precisa os estados atuais nas quais uma entidade

pode estar. Por exemplo, no cenário abordado apenas os dados das temperaturas das

unidades de armazenamento foram capturados. Estes dados refletem os fatos que

alimentam a máquina de regras Drools já discutida nesta proposta. Posicionar novos

sensores em locais estratégicos das entidades, p. ex., nas unidades de evaporação, nos

condensadores, nos ventiladores e nos motores podem fornecer novos fatos sobre a

entidade monitorada e, portanto, podem constituir novos cenários de situações/contexto.

Algumas questões transversais, como segurança e privacidade não foram

exploradas neste trabalho, o que abre espaço para investigações adicionais nestas linhas

de pesquisa. Do mesmo modo, a composição de serviços e sua integração com o nível

de processos de negócios também constituem fontes interessantes de trabalhos futuros,

que podem usar a infraestrutura aqui desenvolvida como ponto de partida para a

concepção de novos componentes e novas funcionalidades na arquitetura proposta.

Por último, a experiência deste trabalho nos leva a acreditar que a arquitetura

proposta pode se adequar em outros domínios de interesse, p. ex., na agricultura de

precisão, na qual as escolhas conceituais e tecnológicas podem ser testadas e avaliadas

utilizando novas classes de aplicações.

96

8. Referências

ABID, A.; KACHOURI, A.; MAHFOUDHI, A. Anomaly Detection in WSN : critical study with new vision. International Conference on Automation, Control, Engineering and Computer Science (ACECS’14) Proceedings, p. 1–9, 2014.

AKYILDIZ, I. F. et al. Wireless sensor networks: a survey. Computer Networks, v. 38, n. 4, p. 393–422, mar. 2002.

AKYILDIZ, I. F.; VURAN, M. C. Wireless Sensor Networks. Chichester, UK: John Wiley & Sons, Ltd, 2010.

AMIDI, A.; HAMM, N. A. S.; MERATNIA, N. Wireless sensor networks and fusion of contextual information for weather outlier detection. International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences - ISPRS Archives, v. 40, n. 1W3, p. 37–41, 2013.

ATZORI, L.; IERA, A.; MORABITO, G. The Internet of Things: A survey. Computer Networks, v. 54, n. 15, p. 2787–2805, 2010.

BAILLIE, C.; EDWARDS, P.; PIGNOTTI, E. Quality reasoning in the semantic web. The Semantic Web – ISWC 2012, v. 7650, p. 383–390, 2012.

BALI, M. Drools JBoss Rules 5. X Developer’s Guide. Birmingham: Packt Publishing Ltd, 2013.

BARNAGHI, P. et al. Semantics for the Internet of Things. International Journal on Semantic Web and Information Systems, v. 8, n. 1, p. 1–21, 2012.

BHUYAN, B. et al. A Survey on Middleware for Wireless Sensor Networks. Journal of Wireless Networking and Communications 2014, v. 4, n. 1, p. 7–17, 2014.

BIMSCHAS, D. et al. Semantic-Service Provisioning for the Internet of Things. Electronic Communications of the EASST, v. 37, p. 1–12, 2011.

BISDIKIAN, C. et al. A letter soup for the quality of information in sensor networks. IEEE Information Quality and Quality of Service (IQ2S) Workshop (in IEEE PerCom’09), p. 1–6, 2009.

BISDIKIAN, C.; KAPLAN, L. M.; SRIVASTAVA, M. B. On the quality and value of information in sensor networks. ACM Transactions on Sensor Networks (TOSN), v. 9, n. 4, p. 1–26, 2013.

BONINO, D. et al. ALMANAC: Internet of Things for Smart Cities2015 3rd International Conference on Future Internet of Things and Cloud. Anais...IEEE, ago. 2015Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber= 7300833>

BRUNO, G. et al. Infraestrutura de Redes de Sensores Sem fio para Monitoramento Térmico de CPDsSimpósio Brasileiro de Engenharia de Sistemas Computacionais,Nitetói, 2013. Disponível em: <http://sbesc.lisha.ufsc.br/sbesc2013 /Anais>

BRUNO, G. Z. Sistema para Monitoramento Termoenergético de CPDs. [s.l.]

97

Universidade Federal Fluminense, 2013.

CASATI, F. et al. Towards business processes orchestrating the physical enterprise with wireless sensor networks BT - 34th International Conference on Software Engineering, ICSE 2012, June 2, 2012 - June 9, 2012. p. 1357–1360, 2012.

CHAWLA, B. et al. Performance Analysis of Collection Tree Protocol in Mobile Environment. International Journal of Engineering Research and Applications, v. 3, n. 3, p. 798–804, 2013.

CHRISTENSEN, E. et al. Web Services Description Language (WSDL) 1.1. W3C, n. March 2001, p. 1–28, 2009.

CHU, D. et al. The design and implementation of a declarative sensor network system. SenSys, p. 175, 2007.

COMPTON, M. et al. The SSN Ontology of the W3C Semantic Sensor Network Incubator Group. Journal of Web Semantics, v. 17, p. 25–32, 2012.

COSTA, P.; ALMEIDA, J. P. A.; PIRES, L. Towards conceptual foundations for context-aware applications. Proc 3rd Int WS Model Retriev Context, 2006.

CROSSBOW. MTS/MDA Sensor Board Users Manual, 2007. Disponível em: <www.xbow.com>

DELICATO, F. et al. Middleware Orientado a Serviços para Redes de Sensores sem Fio. Ufrj, 2004.

DESAI, P.; SHETH, A.; ANANTHARAM, P. Semantic Gateway as a Service Architecture for IoT Interoperability. IEEE International Conference on Mobile Services. Jun, 2015. Disponível em: <http://arxiv.org/abs/1410.4977>

DEY, A. K. Understanding and using context. Personal and Ubiquitous Computing, v. 5, n. 1, p. 4–7, 2001.

DINH, N.-T. RESTful Architecture of Wireless Sensor Network for Building Management System. KSII Transactions on Internet and Information Systems, v. 6, n. 1, p. 46–63, 2012.

DISTEFANO, S.; MERLINO, G.; PULIAFITO, A. Sensing and actuation as a service: A new development for clouds. Proceedings - IEEE 11th International Symposium on Network Computing and Applications, NCA 2012, v. 1, p. 272–275, 2012.

DOCKHORN COSTA, P. et al. Situation Specification and Realization in Rule-Based Context-Aware Applications. In: [s.l: s.n.]. p. 32–47.

ERL, T. SOA: Princípios do Design de Serviço. [s.l.] Pearson Prentice Hall, 2009.

FALBO, R. D. A. et al. Organizing Ontology Design Patterns as Ontology. 10th International Conference, ESWC 2013, p. 61–75, 2013.

FAWZY, A.; MOKHTAR, H. M. O.; HEGAZY, O. Outliers Detection and Classification in Wireless Sensor Networks. Egyptian Informatics Journal, v. 14, n. 2, p. 157–164, 2013.

98

FILHO, J. DE M. Uma Arquitetura Multiagentes para Sistema Educacional Uma Arquitetura Multiagentes para Sistema Educacional. [s.l.] Universidade Estadual Paulista, 2011.

FORGY, C. Rete: A Fast Algorithm for the Many Patterns/Many Objects Match Problem. Artificial Intelligence, v. 19, n. 1982, p. 17–37, 1982.

FRANÇA, T. C. DE et al. Web das Coisas: Conectando Dispositivos Físicos ao Mundo Digital. Livro Texto de Minicursos - SBRC 2011, p. 48, 2011.

FRIEDMAN-HILL, E. Under the hood: how Jess works. [s.l: s.n.].

GANZ, F. et al. Context-aware management for sensor networks. Proc of the Fifth International Conference on COMmunication System softWAre and middlewaRE COMSWARE11, p. 1–6, 2011.

GAY, D. et al. The nesC language: A holistic Approach to Tetworked Embedded Systems. Proceedings of the ACM SIGPLAN 2003 conference on Programming language design and implementation - PLDI ’03, p. 1, 2003.

GAY, D.; LEVIS, P.; CULLER, D. Software design patterns for TinyOS. ACM SIGPLAN Notices, v. 40, n. 7, p. 40, 2005.

GIL, P.; SANTOS, A.; CARDOSO, A. Dealing with outliers in wireless sensor networks: An oil refinery application. IEEE Transactions on Control Systems Technology, v. 22, n. 4, p. 1589–1596, 2014.

GRUBER, T. R. A translation approach to portable ontology specifications. Knowledge Acquisition, v. 5, n. 2, p. 199–220, 1993.

GUARINO, N. Formal Ontology and Information Systems. Proceedings of the first international conference, v. 46, n. June, p. 3–15, 1998.

GUBBI, J. et al. Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems, v. 29, n. 7, p. 1645–1660, 2013.

GUINARD, D. et al. Interacting with the SOA-based internet of things: Discovery, query, selection, and on-demand provisioning of web services. IEEE Transactions on Services Computing, v. 3, n. 3, p. 223–235, 2010.

GUIZZARDI, G. On Ontology, ontologies, Conceptualizations, Modeling Languages, and (Meta)Models. [s.l: s.n.]. v. 155

GUO, H. et al. A Flexible Framework for Assessing the Quality of Information in Wireless Sensor Networks. International Journal of Distributed Sensor Networks, v. 2015, p. 1–15, 2015.

HAYES-ROTH, F. Rule-based systems. Magazine Communications of the ACM, v. 28, n. 9, p. 921–932, 1985.

HENSON, C. A. et al. SemSOS: Semantic sensor observation service. 2009 International Symposium on Collaborative Technologies and Systems, CTS 2009, p. 44–53, 2009.

HOSSAIN, M. A.; ATREY, P. K.; SADDIK, A. EL. Context-aware QoI computation

99

in multi-sensor systems, 2008. 5th IEEE International Conference on Mobile Ad Hoc and Sensor Systems. Anais. IEEE, Set. 2008. Disponível em: <http://ieeexplore.ieee.org/stampPDF/getPDF.jsp?tp=&arnumber=4660120>

HUI, J.; CULLER, D.; CHAKRABARTI, S. 6LoWPAN Network Architecture. Architecture, p. 1–17, 2009.

JARDAK, C.; WALEWSKI, J. W.; GANZ, C. Enabling Things to Talk. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.

KEFALAKIS, N. et al. D4.3.1 Core OpenIoT Middleware Platform. 2013.

KHEDO, K. K. et al. A Wireless Sensor Network Air Pollution Monitoring System. Science, v. 2, n. 2, p. 15, 2010.

KO, J. et al. Evaluating the Performance of RPL and 6LoWPAN in TinyOS. Ip+SN 2011, 2011.

KOBIALKA, T.; BUYYA, R.; DENG, P. Sensor web: Integration of sensor networks with web and cyber infrastructure. Information Science Reference, 2010.

KOLOZALI, S. et al. A Knowledge-Based Approach for Real-Time IoT Data Stream Annotation and Processing. Internet of Things (iThings), 2014 IEEE International Conference on, and Green Computing and Communications (GreenCom), IEEE and Cyber, Physical and Social Computing(CPSCom), IEEE, p. 215–222, 2014.

KREEGAR, J. et al. OnWorld. Disponível em: <http://www.onworld.com/>.

KRIEGEL, H.; KRÖGER, P.; ZIMEK, A. Outlier Detection Techniques for Wireless Sensor Networks: A Survey. IEEE Communications Surveys, v. 12, n. 2, p. 159–170, 2010.

KYUSAKOV, R. Towards Application of Service Oriented Architecture in Wireless Sensor Networks. [s.l.] Universidade de Tecnologia Luela, Suécia, 2012.

LANKHORST, M. Enterprise Architecture at Work. [s.l: s.n.]. v. 10

LEVINE, D. M. Estatística: teoria e aplicações. 5a. ed. Rio de Janeiro: LTC, 2008.

LI, B. A Generic Data Fusion and Aggregation Framework for Wireless Sensor Networks. [s.l.] Aalto University, 2010.

LIMA, M. A. D. S. Sistema para Análise de Dados de Nodos Sensores. [s.l.] Universidade do Estado do Rio Grande do Norte, 2014.

LOUREIRO, A. A. F. et al. Redes de Sensores Sem Fio. XXI Simpósio Brasileiro de Redes de Computadores, p. 179–226, 2003.

LUCATO, M. U.; COUTO, P. R. G.; LUZ, D. Proposta para o estabelecimento da confiabilidade metrológica em calibração volumétrica. V Congresso Latino Americano de Metrologia, v. 2, n. 1, p. 2–5, 2007.

LUO, T.; TAN, H. P.; QUEK, T. Q. S. Sensor openflow: Enabling software-defined wireless sensor networks. IEEE Communications Letters, v. 16, n. 11, p. 1896–1899, 2012.

100

MALATRAS, A.; ASGARI, A. H.; BAUGÉ, T. Web Enabled Wireless Sensor Networks for Facilities Management. IEEE SYSTEMS JOURNAL, v. 2, n. 4, p. 500–512, 2008.

MASHAL, I. et al. Choices for interaction with things on Internet and underlying issues. Ad Hoc Networks, v. 28, p. 68–90, 2015.

MCDONALD, D. et al. A Survey of Methods for Finding Outliers in Wireless Sensor Networks. Journal of Network and Systems Management, v. 23, n. 1, p. 163–182, 2013.

MEMSIC. Mote Processor Radio & Mote Interface Boards User Manual, 2010. Disponível em: <www.memsic.com>

MEYER, S.; RUPPEN, A.; MAGERKURTH, C. Internet of Things-Aware Process Modeling: Integrating IoT Devices as Business Process Resources. In: Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). [s.l: s.n.]. v. 7908 LNCSp. 84–98.

MEYER, S.; SPERNER, K.; MAGERKURTH, C. Towards Real World Aware Enterprise Systems - Reflecting the Quality Information of Physical Resources in Services and Processes. 2011. IEEE 8th International Conference on Mobile Adhoc and Sensor Systems (MASS), p. 843–848, 2011.

MIORANDI, D. et al. Internet of things: Vision, applications and research challenges. Ad Hoc Networks, v. 10, n. 7, p. 1497–1516, 2012.

MITTON, N. et al. Combining Cloud and sensors in a smart city environment. EURASIP Journal on Wireless Communications and Networking, v. 2012, n. 1, p. 247, 2012.

MORARU, A. et al. Exposing real world information for the web of things. Proceedings of the 8th International Workshop on Information Integration on the Web in conjunction with WWW 2011 - IIWeb ’11. Anais...New York, New York, USA: ACM Press, 2011. Disponível em: <http://eprints.pascal-network.org/archive/ 00008715/>

MOSS, D.; LEVIS, P. BoX-MACs : Exploiting Physical and Link Layer Boundaries in Low-Power Networking. Design, p. 1–12, 2008.

NAKAMURA, L. H. V. Utilização de Web Semântica para Seleção de Informações de Web Services no registro UDDI: uma abordagem com qualidade de serviço. [s.l.] Universidade de São Paulo - USP, 2012.

NETO, B. DE B. Como fazer experimentos: Aplicações na Ciência e na Indústria. 4a Edição ed. Porto Alegre: [s.n.].

NISHA, U. B. et al. Statistical Based Outlier Detection in Data Aggregation for Wireless Sensor Networks. Journal of Theoretical and Applied Information Technology, v. 59, n. 3, p. 770–780, 2014.

OLIVEIRA, E. C. DE. Comparação das diferentes técnicas para a exclusão de “outliers”. Metrologia, 2008.

101

PATEL, P. et al. Towards Application Development for the Internet of Things. Proceedings of the 8th Middleware Doctoral Symposium, p. 5:1–5:6, 2011.

PEREIRA, I. S. A.; COSTA, P. D.; ALMEIDA, J. P. A. A Rule-Based Platform for Situation Management. 2013 IEEE International Multi-Disciplinary Conference on Cognitive Methods in Situation Awareness and Decision Support, CogSIMA 2013, p. 83–90, 2013.

PERERA, C. et al. CA4IOT: Context awareness for Internet of Things. Proceedings - 2012 IEEE Int. Conf. on Green Computing and Communications, GreenCom 2012, Conf. on Internet of Things, iThings 2012 and Conf. on Cyber, Physical and Social Computing, CPSCom 2012, p. 775–782, 2012.

___. Context-aware sensor search, selection and ranking model for internet of things middleware. Proceedings - IEEE International Conference on Mobile Data Management, v. 1, p. 314–322, 2013.

PERERA, C. et al. Sensor Search Techniques for Sensing as a Service Architecture for the Internet of Things. Sensors Journal, IEEE, v. 14, n. 2, p. 406–420, 2014.

PIRES, P. F. et al. Plataformas para a Internet das Coisas. Anais do Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, p. 110–169, 2015.

PRESSER, M. et al. The SENSEI project: integrating the physical world with the digital world of the network of the future - [global communications newsletter]. IEEE Communications Magazine, n. April, p. 1–4, 2008.

PRIYANTHA, B. et al. Tiny Web Services for Sensor Device InteroperabilityInternational Conference on Information Processing in Sensor Networks. Anais...New York, New York, USA: IEEE, abr. 2008. Disponível em: <http://dl.acm.org/citation.cfm?id=1460438>

REDDY, A. J.; MORARJEE, K. A Survey on Semantic Sensor Techniques. v. 24, n. 2, p. 89–91, 2015.

RODRIGUES, P. et al. Conservação de Produtos Refrigerados e Congelados Expostos para a venda em Supermercados da Cidade de Palmas-TO. Journal of Bioenergy and Food Science, v. 1, n. 2, p. 27–31, 2014.

RODRÍGUEZ, S. et al. Multi-agent information fusion system to manage data from a WSN in a residential home. Information Fusion, v. 23, p. 43–57, 2015.

RUIZ, L. B. et al. Arquiteturas para Redes de Sensores Sem Fio. In: Mini-cursos do XXII Simpósio Brasileiro de Redes de Computadores. Gramado/RS: [s.n.]. p. 167–218.

SACHIDANANDA, V. et al. Quality of Information in Wireless Sensor Networks : A Survey. Proceedings of the 15th International Conference on Information Quality (ICIQ-2010), v. 1, p. 1–15, 2010.

SCHERP, A. et al. Designing Beautiful Core Ontologies. Applied Ontology, v. 3, p. 1–3, 2009.

SERRANO, M. et al. Open services for IoT cloud applications in the future internet.

102

2013 IEEE 14th International Symposium on a World of Wireless, Mobile and Multimedia Networks, WoWMoM 2013, 2013.

___. Defining the Stack for Service Delivery Models and Interoperability in the Internet of Things: A Practical Case With OpenIoT-VDK. IEEE Journal on Selected Areas in Communications, v. 33, n. 4, p. 676–689, 2015.

SHAIK, A.; ESWARAN, P. Removal of IEEE 802 . 15 . 4 MAC Unrelaibility Problem in Hardware Superframe structure. International Journal of Advanced Computer Research, v. 2, n. 4, 2012.

SILVA, E. G. DA; PIRES, L. F.; SINDEREN, M. VAN. A-DynamiCoS: A Flexible Framework for User-centric Service Composition2012 IEEE 16th International Enterprise Distributed Object Computing Conference. Anais...IEEE, set. 2012Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber= 6337239>

SON, V. Q. et al. A Model of Wireless Sensor Networks using Context- Awareness in Logistic Applications. Intelligent Transport Systems Telecommunications, (ITST), 2009. 9th International Conference on, p. 2–7, 2009.

SOUZA, S. C. DE. Uma abordagem baseada em regras e computação em nuvem para desenvolvimento de aplicações em redes de sensores sem fio. [s.l.] Universidade Federal do Espírito Santo, 2013.

SOUZA, S. C. DE; FILHO, J. G. P.; SPESSIMILLE, E. F. A Rule-Base Approach for WSN Application Development in a Cloud Environment. Journal of Advances in Computer Networks, v. 1, n. 4, p. 306–309, 2014.

SPIESS, P. et al. SOA-Based Integration of the Internet of Things in Enterprise Services2009 IEEE International Conference on Web Services. Anais...IEEE, jul. 2009Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber= 5175920>

SU, L. Resource Efficient Information Integration In Cyber-Physical Systems. [s.l.] Universidade de Illinois, Urbana-Champaingn, 2013.

SUBRAMANIAM, S. et al. Online outlier detection in sensor data using non-parametric models. VLDB ’06: Proceedings of the 32nd international conference on Very large data bases, p. 187–198, 2006.

TERFLOTH, K.; WITTENBURG, G.; SCHILLER, J. FACTS – A Rule-based Middleware Architecture for Wireless Sensor Networks. 2006 1st International Conference on Communication Systems Software & Middleware, p. 1–8, 2006.

TOSE, T. et al. Redes de sensores sem fio zigbee aplicada em uma estação de tratamento de esgotoAnais do XIX Congresso Brasileiro de Automática. Anais...2012

UNDERWOOD, M. et al. Internet of things: Toward smart networked systems and societies. Applied Ontology, v. 10, n. 3-4, p. 355–365, 2015.

W3C SEMANTIC SENSOR NETWORK INCUBATOR. Semantic Sensor Network Ontology. Disponível em: <http://purl.oclc.org/NET/ssnx/ssn>. Acesso em: 21 fev. 2016.

103

YICK, J.; MUKHERJEE, B.; GHOSAL, D. Wireless sensor network survey. Computer Networks, v. 52, n. 12, p. 2292–2330, 2008.

ZHANG, W.; HANSEN, K. M. Semantic web based self-management for a pervasive service middleware. Proceedings - 2nd IEEE International Conference on Self-Adaptive and Self-Organizing Systems, SASO 2008, p. 245–254, 2008.

ZHOU, P. et al. Wireless sensor network based monitoring system for a large-scale indoor space: Data process and supply air allocation optimization. Energy and Buildings, v. 103, p. 365–374, 2015.

104

Apêndice A

Protótipo para Sensoriamento Térmico de Câmaras Frigoríficas utilizando Redes

de Sensores Sem Fio

Muitas soluções para sensoriamento térmico em ambientes de baixa temperatura (ou

negativos) disponíveis no mercado utilizam sensores com fio ou são de arquitetura

fechada e exclusiva. Utilizar sensores com fio tem algumas desvantagens e, muitas

vezes, sua instalação não é possível por causa da infraestrutura disponível no local.

Outra questão é a alimentação normalmente utilizada nos dispositivos com fio: a queda

de energia causa falha de leitura por parte dos sensores. O uso de uma arquitetura

fechada, tanto no software de sensoriamento quanto no software coletor de dados,

também é uma característica negativa, além de possuir maior custo de aquisição e

manutenção.

Este relatório mostra o uso de uma RSSF que utiliza como base motes amplamente

conhecidos, como o modelo IRIS da fabricante MEMSIC, além de suas interfaces de

sensoriamento de temperatura, como o MDA100cb. Além disso, o software embarcado

no protótipo utiliza como base o TinyOS, um Sistema Operacional open source

desenhado para dispositivos wireless de baixo consumo, como as RSSF.

Protótipo e os protocolos embarcados

O Collection Tree Protocol é um dos protocolos coletores de dados mais promissores

em redes de sensores estáticos. Com isso, o protocolo selecionado para o protótipo é o

Collection Tree Protocol (CTP), um protocolo do tipo vetor-distância que calcula as

rotas de cada nó até o nó raiz.

A habilitação do protocolo CTP acontece com o uso de um Coletor e das interfaces

básicas, como ctpinfo e ctpcongestion, dentro do módulo da aplicação embarcada. Além

disso, deve-se incluir o cabeçalho do protocolo CTP dentro da configuração da

aplicação, ambos utilizando como base o sistema operacional TinyOS v2.1.1.

Na camada de enlace é utilizado o protocolo Box-MAC-1, que é uma variação do

protocolo B-MAC. O Box-MAC1 utiliza um mecanismo que desativa o rádio dos nós

quando os mesmos não são usados, economizando energia das baterias. Este mecanismo

é ativado através de flags do tipo Low Power Listening (LPL), quando a aplicação é

105

compilada e embarcada nos motes.

Aplicação embarcada

Em câmaras frigoríficas uma falha de refrigeração não é crítica em curto prazo. Com

isso, a aplicação de coleta e transmissão de dados pode ser configurada para um

intervalo de transmissão maior ao enviar informações sobre a temperatura e enviar

dados sensoriados utilizando um método estatístico que avalie a relevância do dado para

a aplicação. A ideia é que esta abordagem economize a matriz energética dos nodos

sensores.

A conversão do valor lido pelo sensor (raw data) é feita por uma função da aplicação.

Estes valores são diferentes dos apresentados no manual do sensorboard MDA100cb,

pois o termistor utilizado é diferente, uma vez que um novo protótipo de sensoriamento

é utilizado para aferir a temperatura.

A aplicação é composta por Módulos e Configurações conforme o paradigma da

linguagem nesC. Os módulos são os componentes implementados com código nesC. As

configurações são componentes implementados através da ligação dos componentes uns

aos outros. Os Módulos e Configurações possuem um nome, especificação e

implementação. Abaixo estão os códigos da aplicação que foram escritos e embarcados

nos nodos sensores.

Arquivo <lendoTempAppC.nc> Configuração da Aplicação Embarcada

/** * @author Allan F. F. Amaral <[email protected]> * @author Matheus O. Jagi <[email protected]> * @date January 29th, 2016 */ #include "lendoTemp.h" #include "Ctp.h" configuration lendoTempAppC {} implementation { components MainC, LedsC, lendoTempC, ActiveMessageC; components new TimerMilliC(); components CollectionC as Collector; components new CollectionSenderC(AM_TMON); components new SerialAMSenderC(AM_TMON); components SerialActiveMessageC; components new TempC() as TempSource_MDA100; components new TempSensor2C() as TempPrototipoAnalaogico_MDA100; lendoTempC.TempSourceMDA100 -> TempSource_MDA100; lendoTempC.TempPrototipoAnalogicoMDA100 ->

106

TempPrototipoAnalaogico_MDA100; components new VoltageC() as SensorVolt; lendoTempC.Volt -> SensorVolt; components new QueueC(message_t *, 10); components new PoolC(message_t, 10); lendoTempC.Boot -> MainC.Boot; lendoTempC.Leds -> LedsC.Leds; lendoTempC.Timer -> TimerMilliC; lendoTempC.Radio -> ActiveMessageC; lendoTempC.Serial -> SerialActiveMessageC; lendoTempC.Roteador -> Collector; lendoTempC.Send -> CollectionSenderC; lendoTempC.UARTSend -> SerialAMSenderC.AMSend; lendoTempC.Receive -> Collector.Receive[AM_TMON]; lendoTempC.RootControl -> Collector; lendoTempC.Pool -> PoolC; lendoTempC.Queue -> QueueC; lendoTempC.CollectionPacket -> Collector; lendoTempC.CtpInfo -> Collector; lendoTempC.CtpCongestion -> Collector; lendoTempC.LowPowerListening -> ActiveMessageC; components TimeSyncMessageC; components TimeSyncC; MainC.SoftwareInit -> TimeSyncC; TimeSyncC.Boot -> MainC; lendoTempC.TimeSyncPacket -> TimeSyncMessageC; lendoTempC.PacketTimeStamp -> ActiveMessageC; lendoTempC.GlobalTime -> TimeSyncC; lendoTempC.TimeSyncInfo -> TimeSyncC; }

Arquivo <lendoTempC.nc> Módulos da Aplicação Embarcada

/** /** * @author Allan F. F. Amaral <[email protected]> * @author Matheus O. Jagi <[email protected]> * @date January 29th, 2016 */ #include "Timer.h" #include "lendoTemp.h" #include "math.h" module lendoTempC { uses { interface Boot; interface Leds; interface Timer<TMilli>; interface Read<uint16_t> as TempSourceMDA100; interface Read<uint16_t> as TempPrototipoAnalogicoMDA100; interface Read<uint16_t> as Volt; interface SplitControl as Radio; interface SplitControl as Serial; interface StdControl as Roteador; interface Send; interface Receive; interface CollectionPacket; interface CtpInfo; interface CtpCongestion; interface AMSend as UARTSend;

107

interface RootControl; interface Queue<message_t*>; interface Pool<message_t>; interface LowPowerListening; interface GlobalTime<TMilli>; interface TimeSyncInfo; interface PacketTimeStamp<TMilli,uint32_t>; interface TimeSyncPacket<TMilli,uint32_t>; } } implementation { task void uartSendTask(); static float adc_to_celsius(uint16_t adc); static void startTimer(uint32_t interval); static float converte_MDA100(uint16_t adc); lendotemp_t local; uint8_t uartlen; message_t sendbuf; message_t uartbuf; bool sendBusy = FALSE; bool uartBusy = FALSE; float lendoTemperaturaMDA100_prototipoAnalogico[readings]; uint16_t cont = 0, inicio = 0; uint16_t etxNow = 0; uint16_t lastEtx = 0; static float adc_to_celsius(uint16_t adc) { long resistance; double TempK, TempK1; //TempC resistance=((10240000/(float)adc) - 10000); TempK = log(resistance); TempK1 = 1 / (0.001129148 + (0.000234125 * TempK) + (0.0000000876741 * TempK * TempK * TempK)); //TempC = TempK - 273.15; // Convert Kelvin to Celsius return (float)(TempK1 - 273.15); } static float converte_MDA100(uint16_t adc) { double a = 0.001010024, b = 0.000242127, c = 0.000000146; double rthr = (10000*(1023-(float)adc))/(float)adc; double tempc = 1.0/(a + b*log(rthr) + c*pow(log(rthr),3)) - 273; return (float)tempc; } //Liga os leds dependendo das situações void report_problem(){ call Leds.led0Toggle(); } void report_send(){ call Leds.led1Toggle(); } void report_receive(){ call Leds.led2Toggle(); } void fatal_problem(){ call Leds.led0On(); call Leds.led1On(); call Leds.led2On(); } // Função estatística baseada no Teste de Grubbs void outlier(float vetor[]){ uint16_t i, j; float avg, soma=0.0f, somadesv=0.0f, desvp=0.0f, grubbs=0.0f; for(i=0;i<readings;i++){ soma+=vetor[i]; } avg = (float)(soma/(float)readings); for(j=0;j<readings;j++){ somadesv+= (float)(pow((vetor[j]-avg),2)); } desvp = (float)(sqrt(somadesv/(float)readings)); if(desvp!=0.0f) {

108

grubbs = (float)((fabs(vetor[readings-1]-avg))/desvp); if(grubbs > indice){ local.lendoTemperaturaMDA100_prototipoAnalogico = vetor[readings-1]; if(!sendBusy) { lendotemp_t *pckt = (lendotemp_t *)call Send.getPayload(&sendbuf, sizeof(lendotemp_t)); if (pckt == NULL) { fatal_problem(); return; } memcpy(pckt, &local, sizeof(local)); if (call Send.send(&sendbuf, sizeof(local)) == SUCCESS) { sendBusy = TRUE; call Leds.led2Toggle(); } else { report_problem(); } } } } } event void Boot.booted() { local.source = TOS_NODE_ID; if(call Serial.start() != SUCCESS) fatal_problem(); } event void Serial.startDone(error_t error) { if (error != SUCCESS) { fatal_problem(); } if (TOS_NODE_ID % 500 == 0) { call LowPowerListening.setLocalWakeupInterval(0); } else { call LowPowerListening.setLocalWakeupInterval(LPL_INTERVAL); } call Radio.start(); } event void Radio.startDone(error_t error) //Começa a transmissão do rádio { if (error != SUCCESS) { fatal_problem(); } else { call Roteador.start(); if (local.source % 500 == 0) { call RootControl.setRoot();

109

} else { startTimer(SAMPLE_INTERVAL); } } if (sizeof(local) > call Send.maxPayloadLength()) { fatal_problem(); } } static void startTimer(uint32_t intervalo) { if(call Timer.isRunning()) { call Timer.stop(); } call Timer.startPeriodic(intervalo); //Começa o timer } event void Radio.stopDone(error_t error){} event void Serial.stopDone(error_t error){} //Somente o nó raiz irá receber os pacotes event message_t * Receive.receive(message_t *msg, void *payload, uint8_t len) //Recebe a mensagem { lendotemp_t* in = (lendotemp_t*)payload; //Pacote entrando lendotemp_t* out; //Pacote de saída if(uartBusy == FALSE) { out = (lendotemp_t*)call UARTSend.getPayload(&uartbuf, sizeof(lendotemp_t)); if (len != sizeof(lendotemp_t) || out == NULL) { return msg; } else { memcpy(out, in, sizeof(lendotemp_t)); } uartlen = sizeof(lendotemp_t); post uartSendTask(); } else //Está ocupado. Forma fila para atendê-lo quando estiver livre { message_t *newmsg = call Pool.get(); if (newmsg == NULL) //Descarta a mensagem se não tiver mais espaço na fila. { report_problem(); return msg; } //Porta ocupada, enfilera as mensagens out = (lendotemp_t*)call UARTSend.getPayload(newmsg, sizeof(lendotemp_t)); if (out == NULL) { return msg; } memcpy(out, in, sizeof(lendotemp_t)); if (call Queue.enqueue(newmsg) != SUCCESS) //Descarta a mensagem e trava se a fila ficar sem espaço { call Pool.put(newmsg);

110

fatal_problem(); return msg; } } return msg; } task void uartSendTask() { if(call UARTSend.send(0xffff, &uartbuf, uartlen) != SUCCESS) //Se o paocte não for enviado, reporta o problema { report_problem(); } else { uartBusy = TRUE; } } event void UARTSend.sendDone(message_t* msg, error_t error) { uartBusy = FALSE; if(call Queue.empty() == FALSE) //Fila vazia, pronto para novo envio { message_t *queuemsg = call Queue.dequeue(); if (queuemsg == NULL) { fatal_problem(); return; } memcpy(&uartbuf, queuemsg, sizeof(message_t)); if (call Pool.put(queuemsg) != SUCCESS) { fatal_problem(); return; } post uartSendTask(); } } event void Timer.fired() { am_addr_t parent = 0; call TempSourceMDA100.read(); call TempPrototipoAnalogicoMDA100.read(); //Leitura da temperatura do protótipo local.idLendoTemperaturaMDA100 = IDSENSORTEMP; local.idLendoTemperaturaMDA100_prototipoAnalogico = IDSENSORTEMPPROTOTIPO; if(call Volt.read() != SUCCESS) //Leitura da voltagem report_problem(); call CtpInfo.getParent(&parent); local.parent = parent; call CtpInfo.getEtx(&etxNow); local.rssi = etxNow; } event void Send.sendDone(message_t *msg, error_t error) { if(error == SUCCESS){ report_send(); } else{ report_problem(); }

111

sendBusy = FALSE; } //======================[Sensing MDA100]====================================== event void TempSourceMDA100.readDone(error_t result, uint16_t data) { if(result != SUCCESS) { data = 0xffff; call Leds.led1Toggle(); } local.lendoTemperaturaMDA100 = data; } event void TempPrototipoAnalogicoMDA100.readDone(error_t result, uint16_t data) { uint16_t a; if(result != SUCCESS) { data = 0xffff; call Leds.led1Toggle(); } call Leds.led2Toggle(); if(inicio == 0) { lendoTemperaturaMDA100_prototipoAnalogico[cont] = adc_to_celsius(data); } else { for(a=0;a<readings-1;a++){ lendoTemperaturaMDA100_prototipoAnalogico[a] = lendoTemperaturaMDA100_prototipoAnalogico[a+1]; } lendoTemperaturaMDA100_prototipoAnalogico[readings-1] = adc_to_celsius(data); outlier(lendoTemperaturaMDA100_prototipoAnalogico); } cont++; if(cont > readings-1) { call Leds.led0Toggle(); inicio = 1; cont = 0; } } //===================[Sensing Battery Level]===================================== event void Volt.readDone(error_t result, uint16_t data_volt) { if(result != SUCCESS) { data_volt = 0xffff; call Leds.led2Toggle(); } local.lendoVoltagem = data_volt; } }

Protótipo do sensor acoplado ao mote

O sensoriamento em ambientes cuja temperatura é negativa pode trazer problemas para

112

o elemento responsável por coletar, processar e transmitir os dados, que se resume no

mote. Além disso, fatores como umidade podem danificar os motes. Outro detalhe é a

forma de energia utilizada por eles, que usam baterias comuns. A descrição do

funcionamento da maioria das baterias leva em consideração a temperatura ambiente.

Assim, o uso de baterias em ambientes inóspitos como câmaras frigoríficas com

temperaturas negativas podem comprometer a precisão da leitura e também a

degradação das baterias.

Uma das possíveis soluções para este problema é manter o mecanismo de

sensoriamento desacoplado do mote, preservando seu funcionamento na temperatura

ambiente. Uma das características do sensorboard MDA100cb é a existência de uma

breadboard que permite a construção de protótipos utilizando outros sensores. A

breadboard do MDA100cb se conecta a todos os 51 pinos do mote IRIS, sendo possível

utilizar as funções do mote, como os canais de conversão digital-analógica (ADC). Com

isso, é possível construir um componente de sensoriamento externo e conectá-lo com fio

até o mote.

Novo esquema de conexão do protótipo externo

A figura acima apresenta o novo esquema de ligação da breadboard com o componente

de sensoriamento que, neste caso, é o termistor. O termistor e o resistor utilizados são

de prateleira, ou seja, adquirido em lojas de componentes eletrônicos. O termistor tem

precisão de 0,2º C, suficiente para atender a demanda do ambiente monitorado.

O sistema operacional TinyOS é compatível com o MDA100cb e fornece opções para

compilação de código utilizando este sensor. Além disso, é possível alterar a forma de

uso dos canais de acordo com as conexões do breadboard.

113

Protótipo conectado. Em (a) o sensorboard MDA100cb. Em (b) o mote IRIS. Em (c) o

protótipo.

Na figura anterior pode-se observar a existência dos 3 elementos conectados. O

sensorboard MDA100cb está conectado ao mote IRIS (b) através do conector de 51

pinos e também ao protótipo (c) através da breadboard com o qual ele é constituído.

Arquivo < TempImplSensor2P.nc> Configuração do novo sensor

adicionado

/** * @author Kevin Klues <[email protected]> * @date August 20th, 2007 */ /** * Modified by Allan F. F. Amaral <[email protected]> * Modified by Matheus O. Jagi <[email protected]> * @date January 29th, 2016 */ #include "mda100.h" configuration TempImplSensor2P { provides { interface Resource[uint8_t]; interface Read<uint16_t>[uint8_t]; } } implementation { components new SharedAnalogDeviceC(UQ_MDA100_TEMPSENSOR2_RESOURCE, 10); components MicaBusC; components TempSensor2ConfigC as Temp2ConfigC; Resource = SharedAnalogDeviceC; Read = SharedAnalogDeviceC; SharedAnalogDeviceC.AdcConfig -> Temp2ConfigC; SharedAnalogDeviceC.EnablePin -> MicaBusC.PW7; }

Arquivo < TempSensor2ConfigC.nc> Configuração do novo sensor

114

para o canal ADC correto.

/** * @author Kevin Klues <[email protected]> * @date August 20th, 2007 */ /** * Modified by Allan F. F. Amaral <[email protected]> * Modified by Matheus O. Jagi <[email protected]> * @date January 29th, 2016 */ configuration TempSensor2ConfigC { provides interface Atm128AdcConfig; } implementation { components TempSensor2ConfigP; components MicaBusC; Atm128AdcConfig = TempSensor2ConfigP; TempSensor2ConfigP.PhotoTempAdc -> MicaBusC.Adc3; }

Interface e leitura dos dados

O TinyOS fornece algumas ferramentas para facilitar a criação de uma interface,

permitindo a leitura dos dados sensoriados. Uma destas ferramentas é o

SerialForwarder (SF), que permite conexões de redes ou conexões seriais. A grande

vantagem do uso do SF é a multiplexação, ou seja, várias aplicações podem se conectar

a ele e obter os dados desejados ou os dados disponibilizados pela RSSF. Outra

ferramenta é o Message Interface Generator (MIG) para nesC. Com ele, é possível criar

classes Java através da struct (header) do C, disponibilizando os métodos para acesso

aos dados sensoriados.

O gateway utilizado é o modelo MIB600, que utiliza uma interface de rede 10/100 para

conexão com PC ou notebook. Outro tipo de gateway utilizado (e mais comum) é a

MIB520, que utiliza a interface USB.

Como citado anteriormente, o SerialForwarder (SF) é o software responsável por se

conectar ao gateway e obter os dados da estação base. Ele executa no PC e multiplexa

conexões através da porta TCP 9002, permitindo outras aplicações obter dados da

RSSF. Para finalmente coletar e mostrar os dados sensoriados na rede é necessário

construir uma aplicação que faz interface com o SF. Para demonstrar o funcionamento

da RSSF, dois nodos estão se comunicando com uma aplicação que está executando e

lendo os dados da Temperatura, Voltagem do Sensor, a Origem dos dados sensoriados,

115

a Sequência dos pacotes e o Parent (pai) do nó que gerou o dado. A figura seguinte

ilustra o cenário da aplicação conectada ao SF. A aplicação (a) está conectada ao SF (b)

através do localhost na porta 9002. Por sua vez, o SF está conectado ao gateway através

da porta 10002. Com isso, é possível obter os dados lidos da aplicação embarcada. Pela

figura (a) é possível observar a topologia criada pelo protocolo CTP: o nó 4 se conecta

com o nó 6, que por sua vez se conecta com o nó 0 (zero – root).

Em (a) aplicação de leitura dos dados. Em (b) o SerialForwarder, ambos em Java.

O protótipo apresentado tem como objetivo criar uma RSSF e realizar leituras em

ambientes inóspitos no que se refere à temperatura. Isto tem como objetivo manter a

integridade do mote e das suas baterias, que se degradam em condições de baixa

temperatura e alta umidade. Além disso, numa RSSF é necessário manter uma topologia

estável para transmissão de dados com múltiplos saltos. Nos testes em campo, uma

topologia criada com 5 sensores com a aplicação embarcada e o protocolo CTP se

mostrou estável, gerando uma árvore topológica convergente ao nó raiz. Entretanto, a

troca do local dos sensores com a rede ativa causou perda de dados e desconexão de 1

ou mais sensores, dependendo da posição. Conforme descrito anteriormente, o

protótipo construído leva em consideração RSSF com sensores fixos.

116

Anexo I

Tabela do Teste de Grubbs

n 0,1 0,05 0,025 0,01 0,005 3 1,148 1,153 1,154 1,155 1,155 4 1,425 1,462 1,481 1,492 1,496 5 1,602 1,671 1,715 1,749 1,764 6 1,729 1,822 1,887 1,944 1,973 7 1,828 1,938 2,02 2,097 2,139 8 1,909 2,032 2,127 2,221 2,274 9 1,977 2,11 2,215 2,323 2,387

10 2,036 2,176 2,29 2,41 2,482 11 2,088 2,234 2,355 2,484 2,564 12 2,134 2,285 2,412 2,549 2,636 13 2,176 2,331 2,462 2,607 2,699 14 2,213 2,372 2,507 2,658 2,755 15 2,248 2,409 2,548 2,705 2,806 16 2,279 2,443 2,586 2,747 2,852 17 2,309 2,475 2,62 2,785 2,894 18 2,336 2,504 2,652 2,821 2,932 19 2,361 2,531 2,681 2,853 2,968 20 2,385 2,557 2,708 2,884 3,001 21 2,408 2,58 2,734 2,912 3,031 22 2,429 2,603 2,758 2,939 3,06 23 2,449 2,624 2,78 2,963 3,087 24 2,468 2,644 2,802 2,987 3,112 25 2,486 2,663 2,822 3,009 3,135 26 2,503 2,681 2,841 3,029 3,158 27 2,52 2,698 2,859 3,049 3,179 28 2,536 2,714 2,876 3,068 3,199 29 2,551 2,73 2,893 3,086 3,218 30 2,565 2,745 2,908 3,103 3,236 31 2,579 2,76 2,924 3,119 3,253 32 2,592 2,773 2,938 3,135 3,27 33 2,605 2,787 2,952 3,15 3,286 34 2,618 2,799 2,965 3,164 3,301 35 2,63 2,812 2,978 3,178 3,316

117

36 2,641 2,824 2,991 3,191 3,33 37 2,652 2,835 3,003 3,204 3,343 38 2,663 2,846 3,014 3,216 3,356 39 2,674 2,857 3,025 3,228 3,369 40 2,684 2,868 3,036 3,239 3,381 50 2,772 2,957 3,128 3,337 3,482 60 2,841 3,027 3,2 3,411 3,56 70 2,898 3,084 3,258 3,471 3,622 80 2,946 3,132 3,306 3,521 3,673 90 2,987 3,173 3,348 3,563 3,716

100 3,024 3,21 3,384 3,6 3,754 110 3,056 3,242 3,416 3,633 3,787 120 3,086 3,271 3,445 3,662 3,817 130 3,112 3,297 3,471 3,688 3,843 140 3,136 3,321 3,495 3,712 3,867

Documents

Uma Proposta de Arquitetura de Redes de Sensores sem Fio ... · Allan Francisco Forzza Amaral Uma Proposta de Arquitetura de Redes de Sensores sem Fio Aplicada ao Monitoramento Térmico