A linguagem Ladder (LD, Ladder Diagram) é uma linguagem gráfica para programação de controladores lógicos programáveis. Utiliza redes compostas por contatos, bobinas e blocos de instrução para expressar condições lógicas e ações de controle. Sua notação foi inspirada em circuitos de relés, mas um contato desenhado no programa representa a avaliação de uma variável, não […]
Confira!
A linguagem Ladder (LD, Ladder Diagram) é uma linguagem gráfica para programação de controladores lógicos programáveis. Utiliza redes compostas por contatos, bobinas e blocos de instrução para expressar condições lógicas e ações de controle. Sua notação foi inspirada em circuitos de relés, mas um contato desenhado no programa representa a avaliação de uma variável, não necessariamente um contato físico instalado no painel.
A linguagem integra a IEC 61131-3 e é amplamente aplicada em comandos discretos, permissivos, sequências e diagnósticos. Para utilizar Ladder corretamente, é necessário entender operadores booleanos, ordem de execução, memória, temporizadores, intertravamentos e a correspondência entre variáveis e dispositivos de campo.
Contatos, bobinas e lógica booleana
As redes Ladder são organizadas a partir de condições que determinam um resultado. Contatos em série representam conjunção lógica: duas condições precisam ser verdadeiras. Ramos paralelos representam alternativas; basta um caminho verdadeiro para completar a expressão, desde que as demais condições da rede sejam atendidas.
Uma saída lógica verdadeira pode significar que um comando foi solicitado, mas não comprova que o contator fechou ou que o equipamento está operando. A confirmação depende de sinal de campo independente e da estratégia de diagnóstico.
| Elemento | Operação | Atenção de engenharia |
| Contato lógico | Verifica variável | Não é contato físico |
| Contato negado | Negação booleana | Não garante segurança |
| Série | Operação E | Todos os permissivos devem valer |
| Paralelo | Operação OU | Não contornar bloqueios |
| Bobina | Atribuição de estado | Comando não é confirmação |
A matriz sintetiza critérios que devem ser confirmados pelos documentos e ensaios específicos de cada aplicação.
Como interpretar uma rotina de partida
Considere um motor que só pode partir com comando habilitado, condição de processo atendida e ausência de bloqueios. A lógica combina a solicitação com permissivos e produz o comando de acionamento. A manutenção de estado após botão momentâneo pode ser implementada por uma lógica de selo.
Entretanto, uma partida real exige definição sobre confirmação do acionador, proteção elétrica, transferência de modos, reset e parada. Um circuito lógico aparentemente correto pode falhar se uma entrada estiver invertida, se houver atraso na leitura da confirmação ou se uma condição de permissivo tiver sido omitida.
A arquitetura de automação industrial precisa explicar onde residem os permissivos, as proteções e a autoridade do comando, especialmente quando existe SCADA ou IHM.
O diagrama apresenta relações funcionais; as interfaces e condições reais dependem do projeto.
Ordem de execução, varredura e estados
A revisão das condições de comando deve ser vinculada aos requisitos do processo para evitar permissivos incompletos.
Quando não existe especificação funcional, o programa pode funcionar em bancada e ainda não atender à operação real. A engenharia deve definir requisitos, interfaces e critérios de aceite antes da contratação.
A interpretação didática de Ladder costuma considerar a avaliação de redes em sequência. Em plataformas reais, tarefas, blocos especiais e regras de atualização de dados alteram o comportamento percebido. A documentação do fabricante determina quando e como variáveis são escritas.
Duas redes que escrevem a mesma bobina podem produzir comportamento dependente da ordem de execução. O projeto deve reduzir responsabilidades duplicadas, separar a decisão de comando do acionamento final e registrar modos e condições especiais.
Bits de memória retentiva merecem atenção em falta de energia e reinicialização. Um comando mantido após retorno da alimentação pode ter consequências diferentes conforme o processo. A definição do estado de recuperação é um requisito funcional, não uma escolha improvisada de codificação.
Temporizadores, contadores e comparações
Temporizadores podem introduzir atraso de acionamento, medir duração de condição e supervisionar respostas. Contadores acumulam eventos e comparadores avaliam sinais como pressão ou nível contra limites parametrizados. A seleção de instruções deve considerar base de tempo, reset, retenção e comportamento de reinicialização.
Na supervisão de uma bomba, um temporizador verifica se o retorno de funcionamento apareceu após o comando. A ausência de confirmação pode sinalizar falha de partida, mas também erro de sensor ou perda de comunicação. O diagnóstico deve distinguir essas causas quando tecnicamente possível.
Para grandezas analógicas, escalonamento e tratamento de valores inválidos precisam ser executados antes das condições de controle. Uma comparação aplicada a valor bruto sem unidade adequada pode produzir comando incorreto.
Permissivos e intertravamentos operacionais
Permissivos definem quais condições autorizam determinada ação; intertravamentos impedem comandos incompatíveis. Em sistemas com motores e válvulas, a lógica precisa considerar estados transitórios e confirmação, não apenas combinações estáticas de bits.
Uma permissiva de nível pode estar satisfeita em uma leitura e inválida na seguinte. O projeto deve definir filtragem e histerese quando aplicáveis, sem mascarar situações perigosas. Mudanças entre manual e automático exigem regras próprias para impedir comandos intempestivos.
Funções instrumentadas de segurança ou circuitos de parada de emergência não devem ser considerados conformes apenas porque uma rede Ladder os representa. Segurança requer análise de risco, arquitetura e validação por critérios específicos.
Exercícios de interpretação e matriz de verdade
Uma forma útil de revisar Ladder é converter trechos simples em expressões lógicas e tabelas de verdade. Por exemplo, COMANDO = PEDIDO E PERMISSIVO E NÃO BLOQUEIO permite enumerar cenários que devem gerar comando verdadeiro ou falso.
Esse método não substitui testes dinâmicos de sequências e temporizações, mas ajuda a detectar bypass acidental de permissivos e inversões lógicas. Em projetos maiores, matrizes de estado e diagramas de transição complementam a verificação.
| Pedido | Nível OK | Falha | Comando |
| 0 | 1 | 0 | 0 |
| 1 | 0 | 0 | 0 |
| 1 | 1 | 1 | 0 |
| 1 | 1 | 0 | 1 |
A matriz sintetiza critérios que devem ser confirmados pelos documentos e ensaios específicos de cada aplicação.
Depuração e diagnóstico de falhas
Quando uma saída não atua, a equipe precisa identificar se o problema está em entrada, condição de processo, estado interno, permissivo, saída física, comunicação ou equipamento. Uma boa estrutura de programa expõe os motivos do bloqueio e distingue comando de retorno.
A observação online da lógica pode auxiliar o diagnóstico, mas exige procedimentos de segurança operacional e cuidado com alterações forçadas de variáveis. Simular uma entrada ou forçar saída sem avaliar impactos é potencialmente perigoso. Regras de acesso e registro das intervenções fazem parte da governança de manutenção.
Revisão, testes e aceite de programas Ladder
A verificação começa com a especificação funcional e uma matriz de testes que inclui comandos normais, falhas, perda de comunicação, reinicialização, mudança de modos e recuperação. O FAT permite testes de bancada e o SAT verifica interfaces instaladas, com limitações registradas.
A etapa de comissionamento precisa confirmar o comportamento físico, não apenas que os símbolos aparecem energizados na tela. Evidências devem identificar versão do programa, condição ensaiada, resultado observado e eventuais pendências.
Comentários e nomenclatura ajudam na manutenção, mas não compensam ausência de testes, documentação, backups ou controle de versões.
Como especificar um fornecimento com Ladder
Na contratação devem ser definidos programas-fonte, ambiente e versões, bibliotecas, lista de variáveis, descrição funcional, matriz de intertravamentos, integração, documentação de painéis e instrumentação, testes e treinamento. O serviço de projeto de automação industrial ajuda a distribuir responsabilidades entre engenharia, programador e integradores.
A clareza do escopo é decisiva quando diferentes fornecedores entregam sensores, painéis, CLP, IHM e supervisório. O software não pode ser aceito como componente isolado sem considerar interfaces e requisitos do processo.
Integração com redes OT e supervisão
A comunicação com módulos remotos, IHM e SCADA exige definição de protocolo, taxa de atualização, endereçamento, estrutura de dados e tratamento de perda de comunicação. A presença de uma porta Ethernet não assegura interoperabilidade nem desempenho. A configuração deve considerar segmentação, disponibilidade, gestão de acesso e diagnóstico de rede. Uma variável exibida no supervisório deve preservar unidade, origem, qualidade e significado.
Quando diferentes fornecedores são responsáveis por painéis e software, a matriz de interfaces precisa nomear quem configura cada extremidade, quem fornece listas de variáveis e como serão executados testes integrados. O objetivo é impedir que divergências permaneçam ocultas até a partida da planta.
Disponibilidade, manutenção e ciclo de vida
A confiabilidade de uma solução de controle depende de alimentação, componentes, comunicação, software e procedimentos de recuperação. A redundância deve responder a cenários de falha concretos; duplicação de um componente sem análise de pontos únicos de falha pode elevar custo sem atingir a disponibilidade requerida.
A manutenção precisa receber configurações controladas, programas-fonte quando previstos, licenças, backups, listas de sinais e registros de testes. Mudanças de firmware ou biblioteca devem passar por avaliação de impacto e testes regressivos. A capacidade de restaurar a operação após falha é critério de engenharia, não apenas atividade administrativa.
Responsabilidades, evidências e aceitação
O desenvolvedor implementa funções; o responsável pela engenharia estabelece requisitos, interfaces e critérios de verificação; a integração demonstra comportamento conjunto; operação e manutenção contribuem com critérios de uso, recuperação e acesso. Em contratos por múltiplos pacotes, atribuir explicitamente essas responsabilidades reduz retrabalho e disputas de escopo.
O aceite técnico deve verificar não só o comportamento nominal mas também permissivos, falhas, transições, retorno de alimentação, comunicações e documentação final. Uma matriz requisito–ensaio–evidência permite rastrear o que foi contratado e o que foi efetivamente demonstrado. A ausência de evidência não pode ser substituída por declaração genérica de conformidade.
Operadores booleanos e leitura das redes
A lógica Ladder utiliza contatos e ramos para avaliar expressões booleanas. Contatos em série correspondem a condições simultâneas; ramos paralelos representam alternativas. Um contato normalmente fechado desenhado no programa significa avaliação negada da variável, o que não identifica necessariamente o estado físico de um contato elétrico. Confundir esses conceitos causa erros recorrentes em migrações de circuitos de comando para programas digitais.
O leitor deve decompor cada rede em entradas, condição composta e resultado. Em uma partida, a expressão pedido E permissivo E NÃO bloqueio é uma maneira de representar a autorização. Se o permissivo é colocado apenas em um dos ramos paralelos, outra condição pode contorná-lo. A revisão de lógica precisa percorrer todos os caminhos e determinar se eles correspondem à intenção funcional.
Selo e estados retentivos
Quando o escopo não explicita estados, permissivos e interfaces, os riscos são transferidos para a execução e o aceite. A engenharia deve estabelecer essas premissas antes da contratação.
O selo lógico preserva um estado depois do retorno de um botão momentâneo. Isso pode ser útil em partidas convencionais, mas exige definição sobre parada, perda de permissivo, falha de comando e retorno da alimentação. Uma memória retentiva que sobreviva à reinicialização pode autorizar uma retomada indesejada. Em algumas aplicações a retomada é admitida, porém precisa resultar de requisito e avaliação de riscos.
A implementação deve separar o pedido de operação do comando físico e da confirmação de funcionamento. Uma bobina energizada pode representar somente a intenção de acionar o dispositivo. O retorno do contator, a velocidade ou a vazão real são informações distintas. A IHM não deve apresentar uma confirmação baseada apenas no estado de um comando lógico.
Temporizadores e contadores
Temporizadores podem atrasar uma ação, supervisionar uma condição ou detectar ausência de resposta. Contadores acumulam eventos e comparadores verificam limites de grandezas. A escolha da instrução deve considerar o tipo de tarefa, a retenção e o comportamento de reset. Um temporizador de partida pode identificar que um motor não confirmou acionamento dentro do intervalo definido, mas o diagnóstico deve considerar sensor ausente e rede indisponível.
Um alarme de falha pode ter consequências operacionais diferentes de uma lógica de parada. Por isso, é necessário definir separadamente comando, diagnóstico e ação. Quando um valor analógico oscila próximo ao limiar, histerese ou filtragem podem ser necessárias. Seus valores devem decorrer da dinâmica do processo e de uma análise técnica, não de ajuste arbitrário para silenciar alarmes.
Set, reset e múltiplas escritas
Instruções de retenção e redefinição de estados precisam estabelecer prioridade clara. Quando a mesma variável é escrita em diferentes redes, o resultado pode depender da ordem de execução da tarefa. Essa situação se torna especialmente sensível quando há rotinas periódicas e acionadas por eventos. Uma boa arquitetura concentra a responsabilidade sobre estados e saídas e documenta as exceções.
As regras de programação devem explicar quando um bit é zerado, o que ocorre após reinicialização e como as permissivas interferem na retenção. Uma manutenção que altere uma rede sem conhecer outras escritas pode introduzir falhas difíceis de reproduzir. A revisão deve utilizar referências cruzadas de variáveis e testes de regressão.
Intertravamentos e segurança funcional
Mudanças de lógica e estados retentivos exigem diagnóstico antes da intervenção na instalação.
A verificação precisa incluir condições de falha, reinicialização, diagnósticos e integração. O comissionamento transforma requisitos em evidências de desempenho.
Permissivos e intertravamentos de controle impedem condições incompatíveis. A segurança funcional, entretanto, demanda análise de perigos, requisitos específicos, dispositivos apropriados e validação. Um contato negado em Ladder não comprova a integridade de uma função de parada de emergência. O projeto precisa distinguir bloqueios operacionais, proteções de equipamentos e funções destinadas à redução de riscos.
É necessário especificar o que fazer quando sinais de campo ficam inválidos. Manter uma saída, bloqueá-la ou executar parada são possibilidades cuja adequação depende do processo. Bypasses e forçamentos de variáveis devem ser controlados, autorizados e registrados. A facilidade de alterar o programa em tempo real não deve produzir uma prática de manutenção sem governança.
Testes e depuração estruturada
A revisão de Ladder começa pela interpretação das condições e pela construção de cenários. Tabelas de verdade verificam expressões simples; máquinas de estados e matrizes de causa e efeito ajudam em sequências complexas. A simulação permite acionar combinações raras, mas não comprova todas as interfaces físicas. Os testes de campo devem verificar também cabos, sensores, proteção e acionamento real.
Durante a depuração, o técnico precisa distinguir uma variável de entrada falsa por condição física, falha do sensor ou comunicação. A documentação deve indicar origem, unidade, significado e estado de qualidade. Cada teste deve preservar a versão do programa, o estímulo aplicado, o resultado esperado e a evidência observada, inclusive quando houve falha e reteste.
Entrega documental e manutenção
O fornecimento de software deve prever arquivo-fonte e ambiente de desenvolvimento quando contratualmente exigidos, bibliotecas, listas de variáveis, descrição funcional, matriz de testes, backups e versões. Comentários úteis explicam decisões de engenharia e exceções, em vez de repetir o nome de uma instrução. Convenções de nomenclatura facilitam a leitura da lógica por profissionais que não participaram de seu desenvolvimento.
A qualidade de uma rotina Ladder não deve ser avaliada apenas pela aparência gráfica. Ela depende da rastreabilidade até o requisito, da ausência de comandos conflitantes, do tratamento de condições anormais e da possibilidade de manutenção. Testes regressivos após alterações são necessários para evitar que a correção de um defeito afete outras redes conectadas às mesmas variáveis.
O desempenho do sistema depende da coerência entre requisitos, documentação, execução e recebimento; a especificação de engenharia deve integrar esses elementos.
Exemplos de lógica e tabela de condições
Uma rotina Ladder deve ser compreendida a partir das expressões que produz. Considere a função de autorizar uma bomba quando há solicitação de partida, reservatório em condição apropriada e ausência de bloqueio. Uma expressão do tipo AUTORIZA = PEDIDO E NIVEL_OK E NÃO FALHA representa a lógica simplificada. Para cada combinação de valores, é possível prever se a saída deve estar ativa, facilitando a elaboração de testes. Entretanto, o exemplo não substitui a análise de parada, confirmação, emergência e transferência de modos.
Quando existem alternativas, ramos paralelos devem ser revisados cuidadosamente. Se o pedido local e o pedido remoto aparecem em paralelo, mas a permissão geral se aplica apenas a um ramo, a outra origem pode contornar inadvertidamente o bloqueio. A expressão booleana do conjunto deve deixar claro que permissivos comuns se aplicam a todas as origens de comando. A separação entre pedido e comando final facilita essa revisão.
Outra boa prática é evitar que o símbolo Ladder seja interpretado como descrição física do circuito. Um contato de software negado pode estar relacionado a um instrumento normalmente aberto no campo, dependendo da parametrização. A lista de sinais e os diagramas elétricos devem permitir reconstruir a relação entre entrada física, variável e condição lógica.
Estados de sequência e temporização
Um programa Ladder pode controlar uma sequência por etapas, mas a engenharia precisa evitar transições implícitas e estados sobrepostos. Em um ciclo de lavagem, cada etapa deve possuir condição de entrada, ações permitidas, condição de conclusão, tempo máximo e caminho de falha. A presença de um temporizador expirado não deve ser usada para presumir que uma válvula completou seu movimento quando existe retorno de posição disponível. A sequência deve incorporar medições e confirmações coerentes com o processo.
As regras de temporização precisam esclarecer qual evento inicia a contagem e o que ocorre quando a condição desaparece. Em alguns casos, deseja-se um atraso acumulado; em outros, a contagem deve reiniciar sempre que a condição deixa de existir. A escolha errada pode causar alarmes falsos ou partidas prematuras. Testes dinâmicos, e não somente tabelas de verdade estáticas, são necessários para demonstrar o comportamento.
Para sequências extensas, diagramas de estados complementam a leitura de Ladder. Eles ajudam a mostrar ao operador e à equipe de manutenção o significado das etapas e os motivos de bloqueio, sem transformar todas as condições em redes pouco legíveis.
Critérios de auditoria de um programa Ladder
As evidências devem demonstrar comando, bloqueio, falha e recuperação nas condições contratadas.
Uma auditoria técnica deve procurar variáveis escritas em mais de um ponto, instruções de retenção sem reset definido, lógicas de bypass não autorizadas, comandos sem confirmação, escalas inconsistentes e diagnósticos insuficientes. Não se trata de exigir um estilo visual único, mas de verificar se o código é legível, consistente e capaz de ser mantido com segurança. O uso de bibliotecas precisa estar vinculado a versões e ensaios compatíveis com a aplicação.
O processo de revisão pode começar pela descrição funcional, seguir para a matriz de sinais, verificar as redes e concluir com testes em simulação ou bancada. Essa sequência reduz a probabilidade de avaliar somente a aparência da lógica. Cada não conformidade deve identificar requisito, risco, correção e evidência de reteste. Mudanças podem afetar outras rotinas, de modo que a revisão necessita considerar dependências.
Na entrega, a organização deve receber arquivos, versões, documentação e resultados suficientes para restaurar o programa e compreender seu funcionamento. Sem isso, a lógica pode estar operacional no momento do SAT, mas representar risco elevado de manutenção no ciclo de vida.
| Situação | Verificação | Evidência |
| Permissivo ausente | Saída bloqueada | Teste de intertravamento |
| Falha de sensor | Estado definido | Matriz de falhas |
| Retorno de energia | Inicialização adequada | Teste de retomada |
| Mudança de programa | Sem regressão | Versão e reteste |
A matriz sintetiza critérios que devem ser confirmados pelos documentos e ensaios específicos de cada aplicação.
Considerações finais
O desenvolvimento de automação confiável exige projeto coerente com o processo, interfaces documentadas, software mantível e ensaios rastreáveis. O foco deve permanecer na função operacional que o sistema precisa cumprir e nos critérios que demonstram esse resultado.
As funções críticas de controle exigem testes em cenários de falha, reinício e perda de comunicação, com evidências rastreáveis aos requisitos.
Referências técnicas
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 61131-3:2025 — Programming languages. Disponível em: https://webstore.iec.ch/en/publication/68533.
[2] PLCOPEN. Software Construction Guidelines. Disponível em: https://www.plcopen.org/guidelines/software-construction-guidelines/.
[3] PLCOPEN. Guidelines. Disponível em: https://www.plcopen.org/guidelines/.
[4] SIEMENS. S7-1200 Programmable Controller: documentation guide. Disponível em: https://docs.tia.siemens.cloud/r/simatic_s7_1200_manual_collection_enus_20/introduction/s7-1200-documentation-guide?contentId=c4BgYealLTO2SbNyk6T7_A.
[5] PLCOPEN. Downloads: IEC 61131-3. Disponível em: https://plcopen.org/downloads.
Perguntas frequentes
Linguagem gráfica de programação de CLP por redes de contatos e bobinas.
O contato lógico testa um estado de variável; a ligação física depende de sensores e circuitos.
Teste da condição falsa da variável, não necessariamente um contato físico normalmente fechado.
Técnica de retenção lógica de um comando sob condições controladas.
O resultado pode depender da ordem de execução; essa condição requer revisão.
Uma rotina Ladder não comprova por si só a integridade de funções de segurança.
Usar tabela-verdade, estados, simulação, testes de interface e FAT/SAT.
Não. Há também ST, FBD e recursos de sequenciamento.
Código, dependências, matriz funcional, versão e testes conforme contrato.
