Como funciona um ciclo de varredura de CLP: Simulando a execução determinística no OLLA Lab

Um ciclo de varredura de CLP é um loop determinístico no qual o controlador lê entradas, executa a lógica sequencialmente, escreve saídas e realiza tarefas do sistema. O OLLA Lab mimetiza esse comportamento em um ambiente de simulação baseado em navegador para que engenheiros possam observar falhas dependentes da varredura, testar revisões de lógica e validar causa e efeito antes do comissionamento real.

Um equívoco comum é que a lógica ladder se comporta como um software comum reagindo instantaneamente a eventos. Não é o caso. Um CLP geralmente pesquisa a realidade em uma varredura repetitiva, avalia a lógica em uma ordem definida e atualiza as saídas após a conclusão dessa avaliação. Essa distinção é a diferença entre um código que parece correto e um código que sobrevive a uma máquina.

Durante uma avaliação interna recente do cenário de triagem de alta velocidade do OLLA Lab, 68% dos usuários juniores falharam em capturar um pulso de sensor óptico de 10 ms quando o tempo de varredura simulado foi definido para 20 ms [Metodologia: n=41 usuários; tarefa = detectar e travar um pulso transiente de fotocélula em um cenário de rejeição de esteira; comparador de linha de base = captura de pulso bem-sucedida com varredura simulada de 5 ms; janela de tempo = 15 de jan a 10 de mar de 2026]. Este é um benchmark interno da Ampergon Vallis, não uma alegação de prevalência na indústria. Ele sustenta um ponto restrito: o tempo de varredura é frequentemente mal compreendido, mesmo quando a lógica do degrau parece sintaticamente correta.

É exatamente aí que o OLLA Lab é útil. Ele fornece um ambiente de software-in-the-loop delimitado para observar a execução determinística, visibilidade de E/S e modos de falha dependentes da varredura antes que alguém aprenda a lição em uma máquina real, onde o custo do erro é muito maior.

Um ciclo de varredura de CLP padrão é uma sequência repetitiva e determinística com quatro fases funcionais. A implementação exata varia de acordo com o fornecedor e o modelo de tarefa, mas o padrão central é estável em toda a execução cíclica convencional.

O ponto chave de engenharia é simples: o programa geralmente não lê uma entrada física nova a cada instrução. Ele trabalha a partir de uma imagem de memória durante a execução e, em seguida, atualiza as saídas posteriormente.

1. Varredura de Entrada (Leitura) O controlador lê o estado atual das entradas físicas e copia esses estados para a memória, frequentemente chamada de tabela de imagem de entrada ou imagem de processo.
2. Execução do Programa (Lógica) O controlador executa o programa do usuário usando os estados de entrada armazenados. Na lógica ladder, isso é tipicamente avaliado de cima para baixo e da esquerda para a direita dentro da tarefa ativa ou estrutura de rotina.
3. Varredura de Saída (Escrita) O controlador escreve os estados de saída finais calculados da memória para os terminais de saída físicos.
4. Manutenção (Comunicações/Diagnósticos) O controlador atende a diagnósticos internos, comunicações, atualizações de temporizadores, mensagens e outras tarefas do sistema.

Por que isso é importante na prática

A execução baseada em varredura cria comportamentos previsíveis, porém não óbvios:

• Um pulso curto pode ser perdido se ocorrer entre varreduras.
• Uma bobina escrita duas vezes em uma varredura pode ser silenciosamente sobrescrita.
• Uma saída que parece verdadeira em um degrau pode nunca energizar fisicamente se um degrau posterior a redefinir antes da fase de atualização de saída.
• Suposições de tempo que parecem inofensivas na tela podem falhar diante da dinâmica real do processo.

É por isso que conhecer a sintaxe ladder não é o mesmo que estar pronto para a simulação. Operacionalmente, um engenheiro pronto para simulação pode provar, observar, diagnosticar e fortalecer a lógica de controle contra o comportamento real do processo antes que ele chegue a um processo real.

