Refactorización de una antigua aplicación industrial: ¿cuándo tiene sentido y cómo llevarla a cabo sin poner en riesgo la producción?

Por qué este tema es importante hoy

La refactorización de una aplicación industrial antigua ha dejado de ser una cuestión de estética del código o de comodidad de mantenimiento. Hoy es una decisión que afecta a la continuidad de la producción, a la previsibilidad de los costes y al alcance de la responsabilidad del propietario del sistema. En muchas plantas, las aplicaciones de control, las herramientas de operador y las capas de comunicación se han desarrollado durante años sin una arquitectura coherente, a menudo en torno a equipos, bibliotecas y mecanismos de integración cuyo soporte es limitado o ya ha finalizado. Esta situación puede tolerarse durante un tiempo, pero solo hasta el momento en que cada cambio adicional empieza a costar más que la propia funcionalidad que debe aportar. Entonces la pregunta ya no es si conviene intervenir en la aplicación antigua, sino si la organización sigue controlando su comportamiento en condiciones reales de producción.

La importancia de este tema radica en que, en los sistemas industriales, la deuda técnica se convierte muy rápidamente en deuda operativa. Si la aplicación es difícil de reproducir, depende de personas concretas, no dispone de pruebas de regresión fiables o su lógica mezcla funciones de producción con funciones de seguridad y diagnóstico, cualquier incidente resultará más costoso que un problema similar en un sistema de oficina. La consecuencia no es solo una parada. También hay que contar con el coste del trabajo de mantenimiento, el riesgo de aplicar soluciones provisionales erróneas bajo presión de tiempo, la dificultad para demostrar la diligencia debida tras el cambio y el problema de distinguir qué era un fallo previo y qué es consecuencia de la intervención del equipo del proyecto. Para un manager y para el propietario del producto, el criterio práctico es sencillo: si el tiempo y la incertidumbre asociados a la implantación de pequeños cambios crecen más deprisa que su valor de negocio, la aplicación ha entrado en un estado en el que la decisión de refactorizar debe tomarse de forma consciente, y no aplazarse hasta el primer fallo crítico.

La mayoría de los errores aparecen cuando la refactorización se trata como una modernización «sin impacto en el proceso», aunque en realidad cambia la forma en que el sistema toma decisiones. En la práctica, basta una intervención aparentemente menor: sustituir un componente de comunicación, rehacer la planificación de tareas, cambiar la lógica de almacenamiento en búfer de los datos de sensores o reorganizar la secuencia de arranque tras un reinicio. Sobre el papel, son ajustes técnicos. Pero en planta pueden alterar el momento en que se emite una señal, el orden de liberación de enclavamientos, la reacción ante una pérdida de comunicación o el comportamiento de la aplicación tras un corte de alimentación. Es precisamente aquí donde la cuestión de la refactorización pasa a ser una evaluación del riesgo de los cambios conforme a ISO 12100: no se trata de si el código es «mejor», sino de si, después del cambio, la máquina, la línea o el puesto siguen comportándose de forma previsible en estados normales, perturbados y tras la puesta en marcha de nuevo.

Una buena prueba de la madurez de la decisión es comprobar si el equipo sabe trazar la frontera entre un cambio en la estructura interna de la aplicación y un cambio en una función relevante para el proceso o para la seguridad. Si esa frontera no puede describirse a nivel de señales, estados y condiciones de transición, el proyecto está expuesto al riesgo con independencia de la calidad del proveedor. En el entorno industrial son especialmente sensibles las situaciones en las que la aplicación participa en la secuencia de arranque, parada, rearme de fallos, confirmación de alarmas o coopera con sistemas de corte de energía y enclavamientos. En ese momento ya no se plantea solo una cuestión de arquitectura de software, sino también de protección contra la puesta en marcha inesperada y de si el análisis abarca también la instalación eléctrica, la lógica de control y las dependencias entre equipos. Ese es precisamente el punto en el que una refactorización aparentemente local deja de ser una tarea informática y pasa a convertirse en un cambio técnico que exige un proceso de decisión completo.

