Sobre el papel es una conversión uno a uno. Nunca lo es.

Las migraciones como esta se venden como una conversión uno a uno. Coger el sistema antiguo, replicar lo que hace en hardware y software nuevos, y devolverlo comportándose exactamente igual. Alcance limpio, fácil de vender — en la portada se lee como un copiar y pegar con un presupuesto pegado al lado.

Hay un tipo concreto de subsistema que demuestra en silencio que esa portada se equivoca, y una vez que has peleado con uno empiezas a verlo por todas partes: un viejo PLC (autómata) de la serie Mitsubishi FX, un programa escrito en los años 90, en lógica de escalera (ladder), en GX Developer — la generación más antigua del software de programación MELSEC de Mitsubishi. El trabajo consiste en pasarlo a ABB 800xA, reconstruido como módulo de control y programado en diagrama de bloques de funciones (FBD) en lugar de en ladder. «Mismo comportamiento, plataforma nueva.» Esa es la instrucción. Aquí es donde la instrucción se queda corta.

«Uno a uno» es una frase de ventas, no de ingeniería

No creo que nadie mienta cuando lo llama 1:1. Desde el lado del cliente es verdad: mismos botones, misma secuencia, misma salida, la línea funciona como siempre lo hizo. Ese es el resultado por el que pagan, y es una forma justa de describirlo.

Pero mismo resultado y misma lógica son dos trabajos distintos, y la brecha entre ambos es donde se esconde la mayor parte del trabajo. Tres cosas en un subsistema como este abren esa brecha. Ninguna de ellas está en la portada.

Uno: el ladder y el FBD no piensan igual

La lógica de escalera (ladder) y el FBD no son dos dialectos de un mismo idioma. Son dos formas distintas de imaginar una máquina. El ladder se lee como peldaños de contactos y bobinas, con la corriente fluyendo de izquierda a derecha — un modelo mental que tenía sentido cuando describía paneles de relés literales. El FBD se lee como señales que fluyen a través de bloques. Generaciones distintas, instintos distintos.

Así que traducir uno al otro no es mecánico, en ninguna de las dos direcciones. Un patrón que es un peldaño obvio en ladder puede convertirse en un grupo incómodo de bloques en FBD, y algo limpio en FBD sería un lío de peldaños al revés. La trampa es que normalmente puedes conseguir que la salida coincida mientras la estructura de debajo acaba sin parecerse en nada a la original — lo cual se siente como un éxito justo hasta que un caso límite se comporta de forma distinta. Reproducir el comportamiento exacto es la parte genuinamente difícil. No porque la plataforma nueva no pueda hacerlo, sino porque demostrar que la versión nueva se comporta de forma idéntica exige entender la vieja mucho más a fondo que con solo leerla de arriba abajo.

Dos: las partes sin equivalente

Parte de aquello en lo que se apoyan estos programas antiguos sencillamente no tiene gemelo en 800xA. No se traduce; hay que reconstruirlo a mano, y solo descubres cada caso leyendo con cuidado.

• Instrucciones de salto. El ladder usa saltos condicionales (CJ) para omitir secciones enteras de lógica — y cualquier cosa atrapada dentro de una sección omitida mantiene su último estado en lugar de reiniciarse, incluidos los temporizadores, que se congelan en vez de borrarse. No hay un salto equivalente que dejar caer en el FBD, así que ese flujo de control tiene que reexpresarse como orden de ejecución y condiciones de habilitación — un modelo mental distinto, no una instrucción intercambiada. Reproduce el comportamiento de congelar-y-no-reiniciar, o habrás introducido una diferencia silenciosa en un caso límite.
• Ajustes físicos cableados en la lógica. No todas las consignas viven en el código. Algunos valores — cosas como los preajustes del temporizador — se afinaban en la propia máquina mediante potenciómetros físicos. En el FX esos potenciómetros no guardan el valor directamente: aterrizan en registros de datos especiales (D8030/D8031), y el programa los escala para obtener un preajuste. En el mundo nuevo se convierten en parámetros del módulo de control, lo que fuerza una decisión que el original nunca dejó por escrito: qué debía seguir siendo ajustable en campo, y qué era simplemente como se hacía en 1995.
• Relés auxiliares especiales. Estos programas se apoyan en relés de sistema de la serie M8000 — por ejemplo el M8028, que conmuta la base de tiempos de un bloque de temporizadores — para dar forma a partes de la lógica. Esos son bits de sistema específicos de la plataforma. El 800xA tiene sus propios mecanismos, así que cada uso hay que entenderlo por lo que realmente estaba haciendo y luego recrearlo con lo que ofrezca la plataforma nueva — nunca limitarse a copiarlo tal cual.

Tres: el modelo de integración escondido dentro del «1:1»

Este es el que no se ve hasta que vas a buscarlo, y un encargo «equivalente» es el documento peor situado para detectarlo.

