MQTT (Message Queuing Telemetry Transport)

Definição: MQTT (Message Queuing Telemetry Transport) é um protocolo de rede leve no modelo publish-subscribe, projetado para transmitir pequenos pacotes de dados entre dispositivos em redes de baixa largura de banda ou instáveis. É o padrão de comunicação dominante para redes de sensores IoT e amplamente utilizado em sistemas industriais de monitoramento de condição, monitoramento remoto de equipamentos e manutenção preditiva.

O que é MQTT?

O MQTT foi originalmente desenvolvido pela IBM no final dos anos 1990 para monitorar oleodutos via satélite, onde a largura de banda era escassa e as conexões eram instáveis. O protocolo foi posteriormente padronizado pela OASIS e tornou-se a espinha dorsal das implantações modernas de Internet Industrial das Coisas (IIoT). Ao contrário dos protocolos web tradicionais, que exigem que um dispositivo consulte repetidamente um servidor por atualizações, o MQTT permite que os dispositivos enviem dados no momento em que são gerados, distribuindo-os instantaneamente para todos os sistemas que precisam deles.

Para equipes de manutenção e operações, o MQTT é mais relevante como a camada de comunicação que conecta sensores físicos nos equipamentos a dashboards de monitoramento, plataformas CMMS e sistemas de análise. Entender como o MQTT funciona ajuda gestores de manutenção a avaliar arquiteturas de redes de sensores, diagnosticar lacunas de dados e tomar decisões informadas sobre infraestrutura de monitoramento remoto de equipamentos.

Como o MQTT funciona: o modelo publish-subscribe

O MQTT é estruturado em torno de três papéis: publicadores, assinantes e um broker.

Um publicador é qualquer dispositivo que gera dados, como um sensor de vibração em um motor ou um sensor de temperatura em um compressor. O publicador envia seus dados ao broker junto com um rótulo de tópico, por exemplo planta/linha-3/motor-7/temperatura.

O broker é um servidor que recebe todas as mensagens recebidas e as encaminha com base nas assinaturas de tópico. Ele desacopla completamente publicadores de assinantes: um sensor não precisa saber quais sistemas estão consumindo seus dados.

Um assinante é qualquer aplicação que registrou interesse em um tópico. Quando uma nova mensagem chega nesse tópico, o broker a envia imediatamente para cada assinante ativo. Uma plataforma de monitoramento de condição, um dashboard de manutenção e um historiador podem receber a mesma leitura de sensor simultaneamente, sem que o sensor precise saber que nenhum deles existe.

Essa arquitetura torna o MQTT extremamente escalável. Adicionar um novo sistema consumidor não requer alterações nos sensores nem no broker, apenas uma nova assinatura. Remover um sistema também não exige alterações nos dispositivos em campo.

Tópicos MQTT e hierarquias de tópicos

Os tópicos no MQTT são strings que usam uma barra separadora para criar uma hierarquia, similar a um caminho de arquivo. Uma hierarquia de tópicos bem estruturada reflete o layout físico de uma instalação.

Padrão de tópico Exemplo O que representa
Leitura específica de sensor planta/linha-3/bomba-2/vibracao Dados de vibração de uma bomba em uma linha
Todos os sensores de uma máquina planta/linha-3/bomba-2/# Todos os dados da bomba-2 (usando curinga)
Todos os sensores de temperatura da planta planta/+/+/temperatura Temperatura de cada ativo em cada linha
Todos os dados de todos os ativos planta/# Cada mensagem publicada no namespace da planta

Uma convenção consistente de nomenclatura de tópicos é uma das decisões mais importantes em qualquer implantação MQTT. Ela determina com que facilidade novos sistemas podem assinar subconjuntos relevantes de dados e quão manutenível a rede é ao longo do tempo. Muitas equipes industriais alinham sua hierarquia de tópicos MQTT com sua hierarquia de ativos para que os dados sejam rastreáveis até registros específicos de equipamentos.

Níveis de qualidade de serviço (QoS) do MQTT explicados

Nem todos os dados de sensores têm a mesma consequência se uma mensagem for perdida. O MQTT resolve isso com três níveis de Qualidade de Serviço.

