Desacoplamento via Broker na DMZ
Eliminar o polling ponto a ponto de múltiplos sistemas de TI sobre os CLPs: o gateway na borda lê o controlador uma única vez e publica no broker posicionado na DMZ industrial.
Guia de tecnologia · Mensageria industrial
Distribuir telemetria industrial para SCADA, historiadores, MES e nuvem sem abrir conexões de entrada no chão de fábrica nem sobrecarregar CLPs exige desacoplamento via broker. Este guia detalha a engenharia de redes MQTT em OT: níveis de entrega QoS 0/1/2, sessões persistentes, Last Will and Testament (LWT), especificação Eclipse Sparkplug B e segurança com TLS e listas de controle de acesso (ACLs).
Visão geral
MQTT é o protocolo de transporte de mensagens publicar/assinar (Publish/Subscribe) sobre TCP/IP padronizado pela OASIS e ISO/IEC 20922. Em arquiteturas industriais, nós de borda (gateways IIoT, CLPs ou servidores locais) iniciam conexões de saída para um broker centralizado (como HiveMQ, EMQX ou Eclipse Mosquitto) e publicam dados apenas por exceção (Report by Exception). Como o MQTT puro é agnóstico ao formato do payload, projetos industriais críticos adotam a especificação Eclipse Sparkplug B (ISO/IEC 20237) para padronizar hierarquia de tópicos (spBv1.0/...), serialização binária Protobuf, tipos de dados e gerenciamento determinístico de estado de conexão (NBIRTH, NDEATH, STATE).
Da tecnologia ao processo
Eliminar o polling ponto a ponto de múltiplos sistemas de TI sobre os CLPs: o gateway na borda lê o controlador uma única vez e publica no broker posicionado na DMZ industrial.
Garantir que supervisórios, historiadores e consumidores saibam instantaneamente se um gateway está online ou se os dados estão obsoletos (stale) via certificados de nascimento (NBIRTH) e morte (NDEATH).
Conectar subestações, elevatórias, silos e unidades remotas por enlaces celulares ou satelitais instáveis, combinando report por exceção, Keep-Alive ajustado e fila em disco na borda.
Antes de implementar
empresa/planta/area/linha/equipamento ou namespace spBv1.0/group_id/message_type/edge_node_id/[device_id]) e o contrato de payload (Sparkplug B Protobuf ou JSON tipado com timestamp UTC).KeepAlive, Session Expiry Interval (MQTT v5) e limites de filas persistentes no broker e no store-and-forward do gateway de borda.ClientID/identidade, impedindo que um nó publique em tópicos de outra área ou receba comandos indevidos (NCMD/DCMD).NDEATH), reconexão em massa (rebirth storm) e idempotência das aplicações consumidoras.Perguntas e respostas
MQTT é um protocolo de transporte de mensagens publicar/assinar orientado a eventos, projetado originalmente para telemetria de oleodutos e hoje padrão OASIS/ISO para integração IIoT e OT/IT. Na indústria, ele substitui o modelo em que vários sistemas externos interrogam diretamente os CLPs: um nó de borda coleta as variáveis de controle e as publica em um broker central sempre que o valor sofre variação relevante (Report by Exception), permitindo que historiadores, MES, dashboards e algoritmos de manutenção assinem esses tópicos sem impactar a rede de automação.
Referências: 1 · Voltar às perguntas
O broker é o servidor intermediário que autentica os clientes, mantém o estado das sessões, avalia permissões de acesso (ACLs) por tópico e roteia cada mensagem publicada apenas aos assinantes registrados. Enquanto implementações leves como o Eclipse Mosquitto atendem células locais ou laboratórios, arquiteturas críticas de planta costumam empregar brokers em cluster com alta disponibilidade, persistência em disco e observabilidade de conexões. Toda a comunicação passa pelo broker; publicadores e assinantes nunca se conectam diretamente entre si.
Referências: 2 · Voltar às perguntas
O Quality of Service (QoS) define a garantia de entrega do pacote em cada salto (do publicador ao broker e do broker ao assinante): QoS 0 (at most once) envia sem confirmação no nível MQTT, dependendo apenas do TCP; QoS 1 (at least once) armazena a mensagem até receber um PUBACK, garantindo a entrega mas podendo gerar duplicatas em caso de retransmissão; e QoS 2 (exactly once) executa um handshake de quatro etapas (PUBLISH, PUBREC, PUBREL, PUBCOMP) para evitar perda e duplicação, com maior custo de latência e banda. Note que o QoS efetivo entregue ao assinante é sempre o menor entre o QoS publicado e o QoS assinado.
Referências: 3 · Voltar às perguntas
Não. A conclusão do handshake de QoS 2 encerra-se na pilha de protocolo MQTT assim que o broker entrega o pacote ao cliente assinante (ou vice-versa). Se a aplicação consumidora receber a mensagem MQTT e falhar ao gravar no banco de dados SQL ou ERP, o protocolo MQTT já terá considerado a mensagem entregue. Para transações críticas de produção (como apontamento de ordem ou consumo de lote em MES), implemente chaves de idempotência no payload (timestamp + ID único de transação) e um tópico explícito de confirmação de negócio quando exigido pelo processo.
Referências: 4 · Voltar às perguntas
Quando uma mensagem é publicada com a flag RETAIN = true, o broker armazena a última mensagem válida daquele tópico e a entrega imediatamente a qualquer novo cliente que assine o tópico no futuro, evitando que o consumidor fique sem valor até a próxima variação de processo. Contudo, uma mensagem retida em JSON comum não informa se o publicador continua vivo: se o gateway travar ou perder energia sem publicar atualização, o novo assinante pode ler um valor retido horas atrás como se fosse atual — problema resolvido pelo gerenciamento de estado do Sparkplug B ou pelo Message Expiry Interval do MQTT v5.
Referências: 4 · Voltar às perguntas
Se a queda ocorrer entre o broker e um assinante que utiliza sessão persistente (Clean Session = false no MQTT v3.1.1 ou Clean Start = false com Session Expiry Interval > 0 no MQTT v5) e assinatura QoS 1 ou 2, o broker enfileira as mensagens até o limite configurado de memória/disco. Porém, se a queda ocorrer entre o gateway de borda e o broker, a pilha MQTT sozinha não retém histórico de horas: é obrigatório que o software ou gateway de borda possua um buffer local Store-and-Forward em disco não volátil, capaz de estampar o timestamp original da coleta e descarregar a fila em ordem cronológica após a reconexão.
Referências: 4 · 5 · Voltar às perguntas
A especificação Eclipse Sparkplug B transforma o MQTT em um barramento industrial determinístico de estado. Ela define: (1) um formato de tópico rigoroso (spBv1.0/group_id/message_type/edge_node_id/[device_id]); (2) codificação binária compacta em Google Protocol Buffers com tipos de dados, propriedades de qualidade e histórico; e (3) gestão contínua de estado de sessão via mensagens de nascimento (NBIRTH/DBIRTH), dados por exceção (NDATA/DDATA) e certificado de óbito (NDEATH/DDEATH, registrado no Last Will do broker). Quando um gateway cai, o broker dispara o NDEATH imediatamente e o SCADA/historiador marca todas as tags daquele nó como Stale/inválidas.
Referências: 6 · Voltar às perguntas
Nunca opere MQTT industrial em texto claro na porta 1883 através da rede da fábrica ou DMZ. Configure obrigatoriamente TLS 1.2 ou 1.3 (porta 8883) com validação de certificado do servidor e, preferencialmente, autenticação mútua por certificados de cliente X.509 (mTLS). No broker, aplique listas de controle de acesso (ACLs) estritas baseadas na identidade autenticada: cada gateway de borda só pode publicar em seu próprio edge_node_id, clientes analíticos só possuem permissão de leitura (subscribe) e tópicos de comando (NCMD/DCMD) permanecem bloqueados por padrão, a menos que exigidos e auditados pela engenharia de controle.
Referências: 5 · Voltar às perguntas
Para aprofundar
Na especificação do projeto, valide a revisão normativa e a matriz de compatibilidade de firmware aplicáveis à sua instalação.
Próximo passo
Compartilhe o processo, a plataforma atual, as janelas de parada e o objetivo operacional. Estruturamos o escopo técnico com entregáveis claros, do diagnóstico ao startup e operação assistida.
Converse diretamente com Rafhael Feitosa