OPC UA vs MQTT é um dos debates mais comuns na IoT Industrial, e normalmente ele é colocado da forma errada. Este comparativo explica para que cada protocolo foi projetado, como eles diferem em modelagem de informação, padrão de comunicação, segurança e conectividade com a nuvem, e por que a resposta mais comum no mundo real é "OPC UA na borda, MQTT até a nuvem". Ao final, você saberá qual usar em cada camada da sua arquitetura.
Dois protocolos, duas funções diferentes
O OPC UA (Open Platform Communications Unified Architecture) é um framework de interoperabilidade industrial. Ele define não apenas como os bytes trafegam, mas como uma máquina descreve a si mesma: objetos, variáveis, métodos, tipos, unidades de engenharia, alarmes e histórico. Um client se conecta a um servidor, navega pelo seu address space e lê, escreve, assina ou chama métodos. Ele é padronizado como IEC 62541 e vem embutido em muitos CLPs, CNCs e sistemas SCADA modernos.
O MQTT é um protocolo de mensageria publish/subscribe leve. Os clients se conectam a um broker central, publicam mensagens em topics e assinam os topics que lhes interessam. O MQTT propositalmente não diz nada sobre o significado do payload; ele transporta bytes de forma eficiente e confiável sobre redes não confiáveis. É um padrão OASIS, e as versões 3.1.1 e 5.0 são amplamente usadas. Se o conceito de broker é novidade para você, comece por o que um broker MQTT faz.
Por isso, a comparação lembra um pouco comparar o schema de um banco de dados com um barramento de mensagens. Os dois movimentam dados, mas o valor que cada um traz é diferente.
OPC UA vs MQTT em resumo
| Dimensão | OPC UA (client/servidor) | MQTT |
|---|---|---|
| Padrão principal | Sessões client/servidor; subscriptions por sessão | Publish/subscribe por meio de um broker |
| Modelo de informação | Address space rico, tipado e navegável, com metadados | Nenhum embutido; topics e payloads são definidos por você ou por uma especificação como o Sparkplug B |
| Descoberta | Navegar pelo servidor para encontrar nós e tipos | Assinar com wildcards; sem descoberta de schema embutida |
| Acoplamento | Cada consumidor se conecta a cada servidor | Produtores e consumidores só conhecem o broker |
| Direção da rede | O client precisa alcançar o servidor, normalmente entrando na rede de TO | Todos os clients se conectam para fora, até o broker |
| Footprint | Stack mais pesada, mensagens maiores, estado de sessão | Bibliotecas client muito pequenas, cabeçalho mínimo de 2 bytes |
| Segurança | Certificados de aplicação, assinatura e criptografia, tokens de usuário | TLS no transporte, usuário/senha ou certificados de client, autorização no broker |
| Escrita e chamadas de métodos | Nativas: escrever variáveis, chamar métodos | Possíveis via topics de comando, mas por convenção |
| Alcance na nuvem e na TI | Suporte nativo limitado nas plataformas de nuvem | Suportado por praticamente toda plataforma de IoT e linguagem |
| Lugar típico | CLPs, CNCs, SCADA, MES na rede da planta | Gateways de borda, apps na nuvem, dashboards, mobile, dispositivos restritos |
O OPC UA também tem uma extensão PubSub (Parte 14) que pode usar o MQTT como transporte. Isso torna a fronteira bem menos nítida e é tema do nosso artigo sobre OPC UA PubSub sobre MQTT. Este comparativo foca no OPC UA client/servidor clássico, porque é o que a maioria dos equipamentos instalados expõe hoje.
Modelagem de informação: a grande vantagem do OPC UA
O ponto mais forte do OPC UA é a semântica. Um servidor pode dizer "isto é uma variável chamada SpindleTemperature, é um Double, sua unidade é graus Celsius, sua faixa é de 0 a 120 e ela pertence a um objeto do tipo MachineToolType". As companion specifications vão além e definem modelos padrão para classes inteiras de máquinas, de modo que as injetoras de dois fabricantes diferentes possam parecer iguais para um client.
O MQTT não tem nada disso de fábrica. Um payload 47.3 em um topic é só um conjunto de bytes. As equipes compensam isso de três formas:
- Convenções de topics, como uma hierarquia ISA-95, para que o próprio caminho carregue contexto. Nosso guia sobre topics MQTT ISA-95 mostra um layout prático.
- JSON autodescritivo, com valor, unidade, qualidade e timestamp em cada mensagem.
- Sparkplug B, que acrescenta um payload definido, certificados de nascimento e morte e metadados de métricas sobre o MQTT.
Se uma modelagem rica é inegociável em um caso de uso, por exemplo um MES que lê receitas e chama métodos em uma máquina, o OPC UA é a escolha natural.
Padrão de comunicação: sessões vs desacoplamento
Com o OPC UA clássico, cada consumidor abre uma sessão com cada servidor de que precisa. Em uma planta de manufatura em Joinville, dez aplicações lendo de cinquenta máquinas podem significar centenas de sessões, cada uma consumindo memória em CLPs que nunca foram dimensionados para isso. Adicionar um novo consumidor significa mexer em regras de firewall e na configuração dos servidores.
Com o MQTT, cada máquina ou gateway publica uma única vez no broker, e qualquer número de consumidores assina. Adicionar um novo dashboard, um job de analytics ou um gêmeo digital da linha não mexe em nada no chão de fábrica. Esse desacoplamento é o principal motivo pelo qual o MQTT se tornou a espinha dorsal do padrão Unified Namespace.
O outro lado da moeda: o MQTT coloca o broker no caminho crítico. Se ele cair, nada flui, então disponibilidade, monitoramento e capacidade do broker se tornam preocupações operacionais. É um dos motivos pelos quais muitas equipes escolhem um broker MQTT gerenciado em vez de operar brokers por conta própria.
Modelos de segurança
Os dois protocolos podem ser bem protegidos, e os dois podem ser implantados de forma insegura.
A segurança do OPC UA é no nível da aplicação: cada client e servidor tem um certificado X.509 de instância de aplicação, e a sessão pode ser assinada, ou assinada e criptografada. A autenticação de usuários fica em uma camada acima. A dor operacional mais comum é a gestão da confiança entre certificados em dezenas de dispositivos.
A segurança do MQTT fica principalmente no transporte e no broker: TLS para criptografia, credenciais ou certificados de client para autenticação e regras no broker para o que cada client pode fazer. A vantagem arquitetural é a direção. Como todo client MQTT se conecta para fora, até o broker, você não abre portas de entrada na rede de TO. Nosso artigo de boas práticas de segurança MQTT lista o essencial.
Conectividade com a nuvem
É aqui que a comparação é mais desequilibrada. Serviços de nuvem, aplicações web, apps mobile e ferramentas de dados falam quase universalmente MQTT, HTTP ou ambos. Pouquíssimos falam OPC UA client/servidor nativamente, e expor um servidor OPC UA diretamente à internet é uma má ideia. O footprint pequeno do MQTT, sua tolerância a links instáveis, os keep-alives e as mensagens Last Will foram projetados exatamente para esse tipo de conexão remota e intermitente.
O padrão que a maioria das plantas usa: OPC UA na borda, MQTT até a nuvem
Na prática, a pergunta raramente é "OPC UA ou MQTT", e sim "onde cada um entra". O padrão que se vê repetidamente:
Level 0-2 Machines and PLCs -> OPC UA servers (native or via drivers)
Level 2-3 Edge gateway -> OPC UA client: subscribes to tags
-> maps nodes to a topic hierarchy, adds units and quality
Level 3-4 MQTT broker -> single hub (Unified Namespace)
Level 4+ Consumers -> dashboards, historian, MES, analytics, cloud apps
O gateway preserva a semântica do OPC UA onde as máquinas estão e a traduz para uma estrutura de topics e um formato de payload que todo o resto consegue consumir. Nosso tutorial sobre como construir um gateway OPC UA para MQTT apresenta uma implementação funcional em Python que publica em um broker via TLS.
Você pode ver em segundos como fica o lado MQTT desse padrão. Este comando publica um valor derivado de OPC UA, com seu contexto, no servidor MQTT público (gratuito), que serve apenas para testes e protótipos, nunca para dados reais da planta:
mosquitto_pub -h broker.connectmq.com -p 1883 -i opcua-vs-mqtt-5d2e \
-t "connectmq/demo/5d2e/plant1/line1/cnc1/spindle_temp" -r -q 1 \
-m '{"value":47.3,"unit":"degC","quality":"Good","source":"ns=2;s=Line1.CNC1.SpindleTemp"}'
Qualquer subscriber de connectmq/demo/5d2e/# passa a recebê-lo, sem saber nada sobre OPC UA.
Checklist de decisão
Use esta lista para decidir por caso de uso, e não por planta:
- Um client precisa navegar, escrever setpoints ou chamar métodos em uma máquina? Use OPC UA client/servidor.
- Muitos consumidores precisam dos mesmos dados, alguns fora da rede da planta? Publique-os em MQTT.
- Os dispositivos são restritos (microcontroladores, sensores a bateria) ou usam links celulares? MQTT.
- Você precisa de modelos de máquina neutros em relação a fabricantes, com semântica padronizada? OPC UA e suas companion specifications; leve a semântica para os payloads MQTT se fizer a ponte.
- Você quer um Unified Namespace? MQTT como hub, com o OPC UA alimentando-o na borda.
- Você não pode abrir portas de entrada no firewall? As conexões somente de saída do MQTT se encaixam.
- Você precisa de controle determinístico e de baixa latência entre controladores? Nenhum dos dois é a ferramenta certa para controle em tempo real rígido; use o fieldbus projetado para isso.
Onde o ConnectMQ se encaixa
O ConnectMQ é o lado MQTT dessa arquitetura: um broker MQTT gerenciado com suporte a MQTT 3.1.1 e 5.0 sobre TCP, TLS e WebSockets. Ele não fala OPC UA, e isso é intencional; seu gateway de borda cuida do OPC UA e publica MQTT nele. O ConnectMQ detecta topics ISA-95 e de Unified Namespace, mostra-os em um explorador de topics ao vivo e em uma visão de dispositivos organizada por níveis ISA-95, e pode decodificar payloads Sparkplug B se o seu gateway usar esse formato. Para uma visão geral da stack completa, veja nosso guia de IoT industrial com MQTT.
Comece com o ConnectMQ
Experimente o padrão borda-nuvem sem instalar um broker. Cadastre-se em app.connectmq.com no plano Serverless (Free), sem cartão de crédito, crie um broker e aponte seu gateway OPC UA para ele com as credenciais geradas. Na mesma tarde você terá dados da planta fluindo para um broker MQTT privado na nuvem.
Perguntas frequentes
O MQTT está substituindo o OPC UA?
Não. O MQTT está substituindo as integrações ponto a ponto acima do chão de fábrica, enquanto o OPC UA continua sendo a forma padrão pela qual muitas máquinas expõem dados estruturados. A maioria das arquiteturas usa os dois.
O OPC UA ou o MQTT é mais seguro?
Ambos são seguros quando configurados corretamente. O OPC UA protege as sessões com certificados de aplicação; o MQTT depende de TLS e da autenticação no broker, com a vantagem de que os clients só fazem conexões de saída.
O OPC UA pode usar o MQTT diretamente?
Sim. O OPC UA Parte 14 PubSub define o MQTT como transporte com codificações JSON ou UADP binária, de modo que publishers OPC UA podem enviar mensagens por meio de um broker MQTT padrão.
Qual é melhor para um Unified Namespace, OPC UA ou MQTT?
O MQTT é o hub usual de um Unified Namespace por causa do desacoplamento publish/subscribe. Os servidores OPC UA normalmente alimentam esse namespace por meio de gateways de borda.
