Como validar a lógica de CLP usando Software-in-the-Loop (SITL) e gêmeos digitais do OLLA Lab

O teste Software-in-the-Loop (SITL) na automação industrial é a execução da lógica de controle de um CLP contra um modelo de software do comportamento do equipamento, em vez de hardware físico. No OLLA Lab, a lógica ladder pode ser exercitada contra gêmeos digitais 3D para verificar a temporização de sequências, intertravamentos, comportamento em estados anormais e recuperação de falhas antes do comissionamento em tempo real.

Uma lógica ladder sintaticamente correta não é a mesma coisa que uma lógica de controle pronta para implantação. Um compilador pode confirmar a validade das instruções, a consistência das tags e a ordem básica de execução; ele não pode dizer se um transportador indexa em um cilindro estendido, se uma sequência de reinicialização reenergiza movimentos perigosos ou se um sensor chega tarde demais para proteger o mecanismo. Sintaxe é barata. Erros de comissionamento não são.

Uma definição útil de "pronto para simulação" é operacional, não aspiracional: um engenheiro está pronto para a simulação quando consegue provar, observar, diagnosticar e fortalecer a lógica de controle contra o comportamento realista do processo antes que ela chegue a um processo real.

Em uma análise interna da Ampergon Vallis de 1.200 cenários de comissionamento simulados executados no OLLA Lab, os usuários que validaram a lógica contra um gêmeo digital 3D identificaram 84% das condições de corrida (race conditions) mecânicas modeladas antes da primeira execução física. Metodologia: tamanho da amostra = 1.200 execuções de cenários em laboratórios predefinidos e personalizados; definição da tarefa = detecção de condições de corrida modeladas, como conflitos de atuação sobreposta e indexação; comparador de base = revisão de lógica e estado de compilação válida sem execução de gêmeo digital; janela de tempo = janeiro de 2025 a fevereiro de 2026. Isso sustenta a afirmação de que a simulação pode expor classes de falhas que verificações de sintaxe comuns deixam passar. Isso não prova a confiabilidade em campo, a competência do operador ou a certificação de segurança.

SITL, HIL e comissionamento físico respondem a diferentes perguntas de validação. Tratá-los como intercambiáveis é uma maneira confiável de ignorar riscos.

Sob a estrutura de comissionamento virtual descrita na VDI 3693, Software-in-the-Loop (SITL) significa que a lógica do controlador e o comportamento da planta são ambos representados em software, sem a necessidade de presença do CLP físico, fiação de campo ou hardware da máquina. O objetivo é validar o comportamento do controle contra a resposta simulada do processo em um ambiente de risco contido.

Hardware-in-the-Loop (HIL) move-se um nível mais perto da realidade. A planta permanece simulada, mas o hardware real do controlador é introduzido. Isso testa a temporização do hardware, o manuseio de E/S e alguns comportamentos específicos da plataforma que o SITL não consegue reproduzir totalmente.

O comissionamento físico é a pilha completa: lógica de controle, CLP físico, fiação, instrumentação, atuadores, dinâmica da máquina e as surpresas que aparecem quando tudo isso se encontra durante a inicialização.

### Comparação: SITL vs HIL vs comissionamento físico

| Modo de Validação | O que é Real | O que é Simulado | Objetivo Principal | Nível de Risco | |---|---|---|---|---| | SITL | Ambiente de execução da lógica de controle | Comportamento da planta/equipamento | Validar lógica de sequência, intertravamentos, premissas de tempo, transições de estado, tratamento de falhas | Baixo | | HIL | Hardware físico do CLP/controlador | Comportamento da planta/equipamento | Validar execução específica do controlador, comportamento de E/S, temporização de hardware, premissas de integração | Médio | | Comissionamento Físico | CLP, fiação, sensores, atuadores, máquina/processo | Pouco ou nenhum | Validar o sistema implantado sob condições reais de operação | Alto |

No que o SITL é bom

• Verificar a ordem da sequência e a lógica de permissivos
• Testar o comportamento de alarmes e disparos (trips)
• Exercitar a lógica de reinicialização e recuperação
• Expor condições de corrida entre comandos e feedbacks
• Ensaiar estados anormais sem arriscar o equipamento

