La convergencia IT/OT es el proceso de llevar la tecnología de la información (sistemas de negocio, cloud, analítica) y la tecnología operacional (PLC, SCADA, máquinas) a una base común para que ambas trabajen con los mismos datos. En este artículo verás por qué los dos mundos evolucionaron de forma tan distinta, qué tiene que cambiar realmente en el plano técnico y cultural, y cómo un namespace MQTT compartido ofrece a los equipos de IT y OT una única vista en vivo de la planta sin comprometer las prioridades de ninguno de los dos.
Dos mundos que crecieron por separado
La tecnología operacional nació en la planta. Su misión es mantener un proceso físico funcionando de forma segura, cada segundo, durante décadas. Un PLC que controla un horno puede ejecutar el mismo programa durante quince años, y eso se considera un éxito. El cambio es un riesgo, y una parada puede dañar equipos o herir a personas.
La tecnología de la información nació en la oficina. Su misión es procesar información de negocio de forma segura y eficiente. Los sistemas se parchean cada mes, se sustituyen cada pocos años y una caída es cara, pero rara vez peligrosa. El cambio es lo normal, y mantenerse actualizado forma parte de la seguridad.
Ninguna de las dos visiones es errónea. Están optimizadas para consecuencias de fallo diferentes. La mayor parte de la fricción en los proyectos de convergencia surge cuando alguien aplica las reglas de un mundo al otro.
| Dimensión | Prioridades de IT | Prioridades de OT |
|---|---|---|
| Preocupación principal | Confidencialidad de los datos | Disponibilidad y seguridad del proceso |
| Ciclo de vida típico | De 3 a 5 años | De 15 a 30 años |
| Parcheo | Regular, a menudo automatizado | Poco frecuente, planificado en torno a paradas |
| Protocolos | HTTP, SQL, REST, API cloud | Modbus, Profinet, OPC UA, protocolos propietarios |
| Forma de los datos | Transacciones, documentos, registros | Señales continuas, estados, eventos |
| Tolerancia a paradas | Ventanas de mantenimiento planificadas | Se mide en producción perdida por minuto |
| Quién hace los cambios | Administradores de IT, DevOps | Ingenieros de control, integradores |
Qué significa realmente la convergencia IT/OT
La convergencia suele malinterpretarse como "meter los PLC en la red corporativa". Esa es la versión que pone nerviosos a los ingenieros de OT, y con razón. Bien hecha, la convergencia IT/OT significa tres cosas más concretas:
- Datos compartidos. Los datos de producción fluyen de forma fiable hacia los sistemas de negocio, y el contexto de negocio, como pedidos y recetas, está disponible para operaciones.
- Prácticas compartidas. La seguridad, la identidad, la monitorización y la gestión de cambios se aplican de forma coherente, adaptadas a las restricciones de cada lado.
- Personas compartidas. Los equipos entienden las prioridades del otro y son dueños conjuntos de la capa de integración.
Lo que la convergencia no exige es una red plana. El modelo Purdue y las zonas de IEC 62443 siguen vigentes. La integración se produce en una frontera definida, normalmente una DMZ industrial, y la red de planta permanece segmentada. Nuestra comparativa entre el modelo Purdue e ISA-95 explica cómo se relacionan esas capas.
Los componentes técnicos
Datos orientados a eventos en lugar de integraciones punto a punto
La forma tradicional de dar a IT acceso a los datos de OT es una integración punto a punto: el MES consulta al SCADA, el ERP consulta al historiador, una herramienta de informes lee una base de datos en la que escribe el historiador. Cada enlace es a medida, frágil y propiedad de quien lo construyó. Añadir un nuevo consumidor significa otra integración más.
La mensajería publicación/suscripción cambia eso. Cada fuente OT publica sus datos una sola vez en un broker. Cada consumidor de IT se suscribe a lo que necesita. El lado OT nunca tiene que saber quién está escuchando, y el lado IT nunca necesita una conexión hacia la planta. Si el papel del broker es nuevo para ti, consulta qué hace un broker MQTT.
Un Unified Namespace como lenguaje común
Un broker por sí solo no hace que los datos sean comprensibles. Un Unified Namespace (UNS) añade estructura: cada valor vive en un topic predecible basado en la jerarquía ISA-95, como connectmq/acme/plant1/assembly/line2/press04/state. Un ingeniero de OT reconoce la ubicación física. Un desarrollador de IT ve una API estable y documentada. Ambos leen el mismo topic. Nuestra guía sobre cómo construir un Unified Namespace recorre el diseño paso a paso.
Conectividad solo saliente
Los gateways de OT se conectan hacia fuera con el broker a través de TLS, y los consumidores de IT también se conectan hacia fuera. No se abre ningún puerto entrante hacia la planta. Esta es la propiedad más importante para ganarse el apoyo del equipo de seguridad de OT. El patrón se detalla en nuestro artículo sobre MQTT en una DMZ industrial.
Propiedad clara de la capa de datos
Alguien tiene que ser responsable de las reglas de nomenclatura de topics, las convenciones de payload, las credenciales de acceso y la calidad de los datos. En las organizaciones maduras esto se convierte en una función de DataOps industrial situada entre IT y OT. Más información en nuestra introducción a DataOps industrial.
Ejemplo: ambos equipos leyendo los mismos datos en vivo
Así es como se ve la convergencia en la práctica. Un gateway de OT publica el estado de la máquina como retained messages en el UNS. Un desarrollador de IT escribe unas pocas líneas de Python para llevar ese estado a una aplicación de negocio o a un gemelo digital 3D de la línea, sin tocar nunca el PLC ni el gateway.
Pruébalo primero en el servidor MQTT público gratuito, pensado para pruebas y no para datos de producción. Publica un estado retenido como "lado OT":
mosquitto_pub -h broker.connectmq.com -p 1883 -i ot-sim-$RANDOM -r \
-t connectmq/demo/itot42/plant1/assembly/line2/press04/state \
-m '{"state":"RUNNING","order":"WO-1182","ts":"2026-10-16T09:12:00Z"}'
Después ejecuta el suscriptor del "lado IT":
import json
import uuid
import paho.mqtt.client as mqtt
TOPIC = "connectmq/demo/itot42/plant1/+/+/+/state"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(TOPIC, qos=1)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
area, line, machine = parts[4], parts[5], parts[6]
data = json.loads(msg.payload)
# Entregar a un sistema de negocio; aquí solo imprimimos una fila
print(f"{area:10} {line:6} {machine:8} {data['state']:8} order={data.get('order')}")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"it-app-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
El suscriptor recibe el estado retenido nada más conectarse y, después, cada cambio en cuanto se produce. El ingeniero de OT puede abrir un explorador MQTT de escritorio sobre el mismo topic y ver exactamente el mismo mensaje. Esa vista compartida es el día a día de la convergencia. En producción, ambos lados usan sus propias credenciales del broker en el puerto 8883, y los datos reales de planta nunca van a un área pública, que cualquiera puede leer.
Pasos culturales para que la convergencia perdure
La tecnología es la mitad fácil. Estas prácticas ayudan en la parte humana:
- Empieza por un problema de OT. Elige un caso de uso que importe a la planta, como las paradas no planificadas en una máquina cuello de botella. Los proyectos impulsados por IT que solo sirven para informes rara vez consiguen el apoyo de OT.
- Deja que OT sea dueño del edge. Los ingenieros de control deciden qué se lee de cada PLC, con qué frecuencia y en qué modo. IT es dueño de los consumidores.
- Acordad la frontera. Poned por escrito dónde termina la responsabilidad de OT, normalmente en la conexión saliente del gateway, y dónde empieza la de IT.
- Usad un único vocabulario. La jerarquía ISA-95 en los nombres de los topics da a ambos equipos palabras comunes para sitios, áreas, líneas y máquinas.
- Formad parejas. Pon a un desarrollador de IT y a un ingeniero de control en el mismo piloto. Dos semanas de trabajo conjunto valen más que cualquier taller.
- Respeta las ventanas de cambio. Las actualizaciones de los gateways siguen los calendarios de mantenimiento de OT, no los martes de parches de IT.
Dónde ayuda un broker MQTT gestionado
La capa de datos compartida tiene que ser segura, estar siempre disponible y recibir mantenimiento, lo cual es trabajo clásico de IT. Ejecutarla en hardware de planta traslada ese trabajo a OT, que normalmente no lo quiere. Un broker MQTT gestionado es un punto de encuentro neutral para ambos equipos. ConnectMQ detecta automáticamente los topics ISA-95 y de Unified Namespace, muestra los dispositivos agrupados por nivel ISA-95, decodifica Sparkplug B para los equipos que lo usan y ofrece un explorador de topics en vivo que pueden usar tanto un ingeniero de control como un desarrollador. Las organizaciones con normas estrictas de residencia de datos pueden ejecutar ConnectMQ BYOC en su propia cuenta cloud. Para comparar modelos de alojamiento de forma más amplia, consulta nuestra guía de broker MQTT en la nube y, para el panorama industrial completo, la guía de IoT industrial con MQTT.
Da a IT y OT un único namespace en ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Publica el estado de una máquina en un árbol de topics ISA-95, da una credencial a cada equipo y deja que la conversación empiece a partir de datos compartidos en lugar de hojas de cálculo enfrentadas.
Preguntas frecuentes
¿Qué es la convergencia IT/OT en pocas palabras?
Es conseguir que los sistemas de negocio y los sistemas de planta trabajen con los mismos datos, con prácticas compartidas de seguridad y gestión de cambios. No significa fusionar las redes ni dar a IT el control de los PLC.
¿Aumenta la convergencia IT/OT el riesgo cibernético?
Puede aumentarlo si se hace aplanando las redes. Si se hace con segmentación, conexiones solo salientes a través de una DMZ y credenciales por cliente, normalmente mejora la visibilidad y la seguridad frente a las integraciones improvisadas.
¿Por qué MQTT es tan popular para la convergencia IT/OT?
Los clientes se conectan hacia fuera con un broker, así que no hacen falta puertos entrantes hacia la planta. Además, el modelo publicación/suscripción permite que muchos consumidores de IT usen los mismos datos de OT sin integraciones adicionales.
¿Quién debería ser dueño del Unified Namespace?
Idealmente, un equipo conjunto o una función de DataOps industrial. OT es dueño de lo que se publica desde el edge, IT es dueño de los consumidores y el equipo conjunto es dueño de las reglas de nomenclatura y de los estándares de payload.
