Manutenzione predittiva, prescrittiva e Industria 4.0

Il Piano industria 4.0 sta portando nume­rosi cambiamenti nei modelli di business e nell’automazione dei processi. Stiamo vivendo un periodo movimentato in cui le tecnologie abili­tanti, IoT, cloud, big data, analytics, realtà aumen­tata ne rappresentano il substrato tecnologico e che, a differenza del modello tedesco maggior­mente orientato alla ricerca di nuove tecnologie, è volto a favorire l’applicazione di ciò che esiste già.

Secondo il Prof. Paolo Pinceti nell’illuminante ar­ticolo “Industria 4.0 moda, fede e fantasy” pub­blicato da “Automazione Oggi” nell’ottobre 2017, grazie alla tecnologia IoT la comunicazione tra apparati è ora più semplice, aperta e fruibile. Biso­gna tuttavia considerare i rischi derivanti dallo svi­luppo e dall’implementazione di queste tecnologie, come l’impatto sulla sicurezza funzionale che richiedono apparati certificati e la cyber security che possono aprire falle nei sistemi a tutti i livelli.

Impatti delle nuove tecnologie sull’Asset Management

Se ci focalizziamo sull’impatto di tali tecnologie sull’Asset Management, possiamo notare che la disponibilità di informazioni (cloud) e la sempre maggior capacità di gestire grandi moli di dati stanno spostando l’attenzione da ciò che tradi­zionalmente sono stati i processi “Human Cen­tered”, ad aspetti di “Automation Centered” e “Data Centered”. Tale tendenza è stata dimo­strata anche da molti studi, tra cui quelli effettuati dall’Osservatorio 4.0 di A.I.MAN. e dall’Osserva­torio Tecnologie e Servizi per la Manutenzione di TeSeM POLIMI.

Essendo i tre aspetti del tutto interconnessi, è necessario un re-engineering dei modelli di ge­stione, che implica un adattamento dei sistemi esistenti alle nuove prassi. Quando parliamo di sistemi esistenti intendiamo in primis i tradizionali EAM Enterprise Asset Management, tipici siste­mi “Human Centered”, che sono stati scarsamente implementati negli ultimi dieci anni e sicuramente in pochissime PMI, impiegati soprattutto per gestire aspetti di supporto alla Qualità.

Il lungo periodo di crisi economica e le conseguenti ristrutturazioni aziendali hanno portato a frequenti cambi di organizzazione e i sistemi spesso non si sono adeguati. I processi sono stati gestiti con diversi livelli di attenzio­ne a seconda delle singole realtà, magari anche influenzati da scelte molto personali, spesso reinventando la risposta alle stesse domande. Sui sistemi implementati le conseguenze sono state significative, provocando comuni criticità di implementazione e di funzionalità che ne hanno compromesso spesso l’efficacia e che si possono riassumere in:

• Inserimento di dati spesso ridondanti dovuta a deficit di interoperabilità e di integrazione tra piattaforme applicative (ERP, MES, EAM)
• Copertura parziale dei processi, con proliferare dell’utilizzo di Office tool paralleli e scostamento tra processi reali e processi censiti, basso livello di digitalizzazione
• Profondità informativa spesso formalmente accettabile ma sostanzial­mente deficitaria: la quantità di dati gestiti non tiene conto della loro “fi­nalità” e delle differenze nei processi in cui vengono raccolti (tra differenti ruoli operativi, tipologie manutentive, etc.)
• Qualità del dato molto bassa dovuta all’assenza di controlli nella fase di inserimento e alla mancata adozione di strumenti di rilevazione atti a pre­servare e conservare gli stessi.

La mancanza, spesso totale, di affidabilità e attendibilità delle informazioni gestite ed estratte, siano esse KPI, SLA, insieme allo scarso livello di “sha­re information”, impatta negativamente sul decision making, soprattutto per l’Ingegneria di Manutenzione e per il Management, con possibili gravi danni all’economia dell’azienda.

Come cambia il Work on Field

L’Industria 4.0 può dare un importante contributo, favorendo l’automazione del “Work on Field”, l’area più critica, con tecnologie sempre più accessibili ed integrate quali RFID, Mobile, HMI (Human Machine Interaction, non solo In­terface) voice assistant, touchscreen, Virtual Reality glasses or gestures per Remote Assistance. Solo spostando il processo operativo “verso il basso” si può parlare di una vera e propria digitalizzazione e si possono superare i colli di bottiglia nel rilevamento del dato ed aumentarne l’affidabilità.

La vera sfida però è affiancare, agli aspetti “Human Centered”, il riuso dei dati disponibili che afferiscono al mondo “Automation Centered”. Spesso i dati non sono raccolti per finalità di supporto alla funzione di Asset Mana­gement ma solo a supporto delle Operation e della Sicurezza Funzionale. In relazione a ciò, raccogliere quello che è già disponibile e ritenere che le sole tecniche di analisi statistica e Machine Learning (indipendentemente da quali algoritmi vengano utilizzati), possano dare risposte definitive o almeno signi­ficative sulla “Predictive Maintenance”, appartiene alla mitologia contempo­ranea. Preoccupa inoltre anche la superficialità, l’estrema semplificazione e la velocità di diffusione di un pensiero univoco in tal senso.

