Come separare la percezione dell'IA dalla sicurezza del PLC: L'architettura "Midollo Allungato"

L'architettura "Midollo Allungato" separa la percezione non deterministica dell'IA dal controllo deterministico del PLC. In questo modello, l'IA può proporre setpoint o classificazioni, ma il PLC rimane il livello di validazione ed esecuzione hard real-time che impone limiti, permissivi, watchdog e comportamenti in stato sicuro prima che qualsiasi comando raggiunga l'attrezzatura.

L'IA non è un controllore di sicurezza e trattarla come tale è un errore architettonico prima ancora di diventare un errore di messa in servizio. La distinzione utile è semplice: l'IA è efficace nella percezione, nella stima e nell'ottimizzazione; i PLC sono efficaci nell'esecuzione deterministica, negli interblocchi e nel controllo limitato.

Questa distinzione è importante perché i sistemi di controllo industriale non falliscono in astratto. Falliscono sotto forma di heartbeat mancati, valori obsoleti, condizioni di race condition e uscite che si attivano quando non dovrebbero. La macchina raramente rimane colpita da un modello intelligente.

Un recente test interno di Ampergon Vallis conferma il valore pratico di questa separazione. Durante un esercizio di simulazione di 100 ore in OLLA Lab, gli aggiornamenti asincroni dei setpoint esterni iniettati in uno scenario di controllo a ciclo chiuso hanno prodotto un aumento del 14% degli eventi di errore di "integral windup" rispetto a un percorso di validazione PLC con clamp e limitazione di velocità, mentre il percorso governato dal PLC ha mantenuto la varianza di risposta entro un inviluppo di esecuzione deterministico di 3 ms per la sequenza di rung di validazione. [Metodologia: test di simulazione di 100 ore; attività = passaggio di setpoint esterno in uno scenario di controllo limitato; comparatore di base = iniezione asincrona diretta del setpoint senza validazione tramite clamp e watchdog; finestra temporale = singola esecuzione continua di 100 ore.] Questa metrica supporta il valore della validazione difensiva del PLC in simulazione. Non supporta alcuna pretesa generalizzata su tutti i sistemi IA, tutti gli impianti o certificazioni di sicurezza formali.

L'esecuzione deterministica è necessaria perché le decisioni di sicurezza e di controllo primario devono avvenire entro limiti temporali noti. I motori di inferenza IA, locali o remoti, non garantiscono questa proprietà.

Un PLC esegue il suo programma in un ciclo di scansione limitato. Gli ingressi vengono letti, la logica viene risolta, le uscite vengono scritte e il ciclo si ripete a un intervallo definito. Tale intervallo può variare leggermente in base alla piattaforma e al carico del programma, ma è progettato per rimanere prevedibile e osservabile. La prevedibilità è il punto chiave.

I sistemi IA operano diversamente. Il loro tempo di risposta può variare in base al carico del processore, alla pressione sulla memoria, al comportamento dello scheduler, alla dimensione del modello, al thermal throttling, ai ritardi del middleware o alla latenza di rete. Anche quando l'inferenza media è veloce, il timing nel caso peggiore è ciò che conta quando l'attrezzatura può muoversi, collidere, riempirsi eccessivamente, surriscaldarsi o non riuscire a scattare.

La matematica del ciclo di scansione rispetto all'inferenza asincrona

La distinzione ingegneristica non è filosofica. È temporale.

• Percorso di controllo PLC
• Esegue in un ciclo di scansione ripetuto
• Supporta la valutazione logica limitata
• È progettato per la gestione deterministica degli I/O
• Può essere sottoposto a audit rispetto al timing e al comportamento in caso di guasto

• Percorso di calcolo IA
• Esegue in modo asincrono
• Può restituire risultati a intervalli irregolari
• Può bloccarsi, andare in timeout, subire jitter o produrre uscite obsolete
• Spesso dipende da stack software non progettati come logica di sicurezza primaria

In termini pratici, ci si può fidare che un PLC valuti un permissivo a ogni scansione. Un servizio IA può essere utile, ma non può essere considerato affidabile allo stesso modo. "Utile" e "affidabile" non sono sinonimi. Gli impianti imparano questa distinzione a caro prezzo quando la dimenticano.

