CLP obsoleto: quando modernizar o comando da máquina compensa

Existe um tipo de risco que não aparece em nenhum indicador de manutenção até o dia em que se materializa: o controlador que comanda a linha saiu de linha há anos, a peça de reposição só existe no mercado cinzento, e ninguém na equipe sabe abrir o programa porque o software roda em um sistema operacional que a fábrica não usa mais.

Obsolescência tem estágios, e o momento de agir é o segundo

Fabricante de automação costuma comunicar o ciclo de vida em fases. Primeiro o produto sai do catálogo para novos projetos, mas continua com peça e suporte. Depois entra em fase de descontinuidade, com peça só enquanto durar o estoque. Por fim, encerra o suporte.

Quem migra na primeira fase paga caro por antecipação. Quem espera a terceira paga caro por urgência, e escolhe com a linha parada. A janela boa é a segunda: dá tempo de planejar, especificar bem e executar numa parada programada.

Os sinais que indicam que a hora chegou

• Peça de reposição encontrada apenas com fornecedores de recondicionado, sem garantia
• Software de programação que não roda em máquina atual, dependendo de um notebook antigo guardado numa gaveta
• Programa sem backup recente, ou com backup que ninguém testou restaurar
• Rede de campo proprietária, sem caminho de integração com o sistema de supervisão
• IHM com display degradado, sem reposição, e sem documentação da tela
• Alterações feitas ao longo dos anos que não foram registradas na documentação

Migração não é traduzir o programa

A tentação é converter a lógica antiga linha por linha para a plataforma nova e encerrar. Funciona, e desperdiça a oportunidade. Boa parte dos programas de máquina antiga carrega correções que ninguém lembra por que existem, temporizadores ajustados para compensar um problema mecânico já resolvido, e trechos mortos de uma configuração que saiu de operação.

O caminho melhor é levantar a lógica funcional, o que a máquina precisa fazer, e reescrever com estrutura clara, comentada e organizada em blocos reaproveitáveis. Custa mais na migração e devolve uma máquina que a manutenção consegue entender sem arqueologia.

Segurança entra na conta, e muda o orçamento

Modernizar o comando de uma máquina antiga costuma disparar a exigência de adequação à NR-12. Isso não é custo extra inventado pelo integrador: se o circuito de comando vai ser refeito, é o momento natural de implantar as funções de segurança com o nível de desempenho definido pela apreciação de risco.

Fazer o retrofit de automação e deixar a segurança para depois quase sempre significa abrir a máquina duas vezes, com duas paradas de produção.

Como migrar sem parar a fábrica

A estratégia usual monta o painel novo em paralelo, com toda a fiação de campo preparada e testada em bancada, incluindo simulação de entradas e saídas. A parada real fica reduzida à transferência dos cabos de campo, ao teste funcional e à liberação. É a diferença entre uma parada de fim de semana e uma parada de duas semanas.

Onde existir redundância de linha, vale migrar uma máquina por vez, começando pela menos crítica, para que a equipe aprenda a plataforma nova com risco baixo.

O que precisa ser entregue no final

Programa fonte comentado e em poder da contratante, sem trava de fornecedor. Backup da aplicação, do projeto da IHM e dos parâmetros dos inversores. Diagramas atualizados como construído. Lista de entradas e saídas conferida em campo. Manual de operação e o registro dos testes funcionais e de segurança.

Retrofit em que o fonte fica com o integrador transforma toda alteração futura em dependência. Esse ponto se negocia antes da assinatura, não depois da entrega.