Um broker MQTT industrial fica no centro dos dados da sua planta: todos os gateways publicam nele e todos os sistemas SCADA, MES, historiadores e dashboards leem dele. Neste guia você vai aprender quais capacidades separam um broker que sobrevive ao chão de fábrica de outro que apenas passa em testes de protocolo, e vai executar um pequeno script em Python que verifica os comportamentos mais importantes em qualquer broker que estiver avaliando.
Por que o uso industrial muda os requisitos
Qualquer broker compatível consegue rotear uma mensagem de um publisher para um subscriber. Em um app de IoT de consumo, isso muitas vezes basta. Em uma planta, seja uma fábrica de eletroeletrônicos em Manaus ou um frigorífico no interior, o broker carrega mais do que mensagens. Ele carrega estado: quais máquinas estão online, o valor atual de cada tag e se uma leitura está atualizada ou desatualizada. Os operadores tomam decisões a partir desse estado e, em algumas arquiteturas, os sistemas SCADA disparam alarmes com base nele. Um gêmeo digital da linha também só é fiel se esse estado estiver correto e atualizado.
O tráfego industrial também é diferente. Milhares de tags mudam em ritmos irregulares, uma linha inteira pode se reconectar de uma só vez depois de uma oscilação na rede, e os payloads podem ser protobuf Sparkplug B em vez de JSON legível. Os clients vivem por anos em gateways que ninguém quer mexer. Um broker que funciona bem em um projeto pessoal pode ter dificuldades nessas condições. Se o papel do broker em si é novidade para você, comece por o que é um broker MQTT.
Capacidades essenciais de um broker MQTT industrial
| Capacidade | Por que importa em uma planta | O que verificar |
|---|---|---|
| MQTT 3.1.1 e 5.0 | Gateways antigos e clients novos precisam coexistir | As duas versões aceitas no mesmo endpoint |
| Retained messages | Novos subscribers precisam do estado atual na hora | Valores retidos entregues na assinatura |
| Sessões persistentes | Gateways se reconectam sem perder dados QoS 1 | Expiração de sessão respeitada, mensagens enfileiradas entregues |
| Last will and testament | Gateways offline precisam ser sinalizados automaticamente | Will publicado em desconexão abrupta |
| Suporte a Sparkplug B | Payloads protobuf são opacos sem decodificação | Payloads legíveis nas ferramentas |
| Estrutura ISA-95 / UNS | Os dados precisam ser encontrados pela hierarquia da planta | Árvore de topics navegável por site, área, linha |
| TLS e autenticação | Dados da planta atravessam zonas de rede | TLS na 8883, credenciais por client |
| Proteção contra abuso | Um gateway com mau comportamento não pode prejudicar os outros | Cotas, proteção contra flood, bloqueio de login |
| Visibilidade | Comissionamento e troubleshooting exigem enxergar os dados | Explorador de topics ao vivo, estado de conexão, alertas |
| Modelo de operação | Alguém precisa aplicar patches e monitorar | Responsabilidade clara, gerenciado ou auto-hospedado |
Suporte a Sparkplug
O Sparkplug B define a estrutura de topics, os certificados de nascimento e morte e um payload protobuf para MQTT industrial. A rigor, o broker não precisa entender Sparkplug: trata-se de uma especificação do lado do client, e qualquer broker MQTT 3.1.1 com suporte a retained messages, QoS e wills consegue transportá-lo. Na prática, porém, um broker capaz de decodificar payloads Sparkplug economiza horas. Durante o comissionamento você quer ver Temperature = 72.4, e não um bloco binário. Leia nosso guia sobre o payload Sparkplug B para entender o que há dentro dele.
Um passo ainda mais útil é a republicação. Topics Sparkplug como spBv1.0/factory1/DDATA/line1/cnc1 são compactos, mas pouco amigáveis para consumidores de TI. Um broker capaz de republicar essas métricas em topics ISA-95 como connectmq/factory1/production/line1/cnc1/telemetry permite que o SCADA nativo em Sparkplug e as aplicações de negócio orientadas a JSON usem os mesmos dados. A relação entre os dois modelos é explicada em Sparkplug B e o Unified Namespace.
Estado retido e sessões
Um Unified Namespace só funciona se um dashboard aberto às 9h00 conseguir ver o estado de cada máquina às 9h00, e não apenas depois da próxima mudança de cada máquina. É isso que as retained messages oferecem. Sessões persistentes com uma expiração de sessão sensata protegem contra a outra falha comum: um gateway que se reconecta depois de uma breve queda de rede e perde tudo o que foi publicado nas suas assinaturas nesse intervalo. Em sistemas Sparkplug, a primary host application depende desses mecanismos, junto com os certificados de morte, para acompanhar o estado dos edge nodes.
Segurança compatível com a realidade da TO
Os gateways devem se autenticar com credenciais próprias, conectar-se via TLS e ser bloqueados se alguém insistir no login com senhas erradas. Client IDs vinculados às credenciais impedem que um dispositivo se passe por outro ou o derrube reutilizando seu ID. O broker também deve limitar quanto um único client pode publicar, para que um gateway mal configurado publicando uma tag a cada milissegundo não degrade o serviço para o resto da planta.
Visibilidade para quem comissiona o sistema
A capacidade de broker mais subestimada é uma boa janela para dentro dele. Quando um engenheiro de automação conecta um novo gateway, a primeira pergunta é sempre "os dados estão chegando, e no lugar certo?". Um explorador de topics ao vivo, uma visão dos clients conectados e um topic de estado de conexão respondem isso em segundos. Alertas por limite transformam o broker de um simples cano em uma ferramenta básica de monitoramento para valores como limites de temperatura ou a saúde dos gateways.
Disponibilidade e modelo de operação
Pergunte quem aplica patches no broker, quem renova os certificados, quem acompanha disco e memória e quem é acionado às 3 da manhã. Auto-hospedar dá controle total, mas torna a equipe da planta responsável por um servidor exposto à internet. Um broker MQTT gerenciado transfere esse trabalho para o provedor. Seja qual for a escolha, planeje como os clients se comportam durante um reinício do broker: reconexão com backoff, retomada de sessões e republicação de births ou do estado retido quando necessário.
Teste você mesmo qualquer broker MQTT industrial
Listas de funcionalidades são fáceis de escrever. Este script MQTT 5 verifica quatro comportamentos que importam em plantas: entrega de mensagens retidas, retomada de sessão, last will e reason codes. Execute-o primeiro contra o servidor MQTT público e depois contra qualquer broker que você estiver avaliando.
import time
import uuid
import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes
HOST, PORT = "broker.connectmq.com", 1883
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1"
def make_client(cid):
return mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=cid, protocol=mqtt.MQTTv5)
def session_props(seconds):
p = Properties(PacketTypes.CONNECT)
p.SessionExpiryInterval = seconds
return p
received = []
def on_message(client, userdata, msg):
received.append((msg.topic, msg.payload.decode(), msg.retain))
# 1. O gateway publica o estado retido e registra um last will
gw = make_client("gw-" + uuid.uuid4().hex[:6])
gw.will_set(f"{BASE}/gw1/status", "OFFLINE", qos=1, retain=True)
gw.connect(HOST, PORT, keepalive=5)
gw.loop_start()
gw.publish(f"{BASE}/gw1/status", "ONLINE", qos=1, retain=True)
gw.publish(f"{BASE}/cnc1/state", "RUNNING", qos=1, retain=True).wait_for_publish()
# 2. Um subscriber tardio com sessão persistente recebe o estado retido na hora
sub_id = "scada-" + uuid.uuid4().hex[:6]
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
sub.subscribe(f"{BASE}/#", qos=1)
time.sleep(2)
print("Retained on subscribe:", received)
# 3. O subscriber cai, o gateway publica, o subscriber retoma a sessão
sub.disconnect(); sub.loop_stop()
gw.publish(f"{BASE}/cnc1/state", "IDLE", qos=1).wait_for_publish()
received.clear()
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
time.sleep(2)
print("Delivered after resume:", received)
# 4. Simula uma falha do gateway: para o loop de rede sem DISCONNECT
received.clear()
gw.loop_stop()
gw.socket().close()
time.sleep(10) # aguarda mais de 1,5 x keepalive
print("Last will:", received)
sub.disconnect()
Saída esperada: os valores retidos ONLINE e RUNNING na assinatura, a mudança IDLE entregue depois que a sessão é retomada, mesmo tendo sido publicada enquanto o subscriber estava ausente, e OFFLINE chegando assim que o broker percebe que o gateway sumiu. Lembre-se de que o servidor MQTT público é só para testes, pode ser lido por qualquer pessoa (nunca envie dados de produção) e tem limites intencionais (mensagens de 64 KB, 10 mensagens por segundo por client, expiração de sessão de até 30 minutos), então faça testes de carga apenas no seu próprio broker.
Checklist de avaliação
- Execute o script acima contra o broker candidato com TLS na porta 8883.
- Publique tráfego Sparkplug B real a partir de um simulador e verifique se você consegue lê-lo nas ferramentas do broker.
- Reconecte 50 clients ao mesmo tempo e observe se há conexões rejeitadas ou CONNACKs lentos.
- Publique rápido demais de propósito e veja qual reason code você recebe de volta, por exemplo 0x97 (quota exceeded) no MQTT 5.
- Tente cinco senhas erradas seguidas e confirme que o broker reage.
- Pergunte quem opera o broker e como funciona a renovação de certificados.
Para uma comparação mais ampla, fora do contexto industrial, veja como escolher um broker MQTT para IoT.
Como o ConnectMQ aborda o uso industrial
O ConnectMQ é um broker MQTT gerenciado construído com esses requisitos em mente. Ele suporta MQTT 3.1.1 e 5.0 sobre TCP, TLS, WebSocket e WebSocket seguro, retained messages, expiração de sessão e todos os reason codes do MQTT 5. Ele detecta topics ISA-95 e de Unified Namespace, decodifica Sparkplug B (protobuf e JSON) e republica métricas Sparkplug em topics ISA-95. Cada broker expõe o estado de conexão em $SYS/broker/connection/{clientId}/state, e o portal acrescenta um explorador de topics ao vivo, uma visão de dispositivos por nível ISA-95 e regras de alerta por limite. Isolamento multi-tenant, cotas por plano, proteção contra flood e bloqueio de IP após repetidas falhas de login protegem cada tenant. Os planos vão do Serverless gratuito a clusters Dedicated, BYOC na sua própria conta de nuvem e Self Managed Enterprise. Para os trade-offs de hospedagem em geral, leia nosso guia de broker MQTT na nuvem; para o panorama industrial mais amplo, veja IoT Industrial com MQTT.
Comece com o ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Aponte o script de teste e um simulador Sparkplug para ele e, em poucos minutos, veja os dados da sua planta decodificados e organizados por nível ISA-95 no portal do ConnectMQ.
Perguntas frequentes
Um broker MQTT industrial precisa suportar Sparkplug B?
O Sparkplug B funciona em qualquer broker compatível que tenha retained messages, QoS e last will. Um broker que também decodifica payloads Sparkplug torna o comissionamento e o troubleshooting muito mais fáceis.
O MQTT 5 é obrigatório para uso industrial?
Não, o Sparkplug B e muitos gateways usam MQTT 3.1.1. O MQTT 5 acrescenta recursos úteis, como expiração de sessão, reason codes e assinaturas compartilhadas, por isso o broker deve suportar as duas versões.
Devo auto-hospedar ou usar um broker MQTT industrial gerenciado?
Auto-hospedar dá controle total, mas torna sua equipe responsável por patches, certificados e monitoramento. Um broker MQTT gerenciado elimina esse trabalho, e opções como BYOC mantêm o broker na sua própria conta de nuvem.
Como sei se um gateway ficou offline?
Configure uma last will message retida, como OFFLINE, em um topic de status. O broker a publica automaticamente quando o gateway se desconecta sem um DISCONNECT limpo.
