Como converter pesos de redes neurais para Structured Text de CLP para detecção de anomalias

Converter pesos de redes neurais para Structured Text de CLP significa exportar os pesos e vieses de um modelo treinado, reescrevê-los como matrizes IEC 61131-3 e executar a matemática feedforward de forma determinística dentro do ciclo de varredura (scan) do CLP. O objetivo de engenharia não é "IA em controles" como um slogan, mas sim uma inferência delimitada e testável, sem dependência de redes de borda (edge-network).

Redes neurais não se tornam industrialmente úteis apenas porque classificam dados bem em Python. Elas se tornam úteis quando seu caminho de execução é previsível o suficiente para um sistema de controle que depende do tempo de varredura, limites de watchdog e comportamento em caso de falha.

Para detecção de anomalias de alta velocidade, enviar dados de processo para um PC de borda externo pode introduzir latência, jitter e outro ponto de falha entre o sinal e a ação. Essa arquitetura pode ser aceitável para análises consultivas. É menos adequada quando a saída do modelo está vinculada a uma permissão, desarme ou intertravamento. A tecnologia operacional (OT) tem pouca paciência para arquiteturas elegantes que falham de forma deselegante.

Uma alternativa delimitada é exportar um modelo treinado leve — tipicamente um perceptron multicamadas raso — para Structured Text (IEC 61131-3) e executar a inferência diretamente no controlador.

Métrica Ampergon Vallis: Em uma simulação interna do OLLA Lab, um MLP de 3 camadas usando uma matriz de camada oculta de ponto flutuante 16x16 adicionou 1,2 ms à execução do scan simulado durante testes repetidos de inferência. *Metodologia: n=25 execuções de simulação da mesma tarefa feedforward, comparador de linha de base = estado lógico idêntico sem execução de matriz, janela de tempo = uma sessão de validação em março de 2026. Isso sustenta a alegação de que pequenos blocos de inferência neural podem ser testados quanto à viabilidade determinística em um ambiente estilo CLP. Isso não prova a adequação para todo controlador, todo orçamento de scan* ou qualquer função de segurança.

Executar a inferência dentro do CLP remove o transporte de rede do caminho crítico de execução. Essa é a principal razão de engenharia.

Um PC de borda pode ser adequado para monitoramento não crítico, análises de historiador ou painéis de manutenção. É uma proposta diferente quando a saída do modelo deve participar de uma decisão de controle determinística. Se o link de rede cair, o caminho de inferência cai com ele. O problema não é que a computação de borda esteja errada; o problema é que a lógica de controle é menos tolerante do que a arquitetura de análise.

A distinção é simples:

• Inferência de borda é tipicamente assíncrona, dependente de rede e agendada fora do scan do CLP.
• Inferência residente no CLP é determinística apenas se o tempo de execução, o uso de memória e o comportamento de falha forem delimitados dentro da tarefa do controlador.

Para detecção de anomalias vinculada a uma permissão de motor, inibição de válvula ou retenção de sequência, a localidade determinística importa. Um resultado que chega atrasado é frequentemente funcionalmente equivalente a nenhum resultado.

Qual contexto de normas é importante aqui?

As normas de segurança funcional não endossam suposições casuais de tempo. A IEC 61508 preocupa-se com comportamento previsível, execução validada e resposta conhecida a falhas, não com se um modelo pareceu impressionante em um notebook.

Isso requer um limite cuidadoso:

• Incorporar uma rede neural em Structured Text não a torna uma função de segurança por padrão.
• Ela pode suportar lógica de monitoramento de processo determinística se sua execução for validada, delimitada e segregada adequadamente.
• Se a saída influenciar uma ação relacionada à segurança, o ônus da verificação aumenta drasticamente. "Funcionou na simulação" não é um caso de segurança.

Um equívoco popular é que colocar IA dentro do CLP a torna automaticamente mais industrial. Isso apenas a coloca mais próxima do ciclo de scan. A parte difícil ainda é a prova.

Apenas modelos feedforward pequenos são práticos na maioria dos contextos de CLP. Esse é o limite útil.

O candidato mais comum é um perceptron multicamadas (MLP) raso, treinado offline em MATLAB, Python ou ambiente similar, e então exportado como pesos e vieses estáticos. Isso funciona porque a inferência para um MLP fixo é apenas aritmética:

• multiplicação de matrizes
• adição de viés
• avaliação da função de ativação
• lógica de limiar ou classificação

