Dentro il PLC di un impianto del 1998: variabili chiamate PROVA2_DEFINITIVO, commenti incomprensibili e logiche che nessuno sapeva spiegare

Ci hanno chiamato un martedì mattina.
Non per un guasto. L’impianto girava. Girava dal 1998, a dire il vero,  modificato e aggiornato nel tempo da persone capaci che conoscevano quella linea come le loro tasche. Il problema era un altro: vent’anni di interventi, aggiustamenti, ottimizzazioni — ognuno giusto nel momento in cui era stato fatto — avevano prodotto un impianto che funzionava benissimo, ma che era diventato difficile da leggere per chiunque non avesse vissuto quella storia dall’interno.
Il titolare ci ha detto una cosa semplice: “Voglio capire cosa c’è dentro, prima che diventi un problema.“
Era una delle richieste più intelligenti che ci fossero mai arrivate.

Come nasce un impianto illeggibile

Nessuno si sveglia la mattina e decide di scrivere codice incomprensibile. Succede in modo diverso, e molto più naturale.
Un impianto nasce con una logica chiara, scritta in un certo momento, per rispondere a certi requisiti. Poi la produzione cambia. Si aggiunge una linea, si modifica una ricetta, si integra un nuovo sensore. Qualcuno interviene in emergenza — perché in fabbrica le emergenze non aspettano — e aggiunge una patch rapida che funziona, e che resta lì. Qualcun altro, anni dopo, trova quella patch e lavora intorno senza capirla del tutto, perché chi l’aveva scritta non c’è più o non ricorda il contesto.
Vent’anni di questo processo producono un impianto che funziona — e che funziona bene, attenzione — ma che ha accumulato strati di storia che nessun documento racconta.
Il codice diventa una specie di archivio geologico: se sai leggere gli strati, capisci tutto. Se non li hai vissuti, inizi a fare ipotesi.

Quello che si trova, di solito

Aprire il progetto PLC di un impianto con questa storia alle spalle è sempre istruttivo.

Non nel senso didattico del termine, ma nel senso che ti insegna qualcosa di concreto su come quella fabbrica ha lavorato negli anni.

Variabili che raccontano una storia di tentativi, ad esempio PROVA2, PROVA2_OK, PROVA2_DEFINITIVO. Nomi che fotografano il momento in cui una soluzione è stata trovata, dopo diversi tentativi. Sono nomi perfettamente sensati per chi stava lavorando in quel momento, sotto pressione, con una linea ferma. Difficili però da decifrare per chi arriva dopo senza il contesto.

Commenti che non corrispondono più al codice. Quando un’istruzione viene modificata ma il commento che la descrive non viene aggiornato, nasce una contraddizione silenziosa. Non è negligenza: è la velocità con cui si lavora in fabbrica. Ma per chi legge dopo, un commento sbagliato è più disorientante di nessun commento.

Blocchi di codice disabilitati, lasciati al loro posto. Righe commentate fuori, che non vengono eseguite ma non vengono nemmeno cancellate. Erano un tentativo abbandonato? Una funzione stagionale sospesa? Una modifica temporanea mai rimossa? Non si sa. E rimuoverle senza capire cosa facessero è un rischio che nessun tecnico responsabile vuole correre.

Logiche che funzionano, ma che nessuno sa spiegare fino in fondo. Questo è il caso più delicato. Il codice gira, l’impianto produce, tutto bene. Ma dentro c’è una sequenza che compensa qualcosa — un comportamento specifico di quella linea, una caratteristica del materiale lavorato, un aggiustamento empirico nato dall’esperienza — e che non è mai stata documentata perché chi la conosceva la considerava ovvia.

Come si lavora in questi casi

Il nostro approccio: prima si capisce, poi si documenta, poi — solo se necessario — si interviene.
Non si riscrive tutto per il gusto di farlo. Un impianto che funziona da quasi trent’anni ha dimostrato di funzionare: il codice, per quanto stratificato, ha superato migliaia di ore di produzione reale. Il punto di partenza è il rispetto per quello che c’è, non la fretta di sostituirlo.
Il lavoro di comprensione è lento e non si può abbreviare. Si legge il codice, si osserva l’impianto in funzione, si confrontano le due cose. Si fanno domande a chi conosce quella linea — finché quella persona è ancora disponibile a rispondere. Si ricostruisce la storia degli interventi, se esistono tracce. Si costruisce una mappa di quello che esiste, prima di immaginare quello che potrebbe essere diverso.
La documentazione che ne esce non è solo un documento tecnico. È la memoria dell’impianto, finalmente in un posto accessibile — non più distribuita tra la testa di tre persone diverse che lavorano in turni diversi.
[→ Sul tema di come scriviamo il codice nei nostri interventi — leggibile, commentato, strutturato — ne parliamo qui: “Come programmiamo in Elteco“]

La domanda che vale la pena farsi oggi

Il titolare che ci ha chiamato quel martedì aveva capito qualcosa che molte aziende capiscono solo dopo un fermo macchina lungo e costoso: la conoscenza di un impianto è un asset aziendale. Non una questione tecnica da delegare. Ha un valore economico preciso — e può diventare un problema in un giorno, se è distribuita in modo fragile.
Non servono necessariamente interventi strutturali. A volte basta un’analisi, una sessione di documentazione, una mappa di quello che esiste. Il costo è contenuto. Il valore, nel momento in cui serve, è molto più alto.
[→ Se oltre al codice il problema riguarda anche l’hardware — componenti fuori produzione, ricambi introvabili — il ragionamento da fare è diverso: “Sostituire un componente obsoleto o rifare tutto?“][→ Se il tuo impianto manda già segnali di cedimento, prima ancora di aprire il codice: “Fermo macchina imprevisto? 5 segnali che il tuo PLC sta per cedere“]

Quello che abbiamo imparato

Quel titolare ci ha ribadito qualcosa che portiamo in ogni intervento: il momento giusto per capire cosa c’è dentro un impianto non è quando si ferma. È adesso, mentre gira, mentre chi lo conosce è ancora in azienda e può rispondere alle domande.
Un impianto fermo con un codice illeggibile è un problema tecnico. Un impianto fermo con un codice documentato è un problema risolvibile. La differenza tra i due, spesso, si gioca molto prima del guasto.