Linguagens de TI de propósito geral não estão inerentemente erradas para software. Elas estão erradas para explicar a execução de CLP se o modelo de controle for ignorado. O problema não é o prestígio da linguagem; é a semântica de execução.

Execução de TI versus Execução de OT

| Recurso | Linguagens de TI (Python/JavaScript, em geral) | Execução de OT / CLP (contexto IEC 61131-3) | |---|---|---| | Modelo de gatilho primário | Orientado a eventos, a callbacks ou a agendadores | Pesquisa cíclica e execução de tarefa determinística | | Relação com a memória | Alocação dinâmica é comum | Tags predefinidas, memória estruturada, mapeamento direto de processo | | Interação com hardware | Geralmente abstraída por drivers/APIs | Relação direta com imagens de E/S, estados de campo e tempo de varredura | | Tempo de execução | Frequentemente não determinístico no nível da aplicação | Projetado para execução de controle repetível e delimitada | | Modo de falha | Latência, condições de corrida, problemas de ordem de callback | Pulsos perdidos, lógica de sobrescrita, suposições de imagem obsoleta | | Prioridade de engenharia | Vazão, flexibilidade, interação do usuário | Determinismo, repetibilidade, comportamento seguro da máquina |

A norma IEC 61131-3 define as linguagens de programação e conceitos de execução usados no controle industrial, incluindo Diagrama Ladder, Diagrama de Blocos de Funções, Texto Estruturado e Gráfico de Funções Sequenciais (IEC, 2013). Na prática, o controle de CLP depende do comportamento determinístico da tarefa, manipulação explícita de estado e ordem de varredura previsível. Softwares web frequentemente assumem que o mundo pode esperar pelo próximo evento. Bombas, cilindros e esteiras geralmente não podem.

O contraste importante

O contraste claro é este: resposta a eventos versus controle cíclico.

Essa diferença importa porque a automação física não trata apenas de calcular um resultado. Trata-se de calcular o resultado no momento certo, na ordem certa, contra condições de planta em constante mudança.

A execução sequencial de ladder significa que o controlador avalia a lógica em uma ordem definida, não tudo de uma vez. Em uma varredura convencional, o programa é resolvido degrau por degrau, do topo da rotina para baixo e, dentro de cada degrau, da esquerda para a direita, de acordo com as regras de execução da plataforma.

Consequências observáveis da execução sequencial

- A solução de problemas deve distinguir entre:

• A lógica anterior pode definir um bit interno que a lógica posterior usa imediatamente.
• A lógica posterior pode sobrescrever um resultado estabelecido anteriormente na mesma varredura.
• Estados intermediários podem existir na memória durante a execução, embora a saída física ainda não tenha mudado.
• estado da tag na memória
• estado da saída física no terminal

Essa distinção é fácil de perder em uma sala de aula e difícil de ignorar durante o comissionamento.

Fundamentação IEC

A IEC 61131-3 fornece a estrutura da linguagem, mas a documentação do fornecedor e a arquitetura de tempo de execução determinam os detalhes exatos de agendamento de tarefas e atualização. A afirmação segura é esta: a avaliação sequencial e a execução cíclica são comportamentos fundamentais nos sistemas de controle de CLP convencionais, embora os detalhes de implementação difiram por família de controlador.

A síndrome da bobina dupla ocorre quando a mesma saída ou bobina de memória é escrita em mais de um lugar, permitindo que uma instrução posterior sobrescreva uma anterior durante a mesma varredura. O estado final escrito na execução da lógica é aquele que sobrevive até a fase de atualização de saída.

Aqui está o padrão clássico:

DEGRAU 1: O comando de partida define Motor_Run como verdadeiro na memória. |---[ Start_PB ]-------------------------------------( Motor_Run )---|

