Lucio Patone
frontiera

Un world model per una valvola vera: guasti rilevati in cinque secondi senza averne mai visto uno

Nella parte precedente il banco era una mini-centrale termica simulata: comoda, controllabile, ma pur sempre un modello del mondo e non il mondo. La domanda vera restava aperta: la ricetta regge su dati veri? In questa nota la risposta. Abbiamo preso uno dei benchmark classici del fault detection industriale — la telemetria di una valvola pneumatica di uno zuccherificio polacco, registrata nel 2001 — e applicato la stessa procedura, quasi senza ritocchi. Il verdetto in anticipo: sui guasti che il cruscotto rende visibili, il modello li rileva entro cinque secondi dall'inizio, senza averne mai visto uno in training.

Il banco: una valvola vera

Il benchmark si chiama DAMADICS ed è nato per confrontare i metodi di diagnosi su attuatori industriali. I dati sono telemetria vera: tre valvole pneumatiche dello zuccherificio di Lublino, osservate per 25 giorni nel novembre 2001, un campione al secondo per grandezza. Per la valvola di portata che abbiamo scelto (sigla FC57_03) fanno oltre due milioni di campioni per ciascuna delle sei grandezze: comando del regolatore, posizione dello stelo, portata, pressione a monte e a valle, temperatura.

Nel mezzo della conduzione normale, il benchmark documenta 19 episodi di guasto di quattro tipi: caduta dell'alimentazione d'aria, salto di pressione a monte, bypass aperto, sensore di portata guasto. Sono guasti brevi — da quattordici secondi a qualche minuto — iniettati di proposito dagli autori, con inizio e fine certificati al secondo. Per noi sono oro: una verità terreno su cui misurare rilevazioni e ritardi, che nella simulazione dovevamo costruirci a mano.

Dalla telemetria al cruscotto

LeWorldModel parla per immagini; una valvola parla in serie temporali. Il ponte è rendere la telemetria un'immagine: ogni blocco di cinque secondi diventa un quadro strumenti 224×224 — due strumenti a lancetta per la posizione dello stelo e la portata, barre orizzontali per il comando del regolatore e le due pressioni, un indicatore sottile per la temperatura. L'azione che il modello riceve a ogni passo sono i cinque valori del comando del regolatore nel blocco. Vincolo d'onestà: nel cruscotto entrano solo grandezze che i sensori misurano davvero; le etichette di guasto restano fuori, nei metadati usati solo in valutazione.

Sedici cruscotti della valvola in momenti diversi: funzionamento normale e dentro i guasti, più una striscia di otto blocchi attorno a un inizio guasto
La valvola come la vede il modello: sopra, blocchi di funzionamento normale e dentro i guasti etichettati; sotto, otto blocchi consecutivi attorno all'inizio di un guasto al sensore di portata.

Il training: solo il funzionamento normale

Dai 25 giorni abbiamo tenuto solo i periodi sani: 81 episodi di conduzione normale, 423.567 blocchi da cinque secondi. Training da zero con la ricetta immutata, otto epoche su una GPU a noleggio, fermato quando la loss si è assestata. Di guasti, ancora una volta, il modello non ha visto l'ombra: ha imparato soltanto a prevedere il prossimo blocco di telemetria data la storia recente e ciò che il regolatore sta facendo.

81 episodi di solo funzionamento normale · 423.567 blocchi da 5 s · 15M parametri · 8 epoche su una GPU · ~2 $

I numeri

La valutazione mette di fronte le sei finestre registrate attorno ai guasti della valvola — cinque minuti prima e cinque dopo l'inizio certificato — e trenta finestre di controllo pescate nei periodi sani. La soglia d'allarme è la regola di sempre: media più tre deviazioni standard degli errori su funzionamento normale.

