Padronização de programa CLP: camadas e versões

1. O que é padronização de programa CLP: hábito individual vira ativo de engenharia

Padronizar o programa CLP é reduzir a forma de escrever o programa de controle, de hábito individual para uma estrutura que a equipe consegue reutilizar. Na mesma máquina de embalagem, dois engenheiros podem divergir na nomenclatura de variáveis, na divisão de seções e no tratamento de alarmes. Três anos após a entrega, quando o desenvolvedor original sai, quem assume passa vários dias lendo a lógica antes de ousar alterar uma condição de intertravamento. É aí que a padronização paga: estrutura, nomenclatura e documentação seguem uma convenção comum, e qualquer pessoa percorre o mesmo caminho até o mesmo ponto.

O limite precisa ser dito com clareza. A padronização restringe a forma de organizar o programa e o que é entregue, não o processo em si. Receitas, tempo de ciclo e sequência de movimentos continuam seguindo o processo do cliente. Entendê-la como restrição de estilo de escrita é um mal-entendido comum: o que fica fixo é o esqueleto e as interfaces, e a lógica de processo, ao contrário, fica mais fácil de alterar quando as camadas estão claras. A IEC 61131-3:2013 já define unidades de organização de programa (POU), blocos de função e variáveis globais. O trabalho de engenharia é levar esses conceitos para a estrutura de pastas, a ordem das seções e as regras de nomenclatura do projeto, não criar um sistema paralelo.

Um critério prático: entregue o programa a alguém que não participou do desenvolvimento e peça uma alteração, como acrescentar uma estação. Se essa pessoa encontra o ponto de inserção dentro da estrutura existente sem tocar na lógica das outras estações, o programa está padronizado. Se precisa ler tudo antes, a padronização parou no nome dos arquivos.

2. Como cortar as camadas: dispositivo, unidade, processo e comum

O objetivo do fatiamento em camadas é separar lógicas que mudam em ritmos diferentes. O detalhe de movimento da camada de dispositivo muda com a mecânica, a coordenação da camada de unidade muda com o layout da linha, a receita da camada de processo muda com o produto, e a camada comum de alarmes, permissões e comunicação quase não muda. Misture os quatro tipos em um único bloco e cada alteração obriga a reverificar tudo.

• Camada de dispositivo: partida e parada, intertravamentos, fins de curso e tratamento de falha de uma máquina. Um bloco de função por dispositivo, expondo para fora apenas quatro interfaces: partida, parada, reset e status.
• Camada de unidade: coordenação entre estações ou máquinas, como handshake a montante e a jusante, sincronismo de ciclo e decisão de pulmão. Essa camada chama apenas interfaces da camada de dispositivo e não lê nem escreve variáveis internas de outra unidade diretamente.
• Camada de processo: receitas, conjuntos de parâmetros e sequência de etapas. Os dados de receita ficam fora do programa, em tabela de parâmetros ou banco de dados, de modo que trocar receita não exige baixar o programa novamente.
• Camada comum: classes de alarme, permissões de operador, sincronismo de relógio, mapa de comunicação e registro de dados. Um conjunto compartilhado por todo o projeto, em vez de reescrito por estação.

No nível dos arquivos de engenharia, as camadas viram estrutura de pastas e ordem de seções fixas: cada bloco de função começa pela descrição da interface, segue o corpo da lógica e deixa o tratamento de exceções no fim da seção. Definida a convenção, a revisão de código ganha linguagem comum: o revisor primeiro verifica se a interface cruza camadas, depois se a lógica corresponde ao processo.

Uma ressalva: mais camadas não é automaticamente vantajoso. Em projeto com um único tipo de máquina e lotes pequenos, quatro camadas aumentam a superfície de manutenção. Ali é mais prático manter a camada de dispositivo e a comum e escrever a lógica de coordenação no ponto de chamada. A granularidade deve seguir a repetição do equipamento, não o modelo pronto.

3. Nomenclatura, lista de tags e comentários: para a próxima pessoa entender

A nomenclatura é o item de maior retorno por esforço em todo o trabalho de padronização. Quando o mesmo sinal se chama M100 em um projeto, Start_OK em outro e X12 em um terceiro, a manutenção vira adivinhação. O nome em três partes fixa equipamento, função e sequência, e o próprio nome diz a que máquina pertence, o que faz e qual instância é.

A lista de tags acompanha o programa, não é feita depois. No mínimo traz endereço, tipo de dado, faixa e unidade de engenharia, bloco de função responsável, valor inicial e marca de retenção. Sinais analógicos exigem cuidado extra: se o mapeamento de 4–20 mA para a faixa de engenharia, o tempo de filtro e o limite de detecção de rompimento não estiverem escritos, a próxima pessoa a ajustar vai desviar o valor.

Até onde ir nos comentários? Um teste viável é ler o comentário isolado: sem olhar o código, é possível dizer em que condição o bloco é chamado e o que acontece se falhar? Se não, o comentário descreve o nome da ação, não a intenção do projeto.

4. Controle de versão, backup e aceitação na entrega

A alteração em campo é a principal origem do desvio do programa. Uma dúzia de revisões por dia durante o comissionamento é normal; sem registro de versão, uma semana depois ninguém sabe qual revisão roda na máquina e qual foi experimental. O controle de versão precisa responder a três perguntas: qual revisão está rodando, o que mudou nela e para qual voltar em caso de problema.

• Regra de numeração: número maior para mudança de processo ou estrutura, menor para parâmetros e lógica local; a versão aparece tanto no primeiro bloco de comentário do programa quanto na etiqueta dentro do painel, e as duas devem coincidir.
• Ritmo de arquivamento: diário durante o comissionamento e a cada alteração após a estabilização; o arquivo contém projeto-fonte, lista de tags, notas de comentário e log de compilação, e um item ausente quebra a corrente para o próximo responsável.
• Registro de alteração: anotar quem alterou, quando, por quê e com que alcance; mudanças em intertravamentos e em lógica ligada à segurança são marcadas à parte e revisadas.
• Backup e restauração: manter uma cópia restaurável offline na máquina e um conjunto histórico no servidor; a validade do backup é provada por ensaio de restauração, não pela existência do arquivo.

A lógica ligada à segurança tem requisitos adicionais. A ISO 13849-1:2023 estabelece um caminho de projeto e verificação para partes relacionadas à segurança do sistema de controle, e uma função de segurança não pode viver apenas em uma seção comum distinguida por comentário. O Regulamento de Máquinas da UE (UE) 2023/1230 aplica-se a partir de 20 de janeiro de 2027, e software como parte relacionada à segurança exige versão e registro de verificação rastreáveis. A IEC 62443-3-3:2013 exige controle sobre alteração de programa e acesso: quem pode baixar, quem pode mudar parâmetros e se as mudanças são registradas pertencem ao escopo de entrega, não aos opcionais.

Convém fazer a aceitação na entrega por lista, concluída só com os cinco itens: projeto-fonte e projeto compilável, lista de tags e comentários, registros de versão e de alteração, arquivos de backup com procedimento de restauração e um ensaio de restauração em campo. O ensaio é a etapa mais pulada e a que mais expõe problemas: arquivo de backup existir e não restaurar não é raro.