Caro(a) Colega,

a partir do dia 20 inicia-se um curso com 5 dias de duração, sobre soluções de conectividade para a internet industrial das coisas, oferecido pelo CEC – Continuing Education Center numa parceria entre o IEEE, o site de conteúdo Design News e patrocinado pela Digikey. Confira a resenha:

The Industrial Internet of Things (IIoT) consists of components and systems that connect industrial equipment together and potentially link them to external systems.  These are distributed systems that may span a great area inside an individual facility and may even connect to other facilities.  In some cases, external systems are added to the mix to facilitate control and analysis of data.  In this course, we will look at the communication components,  and discuss how they are interconnected and architected. 

    • May 20 – Day 1 – IIoT Landscape – In this lecture we shall introduce the IIoT and how it is used. An understanding of the basic components in play will be given with an eye toward understanding how they may need to communicate and what those requirements might be
    • May 21 – Day 2 – Wired Options – Interconnection between industrial components has long been accomplished using various wired technology solutions. Many of these are still in use and valuable today. In this lecture we will give an overview of those options, including their capabilities and applicability.
    • May 22 – Day 3 – Wireless Options – As wireless technology has improved, the ability to use it in an industrial setting has presented itself. In addition, wireless technologies can be easier to install and maintain. We will look at the technologies in use and how they are adapted in industrial situations. 
    • May 23 – Day 4 – Architectures for Individual Plants – The traditional and main use for the IIoT was to connect devices within a single industrial plant or facility. As many of the facilities contain interconnected devices in large physical areas, it is important to plan the layout and architecture of the communications. These architectures must be  flexible and amenable to growth and reconfiguration.  In this class we will look at the ways in which that may be done. 
    • May 24 – Day 5 – Distributed Operations and External Connections – Many operations in modern industrial enterprises have multiple facilities, including warehousing and distribution sites.  These will have many devices internally and will need to work together.  This can be done by direct connection, or by integration with centralized computing resources, often including cloud computing and storage.  The centralized systems will perform operations such as Manufacturing Resource Planning (MRP) and analytics.  Data transmitted between plants and central facilities can present many challenges.  In this lecture we will discuss how these are met and how to implement them. 

Aproveite! Clique aqui para fazer a sua inscrição ou obter mais informações.

Abraço,

.

Henrique

consulte sempre um engenheiro eletrônico

Caro(a) Colega,

confira as novas edições das revistas de eletrônica publicadas nessa semana. Para acessar a revista, basta clicar na figura correspondente a seguir, ou então acessar a nossa página com as últimas edições das Revistas Técnicas do mês.

Abraço,

.

Henrique

consulte sempre um engenheiro eletrônico


Dear Colleague,

 .
check out the new editions of the  electronics magazines published this week. To access a magazine, simply click on thecorresponding figure below, or access our website with the latest editions of the Technical Journals of the month.
Regards
.
Henrique

always refer to an electronic engineer


Drives & Controls - May 2019 ECN - May 2019 GPS World - May 2019 Industrial Laser Solutions - March/April 2019
MAchine Design - May 2019 Military & Aerospace - May 2019 Printed Circuit Design & Fab - May 2019 SAE Brasil - Engenharia automotiva e aeroespacial - nº 81
Vision Systems Design - May 2019 Medical Design Briefs - May 2019 Tech Briefs - April 2019

Caro(a) Colega,

Confira a seguir a tirinha de hoje. Leia ou releia as tirinhas anteriores aqui.

Abraço,

.

Henrique

consulte sempre um engenheiro eletrônico


Cães e Gatos – Manopla

Caro(a) Colega,

confira as novas edições das revistas de eletrônica publicadas nessa semana. Para acessar a revista, basta clicar na figura correspondente a seguir, ou então acessar a nossa página com as últimas edições das Revistas Técnicas do mês.

Abraço,

.

Henrique

consulte sempre um engenheiro eletrônico


Dear Colleague,

 .
check out the new editions of the  electronics magazines published this week. To access a magazine, simply click on thecorresponding figure below, or access our website with the latest editions of the Technical Journals of the month.
Regards
.
Henrique

always refer to an electronic engineer


Bodo's Power Systems - May 2019 Control Design - May 2019 COTS JOurnal - April 2019 eeNews Europe - Embedded - May 2019
eeNews Europe - MAY 2019 LEDS Magazine - April 2019 MAchine Design - April 2019 Microwaves & RF - April 2019
New Electronics - April 23 - 2019 SAE Automotive Engineering - May 2019

