Strutturare il codice PLC secondo IEC 61131-3: la guida definitiva contro il codice spaghetti

Aprire il progetto di un PLC e trovarsi di fronte a un blocco di codice monolitico, senza commenti, con variabili dai nomi incomprensibili è un’esperienza che ogni programmatore di automazione ha vissuto. È il famigerato “codice spaghetti”, un groviglio che rende la manutenzione un incubo, il debugging una caccia al tesoro e ogni modifica un rischio potenziale per la produzione e la sicurezza. Molti si limitano a consigliare di “aggiungere commenti” o “usare nomi di variabili significativi”. Questi sono consigli validi, ma superficiali. Non risolvono il problema alla radice.

La verità è che il codice spaghetti non è un difetto di forma, ma il sintomo di una malattia più profonda: la mancanza di un’architettura software. La norma IEC 61131-3 non è solo un elenco di linguaggi di programmazione, ma una filosofia di progettazione che, se applicata con rigore, fornisce l’antidoto definitivo a questo caos. La chiave non è scrivere codice, ma progettare sistemi. Si tratta di passare da una mentalità reattiva, dove si tamponano i problemi, a una proattiva, dove si costruisce per la manutenibilità, la scalabilità e la sicurezza fin dal primo giorno.

Questo non è un manuale teorico. È un approccio pragmatico, da ingegnere a ingegnere, per smettere di essere vittime del debito tecnico e iniziare a costruire asset software industriali che funzionino oggi e siano pronti per le sfide di domani. Esploreremo come la separazione delle responsabilità, la modularità e l’integrazione intelligente di tecnologie come HMI, VPN e retrofitting non siano argomenti distinti, ma pilastri interconnessi di un’unica, solida architettura difensiva.

Safety PLC: come separare la logica di sicurezza da quella di processo per evitare incidenti?

La prima regola di un’architettura software robusta è la separazione delle responsabilità. Nel mondo dell’automazione, questo principio assume un’importanza vitale quando si parla di sicurezza. Mescolare la logica di safety (es. arresti di emergenza, barriere ottiche, controllo porte) con la logica di processo (es. sequenze, movimentazioni, regolazioni) all’interno dello stesso programma è una delle pratiche più pericolose e miopi. Un bug nella logica di processo, un errore di calcolo o una modifica apparentemente innocua possono inibire o bypassare una funzione di sicurezza critica, con conseguenze catastrofiche.

L’approccio corretto prevede una separazione netta, sia a livello hardware che software. Il Safety PLC deve essere un’entità sovrana, con il proprio programma dedicato, la cui unica missione è garantire la sicurezza delle persone e dell’impianto. Questo programma deve essere semplice, testato rigorosamente e modificato solo a seguito di un’analisi dei rischi formale. La logica di processo può e deve interagire con la logica di safety, ma solo attraverso un’interfaccia ben definita e gerarchicamente subordinata. Il PLC di processo può “chiedere” al PLC di safety di fermare la macchina, ma non può mai, in nessun caso, impedirgli di farlo.

Questa separazione non è solo una buona pratica, ma un pilastro della difesa contro minacce interne ed esterne. In un contesto dove in Italia sono stati registrati 1.637 incidenti cyber nel solo primo semestre 2024, la convergenza tra Safety e Security diventa cruciale. Come sottolinea il Prof. Roberto Mugavero, implementare architetture separate è fondamentale per prevenire incidenti, sia che la causa sia un errore umano, un guasto o un attacco informatico mirato. Un’architettura segregata garantisce che anche se la rete di processo viene compromessa, il sistema di sicurezza rimanga un baluardo isolato e funzionante.

L’errore di riempire lo schermo di pulsanti: come disegnare pannelli HMI che riducono gli errori umani?

Un pannello operatore (HMI) sovraccarico di informazioni, con decine di pulsanti, indicatori lampeggianti e grafici incomprensibili, è l’equivalente visivo del codice spaghetti. Non è solo brutto da vedere, è pericoloso. Un’interfaccia utente mal progettata aumenta il carico cognitivo dell’operatore, rallenta i tempi di reazione e, nei casi peggiori, induce all’errore. Come afferma un articolo di Fare Elettronica, “Per minimizzare gli errori operativi e non spingere gli operatori a sfogarsi sul dispositivo, è necessario che l’interfaccia utente (UI) degli HMI venga progettata in modo efficace”.