Essa aritmética é tediosa, mas determinística.

Os modelos com maior probabilidade de se encaixar são:

• MLPs de camada oculta única ou rasos
• Vetores de entrada pequenos
• Contagem limitada de nós ocultos
• Funções de ativação simples, como ReLU ou aproximações lineares delimitadas

Os modelos com menor probabilidade de se encaixar perfeitamente são:

• redes recorrentes
• grandes modelos convolucionais
• arquiteturas transformer
• qualquer coisa que exija comportamento de memória dinâmica, bibliotecas não suportadas ou rendimento substancial de ponto flutuante

Esta não é uma declaração sobre a capacidade da IA em geral. É uma declaração sobre economia de controlador e disciplina de scan.

O processo de conversão é direto no conceito e implacável nos detalhes. A maioria das falhas não é matemática. São falhas de indexação, escala, tipo de dados ou tempo de tarefa.

### Passo 1: Treinar um modelo leve offline

Treine o modelo em MATLAB, Python ou outro ambiente de ML usando dados históricos de processo ou dados de eventos rotulados.

Bons candidatos para implementação em CLP geralmente possuem:

• entradas numéricas normalizadas
• contagem limitada de recursos
• envelopes operacionais estáveis
• rótulos de anomalia ou lógica de limiar claros
• um caminho de inferência que pode ser explicado e delimitado

Se o modelo precisa de uma GPU de desktop para rodar confortavelmente, ele geralmente não pertence a uma tarefa de controlador padrão.

### Passo 2: Exportar pesos e vieses

Extraia os parâmetros treinados do modelo:

• matriz de pesos de entrada para oculta
• vetor de viés da camada oculta
• matriz de pesos de oculta para saída
• vetor de viés da camada de saída

Formatos de exportação típicos incluem:

• CSV
• JSON
• Matrizes MATLAB
• Matrizes NumPy do Python escritas em texto

Nesta etapa, preserve:

• dimensões da matriz
• ordenação de linha/coluna
• precisão numérica
• constantes de normalização de entrada
• valores de limiar de saída

Um número surpreendente de problemas de implementação são, na verdade, apenas matrizes transpostas.

### Passo 3: Converter os parâmetros em matrizes compatíveis com IEC 61131-3

Reescreva os parâmetros do modelo como matrizes em Structured Text usando tipos de dados suportados pelo controlador, tipicamente `REAL` ou `LREAL`, dependendo da capacidade da plataforma e do orçamento de scan.

Mapeamento de forma de exemplo:

• `W1[HiddenNodes, InputNodes]`
• `B1[HiddenNodes]`
• `W2[OutputNodes, HiddenNodes]`
• `B2[OutputNodes]`

Defina também:

• matrizes de vetor de entrada
• matrizes de soma de nós intermediários
• matrizes de saída de ativação
• matrizes de saída de inferência final

A escolha do tipo de dados importa. `LREAL` pode melhorar a fidelidade numérica, mas também pode aumentar o custo de execução dependendo da arquitetura do controlador.

### Passo 4: Recriar a passagem feedforward em Structured Text

Implemente o modelo como aritmética explícita:

1. inicialize cada soma de nó com seu viés
2. acumule produtos de entrada ponderados
3. aplique a função de ativação
4. passe as saídas ativadas para a próxima camada
5. compare a saída final com um limiar ou regra de classificação

É aqui que o modelo se torna um bloco aritmético determinístico.

### Passo 5: Recriar o pré-processamento e a lógica de saída

Um modelo treinado em entradas normalizadas deve receber entradas normalizadas no CLP. Caso contrário, a inferência é matematicamente correta e operacionalmente errada.

Você deve implementar:

• escala
• correção de offset
• clamping (limitação), se necessário
• tratamento de sinal ausente
• limiar de saída
• comportamento de estado de falha se o bloco de inferência receber dados inválidos

Um modelo sem seu caminho de pré-processamento não é implementado. Ele é apenas copiado.

A multiplicação de matrizes em Structured Text é geralmente implementada com loops `FOR` aninhados e acumulação explícita em matrizes de soma de nós. O objetivo é correção, determinismo e visibilidade do tempo de scan.

Exemplo: soma ponderada da camada oculta

Linguagem: Structured Text