Caro(a) Colega,

Confira a seguir a tirinha de hoje. Leia ou releia as tirinhas anteriores aqui.

Abraço,

.

Henrique

consulte sempre um engenheiro eletrônico


Programação

Um sábado Qualquer - Programação

 

Caro(a) Colega,

dei uma atualizada na nossa biblioteca de revistas. Confira as novas edições das revistas de eletrônica publicadas nessa semana. Para acessar a revista, basta clicar na figura correspondente a seguir, ou então acessar a nossa página com as últimas edições das Revistas Técnicas do mês.

Abraço,

.

Henrique

consulte sempre um engenheiro eletrônico


Dear Colleague,

 .
check out the new editions of the  electronics magazines published this week. To access a magazine, simply click on thecorresponding figure below, or access our website with the latest editions of the Technical Journals and magazines of the month.
Regards
.
Henrique

always refer to an electronic engineer


Sextas de Humor – Fun Friday

Publicado: 26 de abril de 2019 em Humor
Tags:, , ,

Caro(a) Colega,

aos poucos vou retomar as publicações do blog. Vamos ver o que dá… Confira a seguir a tirinha de hoje. Leia ou releia as tirinhas anteriores aqui.

Abraço,

.

Henrique

consulte sempre um engenheiro eletrônico


Cientistas nos anos 90 e agora

Por Olga Satomi Yoshida e Leonardo Fonseca Larrubia

 

INTRODUÇÃO

 

Este artigo é parte da série de artigos técnicos SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA. Neste artigo serão apresentados alguns resultados reais obtidos durante o projeto. Para melhor compreensão deste artigo leia antes o artigo técnico “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Descrição do Sistema”.

 

ESTUDO DE CASO PRÉDIO 56

O sistema de medição foi instalado na toalete masculina na entrada do prédio 56 do IPT, que é utilizado pelos alunos de mestrado no período noturno, e durante o dia por colaboradores  majoritariamente do CIAM e da Secretaria Acadêmica do IPT..

Figura 1: Prédio 56 do IPT

Este sistema desagrega, em tempo real, o volume  consumido no toalete por aparelho sanitário, por turno ou hora e por atividade, caracterizando totalmente o consumo de água dos seus usuários, alunos dos mestrados e colaboradores do CIAM. Estas medições podem ser acompanhadas em tempo real na nuvem da Amazon Web Services – AWS,

A seguir são apresentadas as fotos das instalações do sistema de medição na toalete. Na sequência apresenta-se uma série de gráficos descrevendo os perfis de consumo na toalete.

Fotos das instalações e sensores

Figura 2:  Sensores 1,2 e 3,  instalados em 3 mictórios.

 

Figura 3: Sensores 4, 5 e 6, instalados nas mangueiras das torneiras.

 

Figura 4: Sensor no mictório e chave de fluxo.

 

Figura 5: Sensor em uma das torneiras.

 

Figura 6: Sensor contador passagem de pessoas na toalete.

 

Figura 7: Dispositivos medidores protegidos em uma caixa.

 

Figura 8: Dispositivos medidores.

Desagregação do consumo total por aparelho

Figura 9: Desagregação do consumo na toalete por aparelhos.

Perfil do consumo total por dia da semana

Figura 10: Consumo na toalete por dia da semana.

Perfil do consumo por horário

Figura 11: Consumo no toalete por hora do dia.

 

Perfil do consumo por turno

Figura 12: Consumo no toalete por turnos.

 

Base de dados de volumes consumidos dos aparelhos e correlações entre seus perfis de consumo

Este projeto gerou uma base dados referentes aos volumes (quase vazões) consumidos característicos de cada aparelho monitorado. Um resumo desta base é apresentado na Tabela 1, onde para cada aparelho sanitário monitorado tem-se estatísticas de volume consumido por acionamento. Tais informações e dados serão guardados para utilização em sistemas inteligentes de predição de consumo em aparelhos monitorados por chaves de fluxo somente em outras instalações.

 

Tabela 1: Volume (l) consumido por acionamento dos aparelhos

Aparelhos  

 n° de eventos/

 acionamento

Média Desvio Padrão Erro Padrão 1° Quartil Mediana 3° Quartil
Torneira 1 9300 0,426 0,449 0,005 0,179 0,287 0,502
Torneira 2 6289 0,660 0,525 0,007 0,380 0,480 0,829
Torneira 3 1457 0,692 0,932 0,024 0,054 0,363 0,889

Geral Torneiras

