IoT Industrial com MQTT: O Guia Completo de IIoT

A IoT industrial com MQTT é a forma como as fábricas modernas levam dados de CLPs, sensores e máquinas aos sistemas que agem sobre eles, sem as integrações ponto a ponto frágeis do passado. Este guia explica por que o MQTT se tornou a espinha dorsal da IIoT, como uma arquitetura da borda à nuvem é montada, onde entram o Sparkplug B e os namespaces de topics ISA-95, e como construir um primeiro fluxo de dados da máquina ao broker com código executável. No final você terá uma arquitetura de referência e um checklist para levar à sua próxima reunião de projeto.

Por Que o MQTT Se Tornou a Espinha Dorsal da IoT Industrial

A automação clássica segue o modelo em camadas de Purdue: sensores conversam com CLPs, CLPs com o SCADA, o SCADA com um historiador, e o MES e o ERP ficam no topo. Cada camada se integra à seguinte por conexões ponto a ponto, muitas vezes com protocolos proprietários. Adicionar um único novo consumidor de dados de máquina, como um dashboard de qualidade ou um modelo de manutenção preditiva, significa mexer em vários desses elos.

O MQTT quebra esse padrão com publish/subscribe. Cada fonte de dados publica uma única vez em um broker central, e qualquer número de consumidores assina exatamente o que precisa. Se esse modelo é novo para você, o que um broker MQTT faz cobre os fundamentos. No uso industrial, algumas características do MQTT importam especialmente:

• Conexões apenas de saída. Os dispositivos de borda abrem conexões com o broker; nada precisa entrar na rede da fábrica. Isso se encaixa muito melhor nas políticas de segurança de TO do que protocolos de polling que exigem acesso de entrada.
• Report by exception. Os dispositivos publicam quando um valor muda, em vez de serem consultados em um ciclo fixo, o que reduz drasticamente a banda em links lentos ou tarifados. Veja report by exception.
• Consciência de estado. Mensagens de Last Will and Testament, valores retidos e keep-alives informam a cada consumidor se uma máquina está online e qual foi seu último estado conhecido.
• Footprint leve. Clientes MQTT rodam em CLPs, gateways e até microcontroladores, e funcionam em links celulares.
• Padrão aberto. O MQTT é um padrão OASIS com clientes em todas as linguagens, então você não fica preso à stack de um único fornecedor.

Isso não torna o OPC UA nem os protocolos de fieldbus obsoletos. O OPC UA continua excelente para modelos de informação ricos e acesso em nível de máquina, e é por isso que a maioria das arquiteturas IIoT combina os dois; nós os comparamos em OPC UA vs MQTT.

Arquitetura de Referência de IoT Industrial com MQTT

Uma arquitetura IIoT prática tem quatro camadas. Cada uma tem uma função clara, e o broker fica no centro.

O artigo sobre arquitetura IIoT aprofunda cada camada. Estas são as decisões que mais importam.

O Gateway de Borda

A maioria das máquinas instaladas não fala MQTT. Um gateway de borda IIoT lê essas máquinas com o protocolo nativo delas e publica no broker. Ele deve fazer polling rápido localmente, mas publicar apenas quando houver mudança, adicionar timestamps e unidades e armazenar mensagens em buffer quando o uplink falhar. Essa última função se chama store and forward, e é ela que impede que uma queda de rede vire uma lacuna nos dados. Para protocolos específicos, veja Modbus TCP para MQTT, o guia de gateway OPC UA para MQTT e do CLP para a nuvem.

Posicionamento na Rede

As fábricas geralmente separam as redes de TO e de TI, com uma DMZ entre elas. Os padrões comuns são um broker na DMZ para o qual os gateways de TO publicam, um broker na nuvem alcançado por uma regra de firewall de saída, ou ambos conectados por bridge. Cada um tem trade-offs de latência, autonomia e segurança; MQTT na DMZ industrial analisa cada um deles.

Onde o Broker Roda

