Como separar a percepção de IA da segurança do CLP: A arquitetura "Medulla Oblongata"

A arquitetura "Medulla Oblongata" separa a percepção de IA não determinística do controle determinístico de CLP. Neste modelo, a IA pode propor setpoints ou classificações, mas um CLP permanece como a camada de validação e execução em tempo real rígido que impõe limites, permissivas, watchdogs e comportamento de estado seguro antes que qualquer comando chegue ao equipamento.

A IA não é um controlador de segurança, e tratá-la como tal é um erro arquitetônico antes mesmo de se tornar um erro de comissionamento. A distinção útil é simples: a IA é boa em percepção, estimativa e otimização; os CLPs são bons em execução determinística, intertravamentos e controle limitado.

Essa distinção é importante porque os sistemas de controle industrial não falham no abstrato. Eles falham como batimentos cardíacos perdidos, valores obsoletos, condições de corrida e saídas que se movem quando não deveriam. A máquina raramente se impressiona com um modelo inteligente.

Um teste de bancada interno recente da Ampergon Vallis apoia o valor prático dessa separação. Durante um exercício de simulação de 100 horas no OLLA Lab, atualizações de setpoint externas assíncronas injetadas em um cenário de controle de malha fechada produziram um aumento de 14% em eventos de falha de integral windup em relação a um caminho de validação de CLP com limites e taxas restritas, enquanto o caminho governado pelo CLP manteve a variância de resposta em um envelope de execução determinístico de 3 ms para a sequência de degraus de validação. [Metodologia: teste de simulação de 100 horas; tarefa = transferência de setpoint externo para um cenário de controle limitado; comparador de linha de base = injeção direta de setpoint assíncrono sem validação de limite e watchdog; janela de tempo = execução contínua única de 100 horas.] Esta métrica apoia o valor da validação defensiva de CLP em simulação. Ela não apoia nenhuma alegação ampla sobre todos os sistemas de IA, todas as plantas ou certificação formal de segurança.

A execução determinística é necessária porque as decisões de segurança e controle primário devem ocorrer dentro de limites de tempo conhecidos. Motores de inferência de IA, sejam locais ou remotos, não garantem essa propriedade.

Um CLP executa seu programa em um ciclo de varredura (scan cycle) limitado. As entradas são lidas, a lógica é resolvida, as saídas são escritas e o ciclo se repete em um intervalo definido. Esse intervalo pode variar ligeiramente de acordo com a plataforma e a carga do programa, mas é projetado para permanecer previsível e observável. A previsibilidade é o ponto principal.

Os sistemas de IA operam de forma diferente. Seu tempo de resposta pode variar com a carga do processador, pressão de memória, comportamento do escalonador, tamanho do modelo, thermal throttling, atrasos de middleware ou latência de rede. Mesmo quando a inferência média é rápida, o tempo no pior caso é o que importa quando o equipamento pode se mover, colidir, transbordar, superaquecer ou falhar ao desarmar.

A matemática do ciclo de varredura versus inferência assíncrona

A distinção de engenharia não é filosófica. É temporal.

• Caminho de controle de CLP
• Executa em um ciclo de varredura repetido
• Suporta avaliação de lógica limitada
• É projetado para manuseio de E/S determinístico
• Pode ser auditado quanto ao comportamento de tempo e falha

• Caminho de computação de IA
• Executa assincronamente
• Pode retornar resultados em intervalos irregulares
• Pode travar, sofrer timeout, jitter ou produzir saídas obsoletas
• Frequentemente depende de pilhas de software não projetadas como lógica de segurança primária

Em termos práticos, pode-se confiar que um CLP avaliará uma permissiva a cada varredura. Um serviço de IA pode ser útil, mas não confiável da mesma maneira. Útil e confiável não são sinônimos. As plantas aprendem essa distinção de forma dispendiosa quando a esquecem.

O que as normas dizem sobre controle determinístico

A IEC 61508 estabelece a estrutura de segurança funcional para sistemas relacionados à segurança elétricos, eletrônicos e eletrônicos programáveis. Uma implicação central para esta discussão é direta: o comportamento relacionado à segurança requer características de execução demonstráveis, limitadas e validadas.

Isso não significa que todo programa de CLP seja automaticamente seguro. Significa que as funções de segurança exigem projeto determinístico, verificação e disciplina de ciclo de vida que os sistemas de IA assíncronos não fornecem inerentemente. A exida e orientações de segurança funcional relacionadas apresentam o mesmo ponto prático em termos industriais: se uma função é crítica para a segurança, a incerteza de tempo e o comportamento não verificável não são inconvenientes menores.

Uma correção concisa é útil aqui: A IA pode auxiliar um sistema relacionado à segurança, mas não deve ser tratada como a camada de segurança determinística primária. Você não pode conectar uma cortina de luz a um LLM e chamar isso de arquitetura.