17046 0,535 0,548 0,004 0,215 0,399 0,658
Mictório 1 2680 0,575 0,594 0,011 0,202 0,487 0,701
Mictório 2 2252 0,737 0,579 0,012 0,388 0,666 0,882
Mictório 3 2310 0,692 0,525 0,011 0,443 0,591 0,816
Geral Mictórios 7242 0,663 0,572 0,007 0,335 0,585 0,796

 

Nas figuras  Figura 13 a Figura 16 tem-se os histogramas dos volumes consumidos por acionamento nos mictórios e torneiras.

 

Figura 13: Histogramas do volume (l) consumido por acionamento nos mictório 1 e 2.

 

Figura 14: Histogramas do volume (l) consumido por acionamento no mictório 3 e geral nos 3 mictórios.

 

Figura 15: Histogramas do volume (l) consumido por acionamento nas torneiras 1 e 2.

 

Figura 16: Histogramas do volume (l) consumido por acionamento na torneira 3 e geral nas 3 torneiras.

 

Nos gráficos de dispersão das  Figura 17 e Figura 18 vê-se o potencial preditivo do contador de pessoas que entram na toalete. Este potencial é utilizado para prever o consumo em todos os aparelhos sanitários, ver Figura 19Figura 22.

 

Figura 17:  Gráfico de dispersão dos volumes (l/dia) por número de pessoas nos mictórios 1, 2, 3 e soma dos volumes dos 3 mictórios.

 

 Figura 18: Gráfico de dispersão dos volumes (l/dia) por número de pessoas nas torneiras 4 e 5 e soma dos volumes das 2 torneiras.

 

Figura19: Predição de nº acionamentos dos mictórios em função do contador de pessoas.

 

Figura 20 Predição do volume consumido nos mictórios em função do contador de pessoas.

 

Figura 21: Predição de nº acionamentos nas torneiras em função do contador de pessoas.

 

Figura 22: Predição de volume consumido nas torneiras  em função do contador de pessoas.

COMPARAÇÃO DA SOLUÇÃO EXISTENTE COM A DESENVOLVIDA

 

 

 

Características das soluções

 

Solução existente

Solução desenvolvida

Hidrômetros com saída pulsada Sim Não
Sensores Sim no medidor hidrômetro Sim nos aparelhos de consumo de água.
Transmissores de rádio e concentradores Sim Sim
Armazenamento, disponibilidade e processamento de dados na nuvem Não, em geral os dados ficam sob custódia da empresa individualizadora, não ficam acessíveis aos contratantes do serviço de individualização. Sim, na nuvem e disponível para interessados em tempo real.
Solução de prateleira Sim Não
Intervenção local Sim. Muita intervenção. Não, nenhuma.
Pouco Visível Não Um pouco – ver fotos
Portabilidade: ajustável às características de outras instalações Não Sim
Baixo custo Não. O maior custo é das obras necessárias a instalação e depois da manutenção. Sim. Os sensores e a conectividade são baratos.
Inteligência e Aprendizado ou utilização de ferramentas analíticas. Não Sim
Sistema avisa aquando há erros em tempo real Não Sim
Rastreabilidade dos números em tempo real Não Sim
Sistema reajusta consumos de vido a erros nos pulsos em tempo real Não Sim
Sistema reajusta consumos devido ao não envio de dados Não Sim

 

CONSIDERAÇÕES FINAIS

 

Pode-se verificar que a utilização de ferramentas analíticas sobre dados coletados em conjunto de sensores tem grande potencial quando os eventos do local monitorado têm padrões de comportamento que se correlacionam ao longo do tempo e padrões de correlação entre as variáveis medidas e monitoradas simultaneamente nos vários sensores.

Foram estas correlações percebidas pelas ferramentas analíticas que possibilitaram ao sistema de medição as seguintes capacidades:

  • Corrigir os erros nos pulsos acumulados coletados dos sensores e enviados a nuvem;
  • Prever o consumo nas válvulas de descarga a partir das torneiras e contagem de pessoas;
  • Prever o consumo nas torneiras e mictórios somente com a contagem de acionamentos dos aparelhos.

A principal característica da solução é o seu conceito de medidor analítico o que o faz ajustável a qualquer instalação hidráulica e consequentemente portátil; e por isto não é uma solução de prateleira.

A meta técnica para o sistema de medição deste projeto foi estabelecida em 10 % a 20 % como margem de erro para a desagregação do consumo. Considerando que a tolerância ao erro de medição para hidrômetros utilizados no faturamento de água das residências seja de 10 %, a margem de erro alcançada deste sistema de medição em 15 % foi bastante razoável.