Brokers on-premises continuam funcionando quando a internet cai, o que importa para tudo o que está dentro de uma malha de controle. Brokers na nuvem simplificam muito a agregação de várias plantas, o acesso remoto e os dashboards. Muitas empresas fazem as duas coisas, como uma mineradora com várias unidades em Minas Gerais ou um grupo com plantas em Campinas e Joinville: a lógica local fica local, e um broker MQTT na nuvem agrega as plantas para analytics e sistemas corporativos. Seja qual for a escolha, os requisitos industriais de disponibilidade, isolamento e segurança são mais altos do que na IoT de consumo, tema que abordamos em como escolher um broker MQTT industrial.

Projeto de Topics: ISA-95 e o Unified Namespace

O MQTT puro não diz nada sobre a estrutura dos topics, e essa liberdade é perigosa na escala de uma fábrica. Sem uma convenção, você acaba com machine7/temp, Line-2/Temp_C e plant/oven/temperature no mesmo broker, e ninguém consegue assinar "tudo da linha 2".

A resposta industrial é alinhar os topics à hierarquia de equipamentos da ISA-95:

enterprise/site/area/line/cell/measurement
acme/izmir/machining/line1/cnc1/spindle_temp

Um broker organizado dessa forma se torna um Unified Namespace (UNS): um único lugar onde o estado atual de todo o negócio é publicado em uma estrutura que todos entendem. O MES assina acme/izmir/#, um dashboard de linha assina acme/izmir/machining/line1/# e um modelo de manutenção assina acme/+/+/+/+/vibration. Adicionar um consumidor nunca exige mexer em um produtor.

Regras que se sustentam em fábricas reais:

1. Combine os nomes dos níveis e os caracteres permitidos antes que o primeiro dispositivo se conecte.
2. Use letras minúsculas, sem espaços, e identificadores estáveis (IDs de ativos, não apelidos dados pelos operadores).
3. Separe telemetria, estado, eventos e comandos em topics-folha distintos.
4. Coloque unidades de engenharia e timestamps no payload, não no topic.
5. Publique o estado atual como retained messages para que novos consumidores o recebam instantaneamente.

As orientações detalhadas estão em topics MQTT ISA-95, estrutura de topics do UNS e no passo a passo como construir um Unified Namespace.

Sparkplug B: Adicionando Estado e Estrutura ao MQTT

O Sparkplug B é uma especificação da Eclipse Foundation que define como dispositivos industriais devem usar o MQTT. Ele resolve três pontos que o MQTT puro deixa em aberto:

• Um namespace de topics: spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}.
• Um formato de payload: métricas codificadas em Protobuf, com nomes, tipos de dados, timestamps e aliases.
• Gerenciamento de estado: certificados de nascimento (NBIRTH, DBIRTH) e de morte (NDEATH, DDEATH), para que cada consumidor saiba quais edge nodes e dispositivos estão online e quais métricas eles publicam.

Os benefícios são a interoperabilidade entre produtos compatíveis com Sparkplug e um estado confiável. O custo é que payloads Protobuf não são legíveis por humanos, e o layout fixo de topics não reflete a hierarquia da sua fábrica. Comece pelos artigos explicativos sobre payload Sparkplug B e certificados de nascimento e morte do Sparkplug, e use decodificando Sparkplug B em Python quando precisar inspecionar o tráfego bruto.

Sparkplug B e ISA-95 Juntos

Muitas fábricas usam os dois: Sparkplug B na borda, para uma comunicação eficiente e ciente de estado, e um namespace ISA-95 em JSON para todos os demais. A parte complicada é a camada de tradução entre eles. Nosso artigo sobre Sparkplug B e o Unified Namespace compara as duas abordagens em detalhes, e a próxima seção mostra como um broker pode fazer a tradução por você.

Mão na Massa: Seu Primeiro Fluxo de Dados de IoT Industrial com MQTT

Você pode testar padrões de topics industriais agora mesmo no servidor MQTT público (gratuito) em broker.connectmq.com. Use um prefixo único, mantenha os topics com no máximo 8 níveis e lembre-se de que a área pública pode ser lida por qualquer pessoa, então use apenas dados simulados.

Assine a fábrica simulada inteira:

mosquitto_sub -h broker.connectmq.com -p 1883 -i iiot-sub-m5q2 \
  -t "connectmq/demo/m5q2/#" -v

Publique uma leitura no estilo ISA-95 e um estado de máquina retido:

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/telemetry" \
  -m '{"spindle_temp":61.4,"spindle_rpm":8200,"unit_temp":"C","ts":1760600000}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 -r \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/state" -m "RUNNING"

Uma Ponte de Borda Mínima de Modbus TCP para MQTT

O script abaixo faz o papel de um gateway de borda. Ele lê dois holding registers de um dispositivo Modbus TCP a cada segundo, publica apenas quando um valor muda mais do que uma banda morta e registra um Last Will para que os consumidores saibam quando o gateway desaparece. Ele usa pymodbus 3.x e paho-mqtt 2.x:

pip install "pymodbus>=3.6" "paho-mqtt>=2.0"

import json
import time

import paho.mqtt.client as mqtt
from pymodbus.client import ModbusTcpClient

PLC_HOST = "192.168.1.50"      # seu dispositivo Modbus TCP ou simulador
BASE = "connectmq/demo/m5q2/machining/line1/press1"
DEADBAND = 0.5                 # publica só se um valor variar pelo menos isto

def on_connect(client, userdata, flags, reason_code, properties):
    print("Broker connection:", reason_code)
    client.publish(f"{BASE}/state", "ONLINE", qos=1, retain=True)

mqttc = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="edge-press1-m5q2",
    protocol=mqtt.MQTTv5,
)
mqttc.will_set(f"{BASE}/state", "OFFLINE", qos=1, retain=True)
mqttc.on_connect = on_connect
mqttc.reconnect_delay_set(min_delay=1, max_delay=30)
mqttc.connect("broker.connectmq.com", 1883, keepalive=30)
mqttc.loop_start()

plc = ModbusTcpClient(PLC_HOST, port=502)
last = {}

while True:
    if not plc.connected:
        plc.connect()
    rr = plc.read_holding_registers(address=0, count=2)
    if rr.isError():
        print("Modbus read failed:", rr)
        time.sleep(2)
        continue

    values = {
        "pressure_bar": rr.registers[0] / 10.0,  # escalado x10 no CLP
        "temperature_c": rr.registers[1] / 10.0,
    }
    changed = {k: v for k, v in values.items()
               if k not in last or abs(v - last[k]) >= DEADBAND}
    if changed:
        changed["ts"] = int(time.time() * 1000)
        mqttc.publish(f"{BASE}/telemetry", json.dumps(changed), qos=1)
        last.update({k: v for k, v in changed.items() if k != "ts"})
    time.sleep(1)

Observe o terminal do subscriber: os valores só aparecem quando mudam, e OFFLINE chega se você encerrar o script. Escalonamento de registradores, ordem das palavras e endereçamento variam entre fabricantes de CLP, então consulte o mapa de registradores do dispositivo; nosso guia de ponte Modbus para MQTT cobre esses detalhes. Um gateway de produção também gravaria um buffer em disco durante as quedas e usaria TLS com credenciais.

Como a ConnectMQ Apoia a IoT Industrial com MQTT

A ConnectMQ é um broker MQTT gerenciado com recursos voltados especificamente para tráfego industrial:

• Detecção de ISA-95 e UNS. O broker reconhece estruturas de topics ISA-95 e Unified Namespace no seu tráfego.
• Decodificação de Sparkplug B. Os payloads Sparkplug B são decodificados (Protobuf ou JSON) para que você possa lê-los no portal em vez de encarar bytes.
• Republicação de Sparkplug para ISA-95. Dados Sparkplug B podem ser republicados em topics ISA-95 com payloads legíveis; por exemplo, spBv1.0/factory1/DDATA/line1/cnc1 se torna connectmq/factory1/production/line1/cnc1/telemetry. Os edge nodes continuam falando Sparkplug enquanto o MES e os dashboards consomem um namespace limpo.
• Visão de dispositivos ISA-95 e alertas. O portal mostra os dispositivos organizados pelos níveis da ISA-95, e regras de alerta por limite com registro de alertas sinalizam valores como uma temperatura de spindle que ultrapassa um limite.
• Escolha de implantação. Comece no plano Serverless (Free) e depois migre para um cluster isolado Dedicated, para BYOC dentro da sua própria conta de nuvem ou para Self Managed Enterprise em plantas que precisam permanecer on-premises.

