No papel é uma conversão um para um. Nunca é.

Migrações como essa são vendidas como conversão um para um. Pegue o sistema antigo, replique o que ele faz em hardware e software novos e devolva se comportando exatamente igual. Escopo limpo, fácil de vender — na capa, parece um copiar e colar com um orçamento anexado.

Existe um tipo específico de subsistema que silenciosamente prova que essa capa está errada, e depois que você briga com um, começa a vê-lo em todo lugar: um antigo CLP da série FX da Mitsubishi, um programa escrito nos anos 1990, em lógica ladder, no GX Developer — a geração mais antiga do software de programação MELSEC da Mitsubishi. O trabalho é levá-lo para o ABB 800xA, reconstruído como módulo de controle e codificado em diagrama de blocos de funções (FBD) em vez de ladder. “Mesmo comportamento, nova plataforma.” Essa é a instrução. É aqui que a instrução acaba.

“Um para um” é uma frase de venda, não de engenharia

Não acho que alguém esteja mentindo ao chamá-la de 1:1. Do lado do cliente, é verdade: mesmos botões, mesma sequência, mesma saída, a linha roda como sempre rodou. É esse o resultado pelo qual eles estão pagando, e é uma forma justa de descrevê-lo.

Mas mesmo resultado e mesma lógica são dois trabalhos diferentes, e o abismo entre eles é onde se esconde a maior parte do trabalho. Três coisas num subsistema como este escancaram esse abismo. Nenhuma delas está na capa.

Um: ladder e FBD não pensam do mesmo jeito

Lógica ladder e FBD não são dois dialetos de uma mesma língua. São duas formas diferentes de imaginar uma máquina. O ladder se lê como degraus de contatos e bobinas, com corrente fluindo da esquerda para a direita — um modelo mental que fazia sentido na época em que descrevia painéis de relés literais. O FBD se lê como sinais fluindo através de blocos. Gerações diferentes, instintos diferentes.

Então traduzir um no outro não é mecânico, em nenhuma das direções. Um padrão que é um degrau óbvio em ladder pode virar um aglomerado desajeitado de blocos em FBD, e algo limpo em FBD seria uma bagunça de degraus na volta. A armadilha é que você normalmente consegue fazer a saída bater enquanto a estrutura por baixo acaba sem nenhuma semelhança com a original — o que parece sucesso até o exato momento em que um caso de borda se comporta de forma diferente. Reproduzir o comportamento exato é a parte genuinamente difícil. Não porque a plataforma nova não consiga fazê-lo, mas porque provar que a versão nova se comporta de forma idêntica significa entender a antiga muito mais a fundo do que apenas lê-la de cima a baixo.

Dois: as partes sem equivalente

Parte daquilo em que esses programas antigos se apoiam simplesmente não tem gêmeo no 800xA. Não se traduz; tem que ser reconstruído à mão, e você só encontra cada uma lendo com cuidado.

• Instruções de salto. O ladder usa saltos condicionais (CJ) para pular seções inteiras de lógica — e qualquer coisa presa dentro de uma seção pulada mantém o último estado em vez de resetar, inclusive temporizadores, que congelam em vez de zerar. Não há um salto igual por igual para encaixar no FBD, então esse fluxo de controle tem que ser reexpressado como ordem de execução e condições de habilitação — um modelo mental diferente, não uma instrução trocada. Reproduza o comportamento de congelar-sem-resetar, ou você introduziu uma diferença silenciosa de caso de borda.
• Ajustes físicos cabeados na lógica. Nem todo setpoint vive no código. Alguns valores — coisas como pré-ajustes de temporizador — eram ajustados na própria máquina por meio de potenciômetros físicos. No FX, esses potenciômetros não guardam o valor diretamente: eles aterrissam em registradores de dados especiais (D8030/D8031), e o programa escala isso em um pré-ajuste. No mundo novo, eles viram parâmetros no módulo de controle, o que força uma decisão que o original nunca escreveu: o que deveria continuar ajustável em campo, e o que era apenas como se fazia em 1995.
• Relés auxiliares especiais. Esses programas se apoiam em relés de sistema da série M8000 — por exemplo o M8028, que troca a base de tempo de um bloco de temporizadores — para moldar partes da lógica. Esses são bits de sistema específicos da plataforma. O 800xA tem seus próprios mecanismos, então cada uso tem que ser entendido pelo que de fato estava fazendo e então recriado com o que a nova plataforma oferecer — nunca apenas copiado.

Três: o modelo de integração escondido dentro do “1:1”

Esta é a que não fica visível até você ir procurar, e um briefing “igual por igual” é o documento pior posicionado para pegá-la.

