Come convertire i pesi di una rete neurale in Structured Text PLC per il rilevamento di anomalie

Convertire i pesi di una rete neurale in Structured Text per PLC significa esportare i pesi e i bias di un modello addestrato, riscriverli come array IEC 61131-3 ed eseguire la matematica feedforward in modo deterministico all'interno della scansione del PLC. L'obiettivo ingegneristico non è l' "AI nei controlli" come slogan, ma un'inferenza limitata e testabile senza dipendenza da reti edge.

Le reti neurali non diventano industrialmente utili semplicemente perché classificano bene i dati in Python. Diventano utili quando il loro percorso di esecuzione è sufficientemente prevedibile per un sistema di controllo che vive e muore in base al tempo di scansione, ai limiti del watchdog e al comportamento in caso di guasto.

Per il rilevamento di anomalie ad alta velocità, l'invio di dati di processo a un PC edge esterno può introdurre latenza, jitter e un ulteriore punto di guasto tra segnale e azione. Tale architettura può essere accettabile per l'analisi consultiva, ma è meno adatta quando l'output del modello è legato a un consenso, un blocco o un interblocco. L'OT ha poca pazienza per architetture eleganti che falliscono in modo inelegante.

Un'alternativa limitata consiste nell'esportare un modello addestrato leggero — tipicamente un percettrone multistrato (MLP) superficiale — in Structured Text IEC 61131-3 ed eseguire l'inferenza direttamente nel controllore.

Metrica Ampergon Vallis: In una simulazione interna di OLLA Lab, un MLP a 3 strati che utilizza una matrice di strati nascosti in virgola mobile 16x16 ha aggiunto 1,2 ms all'esecuzione della scansione simulata durante test di inferenza ripetuti. Metodologia: n=25 esecuzioni di simulazione dello stesso task feedforward, comparatore di base = logica identica senza esecuzione di matrice, finestra temporale = una sessione di validazione di marzo 2026. Ciò supporta l'affermazione che piccoli blocchi di inferenza neurale possono essere testati per la fattibilità deterministica in un ambiente di tipo PLC. Ciò non dimostra l'idoneità per ogni controllore, ogni budget di scansione o qualsiasi funzione di sicurezza.

Eseguire l'inferenza all'interno del PLC rimuove il trasporto di rete dal percorso di esecuzione critico. Questa è la ragione ingegneristica centrale.

Un PC edge può essere adeguato per il monitoraggio non critico, l'analisi lato historian o i dashboard di manutenzione. È una proposta diversa quando l'output del modello deve partecipare a una decisione di controllo deterministica. Se il collegamento di rete cade, il percorso di inferenza cade con esso. Il problema non è che l'edge computing sia sbagliato; il problema è che la logica di controllo è meno tollerante dell'architettura di analisi.

La distinzione è semplice:

• L'inferenza edge è tipicamente asincrona, dipendente dalla rete e pianificata al di fuori della scansione del PLC.
• L'inferenza residente nel PLC è deterministica solo se il tempo di esecuzione, l'uso della memoria e il comportamento in caso di guasto sono limitati all'interno del task del controllore.

Per il rilevamento di anomalie legato a un consenso motore, un inibitore di valvola o un mantenimento di sequenza, la località deterministica è importante. Un risultato che arriva in ritardo è spesso funzionalmente equivalente a nessun risultato.

Quale contesto normativo è importante qui?

Le norme sulla sicurezza funzionale non approvano ipotesi temporali casuali. La IEC 61508 si occupa di comportamento prevedibile, esecuzione validata e risposta nota ai guasti, non del fatto che un modello sembri impressionante in un notebook.

Ciò richiede un confine attento:

• Incorporare una rete neurale in Structured Text non la rende automaticamente una funzione di sicurezza.
• Può supportare una logica di monitoraggio del processo deterministica se la sua esecuzione è validata, limitata e segregata in modo appropriato.
• Se l'output influenza un'azione legata alla sicurezza, l'onere della verifica aumenta drasticamente. "Ha funzionato nella simulazione" non è un caso di sicurezza.

Un'idea sbagliata comune è che inserire l'AI all'interno del PLC la renda automaticamente più industriale. La avvicina solo al ciclo di scansione. La parte difficile rimane la prova.

Solo i modelli feedforward di piccole dimensioni sono pratici nella maggior parte dei contesti PLC. Questo è il confine utile.

