Come costruire un sistema di manutenzione predittiva: la guida

L’interconnessione e il dialogo tra sistemi di gestione della produzione e sistemi fisici (macchinari) è una caratteristica fondamentale del paradigma Industria 5.0. Allo stesso modo, tale integrazione e scambio dati è la base per l’implementazione della manutenzione predittiva, dove l’elaborazione dei dati acquisiti real-time dai diversi sistemi che orbitano intorno ai macchinari di impianto e la modellazione degli insight risultanti, permettono di monitorare gli asset di impiant, diagnosticare in anticipo eventuali guasti o malfunzionamenti, prevedere la vita utile residua (RUL – Remaining Useful Life). Ma come si crea un sistema di manutenzione predittiva in azienda?

Sistema di manutenzione predittiva, le competenze necessarie

Abbiamo visto in precedenza che alcuni modi di guasto non si prestano a politiche di gestione predittive, per natura o per opportunità, e che ogni tipologia di componente nasconde il proprio indice di salute in differenti variabili spia e predilige specifiche tecniche di apprendimento per essere modellati al meglio.

Di conseguenza l’analisi approfondita dei macchinari e dei propri modi di guasto oltre alla costruzione dell’infrastruttura informatica e tecnologica necessaria alla messa a terra di progetti di questo tipo non è affatto semplice e necessita di diverse competenze:

• Affidabilità e manutenzione – per la comprensione delle cause, gli effetti, la criticità, e la politica manutentiva più adatta per ogni modo di guasto. L’individuazione delle variabili spia e le specifiche tecniche necessarie per una loro corretta acquisizione;
• Sensoristica e IoT – per l’installazione e la connessione al sistema di acquisizione della sensoristica integrativa necessaria;
• System Integration – per l’integrazione dei diversi sistemi di acquisizione dei dati (IoT, MES, CMMS ecc.) necessari alla costruzione della base informativa;
• Data Science – per l’analisi della base informativa e lo sviluppo dei modelli necessari a creare i corretti insight dai dati;
• IT – per la progettazione, sviluppo e manutenzione della piattaforma di manutenzione predittiva;
• Automazione di impianto – per integrare i modelli nell’automazione di impianto laddove necessario;
• Data Visualization e dashboarding – per la piena e rapida fruizione e consultazione dei risultati dei modelli di manutenzione predittiva da parte di tutti gli user della piattaforma (manutentori, ing. Di manutenzione, resp. Di manutenzione, monitoraggio di impianto ecc.)

In questo articolo, per fare ordine nella complessità di implementazione di un progetto di manutenzione predittiva, percorreremo le fasi principali applicate ad un caso studio.

Approccio per realizzare un sistema di manutenzione predittiva

Dall’analisi della letteratura e dall’esperienza maturata, emerge che il corretto approccio alla prognostica segue le fasi riportate nella seguente figura:

Figura 1 Approccio alla prognostica.

Come mostrato in figura le fasi sono le seguenti:

1. Analisi dei modi di guasto dei componenti: in questa fase si individuano i componenti critici di impianto ed i relativi modi di guasto. Tra questi, quelli su cui è possibile sviluppare modelli prognostici e le relative variabili spia da monitorare per effettuare prognostica;
2. Sensorizzazione dei macchinari: questo secondo passo suggerisce di installare nuovi sensori (se non già presenti in impianto) che permettano di monitorare tutte le variabili spia di interesse individuate al passo precedente. È inoltre necessario assicurarsi che le specifiche tecniche dei sensori (frequenza di campionamento dati, temperature di funzionamento, accuratezza ecc.) siano compatibili con le analisi da effettuare e le caratteristiche del macchinario da monitorare;
3. Analisi e sviluppo del modello diagnostico: in questa fase viene scelto e sviluppato il modello diagnostico più consono all’individuazione della classe di funzionamento del modo di guasto in analisi in funzione dei dati delle variabili spia individuate. Tale modello diagnostico oltre a classificare il comportamento del componente deve essere in grado di fornire ad output un parametro proxy delle prestazioni del macchinario in analisi.Analisi e sviluppo del modello di previsione della RUL: In questa fase viene scelto il modello di analisi di serie temporali necessario alla prognostica del modo di guasto di interesse. Il modello costruito verrà applicato alla variabile proxy delle prestazioni del macchinario (output del modello diagnostico) in modo da prevedere quando queste saranno inferiori ad una soglia di accettabilità preimpostata.
4. Schedulazione degli interventi manutentivi: dalla conoscenza della vita utile residua del macchinario in analisi, output del modello di previsione della RUL, si procede a scrivere a calendario la data prevista dell’evento di guasto con informazioni circa la confidenza della previsione effettuata e la criticità del modo di guasto in base a quanto studiato nella prima fase. In questo modo si danno tutte le informazioni necessarie all’ingegneria di manutenzione per schedulare gli interventi manutentivi sul campo.