La referencia a los requisitos normativos solo cobra importancia en esta fase, porque las normas no sustituyen la decisión de diseño, pero sí ordenan su alcance. Si el cambio puede influir en las condiciones de arranque, parada, recuperación del funcionamiento tras una perturbación o en las medidas de protección, debe evaluarse como un cambio de riesgo, y no como un simple mantenimiento del código. Si la intervención afecta a la lógica que interactúa con el corte de energía, los enclavamientos o la secuencia de acceso seguro, se abre de forma natural también el ámbito de requisitos relativos a la protección contra la puesta en marcha inesperada. Desde el punto de vista de la responsabilidad, por tanto, lo más importante no es solo «si refactorizar», sino si la organización puede demostrar que conoce los límites del cambio, dispone de criterios de aceptación basados en el comportamiento del proceso y sabe distinguir entre la reorganización del sistema y una modificación que requiere una evaluación completa del riesgo, así como la coordinación con el diseño de la instalación y las pruebas en campo.

Dónde suelen aumentar más los costes o el riesgo

El mayor aumento de coste al refactorizar una aplicación industrial antigua rara vez se debe al propio código. El origen del problema suele ser una clasificación errónea del cambio: el equipo lo trata como una reorganización de la estructura del programa, cuando en realidad se está modificando el comportamiento del sistema en el tiempo, el orden de las operaciones o las condiciones de transición entre estados. En un entorno productivo, este error tiene un efecto directo sobre el proyecto. El calendario deja de corresponderse con el alcance real, las pruebas se planifican para la funcionalidad informática y no para la evolución del proceso, y la responsabilidad sobre el resultado se diluye entre mantenimiento, automatización y el proveedor de software. El criterio práctico aquí es sencillo: si tras el cambio hay que volver a confirmar la secuencia de arranque, parada, reanudación del trabajo tras una perturbación o la respuesta a las señales de los circuitos de protección, entonces ya no se trata de una «refactorización segura» en sentido organizativo, sino de un cambio que puede generar riesgo para la producción y requerir un procedimiento de aprobación distinto.

La segunda área típica en la que se disparan los costes es una decisión de diseño tomada sin una visión completa de las dependencias. Las aplicaciones industriales antiguas suelen estar estrechamente entrelazadas con la configuración del controlador, los actuadores, la visualización, el archivado de datos y los procedimientos del operador. En la documentación parece un único sistema, pero en la práctica son capas desarrolladas durante años por equipos distintos. Una refactorización destinada a mejorar la legibilidad del código o facilitar el mantenimiento posterior puede alterar sin que se perciba el significado de los retardos, las condiciones de enclavamiento, los valores por defecto tras un reinicio o la forma de gestionar un error de comunicación. La consecuencia no es solo una corrección técnica, sino también el coste de las paradas, de las pruebas adicionales en planta y de las discusiones sobre si el defecto ya existía antes o fue introducido por el cambio. Por eso, antes de decidir, conviene evaluar no solo el tamaño de la modificación, sino también el número y la criticidad de los puntos de interfaz: cuántas señales, recetas, modos de funcionamiento y soluciones operativas provisionales dependen del fragmento de código que se pretende reconstruir. Cuantos más puntos de este tipo existan, menos sentido tiene una refactorización «de paso» al hilo de otra tarea.

En la práctica, resultan especialmente costosos los proyectos en los que el equipo descubre los requisitos reales solo durante la puesta en marcha. Un ejemplo típico es la reconstrucción de un módulo secuencial que, según la descripción, «hace lo mismo, solo que de forma más limpia». Sin embargo, tras la implantación se comprueba que la versión anterior contenía comportamientos no documentados que compensaban imperfecciones de la instalación: un breve mantenimiento de señal, tolerancia ante un sensor que llega tarde, un orden específico de rearme de alarma o una condición de la que depende el acceso de servicio. En el código parecía un error o deuda técnica, pero para el proceso era un elemento de estabilización. Si la refactorización elimina estos mecanismos sin identificar su función, el coste aparece de inmediato: aumenta el número de intervenciones tras la puesta en marcha, se alarga el tiempo de aceptación y hay que reconstruir la lógica bajo la presión del funcionamiento de la planta. Por eso, la conveniencia de una refactorización también debe evaluarse en función de la posibilidad de reproducir el comportamiento del sistema actual. Si la organización no dispone de un registro de eventos, descripciones fiables de los modos de funcionamiento y escenarios de prueba basados en el proceso real, primero hay que crear esa base de evaluación y solo después tomar la decisión de reconstruir.

