UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA CURSO DE ENGENHARIA DE COMPUTAÇÃO
JOÉVER SILVA HOFFMAN
UMA PLATAFORMA PARA TRATAMENTO DE
QUALIDADE DE CONTEXTO EM REDES DE
SENSORES SEM FIO
JOÉVER SILVA HOFFMAN
UMA PLATAFORMA PARA TRATAMENTO DE
QUALIDADE DE CONTEXTO EM REDES DE
SENSORES SEM FIO
Projeto Final de curso apresentado ao Colegiado do Curso de Engenharia de Computação da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do Grau de Engenheiro de Computação.
Orientador: Prof. Dr. José Gonçalves Pereira Filho.
JOÉVER SILVA HOFFMAN
UMA PLATAFORMA PARA TRATAMENTO DE
QUALIDADE DE CONTEXTO EM REDES DE
SENSORES SEM FIO
Projeto Final de curso apresentado ao Colegiado do Curso de Engenharia de Computação da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do Grau de Engenheiro de Computação.
Aprovado em ___ de dezembro de 2013
COMISSÃO EXAMINADORA
_____________________________________ Professor Dr. José Gonçalves Pereira Filho Departamento de Informática - UFES Orientador
_____________________________________ Professora Dr.ª Patrícia Dockhorn Costa Departamento de Informática – UFES
_____________________________________ Sergio Teixeira
Doutorando - Departamento de Informática – UFES
_____________________________________ Isaac S. A. Pereira
AGRADECIMENTOS
Primeiramente a Deus, que sempre esteve comigo tanto nos bons como nos maus momentos.
Ao meu orientador Prof. José Gonçalves Pereira Filho por toda a motivação e apoio recebido no decorrer desse trabalho.
A minha esposa Joyce que esteve ao meu lado todo esse tempo de faculdade e não foram poucos.
Aos meus familiares, pelo incentivo, paciência e carinho transmitidos durante toda a minha graduação. Amo vocês!
RESUMO
As Redes de Sensores Sem Fio têm se tornado ferramentas essenciais no monitoramento de grandezas do mundo físico. Estruturas formadas por diminutos nós com capacidade de processamento, armazenamento, comunicação e sensoriamento. As RSSF (Redes de Sensores Sem Fio) permitem aos seus usuários interagirem e observarem, com grande nível de detalhe e precisão, os mais variados ambientes, domínios e objetos de interesse.
As RSSF são consideradas importantes fontes de informações contextuais (e.g., temperatura, pressão, luminosidade, umidade, localização, etc). No entanto, a diversidade de tipos, as tecnologias de sensores (e, por conseguinte, de fontes contextuais), as características dos ambientes pervasivos em que essas redes são usadas, e a natureza das tarefas colaborativas, impõem um grande desafio para a gestão eficiente da informação de contexto, particularmente devido ao grande volume de dados redundantes e, por vezes, conflitantes. Parâmetros de QoC (Quality of Context) podem ser usados para resolver os conflitos que surgem na manipulação de informações contextuais.
ABSTRACT
LISTA DE FIGURAS
Figura 3.1 Exemplos de nós sensores. ... 23
Figura 3.2 Exemplo de um RSSF.. ... 24
Figura 3.3 Exemplo de RSSF ... 25
Figura 3.4 Arquitetura de um nó de uma RSSF ... 27
Figura 4.1 Visão Geral da Arquitetura. ... 33
Figura 5.1 Arquitetura de Implementação. ... 35
Figura 5.2 Visão do Módulo de Configuração. ... 36
Figura 5.3 Tela de Login. ... 37
Figura 5.4 Visão do menu Cadastro. ... 37
Figura 5.5 Visão da tela de Cadastro do Tipo de Validação. ... 38
Figura 5.6 Visão da tela de Cadastro da Origem (RSSF). ... 39
Figura 5.7 Tela de Cadastro de Tipo. ... 40
Figura 5.8 Parametrização da métrica Up_to_dateness. ... 41
Figura 5.9 Parametrização da métrica Accuracy ... 41
Figura 5.10 Parametrização da métrica Frequency. ... 42
Figura 5.11 Parametrização da métrica Significance ... 42
Figura 5.12 Visão do menu Processa. ... 43
Figura 5.13 Visão do menu Simula. ... 43
Figura 5.14 Visão do menu Relatórios. ... 43
Figura 5.15 Apresentação dos relatórios e a tela de configuração. ... 44
Figura 5.16 Relatório de Métricas e status da rede e do processamento. ... 45
Figura 5.17 Simulador de um sensor. ... 48
Figura 5.18 Simulador de N sensores. ... 49
Figura 5.19 Tabela qc_tipo_valida. ... 50
Figura 5.20 Tabela qc_origem. ... 51
Figura 5.21 Tabela qc_entrada. ... 51
Figura 5.22 Tabela qc_tipo. ... 52
Figura 5.23 Tabela qc_saida. ... 53
Figura 5.24 Tabela qc_controle. ... 53
Figura 5.25 Tabela qc_usuario. ... 53
Figura 5.26 Tabela qc_perfil. ... 54
Figura 5.27 DER da base de dados do SGQoC. ... 54
LISTA DE TABELAS
Tabela 4.1 Dados de Contexto. ... 29
Tabela 4.2 Parâmetro de Contexto. ... 29
Tabela 4.3 Exemplos de Parâmetros de Contexto. ... 29
Tabela 4.4 Métricas de QoC. ... 31
Tabela 5.1 Exemplo de utilização do tipo de variação porcentagem. ... 38
Tabela 5.1 Exemplos de Dados de Contexto. ... 46
Tabela 6.1 Parametrização de Tipos de Contexto (CtxType). ... 59
Tabela 6.2 CtxData e QoCData para PM10@RSSF1. ... 59
LISTA DE SIGLAS
DI Departamento de Informática
LPRM Laboratório de Pesquisas em Rede e Multimídia
QoC Quality of Context
UFES Universidade Federal do Espírito Santo
UML Unified Modeling Language
DER Diagrama Entidade Relacionamento
RSSF Redes de Sensores Sem Fio
SGQoC Serviço de Gerenciamento de Qualidade de Contexto
SUMÁRIO 1 INTRODUÇÃO ... 12 1.1 MOTIVAÇÃO ... 12 1.2 OBJETIVO DO TRABALHO ... 13 1.3 METODOLOGIA ... 14 1.4 ORGANIZAÇÃO ... 15 2 CONTEXTO ... 16
2.1 CARACTERÍSTICAS DA INFORMAÇÃO CONTEXTUAL ... 17
2.2 OPROCESSO DE INTERPRETAÇÃO DE CONTEXTO ... 19
2.3 QUALIDADE DE CONTEXTO ... 20
3 REDE DE SENSORES SEM FIO ... 23
3.1 ELEMENTOS DE UMA RSSF ... 24
3.2 ARQUITETURA DE UM NÓ ... 27
4 PLATAFORMA DE GERENCIAMENTO DA QOC EM RSSF ... 28
4.1 MODELO DE QUALIDADE DE CONTEXTO PROPOSTA ... 28
4.1.1 Métricas de QoC ... 30
4.2 REQUISITOS DO SERVIÇO DE QOC ... 31
4.3 ARQUITETURA DA CAMADA DE QOC ... 33
4.3.1 Configuração de Métricas QoC e RSSF ... 33
4.3.2 Adaptador de Contexto ... 34
4.3.3 Avaliador QoC ... 34
4.3.4 Distribuidor de Contexto + QoC ... 34
4.3.5 Simulador ... 34 5 IMPLEMENTAÇÃO DO SERVIÇO ... 35 5.1 SGQOCFRONT-END ... 35 5.2 CONTEXT ADAPTER ... 46 5.3 CONTEXT EVALUATOR ... 47 5.4 CONTEXT GENERATOR ... 48 5.4.1 Simulação de um sensor ... 48 5.4.2 Simulação de N sensores ... 49 5.5 SGQOCCLIENT ... 49 5.6 DBMYSQL ... 50
6 UM CENÁRIO DE USO DO SERVIÇO ... 55
6.1 SIMULAÇÃO DO CENÁRIO... 58
7 CONCLUSÕES ... 62
7.1 CONSIDERAÇÕES FINAIS ... 62
7.2 TRABALHOS FUTUROS ... 63
1 INTRODUÇÃO
O conceito de Computação Pervasiva, sugerido por Weiser [1], vislumbra inteligência computacional permeando o cotidiano das pessoas. No cenário vislumbrado por Weiser, uma grande variedade de dispositivos com inteligência embarcada alimentam aplicações e serviços que suportam, de forma orgânica, as atividades rotineiras das pessoas. Avanços recentes nas áreas de comunicação móvel sem fio, microeletromecânica, tecnologias de sensores e sistemas embarcados [2] tem contribuído para a concretização da proposta de Weiser, ao permitir a construção e a disponibilização, cada vez mais corriqueira, de diversos tipos de novos “objetos inteligentes” (smart objects). Um objeto inteligente, em uma definição adaptada de Vasseur e Dunkels [3] é “[...] um pequeno dispositivo eletrônico equipado com um pequeno microprocessador, uma memória de baixa capacidade, um componente de comunicação de baixo alcance, um elemento sensor/atuador, e uma fonte de alimentação que garante a energia elétrica necessária para que o objeto possa realizar o seu trabalho”. O sensor/atuador possibilita ao objeto inteligente a capacidade de interagir com o mundo físico; o microprocessador permite ao objeto realizar transformações sobre os dados capturados, embora a uma velocidade e complexidade limitadas; o componente de comunicação, por sua vez, expõe as leituras dos sensores para o mundo exterior e recebe informações enviadas por outros objetos inteligentes.
As Redes de Sensores sem Fio (RSSF) são um exemplo de infraestrutura de comunicação inteligente formada a partir de um certo arranjo topológico de objetos ou nós sensores com inteligência embarcada. Com base em dados fornecidos por uma RSSF é possível adaptar pró-ativamente o comportamento das aplicações e serviços de acordo com a situação e necessidades dos usuários. Tal capacidade é conhecida como “sensibilidade ao contexto” (context-awareness). Nesse caso, contexto é entendido como qualquer informação que caracterize a situação de uma pessoa, lugar ou objeto relevante para a aplicação [4] [5].
1.1 Motivação
falhas nos sensores e outros fatores, os dados sensoriados podem ser incompletos e inacurados. Assim, um desafio na construção de serviços e aplicações sensíveis ao contexto é saber como lidar com contextos imperfeitos, visto que eles podem ocasionar comportamentos inadequados das aplicações. Por exemplo, em uma aplicação baseada em RSSF, a qualidade das informações contextuais é sensível à forma como os dados são sensoreados; em consequência, sem a devida análise de qualidade dos dados coletados, a aplicação pode tomar decisões equivocadas devido ao uso inadvertido de informações inconsistentes.
Parâmetros de “Qualidade de Contexto” (QoC – Quality of Context) podem ser usados para medir a qualidade da informação e resolver conflitos que surgem na manipulação de informações contextuais. De acordo com [7] a qualidade de contexto é “... qualquer atributo que descreve a qualidade da informação usada como contexto”. Considerando-se qualidade como o grau de satisfação a determinadas expectativas, uma aplicação sensível ao contexto pode se adaptar de forma diferente quando tem conhecimento do nível de satisfação de determinada informação de contexto considerada relevante para a tomada decisão. Em [7] [8] [9] são sugeridos um conjunto de parâmetros de qualidade relevantes no escopo de aplicações sensíveis ao contexto, os quais podem ser usados como indicadores da qualidade da informação contextual e servir de base para a implementação de infraestruturas de apoio ao gerenciamento da qualidade de contexto.
Apesar da sua reconhecida importância, ainda são poucas as aplicações que consideram informações de QoC sobre os dados adquiridos – ou o fazem de forma insatisfatória [8] [10]. Atualmente, existe uma percepção clara de que as aplicações sensíveis ao contexto reais ou mais complexas devam ser desenvolvidas com ciência dos problemas inerentes à aquisição de dados contextuais.
1.2 Objetivo do Trabalho Objetivos Gerais:
realiza a aquisição, avaliação e distribuição de contexto com QoC agregado e que permita a configuração flexível de requisitos de qualidade relativos às aplicações clientes.
Objetivos Específicos:
Projetar uma infraestrutura de gerenciamento de QoC dotada de componentes funcionais que assumem a existência de imperfeição nos dados coletados e que facilitam o desenvolvimento de serviços e aplicações sensíveis ao contexto em ambiente de redes de sensores sem fio.
Implementar um serviço de gerenciamento de QoC que atue juntamente com as redes de sensores sem fio e as aplicações sensíveis ao contexto e que disponibilize recursos de qualidade de contexto úteis para as aplicações clientes nas suas tomadas de decisão, além de fornecer recursos para correções de dados imperfeitos recebidos pelas redes de sensores.
1.3 Metodologia
A metodologia de desenvolvimento deste trabalho está baseada, essencialmente, em pesquisas bibliográficas sobre o tema central de estudo, sendo desenvolvida através de leitura de livros, monografias e dissertações, além de artigos científicos de periódicos e conferências da área, dentre outras fontes. Além disto, testes práticos poderão ser realizados como forma de apoiar o estudo teórico a ser desenvolvido.
Serão utilizados como base para o desenvolvimento da arquitetura conceitual e do serviço de qualidade de contexto, trabalhos similares reportados na literatura que descrevam e/ou implementem serviços, middleware ou frameworks que tratam do problema da (ausência de) qualidade de contexto em redes de sensores sem fio, além de material específico da linguagem de programação Java e do banco de dados MySQL usados no trabalho.
1.4 Organização
Além desta introdução, este trabalho contém a seguinte estrutura de capítulos:
Capítulo 2: Fornece uma breve introdução teórica ao tema central do trabalho (“contexto”) e apresenta a motivação para a construção da arquitetura proposta;
Capítulo 3: Apresenta conceitos básicos sobre as redes de sensores sem fio;
Capítulo 4: Descreve a plataforma de gerenciamento da QoC proposta;
Capítulo 5: Apresenta o projeto de construção do Serviço de Gerenciamento da QoC e o desenvolvimento de um simulador desse serviço;
Capítulo 6: Ilustra um estudo de caso utilizando o simulador da plataforma criada;
2 CONTEXTO
A palavra “contexto” no dicionário Houaiss significa a “inter-relação de circunstâncias que acompanham um fato ou uma situação”. Essa definição é muito geral e não consegue definir com precisão o uso desse termo no escopo desse trabalho, pois é preciso relacionar com os ambientes computacionais e sistemas de tecnologia da informação.
Alguns pesquisadores, com o intuito de limitar a abrangência desse conceito, enumeraram exemplos de contextos. Schilit [11] [12] divide contexto em três categorias:
Contexto Computacional: conectividade de rede, custos de comunicação, largura de banda e recursos disponíveis como impressoras, processadores e memória.
Contexto do Usuário: perfil do usuário, localização, pessoas próximas a ele, humor e outros.
Contexto Físico: luminosidade, níveis de barulhos, condições do trânsito e temperatura.
Além disso, [13] defende a inclusão do Tempo (hora do dia, da semana, do mês e a estação do ano) como uma quarta categoria de contexto e introduz o conceito de Histórico de Contexto e a necessidade de armazenamento de informações contextuais como fonte de tomada de decisões e construção de aplicações sensíveis ao contexto.
A definição mais referenciada na literatura de computação ubíqua para contexto é a defendida por Dey et al. [14] [15]:
“Contexto é qualquer informação que pode ser usada para caracterizar uma situação de uma entidade. Uma entidade é uma pessoa, um lugar, ou um objeto que é considerado relevante para a interação entre um usuário e uma aplicação, incluindo o próprio usuário e a própria aplicação.”
ou seja, a enumeração de exemplos ainda é bastante usada na literatura. Isso apenas reforça a necessidade de formalização deste conceito (onde trabalhos desenvolvidos pela comunidade de inteligência artificial muito poderia contribuir) e a importância de sub-áreas de pesquisa como modelagem contextual.
Considerando a importância do ambiente ao seu redor e o quanto ele determina o comportamento de uma aplicação sensível ao contexto, Chen e Kotz [13] definem contexto da seguinte maneira:
“Contexto é o conjunto de estados e características de um ambiente que determina o comportamento de uma aplicação ou no qual um evento de uma aplicação ocorre e interessa ao usuário.”
Podemos ainda entender contexto como “circunstâncias ou situações em que uma tarefa computacional está inserida”, definição extraída de [16].
Frequentemente usadas como sinônimo de contexto, as informações contextuais são nada mais que as informações que caracterizam um determinado contexto. São elas as informações relevantes para se determinar o estado atual de um contexto em questão. Considere o contexto localização, as informações contextuais referentes a esse contexto são, por exemplo, a latitude e a longitude de uma entidade ou em que sala de um edifício se encontra uma determinada pessoa. Nesse trabalho, os termos contexto e informações contextuais são utilizados de forma semelhante, mas fica clara a diferenciação entre esses dois conceitos.
2.1 Características da Informação Contextual
As informações contextuais possuem características bem peculiares que devem ser ressaltadas. De acordo com [16], a natureza da informação contextual deve ser levada em conta ao se construir sistemas ubíquos e de computação sensível ao contexto. Eis alguns pontos destacados por esse artigo:
comuns em sistemas ubíquos, variam frequentemente. A persistência de uma informação contextual dinâmica é altamente variável, por exemplo, relações entre colegas e amigos podem durar por meses e anos, enquanto a localização e a atividade de uma pessoa frequentemente se alteram a cada minuto. A característica de persistência influencia e determina quando uma determinada informação deverá ser adquirida. Enquanto informações estáticas podem ser facilmente obtidas de maneira direta dos usuários das aplicações, mudanças frequentes de contextos são detectadas através de meios indiretos como sensores.
Informação contextual é imperfeita. A informação pode estar incorreta se não refletir o verdadeiro estado do mundo que ela modela, inconsistente se contém informação contraditória, ou incompleta se sob alguns aspectos o contexto não é reconhecido. Em ambiente extremamente dinâmico como o da computação ubíqua, a informação contextual rapidamente se torna obsoleta, não refletindo o ambiente que deveria representar. Isso ocorre pelo fato de frequentemente as fontes, os repositórios e os consumidores de contexto estarem distribuídos, gerando muitas vezes um atraso entre o envio e a entrega das informações contextuais. Além disso, os produtores de contextos, como sensores, algoritmos de derivação e usuários, podem prover informação imperfeita. Esse é particularmente um problema que ocorre quando uma informação contextual é inferida a partir de sensores de mais baixo nível; por exemplo, quando a atividade de uma pessoa é inferida indiretamente a partir de sua localização e do nível de ruído ao seu redor. Finalmente, quedas de canais de comunicação, interferências e outras falhas podem ocorrer no caminho entre e o envio e a entrega da informação contextual, perdendo parte do que foi enviado ou a informação por completo.
geográficas de uma pessoa ou de um dispositivo, enquanto uma aplicação está interessada na identidade do prédio ou da sala em que o usuário está. Observe que os requisitos e níveis de abstração que uma informação contextual exige podem variar de uma aplicação para a outra. Portanto, um modelo de contexto deve suportar múltiplas representações do mesmo contexto em diferentes formas e em diferentes níveis de abstração, e ainda ser capaz de entender os relacionamentos entre essas representações alternativas.
Informações contextuais são extremamente inter-relacionadas. Diversos relacionamentos entre as informações contextuais são evidentes, por exemplo, proximidade entre usuários e seus dispositivos. Entretanto, outros tipos de relacionamentos entre informações contextuais não são tão óbvios. As informações contextuais podem estar relacionadas entre si através de regras de derivação que descrevem como uma informação contextual é obtida a partir de uma ou mais informações.
2.2 O Processo de Interpretação de Contexto
A interpretação de contexto é o conjunto de métodos e processos que realizam a abstração, o mapeamento, a manipulação, a agregação, a derivação, a inferência, o refinamento e demais ações sobre as informações contextuais, com o propósito de facilitar o entendimento de um determinado contexto pelas aplicações e auxiliá-las na tomada de decisões. Em [Dey, 2000], a interpretação de contexto é vista como o processo de se elevar o nível de abstração das informações contextuais de um ambiente, de gerar uma informação contextual mais elaborada a partir de uma mais primitiva, por exemplo, gerar o nome do local em que se encontra um indivíduo a partir de suas coordenadas de localização.
Nas plataformas (ou sistemas de midlleware) que dão suporte à manipulação de contexto, em geral a interpretação do contexto está baseada em uma infraestrutura de componentes de software, que corretamente dispostos e organizados, agem como ferramentas funcionais que realizam o processo de interpretação de contexto e de informações contextuais.
Um requisito importante que deve ser observado na implementação dessas plataformas refere-se à confiabilidade e ao grau de incerteza associado às informações contextuais. Por exemplo, informações de localização, temperatura, umidade, entre outras, que estão associadas ao contexto físico, geralmente são transmitidas através de sensores espalhados nos ambientes em que os usuários se encontram. Devido as características físicas do contexto e de certas fontes de dados contextuais – por exemplo, os nós de uma rede de sensores sem fio – esse tipo de informação contextual possui, associada a ela, uma incerteza e uma imprecisão de valor, podendo não refletir o ambiente que representam [16]. Devido a isso, parâmetros de qualidade de contexto podem ser utilizados para fornecer um nível a mais de confiabilidade acerca das informações de contexto. A qualidade de contexto (QoC – Quality of Context) é discutido na próxima subseção.
2.3 Qualidade de Contexto
A investigação sobre a natureza imperfeita da informação contextual, a proposição de métricas de qualidade de contexto e as arquiteturas de suporte à manipulação de QoC já podem ser vistas nos trabalhos de [7] [15] [17]. Desde a introdução do termo Quality of Context (QoC), atribuída a Buchholz [7], uma série de trabalhos sugerindo diferentes parâmetros de QoC foram propostos na literatura. Devido à ausência de padronização dos indicadores de qualidade, vários trabalhos posteriores, tais como [8] [18] [19], exploraram a definição de novas métricas e processos de avaliação de QoC.
Seguindo a linha de Buchholz, foram criadas medidas de qualidade de contexto para expressar a qualidade de um dado. De acordo com [7] [8] [18], são métricas importantes de avaliação da QoC:
(i) Precision – conformidade do dado informado com a realidade; (ii) Trustworthiness – probabilidade da informação estar correta; (iii) Resolution – refere-se à granularidade da informação;
(iv) Up-to-dateness (que em alguns trabalhos é citada como Freshness) – o quão recente é a informação recebida.
Outros trabalhos, como [20] [21], sugerem parâmetros como:
(i) Coverage – define um conjunto de valores possíveis para um atributo de contexto;
(ii) Relevance – o quanto o dado de contexto é relevante para a aplicação cliente;
(iii) Completeness - é o grau em que as informações de contexto estão disponíveis.
Neisse [9] propõe um conjunto de métricas alinhadas com definições de qualidade do vocabulário da International Organization for Standardization (ISO). São elas:
(i) Accuracy – é a medida dos dados serem corretos e confiáveis;
(ii) Precision – medida que descreve exatamente como as informações de contexto se espelha da realidade;
(iii) Temporal Resolution - o período de tempo para que uma informação de contexto é aplicável;
middleware para o desacoplamento entre as aplicações e a heterogeneidade dos sensores de contexto e o uso dos mesmos para aferir QoC.
Em Abid [23] é realizado uma integração de QoC a um framework provedor de contexto já existente chamado COSMOS (COntext entitieS coMpositiOn and Sharing), que é uma estrutura gerenciadora de contexto em ambientes ubíquos. Nele são definidos nós contendo dados de contexto que são enviados as aplicações sensíveis ao mesmo.
A integração realizada por Abid em [23], pode ser implementada de três formas: junto com a mensagem de Contexto do nó, adicionando uma nova camada de mensagem para a QoC dentro do nó, ou através de envios periódicos ou por solicitação das aplicações. As duas primeiras formas de integração são úteis para as aplicações que necessitam da QoC a cada dado de Contexto recebido, só que para incluir as informações de qualidade de contexto é necessário um tempo maior de processamento que pode gerar atrasos no recebimento do Contexto. A última forma de integração é útil para as aplicações que não necessitam de informações de QoC em tempo real, pois os dados são transmitidos sem as informações de qualidade de contexto e quando for necessário essas informações, à aplicação solicita ou aguarda o envio periódico desses dados.
3 REDE DE SENSORES SEM FIO
Os avanços recentes na tecnologia micro-eletromecânica, da comunicação sem fio e da eletrônica digital tem permitido a construção de nós sensores de custo, baixo-consumo e multifuncionais, pequenos em tamanho e não limitados a pequenas distâncias [27]. Com a diminuição dos custos e maior autonomia de energia, aliada a uma capacidade básica de processamento, armazenamento e comunicação, tornou-se possível a criação de uma gama de novas aplicações de monitoramento de maior precisão em diversas áreas, inclusive em ambientes completamente hostis, baseadas no uso de um número elevado de sensores sem fio. As Figuras 3.1(a) e 3.1(b) ilustram dois exemplos de plataforma de nós sensores, respectivamente MicaZ e TelosB, ambos comercializados pela empresa norte americana Memsic (http://www.memsic.com).
Uma Rede de Sensores Sem Fio (RSSF) é composta por uma grande quantidade desses nós sensores, que são espalhados dentro da área, objeto ou fenômeno a ser monitorado ou muito próximo a ele (Loureiro, 2003). Tais fenômenos podem estar relacionados às correntes marítimas, animais, estruturas civis ou mesmo regiões inóspitas, como vulcões; logo, é possível desenvolver aplicações baseadas em RSSF para acompanhar e gerar relatórios de mudanças marítimas, para relatar a posição de animais - podendo apresentar a sua trajetória e entender como funciona o processo de migração de uma determinada espécie - e para monitorar a variação da temperatura e detecção de abalos físicos afim de prever uma possível erupção de um vulcão. Exemplos de aplicações de RSSF incluem: monitoramento ambiental e de habitat em cidades, rios, mares, matas e florestas; rastreamento de objetos, pessoas e animais; controle de segurança física; aplicações de health e homecare;
(a) Nó sensor MICAz (b) Nó sensor TelosB
monitoramento de estruturas civis; monitoramento de facilities em datacenters; automação industrial; aplicações militares; e uma enorme quantidade de outras aplicações de monitoramento de grandezas físicas, tais como temperatura, pressão, umidade, movimento veicular, luminosidade, níveis de ruído, composição do solo, níveis de estresse mecânicos, etc.
Alguns exemplos de serviços que podem ser implementados tendo como base os dados adquiridos de RSSF são:
Hospitais: No monitorando pacientes.
Ruas / Estradas / Rodovias: Disponibilizando informações sobre o transito em tempo real.
Florestas: No controle de animais protegidos e áreas florestais preservadas. Na prevenção de incêndios.
Rios / Oceanos: No monitorando do nível do rio, tamanho das ondas, peixes protegidos.
Residências: Casas inteligentes com controle de temperatura, energia, ventilação, segurança, etc.
3.1 Elementos de uma RSSF
As Figura 3.2 e 3.3 ilustram exemplos de RSSF, destacando alguns dos seus elementos.
Figura 3.2 Exemplo de um RSSF.
Figura 3.3 Exemplo de RSSF.
Fonte: http://iopscience.iop.org/0964-1726/21/7/075009/article, acessado em outubro de 2013.
As Figura 3.2 é um exemplo de uma rede de sensores sem fio que possui vários nós sensores (representados na Figura pelos sensores que não possuem o sinal de onda), alguns nós roteadores (representados com um sinal de onda na figura) e dois gateway (nomeados como gateway#1 e gateway#2) que estão ligados diretamente a um servidor (server) que deverá disponibilizar os dados coletados para aplicações clientes na nuvem.
Observando as Figuras 3.2 e 3.3 vemos que em uma RSSF existem três tipos de nós:
Nós de sensoriamento: monitoram o ambiente com os seus sensores e entrega os dados coletados aos nós roteadores;
Nós roteadores: processam os dados recebidos de outros nós e encaminha-os para os gateways. Eles são responsáveis por definir as rotas que os sensores deverão utilizar nos envios dos dados e, caso aja algum problema na rota (por exemplo, uma falha em um dos sensores) esses nós realizam a modificação da rota para continuar a transmissão dos dados;
Gateways: responsáveis por enviar as informações processadas para um computador ligado à internet, também podendo transmitir essas informações para outras RSSF.
Nota-se que os nós de uma RSSF devem trabalhar em conjunto para executar tarefas específicas e que o sensoriamento pode ser feito de diversas formas:
Periódica: o sensoreamento é feito em intervalos regulares e pré-determinados;
Contínua: os nós coletam dados de forma continua;
Reativa: o sensoreamento é feito quando ocorre um evento de interesse ou quando solicitado por um observador;
Tempo Real: coleta realizadada com a maior quantidade de dados possível no menor intervalo de tempo.
3.2 Arquitetura de um Nó
A arquitetura de um nó sede de uma RSSF consiste basicamente de uma unidade microcontroladora (UMC) que interconecta um transceptor de dados, sensores de grandezas físicas, juntamente com um conversor analógico para digital, uma fonte de energia e uma memória flash externa. A UMC inclui um processador, uma memória RAM (SRAM) e uma memória flash interna. A pouca energia dos microcontroladores limita o armazenamento, normalmente menos de 10 KB de SRAM, do código de execução. A quantidade limitada de memória flash no chip possibilita apenas uma pequena área de memória não volátil; logo, uma grande quantidade de memória flash extra é usada em uma placa separada para possibilitar a melhor funcionalidade da rede. Exemplos de plataformas incluem [28]: MICAz, TelosB e IRIS (acessados em 5/11/2013).
A plataforma MICAz, por exemplo, possui a menor quantidade de memória RAM, 4kB, se comparada às plataformas citadas. Ela é dotada de um rádio de baixo alcance e antena para conexão sem fio, 512kB de memória flash, e conector de expansão que permite que sejam conectadas placas de sensores de som, luminosidade, temperatura e também serve para que o nó seja conectado à estação base (base station), estação que permite com que os dados da rede sejam acessados por um computador e vice-versa através do conector USB. A plataforma TelosB possui 10 kB de memória RAM e a IRIS 8 kB de RAM. A Figura 3.4 ilustra a arquitetura genérica de um nó de uma RSSF.
4 PLATAFORMA DE GERENCIAMENTO DA QOC EM RSSF
Este capítulo apresenta a contribuição principal deste trabalho: uma proposta de plataforma para gerenciamento da qualidade dos dados coletados de RSSF. A proposta inclui a definição de um “Modelo de QoC” e de uma “Camada de QoC”, a qual implementa um “Serviço de QoC”. Através deste serviço, é possível filtrar, processar e executar ações caso ocorra algum problema nos dados recebidos das redes de sensores. Esses problemas que podem ocorrer nas redes de sensores sem fio, estão relacionados com interferências, falhas de comunicação, falhas na medição do contexto, falhas de hardware, entre outras. Um exemplo de tomada de decisão que o serviço poderia realizar é no monitoramento de temperatura de uma caldeira, onde cinco sensores realizam medições frequentes e encaminham os dados coletados ao serviço de QoC. Se ocorre de quatro sensores informarem valores na faixa de 100 °C e um quinto numa faixa completamente fora, por exemplo, faixa de 500 °C, o serviço detectaria essa inconsistência e realizaria a correção dos dados antes de sua entrega as aplicações clientes.
Com a utilização desta plataforma, é possível retirar a responsabilidade das aplicações sensíveis ao contexto de verificar se um dado está correto ou não antes de sua utilização, permitindo que ela passe a ter um foco maior na utilização dos dados de contexto e de suas medidas de qualidade.
O restante do capítulo está assim organizado: a Seção 4.1 introduz o modelo de contexto adotado; os requisitos do serviço de QoC são introduzidos na Seção 4.2; e a Seção 4.3 descreve a arquitetura conceitual da Camada de QoC.
4.1 Modelo de Qualidade de Contexto Proposta
QoC mencionados, aplicando respectivos pesos de acordo com o tipo de dado contextual, como sugerido por [30].
Consideramos tipo de contexto uma entidade que representa um tipo de dado monitorado por uma fonte contextual específica. Aos valores aferidos para um tipo de contexto damos o nome de dado de contexto. Compõem um dado de contexto: a Rede, o Tipo de Contexto, o valor aferido (escalar) e o timestamp da aferição, como é apresentado na tabela 4.1.
Tabela 4.1 Dados de Contexto.
Rede Tipo Valor Timestamp
RSSF_A Temperatura 50.10 19/09/2013 20:58:01 RSSF_B Pressão 0.7 19/09/2013 21:02:05
Para o desenvolvimento das fórmulas das funções de QoC que serão apresentadas na Seção 4.1.1, foram definidos parâmetros de Contexto (min, max, lifespan, period e Consecutive_variation) para cada tipo de contexto em uma rede de sensores. Esses parâmetros eventualmente irão compor as fórmulas das funções de qualidade de contexto. A tabela 4.2 apresenta as definições de cada parâmetro de contexto e a Tabela 4.3 mostra alguns exemplos de valores para esses parâmetros.
Tabela 4.2 Parâmetro de Contexto.
Função Definição
min(C) Valor mínimo para um contexto C
max(C) Valor máximo para um contexto C
lifespan(C) Intervalo de validade de um contexto C
period(C) Período esperado entre leituras adquiridas de um contexto C
Consecutive_variation(X) Porcentagem de variação entre dados consecutivos de um contexto C
Tabela 4.3 Exemplos de Parâmetros de Contexto.
Rede Tipo min ~max lifespan period Consecutive_variation
4.1.1 Métricas de QoC
Nessa seção são definidas as métricas de qualidade de contexto e uma classe de funções de QoC que serão responsáveis pela quantificação das métricas de QoC utilizadas neste trabalho.
Coverage (C(di)): Representa o escopo aceitável de valores (min e max) esperado
para o tipo de contexto. Um dado que obedece ao coverage do seu tipo de contexto representa, a priori, um valor possível de ser manifestado.
Up-to-dateness (U(di)): Denota relevância temporal. Em algumas aplicações é
importante que a tomada de decisão seja baseada em dados recentes e temporalmente válidos. Nossa abordagem considera que dados de determinado tipo de contexto apresentam um lifespan ou tempo de vida. O intervalo entre a produção do dado pela fonte de contexto e o seu processamento (age) deve estar contido em seu lifespan para que seja considerado up-to-date.
Frequency (F(di)): Indica se a geração do dado ocorre na periodicidade esperada
(period). Sua estimativa baseia-se no intervalo entre dados adquiridos consecutivamente de uma mesma fonte contextual.
Accuracy (A(di)): Corresponde ao grau de corretude entre o valor do dado adquirido
(val(di)) e seu valor real. No entanto, é dificil determinar o valor real de um contexto. Nossa abordagem estima um intervalo de confiança entre leituras consecutivas de um mesmo contexto, semelhante ao sugerido por [31], de forma que para uma leitura obter A(di) alto seu valor não pode ser relativamente superior à leitura anterior (di-1) baseado em um fator de variação (consecutive_var).
Significance (S(di)): Mede a relevância ou a importância de um dado contextual.
Com base nas entidades apresentadas e nos parâmetros de Contexto, definimos uma classe de funções de QoC, representada por f(di), di ϵ C, tal que di representa um dado de contexto, e C o conjunto de dados de um determinado tipo de contexto. Sua imagem varia no intervalo [0..1], onde f(di ) = 1 significa a total aderência com o requisito de qualidade, e f(di ) = 0 a total falta de cumprimento do mesmo. Para caracterizar a sequencialidade - em relação ao instante de geração - entre dados contextuais, consideramos que di é um dado consecutivo a di-1. A Tabela 4.4 apresenta como são quantificadas as funções de QoC utilizadas neste trabalho.
Tabela 4.4 Métricas de QoC.
Métrica Sigla e Fórmula
Coverage 𝐶(𝑑𝑖) = { 0, 𝑣𝑎𝑙(𝑑1, 𝑚𝑖𝑛(d) ≤ 𝑣𝑎𝑙(𝑑𝑖) ≤ 𝑚𝑎 𝑥(𝐷) 𝑖) < 𝑚𝑖𝑛(𝐷) || 𝑣𝑎𝑙(𝑑𝑖) > 𝑚𝑎 𝑥(𝐷) Up to dateness 𝑈(𝑑𝑖) = { 1 − 𝑎𝑔𝑒(𝑑𝑖) 𝑙𝑖𝑓𝑒𝑠𝑝𝑎𝑛(𝐷), 𝑎𝑔𝑒(𝑑𝑖) < 𝑙𝑖𝑓𝑒𝑠𝑝𝑎𝑛(𝐷) 0, 𝑎𝑔𝑒(𝑑𝑖) ≥ 𝑙𝑖𝑓𝑒𝑠𝑝𝑎𝑛(𝐷) Frequency 𝐹(𝑑𝑖) = { 1, 0, 𝑝𝑟𝑜𝑑_𝑡𝑖𝑚𝑒(𝑑𝑝𝑟𝑜𝑑_𝑡𝑖𝑚𝑒(𝑑𝑖) − 𝑝𝑟𝑜𝑑_𝑡𝑖𝑚𝑒(𝑑𝑖−1) ≤ 𝑝𝑒𝑟𝑖𝑜𝑑(𝐷) 𝑖) − 𝑝𝑟𝑜𝑑_𝑡𝑖𝑚𝑒(𝑑𝑖−1) > 𝑝𝑒𝑟𝑖𝑜𝑑(𝐷) Accuracy 𝐴(𝑑𝑖) = { 1, 100 × |𝑣𝑎𝑙(𝑑𝑖) − 𝑣𝑎𝑙(𝑑𝑖−1)| 𝑣𝑎𝑙(𝑑𝑖) ≤ 𝑐𝑜𝑛𝑠𝑒𝑐𝑢𝑡𝑖𝑣𝑒_𝑣𝑎𝑟𝑖𝑎𝑡𝑖𝑜𝑛(𝐷) 0, 100 × |𝑣𝑎𝑙(𝑑𝑖) − 𝑣𝑎𝑙(𝑑𝑖−1)| 𝑣𝑎𝑙(𝑑𝑖) > 𝑐𝑜𝑛𝑠𝑒𝑐𝑢𝑡𝑖𝑣𝑒_𝑣𝑎𝑟𝑖𝑎𝑡𝑖𝑜𝑛(𝐷) Significance 𝑆(𝑑𝑖) = 𝑐𝑟𝑖𝑡𝑖𝑐 (𝐶, 𝑑𝑖) = { 1, 𝑑0, 𝑑𝑖 𝑎𝑡𝑒𝑛𝑑𝑒 𝑐𝑜𝑛𝑗𝑢𝑛𝑡𝑜 𝑑𝑒 𝑟𝑒𝑔𝑖õ𝑒𝑠 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑠 𝑑𝑒 𝐶 𝑖 𝑛ã𝑜 𝑎𝑡𝑒𝑛𝑑𝑒 𝑐𝑜𝑛𝑗𝑢𝑛𝑡𝑜 𝑑𝑒 𝑟𝑒𝑔𝑖õ𝑒𝑠 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑠 𝑑𝑒 𝐶 QoC Geral 𝑄𝑜𝐶(𝑑𝑖) = 𝐶(𝑑𝑖) ∗ 𝑝𝐶(𝐶) + 𝑈(𝑑𝑖) ∗ 𝑝𝑈(𝐶) + 𝐴(𝑑𝑖) ∗ 𝑝𝐴(𝐶) + 𝐹(𝑑𝑖) ∗ 𝑝𝐹(𝐶) + 𝑆(𝑑𝑖) ∗ 𝑝𝑆(𝐶) 𝑝𝐶(𝐶) + 𝑝𝑈(𝐶) + 𝑝𝐴(𝐶) + 𝑝𝐹(𝐶) + 𝑝𝑆(𝐶)
O cálculo do QoC Geral (QoC(di)), como apresentado na Tabela 4.4, depende da parametrização de pesos relativos à cada métrica. pC(C), pU(C), pA(C) são exemplos de funções que retornam os pesos das métricas coverage, up-to-dateness e accuracy, para um tipo de contexto C, respectivamente.
4.2 Requisitos do Serviço de QoC
dados obtidos das RSSF é feito por meio da geração de medidas de QoC [8], conforme discutido na Seção 4.1.
O serviço definido nesta camada é denominado de SGQoC – Serviço de Gerenciamento de Qualidade de Contexto. Este serviço intermedia as redes de sensores e as aplicações sensíveis ao contexto, disponibilizando para essas aplicações as informações recebidas das redes de sensores, juntamente com medidas de qualidade de contexto que facilitarão a sua tomada de decisão.
Para o desenvolvimento do serviço de gerenciamento foram definidos 6 (seis) requisitos funcionais e não funcionais: Segurança, Filtragem de Dados Incorretos, Geração de Relatórios, Geração de Medidas de QoC, Usabilidade e Flexibilidade. Esses requisitos são brevemente comentados a seguir.
Segurança: Os dados recebidos das redes de sensores só poderão ser entregues as aplicações que forem cadastradas para receber os dados dessa rede. Além disso, o acesso aos cadastros deverá ser restrito aos desenvolvedores das aplicações sensíveis ao contexto. Por fim, os dados armazenados só serão utilizados como histórico no processamento e reenviados às aplicações sensíveis ao contexto caso seja realizada uma solicitação por meio de interface.
Filtragem de dados incorretos: O SGQoC deverá ser capaz de identificar dados que estão errados ou incoerentes de acordo com as parametrizações do tipo de dados para cada RSSF cadastrada no serviço;
Geração de relatórios: O SGQoC deverá fornecer relatórios sobre o processamento dos dados e situação atual do processamento. Esses relatórios só poderão ser emitidos pelo desenvolvedor cadastrado e só será visualizado os dados das RSSF que ele for responsável.
Geração de Medidas de QoC: O serviço deverá fornecer às aplicações sensíveis ao contexto medidas de qualidade dos dados recebidos para auxiliar nas suas tomadas de decisão;
Flexibilidade: O serviço deverá permitir configurações diferentes para mesmos tipos de dados em diferentes RSSF. Além disso, cada aplicação sensível ao contexto terá suas configurações independentes uma das outras.
4.3 Arquitetura da Camada de QoC
Como descrito na Seção 4.2, a arquitetura proposta faz o tratamento de QoC em uma camada localizada entre as redes de sensores sem fio – as fontes contextuais – e as aplicações sensíveis ao contexto. A Figura 4.1 apresenta uma visão conceitual dessa arquitetura proposta para a Camada de QoC.
Figura 4.1 Visão Geral da Arquitetura.
Como pode ser visto na figura, foram definidos 5 (cinco) módulos funcionais: Configuração de Métricas QoC e RSSF, Adaptador de Contexto, Avaliador QoC, Distribuidor de Contexto + QoC, e Simulador. Esses módulos são introduzidos a seguir.
4.3.1 Configuração de Métricas QoC e RSSF
Dessa forma, uma RSSF terá n tipos de dados, onde cada um deles poderá ter uma configuração diferente em relação às medidas de qualidade de contexto e às aplicações sensíveis ao contexto que irão receber esses dados.
4.3.2 Adaptador de Contexto
Esse módulo é responsável por receber os dados das RSSF que forem cadastradas no módulo de configuração do SGQoC. Ao receber um novo dado, é montada uma estrutura de dados que é entregue ao módulo de Avaliador QoC. Nessa estrutura estão contidas as seguintes informações: o código da rede de sensores, o tipo de dado, o seu valor escalar e o timestamp de criação.
4.3.3 Avaliador QoC
Esse módulo realiza um filtro nos dados recebidos utilizando como base os dados já processados dessa fonte/tipo e as informações contidas no seu cadastro. Ao final do processamento é gerada um nova estrutura de dados contendo a estrutura inicial que foi criada pelo módulo Adaptador de Contexto com a inclusão de um novo timestamp de processamento, do valor escalar final e os valores das métricas de QoC geradas nesse processamento. Essa estrutura é arquivada para posterior utilização e entregue ao módulo de distribuição de contexto.
4.3.4 Distribuidor de Contexto + QoC
Ao receber os dados processados pelo Avaliador de Contexto, esse módulo verifica no cadastro do tipo de dado para a RSSF qual é a aplicação que deverá receber os dados processados com as medidas de QoC. Ao localizar a aplicação, é feita a entrega dos dados utilizando uma interface entre o SGQoC e a aplicação final.
4.3.5 Simulador
5 IMPLEMENTAÇÃO DO SERVIÇO
O Serviço de Gerência de Qualidade de Contexto (SGQoC) é um protótipo de sistema que implementa elementos da arquitetura conceitual proposta na Seção 4. Para a sua implementação foi adotada a linguagem Java como base de programação, MySQL como tecnologia de persistência de dados e a biblioteca Swing para desenvolvimento da interface com o usuário.
A realização da arquitetura contempla a implementação dos seguintes módulos, reunidos em uma Arquitetura de Implementação: (i) SGQoC Front-End; (ii) Context Adapter; (iii) Context Evaluator; (iv) Context Generator; e (v) SGQoC Client como apresentado na Figura 5.1.
Figura 5.1 Arquitetura de Implementação.
Como pode ser visto na Figura 5.1, existem três camadas na arquitetura de implementação, a saber: o nível das redes de sensores sem fio, o nível do SGQoC e o nível das aplicações sensíveis ao contexto. As seções seguintes descrevem os módulos do SGQoC implementados nesta versão da plataforma.
5.1 SGQoC Front-End
o serviço irá manipular e as configurações das medidas de QoC que deverão ser geradas pelo serviço. É nesse módulo que é implementada a Configuração de Métricas QoC e RSSF, definidos na arquitetura proposta na seção 4.3, além de partes dos requisitos de segurança, geração de relatórios, usabilidade e flexibilidade.
A Figura 5.2 mostra a tela “sobre” e os menus disponíveis nesse módulo. Essa é a tela inicial após o Login do usuário.
Figura 5.2 Visão do Módulo de Configuração.
Figura 5.3 Tela de Login.
No menu apresentado na Figura 5.2, temos o menu de Cadastro que dá acesso às telas de configuração de Tipo de Validação, Origem e Tipo. Além disso, podemos bloquear o sistema para ninguém acessá-lo até que ele seja liberado novamente, através do item Bloquear, e fechar o módulo pelo item Sair. A Figura 5.4 mostra o menu Cadastro expandido.
Figura 5.4 Visão do menu Cadastro.
Figura 5.5 Visão da tela de Cadastro do Tipo de Validação.
O cadastro do Tipo de Validação só pode ser feito por um administrador do SGQoC, pois é necessário criar esse tipo de validação dentro do código do sistema antes de cadastrá-lo para os usuários utilizarem. Nessa primeira versão do serviço, foi criado apenas o tipo porcentagem.
O tipo de validação é utilizado para detectar imperfeições nos dados recebidos das redes de sensores. Quando uma rede define que será utilizado o tipo porcentagem, o sistema ao receber um dado dessa rede, verifica se a variação de porcentagem entre o dado recebido e seu antecessor está dentro do limite definido pelo usuário. Em caso afirmativo, o dado de contexto é entregue sem alterações; caso contrário, o sistema pode tomar alguma ação para que esse dado não chegue a ser entregue à aplicação cliente. A Tabela 5.1 mostra um exemplo de utilização desse tipo de variação, onde os dados foram recebidos e o sistema verificou se a diferença de porcentagem entre duas leituras consecutivas está abaixo do limite definido no parâmetro Consecutive_variation.
Ao clicar no botão Origem dentro do menu Cadastro, a tela de “Cadastro da origem” é apresentada como na Figura 5.6. Essa tela permite ao usuário cadastrar o IP do gateway da sua RSSF, que passará a transmitir os dados para o SGQoC, e definir a aplicação que irá receber os dados tratados juntamente com as medidas da QoC.
Figura 5.6 Visão da tela de Cadastro da Origem (RSSF).
Ainda no menu Cadastro é possível acessar o “cadastro de Tipo” que é a tela responsável por definir toda a base de parametrização para a geração das medidas da qualidade de contexto, bem como da definição do tipo de dado da RSSF, do tipo de validação e o que deverá ser feito caso um dado seja considerado errado. A Figura 5.7 mostra essa tela de cadastro.
Figura 5.7 Tela de Cadastro de Tipo.
Como pode ser visto na tela de cadastro de tipo, essa primeira versão do SGQoC comporta cinco tipos de métricas de qualidade de contexto: Coverage, Up_to_dateness, Accuracy, Frequency e Significance. As parametrizações necessárias para a geração de cada uma dessas métricas são mostradas a seguir:
Coverage: representa o escopo aceitável de valores (min e max) esperado para o tipo de contexto, sendo parametrizada com os valores limites (Inferior e Superior), como mostrado na Figura 5.7, além de definir o peso dessa métrica para a geração da medida geral de QoC. O usuário pode escolher não utilizar essa métrica desmarcando a opção “Gerar essa avaliação da QoC”.
Figura 5.8 Parametrização da métrica Up_to_dateness.
Accuracy: avalia o grau de corretude do contexto e é determinado utilizando as informações do tipo de verificação e seus valores (valida1 e valida2). Esses campos podem ser vistos na Figura 5.7. Essa métrica é uma das mais importantes para as aplicações finais, pois através dela será tomada a decisão em utilizar ou não o dado de contexto. Como nessa versão do SGQoC só foi desenvolvido o tipo de validação porcentagem, só o valor do campo valida1 será utilizado na comparação da diferença de porcentagem entre dois dados recebidos consecutivamente pelo serviço. No exemplo da Figura foi parametrizado uma variação máxima de 20%. Na Figura 5.9 temos a definição do peso para essa métrica que será utilizada no cálculo da medida geral de QoC.
Figura 5.9 Parametrização da métrica Accuracy
Figura 5.10 Parametrização da métrica Frequency.
Significance: é a métrica responsável por medir a relevância ou a importância de um dado contextual. Pode ser parametriza com um ou dois operadores com seus respectivos valores, dessa forma é possível parametrizar um espaço fechado, um valor fixo, valores diferentes, fora de uma faixa de valores, etc. A Figura 5.11 mostra a tela de parametrização dessa métrica. Também é definido o peso dessa métrica para ser utilizado no cálculo da medida geral de QoC.
Figura 5.11 Parametrização da métrica Significance
Essas definições e configurações das redes e das métricas de QoC são gravadas na base de dados do sistema para posterior utilização pelos demais módulos.
Figura 5.12 Visão do menu Processa.
Voltando para o menu principal, temos ainda o menu Simula que é responsável por abrir o módulo de simulação chamado de Context Generator. É possível simular um único sensor ou N sensores de uma RSSF. A Figura 5.13 mostra as duas opções de simulação.
Figura 5.13 Visão do menu Simula.
Utilizando o módulo de interface com o usuário é possível monitorar em tempo real as atividades de avaliação de contexto por meio de relatórios e estatísticas. O menu Relatórios apresentado na Figura 5.14 mostra os tipos de relatórios disponíveis nessa versão do SGQoC.
Figura 5.14 Visão do menu Relatórios.
desenvolvidos utilizado a biblioteca jfreechart-1.0.14, que pode ser encontrada em [32].
Figura 5.15 Apresentação dos relatórios e a tela de configuração.
onde o valor da accuracy (linha vermelha) é igual a zero, representa o momento que foi recebido o dado de contexto com valor aproximado de cinquenta (50) e que foi considerado incorreto.
O relatório de resumo das métricas apresentado na Figura 5.16, mostra o percentual das métricas que estão sendo geradas para a RSSF seleciona e apresenta o status da rede e do processamento dos dados. Para a geração do relatório é necessário informar o período de análise, mas para a verificação do status da rede e do processamento não é utilizado esse período.
Figura 5.16 Relatório de Métricas e status da rede e do processamento.
Os menus Usuário e Ajuda ainda não foram desenvolvidos por completo nessa versão do SGQoC. Dentro do menu Ajuda, a tela “Sobre” foi desenvolvida e pode ser vista na Figura 5.2.
Front-End, os usuários passam a ter um acesso fácil às configurações e à utilização do SGQoC.
O requisito de flexibilidade é atendido por completo nesse módulo. Todas as configurações são feitas nesse módulo e são independentes das aplicações clientes.
5.2 Context Adapter
O componente Adaptador de Contexto é responsável por receber os dados das fontes de contexto cadastradas, classificá-los pelo tipo de contexto, instanciá-los na forma de uma entidade dado de contexto (d) e encaminhá-los ao módulo avaliador. Uma entidade dado de contexto possui um tipo de contexto (código da RSSF e do tipo de dado), um valor escalar e um timestamp de geração, que é a data e hora em que o contexto foi coletado ou gerado pelo simulador. A entidade dado de contexto é chamada de CtxData. A tabela abaixo mostra exemplos de CtxData:
Tabela 5.2 Exemplos de Dados de Contexto.
Rede Tipo Valor Timestamp
RSSF1 PM10 20.60 19/09/2013 20:58:01
RSSF1 PM10 21.60 19/09/2013 21:02:05
RSSF1 PM10 50.27 19/09/2013 21:10:09
RSSF1 PM10 20.72 19/09/2013 21:13:13
O módulo Adaptador de contexto da arquitetura proposta na Seção 4.3 é implementado nesse módulo Context Adapter. Ao enviar um dado de contexto ao módulo avaliador, o Contexto Adapter espera receber uma confirmação de recebimento dos dados. Caso o retorno não seja o esperado, o dado de contexto é gravado na base de dados do serviço para posterior avaliação, utilizando a interação 2 mostrada na Figura 5.1.
5.3 Context Evaluator
Para a implementação do módulo Adaptador de QoC representado na arquitetura proposta, foi necessário criar dois sub-componentes: QoCEvalManager e CtxEval. Esses sub-componentes possuem interfaces entre eles e outros componentes, como pode ser visto na Figura 5.1 pelas interações (3, 4, 5 e 6).
Uma vez instanciada a estrutura de dados que será processada, um objeto CtxData é encaminhado ao módulo Context Evaluator (interação 3), composto por dois sub-componentes: QoCEvalManager (QEM) e CtxEval. O QEM gerencia um pool de threads CtxEval (interação 4), que por sua vez implementam as funções de QoC apresentadas na Seção 2.2, aplica essas funções às instâncias CtxData de um CtxType específico e realiza a filtragem dos dados incorretos caso seja detectado utilizando as parametrizações do CtxType.
O QEM, quando recebe um CtxData, verifica a existência de um CtxEval responsável pelo respectivo CtxType. Caso exista, o dado é entregue; caso contrário, é criado um novo CtxEval para iniciar o processamento desse tipo de contexto. Esse sub-componente também instancia um CtxEval ao detectar que algum tipo de contexto recebido não foi processado pelo serviço imediatamente. Dessa forma, quando um dado de contexto é gravado diretamente na base de dados do SGQoC, o subcomponente QEM detecta a existência desse contexto e instancia um CtxEval para processa-lo.
Ao final do processamento esse módulo armazena na base do sistema o CtxData juntamente com seu QoCData (interação 6) e realiza a entrega desses dados ao módulo SGQoC Client (interação 5). Os dados armazenados podem ser posteriormente utilizados pelas aplicações clientes.
solicitante no mesmo formato que o módulo on-line faz, ou seja, dado de contexto com as medidas de QoC geradas.
Esse módulo atende aos requisitos de filtragem de dados incorretos e geração de medidas de QoC. Na implementação atual, a interação 5 ainda não foi desenvolvida, ou seja, o serviço está operando apenas no modo off-line, em que os dados ficam disponíveis apenas na base do sistema para posterior consulta.
5.4 Context Generator
Para testar e validar o sistema proposto, foi desenvolvido o módulo Context Generator, que permite simular um Sensor ou N sensores de uma única RSSF. O módulo Simulador da arquitetura proposta na seção 4.3 é implementado nesse módulo de Context Generator.
5.4.1 Simulação de um sensor
Permite ao usuário simular um tipo de dado em apenas um sensor de uma RSSF. Para iniciar a simulação é necessário definir a variação máxima dos valores a serem gerados, o intervalo de execução, e a RSSF/Tipo que será simulada, ou seja, definir o CtxType. Ao pressionar o botão Simular, é criada e inicializada uma thread que gera números aleatórios utilizando as funções do Java e os grava na base de dados do sistema. Na Figura 5.17 é mostrado esse simulador em execução.
5.4.2 Simulação de N sensores
Permite ao usuário simular vários tipos de dados com vários sensores de uma única RSSF. Para iniciar a simulação é necessário definir o número de sensores, o valor médio do dado a ser gerado e selecionar uma das distribuições de Probabilidade (uniforme, normal, Poisson, Exponencial ou Triangular). Ao pressionar o botão Simular, é criada uma thread que fica gerando no intervalo de tempo definido dentro do cadastro da RSSF/Tipo os números aleatórios de cada sensor e os grava na base de dados do sistema para posterior avaliação. A Figura 5.18 mostra a execução desse simulador.
Figura 5.18 Simulador de N sensores.
Em ambos os casos, a simulação só é terminada se pressionado o botão Parar. Também é possível abrir n sessões desses módulos para simular n sensores de uma única ou n RSSF.
Utilizando o módulo de Configuração é possível monitorar a entrada dos dados incluídos pela simulação ou por uma RSSF real no Relatório de Entrada. Para visualizar em tempo real é necessário marcar a opção Atualização Automática na tela de configuração do relatório.
5.5 SGQoC Client
o novo contexto para sua utilização. Além disso, caso a aplicação queira dados de contextos antigos, ela faz uma requisição a esse componente, que acessa a base de dados do SGQoC pela interação 7, busca os dados do CtxType da aplicação e os entrega como resposta à requisição.
Esse componente atende a mais uma parte do requisito de usabilidade fornecendo recursos próprios para a integração do SGQoC com as aplicações sensíveis ao contexto.
Na versão atual do SGQoC esse componente ainda não foi desenvolvido, sendo assim, os dados processados estão disponíveis na base de dados e podem ser visualizados nos relatórios gerados pelo módulo Front-End.
5.6 DB MySQL
A base de dados do SGQoC foi desenvolvida utilizando o MySQL e está estruturada com as seguintes tabelas: qc_tipo_valida, qc_origem, qc_entrada, qc_tipo, qc_saida, qc_controle, qc_usuario e qc_perfil.
Segue abaixo as definições de cada tabela do SGQoC juntamente com os campos e seus respectivos tipos de dados:
qc_tipo_valida: Responsável por armazenar os tipos de validação que o SGQoC é capaz de realizar nos dados de contexto. A Figura 5.19 mostra os campos dessa tabela.
Figura 5.19 Tabela qc_tipo_valida.
Figura 5.20 Tabela qc_origem.
qc_entrada: Responsável por armazenar os dados recebidos das RSSF. Os dados são gravados nesse tabela no formato de estrutura de dados apresentado na seção 5.2. A Figura 5.21 mostra os campos dessa tabela.
Figura 5.21 Tabela qc_entrada.
Figura 5.22 Tabela qc_tipo.
Figura 5.23 Tabela qc_saida.
qc_controle: Essa tabela foi criada para gerenciar o modo de processamento off-line. A Figura 5.24 mostra os campos dessa tabela.
Figura 5.24 Tabela qc_controle.
qc_usuario: Responsável por armazenar os dados dos usuários que possuem permissão para acessar o módulo Front-End. A Figura 5.25 mostra os campos dessa tabela.
qc_perfil: Responsável por armazenar os perfis de acesso do sistema para o módulo Front-End. A Figura 5.26 mostra os campos dessa tabela.
Figura 5.26 Tabela qc_perfil.
A Figura 5.27 mostra o diagrama de relacionamento das tabelas (DER) do SGQoC.
6 UM CENÁRIO DE USO DO SERVIÇO
O rápido aumento da frota de veículos aliado ao crescimento desordenado das grandes cidades tem diminuído muito a qualidade do ar que respiramos. De acordo com pesquisa realizada pela Organização Mundial de Saúde (OMS) no período de 2006 a 2009 respirar o ar da capital do Estado de São Paulo equivale a fumar dois cigarros por dia [33]. Outra pesquisa realizada pela Universidade de São Paulo (USP) em parceria com a Secretaria Estadual de Saúde (SESA) e o Instituto Estadual de Meio Ambiente (IEMA), apontou um aumento de 19% nas internações de adultos em dias mais poluídos [34].
O IEMA é o órgão do Governo do Estado do Espírito Santo responsável pelo monitoramento e fiscalização da poluição ambiental, tem em operação uma Rede Automática de Monitoramento da Qualidade do Ar (RAMQAr), formada por nove estações de monitoramento capazes de monitorar: Material Particulado (PTS), Partículas Inaláveis com diâmetro inferiores a dez microns (PM10), Dióxido de Enxofre (SO2), Óxidos de Nitrogênio (NOx), Hidrocarboneto (HC), Ozônio (O3), dentre outras medidas atmosféricas [35].
Apesar do monitoramento realizado pela RAMQAr, a população da Grande Vitória questiona os resultados efetivos das ações de fiscalização do IEMA, pois a poluição, principalmente, o material particulado conhecido como “pó preto”, tem causado muitos transtornos e problemas de saúde para os moradores da Grande Vitória.
Essas partículas são provenientes de indústrias e mineradoras existentes na região que causam problemas de saúde para a população. Moradores de bairros mais próximos a essas indústrias entraram com uma ação no Ministério Público do Estado (MP/ES), questionando o excesso de material particulado danoso à saúde, pois existe um projeto de expansão de uma mineradora [36].
concentração inadequada de algum poluente em qualquer localidade que não esteja na área de alcance da estação não será possível identificar o problema.
Essa situação é comum e recorrente em praticamente toda região metropolitana que teve crescimento desordenado e tem indústrias próximas às cidades. Uma alternativa interessante seria propor uma solução de monitoramento em rede, de baixo custo e com maior abrangência da região que se pretende monitorar, pois o monitoramento ambiental de grandes áreas requer recursos distribuídos com escalabilidade e facilidades para as aplicações.
A Computação em Nuvem (“Cloud Computing”) oferece uma infraestrutura com recursos, serviços e diversas possibilidades que pode proporcionar um novo paradigma para soluções de RSSF. Ao se estender o conceito de Cloud Computing para operar e gerenciar sensores distribuídos em diversas RSSF, oferecendo maior cobertura, escalabilidade, simplicidade, facilidades e novos serviços, chega-se ao conceito de Sensor-Cloud [37].
A proposta de uma Sensor-Cloud é coletar e processar a partir de várias RSSF, informações que sejam compartilhadas, em larga escala, com inúmeras aplicações e serviços para usuários que não precisam necessariamente ter conhecimento ou domínio das tecnologias de configuração de uma RSSF. O objetivo é integrar diversas redes com aplicações de monitoramento em uma plataforma de computação em nuvem, possibilitando o fácil acesso, processamento, visualização, análise, armazenamento, compartilhamento, busca de um grande número de sensores e aplicações.
Um exemplo de Sensor-Cloud de sucesso é o Xively [38]. Eles oferecem diversos serviços públicos em nuvem para a Internet das Coisas. Existem serviços públicos gratuitos e pagos, dependendo do tipo da solução ou serviço que o usuário precisa.
O AQE é um projeto iniciado em 2012, que propõe a criação de uma comunidade aberta de monitoramento da qualidade do ar de forma cooperativa. É um projeto de código aberto que engloba o hardware e software do sensor AQE e o compartilhamento dos dados coletados contendo as medidas atmosféricas realizadas pelos sensores s, e.g. temperatura, umidade e de poluentes, que ficam disponíveis na Sensor Cloud da Xively. Existem vários fabricantes do sensor AQE [40].
Cada participante da comunidade AQE compartilha os dados do seu sensor em uma comunidade da Xively. Dessa forma, todos os dados monitorados pelo sensor ficarão disponíveis na Sensor Cloud da Xively. Os sensores AQE são capazes de monitorar temperatura, umidade, índices de Monóxido de Carbono (CO), Dióxido de Nitrogênio (NO2), Material Particulado (PTS), Partículas Inaláveis com diâmetro inferiores a dez microns (PM10), Dióxido de Enxofre (SO2), Óxidos de Nitrogênio (NOx), Hidrocarboneto (HC), Ozônio (O3) e outros componentes. Esses são alguns dos poluentes que devem ser monitorados para analisar a qualidade do ar das cidades [41]. A Figura 6.1 apresenta uma visão geral de um protótipo do AirQualityEgg.
Figura 6.1 Visão geral de um protótipo do AirQualityEgg
