Il problema non è leggere un registro dal PLC. Il problema è capire come raccogliere dati dai PLC in modo continuo, coerente e utilizzabile da produzione, qualità, manutenzione e direzione. In molte fabbriche il dato esiste già, ma resta chiuso nella macchina, disperso tra software diversi o disponibile solo a bordo...
Come raccogliere dati dai PLC senza creare complessità
L’errore più comune è partire dalla tecnologia invece che dal risultato atteso. Si collega il PLC a un software, si importano decine o centinaia di variabili e solo dopo ci si chiede a cosa servano davvero. È l’approccio che genera progetti lunghi, mapping ridondanti e dati poco affidabili.
Un impianto produttivo richiede un’impostazione diversa. Prima si definiscono gli obiettivi: monitorare tempi ciclo, conteggio pezzi, allarmi, stati macchina, consumi, causali di fermo, parametri di processo, tracciabilità lotto o avanzamento commessa. Poi si identificano nel PLC i tag che rappresentano questi eventi in modo chiaro e stabile.
Qui entra in gioco la conoscenza congiunta di OT e IT. Un bit di marcia, da solo, dice poco. Diventa utile quando viene contestualizzato insieme a modalità operativa, presenza ricetta, ordine di produzione, contapezzi e timestamp affidabile. Raccogliere dati bene significa trasformare segnali macchina in informazioni gestionali.
Quali dati conviene leggere da un PLC
Non tutto quello che è disponibile nel controllore deve essere acquisito. In un progetto industriale serio conviene distinguere tra dati base, dati di performance e dati di processo.
I dati base sono quelli necessari per sapere cosa sta succedendo in tempo reale: stato macchina, start, stop, allarme, produzione totale, produzione buona, scarti, ricetta attiva, codice formato, tempo ciclo, assorbimenti se disponibili. Sono la base per dashboard, report e storicizzazione.
I dati di performance servono a misurare l’efficienza. Qui rientrano microfermi, tempi di inattività, velocità reale versus nominale, cambio formato, saturazione della linea, allarmi ricorrenti. Sono i segnali che permettono di calcolare KPI come OEE e di individuare le perdite.
I dati di processo diventano centrali quando si parla di qualità e conformità. Temperature, pressioni, coppie, pesi, valori dimensionali, soglie di tolleranza e conferme di ciclo possono essere indispensabili per rintracciabilità, audit o gestione non conformità. Ma non vanno raccolti in modo indiscriminato. Frequenza di campionamento, granularità e retention vanno calibrate sul caso reale, altrimenti si aumenta il volume dei dati senza aumentare il valore.
La differenza tra variabile disponibile e variabile utile
In fabbrica capita spesso che il PLC esponga centinaia di tag, ma solo una parte sia davvero stabile nel tempo e semanticamente corretta. Una variabile può esistere nel programma macchina e tuttavia non essere affidabile per la reportistica, perché cambia logica tra ricette, dipende da condizioni temporanee o viene riutilizzata dall’automazione per scopi diversi.
Per questo il censimento iniziale è decisivo. Bisogna validare con chi conosce la macchina quali variabili rappresentano davvero l’evento che si vuole misurare. Questo passaggio riduce errori di interpretazione, contestazioni sui dati e rilavorazioni in fase di avviamento.
Protocolli e metodi di connessione
Quando si valuta come raccogliere dati dai PLC, il protocollo conta, ma non è l’unico criterio. Nella pratica industriale i più diffusi sono Siemens S7, Modbus TCP/IP, OPC UA, EtherNet/IP e, in alcuni contesti, MQTT come livello di pubblicazione verso sistemi superiori.
La scelta dipende dal parco macchine, dall’età degli impianti, dal livello di standardizzazione e dai requisiti di sicurezza. OPC UA è spesso apprezzato per interoperabilità e struttura informativa, ma non tutti gli impianti lo espongono nativamente o con un modello dati già pronto. S7 e Modbus TCP/IP restano frequenti in retrofit e integrazioni su macchine esistenti. EtherNet/IP è naturale dove la base installata è orientata a ecosistemi Rockwell. MQTT può essere utile per inoltrare dati elaborati, ma non sempre è il primo punto di accesso al PLC.
Il punto vero è evitare architetture fragili. Se ogni macchina viene integrata con logiche custom, driver diversi e script non documentati, il costo di manutenzione cresce rapidamente. In un contesto multi-linea conviene adottare un layer di raccolta standardizzato, capace di parlare con protocolli diversi ma di esporre i dati in modo uniforme verso MES, ERP, BI o database aziendali.
Polling o evento: non sempre vince la stessa logica
Molti progetti partono con lettura ciclica a intervalli fissi. È una scelta semplice e spesso sufficiente per stati macchina, contatori e parametri lenti. Ma quando servono precisione temporale, eventi rapidi o ricostruzione puntuale dei cambi stato, il solo polling può non bastare.
In alcuni casi conviene combinare polling e logiche event-driven. Il primo garantisce continuità e controllo generale, il secondo migliora la precisione su eventi critici come scarti, allarmi, fine ciclo o cambi causale. La soluzione migliore dipende dal processo, dalla capacità del PLC e dal livello di dettaglio richiesto a valle.
Dalla macchina al MES: dove nasce il valore
Leggere dati dal PLC non equivale a digitalizzare la produzione. Il valore nasce quando quel dato entra in un sistema capace di contestualizzarlo per ordine, lotto, turno, operatore, articolo e centro di lavoro.
Se un PLC segnala che la macchina è ferma, il MES può associare il fermo a una causale, misurare la durata, confrontarla con la pianificazione e farla confluire nei KPI di reparto. Se il PLC aggiorna il contapezzi, il sistema può confrontarlo con l’ordine ERP, valutare lo scostamento e aggiornare l’avanzamento produttivo. Se una variabile di processo esce soglia, il dato può diventare un allarme qualità o un’evidenza per la tracciabilità.
Qui si vede la differenza tra acquisizione e integrazione. L’acquisizione porta fuori il segnale. L’integrazione lo rende operativo.
Affidabilità del dato: il punto che decide il progetto
Nelle aziende manifatturiere il tema non è solo avere dati, ma potersi fidare. Se i contatori non coincidono con quelli di reparto, se i tempi di fermo non tornano, se i timestamp sono incoerenti, il sistema perde credibilità molto in fretta.
L’affidabilità si costruisce su alcuni aspetti concreti: sincronizzazione oraria, gestione delle disconnessioni, buffering locale quando la rete ha interruzioni, regole chiare di deduplicazione, validazione dei range e governance delle modifiche lato macchina. Anche il modo in cui si gestiscono versioni software, aggiornamenti del PLC e variazioni di programma incide direttamente sulla qualità del dato storico.
Per questo molte aziende preferiscono evitare infrastrutture locali complesse, con server in stabilimento da mantenere e integrare nel tempo. Un’architettura con agente leggero on-premise e piattaforma centralizzata riduce punti di guasto, semplifica la manutenzione e accelera l’estensione a nuove linee. In questo scenario, soluzioni come PLCinCloud rispondono bene a chi vuole interconnettere macchine e sistemi gestionali senza aggiungere complessità IT in reparto.
Sicurezza, segmentazione e compliance
Quando si parla di collegare PLC e sistemi informativi, la sicurezza non può essere trattata come un dettaglio finale. La raccolta dati deve rispettare la segmentazione tra rete OT e IT, limitare le superfici di attacco e mantenere un principio di minimo accesso.
Questo significa definire bene chi legge cosa, da quali reti, con quali credenziali e con quali logiche di audit. In molti casi l’obiettivo è sola lettura dal PLC, evitando scritture non necessarie. Anche la scelta dell’infrastruttura conta: cifratura dei flussi, tracciabilità degli accessi, hosting in ambito europeo e presidi certificati sono elementi che pesano sempre di più, soprattutto quando i dati di produzione alimentano processi decisionali e documentazione di compliance.
Il tema è ancora più concreto nelle iniziative legate a Transizione 4.0. Qui la raccolta dati non serve solo a vedere la fabbrica in tempo reale, ma anche a dimostrare interconnessione, continuità informativa e capacità di integrazione con i sistemi aziendali.
Un metodo pratico per partire bene
Se l’obiettivo è ottenere risultati in tempi ragionevoli, conviene procedere per perimetri chiari. Si parte da una linea o da una famiglia di macchine rappresentativa, si selezionano pochi casi d’uso ad alto impatto e si misura il risultato. Tipicamente: avanzamento produzione, fermate, scarti e allarmi.
Una volta validata la qualità del dato, si estende il modello agli altri impianti con logiche standard. Questo approccio riduce tempi di avviamento, evita personalizzazioni inutili e crea una base solida per integrare ERP, BI e funzioni di tracciabilità.
La tentazione di partire da tutto insieme è comprensibile, ma raramente è la scelta migliore. Nel mondo industriale funziona di più un progetto leggibile, con obiettivi verificabili, che una raccolta dati molto ampia ma poco governata.
Raccogliere dati dai PLC, in fondo, non serve a riempire database. Serve a prendere decisioni più rapide, ridurre fermate, rendere misurabile la produzione e sostenere investimenti digitali con numeri verificabili. Se l’architettura è corretta e il dato nasce già pronto per essere usato, la fabbrica smette di inseguire informazioni e ricomincia a governarle.