// Soma ponderada da camada oculta FOR i := 0 TO HiddenNodes - 1 DO NodeSum[i] := Bias1[i]; FOR j := 0 TO InputNodes - 1 DO NodeSum[i] := NodeSum[i] + (InputArray[j] * Weight1[i, j]); END_FOR; END_FOR;

Este código realiza o produto escalar entre o vetor de entrada e a linha de pesos de cada neurônio da camada oculta, e então adiciona o viés correspondente.

Verificações de implementação que importam:

• confirme se o seu CLP usa convenções de matriz baseadas em zero ou um
• mantenha as dimensões da matriz explícitas
• inicialize as somas antes da acumulação
• evite conversão de tipo oculta
• teste o tempo de execução no pior caso, não apenas o tempo de execução nominal

Um loop que funciona uma vez é uma demonstração. Um loop que funciona na taxa da tarefa sob entradas ruidosas é engenharia.

Como calcular a camada de saída?

A camada de saída é o mesmo padrão aplicado às ativações da camada oculta.

Linguagem: Structured Text

// Soma ponderada da camada de saída FOR i := 0 TO OutputNodes - 1 DO OutputSum[i] := Bias2[i]; FOR j := 0 TO HiddenNodes - 1 DO OutputSum[i] := OutputSum[i] + (HiddenOutput[j] * Weight2[i, j]); END_FOR; END_FOR;

Para uma pontuação de anomalia única, `OutputNodes` pode ser `1`, com a pontuação final comparada a um limiar.

ReLU é uma das funções de ativação mais fáceis de traduzir porque é linear por partes. Em Structured Text, ela se torna uma condicional simples.

Linguagem: Structured Text

// Ativação ReLU FOR i := 0 TO HiddenNodes - 1 DO IF NodeSum[i] < 0.0 THEN HiddenOutput[i] := 0.0; ELSE HiddenOutput[i] := NodeSum[i]; END_IF; END_FOR;

Isso preserva a regra básica da ReLU:

• se entrada < 0, saída = 0
• senão saída = entrada

Essa simplicidade é útil em CLPs porque evita funções não lineares mais caras.

Quais outras abordagens de ativação são práticas?

Opções práticas dependem da capacidade do controlador, mas abordagens comuns incluem:

- ReLU: mais simples para implementação direta - Ativação linear: útil para saídas estilo regressão - Aproximação por partes: às vezes usada quando uma função não linear suave é necessária, mas o suporte matemático nativo é limitado

Opções menos práticas em muitos CLPs incluem:

• cálculos exatos de sigmoide ou tanh usando exponenciais caras
• esquemas de ativação dinâmica que exigem bibliotecas não suportadas
• arquiteturas que dependem do comportamento do grafo em tempo de execução

No trabalho de controle, comportamento delimitado geralmente supera comportamento elegante, porém não testável.

A detecção de anomalias torna-se operacionalmente significativa apenas quando a saída está vinculada a uma ação de controle definida. "O modelo produziu 0,83" ainda não é um resultado de engenharia.

Uma implementação utilizável precisa de:

• uma pontuação de anomalia definida
• um limiar ou regra de classificação
• uma regra de debounce ou persistência se ruído for esperado
• uma resposta de controle clara

Por exemplo:

- definir `AnomalyDetected := TRUE` - derrubar `MotorRunPermissive := FALSE`

• se pontuação de anomalia > limiar por 500 ms
• travar um alarme
• exigir reinicialização do operador ou supervisão, dependendo da filosofia

Essa lógica deve ser documentada em termos de controle, não em termos de ML.

Definição operacional de detecção de anomalias

Neste artigo, detecção de anomalias significa:

> ler um conjunto delimitado de entradas de processo, executar um bloco de inferência feedforward determinístico dentro da tarefa do CLP, comparar a pontuação resultante com um limiar definido e alterar uma variável de estado de controle, como uma permissão, alarme ou retenção de sequência, quando a condição de limiar for atingida.

Essa definição é intencionalmente estreita. É observável, testável e adequada para validação.

Os principais riscos são estouro de scan, incompatibilidade numérica e falsa confiança.

1. Risco de tempo de scan e watchdog

A aritmética de matriz consome tempo de tarefa. Se o bloco de inferência for muito grande ou mal estruturado, ele pode disparar falhas de watchdog ou degradar a capacidade de resposta do controle.

Fatores de risco incluem:

• matrizes grandes
• execução frequente em tarefas rápidas
• uso intenso de ponto flutuante
• normalização e escala repetidas dentro do mesmo ciclo
• recomputação desnecessária