Com exceção da mínima visibilidade o sistema de medição desenvolvido atendeu a todas as metas propostas: baixíssimo custo, portátil e não destrutivo. Apesar de não comporem as metas do projeto, as capacidades citadas nesta seção e alcançadas no decorrer da execução do projeto, via o aplicativo tipo dashboard na nuvem são as características mais inovadoras deste sistema de medição.

SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA

Outros artigos da série

 

Licença Creative Commons
Esta obra, “SISTEMA PORTÁTIL DE MEDIÇÃO DE PERFIS DE CONSUMO DE ÁGUA – Estudo de Caso“, de  Olga Satomi Yoshida e Leonardo Fonseca Larrubia está sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional.

 

Por Olga Satomi Yoshida e Leonardo Fonseca Larrubia

INTRODUÇÃO

 

Este artigo mostra com detalhes o desenvolvimento do Sistema de Medição Aplicativo utilizado no Sistema de Medição de consumo de água. A Figura 1 mostra a tela de abertura do sistema aplicativo. Na sequência serão apresentadas cada uma das funcionalidades desse sistema. Para melhor compreensão deste artigo leia antes o artigo técnico “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Descrição do Sistema”.

 

Figura 1: Tela principal do sistema aplicativo.

SISTEMA DE MEDIÇÃO APLICATIVO

Armazenamento e processamento na Amazon Web Services (AWS)

Os dados coletados e enviados a nuvem pelo sistema físico de medição precisam ser corrigidos e analisados para gerar os perfis de consumo do local monitorado. Foi desenvolvido um aplicativo tipo dashboard com este proposito especifico, e que qualquer um, em qualquer lugar e a qualquer tempo possa acessar os resultados do aplicativo.

As seguintes tecnologias foram utilizadas para desenvolver o aplicativo.

 

Amazon Elastic Compute Cloud (EC2)

O Amazon Elastic Compute Cloud  (EC2) é um serviço web da Amazon Web Services (AWS) que disponibiliza capacidade computacional segura e redimensionável na nuvem.  A AWS oferece gratuitamente 750 horas de utilização do EC2 executando uma instância t2.micro Linux, RHEL ou SLES (1 GiB de memória e suporte para plataformas de 32 e 64 bits) durante 12 meses  (Figura 2 e a Figura 3).

Figura 2: Tela de Login da AWS.

Figura 3: Página do EC2-AWS que possibilita a administração dos computadores em nuvem.

 

Ubuntu Linux Server

É o sistema operacional (SO) para operar o recurso computacional na nuvem. O sistema é de uso é gratuito e seu código fonte é aberto.

 

R: The R Project for Statistical Computing

https://www.r-project.org/about.html

É uma linguagem e também um ambiente de desenvolvimento integrado para cálculos estatísticos e gráficos. O seu uso é gratuito, assim como o código fonte que está disponível sob a licença GNU GPL. O R possui uma vasta comunidade de usuários que disponibilizam variados “pacotes” (conjunto de rotinas, funções e/ou dados pré-programadas). Neste projeto são utilizados os seguintes pacotes:

    • shiny: cria aplicativos para web que permitem um certo grau de interação com o usuário;
    • shinydashboard: simplifica a criação de dashboard;
    • ggplot2: constrói variados tipos de gráficos;
    • plotly: constrói variados tipos de gráficos interativos;
    • rmarkdown: cria e formata documentos dinâmicos e páginas web estáticas;
    • dplyr: auxilia na manipulação e estruturação de dados;
    • stringi: auxilia na manipulação e formatação de textos;
    • lubridate: auxilia na manipulação e formatação de datas e horas.

 

RStudio Server

É um Ambiente de Desenvolvimento Integrado (IDE) para programação em R que é acessado via browser (navegador). Esse IDE permite uma melhor organização no desenvolvimento do sistema e facilita a programação (Figuras 4 e 5).

Figura 4: Tela de Login para acessar o RStudio Server via browser

Figura 5: Interface do ambiente RStudio Server

Shiny Server

É um servidor que permite a disponibilização online de aplicativos shiny. Possui recursos de escalabilidade, segurança e administração de nível corporativo.

Organização e funções do R

Foi criado um servidor com o sistema operacional (SO) Linux Ubuntu no EC2 da AWS que é responsável por disponibilizar recursos computacionais na nuvem. Nesse SO foi criado um sistema de diretórios para a organização do projeto de medição. Sua estrutura é presentada na Figura 6.

