Sono le tre di notte e la Pressa 2 è ferma. Sul pannello operatore lampeggia una riga: "Allarme 4.16 — mancato consenso idraulico". Il manutentore di turno conosce la macchina, ma non il programma: quel bit vive da qualche parte dentro migliaia di rung di logica ladder, scritti anni fa da un system integrator esterno. Le opzioni sono due: chiamare qualcuno a tariffa d'urgenza, o aprire Studio 5000 e mettersi a cercare. Intanto la linea non produce.
Questa scena si ripete identica in migliaia di stabilimenti. Il problema non è la mancanza di informazione — il programma PLC contiene esattamente la risposta — ma la sua inaccessibilità: la logica di un impianto è scritta in un linguaggio che in azienda leggono in pochi, spesso pochissimi, a volte nessuno.
Il programma PLC è documentazione, se qualcuno la legge
Un progetto Rockwell Studio 5000 (file .ACD o export .L5X) è una descrizione formale e completa del comportamento dell'impianto: tag, routine, timer, condizioni di allarme, sequenze di sblocco. A differenza dei manuali — che invecchiano — il programma è per definizione sempre aggiornato: è ciò che la macchina esegue davvero.
Il paradosso è che questa documentazione perfetta resta muta. La logica ladder non si "legge" come un testo: un allarme tipico è il risultato di un timer TON che scade, alimentato da una serie di contatti — alcuni negati (XIO), alcuni no (XIC) — che a loro volta dipendono da altri rung. Ricostruire la catena causale richiede di saltare tra routine, tenere a mente lo stato dei bit e applicare mentalmente le leggi di De Morgan quando la logica è negativa: un lavoro da specialista, lento anche per lo specialista.
Cosa serve perché un'AI la legga davvero
Dare un file L5X in pasto a un modello linguistico generico produce risposte plausibili e inaffidabili — l'ultima cosa che serve in manutenzione. Un approccio serio combina due ingredienti.
1. Un parser deterministico, non probabilistico
La struttura del progetto va estratta con un parser, non con il modello: enumerazione di programmi e routine, identificazione degli array di allarme, estrazione dei preset dei timer, interpretazione sintattica dei rung (serie AND, rami OR, istruzioni XIC/XIO/OTE/TON…). Su questa base deterministica si costruiscono analisi affidabili: per ogni bit di allarme, quale rung lo scrive, quali condizioni lo attivano, cosa deve accadere perché si resetti.
2. Il collegamento con ciò che l'operatore vede
Il manutentore non parte dal tag: parte dalla frase sul pannello. Se lo SCADA è Ignition, l'export dei tag contiene i testi di allarme che compaiono a video. Collegare ogni testo HMI al suo bit — e ogni bit al suo rung — chiude il cerchio: si può chiedere "perché è scattato 'mancato consenso idraulico'?" e arrivare alla logica che l'ha generato, passando per l'array di memoria giusto.
Il risultato è una diagnosi in tre atti, generata dal programma reale:
- Causa — la condizione che ha attivato il bit, con il timer e i segnali coinvolti già interpretati;
- Reset — cosa deve tornare vero (o falso) perché l'allarme rientri, incluso l'eventuale riarmo manuale;
- Conseguenze — cosa l'allarme blocca a valle: cicli, consensi, altre zone della linea.
A corredo, il cross-reference dei tag risponde alla domanda successiva del tecnico esperto: chi scrive questo tag? chi lo legge? — la mappa delle dipendenze che serve prima di toccare qualsiasi logica.
Perché on-premise non è un dettaglio
C'è una ragione pratica per cui questa analisi deve girare in stabilimento e non su un cloud: i programmi PLC sono tra gli asset più sensibili che un'azienda manifatturiera possiede. Contengono il know-how di processo — ricette, sequenze, parametri — che costituisce spesso il vero vantaggio competitivo. Caricarli su servizi esterni è, per molte aziende, semplicemente non negoziabile; per altre è vietato da contratti con i clienti finali.
C'è anche una ragione operativa: la rete di fabbrica è spesso segregata da Internet per progetto (e la normativa NIS2 spinge in quella direzione). Un sistema che ha bisogno del cloud per funzionare è un sistema che alle tre di notte, in reparto, non funziona.
Dal codice di allarme alla conversazione
Messi insieme — parser deterministico, testi HMI collegati, esecuzione locale — questi ingredienti cambiano la natura dell'interazione con l'impianto. La domanda non è più "chi sa leggere il programma della Pressa 2?" ma diventa una riga in chat: "allarme 4.16". La risposta arriva in secondi, con il rung responsabile citato e interpretato, le condizioni di reset e le conseguenze sull'impianto.
È l'approccio che abbiamo portato in IntelligenceBox con le cartelle di tipo PLC/SCADA: si caricano i progetti Studio 5000 e gli export tag Ignition, e la diagnosi degli allarmi, il cross-reference dei tag e l'esplorazione del progetto diventano strumenti di chat — sulla Box, dentro la rete di stabilimento, accanto a schemi elettrici, manuali macchina e log che già vivono nella stessa base di conoscenza.
Il know-how dell'impianto smette di dipendere dalla memoria di una persona sola. E la prossima volta che la Pressa 2 si ferma alle tre di notte, la risposta è già in reparto.