Nível de QoS Nome Garantia de entrega Melhor uso
QoS 0 No máximo uma vez Sem confirmação. Mensagem pode ser perdida. Leituras ambientais de alta frequência onde perda ocasional é aceitável
QoS 1 Ao menos uma vez Confirmação obrigatória. Duplicatas são possíveis. A maioria dos cenários de monitoramento de condição; alertas de falha e violações de limite
QoS 2 Exatamente uma vez Handshake de quatro etapas. Sem duplicatas, sem perda. Eventos críticos de segurança, registro regulatório de dados, acionamento de ordens de serviço

Para aplicações de manutenção preditiva, o QoS 1 é a escolha mais comum. Ele garante que alertas de violação de limite e eventos de detecção de anomalias cheguem à plataforma de monitoramento mesmo que a rede caia brevemente, sem a penalidade de latência do QoS 2.

Mensagens retidas e Last Will do MQTT

Dois recursos do MQTT são especialmente úteis para monitoramento industrial: mensagens retidas e Last Will and Testament (LWT).

Uma mensagem retida é uma mensagem sinalizada para ser armazenada pelo broker. Quando um novo assinante se conecta e solicita um tópico, o broker entrega imediatamente a mensagem retida mais recente, de modo que o assinante sempre tem um valor inicial conhecido em vez de esperar pelo próximo ciclo de publicação. Isso é útil para tópicos de status que se atualizam com pouca frequência, como o estado operacional de uma máquina.

O recurso Last Will and Testament permite que um dispositivo pré-registre uma mensagem no broker no momento da conexão. Se o dispositivo se desconectar inesperadamente sem enviar uma notificação de desconexão adequada, o broker publica automaticamente a mensagem LWT em nome do dispositivo. Para equipes de manutenção, isso viabiliza alertas imediatos quando um sensor ou gateway perde energia ou conectividade de rede, em vez de depender de detecção baseada em timeout.

MQTT vs HTTP vs OPC-UA: comparação para equipes industriais

Atributo MQTT HTTP/REST OPC-UA
Modelo de comunicação Publish-subscribe Requisição-resposta Cliente-servidor e pub-sub
Overhead por mensagem Muito baixo (cabeçalho mínimo de 2 bytes) Alto (cabeçalhos HTTP completos por requisição) Médio a alto
Projetado para Dispositivos com recursos limitados, redes de sensores APIs web, requisições iniciadas por humanos Integração PLC/SCADA, modelos de dados ricos
Modelagem de dados Nenhuma (payload são bytes arbitrários) Nenhuma nativa Modelo de dados e sistema de tipos nativos ricos
Segurança TLS opcional; usuário/senha; certificados de cliente TLS padrão; OAuth comum Modos de segurança nativos; baseado em certificados
Melhor uso Telemetria de sensores de borda para nuvem em escala Integrações empresariais, dashboards Integração de PLC/controlador no chão de fábrica

Muitas arquiteturas industriais modernas usam tanto MQTT quanto OPC-UA. Um PLC ou sistema SCADA pode se comunicar internamente via OPC-UA, enquanto um gateway de borda converte e encaminha esses dados upstream via MQTT para transmissão para análises na nuvem ou um Namespace Unificado.

MQTT em monitoramento de condição e redes de sensores

O monitoramento baseado em condição requer um fluxo constante de dados de ativos distribuídos por uma instalação. Sensores que medem vibração, temperatura, corrente e pressão geram leituras continuamente, às vezes a centenas de amostras por segundo por sensor. O polling HTTP sobrecarregaria a rede e introduziria latência; o MQTT lida com essas cargas de trabalho de forma nativa.

Uma implantação típica funciona assim: sensores ou gateways de borda conectados aos equipamentos publicam leituras em um broker MQTT on-premises ou na nuvem. Uma plataforma de monitoramento de condição assina os tópicos relevantes e processa o fluxo de dados recebidos em tempo real, acionando alertas quando as leituras ultrapassam limites ou quando modelos de machine learning detectam padrões associados a falhas de equipamentos.

O MQTT também é central para arquiteturas de comunicação machine-to-machine (M2M) em que os ativos precisam compartilhar informações de status entre si ou com sistemas de controle sem intervenção humana. Por exemplo, um sensor que detecta vibração anormal pode publicar um alerta que aciona automaticamente uma ordem de serviço em um CMMS conectado.

MQTT e o Namespace Unificado

O Namespace Unificado (UNS) é um padrão de arquitetura industrial cada vez mais popular em que todos os dados de uma instalação, de sensores e PLCs a sistemas ERP e MES, são publicados em um único broker MQTT compartilhado. Cada sistema na empresa assina os tópicos de que precisa e publica os dados que gera, sem integrações ponto a ponto entre sistemas.

