Como fazer o backup e a documentação do programa de um CLP

A CPU de uma envasadora queima durante o terceiro turno. A peça de reposição chega em poucas horas, mas a linha fica parada o resto do dia: o último arquivo do programa está no notebook de um técnico que saiu da empresa, e a cópia encontrada no servidor é de dois anos antes, sem as alterações feitas desde então. Esse roteiro se repete em fábricas de todos os portes, e quase nunca por falta de tecnologia. Falta rotina. Uma política simples de backup do programa do CLP, da IHM e dos inversores, com nome padronizado e documentação junto, transforma uma parada de dias em uma troca de componente.

Este tutorial mostra o que copiar, onde guardar, como nomear as versões e o que registrar para que outra pessoa consiga restaurar a máquina sem depender da memória de ninguém.

O que precisa entrar no backup

O erro mais comum é achar que "o programa do CLP" é um arquivo só. Em uma máquina típica, a lógica está espalhada por vários dispositivos, e cada um guarda uma parte da configuração.

Controlador

• Projeto completo do software de engenharia, não apenas o upload da CPU. Em várias plataformas, o que fica gravado no controlador não inclui todos os comentários, nomes simbólicos e a documentação do projeto. Um upload feito às pressas pode devolver uma lógica que funciona, mas que ninguém consegue ler.
• Valores atuais de dados: receitas, setpoints, contadores, tempos ajustados em campo e parâmetros guardados em memória retentiva. O projeto offline costuma carregar os valores iniciais, que podem estar longe dos que a máquina usa de fato.
• Configuração de hardware e de rede: módulos, endereços, parâmetros de comunicação e versão de firmware da CPU.

IHM e supervisório

• Projeto-fonte editável, além do arquivo compilado que roda no painel.
• Telas, alarmes, receitas, usuários e níveis de acesso.
• Versão do software de desenvolvimento e do firmware do terminal.

Acionamentos e periféricos

• Lista de parâmetros de cada inversor e servoacionamento, exportada pelo software do fabricante ou copiada pelo teclado ou cartão de memória.
• Configuração de relés de segurança programáveis, com a assinatura ou soma de verificação gerada pela ferramenta.
• Parâmetros de sensores IO-Link, câmeras de visão, balanças, robôs e gateways de protocolo.
• Configuração de switches gerenciáveis, quando houver.

Um inversor trocado sem a lista de parâmetros volta a operar com o padrão de fábrica: rampas, limites de corrente e referências de velocidade diferentes do que o processo exige. Esse detalhe costuma aparecer só depois da troca, na forma de desarmes e produto fora de especificação.

Onde guardar as cópias

Backup que mora em um único lugar não é backup. Uma regra prática consagrada em TI serve bem à automação: três cópias, em dois tipos de mídia, com uma fora do prédio.

• Repositório central em servidor da empresa, com acesso controlado e cópia automática para outro local.
• Cópia de campo, dentro do painel ou no armário da manutenção, em mídia identificada, para restauração rápida quando a rede estiver fora do ar.
• Cópia externa, em nuvem corporativa ou em outra unidade, para o caso de incêndio, ataque de ransomware ou falha do servidor.

Notebook de técnico e pen drive solto não contam como local de guarda. Servem para levar o arquivo até a máquina e devem ser verificados contra malware antes de se conectar à rede de automação. As séries de normas ISA/IEC 62443 e o guia de segurança de sistemas de controle industrial do NIST tratam backup, recuperação e gestão de mudanças como parte da proteção desses sistemas, não como tarefa opcional de manutenção.

Como nomear e versionar

O nome do arquivo precisa responder, sem abrir nada, a quatro perguntas: qual máquina, qual dispositivo, quando e qual versão. Um padrão possível:

L2-ENVASE-CLP01_2026-10-28_v014

