Como programar um veto determinístico em um CLP de segurança para anular alucinações de IA

Para anular alucinações de IA em automação industrial, os engenheiros devem colocar a IA atrás de um veto determinístico de CLP. O CLP deve verificar os comandos solicitados pela IA em relação a limites fixos, permissivos de estado e funções de segurança cabeadas antes que qualquer atuação ocorra. Essa defesa em camadas separa a otimização probabilística da execução determinística.

A IA não se torna segura só porque soa confiante. No controle industrial, confiança não é uma variável de controle.

O conflito de engenharia é direto: LLMs e sistemas de IA agentica são probabilísticos e não determinísticos, enquanto CLPs executam lógica em ciclos de varredura (scan cycles) repetíveis com comportamento limitado. Essa diferença não é filosófica. É arquitetural e, em contextos relevantes para a segurança, é decisiva.

Em um lote interno recente de 500 anomalias de setpoint geradas por IA simuladas através dos fluxos de trabalho de validação de gêmeos digitais do OLLA Lab, um limitador de taxa de variação (rate-of-change clamp) no lado do CLP, somado a permissivos de estado explícitos, bloqueou 100% dos comandos catastróficos fora dos limites antes que eles atuassem nos modelos virtuais de válvulas e motores. Metodologia: n=500 casos de anomalia injetados em tarefas de velocidade, pressão e posição de válvula limitadas; comparador de linha de base = passagem direta do comando solicitado pela IA para a tag do atuador simulado; janela de tempo = execuções internas do laboratório da Ampergon Vallis conduzidas no 1º trimestre de 2026. Isso sustenta o valor da verificação determinística em simulação. Não constitui certificação IEC 61508, evidência de SIL ou uma afirmação sobre todas as arquiteturas de planta.

A resposta prática não é banir a IA. É negar à IA autoridade de execução direta e exigir que o CLP mantenha um veto determinístico permanente.

As alucinações de IA exigem um veto determinístico porque as saídas da IA não têm garantia de serem limitadas, repetíveis ou síncronas ao ciclo de varredura da maneira que a execução do CLP deve ser.

Em um sistema de controle, um comando inseguro é inseguro mesmo que tenha sido gerado por um modelo estatisticamente impressionante. Uma válvula não se importa que a probabilidade do token parecesse persuasiva.

A IEC 61508 e a ISO 13849 são construídas em torno de comportamento previsível, tratamento de falhas definido e estados seguros conhecidos. As funções de controle relacionadas à segurança devem falhar de maneiras que possam ser analisadas, limitadas e validadas. Os sistemas atuais do tipo LLM não atingem esse patamar porque seus modos de falha não são exaustivamente caracterizáveis da maneira que a lógica de segurança determinística exige. Esse é o verdadeiro problema: não que a IA seja nova, mas que a IA não é sistematicamente limitada o suficiente para possuir o caminho final de atuação.

O ciclo de varredura vs. o motor de inferência

Um CLP executa lógica ciclicamente. Ele varre entradas, resolve a lógica, atualiza saídas e repete em um intervalo conhecido, frequentemente na faixa de milissegundos, dependendo da plataforma, estrutura da tarefa e carga.

Um motor de inferência de IA não se comporta dessa maneira. Seu tempo de resposta varia com o tamanho do modelo, disponibilidade de computação, condições de rede, sobrecarga de orquestração e complexidade do prompt. Mesmo quando a latência média parece aceitável, o pior cenário de tempo e comportamento de saída continua sendo o problema.

Isso cria duas classes de risco:

- Risco de temporização: a resposta da IA pode chegar atrasada, fora de sequência ou durante um estado de máquina inválido. - Risco de conteúdo: a resposta da IA pode solicitar uma ação impossível, insegura ou cega ao contexto.

Um CLP pode tolerar solicitações atrasadas ou rejeitadas. Um trem de bombas não pode tolerar fantasia.

O que as normas realmente exigem?

As normas exigem comportamento de segurança previsível, não software da moda.

Em um nível elevado:

• IEC 61508 aborda a segurança funcional de sistemas elétricos, eletrônicos e eletrônicos programáveis relacionados à segurança.
• ISO 13849 aborda partes de sistemas de controle relacionadas à segurança, particularmente em contextos de máquinas.
• Ambas as estruturas dependem de arquiteturas definidas, comportamento validado e respostas conhecidas a condições de falha.

Isso não significa que todo componente de software não determinístico seja proibido em qualquer lugar em uma pilha industrial. Significa que componentes não determinísticos não devem ser tratados como a autoridade final de segurança. A distinção é importante. Percepção e otimização podem ser probabilísticas; o veto e o caminho de desligamento não podem.

