Automação de sistemas de água prediais: do sensor ao dashboard

Sistemas de água prediais parecem simples: um reservatório inferior recebe água da rede pública, uma bomba eleva para o reservatório superior, e a gravidade distribui para as unidades. Na prática, garantir disponibilidade, qualidade e eficiência exige automação e telemetria. Este guia apresenta uma arquitetura do sensor ao dashboard, com escolhas de sensores, padrões MQTT, KPIs e um roteiro de implementação.

Arquitetura de referência

Sensores & atuadores: nível, pressão, vazão (opcional), estado/falha de bomba, corrente elétrica.
PLC/RTU ou gateway: leitura de I/O, histerese/antioscilação, intertravamentos, normalização de tags.
MQTT: publicação com QoS 1, tópicos padronizados, mensagens retidas para estados.
Broker: local e/ou nuvem, com TLS e ACL por tópico.
Persistência: banco de séries temporais/relacional com retenções diferenciadas e downsampling.
Dashboards & alarmes: visão executiva (disponibilidade, consumo, eventos) e visão técnica (tendências).

Sensores: prós e contras

Grandeza	Opções	Prós	Contras	Uso típico
Nível	Boia (ON/OFF), Ultrassônico, Pressão hidrostática	Boia é barata; ultrassônico sem contato; pressão é robusto	Boia é binária; ultrassônico sensível a espuma/eco; pressão requer calibração	Controle de partida/parada; tendência e alarmes
Pressão	Transdutor 4–20 mA	Confiável; diagnóstico de cavitação/restrições	Instalação com tomada de pressão; precisa de compensação	Rede de distribuição, sucção/descarga
Vazão	Eletromagnético, ultrassônico clamp-on	Gestão de consumo e perdas	Custo maior; instalação/conduto reto	Condomínios grandes, auditorias
Elétrico	TC para corrente, contato de falha térmica	Proteção e saúde da bomba	Escala/config. adequadas	Alarmes de sobrecorrente, runtime

Lógica no PLC/gateway

Histerese para nível: evita liga/desliga frequente (short cycling).
Intertravamentos: pressão mínima de sucção, válvula aberta, atraso entre partidas.
Detecção de falhas: sobrecorrente, falta de fase, motor não parte, seca (pressão baixa persistente).
Agregações: médias de nível a cada 10 s, contadores de partidas, runtime acumulado.
Store & forward: fila persistente durante perda de internet.

Padrões MQTT (tópicos e payloads)

Tópico: org/<site>/agua/<equip>/<variavel>

Estado da bomba (retido): org/acme/torreA/agua/bomba01/state → {"v":1,"ts":1730162400000,"value":"on"}
Nível (m): org/acme/torreA/agua/reservatorio_sup/level_m → {"v":1,"ts":1730162410000,"value":3.12,"unit":"m"}
Pressão (bar): org/acme/torreA/agua/rede/pressure_bar → {"v":1,"ts":1730162415000,"value":2.8,"unit":"bar"}
Evento (não retido): org/acme/torreA/agua/bomba01/events/overcurrent → {"v":1,"ts":1730162420000,"value":true}
Status do gateway (LWT, retido): org/acme/torreA/gateway/status → {"v":1,"ts":1730162430000,"value":"online"}

Boas práticas: QoS 1 como padrão; retained apenas para estados/setpoints; versionar payload (v); manter metadados (unidades, limites, nomes) fora da telemetria em um catálogo.

KPIs e dashboards

Disponibilidade do sistema (% tempo com pressão ≥ limite na rede).
Runtime de bomba (h/dia), partidas/dia e ciclos por hora.
Nível do reservatório (tendência, mín/máx, tempo em faixas críticas).
Alarmes ativos (prioridade, tempo de reconhecimento, recorrência).
Consumo específico (kWh/m³) quando houver medição elétrica e vazão.

UX do painel: uma visão executiva com cartões de status (verde/âmbar/vermelho), KPIs e último evento; e uma visão técnica com tendências (nível, pressão) e tabela de eventos com filtros.

Alarmes inteligentes (reduzindo ruído)

Histerese em nível e pressão; evite thresholds simples.
Debounce em digitais (falha térmica, boia).
Janelas móveis para detectar tendência de esvaziamento.
Prioridades: crítico (parada do sistema), alto (falha de bomba), médio (nível baixo).
Playbooks: ação sugerida por alarme e tempo de resposta esperado.

Resiliência e segurança

Buffer offline no gateway, com reenvio idempotente.
TLS no broker; ACL por tópico; usuários separados por função.
LWT para status de gateways; estados de equipamentos como mensagens retidas.
Segmentação OT/IT e inventário de ativos (credenciais, firmware).

Custos sob controle

Publicar por variação (delta) ou em janelas (ex.: média 10 s) para reduzir tráfego.
Retenção: brutos por 7–14 dias; agregados de 1 min por 6–12 meses; diários para longo prazo.
Foque em KPIs acionáveis; evite coleções de gráficos sem uso operacional.

Checklist de comissionamento

Instrumentação: verifique escala/offset, polaridade em 4–20 mA e vedação/posição de sensores.
Lógica: teste histerese de nível, intertravamentos, tempo mínimo entre partidas.
MQTT: valide tópicos, QoS, retained e LWT; execute teste de queda de internet.
Alarmes: simule sobrecorrente, nível baixo prolongado, pressão fora de faixa.
Dashboards: revise rótulos, unidades, limites e cores; crie usuários e permissões.
Documentação: catálogo de tags, políticas de retenção, playbooks e contatos de plantão.

Exemplo de sequência operacional

Nível do superior cai abaixo de StartLevel; PLC aplica histerese e liga bomba.
Gateway publica .../bomba01/state = "on" (retido) e começa a enviar pressão/nível a cada 10 s.
Se pressão de sucção < limite, intertravamento desliga a bomba e evento .../events/low_suction é publicado.
Ao atingir StopLevel e estabilidade, bomba desliga; runtime e partidas são acumulados e enviados.
Dashboard atualiza KPIs e alarmes; relatório diário consolida disponibilidade e eventos.

Conclusão: com sensores adequados, lógica robusta no PLC/gateway e um pipeline MQTT bem governado, é possível transformar sistemas de água prediais em operações visíveis, previsíveis e eficientes. Comece pelo essencial (nível, pressão, estado/falha da bomba), padronize tópicos e payloads, e evolua para KPIs e alarmes inteligentes. O resultado: menos emergências, mais disponibilidade e decisões baseadas em dados.