Integração MES MQTT: ordens, contagens e qualidade orientadas a eventos

A integração MES MQTT substitui o emaranhado de interfaces customizadas entre um sistema de execução da manufatura (MES) e o chão de fábrica por um único namespace orientado a eventos. Este guia mostra como estruturar topics para ordens de produção, contagens e resultados de qualidade, o que os payloads devem conter e como escrever um pequeno adaptador que conecta um MES a um broker MQTT.

Por que a integração do MES costuma ser a parte mais difícil

Um sistema de execução da manufatura acompanha o que está sendo produzido, em qual equipamento, por quem e com qual resultado. Para isso, ele precisa de dados das máquinas e precisa enviar instruções de volta. Tradicionalmente, isso acontece por links ponto a ponto: uma conexão OPC aqui, uma tabela de banco de dados consultada a cada minuto ali, um arquivo CSV que o CLP da linha deixa em uma pasta compartilhada.

Cada link funciona isoladamente, mas juntos criam problemas que todo engenheiro de planta reconhece, seja em uma montadora em Campinas ou em uma fábrica em Joinville:

• Adicionar um segundo consumidor (um dashboard de OEE, um sistema de manutenção) significa construir outra interface para a mesma máquina.
• O polling introduz atraso e carga; uma contagem só é tão atual quanto a última consulta.
• Quando o MES é atualizado ou substituído, todas as interfaces quebram ao mesmo tempo.
• Ninguém tem um lugar único para ver quais dados realmente trafegam.

Uma abordagem orientada a eventos inverte essa lógica. Máquinas e gateways publicam o que acontece, no momento em que acontece. O MES assina os eventos de que precisa e publica suas próprias decisões, como uma ordem de produção liberada. Outros sistemas assinam os mesmos eventos sem tocar no MES. Se você não tem certeza de onde o MES fica em relação ao ERP e ao SCADA, leia antes MES vs ERP vs SCADA.

Como funciona a integração MES MQTT

A peça central é um broker MQTT ao qual todos os participantes se conectam como clientes. Ninguém se conecta diretamente a ninguém. Três fluxos cobrem a maior parte das necessidades do MES:

O caminho do topic segue a hierarquia de equipamentos ISA-95 (empresa, site, área, linha, célula), que é a espinha dorsal de um Unified Namespace. Os detalhes dessa nomenclatura estão em como construir um Unified Namespace.

Dois recursos do MQTT são especialmente importantes para o tráfego do MES:

• Retained messages. A ordem de produção atual e o estado atual da máquina são retidos, então uma IHM que reinicia sabe imediatamente o que produzir sem perguntar ao MES.
• QoS 1. Contagens e resultados de qualidade não podem ser perdidos, por isso são publicados com entrega pelo menos uma vez (at-least-once). O MES precisa, portanto, tratar duplicatas, normalmente mantendo um número de sequência por publicador.

Contratos de payload que resistem a mudanças

Os topics dizem de onde veio um evento; os payloads dizem o que aconteceu. Defina um contrato por tipo de evento e versione-o. Um evento de contagem em que o MES pode confiar se parece com isto:

{
  "schema": "count/v1",
  "ts": "2026-10-16T08:42:13.512Z",
  "seq": 18233,
  "orderId": "WO-2026-04417",
  "material": "HSG-220-B",
  "good": 1,
  "scrap": 0,
  "source": "cell3-plc"
}

Algumas regras mantêm esses contratos robustos:

1. Envie incrementos ou totais, não os dois. Incrementos com número de sequência são fáceis de deduplicar; totais são fáceis de recuperar depois de uma lacuna. Escolha um por sinal e documente.
2. Inclua o ID da ordem. A linha já conhece a ordem ativa pelo topic retido da ordem, então carimbá-la em cada evento poupa uma consulta ao MES e evita contagens atribuídas à ordem errada na troca de ordem.
3. Registre o timestamp na origem, em UTC com milissegundos.
4. Inclua um campo de schema para que os consumidores consigam lidar com count/v2 sem quebrar.

Um adaptador MES funcional em Python

A maioria dos produtos MES expõe uma API REST ou uma interface de banco de dados, e não MQTT. Um pequeno adaptador faz a ponte entre os dois: ele assina os eventos do chão de fábrica e chama o MES, e publica as decisões do MES de volta no namespace. O exemplo abaixo usa paho-mqtt 2.x e uma função de exemplo post_to_mes que você substitui pela chamada à API do seu MES.

import json
import uuid

import paho.mqtt.client as mqtt

LINE = "connectmq/demo/mes-5c21/line2"   # use o caminho ISA-95 completo em produção
last_seq = {}

def post_to_mes(kind, event):
    # Substitua por uma chamada à API do seu MES, por exemplo requests.post(...)
    print(f"MES <- {kind}: {event}")