Vediamo adesso come la metodologia si applica nella pratica analizzando un caso studio.

Use case, un sistema di manutenzione predittiva in azienda

Il caso d’uso riguarda un impianto di produzione di energia da fonte geotermica con ciclo a condensazione a singolo flash di una grande azienda italiana del settore energy.

L’obiettivo del progetto è quello di sviluppare un nuovo sistema avanzato di diagnostica e prognostica dei sistemi di impianto al fine di estendere il monitoraggio a tutti i componenti per riconoscere in anticipo l’imminente incorrere dei guasti, così da supportare i responsabili di esercizio nell’ottimizzazione degli interventi di manutenzione.

I componenti più importanti di impianto sono riportati in figura.

Figura 2 Schema dell’impianto pilota

La tipologia di ciclo di condensazione ha la particolarità di lavorare il fluido geotermico direttamente in impianto. Prima dell’ingresso in turbina è quindi necessario lavare il vapore dalle componenti corrosive e separare la fase vapore dalla fase liquida. A questo punto il vapore geotermico è pronto per entrare in turbina e generare energia. Successivamente viene condensato, pompato nelle torri di refrigerazione e reimmesso nel sottosuolo. La parte gassosa non condensabile, viene prelevata attraverso un compressore centrifugo, trattata e liberata in atmosfera.

Ognuno dei componenti presentati, ad eccezione dei componenti principali di impianto (Turbine, Generator) sono stati oggetto di analisi e sviluppo di modelli predittivi.

Team di progetto

Figura 3 Partner di progetto

Il team di progetto ha visto coinvolti diversi attori con competenze ed esperiente eterogenee sulle diverse aree necessarie allo sviluppo del sistema di Predictive Maintenance.

In particolare:

1. L’azienda use case ha messo le sue competenze e conoscenze di impianto per guidare e supportare gli altri partner di progetto. Si è poi occupata dell’IT, dei System integratoion e automazione di impianto.
2. Smartoperations insieme agli organismi di ricerca hanno portato le competenze su Affidabilità, manutenzione e Data Science.

Sono poi stati coinvolti altre due società partner di progetto con competenze verticali su:

1. Sensoristica ed IoT
2. Data visualization.

Tempi di implementazione:

L’implementazione di un sistema di manutenzione predittiva è complesso e richiede un effort elevato in tutte le fasi sopra descritte. In particolare, lo svolgimento di questo caso studio ha richiesto 2 anni e 6 mesi per la sua implementazione, vedendo impegnato l’intero gruppo di progetto, con effort variabile nelle diverse fasi, per la sua intera durata.

Passiamo ora in rassegna ognuna delle fasi dell’approccio presentato calate sullo specifico use-case.

Analisi dei modi di guasto

È stata condotta una analisi FMEA (Failure Mode and Effects Analysis) per tutti i componenti giudicati di rilevanza per il progetto. Abbiamo creato una tabella Excel che è stata successivamente riempita attraverso le indicazioni degli esperti di ogni componente.

