Quali dati mi servono per questa soluzione di AI industriale?

I dati e l’AI

Le soluzioni di machine learning, deep learning, automated data processing e chi più ne ha più ne metta hanno bisogno di raccogliere i dati dal campo. Versi di meraviglia e stupore.

In particolare l’AI ha bisogno dei dati del passato per imparare e di quelli del futuro per predire. E se si utilizza uno specifico dato in fase di allenamento, questo deve essere necessariamente disponibile.

Come raccogliamo i dati?

Quando parliamo di dati in industria parliamo di una rosa di opzioni non indifferente:

• I dati dai sensori di campo (PLC, SCADA, IIoT): rappresentano le variabili di processo in real time, e sono la base di ogni sistema in grado di fare previsioni in base al vero comportamento del sistema
• I dati dai MES: dipendono molto dalla configurazione specifica del cliente, e raccolgono le informazioni utili per fotografare il processo produttivo – stati macchina, volumi prodotti, ordini, operatori e così via. Di solito sono popolati automaticamente.
• I dati dagli ERP: raccolgono tutte le informazioni di acquisti, vendite, bom, e in alcuni casi la pianificazione, secondo procedure manuali o semi-automatiche
• I dati dagli altri sistemi di gestione della qualità e del processo: hanno una frequenza più bassa e sono aggiornati secondo procedure semi-automatiche, potrebbero rappresentare ricambi, qualità delle materie prime, regolazioni o ricette
• I dati di manutenzione: hanno una frequenza più bassa e di solito sono inseriti a mano, rappresentano gli interventi di manutenzione pianificata, correttiva o altro.

Selezionare i dati giusti

Una delle domande più spinose in ambito AI e data science è come si scelgono i dati? Si possono scegliere in anticipo?

Considerando che i dati sono alla base delle soluzioni data-driven, è una buona domanda da porsi, che di solito funziona meglio dell’approccio all-in.

Partire dall’obiettivo

Come sempre, per essere sicuri di non sbagliare bisogna tenere a mente cosa si vuole sviluppare: un sistema di controllo performance? Una soluzione di raccomandazione per il miglior ricambio? Un report che suggerisca la migliore pianificazione per le successive ore?

A partire dalla necessità di business, si identifica il task dell’algoritmo, e si prova ad immaginare la strategia migliore per la previsione.

La stragrande maggioranza delle applicazioni in industria sono di apprendimento supervisionato. Il task quindi potrebbe essere prevedere il consumo o una specifica temperatura, oppure prevedere un guasto.

Ecco quindi che abbiamo selezionato il primo e più importante parametro, il nostro output.

Quale benchmark?

Per raggiungere l’obiettivo identificato spesso ci sono già in campo delle procedure meno smart: limiti statici, verifica manuale, semplici modelli di regressione…

La quantità di dati è direttamente correlata alla precisione che si può raggiungere con il modello: è necessario quindi capire qual è la performance minima sotto cui non ha senso implementare nulla.

In base a quello, si cerca di mappare il processo e capire quali dati sono i più importanti per rappresentare al meglio il fenomeno, che diventeranno i nostri input.

Mappare il processo

La mappatura del processo si basa fortemente sulla competenza di dominio, quindi è buona cosa coinvolgere le persone che conoscono bene il sistema. Selezionare i dati da MES o ERP è relativamente facile in quanto rappresentano più o meno sempre le stesse cose – quando la macchina si è accesa o spenta, quanti pezzi ha fatto, chi stava lavorando in un preciso momento… Selezionare i parametri da sensori invece in alcuni casi può diventare complesso. In questi casi è utile uno schema del processo: utilizzare un P&I, o una sintesi dei principali asset e delle loro interazioni, è il miglior modo per focalizzare bene i flussi che entrano e che escono, e come è regolato il tutto.

Una volta chiaro il sistema, si definisce il perimetro. Il perimetro racchiude tutti gli asset e i processi che si vogliono modellare con un singolo modello, e interagisce con l’ambiente esterno. In base all’obiettivo, il perimetro è più o meno ampio e frammentato.

Dal perimetro si capisce cosa entra, cosa esce e cosa influenza il sistema. La mappatura più completa possibile ispirata al bilancio exergetico è la seguente:

• Flussi in ingresso e in uscita: portata, temperatura, qualità di ogni flusso in ingresso. La qualità dipende dall’uso del flusso: per il vapore potrebbe essere il titolo, per il gas il PCI, per l’acqua potrebbe non essere necessario.
• Energia consumata e prodotta: tensione, corrente, potenza, cosfi, energia
• Materie prime: quantità, qualità, caratteristiche
• Prodotto: quantità, qualità, caratteristiche
• Dissipazioni in ambiente: calore, vibrazioni, rumore
• Interazioni non controllate dall’esterno: temperatura, umidità, pressione ambientale, ma anche irraggiamento e piovosità
• Regolazioni: apertura o chiusura delle valvole, setpoint di temperatura o frequenza, spessori o altro che viene deciso da un operatore o un sistema di controllo

Ai dati di processo si aggiungono i dati di manutenzione, di gestione della produzione ed eventuali altre informazioni dai sistemi di gestione qualità o ERP.

Attenzione: nel caso in cui si voglia predisporre un sistema di manutenzione predittiva all-in-one (un modellino multiclasse che prevede contemporaneamente i guasti di ogni asset con dettaglio sul modo di guasto o uno sguardo diagnostico) è suggeribile trattare ogni asset con un perimetro dedicato.

Dati inevitabili, dati interessanti, dati vietati