O modelo publish-subscribe do MQTT é a camada de transporte natural para um UNS, pois permite que qualquer número de produtores e consumidores troquem dados sem acoplamento. Uma equipe de manutenção que adota uma abordagem UNS pode esperar que os brokers MQTT sejam uma peça central de sua infraestrutura de Indústria 4.0, ao lado de sistemas SDC e MES.

Considerações de segurança do MQTT para implantações industriais

O MQTT foi projetado para ambientes com recursos limitados onde a segurança nem sempre era viável, portanto o protocolo não impõe autenticação ou criptografia por padrão. Em implantações industriais, isso cria riscos se os brokers forem deixados com as configurações padrão.

As práticas essenciais de segurança para implantações industriais de MQTT são:

  • Criptografia de transporte: sempre use TLS na porta 8883 em vez de TCP não criptografado na porta 1883. Isso previne escuta e ataques man-in-the-middle nos dados dos sensores.
  • Autenticação: exija credenciais de usuário e senha no mínimo. Para sistemas críticos, use TLS mútuo com certificados de cliente para verificar a identidade do dispositivo.
  • Autorização: configure o broker com listas de controle de acesso (ACLs) por tópico para que cada dispositivo ou aplicação só possa publicar ou assinar nos tópicos autorizados.
  • Segmentação de rede: coloque o broker MQTT em uma zona de rede dedicada e restrinja o acesso com regras de firewall. Os sensores não devem ter acesso direto à internet.
  • Hardening do broker: desative conexões anônimas, limite o tamanho das mensagens e defina limites de taxa adequados para prevenir condições de negação de serviço causadas por dispositivos mal configurados.

Ambientes de tecnologia operacional exigem atenção extra porque redes de sensores frequentemente combinam dispositivos mais antigos que não suportam TLS com gateways modernos que suportam. Nesses casos, proteger o gateway e isolar os dispositivos legados em uma VLAN separada é uma abordagem pragmática.

Brokers MQTT mais usados na indústria

A escolha do broker afeta escalabilidade, overhead de gerenciamento e opções de integração. Os brokers mais utilizados em contextos industriais são:

  • Eclipse Mosquitto: open-source, leve e amplamente implantado em gateways de borda e pequenos servidores on-premises. Adequado para instalações com algumas centenas de dispositivos.
  • HiveMQ: broker enterprise com forte clustering, console de gerenciamento e ecossistema de extensões. Comum em grandes implantações de IoT industrial.
  • EMQX: broker open-source e enterprise de alto throughput, capaz de lidar com milhões de conexões simultâneas. Popular em plataformas IoT em escala de nuvem.
  • AWS IoT Core / Azure IoT Hub: endpoints MQTT gerenciados na nuvem com autenticação nativa, gerenciamento de dispositivos e integração com serviços de análise em nuvem.

Para a maioria das instalações de manufatura, um broker on-premises combinado com encaminhamento seletivo para a nuvem oferece o melhor equilíbrio entre latência, soberania de dados e capacidade de monitoramento em tempo real.

Versões do MQTT: MQTT 3.1.1 vs MQTT 5

O MQTT 3.1.1 é a versão mais amplamente implantada em sistemas industriais existentes. O MQTT 5, lançado em 2019, introduziu vários recursos relevantes para operações de manutenção:

  • Códigos de motivo: cada confirmação agora inclui um código de motivo, tornando muito mais fácil diagnosticar falhas de conexão e erros de entrega.
  • Expiração de mensagem: os publicadores podem definir um tempo de vida nas mensagens para que leituras desatualizadas sejam descartadas se não tiverem sido consumidas dentro de uma janela definida.
  • Propriedades de usuário: metadados de chave-valor podem ser anexados a qualquer mensagem sem alterar o formato do payload, viabilizando marcação de dados mais rica sem mudanças de esquema.
  • Assinaturas compartilhadas: múltiplos assinantes podem compartilhar uma assinatura no mesmo tópico, distribuindo o processamento de mensagens por múltiplos consumidores sem entrega duplicada.

Equipes que constroem nova infraestrutura de monitoramento de condição de ativos devem considerar o MQTT 5 por seus diagnósticos aprimorados e flexibilidade operacional, especialmente a expiração de mensagens e os códigos de motivo.

O mais importante

