Cosa conviene davvero automatizzare con l'IA in fabbrica

Gran parte di ciò che decide l'esito di un progetto di IA in fabbrica non è la modellazione. È dare un nome al tipo di problema che avete, verificare se i vostri dati di esecuzione sono in grado di sostenerlo e progettare cosa succede quando il modello sbaglia.

Regole, machine learning, ottimizzazione e modelli linguistici: cosa si adatta a cosa

Regole e statistica vengono prima e meritano più rispetto di quanto ne ricevano. Se una regola che un tecnico sa scrivere porta a casa gran parte del valore, il confronto onesto per qualunque modello è con quella regola, non con il non fare nulla.

Il machine learning si guadagna il posto dove la relazione tra ingressi ed esito è reale ma nessuno la sa scrivere: decine di variabili di processo che interagiscono, un difetto che dipende dal lotto di materiale, dall'umidità ambientale e dalla posizione in cavità. Conosce le condizioni che gli sono state mostrate e non dice nulla di utile su condizioni che non ha mai visto.

L'ottimizzazione è una disciplina diversa e viene abitualmente spacciata per IA. Schedulare uno stabilimento a capacità finita, sequenziare per minimizzare gli attrezzaggi, assegnare operatori qualificati: sono problemi di vincoli con una funzione obiettivo. Non hanno bisogno di esempi etichettati, ma hanno bisogno di tempi di processo e vincoli onesti, che di solito vanno misurati invece che dati per scontati. Per la pianificazione, un solver capace di esprimere i vostri veri vincoli di attrezzature e di asciugatura è quasi sempre lo strumento giusto, perché pianificare è un problema di vincoli e non un problema di previsione.

I modelli linguistici sono l'ultimo arrivo e il loro campo d'impiego è specifico. Si adattano al lavoro che ha la forma di un documento o di una conversazione: leggere una richiesta in ingresso e redigerne una versione strutturata, condensare un lungo storico di manutenzione in qualcosa che il manutentore possa leggere prima di andare alla macchina, rispondere su cosa dice un'istruzione di lavoro a proposito di un attrezzaggio. Non sono strumenti di misura: chiedere a un modello linguistico di prevedere la rottura di un cuscinetto dai dati di vibrazione è usare il martello su una vite.

Di quali dati ha davvero bisogno un progetto di IA in fabbrica

Un modello ha bisogno di esempi che accoppino una situazione a un esito, con abbastanza contesto da distinguere una situazione dall'altra: un segnale o un insieme di condizioni legati a un ordine, a una macchina, a un'attrezzatura, a un lotto di materiale, a un operatore e a una marca temporale veritiera. La marca temporale conta più di quanto ci si aspetti. Se i consuntivi vengono inseriti a fine turno, tutti gli eventi di quel turno condividono un orario approssimativo, e qualunque cosa dipenda dalla sequenza o dalla durata impara l'abitudine di registrazione invece del processo.

Il lato dell'esito è di solito messo peggio. La manutenzione predittiva ha bisogno che i guasti siano registrati come guasti, con una causa e una data, non come fermo non pianificato con il campo causale in bianco. La previsione della qualità ha bisogno che lo scarto sia dichiarato sull'operazione e sul tipo di difetto che l'ha causato, non aggregato in un numero mensile. La previsione della domanda ha bisogno di uno storico dei consumi che non sia stato riscritto in silenzio dalle rettifiche di magazzino. Nella maggior parte degli stabilimenti gli ingressi stanno nell'historian e gli esiti stanno su un quaderno della manutenzione o nel foglio Excel di una persona sola.

La verifica non è quanti gigabyte contiene l'historian, ma se riuscite a estrarre, per una linea e una famiglia di prodotto, un anno di righe in cui ogni riga porta con sé le condizioni e il risultato, e due persone che conoscono il processo concordano che quelle righe siano vere. Se quell'estrazione richiede una settimana di riconciliazione manuale, il progetto non è il modello: è la registrazione del dato. Per questo la qualità dei dati di MES e historian è il vincolo che determina tutto, e nessuna raffinatezza di modellazione recupera ciò che non è mai stato rilevato.

Previsione della domanda e dei consumi, dove il ritorno è più vicino

La previsione ha di solito la strada più breve verso il denaro, perché l'alternativa è visibilmente debole: quasi tutti gli stabilimenti prendono l'anno scorso e aggiungono una percentuale, oppure chiedono al commerciale un numero che in realtà è un obiettivo. Un modello che usa lo storico degli ordini, la stagionalità, il mix clienti, le trattative aperte e gli effetti di calendario batte quell'approccio sugli articoli a domanda regolare e ripetitiva. Sugli articoli intermittenti e legati alle commesse, spesso la maggior parte dei codici e una quota piccola dei volumi, di solito non lo batte, e una baseline naive o di tipo Croston è difficile da superare. La versione onesta segmenta prima il catalogo e lascia quegli articoli a una politica di scorta e al giudizio delle persone.

