PLC longevi, codice fragile: come scrivere programmi macchina che durano quanto l’hardware

Un PLC ben mantenuto resta in servizio 15-20 anni, a volte di più. È uno dei motivi per cui interi settori si affidano a questi controllori per l’automazione mission-critical: l’hardware è pensato per durare una generazione industriale intera.

Il codice che ci gira sopra, quasi mai.

Non è un paradosso tecnico, è un problema di metodo.
Il ladder logic — ancora oggi il linguaggio più diffuso per la programmazione PLC — nasce come trasposizione diretta degli schemi elettrici a relè: è leggibile, è familiare a chi ha una formazione elettrotecnica, e proprio per questo resta la scelta di default anche quando il progetto meriterebbe un approccio più strutturato. Ne avevamo già parlato tempo fa confrontando KOP e AWL su PLC Siemens: task semplici in KOP, task con calcoli complessi in AWL — un principio che vale, più in generale, per qualsiasi scelta di linguaggio PLC. Il problema nasce quando questa scelta non viene fatta consapevolmente, ma per abitudine.

Il risultato, nel tempo, è spesso lo stesso: rung duplicati, logica copiata da una macchina all’altra con piccole varianti mai documentate, valori scritti a mano invece che parametrizzati.

Funziona, finché il tecnico che l’ha scritto è ancora in azienda. Il problema si presenta quando quel tecnico va in pensione, cambia lavoro, o semplicemente non si ricorda perché tre anni prima ha inserito un salto logico apparentemente inutile in un angolo del programma.

Lo standard IEC 61131-3 — quello che definisce i cinque linguaggi di programmazione PLC riconosciuti a livello internazionale (Ladder Diagram, Function Block Diagram, Structured Text, Instruction List, Sequential Function Chart) — esiste anche per questo: rendere il codice trasferibile, non solo tra piattaforme hardware diverse, ma tra persone diverse.

Un aspetto spesso frainteso è che la conformità allo standard non garantisce da sola la portabilità: i produttori aggiungono istruzioni ed estensioni proprietarie, e non tutti i PLC “conformi” supportano tutti e cinque i linguaggi. La vera differenza la fa come il codice viene scritto, non solo in quale linguaggio.

Tre pratiche concrete aiutano a scrivere codice macchina che sopravvive al collega che lo ha scritto:

Blocchi funzione riutilizzabili, non copia-incolla. Ogni volta che una logica viene duplicata da una macchina all’altra invece di essere incapsulata in un blocco funzione riutilizzabile, si crea un problema di manutenzione futuro: una modifica va replicata manualmente ovunque, con il rischio concreto di dimenticarne una copia.

Parametri centralizzati, non valori nascosti nel codice. Un valore di soglia scritto a mano in dieci punti diversi del programma è una bomba a orologeria: quando va cambiato, qualcuno lo troverà solo dopo che la macchina si sarà fermata per un motivo apparentemente incomprensibile.

Il linguaggio giusto per il compito giusto, non uno solo per abitudine. Ladder per l’interfacciamento I/O e la logica di interblocco, dove la lettura rapida in campo conta più di tutto; Structured Text (o AWL, per chi lavora su piattaforme Siemens più datate) per i calcoli; Sequential Function Chart per governare cicli macchina e processi batch complessi. Un programmatore che padroneggia un solo linguaggio è, di fatto, un meccanico con una sola chiave in tasca.

Nessuna di queste pratiche richiede un cambio di piattaforma o un investimento straordinario.

Richiede disciplina, e — spesso — qualcuno che guardi il codice esistente con occhi esterni prima che il problema si manifesti come fermo macchina.