otros
Comparativa: OPC UA vs. MQTT en Edge Computing
Jun
Si tengo que decirlo en una línea: OPC UA sirve mejor dentro de planta; MQTT sirve mejor para enviar datos por redes limitadas; y muchas veces conviene usar ambos.
Yo lo resumiría así:
- Uso OPC UA cuando necesito contexto de datos, integración entre equipos y seguridad a nivel de aplicación.
- Uso MQTT cuando necesito mensajes livianos, bajo consumo de red y tolerancia a enlaces inestables.
- Uso OPC UA + MQTT cuando quiero datos bien modelados en planta y salida eficiente hacia nube o sitios remotos.
Hay números que explican rápido la diferencia:
- El edge computing puede bajar el tráfico entre 100 y 1.000 veces al filtrar datos en terreno.
- MQTT puede trabajar con una sobrecarga de cerca de 2 bytes por dato.
- OPC UA Binary puede llegar a cerca de 150 bytes por dato.
- En OPC UA, leer un nodo puede tomar una mediana de 3,0 ms, pero recorrer árboles completos puede subir a 103,9 ms.
Dicho simple: si tu red es angosta, cara o inestable, MQTT parte mejor.
Y si tu planta mezcla PLC, SCADA, DCS y equipos de varias marcas, OPC UA suele calzar mejor por su modelo de datos.
OPC UA vs MQTT vs Sparkplug B en Edge Computing Industrial
OPC UA vs MQTT – The Industrial Protocol Showdown! #opcua #mqtt #automation
sbb-itb-f30cc9a
Quick Comparison
| Criterio | OPC UA | MQTT | MQTT + Sparkplug B |
|---|---|---|---|
| Modelo | Cliente-servidor | Publicación-suscripción | Publicación-suscripción con estado |
| Ancho de banda | Alto | Bajo | Bajo |
| Carga en edge | Alta | Baja | Media |
| Semántica | Nativa | No incluida | Ordenada por estándar |
| Seguridad | Certificados X.509 y firma | TLS | TLS |
| Redes inestables | Menos apto | Sí | Sí |
| Integración industrial local | Alta | Media | Alta |
| Caso típico | Planta y control local | Telemetría remota | Esquema híbrido |
Mi lectura corta: no conviene mirar solo el protocolo. También pesan la red física, la EMI, la calidad del cableado, el uso de fibra óptica, la RAM del equipo edge, el manejo de certificados y qué pasa si se corta el enlace.
Con eso claro, esta comparativa ayuda a elegir sin quedarse en la teoría.
2. Fundamentos de OPC UA y MQTT para arquitecturas edge
2.1 OPC UA en el edge: modelos de datos, seguridad e integración industrial
OPC UA resuelve el intercambio de datos con contexto entre equipos heterogéneos. No envía solo un valor. También entrega nombre, unidad, tipo y estado.
Su modelo base es cliente-servidor: el cliente solicita datos y el servidor responde con ese contexto. Con PubSub, además, puede calzar bien en arquitecturas distribuidas y apoyarse en brokers MQTT. En seguridad, OPC UA viene preparado desde el origen, con cifrado, certificados digitales X.509 y firma de mensajes.
En la práctica, OPC UA llega al edge por medio de gateways industriales. Estos equipos leen dispositivos de campo usando protocolos heredados como Modbus o Profibus (que suelen requerir cable de comunicación RS485 para su capa física), y después exponen esa información como un servidor OPC UA hacia los sistemas superiores. Dicho de forma simple: la planta puede modernizar su capa de datos sin detener la operación.
Eso sí, en el edge hay un punto que pesa. El costo de cómputo no es menor. Leer un solo nodo tiene una latencia mediana de 3,0 ms, pero recorrer un árbol completo de variables puede llegar a una mediana de 103,9 ms. La brecha es grande, y se nota más cuando el edge trabaja con recursos acotados. Por eso, OPC UA suele mantenerse puertas adentro de la planta, mientras MQTT gana terreno en la salida de datos.
2.2 MQTT en el edge: publicación-suscripción liviana para redes restringidas
MQTT fue pensado para entornos donde el ancho de banda es limitado y la conexión puede caerse en cualquier momento. Su arquitectura sigue el modelo de publicación-suscripción: los dispositivos publican mensajes en un broker central, y los consumidores se suscriben a los tópicos que les interesan. El productor y el consumidor no hablan entre sí de forma directa, lo que hace más simple escalar la solución.
Lo que vuelve a MQTT tan útil en el edge es su sobrecarga mínima. Su cabecera ocupa apenas 2 bytes. En redes apretadas, ese detalle importa.
Su principal punto débil en contextos industriales está en la semántica. MQTT no define el contenido del mensaje ni trae un modelo de información estándar. Entonces, dos dispositivos pueden publicar en el mismo tópico usando JSON distintos y, aun así, no entenderse de forma consistente.
Con esta base, la siguiente sección compara desempeño, semántica y seguridad.
3. OPC UA vs. MQTT en edge computing: comparación directa
Con esa base, la comparación útil ya no es teórica. Pasa a ser operativa.
En edge, la diferencia que más pesa suele ser el costo por mensaje. MQTT agrega 2 bytes por dato, Sparkplug B 20 y OPC UA Binary 150. En enlaces celulares o satelitales, esa distancia no es menor. Ahí cada byte cuenta.
La tabla siguiente resume dónde rinde mejor cada opción en edge:
| Criterio | OPC UA | MQTT | MQTT + Sparkplug B |
|---|---|---|---|
| Arquitectura | Cliente-servidor con consulta periódica | Publicación-suscripción basada en eventos | Pub/Sub + gestión de estado |
| Consumo de ancho de banda | Alto | Muy bajo | Muy bajo + estructura de datos |
| Carga CPU/Memoria | Alta | Muy baja | Baja |
| Latencia local | Baja y predecible en una LAN estable | Asíncrona, ideal para telemetría | Asíncrona, ideal para telemetría |
| Redes inestables | Menos adecuado | Diseñado para WAN/celular intermitente | WAN industrial / nube |
| Interoperabilidad semántica | Rica, nativa | No nativa | Estandarizada con Protocol Buffers |
| Seguridad integrada | Certificados X.509 en capa de aplicación | TLS en la capa de transporte | TLS en la capa de transporte |
| Integración PLC/SCADA/DCS | Alta en entornos industriales locales | Requiere mapeo manual o Sparkplug B | Alta, con autodescubrimiento |
| Escalabilidad | Limitada por conexiones punto a punto | Alta vía broker | Alta, con autodescubrimiento |
| Complejidad de implementación | Alta | Baja | Media |
3.1 Rendimiento, sobrecarga y confiabilidad bajo restricciones del edge
OPC UA genera tráfico continuo. MQTT, en cambio, envía datos solo cuando hay cambios. En muchos sensores, eso puede bajar el tráfico entre 100 y 1.000 veces frente al polling continuo.
Dicho simple: si el enlace es caro, inestable o angosto, MQTT parte con ventaja.
Para control local con exigencias de tiempo estrictas, OPC UA sigue siendo la opción correcta. Tiene sentido en entornos donde importa una respuesta baja y predecible dentro de una LAN estable. MQTT juega otro partido: fue pensado para entregar telemetría de forma confiable sobre redes que pueden caerse en cualquier momento.
Ahí entra una función bien útil: Last Will and Testament (LWT). Si un nodo edge se desconecta de forma inesperada, el broker puede avisarles a los suscriptores de inmediato. En monitoreo remoto de plantas con conectividad irregular, eso es clave.
La diferencia no se queda solo en rendimiento. También cambia la manera en que cada protocolo da forma a los datos y cómo los protege.
3.2 Interoperabilidad semántica, seguridad y esfuerzo de integración
OPC UA entrega contexto nativo. MQTT no lo trae por sí solo y necesita una capa extra para estandarizarlo.
Esa capa suele ser Sparkplug B. Al fijar el formato del payload con Protocol Buffers y sumar mensajes de estado como Birth/Death certificates, le da a MQTT una estructura mucho más predecible, en una línea parecida a la de OPC UA.
En seguridad, también hay una diferencia clara. OPC UA incorpora cifrado y firma en la capa de aplicación con certificados X.509. MQTT depende de TLS en la capa de transporte.
Al final, la elección ya no pasa solo por cuál protocolo mueve datos con menos costo. Pasa por el tipo de planta, la calidad de la red y cuánto trabajo de integración se puede asumir.
4. Elegir el protocolo correcto para casos industriales en Chile
4.1 Cuándo usar OPC UA, cuándo MQTT y cuándo combinar ambos
Con esos criterios sobre la mesa, toca llevarlos a casos industriales en Chile. Acá la elección cambia según la operación y, muy en serio, según la red que tengas disponible.
| Caso de uso | Protocolo recomendado | Razón principal |
|---|---|---|
| Minería (control local) | OPC UA | Modelos de datos complejos, seguridad y autonomía local |
| Energía remota (telemetría) | MQTT | Eficiente sobre celular o satélite; tolera alta latencia |
| Despliegue edge híbrido | OPC UA + MQTT | Datos ricos localmente, sincronización eficiente hacia la nube |
Si una planta necesita datos bien estructurados dentro de la operación y, al mismo tiempo, una salida liviana hacia la nube, el esquema híbrido suele calzar mejor. Dicho simple: OPC UA se queda en planta y MQTT envía la información agregada hacia sistemas externos o servicios en la nube.
Eso hace sentido en faenas donde no conviene depender por completo de la conectividad externa. El control y el contexto quedan adentro; la publicación remota va por un canal más liviano.
4.2 Infraestructura física: medios de red, calidad de señal y selección de cables
La decisión no termina en el protocolo. La red física puede ser el punto que haga que todo funcione bien… o que empiece a fallar sin aviso. Al final, la capa física manda más de lo que muchos quisieran.
En ambientes con alta interferencia electromagnética (EMI), como plantas mineras o zonas con mucho ruido eléctrico, un cable mal blindado puede dañar la calidad de los datos aunque el protocolo esté bien implementado. Es el típico caso donde el software hace su pega, pero el medio físico le pone la traba.
Para esas condiciones, la fibra óptica corta el problema de raíz porque no sufre EMI. En enlaces Ethernet, conviene usar cable industrial Cat 6A o 7 cuando el nivel de ruido y la distancia lo pidan.
Inducable distribuye en Chile cables industriales Ethernet, RS-485, bus de campo y fibra óptica para entornos de automatización. Si la capa física no está bien resuelta, comparar OPC UA con MQTT queda solo en el papel.
5. Consideraciones de despliegue y conclusión
5.1 Lista de verificación para despliegues edge con OPC UA o MQTT
Antes de desplegar, hay tres cosas que deben quedar cerradas: la semántica, el dueño del dato y la reacción ante una pérdida de enlace. Suena básico, pero ahí es donde se enredan muchos proyectos. En terreno, varias fallas parten por no definir desde el diseño quién interpreta los datos, cómo se ordena la información y qué pasa si la comunicación se cae.
Si el canal transporta comandos o variables críticas, deja fijado un estado seguro frente a pérdida de comunicación o reinicio. Ese punto no es un detalle. Es de esas decisiones que después evitan paradas, alarmas mal disparadas o maniobras fuera de lugar.
La siguiente tabla resume lo que conviene revisar antes del despliegue:
| Componente | OPC UA (servidor edge) | MQTT (broker/cliente) | Requisitos físicos |
|---|---|---|---|
| Seguridad | Gestión de certificados y cifrado | Gestión de certificados y cifrado | Cableado apantallado (Cat6a), fibra óptica y DMZ industrial |
| Modelo de datos | Modelo semántico | Mensajes por tópico | Segmentación OT/IT con gateway edge |
| Red | LAN local estable, alto ancho de banda | WAN remota, bajo ancho de banda o inestable | Fibra óptica en distancias largas o con EMI |
| QoS y latencia | Determinista con TSN; 10–50 ms local | QoS 0, 1 o 2 según criticidad | 4G/5G para activos móviles (AGV) |
| Hardware | 1 GB o más de RAM para modelos complejos | 512 MB o más de RAM para clientes livianos | Equipos en riel DIN, IP65/67 y UPS |
También conviene dejar resueltos desde el arranque dos temas que suelen aparecer tarde: la gestión de certificados X.509 y el buffering local. Ambos ayudan a evitar cortes y pérdida de datos.
Con eso claro, la elección entre protocolos deja de ser una discusión abstracta y pasa a depender del tipo de operación que necesitas cubrir.
5.2 Conclusión: cómo elegir entre OPC UA y MQTT para proyectos edge
Si ya resolviste semántica, red y seguridad, la decisión suele caer en dos patrones de uso bastante claros. OPC UA pega mejor donde manda la semántica: integración entre PLC, MES y sistemas de gestión dentro de planta, con seguridad integrada y modelos de datos ricos. MQTT, en cambio, funciona mejor donde manda el transporte: telemetría remota, conexión hacia la nube y redes celulares o satelitales con ancho de banda limitado.
En plantas existentes con equipos legacy, como Modbus RTU o Profibus, la salida más práctica suele pasar por gateways de traducción. Esos equipos convierten datos hacia MQTT u OPC UA sin tocar el hardware ya instalado. Dicho en simple: OPC UA en planta, MQTT hacia afuera.
Al final, el protocolo correcto no se define por moda ni por preferencia técnica. Se define por lo que pide la aplicación, por las condiciones de red disponibles, por la capacidad del hardware, por los requisitos de ciberseguridad y por la calidad de la infraestructura física de comunicaciones. Si uno de esos puntos sigue abierto, comparar protocolos sirve de poco.
FAQs
¿Cómo elegir entre OPC UA, MQTT o ambos?
Depende de tu arquitectura. OPC UA suele calzar mejor dentro de la planta cuando necesitas interoperabilidad, seguridad sólida y modelos de datos con contexto. Por eso, se usa mucho para conectar PLCs y sensores con sistemas SCADA o MES.
MQTT, en cambio, funciona mejor para comunicaciones externas, despliegues IIoT o redes con poco ancho de banda o con conexiones inestables. Va al grano y mueve datos de forma liviana.
En edge computing, de hecho, muchos sistemas ocupan los dos. OPC UA se usa para normalizar los datos que vienen del campo, y MQTT para mandarlos de forma liviana a la nube. Es una combinación bien común: uno ordena la información y el otro la transporta sin meter tanto peso.
¿Es necesario Sparkplug B con MQTT industrial?
No, Sparkplug B no es un requisito estricto para implementar MQTT industrial, pero sí conviene mucho usarlo.
Por sí solo, MQTT no define cómo se deben estructurar los datos ni cómo manejar el estado de los equipos. Ahí es donde entra Sparkplug: entrega un marco para estandarizar los temas, la carga útil y el estado del dispositivo. En la práctica, eso facilita la interoperabilidad y baja la complejidad en entornos industriales heterogéneos.
¿Qué impacto tiene la red física en esta decisión?
La red física pesa mucho al momento de elegir un protocolo. No es un detalle menor: lo que la red puede o no puede hacer pega directo en el rendimiento.
Si hay poco ancho de banda, conexiones inestables o la meta es bajar el consumo de energía, MQTT suele funcionar mejor. Va más liviano y se adapta bien a escenarios donde cada byte cuenta.
En cambio, cuando la prioridad es la interoperabilidad, la seguridad integrada y una fiabilidad determinista dentro de la planta, OPC UA saca ventaja. Su modelado de datos y el uso de metadatos le dan más orden y contexto al intercambio de información.
En Inducable, sabemos que elegir bien los cables de comunicación industrial ayuda a mantener condiciones de red óptimas y a evitar problemas que después cuestan tiempo y plata.
Publicaciones de blog relacionadas
- ¿Qué Cable de Comunicación Necesito? Preguntas Frecuentes
- Checklist para Planificar Proyectos de Cableado Industrial
- Impacto de la fibra óptica en la automatización industrial
- Cómo elegir cables PoE para sistemas industriales