Figura 6: Organização dos diretórios para o projeto de medição de perfil de consumo de água.

Também foram instalados nesse SO os softwares R, RStudio Server e Shiny Server. Toda a programação para leitura, comandos e as análises dos dados foram realizadas usando o R. Os scripts com o códigos em R foram construídos e divididos de acordo com as funcionalidade exigida pelo sistema. Ao todo existem oito scripts, a seguir listados.

  • atualiza.R: conecta-se com a conta do pCloud, baixa, atualiza e faz uma estruturação e formatação inicial do conjunto de dados no diretório do computador da nuvem;
  • func_auxiliar.R: conjunto de funções genéricas de suporte que tem papel secundário nas análises;
  • func_carregaDados.R: conjunto de funções que carregam os dados dos diretórios e os estruturam numa única tabela;
  • func_corrigeDados.R: conjunto de funções que transformam as observações da base temporal de evento para hora, período do dia e dia. Também possuem funções que verificam a consistência e aplicam correções aos dados;
  • func_estatisticas.R: conjunto de funções que obtém informações estatísticas dos dados;
  • func_interface.R: conjunto de funções responsáveis pela construção da interface do aplicativo;
  • func_visualizacao.R: conjunto de funções que geram gráficos;
  • pacotes.R: conjunto de pacotes utilizados na programação e análise.

O RStudio Server foi utilizado como um IDE auxiliar para a interação com o R, além de servir como uma interface de acesso ao servidor via browser. Já o Shiny Server é responsável por “disponibilizar” o aplicativo online, atendendo as requisições de acesso do usuário.

 

Componentes funcionais do aplicativo

De modo geral, o funcionamento do sistema na nuvem pode ser dividido em duas partes: atualização e formatação dos dados e a análise e apresentação dos resultados.  Na Figura 7, pode-se observar que o esquema desenvolvido simplifica todo esse sistema na nuvem: O esquema do processo da operacionalização dos dados na nuvem relacionando o uso de cada tecnologia. Em 1 o desenvolvedor cria toda a operacionalização e análise de dado na nuvem e faz ajustes quando necessário. Em 2 o sistema na nuvem conecta-se ao pCloud e baixa e atualiza os dados no computador na nuvem.  Em 3 o usuário solicita o acesso ao aplicativo quando acessa o endereço via web e recebe as informações e análises (Figura 7).

Figura 7: Esquema do processo da operacionalização dos dados na nuvem.

 

Atualização e formatação dos dados

Consiste em um script em linguagem R (atualiza.R) responsável por baixar os dados do pCloud e salvá-los em um diretório local do sistema operacional Ubuntu Linux. Os dados primários estão organizados em arquivos .csv que são definidos por sensor e por dia. Após serem baixados, esses dados são estruturados em uma única tabela e a quantidade de pulsos acumulada pelo sistema de medição em cada evento é transformada em volume de água consumida. Depois é aplicada uma análise de consistência e, por fim, a tabela é salva. O sistema operacional manda o R executar essa rotina a cada 15 minutos.

 

Análise e apresentação dos resultados no aplicativo

A seguir os resultados de consumo são organizados em três bases temporais: hora, período do dia (madrugada, manhã, tarde e noite) ou dia. Diversas análises estatísticas são aplicadas e vários gráficos são construídos para cada base temporal de consumo. As análises e o monitoramento do consumo são apresentados em um aplicativo do tipo dashboard. Esse procedimento é executado toda vez que um usuário acessa o aplicativo.

 

Inteligências inseridas no aplicativo

A primeira ação do aplicativo é a análise de consistência dos dados monitorados dos sensores. O objetivo é identificar e eliminar ruídos no conjunto de dados. Eventos que apresentam consumos acima de um limite máximo são considerados ruídos e são excluídos. Para as torneiras e mictórios foi fixado um volume máximo de 3600 litros por hora.

Devido a uma falha inerente de conectividade do sistema de medição, há sempre um delay no acionamento do sistema de medição, e portanto foi acrescentado um tempo médio de 2,5 segundos ao tempo de duração dos eventos.

O volume obtido para os eventos de cada ponto de medição é sempre corrigido pela curva média de erro de cada medidor de acordo com as calibrações realizadas em laboratório.

Nos vasos sanitários é registrado apenas a ocorrência de evento com sua respectiva duração, sem ser medido, de fato, o consumo de água em cada evento. Tal consumo é estimado pela multiplicação da vazão média de descarga (obtidas através de estudos anteriores) com a duração do evento.