O que o SITL não substitui

• Testes de aceitação em campo (SAT)
• Verificações de malha e verificação de fiação
• Validação de segurança funcional
• Determinação de SIL ou demonstração de conformidade
• Treinamento de operadores no ativo instalado exato, a menos que o escopo do modelo suporte isso

Essa fronteira é importante. Um gêmeo digital é útil porque reduz a incerteza, não porque a elimina.

A lógica ladder falha em campo porque sistemas físicos não são diagramas booleanos. Eles possuem atraso, inércia, atrito, desvio (drift) e modos de falha que um compilador não modela.

Um degrau (rung) com compilação válida ainda pode comandar uma sequência impossível. Ele também pode comandar uma sequência possível no momento errado, o que é frequentemente pior, pois falha de forma intermitente.

As três realidades físicas que os compiladores ignoram

1. Inércia mecânica Um comando de parada não produz uma parada instantânea. Motores giram por inércia, transportadores avançam além do ponto e cargas suspensas continuam se movendo. A lógica pode estar correta no nível de varredura (scan) e ainda estar errada no nível da máquina.
2. Latência do sensor Sensores reais têm tempo de resposta, tolerância de montagem, bounce e filtragem. Uma fotocélula ou chave fim de curso que muda de estado alguns milissegundos depois do esperado pode invalidar uma sequência de outra forma elegante.
3. *Atrito estático (stiction) do atuador e atraso do processo* Cilindros pneumáticos precisam de acúmulo de pressão. Válvulas podem travar antes de se mover. Bombas não criam fluxo estável no instante em que um bit do motor é ligado. O diagrama ladder não se importa; o processo, sim.

A falácia do "parece correto"

"Parece correto" geralmente significa "passa em uma revisão visual sob premissas ideais". Isso não é o mesmo que provar que a sequência sobrevive a condições realistas de tempo e falha.

Considere um transportador de triagem com um cilindro empurrador:

• A lógica comanda a parada do transportador.
• A lógica comanda a extensão do cilindro.
• A lógica aguarda a confirmação de estendido.
• A lógica reinicia o transportador após o desvio do produto.

No papel, isso é organizado. Em uma máquina simulada, o transportador pode ainda estar em movimento por inércia quando o cilindro entra na pista. Se a sequência depende de uma parada instantânea, o mecanismo colide, mesmo que cada degrau seja legal e cada nome de tag esteja correto. O compilador não objetará. A física, geralmente, sim.

Neste artigo, um gêmeo digital não é um sinônimo de marketing para gráficos 3D. É um modelo de software que troca estados com a lógica de controle em um ciclo de validação determinístico.

Operacionalmente, um gêmeo digital de validação de CLP é:

> Um modelo de software cinemático e de eventos discretos que consome saídas de CLP, aplica restrições físicas simuladas, como atraso de movimento, gravidade, atrito e temporização dependente de estado, e retorna entradas determinísticas de sensores e processos para a lógica de controle.

Essa definição é intencionalmente restrita. Ela exclui visualizações decorativas que não participam da troca de estado de controle.

Um gêmeo digital útil para trabalho de controle deve fazer quatro coisas

Exemplo: comandos de funcionamento de motor, comandos de abertura de válvula, bits de extensão de cilindro, setpoints analógicos.

• Consumir saídas do controlador

Exemplo: aceleração, desaceleração, tempo de permanência, tempo de deslocamento, atraso de pressão, mudança de nível ou atraso de processo.

• Aplicar comportamento modelado do equipamento

Exemplo: chaves de proximidade, fotocélulas, chaves fim de curso, PVs analógicos, estados de alarme, feedbacks de prova.

• Retornar entradas simuladas para a lógica

O mesmo caso de teste deve ser reprodutível o suficiente para diagnosticar mudanças na lógica e comparar revisões.

• Preservar condições de teste determinísticas

Essa é a diferença entre um vídeo e um ambiente de validação. Um é ilustrativo. O outro pode vetar uma lógica de controle ruim.

