Llevar los datos de un PLC a la nube es ya un requisito habitual: mantenimiento quiere datos de estado en remoto, la dirección quiere el OEE de todas las plantas y los equipos de datos quieren series temporales limpias para analítica. Esta guía compara las tres arquitecturas que realmente funcionan en planta (MQTT nativo en el PLC, gateways de borde y reenvío desde SCADA) y repasa las decisiones de seguridad y fiabilidad que hay detrás de cada una. Terminarás con una lista de comprobación para elegir el diseño de tu propia planta.
Por qué MQTT es el puente habitual
Los PLC hablan protocolos de campo diseñados para la comunicación local y determinista: PROFINET, EtherNet/IP, Modbus, comunicación S7, ADS. Ninguno se diseñó para atravesar internet. Las aplicaciones en la nube, en cambio, quieren flujos de eventos sobre conexiones cifradas y autenticadas que atraviesen firewalls.
MQTT encaja entre ambos mundos gracias a tres propiedades:
- Solo conexiones salientes. El lado de planta abre una conexión TLS con el broker. Nada en la nube necesita entrar en la planta, así que no se abren puertos entrantes en el firewall.
- Desacoplamiento publicación/suscripción. El lado del PLC publica una vez; dashboards, historiadores, analítica y alertas se suscriben de forma independiente. Añadir un consumidor no afecta a la planta.
- Ligero y tolerante con enlaces deficientes. Cabeceras pequeñas, keep alive, niveles de QoS, retained messages y sesiones persistentes se comportan bien en enlaces celulares o WAN congestionadas.
Si el concepto de broker es nuevo para ti, empieza por qué hace un broker MQTT antes de elegir una arquitectura.
Arquitectura 1: MQTT nativo en el PLC
El propio controlador ejecuta un cliente MQTT y se conecta al broker. Siemens ofrece una librería para S7-1200 y S7-1500, CODESYS tiene una librería de cliente MQTT y Beckhoff TwinCAT dispone de funciones IoT; encontrarás guías paso a paso en el tutorial Siemens S7 MQTT y sus artículos hermanos.
Puntos fuertes: sin hardware adicional, latencia mínima y payloads definidos por quien mejor conoce el proceso.
Puntos débiles: el código de red y de certificados pasa a vivir en el programa de control, cada cambio implica una descarga al PLC, el store-and-forward está limitado por la memoria del controlador y el PLC necesita una ruta hacia internet o hacia un broker en la DMZ, algo a lo que muchos equipos de seguridad se resisten.
Encaja cuando: un fabricante de máquinas entrega equipos conectados, o unos pocos controladores necesitan unas decenas de señales y añadir hardware no es práctico.
Arquitectura 2: gateway de borde
Un gateway en la red de control lee los PLC con sus protocolos nativos y publica MQTT hacia arriba. Puede ser un PC industrial con un servidor de conectividad comercial, un contenedor en una plataforma edge, Node-RED o un breve servicio en Python. La guía de gateways de borde IIoT trata en profundidad las opciones de hardware y software.
Puntos fuertes: los programas de PLC no se tocan, un gateway sirve a muchos controladores y marcas, el buffer en disco sobrevive a las caídas de la WAN, y el formateo de payloads, las bandas muertas y la codificación Sparkplug B se hacen en un lugar donde las herramientas de software son buenas.
Puntos débiles: un dispositivo más que parchear, monitorizar y respaldar; el gateway se convierte en un nodo crítico; y hay que habilitar la lectura con protocolos nativos en los PLC, lo que a veces debilita protecciones del lado del controlador, como tener PUT/GET desactivado.
Encaja cuando: vas a conectar una línea, una planta o una flota mixta. Es la opción por defecto en la mayoría de plantas existentes.
Arquitectura 3: reenvío desde SCADA
El servidor SCADA o HMI existente ya sondea todos los PLC. Un módulo o script MQTT en ese servidor reenvía al broker los tags seleccionados, a menudo como Sparkplug B. Ignition es un ejemplo habitual; consulta Ignition con MQTT.
Puntos fuertes: reutiliza la base de datos de tags, la configuración de alarmas y la nomenclatura existentes; no añade conexiones nuevas a los PLC; un único lugar para gestionar qué sale de la planta.
Puntos débiles: los datos en la nube pasan a depender de la disponibilidad y las licencias del SCADA; los nombres de tags del SCADA pueden no coincidir con el estándar de nomenclatura corporativo; y el servidor SCADA, normalmente un activo OT de alto valor, pasa a tener una ruta saliente hacia internet.
Encaja cuando: el SCADA ya cubre los activos que te interesan y su equipo se encarga de la integración.
Arquitecturas de PLC a la nube, lado a lado
| Criterio | MQTT nativo en el PLC | Gateway de borde | Reenvío desde SCADA |
|---|---|---|---|
| Hardware adicional | Ninguno | Gateway por planta o línea | Ninguno |
| Cambios en el programa del PLC | Sí | No | No |
| PLC de varios fabricantes | Una implementación por fabricante | Sí, mediante drivers | Sí, si el SCADA los admite |
| Store-and-forward | Limitado | Robusto (buffer en disco) | Depende del módulo |
| Flexibilidad del payload | Limitada por el manejo de strings del PLC | Alta | Media a alta |
| Gestión de cambios | Descarga al PLC | Despliegue de la configuración del gateway | Cambio en el proyecto SCADA |
| Riesgo de dependencia | Ruta de red de cada PLC | Disponibilidad del gateway | Disponibilidad del SCADA |
| Responsable típico | Ingeniero de control | Equipo OT o IT/OT | Equipo SCADA |
Muchas plantas acaban combinándolas: los fabricantes de máquinas entregan equipos con conexión nativa, las líneas antiguas pasan por gateways y el SCADA reenvía sus resúmenes de alarmas y producción.
Patrones de seguridad para PLC a la nube
La seguridad es donde estos proyectos triunfan o se atascan. Los patrones siguientes se aplican sea cual sea la arquitectura.
- Solo salientes. Los dispositivos de planta inician las conexiones TLS hacia el broker. Nada de redirección de puertos entrantes ni de VPN hacia las redes de controladores para recoger datos.
- Segmenta por niveles. Mantén los PLC en la zona de control. Sitúa los gateways en la frontera o en una DMZ industrial y permite que solo el gateway alcance el broker. El patrón MQTT en una DMZ explica dónde colocar el broker entre OT e IT.
- TLS en todas partes fuera de la célula. Usa el puerto 8883 con validación de certificados; nunca desactives la verificación para que una conexión funcione.
- Una identidad por publicador. Cada PLC o gateway recibe su propio usuario, contraseña y client ID, de modo que un dispositivo comprometido pueda revocarse sin tocar los demás.
- Solo lectura por defecto. Trata las escrituras de la nube al PLC como un proyecto aparte, con listas de permitidos, comprobaciones de rango, enclavamientos en el PLC y un registro de auditoría.
- Mantén los secretos fuera de los proyectos. No guardes contraseñas del broker en proyectos de PLC ni en repositorios de gateways compartidos entre equipos.
- Vigila los abusos. Usa un broker que limite las avalanchas de mensajes y bloquee los inicios de sesión fallidos repetidos, y genera una alerta cuando desaparezca un publicador esperado.
ConnectMQ, por ejemplo, aplica en todos los brokers cuotas por plan, protección contra avalanchas de mensajes y bloqueo de IP tras inicios de sesión fallidos repetidos, de modo que estas protecciones no dependen de que cada planta acierte con su propia configuración.
Fiabilidad y calidad de los datos
Una conexión que funciona en una demo no es lo mismo que una que entrega datos fiables durante años. Comprueba esto antes de la puesta en producción:
- Report by exception con latidos. Publica ante cambios significativos y con un refresco periódico, para que los valores inactivos se distingan de los enlaces caídos.
- Last Will y estado retained. Un estado
onlineuofflineretained por publicador permite a cada consumidor saber qué está vigente. - Marcas de tiempo en origen. Pon la marca de tiempo donde se leen los valores, no donde se reciben, y mantén los relojes sincronizados con NTP.
- Buffer. Decide qué ocurre durante una caída de la WAN: descartar, almacenar en memoria o almacenar en disco y reenviar en orden.
- Nomenclatura. Acuerda una jerarquía de topics basada en ISA-95 antes de que se conecte la segunda planta. Renombrar después sale caro.
Probar la ruta de red
Antes de construir nada, demuestra que la red de planta puede llegar a un broker con TLS. Desde una máquina en la zona donde se ejecutará tu publicador:
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i plant-path-test-9x2c -t 'connectmq/demo/9x2c/path-test' -m 'hello from the plant'
Si falla con un timeout, el firewall bloquea la salida por el 8883. Si falla durante el handshake, puede que un proxy de inspección TLS esté sustituyendo los certificados, una conversación que conviene tener pronto con el equipo de redes. El servidor MQTT público gratuito es compartido y cualquiera puede leerlo, así que envía solo cadenas de prueba.
Dónde debe estar el broker
Tus opciones son un broker local, un broker que gestionas tú mismo en la nube o un broker MQTT gestionado. Los brokers locales son útiles para consumidores locales y diseños con DMZ; para datos a nivel de toda la empresa, un broker en la nube accesible desde todas las plantas, por ejemplo en Monterrey, Querétaro y Bogotá, es más sencillo. ConnectMQ lo ofrece como servicio gestionado con MQTT 3.1.1 y 5.0, TLS en el 8883 y opciones que van desde planes Serverless compartidos hasta clústeres Dedicated y despliegues BYOC en tu propia cuenta cloud. La vista de dispositivos del portal entiende los topics ISA-95 y Sparkplug B, de modo que los datos de clientes PLC nativos, gateways y SCADA llegan a una única jerarquía navegable. Esa misma jerarquía puede alimentar después un gemelo digital 3D de cada planta sin abrir nuevas conexiones hacia los PLC.
Lista de comprobación para decidir
- ¿Cuántos PLC, y de cuántos fabricantes, entran en el alcance este año?
- ¿Se pueden modificar y descargar los programas de PLC, y quién lo aprueba?
- ¿El SCADA ya sondea los activos que necesitas?
- ¿Qué latencia de datos se requiere: segundos, minutos u horas?
- ¿Qué pasa con los datos durante una caída de la WAN, y durante cuánto tiempo?
- ¿Qué zona puede iniciar conexiones salientes, y por qué puertos?
- ¿Quién se encargará del parcheado, los certificados y la monitorización del gateway?
- ¿Se necesita alguna ruta de escritura de la nube al PLC, y se ha evaluado su riesgo?
Si las respuestas apuntan a muchos fabricantes, ningún cambio en los PLC y caídas largas, empieza con un gateway de borde. Para la arquitectura de extremo a extremo, continúa con la guía de IoT industrial con MQTT.
Empieza tu proyecto de PLC a la nube con ConnectMQ
Elijas la arquitectura que elijas, necesita un broker MQTT en la nube fiable al otro lado. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y conecta hoy mismo tu primer PLC o gateway con TLS.
Preguntas frecuentes
¿Cuál es la forma más segura de conectar un PLC a la nube?
Mantén el PLC en su zona de control, deja que un gateway o un broker en la DMZ haga solo conexiones TLS salientes, da a cada publicador sus propias credenciales y mantén la ruta de datos en solo lectura.
¿Necesito un gateway de borde para llevar un PLC a la nube?
No siempre. Algunos PLC pueden publicar MQTT de forma nativa, pero los gateways suelen ser preferibles para flotas de varios fabricantes, para almacenar datos durante las caídas y para no modificar los programas de PLC.
¿Es mejor OPC UA o MQTT para llevar un PLC a la nube?
OPC UA destaca en el acceso local y estructurado a los datos del PLC, mientras que MQTT es mejor para distribuir eventos a muchos consumidores en la nube. Muchas arquitecturas leen vía OPC UA en el borde y publican vía MQTT.
¿Deben enviarse los datos del PLC a la nube en tiempo real?
La mayoría de casos de uso en la nube necesitan segundos o minutos, no milisegundos. Mantén el control en lazo cerrado en local y envía hacia arriba datos con report by exception.
