Programmazione PLC: quale linguaggio per quale processo industriale

Quando si commissiona un impianto automatizzato, la discussione sul PLC ruota quasi sempre attorno alla marca e al modello: Siemens o Rockwell, S7-1500 o ControlLogix. Raramente qualcuno chiede in quale linguaggio verrà scritto il codice e perché.

È una domanda che sembra tecnica, da fare al programmatore. In realtà è una decisione di progetto con conseguenze che durano quanto l’impianto: dieci, vent’anni. Il linguaggio sbagliato non causa errori durante il collaudo. Li causa quando il programmatore originale non c’è più, quando la macchina si ferma a mezzanotte e qualcuno deve capire cosa sta succedendo leggendo un codice che non riconosce.

La norma IEC 61131-3 definisce cinque linguaggi di programmazione per i controllori logici programmabili. Non sono intercambiabili. Ciascuno modella un tipo specifico di logica industriale — e ogni processo ha una struttura temporale e causale che si adatta meglio a uno di loro.

Questo articolo spiega come ragionare su questa scelta, partendo dal processo, non dal linguaggio.

Un controllore logico programmabile (PLC programmabile nella terminologia comune, o programmable logic controller in inglese) è il cervello di un impianto di automazione industriale. Riceve segnali dai sensori, esegue la logica di controllo e invia comandi agli attuatori. Lo fa in cicli continui, spesso nell’ordine dei millisecondi.

Ma il PLC non si programma: si programma il PLC in un linguaggio. E quella scelta rimane nel codice per tutto il ciclo di vita dell’impianto.

Il problema è che in Italia la programmazione PLC viene ancora trattata come un mestiere specialistico riservato a pochi tecnici di fiducia. Quando quei tecnici cambiano azienda, vanno in pensione o sono semplicemente indisponibili, l’impianto diventa opaco. Nessuno sa più cosa fa quel blocco di istruzioni, perché quella variabile si chiama così, cosa succede quando quel bit va a 1.

Questo non è un problema di documentazione è un problema di linguaggio. Un codice scritto nel linguaggio sbagliato per quel dato processo è difficile da leggere anche per chi lo conosce. Un codice scritto con l’ottica al progetto è quasi autoesplicativo perché la struttura del programma rispecchia la struttura del processo.

La norma IEC 61131-3, pubblicata dall’International Electrotechnical Commission e aggiornata nella terza edizione del 2013, ha standardizzato cinque linguaggi proprio per questo: perché processi diversi hanno logiche diverse, e ogni logica ha un linguaggio più adatto a rappresentarla.

La norma IEC 61131-3 definisce quattro linguaggi testuali e grafici, più uno di coordinazione:

Tutti i principali ambienti di sviluppo supportano questi linguaggi: Siemens TIA Portal (S7-1200, S7-1500), Rockwell Studio 5000 (ControlLogix, CompactLogix), Schneider EcoStruxure Machine Expert (Modicon). La scelta del linguaggio è indipendente dalla scelta del costruttore del PLC.

Una linea di trafilatura del rame o dell’alluminio segue una sequenza definita: carico del vergella, tensionamento del filo, passaggio attraverso la filiera, raffreddamento, avvolgimento sulla bobina. Ogni fase ha condizioni di ingresso precise (il filo è teso? la filiera è a temperatura? la bobina è pronta?) e condizioni di uscita altrettanto definite.

Questa è la struttura perfetta per il Sequential Function Chart. Il programma rispecchia il processo: ogni step SFC corrisponde a una fase operativa, ogni transizione corrisponde a una condizione fisica verificabile. Leggere il codice equivale a leggere il diagramma di flusso del processo.

Nel caso di una linea multifilo, dove più fili vengono trafilati in parallelo su anelli concentrici, la gestione degli stati diventa più complessa, ma rimane sequenziale: ciascun filo ha il suo SFC, e un SFC coordinatore gestisce le dipendenze. Questo sarebbe difficile da implementare in Ladder in modo leggibile: la logica sequenziale in LD richiede bits di stato, temporizzatori e condizioni incrociate che, oltre una certa complessità, diventano impossibili da seguire senza documentazione aggiuntiva.

L’esperienza su impianti di trafilatura (come i progetti su sbozzatori e linee di processo nel settore metalli) mostra che le manutenzioni straordinarie richiedono spesso di mettere in pausa e riprendere specifiche fasi del ciclo. Il SFC lo permette in modo nativo: si può interrompere un passo, gestire l’eccezione e riprendere dal punto esatto.

Un estrusore plastico ha una struttura completamente diversa. Il processo è continuo: la vite ruota, il materiale viene fuso e spinto attraverso la testa di estrusione. Le variabili critiche sono la temperatura per zone (barrel zones), la pressione del materiale, la velocità di estrusione e la velocità della linea di traino.

Queste variabili sono continue, non binarie. Non esistono stati “on” e “off”: esiste un set-point di 230°C, una temperatura misurata di 228°C e una deviazione che il regolatore PID deve correggere. Il Ladder Diagram non è il posto giusto dove scrivere questa logica: un PID in LD è possibile, ma la rappresentazione grafica a contatti è pensata per la logica booleana, non per la regolazione continua.

Il Function Block Diagram è il linguaggio naturale per questo tipo di processo. Un blocco PID con i suoi ingressi (setpoint, valore misurato, parametri) e le sue uscite (segnale di correzione al riscaldatore) si legge in modo immediato anche per chi non ha scritto il codice. I blocchi si collegano tra loro come i segnali si collegano nei P&ID: il flusso è visibile.

