En una empresa de servicios públicos, la frontera entre TI y TO no es una línea definida en un diagrama de red. Es una membrana permeable a través de la cual fluyen datos en ambas direcciones: programas por lotes COBOL que generan archivos de configuración de puntos de ajuste que son utilizados por los PLC; programas RPG que leen datos del historial SCADA para la facturación y la elaboración de informes regulatorios; puentes C heredados que traducen las salidas de los mainframes a formatos que los sistemas de control distribuido comprenden; y flujos de trabajos JCL que programan y secuencian los intercambios de datos a través de la frontera, según la sincronización de la que dependen los procesos operativos. El software que gestiona este flujo no es ni puramente TI ni puramente TO. Es el tejido conectivo que permite el funcionamiento de las empresas de servicios públicos, y es la categoría de código que los equipos de modernización están menos preparados para analizar cuando comienza un programa de transformación.
El sector energético está experimentando una de las transformaciones digitales más significativas de su historia. A medida que las empresas de servicios públicos modernizan su infraestructura con redes inteligentes, subestaciones conectadas, sistemas de control industrial (ICS) y automatización avanzada, las redes de tecnología operativa (OT) se han vuelto más interconectadas que nunca. Esta interconexión no elimina la capa de código heredado, sino que la hace más crítica, ya que cada nuevo punto final de la red inteligente y plataforma de análisis en la nube depende de flujos de datos que se originan en aplicaciones escritas hace décadas. Modernizar esas aplicaciones sin comprender su función en la cadena de datos operativa no es una modernización, sino una disrupción con consecuencias que se extienden más allá del centro de datos hasta la infraestructura física.
Encuentra todos los parámetros operativos codificados
SMART TS XL Localiza todas las constantes de la UE, los límites de alarma y las direcciones de protocolo integrados en su cartera de código heredado.
DESCUBRE MÁS…Qué significa realmente “SCADA-Adyacente”
El término «adyacente a SCADA» describe el software del lado de TI que interactúa con los sistemas de tecnología operativa, no el software SCADA en sí, ni el firmware del PLC, ni el código integrado de la RTU, sino la capa de aplicaciones empresariales que introduce y recibe datos de dichos sistemas. Esta categoría es amplia, poco analizada y genuinamente diferente del resto del portafolio de aplicaciones empresariales.
En un entorno típico de servicios públicos, el código adyacente a SCADA incluye:
Programas de cálculo de caudal y punto de consigna. Programas en COBOL y PL/I que calculan puntos de consigna de carga, objetivos de voltaje, umbrales de presión y límites operativos, y que se entregan a los sistemas SCADA como archivos de configuración o flujos de datos directos. Estos programas codifican los requisitos de cumplimiento normativo, las especificaciones de ingeniería y los límites de seguridad física. Un cálculo incorrecto no produce un valor erróneo en un informe, sino un punto de consigna operativo incorrecto sobre el que actúa el sistema de control.
Consumidores de datos del sistema de registro histórico. Programas RPG y COBOL que leen datos operativos de las bases de datos del sistema de registro histórico SCADA para facturación, informes regulatorios y análisis de rendimiento. Estos programas dependen de formatos de datos, convenciones de marcas de tiempo y definiciones de unidades de ingeniería específicas que genera el sistema de registro histórico. Un cambio de formato en la salida del sistema de registro histórico, o un cambio en el programa del sistema de TI, puede provocar errores implícitos en los cálculos de facturación o en las presentaciones regulatorias.
Programas puente de protocolo. Programas personalizados en C que traducen entre formatos de salida de mainframe y las interfaces basadas en archivos o en red que utilizan los sistemas DCS (Sistema de Control Distribuido) y SCADA. Estos puentes implementan protocolos específicos, como Modbus, DNP3, IEC 61850 y formatos propietarios de proveedores, y presentan suposiciones predefinidas sobre la estructura del mensaje, el orden de los bytes y la temporización que no aparecen en la documentación.
Rutas de datos de procesamiento por lotes a tiempo real. Flujos de trabajos JCL que programan y secuencian intercambios de datos entre los entornos de TI y OT en ventanas de tiempo específicas. La ejecución nocturna de un proceso por lotes de una empresa de servicios públicos puede generar datos de configuración que deben estar disponibles para el sistema SCADA antes de que comiencen las operaciones matutinas. Esta dependencia temporal está implícita en la configuración del programador y en las expectativas operativas de la sala de control, y no está documentada en el código de la aplicación.
Programas de procesamiento de alarmas y eventos. Estos programas reciben registros de alarmas de los sistemas SCADA, aplican lógica de clasificación y enrutamiento, generan órdenes de trabajo y producen registros de cumplimiento normativo. La lógica de clasificación de alarmas, que determina qué eventos requieren qué informes normativos y en qué plazos, suele estar integrada en el código del programa, que ha acumulado décadas de cambios normativos.
Este es el código que controlan tanto los ingenieros como los desarrolladores de TI, quienes lo poseen parcialmente pero ninguno lo comprende del todo. Cuando un programa de modernización pregunta "¿qué podemos cambiar?", la respuesta para el código relacionado con SCADA es casi siempre "menos de lo que crees, y solo después de un análisis más exhaustivo del previsto".
Por qué falla aquí el análisis de modernización estándar
La mayoría de los marcos de análisis de modernización empresarial parten de la base de que el código analizado controla únicamente los datos y la lógica empresarial, y que un cambio en un programa produce un resultado de datos diferente sin consecuencias en el mundo físico. El código asociado a SCADA rompe esta suposición de cuatro maneras específicas.
Consecuencias físicas de los errores de datos
En una aplicación de facturación estándar, un cálculo incorrecto genera una factura errónea. El error es detectable, reversible y de alcance limitado. En el código asociado a SCADA, un cálculo incorrecto puede generar un punto de ajuste erróneo, un valor objetivo sobre el cual actúa un sistema de control ajustando parámetros físicos como la presión, el voltaje, el caudal y la temperatura. La consecuencia no es un dato incorrecto en la base de datos, sino un proceso físico que se ejecuta fuera de sus parámetros previstos, con consecuencias que van desde la ineficiencia y el daño a los equipos hasta incidentes de seguridad.
Esta asimetría entre el error de datos y la consecuencia física es la razón fundamental por la que el código asociado a SCADA no puede analizarse con la misma tolerancia al riesgo que el código empresarial estándar. Un cambio que «funciona correctamente» desde la perspectiva de producir una salida válida aún puede producir una salida operacionalmente incorrecta, dentro del rango legal del tipo de datos, sintácticamente válida, pero físicamente errónea para el contexto operacional que representa.
Dependencias temporales que el análisis estático no puede modelar
Los programas informáticos adyacentes a los sistemas SCADA suelen tener restricciones de tiempo que, si bien son operativamente importantes, resultan invisibles para las herramientas de análisis estático. Un programa que genera datos de configuración debe completarse antes de que el ciclo de sondeo del sistema SCADA los lea. Un proceso por lotes que agrega datos históricos debe finalizar antes de la marca de tiempo de fin de intervalo que exigen los informes reglamentarios. Un programa puente que transmite alarmas debe procesar los eventos dentro del tiempo de respuesta especificado en los procedimientos operativos de la sala de control.
Estas limitaciones de tiempo existen en los procedimientos operativos de la utilidad, en la configuración del planificador y en el entendimiento implícito de los desarrolladores que escribieron los programas, no en el código fuente. Las herramientas de análisis estático que se centran en la estructura del código y el flujo de datos no tienen visibilidad de los requisitos de tiempo que existen fuera del propio código.
La implicación práctica es que el análisis de modernización del código asociado al sistema SCADA debe documentar explícitamente el contexto temporal de cada programa incluido en su alcance. Esto requiere conocimiento operativo, entrevistas con los operadores de la sala de control, revisión de los cronogramas de cumplimiento normativo y análisis de las dependencias de las tareas del planificador, además del análisis del código.
Identificación de la función de seguridad
Las normas IEC 61511 (seguridad funcional para sectores de la industria de procesos) e IEC 61508 (seguridad funcional para sistemas eléctricos, electrónicos y electrónicos programables relacionados con la seguridad) definen los requisitos de certificación para el software que realiza funciones de seguridad. El código certificado según estas normas no es simplemente código heredado que se pueda refactorizar para facilitar su mantenimiento. La certificación se refiere a artefactos de código específicos, a la versión específica del binario que evaluó el organismo certificador. Modificar el código, incluso para corregir un problema de calidad que no sería relevante en una aplicación comercial, invalida la certificación y requiere una nueva certificación antes de que el código modificado pueda implementarse en una función de seguridad.
Muchas empresas de servicios públicos cuentan con programas auxiliares para SCADA que realizan cálculos relacionados con la seguridad, detección de sobrepresión, cálculo de puntos de ajuste de protección de transformadores y lógica de parada de emergencia. Estos programas pueden estar sujetos a requisitos de certificación de seguridad sin que el equipo de modernización de TI lo sepa. La primera pregunta que se plantea al analizar el código auxiliar para SCADA es: ¿alguna de estas funciones cumple una función de seguridad? En caso afirmativo, ¿qué funciones, bajo qué certificación y qué implica su modificación?
Acoplamiento de hardware y protocolo
Los programas de puente de protocolo y el código de interfaz integrado dependen directamente del hardware y las versiones de protocolo que implementan. Un programa que implementa Modbus RTU con códigos de función, mapas de registros y valores de tiempo de espera específicos para un modelo de RTU concreto de un proveedor determinado no implementa Modbus de forma genérica, sino que implementa esa combinación específica, con supuestos que podrían no ser válidos para cualquier otra configuración.
Al analizar este código para su modernización, la dependencia no se limita al código fuente COBOL o C, sino que también abarca el modelo del dispositivo RTU, la versión del firmware, la topología del cableado físico y la configuración de la red. Cualquier modificación en estos elementos puede provocar fallos en la interfaz, incluso si el código fuente del programa permanece inalterado. Además, los cambios en el código fuente pueden afectar a interfaces aparentemente no relacionadas, ya que el puente se diseñó para compensar peculiaridades del protocolo específicas del proveedor que no están documentadas.
La frontera entre TI y TO: dónde reside el código
El modelo Purdue (ISA-99 / IEC 62443) define la arquitectura conceptual de las redes de sistemas de control industrial en cinco niveles, desde los procesos físicos en el Nivel 0 hasta los sistemas empresariales en el Nivel 4. El código heredado adyacente a SCADA en entornos de servicios públicos normalmente reside en los Niveles 3 y 4, las zonas de operaciones de fabricación y de red empresarial, pero sus flujos de datos cruzan al Nivel 2 (la capa de supervisión de SCADA) en ambas direcciones.
La frontera entre TI y TO, entre los niveles 3 y 2, es donde el riesgo operativo y de seguridad es mayor. Actores estatales se infiltran en las redes TO meses antes de su activación, mientras que los grupos de ransomware ahora despliegan cargas útiles con reconocimiento de sistemas de control industrial (ICS) diseñadas para bloquear las interfaces hombre-máquina (HMI) e interrumpir la producción. El punto de entrada más frecuente no es el software SCADA integrado, sino la capa límite entre TI y TO, donde el código de TI y los sistemas de TO intercambian datos a través de interfaces diseñadas para la fiabilidad operativa, no para la seguridad frente a ataques.
Comprender el conjunto exacto de programas que cruzan este límite, y qué hacen allí, es un requisito previo tanto para la planificación de la modernización como para la mejora de la postura de seguridad. Un programa que lee datos de un historiador SCADA y escribe los resultados en una base de datos de facturación cruza el límite en una dirección. Un programa que calcula puntos de ajuste y los escribe en un directorio de configuración que lee un PLC lo cruza en la otra. Ambos están relacionados con SCADA. Ninguno aparece en un análisis de red SCADA ni en un inventario de aplicaciones de TI, razón por la cual se analizan sistemáticamente de forma insuficiente.
Patrones de código específicos para programas relacionados con SCADA
Código de cálculo de unidades de ingeniería
Los cálculos de unidades de ingeniería (UE) convierten los valores brutos de los sensores, generalmente recuentos enteros de convertidores analógico-digitales, en mediciones físicas con unidades, rangos y precisión específicos. Un bucle de corriente de 4-20 mA de un transmisor de presión produce un recuento bruto; el cálculo de UE lo convierte a PSI o bar con la calibración correcta de cero y rango.
Este código de cálculo tiene características que lo distinguen de la lógica empresarial estándar:
cobol
CALCULATE-PRESSURE-EU.
* RAW-COUNT ranges 0-4095 (12-bit ADC)
* SENSOR-ZERO-OFFSET = 819 (4mA = 20% of 4095)
* SENSOR-SPAN = 3276 (16mA span = 80% of 4095)
* RANGE-LOW-PSI = 0
* RANGE-HIGH-PSI = 500
COMPUTE EU-PRESSURE-PSI =
(RAW-COUNT - SENSOR-ZERO-OFFSET) /
SENSOR-SPAN *
(RANGE-HIGH-PSI - RANGE-LOW-PSI)
+ RANGE-LOW-PSI
IF EU-PRESSURE-PSI < RANGE-LOW-PSI OR
EU-PRESSURE-PSI > RANGE-HIGH-PSI
MOVE 'RANGE-VIOLATION' TO ALARM-STATUS
PERFORM GENERATE-ALARM
END-IF.Las constantes en este cálculo, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSIEstos valores corresponden a las especificaciones del instrumento físico. Si están codificados de forma fija (como suele ocurrir en el código heredado), cualquier cambio en el instrumento físico requiere un cambio en el código. Si son incorrectos (debido a la recalibración, el reemplazo o la configuración original errónea del instrumento), el valor de la UE será sistemáticamente incorrecto para cada registro que el programa haya generado. El análisis estático permite identificar dónde se definen estas constantes; solo la validación operativa puede confirmar si son correctas para la configuración actual del instrumento.
Lógica de generación y clasificación de alarmas
El código de generación de alarmas se encuentra entre los códigos SCADA más sensibles a la normativa en entornos de servicios públicos. Las normas NERC CIP (Protección de Infraestructura Crítica) para empresas eléctricas, los requisitos de la NRC para instalaciones nucleares y los requisitos de notificación de la EPA para empresas de agua y aguas residuales especifican qué eventos deben generar alarmas, qué información deben contener dichas alarmas y en qué plazos deben notificarse.
cobol
CLASSIFY-ALARM.
EVALUATE TRUE
WHEN EU-PRESSURE-PSI > HIGH-HIGH-LIMIT
MOVE 'HH' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
WHEN EU-PRESSURE-PSI > HIGH-LIMIT
MOVE 'HI' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LIMIT
MOVE 'LO' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LOW-LIMIT
MOVE 'LL' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
END-EVALUATE.Los límites de alarma en este código, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMITEstos son parámetros operativos con relevancia regulatoria. Los cambios en estos límites afectan tanto el comportamiento operativo del sistema de control como las obligaciones de presentación de informes regulatorios de la empresa de servicios públicos. Cualquier programa de modernización que involucre el código de clasificación de alarmas debe someterse a una revisión regulatoria en su proceso de control de cambios, y no solo a la aprobación del departamento de ingeniería.
Implementaciones de Protocol Bridge
Los programas puente de protocolo heredados se encuentran entre los códigos adyacentes a SCADA más difíciles de modernizar, ya que sus dependencias son las más difíciles de enumerar. El programa implementa una versión específica de protocolo para un dispositivo específico, con comportamientos no documentados propios del proveedor que se compensan en el código.
c
/* Legacy Modbus RTU bridge -- written for Modicon 984 PLCs, circa 1998 */
/* NOTE: 984 series uses 1-based register addressing, not 0-based */
/* Function code 03 only -- 984 does not support FC 04 */
/* Max 60 registers per request -- 984 firmware limitation */
#define MODBUS_FC03_READ_HOLDING 0x03
#define MAX_REGS_PER_REQUEST 60 /* 984 firmware limit, not Modbus spec */
#define REGISTER_OFFSET 1 /* 984 uses 1-based addressing */
int read_holding_registers(int start_reg, int count, uint16_t *buffer) {
/* Compensate for 984 1-based addressing */
uint16_t adjusted_start = (uint16_t)(start_reg + REGISTER_OFFSET);
if (count > MAX_REGS_PER_REQUEST) {
/* 984 will return error if count exceeds 60 */
/* Split into multiple requests silently */
return read_registers_chunked(adjusted_start, count, buffer);
}
/* ... */
}Este código incluye cuatro supuestos sobre un modelo específico de PLC que no forman parte de la especificación Modbus: direccionamiento de registros basado en 1, solo el código de función 03, un máximo de 60 registros y el comportamiento de segmentación para solicitudes de mayor tamaño. Ninguno de estos supuestos aparece en la documentación de Modbus. Se trata de comportamientos específicos del fabricante Modicon 984, documentados en un manual de hardware de 1998 que podría no estar disponible. Si este puente se moderniza sin comprender estos supuestos, o si el PLC se reemplaza por un modelo más reciente que utiliza direccionamiento estándar basado en 0, cada lectura de registro devolverá un valor incorrecto con un desplazamiento de una dirección de registro.
Análisis de la premodernización: ¿Qué debe producirse?
Antes de modificar, refactorizar o reemplazar cualquier código relacionado con SCADA, el análisis debe generar un conjunto de resultados que vayan más allá de lo que proporciona un análisis estándar de modernización empresarial.
Inventario de funciones operativas. Cada programa relacionado con SCADA debe clasificarse según su función operativa: cálculo de unidades de control, suministro de puntos de consigna, consumo de datos históricos, generación de alarmas, puente de protocolo, conversión de procesamiento por lotes a tiempo real. Esta clasificación determina quién debe participar en el proceso de cambio: solo los ingenieros de TI o un equipo multidisciplinario que incluya ingenieros de control, personal de operaciones y cumplimiento normativo.
Mapa de cruce de límites TI/OT. Cada flujo de datos que cruza el límite TI/OT debe documentarse: qué programa genera los datos, en qué formato y con qué periodicidad; qué sistema OT los consume; y cuál es la consecuencia si los datos son incorrectos, se retrasan o faltan. Este mapa representa el perfil de riesgo operacional para la capa adyacente a SCADA.
Identificación de la función de seguridad. Cada programa debe evaluarse para determinar si cumple una función de seguridad según las normas IEC 61511, IEC 61508, NERC CIP u otras normas aplicables. Los programas identificados como código de función de seguridad requieren un control de cambios independiente, notificación regulatoria y, posiblemente, recertificación. El cronograma de modernización para estos programas es fundamentalmente diferente al del código empresarial estándar.
Registro de parámetros operativos predefinidos. Cada constante predefinida que representa un parámetro operativo, valores de calibración de sensores, límites de alarma, restricciones de protocolo o umbrales de temporización debe identificarse, documentarse con su significado operativo y validarse según las especificaciones actuales del instrumento. Este registro sirve como entrada para el proceso de gestión de la configuración, que reemplaza las constantes predefinidas con una configuración gestionada externamente.
Documentación de dependencias temporales. El contexto temporal de cada programa, los intervalos de tiempo en los que debe completarse, las dependencias del planificador que imponen dichos intervalos y los procedimientos operativos que dependen de su finalización deben documentarse explícitamente. Esta documentación constituye la especificación con la que debe validarse la implementación modernizada.
Especificación de protocolo e interfaz. Cada programa puente de protocolo debe analizarse para identificar comportamientos específicos del proveedor, supuestos sobre la versión del protocolo y compensaciones específicas del dispositivo. El resultado es un documento de especificación que puede utilizarse para validar una implementación de reemplazo, confirmando que se conservan todos los comportamientos compensatorios, incluso aquellos que no estaban incluidos en la especificación original.
Los enfoques de modernización que funcionan y los que no.
El patrón Strangler Fig, aplicado con cuidado, consiste en desarrollar nuevas funcionalidades junto con las antiguas, enrutarlas de forma incremental y desmantelarlas gradualmente. Este patrón es apropiado para el código asociado a SCADA que realiza procesamiento de datos en el lado de TI (consumidores de datos históricos, cálculos de facturación). El programa antiguo continúa ejecutándose durante la transición; la nueva implementación produce salidas paralelas que se validan para comprobar su equivalencia antes de que se retire el programa antiguo.
La figura del estrangulador no se aplica a las rutas en tiempo real. Para los programas que se encuentran en una ruta de datos en tiempo real, donde no existe una forma segura de ejecutar versiones antiguas y nuevas en paralelo, ya que producirían efectos operativos conflictivos, la transición debe ser instantánea y validarse fuera de línea antes de cualquier puesta en producción. Ejecutar un programa de cálculo de punto de consigna en paralelo que produzca valores diferentes a los del programa actual enviaría puntos de consigna conflictivos al sistema de control.
Externalización de la configuración antes de modificar el código. Para programas con parámetros operativos codificados, el primer paso más seguro para la modernización consiste en externalizar dichos parámetros a un archivo de configuración o base de datos sin modificar la lógica de cálculo. Esto permite visualizar, gestionar y auditar los parámetros sin alterar el código de cálculo relevante para el funcionamiento. El riesgo de externalizar parámetros es considerablemente menor que el de refactorizar la lógica de cálculo.
Código de funciones de seguridad: análisis y documentación, no refactorización. El código certificado en seguridad debe analizarse y documentarse durante la fase de planificación de la modernización, pero sus modificaciones deben posponerse a un programa de recertificación específico con coordinación regulatoria, y no abordarse como parte de una iniciativa general de modernización. El riesgo de invalidar una certificación de seguridad durante una modernización integral no se justifica por ningún beneficio típico de la modernización.
Cómo SMART TS XL Admite el análisis de código heredado adyacente a SCADA.
SMART TS XL, análisis de código estático Se aplica al lado de TI del límite adyacente a SCADA, los programas COBOL, JCL, RPG, PL/I y C que se ejecutan en mainframes y sistemas de gama media y generan, transforman o consumen datos que se transfieren a entornos OT. Para este código, el análisis estructural produce el inventario de funciones operativas y el registro de parámetros predefinidos que requiere el análisis previo a la modernización.
El mapeo de dependencias de la aplicación crea el mapa de cruce de límites TI/OT: cada programa que escribe en una interfaz de archivo consumida por un sistema SCADA, cada paso de trabajo JCL que produce datos con importancia de tiempo operativo, cada programa en la ruta de datos del historiador desde la fuente OT hasta el consumidor TI. Cuando un programa COBOL de facturación de una empresa de servicios públicos lee datos del historiador a través de un puente C intermedio, el mapa de dependencias representa tanto la dependencia de COBOL a C como la de C al historiador como una cadena conectada, lo que hace visible el cruce completo de TI/OT en lugar de que solo se pueda descubrir a través de un incidente operativo.
La capacidad de análisis de impacto es especialmente crítica para el código adyacente a SCADA, ya que permite determinar el alcance de cualquier cambio propuesto antes de su implementación. Una modificación a un programa de cálculo de la UE, compartido (mediante un archivo de copia) con el código de generación de alarmas, el código de entrega de puntos de consigna y el código de escritura del historiador, requiere comprender los tres impactos secundarios antes de modificar el cálculo. En el código empresarial estándar, un cambio incorrecto produce datos erróneos. En el código adyacente a SCADA, produce parámetros operativos erróneos.
La capacidad de expansión de JCL revela la estructura de temporización y secuenciación de la capa de procesamiento por lotes: qué trabajos se ejecutan y en qué orden, qué conjuntos de datos alimentan qué pasos subsiguientes y qué flujos de trabajos están sujetos a limitaciones de tiempo por requisitos operativos. Esta es la base estructural para la documentación de dependencias temporales que requiere la modernización de sistemas SCADA.
La capacidad de búsqueda empresarial permite escalar el registro de parámetros predefinidos: encuentra cada instancia de una constante de unidad de ingeniería específica, cada valor límite de alarma y cada dirección de protocolo predefinida en todos los artefactos COBOL, C, RPG y JCL del entorno, en segundos y a través de millones de líneas de código. Para las empresas de servicios públicos que gestionan cientos de miles de líneas de código heredado relacionado con SCADA, esta capacidad de búsqueda marca la diferencia entre una auditoría manual que lleva meses y un inventario automatizado que solo toma horas.
Para equipos de planificación modernización heredada de sistemas de servicios públicos, SMART TS XL Proporciona el análisis estructural del lado de TI que permite al equipo de modernización trabajar eficazmente junto con los ingenieros de control del lado de OT, quienes comprenden el contexto operativo. La frontera entre TI y OT no se cruza de forma segura ni por los equipos de TI ni por los de OT por separado; se cruza de forma segura cuando ambas partes poseen un conocimiento estructural preciso de lo que contienen sus sistemas.
Por qué este código exige un tipo de atención diferente
Las empresas de servicios públicos que modernizan su código heredado vinculado al sistema SCADA no se limitan a actualizar software antiguo. Están modificando la capa de software que actúa como enlace entre los sistemas empresariales y la infraestructura física. Las consecuencias de un error en este proceso no se limitan a errores de datos, interrupciones del servicio o pérdidas financieras, sino que afectan a los sistemas físicos que dan servicio a las personas que dependen de estos servicios para su funcionamiento.
Las características que hacen especial a este código —la consecuencia física de los errores de datos, las dependencias temporales invisibles al análisis estático, las restricciones de certificación de seguridad, el acoplamiento entre hardware y protocolo— no constituyen argumentos en contra de su modernización. Son argumentos a favor de comprenderlo completamente antes de realizar cualquier cambio. El marco de análisis de esta guía permite dicha comprensión. El programa de modernización resultante es más seguro porque el alcance del cambio se define mediante evidencia en lugar de suposiciones, las dependencias temporales se documentan en lugar de darse por implícitas, el código de la función de seguridad se identifica en lugar de modificarse accidentalmente, y las intersecciones entre TI y OT se mapean en lugar de descubrirse a través de incidentes operativos tras la implementación.