Il valore si vede a valle, più che nella previsione in sé: si muovono le scorte di sicurezza, cambiano i tempi di acquisto sugli articoli a lungo lead time e diventano più rari i cambi di attrezzaggio in emergenza che mandano all'aria un programma. Una percentuale di accuratezza della previsione su una slide non è un beneficio; lo sono i giorni di giacenza e il numero di solleciti.

Manutenzione predittiva, solo dove il modo di guasto è davvero prevedibile

Qui tutto ruota attorno al fatto che il guasto si sviluppi gradualmente e lasci una firma in qualcosa di misurabile. Degrado di un cuscinetto, squilibrio, disallineamento, intasamento progressivo di un filtro o di un circuito di raffreddamento, deriva della pressione idraulica, corrente motore che sale lentamente sulla stessa operazione: sono fenomeni che si sviluppano in settimane o mesi, a volte solo in ore, e in quel caso di solito è troppo tardi perché valga la pena strumentare, e si vedono in vibrazione, corrente, temperatura o pressione. Un modello li vede, e spesso li vede anche una soglia scelta bene, ed è per questo che qui il confronto con la statistica semplice conta.

Una scheda di controllo che muore, un utensile spezzato da un inserto difettoso, un danno da errore operatore: sono di fatto istantanei, e nessun modello li prevede da un andamento che non esiste.

La seconda condizione è che il preavviso vi compri tempo utilizzabile. Se il ricambio ha un lead time lungo e la linea non può fermarsi prima del fine settimana, l'investimento che rende è una politica di ricambi, non un modello. Definite la finestra di intervento prima del budget per la sensoristica.

Previsione della qualità e riduzione dello scarto

La qualità è dove di solito sta il denaro maggiore e dove i requisiti sui dati sono più esigenti. La versione attraente prevede, dalle condizioni durante la produzione, quali pezzi o quali lotti sono a rischio, così che qualcuno possa correggere prima che lo scarto sia prodotto invece di trovarlo al collaudo finale.

Funziona quando il processo è strumentato alla risoluzione della cosa che volete prevedere e quando lo scarto porta una causale vera sull'operazione. Fallisce in silenzio quando lo scarto viene dichiarato a fine ordine sull'ordine nel suo complesso, perché allora il modello non può dire quali condizioni abbiano prodotto quale difetto.

Un passo per nulla appariscente si ripaga prima di qualunque modello: raccogliere le causali di scarto alla macchina, nel momento in cui accade, da un elenco corto di cause che l'operatore riconosce. Molti stabilimenti che chiedono la previsione della qualità scoprono da quei soli dati che poche cause spiegano gran parte della perdita, e chiudono la più grande con una modifica tecnica. Questo è un buon risultato, non un progetto fallito.

IA per la schedulazione della produzione: perché è un problema di ottimizzazione e non di previsione

Se il piano salta ogni settimana, la causa è raramente una mancanza di intelligenza e quasi sempre una mancanza di vincoli. A cambiare le cose è uno schedulatore che rispetta le attrezzature condivise, le famiglie di cambio formato, le qualifiche degli operatori, i tempi di maturazione e le finestre di manutenzione che intendete mantenere.

L'apprendimento serve qui in un modo preciso e reale: i tempi di processo. Un programma costruito su tempi standard che nessuno rimisura da anni è preciso sui numeri sbagliati, e le durate reali rilevate dal MES possono aggiornare i dati su cui lo schedulatore lavora. Giudicate una proposta di schedulazione dai vincoli che sa esprimere e dalla velocità con cui ripianifica quando qualcosa si rompe; un piano che per essere rigenerato richiede tutta la notte viene scavalcato a mano nella riunione del mattino.

Rilevamento delle anomalie su segnali energetici e di processo

Il rilevamento delle anomalie impara com'è fatto il normale e segnala lo scostamento. Si adatta ai segnali continui dove avete molto comportamento buono e pochi guasti etichettati: assorbimento energetico per ciclo, consumo di aria compressa, resa del gruppo frigorifero, un segnale di processo la cui forma è stabile quando le cose vanno bene.

