Entenda o que é MQTT, como funciona o modelo publish/subscribe, broker, tópicos, QoS, retain, sessões, segurança, alta disponibilidade e aplicações em IoT industrial.

Confira!

MQTT é um protocolo de mensageria leve baseado no modelo publish/subscribe. Ele foi projetado para permitir a troca eficiente de informações entre dispositivos, aplicações e plataformas, inclusive quando a largura de banda é limitada ou os equipamentos possuem poucos recursos computacionais.

Em vez de cada aplicação consultar diretamente todos os dispositivos, os clientes publicam mensagens em tópicos e outros clientes assinam os tópicos de interesse. Um broker MQTT recebe, filtra e distribui essas mensagens. Essa arquitetura desacopla produtores e consumidores, facilita a expansão e permite integrar sensores, gateways, sistemas supervisórios, aplicações de analytics, plataformas IoT e serviços de nuvem.

O protocolo é simples, mas um projeto confiável exige decisões sobre estrutura de tópicos, qualidade de serviço, retenção, sessões, disponibilidade do broker, autenticação, criptografia, autorização e monitoramento. Uma implantação sem governança pode gerar mensagens duplicadas, perda de eventos, tópicos inconsistentes e acesso excessivo.

Fundamentos do MQTT e do modelo publish/subscribe

MQTT significa Message Queuing Telemetry Transport, embora a especificação atual trate MQTT como nome próprio. É um protocolo cliente-servidor de transporte de mensagens no modelo publish/subscribe.

Seus principais elementos são:

  • publisher: cliente que publica mensagens;
  • subscriber: cliente que recebe mensagens de tópicos assinados;
  • broker: servidor responsável por receber e distribuir mensagens;
  • topic: caminho lógico usado para classificar as mensagens;
  • payload: conteúdo transportado;
  • QoS: nível de garantia de entrega;
  • sessão: estado mantido entre cliente e broker conforme configuração.

O broker não precisa conhecer a lógica completa da aplicação. Ele aplica regras de conexão, autenticação, autorização, retenção e encaminhamento.

Como funciona o modelo publish/subscribe. No modelo tradicional de requisição e resposta, um cliente precisa conhecer o endereço do servidor e solicitar a informação. No MQTT, o produtor publica em um tópico e não precisa saber quais consumidores receberão o conteúdo.

Exemplo:

subestacao/SE01/transformador/TR1/temperatura

Um sensor ou gateway pode publicar o valor nesse tópico. O SCADA, uma plataforma de manutenção e um sistema de analytics podem assiná-lo simultaneamente.

Esse desacoplamento ocorre em três dimensões:

  • espacial: publisher e subscriber não precisam conhecer o endereço um do outro;
  • temporal: dependendo da sessão e do QoS, os clientes não precisam estar conectados exatamente ao mesmo tempo;
  • funcional: o produtor não precisa implementar a lógica de cada consumidor.

Broker, hierarquia de tópicos e contratos de dados

O broker é o componente central da arquitetura. Ele aceita conexões, autentica clientes, recebe publicações, verifica permissões e entrega mensagens aos assinantes.

Também pode oferecer:

  • persistência de sessões;
  • mensagens retidas;
  • filas para clientes desconectados;
  • cluster e alta disponibilidade;
  • bridge entre brokers;
  • logs e métricas;
  • integração com bancos, filas e plataformas de eventos;
  • políticas de limite de conexão e tamanho de mensagem.

Por ser um ponto de concentração, o broker precisa ser dimensionado e protegido. Uma indisponibilidade pode interromper a distribuição de eventos de muitos dispositivos.

Tópicos e hierarquia. Tópicos MQTT são cadeias hierárquicas separadas por barras. A convenção deve ser planejada para permitir leitura, filtragem, autorização e expansão.

Uma estrutura possível:

empresa/site/sistema/ativo/grandeza

Exemplos:

  • empresa/planta01/utilidades/compressor03/pressao
  • empresa/se01/cftv/camera12/evento
  • empresa/se01/scada/chave52/posicao

Boas práticas:

  • usar nomes consistentes;
  • evitar incorporar dados sensíveis no nome do tópico;
  • definir maiúsculas, minúsculas e caracteres permitidos;
  • separar telemetria, estado, comando e evento;
  • reservar versões quando a estrutura puder evoluir;
  • documentar unidade, formato e origem do payload;
  • evitar tópicos genéricos como dados ou status sem contexto.

Wildcards de assinatura. Assinantes podem utilizar curingas para receber conjuntos de tópicos.

O curinga + representa um nível:

empresa/se01/+/alarme