Il candidato più comune è un percettrone multistrato (MLP) superficiale addestrato offline in MATLAB, Python o un ambiente simile, quindi esportato come pesi e bias statici. Questo funziona perché l'inferenza per un MLP fisso è solo aritmetica:

• moltiplicazione di matrici
• addizione di bias
• valutazione della funzione di attivazione
• logica di soglia o classificazione

Quell'aritmetica è noiosa ma deterministica.

I modelli con maggiori probabilità di adattarsi sono:

• MLP a singolo strato nascosto o superficiali
• Vettori di input piccoli
• Conteggio limitato di nodi nascosti
• Funzioni di attivazione semplici, come ReLU o approssimazioni lineari limitate

I modelli con meno probabilità di adattarsi in modo pulito sono:

• reti ricorrenti
• modelli convoluzionali di grandi dimensioni
• architetture transformer
• qualsiasi cosa richieda un comportamento dinamico della memoria, librerie non supportate o un throughput sostanziale in virgola mobile

Questa non è un'affermazione sulla capacità dell'AI in generale. È un'affermazione sull'economia del controllore e sulla disciplina di scansione.

Il processo di conversione è semplice nel concetto e spietato nei dettagli. La maggior parte dei fallimenti non è matematica. Sono fallimenti di indicizzazione, scalabilità, tipo di dati o tempo di task.

### Passaggio 1: Addestrare un modello leggero offline

Addestrare il modello in MATLAB, Python o un altro ambiente ML utilizzando dati di processo storici o dati di eventi etichettati.

I buoni candidati per l'implementazione su PLC di solito hanno:

• input numerici normalizzati
• conteggio delle feature limitato
• inviluppi operativi stabili
• etichette di anomalia chiare o logica di soglia
• un percorso di inferenza che può essere spiegato e limitato

Se il modello ha bisogno di una GPU desktop per funzionare comodamente, di solito non appartiene a un task di controllo standard.

### Passaggio 2: Esportare pesi e bias

Estrarre i parametri addestrati dal modello:

• matrice dei pesi da input a strato nascosto
• vettore dei bias dello strato nascosto
• matrice dei pesi da strato nascosto a output
• vettore dei bias dello strato di output

I formati di esportazione tipici includono:

• CSV
• JSON
• Array MATLAB
• Array NumPy di Python scritti in testo

In questa fase, preservare:

• dimensioni degli array
• ordinamento righe/colonne
• precisione numerica
• costanti di normalizzazione degli input
• valori di soglia di output

Un numero sorprendente di problemi di distribuzione sono in realtà solo matrici trasposte.

### Passaggio 3: Convertire i parametri in array conformi a IEC 61131-3

Riscrivere i parametri del modello come array Structured Text utilizzando tipi di dati supportati dal controllore, tipicamente `REAL` o `LREAL` a seconda della capacità della piattaforma e del budget di scansione.

Esempio di mappatura della forma:

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

Definire anche:

• array dei vettori di input
• array delle somme dei nodi intermedi
• array di output dell'attivazione
• array di output dell'inferenza finale

La scelta del tipo di dati è importante. `LREAL` può migliorare la fedeltà numerica, ma può anche aumentare il costo di esecuzione a seconda dell'architettura del controllore.

### Passaggio 4: Ricreare il passaggio feedforward in Structured Text

Implementare il modello come aritmetica esplicita:

1. inizializzare ogni somma di nodo con il suo bias
2. accumulare i prodotti degli input pesati
3. applicare la funzione di attivazione
4. passare gli output attivati allo strato successivo
5. confrontare l'output finale con una soglia o una regola di classificazione

È qui che il modello diventa un blocco aritmetico deterministico.

### Passaggio 5: Ricreare la pre-elaborazione e la logica di output

Un modello addestrato su input normalizzati deve ricevere input normalizzati nel PLC. Altrimenti, l'inferenza è matematicamente corretta e operativamente sbagliata.

È necessario implementare:

• scalabilità
• correzione dell'offset
• clamping se richiesto
• gestione dei segnali mancanti
• soglia di output
• comportamento in stato di guasto se il blocco di inferenza riceve dati non validi

Un modello senza il suo percorso di pre-elaborazione non è distribuito. È semplicemente copiato.

La moltiplicazione di matrici in Structured Text viene solitamente implementata con cicli `FOR` nidificati e accumulo esplicito in array di somme di nodi. L'obiettivo è la correttezza, il determinismo e la visibilità del tempo di scansione.

