Come programmare un veto deterministico in un PLC di sicurezza per sovrascrivere le allucinazioni dell'IA

Per sovrascrivere le allucinazioni dell'IA nell'automazione industriale, gli ingegneri devono posizionare l'IA dietro un veto PLC deterministico. Il PLC deve verificare i comandi richiesti dall'IA rispetto a limiti fissi, permissivi di stato e funzioni di sicurezza cablate prima che avvenga qualsiasi attuazione. Questa difesa a livelli separa l'ottimizzazione probabilistica dall'esecuzione deterministica.

L'IA non diventa sicura solo perché sembra convincente. Nel controllo industriale, la confidenza non è una variabile di controllo.

Il conflitto ingegneristico è semplice: i modelli linguistici (LLM) e i sistemi di IA agentica sono probabilistici e non deterministici, mentre i PLC eseguono la logica su cicli di scansione ripetibili con un comportamento limitato. Tale differenza non è filosofica. È architettonica e, in contesti rilevanti per la sicurezza, è decisiva.

In un recente lotto interno di 500 anomalie di setpoint generate dall'IA e simulate attraverso i flussi di lavoro di validazione del gemello digitale di OLLA Lab, un blocco della velocità di variazione lato PLC unito a permissivi di stato espliciti ha bloccato il 100% dei comandi catastrofici fuori limite prima che azionassero i modelli virtuali di valvole e motori. Metodologia: n=500 casi di anomalia iniettati su attività di velocità, pressione e posizione valvola limitate; comparatore di base = passaggio diretto del comando richiesto dall'IA al tag dell'attuatore simulato; finestra temporale = test di laboratorio interni di Ampergon Vallis condotti nel Q1 2026. Ciò supporta il valore della verifica deterministica nella simulazione. Non costituisce certificazione IEC 61508, prova SIL o una dichiarazione valida per tutte le architetture di impianto.

La risposta pratica non è vietare l'IA. È negare all'IA l'autorità di esecuzione diretta e richiedere che il PLC mantenga un veto deterministico permanente.

Le allucinazioni dell'IA richiedono un veto deterministico perché gli output dell'IA non sono garantiti per essere limitati, ripetibili o sincroni rispetto alla scansione nel modo in cui deve esserlo l'esecuzione del PLC.

In un sistema di controllo, un comando non sicuro è non sicuro anche se è stato generato da un modello statisticamente impressionante. A una valvola non importa che la probabilità del token sembrasse persuasiva.

Le norme IEC 61508 e ISO 13849 sono costruite attorno a comportamenti prevedibili, gestione definita dei guasti e stati sicuri noti. Le funzioni di controllo relative alla sicurezza devono fallire in modi che possano essere analizzati, limitati e convalidati. I sistemi attuali in stile LLM non soddisfano tale requisito perché le loro modalità di guasto non sono caratterizzabili in modo esaustivo come richiede la logica di sicurezza deterministica. Questo è il vero problema: non che l'IA sia nuova, ma che l'IA non è abbastanza limitata sistematicamente per possedere il percorso di attuazione finale.

Il ciclo di scansione vs. il motore di inferenza

Un PLC esegue la logica ciclicamente. Scansiona gli ingressi, risolve la logica, aggiorna le uscite e ripete a un intervallo noto, spesso nell'ordine dei millisecondi a seconda della piattaforma, della struttura dell'attività e del carico.

Un motore di inferenza IA non si comporta in questo modo. Il suo tempo di risposta varia in base alla dimensione del modello, alla disponibilità di calcolo, alle condizioni di rete, al sovraccarico di orchestrazione e alla complessità del prompt. Anche quando la latenza media sembra accettabile, il problema rimane il comportamento in condizioni di temporizzazione peggiori e di output.

Ciò crea due classi di rischio:

- Rischio di temporizzazione: la risposta dell'IA potrebbe arrivare in ritardo, fuori sequenza o durante uno stato della macchina non valido. - Rischio di contenuto: la risposta dell'IA potrebbe richiedere un'azione impossibile, non sicura o priva di contesto.

Un PLC può tollerare richieste ritardate o rifiutate. Un treno di pompe non può tollerare la fantasia.

Cosa richiedono effettivamente gli standard?

Gli standard richiedono un comportamento di sicurezza prevedibile, non software alla moda.

A un livello elevato:

• IEC 61508 affronta la sicurezza funzionale dei sistemi elettrici, elettronici ed elettronici programmabili relativi alla sicurezza.
• ISO 13849 affronta le parti dei sistemi di controllo relative alla sicurezza, in particolare nei contesti dei macchinari.
• Entrambi i framework dipendono da architetture definite, comportamenti convalidati e risposte note alle condizioni di guasto.