O curinga # representa múltiplos níveis restantes:

empresa/se01/#

Curingas ampliam a flexibilidade, mas também podem aumentar carga e exposição. As regras de autorização devem limitar quais padrões cada cliente pode assinar.

QoS, mensagens retidas e persistência de sessão

Os níveis QoS devem ser interpretados por fluxo de entrega do protocolo, não como garantia de execução física de uma tarefa. Em QoS 0 não há reconhecimento da publicação; em QoS 1 o receptor pode receber duplicatas e deve tratá-las; em QoS 2 a troca de controle busca evitar entrega duplicada naquele fluxo MQTT, mas aplicações integradas continuam sujeitas a falhas de processamento, persistência e confirmação. Um comando para um atuador não pode depender apenas do QoS para comprovar que a ação foi executada com segurança.

Os curingas + e # são utilizados em filtros de assinatura, e não em nomes de tópico de mensagens publicadas. Esse detalhe é importante para projetar ACLs: uma permissão de assinatura com planta01/linha2/# não implica autorização para publicar nesse filtro. A regra de publicação deve corresponder aos tópicos concretos admitidos pela política do broker.

MQTT possui três níveis de QoS.

QoSGarantiaConsequência
0no máximo uma vezmenor overhead, mas a mensagem pode ser perdida
1pelo menos uma vezentrega confirmada, com possibilidade de duplicação
2exatamente uma vez no fluxo MQTTmaior troca de mensagens e maior custo de processamento

A escolha não deve ser automática. QoS 2 não significa que toda a aplicação executará uma ação exatamente uma vez. O consumidor ainda precisa tratar idempotência, persistência e falhas após o recebimento.

Para telemetria frequente, QoS 0 pode ser aceitável quando a próxima amostra substitui a anterior. Para alarmes e eventos importantes, QoS 1 costuma ser considerado, com tratamento de duplicações. QoS 2 deve ser reservado a situações em que o custo adicional seja justificável.

Mensagens retidas. Uma mensagem publicada com a flag retain pode ser armazenada pelo broker como último valor conhecido do tópico. Novos assinantes recebem essa mensagem imediatamente.

É útil para:

  • estado atual de um dispositivo;
  • versão de firmware;
  • modo de operação;
  • disponibilidade;
  • último valor válido.

Não deve ser confundida com histórico. O broker normalmente mantém apenas a última mensagem retida por tópico. Telemetria histórica precisa ser armazenada em banco, historiador ou plataforma apropriada.

Mensagens retidas inadequadas podem manter estados obsoletos. O projeto deve definir quais tópicos aceitam retain e como o valor é limpo ou atualizado.

Sessões persistentes. Sessões podem preservar assinaturas e mensagens pendentes para clientes que se desconectam. O comportamento depende da versão do MQTT e dos parâmetros de conexão.

A persistência é útil para conexões instáveis, mas aumenta o consumo de memória e armazenamento do broker. Clientes com identificadores duplicados também podem derrubar sessões existentes.

Cada cliente deve possuir identificador único e política clara de expiração da sessão.

Last Will and Testament. O Last Will and Testament permite registrar uma mensagem que o broker publicará caso o cliente se desconecte de forma inesperada.

Exemplo:

empresa/planta01/gateway07/disponibilidade = offline

Quando o cliente encerra normalmente, ele pode publicar online ou outra condição. O recurso ajuda a detectar perda de comunicação, mas o tempo de detecção depende do keepalive e das condições da rede.

Formato do payload. MQTT transporta bytes e não obriga um formato de dados. JSON é comum por ser legível e amplamente suportado, mas pode ter overhead maior que formatos binários.

O contrato de dados deve definir:

  • esquema e versão;
  • tipos de campo;
  • unidade de engenharia;
  • timestamp;
  • qualidade do dado;
  • identificador do ativo;
  • sequência ou ID da mensagem;
  • tratamento de valores nulos;
  • codificação;
  • limites de tamanho.

Sem contrato, cada integrador cria payloads incompatíveis.

Versões MQTT e interoperabilidade

O MQTT 5.0 separa o início limpo da sessão do seu intervalo de expiração e adiciona propriedades como expiração de mensagens, códigos de motivo, opções de assinatura e atrasos configuráveis de Will. Esses recursos ajudam a controlar retenção e reconexão, mas devem ser testados com as bibliotecas e os dispositivos efetivamente instalados. Um broker com suporte a MQTT 5 não garante que clientes antigos interpretem os mesmos parâmetros.

