AprenderMQTT u OPC UA
Herramientas UNS gratuitas
MQTT u OPC UA

Dos estándares, dos trabajos distintos.

OPC UA (IEC 62541) es un estándar de interoperabilidad con modelo de información: objetos tipados y explorables que llevan tipos de datos, unidades de ingeniería y métodos, normalmente consultados en cliente/servidor. MQTT (OASIS, v3.1.1 y v5.0) es un transporte publish/subscribe ligero: un broker desacopla a los publicadores de los consumidores y mueve mensajes pequeños por redes poco fiables, sin opinión alguna sobre su contenido. No son dos candidatos para el mismo hueco, y por eso la respuesta honesta suele ser ambos — OPC UA para sacar datos estructurados de las máquinas, MQTT para distribuirlos por la planta.

Cara A Cara

Las diferencias que sí cambian su arquitectura.

CriterioOPC UAMQTT
Modelo de interacciónSesiones cliente/servidor con suscripciones y elementos monitorizados. El cliente debe conocer y alcanzar cada servidor. OPC UA PubSub (parte 14) añade un modo con broker que puede ir sobre MQTT.Publish/subscribe a través de un broker. Publicador y consumidor no se conocen: añadir un décimo consumidor no cambia nada aguas arriba.
Modelo de informaciónUn espacio de direcciones explorable: objetos, variables, tipos de datos, unidades, métodos y companion specifications para familias enteras de máquinas.Ninguno. La carga útil son bytes opacos. MQTT 5 añade propiedades de usuario y una pista de content-type, pero no un modelo — Sparkplug B es la forma habitual de aportarlo.
DescubrimientoExplorar el servidor en tiempo de ejecución. Un cliente nuevo aprende la estructura sin esperar la hoja de cálculo del integrador.Suscribirse a un comodín y ver qué llega. El significado viene de una convención de topics que usted diseña, documenta y gobierna.
Comportamiento de redSensible a la latencia y a la pérdida de paquetes; las sesiones se reconectan y vuelven a suscribirse. Pide conexiones entrantes a través de los cortafuegos entre niveles, más un intercambio de certificados.Cada equipo edge abre una única conexión TLS saliente. QoS 1, sesiones persistentes y last will sobreviven a los cortes: de ahí su comodidad sobre celular, satélite y NAT.
Carga útil y ancho de bandaUA Binary sobre TCP 4840 es compacto; la codificación JSON no lo es. Las suscripciones reportan solo cambios si usted configura bandas muertas y muestreo con intención.Cabecera fija de dos bytes como mínimo; puertos 1883 en claro y 8883 con TLS. Una actualización DDATA de Sparkplug con alias de métricas pesa decenas de bytes.
SeguridadCertificados X.509 por sesión, firma y cifrado, autenticación de usuario, políticas de seguridad con nombre. Las listas de confianza y las caducidades son trabajo operativo real y recurrente.TLS más usuario/contraseña, certificado de cliente o token. La autorización por topic vive en el broker: su control de acceso es el diseño que no se puede saltar.
Mejor encajeIntegración de máquina y línea: acceso tipado, comandos y métodos con acuse, o una companion specification del fabricante que conviene heredar en vez de reinventar.Distribución por toda la planta y hacia la nube: muchos consumidores independientes, enlaces intermitentes, arquitectura basada en eventos y el transporte bajo la mayoría de despliegues UNS.

Elegir OPC UA

Cuando necesita la estructura de una máquina y no una lista de direcciones: nodos tipados, unidades, métodos, alarmas y condiciones, y una companion specification que ya modela su clase de equipo. También cuando un comando exige un acuse firme y no una publicación sin retorno.

Elegir MQTT

Cuando una medida tiene muchos consumidores — paneles, historian, MES, un análisis, otra planta — y usted se niega a añadir una integración cada vez que aparece uno nuevo. También en cuanto el enlace es malo: un broker con QoS 1 y store-and-forward tolera lo que una sesión cliente/servidor no tolera.