O MQTT é a espinha dorsal de comunicação das redes modernas de sensores industriais. Seu modelo publish-subscribe, overhead mínimo e garantias de entrega flexíveis fazem dele o protocolo certo para transmitir dados de máquinas de alta frequência do chão de fábrica para plataformas de monitoramento, sistemas de manutenção e motores de análise.

Para equipes de manutenção e operações, o MQTT não é apenas uma questão de desenvolvimento de software. Entender como o broker, os tópicos e os níveis de QoS funcionam ajuda as equipes a projetar pipelines de dados confiáveis, solucionar lacunas na cobertura de sensores e avaliar se a infraestrutura de monitoramento de condição suporta análise preditiva em tempo real. À medida que as instalações avançam em direção a arquiteturas de Indústria 4.0, a fluência em MQTT está se tornando uma competência prática para engenheiros de confiabilidade e gestores de manutenção.

Veja dados de sensores em tempo real na prática

A plataforma de monitoramento de condição da Tractian usa sensores conectados via MQTT para transmitir dados de vibração, temperatura e corrente diretamente para sua equipe de manutenção, sem necessidade de programação.

Agendar uma demo

Perguntas frequentes

Para que o MQTT é usado em ambientes industriais?

O MQTT é usado para transmitir dados de sensores de máquinas e equipamentos para plataformas centralizadas de monitoramento. Em ambientes industriais, ele viabiliza o monitoramento de condição em tempo real, a manutenção preditiva e o monitoramento remoto de equipamentos, entregando dados de sensores instalados em motores, bombas, compressores e outros ativos de forma confiável, mesmo em conexões de baixa largura de banda ou instáveis.

Qual a diferença entre MQTT e HTTP?

O HTTP usa um modelo de requisição-resposta em que o cliente precisa solicitar dados a cada vez. O MQTT usa um modelo publish-subscribe em que os dados são enviados automaticamente a todos os assinantes quando disponíveis. O MQTT é muito mais eficiente para redes de sensores porque tem um overhead de pacotes muito menor e mantém uma conexão persistente, enquanto o HTTP abre e fecha uma conexão a cada requisição.

O que é um broker MQTT?

Um broker MQTT é um servidor que recebe todas as mensagens dos dispositivos publicadores e as encaminha para os clientes assinantes corretos com base nos filtros de tópico. O broker desacopla publicadores de assinantes, de modo que cada sensor precisa apenas se conectar ao broker em vez de conhecer os endereços de todos os sistemas receptores. Brokers comuns incluem Eclipse Mosquitto, HiveMQ e EMQX.

O que são os níveis de QoS do MQTT?

O MQTT oferece três níveis de Qualidade de Serviço. O QoS 0 entrega uma mensagem no máximo uma vez, sem confirmação (disparar e esquecer). O QoS 1 entrega uma mensagem ao menos uma vez e exige confirmação, o que significa que duplicatas são possíveis. O QoS 2 entrega uma mensagem exatamente uma vez usando um handshake de quatro etapas, sendo o mais confiável, mas também o mais lento. Equipes de manutenção normalmente usam QoS 1 ou 2 para dados de alertas críticos.

O MQTT é seguro o suficiente para uso industrial?

O MQTT em si é um protocolo de transporte leve e não exige segurança por padrão. No entanto, ele suporta criptografia TLS/SSL, autenticação por usuário e senha, e autenticação por certificado de cliente. Em implantações industriais, a prática padrão é executar o MQTT sobre TLS na porta 8883, impor autenticação de cliente e colocar o broker dentro de um segmento de rede protegido ou atrás de uma VPN.

Qual a diferença entre MQTT e OPC-UA?

O MQTT é um protocolo de transporte de mensagens leve, otimizado para ambientes de baixa largura de banda e alta latência com grande número de dispositivos simples. O OPC-UA é um padrão completo de comunicação industrial que inclui modelagem de dados, segurança e definições de serviço próprios. O OPC-UA é mais adequado para comunicação machine-to-machine dentro do chão de fábrica onde o contexto de dados é rico, enquanto o MQTT é preferido para transmitir dados de dispositivos de borda para sistemas de nuvem ou empresariais em escala.

O MQTT funciona sem conexão com a internet?

Sim. O MQTT exige apenas uma rede TCP/IP, que pode ser uma rede local sem acesso à internet. Muitas implantações industriais executam um broker MQTT on-premises na LAN da planta para que os dados dos sensores nunca saiam da instalação. A conectividade com a internet só é necessária se os dados precisarem ser enviados para uma plataforma na nuvem.

Termos relacionados