def release_order(client, order_id, material, quantity):
    order = {"schema": "order/v1", "orderId": order_id,
             "material": material, "quantity": quantity, "status": "RELEASED"}
    client.publish(f"{LINE}/mes/order/current", json.dumps(order), qos=1, retain=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(f"{LINE}/+/count", qos=1)
    client.subscribe(f"{LINE}/+/state", qos=1)
    client.subscribe(f"{LINE}/+/result", qos=1)
    client.subscribe(f"{LINE}/mes/order/ack", qos=1)
    release_order(client, "WO-2026-04417", "HSG-220-B", 500)

def on_message(client, userdata, msg):
    event = json.loads(msg.payload)
    kind = msg.topic.rsplit("/", 1)[-1]
    source = msg.topic.split("/")[-2]
    seq = event.get("seq")
    if seq is not None:
        key = (source, kind)
        if seq <= last_seq.get(key, -1):
            return  # duplicata de uma reentrega QoS 1
        last_seq[key] = seq
    post_to_mes(kind, {"source": source, **event})

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"mes-adapter-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Teste-o no servidor MQTT público publicando uma contagem pela linha de comando:

mosquitto_pub -h broker.connectmq.com -p 1883 -i cell3-test-5c21 -q 1 \
  -t "connectmq/demo/mes-5c21/line2/cell3/count" \
  -m '{"schema":"count/v1","seq":1,"orderId":"WO-2026-04417","good":1,"scrap":0}'

Publique a mesma mensagem duas vezes e o adaptador a encaminha apenas uma vez. Lembre-se de que o servidor MQTT público pode ser lido por qualquer pessoa e serve para testes e protótipos, então use apenas números de ordem inventados.

Em produção, mantenha o estado de deduplicação (last_seq) em um local durável, execute o adaptador com sessão persistente para que ele receba os eventos enfileirados enquanto reinicia e dê a ele suas próprias credenciais.

Padrões de integração e armadilhas

Comandos precisam de confirmação. Quando o MES libera uma ordem, a linha deve publicar uma confirmação com o ID da ordem e o status (aceita, rejeitada, iniciada). Sem isso, o MES não sabe se a ordem chegou. O request/response do MQTT 5, com response topic e correlation data, formaliza esse padrão.

Mantenha o MES fora do loop da máquina. Intertravamentos e lógica de segurança ficam no CLP. O MQTT transporta eventos e instruções, não controle de tempo real rígido.

Não deixe o MES virar o namespace. Se todos os consumidores leem dados através do MES, você volta à integração ponto a ponto. Publique os eventos brutos no broker e deixe o MES ser apenas um assinante entre muitos, ao lado de ferramentas de coleta de dados do chão de fábrica, dashboards de OEE e historiadores.

Planeje as trocas de ordem. A maioria das contagens atribuídas à ordem errada acontece nos segundos em torno de uma troca de ordem. Faça a linha carimbar o ID da ordem em cada contagem e faça o MES fechar uma ordem apenas depois de receber um evento explícito de término.

Rodando o namespace em um broker MQTT gerenciado

Quando o MES, os gateways e os dashboards dependem do broker, a disponibilidade e a segurança dele passam a ser a disponibilidade e a segurança da sua integração. Um broker MQTT gerenciado elimina o trabalho de aplicar patches, cuidar de certificados e monitorar um broker por conta própria. O ConnectMQ oferece MQTT 3.1.1 e 5.0 sobre TLS (8883) e WebSocket seguro (8084), credenciais vinculadas a client IDs e um portal com explorador de topics ao vivo e uma visão de dispositivos organizada pelos níveis ISA-95, o que facilita verificar se contagens e estados chegam sob a linha e a célula corretas.

Se suas máquinas falam Sparkplug B, o ConnectMQ pode decodificá-lo e republicar os dados em topics ISA-95 legíveis, para que o adaptador do MES assine caminhos JSON simples em vez de Protobuf. Para a visão arquitetural mais ampla, veja o guia de manufatura inteligente e a visão geral do que um broker MQTT na nuvem oferece.

Conecte seu MES ao ConnectMQ

Cadastre-se em app.connectmq.com, crie um broker no plano Serverless gratuito sem cartão de crédito e aponte o adaptador acima para ele com YOUR_USERNAME, YOUR_PASSWORD e YOUR_CLIENT_ID obtidos no portal.

Perguntas frequentes

Meu MES precisa ter suporte nativo a MQTT?

Não. Muitas integrações usam um pequeno adaptador que fala MQTT de um lado e a API ou o banco de dados do MES do outro. O suporte nativo apenas dispensa o adaptador.

O MES deve publicar as ordens de produção como retained messages?

Sim. A ordem atual de cada linha é um estado, não um evento, então retê-la permite que qualquer cliente que se conecte depois saiba o que está rodando. O histórico de ordens pertence ao banco de dados do MES.

Como evito contagem dupla com QoS 1?

Adicione um número de sequência por publicador a cada evento de contagem e descarte qualquer sequência que o adaptador já tenha processado. Como alternativa, publique totais acumulados e calcule as diferenças no lado do MES.

O MQTT é seguro o suficiente para o tráfego do MES?

Com TLS, credenciais únicas por cliente e um broker que imponha o vínculo ao client ID, o MQTT é adequado para o tráfego do MES entre a planta e a nuvem. Mantenha a lógica de segurança e de intertravamento no CLP.