Nella tabella di seguito si riportano i campi del file utilizzato per la compilazione dell’FMEA.

Tabella 1: FMEA

Un guasto può essere grave per vari motivi, come si deduce anche dalla presenza di più campi nell’FMEA. Quindi per generare un indice di Severity consistente è necessario trovare il modo di pesare ogni impatto nel modo più corretto possibile. Per ovviare a questo problema abbiamo adottato una versione personalizzata del metodo AHP (Analytic Hierarchy Process) che ci ha permesso di conciliare le diverse scale e unità di misura adottate per ogni impatto. Per l’applicazione di questa metodologia è necessario predisporre dei questionari ad hoc di confronto a coppie tra tutti gli aspetti da confrontare per ottenere i pesi di ciascuno nella valutazione finale dell’indice di Severity.

Una volta compilata la tabella, abbiamo tutte le informazioni necessarie ad identificare:

• Modi di guasto critici;
• Metodo più appropriato di gestione del particolare modo di guasto;
• Variabili spia del modo di guasto.

Sensorizzazione dei macchinari

Per il caso studio, sulla base dell’analisi precedentemente condotta, si è deciso di sensorizzare ulteriormente i seguenti componenti:

• PAE Pump
• Refrigerating Tower

Per la pompa PAE sono stati installati:

• Accelerometri per la diagnostica di usure dei cuscinetti e avarie del motore elettrico;
• Trasduttori di prossimità per diagnosticare disallineamenti dell’albero della pompa;
• Trasduttori di assorbimento di corrente per diagnosticare avarie del motore elettrico

Per i ventilatori delle Refrigerating Tower:

• Accelerometri per diagnosticare usure sui cuscinetti e malfunzionamenti dei motori elettrici di azionamento.

A questi sono stati poi associati i sistemi di acquisizione ed elaborazione dei dati.

Sviluppo modello prognostico

Figura 4 Framework del modello prognostico real-time.

Come mostrato in figura, la metodologia adottata nel caso studio prevede uno sviluppo off-line dei tre modelli necessari alla prognostica:

1. Modello di validazione delle misure;
2. Modello diagnostico;
3. Modello di previsione della RUL;

ed una macro-fase di analisi on-line in tempo reale dei dati acquisiti dai sensori ed elaborati dai modelli addestrati.

A partire da un ricco database di impianto (2 anni di storico dati campionati a 5 secondi, dai 20 ai 40 punti di misura per ogni macchinario) si effettua una prima analisi dei dati allo scopo di selezionare le variabili spia del modo di guasto di interesse nei periodi sia di funzionamento corretto che di funzionamento anomalo connesso al particolare modo di guasto di interesse.

Successivamente si passa alla fase di preprocessing dei dati a database, allo scopo di:

1. Sincronizzare i dati per ottenere un set di training dei modelli coerente;
2. Trasformare i dati in modo da esaltare il loro contenuto informativo
3. Creare il set di dati necessario all’addestramento dei modelli.

Viene quindi selezionato, sviluppato, addestrato e validato sui dati storici il modello diagnostico che sarà utilizzato in real-time allo scopo di:

1. Individuare la classe di funzionamento del macchinario (regime o incipiente guasto);
2. Individuare lo stato attuale di salute del componente.

L’output del modello diagnostico, se necessario, viene trasformato al fine di ottimizzare il potere previsionale del modello di stima della RUL. A questo punto si passa alla selezione, sviluppo ed addestramento anche di questo modello sui dati presenti a storico.

Parallelamente, nella fase di sviluppo e validazione off-line dei modelli necessari alla prognostica, i dati storici provenienti dai sensori vengono utilizzati allo scopo di sviluppare il modello di validazione delle misure provenienti dai sensori, necessario ad assicurare che tutti i dati processati dai modelli siano da considerarsi affidabili e che non ci siano quindi guasti/malfunzionamenti o starature ai sensori.