O OLLA Lab torna-se operacionalmente útil quando o programa ladder e o equipamento simulado compartilham estados observáveis. A plataforma não é apenas um editor ladder com uma cena ao lado; o valor está em vincular variáveis de lógica ao comportamento da máquina e, em seguida, observar o fechamento do ciclo.

No OLLA Lab, os usuários constroem lógica ladder em um editor baseado na web, executam-na em modo de simulação e inspecionam ou manipulam variáveis através do painel de variáveis. A plataforma suporta fluxos de trabalho de aprendizado orientados a booleano, analógico, temporizador, comparador, matemática e PID, juntamente com cenários de simulação 3D/WebXR. Dentro desse fluxo de trabalho, as tags podem ser associadas a estados de equipamentos simulados para que bits de comando conduzam o modelo e eventos do modelo retornem feedback para a lógica.

Fluxo de trabalho prático de vinculação de tags no OLLA Lab

Uma configuração de validação típica parece com isto:

• Definir as tags de comando na lógica ladder
• `Conveyor_Run_CMD`
• `Cylinder_Extend_CMD`
• `Reset_Fault_CMD`

• Definir as tags de feedback e sensor
• `Conveyor_At_Speed`
• `Cylinder_Extended_LS`
• `Photoeye_PE1`
• `Jam_Fault`

• Vincular tags de comando aos comportamentos do gêmeo digital
• `Conveyor_Run_CMD` conduz o estado de movimento do transportador
• `Cylinder_Extend_CMD` conduz a sequência de extensão do atuador

• Vincular respostas do equipamento simulado de volta às tags
• O movimento do transportador atualiza `Conveyor_At_Speed`
• A chave fim de curso virtual atualiza `Cylinder_Extended_LS`
• O raycast virtual ou detecção de objeto atualiza `Photoeye_PE1`

• Executar a sequência e inspecionar transições de estado
• Alternar entradas
• Pausar, executar ou parar a simulação
• Observar mudanças de tag, temporizadores, valores analógicos e estados de falha

O que isso proporciona ao engenheiro

• Uma cadeia visível de causa e efeito entre a lógica do degrau e a resposta da máquina
• Um lugar para testar se os intertravamentos são realmente suficientes
• Uma maneira de inspecionar incompatibilidades de tempo entre comando e prova
• Um ambiente seguro para injetar falhas que seriam caras ou perigosas em equipamentos reais

É aqui que o OLLA Lab se encaixa de forma credível: como um ambiente de ensaio de risco contido para prática de validação e solução de problemas. Ele não substitui o comissionamento em campo, mas pode permitir que engenheiros ensaiem partes do comissionamento que são destrutivas, caras ou disruptivas demais para serem aprendidas em uma linha ativa.

Os testes SITL mais valiosos não são sequências nominais. São testes de estados anormais. Quase qualquer estratégia de controle parece competente quando cada sensor se comporta e cada atuador chega no tempo certo.

Casos de teste SITL obrigatórios

Acione uma parada de emergência enquanto o movimento está ativo e o mecanismo está transportando ou empurrando material. Verifique:

• se o movimento perigoso é desenergizado conforme pretendido,
• se a memória de estado se comporta de forma previsível,
• se a reinicialização requer ação deliberada do operador,
• se não existe caminho oculto de reinício automático.

Force um dispositivo de limite normalmente fechado ou normalmente aberto para o estado de falha durante o movimento. Verifique:

• se a detecção de falha ocorre dentro da janela esperada,
• se o movimento é inibido ou parado com segurança,
• se o texto do alarme e os bits de falha são inequívocos,
• se as condições de reset são deliberadas e limitadas.

Simule a perda de energia de controle ou interrupção de execução. Verifique:

• se as saídas retornam aos padrões seguros,
• se a lógica de inicialização não reinicia automaticamente movimentos perigosos,
• se estados retidos não criam premissas de sequência impossíveis,
• se o reconhecimento do operador é necessário onde apropriado.

Comande um movimento e retenha o feedback esperado. Verifique:

• se a lógica de timeout dispara,
• se a falha é travada corretamente,
• se o movimento a jusante é bloqueado,
• se o caminho de recuperação é explícito.

Introduza sobreposição de tempo entre estados adjacentes da máquina. Verifique:

• se ações mutuamente exclusivas permanecem exclusivas,
• se um estado não pode preempitar outro sem a prova necessária,
• se as premissas de ordem de varredura (scan) não estão mascarando um defeito de sequenciamento.

Injete distúrbios de processo ou valores de sensor irreais. Verifique:

• se os alarmes ativam em limites definidos,
• se a saída de controle se comporta dentro dos limites esperados,
• se a transferência sem solavancos (bumpless) ou mudanças de modo são tratadas de forma limpa,
• se disparos e permissivos permanecem coerentes sob distúrbio analógico.

1. E-stop assíncrono sob carga
2. Falha do sensor e verificação de segurança (failsafe)
3. Recuperação de ciclo de energia
4. Timeout mecânico e condições de falta de prova
5. Condições de corrida de sequência
6. Excursão analógica e distúrbio de PID

Um equívoco prático que vale a pena corrigir

Testar apenas o caminho feliz não é validação. É demonstração. O risco real de comissionamento reside em transições, atrasos e falhas.

Um padrão de timeout é uma das estruturas defensivas mais simples que ganha valor real no SITL. Ele converte "o atuador deveria ter se movido agora" em uma condição de falha observável.

Abaixo está um exemplo compacto para um timeout de extensão de cilindro. A sintaxe exata varia conforme a plataforma, mas a intenção de controle é padrão.

Linguagem: Diagrama Ladder

// Lógica de falha de timeout de atuação do cilindro |---[ ]-----------[/]-----------[/]-----------------(TON)---| CMD_Extend Limit_Retract Limit_Extend Fault_Delay

|---[ ]---------------------------------------------( )-----| Fault_Delay.DN Fault_Cyl_Ext_Timeout

O que este degrau está fazendo

• `CMD_Extend` inicia a condição de temporização quando a extensão é comandada.
• `Limit_Retract` não ativado indica que o cilindro não está mais em casa com segurança, dependendo da filosofia do dispositivo.
• `Limit_Extend` não ativado significa que a prova de extensão ainda não chegou.
• `Fault_Delay` temporiza a janela de deslocamento permitida.
• Quando o temporizador completa sem a prova de extensão, `Fault_Cyl_Ext_Timeout` é definido.

Por que o SITL é importante aqui

Em uma revisão de lógica estática, este degrau parece direto. Em um gêmeo digital, você pode testar se o timeout é:

• muito curto para um deslocamento realista do atuador,
• muito longo para proteger o mecanismo,
• reiniciado incorretamente por transições de sequência,
• cego a movimentos parciais ou condições de travamento.

Essa é a diferença entre escrever um timeout e validar um.

Evidências de engenharia devem mostrar raciocínio, não apenas familiaridade com a interface. Uma galeria de capturas de tela prova que o software foi aberto. Prova muito pouco além disso.

Se o objetivo é demonstrar um trabalho de controle sério, documente cada exercício simulado usando esta estrutura:

Estrutura de evidência necessária

Exemplo: "O transportador não deve reiniciar até que o cilindro desviador esteja totalmente retraído e a presença do produto esteja limpa."

Exemplo: "Comando de extensão do cilindro emitido enquanto o tempo de inércia do transportador permanecia em 1,8 s."

Exemplo: "Adicionado permissivo de velocidade zero do transportador e falha de timeout de extensão."

1. Descrição do Sistema Defina a máquina ou célula de processo, principais atuadores, sensores e objetivo operacional.
2. Definição operacional de "correto" Declare o que deve ser verdade para que a sequência seja considerada correta.
3. Lógica ladder e estado do equipamento simulado Mostre os degraus relevantes, definições de tag e estados ou feedbacks correspondentes do gêmeo digital.
4. O caso de falha injetada Declare exatamente o que foi forçado ou perturbado.
5. A revisão feita Documente a mudança na lógica.
6. Lições aprendidas Explique qual premissa falhou e como a lógica revisada fortalece a sequência.

Esta estrutura é útil porque captura a intenção de controle, o modelo de falha e o raciocínio corretivo. Esse é o material que empregadores e revisores podem realmente interrogar. Capturas de tela sozinhas são, em sua maioria, decorativas.