La soluzione, ispirata dallo standard ISA-101, è il design ad alte prestazioni (High-Performance HMI). Il principio è semplice: “less is more”. Invece di mostrare tutto sempre, l’interfaccia deve presentare solo le informazioni necessarie per la situazione corrente, in modo chiaro e inequivocabile. Questo significa abbandonare i colori sgargianti per un fondo grigio neutro, usando il colore solo per evidenziare le anomalie. Significa raggruppare le informazioni in modo logico e gerarchico, permettendo all’operatore di navigare dal quadro generale al dettaglio con pochi tocchi intuitivi.

Progettare un HMI efficace significa pensare come un controllore del traffico aereo: l’obiettivo non è decorare, ma fornire la massima consapevolezza situazionale con il minimo sforzo. Questo implica la separazione delle performance: il PLC deve gestire il controllo in tempo reale, mentre l’HMI si concentra sulla visualizzazione. L’interfaccia deve essere uno strumento che guida l’operatore alla decisione giusta, non un ostacolo da superare. Un buon HMI non si nota, semplicemente funziona, riducendo stress ed errori.

Per minimizzare gli errori operativi e non spingere gli operatori a sfogarsi sul dispositivo, è necessario che l’interfaccia utente (UI) degli HMI venga progettata in modo efficace

– Fare Elettronica, Articolo sugli HMI per l’Automazione Industriale 4.0

VPN industriale: come permettere ai tecnici di collegarsi alla macchina dall’ufficio senza aprire falle agli hacker?

L’accesso remoto ai PLC per la manutenzione e la diagnostica non è più un lusso, ma una necessità operativa. Tuttavia, aprire una porta di comunicazione verso un impianto industriale è come lasciare una finestra aperta in una banca. Senza le giuste precauzioni, si trasforma un vantaggio di efficienza in un’enorme vulnerabilità di sicurezza. In un paese dove il Rapporto Clusit 2024 evidenzia un +65% di incidenti rilevati rispetto all’anno precedente, l’approccio “basta che funzioni” non è più accettabile.

L’uso di una VPN (Virtual Private Network) è il requisito minimo, ma non tutte le VPN sono uguali e la sola VPN non basta. Una VPN industriale deve offrire funzionalità specifiche come l’autenticazione a più fattori, la gestione granulare degli accessi (l’utente A può solo visualizzare, l’utente B può modificare solo il PLC X) e una tracciabilità completa di ogni singola connessione e operazione. L’architettura di rete è altrettanto critica. La soluzione più sicura è creare una zona demilitarizzata (DMZ), una rete cuscinetto che isola la rete di fabbrica (OT) dalla rete aziendale (IT). Qualsiasi connessione remota termina nella DMZ e solo da lì, attraverso un ulteriore livello di controllo, si può accedere a risorse specifiche della rete OT.

La scelta della giusta architettura dipende dal livello di rischio e dalla complessità dell’impianto. La conformità a normative come la NIS2 sta spingendo sempre più aziende a adottare soluzioni strutturate. Le piattaforme Cloud IIoT, ad esempio, offrono un’alternativa interessante, gestendo la complessità della sicurezza in modo centralizzato, ma richiedono un’attenta configurazione per essere conformi.

Per un ingegnere, la scelta tra diverse architetture di accesso remoto deve basarsi su una valutazione oggettiva di sicurezza, complessità e conformità. La seguente tabella, basata sulle linee guida fornite da enti come l’ACN (Agenzia per la Cybersicurezza Nazionale), riassume le principali opzioni.

Retrofitting digitale: come collegare un vecchio PLC senza porta Ethernet al sistema di fabbrica?

In molti stabilimenti italiani, macchine degli anni ’90, meccanicamente ancora perfette, convivono con le nuove tecnologie dell’Industria 4.0. Il loro limite è spesso il “cervello”: un PLC obsoleto, privo di porta Ethernet, che comunica con protocolli seriali o bus di campo ormai datati come MPI o Profibus-DP. Sostituire l’intera macchina è economicamente insostenibile. È qui che entra in gioco il retrofitting digitale, una strategia chirurgica per modernizzare l’esistente senza stravolgerlo.

L’errore comune è pensare di dover sostituire il vecchio PLC. Spesso, la soluzione più intelligente è affiancarlo. Il PLC originale, affidabile e testato, continua a gestire le funzioni base della macchina, mentre un gateway multiprotocollo o un Edge Controller moderno viene installato “accanto” per fare da traduttore e ponte verso il mondo digitale. Questo dispositivo si collega al vecchio PLC tramite la sua porta seriale o il suo bus di campo e, dall’altro lato, parla i linguaggi moderni dell’IT: Ethernet, OPC UA, MQTT.