A arquitetura "Medulla Oblongata" é um modelo de controle em camadas no qual a IA propõe e o CLP dispõe. A IA realiza percepção ou otimização de alto nível; o CLP permanece como a autoridade de tempo real rígido que valida, limita, sequencia ou rejeita essas solicitações antes que o hardware aja.

A analogia biológica é memorável porque é estruturalmente precisa o suficiente para ser útil. O córtex interpreta e planeja. A medula lida com funções de sobrevivência autonômicas. Em termos de automação, a IA pode estimar a qualidade do produto, detectar objetos ou sugerir um ajuste de taxa de alimentação; o CLP ainda detém os intertravamentos, cadeias de parada, permissivas e atuação limitada.

A hierarquia de controle

• Interpreta imagens, tendências ou contexto de processo multivariável
• Gera uma classificação, consultoria ou setpoint solicitado
• Opera assincronamente e pode estar errada, atrasada ou obsoleta

• Verifica a solicitação contra limites rígidos
• Verifica o estado da máquina, permissivas e intertravamentos
• Confirma a atualização através de lógica de heartbeat ou watchdog
• Aplica limites de taxa de variação, clamps e comportamento de fallback

• Recebe apenas comandos aprovados pelo CLP
• Inclui drives, válvulas, contatores, atuadores e alarmes
• Move-se para um estado seguro ou limitado se a validação falhar

1. Camada de Percepção (IA)
2. Camada de Validação (CLP)
3. Camada de Execução (Hardware)

Esta não é uma posição anti-IA. É uma posição pró-limites. Uma boa arquitetura é, em grande parte, uma recusa disciplinada.

O que o CLP deve sempre reter

O CLP deve reter autoridade absoluta sobre funções que exigem resposta determinística e comportamento de falha limitado.

Isso normalmente inclui:

• Processamento de parada de emergência
• Avaliação de intertravamento de segurança
• Permissivas de movimento
• Lógica de prevenção de colisão
• Limites rígidos de curso ou velocidade
• Fallback para estado seguro em caso de perda de comunicação
• Gating de sequência para transições perigosas
• Arbitragem de comando final para atuadores

Se uma IA solicitar um aumento de velocidade, o CLP pode permitir, reduzir, atrasar ou rejeitar. A resposta final pertence à camada determinística.

Você programa limites de segurança de tempo real rígido tratando as saídas da IA como entradas externas não confiáveis. Isso significa que cada valor originado pela IA deve passar por uma lógica defensiva explícita antes que possa influenciar uma máquina ou processo.

É aqui que a lógica ladder deixa de ser prática de sintaxe e se torna julgamento de comissionamento. Um degrau (rung) que apenas "funciona" não é suficiente. O degrau também deve falhar de maneira controlada.

Degraus defensivos essenciais para o handshake IA-CLP

#### 1. Watchdog timer para supervisão de heartbeat

Um watchdog timer verifica se a IA ou o sistema de computação a montante ainda está se comunicando dentro de um intervalo aceitável.

- Se o temporizador expirar, o CLP:

• A IA envia um bit de heartbeat ou um valor incremental
• O CLP reseta um temporizador TON ou equivalente quando o heartbeat muda
• invalida a solicitação da IA,
• força um padrão seguro,
• levanta uma falha ou alarme,
• e impede a execução adicional até que as condições de recuperação sejam atendidas

Um serviço a montante inativo não deve deixar um caminho de saída ativo para trás. Isso não é inteligência; isso é resíduo.

#### 2. Bloco de limite para clamping rígido

Uma instrução de limite restringe os valores solicitados a uma banda de operação fisicamente segura.

Exemplos de uso:

• Limitar a velocidade solicitada do motor entre a velocidade mínima de resfriamento e a RPM máxima segura
• Limitar a demanda de uma válvula a uma faixa que evite choque hidráulico
• Limitar um setpoint de temperatura aos limites de projeto do equipamento

Exemplo de estrutura de lógica ladder:

- Instrução: LIM (Teste de Limite) - Limite Inferior: 15.0 Hz - Teste: `AI_Requested_Speed` - Limite Superior: 45.0 Hz - Saída: `Safe_Speed_Permissive`

O ponto não é a elegância. O ponto é que nenhum otimismo a montante pode comandar excesso de velocidade.

#### 3. Limitação de taxa de variação

Um limitador de taxa de variação evita mudanças bruscas de comando que são tecnicamente válidas em magnitude, mas inseguras na transição.

Exemplos:

• Impedir que uma válvula se mova de 10% para 100% em uma única atualização
• Restringir aumentos de velocidade de VFD a uma rampa definida
• Limitar o movimento do setpoint por varredura ou por segundo

