Un caso d'uso reale: Gestione delle ricette

Introduzione

Il cliente è un produttore leader di valvole e componenti per la gestione dei fluidi per applicazioni HVAC e industriali. La divisione Power Solution ha richiesto una soluzione MES (Manufacturing Execution System) in grado di gestire il processo di assemblaggio delle pompe idrauliche, ovvero una soluzione in grado di gestire l'estrema varietà di ricette e la tracciabilità delle unità lungo la linea di assemblaggio.

Tra questi due obiettivi fondamentali, la sfida principale è stata quella di gestire l'enorme numero di ricette per un singolo prodotto finale in modo estremamente configurabile, senza ricorrere a una "codifica rigida" di un'enorme quantità di informazioni. Quest'ultima soluzione non solo avrebbe reso inaccettabili le prestazioni, ma avrebbe anche portato a una manutenzione dei dati estremamente inefficiente.

Contesto di produzione

Il processo di assemblaggio di un prodotto (o meglio di una famiglia di prodotti) realizzato all'interno della divisione energia è estremamente variabile. In altre parole, sebbene il numero e il tipo di operazioni di lavoro siano sempre gli stessi per tutte le unità appartenenti a quella famiglia, due unità possono variare per una serie di motivi che possono andare da un diverso spostamento dell'etichetta del nome a una forma, un colore e/o dei sottogruppi completamente diversi.

Ad esempio, per un prodotto denominato pompa H1P, le operazioni di lavoro saranno sempre:

1. Caricamento dell'alloggiamento - Piatto oscillante - Servo pistoni - Servo cilindri - Porta magneti.
2. Perni di fissaggio - Guarnizione - Piastra di bloccaggio.
3. Albero di carico - Cuscinetto a pressione - Blocco cilindri di montaggio - Valvole di carico - Sensore di pressione.
4. Boccola di carico - Protezione del carico - Guarnizione superiore - Blocco cilindri olio - Testata di serraggio - Pompa di carica - Vaselina - Sensore di velocità.
5. Scansione HPVR - Piastra di spinta - Adattatore coperchio - Prova di rotazione della coppia - Movimentazione a vuoto.
6. Prova finale.
7. Vernice.

Tuttavia, il numero di varianti possibili all'interno della stessa famiglia H1P è di circa 500. Come variano queste 500 varianti se sono assemblate "allo stesso modo"? Ad esempio, l'operazione di "caricamento dell'alloggiamento" (#1) potrebbe essere eseguita utilizzando viti diverse a seconda del lotto specifico di unità, oppure l'operazione di "supporto della pressa" (#3) potrebbe essere eseguita utilizzando forze di pressatura diverse e così via. Le differenze possono variare da "minime" a "enormi", portando a un numero elevato di variazioni all'interno della stessa famiglia; i prodotti più configurabili potrebbero avere più di 2.000 varianti possibili.

Ma come può un ingegnere di processo distinguere una variante dall'altra? Il "trucco" utilizzato dal cliente consiste nell'assegnare una distinta base (BoM) diversa a ogni possibile variazione. Nel caso in cui vari un pezzo utilizzato, è abbastanza ovvio come ciò possa accadere, mentre potrebbe non essere così se la differenza è data da un diverso colore di vernice o dallo spostamento della targhetta. Questo "problema" viene superato riservando un posto nella BoM anche agli elementi "non fisici" (come il colore della vernice) e assegnando a ogni elemento della BoM un designatore di riferimento (chiamato sort string dalla terminologia SAP), che tipicamente definisce lo spostamento di un elemento all'interno del progetto CAD.

In base a questi elementi, guardando una BoM, gli ingegneri di processo possono capire se hanno a che fare con la variante A piuttosto che con la variante B:

• Voce di BoM: A potrebbe avere un elemento della BoM che B non ha e viceversa (una vite, un sottoassieme diverso, un colore di vernice diverso);
• Stringa di ordinamento: A e B condividono lo stesso articolo, ma collocato in una posizione diversa;
• Master Model Code: il codice modello assegnato a un ordine di produzione può cambiare da variante a variante.

Considerando tutti questi elementi e sfruttando la suite Siemens Opcenter Execution (SIMATIC IT), i fattori determinanti presi in considerazione dall'Engineering per trovare la soluzione ottimale sono stati:

• Volume dei dati: avere in media centinaia di ricette per ogni famiglia di prodotti avrebbe portato a un'enorme quantità di dati all'interno del database;
• Flessibilità dei dati: la mappatura di un singolo BoM in un PPR porterebbe a una configurazione strettamente statica; un ambiente di produzione con così tante varianti è tale perché le esigenze di produzione sono estremamente flessibili e possono facilmente cambiare nel tempo in base alle richieste dei clienti, e una soluzione progettata in modo statico non può far fronte a tali requisiti;
• Manutenzione dei dati: le modifiche applicate a qualsiasi parte non sarebbero state facilmente propagate.

La soluzione

La soluzione sviluppata per questo cliente, nota come "modulo di gestione delle ricette", si basa sul concetto di regola di produzione; una regola di produzione serve a definire un'azione da intraprendere nel caso in cui una specifica variante sia in lavorazione in una determinata stazione.

Ogni regola di produzione può essere suddivisa in tre parti:

1. stazione di destinazione (operazione di lavoro);
2. criterio di applicabilità (in quali casi la regola deve essere applicata);
3. corpo della regola (cosa deve essere fatto).

Il punto #1 risponde alla domanda "Sto lavorando la variante di produzione "abc"" (oppure "Sto lavorando le varianti di produzione "abc"/"def"/..."). Il punto #2 definisce cosa fare nel caso in cui la risposta al punto #1 sia positiva. Per la sua natura, il punto #1 deve essere definito facendo riferimento:

• quegli elementi del BoM che possono distinguere una variante da un'altra, ad esempio il numero di voce del BoM, la stringa di ordinamento o il codice del modulo;
• a un livello ancora più alto, quegli elementi che possono distinguere una famiglia di prodotti da un'altra, ad esempio la posizione di stoccaggio del materiale finale.

In questo modo, un ingegnere di processo può definire regole per un'intera famiglia di prodotti (granularità maggiore) o per una variante molto specifica (granularità minore).

Il punto 2 definisce cosa deve essere fatto nel caso in cui la regola sia applicabile. Le azioni possibili possono essere

• utilizzare uno strumento specifico;
• prelevare un pezzo da un magazzino "Pick To Light";
• mostrare una EWI (Electronic Work Instruction);
• stampare un'etichetta o un cartellino;
• inviare una conferma a SAP.

Le regole di produzione vengono tipicamente scaricate nel livello di controllo per essere applicate. Ad esempio, nel caso delle regole per gli strumenti, l'ID dello strumento e una serie di parametri di lavoro vengono inviati al controllore della linea che attiverà automaticamente lo strumento, segnalando visivamente all'operatore quale strumento utilizzare e/o preimpostandone i parametri di lavoro.

Per semplificare l'implementazione, la soluzione fornita al cliente astrae dal "modo effettivo" in cui i dati vengono inviati al controllore di linea (inviando un XML), ma è in grado di scrivere direttamente i dati nei registri del PLC.

Come e quando vengono calcolate le regole

Quando un nuovo ordine è disponibile, viene importato insieme al suo BoM dal modulo di gestione delle ricette. Il gestore delle ricette esamina quindi la BoM e, stazione per stazione (cioè inserimento dell'ordine di produzione per inserimento dell'ordine di produzione), controlla le regole definite per la stazione corrente e identifica quelle che hanno un criterio di applicabilità "corrispondente".

Poiché le regole possono essere etichettate con un numero di sequenza dall'ingegnere di processo che le definisce, per ogni ordine, l'intero processo risulterà in uno "script" per ogni singola stazione. In altre parole, Opcenter Execution (SIMATIC IT) "conoscerà" tutte le micro-operazioni da eseguire in una determinata stazione e le scaricherà nel livello di controllo o le applicherà direttamente.

Un'ultima parola sulle regole riguarda il modo in cui vengono scaricate nel livello di controllo. La soluzione si basa su un protocollo di comunicazione in 4 fasi; per ogni unità, il livello di controllo

1. chiede l'autorizzazione a lavorare al numero di serie della stazione (interlocking);
2. richiedere tutte le regole applicabili in sequenza;
3. caricare i risultati effettivi per ogni regola applicata (forza di pressione effettiva, angolo, coppia ecc.);
4. infine, confermare se l'output è buono o se si tratta di uno scarto.

Questa soluzione, sebbene "più lenta" in quanto comporta un overhead di comunicazione, consente una comunicazione sincrona tra Opcenter Execution (SIMATIC IT) e il livello di controllo, in modo che la produzione possa essere fermata e ripresa in caso di necessità. Inoltre, il modulo di gestione delle ricette consente di scaricare tutte le regole applicabili in una sola volta e di farle rivedere al livello di controllo intelligente.