Esempio: somma pesata dello strato nascosto

Linguaggio: Structured Text

// Somma pesata dello strato nascosto 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;

Questo codice esegue il prodotto scalare tra il vettore di input e la riga dei pesi di ogni neurone dello strato nascosto, quindi aggiunge il bias corrispondente.

Controlli di implementazione importanti:

• confermare se il PLC utilizza convenzioni di array basate su zero o su uno
• mantenere esplicite le dimensioni dell'array
• inizializzare le somme prima dell'accumulo
• evitare la conversione di tipo nascosta
• testare il tempo di esecuzione nel caso peggiore, non solo il tempo di esecuzione nominale

Un ciclo che funziona una volta è una demo. Un ciclo che funziona alla velocità del task con input rumorosi è ingegneria.

Come si calcola lo strato di output?

Lo strato di output segue lo stesso schema applicato alle attivazioni dello strato nascosto.

Linguaggio: Structured Text

// Somma pesata dello strato di output 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;

Per un singolo punteggio di anomalia, `OutputNodes` può essere `1`, con il punteggio finale confrontato rispetto a una soglia.

ReLU è una delle funzioni di attivazione più facili da tradurre perché è lineare a tratti. In Structured Text, diventa una semplice condizione.

Linguaggio: Structured Text

// Attivazione 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;

Questo preserva la regola base di ReLU:

• se input < 0, output = 0
• altrimenti output = input

Quella semplicità è utile nei PLC perché evita funzioni non lineari più costose.

Quali altri approcci di attivazione sono pratici?

Le opzioni pratiche dipendono dalla capacità del controllore, ma gli approcci comuni includono:

- ReLU: il più semplice per l'implementazione diretta - Attivazione lineare: utile per output di tipo regressione - Approssimazione a tratti: talvolta utilizzata quando è necessaria una funzione non lineare liscia ma il supporto matematico nativo è limitato

Le opzioni meno pratiche in molti PLC includono:

• calcoli esatti di sigmoide o tanh che utilizzano esponenziali costosi
• schemi di attivazione dinamica che richiedono librerie non supportate
• architetture che dipendono dal comportamento del grafo in runtime

Nel lavoro di controllo, il comportamento limitato spesso batte il comportamento elegante ma non testabile.

Il rilevamento di anomalie diventa operativamente significativo solo quando l'output è legato a un'azione di controllo definita. "Il modello ha prodotto 0,83" non è ancora un risultato ingegneristico.

Un'implementazione utilizzabile necessita di:

• un punteggio di anomalia definito
• una soglia o una regola di classificazione
• una regola di debounce o persistenza se si prevede rumore
• una risposta di controllo chiara

Ad esempio:

- impostare `AnomalyDetected := TRUE` - rilasciare `MotorRunPermissive := FALSE`

• se il punteggio di anomalia > soglia per 500 ms
• bloccare un allarme
• richiedere il ripristino dell'operatore o della supervisione a seconda della filosofia

Quella logica deve essere documentata in termini di controllo, non in termini di ML.

Definizione operativa del rilevamento di anomalie

In questo articolo, rilevamento di anomalie significa:

> leggere un insieme limitato di input di processo, eseguire un blocco di inferenza feedforward deterministico all'interno del task PLC, confrontare il punteggio risultante con una soglia definita e modificare una variabile di stato di controllo come un consenso, un allarme o un mantenimento di sequenza quando la condizione di soglia è soddisfatta.

Quella definizione è intenzionalmente ristretta. È osservabile, testabile e adatta alla validazione.

I rischi principali sono il superamento della scansione, la discrepanza numerica e la falsa fiducia.

1. Rischio di tempo di scansione e watchdog

L'aritmetica delle matrici consuma tempo di task. Se il blocco di inferenza è troppo grande o mal strutturato, può innescare guasti del watchdog o degradare la reattività del controllo.

I fattori di rischio includono:

• matrici grandi
• esecuzione frequente in task veloci
• uso intensivo di virgola mobile
• ripetuta normalizzazione e scalabilità all'interno dello stesso ciclo
• ricomputazione non necessaria

Le mitigazioni includono:

• riduzione delle dimensioni del modello
• spostamento dell'inferenza in un task periodico più lento dove appropriato
• pre-calcolo delle costanti
• utilizzo di test di esecuzione limitati
• validazione dell'impatto della scansione nel caso peggiore prima della distribuzione

2. Discrepanza di tipo di dati e precisione

