3.4 Soluções Envolvendo a SITRUS
4.3.1 Low Power Listening
O gerenciamento de energia do RAMSES é auxiliado pela utilização da interface Low Power Listening, fornecida pelo TinyOS. Ela gerencia de forma mais eficiente as operações de controle de acesso ao meio (MAC), em que o rádio é desligado durante uma percentagem do tempo e apenas ligado periodicamente.
A implementação se baseia no método Clear Channel Assessments (CCA) (JOGI;
VIDHATE, 2013), para determinar se há um transmissor nas proximidades, verificando se o canal de comunicação está livre, evitando assim colisões. Isso permite ao receptor desligar o rádio e determinar que não há transmissores em um período muito curto de tempo ao invés de deixar o rádio ligado tempo suficiente para receber um pacote completo.
Os transmissores realizam a entrega de mensagens por transmitir o pacote completo repetidas vezes pelo dobro da duração do período de atividade (duty cycle) do receptor. Transmitir pelo dobro do tempo aumenta a probabilidade de que a mensagem será detectada pelo receptor e permite ao receptor diminuir o tempo que necessita para manter o seu rádio ligado.
Tipicamente, um pacote transmitido usando a interface Low Power Listening segue o formato apresentado pela Figura 4.2. O Backoff é o período necessário para fazer a checagem do meio de transmissão e verificar se o canal está livre para envio de dados. Já o Ack Wait é o período necessário para o receptor enviar uma mensagem de confirmação.
+−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−+
| B a c k o f f | P a c k e t Tx | Ack W a i t |
+−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−+
Figura 4.2: Formato de um pacote em Low Power Listening
Para diminuir a quantidade de tempo necessária para uma verificação de recebimento, o canal deve ser modulado pelo transmissor sempre que possível. O único período onde o canal é modulado é durante a fase de transmissão de pacotes. O receptor deve constantemente realizar amostras de leitura no CCA por um momento maior que o período de Backoff e Ack Wait juntos, para sobrepor o período de transmissão de pacotes.
Ao fazer o período de Backoff o mais curto possível, pode-se diminuir a quantidade de tempo que o rádio do receptor deve estar ligado enquanto executa uma verificação de recebimento. No entanto, isto também aumenta a probabilidade de colisão ou captura do canal.
Se dois transmissores tentam transmitir utilizando a interface Low Power Listening, um transmissor pode capturar o canal se o seu período de Backoff está muito curto. Nós sensores transmitindo ao mesmo tempo irão causar interferência e impedir outros nós sensores de entregar com sucesso as suas mensagens para o destinatário pretendido.
Usar essa interface tipicamente envolve definir um duty cycle para os nós sensores a partir do evento Boot.booted() em uma aplicação nesC (linha 2). Esse evento é disparado logo no início da aplicação para configuração do nó sensor e inicialização das atividades da antena de rádio (linha 3). Para cada pacote que a aplicação precisa enviar, o duty cycle do seu nó destino é então especificado como um metadado, de modo que o número correto de preâmbulos possa ser estabelecido para ele. O trecho de código apresentado pela Figura 4.3 demonstra esse padrão de uso. 1 e v e n t v o i d B o o t . b o o t e d ( ) { 2 c a l l L o w P o w e r L i s t e n i n g . s e t L o c a l S l e e p I n t e r v a l ( INTERVAL ) ; 3 c a l l R a d i o C o n t r o l . s t a r t ( ) ; 4 } 5 6 e v e n t v o i d R a d i o C o n t r o l . s t a r t D o n e ( e r r o r _ t e ) { 7 i f ( e ! = SUCCESS ) 8 c a l l R a d i o C o n t r o l . s t a r t ( ) ; 9 }
Figura 4.3: Código Utilizado para Inicialização de um Nó Sensor Usando Low Power Listening
A interface RadioControl, fornecida pelo componente CC2420ActiveMessageC, é usada para permitir as operações de rádio em Low Power Listening a partir de antenas CC2420, que são as adotadas em motes MICAz e TelosB.
Uma vez que o comando RadioControl.start() seja concluído, o rádio começa a seu duty cycle, conforme especificado pelo parâmetro para o comando setLocalSleepInterval().
O middleware RAMSES foi implementado de forma mais genérica possível, tentando contemplar uma quantidade razoável de hardwares diferentes executando o mesmo middleware. Dessa forma, é apresentado na Figura 4.4 um código de configuração do componente Active-
Messagepara transmissão de dados utilizando a interface Low Power Listening correta para
tipos diferentes de motes (TelosB, TMote, MICAz, Z1, MICA2, IRIS e UCMINI), como pode ser observado nas linhas 1, 2, 7 e 12, associado aos seus hardwares de transmissão de rádio correspondentes (CC2420 e CC1000), nas linhas 3, 8 e 13.
4.3. IMPLEMENTAÇÃO 55 1 # i f d e f i n e d ( PLATFORM_TELOSB ) | | d e f i n e d (PLATFORM_TMOTE) | | \ 2 d e f i n e d ( PLATFORM_MICAZ) | | d e f i n e d ( PLATFORM_Z1 ) 3 c o m p o n e n t s CC2420ActiveMessageC a s L P L P r o v i d e r ; 4 App . LPL −> L P L P r o v i d e r ; 5 # e n d i f 6 7 # i f d e f i n e d ( PLATFORM_MICA2 ) 8 c o m p o n e n t s CC1000CsmaRadioC a s L P L P r o v i d e r ; 9 App . LPL −> L P L P r o v i d e r ; 10 # e n d i f 11 12 # i f d e f i n e d ( PLATFORM_IRIS ) | | d e f i n e d ( PLATFORM_UCMINI ) 13 c o m p o n e n t s A c t i v e M e s s a g e C a s L P L P r o v i d e r ; 14 App . LPL −> L P L P r o v i d e r ; 15 # e n d i f
Figura 4.4: Configuração da Interface LowPowerListening por Tipo de Plataforma
4.3.2
Componente Middleware
O componente Middleware, apresentado na Figura 4.5, encapsula os componentes da
Camada de Serviçose da Camada de Distribuição da arquitetura proposta, oferecendo para a
aplicação suporte aos serviços do middleware e o modelo de distribuição desenvolvido. Ao fazer isso, a complexidade do modelo de distribuição e os serviços providos pelo middleware são oferecidos de forma transparente.
Middleware MiddlewareM Middleware ServiceLayerC ServiceLayer DistributionLayerC DistributionLayer OscilloscopeC Oscilloscope
Figura 4.5: Componente Middleware
comando sendData interage diretamente com o componente ServiceLayer, a partir dos algoritmos de agregação de dados. Caso o algoritmo de agregação esteja parametrizado para realizar a tarefa, os dados apenas serão repassados para a Camada de Distribuição após a conclusão da agregação de dados. Por exemplo, se algoritmo estiver parametrizado para utilizar como base de cálculo a média e que 10 amostras serão utilizadas para o cálculo, apenas após o cálculo da média dessas 10 amostras os dados são repassados para a Camada de Distribuição.
Já o comando createTopic interage diretamente com o componente DistributionLayer, associando um tópico para a aplicação. Por padrão, cada aplicação está associada a apenas um tópico, e por consequência, só poderá transmitir dados associados a esse tópico, economizando assim energia na transmissão caso diversos tópicos diferentes estejam interagindo em uma mesma RSSF.
O desenvolvedor de aplicações que deseja utilizar o RAMSES precisa apenas adicionar o módulo Middleware à sua aplicação para ter acesso à interface com as operações disponíveis. Dessa forma, a aplicação poderá utilizar o modelo de comunicação publish/subscribe e ter acesso aos serviços de reconfiguração e agregação de dados, pois o Módulo de Processamento Semântico da Informação (SIP) é quem decide o momento de alterar parâmetros de tais serviços e o RAMSES executa as ações de reconfiguração a partir dessas mensagens. Para a aplicação, esses serviços são executados de forma transparente.
4.3.3
Componente TransportLayer
O componente TransportLayer, apresentado na Figura 4.6, implementa a Camada de
Transporteda arquitetura proposta. Assim, ele é o responsável pela transmissão e aquisição
de dados. Pare realizar tal tarefa, o TransportLayer interage diretamente com as primitivas de transporte de dados do TinyOS.
TransportLayer TransportLayerM TransportLayer CC2420ActiveMessageC LowPowerListening AMReceiverC Receive AMSenderC AMSend Packet ServiceLayerC ServiceLayer
Figura 4.6: Componente TransportLayer
Ele provê uma interface com duas operações: send e receive. O comando send, com seu código de transmissão de dados apresentado pela Figura 4.7, tem por finalidade montar a
4.3. IMPLEMENTAÇÃO 57 mensagem que será enviada aos componentes remotos. Por fim, é feita uma chamada ao módulo AMSend, fornecido pelo TinyOS, para que os dados sejam enviados pela rede.
1 command v o i d T r a n s p o r t L a y e r . s e n d ( m e s s a g e _ t * b u f P t r , i n t 8 _ t s i z e ) { 2 i f ( l o c k e d ) {
3 r e t u r n ; 4 } e l s e {
5 c a l l L o w P o w e r L i s t e n i n g . s e t R x S l e e p I n t e r v a l ( b u f P t r , INTERVAL ) ;
6 i f ( c a l l AMSend . s e n d (AM_BROADCAST_ADDR, b u f P t r , s i z e ) == SUCCESS ) { 7 p a c k e t = b u f P t r ; 8 l o c k e d = TRUE ; 9 } e l s e { 10 p o s t r e t r y S e n d T a s k ( ) ; 11 } 12 } 13 }
Figura 4.7: Código Utilizado para Transmissão de Dados Utilizando o RAMSES
A invocação do comando setRxSleepInterval com um intervalo de suspensão específico, linha 5, permite enviar o número correto de preâmbulos para a mensagem especificada em sua lista de parâmetros. Assim, o processo de transmissão de dados ocorre em Low Power Listening.
O comando receive tem por finalidade processar a aquisição de dados provenientes da estação base. Para realizar tal tarefa, é utilizado o módulo AMReceiver, também fornecido pelo TinyOS.
Sempre que uma nova mensagem enviada pela estação base é recebida, ou seja, foi transmitida pelo Módulo de Processamento Semântico da Informação (SIP), essa mensagem é direcionada ao componente ServiceLayer, para que a mensagem possa ser processada e sua reconfiguração executada.
Toda comunicação entre os nós da RSSF e a estação base é baseada no paradigma Active
Message(BUONADONNA; HILL; CULLER, 2001), usando baixo consumo de energia na
comunicação. De acordo com esse paradigma, cada mensagem contém um ID de uma rotina de tratamento a ser invocada no nó sensor alvo e um payload contendo os dados a serem passados como argumento. Esta comunicação baseada em eventos e orientada a mensagens faz do TinyOS uma boa solução para a construção de uma infraestrutura de comunicação publish/subscribe.
4.3.4
Componente DistributionLayer
O componente DistributionLayer, apresentado na Figura 4.8, implementa a Camada de
Distribuiçãoda arquitetura proposta, provendo uma interface com três operações: createTopic,
publishe subscribe.
Para que um pacote possa ser montado, ter seus dados lidos ou enviados para transmis- são, o componente DistributionLayer utiliza o componente CC2420ActiveMessageC em sua implementação, que é responsável pelo acesso aos dados de um pacote. Todas essas operações são realizadas utilizando baixo consumo de energia.
DistributionLayer DistributionLayerM DistributionLayer CC2420ActiveMessageC Packet TransportLayerC TransportLayer ServiceLayerC ServiceLayer
Figura 4.8: Componente DistributionLayer
Sempre que uma mensagem está pronta para ser publicada, com todas as suas informações preenchidas, é executado o comando Send do componente TransportLayer para transmissão dessa mensagem. Assim, todas as operações de aquisição e transmissão de dados ficam em uma camada diferente das operações de criação, assinatura e publicação de tópicos e mensagens, de forma que cada camada tenha suas responsabilidades bem definidas.
Antes de publicar uma mensagem, alguns metadados precisam ser preenchidos, por exemplo, a taxa de amostragem atual de um nó sensor e a quantidade de dados agregados por mensagem. Esses metadados são utilizados pelo Módulo de Processamento Semântico da Informação (SIP) para o processamento sobre o estado atual do nó sensor.
O diagrama de sequência da Figura 4.9 mostra a interação entre diversas camadas do
middleware RAMSES e o SIP para o anúncio e assinatura de tópico dos nós sensores. Por
padrão, cada aplicação está associada a apenas um tópico, que também pode ser alterado durante a execução da aplicação. Assim, a partir da criação do tópico pelo nó sensor, imediatamente ele está assinando sua participação.
A aplicação anuncia ao componente Middleware a operação de sensoriamento (tempe- ratura, umidade, luz, dentro outros) que está sendo realizada e envia como parâmetro através do método createTopic, que por sua vez encaminha a mensagem para o componente Distributi- onLayer. O anúncio de tópicos não é direcionado aos demais nós da rede, mas apenas para o SIP, que armazena essa informação em sua base de dados semântica. Para realizar tal tarefa, o componente DistributionLayer executa o método subscribe, com o tópico como parâmetro, para o componente TransportLayer, de modo que a mensagem possa ser transmitida até o SIP.
A interação na parte inferior da Figura 4.9 refere-se à ocorrência de alterações de tópicos pelo SIP ou a não associação de um tópico pela aplicação sendo executada no nó sensor no início da execução. Para os dois casos, a execução é a mesma. Caso a aplicação altere seu tipo de
4.3. IMPLEMENTAÇÃO 59
Figura 4.9: Diagrama de Sequência para Anúncio e Assinatura de Tópico
sensoriamento, como requisito da própria aplicação ou por reconfiguração enviada pelo SIP, seu tópico também precisa ser alterado. Dessa forma, o SIP envia uma mensagem para o nó sensor com as novas informações sobre o novo tópico. Essa mensagem é recebida pelo componente
TransportLayere encaminhada para o componente ServiceLayer, a partir do comando receive.
Após essa etapa, é feita uma chamada ao comando setTopic do componente DistributionLayer, e com isso, a partir do novo tópico que foi enviado por parâmetro, o nó sensor tem seus dados atualizados com o novo tópico associado a ele.
A Figura 4.10 apresenta como os dados monitorados pelos nós sensores são publicados na rede até sua chegada no SIP. A aplicação periodicamente coleta dados de sensoriamento e os envia para o componente Middleware através do comando sendData. Com isso, os dados são encaminhados para o componente ServiceLayer, para que seus dados sejam processados pelos serviços existentes, por exemplo, o serviço de agregação de dados. Com esses dados processados e prontos para serem enviados, o comando publish é executado e a mensagem segue seu fluxo até o SIP, a partir da estação base.
Finalmente, a interação na parte inferior da Figura 4.10 ocorre quando uma mensagem chega a um nó sensor a partir de outro nó sensor. O componente TransportLayer, ao receber uma mensagem, encaminha-a para o componente ServiceLayer, a partir do comando receive. Neste componente é feita uma comparação do tópico recebido pela mensagem com o tópico correspondente do nó sensor, a partir do comando getTopic do componente DistributionLayer. Caso sejam do mesmo tópico, a mensagem segue seu fluxo com a execução do comando
publishaté chegar a outro nó sensor ou ao SIP, a partir da estação base. Caso o nó sensor não
Figura 4.10: Diagrama de Sequência para Publicação de uma Mensagem
desnecessárias sejam enviadas e economiza-se energia a partir da transmissão de dados pela rede.
4.3.5
Componente ServiceLayer
O componente ServiceLayer, apresentado na Figura 4.11, implementa a Camada de
Serviços da arquitetura proposta. Ele provê uma interface com operações responsáveis pela
checagem e alteração da taxa de amostragem, com os comandos getPeriodicSampling e setPe- riodicSampling; checagem e alteração da quantidade de dados agregados, com os comandos
getAggregationSize e setAggregationSize; por receber as mensagens do SIP e processar os
seus dados, a partir do comando receive; e finalmente, enviar mensagens para o componente DistributionLayer, para que essas possam ser enviadas pela RSSF, através do comando sendData.
Sempre que a aplicação precisa enviar seus dados de sensoriamento pela RSSF, estes são enviados pelo componente Middleware até chegar ao componente ServiceLayer, onde seus dados serão processados e, apenas depois dessa etapa, é que esses dados serão encaminhados para o componente DistributionLayer, como apresentado anteriormente pela Figura 4.10.
Uma das responsabilidades do componente ServiceLayer é a execução do serviço de agregação de dados, apresentado pela Figura 4.12 a partir de suas interações. Sempre que um novo dado de sensoriamento é enviado do componente Middleware para o componente ServiceLayer, o serviço implementado pelo componente AggregationService é executado. As mensagens que são transmitidas por outros nós sensores não são novamente agregadas, apenas repassadas para o componente DistributionLayer após a verificação do tópico, como apresentado
4.3. IMPLEMENTAÇÃO 61 ServiceLayer ServiceLayerM ServiceLayer AggregationServiceC AggregationService DistributionLayerC DistributionLayer ConfigurationServiceC ConfigurationService MiddlewareC Middleware
Figura 4.11: Componente ServiceLayer
anteriormente pela Figura 4.10.
Figura 4.12: Diagrama de Sequência para Agregação de Dados
Para realizar a execução do serviço de agregação, o comando aggregate é invocado com os parâmetros do tamanho da amostra (size) e um vetor (sample) do tamanho da amostra preenchido com dados de sensoriamento. Após a execução do serviço de agregação, com o dado agregado já processado, ele segue o fluxo de publicação pelo componente DistributionLayer.
Toda mensagem transmitida do SIP para um determinado nó sensor é processada pelo componente ServiceLayer para que o serviço de reconfiguração desse nó sensor seja executado, a partir do componente ConfigurationService. A Figura 4.13 apresenta a interação de como o processo de reconfiguração a partir de mensagens do SIP ocorre.
Faz parte das mensagens enviadas pelo middleware um campo numerado que corresponde ao código de reconfiguração do SIP. O objetivo desse campo é definir que tipo de operação será
Figura 4.13: Diagrama de Sequência para as Mensagens Recebidas do SIP para Reconfiguração
executada pelo nó sensor no componente ServiceLayer, a partir do momento que receber uma mensagem.
Durante a transmissão de dados entre nós sensores até a estação base, o valor desse campo está configurado como 0, indicando que não existe nenhuma operação de reconfiguração a ser executada. Qualquer outro valor significa que o SIP enviou uma mensagem de reconfiguração para o nó sensor. O processo de reconfiguração pode ser observado pelo diagrama de sequência apresentado pela Figura 4.13. Por exemplo, se o campo correspondente for encaminhado com o número 3, indica que a taxa de amostragem deve ser alterada pelo novo valor também transmitido na mensagem.
4.4. CONSIDERAÇÕES FINAIS 63
4.4
Considerações Finais
Este capítulo apresentou o RAMSES, um Middleware Ciente de Reconfiguração para Rede de Sensores Sem Fio responsável pelo transporte de dados e gerenciamento de serviços das aplicações executadas nos nós sensores.
5
SIP: Módulo de Processamento Semântico
da Informação
Este capítulo apresenta o SIP (acrônimo em inglês para Semantic Information Processing
Module) (BISPO; ROSA; CUNHA,2012), o módulo da SITRUS responsável pela manipulação
de dados das Redes de Sensores Sem Fio. O SIP categoriza e instancia os dados de forma adequada em uma ontologia, e gera a base de dados semântica utilizada para a tomada de decisões de reconfiguração dos nós sensores e a realização de consultas.
As próximas seções apresentam o funcionamento do SIP de forma mais detalhada. Primeiro, uma visão geral do módulo será introduzida. Em seguida, será discutida sua arquitetura em camadas e como elas se comunicam para formar o módulo de processamento semântico. Depois, será descrita a ontologia desenvolvida, com suas classes e relacionamentos. Além disso, a implementação da arquitetura é analisada a partir de suas funcionalidades e diagramas. Por fim, serão apresentadas as considerações finais do SIP.
5.1
Visão Geral
O Módulo de Processamento Semântico da Informação (SIP) interage com a Camada
Semânticada arquitetura da SITRUS. Por conta disso, o SIP tem que executar todo o processa-
mento relacionado à ontologia, bem como estabelecer mecanismos relacionados às consultas realizadas por aplicações.
O SIP foi totalmente desenvolvido em Java e todas as RSSFs são conectadas ao SIP a partir de suas respectivas estações base. Para poder prover comunicação com as RSSFs, foi
utilizada uma API de comunicação e manipulação de dados do TinyOS (LEVIS et al.,2005), a
TinyOS API, que transmite e recebe dados serializados pela rede.
Além da TinyOS API, outra ferramenta utilizada para construção do Módulo de Pro- cessamento Semântico da Informação, mais precisamente para manipulação das ontologias,
foi o framework Jena1(YU,2014;MCBRIDE,2002). O Jena é um framework de suporte ao
5.2. ARQUITETURA 65 uso da Web Semântica em aplicações Java, onde esse suporte inclui recursos para manipulação
de linguagens Resource Description Framework (RDF) (LASSILA, 2004) e Web Ontology
Language(OWL) (MCGUINNESS; HARMELEN,2004).
Uma das funções básicas do Módulo de Processamento Semântico da Informação é a geração da base de dados semântica, onde seu processamento é realizado após receber os dados das RSSFs. Todos os dados das RSSFs são enviados de suas respectivas estações base e possuem informações sobre o sensoriamento do ambiente (luminosidade, umidade ou temperatura, por exemplo) e metadados referentes ao estado dos nós sensores (quantidade de dados agregados do nó sensor por mensagem, identificador do nó sensor, taxa de amostragem, dentro outros).
Após o processamento desses dados recebidos, o SIP instancia esses dados na onto- logia que foi desenvolvida para ele, assim, os dados obtidos das RSSFs são categorizados e instanciados na ontologia de forma correta. Dessa forma, podemos inferir novos dados, buscar relacionamentos de dados dentro de uma mesma RSSF ou entre redes diferentes.
Com os dados recebidos, instanciados e processados para a construção da base de dados semântica, outra função importante é o processamento de consultas. Consultas sobre a rede não mais precisam ser feitas diretamente sobre as RSSFs. Todas as consultas são realizadas na base de conhecimento gerada, obtendo assim dados mais precisos e relacionados com outras informações, e evitando com isso ambiguidades, respostas incorretas e acesso direto à RSSF.
Uma questão importante sobre a base de dados semântica é por quanto tempo um dado é considerado atual. Esse é um problema que envolve o tipo de aplicação, sensoriamento ou a necessidade da consulta a ser realizada. Assim, deixamos para o cliente (usuário, aplicação ou o próprio SIP) decidir a relevância temporal do dado a ser consultado.
Outra possibilidade do SIP é o processamento interno de consultas. O SIP também realiza consultas automáticas sobre o estado das RSSFs e seus nós sensores. Com isso, podemos checar se algum nó sensor atingiu algum limiar pré-estabelecido que determina um consumo de energia desnecessário, e caso tenha alcançado, uma mensagem de reconfiguração será enviada para este nó sensor, com o objetivo de normalizar seu comportamento. Por exemplo, se diversos nós sensores em uma mesma região estão coletados dados iguais de temperatura do ambiente, alguns desses nós serão desligados temporariamente, evitando assim a redundância de dados.
As próximas seções detalham o funcionamento de cada uma das etapas de desenvolvi- mento do Módulo de Processamento Semântico da Informação.
5.2
Arquitetura
Nesta seção, será apresentada a arquitetura do Módulo de Processamento Semântico da Informação (SIP). Como ilustrado na Figura 5.1, a arquitetura do SIP é dividida em camadas. Todas as camadas e suas funcionalidades serão discutidas a seguir.
Figura 5.1: Arquitetura do Módulo de Processamento Semântico da Informação (SIP)