Passando alla fase di analisi on-line, si procede all’acquisizione real-time dei dati delle variabili spia del guasto provenienti dai sensori. Questi vengono dapprima validati dal modello di validazione delle misure e successivamente processati e trasformati, applicando la trasformazione fatta nella fase di addestramento off-line, prima di essere elaborati dal modello diagnostico. Da quest’ultimo otteniamo quindi:

• classe di funzionamento del componente analizzato (regime o incipiente guasto)
• l’indice delle performance attuali del componente (Health Index).

Si applica quindi la trasformazione costruita in fase off-line e si passa all’elaborazione dell’Health Index tramite il modello di previsione della RUL per ottenere la previsione della data prevista di guasto del componente.

Vediamo adesso nel dettaglio i modelli utilizzati nel caso studio.

Validazione delle misure acquisite dai sensori

Questo modello permette di ottenere due importanti risultati:

1. Definire preventivamente malfunzionamenti dei sensori;
   1. Evitare di effettuare analisi diagnostiche e prognostiche su misure non valide, evitando quindi il problema del “Garbage In Garbage Out” (GIGO), ovvero dell’elaborazione di dati “spazzatura” che chiaramente forniranno in uscita informazioni fuorvianti.

Nei punti critici dell’impianto è previsto l’utilizzo di sensori ridondati in modo tale che la misura sia calcolata sfruttando i dati provenienti da 3 fonti.

Per questi punti di misura con doppia ridondanza è stato quindi implementato un sistema di riconoscimento delle anomalie. In particolare, trattandosi di variabili continue a media e varianza stazionarie, il range viene imposto a priori uguale alla media della misura più 3 volte la deviazione standard (UCL – Upper Control Limit), calcolate durante un regime di funzionamento senza anomalie.

In ogni istante, il modello verifica che la differenza a coppie dei valori registrati dai 3 sensori siano inferiori all’UCL.

Quando si hanno dei superamenti di soglia, l’obiettivo diventa quello di capire quale/i siano i dispositivi che in quell’istante stanno fornendo la lettura più verosimile per la grandezza osservata. Quindi, per mezzo di una tabella della verità, abbiamo distinto delle categorie di situazioni degradate, dove ciascuna indica il valore da prendere come valore finale.

Tabella 2 Tabella della verità

Modello diagnostico SVM

I modelli SVM fanno parte dei modelli supervisionati classificatori e regressivi machine learning.

È stato scelto di utilizzare modelli ML per:

È stato scelto di utilizzare modelli ML per:

1. versatilità di utilizzo: La qualità previsionale e classificatoria di questi modelli non dipende dalla tipologia di guasto analizzata ma solo dalla quantità e qualità dei dati di addestramento a disposizione.;
   1. miglioramento continuo: Essendo la loro accuratezza strettamente connessa alla quantità e alla qualità dei dati a disposizione, incrementando la base dati a disposizione del loro addestramento, incrementerà conseguentemente anche il loro potere classificatorio.

Abbiamo selezionato le Support Vector Machine (SVM) in quanto una volta addestrato fornisce due tipi di output:

1. Classificazione del comportamento attuale del componente;
   1. Distanza del punto di funzionamento attuale del componente dalla superficie di separazione delle classi di addestramento (regime, anomalia);

Quest’ultimo output avrà quindi valore maggiore quanto più il comportamento del componente è situato all’interno della regione della classe di appartenenza e quindi quanto più saremo certi che il macchinario sia effettivamente nella classe predetta.

Di conseguenza questo parametro può essere considerato come la variabile proxy dello stato di salute (Health Index) del componente, sul quale costruire un modello prognostico attraverso l’analisi del suo andamento nel tempo.

Analisi di serie temporali ARIMA

Il metodo ARIMA (AutoRegressive Integrated Moving Average) è un modello che dati in ingresso 3 parametri p,d,q è in grado di modellare l’andamento di una serie temporale e di prevedere ciò che accadrà i successivi istanti temporali permettendo così di stimare la vita utile residua del mio componente sulla base del consumo storico del suo Health Index.

