Skip to content

2.1 Módulo SensorNet

Jump to bottom Edit New page
Felipe Santos edited this page Mar 26, 2015 · 1 revision

#SensorNet

##Descrição O SensorNet é o módulo que monitora a rede física e emite alertas para eventos de modificações na rede de sensores, no coletor e no sensor. O SensorNet está vinculado a rede física, mapeando a rede de sensores para o mundo computacional.

##Funcionalidades

A função do SensorNet no framework é monitorar o funcionamento da rede sensores através das mensagens recebidas de algum Colletor. Esses dados são persistidos em um banco de dados e, com isso, o SensorNet se torna apto a inferir sobre a quantidade de nós sensores na rede, a quantidade de rede e todos os coletores existentes em uma rede de sensores. O SensorNet suporta:

  1. O mapeamento de diversas redes sensores;
  2. Diversos coletores por rede;
  3. Verificação periódica do estado de funcionamento de um sensor.

###Consumo de dados do coletor Para o SensorNet iniciar sua operação, ele necessita de dados sobre cada amostra capturada por um nó sensor da rede de sensores. Para obter estes dados, o SensorNet precisa capturá-los direto na infraestrutura de comunicação do OSIRIS, via inscrição em omcp://collector.ex/, que é o endereço onde todos os coletores devem publicar seus dados. Após o recebimento do dado, o SensorNet o processa e retira todas as informações necessárias para mapear a rede de sensores no ambiente computacional o framework.

Todos os dados publicados por um coletor seguem o padrão, definido pelo OSIRIS, para o funcionamento consistente em todo o framework: mesmo tipo de pacotes e endereço único de publicação.

###Verificação periódica dos sensores O SensorNet precisa definir o estado de operação da rede, do coletor e de um sensor, para isso, o mesmo deve ser capaz de monitorar se uma amostra de um determinado nó sensor da rede de sensores foi enviada dentro de um período, atendo o prazo de captura. Como o SensorNet mapeia a rede de sensores para o ambiente computacional, ele deve ser capaz de informar se um nó sensor está funcionando ou não.

Para isso, verificações periódicas agendas ocorrem, afim realizar em um instante de tempo aproximado, a verificação de cada sensor mapeado pelo módulo. A após essa verificação o estado de funcionamento de um sensor, uma rede ou um coletor pode ser alterado.

####Tabela de estados de funcionamento A tabela a seguir contém todos os estados possíveis de serem atribuídos a uma rede, coletor ou sensor, com uma descrição do seu significado.

Estado de operação Descrição
NEW Novo item no módulo
UPDATED Atualizado com sucesso
INACTIVE Desativado
REACTIVATED Reativado
MALFUNCTION Funcionamento incorreto ou parcial

O estado de funcionamento MALFUNCTION contém uma propriedade de transitividade entre o item mais específicos para o mais geral. Supondo que cada sensor seja uma folha, um coletor seja um nó e uma rede seja a raiz, uma folha com um de estado do funcionamento MALFUNCTION propaga seu estado até a raiz, hierarquicamente, tornando toda árvore condenada por mal funcionamento.

##Comunicação Para o SensorNet fazer parte do framework, o mesmo deve implementar o protocolo de comunicação OMCP para o servidor. O OMCP é um protocolo de comunicação REST, baseado no protocolo HTTP da Web, possuindo métodos de requisição e códigos de resposta previamente definidos.

###Servidor RPC Por debaixo dos panos, o SensorNet atua como um servidor OMCP, disponibilizado dados de todos os sensores, coletores e redes para uma aplicação externa, em formato REST, com todos estes itens endereçáveis por uma URL. O servidor SensorNet contém os seguintes recursos OMCP:

  1. omcp://sensornet.osiris/networks/;
  2. omcp://sensornet.osiris/networks/{networkId}/collectors/;
  3. omcp://sensornet.osiris/networks/{networkId}/sensors/;
  4. omcp://sensornet.osiris/networks/{networkId}/collectors/{collectorId}/sensors/;
  5. omcp://sensornet.osiris/networks/{networkId}/collectors/{collectorId}/sensors/{sensorId}/.

####Formato de dados para chamadas RPC O OSIRIS define como os dados do recurso rede, coletor e sensor devem ser. Todos os dados devem possuir o seu estado de operação.

#####Sensor O formato do dado de sensor devem ser como descrito no exemplo a seguir, contendo informações sobre nó sensor na rede física, o estado de seus recursos consumíveis, a última captura realizada pelos seus sensores e os metadados relacionados a informações diversas. Estes metadados são um conjunto variável de dados que estão relacionados a aplicação construída com o framework.

"sensor": {
    "id": 34,
    "state": "updated",
    "modified": 1418734950,
    "network": "labtempo",
    "collector": "lab",
    "timestamp": 1408734195,
    "values": [
      {
        "name": "temperature",
        "type": "real",
        "value": 10,
        "unit": "celsius",
        "symbol": "°C"
      },
      {
        "name": "luminosity",
        "type": "real",
        "value": 200,
        "unit": "candela",
        "symbol": "cd"
      }
    ],
    "consumables": {
      "battery": 67,
      "fuel": 87,
      "tire": 45,
      "oil": 89
    },
    "info": {
      "description": "sensor baseado no hardware xpto386",
      "model": "micaz",
      "sn": 1235623512,
      "vendor": "memsic",
      "url": "http://memsic.com/micaz/"
    }
}

