Telemetria industrial: como levar o dado do sensor até o seu sistema

Quatro peças, sempre. O sensor mede (temperatura, vibração, pressão, corrente, nível). O gateway ou controlador junta as leituras de vários sensores e as traduz para um formato de rede. A conectividade leva esses dados para fora da fábrica — por cabo, Wi-Fi ou celular. E a plataforma recebe, guarda, mostra em painel e dispara alerta.

Quase todo projeto que falha falha na passagem entre duas camadas: o sensor mede, mas o dado não chega; o dado chega, mas ninguém olha o alerta.

Porque a rede corporativa nem sempre está onde o sensor está. Pátio, tanque externo, subestação, poço, linha de produção recém-instalada: puxar cabo até lá custa obra, e o Wi-Fi do escritório não alcança. Um gateway com chip M2M sai direto pela rede celular, sem depender da TI da fábrica para cada ponto novo.

Há também uma razão de segurança e de responsabilidade. Manter os dispositivos de telemetria numa rede separada da rede administrativa reduz o risco de um equipamento vulnerável virar porta de entrada para o resto da empresa — e simplifica quem responde por quê.

Na maioria dos projetos atuais, por MQTT: um protocolo leve de mensagens em que o gateway publica as leituras num broker (o servidor que distribui as mensagens) e a plataforma as recebe. Ele foi feito para redes instáveis e pacotes pequenos, o que combina com conexão celular.

Também é comum o gateway enviar por HTTP para uma API da plataforma, ou falar protocolos industriais (Modbus, OPC UA) com os equipamentos de um lado e MQTT com a nuvem do outro. O ponto de atenção é o mesmo: o gateway precisa guardar as leituras quando a conexão cai e reenviar depois, para não abrir buracos no histórico.

Os que evitam parada ou perda: vibração e temperatura de motor (para antecipar quebra), temperatura de câmara fria e de processo, pressão de compressor, nível de tanque e consumo de energia. Comece pelo equipamento cuja parada custa mais e cujo sinal de alerta é mais claro.

Um erro frequente é instrumentar tudo de uma vez e não ter ninguém para olhar. Comece pequeno, com um alerta que alguém realmente vai atender, e amplie quando o processo estiver rodando.

Telemetria pura consome pouco: leituras numéricas a intervalos regulares. O que aumenta o consumo é frequência alta (vibração em alta resolução, por exemplo) e o envio de arquivos ou imagens. Faça a conta por gateway — tamanho da mensagem, quantas por hora, quantas horas por dia — e acompanhe o consumo real nas primeiras semanas.

Em instalação crítica, use chip multioperadora no gateway e, onde houver, um segundo caminho por cabo. A plataforma deve avisar quando um gateway para de comunicar — silêncio também é um dado.

Quem é dono de cada camada (sensor, gateway, chip, plataforma) e quem atende quando algo para. Onde ficam os dados e quem tem acesso. Se a plataforma exporta os dados ou integra com o seu sistema por API. E o que acontece com o histórico se a conexão cair por algumas horas.

Projeto de telemetria bom é aquele em que, às três da manhã, alguém recebe o alerta certo e sabe o que fazer.