Per il calcolo dei coefficienti si procede con l’analisi dell’autocorrelazione e della autocorrelazione parziale (ACF e PACF). Il numero di lag significativi della ACF identificherà il valore di p, quello della PACF mi fornirà il valore di q, e la D mi indicherà il grado di non stazionarietà della funzione, zero quando è stazionaria, uno quando a trend lineare, ecc.

Una volta generata la previsione dell’andamento temporale dell’Helth Index del macchinario in analisi, identifichiamo una soglia minima di questo parametro oltre la quale considerare il macchinario guasto. Il tempo intercorrente tra il momento della previsione e il superamento della soglia di accettabilità corrisponderà alla RUL del macchinario.

Passiamo adesso all’architettura informatica messa in campo.

Architettura informatica

I DCS (Distributed Control System) di impianto sono tipicamente costruiti su 5 differenti livelli, dall’acquisizione delle misure di interesse sul campo all’analisi di informazioni aggregate al livello più alto. Più aumenta il livello e minore è il dettaglio sui dati acquisiti dai sensori, inoltre, maggiore è il livello e maggiore è la potenza di calcolo a disposizione per effettuare analisi sui dati.

Figura 5: Struttura DCS.

Per definire a che livello istanziare i modelli, è necessario suddividere le caratteristiche prognostiche dei possibili modi di guasto in due categorie:

• • 1. Modi di guasto che richiedono un monitoraggio hard real-time
    2. Modi di guasto che richiedono un monitoraggio soft real-time

Appartengono alla prima categoria quei modi di guasto o fenomeni di perdita di prestazioni del macchinario che hanno una rapida evoluzione nel tempo e che necessitano di un intervento immediato non appena diagnosticati da parte dell’automazione di impianto.

Appartengono invece alla seconda categoria quei modi di guasto, tipici dell’usura e/o corrosione di componenti meccanici, che presentano una fenomenologia di degrado di lunga durata e che necessitano di interventi manutentivi da parte degli operatori di manutenzione.

Per l’una e l’altra categoria, è necessario implementare i modelli a diversi livelli del DCS per garantire l’efficacia degli interventi, automatici o tramite personale dedicato.

Una ulteriore riflessione necessaria riguarda invece la tipologia di misura acquisita, che a sua volta determina la necessità o meno di spingersi ad operare a livelli più bassi del DCS. In particolare, anche in questo caso le misure possono essere suddivise in due macrofamiglie:

1. Misure che richiedono un preprocessing sui dati raw per poterne cogliere il contenuto informativo;
2. Misure che non richiedono un preprocessing sui dati raw.

Appartengono alla prima categoria tutte le misure il cui contenuto informativo riguardo allo stato di salute del macchinario sono visibili solo se analizzati ad alta frequenza di campionamento ed esplicate al meglio dopo una trasformazione dei dati da effettuarsi quindi a livello 1 del DCS (Controllo diretto).

Appartengono invece alla seconda categoria tutte le misure che sono informative già così come sono acquisite dal sensore. Tipicamente queste grandezze presentano ad alta frequenza solo delle oscillazioni intorno al valore atteso e le loro variazioni sostanziali sono apprezzabili ad intervalli di tempo relativamente lunghi (secondi, minuti, ore). Per queste grandezze la fase di pre-processing, se necessaria, può essere effettuata a livelli di DCS più alti direttamente sui dati storicizzati.

Nella tabella seguente si riportano: il livello di DCS in cui sono rilasciati i modelli sviluppati e dove avvengono le fasi di analisi on-line suddivise per modelli soft real-time ed hard real-time. In entrambi i casi le fasi di sviluppo degli algoritmi possono essere effettuate anche separatamente su PC dedicati o a livello 3 del DCS dove si ha una elevata potenza di calcolo.

Tabella 3. Livello di rilascio dei modelli ed analisi dati sul DCS dell’impianto pilota