Um controlador nunca trabalha sozinho. Ele conversa com tudo o que está à sua volta — outros controladores, as E/S, a linha como um todo — e como ele conversa é parte do que ele faz, mesmo que nada disso apareça quando você lê o programa de cima a baixo. A suposição silenciosa embutida num briefing 1:1 é que essa conversa é transportada intacta. Muitas vezes não é. Saia de uma plataforma de décadas atrás para uma moderna e o próprio modelo de integração pode mudar: como esse canto do sistema se conecta a todo o resto, e do que essa conexão é sequer feita.

Pare e pense no que isso significa. Mesma função no chão de fábrica, um sistema nervoso diferente por trás. Você não consegue replicar uma conexão que não existe mais na mesma forma — você tem que reprojetar como a coisa conversa com o resto do sistema, e isso é trabalho de verdade que a capa nunca precificou. Não é nada exótico. É só invisível a partir da listagem do programa, que é exatamente por que um briefing escrito com base nessa listagem continua deixando passar.

Como eu leio um programa escrito antes de eu nascer

Estou cedo o bastante nesta profissão para que um programa ladder dos anos 1990 me seja genuinamente estranho — tenho 21 anos, cerca de dezoito meses de estrada. Eu nunca ia superar um código desses em experiência. Então me apoio nas ferramentas, deliberadamente — e vou contar como, porque o método é metade do que importa.

A sacada é tirar o programa antigo do seu ambiente nativo e colocá-lo numa forma simples e legível — exportá-lo para PDF, ou qualquer formato que preserve o que a lógica de fato faz — e então usar um modelo de IA como auxílio de leitura (tomando o cuidado de trabalhar em uma plataforma de ML da própria empresa, hospedada on-premise — e só depois de confirmar que está liberado com a sua empresa, o cliente e qualquer outra parte cujos dados estejam envolvidos): explique isto seção por seção, com trechos anotados que eu possa conferir direto contra os degraus. Isso transforma um programa que ninguém tocava havia décadas em um mapa legível. A partir daí você descobre quais partes não vão sobreviver à migração — os saltos, os especiais, os pré-ajustes definidos em campo — e raciocina sobre como um determinado bloco de ladder deveria ser reconstruído em FBD.

Quero ser honesto sobre os limites, porque um público de automação vai, com razão, desconfiar disso. A IA erra às vezes. Ela chuta intenções, às vezes com uma confiança que não conquistou. É um auxílio de leitura e um parceiro de raciocínio, não uma autoridade — toda conclusão é conferida contra o programa real e o comportamento real antes de chegar perto do código novo. Mas como forma de transformar um artefato opaco dos anos 1990 em algo sobre o qual se possa raciocinar em dias em vez de semanas, ela merece seu lugar. É exatamente esse o trabalho fácil em que a ferramenta é boa: não tomar a decisão de engenharia, só limpar o mato para que você possa tomá-la.

O mesmo truque, apontado para a resposta

Ler o programa antigo é só metade. A outra metade é provar que o novo bate — e a mesma abordagem funciona aí também. Exporte os dois programas para texto que espelha sua lógica — o ladder e o FBD, cada um despejado em PDF, ou qualquer formato que preserve o que o código de fato faz — e alimente a IA com ambos ao mesmo tempo, pedindo que os compare lógica e funcionalmente e relate onde divergem. Ela não vai reconstruir nada para você, mas é um segundo leitor rápido e incansável: o degrau que não sobreviveu à migração, o caso de borda que o FBD trata de forma diferente, a saída que mudou silenciosamente — ela sinaliza tudo para você ir atrás. Mesma ressalva de antes: cada sinalização é conferida contra o comportamento real antes de você confiar nela. Mas apontar a ferramenta para os dois lados ao mesmo tempo transforma o “isto bate?” de uma semana de releitura cruzada manual em algo sobre o qual você pode iterar numa tarde.

A lição

Uma migração um para um é real da cadeira do cliente e ficção da do engenheiro, e ambas podem ser verdade ao mesmo tempo. O perigo não é o rótulo — é quando as pessoas que dimensionam o trabalho acreditam nele.

Então aqui está o que um serviço como este ensina, e o que vale a pena fazer no próximo antes de tocar em um único degrau: quando algo é vendido como um para um, vá caçar os três pontos em que ele não pode ser.

• A diferença de paradigma — onde quer que as ferramentas de origem e de destino pensem de formas diferentes (ladder para FBD), o comportamento é difícil de provar, não só de escrever.
• Os órfãos — os elementos específicos da plataforma sem equivalente (saltos, relés de sistema, pré-ajustes definidos em campo) que têm que ser reconstruídos à mão.
• O modelo de integração — como a coisa conversa com tudo ao seu redor, algo que um briefing “igual por igual” adora supor que continua o mesmo quando não continua.

Encontre esses três cedo. Precifique-os com honestidade. Aí o “um para um” deixa de ser uma mentira que você descobre no meio do caminho e passa a ser um plano que você de fato consegue defender. O rótulo nunca foi o problema — acreditar nele foi.