Bastava un aggiornamento. Come tre giorni di fermo linea hanno insegnato a una fabbrica chi decide cosa si tocca — e chi no

Il lunedì mattina la linea non è partita.
Nessun allarme il venerdì sera. Nessun guasto visibile nel weekend. L’operatore del primo turno ha provato a riavviare, ha guardato il pannello, ha chiamato il responsabile. Il responsabile ha guardato il pannello, ha chiamato noi.
Quando siamo arrivati, il sistema era integro. Nessun componente rotto, nessun corto circuito, nessuna anomalia hardware. Il problema era più sottile — e per questo più difficile da trovare.
Nel weekend era stato fatto un aggiornamento. Qualcuno, in buona fede, aveva toccato qualcosa. E quel qualcosa aveva rotto un equilibrio che nessuno sapeva di stare mantenendo.

Due fabbriche, stesso lunedì mattina

Nel corso degli anni abbiamo visto questa scena ripetersi in modi diversi. Le cause cambiano, il risultato no. Ve ne raccontiamo due — perché sono le più comuni, e perché insieme raccontano un problema che va oltre il caso specifico.
Il reparto IT ha aggiornato Windows.
In uno stabilimento del vicentino, il software SCADA girava su un PC di produzione. Un PC come tanti, collegato alla rete aziendale, gestito dal reparto IT insieme a tutti gli altri computer dell’ufficio.
Il venerdì sera, con la fabbrica ferma per il weekend, il reparto IT aveva applicato gli aggiornamenti di Windows. Procedura normale, fatta ogni settimana su tutti i computer aziendali. Nessuno aveva pensato di escludere quel PC — perché nessuno aveva mai detto esplicitamente che quel PC non era un PC come gli altri.
Il lunedì mattina il software di supervisione non riusciva più a comunicare con il campo. Un aggiornamento del sistema operativo aveva modificato il comportamento di un driver di comunicazione. Il driver funzionava — tecnicamente. Ma non parlava più la stessa lingua del PLC.
“No gavevo toccà gnente” — non avevo toccato niente — ci ha detto il responsabile di produzione. Aveva ragione. Non era stato lui.
Tre giorni per isolare il problema, ripristinare la versione precedente del driver, verificare che tutto il resto fosse ancora allineato.
Il tecnico ha aggiornato un gateway IoT.
In un altro caso, il protagonista era un gateway di connettività — uno di quei dispositivi che raccolgono dati dal campo e li trasmettono al sistema di supervisione. Componente moderno, installato nell’ambito di un progetto Industria 4.0, con firmware aggiornabile da remoto.
Un tecnico interno aveva ricevuto una notifica di aggiornamento disponibile. Aveva pensato, ragionevolmente, che tenere il firmware aggiornato fosse una buona pratica. Aveva cliccato. Il gateway si era aggiornato correttamente.
Solo che la nuova versione del firmware aveva cambiato il formato dei dati in uscita. Non in modo drammatico — qualche campo rinominato, qualche struttura leggermente diversa. Abbastanza però da far sì che il sistema SCADA a valle ricevesse dati che non riusciva più a interpretare correttamente.
La linea girava. I dati arrivavano. Ma i valori sul monitor erano sbagliati — e nessuno se ne era accorto subito, perché i numeri erano plausibili. Il problema è emerso due giorni dopo, quando la qualità del prodotto ha iniziato a calare.

Il problema vero non è tecnico

Questi due casi sembrano diversi. Uno riguarda l’IT, l’altro un componente di campo. Uno è stato fatto da qualcuno esterno alla produzione, l’altro da un tecnico interno. Ma il problema sottostante è identico: in fabbrica, nessuno aveva mai deciso formalmente chi può aggiornare cosa — e quando.
Non è una critica. È la normalità in molte PMI del Nord-Est: finché tutto funziona, certe domande non vengono poste. La governance degli aggiornamenti software è un tema che nelle grandi aziende ha procedure dedicate, reparti specifici, audit periodici. Nelle fabbriche di medie dimensioni, spesso, non esiste nemmeno come concetto.
Il risultato è che le decisioni vengono prese per inerzia — si aggiorna perché c’è la notifica, si applica la patch perché “è meglio tenerlo aggiornato”, si fa nel weekend perché “tanto la fabbrica è ferma”. Tutte scelte ragionevoli, prese senza le informazioni necessarie per valutarne le conseguenze.

