uma proposta de arquitetura de redes de sensores sem fio ... · allan francisco forzza amaral uma...
TRANSCRIPT
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
Allan Francisco Forzza Amaral
Uma Proposta de Arquitetura de Redes de Sensores sem Fio Aplicada ao Monitoramento Térmico da Rede de Frios
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
Allan Francisco Forzza Amaral
Uma Proposta de Arquitetura de Redes de Sensores sem Fio Aplicada ao Monitoramento Térmico da Rede de Frios
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
3.6 - Considerações do Capítulo .............................................................................. 46
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
4.5 - Considerações do Capítulo .............................................................................. 62
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.
3.6 - Considerações do Capítulo
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
4.5 - Considerações do Capítulo
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