UM SERVIÇO DE GERENCIAMENTO DE QUALIDADE DE CONTEXTO EM REDES DE SENSORES SEM FIO

Joéver Silva Hoffman1, Isaac S. A. Pereira1, Sérgio Teixeira1,2,3, Janaína Scal Duia Castello1, José Gonçalves Pereira Filho1 e Patricia Dockhorn Costa1

1Universidade Federal do Espírito Santo (UFES), Vitória, ES, Brasil2Universidade Católica de Brasília (UCB), Brasília, DF, Brasil

3Faculdade Católica Salesiana do Espírito Santo (FCSES), Vitória, ES, Brasil

ABSTRACT

Aplicações sensíveis ao contexto são uma categoria emergente de sistemas computacionais que utilizam informações contextuais como meio de enriquecer a interação humano-computador. Essas aplicações se caracterizam por adaptar o seu comportamento de acordo com a situação do usuário e do ambiente físico que o cerca. Redes de Sensores sem Fio (RSSF) são consideradas importantes fontes de contexto. No entanto, falhas nos nós sensores decorrentes de problemas nas plataformas de hardware e de características particulares dos ambientes em que as RSSF são instaladas, impõem uma série de desafios quanto à gestão eficiente da informação de contexto, por exemplo, a necessidade de tratamento de eventuais imperfeições nos dados coletados. Parâmetros de Qualidade de Contexto (QoC – Quality of Context) podem ser usados para resolver conflitos que surgem na tomada de decisão baseada em informações contextuais imperfeitas. Este trabalho propõe um serviço de gerenciamento de qualidade de contexto em redes de sensores sem fio que fornece facilidades para análise, processamento e entrega de dados de QoC às aplicações sensíveis ao contexto.

KEYWORDS: Redes de Sensores sem Fio; Aplicações Sensíveis ao Contexto, Qualidade de Contexto

1. INTRODUÇÃO

O conceito de Computação Pervasiva, sugerido por Weiser (1991), 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 e sem fio, microeletromecânica, tecnologias de sensores e sistemas embarcados (Yick et al. 2008) têm 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).

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 fonecidos 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. (Dey, 1999; Costa, 2007).

De acordo com (Henricksen & Indulska, 2004), as aplicações sensíveis ao contexto geralmente assumem que a informação contextual é completa e acurada; entretanto, como resultado de ruídos, falhas nos sensores e outros fatores, os dados sensoriados podem estar sujeitos a erros. Diante disso, 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.

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. (Buchholz et al., 2003), (Manzoor et al., 2008) e (Neisse et al., 2008) sugerem um conjunto de métricas de qualidade relevantes no escopo das aplicações sensíveis ao contexto, as quais podem ser usadas 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. De acordo com (Zimmer, 2006), (Manzoor et al., 2008) existem poucas aplicações que consideram informações de QoC sobre os dados adquiridos – ou o fazem de forma insatisfatória. 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.

Este artigo apresenta uma infraestrutura de gerenciamento de QoC que visa apoiar o desenvolvimento de serviços e aplicações sensíveis ao contexto que assumem a existência de imperfeição nos dados coletados. A solução proposta inclui a definição e a implementação de uma arquitetura conceitual que realiza a aquisição, avaliação e distribuição de contexto com QoC agregado e que permite a configuração flexível de requisitos de qualidade relativos às aplicações-clientes. O sistema fornece ainda um valor global de qualidade, calculado a partir da importância relativa de cada um dos parâmetros de qualidade.

O restante do artigo está assim organizado: a Seção 2 apresenta alguns trabalhos relacionados; a Seção 3 introduz um cenário de uso; a Seção 4 apresenta o modelo de métricas de QoC adotado e a arquitetura conceitual proposta; a Seção 5 trata da implementação realizada e, finalmente, a Seção 6 conclui o trabalho.

