Configurando fluxos de processamento de dados da plataforma dojot

plataforma dojot
Este post faz parte da série Plataforma dojot. Leia também os outros posts da série:

A dojot é uma plataforma brasileira desenvolvida principalmente pelo CPqD e que surgiu com uma proposta open source, visando facilitar o desenvolvimento de soluções e subsidiar o ecossistema IoT com conteúdo local voltado às necessidades do País.

 

O código dos componentes que compõem a solução está disponível no repositório do Github. Descritivos detalhados da arquitetura, do funcionamento dos componentes e alguns casos de uso podem ser encontrados na documentação.

 

Introdução

 

Nos artigos anteriores, foram abordados os passos iniciais para inicializar a plataforma dojot e enviar informações a partir de um dispositivo que realiza o sensoriamento de temperatura.

 

Contudo, capturar e salvar as medições enviadas pelos sensores é só parte do arranjo. Para que ações possam ser tomadas, é necessário que estes dados sejam analisados de acordo com as regras de negócio específicas da aplicação.

 

Para alcançar esse objetivo, este artigo abordará a utilização do sistema de fluxos da dojot. Esse sistema é baseado em eventos: quando um dispositivo envia um ou mais dados de medição, os fluxos vinculados ao mesmo são executados.

 

Atualizando a modelagem

 

Partindo do exemplo de monitoramento de temperatura, serão inseridos dois novos componentes: um sinalizador para indicar temperatura alta e outro para temperatura baixa.

O novo arranjo da modelagem segue o seguinte layout:

 

Figura 1: Layout do novo arranjo da modelagem.

 

Partindo da mesma metodologia de modelagem apresentado anteriormente, será criado um modelo (template) que caracterize este tipo de sinalizador: atributo de valor dinâmico denominado ativo, do tipo booleano, indicando o status do sinalizador.

 

Em seguida, os dois componentes baseados neste modelo são criados e nomeados de  forma a facilitar a diferenciação.

 

 

Figura 2: Criação do modelo de sinalizador.
Figura 3: Criação dos dispositivos sinalizadores.

 

Com isso, é possível criar um fluxo onde:

 

(1) caso a temperatura atinja um valor acima de um valor predeterminado, o sinalizador de temperatura alta será ativado - e desativado, caso contrário.

 

(2) de forma análoga, o sinalizador de temperatura baixa será ativado quando a temperatura medida estiver abaixo de um limiar predeterminado - e desativado, caso contrário.

 

Criando um novo fluxo

 

No menu lateral, a opção Data Flow leva o usuário à seção de criação de fluxos customizados para a aplicação.

 

A imagem a seguir ilustra a modelagem do fluxo descrito anteriormente. As partes utilizadas serão explicadas em mais detalhes.

 

Figura 4: modelagem do fluxo descrito anteriormente.

 

Cada fluxo tem, em geral, três etapas:

 

  • obtenção da leitura dos sinais do dispositivo ao qual o fluxo é relacionado;
  • avaliação dos valores frente às regras de negócio;
  • tomada de ação de acordo com o resultado da análise total do fluxo.

 

Baseando-se nesta divisão, o cenário do exemplo abordado pode ser visto como:

 

  • leitura do valor da temperatura no escritório;
  • verificação se a temperatura está acima ou abaixo dos limiares configurados;
  • acionamento dos sinalizadores de temperatura alta ou baixa.

 

Dispositivo de entrada

(A) Name: nome de exibição do bloco no diagrama. No caso do exemplo, é nomeado com o nome do próprio dispositivo: o sensor de temperatura do escritório.

(B) Device: identifica qual dispositivo será monitorado para acionar o fluxo.

(C) Status: define se as mudanças de estado (online/offline) serão considerados ou não para ativação do fluxo.

 

Tomada de decisão

(A) Name: nome de exibição do bloco no diagrama. No exemplo, é nomeado com a função do bloco: controlar os casos de temperatura alta.

(B) Property: define qual propriedade será utilizada na comparação. Neste caso, se espera comparar o atributo “temperatura” enviado no payload do dispositivo.

(C) Lista de comparações: define as regras checadas para acionar a saída. A cada regra adicionada, também é acrescido o número de saídas deste bloco. No exemplo, existem duas regras - e é possível ver, no diagrama completo, a presença de duas saídas.

(D) Critério de comparação: define se todas as regras serão verificadas ou se o bloco acionará apenas a primeira que for válida.

 

Atribuição de valor

(A) Name: nome de exibição do bloco no diagrama. No exemplo, é nomeado baseado na ação que o bloco executa: acionar o sinalizador.

(B) Lista de atribuições: define os valores que serão atribuídos às variáveis de saída. Neste caso, valor true foi atribuído à saída payload.ativo, visando ativar o sinalizador.

 

Dispositivo de saída

(A) Name: nome de exibição do bloco no diagrama. No caso do exemplo, é nomeado com o nome do próprio dispositivo: o alerta de temperatura alta.

(B) Device: identifica a qual dispositivo o sinal de entrada será enviado. Neste caso, foi escolhida a opção de selecionar um dispositivo específico. Também é possível escolher o dispositivo que ativou o fluxo ou mesmo um criado durante o fluxo.

(C) Nome do dispositivo: no caso onde (B) tem um dispositivo específico, neste campo é especificado qual.

(D) Source: variável na qual o valor está presente. Para os casos onde a temperatura está acima do limiar, o payload contém o objeto {ativo : true}.

 

Validando o fluxo configurado

 

Uma vez salvas, as alterações do fluxo são automaticamente carregadas no componente contido no contêiner identificado por flowbroker. Essas alterações, juntamente com a execução de cada fluxo, podem ser monitoradas através do acompanhamento dos logs deste contêiner.

 

Enviando valores de temperatura à plataforma, é possível simular o comportamento esperado para cada saída do fluxo.

 

Note que os comandos a seguir utilizam o device id 90a144. Esse valor deve ser atualizado de acordo com o gerado na criação do dispositivo.

 

 

Estado após envio da leitura de temperatura de 23ºC.

 

 

Estado após envio da leitura de temperatura de 14ºC. Note que os valores são ordenados inversamente ao horário de recebimento.

 

 

Estado após envio da leitura de temperatura de 32ºC.

 

Com isso, é possível notar que os sinais de alerta estão de acordo com o comportamento esperado para diferentes valores de temperatura, conforme especificado pelas regras de negócio.

 

Conclusão

 

Até aqui, foram abordadas as principais funcionalidades iniciais da plataforma. A partir destes procedimentos, já espera ser possível a um novo usuário a criação de aplicações customizadas às suas necessidades.

 

Ainda que a aplicação abordada tenha caráter introdutório, espera-se despertar no leitor o interesse em investigar novas formas de utilizar esses procedimentos para criação de soluções de maior complexidade.

Outros artigos da série

<< Simulação de dispositivos na plataforma dojot
Este post faz da série Plataforma dojot. Leia também os outros posts da série:
NEWSLETTER

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Obrigado! Sua inscrição foi um sucesso.

Ops, algo deu errado. Por favor tente novamente.

Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

Rafael Zanetti
Graduado em Engenharia Mecatrônica, atua em desenvolvimento de software com foco em soluções potencializadas por big data e inteligência artificial. Atualmente, está envolvido com IoT e suas aplicações no cenário nacional.

Deixe um comentário

avatar
 
  Notificações  
Notificar