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 stiamo parlando di tre tipologie di dato:

• I dati dai sensori di campo: hanno una frequenza più o meno alta e sono aggiornati automaticamente, rappresentano il processo in continuo
• I dati dai 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 che più spesso mi vengono fatte è 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 le condizioni di pre-guasto.

Ecco quindi che abbiamo selezionato il primo e più importante parametro, il nostro output. Il consiglio è selezionare grandezze i cui sensori sono semplici da manutenere – se si rompe quello si butta tutto il modello!

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. Io di solito parto da uno schema del processo: un P&I, o una sintesi dei principali asset e delle loro interazioni, in modo da 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 è 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.

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 inevitabili: quelli che sicuramente influenzano il modo di guasto o la performance di un sistema. 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 i trasformatori. I dati inevitabili dipendono molto dal benchmark di riferimento, e di solito utilizzano gli stessi dati o pochi dati aggiuntivi.
• Dati interessanti: alla lista dei dati inevitabili 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 trasformatori. I dati interessanti sono dati che intuitivamente possono 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 un condensatore monitorandone la pressione a vuoto, è bene escludere la temperatura di scarico del condensatore stesso, in quanto se la temperatura di condensazione aumenta significa che c’è stata una variazione alla pressione di condensazione, ma il modello vedendo una temperatura in aumento si spiegherebbe anche la variazione in pressione e non intercetterebbe l’anomalia. 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. Ricordiamoci che i dati devono essere necessari sia nello storico che nel presente.

Ci sono 3 situazioni tipiche che si trovano in giro.

1. I dati non ci sono neanche a piangere. In questo caso, il consiglio è installare i dati inevitabili e una parte di quelli interessanti, quelli che magari possono essere utili anche per monitorare altri aspetti del processo.
   • Tenete in considerazione il tempo per raccogliere una base dati sufficiente!
2. I dati ci sono ma sono 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. I dati ci sono su un HMI, uno SCADA, o un datalake. Siamo a cavallo! 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. In questa fase, il consiglio è chiedersi se alcune delle grandezze inevitabili possono essere rappresentate da altri parametri più semplici da raccogliere, e quali ipotesi stiamo inserendo. 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. L’attenzione da avere è che se la pompa si rompe assorbirà di più a parità di portata, e potrebbe influenzare il modello a valle.

Fail a lot, model more

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.