El patrón habitual

OPC UA desde las máquinas hasta un nodo edge; el nodo edge proyecta las señales sobre un espacio de nombres gobernado y republica por excepción hacia un broker MQTT; todo lo demás se suscribe. En esa proyección está el trabajo de modelado, y saltarla produce un broker lleno de señales sin significado.

Trampas que vemos en despliegues reales.

  • Tratar la elección como una religión de planta. Se decide por tramo — máquina a edge, edge a planta, planta a nube — y distintos tramos eligen de forma legítimamente distinta.
  • Puentear un nodo OPC UA a un topic MQTT sin modelo por medio. Ha mudado el desorden, no ha construido un espacio de nombres.
  • Suponer que MQTT entrega un UNS. MQTT entrega mensajes; jerarquía, nomenclatura, contrato de carga útil y gobierno siguen siendo su trabajo.
  • Dejar que los certificados y las listas de confianza de OPC UA se descuiden hasta que una caducidad para la línea un domingo.
  • Activar QoS 2 en todas partes «por si acaso». Cuesta un saludo de cuatro pasos por mensaje; QoS 1 con consumidores idempotentes es la elección industrial normal.
  • Sondear 20.000 nodos OPC UA cada segundo y llamar a eso arquitectura por eventos. El reporte por excepción es una decisión de configuración, no una insignia del protocolo.
Conceptos Relacionados

Dónde encaja esta decisión.

La elección de protocolo es la fontanería bajo una pregunta mayor: qué información publica la planta y quién tiene derecho a depender de ella. Eso es lo que define un Unified Namespace, lo que Sparkplug B codifica en el cable, aquello para lo que ISA-95 aporta vocabulario común, y lo que la contextualización convierte en algo legible para una persona o un modelo. Los requisitos técnicos mínimos — gobernado por el edge, reporte por excepción, abierto, ligero — filtran más rápido que una matriz de funciones. Aguas abajo, la misma elección decide si un OEE es creíble y si el mantenimiento predictivo llega a ver la señal que necesita.

Gratis, Sin Registro

Compruebe sus topics antes de convertirlos en estándar.

Nuestras herramientas gratuitas, ejecutadas en el navegador, validan un topic Sparkplug B contra la gramática de la especificación y revisan una lista de rutas de espacio de nombres buscando lo que lo degrada en silencio: profundidad inconsistente, mayúsculas mezcladas, espacios, colisiones por mayúsculas y duplicados. Nada de lo que pegue sale de su equipo.

Abrir las herramientas gratuitas

Preguntas frecuentes

¿Hay que elegir uno para toda la planta?

No, y la pregunta suele delatar un error de alcance. La elección se hace tramo a tramo: OPC UA entre una máquina y su nodo edge, MQTT entre ese nodo y todos los consumidores posteriores. Decidir una sola vez para todo es justo lo que obliga después a las pasarelas incómodas que nadie quiere mantener.

¿MQTT nos da un Unified Namespace?

No. MQTT es el transporte sobre el que corren la mayoría de despliegues UNS, nada más. El espacio de nombres es precisamente lo que MQTT no aporta: una jerarquía que refleja el negocio, una convención de nomenclatura, un contrato de carga útil y alguien responsable de cambiarlos. Un broker con 40.000 topics libres es un bus de mensajes, no un espacio de nombres.

¿Es OPC UA PubSub sobre MQTT lo mejor de ambos mundos?

Ayuda de verdad cuando quiere que la información de tipos de UA viaje por un broker en lugar de por sesiones punto a punto. Pero el soporte en brokers y clientes sigue siendo desigual, la codificación elegida (JSON o UA Binary) determina quién puede leer, y no diseña su espacio de nombres. Confirme qué saben decodificar sus consumidores reales antes de convertirlo en estándar.