Ora abbiamo la lista di tutti i dati che nel mondo dei sogni ci servirebbero per avere modelli ultra-precisi.

Però, sappiamo che non sempre utilizzare tutti i dati è un bene. Cerchiamo quindi di capire di questi dati quali sono da tenere e quali da scartare:

• Dati necessari: quelli che sicuramente influenzano il fenomeno che vogliamo modellare. Potrebbero essere le portate e i consumi se si vuole costruire un modello di performance per una pompa, o la temperatura degli avvolgimenti, la corrente, la tensione e la temperatura ambiente se si vuole costruire un sistema di anomaly detection per un motore elettrico. I dati necessari dipendono molto dal benchmark di riferimento, e di solito utilizzano gli stessi dati o pochi dati aggiuntivi.
• Dati interessanti: alla lista dei dati necessari si aggiunge la lista di tutti quei dati che potrebbe essere interessante valutare. Ad esempio, la temperatura del fluido, la pressione o le vibrazioni per le pompe, o magari l’irraggiamento e l’umidità dell’aria per i motori elettrici. I dati interessanti sono dati che intuitivamente potrebbero influenzare il sistema, ma che non sappiamo se effettivamente concorrono al miglioramento del modello.
• Dati vietati: bisogna poi identificare tutti i dati che è necessario escludere per evitare di confondere il modello. Ad esempio, se si vuole costruire un modello di anomaly detection per una pressa idraulica monitorandone la forza di chiusura stampo, è bene escludere la temperatura dell’olio idraulico dal set di feature. Quando un componente come una guarnizione inizia a deteriorarsi, la perdita di pressione interna causa un aumento della temperatura dell’olio – un effetto collaterale diretto del guasto. Se il modello include la temperatura, impara ad associare forze di chiusura anomale a temperature elevate, e interpreta la deviazione come “normale dato il calore”: l’anomalia viene mascherata invece di essere intercettata. Scontato dire che i dati che appartengono ad altre linee o altri processi sono da escludere a meno che non ci siano interazioni non rappresentabili in altri modi.

Un dato esce, un dato entra

Una volta selezionati i dati che vogliamo raccogliere, bisogna capire come raccoglierli. Gli scenari tipici in cui ci possiamo trovare sono anche in questo caso molteplici:

1. Ci sono solamente i dati raccolti a mano sui sistemi di gestione. In questo caso, partire con un modello data-driven potrebbe non essere la cosa più saggia (o fattibile!) ma è possibile valutare quali sono i sistemi o i processi più critici, analizzarli e impostare un pilota di raccolta dati concentrandosi sui dati necessari.
   • Tenete in considerazione il tempo per raccogliere una base dati sufficiente!
2. Ci sono i dati raccolti a mano e sul MES, ma i dati di processo sono solo sul PLC della macchina, in real-time e non storicizzati. In questo caso partiamo avvantaggiati: basta guardare sul manuale quali dati ci sono, e raccoglierli con un gateway in campo o un PC industriale. Quello che manca invece si installa.
   • In questo caso, potremmo avere alcuni dati aggiuntivi gratis, tanto una volta che il PLC è collegato è possibile raccogliere tutti i parametri in un colpo solo.
   • Anche qui, è comunque necessario un tempo minimo per costruire lo storico.
3. Tutti i dati da MES, ERP e dal campo sono storicizzati e disponibili. Questa è la situazione ideale per partire con un PoC o una sperimentazione data driven. Recuperiamo nel modo migliore i dati e iniziamo ad esplorarli.
   • In questo caso, possiamo permetterci di sperimentare molto di più, mettendo e togliendo i dati interessanti per trovare la progettazione migliore.

Quando serve installare, bisogna tenere a mente che alcune installazioni costano più di altre. Ad esempio il flussimetro è molto invasivo e costoso, mentre i multimetri di solito costano meno. Installare un MES è un percorso complesso che prevede un cambio di paradigma in azienda. In questa fase, il consiglio è chiedersi se alcune delle grandezze necessarie possono essere rappresentate da altri parametri più semplici da raccogliere, e quali semplificazioni si possono tollerare. Ad esempio, se ci serve il flusso in ingresso al sistema, e c’è una pompa per il ricircolo, possiamo pensare di utilizzare l’assorbimento della pompa invece che la portata. Se servono gli stati macchina e abbiamo il consumo, assorbimenti sotto soglia possono essere usati per capire se la macchina era accesa o meno.

Trial-and-error

L’ultimo passo è verificare le varie ipotesi. Fate molti tentativi con modelli diversi e set di dati differenti, per vedere se i dati interessanti lo sono davvero, e se le performance superano il benchmark o se manca qualcosa.

Il processo è mooooolto iterativo, vi troverete a buttare decine di modelli e testare diverse combinazioni di dati prima di trovare quello giusto. Il consiglio è tenere sempre a mente l’obiettivo business e le ipotesi sui dati fatte in fase di mappatura.

Concludendo

Per selezionare i dati giusti, è necessario chiedersi prima di tutto cosa si vuole ottenere. In base alla risposta, si seleziona il parametro target – il nostro output – e si analizza il sistema da modellare. L’analisi si basa sul perimetro, da cui entrano ed escono flussi, regolazioni ed interazioni. Ogni elemento è da caratterizzare da parametri di processo, per capire cosa servirebbe nella migliore delle ipotesi.

Con la lista di tutti i parametri possibili, si fa una scelta rispetto a quali sono indispensabili, quali utili e quali dannosi. Una volta raccolti i dati, si inizia il processo di modellazione con le sue iterazioni.