2. TRABALHOS RELACIONADOS

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 (Dey et al., 2000; Buchholz et al., 2003; Schmidt, 2004). Desde a introdução do termo Quality of Context (QoC), atribuída a (Buchholz et al., 2003), 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 (Manzoor et al., 2008; Krause & Hochstatter, 2005; Bu, 2006), exploraram a definição de novas métricas e processos de avaliação de QoC.

De acordo com (Buchholz et al., 2003; Krause & Hochstatter, 2005; Manzoor et al., 2008), 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; e (iv) Up-to-dateness (que em alguns trabalhos é citada como Freshness) – o quão recente é a informação recebida. Outros trabalhos, como (Gray & Salber, 2011; Toninelli, 2009), sugerem parâmetros como: Coverage, relevance e completeness. (Neisse et al., 2008) propõe um conjunto de métricas (Accuracy, Precision, Temporal Resolution) alinhadas com definições de qualidade do vocabulário da International Organization for Standardization (ISO).Em um linha de pesquisa paralela, na qual o presente trabalho se inclui, há a investigação de arquiteturas de avaliação de QoC, geralmente propostas como uma camada entre aplicações e as fontes de dados das quais dependem. Exemplos desta abordagem são os trabalhos de (Abid, 2009; Manzoor, 2010; Filho et al., 2010) e mais recentemente de (Zheng et al. 2012), que descrevem a integração de QoC a frameworks e sistemas de middleware provedores de contexto para o desacoplamento entre as aplicações e a heterogeneidade dos sensores de contexto e o uso dos mesmos para aferir qualidade e tratar contexto. (Abid, 2009) realiza a integração de QoC a um framework provedor de contexto já existente (COSMOS). Essa abordagem permite a comunicação de QoC como metadado na entrega de pacotes de dados contextuais ou separadamente, além de permitir a fácil extensão do serviço com novas métricas QoC. Em (Manzoor, 2010) é apresentada uma arquitetura centrada em serviço para inferir o valor de informações de contexto, agregando métricas QoC de acordo com requisitos de um dado serviço consumidor de contexto. (Filho et al., 2010) e (Zheng et al. 2012), apresentam arquiteturas com composições similares. De maneira geral, ambos propõem coleta ou obtenção de contexto (adaptação), avaliação de qualidade e entrega de dados, como componentes ou camadas básicas do processo. Ainda, (Zheng et al. 2012), apresenta os chamados planos de configuração de qualidade como uma forma de usuários (consumidores de contexto) ajustarem particularidades da avaliação de QoC para si.

Este trabalho lança mão de uma arquitetura semelhante à desses trabalhos, no entanto, há um esforço para torná-la mais centrada aos usuários do serviço, com uma interface rica e intuitiva, questão pouco atendida pelas soluções apresentadas. Nosso serviço permite, por meio de um front-end, por exemplo, a configuração das métricas e pesos relativos aos clientes de contexto (semelhante aos planos de configuração de qualidade de Zheng), monitoramento do processo de avaliação de QoC (estatísticas e gráficos) e simulação de um ambiente de RSSF, que facilita o ajuste do serviço para entrega de contexto de melhor qualidade por usuários não-desenvolvedores, mas especialistas do domínio do problema, i. e., profissionais de monitoramento de ar – como no cenário proposto a seguir.

3. CENÁRIO DE APLICAÇÃO

A poluição do ar está se tornando uma problema cada vez mais preocupante nas grandes cidades, com consequências sérias para a saúde das populações urbanas e impacto direto na rede hospitalar devido ao aumento do número de pacientes, principalmente crianças e idosos. Uma das causas que podem ser apontadas é o rápido aumento da frota de veículos que, aliado ao crescimento desordenado das grandes cidades, tem diminuído 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, por exemplo, equivale a fumar dois cigarros por dia. 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) do estado do Espirito Santo, apontou um aumento de 19% nas internações de adultos em dias mais poluídos na Grande Vitória.

