Migración de PLCs antiguos
y SCADA obsoleto: metodología

¿Por qué migrar es urgente?

Hay miles de plantas industriales en Chile y Latinoamérica que hoy mismo están siendo controladas por equipos que llevan 20, 30 o incluso 40 años en servicio: Allen-Bradley PLC5 y SLC500, Siemens S5, GE Series 90, sistemas SCADA corriendo sobre Windows XP o Windows 2003 sin parches de seguridad desde hace una década.

Los gerentes de planta conocen el riesgo pero lo postergan: migrar parece caro, complejo y riesgoso. Hasta que el PLC falla y no hay repuestos. Hasta que el disco duro del servidor SCADA colapsa y el backup tiene 3 años. Hasta que un ransomware entra por el Windows XP sin parches y detiene la producción por semanas.

Los riesgos reales de no migrar

Riesgo de continuidad operacional

Un PLC5 o SLC500 que falla hoy puede tomar semanas en reponerse — si es que se consigue el repuesto. Allen-Bradley discontinuó el PLC5 hace años. Los módulos se consiguen en mercados secundarios con stock incierto y sin garantía de funcionamiento. Una falla de CPU en una planta continua puede significar millones de dólares en producción perdida mientras se espera un repuesto que quizás no llega.

Riesgo de ciberseguridad

Windows XP no recibe parches de seguridad desde 2014. Un servidor SCADA sobre Windows XP conectado a cualquier red — aunque sea solo para enviar reportes por email — es una puerta abierta para ransomware y ataques dirigidos. Los incidentes de ciberseguridad en sistemas OT con infraestructura obsoleta crecen año a año en Latinoamérica.

Riesgo de conocimiento

El ingeniero que programó el PLC5 en 1995 ya se jubiló. La documentación está en papel amarillento o directamente no existe. El conocimiento del sistema vive solo en la memoria de una o dos personas. Cuando esas personas se van, el sistema se vuelve inmantenible.

Riesgo regulatorio

En sectores como alimentos, farmacéutica, agua potable y energía, las auditorías regulatorias cada vez más exigen evidencia de que los sistemas de control están mantenidos y actualizados. Un SCADA sobre Windows XP sin soporte puede comprometer certificaciones.

Caso real: Aceros de Guatemala

Grupo Salba ejecutó un proyecto de migración completa en la planta de fragmentado de Aceros de Guatemala que ilustra perfectamente la metodología correcta.

Situación inicial

La planta operaba con un PLC SLC500 de Allen-Bradley controlando el proceso de fragmentado de chatarra — uno de los procesos más críticos e intensivos de la operación. El sistema SCADA era Cimplicity versión 6.x corriendo sobre un servidor con sistema operativo obsoleto, sin soporte del fabricante y sin posibilidad de actualización de seguridad.

Adicionalmente, el sistema incorporaba 10 silos de almacenamiento con identificación por TAGs RFID, pesaje dinámico integrado y un Historian en base de datos MySQL para trazabilidad de materiales.

Objetivos del proyecto

• Migrar el PLC SLC500 a RX3i de GE (ahora Emerson) — plataforma moderna con soporte vigente y mayor capacidad de procesamiento
• Actualizar el SCADA de Cimplicity 6.x a versión 10.x — manteniendo toda la funcionalidad existente y agregando capacidades modernas
• Mantener la integración RFID y el sistema de pesaje dinámico
• Minimizar el tiempo de detención de la planta — el fragmentado no puede parar más de lo estrictamente necesario

Metodología de migración: las 6 fases

La ingeniería de migración que aplicamos en Aceros de Guatemala — y que replicamos en cada proyecto — sigue una metodología de 6 fases diseñada para minimizar el riesgo operacional.

Fase 1 — Levantamiento exhaustivo del sistema existente

Antes de tocar una línea de código o un módulo de hardware, documentamos completamente el sistema actual. Esto incluye el relevamiento completo del programa PLC (ladder, function blocks, datos, configuración de I/O), el inventario de todas las pantallas y objetos del SCADA, el mapeo de señales entre PLC y SCADA, la documentación de todas las interlocks de seguridad, y el registro de los valores de proceso normales para cada variable.

En muchos proyectos de migración, esta fase revela sorpresas: lógica no documentada, workarounds acumulados durante años, y funcionalidades que nadie recuerda exactamente para qué sirven pero que "siempre han estado ahí". Todo esto debe ser comprendido antes de migrar.

Fase 2 — Diseño de la arquitectura destino

Con el sistema actual completamente documentado, se diseña la arquitectura del sistema nuevo. Para Aceros de Guatemala esto implicó:

• Mapeo completo de señales SLC500 → RX3i, incluyendo módulos de I/O equivalentes
• Conversión de la lógica Ladder de RSLogix 500 a Proficy Machine Edition (entorno de programación del RX3i)
• Diseño de la nueva arquitectura de red industrial (Ethernet industrial vs. DH+ original)
• Plan de migración de base de datos Cimplicity: puntos, alarmas, tendencias, scripts
• Estrategia de mantenimiento de la integración RFID con el nuevo SCADA