Uma mensagem retida (retain) é um último valor associado a um tópico no broker e não o histórico do processo. O Will informa uma condição quando o broker detecta encerramento anormal da conexão conforme suas regras; pode haver atraso ou efeitos de indisponibilidade do próprio servidor. O projeto deve especificar como consumidores diferenciam o último estado conhecido de um estado atual validado, evitando alarmes incorretos por dados antigos.

MQTT 3.1.1 é amplamente utilizado. MQTT 5.0 adiciona recursos de controle e diagnóstico, como propriedades de mensagens, códigos de motivo mais detalhados, expiração, aliases de tópicos e melhor negociação entre cliente e broker.

A seleção depende do suporte dos dispositivos, bibliotecas e plataforma. Não se deve ativar uma versão apenas por ser mais nova sem validar interoperabilidade.

Arquitetura MQTT para IoT industrial e integração SCADA

Uma arquitetura industrial pode incluir:

  1. sensores e dispositivos de campo
  2. gateways que coletam protocolos locais
  3. broker MQTT na planta, data center ou nuvem
  4. aplicações assinantes
  5. armazenamento e analytics
  6. sistemas de gestão e monitoramento

Gateways podem converter Modbus, OPC UA, entradas digitais ou APIs em tópicos MQTT. Essa conversão precisa preservar unidade, qualidade, timestamp e origem.

Em aplicações críticas, deve-se definir o que acontece quando o broker ou a WAN ficam indisponíveis. O gateway pode armazenar dados localmente e reenviar depois, mas isso precisa ser previsto no projeto.

MQTT em CFTV e analytics. Câmeras e plataformas de vídeo podem publicar eventos, contagens, alarmes e metadados por MQTT. O padrão ONVIF Profile M prevê o uso de MQTT para eventos e metadados em aplicações compatíveis.

Exemplos de uso:

  • contagem de pessoas;
  • cruzamento de linha;
  • perda de sinal;
  • mudança de cena;
  • entrada digital;
  • estado de relé;
  • reconhecimento de placa;
  • eventos de analytics.

A arquitetura permite que múltiplas aplicações recebam o mesmo evento sem consultar diretamente cada câmera. Isso reduz acoplamento, mas exige controle de tópicos, credenciais e exposição de metadados.

Desenho de integração: sensor, broker, SCADA e serviços em nuvem

O broker deve ser tratado como infraestrutura de integração, não como substituto dos controladores e sistemas supervisórios. Em uma planta industrial, o gateway pode ler medidores e equipamentos por Modbus, converter os valores para mensagens MQTT e publicá-los em um broker local; aplicações autorizadas recebem esses dados e os encaminham para historiador, análise de manutenção ou serviços corporativos. A fonte do dado, a unidade de medida, o horário, o estado de qualidade e a identidade do dispositivo precisam ser preservados, sobretudo se o payload vai alimentar decisões operacionais.

É recomendável distinguir tópicos de telemetria, alarmes, estado e comandos. O envio de comando por MQTT exige modelo de autorização e confirmação distinto da leitura de temperatura ou consumo de energia; QoS 2, isoladamente, não garante que uma atuação física ocorra uma única vez. A camada de aplicação precisa tratar identificadores de comando, validade, reconhecimento de recebimento, execução efetiva, idempotência e bloqueios de segurança.

FluxoExemploCritério de projeto
Telemetria de campoplanta/linha-01/motor-03/temperaturaUnidade, timestamp, qualidade, origem e frequência definidos
Alarme de processoplanta/linha-01/motor-03/alarmePrioridade, persistência, confirmação e política de retenção
Estado de conectividadeplanta/linha-01/gateway/statusLast Will e timeout compatíveis com o processo
Comando supervisionadoplanta/linha-01/motor-03/comandoACL distinta, autorização, idempotência e confirmação

Quando há separação TI/OT, a segmentação de redes e a intermediação de dados precisam ser definidas antes de permitir acesso externo ao broker. Uma réplica ou bridge MQTT em zona intermediária pode ser apropriada, desde que não crie rota de retorno não autorizada para os controladores. Se o negócio exige integração com SCADA e sistemas corporativos, a engenharia de automação industrial deve definir requisitos, proprietários do dado e critérios de testes entre disciplinas.

Segurança, autenticação e autorização no MQTT

MQTT não criptografa automaticamente seu transporte. É necessário configurar TLS ou outra proteção equivalente adequada ao caminho, validar certificados e proteger a identidade dos clientes e do broker. Em arquiteturas industriais, o plano de credenciais deve prever provisionamento, armazenamento seguro, rotação, revogação e recuperação. Uma credencial usada por vários gateways reduz rastreabilidade e aumenta o impacto de comprometimento.