Un controlador nunca trabaja solo. Habla con todo lo que lo rodea — otros controladores, las E/S, la línea en su conjunto — y cómo habla es parte de lo que hace, aunque nada de eso aparezca cuando lees el programa de arriba abajo. La suposición tácita que lleva incorporada un encargo 1:1 es que esa conversación se traslada intacta. A menudo no es así. Pasa de una plataforma de hace décadas a una moderna y el propio modelo de integración puede cambiar: cómo se conecta este rincón del sistema con todo lo demás, y de qué está hecha siquiera esa conexión.

Detente a pensar lo que eso significa. Misma función en la planta, un sistema nervioso distinto por detrás. No puedes replicar una conexión que ya no existe en la misma forma — tienes que rediseñar cómo habla la cosa con el resto del sistema, y eso es trabajo real que la portada nunca presupuestó. No es nada exótico. Sencillamente es invisible desde el listado del programa, que es exactamente la razón por la que un encargo escrito a partir de ese listado lo sigue pasando por alto.

Cómo leo un programa escrito antes de que yo naciera

Estoy lo bastante al principio de este oficio como para que un programa en ladder de los años 90 me resulte genuinamente ajeno — tengo 21 años, llevo unos dieciocho meses. Nunca iba a poder superar en experiencia a un código así. Así que me apoyo en las herramientas, de forma deliberada — y voy a contar cómo, porque el método es la mitad de la cuestión.

La jugada es sacar el programa antiguo de su entorno nativo y llevarlo a una forma sencilla y legible — exportarlo a PDF, o a cualquier formato que conserve lo que la lógica hace de verdad — y luego usar un modelo de IA como ayuda de lectura (asegurándote de trabajar en una plataforma de ML propia de la empresa, alojada on-prem — y solo después de verificar que está autorizado con tu empresa, el cliente y cualquier otra parte cuyos datos estén implicados): explícame esto sección por sección, con fragmentos anotados que yo pueda contrastar directamente contra los peldaños. Eso convierte un programa que nadie ha tocado en décadas en un mapa legible. A partir de ahí averiguas qué partes no sobrevivirán al cambio — los saltos, los especiales, los preajustes definidos en campo — y razonas cómo debería reconstruirse un bloque dado de ladder como FBD.

Quiero ser sincero sobre los límites, porque un público de automatización desconfiará de esto con razón. La IA se equivoca a veces. Adivina la intención, a veces con una confianza que no se ha ganado. Es una ayuda de lectura y un compañero de pensamiento, no una autoridad — cada conclusión se contrasta contra el programa real y el comportamiento real antes de acercarse siquiera al código nuevo. Pero como forma de convertir un artefacto opaco de los años 90 en algo sobre lo que poder razonar en días en lugar de en semanas, se gana su sitio. Esto es exactamente el trabajo fácil en el que las herramientas son buenas: no tomar la decisión de ingeniería, solo desbrozar el terreno para que puedas tomarla.

El mismo truco, apuntando a la respuesta

Leer el programa antiguo es solo la mitad. La otra mitad es demostrar que el nuevo coincide — y el mismo enfoque también funciona ahí. Exporta ambos programas a texto que refleje su lógica — el ladder y el FBD volcados cada uno a PDF, o a cualquier formato que conserve lo que el código hace de verdad — y pásalos los dos a la vez a una IA, pidiéndole que los compare lógica y funcionalmente y que señale dónde divergen. No te reconstruirá nada, pero es un segundo lector rápido e incansable: el peldaño que no sobrevivió al cambio, el caso límite que el FBD maneja de otra forma, la salida que cambió en silencio — te los marca para que vayas a perseguirlos. La misma advertencia que antes: cada marca se contrasta contra el comportamiento real antes de fiarte de ella. Pero apuntar la herramienta a ambos lados a la vez convierte el «¿esto coincide?» de una semana de lectura cruzada manual en algo sobre lo que puedes iterar en una tarde.

La conclusión

Una migración uno a uno es real desde el asiento del cliente y una ficción desde el del ingeniero, y ambas cosas pueden ser verdad a la vez. El peligro no es la etiqueta — es cuando quien define el alcance del trabajo se la cree.

Así que esto es lo que enseña un trabajo como este, y lo que merece la pena hacer en el siguiente antes de tocar un solo peldaño: cuando algo se venda como uno a uno, ve a cazar los tres lugares donde no puede serlo.

• La brecha de paradigma — allá donde las herramientas de origen y de destino piensan distinto (de ladder a FBD), el comportamiento es difícil de demostrar, no solo de escribir.
• Los huérfanos — los elementos específicos de la plataforma sin equivalente (saltos, relés de sistema, preajustes definidos en campo) que hay que reconstruir a mano.
• El modelo de integración — cómo habla la cosa con todo lo que la rodea, algo que un encargo «equivalente» adora dar por sentado que permanece igual cuando no es así.

Encuentra esos tres pronto. Ponles un precio honesto. Entonces «uno a uno» deja de ser una mentira que descubres a mitad del camino y se convierte en un plan que de verdad puedes defender. La etiqueta nunca fue el problema — creérsela sí.