Esta cuestión conduce directamente a una evaluación práctica del riesgo de los cambios cuando la modificación afecta a funciones de protección, secuencias de acceso seguro, control del movimiento de los actuadores o al comportamiento de la instalación tras la pérdida y el retorno de la alimentación. En este ámbito, el coste de un error no se limita a las correcciones de programación, porque también entra en juego la responsabilidad por autorizar el cambio para su funcionamiento. Si la aplicación trabaja con sistemas hidráulicos, neumáticos o soluciones como el control a dos manos, el límite entre refactorización y cambio técnico se vuelve aún más estrecho y exige comprobar si no se han vulnerado los supuestos de diseño de las medidas de protección. Es precisamente aquí donde resulta justificado recurrir a métodos estructurados de identificación de peligros según ISO 12100, incluido el enfoque aplicado en la práctica sobre la base de ISO/TR 14121-2, y en el caso de sistemas hidráulicos también a los requisitos de diseño ordenados por UNE-EN ISO 4413. No se trata de formalismo por el formalismo, sino de una regla de decisión sencilla: si el cambio puede afectar a la seguridad del proceso o de la operación, su coste debe calcularse junto con la validación, las pruebas en planta y el régimen de responsabilidad, y no únicamente en función del tiempo de trabajo del programador.

Cómo abordar el tema en la práctica

En la práctica, la conveniencia de refactorizar una aplicación industrial antigua no se valora por el atractivo tecnológico del cambio, sino por si permite reducir al mismo tiempo el riesgo operativo y mantener el control sobre la implantación. Para el manager y el propietario del producto, esto implica un cambio de enfoque muy simple: la pregunta no es si «merece la pena poner orden en el código», sino si el estado actual de la aplicación dificulta realmente el mantenimiento, las pruebas, la corrección de fallos o la introducción de nuevas modificaciones de forma conforme a los requisitos. Si la respuesta es afirmativa, la refactorización tiene sentido, pero solo dentro de un alcance que pueda aislarse de la operación productiva y evaluarse sobre la base de efectos medibles. Un buen criterio de decisión es comparar dos costes: el de mantener la aplicación en su estado actual, incluyendo paradas, tiempo de diagnóstico, dependencia de personas concretas y riesgo de cambios erróneos, y el de una reestructuración controlada junto con las pruebas, la validación y la puesta en marcha. Sin esta comparación, el proyecto suele descontrolarse, porque el equipo acaba financiando la reorganización del código con el presupuesto destinado a funcionalidad, mientras que la responsabilidad por las consecuencias en la instalación queda sin definir.

Por eso, la primera decisión no debería ser «reescribimos» o «lo dejamos como está», sino fijar el límite del cambio. En un enfoque maduro, se separa la parte que afecta exclusivamente a la estructura del software de la que influye en la lógica del proceso, las secuencias de arranque y parada, los modos de funcionamiento, la comunicación con los accionamientos y el comportamiento tras una perturbación de la alimentación. Esta distinción tiene un efecto directo en costes y organización. Un cambio limitado a la capa de ordenación del código puede ejecutarse en un ciclo más corto y con menor participación de los servicios de mantenimiento. En cambio, una modificación que altere el comportamiento de la máquina o de la línea ya exige un plan de pruebas en la instalación, una ventana de servicio, un procedimiento de reversión y una definición inequívoca de quién autoriza la puesta en explotación. Además, conviene medir no solo el tiempo de ejecución de los trabajos de programación, sino también el tiempo necesario para restaurar el sistema tras un intento fallido, el número de áreas incluidas en las pruebas de regresión y el tiempo requerido para diagnosticar una desviación después de la puesta en marcha. Estos son los indicadores que muestran si la refactorización reduce realmente el riesgo del proyecto, y no solo mejora la comodidad de trabajo del equipo de desarrollo. En entornos en los que intervienen varias disciplinas, este tipo de coordinación suele exigir una gestión de proyectos rigurosa para que el alcance técnico y la responsabilidad queden definidos desde el principio.