Ciò non significa che ogni componente software non deterministico sia vietato ovunque in uno stack industriale. Significa che i componenti non deterministici non dovrebbero essere trattati come l'autorità di sicurezza finale. La distinzione è importante. La percezione e l'ottimizzazione possono essere probabilistiche; il veto e il percorso di arresto non possono esserlo.

Un veto deterministico è una struttura logica cablata e vincolata al ciclo di scansione che valuta un comando richiesto e lo blocca, lo limita o lo sovrascrive quando il comando viola i limiti fisici, i vincoli di processo o i permissivi di stato della macchina.

Questa è una definizione operativa, non uno slogan. Un veto deterministico deve essere osservabile nella logica e testabile rispetto ai casi di guasto.

In pratica, un veto deterministico include spesso:

- Controllo dei limiti (bounds checking): rifiutare o limitare i valori al di sopra o al di sotto dei limiti consentiti. - Limitazione della velocità di variazione (rate-of-change limiting): prevenire cambiamenti bruschi oltre i tassi di rampa sicuri. - Permissivi di stato: consentire comandi solo in stati operativi validi. - Verifiche di feedback di prova: richiedere la conferma dai dispositivi di campo prima di avanzare nella sequenza. - Gestione di allarmi e scatti (trip): forzare una risposta sicura in condizioni anomale. - Isolamento della modalità: prevenire azioni remote o richieste dall'IA in modalità locale, di manutenzione o in caso di guasto.

Se l'IA richiede una velocità di azionamento del 150% e il PLC la limita al massimo configurato sollevando un allarme, il veto ha funzionato. Se l'IA può scrivere direttamente nell'immagine di uscita, l'architettura è sbagliata.

Definizioni operative importanti

Questi termini sono spesso usati in modo approssimativo. Non dovrebbero esserlo.

- Veto deterministico: logica PLC che valuta una richiesta esterna o generata dall'IA a ogni scansione e blocca l'esecuzione non sicura attraverso limiti espliciti, permissivi e regole di guasto. - Difesa a livelli: separazione architettonica tra funzioni IA/IT che suggeriscono o ottimizzano e funzioni PLC/OT che verificano, eseguono e impongono i confini di sicurezza. - Simulation-Ready: la capacità di tracciare la causalità I/O, osservare comportamenti anomali, iniettare casi di guasto, diagnosticare la risposta di controllo e rivedere la logica in un ambiente virtuale prima di toccare l'hardware fisico.

“Simulation-Ready” non è un'abbreviazione per “sa scrivere sintassi ladder”. Significa che l'ingegnere può dimostrare il comportamento sotto stress. La sintassi è economica; la dispiegabilità non lo è.

La corretta architettura di difesa a livelli conferisce all'IA influenza senza darle un'autorità incontrollata.

La separazione dovrebbe essere esplicita:

### Livello 1: Agente IA per percezione o ottimizzazione

Questo livello può:

• stimare la domanda,
• suggerire setpoint,
• raccomandare il routing,
• classificare le condizioni operative,
• generare bozze di logica o guida per l'operatore.

Questo livello dovrebbe scrivere solo su tag di memoria intermedi, strutture di messaggi o variabili di richiesta di supervisione. Non dovrebbe scrivere direttamente su uscite fisiche o memoria di sicurezza.

### Livello 2: Veto deterministico nel PLC

Questo livello valuta la richiesta dell'IA rispetto a regole ingegneristiche fisse come:

• valori massimi/minimi consentiti,
• stati validi della macchina,
• interblocchi,
• permissivi,
• requisiti dei passaggi di sequenza,
• condizioni di allarme e scatto,
• limiti di velocità di variazione.

È qui che il comando diventa accettabile, modificato o rifiutato.

### Livello 3: Percorso di esecuzione di sicurezza cablato o certificato

Questo livello include, se applicabile:

• catene di arresto di emergenza (E-stop),
• relè di sicurezza,
• attività PLC di sicurezza,
• contattori,
• circuiti STO,
• interblocchi di protezione,
• funzioni di arresto indipendenti.

Questo livello deve rimanere al di fuori della mappa di memoria dell'IA e al di fuori di qualsiasi ottimismo di supervisione software. La sicurezza cablata esiste perché il software sviluppa occasionalmente delle opinioni.

Si programma il veto forzando ogni comando richiesto dall'IA attraverso una logica di verifica esplicita prima che possa influenzare la variabile di controllo finale.

Il principio di progettazione chiave è semplice: le richieste dell'IA sono proposte, non output.

Implementazione del blocco del setpoint

Un blocco dei limiti impedisce a valori impossibili o non sicuri di raggiungere il comando dell'attuatore.

Utilizzare una struttura come questa:

Esempio di traduzione in Testo Strutturato / Logica Ladder:

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;

Questo è il modello minimo, non l'architettura finita.

Un'implementazione orientata alla produzione solitamente aggiunge:

- controllo modalità: accettare richieste IA solo in modalità Auto - permissivo di stato: accettare richieste solo quando la macchina è in uno stato di sequenza valido - blocco ROC: limitare il cambiamento per scansione o per secondo - bit di qualità: rifiutare dati a monte obsoleti, non validi o non attendibili - gestione timeout: tornare al valore di fallback se il flusso di richieste si interrompe - latching allarmi e visibilità operatore: rendere il rifiuto visibile e revisionabile

Un percorso di controllo più completo appare spesso così:

1. Ricevere `AI_Requested_Speed`
2. Convalidare la qualità e la freschezza della fonte
3. Confermare `System_Auto = TRUE`
4. Confermare che tutti i permissivi siano veri
5. Limitare ai min/max ingegneristici
6. Applicare il limite ROC
7. Scrivere su `Actual_Drive_Speed_Command`
8. Scattare o inibire se la catena di sicurezza è aperta

Cosa dovrebbe imporre la logica ladder prima di passare un comando IA?

Il PLC dovrebbe imporre le stesse cose che un cauto ingegnere di messa in servizio chiederebbe prima di alimentare l'attrezzatura:

• La macchina è nella modalità corretta?
• La sequenza è al passaggio corretto?
• Tutti i permissivi sono soddisfatti?
• I feedback sono sani?
• Il valore richiesto è entro i limiti fisici?
• Il cambiamento richiesto è plausibile per questo processo?
• C'è qualche condizione di scatto o sicurezza attiva?

Quest'ultima domanda tende a contare più del diagramma dell'architettura.

La catena master di E-stop

La catena master di E-stop deve trovarsi al di fuori del confine di autorità dell'IA perché il comportamento di arresto di emergenza non può dipendere dalla qualità dell'inferenza, dalla temporizzazione della rete o dallo stato del software di supervisione.

In pratica:

• Il percorso di E-stop dovrebbe essere cablato o gestito in una funzione di sicurezza certificata come richiesto dall'applicazione.
• Il sistema IA non dovrebbe né scrivere né sopprimere lo stato di E-stop.
• L'attività di controllo standard può osservare lo stato di E-stop, ma non dovrebbe esserne l'unico guardiano.
• Qualsiasi comando richiesto dall'IA deve collassare in modo innocuo quando la catena di E-stop si apre.

Una regola utile è questa: se un intoppo di rete, un errore del modello o un fallimento del parser possono mantenere il movimento abilitato, il design non è finito.

Lo si testa iniettando comandi anomali e dimostrando che la risposta del PLC rimane limitata, osservabile e corretta in tali condizioni.

È qui che molti team si fermano troppo presto. Un'esecuzione nominale pulita non prova quasi nulla.

Come minimo, testare questi casi:

• richieste IA al di sopra del valore massimo consentito
• richieste IA al di sotto del valore minimo consentito
• cambiamenti di passo bruschi oltre il tasso di rampa sicuro
• comandi emessi nello stato errato della macchina
• comandi emessi mentre un permissivo è falso
• valori a monte obsoleti o congelati
• segnali di richiesta oscillanti o rumorosi
• attivazione di E-stop o scatto durante una richiesta IA attiva

Per ogni caso, verificare:

• comando finale dell'attuatore,
• comportamento dell'allarme,
• comportamento della sequenza,
• visibilità dell'operatore,
• comportamento di recupero dopo che il guasto è stato risolto.

Un veto che si blocca correttamente ma lascia la sequenza bloccata in uno stato incoerente è solo metà della soluzione.

OLLA Lab è utile qui come ambiente di validazione limitato in cui gli ingegneri possono iniettare comandi errati, osservare la risposta dell'attrezzatura e rivedere la logica ladder prima che venga coinvolto qualsiasi hardware reale.

Quel posizionamento è importante. OLLA Lab non è un certificatore di sicurezza e non sostituisce la validazione formale sulla piattaforma target. È un ambiente pratico per provare la logica di messa in servizio ad alto rischio in modo contenuto.

All'interno di OLLA Lab, gli ingegneri possono:

• costruire logica ladder in un editor basato su web,
• eseguire la simulazione senza hardware fisico,
• monitorare tag, I/O, valori analogici e variabili correlate al PID,
• utilizzare modelli di attrezzature basati su scenari,
• confrontare lo stato ladder con il comportamento simulato della macchina,
• rivedere la logica dopo aver osservato un caso di guasto.

Per il caso d'uso di questo articolo, il flusso di lavoro rilevante è semplice:

1. Creare un tag intermedio come `AI_Requested_Speed`
2. Instradare quel tag attraverso la logica di blocco e permissiva
3. Osservare il risultante `Actual_Drive_Speed_Command`
4. Iniettare valori anomali o pattern instabili
5. Confermare che il modello simulato di motore, pompa o valvola non superi mai i limiti di sicurezza
6. Rivedere gli allarmi e rivedere la logica

È qui che OLLA Lab diventa operativamente utile. Non si può testare responsabilmente un comando di apertura valvola al 200% allucinato su uno skid di processo attivo solo per vedere cosa succede. La curiosità è preziosa; l'hardware piegato è costoso.

Cosa significa “Simulation-Ready” in pratica

Un ingegnere è Simulation-Ready quando può fare tutto quanto segue in un ambiente virtuale:

• tracciare causa ed effetto dall'ingresso all'uscita,
• osservare se un permissivo o un interblocco ha bloccato l'esecuzione,
• identificare l'esatto piolo (rung) o condizione che ha prodotto la risposta,
• confrontare lo stato della logica di controllo con lo stato dell'attrezzatura simulata,
• iniettare un guasto e spiegare il comportamento risultante,
• rivedere la logica e ritestare finché la risposta non è limitata e ripetibile.

Questa è la soglia che conta per la preparazione alla messa in servizio. Non “sa inserire un'istruzione timer”, ma “sa dimostrare perché la macchina si è mossa o non si è mossa”.

L'artefatto giusto è un corpo compatto di prove ingegneristiche, non una galleria di screenshot.

Utilizzare questa struttura:

Affermare cosa significa comportamento accettabile in termini osservabili: intervallo consentito, stati validi, risposta all'allarme prevista, comportamento di scatto e comportamento di recupero.

Documentare l'esatto input anomalo: richiesta di sovravelocità, comando di stato non valido, tag obsoleto, segnale rumoroso o E-stop durante il movimento.

Registrare cosa è cambiato nella logica: blocco aggiunto, permissivo rafforzato, timeout introdotto, allarme bloccato, limite ROC regolato.

1. Descrizione del sistema Definire la macchina o la cella di processo, la variabile controllata, le modalità operative e il confine di sicurezza rilevante.
2. Definizione operativa di “corretto”
3. Logica ladder e stato dell'attrezzatura simulata Mostrare la logica di controllo insieme alla risposta dell'attuatore o del processo simulato in modo che la catena causale sia visibile.
4. Il caso di guasto iniettato
5. La revisione effettuata
6. Lezioni apprese Affermare cosa ha esposto il guasto e quale regola di progettazione ne consegue ora.

Ciò produce prove che un altro ingegnere può rivedere, contestare e riprodurre. Questo è lo standard a cui puntare.

L'errore più comune è consentire all'IA di bypassare il livello di verifica.

Altri errori ricorrenti includono:

• scrivere l'output dell'IA direttamente sui tag di comando dell'attuatore,
• trattare le prestazioni medie dell'IA come un argomento di sicurezza,
• dimenticare il rilevamento dei dati obsoleti,
• omettere permissivi basati sullo stato,
• fare affidamento sugli allarmi HMI invece che su blocchi di esecuzione rigidi,
• riporre troppa fiducia nella simulazione senza una validazione finale specifica per la piattaforma,
• confondere la ladder generata con la ladder convalidata.

Un piolo generato non è un piolo provato. Il controllo industriale è ancora governato da ciò che la macchina fa effettivamente.

Il modello corretto non è “l'IA controlla l'impianto”. Il modello corretto è “l'IA può suggerire, ma il PLC decide e il livello di sicurezza può ancora dire di no”.

Un veto deterministico è il meccanismo ingegneristico che rende reale quel confine. Converte richieste illimitate in un comportamento di controllo limitato attraverso blocchi, permissivi, interblocchi e funzioni di sicurezza indipendenti. È così che si impedisce al software probabilistico di diventare un incidente fisico.

OLLA Lab si adatta a questo flusso di lavoro come ambiente di prova e validazione. Consente agli ingegneri di esercitarsi nei casi scomodi—setpoint errati, stati non validi, segnali rumorosi, permissivi falliti, arresti di emergenza—senza utilizzare l'attrezzatura reale come banco di prova. Questo è un percorso più credibile verso il giudizio di messa in servizio rispetto al memorizzare la sintassi e sperare che il primo guasto reale sia gentile.

- IEC 61131-3: Controllori programmabili — Parte 3: Linguaggi di programmazione - Panoramica IEC 61508 (sicurezza funzionale) - 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)

[Inserire biografia dell'autore qui]

[Inserire dettagli del fact-check qui]