Sul guasto al sensore di portata la risposta è netta: AUC 1,000, tre finestre su tre rilevate, e la sorpresa supera la soglia già al primo blocco dopo l'inizio — cinque secondi. L'errore schizza a cento volte la baseline e rientra in una ventina di blocchi, seguendo la durata reale del guasto. Sul salto di pressione, il guasto più corto (quattordici-ventidue secondi), due finestre su tre: quella mancata è la più breve di tutte e sul cruscotto lascia una firma troppo debole — l'errore resta sotto metà della soglia. Va detto con onestà: la letteratura ventennale su questo benchmark lavora con metodi dedicati, supervisionati o statistici, allenati anche sugli esempi di guasto; il nostro modello ne ha visti zero, e cinque finestre su sei le riconosce subito.

Curve di sorpresa attorno all'inizio del guasto: il controllo resta piatto sotto la soglia, le finestre di guasto si impennano esattamente al blocco zero
Errore di predizione attorno all'inizio del guasto (blocco 0; un blocco = 5 secondi). Il controllo fault-free resta piatto sotto la soglia tratteggiata; le finestre di guasto si impennano al blocco zero e rientrano seguendo la durata reale del guasto.

La demo: il nodo sensore in diretta

Il modo migliore per giudicare è guardarlo lavorare. La demo interattiva riproduce due ore vere del 17 novembre 2001 — quelle con cinque guasti — come un flusso live: il cruscotto che il modello vede (i frame originali, non una ricostruzione), la curva dello stupore con la soglia, l'allarme che scatta. A velocità reale dura due ore come la realtà; a 240× si guarda in trenta secondi. È la prova generale di ciò che farebbe un nodo sensore attaccato alla valvola: niente cloud, niente etichette, solo il modello che si stupisce.

luciopatone.it/demo/nodo-sensore/ · 2 ore del 17/11/2001 · 5 guasti veri · da tempo reale a 240×

Cosa manca

Tre limiti dichiarati. Primo: un solo attuatore su tre e due tipi di guasto su quattro in valutazione — le altre valvole e gli altri guasti aspettano il loro training. Secondo: il salto di pressione breve resta il punto debole; la strada per rafforzarlo passa da una grana temporale più fine o da strumenti più sensibili alla pressione. Terzo: il conto che decide tutto, cioè quanto hardware serve per far girare il modello attaccato alla valvola, è per ora un conto di massima — tre millisecondi a blocco su GPU, una cinquantina su CPU da laptop, contro i cinque secondi del blocco — e va misurato su hardware vincolato vero. È il prossimo esperimento del filone.

La direzione però è quella giusta: la stessa ricetta che funzionava nella centrale simulata regge sulla telemetria vera, con numeri che un manutentore può usare. Un world model piccolo, allenato solo sul funzionamento normale, può stare attaccato a un componente e fare la guardia. Resta da misurare quanto piccolo può diventare l'hardware che lo ospita.

Note e riferimenti

Questa è la quarta parte di una serie: la teoria, la verifica del modello altrui, l'impianto simulato nelle parti precedenti. Il modello è LeWorldModel (Maes et al., 2026), fondato su LeJEPA (Balestriero & LeCun, 2025); training con il codice pubblico le-wm su stable-worldmodel. I dati sono il benchmark DAMADICS (Bartyś & Syfert, «DAMADICS Benchmark Definition», 2002), registrati allo zuccherificio di Lublino.

Note di metodo: blocco da 5 secondi (5 campioni a 1 Hz); il frame è il cruscotto delle medie di blocco; azione = i 5 valori del comando del regolatore, standardizzati sul training set; sorpresa = errore quadratico tra il latente predetto (storia di 3 blocchi + azioni) e il latente del frame reale successivo; soglia = media + 3σ su 30 finestre di controllo fault-free, stimata sui blocchi a regime; latenza = primo blocco dopo l'inizio del guasto con errore sopra soglia, in blocchi da 5 secondi; loss di validazione a fine training 0,024, in plateau da tre epoche.