Questo approccio permette non solo di raccogliere dati, ma anche di implementare nuove funzionalità, come il monitoraggio da remoto o l’integrazione con sistemi di visione, sfruttando la potenza di calcolo del nuovo dispositivo. Affrontare un progetto di retrofitting richiede un approccio metodico per garantire risultati concreti e conformi.

Perché creare blocchi funzione riutilizzabili ti fa risparmiare il 50% del tempo sul prossimo progetto?

Il cuore della filosofia IEC 61131-3 è la modularità. Invece di scrivere un unico, lungo programma, lo standard incoraggia a scomporre la logica in pezzi più piccoli e gestibili: i Blocchi Funzione (FB). Un Blocco Funzione è un componente software incapsulato, con i propri dati interni e un’interfaccia definita di ingressi e uscite. Immaginatelo come un “mattoncino Lego” software: un motore, un pistone, un nastro trasportatore. Ogni blocco ha una funzione specifica e può essere riutilizzato all’infinito.

Il vantaggio non è solo la leggibilità. L’investimento iniziale nella creazione di una libreria di blocchi funzione standardizzati, testati e affidabili per le applicazioni tipiche della propria azienda (es. `FB_Motore`, `FB_Valvola`, `FB_Asse`) si ripaga esponenzialmente. Come evidenziato da Systematik, l’analisi dello standard IEC 61131-3 mostra che questo approccio può portare a una riduzione fino al 50% nei tempi di sviluppo sui progetti successivi. Il motivo è semplice: invece di reinventare la ruota ogni volta, si assemblano componenti già pronti e collaudati.

Questo trasforma il codice da un semplice costo operativo a un asset strategico riutilizzabile. Una buona libreria di FB diventa parte del know-how aziendale, accelera il time-to-market, riduce i bug (il codice viene testato una sola volta e poi riutilizzato) e semplifica drasticamente la manutenzione. Se un motore non funziona, il tecnico sa che deve guardare solo all’interno dell’istanza `FB_Motore` corrispondente, senza dover decifrare centinaia di righe di codice interconnesso.

L’utilizzo di blocchi funzione, strutture gerarchiche e di altri elementi modulari consente di realizzare librerie di funzioni comuni. In questo modo, le soluzioni software possono essere facilmente adattate a diverse applicazioni, riducendo tempi e costi di sviluppo.

– Systematik, IEC 61131-3: Fondamento Tecnico della Programmazione dei PLC

Latenza ultra-bassa: come il 5G permette di controllare bracci robotici in tempo reale senza cavi?

Per decenni, il controllo di macchine ad alta velocità o che richiedono una risposta in tempo reale (come bracci robotici o motion control) è stato sinonimo di cavi. Le reti wireless tradizionali, come il Wi-Fi, non potevano garantire la bassissima latenza e l’altissima affidabilità necessarie. Il 5G, in particolare nelle sue implementazioni private industriali, sta cambiando radicalmente questo paradigma.

La vera rivoluzione del 5G per l’industria non è tanto la velocità di banda (throughput), ma la sua capacità di offrire una comunicazione ultra-affidabile a bassissima latenza (URLLC – Ultra-Reliable Low-Latency Communication). Questo significa tempi di risposta inferiori al millisecondo, paragonabili a quelli di una connessione cablata. Questa caratteristica apre le porte a scenari prima impensabili: bracci robotici montati su veicoli a guida autonoma (AGV) che operano senza soluzione di continuità, coordinamento di flotte di droni per la logistica di magazzino, o il controllo di processi su parti rotanti della macchina dove il cablaggio è impossibile.

Tuttavia, è fondamentale distinguere tra il 5G pubblico (quello dei nostri smartphone) e il 5G privato. Una rete 5G privata è un’infrastruttura dedicata, installata all’interno dello stabilimento, che offre un controllo totale su sicurezza, prestazioni e priorità del traffico. È una rete completamente isolata, che garantisce che il segnale di arresto di emergenza di un robot non debba competere per la banda con lo streaming video di un tablet.

La scelta tra 5G pubblico e privato per applicazioni industriali critiche dipende da un’analisi dei requisiti di latenza, sicurezza e affidabilità, come illustrato nella tabella seguente.

