Hay una paradoja bastante evidente en la situación actual de las empresas industriales. Por un lado, los sensores, los autómatas y los equipos conectados generan volúmenes de datos como nunca antes. Por otro, según estudios de Forrester citados en diversos análisis del sector, alrededor del 70 % de esos datos recopilados sigue sin aprovecharse. No porque no tenga valor, sino porque, sencillamente, no llega a donde debería.
El problema no es, por tanto, la generación de datos, sino su circulación. Y es aquí precisamente donde entra en juego la gestión de los flujos de datos industriales: no como una capa técnica secundaria, sino como la infraestructura central que permite la toma de decisiones en tiempo real.
Antes de entrar en las arquitecturas y los protocolos, conviene entender por qué este problema persiste, a pesar de que la industria lleva décadas utilizando herramientas de supervisión y control.
La respuesta se resume en una palabra: los silos. Históricamente, los entornos industriales se han diseñado para priorizar el rendimiento y la robustez, no la interoperabilidad. Un autómata Siemens de hace veinte años no estaba pensado para comunicarse con un ERP SAP. Del mismo modo, un sistema SCADA de una planta química no se diseñó para enviar datos a un data lake en la nube. Estos sistemas funcionaban en circuitos cerrados, y era una decisión consciente: menos conexiones significaban menos riesgos de fallo o de intrusión.
Hoy, esa lógica choca de frente con las exigencias de la industria conectada. Los equipos de producción necesitan indicadores en tiempo real, las direcciones quieren consolidar la información de múltiples plantas y los equipos de mantenimiento buscan anticipar anomalías antes de que provoquen una parada. Todo esto exige que los datos circulen, desde el sensor hasta la aplicación que los utiliza, de forma fiable, coherente y segura.
Según el Observatorio IT/OT 2024, realizado por NXO y Cisco entre 135 responsables industriales, el 64 % de los encuestados señala la circulación de los datos como la principal prioridad en sus programas de convergencia entre redes informáticas y redes de producción. Sin embargo, en el momento del estudio, solo el 11 % de las empresas había completado dicha convergencia, aunque un 44 % ya la había iniciado. El proceso está en marcha, pero aún queda camino por recorrer.
Para hacer circular un dato desde un sensor de presión hasta un sistema de supervisión o un pipeline en la nube, primero hay que ponerse de acuerdo sobre el “idioma” que se va a utilizar. Ese es el papel de los protocolos de comunicación industriales, y el panorama está mucho menos unificado de lo que podría parecer.
Diseñado en 1979 por Modicon, Modbus es probablemente el protocolo más extendido en las plantas industriales. Funciona según un modelo maestro-esclavo sencillo: un controlador interroga a un equipo, que responde con sus datos. Su versión TCP/IP (Modbus TCP) le permitió adaptarse a la era Ethernet. Su principal fortaleza es su simplicidad y su universalidad: prácticamente cualquier equipo industrial lo soporta.
Sin embargo, Modbus fue concebido para otro contexto. No gestiona la seguridad de forma nativa, no ofrece un modelo de datos estandarizado y su arquitectura de sondeo (el maestro debe interrogar a cada esclavo) se convierte en un cuello de botella cuando aumenta el número de dispositivos. Sigue siendo imprescindible en los parques de máquinas existentes, pero no está pensado para alimentar flujos de datos en tiempo real hacia la nube.
OPC-UA (Open Platform Communications Unified Architecture) es otra cosa. Desarrollado por la OPC Foundation, se basa en un modelo de objetos jerárquico. Permite describir los valores de las variables (temperatura, presión, caudal), pero también su contexto semántico: a qué equipo pertenecen, sus unidades y sus rangos normales de funcionamiento.
Esta riqueza semántica es lo que diferencia a OPC-UA de Modbus. No transporta solo números en bruto, sino información estructurada e interpretable.
OPC-UA también soporta el modo publish/subscribe (Pub/Sub), que elimina el modelo maestro-esclavo: los equipos publican sus datos en cuanto cambian, y los suscriptores los reciben sin necesidad de solicitarlos. Es un cambio arquitectónico importante, sobre todo para aplicaciones en tiempo real. Su seguridad nativa (cifrado, autenticación, firma de mensajes) lo convierte además en una opción sólida para entornos regulados como los afectados por la directiva NIS 2.
El inconveniente es su complejidad de implementación. Establecer una sesión OPC-UA entre dos equipos implica varios intercambios previos (handshake, negociación de seguridad, establecimiento de sesión), lo que genera una sobrecarga mayor que Modbus o MQTT. En redes de baja capacidad o en dispositivos con recursos limitados, este coste puede ser un factor limitante.
MQTT (Message Queuing Telemetry Transport) tiene otro origen: fue diseñado para entornos con recursos limitados, redes inestables y conexiones intermitentes. Su protocolo binario es extremadamente ligero, su sobrecarga de conexión mínima y su modelo publish/subscribe basado en un broker central lo hace especialmente adecuado para arquitecturas distribuidas donde muchos equipos publican datos hacia un punto único de recogida.
En un despliegue típico, las pasarelas industriales o los autómatas publican sus mediciones en topics MQTT (por ejemplo, planta/línea3/prensa/temperatura). Un broker, a menudo una instancia de Eclipse Mosquitto o EMQX, recibe estos mensajes y los redistribuye a las aplicaciones suscritas: sistemas de supervisión, pipelines de datos o herramientas de mantenimiento predictivo. En caso de corte de red, MQTT puede almacenar los mensajes en cola y reenviarlos al restablecerse la conexión, lo que reduce el riesgo de pérdida de datos.
La limitación de MQTT es la ausencia de modelado semántico nativo. Un mensaje MQTT transporta un valor asociado a un topic, pero el protocolo no define qué significa ese valor, a qué sensor corresponde ni en qué unidad se expresa. Por eso la industria ha desarrollado capas adicionales como Sparkplug B, una especificación que define un formato de payload estandarizado sobre MQTT para aportar la semántica que le falta.
En la práctica, OPC-UA y MQTT no compiten entre sí, sino que se complementan. OPC-UA suele utilizarse dentro de la red local de la planta, donde la riqueza semántica y la seguridad son prioritarias. MQTT se encarga del tránsito hacia la nube o hacia sistemas remotos, donde priman la ligereza y la resistencia a las interrupciones.
Comprender los protocolos no es suficiente si no se tiene en mente la arquitectura global en la que se inscriben. Un flujo de datos industrial moderno suele atravesar tres capas claramente diferenciadas.
Aquí es donde todo comienza. Sensores de temperatura, vibración, presión, caudal o corriente generan señales analógicas o digitales. Estas señales son captadas por equipos de control como autómatas programables (PLC), unidades de adquisición o sistemas DCS en procesos continuos, que las exponen mediante los protocolos mencionados anteriormente.
Una línea de producción bien equipada puede generar varios miles de puntos de medida, con frecuencias que van desde unos pocos milisegundos hasta varios segundos. Enviar todo sin procesar a la nube sería técnicamente posible, pero económicamente absurdo y, en muchos casos, innecesario: muestrear a 10 Hz una temperatura que evoluciona lentamente genera ruido, no información útil.
Aquí se toman muchas de las decisiones clave. Una pasarela edge industrial, a menudo un PC industrial reforzado o un dispositivo dedicado (como las gamas Siemens SIMATIC, Moxa o soluciones de Advantech), asume varias funciones críticas de forma local.
En primer lugar, la normalización de protocolos: puede ingerir datos procedentes de Modbus RTU, Profinet, OPC-UA o incluso sensores 4-20 mA, y convertirlos en un formato unificado antes de enviarlos hacia arriba. Es lo que se conoce como una pasarela de protocolos. A esto se suma el filtrado y la reducción de datos: en lugar de transmitir todos los valores en cada ciclo, la pasarela puede enviar únicamente variaciones significativas (change of value, CoV), agregados por ventanas temporales o alertas activadas por umbrales. Esto reduce de forma considerable el volumen de datos transmitidos.
Por último, y cada vez con más frecuencia, la capa edge incorpora lógica de procesamiento local: reglas de detección de anomalías, preprocesamiento de datos e incluso modelos ligeros de machine learning que pueden ejecutarse en arquitecturas ARM o x86 embebidas, utilizando frameworks como TensorFlow Lite u OpenVINO. Esta capacidad de procesamiento en el borde permite tiempos de respuesta del orden de milisegundos, sin depender de la disponibilidad de un entorno cloud remoto.
Una vez que los datos han sido normalizados y filtrados en el edge, pasan a la capa de integración. Aquí entran en juego los pipelines de datos y los brokers de mensajería.
Herramientas open source como Apache Kafka se utilizan para construir pipelines robustos y escalables, capaces de gestionar flujos en tiempo real con alta disponibilidad y tolerancia a fallos. En una arquitectura industrial típica, Kafka actúa como un bus de mensajes central: las pasarelas edge publican sus datos en topics, y las aplicaciones consumidoras (ERP, herramientas de mantenimiento, data lakes o sistemas de supervisión) se suscriben a los flujos que les interesan. Apache Flink o Spark Streaming permiten realizar tratamientos en tiempo real, como agregación, filtrado o enriquecimiento de los datos.
En instalaciones de menor tamaño, herramientas de orquestación como Apache NiFi ofrecen una alternativa visual para diseñar flujos de datos entre fuentes y destinos, con gestión integrada de errores, enrutamiento condicional y cifrado de las comunicaciones.
Uno de los aspectos más infravalorados en esta etapa es la gobernanza del esquema de datos. Cuando una pasarela envía una medición de temperatura, el sistema receptor debe saber que se trata efectivamente de una temperatura, expresada en grados Celsius y asociada a un equipo concreto de una línea específica. Sin un registro de metadatos (a menudo llamado schema registry en el ecosistema Kafka o Confluent), los pipelines se convierten en cajas negras difíciles de mantener.
La ausencia de metadatos impide comprender el origen o el significado de los datos, mientras que la falta de trazabilidad (lineage) complica la identificación de problemas en caso de error. Es exactamente lo que se conoce como un “data swamp”, un lago de datos donde ya nadie sabe qué contiene qué.
La teoría de las arquitecturas por capas resulta muy atractiva sobre el papel. La realidad de los proyectos suele ser bastante más compleja.
En la práctica totalidad de las fábricas, los equipos conviven entre varias generaciones tecnológicas. Un taller puede mezclar autómatas de los años 90 que siguen funcionando perfectamente, variadores instalados en 2012 y sensores IoT desplegados en 2023. Estos equipos antiguos a veces solo soportan Modbus RTU sobre RS-485, sin ninguna capacidad de conexión Ethernet. Integrarlos en una arquitectura de flujos moderna requiere convertidores de protocolos, pasarelas intermedias y, en ocasiones, soluciones ingeniosas, casi nunca con el presupuesto previsto.
¿Quién es responsable de los datos que genera una línea de producción? ¿El equipo de mantenimiento que gestiona los autómatas? ¿La DSI que administra la red? ¿Los equipos de métodos que utilizan los datos para controlar la calidad? En la mayoría de las plantas, esta pregunta no tiene una respuesta clara. Como resultado, nadie documenta el modelo de datos, nadie valida de forma sistemática la calidad de las mediciones, y los proyectos avanzan a base de capas sucesivas de correcciones.
La apertura de las redes OT hacia el entorno IT multiplica las superficies de ataque. Modbus, en particular, no dispone de mecanismos de autenticación ni de cifrado: cualquier equipo conectado a la red puede enviar comandos a un autómata Modbus si la segmentación de red no es la adecuada. La directiva NIS 2 obliga ahora a muchas empresas industriales a abordar este problema con seriedad y a documentar su arquitectura de flujos de datos para poder evaluar los riesgos.
Un pipeline de datos sofisticado no puede compensar sensores mal calibrados, mediciones con marcas de tiempo incorrectas o variables cuya definición no está documentada. Sin embargo, en muchos centros industriales, la calidad de los datos en la capa de campo nunca ha sido auditada. Se observan desviaciones de sensores no detectadas, valores atípicos que contaminan los históricos o etiquetas Modbus mal nombradas que impiden identificar con claridad qué están midiendo. Corregir estos problemas en origen suele ser la tarea más ingrata, pero también la más rentable.
Frente a estos obstáculos, existen algunos principios estructurales que marcan la diferencia entre los proyectos que llegan a buen puerto y los que se alargan indefinidamente.
Mapear antes de conectar
Antes de instalar la más mínima pasarela, es fundamental saber qué equipos existen, qué protocolos soportan, qué variables exponen y con qué frecuencia. Este mapeo, a menudo realizado con herramientas de descubrimiento de redes industriales, constituye la base sobre la que se apoya todo lo demás.
Priorizar protocolos abiertos y estandarizados siempre que sea posible
Cuando se adquiere un nuevo equipo, exigir compatibilidad con OPC-UA en los pliegos técnicos es una inversión mínima con un retorno enorme en flexibilidad a largo plazo. Para los equipos ya existentes, una pasarela de protocolos (por ejemplo, de Modbus a MQTT u OPC-UA) suele ser suficiente para integrarlos sin necesidad de sustituirlos.
Tratar la gobernanza del dato como un proyecto en sí mismo
Definir las convenciones de nomenclatura de los topics MQTT o de los nodos OPC-UA, mantener un registro de metadatos, documentar las unidades y los rangos normales de funcionamiento: estas tareas pueden parecer administrativas, pero condicionan directamente la mantenibilidad de los pipelines a lo largo de los años.
Segmentar las redes OT e IT mediante pasarelas controladas
Una DMZ industrial, es decir, una zona desmilitarizada entre la red de producción y la red informática, permite hacer circular los datos al tiempo que limita los riesgos. Los datos se transfieren desde OT hacia IT mediante pasarelas unidireccionales o reglas de filtrado estrictas, sin que la red informática tenga acceso directo a los autómatas.
Empezar pequeño, documentar todo, replicar
Los proyectos que funcionan suelen empezar con un perímetro limitado: una línea, un taller o un tipo de equipo, con una arquitectura bien documentada. Es mucho más fácil industrializar este enfoque después que intentar conectar todo desde el principio y acabar desbordado por la complejidad.
Fuentes:
Observatorio IT/OT 2024, NXO & Cisco (135 encuestados); Forrester Research, tasa de infrautilización de datos industriales; Linux Embedded, arquitecturas edge y pipelines industriales (2025); OPC Foundation, especificaciones OPC-UA.
Copyright © 2026. MOTILDE. All rights reserved.