DEGRAU 2: Uma condição posterior escreve na mesma bobina. Se este degrau for avaliado como falso de uma forma que desenergize o mesmo alvo, o estado anterior é efetivamente sobrescrito antes que as saídas sejam escritas. |---[ Some_Other_Condition ]-------------------------( Motor_Run )---|

O que realmente acontece

- Resultado: o motor pode nunca energizar, embora um degrau anterior parecesse correto.

• O primeiro degrau escreve `Motor_Run = TRUE` na memória.
• Um degrau posterior escreve no mesmo alvo.
• A última escrita determina o estado final da memória ao final da execução.
• A atualização da saída física ocorre posteriormente.

Esta é a execução determinística fazendo exatamente o que a lógica especifica, independentemente da intenção.

Por que essa falha é útil para treinamento

Falhas de bobina dupla expõem três ideias centrais rapidamente:

• a ordem importa
• o estado da memória não é o mesmo que o estado do terminal
• a correção visual do degrau não é suficiente

No OLLA Lab, isso se torna observável em vez de teórico, porque os usuários podem executar a lógica, inspecionar variáveis e comparar o estado do ladder com o comportamento do equipamento simulado.

Um pulso curto pode ser perdido quando sua duração é menor do que a oportunidade efetiva do controlador de amostrá-lo. Se uma entrada liga e desliga entre as varreduras de entrada, a CPU pode nunca registrar o evento na imagem de entrada.

### Exemplo: largura de pulso versus tempo de varredura

Se:

• um pulso de fotocélula dura 10 ms, e
• o controlador amostra as entradas a cada 20 ms,

então o pulso pode ocorrer inteiramente entre as varreduras e desaparecer da perspectiva do programa.

Este é um problema de amostragem. No trabalho de controle, frequentemente aparece como "o sensor disparou definitivamente, mas o CLP nunca viu". Ambas as afirmações podem ser verdadeiras.

Por que os engenheiros devem se importar

Pulsos perdidos afetam:

• triagem de alta velocidade
• lógica adjacente a encoders
• confirmação de rejeição
• contagem de garrafas ou caixas
• sinais de prova intermitentes
• alarmes acionados por borda

A correção pode envolver tarefas mais rápidas, travamento de hardware, alongamento de pulso, one-shots, contadores de alta velocidade ou design de sequência revisado. A resposta correta depende do processo e da arquitetura do controlador.

O OLLA Lab mimetiza a varredura física da CPU fornecendo um ambiente de simulação estruturado no qual a lógica ladder é executada como um loop determinístico, em vez de reações soltas a eventos do navegador. Mais simplesmente, ele foi projetado para permitir que os usuários observem o comportamento de controle dependente da varredura, não apenas desenhem degraus.

O que o OLLA Lab faz em termos delimitados

Dentro da plataforma, os usuários podem:

• construir lógica ladder em um editor baseado na web
• executar lógica em modo de simulação
• alternar e inspecionar entradas, saídas e variáveis
• trabalhar em cenários industriais realistas
• comparar o comportamento do ladder com visualizações de equipamentos em 3D/WebXR/VR onde disponível
• usar o GeniAI, o guia de laboratório de IA, para suporte orientado

Para o escopo deste artigo, o fato importante do produto é mais restrito: o OLLA Lab fornece um ambiente baseado em software para ensaiar a execução de lógica determinística e observar como o tempo de varredura afeta o comportamento da máquina.

Comportamentos observáveis que a plataforma é adequada para demonstrar

• Comportamento de sobrescrita de bobina dupla
• Pulsos transientes perdidos
• Rastreamento de causa e efeito através de E/S
• Falhas de sequência causadas por suposições obsoletas sobre o estado
• Diferenças entre o estado do ladder e o estado do equipamento simulado

Isso o torna útil como um ambiente de ensaio de software-in-the-loop para tarefas de comissionamento de alto risco. Ele não substitui testes de aceitação de hardware, validação de segurança ou comissionamento específico do local. Esses ainda pertencem ao sistema real, com o controlador real, sob as restrições reais.