De modo geral, as soluções de monitoramento de ar existentes são de alto custo e de baixa granularidade, pois as medidas são limitadas aos locais de presença das estações. Por exemplo, em uma região metropolitana como a da Grande Vitória, existem apenas nove estações de monitoramento em operação na Rede Automática de Monitoramento da Qualidade do Ar (RAMQAr) do IEMA. Essas questões prejudicam uma avaliação mais eficaz da qualidade do ar das metrópoles pois os resultados são sensíveis a arbitrariedade do posicionamento das estações (IEMA, 2013).

Uma alternativa barata frente aos elevados custos e complexidade das atuais redes de monitoramento da qualidade do ar é o Air Quality Egg (AQE) (Air Quality Egg, 2013), um projeto que propõe a criação de uma comunidade aberta de monitoramento da qualidade do ar de forma cooperativa (crowdsourcing). O projeto, de código aberto, engloba o hardware e software do sensor e o compartilhamento dos dados com as medidas atmosféricas como temperatura, umidade e de poluentes, realizadas pelos sensores que ficam disponíveis na infraestrutura de sensor-cloud da Xively que também faz parte do projeto AQE (XIVELY, 2013).

Os sensores AQE são capazes de monitorar temperatura, humidade, í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 (Air Quality Egg, 2013).

As pequenas dimensões e o baixo custo de dispositivos de sensoriamento similares ao AQE, fazem deles uma solução com potencial de alta granularidade, permitindo levar o serviço de monitoramento da qualidade do ar para qualquer local da cidade, ampliando consideravelmente a cobertura do serviço. Existem, entretanto, questões importantes que devem ser consideradas ao se optar por uma solução de mais baixo custo baseada em uma rede de sensores. Uma dessas questões é a necessidade de tratamento das eventuais imperfeições dos dados coletados. Uma solução de gerencimento de QoC, como a proposta neste trabalho, poderia ser integrada ao ambiente de monitoramento, provendo às aplicações clientes um conjunto de métricas que permitem medir a qualidade da informação contextual sendo adquirida pelos nós da rede. Além disso, as leituras podem ser salvas em banco de dados para acesso e processamento posterior.

4. ABORDAGEM PROPOSTA

Como discutido anteriormente, indicadores de QoC podem tornar as aplicações cientes da qualidade dos dados manipulados para que os utilizem da melhor forma na tomada de decisão. Apesar da reconhecida demanda de qualidade de contexto, deixar a implementação de avaliação de QoC à cargo das aplicações constitui um modelo pouco eficaz devido a fatores como o overhead de processamento de QoC sobre a aplicação e o não compartilhamento de dados de QoC entre aplicações interessadas num mesmo contexto. Desta forma, o tratamento de qualidade de contexto é geralmente abordado numa camada intermediária entre as aplicações e as fontes contextuais de interesse.

Baseada nessas premissas, nossa abordagem divide-se em três etapas: (i) a definição de modelo de métricas de QoC; (ii) proposta de arquitetura conceitual da camada de gerência de QoC com base no modelo formalizado e (iii) a realização da mesma como um serviço aplicado no cenário de monitoramento de ar proposto na Seção 3.

4.1 Modelo de Qualidade e Avaliação de QoC

Como ressaltado em (Nazário, Dantas & Todesco, 2012), ainda não foram criadas padronizações dos parâmetros de qualidade de contexto. Devido a grande variedade desses parâmetros, selecionamos cinco métricas recorrentemente sugeridas em trabalhos como (Gray & Salber, 2001; Buchholz, 2003; Toninelli, 2009): Coverage, Up-to-dateness, Frequency, Accuracy e Significance. Adotamos um valor geral de qualidade baseado nos sub-parâmetros de QoC mencionados, aplicando respectivos pesos de acordo com o tipo de dado contextual, como sugerido por (Yasar, 2011).

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: o valor aferido (escalar) e o timestamp da aferição.