Um veto determinístico é uma estrutura lógica codificada e vinculada ao ciclo de varredura que avalia um comando solicitado e o bloqueia, limita ou anula quando o comando viola limites físicos, restrições de processo ou permissivos de estado da máquina.

Esta é uma definição operacional, não um slogan. Um veto determinístico deve ser observável na lógica e testável contra casos de falha.

Na prática, um veto determinístico geralmente inclui:

- Verificação de limites (Bounds checking): rejeitar ou limitar valores acima ou abaixo dos limites permitidos. - Limitação de taxa de variação (Rate-of-change limiting): prevenir mudanças abruptas além das taxas de rampa seguras. - Permissivos de estado: permitir comandos apenas em estados operacionais válidos. - Verificações de feedback de prova: exigir confirmação de dispositivos de campo antes de avançar a sequência. - Tratamento de alarmes e disparos (trips): forçar uma resposta segura em condições anormais. - Isolamento de modo: prevenir ações remotas ou solicitadas por IA em modos local, manutenção ou com falha.

Se a IA solicita 150% de velocidade de acionamento e o CLP limita ao máximo configurado enquanto dispara um alarme, o veto funcionou. Se a IA pode escrever diretamente na imagem de saída, a arquitetura está errada.

Definições operacionais que importam

Estes termos são frequentemente usados de forma vaga. Eles não deveriam ser.

- Veto determinístico: lógica de CLP que avalia uma solicitação externa ou gerada por IA a cada varredura e bloqueia a execução insegura através de limites explícitos, permissivos e regras de falha. - Defesa em camadas: separação arquitetural entre funções de IA/TI que sugerem ou otimizam e funções de CLP/OT que verificam, executam e impõem limites de segurança. - Pronto para Simulação (Simulation-Ready): a capacidade de rastrear a causalidade de E/S, observar comportamento anormal, injetar casos de falha, diagnosticar a resposta de controle e revisar a lógica em um ambiente virtual antes de tocar no hardware físico.

“Pronto para Simulação” não é abreviação para “sabe escrever sintaxe ladder”. Significa que o engenheiro pode provar o comportamento sob estresse. Sintaxe é barata; a capacidade de implantação não é.

A arquitetura de defesa em camadas correta dá influência à IA sem dar a ela autoridade irrestrita.

A separação deve ser explícita:

### Camada 1: Agente de IA para percepção ou otimização

Esta camada pode:

• estimar demanda,
• sugerir setpoints,
• recomendar roteamento,
• classificar condições operacionais,
• gerar rascunhos de lógica ou orientação ao operador.

Esta camada deve escrever apenas em tags de memória intermediárias, estruturas de mensagens ou variáveis de solicitação supervisória. Não deve escrever diretamente em saídas físicas ou memória de segurança.

### Camada 2: Veto determinístico no CLP

Esta camada avalia a solicitação da IA em relação a regras de engenharia fixas, tais como:

• valores máximos/mínimos permitidos,
• estados válidos da máquina,
• intertravamentos,
• permissivos,
• requisitos de etapa de sequência,
• condições de alarme e disparo,
• limites de taxa de variação.

É aqui que o comando se torna aceitável, modificado ou rejeitado.

### Camada 3: Caminho de execução de segurança cabeado ou certificado

Esta camada inclui, conforme aplicável:

• cadeias de parada de emergência (E-stop),
• relés de segurança,
• tarefas de CLP de segurança,
• contatores,
• circuitos STO,
• intertravamentos de proteção,
• funções de desligamento independentes.

Esta camada deve permanecer fora do mapa de memória da IA e fora de qualquer otimismo supervisório de software. A segurança cabeada existe porque o software ocasionalmente desenvolve opiniões.

Você programa o veto forçando cada comando solicitado pela IA através de uma lógica de verificação explícita antes que ele possa influenciar a variável de controle final.

O princípio de design chave é simples: solicitações de IA são propostas, não saídas.

Implementando o limitador de setpoint

Um limitador de limites (bounds clamp) impede que valores impossíveis ou inseguros alcancem o comando do atuador.

Use uma estrutura como esta:

IF AI_Requested_Speed > Max_Allowable_Speed THEN Actual_Drive_Speed := Max_Allowable_Speed; Set Alarm_AI_Hallucination_Over_Speed; ELSIF AI_Requested_Speed < Min_Allowable_Speed THEN Actual_Drive_Speed := Min_Allowable_Speed; Set Alarm_AI_Hallucination_Under_Speed; ELSE Actual_Drive_Speed := AI_Requested_Speed; END_IF;