Un ejemplo práctico, típico de aplicaciones de control antiguas, es aquel en el que el código contiene múltiples fragmentos duplicados responsables de los enclavamientos de movimiento, la gestión de alarmas y las transiciones entre modo manual y automático. El equipo quiere unificarlos, porque la estructura actual dificulta la evolución y provoca discrepancias entre puestos. Esta decisión solo tiene sentido después de comprobar que la unificación no modificará las condiciones en las que un elemento actuador recibe permiso de movimiento, ni hará que, tras el reinicio del controlador, aparezca una secuencia distinta de restauración del estado. Si la aplicación también controla válvulas, accionamientos o sistemas con energía acumulada, incluso una refactorización aparentemente «interna» puede entrar en el ámbito de la evaluación del riesgo de los cambios y requerir un análisis de la protección contra la puesta en marcha inesperada conforme a ISO 14118. En ese caso, una práctica razonable consiste en realizar la refactorización por etapas: primero reproducir el comportamiento en un entorno de pruebas, después aislar módulos sin cambiar la lógica y, a continuación, verificar en la instalación con un escenario de reversión ya preparado. Esto limita la responsabilidad operativa y permite interrumpir la implantación antes de que el problema afecte a la producción.

Solo en esta fase resulta necesaria la referencia normativa, porque las normas no sustituyen la decisión técnica, pero sí ordenan el momento en que el cambio deja de ser exclusivamente un trabajo de programación. Si la refactorización afecta a las medidas de protección, a las condiciones de acceso seguro, al corte de energía o al comportamiento de los sistemas tras la parada y el rearranque, entra de forma natural en el ámbito de la evaluación práctica del riesgo de los cambios, realizada de forma estructurada también con apoyo del enfoque conocido por ISO/TR 14121-2. Cuando aparece el riesgo de puesta en marcha inesperada, ya no basta con revisar el propio código, sino también la lógica de corte y restablecimiento de la energía, lo que conduce directamente a cuestiones asociadas con ISO 14118. Y si la aplicación está vinculada a sistemas hidráulicos o neumáticos, la evaluación no puede omitir las premisas de diseño de esos sistemas, porque una secuencia de control errónea puede comprometer su funcionamiento seguro con independencia de que el programa en sí sea correcto; en ese caso, también está justificado recurrir a los requisitos que ordenan el diseño de los sistemas hidráulicos. En la práctica, esto significa una sola cosa: el alcance de la refactorización no lo determina la elegancia de la solución, sino el límite de la responsabilidad sobre el comportamiento seguro de la instalación después del cambio. En contextos de integración más amplios, esta frontera suele aparecer también en proyectos de automatización industrial, donde software, control y operación forman un único sistema.

Qué tener en cuenta durante la implantación

La implantación de la refactorización de una aplicación industrial antigua es el momento en el que incluso una decisión arquitectónica correcta puede convertirse en un problema operativo. El sentido de toda la iniciativa termina allí donde el cambio mejora el código, pero empeora la previsibilidad del funcionamiento de la instalación o amplía la responsabilidad del equipo más allá de lo que se ha identificado y aprobado. El error más frecuente consiste en tratar la implantación como una simple publicación de una nueva versión. En un entorno productivo no solo importa si la aplicación funciona, sino también si, después del cambio, todos los estados transitorios se comportan exactamente igual: el arranque tras una pérdida de alimentación, el reinicio de la comunicación, la restauración de recetas y la gestión de alarmas, enclavamientos y modos manuales. El criterio práctico es sencillo: si el equipo no es capaz de describir de forma inequívoca qué comportamientos deben permanecer inalterados tras la implantación, significa que todavía no se dan las condiciones para una puesta en marcha segura.