Il suo punto di forza è reagire a ciò che nessuno aveva previsto. Il suo punto debole è che dice soltanto che qualcosa è insolito, mai cosa non va, e uno stabilimento che riceve allarmi senza spiegazione impara a ignorarli. Il lavoro di progettazione non è il rilevatore ma l'instradamento: quali allarmi vanno a chi, qual è il primo controllo e come viene registrata la risposta, così che il prossimo allarme della stessa forma arrivi con lo storico allegato.

IA nel commerciale e nel servizio al cliente, dove il lavoro ha la forma di un documento

Il lato commerciale di un'azienda manifatturiera vive di documenti e conversazioni: richieste, specifiche, preventivi, conferme d'ordine, solleciti di consegna, reclami. Qui i modelli linguistici trovano davvero il loro posto, perché il lavoro consiste nel leggere, estrarre, redigere e riassumere.

In concreto: una richiesta in ingresso interpretata in articolo, quantità, data richiesta e requisiti particolari, con accanto i preventivi precedenti richiamati. Uno scambio di email condensato in una registrazione CRM che riporta l'impegno preso e l'azione successiva.

Due regole evitano che vada storto. Il modello redige e una persona invia, almeno finché non si conosce il tasso di errore in quel flusso di lavoro. E qualunque dato di fatto, prezzo, lead time, giacenza, data promessa, arriva dal sistema di registrazione e non dal modello, che deve citare un valore letto e mai generarne uno. Un'automazione del CRM che si inventa un lead time è peggio di nessuna automazione, perché impegna l'azienda.

Quantificare il beneficio prima di comprare qualsiasi cosa

Date un nome alla perdita nelle unità che il vostro stabilimento già misura: costo dello scarto al mese sulla famiglia di prodotto in questione, ore di fermo non pianificato sulla macchina collo di bottiglia moltiplicate per quanto vale lì un'ora in termini di margine di contribuzione e non di costo macchina, trasporti urgenti, capitale immobilizzato negli articoli che una previsione muoverebbe, ore alla settimana passate a ridigitare dati da un sistema all'altro.

Poi stimate, in modo pessimistico, quale quota di quella perdita l'applicazione potrebbe plausibilmente aggredire. La manutenzione predittiva non elimina i fermi; nel migliore dei casi converte alcuni fermi non pianificati in fermi pianificati, per i modi di guasto che copre. Un modello di qualità non elimina lo scarto; accorcia il tempo tra un processo che va fuori controllo e qualcuno che se ne accorge.

Se quel numero onesto, messo a confronto con un costo totale sulla vita utile che pianifichereste davvero, integrazione e persone che lo faranno funzionare comprese, non supera la soglia che la vostra funzione finanziaria applica a qualunque altro investimento di quella dimensione, il progetto è un esperimento scientifico. È legittimo, ma va finanziato e giudicato come tale.

Quanto costa davvero l'integrazione

Il modello è di solito la parte economica; il costo sta nelle giunzioni. Portare fuori i segnali dalle macchine viene per primo, e uno stabilimento reale è un parco misto: alcuni asset parlano OPC UA, altri Modbus o un protocollo seriale, altri offrono un contatto pulito, e alcuni controlli chiusi richiedono un sensore in retrofit sul mandrino, sul circuito idraulico o sulla linea di alimentazione. Poi l'output deve atterrare da qualche parte dove provochi un'azione: uno schermo che l'operatore già guarda, un ordine di lavoro aperto in manutenzione, un vincolo passato allo schedulatore, un blocco applicato in qualità.

Dopodiché arriva la riconciliazione dei dati anagrafici che nessuno mette a preventivo. Codici articolo che differiscono per un suffisso tra un sistema e l'altro, unità di misura che non coincidono, una distinta base mantenuta in due posti, identificativi macchina cambiati quando la linea è stata riorganizzata. Nulla di difficile e tutto più lungo del software. Un'offerta che quota il modello e lascia le giunzioni come integrazione da definire non è un prezzo.

Chi gestisce il modello e cosa succede quando sbaglia

Ogni modello messo in esercizio ha bisogno di un responsabile con nome e cognome, e la domanda da fare in fase di acquisto è chi sarà, nella vostra organizzazione, quella persona. Deve sapere su cosa il modello è stato addestrato, quali condizioni ricadono fuori da lì, perché ha prodotto un certo output e come toglierlo dal ciclo senza fermare la produzione. Un modello che smette di rispondere deve ricadere su ciò che governava il processo prima di lui, il piano di campionamento, la soglia, il controllo dell'operatore, e non su un cancello aperto o su una linea bloccata. Decidete quale dei due prima del go-live.