Esse é o padrão mínimo, não a arquitetura finalizada.

Uma implementação voltada para produção geralmente adiciona:

- verificação de modo: aceitar solicitações de IA apenas no modo Automático - permissivo de estado: aceitar solicitações apenas quando a máquina estiver em um estado de sequência válido - limitador ROC: limitar a mudança por varredura ou por segundo - bit de qualidade: rejeitar dados upstream obsoletos, inválidos ou não confiáveis - tratamento de timeout: reverter para um valor de fallback se o fluxo de solicitação cair - travamento de alarme e visibilidade do operador: tornar a rejeição visível e revisável

Um caminho de controle mais completo geralmente se parece com isto:

1. Receber `AI_Requested_Speed`
2. Validar a qualidade e o frescor da fonte
3. Confirmar `System_Auto = TRUE`
4. Confirmar que todos os permissivos são verdadeiros
5. Limitar aos min/max de engenharia
6. Aplicar limite ROC
7. Escrever em `Actual_Drive_Speed_Command`
8. Disparar ou inibir se a cadeia de segurança estiver aberta

O que a lógica ladder deve impor antes de passar um comando de IA?

O CLP deve impor as mesmas coisas que um engenheiro de comissionamento cauteloso perguntaria antes de energizar o equipamento:

• A máquina está no modo correto?
• A sequência está na etapa correta?
• Todos os permissivos estão satisfeitos?
• Os feedbacks estão saudáveis?
• O valor solicitado está dentro dos limites físicos?
• A mudança solicitada é plausível para este processo?
• Existe alguma condição de disparo ou segurança ativa?

Essa última pergunta tende a importar mais do que o diagrama de arquitetura.

A cadeia mestre de E-stop

A cadeia mestre de E-stop deve ficar fora da fronteira de autoridade da IA porque o comportamento de parada de emergência não pode depender da qualidade da inferência, temporização de rede ou estado do software supervisório.

Na prática:

• O caminho de E-stop deve ser cabeado ou tratado em uma função de segurança certificada, conforme exigido pela aplicação.
• O sistema de IA não deve escrever nem suprimir o estado de E-stop.
• A tarefa de controle padrão pode observar o estado de E-stop, mas não deve ser a única guardiã dele.
• Qualquer comando solicitado pela IA deve colapsar inofensivamente quando a cadeia de E-stop abrir.

Uma regra útil é esta: se uma falha de rede, erro de modelo ou falha de parser puder manter o movimento habilitado, o design não está terminado.

Você o testa injetando comandos anormais e provando que a resposta do CLP permanece limitada, observável e correta sob essas condições.

É aqui que muitas equipes param cedo demais. Uma execução nominal limpa não prova quase nada.

No mínimo, teste estes casos:

• IA solicita acima do valor máximo permitido
• IA solicita abaixo do valor mínimo permitido
• mudanças de passo abruptas além da taxa de rampa segura
• comandos emitidos no estado de máquina errado
• comandos emitidos enquanto um permissivo é falso
• valores upstream obsoletos ou congelados
• sinais de solicitação oscilantes ou ruidosos
• ativação de E-stop ou disparo durante uma solicitação de IA ativa

Para cada caso, verifique:

• comando final do atuador,
• comportamento do alarme,
• comportamento da sequência,
• visibilidade do operador,
• comportamento de recuperação após a falha ser limpa.

Um veto que limita corretamente, mas deixa a sequência presa em um estado incoerente, é apenas metade de uma solução.

O OLLA Lab é útil aqui como um ambiente de validação limitado onde engenheiros podem injetar comandos ruins, observar a resposta do equipamento e revisar a lógica ladder antes que qualquer hardware real esteja envolvido.

Esse posicionamento é importante. O OLLA Lab não é um certificador de segurança e não é um substituto para a validação formal na plataforma alvo. É um ambiente prático para ensaiar lógica de comissionamento de alto risco de forma contida.

Dentro do OLLA Lab, os engenheiros podem:

• construir lógica ladder em um editor baseado na web,
• executar simulação sem hardware físico,
• monitorar tags, E/S, valores analógicos e variáveis relacionadas a PID,
• usar modelos de equipamento baseados em cenários,
• comparar o estado da ladder com o comportamento simulado da máquina,
• revisar a lógica após observar um caso de falha.

Para o caso de uso deste artigo, o fluxo de trabalho relevante é direto:

1. Criar uma tag intermediária como `AI_Requested_Speed`
2. Rotear essa tag através da lógica de limitador e permissivo
3. Observar o `Actual_Drive_Speed_Command` resultante
4. Injetar valores anormais ou padrões instáveis
5. Confirmar que o modelo simulado de motor, bomba ou válvula nunca excede os limites seguros
6. Revisar alarmes e revisar a lógica

É aqui que o OLLA Lab se torna operacionalmente útil. Você não pode testar responsavelmente um comando de válvula 200% aberta alucinado em um skid de processo real apenas para ver o que acontece. Curiosidade é valiosa; hardware empenado é caro.

Como é o "Pronto para Simulação" na prática

Um engenheiro está Pronto para Simulação quando pode fazer tudo o que segue em um ambiente virtual:

• rastrear causa e efeito da entrada para a saída,
• observar se um permissivo ou intertravamento bloqueou a execução,
• identificar o degrau (rung) ou condição exata que produziu a resposta,
• comparar o estado da lógica de controle com o estado do equipamento simulado,
• injetar uma falha e explicar o comportamento resultante,
• revisar a lógica e testar novamente até que a resposta seja limitada e repetível.

Esse é o limiar que importa para a preparação do comissionamento. Não "sabe colocar uma instrução de temporizador", mas "sabe provar por que a máquina se moveu ou não".

O artefato correto é um corpo compacto de evidências de engenharia, não uma galeria de capturas de tela.

Use esta estrutura:

Declare o que o comportamento aceitável significa em termos observáveis: faixa permitida, estados válidos, resposta de alarme esperada, comportamento de disparo e comportamento de recuperação.

Documente a entrada anormal exata: solicitação de sobrevelocidade, comando de estado inválido, tag obsoleta, sinal ruidoso ou E-stop durante o movimento.

Registre o que mudou na lógica: limitador adicionado, permissivo apertado, timeout introduzido, alarme travado, limite ROC ajustado.

1. Descrição do Sistema Defina a máquina ou célula de processo, a variável controlada, os modos operacionais e a fronteira de segurança relevante.
2. Definição operacional de "correto"
3. Lógica ladder e estado do equipamento simulado Mostre a lógica de controle ao lado do atuador simulado ou resposta do processo para que a cadeia causal seja visível.
4. O caso de falha injetado
5. A revisão feita
6. Lições aprendidas Declare o que a falha expôs e qual regra de design agora decorre disso.

Isso produz evidências que outro engenheiro pode revisar, desafiar e reproduzir. Esse é o padrão que vale a pena buscar.

O erro mais comum é permitir que a IA ignore a camada de verificação.

Outros erros recorrentes incluem:

• escrever a saída da IA diretamente nas tags de comando do atuador,
• tratar o desempenho médio da IA como um argumento de segurança,
• esquecer a detecção de dados obsoletos,
• omitir permissivos baseados em estado,
• confiar em alarmes de IHM em vez de blocos de execução rígidos,
• depositar confiança excessiva na simulação sem validação final específica da plataforma,
• confundir ladder gerada com ladder validada.

Um degrau (rung) gerado não é um degrau comprovado. O controle industrial ainda é governado pelo que a máquina realmente faz.

O padrão correto não é "a IA controla a planta". O padrão correto é "a IA pode sugerir, mas o CLP decide, e a camada de segurança ainda pode dizer não".

Um veto determinístico é o mecanismo de engenharia que torna essa fronteira real. Ele converte solicitações ilimitadas em comportamento de controle limitado através de limitadores, permissivos, intertravamentos e funções de segurança independentes. É assim que você evita que um software probabilístico se torne um incidente físico.

O OLLA Lab se encaixa neste fluxo de trabalho como um ambiente de ensaio e validação. Ele permite que os engenheiros pratiquem os casos desconfortáveis — setpoints ruins, estados inválidos, sinais ruidosos, permissivos falhos, paradas de emergência — sem usar o equipamento real como bancada de testes. Esse é um caminho mais credível para o julgamento de comissionamento do que memorizar sintaxe e esperar que a primeira falha real seja gentil.

Equipe de Engenharia da Ampergon Vallis Lab.

Validado contra os princípios de segurança funcional IEC 61508 e práticas de automação industrial.

- IEC 61131-3: Controladores programáveis — Parte 3: Linguagens de programação - Visão geral da IEC 61508 (segurança funcional) - NIST AI Risk Management Framework (AI RMF 1.0) - Digital Twin in Manufacturing: A Categorical Literature Review and Classification (IFAC, DOI) - Digital Twin in Industry: State-of-the-Art (IEEE, DOI)