Por que a entrega via navegador é importante

Um ambiente baseado em navegador reduz o atrito de configuração para aprendizado e revisão. Mais importante, permite a injeção repetida e de baixo risco de falhas sem ocupar um treinador físico ou hardware adjacente à produção.

Neste contexto, validação de gêmeo digital significa testar a lógica ladder contra uma máquina simulada ou modelo de processo e verificar se o comportamento esperado do equipamento corresponde à filosofia de controle sob condições normais e anormais.

Essa definição precisa permanecer fundamentada. Ela não significa que a simulação é um substituto legalmente suficiente para aceitação no local, verificação SIL ou comissionamento de planta.

### Operacionalmente, a validação de gêmeo digital inclui:

• comparar estados de comando com a resposta do equipamento simulado
• verificar a ordem da sequência e permissivos
• verificar o comportamento de alarmes e disparos
• observar mudanças de estado analógicas ou acionadas por PID onde modeladas
• injetar falhas e confirmar a resposta da lógica
• revisar o programa e testar novamente

É aqui que o OLLA Lab se torna operacionalmente útil. Ele permite que engenheiros testem se uma sequência funciona em um modelo realista antes de testá-la em equipamentos que podem travar, inundar, ultrapassar o curso ou falhar de outras maneiras dispendiosas.

Os engenheiros devem praticar o tratamento de falhas dependentes da varredura construindo cenários onde a lógica é forçada a falhar por razões de tempo e, em seguida, revisando o design até que o modo de falha seja controlado e explicável.

### Um exercício prático: captura de pulso em um cenário de esteira

Use um cenário de esteira ou estilo triagem e defina um evento de sensor transiente que seja mais curto do que o intervalo de varredura simulado.

#### Passo 1: Construir a lógica inicial

Crie uma lógica que dependa diretamente de um pulso de fotocélula para acionar uma ação, como rejeitar, contar ou desviar.

#### Passo 2: Definir as condições simuladas

Use um intervalo de varredura que seja mais longo do que a duração do pulso. Em seguida, execute o cenário e observe se o evento é capturado de forma confiável.

#### Passo 3: Inspecionar variáveis e estado do equipamento

Use o painel de variáveis para comparar:

• estado da entrada
• bits de memória interna
• comandos de saída
• resposta do equipamento simulado

#### Passo 4: Injetar o caso de falha

Force um pulso que ocorra rápido demais para as suposições de varredura atuais. Confirme que a lógica o perde.

#### Passo 5: Revisar a lógica

Possíveis revisões incluem:

• adicionar um caminho de travamento ou selo
• usar detecção de borda onde apropriado
• alongar o pulso na lógica
• redesenhar a sequência para evitar a dependência de um transiente estreito
• documentar quando recursos de hardware seriam necessários em um controlador real

#### Passo 6: Executar novamente e verificar

Valide se a lógica revisada captura o evento sob as condições definidas e não cria falsos positivos ou persistência insegura.

Uma galeria de capturas de tela prova que o software foi aberto. Não prova o julgamento de engenharia. Se um aluno deseja demonstrar um entendimento real de controle, o artefato deve mostrar raciocínio, tratamento de falhas e disciplina de revisão.

Use esta estrutura:

Declare exatamente o que o comportamento correto significa. Exemplo: "Um pulso de detecção de produto de 10 ms deve ser capturado e travado para que a sequência de rejeição seja executada uma vez e apenas uma vez."

Documente a falha dependente da varredura. Exemplo: "O pulso foi perdido quando o tempo de varredura excedeu a largura do pulso."

1. Descrição do Sistema Defina a máquina ou segmento de processo, o objetivo de controle e a E/S relevante.
2. Definição operacional do comportamento correto
3. Lógica ladder e estado do equipamento simulado Mostre os degraus relevantes, tags e o comportamento correspondente da máquina simulada.
4. O caso de falha injetado
5. A revisão feita Explique o que mudou na lógica e por quê.
6. Lições aprendidas Resuma o princípio de controle, como o tempo da tabela de imagem, comportamento de sobrescrita ou por que a captura de pulso requer um design explícito.