Un modello addestrato in `float64` e distribuito in `REAL` può comportarsi diversamente a livello di soglie. Quella differenza può essere piccola numericamente e grande operativamente.

Controllare:

• intervallo numerico
• coerenza della scalabilità
• sensibilità della soglia
• comportamento in virgola mobile specifico del controllore

3. Errori di indicizzazione e orientamento della matrice

Una matrice trasposta, un indice spostato o una mappatura errata dei bias possono produrre output che sembrano plausibili pur essendo completamente errati.

Ecco perché la validazione deterministica è importante. Gli errori aritmetici sono spesso abbastanza educati da compilare.

4. Comportamento con input non validi

Un sensore mancante, un valore obsoleto, un trasmettitore saturato o una cattiva scalabilità analogica possono corrompere l'inferenza.

Definire:

• cosa succede in caso di cattiva qualità
• se il blocco si inibisce da solo
• se l'output fallisce in sicurezza, fallisce in modo neutro o allarma solo
• se il risultato viene ignorato durante gli stati di manutenzione o avvio

5. Uso improprio in contesti di sicurezza

Un blocco di inferenza neurale non dovrebbe essere descritto come classificato per la sicurezza solo perché si trova all'interno di un PLC. Se influenza una funzione legata alla sicurezza, gli obblighi di progettazione, verifica e ciclo di vita diventano sostanzialmente più impegnativi.

OLLA Lab è utile qui come ambiente di validazione limitato per task di messa in servizio ad alto rischio. Non è una scorciatoia per i test del controllore e non sostituisce l'accettazione in loco. È dove si provano le modalità di guasto prima che l'hardware e il tempo di processo diventino costosi.

In questo caso d'uso, OLLA Lab può supportare gli ingegneri fornendo:

• un ambiente logico basato su browser per costruire e rivedere la logica di controllo
• modalità di simulazione per eseguire, arrestare e osservare il comportamento senza hardware fisico
• visibilità di variabili e I/O per tracciare i valori intermedi
• test realistici basati su scenari contro il comportamento simulato dell'apparecchiatura
• flussi di lavoro di validazione in stile digital twin in cui la logica può essere confrontata con la risposta prevista della macchina

Per il flusso di lavoro di questo articolo, il valore pratico è chiaro:

• scrivere la logica di inferenza
• associare gli input alle variabili di processo simulate
• iniettare disturbi o condizioni anomale
• osservare i cambiamenti di stato dell'output
• verificare se la risposta di controllo corrisponde alla filosofia prevista

Questo è ciò che Simulation-Ready dovrebbe significare in termini operativi: un ingegnere che può provare, osservare, diagnosticare e indurire la logica di controllo contro un comportamento di processo realistico prima che raggiunga un processo dal vivo.

Cosa significa validazione digital twin qui?

In questo contesto limitato, validazione digital twin significa testare la logica di controllo contro un modello di apparecchiatura simulato realistico in modo che l'ingegnere possa confrontare:

• stato ladder o Structured Text
• stato I/O
• risposta del processo
• gestione delle condizioni anomale
• azione di controllo risultante

Non significa che il modello simulato sia automaticamente una replica perfetta del comportamento in loco. Significa che la logica può essere provata contro le dinamiche rappresentative della macchina o del processo prima della distribuzione sul campo.

Un flusso di lavoro pratico consiste nel trattare la rete neurale come un blocco all'interno di una narrazione di controllo più ampia piuttosto che come un oggetto di novità.

Una sequenza di validazione rappresentativa sarebbe:

1. Costruire il blocco di inferenza Implementare i pesi, i bias, la normalizzazione e la logica di soglia esportati in Structured Text o in un flusso di lavoro di logica di controllo supportato equivalente.
2. Associare gli input ai segnali di processo simulati Mappare gli input del modello a variabili come vibrazione, corrente del motore, aumento di temperatura, fluttuazione di pressione o instabilità di flusso.
3. Definire lo stato normale previsto Confermare che l'output del modello rimanga al di sotto della soglia durante il funzionamento sano.
4. Iniettare una condizione anomala Introdurre un disturbo come vibrazione oscillatoria, picco del sensore, deriva, o comportamento di carico instabile.
5. Osservare l'output dell'inferenza e la risposta di controllo Verificare che il punteggio di anomalia superi la soglia solo quando previsto e che lo stato di consenso, allarme o sequenza cambi correttamente.
6. Misurare l'onere logico Rivedere se l'aritmetica aggiunta crea un costo di esecuzione inaccettabile o un comportamento instabile.