Com base nas entidades apresentadas, 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. Também foi definida uma classe de funções de parâmetro de contexto f(C), que retorna valores arbitrários de parametrização de determinado Tipo de Contexto, por exemplo, min, max, lifespan, period, os quais eventualmente compõem as fórmulas das funções de QoC. A seguir, as métricas de QoC utilizadas neste trabalho são introduzidas.

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 (Kim & Lee, 2006), 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. Apesar da subjetividade do termo, nesta abordagem, a significância de um dado indica se esse pertence a um subconjunto de valores críticos definidos para o seu tipo. Este parâmetro pode ser usado para situações onde alguma ação é imediatamente necessária. Os valores críticos são avaliados por um conjunto de regras sobre o intervalo do valor escalar do dado de contexto.

As Tabela 1 e 2 apresentam, respectivamente, como são quantificadas as funções QoC e a definição de cada função de parâmetro de contexto.

Tabela 1. Métricas QoCMétrica Sigla Fórmula

Coverage

Up to dateness

Frequency

Accuracy

Significance

QoC Geral

Tabela 2. Funções de Parâmetro de ContextoFunção Definiçãomin(C) Valor mínimo para um contexto Cmax(C) Valor máximo para um contexto C

lifespan(C) Intervalo de validade de um contexto Cperiod(C) Periodo esperado entre leituras adquiridas de um contexto C

Porcentagem de variação entre dados consecutivos de um contexto C

O cálculo do QoC Geral (QoC(di)), como apresentado na Tabela 1, 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 Arquitetura Conceitual do Serviço

Na abordagem proposta, o tratamento de QoC é fornecido por uma camada entre as redes de sensores sem fio – as fontes contextuais – e as aplicações sensíveis ao contexto. Esta “Camada de QoC” implementa um serviço que realiza a aquisição, avaliação e distribuição de contexto com QoC agregado e permite a configuração de requisitos de qualidade relativos às aplicações-clientes. O tratamento de QoC dos dados obtidos das RSSF é feito por meio da geração de medidas de QoC (Manzoor, 2008), conforme discutido na seção anterior. A Fig.1 apresenta uma visão conceitual da arquitetura proposta.

Fig. 1. Arquitetura Conceitual

A arquitetura conceitual é constituída de quatro componentes principais: (i) Configuração de Métricas QoC e RSSF; (ii) Adaptador de Contexto; (iii) Avaliador de QoC; e (iv) Distribuidor de Contexto e QoC. O componente de configuração gerencia a parametrização da rede onde é definido o tipo de contexto, as medidas de qualidade desse tipo, o gateway que irá transmitir o contexto e a aplicação que deverá receber o contexto avaliado juntamente com as medidas de QoC geradas. Dessa forma, um tipo de contexto é definido por (i) sua fonte – no caso, um gateway de uma rede de sensores sem fio; (ii) a aplicação sensível ao contexto destino ou cliente; (iii) o tipo de dado sensoriado, e.g., temperatura, umidade, etc; e (iv) a parametrização dos requisitos de QoC, e.g., definição das situações em que esse contexto é considerado significante, intervalos de valores aceitáveis, definição dos pesos de cada métrica, etc. Todas as etapas do processo, desde a aquisição até a distribuição, dependem das configurações dos tipos de contexto.

O componente Adaptador de Contexto é responsável por receber os dados das fontes de contexto cadastradas, classificá-los por tipo de contexto, e instanciá-los na forma de uma entidade dado de contexto (d) e encaminhá-los ao módulo avaliador. Um entidade dado de contexto possui um tipo de contexto, um valor escalar e um timestamp de geração, que é a data e hora em que o contexto foi coletado ou gerado pelo simulador.

O componente Avaliação de QoC recebe os dados de contexto (d), realiza o tratamento com base nas parametrizações do respectivo tipo de contexto, gera e agrega um timestamp de avaliação e medidas de QoC repassando-os ao componente de distribuição de contexto, em uma abordagem tipicamente publish-subscribe (Eugster, 2001). Este componente, por sua vez, pode operar em dois modos: on-line ou off-line. No modo on-line, a distribuição é realizada em tempo real, entregando dados de contexto e QoC agregado proativamente à respectiva aplicação. No modo off-line, a aplicação realiza uma requisição ao serviço, especificando uma janela de tempo ou quantidade máxima de dados contextuais que devem ser entregues, o serviço por sua fez realiza uma consulta na base de dados histórica e entrega o seu resultado a aplicação solicitante no mesmo formato que o módulo on-line faz, ou seja, dado de contexto com as medidas de QoC geradas.