O controle de acesso deve separar no mínimo três operações: conectar, publicar em determinados tópicos e assinar determinados filtros. Tópicos de telemetria e de comandos merecem permissões distintas. Deve-se testar também o comportamento de um cliente com identificação duplicada, excesso de conexões, assinaturas abrangentes, mensagens muito grandes e falha na renovação de certificados, de modo a reconhecer tanto o risco de segurança quanto o de indisponibilidade.

O protocolo precisa ser implementado com controles de segurança. Portas abertas e conexões anônimas transformam o broker em um ponto de exposição.

Os principais controles são:

  • autenticação de clientes;
  • TLS para proteger a comunicação;
  • certificados quando aplicável;
  • autorização por tópico;
  • segregação de tenants ou ambientes;
  • desativação de acesso anônimo;
  • limites de conexão e mensagens;
  • logs de autenticação e publicação;
  • atualização do broker e das bibliotecas;
  • proteção da interface administrativa;
  • segmentação de rede.

Autorização por tópico. Cada cliente deve publicar e assinar apenas o necessário.

Exemplo:

  • sensor publica em um tópico concreto, por exemplo planta01/linha2/sensor17/temperatura;
  • supervisório assina planta01/linha2/#;
  • aplicação de manutenção não publica comandos;
  • gateway de comando publica somente no conjunto autorizado.

Permissões amplas como # para todos os clientes facilitam integração inicial, mas aumentam o impacto de uma credencial comprometida.

TLS e certificados. TLS protege a comunicação contra interceptação e alteração. A arquitetura deve definir:

  • autoridade certificadora;
  • validação do certificado do broker;
  • autenticação mútua quando necessária;
  • armazenamento de chaves;
  • renovação e revogação;
  • comportamento durante expiração;
  • suporte dos dispositivos.

Dispositivos com recursos limitados podem exigir avaliação de desempenho. A segurança precisa ser testada no hardware real.

Comandos por MQTT. MQTT pode transportar comandos, mas isso aumenta o risco. Um comando não deve ser tratado como simples telemetria.

A aplicação deve considerar:

  • autenticação e autorização forte;
  • separação entre tópicos de estado e comando;
  • confirmação de execução;
  • validação de origem;
  • expiração de mensagens;
  • proteção contra repetição;
  • idempotência;
  • intertravamentos locais;
  • registro de operador e contexto;
  • operação segura quando a comunicação falha.

Em sistemas críticos, a lógica local deve preservar condições seguras mesmo se o broker estiver indisponível.

Disponibilidade, diagnóstico e recuperação

A disponibilidade pode ser aumentada por cluster, replicação, balanceamento ou múltiplos brokers. Entretanto, a solução depende do produto e do comportamento dos clientes.

O projeto deve verificar:

  • descoberta e failover;
  • persistência de sessão;
  • replicação de mensagens retidas;
  • consistência de autorização;
  • certificados;
  • tempo de reconexão;
  • perda e duplicação durante falhas;
  • dependência de DNS ou balanceador;
  • backup da configuração.

Alta disponibilidade precisa ser testada, não apenas declarada.

Monitoramento do broker. Indicadores relevantes:

  • clientes conectados;
  • tentativas de autenticação negadas;
  • taxa de publicação e entrega;
  • mensagens descartadas;
  • sessões persistentes;
  • tamanho de filas;
  • uso de CPU, memória e armazenamento;
  • latência;
  • conexões por cliente;
  • tópicos mais utilizados;
  • certificados próximos da expiração;
  • falhas de cluster.

A monitoração ajuda a detectar degradação e comportamento anormal.

MQTT versus protocolos de integração industrial

TecnologiaUso típico
MQTTmensageria leve publish/subscribe, IoT e telemetria
HTTP/RESTrequisição e resposta, APIs e integração web
AMQPmensageria empresarial com recursos avançados de filas e roteamento
OPC UAinteroperabilidade industrial, modelo de informação e serviços
Modbuscomunicação simples com dispositivos e registradores industriais

As tecnologias podem coexistir. Um gateway pode ler Modbus, modelar os dados e publicá-los por MQTT. O importante é definir a função de cada protocolo.

Dimensionamento do broker e critérios de continuidade

O dimensionamento deve considerar quantidade de clientes simultâneos, taxa média e pico de publicações, tamanho de payload, assinaturas por cliente, retenção de mensagens, sessões persistentes, taxa de reconexão, armazenamento e políticas de expiração. Para aplicações com links instáveis, a solução pode exigir buffer em gateways e encaminhamento posterior com controle de duplicatas, atraso e ordenação. Esses requisitos não são resolvidos apenas pela escolha de QoS mais alto: a indisponibilidade de uma WAN ou do serviço de autenticação pode comprometer comunicações antes mesmo da entrega da mensagem.