En la fase de decisión sobre la implantación, es necesario distinguir entre un cambio técnicamente reversible y un cambio que, una vez puesto en marcha, crea una nueva situación de referencia y dificulta la vuelta atrás. Esto tiene consecuencias directas sobre el coste y el calendario. Una refactorización que exige actualizar al mismo tiempo los controladores, la visualización, el servidor de datos y las interfaces con los sistemas de nivel superior deja de ser una tarea aislada de programación; pasa a convertirse en un cambio coordinado en producción con múltiples puntos potenciales de fallo. Por eso, antes de implantarla conviene adoptar un criterio de aceptación basado no en la simple declaración de que «las pruebas se han superado», sino en la capacidad de revertir el cambio de forma controlada en un tiempo aceptable para el proceso. Si no existe un procedimiento de retorno fiable, tampoco hay base para afirmar que el riesgo está bajo control. En la práctica, resulta más útil medir no una abstracta «calidad de la implantación», sino indicadores como el tiempo necesario para restaurar la versión anterior, el número de interfaces que dependen del cambio y el número de funciones cuya corrección puede confirmarse en la instalación sin intervenir en la producción. Cuando existen dudas sobre el impacto real de la modificación en la línea o en la máquina, una auditoría de seguridad de máquinas y líneas de producción puede ayudar a ordenar el alcance de la verificación en campo.

Un buen ejemplo es la situación en la que la refactorización ordena la gestión de excepciones y de mensajes de error, pero al mismo tiempo modifica el orden de inicialización tras el reinicio del sistema. En el puesto de pruebas todo parece correcto, porque los equipos están disponibles de inmediato y el proceso no trabaja bajo carga. Sin embargo, en planta ese mismo código puede lanzar la secuencia en un momento distinto al habitual, lo que provoca pérdida de sincronización con los accionamientos, una interpretación errónea de las señales de disponibilidad o la detención de un lote de material en un estado intermedio. Este tipo de incidente no tiene por qué significar una avería en sentido técnico, pero sí genera el coste de la parada, del desperdicio, del nuevo arranque y de la responsabilidad adicional asociada a la decisión de reanudar la operación. Es precisamente aquí donde la cuestión de la refactorización pasa a convertirse en una evaluación práctica del riesgo de los cambios conforme a ISO 12100: no cuando el cambio es grande, sino cuando sus efectos ya no pueden limitarse a la capa de software.

El límite de la responsabilidad se vuelve aún más claro allí donde la aplicación influye en las funciones de protección, la lógica de habilitación del movimiento, las secuencias de descarga, la parada y el rearranque tras una perturbación. En ese caso, ya no basta con comparar versiones del código ni con una prueba funcional realizada por el integrador. Se necesita una evaluación estructurada para determinar si el cambio modifica el nivel de riesgo y si no vulnera las premisas de funcionamiento seguro de la máquina o de la instalación. Este es el momento natural para entrar en el ámbito de la evaluación del riesgo según ISO 12100 y de las prácticas aplicadas a la valoración del riesgo de los cambios, y en los casos más complejos puede resultar útil el enfoque metodológico conocido por ISO/TR 14121-2. Si la aplicación controla sistemas hidráulicos o neumáticos, además hay que comprobar si la nueva lógica no altera las condiciones de control seguro de la energía ni la secuencia de movimientos; en ese caso, también cobran importancia los requisitos de diseño propios de esos sistemas, y no solo la corrección del propio programa. Para el equipo del proyecto, esto significa una cosa: la implantación solo puede considerarse preparada cuando el alcance de la responsabilidad técnica, operativa y de conformidad se ha definido antes de la puesta en marcha, y no únicamente después del primer incidente. Cuando la intervención forma parte de un cambio técnico mayor, también puede estar relacionada con el diseño y construcción de máquinas o con la adaptación de las máquinas a los requisitos mínimos.