Com os consumos de cada ponto já estimados e corrigidos parte-se para a fase de análises estatísticas, que procuram descrever o perfil de consumo de água no ambiente. Os consumos, que até então eram por evento, são agregados por hora, por período do dia e por dia. De acordo com cada uma dessas bases temporais são obtidas algumas estatísticas resumo como média, mediana, máximo, mínimo de consumo, entre outras.

Os gráficos de séries temporais exibem a história do consumo até o momento atual. Os gráficos de “pizza” mostram a participação de cada aparelho ou grupo de pontos no consumo total. Os gráficos de barras permitem desagregar o consumo de acordo com a base temporal selecionada, possibilitando a visualização dos picos horários de maior consumo, a verificação de consumo nas madrugadas, ou os dias de maior consumo na semana. Os gráficos  boxplot e histogramas descrevem a distribuição da dispersão dos consumos ocorridos, sendo possível perceber qual é a faixa de consumo mais frequente, se períodos de tempo de consumo elevados são recorrentes, quais os valores de consumo mais destoantes entre muitas outras funcionalidades de análises.

As falhas possíveis de ocorrer são:

  • Perda de dados em decorrência de falta de energia, falta de bateria, ou entupimento da mangueira de água provocando erros como ZEROS ou VAZIOS nos registros de pulsos; ou
  • erro no registro de pulsos tipo outlier impactando no volume calculado.

Foi desenvolvida uma inteligência de dados para gerar alarmes, identificar e corrigir estes erros em tempo real. Na Figura 8 os alarmes estão indicando perda de dados em 3 aparelhos, 2 mictórios e uma torneira. Para estes pontos, a inteligência do aplicativo estima um consumo para toda perda de dado.

Figura 8: No link, a direita indicação de que não está havendo registro de consumo em três aparelhos.

 

Interfaces de acesso às funcionalidades do aplicativo

O aplicativo permite ao usuário ter acesso às informações e análises do consumo de água de forma dinâmica, fácil, simples e em tempo real. O aplicativo apresenta uma interface em essencialmente duas partes: uma barra lateral de navegação  (Figura 9 – A) e um painel que exibe informações e análises de acordo com o item selecionado na barra lateral (Figura 9 – B).

Figura 9: – Tela inicial do aplicativo.

A barra lateral é composta por três itens (Figura 10 – A):

  • Monitoramento: exibe informações do consumo;
  • Informações técnicas: exibe informações mais técnicas sobre o projeto;
  • Sobre: breve descrição do projeto.

Monitoramento: agrupa seis subitens responsáveis por exibir o consumo de água de acordo com o local escolhido pelo usuário (Figura 10 – B):.

  • Global: relativo ao consumo de todo o ambiente.
  • Torneiras: relativo ao consumo das torneiras. Na parte inferior do painel que exibe o acompanhamento de consumo é possível selecionar e exibir as informações individualizadas de cada torneira.
  • Mictórios: relativo ao consumo dos mictórios. Na parte inferior do painel que exibe o acompanhamento de consumo é possível selecionar e exibir as informações individualizadas de cada mictório.
  • Vasos: relativo ao consumo dos vasos.
  • Frequência de pessoas: relativo à quantidade de pessoas que usam o ambiente.
  • Análise de correlação: permite o usuário fazer uma cruzar o perfil de consumo entre os pontos de monitoramento.

Além dos seis subitens há uma barra de seleção que permite o usuário selecionar a base temporal (hora, período do dia ou dia) na qual deseja exibir as informações e análises do consumo; há uma caixa de marcação que permite o usuário escolher se quer ou não considerar os períodos que não houve consumo na análise e, por fim, há dois campos de data em que o usuário pode definir a data de inicio e de fim do período que deseja acompanhar o consumo.

O item Informações técnicas é composto por quatro subitens (Figura 10 – C)::

  • Sensores: exibe detalhes dos sensores e sobre seu funcionamento;
  • Modelagem: exibe informações sobre a modelagem aplicada aos dados;
  • Equipe: exibe a composição da equipe que participou do projeto;
  • Outros: exibe outras informações que podem ser relevantes.

O item Sobre exibe informações gerais sobre o projeto.

Figura 10: Detalhamento da barra lateral.

RESUMO

 

Este artigo apresentou com detalhes a solução desenvolvida para o Sistema de Medição Aplicativo e as diversas funcionalidades e ferramentas de análise que foram disponibilizadas aos usuários.

SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA

Outros artigos da série

 