Tornando al “Data Centered”, l’efficacia e l’affidabilità del risultato che si ot­tiene e quindi il successo dei modelli di manutenzione predittiva basati su Machine Learning (ML) dipendono da tre fattori principali:

• La disponibilità dei dati realmente necessari
• Il giusto inquadramento del problema
• La corretta previsione dei risultati.

A tali aspetti si affianca l’integrazione/l’implementazione di dati provenienti dal mondo CND (vibrazionali, impulsi, analisi oli, ultrasuoni, etc.) dove alcune tecniche si caratterizzano, negli ultimi anni, da un tale aumento dell’affidabili­tà nella diagnosi, che le porta ad essere le uniche realmente efficaci per una manutenzione prescrittiva, intendendo con ciò che non si limitano a predire il guasto ma indirizzano precisamente sul “cosa fare”.

Come si costruiscono i modelli di manutenzione predittiva

Come da ampia letteratura sul tema, cerchiamo di approfondire i primi due fattori principali sopra menzionati e di fornire qualche spunto su come sce­gliere la tecnica di modellazione che meglio si adatta alla domanda a cui si sta cercando di rispondere, sulla base dei dati che si hanno a disposizione.

Per costruire un modello, occorre conoscere le caratteristiche generali “statiche” della mac­china che possono fornire informazioni preziose, quali proprietà meccaniche, utilizzo medio e con­dizioni operative, e disporre di un numero suffi­ciente di dati storici che consentano di acquisire informazioni sugli eventi che portano al “Failure”. Tuttavia, la quantità dei dati non è sufficiente, oc­corre anche che essi siano di buona qualità e che il modello sia in grado di definire il guasto/errore per poter dare risposte alle domande:

• Quali eventi negativi possono verificarsi? Quali cercheremo di prevedere?
• Come si manifesta il “processo di Failure”? E’ un processo di degrado lento o acuto?
• Quali parti della macchina / sistema potreb­bero essere correlate a ciascun tipo di guasto?
• Cosa può essere misurato su ciascuno di essi che rifletta il loro stato e con che frequenza e con quale precisione devono essere effettuate le misurazioni?

Per dare delle risposte occorre un approccio metodologico come la FMECA, in particolare per l’analisi dei Failure Mode, che consideri so­prattutto la casistica in esercizio (FRACAS) ed in questo caso l’aspetto di integrazione con EAM per la gestione dei processi operativi diventa essen­ziale, cosi come il ruolo dell’Ingegneria di Manu­tenzione che lavori in team con i “data scientist”. Le macchine durano anni e i dati devono essere raccolti per lungo tempo al fine di osservare il si­stema durante il processo di degrado. Lo scenario ideale sarebbe potere partecipare alla fase di pro­gettazione della raccolta dati di un nuovo impianto, per garantire che questi siano adatti al modello da costruire. Tuttavia, quasi sempre ci troviamo davanti a dati già esistenti e dobbiamo cercare di ottenere il massimo da ciò che è disponibile.

Per poter definire correttamente il modello da costruire sulla base delle caratteristiche del sistema/macchina e dei dati disponibili, è essenziale va­lutare che tipo di output vogliamo ottenere e comprendere se ciò è fattibile con i dati (storici e statici) a disposizione. Tra i dati storici è essenziale l’in­sieme di misure che possano essere associate all’evento di “buon funziona­mento” e a quello di “failure” in senso ampio, non basta tracciare il guasto ma anche il caso in cui la macchina abbia fallito, seppure parzialmente, la sua prestazione. Per poter considerare quali saranno le conseguenze di non prevedere un errore o di prevedere un errore che non accadrà, occorre trac­ciare e monitorare gli eventi nella giusta proporzione, determinare il livello di precocità richiesto e fissare a quali obiettivi prestazionali del modello dobbia­mo tendere.

Principali strategie di modellazione

Tra le molteplici strategie di modellazione per la manutenzione predittiva, ne descriviamo quattro in relazione alle finalità e al tipo di dati che richiedono:

1. Modelli di regressione per prevedere la vita utile residua (RUL - Re­main Useful Lifetime), quanto tempo / cicli occorrono prima che il sistema abbia un Failure. Per tale obiettivo devono essere disponibili dati statici e sto­rici per ogni evento di Failure e diversi casi di ciascun tipo di errore. Se sono possibili molti tipi di errori e il comportamento del sistema prima di ciascuno di essi è diverso, è necessario creare un modello dedicato per ciascuno.