Quella sequenza è importante perché il rilevamento di anomalie è utile solo quando è legato alla conseguenza del processo. Un punteggio senza un percorso di azione è solo un numero.

Una galleria di screenshot è una prova debole. Un record di validazione compatto è più utile per revisori, istruttori e datori di lavoro perché mostra il ragionamento, non solo la familiarità con l'interfaccia.

Utilizzare questa struttura:

Registrare cosa è cambiato dopo il primo test: regolazione della soglia, logica di debounce, correzione della scalabilità, posizionamento del task o ottimizzazione della matrice.

1. Descrizione del sistema Descrivere l'apparecchiatura, l'obiettivo del processo, gli input rilevanti e dove si colloca il blocco di rilevamento anomalie nella filosofia di controllo.
2. Definizione operativa del comportamento corretto Affermare esattamente cosa deve fare la logica in condizioni normali e anomale, inclusi soglie, tempistiche e stati di output previsti.
3. Stato della logica e dell'apparecchiatura simulata Mostrare la logica implementata e il corrispondente comportamento simulato della macchina o del processo durante il test.
4. Il caso di guasto iniettato Documentare il disturbo introdotto, come rumore del sensore, deriva, oscillazione o carico anomalo.
5. La revisione apportata
6. Lezioni apprese Riassumere ciò che il test ha rivelato sulla distribuibilità, i falsi positivi, l'onere di scansione o la filosofia di controllo.

Quel corpo di prove è molto più vicino al giudizio di messa in servizio rispetto a uno screenshot rifinito.

La distribuzione dovrebbe essere regolata da una verifica limitata, non dall'entusiasmo.

Utilizzare una checklist pre-distribuzione:

• La dimensione del modello è appropriata per il controllore e la velocità del task
• La scalabilità dell'input corrisponde alle condizioni di addestramento
• Pesi e bias sono mappati correttamente
• La logica di attivazione è implementata esattamente come previsto
• Il comportamento della soglia è documentato
• La gestione degli input errati è definita
• Il tempo di esecuzione nel caso peggiore è testato
• La risposta di controllo all'anomalia è verificata
• Il comportamento di fallback è definito se il blocco di inferenza non è valido
• Sono pianificati test di messa in servizio specifici per il sito

Se il modello non può superare questa checklist, non è pronto per il PLC. Potrebbe essere ancora utile altrove.

Questo approccio risolve un problema OT specifico: come eseguire un piccolo modello addestrato in modo deterministico all'interno di un ambiente di controllo in stile PLC senza fare affidamento su un'infrastruttura di inferenza esterna.

Può aiutare con:

• punteggio di anomalia a bassa latenza
• inferenza locale limitata
• riduzione della dipendenza dalla rete nelle decisioni di controllo
• validazione dell'aritmetica del modello contro un comportamento di processo realistico

Non risolve:

• certificazione di sicurezza per implicazione
• governance del modello da sola
• messa in servizio specifica dell'impianto solo tramite simulazione
• idoneità di architetture neurali grandi o complesse per hardware PLC standard

Vale la pena mantenere pulito quel confine.

Convertire i pesi di una rete neurale in Structured Text PLC è tecnicamente fattibile quando il modello è piccolo, il percorso aritmetico è esplicito e l'onere di esecuzione è validato rispetto ai vincoli del controllore. Il punto non è far imitare ai PLC gli ambienti Python. Il punto è posizionare una funzione di inferenza limitata dove la risposta deterministica conta di più.

La sequenza ingegneristica è chiara:

• addestrare offline
• esportare pesi e bias
• riscriverli come array IEC 61131-3
• implementare la matematica feedforward e la logica di attivazione
• validare l'impatto della scansione e il comportamento in caso di guasto
• testare la conseguenza di controllo contro condizioni di processo simulate realistiche

È qui che OLLA Lab diventa operativamente utile. Fornisce un luogo per provare la logica pesante sulle matrici, osservare il comportamento di I/O e variabili, iniettare condizioni anomale e indurire il design prima della messa in servizio dal vivo. Questo è un uso credibile della simulazione: non sostituire la prova sul campo, ma rendere la prova sul campo meno spericolata.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety overview - NIST AI Risk Management Framework (AI RMF 1.0) - Digital twin review (IFAC-PapersOnLine) - Industrial AI in Industry 4.0 (Manufacturing Letters)