A disponibilidade do broker também deve ser especificada com seus domínios de falha. Cluster, replicação, failover e múltiplos endpoints possuem comportamentos diferentes entre produtos; a assinatura ou mensagem persistida em um nó pode não sobreviver à indisponibilidade de outro sem capacidade prevista pelo fabricante. O plano de teste deve demonstrar reinício, falha de rede, expiração de sessão, reconexão de clientes com o mesmo identificador e continuidade dos serviços consumidores.

ParâmetroPremissa necessáriaVerificação no FAT/SAT
Clientes e taxa de mensagensPicos, reconexões, payload e assinaturasCarga representativa e latência
QoS e persistênciaPolítica por tipo de dado e sessãoPerda, duplicidade, ordem e recuperação
SegurançaIdentidades únicas, TLS, ACL por tópico e rotaçãoTentativas permitidas e negadas, revogação de certificado
FalhasBroker, enlace, gateway e alimentaçãoFailover, buffer, restauração, recuperação operacional
OperaçãoLogs, métricas, backup e versionamentoMonitoramento, restauração e Data Book

O aceite deve distinguir conformidade do transporte de confiabilidade da aplicação. Um teste em que o assinante recebe uma única mensagem não comprova dimensionamento em pico, recuperação após queda ou segurança da infraestrutura. A equipe de engenharia precisa registrar baseline de tópicos e payloads, configurações de broker, versões, certificados e relatórios de ensaio. A alteração de fabricante de gateway, biblioteca ou versão MQTT deve ser tratada como mudança sujeita a regressão funcional e avaliação de interoperabilidade.

Para contratação, a especificação deve atribuir responsabilidades pela origem dos dados, publicação, administração do broker, consumidores, armazenamento e segurança de rede. O projeto de rede lógica deve ser compatibilizado com o projeto de automação, de modo que disponibilidade, segurança e diagnóstico não fiquem sem responsável.

Contrato de dados: tópicos, unidades e qualidade da informação

Uma estrutura coerente de tópicos é apenas o início de uma arquitetura MQTT. O projeto também precisa definir o conteúdo e o significado de cada mensagem. Equipamentos de diferentes fabricantes podem entregar a mesma grandeza com unidades, frequências ou interpretações distintas de validade. Sem um contrato de dados compartilhado, os consumidores podem produzir relatórios aparentemente consistentes, mas baseados em dados incompatíveis. Esse contrato deve identificar ativo, origem, grandeza, unidade, precisão necessária, formato, versão e responsável pela informação.

A convenção de tópicos deve distinguir local, sistema, ativo, tipo de dado e função da mensagem. Não basta utilizar nomes descritivos: a organização precisa resistir a alterações de equipamento, movimentações de ativos e substituições de gateways. Caso uma linha de produção seja renomeada, as aplicações consumidoras precisam saber se haverá redirecionamento, período de coexistência ou mudança coordenada. Isso exige política de versionamento e uma forma de informar consumidores sobre alterações do esquema.

Os timestamps merecem tratamento próprio. Um gateway pode coletar uma leitura, armazená-la temporariamente durante falha de WAN e publicá-la somente após a recuperação. O horário de recebimento pelo broker não é equivalente ao horário da medição. Para análise de séries temporais, alarmes e investigações, o contrato precisa identificar timestamp de origem, condição do relógio, qualidade e eventual atraso. Deve-se especificar como lidar com dados obsoletos, fora de sequência ou duplicados.

CampoO que documentarImpacto se estiver indefinido
Identificação do ativoNome estável e vínculo com cadastroMensagens atribuídas ao equipamento errado
Grandeza e unidadeTipo, unidade, faixa e escalaConversões e alarmes equivocados
Tempo de origemTimestamp e sincronismo do dispositivoEventos ordenados incorretamente
Qualidade do dadoVálido, suspeito, perdido ou substituídoDecisão com leitura não confiável
Versão do payloadEsquema e compatibilidade dos consumidoresFalha após atualização de gateway
ID do eventoIdentificador ou sequência para deduplicaçãoContagem dupla após reconexão

Um payload JSON costuma facilitar depuração, mas possui custo adicional de bytes e processamento em relação a formatos binários mais compactos. A escolha deve considerar capacidade dos gateways, largura de banda, armazenamento e interoperabilidade. Os campos importantes para a decisão de engenharia não podem ser deixados à interpretação posterior de cada integrador. O MQTT transporta mensagens: ele não garante automaticamente a qualidade dos dados que elas representam.