La spiegabilità non è una questione filosofica in reparto, è un requisito di adozione. Una raccomandazione che dice quale segnale si è mosso, di quanto e rispetto a quale riferimento viene seguita. Un punteggio senza motivazione viene scavalcato, e quando scavalcarlo diventa la norma il sistema è un soprammobile.

L'eccesso di allarmi distrugge la fiducia più in fretta delle mancate rilevazioni, per la stessa ragione per cui su una stazione di collaudo lo fa l'eccesso di scarti buoni: un falso allarme è visibile subito e a tutti, una mancata rilevazione resta invisibile finché il guasto non arriva. Dimensionate la frequenza degli allarmi sull'attenzione realmente disponibile in reparto e instradate la fascia di incertezza verso una persona, non verso la linea.

Governance, deriva e l'onere di manutenzione che nessuno mette a budget

Un modello è una fotografia del vostro processo nel momento in cui è stato addestrato, e il vostro processo si muove: un nuovo fornitore, la revisione di un'attrezzatura, una modifica di disegno, una riorganizzazione della linea, un mix di prodotto cambiato, un sensore sostituito con uno leggermente diverso. Ognuno di questi può spostare gli ingressi abbastanza da rendere silenziosamente sbagliato oggi il modello di ieri, e il modo di guasto non è un messaggio di errore ma un consiglio progressivamente peggiore.

Monitorate gli ingressi oltre alle uscite, perché la deriva degli ingressi si vede prima del degrado dell'esito. Tenete da parte un set di test di casi reali, casi al limite compresi, così che un nuovo modello possa essere confrontato onestamente con quello in uso. Versionate il modello e registrate quale versione ha prodotto quale raccomandazione; dopo un riaddestramento, gli output di ieri vengono da un giudice diverso.

E mettete a budget lo sforzo continuativo. Un modello in produzione è un asset da manutenere, più vicino a un impianto di processo che a un report acquistato. Se nessuno ha tempo assegnato per riaddestrarlo, esaminare gli allarmi e verificare che i dati continuino ad arrivare, degraderà finché le persone smetteranno di usarlo.

Un primo progetto realistico, con criteri di accettazione

Scegliete una perdita ben definita su una linea o una famiglia di prodotto, enunciata come una frase con dentro un numero: scartiamo questa quantità su questa operazione, perdiamo queste ore di collo di bottiglia su questa macchina, teniamo questa giacenza perché non sappiamo prevedere questa famiglia. Se il progetto non si può enunciare così, non è pronto.

Prima di comprare qualsiasi cosa, fate l'estrazione dei dati. Un anno, una linea, condizioni ed esiti nelle stesse righe, due persone che conoscono il processo a confermare che le righe siano vere. Poi misuratevi con l'alternativa semplice: una soglia, una carta di controllo o il giudizio dell'attuale pianificatore.

Scrivete i criteri di accettazione nelle unità dello stabilimento prima del go-live, a coppie, così che il compromesso sia esplicito. Per la manutenzione predittiva, un numero dichiarato di modi di guasto coperti e intercettati con almeno una settimana di preavviso, a fronte di un tetto di falsi allarmi al mese. Per la previsione della domanda, una riduzione dichiarata dei giorni di giacenza sulle famiglie modellate senza aumento delle rotture di stock. Per la qualità, una riduzione dichiarata dello scarto sull'operazione bersaglio rispetto agli stessi mesi dell'anno precedente, con accanto registrate le modifiche di processo.

Indicate nello stesso documento il responsabile, il comportamento in caso di guasto e il piano di riaddestramento, e fissate una data di revisione con l'onesta possibilità di fermarsi. Un primo progetto che si chiude con la decisione di non estenderlo, presa sulle evidenze, è un successo. Un pilota che diventa una dimostrazione permanente non lo è.

Dove si colloca Meta Smart Factory

Meta Smart Factory è modulare, e qui la cosa conta perché il modulo IA e machine learning sta sopra il livello di esecuzione e non accanto ad esso. Il MES fornisce gli eventi e il contesto, la connettività IIoT e OPC UA forniscono i segnali macchina, il modulo Qualità fornisce lo scarto con le sue causali, la Manutenzione fornisce lo storico dei guasti e l'APS consuma l'output là dove la risposta è un programma di produzione e non una previsione.

Potete partire da un modulo su un vincolo ben definito e aggiungere il successivo quando il primo è in uso. Ciò che nessuna piattaforma toglie di mezzo è la parte difficile: mettersi d'accordo su cosa significano i numeri, far raccogliere le causali alla macchina e decidere chi risponde di un modello quando sbaglia. Ragionare su questa sequenza per uno stabilimento specifico è una prima conversazione più utile di una dimostrazione, perché una dimostrazione funzionerà sempre.