Mitigações incluem:

• reduzir o tamanho do modelo
• mover a inferência para uma tarefa periódica mais lenta, quando apropriado
• pré-computar constantes
• usar testes de execução delimitados
• validar o impacto do scan no pior caso antes da implementação

2. Incompatibilidade de tipo de dados e precisão

Um modelo treinado em `float64` e implementado em `REAL` pode se comportar de forma diferente nos limiares. Essa diferença pode ser pequena numericamente e grande operacionalmente.

Verifique:

• faixa numérica
• consistência de escala
• sensibilidade ao limiar
• comportamento de ponto flutuante específico do controlador

3. Erros de indexação e orientação de matriz

Uma matriz transposta, índice deslocado ou mapeamento de viés incorreto pode produzir saídas que parecem plausíveis enquanto estão completamente erradas.

É por isso que a validação determinística importa. Erros aritméticos são frequentemente educados o suficiente para compilar.

4. Comportamento de entrada inválida

Um sensor ausente, valor obsoleto, transmissor saturado ou escala analógica ruim podem corromper a inferência.

Defina:

• o que acontece com má qualidade
• se o bloco se inibe
• se a saída falha de forma segura, falha de forma neutra ou apenas emite alarme
• se o resultado é ignorado durante estados de manutenção ou inicialização

5. Uso indevido em contextos de segurança

Um bloco de inferência neural não deve ser descrito como classificado para segurança apenas porque está dentro de um CLP. Se ele influenciar uma função relacionada à segurança, as obrigações de projeto, verificação e ciclo de vida tornam-se substancialmente mais exigentes.

O OLLA Lab é útil aqui como um ambiente de validação delimitado para tarefas de comissionamento de alto risco. Não é um atalho para testes de controlador e não substitui a aceitação no local. É onde você ensaia os modos de falha antes que o hardware e o tempo de processo se tornem caros.

Neste caso de uso, o OLLA Lab pode apoiar os engenheiros fornecendo:

• um ambiente de lógica baseado em navegador para construir e revisar a lógica de controle
• modo de simulação para executar, parar e observar o comportamento sem hardware físico
• visibilidade de variáveis e E/S para rastrear valores intermediários
• testes realistas baseados em cenários contra comportamento de equipamento simulado
• fluxos de trabalho de validação estilo gêmeo digital, onde a lógica pode ser comparada com a resposta esperada da máquina

Para o fluxo de trabalho deste artigo, o valor prático é claro:

• escrever a lógica de inferência
• vincular entradas a variáveis de processo simuladas
• injetar distúrbios ou condições anormais
• observar mudanças de estado de saída
• verificar se a resposta de controle corresponde à filosofia pretendida

É isso que Simulation-Ready deve significar em termos operacionais: um engenheiro que pode provar, observar, diagnosticar e endurecer a lógica de controle contra o comportamento realista do processo antes que ele chegue a um processo real.

O que significa validação de gêmeo digital aqui?

Neste contexto delimitado, validação de gêmeo digital significa testar a lógica de controle contra um modelo de equipamento simulado realista para que o engenheiro possa comparar:

• estado de ladder ou Structured Text
• estado de E/S
• resposta do processo
• tratamento de condições anormais
• ação de controle resultante

Isso não significa que o modelo simulado é automaticamente uma réplica perfeita do comportamento do local. Significa que a lógica pode ser ensaiada contra a dinâmica da máquina ou do processo representativo antes da implementação em campo.

Um fluxo de trabalho prático é tratar a rede neural como um bloco dentro de uma narrativa de controle maior, em vez de um objeto de novidade.

Uma sequência de validação representativa seria:

1. Construir o bloco de inferência Implemente os pesos, vieses, normalização e lógica de limiar exportados em Structured Text ou um fluxo de trabalho de lógica de controle suportado equivalente.
2. Vincular as entradas aos sinais de processo simulados Mapeie as entradas do modelo para variáveis como vibração, corrente do motor, aumento de temperatura, flutuação de pressão ou instabilidade de fluxo.
3. Definir o estado normal esperado Confirme se a saída do modelo permanece abaixo do limiar durante a operação saudável.
4. Injetar uma condição anormal Introduza um distúrbio como vibração oscilatória, pico de sensor, desvio ou comportamento de carga instável.
5. Observar a saída da inferência e a resposta de controle Verifique se a pontuação de anomalia cruza o limiar apenas quando pretendido e se o estado de permissão, alarme ou sequência muda corretamente.
6. Medir a carga da lógica Revise se a aritmética adicionada cria custo de execução inaceitável ou comportamento instável.

