Modelo Purdue vs ISA-95 es uno de los puntos de confusión más habituales en la arquitectura industrial, porque ambos usan niveles numerados del 0 al 4 y ambos se dibujan como capas apiladas. En esta comparativa aprenderás para qué se diseñó cada modelo, cómo se corresponden sus niveles, en qué se diferencian realmente y cómo MQTT y un Unified Namespace cambian la forma en que los datos se mueven entre niveles sin renunciar a la zonificación de seguridad que aportan las redes de estilo Purdue.
De dónde viene cada modelo
La Purdue Enterprise Reference Architecture se desarrolló en la Universidad de Purdue a principios de los años noventa como modelo general para la fabricación integrada por ordenador. En el mundo de la seguridad industrial se ha convertido en una forma abreviada de referirse a una arquitectura de red por capas: el proceso físico abajo, la IT corporativa arriba y fronteras controladas entre ambos. Se usa mucho como referencia en los programas de seguridad OT e influyó en el enfoque de zonas y conductos de ISA/IEC 62443.
ISA-95, publicada también como IEC 62264, es una norma de integración. Su propósito es definir cómo intercambian información los sistemas de negocio, como el ERP, y los sistemas de operaciones de fabricación, como el MES: programas de producción, consumo de materiales, capacidad de los equipos, resultados de calidad. Aporta modelos de objetos, modelos de actividad y una jerarquía funcional, y define además la jerarquía de equipos basada en roles: empresa, sitio, área, centro de trabajo y unidad de trabajo.
En resumen: Purdue se usa sobre todo para responder "¿cómo deben segmentarse las redes?", mientras que ISA-95 responde "¿qué funciones existen en cada nivel y qué información fluye entre el negocio y las operaciones?".
Cómo se corresponden los niveles
Los números de nivel coinciden lo bastante como para resultar útiles y lo bastante poco como para provocar discusiones.
| Nivel | Modelo Purdue (vista de red) | Jerarquía funcional ISA-95 | Sistemas típicos |
|---|---|---|---|
| 5 | Red empresarial | No se define por separado | IT corporativa, servicios expuestos a internet |
| 4 | Logística del negocio | Planificación del negocio y logística | ERP, planificación, correo electrónico |
| 3.5 | DMZ industrial | No definido | Jump hosts, servidores de parches, brokers de datos |
| 3 | Operaciones del sitio | Gestión de operaciones de fabricación | MES, historian, servidores SCADA del sitio |
| 2 | Control supervisor de área | Supervisión y control supervisor | HMI, clientes SCADA, estaciones de ingeniería |
| 1 | Control básico | Detección y actuación | PLC, controladores DCS, RTU |
| 0 | Proceso físico | El proceso físico | Sensores, actuadores, variadores |
Destacan tres diferencias:
- El nivel 3.5 es un concepto de Purdue. ISA-95 no tiene DMZ porque no modela redes. Los profesionales de la seguridad añadieron la DMZ industrial entre las operaciones del sitio y las redes corporativas para impedir el tráfico directo entre IT y OT.
- El nivel 5 aparece en muchos diagramas Purdue como un nivel empresarial o de internet separado. ISA-95 se detiene en el nivel 4.
- La principal aportación de ISA-95 es la interfaz entre los niveles 3 y 4, que los diagramas Purdue tratan como una única frontera de cortafuegos.
Modelo Purdue vs ISA-95: diferencias clave
| Aspecto | Modelo Purdue | ISA-95 |
|---|---|---|
| Tipo | Arquitectura de referencia | Norma internacional (IEC 62264) |
| Preocupación principal hoy | Segmentación de red y seguridad | Integración de sistemas y modelos de información |
| Define modelos de datos | No | Sí, para producción, calidad, mantenimiento e inventario |
| Define jerarquía de equipos | No | Sí, de la empresa a la unidad de trabajo |
| Define una DMZ | Sí, normalmente como nivel 3.5 | No |
| Público habitual | Seguridad OT, ingenieros de red | Arquitectos MES, integradores, operaciones |
| Relevancia para el diseño de topics MQTT | Indirecta, por la ubicación de los brokers | Directa, a través de la jerarquía de equipos |
La consecuencia práctica: cuando diseñes topics MQTT, usa la jerarquía de equipos ISA-95, que explica nuestra guía sobre la jerarquía de equipos ISA-95. Cuando decidas dónde se ejecuta el broker y qué conexiones permiten los cortafuegos, piensa en zonas Purdue.
Cómo MQTT aplana la comunicación entre niveles
En una planta clásica de estilo Purdue, los datos suben los niveles salto a salto. SCADA sondea un PLC en el nivel 2, SCADA alimenta el historian en el nivel 3, el historian se replica a través de la DMZ y el ERP acaba viendo un resumen. Cada salto es una integración punto a punto con su propio protocolo, mapeo y modos de fallo.
Una arquitectura de publicación-suscripción cambia el flujo de datos. Con un broker MQTT como Unified Namespace, cualquier productor autorizado publica una vez y cualquier consumidor autorizado se suscribe directamente. El MES, el historian, un dashboard y un proceso de analítica en la nube leen la misma telemetría de la llenadora desde el mismo topic. A esto se refiere la gente cuando dice que MQTT "aplana la pirámide".
Conviene precisar qué se aplana. La arquitectura de la información se vuelve plana: hay un único namespace en lugar de una cadena de copias. La arquitectura de red no tiene por qué: las zonas, los cortafuegos y la DMZ siguen existiendo. MQTT ayuda en esto, porque los clientes siempre abren conexiones salientes hacia el broker. Un gateway en el nivel 2 puede publicar en un broker situado en la DMZ o en la nube sin abrir ningún puerto entrante hacia la red de control.
Dónde ubicar el broker
| Ubicación | Cómo funciona | Consideraciones |
|---|---|---|
| Broker de sitio en el nivel 3 | Los gateways publican dentro del sitio; un bridge o consumidor reenvía hacia arriba | Los datos se quedan en local; tú operas el servidor |
| Broker en la DMZ (nivel 3.5) | Los clientes OT se conectan en saliente a la DMZ; los clientes IT se conectan desde arriba | Frontera clara; ningún lado se conecta a la zona del otro |
| Broker en la nube | Los gateways edge se conectan en saliente por TLS a un broker alojado | Sin servidor que operar; requiere salida a internet desde una zona controlada |
| Híbrido | Broker de sitio para consumidores locales y broker en la nube para la empresa y entre sitios | Más componentes, mejor resiliencia y alcance |
Nuestro artículo sobre MQTT en la DMZ trata a fondo el diseño de la DMZ, incluidas las reglas de cortafuegos. Si eliges un broker MQTT en la nube, un broker MQTT gestionado como ConnectMQ se encarga del lado del servidor, mientras que tu cortafuegos solo necesita permitir TLS saliente desde la zona del gateway.
Probar una ruta saliente desde una zona OT
Antes de decidir la ubicación, comprueba que un gateway en la zona prevista puede llegar al broker por el puerto correcto y que TLS valida. Estos comandos pueden ejecutarse con seguridad desde un gateway Linux o un jump host; usan el servidor MQTT público gratuito, así que no publiques nada sensible:
# 1. ¿Se permite TLS saliente en el 8883 y valida el certificado?
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null 2>/dev/null | grep -E "Verify return code|subject="
# 2. Publica un mensaje de prueba retenido por TLS
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-pub-j2 -r -t "connectmq/demo/j2v6/zone-test/level2-gateway" -m "reachable"
# 3. Léelo desde otra zona
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-sub-j2 -t "connectmq/demo/j2v6/zone-test/#" -v -C 1
Una línea Verify return code: 0 (ok) confirma que la cadena de certificados es de confianza. Si el paso 1 se queda colgado, un cortafuegos está bloqueando el 8883; si WebSocket es la única opción, el puerto 8084 con la ruta /mqtt es una alternativa. El servidor MQTT público gratuito sirve para esta prueba de conectividad; el tráfico de producción debe ir a un broker privado con credenciales.
La seguridad sigue importando
Un namespace plano hace que los datos sean fáciles de alcanzar, así que la autenticación y el mínimo privilegio importan más, no menos:
- Solo conexiones salientes. Los gateways se conectan hacia el broker; nunca abras puertos entrantes hacia los niveles 0 a 2.
- TLS en todas partes. Puerto 8883 para MQTT sobre TLS y 8084 para WebSocket seguro.
- Una identidad por cliente. Emite credenciales por gateway y aplicación para poder revocar cada una de forma independiente. En ConnectMQ, los client IDs están vinculados a las credenciales emitidas.
- Rutas de lectura y escritura separadas para el control. Trata los topics de comandos como de alto riesgo y mantén el control en lazo cerrado en la red de control local.
- Supervisa las conexiones. Vigila clientes inesperados e inicios de sesión fallidos. ConnectMQ bloquea IPs tras inicios de sesión fallidos repetidos y aplica protección contra inundación por tenant.
La relación entre ambos modelos forma parte de la conversación más amplia sobre la convergencia IT/OT, y nuestra guía de MQTT para IoT industrial muestra cómo encajan estas piezas en una arquitectura de planta completa.
Conecta tus niveles con ConnectMQ
Mantener las zonas de estilo Purdue mientras se aplana el flujo de datos requiere un broker al que todas las zonas puedan llegar mediante TLS saliente. ConnectMQ es un broker MQTT gestionado con TLS en el 8883, WebSocket seguro en el 8084, credenciales por cliente y una vista de dispositivos ISA-95, disponible en despliegues compartidos, Dedicated o BYOC. Empieza en el plan gratuito Serverless en app.connectmq.com, sin tarjeta de crédito.
Preguntas frecuentes
¿Está obsoleto el modelo Purdue?
Su flujo de datos estricto, salto a salto, está siendo sustituido por arquitecturas de publicación-suscripción, pero su idea central de segmentar las redes en zonas con fronteras controladas sigue siendo fundamental para la seguridad OT.
¿Define ISA-95 la seguridad de red?
No. ISA-95 define funciones, modelos de información y la jerarquía de equipos. La seguridad de redes y sistemas en la automatización industrial se aborda en la serie ISA/IEC 62443.
¿Qué modelo debo usar para diseñar topics MQTT?
Usa la jerarquía de equipos ISA-95 para los topics y las zonas de estilo Purdue para decidir dónde se ejecuta el broker y qué conexiones salientes se permiten.
¿Rompe un Unified Namespace el modelo Purdue?
Cambia el flujo de datos, no necesariamente la segmentación de red. Con conexiones MQTT solo salientes y un broker en la DMZ o en la nube, las zonas y los cortafuegos siguen en su sitio.
