Un turno chiude con 12.000 pezzi dichiarati dall’operatore, l’ERP ne registra 11.650 e il responsabile di produzione scopre il giorno dopo che una macchina è rimasta ferma 47 minuti. Il problema non è la mancanza di dati: è l’assenza di un processo affidabile per raccoglierli, contestualizzarli e renderli...
Perché i dati macchina da soli non risolvono il problema
Un PLC contiene molti segnali, ma non tutti hanno valore gestionale. Leggere centinaia di tag senza una struttura produce dashboard affollate e database costosi da mantenere, senza migliorare la capacità di intervenire su una perdita di efficienza. Al contrario, raccogliere pochi dati ben definiti può fornire una visione molto più utile di disponibilità, performance e qualità.
C’è anche un tema di semantica. Un bit che segnala “macchina in ciclo” non basta a distinguere una produzione regolare da un’attesa materiale, un microfermo o un fermo per cambio formato. Questa distinzione richiede una mappatura condivisa tra produzione, manutenzione, automazione e IT/OT. Se ciascuna funzione interpreta gli stati in modo diverso, l’OEE perde credibilità prima ancora di essere calcolato.
Il livello di dettaglio corretto dipende dall’obiettivo. Una linea ad alta velocità può richiedere contatori e segnali evento con precisione al secondo; per un reparto a lotti può essere più rilevante associare avvio, fine, operatore, ordine e causale di fermo. La regola non è acquisire tutto: è acquisire ciò che consente di misurare, spiegare e migliorare il processo.
Best practice per la raccolta dati di produzione
1. Partire dalle decisioni da prendere, non dai tag disponibili
Prima di definire il collegamento a Siemens S7, Modbus TCP/IP, OPC UA o altri protocolli, è utile formulare domande operative precise. Quali linee generano più scarti? Quanto incidono i fermi non pianificati? Il tempo ciclo reale rispetta lo standard dell’ordine? Il consumo di materiale è coerente con i pezzi buoni prodotti?
A ogni domanda devono corrispondere dati, formule, responsabilità e soglie di attenzione. Ad esempio, per analizzare gli scarti non è sufficiente un contatore cumulativo: servono il contatore pezzi totali, quello dei pezzi conformi o scartati, l’ordine in corso e, quando possibile, una causale. Questo approccio evita di progettare una raccolta dati tecnicamente corretta ma non utilizzata dal reparto.
2. Costruire un modello dati comune tra macchine diverse
Macchine dello stesso stabilimento possono esporre variabili con nomi, unità di misura e logiche differenti. Una pressa può inviare un contatore pezzi, una confezionatrice un contatore cicli, una linea più datata solo un impulso. Senza normalizzazione, il confronto tra reparti diventa manuale e fragile.
Il modello dati comune deve definire almeno stati macchina, quantità prodotte, quantità scartate, tempi, ordini, ricette o formati, allarmi e causali. Non significa forzare tutti gli impianti a funzionare nello stesso modo. Significa tradurre il dato nativo in categorie comprensibili e comparabili a livello di stabilimento.
È essenziale gestire anche unità di misura e contatori. Un contatore che si azzera a fine turno, a cambio lotto o dopo un riavvio PLC deve essere riconosciuto dal sistema. In caso contrario, si rischiano quantità negative, doppie contabilizzazioni o perdite di produzione, con effetti diretti su avanzamento e consuntivazione ERP.
3. Preferire eventi e stati ai campionamenti indiscriminati
Molte architetture storiche leggono le variabili a intervalli fissi, ad esempio ogni secondo. Può essere una scelta valida per alcuni segnali analogici o per una dashboard di processo, ma non è sempre la soluzione migliore per dati produttivi. Per contatori, allarmi e cambi di stato, la raccolta basata sugli eventi riduce traffico e volume storico, mantenendo al tempo stesso un’informazione più precisa.
La scelta va valutata caso per caso. Un valore di temperatura può richiedere campionamento e soglie di variazione; un fermo macchina deve essere registrato con timestamp di inizio e fine; un pezzo buono può essere rilevato tramite incremento del contatore o segnale di espulsione. La combinazione di questi metodi consente di evitare sia lacune informative sia archivi sovradimensionati.
4. Garantire qualità, continuità e storicizzazione del dato
Un dato affidabile deve mantenere tre proprietà: deve essere corretto, disponibile e tracciabile nel tempo. La correttezza si verifica confrontando i primi risultati con contatori macchina, report di turno e quantità dichiarate. La disponibilità richiede una gestione adeguata delle disconnessioni di rete, dei riavvii e delle manutenzioni. La tracciabilità richiede timestamp coerenti, identificativi dell’asset e, dove necessario, utente, ordine e lotto.
È opportuno prevedere controlli automatici su valori impossibili o incoerenti, come un aumento improvviso di un contatore, un fermo senza fine oppure uno scarto superiore ai pezzi prodotti. Queste anomalie non devono essere nascoste: vanno segnalate e rese verificabili, perché spesso rivelano un problema di mappatura, di logica PLC o di processo.
Anche l’orario merita attenzione. Se PLC, gateway, MES e ERP non lavorano su riferimenti temporali allineati, ricostruire la sequenza di un allarme, un fermo e un avanzamento diventa complesso. La sincronizzazione del tempo è un dettaglio tecnico con conseguenze operative rilevanti.
5. Separare la connettività OT dalla complessità IT locale
Collegare macchine e sistemi aziendali non dovrebbe comportare la creazione di nuovi server da amministrare in stabilimento. Un’architettura con agente leggero on-premise consente di dialogare con la rete OT e trasferire in modo controllato i dati verso una piattaforma centralizzata, limitando l’impatto sull’infrastruttura locale.
La segmentazione di rete, l’uso di protocolli standard e la definizione dei permessi devono essere parte del progetto fin dall’inizio. Non è necessario esporre il PLC direttamente verso l’esterno per ottenere dati in tempo reale. La sicurezza va progettata senza ostacolare il lavoro di manutentori e operatori: un eccesso di vincoli non coordinati può spingere i reparti a tornare a fogli Excel e rilevazioni manuali.
In questo contesto, una piattaforma cloud-native come PLCinCloud può centralizzare l’interconnessione con PLC e macchinari, lasciando in fabbrica solo il componente necessario alla comunicazione. Il vantaggio non è solo tecnologico: riduce attività di manutenzione locale e accelera l’estensione del progetto a nuove linee o stabilimenti.
6. Integrare MES, ERP e BI senza duplicare la verità
La raccolta dati di produzione genera valore quando alimenta i sistemi che già governano ordini, magazzino, qualità e analisi. Tuttavia, l’integrazione non deve creare versioni concorrenti dello stesso dato. Occorre chiarire quale sistema genera l’ordine, quale calcola l’avanzamento, quale conserva il dettaglio degli eventi macchina e quale espone i KPI direzionali.
In pratica, l’ERP può rimanere il riferimento per anagrafiche, ordini e consuntivi amministrativi, mentre il MES raccoglie gli eventi di campo, gestisce l’avanzamento real-time e produce la tracciabilità operativa. Il BI può elaborare confronti storici e analisi trasversali. Questa ripartizione evita importazioni manuali, riconciliazioni ripetute e discussioni su quale report sia corretto.
7. Misurare l’adozione sul campo, non solo l’avvio tecnico
Un progetto può essere completato dal punto di vista della connettività e non essere ancora utile alla produzione. La verifica deve includere dashboard consultate durante il turno, causali di fermo compilate con coerenza, alert presi in carico e confronti periodici tra dati acquisiti e realtà di reparto.
Conviene iniziare da una linea rappresentativa, validare mappature e KPI con le persone che lavorano sull’impianto, quindi estendere il modello. Un pilota troppo semplice può non rappresentare le difficoltà della fabbrica; uno troppo ampio rallenta l’adozione. La scelta migliore è una linea con un problema misurabile, una sufficiente varietà di segnali e un team disposto a validare i risultati.
Dalla raccolta al controllo operativo
La raccolta dati diventa un investimento utile quando riduce il tempo necessario per capire cosa sta accadendo in produzione. Questo richiede una progettazione disciplinata, ma non necessariamente lunga o invasiva: protocolli industriali già presenti, un modello dati chiaro e integrazioni mirate sono spesso più efficaci di progetti costruiti interamente su misura.
Il primo passo concreto è scegliere un KPI oggi discusso ma non dimostrabile con dati certi, come i microfermi di una linea, la differenza tra pezzi dichiarati e pezzi reali o gli scarti per formato. Da quel punto, la raccolta dati smette di essere un tema IT e diventa uno strumento con cui lo stabilimento può decidere meglio già dal turno successivo.