Immagina questa scena.
Sei il responsabile tecnico di uno stabilimento. Un impianto si ferma. Chiami il tuo tecnico interno. Apre il software di programmazione, guarda il codice PLC e ti dice una cosa che non vorresti mai sentire: “Non capisco cosa fa questo programma.”
Non perché il tecnico non sia bravo. Ma perché il codice è stato scritto quindici anni fa da un programmatore esterno che non lavora più con voi. Senza commenti. Senza documentazione. Con variabili che si chiamano Bit_07, Temp1, X_aux_3. Una struttura che solo chi l’ha scritta potrebbe, forse, decifrare.
Questa situazione ha un nome nel mondo del software: debito tecnico. Nell’automazione industriale è ancora più insidioso che nel software gestionale, perché qui il codice opaco non rallenta un processo amministrativo: ferma una linea produttiva.

Cos’e il debito tecnico nell’automazione industriale

Il termine “debito tecnico” nasce nello sviluppo software e descrive il costo futuro che si paga quando si scelgono soluzioni rapide e poco strutturate al posto di soluzioni corrette e manutenibili. Nell’automazione industriale il concetto si applica perfettamente, anche se raramente viene chiamato con questo nome.
Un programma PLC accumula debito tecnico quando è scritto senza seguire convenzioni di denominazione coerenti, manca di commenti che spieghino la logica delle sezioni critiche, non è strutturato in blocchi funzionali riutilizzabili e documentati, non esiste una documentazione esterna (specifiche funzionali, flow chart, manuale operatore) e le modifiche nel tempo sono state aggiunte sopra alla struttura originale senza un criterio.
Il risultato è un programma che funziona, finché funziona. Quando smette di farlo, o quando hai bisogno di modificarlo, il costo di quel debito diventa improvvisamente molto visibile.

Il problema della dipendenza dal programmatore originale

Uno degli effetti più concreti del debito tecnico nell’automazione è la dipendenza dal programmatore originale. Un impianto programmato senza standard è di fatto un impianto che appartiene, tecnicamente, a chi l’ha scritto.
Questa dipendenza ha conseguenze molto pratiche.
In caso di guasto, il tempo di diagnosi si allunga enormemente. Invece di identificare la causa guardando una logica comprensibile, il tecnico deve decodificare un sistema di riferimenti incomprensibili prima ancora di iniziare a cercare il problema.
In caso di modifica o ampliamento, il rischio di introdurre nuovi errori è alto. Senza capire come interagiscono le parti del programma, ogni intervento diventa una scommessa.
In caso di cambio fornitore, ci si trova a dover riscrivere tutto da zero, spesso senza nemmeno sapere esattamente cosa faceva il codice originale.
Non è una questione di cattiva fede da parte di chi ha programmato.  Ma per chi possiede l’impianto, questo significa avere un asset produttivo che non controlla davvero.

Lo standard esiste, ma non è obbligatorio applicarlo

Lo standard internazionale IEC 61131-3 definisce i linguaggi di programmazione per i controllori logici programmabili (PLC) e stabilisce un’architettura comune, con Ladder Diagram, Structured Text, Function Block Diagram, Sequential Function Chart e Instruction List, pensata proprio per rendere il codice più portabile e manutenibile.
Il problema è che lo standard non impone come deve essere strutturato e documentato il codice all’interno di quei linguaggi. Due programmi scritti in Structured Text possono essere ugualmente conformi allo IEC 61131-3 e avere livelli di leggibilità completamente diversi: uno con variabili descrittive, commenti sistematici e blocchi funzionali ordinati; l’altro con nomi criptici, nessun commento e una logica annegata in condizioni annidate.
Questo significa che la qualità del codice dipende quasi interamente dalla cultura e dalle linee guida interne di chi programma, non da un obbligo normativo.

Come riconosci se hai un problema di debito tecnico

Non serve aprire il software di programmazione per capire se stai accumulando debito tecnico. Ci sono segnali operativi che puoi osservare direttamente.
Il primo è il tecnico che ti dice “meglio non toccare quella parte“. Ogni impianto ha le sue zone proibite, sezioni di codice che nessuno vuole modificare perché nessuno capisce esattamente cosa fanno e cosa potrebbe andare storto.
Il secondo segnale sono i tempi di diagnosi che si allungano. Se un guasto che dovrebbe volerci un’ora a risolvere ne richiede sei, spesso il problema non è la complessità del guasto ma la complessità del codice da interpretare.
Il terzo segnale è l’impossibilità di formare un nuovo tecnico. Se l’unico modo per trasferire la conoscenza dell’impianto è affiancarlo per mesi al tecnico senior, senza documentazione di supporto, il codice è opaco per definizione.
Il quarto segnale sono le modifiche fatte e poi disfatte. Se interventi che sembravano corretti hanno generato problemi inaspettati in parti apparentemente non collegate, è probabile che la struttura del programma abbia interdipendenze non documentate.

Cosa si può fare: dalla diagnosi al risanamento

Affrontare il debito tecnico di un impianto richiede un approccio graduale. Non è quasi mai necessario, né conveniente, riscrivere tutto da capo.
Il primo passo é una valutazione tecnica del codice esistente: capire cosa fa il programma, identificare le sezioni critiche, ricostruire le specifiche funzionali anche in assenza di documentazione originale. E’ un lavoro di ingegneria inversa che richiede esperienza, ma che permette di ottenere una base affidabile da cui partire.
Il secondo passo è una ristrutturazione progressiva: non una riscrittura totale, ma una revisione che introduce standard di denominazione, commenti sistematici e una struttura modulare, senza stravolgere la logica di controllo che funziona.
Il terzo passo è la documentazione: specifiche funzionali aggiornate, flow chart delle sequenze principali, tracciabilità delle modifiche future. Non come burocrazia, ma come strumento di lavoro reale.
Il risultato non è un codice più bello. E’ un impianto che puoi manutenere, modificare e trasferire ad altri tecnici senza perdere mesi a decifrare cosa fa.

Il costo di non fare niente

C’è una tentazione comprensibile: finché l’impianto gira, perché investire tempo e risorse sul codice?
La risposta è che il debito tecnico ha un costo reale, anche quando non si manifesta in modo acuto. E’ il costo dei tempi di diagnosi più lunghi, degli interventi più rischiosi, della dipendenza da un singolo fornitore, dell’impossibilita di fare evoluzioni senza partire da zero.
E poi c’è il costo che si manifesta esattamente nel momento peggiore: quando l’impianto si ferma, quando il programmatore originale non è più disponibile, quando devi integrare quell’impianto con un sistema di supervisione o con l’ERP aziendale e scopri che il codice non lo permette.
Nelle fabbriche venete, dove l’automazione è spesso cresciuta per accrezioni successive, impianto dopo impianto, programmatore dopo programmatore, questo scenario è più comune di quanto si pensi. Non è colpa di nessuno. E’ il risultato di anni di scelte pragmatiche fatte in assenza di standard condivisi.
Riconoscerlo è già il primo passo per affrontarlo.

In Elteco lavoriamo sull’automazione industriale da oltre 40 anni. Se hai un impianto che “funziona ma nessuno capisce bene come”, parliamo: possiamo aiutarti a capire cosa hai davvero tra le mani.