Cosa dicono gli standard sul controllo deterministico

La norma IEC 61508 stabilisce il quadro della sicurezza funzionale per i sistemi elettrici, elettronici ed elettronici programmabili correlati alla sicurezza. Un'implicazione centrale per questa discussione è diretta: il comportamento correlato alla sicurezza richiede caratteristiche di esecuzione dimostrabili, limitate e validate.

Ciò non significa che ogni programma PLC sia automaticamente sicuro. Significa che le funzioni di sicurezza richiedono una progettazione deterministica, una verifica e una disciplina del ciclo di vita che i sistemi IA asincroni non forniscono intrinsecamente. exida e le relative linee guida sulla sicurezza funzionale sostengono lo stesso punto pratico in termini industriali: se una funzione è critica per la sicurezza, l'incertezza temporale e il comportamento non verificabile non sono inconvenienti minori.

Una correzione concisa è utile qui: l'IA può assistere un sistema correlato alla sicurezza, ma non dovrebbe essere trattata come il livello di sicurezza deterministico primario. Non si può collegare una barriera fotoelettrica a un LLM e chiamarla architettura.

L'architettura "Midollo Allungato" è un modello di controllo a livelli in cui l'IA propone e il PLC dispone. L'IA esegue la percezione o l'ottimizzazione di alto livello; il PLC rimane l'autorità hard real-time che valida, blocca (clamp), sequenzia o rifiuta tali richieste prima che l'hardware agisca.

L'analogia biologica è memorabile perché è strutturalmente abbastanza accurata da essere utile. La corteccia interpreta e pianifica. Il midollo gestisce le funzioni di sopravvivenza autonomiche. In termini di automazione, l'IA può stimare la qualità del prodotto, rilevare oggetti o suggerire una regolazione della velocità di alimentazione; il PLC mantiene comunque il controllo su interblocchi, catene di arresto, permissivi e attuazione limitata.

La gerarchia di controllo

• Interpreta immagini, trend o il contesto di processo multivariabile
• Genera una classificazione, un consiglio o un setpoint richiesto
• Opera in modo asincrono e può essere errato, ritardato o obsoleto

• Controlla la richiesta rispetto a limiti rigidi
• Verifica lo stato della macchina, i permissivi e gli interblocchi
• Conferma la freschezza tramite logica di heartbeat o watchdog
• Applica limiti di velocità di variazione, clamp e comportamento di fallback

• Riceve solo comandi approvati dal PLC
• Include azionamenti, valvole, contattori, attuatori e allarmi
• Si sposta in uno stato sicuro o limitato se la validazione fallisce

1. Livello di percezione (IA)
2. Livello di validazione (PLC)
3. Livello di esecuzione (Hardware)

Questa non è una posizione anti-IA. È una posizione pro-confini. Una buona architettura è principalmente un rifiuto disciplinato.

Cosa deve sempre mantenere il PLC

Il PLC deve mantenere l'autorità assoluta sulle funzioni che richiedono una risposta deterministica e un comportamento di guasto limitato.

Ciò include tipicamente:

• Elaborazione dell'arresto di emergenza
• Valutazione degli interblocchi di sicurezza
• Permissivi di movimento
• Logica di prevenzione delle collisioni
• Limiti rigidi di corsa o velocità
• Fallback in stato sicuro in caso di perdita di comunicazione
• Gating di sequenza per transizioni pericolose
• Arbitraggio finale dei comandi verso gli attuatori

Se un'IA richiede un aumento di velocità, il PLC può consentirlo, ridurlo, ritardarlo o rifiutarlo. La risposta finale appartiene al livello deterministico.

Si programmano i limiti di sicurezza hard real-time trattando le uscite dell'IA come ingressi esterni non attendibili. Ciò significa che ogni valore originato dall'IA deve passare attraverso una logica difensiva esplicita prima di poter influenzare una macchina o un processo.

È qui che la logica ladder smette di essere esercizio di sintassi e diventa giudizio di messa in servizio. Un rung che semplicemente "funziona" non è sufficiente. Il rung deve anche fallire in modo controllato.