Lo Structured Text entra in gioco per la gestione delle ricette, le configurazioni di temperatura, velocità e pressione per materiali diversi (PE, PP, PA, PVC). Una ricetta è una struttura dati, e le strutture dati si gestiscono bene in un linguaggio testuale con array, cicli e accesso a memoria strutturata.

La combinazione FBD per la regolazione continua e ST per la gestione dati è lo standard de facto negli impianti di estrusione plastica di fascia media e alta.

Le macchine di packaging sono discontinue: fanno cicli veloci e ripetitivi. Una confezionatrice verticale compie decine di cicli al minuto, ciascuno composto da pochi passi (apertura busta, riempimento, chiusura, taglio, espulsione). La logica è relativamente semplice, la velocità di ciclo è alta.

In questo contesto il Ladder Diagram funziona bene e continua a funzionare bene per i tecnici di manutenzione che conoscono l’elettrotecnica ma non la programmazione orientata agli oggetti. Il Ladder rispecchia la logica dei vecchi schemi a relè: è leggibile senza formazione informatica, è direttamente correlato all’hardware e all’elettrica.

La robotica integrata aggiunge però un livello di complessità che il Ladder fatica a gestire. La coordinazione tra assi, i calcoli cinematici, la gestione delle traiettorie e l’interfacciamento con i robot industriali (Fanuc, KUKA, ABB tramite protocolli dedicati) richiedono lo Structured Text: cicli FOR per iterare su array di posizioni, funzioni matematiche per le trasformazioni di coordinate, gestione delle eccezioni con strutture di controllo esplicite.

Nei progetti che combinano macchina di packaging e celle robotizzate, sempre più comuni nel settore food, farmaceutico e logistica, la scelta più efficace è mista: LD per la logica della macchina meccanica, ST per la coordinazione con i robot e la gestione delle ricette di prodotto.

La safety di un impianto obbedisce a regole diverse. Le norme IEC 62061 e EN ISO 13849 definiscono i livelli di integrità della sicurezza (SIL) e i livelli di prestazione (PL) richiesti per le funzioni di sicurezza in base all’analisi del rischio.

I PLC di sicurezza (F-PLC, Fail-safe PLC) come Siemens S7-1500F con TIA Portal Safety, Allen-Bradley GuardLogix con Studio 5000 Logix Designer o Pilz PSS 4000 gestiscono la logica di sicurezza in ambienti separati e certificati. Il codice di sicurezza viene scritto in linguaggi approvati dagli enti certificatori (TÜV, Bureau Veritas), che nella maggior parte dei casi sono un sottoinsieme limitato di LD o FBD non ST completo.

La ragione è precisa: la logica di sicurezza deve essere verificabile, auditabile e semplice da ispezionare. Uno Structured Text ricco di cicli annidati e funzioni complesse non è facilmente verificabile e il certificatore lo sa. Il Ladder, per quanto limitato, ha una leggibilità intrinseca che lo rende adatto alla safety review.

Questo significa che in un impianto dove coesistono logica standard e logica di sicurezza, il programmatore deve spesso lavorare in due ambienti e due linguaggi diversi anche quando tecnicamente potrebbe fare tutto in uno solo.

La scelta del linguaggio di programmazione non avviene nel vuoto. Il controllore PLC non è un’isola: comunica con sensori, attuatori, azionamenti, HMI e altri sistemi attraverso il bus di campo che è la rete di comunicazione industriale dell’impianto.

Il bus di campo influenza la scelta del PLC (e viceversa) più di quanto si pensi. I principali protocolli in uso:

La scelta del bus di campo determina quali dispositivi si possono connettere, con quale latenza e con quale livello di diagnostica. Un impianto di trafilatura con azionamenti Siemens e un PLC S7-1500 vivrà in un ecosistema Profinet; un impianto con servoassi Beckhoff e logica motion complessa parlerà EtherCAT e il programmatore scriverà quasi certamente in ST su TwinCAT.

Purtroppo capita spesso di trovarci a svolgere manutenzione su impianti che hanno problemi che in origine non erano nemmeno pensabili. Qui diventa evidente la differenza di un programmatore junior e un’azienda con anni di esperienza. La nostra esperienza nella progettazione, ci permette di avere una visione del processo e del progetto nella sua interessa e anche oltre, nelle possibili variabili che il tempo potrebbe presentare.

Un impianto programmato in Ladder con 3.000 rung non è un impianto che funziona male. Funziona, supera il collaudo, va in produzione. Il problema emerge dodici mesi dopo, quando un sensore manda un segnale inatteso e nessuno riesce a capire in tempo dove andare a guardare nel codice.

O cinque anni dopo, quando l’azienda decide di aggiungere una fase al processo e il programmatore originale, quello che sapeva come era strutturata la logica, non è più reperibile.

La norma IEC 61131-3 non è una lista di opzioni equivalenti. È un insieme di strumenti diversi per lavori diversi. Usare il cacciavite giusto non migliora solo il risultato, riduce il tempo di ogni intervento futuro sull’impianto.

Nei progetti di automazione industriale complessi, il costo del software è spesso sottostimato rispetto all’hardware. Ma è il software che determina quanto facilmente l’impianto sarà mantenuto, adattato e migliorato nel tempo. È lì che si gioca buona parte del TCO, il costo totale di proprietà, di una linea produttiva.