C AS DES STATIONS « USINE »

Esta visão demonstra a organização da AS a partir do ponto de vista funcional. Nesta visão os principais elementos, como subsistemas, módulos e a interface entre estes elementos são especificados. A Figura 28 ilustra a arquitetura do ponto de vista lógico e abaixo são descritos seus módulos.

Mediador de Dados (MD)

Este é o principal módulo da arquitetura, sendo responsável pela orquestração das mensagens e armazenamento das principais entidades e dados do sistema. Esse módulo encontra-se na Plataforma IoT e deve gozar das características de um ambiente de Com- putação em Nuvem, como: elasticidade, ubiquidade, escalabilidade, acesso amplo via rede

Capítulo 4. Arquitetura Proposta 71

Figura 28 – Visão Lógica da AS proposta

Fonte: O Autor

e segurança. Para coordenar a comunicação, esse módulo deve implementar o PA Broker, uma vez que esse padrão é usado para estruturar sistemas de software com componentes distribuídos que interagem com chamadas de serviços remotos.

Os principais atores do módulo Mediador de Dados são:

• Produtor de Contexto - entidade (por exemplo, um Nó IoT) capaz de gerar contexto;

• Consumidor de Contexto - entidade (por exemplo, uma aplicação baseada em contexto) que explora informações de contexto.

Esse módulo representa o ponto de entrada para as aplicações e serviços externos da Camada de Negócio, provendo mecanismos necessários para o acesso e a comunicação com a AS e entre seus módulos. Todas as comunicações com este módulo devem ocorrer através da API fornecida por ele. Com essas interfaces, pode-se fazer as seguintes operações:

• Registrar Produtor de Contexto; • Atualizar contexto;

• Ser notificado quando da alteração de contexto ou com uma frequência determinada; • Consultar contexto.

Um princípio fundamental deste módulo é a total dissociação entre os Produtores e os Consumidores de Contexto. Desta forma um Consumidor não necessita saber qual Produtor publicou um evento, assim como um Produtor não precisa conhecer qualquer Consumidor. Como resultado, esse módulo é uma ponte que permite que aplicações ex- ternas da Camada de Negócio gerenciem eventos de forma mais simples escondendo a complexidade da coleta de recursos dos Nós.

Autenticador

Este módulo é o responsável pela criação do Token para autorização da comunicação do Gateway (dispositivo de posse do Pipeiro) com o Nó (Cisterna do Beneficiário) e da autenticação do Pacote de Recebimento gerado no Nó e transmitido pelo Gateway.

Capítulo 4. Arquitetura Proposta 72

O Módulo Autenticador encontra-se na Plataforma IoT, porém em uma máquina vir- tual diferente do Mediador de Dados. Essa decisão arquitetural de manter esses dois mó- dulos no mesmo ambiente se explica pela maior facilidade na gestão das Chaves Pública e Privadas do Autenticador e dos Nós, facilitando a comunicação entre esses módulos. Esses módulos se comunicam através da API disponibilizada pelo Mediador de Dados. Para essa comunicação o módulo Autenticador deve ser registrado no módulo Mediador de Dados de forma que quando uma atualização de contexto ocorra ele seja notificado. Uma atualização de contexto nesse caso pode ser um pedido de geração de Token ou um pedido de autenticação de Pacote de Recebimento.

Este módulo é o responsável direto pela autenticidade das informações trocadas entre o Gateway, o Nó e o Mediador de Dados. Tendo em vista que os Nós não possuem necessariamente acesso a Internet, a metodologia de Token proposta neste trabalho não é a convencional, na qual os interessados possuem acesso à Internet, mas sim gerada a partir da assinatura com Chave Privada e autenticação com Chave Pública, garantindo assim a autenticidade de um pacote. A Figura 29 mostra o diagrama de sequência das atividades de Gerar Token de Entrega e Autenticar um Pacote de Recebimento.

Figura 29 – Diagrama de sequência da atividade de Gerar Token de Entrega

Fonte: O Autor

Para a geração de um Token de Entrega o Módulo Mediador de Dados notifica o Módulo Autenticador, passando um pacote com os dados da entrega a ser realizada. Então o Módulo Autenticador assina esse pacote com sua Chave Privada. O Módulo Autenticador então atualiza o contexto passando o Token para o Mediador de Dados.

Por outro lado, para a autenticação de um Pacote de Recebimento o Módulo Mediador de Dados notifica o Módulo Autenticador, passando o Pacote de Recebimento (previa- mente assinado com a Chave Privada do Nó). Módulo Autenticador autentica esse pacote com a Chave Pública do Nó. O Módulo Autenticador então atualiza o contexto passando o Pacote de Recebimento para o Mediador de Dados com o resultado da verificação.

Capítulo 4. Arquitetura Proposta 73

Gateway

A função principal deste módulo/subsistema é transferir o pacote de Entrega para o Nó e transmitir o Pacote de Recebimento para o Mediador de Dados. Outra função de responsabilidade do Gateway é monitorar o deslocamento a fim de armazenar o itinerário realizado, a data-hora de passagem pelo Manancial estabelecido para o recebimento do recurso hídrico e a localização do Nó onde houve a transmissão do Pacote de Entrega.

Esse módulo encontra-se de posse do Pipeiro e deve possuir tecnologia de geolocali- zação integrada e um razoável poder de processamento e armazenamento. Outra carac- terística que o Gateway deve possuir é acesso aos protocolos de comunicação interna e externa como definido neste trabalho, Figura 11. Desta forma, o Gateway deve funcionar como um roteador, interligando duas redes diferentes, neste caso, os dois protocolos de comunicação empregados nesta arquitetura. A comunicação deste módulo com os outros subsistemas e módulos da arquitetura é da seguinte forma: via API entre o Gateway e o Mediador de Dados; e via protocolo de comunicação interna entre o Gateway e o Nó.

