O que é telemetria industrial (na prática) e como começar

Telemetria industrial é a capacidade de coletar dados de equipamentos em campo, transmitir essas informações com confiabilidade e transformá-las em indicadores úteis para operação e decisão. Em vez de depender de rondas, planilhas e “sensações”, a telemetria cria um fluxo contínuo: sensores geram sinais, um controlador ou gateway organiza essas leituras e um protocolo leve — normalmente MQTT — entrega os dados para armazenamento e análise.

Por que isso importa (mesmo se você não for engenheiro)

Dados em tempo quase real permitem detectar falhas mais cedo, reduzir visitas ao campo e tomar decisões com base em métricas objetivas: tempo de funcionamento de bombas, ciclos por hora, nível de reservatórios, consumo específico de energia, tempo médio entre falhas (MTBF), entre outras. Na prática, telemetria reduz custo operacional, melhora a disponibilidade e aumenta a previsibilidade do processo.

Arquitetura mínima (do sensor ao dashboard)

Sensores/atuadores — nível, pressão, corrente, temperatura, estado de bomba etc.
PLC/RTU ou gateway — concentra sinais (digitais/analógicos), executa lógica simples, normaliza tags.
Protocolo de transporte — MQTT é o padrão de fato: publish/subscribe, leve, com QoS e retenção.
Broker — servidor MQTT que recebe mensagens e as distribui aos assinantes.
Persistência e analytics — banco de séries temporais ou relacional com estratégia de downsampling.
Dashboards e alertas — visualização, alarmes com histerese, notificações e trilhas de auditoria.

MQTT em 2 minutos

Tópicos são “endereços” hierárquicos (ex.: plantaA/linha1/bomba03/status).
QoS define garantia de entrega (0, 1, 2). Na maioria dos casos, QoS 1 é o melhor compromisso.
Retained messages mantêm o último valor no broker, útil para estados.
Last Will publica um aviso automático quando um cliente desconecta inesperadamente.

Edge vs Cloud: onde processar o quê?

Edge (no gateway/PLC): ideal para lógicas de segurança, intertravamentos, debouncing de sinais, agregações locais e buffer offline. Reduz latência e mantém o processo funcional durante quedas de internet.
Cloud: ótimo para armazenamento histórico, modelos analíticos, relatórios e colaboração entre times.

Na prática, um desenho híbrido costuma vencer: lógica crítica no edge, contexto e histórico na nuvem.

Segurança essencial (sem complicar)

TLS no broker (criptografia em trânsito).
Usuário/senha ou certificados, com ACL (controle por tópico: quem publica/quem lê).
Versione payloads (v1, v2) para evoluir sem quebrar integrações.
Separação de redes: campo (OT) isolado do corporativo (IT), com rotas e firewalls claros.
Observabilidade: métricas do próprio broker (conexões, taxa de mensagens, erros).

Padrão de tópicos e payloads (evite caos futuro)

Defina desde o início convenções claras.

Tópico: org/<site>/<área>/<equipamento>/<variável>
Ex.: org/acme/plantaA/linha1/bomba03/nivel_selo

Payload (JSON enxuto):

{
  "v": 2,
  "ts": 1730068800000,
  "value": 0.73,
  "unit": "m",
  "q": "ok"
}

Metadados (nome, unidade, limites) ficam em catálogo separado para não inflar cada mensagem.

Qualidade de dado: do “sinal” ao “insight”

Granularidade: defina taxas de amostragem compatíveis com o fenômeno (nível varia mais devagar que pressão).
Debouncing/histerese para sinais digitais: ameniza ruído e reduz falsos alarmes.
Agregações: calcule médias/mín./máx. por janela; salve brutos por período limitado e mantenha agregados para longo prazo.
Contexto: registre eventos (manutenção, troca de bomba) para explicar mudanças de perfil.

Custos: como não gastar à toa

Tráfego: multiplique taxa de mensagens × tamanho do payload × número de pontos. Reduza campos redundantes e prefira compressão entre gateway e nuvem quando possível.
Armazenamento: defina retenções diferentes (curto prazo bruto; médio prazo agregados de 1 min; longo prazo diários).
Dashboards: priorize KPIs realmente acionáveis (runtime, ciclos/h, consumo específico, alarmes abertos).

Erros comuns (e como evitar)

Tópicos sem padrão → difícil escalar e dar manutenção. Resolva com um catálogo de tags versionado.
QoS inadequado → ou saturação (QoS 2 sem necessidade) ou perda (QoS 0 em tudo). Use QoS 1 por padrão.
Sem buffer offline → buracos no histórico. Adote store & forward no gateway.
Payload “inchado” → custo alto e latência. Use JSON compacto e metadados fora da telemetria.
Alarme que grita → ajuste histerese, janelas móveis e prioridades para reduzir fadiga de alarme.

Como começar: roteiro em 7 passos (piloto enxuto)

Escolha um caso simples e crítico: ex. bomba de recalque e nível do reservatório.
Mapeie 8–12 pontos relevantes: nível, estado da bomba, corrente, pressão, falha térmica etc.
Defina padrão de tópicos/payload e crie o catálogo de tags (CSV ou JSON) com unidade e limites.
Implemente o gateway/PLC: leitura de I/O, normalização, QoS 1, retained quando fizer sentido, last will.
Ative buffer offline (store & forward) com fila persistente e política de reenvio idempotente.
Monte um dashboard mínimo viável: 1 visão executiva (KPIs) + 1 visão técnica (tendências).
Feche o ciclo com alarmes: defina 3–5 alarmes realmente úteis (nível baixo crítico, bomba em falha, sobrecorrente). Teste cenários e documente o playbook de resposta.

Exemplo prático de tópicos

Estado da bomba: org/acme/plantaA/linha1/bomba03/state → {"v":1,"ts":1730068800000,"value":"on"}
Nível do tanque: org/acme/plantaA/linha1/tanque01/level_m → {"v":1,"ts":1730068800000,"value":3.42,"unit":"m"}
Alarme de sobrecorrente: org/acme/plantaA/linha1/bomba03/alarms/overcurrent → {"v":1,"ts":1730068805000,"value":true}

O que esperar nos primeiros 30 dias

Semana 1: pontos no ar, dados chegando, dashboard básico.
Semana 2: ajuste de taxas, histerese e nomes; estabilização do catálogo de tags.
Semana 3: primeiros KPIs (runtime/ciclos/h) e alarmes sem falso-positivo.
Semana 4: relatório simples de disponibilidade e intervenções, com evidências objetivas.

Começar pequeno, com padrões bem definidos, costuma gerar vitórias rápidas e pavimentar a expansão para outras áreas. Telemetria industrial não é um projeto “big bang”; é um processo incremental, onde consistência e governança dos dados valem mais do que pirotecnia tecnológica.