Licença Creative Commons
Esta obra, “SISTEMA PORTÁTIL DE MEDIÇÃO DE PERFIS DE CONSUMO DE ÁGUA – Desenvolvimento de solução no Amazon AWS“, de  Olga Satomi Yoshida e Leonardo Fonseca Larrubia está sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional.

Por Ramon Vals Martin

INTRODUÇÃO

 

Este artigo é parte da série de artigos técnicos SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA. Neste artigo serão desenvolvidas diversas soluções alternativas para realizar a medição indireta do consumo de água em vasos sanitários ou outros pontos de entrega de água embutidos. Para melhor compreensão deste artigo leia antes o artigo técnico “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Descrição do Sistema”.

 

PROTÓTIPOS DE SENSORES ALTERNATIVOS

 

No sistema para determinar o perfil de consumo de água, há situações em que não é possível medir diretamente o fluxo da água. Como exemplo, descargas de vasos sanitários sem caixa acoplada (descargas com válvulas Hydra) não permitem um acesso ao escoamento de forma não invasiva. Neste caso, o monitoramento de consumo pode ser feito pelo tempo de acionamento. Naturalmente, trata-se de uma estimativa em que dados de calibração preliminarmente medidos ou obtidos no catálogo do fabricante da válvula de descarga, ou torneira de acionamento momentâneo, são analisados em conjunto com dados de pressão na linha (coluna de água) e tempo de acionamento. O tempo de acionamento deverá ser determinado com auxílio de um sensor do tipo chave liga/desliga adaptado ao botão de acionamento da válvula, ou através de uma chave de fluxo.

A informação do tempo de abertura da válvula deverá ser transmitida sem fio, preferencialmente por sinal de rádio, para um centralizador que disponibilizará a conexão com a rede local de comunicação ou a publicação em ambiente de nuvem. O transmissor de rádio deverá ser compacto e com baixo consumo de energia para possibilitar a alimentação com bateria de longa duração.

PROTÓTIPO PULSADO  I

 Transmissor

O primeiro protótipo construído utilizava um módulo transmissor de rádio (modelo FS1000A – Módulos transmissor e Receptor de rádio [1]) operando em 433 MHz, modulado com pulsos de largura de 100 µs e taxa de repetição ajustável entre 20 Hz e 30 Hz. No acionamento da descarga, o dispositivo transmitia um burst de rf durante cada pulso.  A duração do evento era feita pela contagem de pulsos recebida no receptor. A Figura 1 mostra o circuito utilizado. A Figura 2 mostra o aspecto dos protótipos montados.

Figura 1: Diagrama esquemático do módulo transmissor

Figura 2: Aspecto da montagem dos circuitos

A alimentação dos circuitos foi feita com pequenas baterias de 12 V utilizadas normalmente em controles remotos. A avaliação de consumo e o efeito de carga da bateria podem ser visualizados nos gráficos da Figura 3. Quando a descarga não é ativada, o consumo do circuito é zero. Os protótipos foram instalados no banheiro masculino no andar térreo do prédio 56 do IPT.

Figura 3: Acima, consumo de corrente durante a transmissão dos pulsos. Abaixo, desvio da frequência em função da tensão da bateria, que pode ser utilizada como uma indicação de carga para programação de troca.

Receptor

O módulo de recepção é composto por um receptor de rádio de 433 MHz e um circuito condicionador de sinal para fornecer pulsos em níveis TTL para os estágios posteriores. O diagrama esquemático do circuito deste módulo é mostrado na Figura 4. O consumo deste módulo é de 20 mA, utilizando uma fonte linear de 5 V. Fontes chaveadas geram muito ruído de RF. Os pulsos de saída TTL tem largura ajustada em 1 ms, e repetem-se enquanto a descarga é acionada. Na Figura 5 é possível observar o aspecto da montagem dos circuitos.

Figura 4: Diagrama esquemático do circuito do receptor.

Figura 5: Aspecto da montagem dos circuitos do módulo do receptor.

Modos de Operação

O sistema pode operar em dois modos de operação:

Frequência única

Os quatro transmissores são ajustados para a mesma taxa se repetição de pulsos.  O receptor opera como totalizador, atribuindo um determinado volume para cada pulso recebido (Não identifica o vaso da descarga).

Frequências múltiplas

Os quatro transmissores são ajustados para quatro frequências diferentes (Ex.: 20 Hz, 23 Hz, 26 Hz, 29 Hz). Quando o primeiro pulso é recebido (placa Zigbee wake up) a totalização é feita em intervalos de tempo parciais (Ex.: A cada 0,5 s), enquanto a recepção de pulsos não cessar. Assim é possível identificar a origem de cada descarga, e atribuir coeficientes de calibração de vazão específicos para cada vaso.

