Un fermo linea non classificato, un contapezzi aggiornato a fine turno e uno scarto annotato su carta producono lo stesso effetto: il responsabile di produzione decide quando il problema è già passato. Questa guida dashboard produzione real time spiega come progettare una visualizzazione che trasformi i segnali di PLC...
A cosa serve una dashboard di produzione real time
Il valore del real time non è la velocità del dato in sé. È la riduzione del tempo tra evento, comprensione e decisione. Se una confezionatrice è ferma per mancanza materiale, il supervisore deve saperlo mentre il fermo è in corso, non dopo che l'ERP ha consolidato la produzione del giorno precedente.
In un impianto manifatturiero, una dashboard operativa deve rispondere a domande molto concrete: quali macchine stanno producendo? Quali sono ferme e per quale motivo? Il ritmo attuale è coerente con il target? Quanti pezzi buoni, scarti e rilavorazioni sono stati rilevati? Quale reparto richiede attenzione prima che il ritardo diventi un problema di consegna?
Questo richiede dati con un contesto. Il segnale macchina “run” è utile, ma da solo non spiega il risultato produttivo. Va associato a ordine, articolo, turno, operatore quando necessario, causale di fermo e quantità dichiarate o rilevate. Senza questa struttura, la dashboard visualizza attività ma non governa il processo.
Guida dashboard produzione real time: partire dalle decisioni
Il punto di partenza corretto è la decisione da supportare, non il layout. Un direttore di stabilimento osserva capacità, rispetto del piano e OEE per reparto. Il capoturno ha bisogno di individuare in pochi secondi le linee in anomalia. Manutenzione deve distinguere un microfermo ricorrente da un arresto prolungato. Qualità deve correlare scarti, lotti e condizioni di processo.
Una singola schermata che tenta di soddisfare tutti tende a diventare sovraccarica. È più efficace definire una vista per ruolo, mantenendo le stesse regole di calcolo e la stessa origine del dato. Così il KPI non cambia a seconda del reparto che lo consulta, mentre il livello di dettaglio resta appropriato all'azione richiesta.
Prima di configurare widget e grafici, conviene formalizzare per ogni indicatore quattro elementi: definizione, fonte dati, frequenza di aggiornamento e responsabile dell'azione. Per esempio, l'OEE deve indicare con chiarezza quali tempi rientrano nella disponibilità, come sono trattate le pause pianificate e da dove provengono velocità nominale e quantità conformi. Un OEE calcolato con regole ambigue genera discussioni, non miglioramento.
I KPI che meritano spazio nella prima vista
La prima pagina dovrebbe privilegiare pochi indicatori ad alta priorità. Stato macchina e stato linea, produzione effettiva contro target, pezzi buoni, scarti, fermo corrente e OEE sono spesso sufficienti. L'utilità dipende dal processo: nella plastica può essere decisivo il tempo ciclo; nel food la tracciabilità di lotto e le condizioni di conservazione; nel packaging il rendimento della linea e la disponibilità dei materiali.
Il codice colore va usato con disciplina. Verde non dovrebbe significare soltanto “macchina accesa”, ma condizione coerente con il piano e senza allarmi rilevanti. Rosso dovrebbe indicare una condizione che richiede un'azione. Giallo può segnalare una soglia di attenzione, per esempio una velocità inferiore al target o una percentuale scarti in crescita. Se quasi tutto è colorato, nulla è realmente prioritario.
Per analizzare le perdite serve poi una vista di dettaglio. Un grafico Pareto delle causali di fermo, la distribuzione dei microfermi e il confronto tra turni permettono di passare dal sintomo alla causa ricorrente. La dashboard non sostituisce il lavoro di analisi in reparto, ma lo indirizza verso i pochi fenomeni con impatto misurabile.
Dal PLC al browser: come rendere il dato affidabile
La qualità della dashboard dipende dalla catena che porta il dato dalla macchina alla piattaforma. In molte fabbriche coesistono PLC Siemens S7, dispositivi Modbus TCP/IP, server OPC UA, macchine con EtherNet/IP o protocolli proprietari. L'obiettivo non è uniformare forzatamente il parco installato, ma acquisire i segnali necessari con una modalità governabile e sicura.
Il primo lavoro consiste nel mappare i tag disponibili e validarli sul campo. Stato automatico, marcia, fermo, allarme, contatore totale, contatore scarti, ricetta o codice articolo sono candidati tipici. Tuttavia, il nome del tag non garantisce il suo significato operativo. Un contatore può azzerarsi a ogni cambio formato, uno stato di marcia può restare attivo durante un blocco a valle, una variabile di allarme può contenere codici non normalizzati.
Serve quindi un modello eventi che traduca i segnali tecnici in stati comprensibili: produzione, fermo pianificato, guasto, attesa materiale, cambio formato, pulizia, assenza operatore. Dove la macchina non può fornire una causale completa, l'operatore può integrarla tramite interfaccia guidata. Questa combinazione è spesso più affidabile di un progetto che pretende di dedurre ogni causa esclusivamente dal PLC.
Anche la sincronizzazione temporale conta. Se gateway, PLC e sistemi applicativi usano orari non allineati, la sequenza degli eventi diventa incerta e il calcolo dei tempi perde precisione. Occorre definire inoltre cosa accade in caso di perdita temporanea della connettività: il dato deve essere bufferizzato, trasmesso al ripristino e identificato senza duplicazioni.
Integrare produzione, ERP e qualità senza creare un nuovo silo
Una dashboard real time è più efficace quando riceve il contesto dall'ERP e restituisce dati utilizzabili dai sistemi aziendali. L'ordine di produzione, l'anagrafica articolo, i tempi teorici e le distinte possono qualificare il dato macchina. Al contrario, quantità prodotte, tempi di avanzamento, consumi, scarti e stati di lavorazione possono alimentare consuntivazione, BI o analisi di pianificazione.
Non tutte le integrazioni devono avvenire in tempo reale. Un allarme critico o lo stato di una linea richiedono aggiornamento immediato; un report direzionale può essere aggiornato a intervalli definiti. Separare questi casi evita di progettare architetture più complesse del necessario e protegge i sistemi gestionali da flussi inutilmente frequenti.
Un'architettura cloud-native con agente leggero on-premise riduce la necessità di server locali dedicati e rende più semplice l'accesso via browser da reparti, uffici tecnici e sedi autorizzate. La valutazione deve comunque includere segmentazione di rete, gestione delle credenziali, permessi per ruolo, audit e politiche di conservazione. In ambito OT, rapidità di accesso e sicurezza devono procedere insieme.
PLCinCloud adotta questo approccio collegando protocolli industriali e sistemi gestionali in una piattaforma modulare, con dashboard operative e dati strutturati per KPI, tracciabilità e requisiti di interconnessione.
Progettare le viste per reparto e per turno
La dashboard di reparto deve essere leggibile anche da distanza e in pochi secondi. Per ogni linea, è utile mostrare stato corrente, ordine attivo, quantità buona, target e durata dell'eventuale fermo. Il dettaglio tecnico può essere disponibile con un'interazione successiva, senza appesantire la vista principale.
La vista di turno, invece, deve raccontare ciò che è accaduto: tempi produttivi e improduttivi, scostamento dal piano, scarti, principali causali e confronto con turni o giorni omogenei. Attenzione ai confronti semplicistici. Due turni possono lavorare articoli, lotti o formati diversi, con tempi ciclo e complessità non paragonabili. Il confronto deve usare parametri coerenti, altrimenti premia o penalizza le persone per condizioni non controllabili.
Una vista direzionale può aggregare per stabilimento, reparto o famiglia prodotto. Qui il real time è utile per cogliere eccezioni e trend, non per sostituire il dettaglio operativo. Il management non ha bisogno del singolo tag PLC, ma di sapere dove capacità, qualità o puntualità stanno deviando dagli obiettivi.
Errori che riducono l'adozione
Il primo errore è misurare prima di definire gli standard. Se causali, target e stati macchina non sono condivisi, la dashboard renderà visibili incoerenze già presenti nel processo. Il secondo è partire da decine di KPI. Meglio attivare un perimetro ristretto, verificare che i dati siano credibili e ampliare solo dopo che gli utenti li utilizzano nelle riunioni operative.
Il terzo errore è considerare il progetto concluso alla pubblicazione della schermata. Soglie, layout e logiche di classificazione vanno rivisti dopo alcune settimane di esercizio. La fabbrica cambia: entrano nuovi articoli, vengono aggiornate le macchine, mutano priorità produttive e regole di pianificazione.
Infine, non va trascurata la responsabilità dell'azione. Un alert senza destinatario, tempi di presa in carico e regola di escalation aggiunge rumore. La dashboard deve inserirsi nei rituali esistenti - riunione di turno, gestione anomalie, manutenzione, pianificazione - rendendo queste attività più rapide e documentabili.
Una buona dashboard non si giudica dal numero di quadranti, ma dalla qualità delle conversazioni che genera davanti a una linea. Quando un dato è affidabile, contestualizzato e disponibile nel momento giusto, il reparto può intervenire su un fermo, uno scarto o un ritardo prima che diventino il consuntivo di domani.