Modbus, OPC UA o MQTT: qué protocolo elegir en tu planta
Publicado el 5 min de lecturaRead in English
Respuesta corta
No compiten entre sí: cada uno encaja en un nivel. Modbus es simple y universal para leer registros de equipos de campo; OPC UA aporta modelo de información y seguridad a nivel de máquina y autómata; MQTT es ligero y eficiente para enviar telemetría a SCADA o a la nube. En la mayoría de plantas se combinan mediante pasarelas.
Puntos clave
- Modbus lee y escribe registros numerados: es sencillo y casi universal, pero no describe qué significan los datos ni tiene seguridad propia.
- OPC UA modela los datos con nombres, tipos y unidades, e incorpora autenticación y cifrado, a cambio de más complejidad.
- MQTT publica mensajes a través de un broker; es ideal para telemetría, pero no define el formato de los datos salvo que uses Sparkplug B.
- La arquitectura habitual combina los tres: Modbus en campo, OPC UA en máquina y MQTT hacia SCADA o nube.
- Nunca expongas Modbus a internet: segmenta la red y usa pasarelas o VPN.
Si estás conectando máquinas, contadores o sensores, tarde o temprano te toca elegir protocolo. Modbus, OPC UA y MQTT aparecen en casi todas las conversaciones, y a menudo se presentan como alternativas. En realidad resuelven problemas distintos. Aquí tienes qué hace cada uno, en qué se diferencian y cómo elegir.
¿Qué es Modbus?
Modbus es un protocolo de comunicación maestro-esclavo (hoy se habla de cliente-servidor) basado en registros numerados. Un equipo pregunta «dame el valor de los registros 100 a 110» y el otro responde con números. Existen dos variantes principales:
- Modbus RTU: por bus serie, normalmente RS-485. Muy habitual en contadores de energía, variadores y controladores sencillos.
- Modbus TCP: el mismo modelo de datos sobre Ethernet.
Su gran ventaja es que está en todas partes y es fácil de implementar. Sus limitaciones también son claras: no tiene semántica (el registro 104 no dice si es una temperatura o una presión, ni en qué unidades; eso está en el manual del equipo) y no incorpora seguridad: cualquiera con acceso a la red puede leer y escribir.
¿Qué es OPC UA?
OPC UA (Open Platform Communications Unified Architecture) es un estándar abierto para intercambiar datos industriales con modelo de información. Los datos no son solo números: tienen nombre, tipo, unidades, jerarquía y relaciones. Un cliente puede navegar por el servidor y descubrir qué variables hay sin leer un manual.
Características principales:
- Seguridad integrada: autenticación con certificados, firma y cifrado de mensajes.
- Dos modelos de comunicación: cliente/servidor para consultas y escritura, y PubSub para distribuir datos a muchos receptores.
- Especificaciones sectoriales (companion specifications) que estandarizan cómo se describe un tipo de máquina.
El precio es la complejidad: requiere más recursos, más configuración (gestión de certificados incluida) y más conocimiento para sacarle partido.
¿Qué es MQTT?
MQTT es un protocolo ligero de publicación/suscripción. Los dispositivos no se hablan directamente: publican mensajes en «temas» (por ejemplo, planta1/bomba3/presion) en un servidor intermedio llamado broker, y quien esté interesado se suscribe a esos temas.
Funciona muy bien con conexiones lentas o inestables, consume poco ancho de banda y encaja de forma natural con sistemas de IT y nube. Ofrece niveles de calidad de servicio para garantizar la entrega y admite TLS y autenticación en el broker.
Su limitación: MQTT no define qué hay dentro del mensaje. Cada integrador puede inventar su propio formato y su propia estructura de temas. Sparkplug B resuelve esto añadiendo una estructura de temas, un formato de mensaje y la gestión del estado de los dispositivos.
¿En qué se diferencian Modbus, OPC UA y MQTT?
| Aspecto | Modbus RTU/TCP | OPC UA | MQTT |
|---|---|---|---|
| Modelo | Petición/respuesta sobre registros | Cliente/servidor y PubSub con modelo de información | Publicación/suscripción a través de broker |
| Semántica de los datos | Ninguna: solo números | Completa: nombres, tipos, unidades, estructura | Ninguna de serie; Sparkplug B la añade |
| Seguridad | No integrada | Certificados, firma y cifrado | TLS y autenticación en el broker |
| Complejidad | Baja | Alta | Baja a media |
| Recursos del dispositivo | Mínimos | Moderados a altos | Bajos |
| Uso típico | Contadores, variadores, sensores de campo | Autómatas, máquinas, integración con SCADA/MES | Telemetría, remotas, envío a nube y aplicaciones IT |
| Punto débil | Mapa de registros en el manual de cada equipo | Configuración y curva de aprendizaje | Formatos incompatibles si no se acuerda un estándar |
¿Cómo se combinan en una arquitectura real?
En la mayoría de plantas no se elige uno, sino que se usa cada protocolo en el nivel donde encaja:
- Nivel de campo: contadores de energía, variadores y sensores hablan Modbus RTU o TCP con el autómata o con una pasarela.
- Nivel de máquina y autómata: el autómata expone sus datos por OPC UA, con nombres y unidades, al SCADA o a otros sistemas de la planta.
- Nivel de supervisión y nube: una pasarela o el propio SCADA publica la telemetría por MQTT hacia un historiador, un panel o un servidor remoto.
Las pasarelas son la pieza que une los niveles: leen Modbus, traducen a nombres con sentido y publican por OPC UA o MQTT. Es importante que el control funcione aunque se caiga la conexión externa: la planta no debe depender de internet para producir.
¿Qué protocolo elegir según tu caso?
- Quieres leer contadores de energía o variadores existentes: Modbus, casi seguro, porque es lo que traen. Ver consumo en vacío: la energía que gasta tu fábrica sin producir.
- Integras varias máquinas con autómatas modernos en un SCADA o MES: OPC UA, por su modelo de datos y su seguridad.
- Tienes instalaciones remotas con conexión móvil (bombeos, depósitos, campo): MQTT, por su ligereza y su tolerancia a cortes. Lo desarrollamos en telemetría de estaciones de bombeo.
- Envías datos a una plataforma en la nube o a aplicaciones de IT: MQTT, preferiblemente con Sparkplug B o un formato documentado.
- Diseñas un equipo propio: ofrece al menos Modbus por compatibilidad, y añade MQTT u OPC UA si el destino lo requiere.
Preguntas para decidir
- ¿Qué protocolos soportan ya los equipos que tienes?
- ¿Quién va a consumir los datos: un operario, un SCADA, una aplicación en la nube?
- ¿La conexión es local y estable, o remota e intermitente?
- ¿Necesitas escribir consignas o solo leer datos?
- ¿Qué exigencias de seguridad tiene la red?
¿Qué precauciones de seguridad hay que tomar?
- No expongas Modbus a internet. No tiene autenticación: abrir su puerto es dejar que cualquiera lea y escriba en tus equipos.
- Segmenta la red. Separa la red de control de la red de oficina con cortafuegos y permite solo el tráfico necesario.
- Usa la seguridad que ofrece cada protocolo. En OPC UA, activa firma y cifrado y gestiona los certificados. En MQTT, usa TLS, credenciales por dispositivo y permisos por tema en el broker.
- Saca los datos, no metas el acceso. Es preferible que una pasarela publique hacia fuera a que alguien entre desde fuera; si necesitas acceso remoto, usa una VPN.
¿Cómo evitar quedar atado a un fabricante?
Los tres protocolos son abiertos, pero eso no garantiza nada si los datos acaban en un formato propietario. Exige que la arquitectura use estándares documentados, que el mapa de variables y la estructura de temas estén por escrito y que los datos sean tuyos y exportables. Así podrás cambiar de SCADA, de nube o de integrador sin rehacer la planta.
¿Cómo lo abordamos en Kinetifab?
Trabajamos solo con protocolos abiertos (Modbus, OPC UA y MQTT) y diseñamos los sistemas para que el control funcione en local, sin depender de internet. Antes de proponer una arquitectura revisamos qué tienes y qué necesitas medir, y la documentación queda en tus manos. Más detalle en automatización industrial o, si quieres comentar tu caso, en contacto.