Esse é o tipo de evidência que um revisor pode interrogar. É também o tipo que tende a se sustentar melhor em uma revisão técnica do que apenas uma captura de tela.

A simulação do ciclo de varredura é valiosa porque torna observável o comportamento invisível do controlador. Seus limites importam tanto quanto.

Uma declaração delimitada do que a simulação pode e não pode fazer

A simulação pode ajudar os engenheiros a:

• entender a execução determinística
• testar a lógica de sequência
• observar falhas relacionadas ao tempo
• ensaiar a solução de problemas
• comparar o comportamento esperado e o simulado do equipamento

A simulação não pode, por si só:

• certificar a competência no local
• substituir a validação específica de hardware
• estabelecer conformidade de segurança funcional
• provar o comportamento final de tempo do fieldbus
• substituir FAT, SAT, verificações de loop ou comissionamento real

Este limite não é uma fraqueza. É parte do que mantém a ferramenta credível.

O treinamento baseado em simulação e modelos digitais estão bem estabelecidos na engenharia industrial, especialmente onde a experimentação direta em ativos reais é dispendiosa ou insegura. A literatura geralmente apoia a simulação como uma forma de melhorar a compreensão do comportamento dinâmico, resposta a falhas e preparação do operador ou engenheiro, ao mesmo tempo em que enfatiza que a fidelidade do modelo e o design da tarefa determinam a utilidade.

Normas relevantes e fundamentação técnica

• IEC 61131-3 define estruturas de linguagem de programação de CLP e conceitos de execução relevantes para o comportamento da lógica ladder (IEC, 2013).
• IEC 61508 estabelece a estrutura mais ampla de segurança funcional e reforça que as alegações de segurança exigem evidências disciplinares do ciclo de vida, não apenas confiança informal na simulação (IEC, 2010).
• exida e orientações de segurança funcional relacionadas enfatizam a verificação, validação e rigor do ciclo de vida no trabalho de automação relacionado à segurança.
• Pesquisas em simulação industrial, gêmeos digitais e ambientes de treinamento mostraram valor no ensaio de falhas, preparação para comissionamento e compreensão humana de sistemas dinâmicos, particularmente quando a simulação está vinculada ao comportamento observável do processo, em vez de apenas instruções abstratas.

A conclusão cuidadosa é esta: a simulação é mais forte quando usada para expor comportamentos, testar suposições e melhorar o julgamento pré-implantação. É mais fraca quando tratada como um atalho para evitar evidências de engenharia.

A alfabetização em ciclos de varredura é importante porque o controle determinístico não é intuitivo para pessoas treinadas em software orientado a eventos ou exemplos de ladder estáticos. Um CLP não percebe tudo no momento em que acontece. Ele amostra, resolve, escreve e repete.

É por isso que o OLLA Lab tem um lugar legítimo no fluxo de trabalho. Ele oferece aos engenheiros um ambiente delimitado para observar a ordem de varredura, inspecionar o estado de E/S, injetar falhas e revisar a lógica antes que esses mesmos erros cheguem a um processo real. Não se trata de fazer a simulação parecer impressionante. Trata-se de tornar a falha visível enquanto o custo de estar errado ainda é tolerável.

Em termos práticos, esse é o movimento da sintaxe para a capacidade de implantação.

- IEC 61131-3: Controladores programáveis — Parte 3 - Visão geral da norma de segurança funcional IEC 61508 - Perfil de Manufatura Inteligente do NIST - IEEE Access: Tecnologias habilitadoras de gêmeos digitais (DOI)

Equipe de Engenharia da Ampergon Vallis.

Conteúdo revisado tecnicamente quanto à precisão dos conceitos de ciclo de varredura IEC 61131-3 e aplicabilidade da simulação no OLLA Lab.