Rung difensivi essenziali per l'handshaking IA-PLC

#### 1. Timer watchdog per la supervisione dell'heartbeat

Un timer watchdog verifica che l'IA o il sistema di calcolo a monte stia ancora comunicando entro un intervallo accettabile.

- Se il timer scade, il PLC:

• L'IA invia un bit di heartbeat o un valore incrementale
• Il PLC resetta un TON o un timer equivalente quando l'heartbeat cambia
• invalida la richiesta dell'IA,
• forza un default sicuro,
• solleva un guasto o un allarme,
• e impedisce ulteriori esecuzioni finché non vengono soddisfatte le condizioni di ripristino

Un servizio a monte morto non dovrebbe lasciare un percorso di uscita attivo dietro di sé. Questa non è intelligenza; è residuo.

#### 2. Blocco di limite per il clamping rigido

Un'istruzione di limite vincola i valori richiesti a una banda operativa fisicamente sicura.

Esempi di utilizzo:

• Clamp della velocità motore richiesta tra la velocità di raffreddamento minima e il massimo RPM sicuro
• Clamp della richiesta di una valvola a un intervallo che eviti shock idraulici
• Clamp di un setpoint di temperatura ai limiti di progettazione dell'attrezzatura

Esempio di struttura logica ladder:

- Istruzione: LIM (Test di limite) - Limite inferiore: 15.0 Hz - Test: `AI_Requested_Speed` - Limite superiore: 45.0 Hz - Uscita: `Safe_Speed_Permissive`

Il punto non è l'eleganza. Il punto è che nessun ottimismo a monte può comandare un fuorigiri.

#### 3. Limitazione della velocità di variazione (Rate-of-change)

Un limitatore di velocità di variazione impedisce bruschi cambiamenti di comando che sono tecnicamente validi in termini di grandezza ma non sicuri nella transizione.

Esempi:

• Impedire a una valvola di passare dal 10% al 100% in un unico aggiornamento
• Limitare gli aumenti di velocità del VFD a una rampa definita
• Limitare il movimento del setpoint per scansione o per secondo

Questo è importante perché molti guasti si verificano nella transizione, non nel punto finale. Il numero finale può essere legale mentre il percorso per arrivarci è sconsiderato.

#### 4. Rilevamento di obsolescenza e validità della sequenza

Un valore può essere numericamente plausibile e tuttavia operativamente non valido.

Il PLC dovrebbe verificare:

• freschezza del timestamp o conteggio di sequenza
• compatibilità della modalità macchina
• fase attuale dell'operazione
• stato dei permissivi prima di applicare la richiesta
• se la richiesta appartiene alla ricetta attiva, al passo del lotto o allo stato della sequenza

Un setpoint obsoleto durante la fase di sequenza sbagliata è solo una forma educata di dati errati.

Cosa significa "corretto" in questa architettura

La correttezza deve essere definita operativamente, non esteticamente. In questo contesto, una corretta integrazione IA-PLC significa:

• il PLC accetta solo richieste fresche e limitate,
• la macchina si muove solo quando i permissivi sono veri,
• le transizioni non sicure sono bloccate,
• la perdita di comunicazione produce uno stato di fallback definito,
• e ogni percorso di rifiuto è osservabile in tag, allarmi o logica di evento.

Questa definizione è più utile di "il rung è stato compilato". La compilazione è un'asticella bassa. I danni alle attrezzature la superano regolarmente.

Si valida l'handshaking IA-PLC simulando deliberatamente comportamenti anomali, dimostrando poi che la logica del PLC li rifiuta o li contiene. La validazione non consiste nel mostrare che il percorso ideale funziona. La validazione consiste nel mostrare che gli ingressi errati falliscono in modo sicuro e osservabile.

È qui che Simulation-Ready necessita di una definizione rigorosa. Un ingegnere Simulation-Ready è colui che sa dimostrare, osservare, diagnosticare e rafforzare la logica di controllo contro un comportamento di processo realistico prima che raggiunga un processo dal vivo. È uno standard più elevato rispetto alla conoscenza della sintassi ladder. È la differenza tra disegnare la logica e metterla in servizio.