Instalação

Os módulos transmissores foram instalados nos botões de acionamento das válvulas de descarga, conforme ilustrado na Figura 6 e na Figura 7. O módulo de recepção foi montado numa caixa de proteção, conforme a Figura 8. A sua instalação foi feita na parede, acima das pias, num ponto de distribuição de energia, como mostrado na Figura 9.

Figura 6: instalação do módulo transmissor no interior do “espelho” da válvula.

 

Figura 7: Aspecto final da instalação dos transmissores.

 

Figura 8: Montagem do módulo de recepção.

 

Figura 9: Módulo de recepção instalado na parede.

PROTÓTIPO II

Foram realizados diversos testes de funcionamento no sistema implementado, mas os resultados não foram satisfatórios, principalmente em relação à sua susceptibilidade aos ruídos eletromagnéticos ambientes. Numa nova tentativa, foi utilizado um controle remoto comercial de quatro canais, como mostrado na Figura 10. Os botões de acionamento do controle foram substituídos pelas chaves colocadas nas descargas.

Figura 10: Controle remoto de quatro canais, que foi modificado para transmitir informações sobre o acionamento de descargas.

PROTÓTIPO III

Novamente os resultados não foram satisfatórios, pois o sistema não permitia medir a duração do evento, apenas a sua ocorrência. Para sanar este problema, foi projetado um circuito baseado no Encoder PT2262 [2]  (Figura 11) e no Decoder PT2272 [3] (Figura 12). Estes dois circuitos integrados são customizados para aplicações de controles remotos, e permitem a identificação de mais de 8000 endereços de transmissores. Foi montado o circuito mostrado no diagrama esquemático da Figura 13 e Figura 14, que envia um trem de pulsos codificados para o início do evento, e outro trem de pulsos codificados para o final do evento. O diagrama de estados é mostrado na Figura 15. A contagem do tempo entre estes dois códigos é feita no módulo receptor.

Figura 11: Encoder PT2262.

Figura 12: Decoder PT2272.

 

Figura 13: Diagrama de blocos do sistema de transmissão por rádio.

 

Figura 14: Diagrama esquemático do circuito do módulo transmissor.

 

Figura 15: Diagrama de temporização do sistema.

PROTÓTIPO IV

O protótipo anterior foi construído e instalado no banheiro do prédio 56 do IPT, e encontra-se em fase de testes. Até o momento os resultados foram positivos, com alcance suficiente e imunidade ao ruído.  A monitoração do uso de uma descarga já está sendo feita em tempo real com acesso remoto ao tempo e duração do evento.

Para replicar este módulo em grande escala há alguns inconvenientes:  A necessidade de modificar totalmente o controle remoto apenas para aproveitar o transmissor de rádio e o chip de codificação;  A frequência deste transmissor não é permitida no Brasil (315 MHz) para esta aplicação; O chip de codificação é customizado, não permitindo alterações nos protocolos, e sua aquisição é mais difícil; Os processos de transmissão e recepção são lentos (alguns décimos de segundo); A contagem do tempo é feita no módulo receptor.  Para evitar estas limitações, esta sendo desenvolvido um novo módulo transmissor, que utiliza componentes padronizados de baixo custo e consumo, que são facilmente adquiríveis (contadores, portas lógicas e shift registers de tecnologia cmos).  Nesta nova configuração, a contagem do tempo é feita no próprio módulo transmissor. Este envia um código de 16 bits logo após o final do evento com a sua duração e a identificação da origem.  Este código é configurável por hardware. Exemplo de configuração: 2 bits de sinalização, contador de tempo de 9 bits (tempo máximo de evento de 10 s  com resolução de 20 ms), endereço de 5 bits (até 32 dispositivos).  Não há necessidade de decodificador no receptor de rádio. A saída do receptor já fornece o código de 16 bits de forma serial.

O protótipo do módulo transmissor nesta nova configuração já está em fase de construção para testes de desempenho e comparação com as configurações dos protótipos anteriores. 

 

SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA

 

Outros artigos da série

 

 Referências 

 

 Licença Creative Commons

Esta obra, “SISTEMA PORTÁTIL DE MEDIÇÃO DE CONSUMO DE ÁGUA – Soluções alternativas para medir fluxo de água“, de  Ramon Vals Martin está sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional.