Part Production Cell

Livello MES e KPI didattico

Come lo stato del PLC diventa un risultato d’ordine chiaro

Questo caso didattico mostra come un livello MES possa affiancare un PLC. Il controllore resta la fonte dei fatti: stato della cella, guasti e contatori. Il MES aggiunge il contesto temporale e dell’ordine, mentre la Dashboard riunisce il risultato.

Ho seguito uno scenario dalle azioni dell’operatore fino agli eventi e al calcolo. Così è possibile non solo vedere l’OEE, ma anche capire da dove proviene ogni durata e quale causa ha inciso sulla Disponibilità.

Le schermate mostrano parti diverse dello scenario: transizioni di stato, validazione dell’OEE e Pareto finale. Lo storico condiviso permette di ricondurre ogni metrica a un evento e a una regola di calcolo.

PLC → MES

eventi, OEE e tracciabilità

Part Production Cell — MES & OEE Summary

Il problema

Conservare lo storico dell’ordine, non solo lo stato corrente

L’HMI aiuta l’operatore a lavorare con la cella. Il MES risolve un compito diverso: conserva cosa è successo a un singolo ordine, quanto è durato e come ha influito sul risultato finale.

Part Production Cell — MES & OEE Overview

PLC — fonte dei fatti

Il PLC conserva lo stato della cella, il codice di guasto, il consenso di marcia e i contatori di produzione. L’HMI mostra questi fatti invece di sostituirli con uno stato locale dell’interfaccia.

MESCollector — contesto e tempo

Un Gateway Timer legge i fatti del PLC e registra la base dell’ordine, lo stato e gli eventi. Non comanda il PLC e non calcola i KPI.

SQL e Dashboard — visualizzare il risultato

Le Named Query riuniscono lo storico dell’ordine. La Dashboard mostra il risultato calcolato, ma non può creare dati di produzione né modificare la logica della cella.

Contesto dell’ordine

Un ordine passa attraverso stati chiari

All’avvio, un ordine riceve un target, la base dei contatori, l’ora di inizio e uno stato. Mentre è attivo, MESCollector associa i fatti del PLC al suo order_id. Con ORDER COMPLETE il confine del report viene fissato, così una Dashboard aperta non può modificare le durate.

FEED

Nel caso #2009, la cella accetta il materiale. Il MES associa questo stato normale all’order_id attivo.

Intervento dell’arresto di emergenza

La cella entra in FAULT quando E-STOP OK viene interrotto. Il MES conserva il codice di guasto 60 con l’order_id attivo.

Guasto e ripristino

E-STOP viene mantenuto come causa del FAULT. Dopo il reset, il MES aggiunge FAULT_CLEARED e STATE_PAUSED, così il ripristino resta nello storico dell’ordine.

Registro MES

Gli eventi aggiungono la sequenza che manca a un singolo tag PLC

production_events conserva ora, order_id, stato, contesto del guasto e tipo di evento. Invece di un’altra istantanea della schermata, il registro mantiene la transizione: pezzo conforme o scartato, mancanza di materiale, guasto, ripristino del guasto e cambi di stato.

Classificare ogni pezzo

PIECE_GOOD e PIECE_REJECT conservano il risultato di ogni pezzo. Good, Reject e Total sono calcolati dalla base dell’ordine, non dal contatore complessivo della macchina.

Conservare i cambi di stato

STATE_* crea la sequenza: feed, clamp, process, inspect, release, pause e fault. Questa sequenza supporta il calcolo delle durate.

Associare un guasto al suo ordine

FAULT_STARTED e FAULT_CLEARED conservano il codice di guasto con l’order_id attivo. La Dashboard mostra sia l’errore corrente sia la sua posizione nello storico dell’ordine.

Dal registro al KPI

La durata deriva dai confini degli eventi

SQL calcola la durata tra eventi vicini. Gli eventi simultanei di pezzo e stato restano marcatori invece di creare un intervallo aggiuntivo. Il report mostra quindi un bilancio chiaro tra tempo totale, pausa, guasto, attesa del materiale e tempo di funzionamento.

Una causa per intervallo

Un intervallo viene verificato prima per un guasto, poi per una pausa dell’operatore e infine per la mancanza di materiale. Così lo stesso tempo non viene conteggiato due volte.

La pausa resta visibile

PAUSED dell’operatore è una pausa di lavoro pianificata. Resta nella ripartizione, ma non fa parte del tempo di produzione pianificato e non riduce la Disponibilità.

Il tempo è allocato completamente

Per #2010, unclassified_ms = 0. Tutto il tempo osservato viene assegnato a categorie chiare invece di sparire tra un rilevamento e l’altro.

OEE e miglioramento

Una metrica è utile quando condizioni e cause delle perdite sono visibili

La Prestazione richiede un ciclo ideale e l’OEE richiede tre componenti validi. Se mancano dati, la Dashboard mostra correttamente N/A. Il Pareto conserva quindi solo le cause che hanno davvero ridotto la Disponibilità.

Il ciclo ideale è un input dell’OEE

Per l’ordine #2010 completato, il calcolo riceve ideal_cycle_time_ms = 5.000. È usato solo per la Prestazione: la schermata mostra il 96,7% di Prestazione e il 100% di Qualità. Non influisce sul movimento del PLC.

Non mostrare una percentuale falsa

Con ideal_cycle_time_ms = 0, la Prestazione non viene mostrata come percentuale e l’OEE diventa N/A. Disponibilità e Qualità restano visibili. Ripristinando 5.000 ms, il calcolo torna disponibile.

KPI finali e Pareto delle perdite

KPI finali: Disponibilità 54,3%, Prestazione 80,5%, Qualità 76,9% e OEE 33,6%. Il Pareto mostra perché la Disponibilità è diminuita: l’arresto di emergenza ha richiesto più tempo, seguito dalla mancanza di materiale.

Cosa mostra il caso:

PLC, MES e Dashboard hanno ruoli chiari e separati
Lo storico dell’ordine basta a spiegare durate e KPI
Il Pareto aiuta a individuare le cause che hanno davvero ridotto la Disponibilità

Altri progetti

Conveyor Sorting

OpenPLC e Ignition: logica Ladder, macchina a stati in Structured Text, feedback dei sensori e cicli normali verificabili.

Vedi il caso studio

Tank Level Control

OpenPLC, Modbus TCP e Ignition: dalla logica Ladder a uno scenario operatore verificabile.

Vedi il caso studio

Monitoring — UPL

Monitoraggio enterprise per una centrale nucleare: stati del sistema, vincoli ingegneristici e logica 3D degli stoccaggi.

Vedi il caso studio