Un documento de posición contraria que sostiene que la narrativa dominante de la convergencia OT/TI comete un error de categoría. La tecnología operativa y la tecnología de la información deberían compartir cadenas de herramientas, prácticas y personal, pero su distinción arquitectónica refleja diferencias fundamentales en física, modos de falla y límites de confianza que ninguna cantidad de herramientas puede disolver. El modelo correcto es asimétrico: distinción arquitectónica con unificación operativa, mediada por una capa de demarcación deliberada.
Preámbulo
Una frase en particular ha adquirido el estatus de axioma industrial durante la última década: convergencia OT/TI. Aparece en documentos técnicos de proveedores, en marcos de consultoría estratégica, en conferencias magistrales industriales y en presentaciones de diapositivas que justifican programas de transformación multimillonarios. La frase sugiere que la separación histórica entre la tecnología operativa (los sistemas de control que mueven la materia física) y la tecnología de la información (los sistemas que mueven la información sobre la materia) fue una condición transitoria producida por accidentes de la historia organizacional, y que la práctica madura de la ingeniería disolverá la distinción.
Este artículo sostiene que la narrativa de la convergencia, tomada en su forma dominante, es errónea. No es parcialmente incorrecto, ni ocasionalmente incorrecto, sino estructuralmente incorrecto de una manera que produce fallas arquitectónicas cuando se lo trata como un principio de diseño.
Sin embargo, el argumento no es una defensa de la narrativa más antigua: la doctrina de la brecha de aire, el fundamentalismo del modelo Purdue, la posición de que la TO y la TI pertenecen a tradiciones de ingeniería inconmensurables que deben mantenerse rigurosamente separadas. Esa narrativa más antigua también ha fracasado, por razones que examinaremos en este artículo. Los sistemas industriales modernos no pueden funcionar como si los dominios de TI y OT estuvieran sellados entre sí; Las realidades operativas de la seguridad de la cadena de suministro, la observabilidad, el ciclo de vida del software y el despliegue del personal requieren un nivel de unificación que la narrativa anterior niega.
La posición correcta tiene más matices que cualquiera de los extremos. Es que OT y TI difieren a nivel arquitectónico (en sus objetivos de optimización, modelos de confianza, semántica de fallas, escalas de tiempo y propiedades de reversibilidad) y que estas diferencias no son artefactos de la historia organizacional sino reflejos de hechos físicos y operativos que ninguna elección de ingeniería puede disolver. Deben permanecer arquitectónicamente distintos. Al mismo tiempo, las prácticas operativas que los rodean (control de versiones, seguridad de la cadena de suministro, observabilidad, automatización de la implementación, desarrollo del personal) deben unificarse. El lugar de esta unificación es la capa de demarcación entre los dos dominios: en términos industriales, la puerta de entrada.
La posición se puede expresar de forma compacta: distinción arquitectónica, unificación operativa. Este artículo desarrolla el argumento en ocho secciones. El primero caracteriza la narrativa de la convergencia e identifica lo correcto en ella. El segundo establece las propiedades arquitectónicas que distinguen la TO de la TI y sostiene que estas propiedades son esenciales, no accidentales. El tercero diagnostica el error conceptual en la narrativa de convergencia como un error de categoría. El cuarto examina las analogías históricas (narrativas de convergencia en otros ámbitos) y el patrón por el cual han fracasado. El quinto confronta los contraargumentos más fuertes. El sexto describe el modelo arquitectónico correcto y el papel de la capa de demarcación. El séptimo analiza las implicaciones para la práctica de la ingeniería. El octavo reafirma y defiende la tesis.
El público objetivo es el arquitecto, líder de ingeniería o estratega técnico a quien se le pide que comprometa a una organización industrial con un programa de convergencia y que siente que el programa no es del todo correcto pero no puede explicar por qué.
La narrativa de la convergencia
Un argumento claro requiere una caracterización clara de la posición a la que se opone. La narrativa de la convergencia, en su forma dominante, sostiene lo siguiente:
La separación histórica entre OT y TI fue producida por accidentes organizacionales (ecosistemas de proveedores distintos, tradiciones de ingeniería distintas, procesos de adquisición distintos) más que por una necesidad técnica subyacente.
A medida que los sistemas OT adoptan protocolos estándar (TCP/IP, OPC UA, MQTT), sistemas operativos estándar (Linux, en varias variantes integradas y en tiempo real) y hardware estándar (x86 y ARM en lugar de controladores propietarios), la base técnica para la distinción se erosiona.
Las prácticas operativas nativas de la nube (integración continua, observabilidad, infraestructura como código, orquestación de contenedores) se aplican igualmente bien a las cargas de trabajo de OT y TI.
El punto final maduro de esta trayectoria es una arquitectura unificada en la que las cargas de trabajo de OT se ejecutan en la misma infraestructura, son administradas por las mismas herramientas y operadas por el mismo personal que las cargas de trabajo de TI. La distinción entre ambos se convierte en una curiosidad histórica.
Varios elementos de esta narrativa son correctos y la posición presentada en este artículo los reconoce explícitamente.
Es cierto que los protocolos estándar han reemplazado en gran medida a los propietarios en las capas superiores de la comunicación industrial. OPC UA [1] se ha convertido en el protocolo de interoperabilidad de facto para datos de planta, desplazando a docenas de equivalentes propietarios. MQTT [2] domina la telemetría en dirección norte. TCP/IP es universal. La superficie del protocolo que distinguía la OT de la TI hace una generación se ha disuelto sustancialmente.
Es cierto que las prácticas operativas desarrolladas originalmente para aplicaciones nativas de la nube se aplican a cargas de trabajo de OT con resultados productivos. La orquestación de contenedores [3], la gestión de configuración de GitOps, la observabilidad basada en OpenTelemetry [4] y los marcos de seguridad de la cadena de suministro como SLSA [5] y Sigstore [6] no son simplemente transferibles a implementaciones industriales: son mejoras con respecto a las prácticas operativas que las precedieron.
Es cierto que la movilidad del personal entre OT y TI está aumentando y que esto es saludable. El aislamiento histórico de la ingeniería OT de la práctica más amplia del software produjo déficits documentados en la postura de seguridad, la calidad del código y la madurez operativa. El intercambio de personal y de prácticas entre los dominios ha reducido estos déficits.
Donde falla la narrativa de la convergencia es en su conclusión. A partir de las premisas correctas de que los protocolos han convergido, las prácticas deberían converger y el personal debería mezclarse, la narrativa extrae la inferencia incorrecta de que las arquitecturas también deberían converger. Esta inferencia no se sigue. La distinción arquitectónica entre OT y TI no se reduce a la distinción de protocolo o a la distinción de práctica; refleja propiedades que sobreviven a la convergencia de protocolos y prácticas porque no son propiedades a nivel de protocolo o de práctica.
La siguiente sección establece cuáles son estas propiedades.
Convergence pressure versus architectural separability
bar chartLas propiedades arquitectónicas que deben permanecer distintas
Lo que distingue a OT de TI, a nivel de arquitectura, no es una lista de tecnologías sino un conjunto de propiedades estructurales que se mantienen independientemente de qué tecnologías las implementen. Siete de esas propiedades merecen un examen explícito.
2.1 El tiempo como preocupación arquitectónica de primer nivel
En los sistemas de TI, el tiempo es, salvo raras excepciones, una limitación suave. Una solicitud web que tarda 200 ms es aceptable; uno que tarda 2 s está degradado pero funcional; uno que tarda 20 s se rompe, pero normalmente no es catastrófico. El sistema está diseñado según objetivos estadísticos de nivel de servicio (latencia percentil 99, latencia percentil 99,9) y la degradación elegante bajo carga es una virtud.
En los sistemas OT, el tiempo es una dura limitación. Un bucle de control de movimiento que no cumple su plazo de 1 ms no produce un resultado degradado; produce un resultado equivocado, posiblemente un resultado inseguro. El sistema está diseñado para el peor de los casos, no para distribuciones estadísticas. La degradación elegante no es una virtud sino un peligro, porque el sistema físico que se controla no se degrada elegantemente: continúa funcionando y la ausencia de una entrada de control correcta no produce una respuesta lenta sino incorrecta.
Edward A. Lee de Berkeley ha argumentado, a lo largo de dos décadas de artículos sobre sistemas ciberfísicos [7][8], que esta diferencia no es una diferencia cuantitativa en los requisitos de latencia sino una diferencia cualitativa en cómo el tiempo entra en la arquitectura. En los sistemas de TI, el tiempo es una propiedad del desempeño. En los sistemas OT, el tiempo es una propiedad de corrección. Las implicaciones de esta distinción llegan al diseño de lenguajes de programación, programadores, protocolos de comunicación y técnicas de verificación. No se pueden disimular tratando una carga de trabajo de OT como una "carga de trabajo de TI de baja latencia".
La narrativa de la convergencia trata consistentemente la latencia como una propiedad cuantitativa que un hardware más potente y mejores redes resolverán. El diagnóstico a nivel de doctorado es que la latencia es un síntoma; la propiedad subyacente es el determinismo, y el determinismo es cualitativamente diferente de la baja latencia.
2.2 Modos de falla y asimetría de consecuencias
Cuando un sistema de TI falla, el modo de falla suele ser la pérdida de disponibilidad o integridad de la información. Las consecuencias son económicas (tiempo de inactividad del servicio, pérdida de transacciones, daño a la reputación) y, en la inmensa mayoría de los casos, son reversibles. Las transacciones perdidas se pueden reproducir. Los datos dañados se pueden restaurar desde una copia de seguridad. Las implementaciones fallidas se pueden revertir.
Cuando falla un sistema OT, el modo de falla suele ser la pérdida de control físico. Las consecuencias incluyen posibles daños a los equipos, el medio ambiente o la vida humana y, en muchos casos, son irreversibles. Un controlador que libera el producto químico incorrecto, abre la válvula incorrecta o ordena la trayectoria del motor incorrecta produce un efecto físico que no se puede revertir invirtiendo una configuración.
Esta asimetría de consecuencias tiene implicaciones arquitectónicas que ninguna cantidad de herramientas operativas puede disolver. El régimen de verificación que debe cumplir un sistema OT antes de su implementación es cualitativamente diferente del régimen de verificación que debe cumplir un sistema TI. El proceso de gestión del cambio es diferente. El modelo de confianza es diferente. Los modos de falla aceptables (a prueba de fallas, seguro contra fallas, operacional contra fallas) no tienen análogos de TI claros porque los sistemas de TI generalmente tienen solo un modo de falla, que es falla no disponible, y la indisponibilidad rara vez es una condición de seguridad.
La narrativa de la convergencia trata esta asimetría como un problema de herramientas: mejores pruebas, mejor observabilidad, mejor retroceso. El diagnóstico a nivel de doctorado es que la asimetría es estructural y no puede borrarse con herramientas. Un sistema cuya falla puede liberar material radiactivo, dañar a un trabajador o contaminar una cuenca no es una versión más crítica de un sistema cuya falla puede hacer perder una transacción; es una categoría diferente de sistema, que requiere diferentes primitivas arquitectónicas.
2.3 Modelos de confianza: basados en zonas versus basados en identidad
Las arquitecturas modernas de seguridad de TI han convergido en gran medida en la confianza basada en la identidad. El paradigma Zero Trust [9] sostiene que no se debe otorgar ninguna confianza implícita en función de la posición de la red; Cada solicitud debe ser autenticada y autorizada en función de la identidad de su originador. Este modelo es apropiado para sistemas de TI, donde las solicitudes generalmente son generadas por usuarios humanos identificables o cuentas de servicio, y donde el costo de los gastos generales de autenticación es soportable.
Los sistemas OT, en general, no se ajustan a este modelo. Los creadores del tráfico OT suelen ser procesos (controladores, unidades, sensores) sin identidades naturales en el sentido de TI. Los protocolos que utilizan no fueron diseñados para la autenticación. Los presupuestos de latencia con los que operan normalmente no pueden adaptarse a la sobrecarga criptográfica de la autenticación por mensaje. El modelo de confianza que surgió en OT, codificado en Purdue Enterprise Reference Architecture [10] y refinado en IEC 62443 [11], está basado en zonas: la confianza se otorga en función de la zona de red en la que reside un dispositivo, y los límites entre zonas se aplican mediante conductos cuyos protocolos y acceso están definidos explícitamente.
La narrativa de la convergencia tiende a tratar la confianza basada en zonas como una forma primitiva de confianza basada en identidad, en espera de actualización. El diagnóstico a nivel de doctorado es que la confianza basada en zonas no es primitiva; es apropiado para los tipos de sistemas que gobierna. La confianza basada en la identidad requiere identidad, y las entidades en los niveles más bajos de un sistema industrial (un transmisor de temperatura, un interruptor de proximidad, un solenoide) no tienen identidades naturales. Forzarlos a adoptar un modelo basado en la identidad produce una ceremonia sin seguridad; el suministro de certificados, la rotación y la revocación se convierten en gastos administrativos sin la correspondiente ganancia de confianza.
La arquitectura madura combina ambos modelos: confianza basada en identidad por encima de la capa de demarcación (lado de TI), confianza basada en zonas por debajo (lado de OT) y puerta explícita en el límite. Este es el modelo que IEC 62443 ya codifica, y la presión de la narrativa de convergencia para abandonarlo en favor de una confianza universal basada en la identidad representa una regresión arquitectónica.
2.4 Asimetría del ciclo de vida
Un sistema de TI típico tiene un ciclo de vida medido en años: de tres a cinco para el hardware, de meses a un año para las principales versiones de software, de semanas a meses para los parches de seguridad. El ciclo de vida supone un compromiso continuo con el sistema: se actualizará con frecuencia, se reemplazará periódicamente y se retirará del servicio dentro de un horizonte de planificación.
Un sistema OT típico tiene un ciclo de vida medido en décadas. Un controlador industrial implementado en 2005 aún puede estar operativo en 2035. El hardware, el firmware, la configuración y la documentación deben ser compatibles en este horizonte. La lógica económica de la depreciación de los equipos industriales, la lógica regulatoria de la seguridad de los procesos y la lógica operativa de la disponibilidad de la planta empujan en la dirección de una larga vida útil.
Esta asimetría tiene implicaciones arquitectónicas que son fáciles de subestimar. Las dependencias de software que son aceptables en TI (basarse en servicios en la nube que pueden quedar obsoletos, en bibliotecas cuyo estado de mantenimiento puede cambiar, en protocolos cuyas especificaciones pueden evolucionar) son inaceptables en OT, porque el horizonte temporal durante el cual el sistema OT debe funcionar excede el horizonte de mantenimiento de las dependencias. La respuesta arquitectónica es minimizar las dependencias externas, preferir protocolos con especificaciones estables durante mucho tiempo y diseñar para operación fuera de línea con una dependencia limitada de servicios remotos.
La narrativa de la convergencia tiende a descartar esta asimetría al suponer que los ciclos de vida convergerán, es decir, que los sistemas OT adoptarán ciclos de vida típicos de TI. El diagnóstico a nivel de doctorado es que no pueden hacerlo, porque los ciclos de vida no son opciones de ingeniería sino reflejos de cronogramas de depreciación del capital, regímenes regulatorios y requisitos de continuidad operativa que no están sujetos a preferencias de ingeniería.
2.5 Reversibilidad
La propiedad de reversibilidad difiere entre OT e IT de una manera que se conecta con la asimetría del modo de falla, pero es lógicamente distinta. En TI, la mayoría de las acciones son reversibles: se puede revertir un cambio de configuración, se puede revertir una implementación y se puede anular una transacción. El patrón arquitectónico de implementación atómica con reversión automatizada, fundamental para la práctica moderna nativa de la nube, depende de la reversibilidad.
En OT, muchas acciones son irreversibles a nivel del sistema. Un motor que ha girado a una nueva posición no puede dejar de girar para deshacer la rotación; la nueva posición es el estado del sistema. Una sustancia química que se ha agregado a un proceso no se puede cancelar. Una soldadura que se ha realizado no se puede desoldar. El sistema de control puede revertir sus órdenes, pero los efectos físicos de órdenes pasadas persisten.
Esta asimetría tiene implicaciones arquitectónicas directas. El modelo de implementación típico de TI (implementar, observar, revertir si es necesario) no se corresponde con OT. Un cambio de OT que produce efectos físicos no deseados no se puede remediar revirtiendo el cambio. La respuesta arquitectónica es invertir en verificación antes de la implementación, en lugar de retroceder después de la implementación. La simulación de hardware en el circuito, la verificación formal de las propiedades de seguridad y la implementación por etapas con validación física explícita son prácticas específicas de OT que no tienen un análogo directo de TI.
La narrativa de la convergencia importa el modelo de TI de observar y retroceder a contextos de OT donde es estructuralmente inaplicable. No se trata de una cuestión de madurez operativa: es una cuestión de realidad física.
2.6 Determinismo versus desempeño estadístico
Los sistemas de TI suelen optimizarse en función de métricas estadísticas de rendimiento: rendimiento medio, latencia de cola, tasas de error en percentiles. La maquinaria matemática de la teoría de colas, los patrones arquitectónicos de deslastre de carga y degradación gradual y la práctica operativa de los objetivos de nivel de servicio suponen que el rendimiento se caracteriza mejor estadísticamente.
Los sistemas OT generalmente se optimizan según métricas de rendimiento deterministas: tiempo de ejecución en el peor de los casos, garantías estrictas en tiempo real, fluctuación limitada. La maquinaria matemática del análisis de la programabilidad, los patrones arquitectónicos de la programación con prioridad fija y el diseño basado en plazos, y la práctica operativa del comportamiento certificado en el peor de los casos suponen que el desempeño debe caracterizarse de manera determinista.
Esta no es la misma propiedad que la propiedad de tiempo como corrección de la Sección 2.1; es una propiedad arquitectónica relacionada pero distinta. Un sistema puede tener plazos estrictos en tiempo real (Sección 2.1) y también caracterizarse estadísticamente: la propiedad de determinismo (esta sección) requiere que la arquitectura misma descarte la variación estadística en las dimensiones relevantes. El argumento de extremo a extremo aplicado al tiempo (la posición de que las garantías de tiempo no pueden sintetizarse de manera confiable a partir de primitivas que no garantizan el tiempo) implica que el determinismo debe diseñarse desde el fondo de la pila, no agregarse desde arriba.
La narrativa de la convergencia tiende a tratar el determinismo como un caso especial de baja latencia, abordable mediante un mejor hardware y SLO más estrictos. El diagnóstico a nivel de doctorado es que el determinismo no es una extensión cuantitativa de la baja latencia sino una propiedad arquitectónica cualitativa que requiere diferentes primitivos de diseño.
2.7 Radio de explosión y contención
El radio de explosión de una falla en un sistema de TI generalmente está limitado por el propio sistema. Una falla en un servicio de pago produce pagos fallidos; una falla en un servicio de búsqueda produce búsquedas fallidas. El mundo físico no se ve afectado; el daño se limita al dominio de la información.
El radio de explosión de una falla en un sistema OT se extiende al mundo físico por diseño. Una falla en un sistema de control de la red eléctrica produce apagones. Una falla en un sistema de control de tratamiento de agua produce agua contaminada. Una falla en un sistema de control de transporte produce colisiones. El radio de la explosión está determinado por el sistema físico bajo control, no por el sistema de control en sí.
Esta asimetría tiene implicaciones para el diseño arquitectónico de los límites, la segmentación y la contención de la confianza. Un sistema OT debe diseñarse partiendo del supuesto de que su falla producirá consecuencias físicas, y la arquitectura debe estructurarse para limitar esas consecuencias, a través de sistemas de enclavamiento, funciones instrumentadas de seguridad, aislamiento físico y similares. La arquitectura típica de TI, que no proporciona contención física porque las fallas de TI no la requieren, es estructuralmente inadecuada cuando se importa a OT.
El error conceptual: un error de categoría
El diagnóstico de que la narrativa de la convergencia es errónea aún no identifica qué tipo de error comete. Son posibles varios diagnósticos: la narrativa podría estar empíricamente equivocada, técnicamente mal informada o culturalmente sesgada. El diagnóstico propuesto aquí es que comete un error de categoría en el sentido de Gilbert Ryle [12]: trata dos cosas como miembros de la misma categoría que, de hecho, pertenecen a categorías diferentes, y las inferencias extraídas de este tratamiento son sistemáticamente erróneas.
El error de categoría es tratar un sistema de control como un servicio.
Un servicio, en el sentido de TI, es un artefacto de software que acepta solicitudes, produce respuestas y se caracteriza por su contrato funcional, propiedades de desempeño y disponibilidad. Los servicios se componen a través de API. Escalan horizontalmente. Se operan en función de objetivos de nivel de servicio. Los patrones arquitectónicos del diseño orientado a servicios (acoplamiento flexible, apatridia, idempotencia, mensajería asincrónica) son apropiados para los servicios.
Un sistema de control, en el sentido OT, es un artefacto de software que participa en un circuito de retroalimentación con un proceso físico. No acepta solicitudes en el sentido informático; observa el estado físico y produce resultados de control. Se caracteriza no por un contrato funcional sino por una especificación teórica de control: márgenes de estabilidad, rechazo de perturbaciones, precisión de seguimiento, tiempo de respuesta. No escala horizontalmente: hay un proceso físico que controlar. No se opera contra los SLO de disponibilidad sino contra los requisitos de seguridad y confiabilidad derivados de los peligros físicos del proceso.
Cuando la narrativa de convergencia trata un sistema de control como un servicio, importa patrones arquitectónicos que son apropiados para los servicios y los aplica a sistemas que no son servicios. Los patrones fracasan no porque estén mal implementados sino porque están categóricamente mal aplicados. El control apátrida es incoherente: el control requiere fundamentalmente del Estado. Los comandos idempotentes a un actuador físico son incoherentes: el estado de un actuador evoluciona con cada comando, independientemente de la identidad del nivel de TI del comando. La composición del servicio no captura la estructura de un sistema de control, que está determinada por la física y no por los contratos API.
El error de categoría explica por qué las arquitecturas impulsadas por la convergencia a menudo producen sistemas que funcionan en desarrollo y fallan en producción. El entorno del desarrollador, donde el proceso físico controlado está ausente o simulado, no exhibe las propiedades que distinguen el control del servicio; el entorno de producción, donde el proceso físico está presente y es consecuente, exhibe estas propiedades con toda su fuerza.
El error es reversible, pero sólo si se reconoce que OT y TI son categorías diferentes y se diseña en consecuencia.
Analogías históricas: cuando fallan las narrativas de convergencia
La narrativa de la convergencia OT/TI no es única. Pertenece a una familia de narrativas de convergencia que han aparecido, con distintos grados de confianza, a lo largo de varias décadas de historia de la informática. Examinar a la familia ayuda a aclarar por qué las narrativas son persistentemente atractivas y por qué fracasan persistentemente.
La narrativa de que "todos los sistemas se vuelven distribuidos", prominente en la década de 1990, sostenía que el éxito de los sistemas distribuidos haría que los sistemas centralizados quedaran obsoletos. La narrativa predijo que las bases de datos distribuidas, los sistemas de archivos distribuidos y la computación distribuida desplazarían a sus predecesores centralizados. Los resultados empíricos son mixtos. Algunas cargas de trabajo se distribuyeron; otros permanecieron obstinadamente centralizados porque la centralización era, para esas cargas de trabajo, la elección arquitectónica correcta. El teorema CAP [13] proporcionó la explicación formal: la distribución y la coherencia no se pueden componer libremente, y las cargas de trabajo que requieren una fuerte coherencia en caso de fallo permanecen centralizadas por razones que las preferencias de ingeniería no pueden cambiar.
La narrativa de que "todo el software se convierte en web", destacada en la década de 2000, sostenía que las aplicaciones nativas serían desplazadas por las aplicaciones web. La narrativa predijo que la computación local migraría al navegador, que las diferencias entre los sistemas operativos se volverían irrelevantes y que la aplicación de escritorio se uniría a la tarjeta perforada en la prehistoria de la informática. El registro empírico muestra nuevamente un patrón más complejo. Las aplicaciones web capturaron muchas cargas de trabajo, pero las aplicaciones nativas persistieron para cargas de trabajo que requerían una estrecha integración de hardware, operación fuera de línea o una rica capacidad de interfaz de usuario. La convergencia fue parcial, no total.
La narrativa de que "la nube absorberá todo",, prominente en la década de 2010, sostenía que la computación local se disolvería en la computación en la nube. La narrativa predijo que los centros de datos se vaciarían, que los dispositivos de borde se convertirían en terminales delgadas y que la nube surgiría como el sustrato universal. El registro empírico muestra nuevamente una convergencia parcial seguida de un contramovimiento. La adopción de la nube es sustancial, pero el movimiento de la informática de punta (ver [14] para una encuesta) representa una redistribución explícita de la computación fuera de la nube, impulsada por la latencia, la soberanía y la economía del ancho de banda que la narrativa de la convergencia no modeló adecuadamente.
Un patrón emerge a través de estos ejemplos. Las narrativas de convergencia están sistemáticamente sesgadas hacia la predicción de la homogeneización y subestiman sistemáticamente las fuerzas que mantienen la heterogeneidad arquitectónica. Las fuerzas no son siempre las mismas, pero comparten una estructura común: reflejan realidades físicas, económicas u operativas que no están sujetas a preferencias de ingeniería, y las narrativas de convergencia que las ignoran producen arquitecturas que fracasan cuando las realidades se reafirman.
La narrativa de la convergencia OT/TI encaja en esta familia. Subestima las propiedades arquitectónicas identificadas en la Sección 2: propiedades que reflejan realidades físicas y operativas no sujetas a preferencias de ingeniería. Es probable que su trayectoria empírica siga el patrón: convergencia parcial en las áreas donde la convergencia es factible (herramientas, práctica, personal) seguida de reafirmación de la distinción en las áreas donde la convergencia es inviable (arquitectura, modelo de confianza, ciclo de vida).
Enfrentando los contraargumentos
Una defensa seria debe abordar las formas más fuertes de la posición a la que se opone. Esta sección aborda cuatro contraargumentos que los defensores de la convergencia plantean habitualmente.
5.1 El argumento de la convergencia del protocolo
OPC UA, MQTT y TCP/IP han unificado eficazmente la comunicación OT y TI. La distinción protocolaria se ha disuelto y sigue la distinción arquitectónica.
El argumento es parcialmente correcto y en gran medida erróneo. De hecho, los protocolos han convergido en las capas superiores. Pero la convergencia de protocolos no es una convergencia arquitectónica. OPC UA es un protocolo puente; permite que dos dominios arquitectónicos distintos intercambien datos sin fusionarlos. La existencia de una lengua común entre dos culturas no implica que las culturas sean las mismas. Los hablantes de francés y alemán pueden comunicarse en inglés sin convertirse en la misma cultura; Los sistemas OT y TI pueden comunicarse en OPC UA o MQTT sin convertirse en la misma arquitectura.
El punto más profundo es que las distinciones arquitectónicas identificadas en la Sección 2 (semántica de tiempo, modos de falla, modelos de confianza, ciclo de vida, reversibilidad, determinismo, radio de explosión) no son propiedades a nivel de protocolo. Son propiedades de los sistemas que utilizan los protocolos. Dos sistemas que hablan OPC UA pueden tener propiedades arquitectónicas completamente diferentes dependiendo de lo que hagan con el protocolo.
5.2 El argumento de la convergencia de Linux
Los PLC modernos ejecutan Linux. Las puertas de enlace industriales modernas ejecutan Linux. El kernel que ejecuta cargas de trabajo de OT es el mismo kernel que ejecuta cargas de trabajo de TI. La distinción entre SO se ha disuelto y le sigue la distinción arquitectónica.
El argumento observa una premisa verdadera (Linux se ha vuelto omnipresente en la informática industrial) y llega a una conclusión incorrecta. El kernel compartido no implica una arquitectura compartida, porque el régimen operativo bajo el cual se ejecuta el kernel difiere profundamente entre los contextos de OT y de TI.
Un sistema Linux configurado con OT normalmente se ejecuta con el parche PREEMPT_RT [15], con núcleos de CPU aislados dedicados a cargas de trabajo en tiempo real, con demonios que no son en tiempo real deshabilitados, con aislamiento explícito de recursos basado en cgroup y con parámetros del kernel ajustados para el determinismo en lugar del rendimiento. Un sistema Linux configurado por TI se ejecuta con el programador estándar, con todos los núcleos disponibles para una carga de trabajo general, con el conjunto completo de servicios systemd y con los parámetros del kernel ajustados para el rendimiento en lugar del determinismo. Los dos sistemas ejecutan la misma fuente central en el mismo sentido en que un auto de carreras de Fórmula 1 y un sedán urbano ejecutan el mismo principio de motor de combustión interna: cierto en un nivel de descripción, profundamente engañoso en el nivel de descripción que importa para las decisiones de ingeniería.
5.3 El argumento de los nativos de la nube
La orquestación de contenedores, las mallas de servicios, las plataformas de observabilidad y GitOps han demostrado su valor a escala de hiperescalador. No hay ninguna razón por la que estas prácticas no deban aplicarse a OT. La distinción operativa se ha disuelto y le sigue la distinción arquitectónica.
La premisa del argumento es correcta y la posición presentada en este artículo lo admite explícitamente. Las prácticas operativas nativas de la nube sí se aplican productivamente a OT. La pregunta diagnóstica es qué conclusión se sigue.
La conclusión que sigue es unificación operativa, no convergencia arquitectónica. La misma cadena de herramientas que opera cargas de trabajo de TI puede operar cargas de trabajo de OT, con la configuración adecuada. La misma plataforma de observabilidad puede incorporar telemetría de ambos dominios. El mismo controlador GitOps puede gestionar la configuración en ambos dominios. Esto es lo que la posición presentada aquí llama unificación operativa, y es inequívocamente beneficioso.
Lo que no se sigue es que las propiedades arquitectónicas de las cargas de trabajo de OT se conviertan en las de las cargas de trabajo de TI. Una carga de trabajo de OT en contenedores todavía tiene plazos estrictos en tiempo real, modos de falla irreversibles y un ciclo de vida de 20 años. El contenedor es un vehículo de despliegue, no una transformación arquitectónica. El hecho de que la misma cadena de herramientas opere ambos dominios no borra las diferencias entre las cargas de trabajo que opera la cadena de herramientas.
5.4 El argumento del personal
Los ingenieros de OT y los ingenieros de TI están aprendiendo las disciplinas de los demás. Los equipos multifuncionales son cada vez más comunes. La distinción cultural se está disolviendo y la distinción arquitectónica sigue.
La premisa del argumento es correcta y bienvenida. El aislamiento histórico de la ingeniería OT de la práctica más amplia del software fue perjudicial en ambas direcciones. Su disolución es una ganancia neta.
Sin embargo, la conclusión no se sigue porque las distinciones arquitectónicas no son artefactos culturales. Un ingeniero energético que aprende Python y un desarrollador backend que aprende lógica de escalera amplían su alcance, pero los sistemas que diseñan aún deben respetar las propiedades arquitectónicas de los dominios para los que diseñan. Un equipo culturalmente unificado puede construir sistemas arquitectónicamente distintos; de hecho, este es el modelo correcto. La relación cultura-arquitectura no es simétrica.
El modelo correcto: distinción arquitectónica con unificación operativa
La posición aquí expuesta no es negativa. Habiendo argumentado que la narrativa de la convergencia falla, el artículo debe articular el modelo que defiende en lugar de la convergencia. El modelo tiene tres componentes.
Primero, demarcación arquitectónica explícita entre los dominios OT y TI. La arquitectura de referencia empresarial de Purdue [10] y IEC 62443 [11] ya proporcionan el marco conceptual: zonas con límites de confianza explícitos, conductos con protocolos explícitos y puntos de demarcación donde los flujos de datos son mediados. Este marco debe preservarse y modernizarse, no abandonarse. La modernización consiste en reemplazar el supuesto histórico del aislamiento físico por el supuesto contemporáneo de la puerta explícita: los datos fluyen entre zonas, pero lo hacen a través de conductos deliberados, observables y controlables.
En segundo lugar, el flujo de datos asimétrico a través de la demarcación. La telemetría fluye de OT a TI en un gran volumen; el control fluye de TI a OT en bajo volumen y a través de canales cuidadosamente cerrados. La asimetría refleja la asimetría de consecuencias (Sección 2.2) y reversibilidad (Sección 2.5): un paquete de telemetría mal formado se puede descartar de forma segura, mientras que un comando de control mal formado puede producir efectos físicos irreversibles. Los dos flujos no deberían implementarse simétricamente; deben reflejar sus diferentes requisitos de seguridad y confianza.
En tercer lugar, unificación operativa por encima de la capa de demarcación. La cadena de herramientas que gestiona las cargas de trabajo de OT (la gestión de la configuración, la automatización de la implementación, la observabilidad, la seguridad de la cadena de suministro) debe ser la misma cadena de herramientas que gestiona las cargas de trabajo de TI, con la configuración adecuada para las propiedades específicas del dominio. Esta unificación logra los beneficios de la práctica operativa nativa de la nube sin comprometer las distinciones arquitectónicas que las prácticas no disuelven por sí mismas.
El lugar natural de la capa de demarcación, en los despliegues industriales, es la puerta de entrada. Un artículo anterior de esta serie [14] argumentó que la puerta de enlace ha surgido como el punto de equilibrio de la onda de computación de borde; El argumento aquí es que la puerta de enlace es también el punto de equilibrio de la relación arquitectónica OT/TI. Es el punto en el que los dos dominios se encuentran, donde los flujos de datos son mediados, donde los límites de confianza se cruzan bajo control explícito y donde la cadena de herramientas operativas logra visibilidad en ambos lados sin disolver la distinción entre ellos.
Esta no es una coincidencia accidental. La puerta de entrada se encuentra en un lugar arquitectónicamente significativo precisamente porque su ubicación refleja la estructura subyacente del problema: un punto de mediación entre dos dominios que comparten tráfico pero no arquitectura.
Implicaciones para la práctica
La posición aquí presentada tiene implicaciones directas para varias categorías de la práctica de la ingeniería.
Para el diseño organizacional, la implicación es que la prescripción de la narrativa de convergencia (fusionar las organizaciones de OT y TI) es parcialmente correcta y muy incorrecta. Las dos organizaciones deben compartir liderazgo, compartir herramientas, compartir procesos y compartir personal donde se transfieran las habilidades. No deben fusionarse en su responsabilidad por las propiedades arquitectónicas de sus respectivos dominios. La función de ingeniería de OT sigue siendo responsable de las propiedades arquitectónicas de los sistemas de OT, incluso cuando la cadena de herramientas operativas está unificada.
Para las adquisiciones, la implicación es que la convergencia de proveedores (seleccionar un único proveedor para la infraestructura de OT y TI) es generalmente una mala elección. Los proveedores que sobresalen en infraestructura de TI no son, salvo raras excepciones, los proveedores que sobresalen en infraestructura de OT. Las propiedades arquitectónicas que importan en el lado de OT no son las propiedades arquitectónicas que optimizan los proveedores de TI, y viceversa. El modelo de adquisición correcto selecciona proveedores apropiados para cada dominio e invierte en la capa de demarcación que los conecta.
Para el diseño de software, la implicación es que las cargas de trabajo que cruzan el límite OT/TI deben diseñarse con la asimetría modelada explícitamente. Una carga de trabajo que procesa telemetría OT y la expone a los consumidores de TI es estructuralmente diferente de una carga de trabajo que acepta comandos de TI y los traduce en actuación de OT. Los dos no deben combinarse, incluso si se implementan en el mismo marco en contenedores.
Para la arquitectura de seguridad, la implicación es que el modelo Zero Trust debe adoptarse en el lado de TI y el modelo basado en zonas retenerse en el lado de OT, con una política explícita en la capa de demarcación que se traduzca entre ellos. Se debe resistir la presión para extender Zero Trust universalmente a entornos OT donde produce ceremonia sin ganancia de seguridad.
Para la gestión del ciclo de vida, la implicación es que se debe respetar el supuesto de ciclo de vida largo de los sistemas OT en el diseño de integraciones entre dominios. Un servicio de TI que se integra con sistemas OT debe diseñarse para el ciclo de vida de TI en el lado de TI y para el ciclo de vida de OT en el lado de OT, con la capa de integración diseñada para unir ambos. La tentación de imponer un ciclo de vida de TI más corto en el lado de OT, en nombre de la agilidad, produce sistemas que el entorno de OT no puede sostener.
Argumento final
La posición puede expresarse de forma compacta. La narrativa de la convergencia observa premisas correctas (que los protocolos, las prácticas y el personal se están unificando a través de la división OT/TI) y llega a una conclusión incorrecta: que las arquitecturas también deberían unificarse. La distinción arquitectónica entre OT y TI no se reduce a la distinción de protocolo o a la distinción de práctica; refleja propiedades de la física, modos de falla, confianza, ciclo de vida y reversibilidad que sobreviven a la convergencia de protocolos y prácticas porque operan en un nivel diferente. Tratar un sistema de control como un servicio es un error de categoría en el sentido de Ryle, y las fallas arquitectónicas que resultan de este error son sistemáticas.
El modelo correcto es asimétrico: distinción arquitectónica en los niveles donde las distinciones son reales, unificación operativa en los niveles donde la unificación es factible y beneficiosa, y una capa de demarcación deliberada en la que se encuentran los dos dominios. El locus de esta demarcación, en los despliegues industriales, es la puerta de entrada. Las inversiones que se derivan de este modelo (en primitivas arquitectónicas apropiadas para el dominio, en infraestructura de mediación en la capa de demarcación, en herramientas operativas compartidas por encima de la demarcación) producen sistemas que son mejores que los sistemas que producirían la ortodoxia de convergencia o la ortodoxia de espacio aéreo.
La recomendación es directa. Resistir la narrativa de la convergencia que aconseja la homogeneización arquitectónica; abrazarlo cuando aconseja la unificación operativa; invertir en la capa de demarcación donde ambos se encuentran. El resultado no es un compromiso sino una arquitectura más sólida que la que produciría cualquiera de las posiciones puras.
Los mundos de OT y de TI no llegarán a ser uno. Compartirán cada vez más una cadena de herramientas, una cultura y una fuerza laboral. La distinción restante (arquitectónica, basada en principios y duradera) no es un residuo que debe eliminarse sino una estructura que debe preservarse.
References
[1] Fundación OPC. Especificación de arquitectura unificada de OPC, partes 1-100. 2008-presente.
[2] OÁSIS. MQTT Versión 5.0. Estándar OASIS, 2019. ISO/IEC 20922:2016 cubre MQTT 3.1.1.
[3] B. Burns et al. "Borg, Omega y Kubernetes". Comunicaciones de la JCA, 59(5), 2016.
[4] Proyecto OpenTelemetry. Especificación de OpenTelemetry. CNCF, 2019-presente.
[5] Google y otros. Niveles de la cadena de suministro para artefactos de software (SLSA). Open Source Security Foundation, 2021-presente.
[6] Fundación Linux. Sigstore: Firma de software para todos. 2021-presente.
[7] EA Lee. "Sistemas ciberfísicos: desafíos de diseño". 11th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC), 2008.
[8] EA Lee. "La informática necesita tiempo". Comunicaciones de la JCA, 52(5), 2009.
[9] Instituto Nacional de Normas y Tecnología. Arquitectura Zero Trust. Publicación especial del NIST 800-207, 2020.
[10] TJ Williams. The Purdue Enterprise Reference Architecture. Purdue Laboratory for Applied Industrial Control, 1992. ISA-95 (ANSI/ISA-95.00.01) proporciona la formalización contemporánea.
[11] Comisión Electrotécnica Internacional. IEC 62443: Redes de comunicaciones industriales: seguridad de redes y sistemas. 2009 hasta la actualidad (estándar de varias partes).
[12] G. Ryle. The Concept of Mind. University of Chicago Press, 1949. (El capítulo 1 introduce la categoría de error).
[13] S. Gilbert y N. Lynch. "La conjetura de Brewer y la viabilidad de servicios web coherentes, disponibles y tolerantes a las particiones". Noticias ACM SIGACT, 33(2), 2002.
[14] Serie Técnica Modibus. "From Cloud to Edge: A Critical Examination of Why Computation Is Migrating to the Gateway Layer." 2026.
[15] T. Gleixner y I. Molnar. PREEMPT_RT: Parches de preferencia en tiempo real para el kernel de Linux. Linux Foundation, https://wiki.linuxfoundation.org/realtime/
[16] EA Lee y SA Seshia. Introducción a los sistemas integrados: un enfoque de sistemas ciberfísicos. MIT Press, 2ª ed., 2017.
[17] JH Saltzer, DP Reed y DD Clark. "Argumentos de un extremo a otro en el diseño de sistemas". Transacciones ACM en sistemas informáticos, 2(4), 1984.
[18] JH Saltzer y MD Schroeder. "La Protección de la Información en los Sistemas Informáticos". Actas del IEEE, 63(9), 1975.
[19] ME Conway. "¿Cómo inventan los comités?" Datamation, 14(5), 1968. (Fuente de la Ley de Conway).
[20] RM Lee, MJ Assante y T. Conway. Análisis del ciberataque a la red eléctrica de Ucrania. SANS ICS / E-ISAC, 2016.
[21] N. Falliere, L. O. Murchu y E. Chien. W32.Stuxnet Dossier. Symantec Security Response, 2011.
[22] M. Krotofil y J. Larsen. "Sacudiendo el libro de bolsillo: pirateando plantas químicas". DEF CON 23, 2015.
[23] J. Slowik. Evolución de los ataques ICS y perspectivas de futuros eventos disruptivos. Dragos, 2019.
[24] E. Byres, A. Ginter y J. Langill. How Stuxnet Spreads — A Study of Infection Paths in Best Practice Systems. Tofino Security / Abterra / SCADAhacker, 2011.
[25] NG Leveson. Ingeniería para un mundo más seguro: pensamiento sistémico aplicado a la seguridad. MIT Press, 2011. (Tratamiento fundamental de la seguridad como problema de control).
[26] J. Razón. Error humano. Cambridge University Press, 1990. (Fuente del modelo de causalidad de accidentes del "queso suizo", relevante para el análisis de fallas de OT).
[27] Sociedad Internacional de Automatización. ANSI/ISA-95.00.01: Integración del sistema de control empresarial - Parte 1: Modelos y terminología. 2010.
[28] R.Anderson. Ingeniería de seguridad: una guía para construir sistemas distribuidos confiables. 3.ª ed., Wiley, 2020. (Capítulos sobre seguridad de sistemas de control).
[29] Serie Técnica Modibus. "El caso de los contenedores en la industria: por qué Docker es la base adecuada para el software industrial moderno". 2026.
[30] Serie Técnica Modibus. "MQTT vs OPC UA: ¿Qué protocolo para qué datos?" 2026.
Este artículo es parte de la serie técnica Modibus. Modibus diseña el nivel de puerta de enlace: la capa de demarcación arquitectónica en la que los dominios de OT y TI se encuentran bajo control explícito. La plataforma MB213 admite los patrones de flujo de datos asimétricos, las primitivas de mediación y las herramientas operativas descritas en la Sección 6. Para discusiones técnicas o consultas sobre la plataforma, comuníquese con [info@modibus.com](mailto:info@modibus.com).