Além desses quatro módulos, a figura 1 mostra um componente chamado de simulador. Esse componente foi criado para avaliar e simular a utilização do serviço proposto em um ambiente controlado, onde poderam

ser incluídos com facilidade vários tipos de dados em várias redes de sensores. O simulador foi incluído na arquitetura, no entanto ele não é um módulo essencial para o funcionamento do serviço.

5. SERVIÇO DE GERÊNCIA DE QUALIDADE DE CONTEXTO

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 Fig. 2.

Fig. 2. Arquitetura de Implementação

O SGQoC Front-End é o módulo de interface com o usuário. Por meio dele, são definidos os Tipos de Contexto (CtxType) de cada RSSF que o serviço irá manipular e as configurações das medidas de QoC, ou seja, esse módulo implementa o componente Configuração de Métricas QoC e RSSF apresentada na seção de Arquitetura. Essas definições e configurações das redes e das métricas de QoC são gravadas na base de dados do sistema (representado pela interação 1 da Fig. 2) para posterior utilização pelos demais módulos. Utilizando o módulo Front-End, é possível acessar o módulo de simulação (Context Generator) e monitorar em tempo real as atividades de avaliação de contexto por meio de relatórios e estatísticas. A tabela 3 apresenta a configuração de dois tipos de contexto (PM10@RSSF1 e PM10@RSSF2) monitorados no cenário proposto na Seção 3. Nele são associados o gateway de origem do dados e a aplicação a qual o dado se destina. Além disso, são informados os dados de parametrização que serão considerados no cálculo das métricas de QoC. Para efeitos de teste foram adotados pesos iguais para todas as métricas (peso 1).

Tabela 3. Parametrização de Tipos de Contexto (CtxType).

Parametrização para Gerar Métricas de QoC RSSF

CtxType min-max lifespan period consecutive_var Gateway AplicaçãoPM10@RSSF1 ~0-500 g/m3 3600 s 5 s 10% 2001:db8:0:1200:fe0::1 App1@localhost:80PM10@RSSF2 ~0-500 g/m3 3600 s 15 s 10% 2001:db8:0:1200:fe0::2 App2@localhost:80

O Context Adapter lida com a construção de instâncias de CtxData – objeto que representa uma unidade de dado de contexto – provenientes de uma fonte de contexto, por exemplo, um gateway de uma RSSF. Nossa implementação oferece um componente de simulação, o Context Generator, que age como um facilitador do processo de desenvolvimento e validação da solução. Com base no CtxType configurado, ele é capaz de simular uma RSSF geradora de contexto, aplicando deficiências de qualidade, e.g., adição de ruídos, durante sua geração.

Uma vez instanciado, 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 4.1 e as aplicam às instâncias CtxData de um CtxType específico.

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. Esse sub-componente também instancia um CtxEval ao detectar que algum tipo de contexto recebido não foi processado pelo serviço imediatamente.

A Tabela 4 apresenta um trecho da execução do Context Generator para a simulação do cenário de monitoramento de qualidade do ar. Nesta tabela pode-se observar o CtxData e QoCData resultantes do processamento do contexto PM10@RSSF1, que representa a concentração (g/m3) da partícula PM10 aferida por uma determinada rede de sensores.

Tabela 4. CtxData e QoCData para PM10.

CtxData QoCData

ContextType

Source Value

Final Value

GenerationTime

ArrivalTime

C U A F S QoC

PM10 @RSSF1 20.6 20.6 20:58:01 20:58:02 1 1 1 1 0 0.8PM10 @RSSF1 21.06 21.06 21:02:05 21:02:07 1 1 1 1 0 0.8PM10 @RSSF1 50.24 21.06 21:10:09 21:10:12 1 1 0 1 0 0.6PM10 @RSSF1 20.72 20.72 21:13:13 21:13:15 1 1 1 1 0 0.8PM10 @RSSF1 20.87 20.87 21:17:17 21:17:19 1 1 1 1 0 0.8

