En casi todos los proyectos IIoT surge la misma pregunta: ¿OPC UA o MQTT? A veces hay detrás una necesidad real de decidir. A menudo, lo que hay es la esperanza de que exista una respuesta clara: «elige X y listo».
La respuesta honesta es: depende. Pero «depende» solo sirve de algo si se sabe de qué depende. Eso es exactamente lo que intento explicar aquí, desde la perspectiva de alguien que utiliza ambos protocolos con regularidad en entornos de fabricación reales.
Qué es OPC UA y qué no es
OPC UA (Open Platform Communications Unified Architecture) es un estándar de comunicación industrial publicado en 2008 por la OPC Foundation. Lo decisivo: OPC UA no es solo un protocolo de transporte. También define un modelo de datos semántico.
¿Qué significa esto en concreto? Cuando un PLC Siemens S7 exporta por OPC UA un punto de datos «velocidad del husillo», un cliente OPC UA no solo sabe que el valor es 3.200. También sabe qué significa ese valor, qué unidad tiene, qué límites se aplican y cuándo cambió por última vez.
Esa es la gran ventaja de OPC UA: los datos llevan consigo su propio significado. Eso hace que la integración sea mucho más robusta, porque emisor y receptor tienen que acordar menos conocimiento implícito.
Qué es MQTT y por qué se hizo tan popular
MQTT (Message Queuing Telemetry Transport) fue desarrollado por IBM en 1999 para aplicaciones en entornos con malas conexiones de red, originalmente para oleoductos en el desierto. Ligero, robusto, de baja latencia y con una sobrecarga mínima (la cabecera ocupa solo 2 bytes).
MQTT es un protocolo puramente pub/sub: los dispositivos (publishers) envían mensajes a topics. Un broker (p. ej., Mosquitto o HiveMQ) los distribuye a todos los subscribers. Funciona de maravilla, pero MQTT en sí no define qué contienen esos mensajes. Eso deben acordarlo de antemano el emisor y el receptor.
Si una máquina envía por MQTT un valor «3200», el receptor, de entrada, no sabe nada de él, salvo lo que diga el nombre del topic. Que sean revoluciones por minuto, vatios o gramos depende por completo de la implementación.
La comparación directa
| Aspecto | OPC UA | MQTT |
|---|---|---|
| Origen | Estándar industrial (OPC Foundation, 2008) | Protocolo IoT (IBM, 1999) |
| Arquitectura | Cliente-servidor y pub/sub (desde v1.04) | Pub/sub (basado en broker) |
| Modelo de datos | Tipado, semántico (address space) | Agnóstico respecto al payload (binario, JSON, etc.) |
| Semántica | Integrada: los datos tienen significado | Ninguna: el significado debe acordarse |
| Seguridad | TLS + certificados de forma nativa | TLS opcional, la implementación varía |
| Sobrecarga | Mayor (XML/binario, handshake) | Muy baja (cabecera: 2 bytes) |
| Latencia | Baja a media | Muy baja |
| Idóneo para | Conexión de máquinas, integración OT | Sensor→cloud, edge→backend |
Cuándo recomiendo OPC UA
OPC UA es la elección correcta cuando lo principal es la conexión con el control de la máquina, es decir, cuando quiere leer datos directamente de un PLC, de un controlador CNC o de un sistema SCADA.
- Conexión de máquinas: Siemens, Beckhoff, B&R, Bosch Rexroth: estos PLC admiten OPC UA de forma nativa. La integración es limpia, tipada y está bien documentada.
- Interoperabilidad: Si hay que integrar distintas máquinas de distintos fabricantes, OPC UA ofrece un estándar común. Con MQTT tiene que definir una estructura de topics propia para cada máquina.
- Integración IT/OT: OPC UA tiene un marco de seguridad claro (certificados, autenticación, sesiones cifradas). Eso es relevante en entornos regulados y en cualquier lugar donde se conecten redes IT y OT.
- Requisitos semánticos: Si los puntos de datos deben interpretarse de forma coherente en distintos sistemas, p. ej., en el historian, el SCADA y la analítica a la vez, el modelo de datos tipado de OPC UA es una ventaja considerable.
Cuándo recomiendo MQTT
MQTT es la elección correcta para todo lo que ocurre entre el dispositivo edge y el backend, sobre todo cuando hay que transmitir muchos puntos de datos con alta frecuencia y la conexión de red puede no ser fiable.
- Conexión de sensores: Raspberry Pi, Arduino, ESP32: estos dispositivos rara vez tienen OPC UA implementado. MQTT funciona en todos ellos con recursos mínimos.
- Funcionamiento sin conexión: Los brokers MQTT pueden almacenar mensajes (QoS nivel 1 y 2) hasta que el subscriber vuelva a estar disponible. Eso es valioso en entornos de producción con redes inestables.
- Alto rendimiento: Si hay que transmitir 500 puntos de datos por segundo, MQTT, gracias a su sobrecarga mínima, es mucho más eficiente que OPC UA.
- Conexión con la nube: AWS IoT Core, Azure IoT Hub: las grandes plataformas IoT en la nube hablan MQTT de forma nativa. OPC UA siempre necesita ahí un adaptador.
La respuesta más habitual en la práctica: ambos
En casi todos los proyectos que realizamos se utilizan ambos protocolos, en distintos puntos de la arquitectura. Típicamente se ve así:
PLC (Siemens S7) ──OPC UA──▶ Gateway edge
Gateway edge ──MQTT──▶ Broker (Mosquitto/HiveMQ)
Broker ──MQTT──▶ InfluxDB / Grafana / Backend
OPC UA lee el control de la máquina: tipado, semánticamente correcto y con autenticación por certificados. El gateway edge (típicamente un PC industrial o una Raspberry Pi) normaliza los datos y los reenvía por MQTT: ligero, apto para funcionar sin conexión y compatible con la nube.
No es un compromiso. Es la arquitectura que aprovecha los puntos fuertes de ambos protocolos en el lugar adecuado.
Guía práctica para decidir
¿La máquina tiene OPC UA nativo?
→ Usar OPC UA directamente.
¿La máquina tiene una interfaz propietaria (FOCAS, SHDR, Siemens S5)?
→ Adaptador en el gateway edge, salida por MQTT.
¿Sensor sin protocolo de red (analógico, E/S digital)?
→ Gateway edge con hardware de sensores, salida por MQTT.
¿Los datos deben ir a una plataforma cloud (Azure, AWS)?
→ MQTT al broker y de ahí en adelante.
¿Hay que unificar varias máquinas de distintos fabricantes?
→ OPC UA como protocolo de destino, con adaptadores donde haga falta.
¿Tasa de datos muy alta (>100 puntos/s)?
→ Dar preferencia a MQTT.
¿Entorno regulado, con requisitos de auditoría?
→ OPC UA, por su marco de seguridad y autenticación.
Qué cambia MQTT Sparkplug B
Una breve indicación para quien quiera profundizar: MQTT Sparkplug B es una especificación que se basa en MQTT y define un modelo de datos y una estructura de topics estandarizados para aplicaciones industriales. Intenta trasladar a MQTT la ventaja semántica de OPC UA.
En la práctica, vemos Sparkplug B sobre todo en proyectos greenfield con una infraestructura homogénea. En entornos mixtos con máquinas heredadas, OPC UA sigue siendo la opción más robusta a nivel de máquina.
Conclusión
OPC UA y MQTT no son competidores: resuelven problemas distintos en distintos puntos de una arquitectura IIoT. La pregunta «¿OPC UA o MQTT?» suele ser la pregunta equivocada. La pregunta correcta es: «¿Qué hay que transmitir, dónde, en qué condiciones y con qué requisitos de seguridad y semántica?»
Si quiere repasar estas preguntas para su situación concreta (qué máquinas tiene, qué protocolos hablan y cómo sería una arquitectura pragmática): Póngase en contacto con nosotros.