Come digitalizzare macchinari anni ’90 senza doverli sostituire completamente?

La strategia di affiancare un nuovo gateway a un vecchio PLC, già discussa nel contesto del retrofitting, può essere elevata a un vero e proprio paradigma architetturale: l’architettura a “doppio cervello”. Questo approccio è la soluzione più pragmatica ed economicamente vantaggiosa per la digitalizzazione di macchinari datati ma ancora funzionali.

L’idea di fondo, come evidenziato da esperti del settore, è di una semplicità disarmante ma di grande efficacia. Il vecchio PLC, che ha dimostrato per decenni la sua affidabilità nel gestire il ciclo macchina base, viene lasciato indisturbato. Non si tocca il suo programma, non si modificano i suoi cablaggi. Lo si considera il “cervello rettile” della macchina, responsabile delle funzioni vitali e del controllo in tempo reale. Accanto a questo, si installa un “cervello intelligente”, un moderno PLC o un Edge Controller. Questo secondo cervello non interviene nel controllo diretto della macchina, ma si occupa di tutte le funzioni legate all’Industria 4.0: raccoglie dati dal primo PLC (tramite un gateway se necessario), si interfaccia con sensori IIoT aggiuntivi, comunica con il sistema informativo di fabbrica (MES/ERP) e abilita funzionalità avanzate come il monitoraggio da remoto e la manutenzione predittiva.

L’architettura a ‘doppio cervello’ permette di mantenere il vecchio PLC per le funzioni base della macchina e aggiungere un nuovo PLC o Edge Controller che funge da ‘cervello intelligente’ per la comunicazione con il sistema informativo di fabbrica.

– Redazione Italia 4.0, HMI mobili vs dispositivi fissi

Questa strategia di revamping offre numerosi vantaggi. Minimizza i rischi e i tempi di fermo macchina, in quanto l’intervento è molto meno invasivo di una sostituzione completa. Permette un adeguamento graduale, iniziando con la sola raccolta dati per poi aggiungere funzionalità più complesse. Inoltre, consente di adeguare la sicurezza della macchina alle normative attuali (come il D.Lgs. 81/2008) implementando le nuove logiche di sicurezza sul cervello moderno, che può così supervisionare e, se necessario, intervenire sul cervello più vecchio. È l’essenza del pragmatismo ingegneristico: ottenere il massimo risultato con il minimo sforzo e rischio.

Come l’Edge Computing permette il controllo qualità in tempo reale sulle linee di produzione veloci?

Su una linea di produzione ad alta velocità, come nel settore del packaging o dell’imbottigliamento, un difetto può generare migliaia di scarti in pochi minuti. Inviare i dati da un sensore o da una telecamera al cloud, aspettare l’elaborazione e ricevere una risposta è un processo troppo lento. Il pezzo difettoso sarebbe già passato da un pezzo. L’Edge Computing risolve questo problema portando l’intelligenza e la capacità di calcolo direttamente a bordo macchina, “sull’orlo” (edge) della rete.

Un dispositivo Edge, che può essere un PC industriale o un controller avanzato, raccoglie i dati grezzi ad altissima frequenza (es. le immagini di un sistema di visione) e li elabora localmente, in tempo reale. Se viene rilevato un difetto, il dispositivo Edge può comandare immediatamente un attuatore per scartare il pezzo, con tempi di reazione nell’ordine dei millisecondi. Solo i dati già elaborati e aggregati (es. “scartati 3 pezzi nell’ultimo minuto per difetto X”, “la temperatura media è salita di 0.5°C”) vengono poi inviati al cloud per analisi storiche, statistiche e manutenzione predittiva.

Questo approccio offre un triplice vantaggio. Primo, la risposta in tempo reale, impossibile con un’architettura basata solo sul cloud. Secondo, una drastica riduzione del traffico di rete e dei costi di banda, poiché solo i dati significativi vengono inviati al cloud. Terzo, una maggiore resilienza: se la connessione internet si interrompe, il controllo qualità a bordo macchina continua a funzionare senza interruzioni.

Per trasformare questi principi in pratica, il prossimo passo consiste nell’effettuare un audit del vostro codice esistente per identificare il debito tecnico e definire le priorità di intervento. Un’architettura software solida non si costruisce in un giorno, ma ogni passo verso la modularità e la chiarezza è un investimento nel futuro della vostra automazione.