O processo de simulação permite definir o número de sensores e uma respectiva distribuição de probabilidade, e.g, uniforme, normal, poisson, exponencial ou triangular, para geração de seus dados. A linha destacada na Tabela 3 indica um erro induzido na simulação que afeta o valor de Accuracy do dado. Em casos como este - onde QoC de dado é insatisfatório - o CtxEval é capaz de aplicar medidas de tratamento pós-avaliação de QoC. São possíveis sua rejeição, correção ou manter como está. O primeiro caso consiste no descarte do CtxData; o segundo, em manter o valor erro e por último, na repetição do valor do último CtxData com QoC aceitável. Este último foi aplicado na simulação (observe que o atributo Final Value replicou o valor da leitura anterior).

A Figura 3 ilustra o front-end do serviço durante a execução da simulação, com o tratamento por correção sendo aplicado ao longo do processo, e seu impacto nos dados destinados às aplicações. Pode-se ver que a simulação gerou picos de aproximadamente 50 g/m3 em um sinal de entrada, cujo valor médio é 20 g/m3, enquanto a saída foi ajustada conforme a configuração de QoC definida pela aplicação (repetir medição anterior).

Fig. 3. Comparação entre entrada de dados com ruído e saída com correção

Com os processos de avaliação de QoC e eventual tratamento do dado, CtxData e seu respectivo QocData são armazenados no banco de dados do serviço (interação 5), os quais podem ser posteriormente utilizados pelas aplicações. Na implementação atual, a interação 6 é feita por meio de um componente de integração que deve estar presente na aplicação cliente, o SGQoC Client, que realiza a abordagem off-line de distribuição de contexto, como apresentada na Seção 4.

6. CONCLUSÕES

Esse trabalho propôs uma infraestrutura para avaliação de qualidade da informação de contexto proveniente de redes de sensores sem fio (RSSF). O objetivo é a entrega de contexto enriquecido com informações de QoC (Quality of Context) à aplicações clientes. A abordagem proposta permite a seleção e especificação de

métricas de QoC e o protótipo desenvolvido é capaz de avaliar contexto de diferentes fontes e aplicar correções em dados contextuais antes de entregá-los as aplicações interessadas. Além disso, ele oferece um front-end de monitoramento que permite aos desenvolvedores acompanharem estatísticas do processo de sensoriamento em tempo real. Um exemplo de uso foi mostrado em um cenário de monitoramento de qualidade do ar, ilustrando o potencial de aplicação do sistema proposto.

Desenvolvimento futuros da infraestrutura incluem: (i) desenvolvimento de uma API para integração dos gateways das redes de sensores sem fio com o SGQoC; (ii) indução de outros tipos de degradação de qualidade durante a simulação, e.g., atraso e inconstância no envio de dados. (iii) proposta de novas políticas de correção de dados, e.g, implementação de padrão publish-subscribe para o desenvolvimento da distribuição de contexto (Context Publisher) e uma API para facilitar a integração das aplicações-clientes ao serviço.

REFERÊNCIAS

Weiser, M. 1991, The computer of the 21st century. Scientific American, pp. 94–104Yick, J. et al. 2008, Wireless sensor network survey, Computer Networks, vol. 52, no. 12, pp. 2292–2330.Dey, A.K. & Abowd, G.D. 1999. Towards a better understanding of context and context-awareness. GVU Technical

Report GITGVU-99-22, College of Computing, Georgia Institute of Technology. pp. 304—307.Costa, P.D., 2007, Architectural Support for Context-Aware Applications: From Context Models to Services Platforms,

Ph.D. Thesis, University of Twente.Henricksen, K., Indulska, J. 2004, Modelling and Using Imperfect Context Information. Proceedings of the Second IEEE

