Da almeno tre decenni i sistemi SCADA (Supervisory Control and Data Acquisition) rappresentano la spina dorsale del controllo industriale. Raccolgono dati da PLC, sensori e attuatori, li centralizzano in HMI, attivano allarmi su soglie predefinite. Il modello, però, mostra i suoi limiti: in un impianto manifatturiero moderno la mole di dati generata da migliaia di tag a frequenza sub-secondo rende la logica a soglia statica inadeguata. È in questo spazio che l’intelligenza artificiale sta ridefinendo la supervisione industriale, ma come strato architetturale.
In questo contesto, FactorySoftware è un distributore ufficiale di AVEVA. L’azienda distribuisce le soluzioni industriali AVEVA in Italia e in diversi Paesi europei, supportando le imprese nella digitalizzazione e nell’ottimizzazione dei processi produttivi attraverso strumenti avanzati di supervisione e controllo.
Dal threshold-based all’anomaly detection statistico
Il salto concettuale è netto. Un allarme tradizionale si attiva quando una variabile supera un limite fissato a priori da un ingegnere di processo. Funziona per guasti netti, fallisce sulle derive lente, sulle correlazioni multivariate e sulle anomalie contestuali, quando un valore “normale” diventa anomalo solo in relazione ad altre variabili o a un determinato regime operativo.
Le tecniche di anomaly detection applicate ai dati SCADA spostano la logica dal “fuori soglia” al “fuori distribuzione”. Tre famiglie dominano oggi i deployment industriali:
- Modelli statistici multivariati (PCA, Mahalanobis distance) per il monitoraggio di processi continui. Computazionalmente leggeri, interpretabili, adatti all’edge.
- Modelli unsupervised (Isolation Forest, One-Class SVM, Autoencoder) per impianti dove i dati di guasto sono rari o assenti, la norma in industria, dove un guasto critico è un evento da settimane o mesi.
- Modelli sequenziali (LSTM, Transformer applicati a time-series) per individuare degradazioni progressive su cuscinetti, valvole, scambiatori termici.
La scelta non è teorica: dipende dalla qualità del data historian, dalla disponibilità di label storici, dal regime operativo (batch vs. continuous), dal vincolo di latenza tra rilevazione e azione.
Il vero collo di bottiglia: la data pipeline, non l’algoritmo
Un errore frequente nei progetti AI+SCADA è concentrarsi sul modello e trascurare la pipeline. L’esperienza dei deployment in ambito process industry mostra che il valore si gioca a monte: standardizzazione semantica dei tag, integrazione OPC UA (IEC 62541) con le sue companion specifications, sincronizzazione temporale rigorosa tra storian e modello, gestione dei dati mancanti senza introdurre bias.
OPC UA è qui un abilitatore decisivo.
La sua information model permette di esporre non solo i valori, ma anche la semantica degli asset, un’esigenza che modelli ML “ignoranti del processo” non possono soddisfare. Le companion specifications (PackML, Robotics, Machine Tool) forniscono ontologie che riducono drasticamente il lavoro di feature engineering.
Sul fronte computazionale, la separazione tra training (in cloud o on-premise data lake) e inference (sempre più all’edge, su gateway industriali o controller con capacità ML come i nuovi PLC con runtime TensorFlow Lite) è ormai lo schema dominante. Riduce la latenza, contiene la banda, e riduce la superficie d’attacco.
Manutenzione predittiva: il caso d’uso che paga il progetto
Tra tutti gli scenari, la manutenzione predittiva resta quello con il ROI più documentato. Studi del Department of Energy USA e del Fraunhofer IPA convergono su ordini di grandezza ricorrenti: riduzione dei fermi non pianificati nell’ordine del 30-50% sui casi maturi, estensione della vita utile degli asset critici, calo dei costi di manutenzione tra il 10 e il 25% rispetto a regimi puramente preventivi calendarizzati.
Il calcolo del business case, però, raramente è banale. Richiede di confrontare il costo dell’iniziativa, dati, sviluppo, MLOps, integrazione con l’infrastruttura esistente, con il costo evitato dei fermi: un calcolo che dipende fortemente dal contesto operativo. Per le organizzazioni che valutano un primo deployment, utilizzare un sistema SCADA già maturo come piattaforma di partenza riduce sensibilmente il time-to-value, perché lo strato di acquisizione, storicizzazione e contestualizzazione del dato è già consolidato e validato sul campo. Una linea di confezionamento alimentare con MTTR di 40 minuti non ha comunque la stessa economia di una turbina di cogenerazione il cui fermo si misura in giorni e milioni di euro.
La dimensione cyber: l’IA allarga la superficie d’attacco
Punto sistematicamente sottovalutato. Integrare modelli ML nella supervisione significa introdurre nuovi vettori: dataset di training potenzialmente avvelenabili (data poisoning), inference engine esposti, flussi bidirezionali tra OT e IT che la segmentazione classica Purdue non prevedeva.
Il quadro normativo si è irrigidito. La direttiva NIS2, recepita in Italia dal D.lgs. 138/2024, estende gli obblighi di cybersecurity a un perimetro molto più ampio di operatori industriali. Lo standard IEC 62443, in particolare le parti 3-3 (system security requirements) e 4-2 (component requirements), diventa il riferimento operativo. ENISA, nei suoi report sulle minacce al settore manifatturiero, ha esplicitamente segnalato i sistemi di AI integrati come categoria di asset da inventariare e proteggere.
Pratica conseguente: qualunque progetto AI+SCADA serio prevede oggi una threat model dedicata al modello stesso, hardening dell’inference layer, monitoring degli input per individuare adversarial attacks, gestione del ciclo di vita dei modelli con la stessa disciplina applicata al firmware degli asset.
