A coleta de dados do chão de fábrica é a base de todo projeto de manufatura inteligente: nenhum dashboard, indicador de OEE ou modelo preditivo é melhor que os dados por trás dele. Este guia compara os quatro principais métodos de coleta, mostra quando cada um se encaixa e explica como centralizar tudo em um único namespace MQTT, para que novas máquinas e novos consumidores possam ser adicionados sem retrabalho.
Quais dados você está realmente coletando?
Antes de escolher um método, liste as perguntas que você quer responder. A maioria das plantas começa com um punhado de sinais que respondem à maior parte das perguntas do dia a dia:
| Tipo de dado | Exemplo | Origem típica | Frequência típica |
|---|---|---|---|
| Estado da máquina | Rodando, ociosa, parada, setup | Bit de CLP, torre de sinalização, sensor de corrente | Por mudança |
| Contagens | Peças boas, refugo | Contador do CLP, sensor de proximidade | Por mudança ou por minuto |
| Variáveis de processo | Temperatura, pressão, velocidade | Tags de CLP, sensores analógicos | 1 a 10 segundos |
| Motivos de parada | Falta de material, troca de ferramenta | Apontamento do operador | Por evento |
| Resultados de qualidade | Aprovado/reprovado, dimensão medida | Estação de teste, instrumento | Por peça |
| Energia | kWh, kW | Medidor de energia | 1 a 60 segundos |
Estado e contagens bastam para análises de OEE e de paradas, e é por isso que costumam ser o ponto de partida. Os códigos de motivo vêm das pessoas, não das máquinas, então toda arquitetura precisa de uma forma de os operadores contribuírem. Para desenhar esses códigos, veja códigos de motivo de parada.
Métodos de coleta de dados do chão de fábrica comparados
1. Coleta manual
Folhas de papel, planilhas ou apontamentos em terminais preenchidos pelos operadores. Custa quase nada para começar e captura um contexto que as máquinas não conhecem, como o motivo de uma linha ter parado. Suas fraquezas são bem conhecidas: os apontamentos são feitos de memória no fim do turno, as paradas curtas desaparecem e os dados chegam tarde demais para que se possa agir.
A coleta manual continua útil para códigos de motivo e verificações, mas deve ser digital (um formulário em tablet que publica um evento) e limitada ao que só uma pessoa pode fornecer.
2. Leitura do CLP
Máquinas modernas têm um CLP que já conhece estado, contagens e muitas variáveis de processo. Ler essas tags pelo protocolo da máquina (Modbus TCP, OPC UA, EtherNet/IP, S7 e outros) fornece os dados mais ricos sem hardware novo.
O problema é o acesso. Os fabricantes de máquinas podem não documentar os endereços das tags, o CLP pode estar bloqueado e alterar o código do CLP pode afetar a garantia. Combine com o responsável pela máquina antes de escrever qualquer coisa em um controlador; a leitura geralmente é de baixo risco.
3. Sensores de retrofit
Em máquinas mais antigas, sem controladores acessíveis, acrescente sensores por fora: um transformador de corrente no motor principal para detectar se está rodando ou ociosa, um sensor de proximidade ou fotoelétrico para contar peças, um sensor de vibração ou temperatura para dados de condição ou um sensor de luz na torre de sinalização. Sensores sem fio tornam a instalação rápida; veja sensores industriais sem fio para conhecer as opções.
Sensores de retrofit enxergam menos que o CLP, mas funcionam em qualquer máquina, independentemente da idade ou da marca, e nunca tocam o sistema de controle.
4. Gateways de borda
Um gateway é um pequeno computador industrial que conversa localmente com CLPs e sensores e encaminha os dados adiante. Ele cuida da tradução de protocolos, do buffer durante quedas de rede, da filtragem (publicar por mudança em vez de a cada varredura) e de acrescentar contexto, como a posição da máquina na hierarquia da planta.
| Método | Riqueza dos dados | Esforço por máquina | Toca o sistema de controle | Ideal para |
|---|---|---|---|---|
| Manual | Baixa, mas com contexto | Muito baixo | Não | Códigos de motivo, verificações |
| Leitura do CLP | Alta | Médio | Somente leitura | Máquinas modernas |
| Sensores de retrofit | Média | Baixo | Não | Máquinas antigas |
| Gateway de borda | Alta | Médio | Somente leitura | Parques mistos, muitos protocolos |
A maioria das plantas acaba com uma combinação: gateways lendo CLPs nas linhas mais novas, sensores de retrofit nas mais antigas e tablets para os códigos de motivo.
Centralizando os dados do chão de fábrica com MQTT
O método escolhido para cada máquina importa menos do que o destino dos dados. Se cada coletor grava no seu próprio banco de dados, você recriou os silos que queria eliminar. O padrão melhor: todo coletor publica em um único broker MQTT com uma estrutura de topics consistente, e todo consumidor assina.
acme/plant1/machining/line1/cnc4/state {"state":"RUNNING","ts":...} retained
acme/plant1/machining/line1/cnc4/count {"good":1,"scrap":0,"ts":...}
acme/plant1/machining/line1/cnc4/spindle {"tempC":41.8,"rpm":8000,"ts":...}
acme/plant1/machining/line1/cnc4/reason {"code":"TOOL_CHANGE","by":"op17"}
O caminho segue a hierarquia ISA-95 descrita em topics MQTT ISA-95. Se um valor veio de um CLP, de um sensor alicate ou de um tablet passa a ser um detalhe de implementação: os consumidores só enxergam o topic. Esse mesmo fluxo organizado é o que permite, mais adiante, alimentar um gêmeo digital da linha.
Um exemplo mínimo de gateway
O script Python a seguir lê dois holding registers de um dispositivo Modbus TCP (um código de estado e um contador de peças), publica o estado por mudança como mensagem retained e publica os incrementos de contagem. Ele usa pymodbus 3.x e paho-mqtt 2.x e roda em um Raspberry Pi ou em qualquer PC industrial pequeno.
import json
import time
import uuid
import paho.mqtt.client as mqtt
from pymodbus.client import ModbusTcpClient
PLC_IP = "192.168.10.50"
BASE = "connectmq/demo/sfdc-91be/line1/cnc4" # substitua 91be pelo seu próprio id
STATES = {0: "STOPPED", 1: "RUNNING", 2: "IDLE", 3: "FAULT"}
mq = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"gw-cnc4-{uuid.uuid4().hex[:6]}")
mq.will_set(f"{BASE}/gateway", json.dumps({"online": False}), qos=1, retain=True)
mq.connect("broker.connectmq.com", 1883, keepalive=30)
mq.loop_start()
mq.publish(f"{BASE}/gateway", json.dumps({"online": True}), qos=1, retain=True)
plc = ModbusTcpClient(PLC_IP, port=502)
last_state, last_count = None, None
while True:
if not plc.connected:
plc.connect()
rr = plc.read_holding_registers(0, count=2)
if rr.isError():
print("Modbus read failed:", rr)
time.sleep(5)
continue
state = STATES.get(rr.registers[0], "UNKNOWN")
count = rr.registers[1]
now = time.time()
if state != last_state:
mq.publish(f"{BASE}/state", json.dumps({"state": state, "ts": now}), qos=1, retain=True)
last_state = state
if last_count is not None and count != last_count:
delta = (count - last_count) % 65536 # trata o estouro do contador de 16 bits
mq.publish(f"{BASE}/count", json.dumps({"good": delta, "total": count, "ts": now}), qos=1)
last_count = count
time.sleep(1)
O mesmo script funciona sem alterações com um broker ConnectMQ privado depois que você acrescenta credenciais e TLS. A mensagem de last will marca o gateway como offline se ele perder a conexão, para que os dashboards consigam distinguir "máquina parada" de "estamos sem dados". No servidor MQTT público tudo pode ser lido por qualquer pessoa, então use-o apenas com valores simulados; para máquinas reais, mude para credenciais privadas e TLS.
Checklist de coleta de dados do chão de fábrica
Use esta lista antes de expandir para além de uma linha piloto:
- Defina as perguntas primeiro e colete apenas os sinais que as respondem.
- Combine uma hierarquia de topics que espelhe o layout da sua planta e documente-a.
- Coloque o timestamp na origem (gateway ou controlador), em UTC.
- Publique por mudança os estados e as contagens; amostre as variáveis de processo em uma frequência fixa razoável.
- Mantenha o estado atual como retained para que novos assinantes o vejam imediatamente.
- Sinalize a qualidade dos dados: gateway online/offline via last will, falhas de sensor como valores explícitos.
- Trate o estouro de contadores e os reinícios do gateway sem contar em dobro.
- Dê a cada dispositivo seu próprio client ID e credenciais.
- Deixe os operadores acrescentarem contexto com um formulário digital simples de códigos de motivo.
- Confira os dados com a realidade por uma semana antes que alguém construa KPIs em cima deles.
Da coleta ao valor
Com os dados fluindo, os próximos passos são diretos: monitoramento do status de máquinas em uma tela na linha, análise de OEE e de paradas e, depois, integração com MES ou com a manutenção. Cada um é apenas mais um assinante.
O broker no meio deveria ser a menor das suas preocupações. O ConnectMQ é um broker MQTT gerenciado com MQTT 3.1.1 e 5.0, endpoints TLS e WebSocket seguro, um explorador de topics ao vivo e uma visão de dispositivos agrupada pelos níveis ISA-95, o que facilita confirmar que cada coletor publica no lugar certo. Regras de alerta por limite no portal podem avisar quando um valor como a temperatura do spindle ultrapassa um patamar. O guia de manufatura inteligente mostra como essas peças se encaixam em um roteiro completo para a planta, e o servidor MQTT público gratuito é o caminho mais rápido para testar seu script de gateway antes de criar credenciais.
Comece a coletar dados do chão de fábrica com o ConnectMQ
Crie um broker no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, e aponte seu primeiro gateway para ele com o username, a senha e o client ID gerados.
Perguntas frequentes
Qual é a forma mais barata de começar a coleta de dados do chão de fábrica?
Um sensor de corrente ou de contagem de peças em uma máquina gargalo, um pequeno gateway e um broker gratuito. Só isso já fornece tempo rodando, tempo ocioso e produção da máquina que limita a sua linha.
Devo ler os dados do CLP ou acrescentar sensores?
Leia o CLP quando tiver acesso e documentação, porque ele já guarda dados ricos. Use sensores de retrofit em máquinas antigas ou bloqueadas, onde o acesso ao CLP é impossível ou arriscado.
Com que frequência os dados de máquina devem ser coletados?
Estados e contagens devem ser publicados por mudança. Variáveis de processo costumam ser amostradas a cada 1 a 10 segundos, o que basta para dashboards e análise de tendências sem inundar a rede.
Preciso de um MES para a coleta de dados do chão de fábrica?
Não. Coleta, dashboards e OEE podem rodar diretamente sobre dados MQTT. Um MES passa a ser útil mais tarde, quando você precisar de acompanhamento de ordens, genealogia e fluxos de trabalho obrigatórios.