Uma mensagem retida (retain) também exige regras semânticas. O último valor conhecido pode ser entregue a um assinante que acaba de conectar, mesmo que tenha sido produzido muito antes. O consumidor deve conhecer a idade e o estado de qualidade do dado; não se deve confundir esse recurso com histórico de processo ou confirmação de condição atual. Para dados históricos, é necessário projetar historiador ou armazenamento com política própria de retenção.

Dimensionamento do broker: publicações, assinaturas e falhas

O dimensionamento deve começar pela taxa de publicação de cada classe de dispositivo e pelo número de assinantes que recebem cada tópico. A quantidade de sensores isoladamente é insuficiente para avaliar carga. Mil dispositivos publicando a cada minuto podem demandar menos throughput que centenas de dispositivos enviando eventos em intervalos muito menores. Quando o mesmo tópico é consumido por SCADA, manutenção, dashboards e analytics, o broker precisa processar múltiplas entregas a partir de uma publicação.

Em um exemplo didático, mil dispositivos publicam, cada um, uma mensagem de aproximadamente um quilobyte a cada dez segundos. Isso corresponde, em média, a cerca de cem publicações por segundo e cem quilobytes por segundo de payload recebido, sem contar cabeçalhos, TLS e confirmações. Se cada publicação tiver três assinantes, a distribuição pode representar aproximadamente trezentos quilobytes por segundo de payload entregue. Esses valores não são uma especificação de hardware: mostram por que recepção, distribuição e overhead precisam de contas distintas.

A média não revela, necessariamente, o cenário de maior solicitação. Após uma queda de energia ou de WAN, gateways podem reconectar em massa, autenticar-se, restabelecer assinaturas e reenviar dados que estavam em buffer. Sessões persistentes e mensagens pendentes podem aumentar consumo de memória e armazenamento; QoS 1 e QoS 2 podem introduzir mais estado e confirmações por mensagem. Por isso, uma solução dimensionada apenas para tráfego normal corre o risco de degradar justamente durante a recuperação.

VariávelHipótese de engenhariaVerificação recomendada
Taxa de entradaClientes, frequência e tamanho do payloadPublicações sustentadas e de pico
Taxa de saídaAssinantes e filtros aplicáveisEntrega, latência e filas
PersistênciaSessões, mensagens pendentes e expiraçãoUso de memória e recuperação
RetainQuantidade de tópicos e último valorArmazenamento e retomada
ReconexõesVolume de clientes afetados por falhaTempestade de conexão e autenticação
SegurançaTLS, certificados, ACL e gestão de chavesSobrecarga e rejeição de acessos indevidos

As métricas de aceite devem refletir os requisitos reais: publicações processadas, atraso de ponta a ponta, conexão simultânea, uso de recursos, perda, duplicações, recuperação e duração de filas. É necessário também ensaiar reinício do serviço e falha de um nó do cluster, quando houver. A documentação deve distinguir capacidade demonstrada em teste da taxa estimada em projeto e não atribuir aos fabricantes valores que não foram verificados.

O MQTT 5.0 oferece assinaturas compartilhadas para determinados cenários. Nesse modelo, uma mensagem elegível é entregue a um integrante do grupo compartilhado, em vez de ser distribuída indiscriminadamente a todos os integrantes. Isso pode apoiar o balanceamento dos consumidores, mas não fornece por si só ordenação global, recuperação automática ou replicação confiável entre brokers. A arquitetura precisa avaliar capacidades específicas da implementação escolhida.

Telemetria, alarmes e comandos: responsabilidades distintas

Publicações de telemetria, alertas e comandos exigem políticas diferentes. Uma temperatura utilizada para análise de tendência pode aceitar atraso controlado, ao passo que um alarme requer prioridade e histórico de recebimento. Já um comando de atuação precisa ter origem autorizada, prazo de validade, proteção contra repetição e evidência de execução. Usar uma credencial com acesso amplo aos três grupos aumenta o impacto de erros operacionais e de comprometimento de um gateway.

O MQTT deve ser tratado como infraestrutura de comunicação, não como substituto de intertravamentos ou lógica de segurança operacional. Um comando enviado ao broker não pode contornar permissivos da máquina, condições de proteção ou mecanismos de segurança funcional. O sistema local deve validar a solicitação segundo suas regras, de modo que a indisponibilidade da WAN ou do broker não deixe o processo dependente de uma comunicação externa para permanecer em condição segura.