Para ver como isso fica de ponta a ponta, a demo web de gêmeo digital 3D da ConnectMQ mostra uma fábrica com CNC, braço robótico, forno, tanque, esteira e bomba atualizando em tempo real via WebSocket seguro. Armazenamento e analytics são tratados de forma aberta: historiadores, Telegraf, Node-RED ou os seus próprios serviços assinam o broker como clientes MQTT padrão. Veja como construir um historiador MQTT para esse padrão.

Checklist de Projeto de IoT Industrial com MQTT

Use esta lista ao definir o escopo de uma primeira implantação. A versão completa está no nosso checklist de conectividade IIoT.

1. Faça o inventário de máquinas, protocolos e dos pontos de dados que realmente respondem a uma pergunta de negócio.
2. Combine uma hierarquia de topics ISA-95 e regras de nomenclatura com as equipes de TO e de TI.
3. Decida o formato de payload: Sparkplug B na borda, JSON para os consumidores, ou ambos.
4. Escolha o hardware de gateway e confirme que ele suporta buffer e TLS.
5. Decida onde o broker roda e como o tráfego cruza a fronteira entre TO e TI.
6. Emita credenciais únicas por gateway e exija TLS na porta 8883.
7. Defina o tratamento de estado: Last Will, topics de estado retidos, mensagens de nascimento e morte.
8. Planeje armazenamento e visualização com ferramentas subscriber, não com mágica no lado do broker.
9. Faça um piloto em uma linha, meça e depois escale.

O alinhamento organizacional importa tanto quanto a tecnologia; convergência TI/TO explica como as equipes dividem as responsabilidades. Para ter a visão geral de onde essa camada de conectividade se encaixa em um programa de transformação digital, leia nosso guia da Indústria 4.0.

Monte Seu Piloto de IoT Industrial na ConnectMQ

Teste os exemplos acima no servidor MQTT público em broker.connectmq.com, apenas com dados simulados, e depois crie um broker MQTT gerenciado privado em app.connectmq.com. O plano Serverless (Free) não exige cartão de crédito e é suficiente para um piloto de uma linha com alguns gateways, dashboards e a decodificação de Sparkplug B e as visões ISA-95 descritas acima.

Perguntas frequentes

O MQTT é adequado para automação industrial?

Sim, para mover dados entre máquinas, gateways de borda e aplicações. Malhas de controle de tempo real rígido continuam pertencendo aos fieldbuses e CLPs; o MQTT transporta os dados ao redor delas até SCADA, MES, historiadores e analytics.

Preciso de Sparkplug B para IoT industrial com MQTT?

Não, mas ele ajuda quando produtos de muitos fornecedores precisam interoperar e você precisa de um estado online/offline confiável. Muitas fábricas usam Sparkplug B na borda e um namespace ISA-95 em JSON para os consumidores.

O broker MQTT industrial deve rodar on-premises ou na nuvem?

Nada que esteja dentro de uma malha de controle deve depender de um link de internet, por isso brokers locais são comuns nas fábricas. Um broker na nuvem é melhor para agregação de várias plantas, dashboards remotos e integração corporativa, e muitas arquiteturas usam os dois.

Como conecto um CLP que não suporta MQTT?

Use um gateway de borda que leia o CLP pelo protocolo nativo dele, como Modbus, OPC UA, S7 ou EtherNet/IP, e publique no broker. Muitos CLPs mais novos também têm clientes MQTT integrados.

A ConnectMQ consegue ler mensagens Sparkplug B?

Sim. A ConnectMQ decodifica payloads Sparkplug B e pode republicá-los em topics ISA-95 com payloads legíveis, para que consumidores que não usam Sparkplug possam usar os dados diretamente.