Fase 3 — Estrategia de corte y ventana de mantenimiento

Esta es la fase más crítica desde el punto de vista operacional. El objetivo es diseñar una estrategia de migración que permita realizar el corte del sistema antiguo e inicio del sistema nuevo en la ventana de mantenimiento disponible — que en el caso de Aceros de Guatemala era muy acotada dado que el fragmentado opera prácticamente las 24 horas.

La estrategia de corte define:

• Preparación previa al corte — todo lo que puede hacerse sin detener la planta: instalación del hardware nuevo en paralelo, configuración del nuevo SCADA, pruebas de comunicación fuera de línea
• Secuencia de corte — el orden exacto de pasos durante la ventana de mantenimiento, con tiempo asignado a cada acción
• Plan de rollback — qué hacer si algo falla durante el corte y es necesario volver al sistema antiguo
• Criterios de go/no-go — condiciones mínimas que deben cumplirse antes de autorizar el arranque con el sistema nuevo

Fase 4 — Desarrollo y pruebas fuera de línea

El nuevo programa PLC y el nuevo SCADA se desarrollan y prueban completamente antes de llegar a la planta. Usamos simuladores de proceso y entornos de prueba que replican las condiciones reales para validar toda la lógica, todas las alarmas y todas las interlocks de seguridad sin riesgo para la producción.

En el caso del RX3i, el entorno Proficy Machine Edition permite simular la ejecución del programa PLC en la misma estación de ingeniería. Para el SCADA Cimplicity 10.x, creamos un entorno de prueba completo con datos simulados que permite validar cada pantalla, cada alarma y cada script antes del corte.

Fase 5 — Ejecución del corte en ventana de mantenimiento

Con toda la preparación completada, la ejecución del corte sigue la secuencia definida en la Fase 3 al pie de la letra. El equipo de migración está en planta, el equipo de producción está disponible, y se ejecuta el plan paso a paso con verificación en cada etapa antes de continuar.

Para Aceros de Guatemala, el corte incluyó: desconexión controlada del SLC500, instalación del rack RX3i en el mismo espacio físico, reconexión del cableado de campo, descarga del programa validado, arranque supervisado del proceso de fragmentado con el nuevo sistema, y verificación de la integración RFID y pesaje dinámico.

Fase 6 — Validación, documentación y traspaso

Una vez que el sistema nuevo está operativo, el trabajo no termina. Se realiza un período de validación operacional — típicamente 2 a 4 semanas — donde el equipo de ingeniería de Grupo Salba está disponible para resolver cualquier situación que no se presentó durante las pruebas. Al cierre, se entrega documentación técnica completa del sistema nuevo y se capacita al personal de mantenimiento.

PLCs antiguos y sus equivalentes modernos

Migración de SCADA: consideraciones específicas

La migración de SCADA presenta desafíos adicionales a la del PLC, porque el SCADA acumula años de desarrollo: cientos o miles de pantallas, configuraciones de alarmas, scripts de lógica, reportes, tendencias históricas y configuraciones de comunicación con múltiples dispositivos.

Cimplicity 6.x a 10.x — lecciones del proyecto Guatemala

La migración de Cimplicity versión 6.x a 10.x en Aceros de Guatemala presentó desafíos específicos porque entre esas versiones hubo cambios importantes en la arquitectura del producto. Los puntos de proceso, las pantallas CimEdit y los scripts Basic se pudieron migrar con las herramientas de importación del fabricante, pero requirieron revisión y ajuste manual en varios casos. La integración con la base de datos MySQL para el Historian fue uno de los puntos que requirió más trabajo de validación.

La lección principal: nunca asumir que la migración de versiones del mismo SCADA es automática. Siempre hay elementos que requieren reconfiguración manual, especialmente en integraciones con sistemas externos y en scripts con lógica compleja.

Migración a plataformas modernas abiertas

Cuando el SCADA a migrar es muy antiguo o el costo de licencias de la versión nueva es prohibitivo, la migración a Ignition (Inductive Automation) es una alternativa poderosa. Su modelo de licencia por servidor — sin costo por número de clientes ni de tags — y su arquitectura web moderna la hacen especialmente atractiva para proyectos de modernización integral.

¿Cuándo migrar y cuándo esperar?

No todo sistema obsoleto requiere migración inmediata. La decisión debe basarse en una evaluación de riesgo que considere:

• Disponibilidad de repuestos — ¿existe stock? ¿por cuánto tiempo más?
• Criticidad del proceso — ¿cuánto cuesta una hora de parada de este equipo?
• Exposición a ciberseguridad — ¿el sistema está conectado a alguna red?
• Estado del conocimiento — ¿existe documentación? ¿hay personas que lo conocen?
• Planes de expansión — ¿se planea agregar capacidad o funcionalidades?

Un sistema PLC5 completamente aislado, bien documentado y con stock de repuestos puede operar algunos años más con bajo riesgo. Un SLC500 conectado a red corporativa, sin documentación y cuyos repuestos ya no se consiguen, necesita migración ahora.