Isso é importante porque muitas falhas ocorrem na transição, não no ponto final. O número final pode ser legal, enquanto o caminho até ele é imprudente.

#### 4. Detecção de obsolescência e validade de sequência

Um valor pode ser numericamente plausível e ainda operacionalmente inválido.

O CLP deve verificar:

• frescor do timestamp ou contagem de sequência
• compatibilidade do modo da máquina
• fase atual da operação
• estado da permissiva antes de aplicar a solicitação
• se a solicitação pertence à receita, passo de lote ou estado de sequência ativo

Um setpoint obsoleto durante a fase de sequência errada é apenas uma forma educada de dados ruins.

O que "correto" significa nesta arquitetura

A correção deve ser definida operacionalmente, não cosmeticamente. Neste contexto, uma integração IA-CLP correta significa:

• o CLP aceita apenas solicitações frescas e limitadas,
• a máquina se move apenas quando as permissivas são verdadeiras,
• transições inseguras são bloqueadas,
• a perda de comunicação produz um estado de fallback definido,
• e cada caminho de rejeição é observável em tags, alarmes ou lógica de eventos.

Essa definição é mais útil do que "o degrau compilou". A compilação é uma barra baixa. Danos ao equipamento a superam regularmente.

Você valida o handshake IA-CLP simulando comportamentos anormais deliberadamente, provando então que a lógica do CLP os rejeita ou contém. Validação não é mostrar que o caminho feliz funciona. Validação é mostrar que entradas ruins falham de forma segura e observável.

É aqui que Simulation-Ready precisa de uma definição rigorosa. Um engenheiro Simulation-Ready é aquele que pode provar, observar, diagnosticar e endurecer a lógica de controle contra o comportamento real do processo antes que ele chegue a um processo real. Esse é um padrão mais elevado do que conhecer a sintaxe ladder. É a diferença entre desenhar a lógica e comissioná-la.

O que deve ser testado antes da exposição ao hardware

No mínimo, os engenheiros devem testar:

• perda de heartbeat do serviço de IA
• atualizações atrasadas e valores obsoletos
• setpoints fora da faixa
• valores implausíveis, mas dentro da faixa
• solicitações de oscilação rápida
• incompatibilidade de modo entre a solicitação da IA e o estado da máquina
• temporização ruim da sequência de inicialização
• comportamento de fallback após a restauração da comunicação

Se esses casos não foram exercitados, a arquitetura não está validada. Ela é meramente esperançosa.

O OLLA Lab é útil aqui como um ambiente de validação limitado para ensaiar o lado do CLP do risco de integração de IA. Ele não é um certificador de segurança de IA e não substitui a aceitação formal do local, revisão de perigos ou avaliação de segurança funcional. É um lugar para praticar as tarefas exatas de endurecimento de controle que são muito arriscadas ou muito caras para improvisar em equipamentos reais.

A vantagem prática é simples: os engenheiros podem injetar comportamentos ruins de forma segura e repetida.

O que o OLLA Lab permite que os engenheiros ensaiem

Usando o editor de lógica ladder baseado na web, o modo de simulação e o painel de variáveis, os engenheiros podem:

• construir lógica ladder que supervisiona um valor solicitado externo,
• alternar entradas e tags internas em tempo real,
• observar saídas e permissivas intermediárias,
• testar temporizadores, contadores, comparadores, matemática e comportamento relacionado a PID,
• comparar o estado ladder com a resposta do equipamento simulado,
• e revisar a lógica após observar um caminho de falha.

Esse fluxo de trabalho é importante porque as falhas de integração de IA geralmente aparecem como problemas de temporização e estado, não apenas números errados. O OLLA Lab dá a esses problemas um lugar para se tornarem visíveis.

Um fluxo de trabalho de validação prático no OLLA Lab

Uma sequência de ensaio credível parece com isto:

• Construir uma sequência de degraus que recebe um valor externo de velocidade, fluxo ou posição solicitado
• Adicionar permissivas, verificações de modo e uma condição de execução final

• Inserir um watchdog timer
• Adicionar um clamp usando lógica de limite
• Adicionar um limitador de taxa ou rampa passo a passo
• Definir comportamento de fallback em caso de timeout ou dados inválidos

• Usar o painel de variáveis para forçar valores fora da faixa
• Pausar ou parar o sinal de heartbeat
• Introduzir mudanças bruscas de comando
• Alternar o estado do processo no meio do comando

• Confirmar que as saídas permanecem limitadas
• Verificar se a lógica de timeout desarma corretamente
• Verificar se alarmes ou bits de falha se tornam visíveis
• Comparar o comportamento da máquina simulada com a filosofia de controle esperada

• Ajustar valores de temporizador, limites e condições de sequência
• Re-testar as mesmas falhas até que o caminho de rejeição seja determinístico e legível

