Cómo escalar un sistema Scada con MQTT (no cometas errores)
Rubén Palomino
Artículo actualizado en marzo de 2026.
Escalar un sistema Scada en entornos industriales no es una tarea fácil. Para fijar un punto de partida hay que hacerse esta pregunta
¿Cómo llega un Scada a una empresa?
La respuesta a esta pregunta es casi siempre la misma.
- Por un problema existente
- Por una mejora en la producción
Una vez el Scada está funcionando, empiezan a surgir nuevas ideas, nuevas necesidades y nuevas oportunidades. Lo que antes no se planteaba, ahora parece imprescindible. Nuevas señales, nuevas líneas, nuevas plantas… y el sistema empieza a crecer.
Otro factor a tener en cuenta es el crecimiento de las instalaciones o de las empresas, a medida que aumentan los dispositivos, las plantas o los puntos de control, muchas arquitecturas tradicionales comienzan a mostrar sus limitaciones.
El problema no suele estar en el software en sí, sino en el modelo de comunicación utilizado.
Un sistema Scada industrial debe estar preparado para crecer sin comprometer el rendimiento.
En la mayoría de los sistemas Scada clásicos se emplea una arquitectura cliente-servidor directa, donde cada PLC, sensor o dispositivo establece una conexión individual con el servidor central.
Esto implica que:
- Cada dispositivo supone una nueva conexión
- El servidor debe gestionar todas las comunicaciones
- El crecimiento del sistema impacta directamente en el rendimiento
El resultado es bien conocido en entornos industriales:
- Cuellos de botella en el servidor
- Aumento de latencias
- Sistemas difíciles de mantener y escalar
- Arquitecturas rígidas y poco flexibles
A partir de cierto tamaño, el Scada deja de escalar de forma eficiente y se convierte en el principal limitante del sistema.
- Diferencias entre sistemas deterministas y no deterministas en Scada
- Cómo escalar un sistema Scada utilizando MQTT
Diferencias entre sistemas deterministas y no deterministas en Scada
Antes de sobre de cómo funciona MQTT hay que sentar las bases del determinismo de las comunicaciones industriales.
SISTEMAS DETERMINISTAS
Estos sistemas se basan en una comunicación en la que el tiempo de respuesta está controlado. Se conoce cuando se envía un dato, y si no hay error cuando se va a recibir.
A nivel de control (PLC, buses de campo, tiempo real…), es la forma de comunicación adecuada. Se garantiza el tiempo de lectura y respuesta de cada memoria o punto de información.
Pero cuando lo llevamos al nivel de un sistema Scada, empiezan a aparecer problemas.
Cuando se trata de leer pocos puntos o tags un Scada pueden dar la sensación de comportarse como un sistema determinista. Pero no lo es, aunque lo parezcan.
Esto se debe a que los sistemas de comunicación que utilizan los Scadas están en su mayoría basados en un sistema tipo polling (o dicho de una forma más común maestro/esclavo o cliente/servidor).
Un sistema central (el Scada ), solicita información a los diferentes servidores o esclavos y estos devuelven la información según se va solicitando.
¿Cómo se comportan estos sistemas cuando aumentan los dispositivos o los puntos de información?
Como el tipo polling es de tipo sondeo, un aumento de dispositivos o tags a leer implica más tiempo en realizar el sondeo de todos ellos.
En resumen, aumenta el número de consultas y por lo tanto el ciclo de muestreo
SISTEMAS NO DETERMINISTAS
Como alternativa a los sistemas deterministas están los sistemas no deterministas, en estos el tiempo de ciclo o muestreo no condiciona las comunicaciones. Estas están condicionadas por los eventos que se producen en el sistema al cual está conectado el Scada.
Gracias a esto:
- No es necesario preguntar todo el tiempo.
- Solo se envía la información cuando hay cambios.
- Disminuye el uso de CPU.
- Se libera mucho ancho de banda.
Y es en este punto donde tecnologías como MQTT encajan perfectamente, permitiendo escalar un sistema Scada de forma eficiente, flexible y sin aumentar la complejidad del sistema.
Un sistema Scada industrial debe poder trabajar con todo tipo de redes OT e IT.
Cómo escalar un sistema Scada utilizando MQTT
Para entender por qué MQTT permite escalar un sistema Scada, hay que entender primero cómo funciona su arquitectura.
Al no ser un sistema polling el Scada se libera de la tarea de preguntar de forma reiterada a los dispositivos. Esto permite liberar recursos del Scada para otras tareas como pueden ser alarmas, registros de datos o atender a las peticiones API REST
MQTT no utiliza el modelo clásico de comunicación basado en consultas (polling), sino un modelo completamente diferente llamado publish/subscribe.
Este cambio es mucho más importante de lo que parece.
En una arquitectura publish/subscribe intervienen tres elementos principales:
- Publicadores: dispositivos que envían información (PLCs, sensores, gateways…). Estos dispositivos son los encargados de mandar la información al Scada solo cuando ha ocurrido un evento o cambio en los valores del sensor
- Suscriptores: sistemas que consumen esa información (Scada, dashboards, APIs…). Para explicarlo de una manera clara, son los sistemas que utilizan la información de esos sensores.
- Broker: un intermediario que recibe los datos y los distribuye. En toda comunicación debe existir un elemento que sea el intermediario entre los dispositivos que emiten información y los que reciben esa información.
El Scada puede tomar el rol de cualquiera de ellos.
El Scada como publicador o emisor
Cuando el Scada está tomando datos de forma tradicional, es decir conectado a varios PLC de planta, se convierte en un almacén de variables o tags intermedio. Podríamos decir que el Scada es un concentrador de información.
Posteriormente el Scada publica los cambios en estas variables a un Broker MQTT superior que distribuye a los sistemas IT de la empresa.
Un sistema Scada industrial no solo toma datos sino que tiene que poder publicarlos a posibles suscriptores.
Pone a disposición de la red la información de planta
El Scada como suscriptor
El Scada se suscribe a un Broker MQTT (intermediario de información) y solicita que se le notifiquen solo aquellos valores necesarios para la operación.
Esto permite intercambio de información entre sistemas diferentes de la empresa, sin saturar las comunicaciones.
Al Scada no le llega toda la información, solo la necesaria.
Un sistema Scada tiene que tener la capacidad de recibir información desde la planta o los sistemas de información.
El Scada como broker
En algunos casos, el propio Scada puede actuar como broker, centralizando la comunicación entre dispositivos y sistemas externos.
Cuando el Scada actúa como broker recibe los datos de las redes OT que publican los dispositivos, y a su vez pone a disposición de las redes IT esa información a los clientes que se quieran suscribir.
Incluso puede actuar como broker de datos tomados en planta de forma tradicional tipo MODBUS.
El Scada reparte el juego entre las redes OT y las de IT
Ejemplo real de uso de un sistema Scada
En una línea de producción que está compuesta por varios puestos donde se realizan diferentes procesos, la información del plc que controla dicha línea normalmente está estructurada en memorias.
Y cada memoria almacena la referencia de la orden de fabricación o pedido que está en ese puesto.
El Scada al estar conectado al PLC (ya sea MODBUS, FINS, STEP7, etc) tiene la información de cada puesto estructurada en topics(Un topic es una ruta o nombre que define cada memoria de almacenamiento dentro de un broker MQTT).
Si el personal de producción quiere saber el estado de los pedidos dentro de la linea, solo tiene que suscribirse a través de un cliente al Scada. Y es el Scada actuando como broker MQTT el que mantendrá informado al cliente de que referencias están dentro de la linea.
La forma de publicar mediante topics sigue este formato.
| TOPIC (publicado) | VALOR |
|---|---|
| línea1/puesto1/ref | 1254855 |
| línea1/puesto2/ref | 1254087 |
| línea1/puesto3/ref | - |
| línea1/puesto4/ref | 2586846 |
| línea1/puesto5/ref | 2526646 |
| línea1/puesto6/ref | - |
| línea1/puesto7/ref | 2566896 |
Cuando el Scada adopta el modelo MQTT en cualquiera de sus funciones, deja de ser el cuello de botella, pasando a ser el elemento que hace posible la escalabilidad del sistema.
Un Scada bien implementado separa completamente las redes OT y las redes IT, permitiendo únicamente el flujo de información necesaria entre ellas, sin comprometer ni la seguridad ni el rendimiento.
A TENER EN CUENTA
Escalar un sistema Scada no consiste en añadir más conexiones o más dispositivos, en muchas ocasiones hay que cambiar la forma en la que fluye la información en el sistema.
Escalar no implica complicar
El uso de arquitecturas basadas en MQTT permite pasar de modelos rígidos y difíciles de mantener (como la lectura MODBUS) a sistemas flexibles, desacoplados y preparados para crecer sin comprometer el rendimiento y sin manipular dispositivos que ya funcionan correctamente.
Este enfoque es especialmente importante en entornos industriales, donde muchas instalaciones han evolucionado con el tiempo y requieren soluciones que se adapten a ese crecimiento.
En SPGN, como empresa especializada en el desarrollo de sistemas Scada, tenemos experiencia en el diseño de arquitecturas escalables que permiten integrar nuevas instalaciones, dispositivos y sistemas sin generar cuellos de botella.
Por este motivo, el Scada SPGN incorpora de forma nativa un cliente MQTT que permite tanto publicar como suscribirse a topics, así como un broker MQTT integrado que facilita la conexión de otros sistemas o dispositivos que necesiten intercambiar información.
Esto permite que el Scada no solo actúe como sistema de supervisión, sino también como un elemento central dentro de la arquitectura de comunicaciones, facilitando la integración entre redes OT e IT.
Si cuando quieres ampliar una casa llamas a un albañil…
¿por qué para desarrollar un sistema Scada se recurre a una empresa de PLC?
Si no tienes clara la respuesta, probablemente estés en el punto adecuado para replantear tu sistema.
* Tus datos se usarán únicamente para responder a tu consulta. No se comparten con terceros.