Annual Conference on Pervasive Computing and Communications Workshops, pp. 33–37.Buchholz, T. et al. 2003. Quality of Context: What It Is And Why We Need It. In Proceedings of the 10th Workshop of the

HP OpenView University Association.Manzoor, A.et al. 2008. On the Evaluation of Quality of Context. 3rd European Conference on Smart Sensing and

Context, pp. 140–153.Neisse, R. et al 2008. Trustworthiness and Quality of Context Information. In Proceedings of the 9th International

Conference for Young Computer Scientists (ICYCS’08), pp. 1925-1931.Zimmer, T. 2006. QoC: Quality of Context – Improving the Performance of Context-Aware Applications. Advances in

Pervasive Computing 2006, Dublin, Ireland, pp. 209–214.Dey, A.K. 2000. Providing Architectural Support for Building Context-Aware Applications. Ph.D. Thesis. Georgia

Institute of Technology.Schmidt, A., 2004. Management of Dynamic and Imperfect User Context Information. In: R.Meersman et al (Eds), OTM

Workshops, LNCS 3292, pp.779-786. Krause, M. and Hochstatter, I. 2005. Challenges in Modelling and Using Quality of Context (QoC). Mobility Aware

Technologies and Applications, pp. 324–333.Bu, Y. et al 2006. Managing quality of context in pervasive computing. In Proceedings of the 6th International

Conference on Quality Software. , pp. 193–200.Gray, P., and Salber, D. 2001. Modelling and Using Sensed Context Information in the design of Interactive Applications.

In LNCS 2254: Proceedings of 8th IFIP International Conference on Engineering for Human-Computer Interaction (EHCI 2001), Toronto, Canada. pp. 317–336.

Toninelli, A. et al., 2009. A quality of context-aware approach to access control in pervasive environments, MobileWireless Middleware, Operating Systems, and Applications: LNCS, v. 7, p. 236–251.

Abid, S. Z. et al., 2009. A framework for quality of context management, in Proceedings of the 1st international conference on Quality of context, pp. 120–131.

Manzoor, A. et al., 2010. Service-centric Inference and Utilization of Confidence on Context. Services Computing Conference (APSCC), pp. 11-18.

Filho, J. B. et al., 2010.Modeling and Measuring Quality of Context Information in Pervasive Environments. In Proceedings of the 24th IEEE International Conference on Advanced Information Networking and Applications, 690-697.Zheng, D. et al. 2012. Evaluation of Quality Measure Factors for the Middleware Based Context-Aware Applications. In

Proceedings of the 11th International Conference on Computer and Information Science, pp. 403-408.IEMA, 2013. Rede automática de monitoramento da qualidade do ar da região da grande vitória. Portal do Governo do

Estado do Espírito Santo. Disponível em: <http://www.meioambiente.es.gov.br/default.asp> Acesso em 21 ago 2013.Air Quality Egg, 2013. A community-led air quality sensing network that gives people a way to participate in the

conversation about air quality. 2013. Disponível em: <http://www.kickstarter.com/projects/edborden/air-quality-egg> Acesso em 22 ago 2013.

XIVELY, 2013. Xively is the Public Cloud specifically built for the Internet of Things. 2013. Disponível em: < https://xively.com/whats_xively/> Acesso em: 21 ago 2013.

Nazário, D. C., Dantas, M. A. R., Todesco, J. L. 2012. Taxonomia das publicações sobre Qualidade de Contexto Sustainable Business International Journal, v. 20, pp. 1–28.

Yasar, A. U. H. et al. 2011. When efficiency matters: Towards quality of context-aware peers for adaptive communication in VANETs. IEEE Intelligent Vehicles Symposium (IV), pp. 1006–1012.

Kim, Y. and Lee, K. 2006. A quality measurement method of context information in ubiquitous environments. In ICHIT ’06: Proceedings of the 2006 International Conference on Hybrid Information Technology, pp. 576–581.

Eugster, P.T., et al. 2003, The many faces of publish/subscribe, ACM Computing Surveys, ACM, pp. 114-131.