2. Modelli di classificazione per prevedere l’evento di errore entro una determinata finestra di tempo. In genere non è necessario prevedere con precisione la durata della vita di un impianto, ma basta solo sapere se la macchina si guasterà “precocemente” ossia se non funzionerà nei prossimi N giorni / cicli. Per i dati necessari valgono le stesse considerazioni del punto precedente e devono essere disponibili con casi “sufficienti” di ciascun tipo di errore per addestrare e valutare il modello.

Le ipotesi di un modello di classificazione sono molto simili a quelle dei modelli di regressione, ma nel primo caso l’errore viene definito in una fine­stra temporale, nel secondo in un tempo esatto, quindi il requisito della distribuzione del processo di degradazione è meno vincolante e si possono gestire diversi tipi di errore, purché siano struttu­rati in più classi, ad esempio:

• classe = 0 per nessun errorenei prossimi n giorni
• classe = 1 per il tipo di errore X nei successivi n giorni
• classe = 2 per il tipo di errore Y nei successivi n giorni e così via

In generale, ciò che i modelli di regressione e classificazione stanno facendo è la modellazione della relazione tra le caratteristiche e il percorso di degrado del sistema. Ciò significa che se il mo­dello viene applicato a un sistema che presenta un diverso tipo di errore non presente nei dati di addestramento macchina, il modello non riuscirà a prevederlo.

3. Modello per la segnalazione di comporta­mento anomalo. Entrambe le strategie preceden­ti richiedono sia dati sul normale comportamento della macchina (spesso se ne hanno molti) sia esempi di Failure (quasi sempre pochissimi e mal rilevati). Se si dispone di sistemi “mission critical”, in cui i “Failure” gravi sono rari o nulli, è necessa­ria una strategia diversa per valutare se il compor­tamento del macchinario è considerato normale. In tal caso devono essere disponibili dati statici e storici, che non sono comunque in grado di risa­lire al Failure, perché sono stati osservati troppi pochi errori o vi sono troppi tipi di errori. Bisogna innanzitutto definire quale sia il comportamento normale e correlare la differenza tra comporta­mento corrente e”normale” al degrado che porta al Failure.

La generalità di un modello di rilevamento delle anomalie è sia il suo più grande vantaggio sia il suo punto debole. Il modello infatti è in grado di segnalare ogni tipo di errore, nonostante non ab­bia alcuna conoscenza precedente su di essi, ma non è in grado di fornire informazioni sull’inter­vallo di tempo in cui dovrebbe verificarsi l’erro­re, poiché il comportamento anomalo non porta necessariamente al Failure. La mancanza di dati da relazionarsi all’errore rende la valutazione di un modello di rilevamento delle anomalie one­rosa. Se sono disponibili almeno alcune relazio­ni con eventi di errore, ciò deve essere utilizzato per perfezionare l’algoritmo, altrimenti bisognerà ricorrere ad esperti del dominio che possano for­nire un feedback sul livello di efficacia nella capa­cità di segnalazione delle anomalie.

4. Modelli di sopravvivenza per la previsione della probabilità di Failure nel tempo. I pre­cedenti tre approcci sono di tipo previsionale e sono in grado di fornire informazioni sufficienti per effettuare la manutenzione prima del Fai­lure. Se tuttavia si è interessati a monitorare il processo di degrado e a stabilire la probabilità di Failure, quest’ultima strategia si adatta meglio. Un modello di sopravvivenza stima la probabilità di Failure per un dato tipo di macchina con carat­teristiche statiche ed è anche utile per analizzare l’impatto di alcune caratteristiche nel corso del ciclo di vita. Fornisce, quindi, stime per un grup­po di macchine con caratteristiche simili, senza tenere conto del loro stato attuale specifico.

Conclusioni

È consigliabile valutare con attenzione un ap­proccio multi-disciplinare: le tecnologie abili­tanti sono importanti, ma gli aspetti organizza­tivi (business process innovation), applicativi, formativi e culturali (organizational alignmennt) hanno un forte impatto sui risultati nel tempo. Non vanno confuse logiche applicative di Proof of Concept, che vogliono realizzare un progetto senza conoscere il risultato atteso (tipico di un approccio sperimentale “innovativo”), con logiche applicative di un progetto Pilota, ove si vogliano applicare nuovi modelli e tecnologie per valutarne in modo dinamico l’efficacia dei risultati, i ROI e l’accettabilità, e che afferiscono ad una diagno­stica evoluta.

Fondamentale per il successo dell’iniziativa è l’in­terazione dei diversi aspetti citati, la conseguente integrazione con l’EAM e la sua contestuale re-in­gegnerizzazione. Occorre dotarsi di competenze sistemiche di Ingegne­ria di Manutenzione, che hanno il compito, non negoziabile, di valu­tare l’efficacia dei risultati ottenuti nel tempo, deri­vanti dall’applicazione dei nuovi approcci, e inter­venire in modo dinamico per correggerne logiche e regole. Qualunque altra alternativa destrutturata è fine a se stessa e desti­nata a fallire.

Maurizio Ricci, IB Ceo e Consigliere A.I.MAN.