Cómo llevar datos Modbus a la nube: gateway edge, MQTT y buffering

Llevar datos Modbus a la nube es probablemente el proyecto de conectividad más repetido en la industria: casi toda planta tiene variadores, contadores, analizadores de red o autómatas que hablan Modbus, y casi ninguna puede explotarlos desde fuera del armario eléctrico. La solución estándar es un gateway edge que lee Modbus TCP o RTU en la red local, convierte los registros en datos con nombre y unidad, los publica por MQTT y los retiene en un buffer local cuando la conexión falla. En esta guía recorremos esa arquitectura paso a paso.

Por qué Modbus sigue en el centro de la planta

Modbus se publicó en 1979 y sigue siendo la interfaz de facto de una parte enorme del equipamiento industrial: variadores de frecuencia, contadores de energía, analizadores de red, sondas de temperatura, reguladores y autómatas de todas las gamas. Es simple, está libre de regalías y todo fabricante lo implementa, y por eso no va a desaparecer: la pregunta práctica no es cómo sustituirlo, sino cómo sacar su dato del bus local y ponerlo donde el negocio pueda usarlo.

El protocolo tiene, eso sí, tres limitaciones que condicionan todo el diseño: los datos son registros numerados sin nombre ni unidad, la comunicación es de sondeo (un maestro pregunta, un esclavo responde, nadie avisa de cambios) y no existe cifrado ni autenticación. Ninguna de las tres es un problema dentro del armario; las tres lo son en cuanto el dato quiere viajar.

Modbus TCP vs Modbus RTU: qué tienes instalado

Antes de diseñar nada conviene saber cuál de las dos variantes convive en la planta, porque cambia el cableado pero no la arquitectura:

Modbus RTU viaja por un par serie RS-485: un bus cableado multipunto, robusto y barato, habitual en contadores y equipos de armario. Cada bus admite un solo maestro, lo que significa que si el SCADA ya sondea ese bus, el gateway no puede preguntar a la vez por el mismo par de hilos: se conecta como segundo puerto del equipo, se integra aguas arriba del SCADA o se lee a través de una pasarela serie.
Modbus TCP encapsula el mismo protocolo sobre Ethernet e IP. Admite varios clientes simultáneos contra un mismo equipo, con lo que el gateway puede sondear sin molestar a lo que ya existe. Es el caso fácil y cada vez más común.

En la práctica, casi todos los proyectos son mixtos: TCP para lo reciente, RTU para el parque instalado. Un gateway que hable las dos variantes evita pasarelas intermedias y unifica la configuración; el criterio general de selección de un sistema de captura está en el pilar del sistema de adquisición de datos industrial.

Por qué Modbus no puede ir directo a la nube

La tentación inicial es abrir un puerto y consultar el equipo desde fuera. Es mala idea por las tres limitaciones de antes, ahora amplificadas:

Seguridad. Modbus no autentica ni cifra: exponer un equipo Modbus a Internet es dar acceso de lectura y escritura a quien encuentre el puerto. La red OT debe permanecer cerrada; el dato sale, las conexiones entrantes no entran.
Semántica. En la nube, "registro 40012 = 4523" no significa nada. El significado (qué señal es, con qué escala, en qué unidad) vive en la documentación del fabricante, y alguien tiene que aplicarlo cerca del equipo, una vez, antes de publicar.
Fiabilidad. El sondeo Modbus necesita una conexión estable y de baja latencia con el equipo. Una WAN con cortes no la ofrece: el sondeo debe ocurrir en la red local y el tramo hacia la nube debe tolerar interrupciones sin perder datos.

Las tres objeciones apuntan a la misma solución: un intermediario en planta que sondee en local y publique hacia fuera.

La arquitectura: un gateway edge en medio

El patrón establecido es un gateway edge: un equipo industrial en la red de planta que actúa de cliente Modbus hacia abajo y de publicador seguro hacia arriba. Sus responsabilidades, en orden:

Sondear cada equipo Modbus al intervalo configurado, por TCP o por RTU, agrupando lecturas para no saturar buses lentos.
Mapear y escalar: convertir cada registro en una señal con nombre de negocio, tipo de dato, factor de escala y unidad.
Marcar el tiempo en el momento de la captura, para que el histórico no dependa de la latencia del tramo hacia la nube.
Publicar hacia arriba con una conexión saliente y cifrada, normalmente por MQTT.
Retener en un buffer local persistente todo lo que no se haya podido entregar todavía.

Con este diseño, la red OT no expone ningún puerto entrante: el gateway origina una única conexión saliente cifrada. Ese planteamiento de seguridad se desarrolla en la guía de zero trust en OT industrial.

De registros Modbus a mensajes MQTT

Para el tramo hacia la nube, el transporte habitual es MQTT: un protocolo de publicación y suscripción ligero, diseñado para redes imperfectas, en el que el gateway publica cada señal en un topic y cualquier consumidor autorizado se suscribe sin tocar la planta. El contraste con la alternativa se analiza en OPC UA vs MQTT; para el caso Modbus, MQTT aporta exactamente lo que falta:

Del sondeo al evento. El gateway sondea en local, pero hacia arriba puede publicar solo cambios de valor: menos tráfico y datos más expresivos.
Semántica en el mensaje. El topic y el payload llevan nombre, unidad y marca de tiempo: el consumidor no necesita conocer mapas de registros de ningún fabricante.
Desacoplamiento. Añadir un consumidor nuevo (dashboard, historiador, modelo de análisis) es una suscripción, no otra integración contra el equipo.
Entrega con garantías. Los niveles de QoS y las sesiones persistentes del protocolo cubren las microcortes; el buffer local cubre los cortes largos.

La pieza que conecta esa publicación con los sistemas de arriba es la integración MQTT, y el árbol de topics compartido es el fundamento del unified namespace.

Buffering: qué pasa cuando se corta la red

La diferencia entre una instalación seria y una demo se ve el día que la WAN cae durante horas. Sin buffer, ese periodo desaparece del histórico y con él cualquier cálculo que lo necesite: consumos por turno, paradas, trazabilidad. Con un buffer local persistente, el gateway sigue sondeando durante el corte, escribe cada lectura en su almacenamiento (que sobrevive a un reinicio) y reenvía todo en orden al recuperarse la conexión, con la marca de tiempo original de captura.

Dos decisiones de dimensionado importan: cuánta autonomía se quiere (horas o días de retención, según señales y frecuencia) y cómo se comporta el reenvío para no saturar el enlace al volver la red. El detalle técnico está en la guía de edge industrial con buffering y QoS.

Paso a paso: de los registros al dashboard

Inventaría las fuentes. Qué equipos Modbus hay, variante (TCP o RTU), dirección de esclavo, y qué documentación de mapa de registros existe de cada fabricante.
Selecciona las señales. No todos los registros valen el esfuerzo: se empieza por las señales con valor de negocio claro (consumos, estados, contadores, alarmas) y se amplía después.
Define el mapeo. Para cada señal: registro, tipo de dato, factor de escala, unidad y nombre dentro de la jerarquía de activos (planta, línea, máquina, señal). Este diccionario es el entregable más valioso del proyecto.
Despliega el gateway. En la red de planta, con acceso a los equipos por TCP o al bus RS-485, y con una única conexión saliente cifrada hacia el broker o la plataforma.
Configura sondeo y publicación. Intervalos por señal, publicación por cambio de valor donde tenga sentido y buffer local activado desde el primer día.
Valida de extremo a extremo. Compara lecturas contra el display del equipo, provoca un corte de red controlado y comprueba que el histórico queda completo tras la reconexión.
Conecta el consumo. Con el dato ya publicado y normalizado, el dashboard, el historiador o el modelo de análisis se suscriben; añadir el siguiente consumidor ya no toca la planta.

Cómo lo hace Captia Connect

Captia Connect implementa exactamente esta arquitectura como capa de adquisición de la plataforma de datos de Captia:

Modbus TCP y Modbus RTU sobre RS-485 nativos, junto a OPC UA, MQTT, OpenWebNet, IEC 870-5-102, API REST, webhooks y CSV: los proyectos mixtos se resuelven con un único sistema de captura.
Normalización en origen: el mapeo de registros a señales con nombre, escala y unidad se hace en el edge, una sola vez.
Buffering local y persistencia sin conectividad: el dato se retiene en planta durante los cortes y se reenvía al restablecerse la conexión.
Envío seguro mediante conectividad cifrada saliente y despliegue local, híbrido o cloud según la política de cada empresa.

Una vez el dato Modbus está en la plataforma, Captia.ai lo convierte en valor operativo: SCADA web, dashboards, reglas y alertas sobre las mismas señales. El conjunto de esta capa de captura es lo que en nuestro catálogo llamamos ingesta edge, y su encaje en la arquitectura completa está en el hub de plataforma de datos industriales.

Preguntas frecuentes sobre Modbus y nube

¿Puedo conectar un equipo Modbus directamente a Internet?

Técnicamente sí; en la práctica, no debe hacerse. Modbus no tiene autenticación ni cifrado, así que exponer el puerto equivale a dar acceso de lectura y escritura a cualquiera que lo encuentre. El patrón correcto es un gateway en la red local que sondea los equipos y origina una única conexión saliente cifrada hacia la nube.

¿Necesito cambiar mis variadores o contadores para llevar su dato a la nube?

No. El gateway edge lee cada equipo con el Modbus que ya habla, TCP o RTU, sin modificar su configuración ni interferir en su funcionamiento. El proyecto es de lectura: las máquinas y los buses existentes se quedan como están.

¿Se pierden datos si se corta la conexión con la nube?

Con la arquitectura correcta, no: el gateway sigue sondeando durante el corte, guarda cada lectura en un buffer local persistente con su marca de tiempo original y lo reenvía todo en orden cuando la conexión se restablece. El histórico queda completo aunque el corte dure horas o días.

¿Por qué convertir Modbus a MQTT y no consultarlo con una API?

Porque MQTT invierte el flujo a favor de la planta: el gateway publica una vez y cualquier consumidor autorizado se suscribe, sin que cada aplicación nueva tenga que sondear equipos ni conocer mapas de registros. Una API de consulta puede añadirse después como un consumidor más; el transporte base que desacopla planta y nube es la publicación.

Si tienes contadores, variadores o autómatas Modbus cuyo dato termina en el armario eléctrico, en Captia Connect montamos este recorrido completo: sondeo local, normalización, publicación segura y buffer sin pérdida de datos, integrado en la plataforma de datos industriales. El primer paso es un inventario de equipos y señales con valor.