• L2-ENVASE identifica a linha e a máquina, com o mesmo código usado no cadastro de ativos da manutenção.
• CLP01 identifica o dispositivo; IHM01, INV03 e SEG01 seguem a mesma lógica.
• Data no formato ano-mês-dia, que mantém a ordem cronológica em qualquer listagem de pastas.
• Número de versão sequencial, sempre crescente, sem sufixos como "final", "novo" ou "agora vai".

Cada versão ganha uma linha no registro de alterações, que pode ser um arquivo de texto na mesma pasta:

• data e autor da mudança;
• o que mudou (rotina, bloco, tela, parâmetro);
• por que mudou, com o número da ordem de serviço ou da solicitação;
• como foi testado e quem aprovou.

Fábricas com muitos controladores costumam adotar sistemas de gestão de versões específicos para automação, que comparam projetos e fazem cópias agendadas direto dos dispositivos. Onde o volume é menor, uma estrutura de pastas bem disciplinada resolve. Projetos que podem ser exportados em texto, como o formato XML de intercâmbio da PLCopen para linguagens da IEC 61131-3, também podem ir para ferramentas de controle de versão de software, que mostram linha a linha o que mudou.

Quando fazer o backup

Periodicidade fixa ajuda, mas o gatilho mais importante é a mudança.

1. Antes de qualquer alteração: copie o que está rodando, mesmo que exista versão arquivada. Assim se garante o ponto de retorno.
2. Depois de toda alteração aprovada: gere a nova versão, registre e envie ao repositório no mesmo dia.
3. Em rotina periódica (mensal ou trimestral, conforme a criticidade): compare o que está na CPU com o arquivado. A função de comparação online/offline, presente na maioria dos softwares de engenharia, mostra diferenças que alguém deixou de registrar.
4. Após paradas programadas e comissionamentos, quando costumam ocorrer ajustes de última hora.

A comparação periódica é o que fecha a porta das alterações sem registro. Quando o arquivado e o que roda divergem, a primeira pergunta é quem mudou e por quê; a segunda é qual das duas versões está certa.

O que documentar junto com o programa

O arquivo do programa, sozinho, não garante a restauração. A pasta de cada máquina deve reunir:

• Inventário de dispositivos: fabricante, modelo, número de série, firmware, endereço de rede e localização no painel.
• Versões de software de engenharia e de licenças necessárias para abrir o projeto. Um backup que só abre em uma versão descontinuada é um risco a ser tratado com antecedência.
• Diagrama elétrico atualizado, lista de entradas e saídas e mapa de endereços de rede.
• Descrição funcional da máquina: sequência de operação, intertravamentos, modos manual e automático.
• Procedimento de restauração passo a passo, escrito para quem não conhece a máquina.
• Senhas de projeto e de acesso, guardadas em cofre de senhas corporativo, nunca no próprio arquivo ou em papel colado no painel.

Teste de restauração

Backup que nunca foi restaurado é uma hipótese. Pelo menos uma vez por ano, e sempre para as máquinas críticas, vale restaurar uma cópia em uma CPU reserva, em bancada ou em simulador, e verificar:

• se o projeto abre na versão de software disponível;
• se a carga na CPU ocorre sem erros de hardware ou de firmware;
• se os valores de dados restaurados correspondem aos de produção;
• se a IHM volta a se comunicar e os inversores aceitam a lista de parâmetros.

O teste costuma revelar problemas que só apareceriam na pior hora: licença vencida, firmware incompatível, arquivo corrompido, parâmetro de inversor faltando.

Checklist da rotina

• Inventário de todos os dispositivos programáveis de cada máquina.
• Projeto completo, valores atuais e configuração de hardware do CLP.
• Projeto-fonte e compilado da IHM.
• Parâmetros de inversores, servos, relés de segurança e periféricos.
• Padrão de nomes com máquina, dispositivo, data e versão.
• Registro de alterações com autor, motivo e teste.
• Três cópias, duas mídias, uma fora do prédio.
• Comparação periódica entre o que roda e o arquivado.
• Documentação e procedimento de restauração na mesma pasta.
• Teste anual de restauração nas máquinas críticas.