Le tre cose che mancano, di solito

Dopo anni di interventi su impianti di questo tipo, abbiamo imparato a riconoscere cosa manca quando questi problemi si presentano. Non sono mancanze gravi — sono semplicemente cose che nessuno aveva mai pensato di definire.
Un registro delle versioni installate.
Su ogni componente critico dell’impianto — PC con software SCADA, gateway IoT, driver di comunicazione, middleware OPC — dovrebbe esistere una lista aggiornata delle versioni software e firmware in uso. Non un documento complesso: anche un foglio condiviso va benissimo. L’importante è che prima di aggiornare qualcosa, ci sia un riferimento chiaro a cosa c’era prima e a cosa dipende da quel componente.
Una distinzione tra rete IT e rete OT.
Il PC che fa girare il software SCADA non è un PC come gli altri. Non dovrebbe ricevere aggiornamenti automatici, non dovrebbe essere gestito con le stesse procedure degli altri computer aziendali, non dovrebbe essere accessibile dalla stessa rete. Questa separazione — tra la rete informatica dell’ufficio e la rete operativa della produzione — è uno dei principi base della cybersecurity industriale, ma ha conseguenze molto concrete anche sulla stabilità degli impianti.
[→ Sul tema della separazione IT/OT e della sicurezza degli impianti: “Messa in sicurezza“]Una procedura minima di change management.
Non serve un sistema complesso. Serve una regola semplice e condivisa: prima di toccare qualsiasi componente software o firmware su un impianto produttivo, si verifica cosa c’è a valle, si fa in un momento in cui il ripristino è possibile, e si tiene traccia di cosa è stato modificato. Tre passi. Applicati con costanza, evitano la maggior parte dei problemi che abbiamo descritto.
[→ Sul tema di come documentiamo e tracciamo ogni intervento sui sistemi che seguiamo: Come programmiamo in Elteco]

Come si gestisce in pratica

La buona notizia è che le contromisure non richiedono investimenti grandi. Richiedono metodo.
Il primo passo è un inventario: quali componenti software e firmware sono installati sull’impianto, in quale versione, e quali dipendenze esistono tra loro. Questo lavoro, fatto una volta, diventa la base per tutte le decisioni successive.
Il secondo passo è definire — e comunicare — quali componenti non devono essere aggiornati senza una valutazione preventiva. Il reparto IT deve sapere che quel PC è fuori dal perimetro degli aggiornamenti automatici. Il tecnico di manutenzione deve sapere che prima di cliccare su “aggiorna” su un gateway di campo, c’è una verifica da fare.
Il terzo passo è costruire una procedura di test minima: dopo qualsiasi modifica software o firmware, prima di rimettere in produzione, si verifica che la comunicazione tra i componenti funzioni correttamente. Non un collaudo completo — bastano dieci minuti con le persone giuste.
[→ Se il tuo impianto manda già segnali di cedimento e vuoi capire cosa fare prima del prossimo fermo: Fermo macchina imprevisto? 5 segnali che il tuo PLC sta per cedere]

Quello che abbiamo imparato

In entrambi i casi che abbiamo raccontato, il problema si è risolto. Non facilmente, non velocemente — ma si è risolto. La cosa che è rimasta, in entrambe le fabbriche, è una consapevolezza nuova: che un impianto industriale moderno non è solo hardware. È un sistema di software, firmware e dipendenze che va gestito con le stesse attenzioni che si riservano ai componenti fisici.
Un cuscinetto usurato si vede. Una versione firmware incompatibile no — finché non è troppo tardi.
Sai quale versione software gira su ogni componente critico del tuo impianto in Veneto? E sai cosa succederebbe se qualcuno lo aggiornasse stasera, mentre la fabbrica è ferma?
Se la risposta è no — o anche solo “non sono sicuro” — è il momento giusto per fare un inventario. Prima del prossimo lunedì mattina.