Come descritto in tabella, nel caso di modelli hard real-time la fase prognostica è inutile da implementare in quanto non si necessita di una schedulazione di un intervento manutentivo ma si agisce direttamente sull’automazione di impianto, regolando il funzionamento del macchinario o bloccandolo.

Per implementare modelli diagnostici e/o di state detection hard real-time è necessario munirsi di PLC di ultima generazione che permettono di implementare modelli analitici complessi come modelli di machine learning o statistici avanzati. Nel nostro caso sono stati utilizzati PLC Siemens SIMATIC STEP 7 che supportano modelli sviluppati in Simulink PLC Coder, sfruttando quindi la potenza di MATLAB nell’implementazione di modelli analitici avanzati. In entrambi i casi, la fase di re-training dei modelli, necessaria in caso di nuovi dati utili all’addestramento del modello diagnostico, è comunque da prevedere su PC dedicati di alto livello del DCS, che rilasceranno poi i parametri dei modelli aggiornati sui PLC.

Interfaccia modelli prognostici soft real-time

Per la visualizzazione e l’istanziazione di analisi sui dati è stato costruito un sito web che si interfaccia con il software di gestione degli asset di impianto in cui si collezionano i dati provenienti dai sensori di impianto.

La landing page multistep del sito consente l’interazione dell’utente con il sistema di manutenzione predittiva messo a punto per il progetto.

Gli step consentono di:

• creare e configurare nuove istanze di elementi diagnostici e prognistici,
• monitorare lo stato di elementi già istanziati dall’utente loggato
• eseguire la schedulazione degli stessi.

I risultati delle analisi sono visualizzabili in tempo reale in una schermata dedicata.

Figura 6 – Pagina dei risultati

Questo tipo di grafico mostra degli eventi futuri identificandoli per gravità (colore), risultato della severity dell’analisi FMEA iniziale, e probabilità di accadimento. Grazie a questo tipo di grafico gli operatori di manutenzione potranno accedere a informazioni altamente informative e fruibili per permettere il buon esercizio dei sistemi di impianto.

Grazie a questa interfaccia interattiva ogni utente può creare agilmente la propria analisi diagnostica e/o prognostica utilizzando i modelli rilasciati nell’architettura informatica:

1. Diagnostico: SVM per la classificazione del comportamento a regime o a guasto di un componente;
2. Stima della RUL: ARIMA per prevedere la RUL di un macchinario utilizzandola in combinazione con un modello diagnostico o di state detection;

Benefici ottenuti

L’azienda caso studio ha ottenuto benefici dall’adozione di questo sistema di analisi dei modi di guasto su diversi fronti:

• Riduzione dei fermi macchina non schedulati
• Supporto alla supervisione dei macchinari di impianto
• Incremento dell’efficienza e dell’efficacia degli interventi manutentivi

Che hanno portato ad una riduzione dei costi di intervento purtroppo non quantificata economicamente.

È stato quantificato solo il beneficio legato all’incremento della produzione di energia elettrica dell’impianto pilota che, grazie al nuovo sistema, ha registrato un incremento del tempo produttivo di impianto del 3% con conseguente incremento analogo di produzione di energia elettrica. Si stima che tale incremento permetta all’azienda caso studio di ottenere un ROI di circa 2 anni e mezzo considerando solo quest’ultimo beneficio.

Conclusioni

In conclusione, attraverso le fasi di un caso studio, ho presentato un approccio consolidato allo sviluppo di un sistema di manutenzione predittiva, approfondendo le competenze necessarie allo sviluppo, un framework per l’analisi FMEA, i modelli utilizzabili per diagnostica e previsione della RUL dei componenti in analisi, l’architettura informatica necessaria e la visualizzazione dei risultati del modello.

Che aggiungere. La complessità e le sfide da affrontare sono molte e richiedono un’accurata gestione del progetto ed una conoscenza di tutte le fasi dell’approccio. Una volta portato a terra i benefici sono indiscutibili.