#####Rede O formato de dado da rede segue o padrão do exemplo a seguir. A estrutura de dados deve possuir a quantidade de sensores e coletores da rede, dados relacionados a identificação da rede e os metadados de informações para a aplicação.

"network": {
    "id": "labtempo",
    "state": "updated",
    "modified": 1418734950,
    "collectors": 3,
    "sensors": 20,
    "info": {
      "domain": "br.uff.ic",
      "type": "wireless",
      "os": "TinyOS"
    }
  }

#####Colector O formato de dado do coletor segue o padrão do exemplo definido a seguir. A estrutura de dados deve conter o dado de identificação do coletor na rede, a quantidade de sensores, a rede qual pertence e as informações relativas a aplicação.

"collector": {
    "id": "lab",
    "state": "new",
    "modified": 1418734950,
	"network":"labtempo"
    "sensors": 15,
    "info": {
      "description": "coletor do laboratório tempo",
      "role": "coletar dados de temperatura dos servidores"
    }
  }

###Anunciante de alterações("Servidor" de eventos) O SensorNet agrega a funcionalidade de notificar todas as alterações de estados dos seus itens, rede, coletor e sensor, através de eventos. Para realizar esta funcionalidade, o SensorNet deve publicar mensagens de notificação para o endereço omcp://exchange-aqui/ e assim possibilitar o acompanhamento externo para um item individualmente ou para um conjunto deles, sem necessidade de contatar o servidor SensorNet a todo o momento(chamadas RPC).

Todas as mensagens de eventos devem ser publicadas dentro do formato padronizado pelo OSIRIS, para garantir a conversão correta em qualquer outro módulo que irá consumi-las. Mais informações sobre este formato, consultar as definições gerais do OSIRIS.

####Notificações do SensorNet A tabela a seguir descreve todos os eventos publicados pelo SensorNet para o mundo exterior.

Ação Descrição
Atualização Rede, coletor e sensor
Descoberta Rede, coletor e sensor
Mal função Rede, coletor e sensor
Desativação Rede, coletor e sensor
Reativação Rede, coletor e sensor
Consumível do sensor atingindo o limiar Sensor

Todas as notificações devem conter a URL para o recurso notificado.

##Implementação

Para implementar o módulo do SensorNet, foi utilizado a linguagem Java, em sua versão 7, e aplicado o padrão de projeto MVC. O MVC utiliza três camadas controles, modelos e visão. Para melhor manipulação do projeto, como, por exemplo, o controle de dependências, o Maven está sendo utilizado para gerenciá-lo por completo.

###Controle Os controles atuam como interface de comunicação entre o exterior e o SensorNet. Utilizando um servidor OMCP, o SensorNet recebe requisições e mensagens de eventos, as quais são todas tratadas pelos controles. Após o tratamento, o controle delega o processamento para um modelo e responde a requisição corretamente de acordo com o resultado do processamento. O conjunto de controles utilizados são: controle para os recursos de rede, controle para recursos de coletor, controle para recursos de sensor e um controle para tratar eventos chegados ao módulo por inscrição prévia do servidor OMCP em algum exchange. Neste último caso, o exchange é o omcp://collector.ex/, o qual é utilizado para capturar as mensagens publicadas pelos coletores.

###Modelo As classes de modelo contêm a regra de negócio do módulo. Para a implementação correta, foram implementado classes de modelo para o sensor, a rede e o coletor. O SensorNet possui também classes de modelos auxiliares, necessárias para a correta implementação do módulo. Pela necessidade de armazenar os dados, as classes do modelo estão vinculadas as classes persistência.

####Persistência Para a persistência de dados, foi utilizado um banco de dados Postgres, banco de dados relacional, em conjunto com o Hibernate, framework de mapeamento objeto-relacional(ORM). O Hibernate facilita o trabalho de conversão de objetos Java para a persistência no modelo relacional.

###Visão A visão, ou view, tem a função de formatar a resposta de uma requisição dentro de um padrão capaz de ser entendido pelo cliente. No caso do módulo do SensorNet, a definição da view ficou por conta das definições gerais do OSIRIS, que utiliza o padrão JSON para os dados estruturados de respostas e requisições. A ampliação do conjunto de tipo de conteúdo para formatação de dados é possível, porém esta decisão pertence ao framework, fugindo do controle do SensorNet decidir como os dados devem ser entregues ao cliente. Já os dados entregues pela view seguem a estrutura definida no Formato de dados para chamadas RPC. Esta estrutura foi implementada para classes TO, classes para objetos transacionais, seguindo o padrão Core J2EE Patterns - Transfer Object - Oracle.

Add a custom footer
Add a custom sidebar
Clone this wiki locally