Para comandos críticos, o protocolo de aplicação pode exigir identificador único, origem, destino, timestamp, expiração e uma resposta que diferencie pedido recebido, pedido aceito e ação executada. Um PUBACK ou a conclusão de um fluxo MQTT QoS 2 não demonstram que uma válvula se movimentou ou que uma máquina parou. A confirmação do processo precisa ser obtida por estado verificado e registrada conforme os requisitos funcionais da instalação.

Também é necessário lidar com mensagens duplicadas ou atrasadas após reconexões. A aplicação pode guardar identificadores já executados, recusar pedidos vencidos e exigir validação humana para ações excepcionais. Esse tratamento de idempotência deve ser definido por função, pois uma simples repetição de comando pode causar consequências diferentes de uma repetição de leitura. Os ensaios de FAT/SAT precisam exercitar explicitamente esses cenários.

Caso aplicado: integração de medidores, SCADA e manutenção preditiva

Considere uma indústria cujos medidores de energia se comunicam por Modbus com gateways de campo. Os gateways coletam grandezas, acrescentam identidade do ativo, unidade e timestamp e publicam a informação em um broker industrial. O SCADA e o historiador locais consomem os dados necessários à operação, enquanto aplicações de manutenção recebem informações aprovadas por uma interface intermediária. A arquitetura reduz o acoplamento entre sistemas, mas demanda definição de tópicos, confiança e propriedade dos dados.

Se a WAN for interrompida, o gateway pode continuar adquirindo as leituras e armazenar amostras por período delimitado, desde que a solução tenha capacidade e política previstas. Quando a comunicação retorna, as mensagens reenviadas precisam preservar o horário da medição e serem identificadas como históricas, sem disparar automaticamente alarmes como se fossem novas. O projeto deve estabelecer quais eventos são prioritários e o que fazer quando o buffer se esgota.

O sistema de manutenção preditiva pode produzir recomendações a partir da telemetria, mas não precisa possuir permissão de comando sobre os equipamentos. Se existir uma função de comando remoto, sua autorização deve ser prevista em arquitetura separada, com rastreabilidade e controles compatíveis com a criticidade do processo. A segmentação de redes TI/OT e os serviços intermediários devem impedir que a mera assinatura de um tópico conceda acesso irrestrito ao controle industrial.

Os testes de aceite devem simular perda do broker, falha do enlace, expiração de certificado, duplicação de mensagem, mudança de versão do payload e reconexão simultânea de clientes. Também precisam comprovar que um consumidor sem privilégio não consegue publicar comandos e que identidades de outro setor não acessam tópicos indevidos. O resultado deve ser documentado em uma matriz que relacione requisito, teste, valor observado, status e responsável pela correção.

Por fim, o Data Book deve reunir topologia, catálogo de tópicos, modelos de payload, parâmetros de QoS e sessões, certificados e política de revogação, registro de versões, regras de integração, limites do broker e testes realizados. Esses documentos permitem que o proprietário mantenha a solução após a implantação e avalie mudanças futuras sem depender exclusivamente do integrador original.

Projeto, testes, contratação e comissionamento

Um projeto MQTT pode produzir:

  • diagrama de arquitetura;
  • inventário de publishers, subscribers e brokers;
  • convenção de tópicos;
  • catálogo de mensagens;
  • esquema de payload;
  • matriz de QoS e retain;
  • matriz de permissões;
  • estratégia de certificados;
  • requisitos de disponibilidade;
  • plano de monitoramento;
  • plano de backup;
  • critérios de teste;
  • documentação as-built.

Testes e comissionamento. Os testes devem verificar:

  • conexão e autenticação;
  • publicação e assinatura;
  • autorização por tópico;
  • QoS 0, 1 e 2 quando utilizados;
  • duplicação e idempotência;
  • retain;
  • sessões persistentes;
  • Last Will;
  • perda de rede;
  • reinicialização do broker;
  • failover;
  • expiração de certificados;
  • limites de carga;
  • integração com consumidores;
  • logs e alarmes.

Erros comuns

Utilizar tópicos sem padrão

A ausência de convenção dificulta autorização, busca e evolução.

Usar QoS 2 em tudo

O maior nível aumenta overhead e não resolve sozinho a execução exatamente uma vez na aplicação.

Permitir acesso anônimo

Brokers sem autenticação podem expor telemetria e comandos.

Misturar estado e comando

Tópicos de comando precisam de controles e confirmação específicos.

Não testar reconexão

Clientes podem perder mensagens, duplicar eventos ou ficar presos após falha.

Usar retain como histórico

Retain mantém o último valor, não uma série temporal completa.