1. Criar o caminho de controle
2. Adicionar lógica defensiva
3. Injetar casos anormais
4. Observar causa e efeito
5. Revisar e reexecutar

É aqui que o OLLA Lab se torna operacionalmente útil. Ele permite que os engenheiros ensaiem a lógica de veto, não apenas a admirem.

Você deve produzir um corpo compacto de evidências de engenharia que demonstre o raciocínio de controle sob falha, não uma galeria de capturas de tela do editor. Capturas de tela provam que uma tela existiu. Elas não provam que a lógica se manteve sob estresse.

Use esta estrutura:

Declare os critérios de aceitação exatos: faixa de operação permitida, intervalo de timeout, condições permissivas, estado de fallback e comportamento de alarme esperado.

Documente a condição anormal introduzida: heartbeat obsoleto, solicitação de excesso de velocidade, incompatibilidade de modo, comando oscilante ou temporização de sequência inválida.

Explique o que mudou na lógica: clamp adicionado, intervalo de watchdog alterado, intertravamento inserido, limite de taxa de variação adicionado ou gating de sequência revisado.

1. Descrição do Sistema Descreva a máquina ou célula de processo, o objetivo de controle, a entrada fornecida pela IA e o papel de segurança ou validação do CLP.
2. Definição operacional de "correto"
3. Lógica ladder e estado do equipamento simulado Mostre os degraus, tags e o estado da máquina ou processo simulado que esses degraus governam.
4. O caso de falha injetado
5. A revisão feita
6. Lições aprendidas Declare o que a falha revelou sobre a filosofia de controle, suposições da máquina ou caminho de validade de dados.

Essa estrutura de evidências é muito mais persuasiva do que um clipe de demonstração polido. O risco de comissionamento responde a provas, não a estética.

A IA pertence a montante do controle determinístico, não em seu lugar. Seu papel útil é gerar valores consultivos ou candidatos a partir de dados complexos que a lógica convencional lida mal.

Exemplos incluem:

• classificação baseada em visão
• detecção de anomalias
• estimativa de qualidade
• pontuação de manutenção preditiva
• recomendações de otimização multivariável
• sugestões de setpoint adaptativo

O CLP então decide se essas saídas são admissíveis no contexto atual da máquina.

Uma regra arquitetônica limpa

Uma regra prática é esta: A IA pode recomendar; o CLP deve autorizar.

Essa regra preserva os pontos fortes de ambas as camadas:

• A IA lida com ambiguidade, reconhecimento de padrões e otimização
• A lógica do CLP lida com temporização, permissivas, limites e execução determinística

O resultado não é glamoroso, o que é frequentemente um bom sinal em controles. Uma boa arquitetura de planta geralmente parece um pouco entediante até o momento em que evita um erro caro.

O erro mais comum é permitir que as saídas da IA ignorem a lógica de validação explícita. Uma vez que isso acontece, a arquitetura já perdeu sua disciplina de limites.

Outros erros recorrentes incluem:

• tratar um timestamp de rede como equivalente ao frescor determinístico
• assumir que valores dentro da faixa são automaticamente seguros
• esquecer a validação do estado da sequência
• omitir o comportamento de fallback em caso de perda de heartbeat
• permitir que saídas consultivas se tornem comandos diretos ao longo do tempo
• testar apenas o comportamento nominal e não as transições anormais
• confundir o sucesso do simulador com a prontidão do local

Esse último merece ênfase. A simulação é um ambiente de validação, não uma declaração de competência de campo. É onde os engenheiros aprendem a observar, diagnosticar e endurecer a lógica antes da exposição real. Útil, necessário e ainda assim não é o mesmo que estar ao lado de uma linha em funcionamento às 2:00 da manhã com a manutenção esperando.

A maneira segura de integrar a IA na automação industrial é separar a percepção da autoridade. A IA pode classificar, estimar e recomendar. O CLP deve permanecer como o núcleo de tempo real rígido que valida, limita, sequencia e veta.

Essa é a arquitetura "Medulla Oblongata" em uma linha: a IA pensa, o CLP mantém o organismo vivo.

Para os engenheiros, a tarefa prática não é celebrar as saídas da IA, mas endurecer o caminho de controle ao redor delas. Watchdogs, limites, permissivas, verificações de taxa de variação, detecção de dados obsoletos e fallbacks de estado seguro não são detalhes opcionais. Eles são a arquitetura.

E se isso soa menos futurista do que os decks de marketing, ótimo. As máquinas geralmente preferem adultos.

- IEC 61131-3: Controladores programáveis — Parte 3 - Família de normas de segurança funcional IEC 61508 - Recursos de validação e segurança funcional da exida - Recomendação de sinalização de status NAMUR NE 107 - Gêmeo digital na indústria: estado da arte (DOI)