Nesta se¸c˜ao ser´a feito um detalhadamente sobre como foi criada a estrutura para o recebimento dos dados desde a coleta pelo nodo sink at´e a chegada ao webService respons´avel pelo envio dos dados ao servidor de BD.
Para realizar a leitura dos dados recebidos pelo nodo sink foi necess´ario um gateway para interpretar os dados passados para a porta
USB do servidor de controle pelo nodo sink. No desenvolvimento deste gateway, foi utilizado o sistema Labview 8.6 que possibilitou demonstrar as mensagens recebidas e criar um arquivo de log que ´e transformado em XML e lido pelo webservice.
Visando realizar a configura¸c˜ao do gateway de acordo com as finalidades do usu´ario, a implementa¸c˜ao foi feita de forma a fazer uma verifica¸c˜ao ao arquivo de configura¸c˜oes gerado pelos transformadores e moldar suas atividades de acordo com o que foi especificado.
Este arquivo ´e gerado pelos transformadores do WiSeN apenas se a feature gateway estiver selecionada e suas configura¸c˜oes s˜ao obtidas de acordo com as tags aplicadas no artefato DataCollector, caso ele esteja anotado com o estere´otipo << Gateway >> no diagrama de classes.
Para facilitar o entendimento, o diagrama de blocos do sistema est´a dividido em 5 partes conforme demonstrado nas Figuras 18 e 21. No entanto, as conex˜oes e componentes do gateway podem ser vistas em sua totalidade no apˆendice D.2.
Figura 18 – Diagrama com os componentes de inicializa¸c˜ao do gateway.
A Figura 18, divide os componentes em dois blocos. O bloco A, representado pela Figura 19, demonstra os componentes respons´aveis pela sele¸c˜ao do arquivo de configura¸c˜ao. O sistema aguarda que um arquivo chamado WisenGateway.ini, seja selecionado a fim de indicar o comportamento que o gateway deve assumir.
Figura 19 – Diagrama com a componentes usados para habilitar a sele¸c˜ao de um arquivo de configura¸c˜ao.
Figura 20 – Diagrama com as tags de leitura para interpreta¸c˜ao do arquivo de configura¸c˜ao.
No bloco B, representado pela Figura 20, ´e feita a leitura do ar- quivo. Caso as informa¸c˜oes b´asicas n˜ao estejam contidas no arquivo, de- vido a um modelo incompleto ou errˆoneo, s˜ao assumidos valores default para as vari´aveis. Note-se que existem oito chaves (keys) diferentes, cada uma representando uma poss´ıvel tag do arquivo de configura¸c˜ao.
Figura 21 – Diagrama que cont´em os componentes para a manipula¸c˜ao dos dados recebido e cria¸c˜ao do arquivo de Log.
A chave (key) 5, que representa a tag BaudRate, ser´a usada para exemplificar o funcionamento desta etapa. Caso esta tag n˜ao exista no arquivo, o valor 9600 ´e utilizado como default.
A leitura dos dados recebidos pelo nodo sink ´e feita pelos compo- nentes demonstrados na Figura 21. Esta figura demonstra como todos os componentes foram conectados mas, para facilitar a explica¸c˜ao, a figura foi dividida em trˆes blocos: Grava¸c˜ao do log bloco(C), processa- mento bloco(D) e interface gr´afica bloco(F).
A Figura 22 detalha os componentes do bloco D da Figura 21, na qual ocorre a leitura dos dados. Primeiro, ´e feita a leitura da porta serial onde os dados s˜ao lidos byte a byte. Depois, com a String coletada, o processamento se divide. Uma parte localiza o valor coletado pelo sensor (atribu´ıdo a tag body.data.value) por meio de uma express˜ao regular e os envia para os componentes visuais do bloco F. A outra parte envia todo o texto coletado para ser salvo no arquivo de log pelo componentes do bloco C.
Figura 22 – Diagrama que faz a leitura da porta conectada do nodo sink.
Os componentes do bloco F da Figura 21 s˜ao demonstrados pela Figura 23. Estes componentes visuais foram criados para que o usu´ario pudesse acompanhar os dados recebidos diretamente do servidor de controle.
Figura 23 – Diagrama que cont´em unicamente os componentes visuais.
Figura 24 – Interface dos componentes visuais visualizados no servidor de controle.
A interface gr´afica dos componentes do bloco F ´e mostrada na Figura 24. Esta ´e a tela que os usu´arios ter˜ao acesso para monitorar os dados no servidor de controle. Neste estudo, foi previsto apenas a
visualiza¸c˜ao de dados referentes `a temperatura no servidor de controle, mas futuramente esta interface pode ser evolu´ıda para outros tipos de sensores.
Todo o restante dos componentes, dispostos no bloco C da Figura 21, s˜ao respons´aveis pela grava¸c˜ao do log e s˜ao exibidos na Figura 25. Pela figura, nota-se que os bytes recebidos pela USB s˜ao lidos e ent˜ao distribu´ıdos em diferentes linhas que s˜ao inseridas ao arquivo de log.
Figura 25 – Diagrama que cont´em unicamente os componentes para cria¸c˜ao do arquivo de Log.
O log gerado ir´a variar de acordo com a estrutura das mensagens montadas no modelo.
Na Figura 26, ´e apresentado um exemplo de como ser´a o arquivo de log gerado.
Ap´os a gera¸c˜ao do log, um componente desenvolvido em java faz a convers˜ao para XML. Esta convers˜ao ´e independente de objetos, isto porque as tags podem mudar e portanto a estrutura do XML deve ser criada dinamicamente.
Quando n˜ao houver arquivos de configura¸c˜ao ou quando os arqui- vos n˜ao forem preenchidos com todas as informa¸c˜oes pr´e-requisitadas, o Gateway conta com uma arquivo de valores default utilizado para o preenchimento destas informa¸c˜oes, evitando a m´a execu¸c˜ao durante o recebimento dos dados.
Para isso, foram estruturados quatro n´ıveis, sendo os trˆes pri- meiros n´ıveis padronizados e imut´aveis.
O primeiro n´ıvel ´e o Sensor, que conter´a as tags de mensagens e possibilitar´a que novas estruturas sejam adicionadas, como por exem- plo, uma resposta contendo instru¸c˜oes aos atuadores. No segundo n´ıvel h´a as Mensagens, onde est˜ao alocadas a lista de mensagens recebidas.
Dentro do terceiro n´ıvel h´a uma tag chamada Msg, esta tag cont´em toda a estrutura e dados das mensagens recebidas que s˜ao alo- cadas ao quarto n´ıvel do XML. Feita a convers˜ao, o XML deve ser transformado em algo similar ao apresentado na Figura 27.
Finalmente, uma conex˜ao ´e aberta com o webservice de inte- gra¸c˜ao e o arquivo XML ´e repassado ao mesmo.
Figura 28 – C´odigo em linguagem Scala contendo o objeto Application e seus m´etodos para salvar e recuperar os dados do banco de dados