A Figura 30 mostra o diagrama de sequência da atividade de realizar entrega de uma Carrada, na esfera de responsabilidade do Gateway.

Figura 30 – Diagrama de sequência da atividade Realizar Entrega

Fonte: O Autor

Para realizar essa atividade, primeiramente o Gateway registra-se no Mediador de Dados para poder receber notificação. Após esse registro, o Gateway atualiza o contexto, passando para o Mediador de Dados a Entrega a ser realizada, de escolha do Pipeiro com base em seu Plano de Trabalho. Então o Gateway recebe do Mediador de Dados a notificação com o Token da entrega.

Neste momento o Gateway começa a monitorar o deslocamento, salvando em seu banco de dados interno as coordenadas e a data-hora. Quando o Gateway chega ao Manancial previsto para a entrega, anexa ao Token as coordenadas do Manancial e a data-hora de

Capítulo 4. Arquitetura Proposta 74

chegada e partida, gerando o Pacote de Entrega.

Ao chegar ao local previsto para entrega, o Gateway estabelece a comunicação com o Nó. Após isso, o Gateway envia o Pacote de Entrega para o Nó. Após a entrega da água, o Gateway então recebe o Pacote de Recebimento, gerado pelo Nó.

Após isso, o Gateway salva esse pacote em seu banco de dados interno e assim que tiver acesso a rede externa atualiza o contexto, transmitindo o Pacote de Recebimento para o Mediador de Dados.

Nó

A principal função deste módulo/subsistema é validar o Pacote de Entrega e gerar o Pacote de Recebimento. Também faz parte das atribuições deste módulo controlar os sensores usados para medir o volume e a qualidade da água recebida.

Esse módulo encontra-se no microcontrolador, o qual é colocado fisicamente na cisterna que irá receber o recurso hídrico. Esse subsistema armazena em sua memória obrigatori- amente o identificador da cisterna, a Chave Privada do Nó e a Chave Pública do Módulo Autenticador. A comunicação desse módulo se dá por protocolo de comunicação interna com o módulo Gateway.

Devido a falta de comunicação com a Internet por parte do Nó, para garantir a auten- ticidade do Pacote de Entrega, bem como do Pacote de Recebimento, é usada a técnica de assinatura com Chave Privada e verificação com Chave Pública. A Figura 31 mostra as atividades realizadas por esse módulo.

Figura 31 – Diagrama de sequência módulo Nó

Fonte: O Autor

Tudo começa com o estabelecimento da comunicação dos dispositivos Gateway e Nó. Após isso o Nó recebe o pacote de Entrega. De posse do pacote, o Token então é verificado com a Chave Pública do Autenticador para validar a autenticidade do Pacote.

Capítulo 4. Arquitetura Proposta 75

No próximo passo, o Nó inicia a medição do volume de água. Essa medição ocorre até que o volume de água entregue seja igual ao previsto no Pacote de Entrega, ou que haja uma interrupção por parte do Gateway. O Volume de água recebido fará parte do Pacote de Recebimento. Após receber o volume de água o Nó faz a medição da pureza da água, o qual também fará parte do Pacote de Recebimento.

Após medir a pureza da água, o Nó gera o Pacote de Recebimento, concatenando as informações da Entrega, Pipeiro, Manancial, Cisterna, volume recebido e pureza da água e assinando esse pacote com a Chave Privada do Nó. Por fim o Pacote de Recebimento é enviado para o módulo Gateway.

Camada de Negócio

A Camada de Negócio possui duas divisões: Camada de Negócio da Arquitetura de Software e Sistemas Externos.

Camada de Negócio AS

Esse módulo encontra-se na Plataforma IoT e consiste apenas de um pacote que contém classes de negócio e interfaces para os Casos de Usos: Manter Nós, Manter Plano de

Trabalho, Manter Manancial, Manter Pipeiro e Manter Carrada.

Esse pacote é utilizado pela Camada de Aplicação e pode ser reusado pelos Sistemas Externos que utilizam os serviços fornecidos por esta arquitetura para implementar um

proxy a fim de facilitar a comunicação com o Módulo Mediador de Dados. A Figura 32

mostra o diagrama de classes resumido deste módulo.

Figura 32 – Diagrama de classes resumido Camada de Negócio AS

Fonte: O Autor Sistemas Externos

São quaisquer sistemas externos que utilizem os serviços fornecidos pela Arquitetura Proposta. Esses sistemas são implementados, hospedados e mantidos por terceiros, não fazendo parte desta arquitetura.

A comunicação destes sistemas com a arquitetura proposta se dá através da API dis- ponibilizada pelo Mediador de Dados. Esses sistemas podem reusar as classes e interfaces contidas no pacote do Módulo Camada de Negócio AS para implementar um proxy para auxiliar a utilização dessa API.

Capítulo 4. Arquitetura Proposta 76

Tabela 6 – Mapeamento dos componentes da AS em processos ethreads

Módulo Processo Thread

Mediador de Dados 1 Principal

1 inicial

+ 1 por notificação e 1 por requisição

Autenticador 1 Principal 1 inicial

+ 1 por requisição

Gateway 1 Principal

1 principal

+ 1 por operação de rede

+ 1 por operação de geolocalização

Nó 1 Principal 1 principal

Camada de Negócio Implementação externa Implementação externa

Fonte: O Autor