Considerações finais

O MQTT é um protocolo de mensageria baseado em publish/subscribe no qual clientes publicam mensagens em tópicos e um broker as encaminha aos assinantes autorizados. Essa separação facilita integrar sensores, gateways, SCADA, plataformas IoT e aplicações de análise, desde que a arquitetura defina hierarquia de tópicos, formato dos payloads, identidade dos dispositivos, qualidade e horário de origem dos dados. O transporte é leve, mas a informação só será confiável se seus contratos e sua governança forem consistentes.

Os níveis de QoS definem o tratamento da entrega no protocolo, não a execução física de uma operação. QoS 0 pode perder mensagens; QoS 1 requer tratamento de duplicatas; QoS 2 controla duplicação no fluxo MQTT, mas não garante, por si só, que uma aplicação execute um comando apenas uma vez. De modo semelhante, mensagens retidas oferecem o último valor conhecido de um tópico, e não um histórico completo nem a certeza de que o estado ainda esteja atual. Sessões persistentes, expiração e retransmissão devem ser especificadas de acordo com a finalidade dos dados.

Em redes industriais, o broker precisa ser dimensionado para carga normal, picos e reconexões, com proteção de transporte, identidade individual e autorização distinta para publicar e assinar. Telemetria, alarmes e comandos demandam políticas próprias. O MQTT não substitui intertravamentos, permissivos nem lógica local de segurança; o caminho de integração TI/OT deve respeitar segmentação e evitar que aplicações corporativas alcancem diretamente o controle do processo.

O aceite da solução deve reunir testes de publicação e consumo, perda de enlace, recuperação de sessões, duplicatas, credenciais, versões de payload e falha do broker, além de documentação de tópicos, integrações, configurações e responsabilidades. Assim, o valor do MQTT em uma instalação não está simplesmente em disponibilizar um broker, mas em estabelecer uma comunicação rastreável, segura e recuperável entre sistemas com requisitos distintos.

Por Eng. Altair Andrade Galvão — Diretor de Engenharia e Projetos, A3A Engenharia.

Referências técnicas

[1] OASIS. MQTT Version 5.0 — OASIS Standard. Disponível em: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html.

[2] OASIS. MQTT Version 3.1.1 — OASIS Standard. Disponível em: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html.

[3] ONVIF. Profile M — Metadata and Events for Analytics Applications, incluindo MQTT. Disponível em: https://www.onvif.org/profiles/profile-m/.

[4] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT IEC/TS 62443-1-1:2023 — Segurança para sistemas de automação e controle industriais. Disponível em: https://abntcatalogo.com.br/.

Perguntas frequentes
O que é MQTT?

MQTT é um protocolo leve de mensageria no modelo publish/subscribe. Clientes publicam mensagens em tópicos e um broker as distribui aos assinantes.

O que é um broker MQTT?

É o servidor que recebe mensagens, autentica clientes, aplica permissões e encaminha o conteúdo aos assinantes dos tópicos.

Qual a diferença entre QoS 0, 1 e 2?

QoS 0 entrega no máximo uma vez, QoS 1 entrega pelo menos uma vez e pode duplicar, e QoS 2 utiliza um fluxo adicional para garantir entrega exatamente uma vez no protocolo.

MQTT é seguro?

Pode ser seguro quando utiliza autenticação, TLS, autorização por tópico, segmentação, atualização e monitoramento. O protocolo não deve ser exposto com acesso anônimo.

O que é uma mensagem retida?

É o último valor armazenado pelo broker para um tópico. Novos assinantes o recebem imediatamente, mas isso não substitui um banco histórico.

Para que serve o Last Will?

Permite que o broker publique uma mensagem quando um cliente se desconecta inesperadamente, ajudando a indicar indisponibilidade.

MQTT pode transportar comandos?

Pode, mas comandos exigem autorização forte, confirmação, expiração, proteção contra repetição, registro e intertravamentos locais.

MQTT substitui Modbus ou OPC UA?

Não necessariamente. MQTT é adequado à distribuição de mensagens. Modbus e OPC UA podem ser usados no campo, com gateways publicando os dados em MQTT.

Como organizar tópicos MQTT?

A hierarquia deve representar empresa, site, sistema, ativo e grandeza, com convenção documentada e separação entre telemetria, estado, evento e comando.

Como testar uma arquitetura MQTT?

Devem ser testados autenticação, autorização, QoS, retain, sessões, reconexão, failover, carga, certificados, logs e integrações com publishers e subscribers.

Materiais técnicos complementares

Soluções

Serviços de engenharia

Materiais técnicos complementares