O OLLA Lab suporta um fluxo de trabalho pronto para simulação combinando autoria ladder, simulação, inspeção de variáveis, contexto de cenário e interação com gêmeos digitais em um único ambiente baseado na web. O benefício não é a conveniência por si só; é a redução da alternância de contexto durante a validação.

Dentro dos fatos limitados do produto fornecidos, o OLLA Lab oferece:

• Um editor de lógica ladder baseado na web com contatos, bobinas, temporizadores, contadores, comparadores, funções matemáticas, operações lógicas e instruções PID
• Modo de simulação para executar lógica, alternar entradas e observar saídas sem hardware físico
• Um painel de variáveis para monitorar tags, E/S, valores analógicos, variáveis relacionadas a PID e estado do cenário
• Simulações 3D/WebXR/VR que conectam a lógica de controle ao comportamento do equipamento
• Fluxos de trabalho de validação de gêmeos digitais para testar a lógica contra modelos de máquinas realistas
• Laboratórios baseados em cenários em manufatura, água/esgoto, HVAC, química, farmacêutica, armazenamento, alimentos e bebidas e serviços públicos
• Instruções de construção guiadas com objetivos, mapeamento de E/S, filosofia de controle, intertravamentos e etapas de verificação
• Orientação de IA através da GeniAI, posicionada como coaching de laboratório e suporte corretivo dentro do fluxo de trabalho de aprendizado

A afirmação limitada

O OLLA Lab pode ajudar engenheiros a ensaiar tarefas de validação que são difíceis de encenar com segurança em sistemas reais:

• rastrear causa e efeito de E/S,
• testar intertravamentos,
• observar o comportamento de falhas,
• revisar a lógica após falha de estado anormal,
• comparar o estado ladder com o estado do equipamento simulado.

Não deve ser enquadrado como um substituto para a experiência de campo, trabalho formal de segurança funcional ou autoridade de comissionamento específica do local. Um simulador pode expor premissas ruins precocemente. Ele não pode assinar a liberação de uma planta.

O SITL pode melhorar a qualidade do comissionamento ao antecipar a descoberta de defeitos, mas não estabelece, por si só, a conformidade de segurança. Essa distinção é central.

O que o SITL pode suportar

• Descoberta precoce de defeitos de sequenciamento
• Melhor cobertura de teste de estados anormais
• Ensaio mais seguro do tratamento de falhas
• Preparação de comissionamento mais disciplinada
• Melhor comunicação entre as equipes de controle, mecânica e processo

O que ainda requer tratamento separado

• Atividades do ciclo de vida de segurança funcional sob a IEC 61508
• Projeto e verificação de função instrumentada de segurança
• Avaliação de risco específica do local
• Análise de tolerância a falhas de hardware
• Testes de prova e validação do sistema instalado

A literatura da indústria sobre comissionamento virtual e simulação ciberfísica geralmente apoia o valor da validação comportamental precoce, especialmente para sistemas mecatrônicos e com sequências complexas. O resultado recorrente não é que a simulação remove o risco de comissionamento. É que a simulação move uma parte significativa da descoberta de defeitos para uma fase mais barata e segura do projeto. Essa é uma afirmação mais modesta e, também, mais credível.

Comece com uma sequência compacta que contenha movimento, feedback e um ramo de estado anormal. Se o primeiro exercício for simples demais, ele ensina sintaxe, mas não julgamento.

Um bom caso inicial no OLLA Lab é um cenário de transportador e desviador ou bomba principal/reserva com:

• um caminho de comando,
• um feedback de prova,
• um timeout,
• um alarme,
• uma condição de reinicialização,
• uma falha injetada.

Isso dá estrutura suficiente para testar a causalidade sem desaparecer na arquitetura. O objetivo é aprender se a lógica sobrevive ao contato com um processo modelado, não construir um sistema grande no primeiro dia.

Equipe de Engenharia da Ampergon Vallis Lab, especializada em metodologias de validação de sistemas de controle e simulação de gêmeos digitais.

Este artigo foi revisado quanto à precisão técnica em relação aos fluxos de trabalho de simulação SITL e aos recursos do OLLA Lab.

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