Cosa dovrebbe essere testato prima dell'esposizione all'hardware

Come minimo, gli ingegneri dovrebbero testare:

• heartbeat perso dal servizio IA
• aggiornamenti ritardati e valori obsoleti
• setpoint fuori intervallo
• valori implausibili ma all'interno dell'intervallo
• richieste oscillanti rapide
• mancata corrispondenza di modalità tra richiesta IA e stato macchina
• timing errato della sequenza di avvio
• comportamento di fallback dopo il ripristino della comunicazione

Se questi casi non sono stati esercitati, l'architettura non è validata. È semplicemente speranzosa.

OLLA Lab è utile qui come ambiente di validazione limitato per provare il lato PLC del rischio di integrazione dell'IA. Non è un certificatore di sicurezza IA e non sostituisce l'accettazione formale del sito, la revisione dei pericoli o la valutazione della sicurezza funzionale. È un luogo dove esercitare le esatte attività di rafforzamento del controllo che sono troppo rischiose o troppo costose da improvvisare su attrezzature dal vivo.

Il vantaggio pratico è semplice: gli ingegneri possono iniettare comportamenti errati in modo sicuro e ripetibile.

Cosa permette OLLA Lab agli ingegneri di provare

Utilizzando l'editor di logica ladder basato su web, la modalità di simulazione e il pannello delle variabili, gli ingegneri possono:

• costruire una logica ladder che supervisiona un valore richiesto esterno,
• attivare ingressi e tag interni in tempo reale,
• osservare uscite e permissivi intermedi,
• testare timer, contatori, comparatori, matematica e comportamento correlato al PID,
• confrontare lo stato ladder con la risposta dell'attrezzatura simulata,
• e rivedere la logica dopo aver osservato un percorso di guasto.

Quel flusso di lavoro è importante perché i fallimenti dell'integrazione dell'IA si manifestano spesso come problemi di timing e di stato, non solo come numeri sbagliati. OLLA Lab dà a quei problemi un luogo dove diventare visibili.

Un flusso di lavoro di validazione pratico in OLLA Lab

Una sequenza di prova credibile appare così:

• Costruire una sequenza di rung che riceve un valore esterno di velocità, flusso o posizione richiesto
• Aggiungere permissivi, controlli di modalità e una condizione di esecuzione finale

• Inserire un timer watchdog
• Aggiungere un clamp usando la logica di limite
• Aggiungere un limitatore di velocità o una rampa a gradini
• Definire il comportamento di fallback in caso di timeout o dati non validi

• Usare il pannello delle variabili per forzare valori fuori intervallo
• Mettere in pausa o interrompere il segnale di heartbeat
• Introdurre bruschi cambiamenti di comando
• Cambiare lo stato del processo a metà comando

• Confermare che le uscite rimangano limitate
• Verificare che la logica di timeout scatti correttamente
• Controllare che allarmi o bit di guasto diventino visibili
• Confrontare il comportamento della macchina simulata con la filosofia di controllo attesa

• Regolare i valori del timer, i limiti e le condizioni di sequenza
• Rieseguire gli stessi guasti finché il percorso di rifiuto non è deterministico e leggibile

1. Creare il percorso di controllo
2. Aggiungere logica difensiva
3. Iniettare casi anomali
4. Osservare causa ed effetto
5. Revisionare e rieseguire

È qui che OLLA Lab diventa operativamente utile. Permette agli ingegneri di provare la logica di veto, non solo di ammirarla.

Dovresti produrre un corpo compatto di prove ingegneristiche che dimostri il ragionamento di controllo sotto guasto, non una galleria di screenshot dell'editor. Gli screenshot provano che uno schermo esisteva. Non provano che la logica abbia retto sotto stress.

Usa questa struttura:

Indica gli esatti criteri di accettazione: intervallo operativo consentito, intervallo di timeout, condizioni di permissività, stato di fallback e comportamento di allarme atteso.

Documenta la condizione anomala introdotta: heartbeat obsoleto, richiesta di fuorigiri, mancata corrispondenza di modalità, comando oscillante o timing di sequenza non valido.