Essa sequência importa porque a detecção de anomalias só é útil quando vinculada à consequência do processo. Uma pontuação sem um caminho de ação é apenas um número.

Uma galeria de capturas de tela é uma evidência fraca. Um registro de validação compacto é mais útil para revisores, instrutores e empregadores porque mostra raciocínio, não apenas familiaridade com a interface.

Use esta estrutura:

1. Descrição do sistema Descreva o equipamento, objetivo do processo, entradas relevantes e onde o bloco de detecção de anomalias se encaixa na filosofia de controle.
2. Definição operacional de comportamento correto Declare exatamente o que a lógica deve fazer sob condições normais e anormais, incluindo limiares, tempo e estados de saída esperados.
3. Lógica e estado do equipamento simulado Mostre a lógica implementada e o comportamento correspondente da máquina ou processo simulado durante o teste.
4. O caso de falha injetado Documente o distúrbio introduzido, como ruído de sensor, desvio, oscilação ou carga anormal.
5. A revisão feita Registre o que mudou após o primeiro teste — ajuste de limiar, lógica de debounce, correção de escala, posicionamento de tarefa ou otimização de matriz.
6. Lições aprendidas Resuma o que o teste revelou sobre capacidade de implementação, falsos positivos, carga de scan ou filosofia de controle.

Esse corpo de evidências está muito mais próximo do julgamento de comissionamento do que uma captura de tela polida.

A implementação deve ser controlada por verificação delimitada, não por entusiasmo.

Use uma lista de verificação pré-implementação:

• O tamanho do modelo é apropriado para o controlador e a taxa da tarefa
• A escala de entrada corresponde às condições de treinamento
• Pesos e vieses estão mapeados corretamente
• A lógica de ativação está implementada exatamente como pretendido
• O comportamento do limiar está documentado
• O tratamento de entrada ruim está definido
• O tempo de execução no pior caso está testado
• A resposta de controle à anomalia está verificada
• *O comportamento de fallback está definido se o bloco de inferência for inválido*
• Testes de comissionamento específicos do local estão planejados

Se o modelo não conseguir sobreviver a esta lista de verificação, ele não está pronto para o CLP. Ele ainda pode ser útil em outro lugar.

Essa abordagem resolve um problema específico de OT: como executar um pequeno modelo treinado de forma determinística dentro de um ambiente de controle estilo CLP sem depender de infraestrutura de inferência externa.

Ela pode ajudar com:

• pontuação de anomalia de baixa latência
• inferência local delimitada
• redução da dependência de rede em decisões de controle
• validação da aritmética do modelo contra o comportamento realista do processo

Ela não resolve:

• certificação de segurança por implicação
• governança de modelo por si só
• comissionamento específico da planta apenas por simulação
• adequação de arquiteturas neurais grandes ou complexas para hardware de CLP padrão

Vale a pena manter esse limite limpo.

Converter pesos de redes neurais para Structured Text de CLP é tecnicamente viável quando o modelo é pequeno, o caminho aritmético é explícito e a carga de execução é validada contra as restrições do controlador. O objetivo não é fazer com que os CLPs imitem ambientes Python. O objetivo é colocar uma função de inferência delimitada onde a resposta determinística mais importa.

A sequência de engenharia é clara:

• treinar offline
• exportar pesos e vieses
• reescrevê-los como matrizes IEC 61131-3
• implementar a matemática feedforward e a lógica de ativação
• validar o impacto do scan e o comportamento de falha
• testar a consequência de controle contra condições de processo simuladas realistas

É aqui que o OLLA Lab se torna operacionalmente útil. Ele fornece um lugar para ensaiar lógica pesada em matrizes, observar o comportamento de E/S e variáveis, injetar condições anormais e endurecer o projeto antes do comissionamento real. Esse é um uso credível da simulação: não substituir a prova de campo, mas tornar a prova de campo menos imprudente.

- IEC 61131-3: Controladores programáveis — Parte 3: Linguagens de programação - Visão geral da segurança funcional IEC 61508 - NIST AI Risk Management Framework (AI RMF 1.0) - Revisão de gêmeo digital (IFAC-PapersOnLine) - IA Industrial na Indústria 4.0 (Manufacturing Letters)