Una de las razones más evidentes para considerar la modernización de Legacy SCADA es cuando el fabricante anuncie el End of Life de la versión instalada.
AVEVA, al igual que otros fabricantes, tiene ciclos de vida para sus productos. Cuando una versión deja de contar con soporte, mantenerla en operación comienza a introducir diferentes riesgos relacionados con compatibilidad, mantenimiento y capacidad de recuperación.
La decisión, sin embargo, rara vez es rápida.
En nuestra experiencia hemos visto sistemas que continúan operando años después de que se conoce su End of Life. Y existe una razón de peso: la modernización de Legacy SCADA puede necesitar una inversión importante y requiere tomar decisiones más allá que la versión del software.
Un sistema SCADA puede llevar muchos años operando y continuar realizando el trabajo para el que fue diseñado.
Pero que continúe funcionando no significa que continúe respondiendo a las necesidades actuales de la operación.
Por eso, la pregunta responsable no debería ser:
¿Qué tan viejo es nuestro sistema SCADA?
Sino:
¿El sistema actual continúa siendo funcional, ciberseguro y adecuado para las necesidades de la operación?
El End of Life es una señal evidente. Pero existen otras condiciones técnicas que también pueden indicar que llegó el momento de una modernización.
1. El software y los sistemas operativos llegan al final de su ciclo de vida
Es probablemente la señal más visible.
Una solución SCADA puede durante años funcionar sobre una versión antigua del software o del sistema operativo. El problema aparece cuando los fabricantes dejan de proporcionar soporte o cuando las nuevas versiones de otros componentes dejan de ser compatibles con la plataforma existente.
En ese momento, un upgrade es el camino a seguir, y sabes que un upgrade no es una simple actualización de software.
Puede involucrar el sistema operativo, hardware, servidores, estaciones de operación e ingeniería, licenciamiento, drivers, bases de datos, Historian y otros componentes relacionados.
El riesgo tampoco consiste solamente en que el sistema falle, que la planta pare.
También considerar qué ocurrirá cuando sea necesario intervenirlo.
2. Mantener el sistema comienza a ser cada vez más difícil
La obsolescencia también puede manifestarse en la capacidad para mantener y recuperar el sistema.
Un Legacy SCADA puede depender de servidores que necesitan reemplazo, hardware que ya no se fabrica, componentes descontinuados, licencias heredadas o conocimiento técnico concentrado en unas cuantas personas.
Mientras el sistema funciona, estas condiciones pueden omitirse.
La situación cambia cuando ocurre una falla.
Entonces aparecen preguntas importantes:
¿Existen respaldos actualizados y comprobados? ¿Podemos reconstruir un servidor? ¿Tenemos los drivers, configuraciones y licencias necesarios? ¿Existe hardware de reemplazo compatible? ¿Cuánto tiempo tomaría recuperar la operación?
En este punto, la obsolescencia deja de ser solamente un problema técnico y se convierte en un problema de mantenimiento y continuidad operativa.
3. Comienzan a aparecer problemas de compatibilidad
Éste es uno de los aspectos más importantes al momento de evaluar un Legacy SCADA.
Un sistema SCADA no envejece como una sola pieza. Sus componentes tienen ciclos de vida diferentes.
El sistema operativo, servidores, estaciones, software SCADA, Historian, PLC, drivers, firmware, switches, protocolos y aplicaciones de terceros pueden pertenecer a distintas generaciones tecnológicas, por lo tanto tiempos de obsolescencia distintos.
Actualizar uno de estos componentes puede generar incompatibilidades con otros que todavía permanecen en operación.
Por esta razón, antes de una modernización o upgrade es importante identificar las dependencias del sistema y desarrollar una matriz de compatibilidad.
Esto permite determinar qué componentes pueden conservarse, cuáles necesitan actualizarse y cuáles realmente deberán reemplazarse.
En proyectos de modernización, este trabajo previo puede involucrar el inventario de versiones, firmware, licencias y comunicaciones, así como la evaluación de compatibilidad de scripts, objetos, alarmas, drivers y otras dependencias antes de definir la arquitectura futura.
4. Las comunicaciones comienzan a limitar al SCADA
Un problema en el SCADA no siempre está en el SCADA.
Pérdidas de información, tiempos de respuesta, interrupciones o dificultades para integrar nuevos sistemas pueden tener su origen en la infraestructura de comunicaciones.
Con el tiempo, una red industrial también evoluciona, y paradójicamente se implementan más rápido.
Se incorporan nuevos switches, enlaces, equipos, segmentos de red, accesos remotos y dispositivos que quizá no formaban parte de la arquitectura original.
Por eso la modernización de Legacy SCADA también puede requerir revisar la topología de red, capacidad de los enlaces, redundancia, segmentación, protocolos, direccionamiento y comunicaciones entre los diferentes componentes del sistema.
Actualizar el software SCADA no resolverá una infraestructura de comunicaciones que se ha convertido en una limitación para la operación.
5. Las necesidades de Operaciones cambiaron, pero el SCADA no
Esta condición puede ser menos evidente que la obsolescencia tecnológica.
La instalación cambia con el tiempo, por lo tanto sus requerimientos.
Se incorporan equipos, se modifican procesos, aumenta la cantidad de información disponible y aparecen nuevas necesidades de análisis, reportes, administración de alarmas, almacenamiento histórico, acceso remoto o integración con otros sistemas.
Mientras tanto, el SCADA puede continuar realizando correctamente las funciones para las que fue diseñado originalmente.
El problema es que operar correctamente no significa responder a las necesidades actuales de Operaciones.
La modernización de Legacy SCADA puede surgir porque la operación necesita capacidades que la arquitectura existente ya no puede proporcionar.
6. La ciberseguridad ya no puede resolverse con parches
Muchos sistemas SCADA heredados fueron diseñados cuando los criterios actuales de ciberseguridad industrial no formaban parte de los requerimientos originales.
Posteriormente pueden haberse incorporado firewalls, VLAN, VPN, antivirus, controles de acceso y otras medidas.
Cada una puede resolver una necesidad determinada.
Sin embargo, llega un punto en que es necesario evaluar si estas medidas continúan siendo suficientes o si la arquitectura OT necesita evolucionar.
La ciberseguridad deja entonces de ser un componente agregado al sistema y comienza a formar parte de las decisiones de arquitectura de una modernización.
7. Las inversiones parciales dejan de resolver el problema
Ésta puede ser una de las señales más interesantes.
Durante el ciclo de vida de un sistema SCADA es normal realizar modificaciones.
- Se reemplaza un servidor.
- Se actualiza una licencia.
- Se cambia un switch.
- Se agrega un enlace de comunicaciones.
- Se incorpora una estación. Se modifica una aplicación.
Cada intervención puede estar técnicamente justificada de manera individual.
Pero después de varios años podemos terminar con una especie de “Frankenstein tecnológico”: diferentes generaciones de hardware, software, sistemas operativos, drivers, protocolos y equipos que continúan funcionando, pero cuya compatibilidad y mantenimiento son cada vez más difíciles de garantizar.
Seguir realizando inversiones aisladas puede dejar de ser la alternativa más conveniente.
Es entonces cuando resulta necesario evaluar el sistema completo.
Entonces, ¿es momento de iniciar la modernización de Legacy SCADA?
No necesariamente.
La modernización de Legacy SCADA puede esperar y el SCADA continuar siendo una plataforma válida si resuelve las necesidades actuales de la operación, se le puede dar mantenimiento adecuadamente, sus riesgos son conocidos y aceptables y existe un protocolo de recuperación ante fallas.
Legacy no significa automáticamente reemplazo.
Ésta es precisamente la razón por la que una decisión de modernización no debería comenzar seleccionando una nueva plataforma, haciendo una lista de servidores o solicitando una cotización de licencias.
Antes necesitamos responder cuatro preguntas:
- ¿Qué podemos conservar?
- ¿Qué debemos corregir?
- ¿Qué necesitamos actualizar?
- ¿Qué realmente debemos reemplazar?
Antes de modernizar: conocer el AS-IS
Para tomar esas decisiones necesitamos conocer el estado actual del sistema.
Un SCADA GAP Analysis permite documentar el AS-IS y evaluar diferentes componentes de la arquitectura para identificar las brechas existentes y determinar su impacto en la operación.
El proceso puede representarse como:
AS-IS → Requisitos y referencias → GAPs → Criticidad → TO-BE → Mitigación → Prioridades de inversión
El resultado no debería ser simplemente una lista de problemas.
Cada GAP debe ayudar a determinar una acción: corregir, actualizar, modernizar, mitigar un riesgo o, cuando sea necesario, reemplazar un componente.
De esta manera, el análisis puede convertirse en la base para definir el alcance de un proyecto de modernización del SCADA.
Modernizar no significa reemplazar todo
Ésta quizá sea la conclusión más importante.
Un proyecto de modernización no debería tener como objetivo justificar el reemplazo de la mayor cantidad posible de componentes.
Debería determinar qué necesita cambiar para que el sistema pueda continuar respondiendo a las necesidades operativas y de proceso durante los próximos años..
Por eso, antes de cotizar una migración, preferimos determinar qué realmente necesita migrarse.
Mantener, modernizar o reemplazar un SCADA son decisiones de inversión y de posibles costos de producción.