Spiega cosa è cambiato nella logica: clamp aggiunto, intervallo watchdog modificato, interblocco inserito, limite di velocità di variazione aggiunto o gating di sequenza rivisto.

1. Descrizione del sistema Descrivi la macchina o la cella di processo, l'obiettivo di controllo, l'input fornito dall'IA e il ruolo di sicurezza o validazione di competenza del PLC.
2. Definizione operativa di "corretto"
3. Logica ladder e stato dell'attrezzatura simulata Mostra i rung, i tag e lo stato della macchina o del processo simulato che quei rung governano.
4. Il caso di guasto iniettato
5. La revisione effettuata
6. Lezioni apprese Indica cosa ha rivelato il fallimento sulla filosofia di controllo, sulle ipotesi della macchina o sul percorso di validità dei dati.

Quella struttura di prova è molto più persuasiva di una clip dimostrativa rifinita. Il rischio di messa in servizio risponde alle prove, non all'estetica.

L'IA appartiene a monte del controllo deterministico, non al suo posto. Il suo ruolo utile è generare valori consultivi o candidati da dati complessi che la logica convenzionale gestisce male.

Gli esempi includono:

• classificazione basata sulla visione
• rilevamento di anomalie
• stima della qualità
• punteggio di manutenzione predittiva
• raccomandazioni di ottimizzazione multivariabile
• suggerimenti di setpoint adattivi

Il PLC decide quindi se tali uscite sono ammissibili nel contesto attuale della macchina.

Una regola architettonica pulita

Una regola pratica è questa: l'IA può raccomandare; il PLC deve autorizzare.

Questa regola preserva i punti di forza di entrambi i livelli:

• L'IA gestisce l'ambiguità, il riconoscimento di pattern e l'ottimizzazione
• La logica PLC gestisce il timing, i permissivi, i limiti e l'esecuzione deterministica

Il risultato non è affascinante, il che è spesso un buon segno nei controlli. Una buona architettura di impianto di solito sembra leggermente noiosa fino a quando non previene un errore costoso.

L'errore più comune è consentire alle uscite dell'IA di bypassare la logica di validazione esplicita. Una volta che ciò accade, l'architettura ha già perso la sua disciplina dei confini.

Altri errori ricorrenti includono:

• trattare un timestamp di rete come equivalente alla freschezza deterministica
• presumere che i valori all'interno dell'intervallo siano automaticamente sicuri
• dimenticare la validazione dello stato di sequenza
• omettere il comportamento di fallback in caso di perdita di heartbeat
• consentire alle uscite consultive di diventare comandi diretti nel tempo
• testare solo il comportamento nominale e non le transizioni anomale
• confondere il successo del simulatore con la prontezza del sito

Quest'ultimo merita enfasi. La simulazione è un ambiente di validazione, non una dichiarazione di competenza sul campo. È dove gli ingegneri imparano a osservare, diagnosticare e rafforzare la logica prima dell'esposizione dal vivo. Utile, necessario e comunque non uguale a stare accanto a una linea in funzione alle 2:00 del mattino con la manutenzione in attesa.

Il modo sicuro per integrare l'IA nell'automazione industriale è separare la percezione dall'autorità. L'IA può classificare, stimare e raccomandare. Il PLC deve rimanere il nucleo hard real-time che valida, blocca, sequenzia e pone il veto.

Questa è l'architettura "Midollo Allungato" in una riga: l'IA pensa, il PLC mantiene in vita l'organismo.

Per gli ingegneri, il compito pratico non è celebrare le uscite dell'IA, ma rafforzare il percorso di controllo attorno ad esse. Watchdog, limiti, permissivi, controlli della velocità di variazione, rilevamento di dati obsoleti e fallback in stato sicuro non sono dettagli opzionali. Sono l'architettura.

E se questo suona meno futuristico delle presentazioni di marketing, bene. Le macchine generalmente preferiscono gli adulti.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standards family - exida functional safety and validation resources - NAMUR NE 107 status signaling recommendation - Digital twin in industry: state-of-the-art (DOI)