Nei progetti di I4.0 nell’asset management hanno sempre più un ruolo fondamentale l’ottimale utilizzo delle tecnologie e dei dati esistenti acquisiti dal campo (dall’automazione o dagli IIoT) relativi a impianti, siano di processo oppure di rilevamento condizioni di funzionamento delle macchine, e le conseguenze sui processi operativi, anche di ingegneria di manutenzione.
La digitalizzazione progressiva dei processi tecnici e lo sfruttamento di tutti i dati provenienti dalle macchine ha potenzialmente un impatto altissimo sui processi “human intensive” e sul loro “reale” miglioramento. Questo vantaggio competitivo si concretizza solo se i dati gestiti diventano veramente “informazioni” in grado di aiutare le aziende a fare delle scelte consapevoli e a prendere iniziative su basi “oggettive”.
È sufficiente che un determinato dato per un periodo (un mese di registrazioni) decada a livello qualitativo, per compromettere l’intera significatività e quindi far sì che non rientri nella classe delle “informazioni”.
Questa affermazione, che sembra scontata, rappresenta spesso, alla resa dei conti, una chimera.
Proviamo a comprenderne le difficoltà e quale deve essere un percorso “adeguato” per non aggiungere elementi di criticità a un tema già di per sé complesso.
Una criticità: la gestione degli Output, delle verifiche e dei “feedback”
Limitandoci alla valutazione del processo che sta a valle di un sistema diagnostico / prognostico di Manutenzione 4.0, partiamo da una constatazione provocatoria: il “come” si applica è fondamentale per “pesare” il risultato che si ottiene … Con ciò intendiamo, che il risultato (output) sia un segnale debole o un sintomo è sempre “utile” e un passo avanti rispetto al punto di partenza, ma raramente appartiene alla classe degli output “ottimali” dal punto di vista della diagnostica/prognostica, perché non rappresenta un preciso input per la risoluzione del problema e la rimozione della causa.
Per motivazioni di processo spesso il segnale debole non viene utilizzato o se accade avviene sicuramente in un modo non adeguato. Invece anche un risultato parziale, come un segnale debole o un sintomo come “una deviazione o un degrado di una performance”, anche se non correlabile direttamente a una causa, se gestito e valutato nell’intero processo, genera informazioni utilissime al fine di un apprendimento automatico(grazie agli algoritmi) per una comprensione del fenomeno.
Quanto sopra concorre a far sì che le sperimentazioni in piloti su manutenzione predittiva finiscano, spesso, su binari morti, o in utilizzi molto parziali, che non sono solo imputabili alle risorse umane operative non adeguatamente formate all’uso delle nuove tecnologie.
Ad esempio, se un “allarme” proveniente da un sistema automatico deve ancora essere interpretato, verificato in relazione ad altre informazioni (dati) e poi collegato ad un’azione diagnostica che richiede il supporto di altre tecniche e skill, certamente la riqualificazione della risorsa diventa un elemento determinante.
Ci possono però essere anche allarmi che richiedono subito una verifica diagnostica come una “Visual Inspection”, oppure altri che possono richiedere l’anticipo di una scadenza di manutenzione programmata. In questo caso è essenziale che l’operatore effettui semplicemente il rilevamento dello stato reale della macchina (diagnosi fisica) e un’azione correttiva in cui fornisca il giusto feedback al fine di comprendere il grado di efficacia dell’allarme ed eventualmente affinarlo attraverso un update del sistema.
L’esempio riportato evidenzia come la problematica critica sia il processo di gestione della singola classe di allarmi (a seconda delle casistiche) nella sua interezza e non si possa trattare il tema in modo superficiale.
Comprendere come intervenire attraverso diversi tipi di allarmi
La capacità di utilizzo del livello di informazioni (output), siano “segnali deboli o sintomi” e i conseguenti “allarmi” generati, è inversamente proporzionale alla competenza necessaria.
A valle di quanto detto gli allarmi vengono classificati in due macrocategorie: “True alarms” e “Weak signals”. Al primo gruppo appartengono gli allarmi per i quali si conosce il percorso da seguire, si è definita una serie di interventi opportuni e non è richiesto un impegno investigativo elevato.
Nel secondo gruppo invece troviamo quegli allarmi classificati come segnali deboli sui quali occorre prestare attenzione in quanto rappresentano dei primi sintomi di malessere che si possono poi tramutare in problemi gravi con conseguenze più o meno impattanti sui processi (comunque un sintomo quasi sempre non è sufficiente a determinare la malattia).
Risulta evidente che l’impegno nel ricercare le cause di tali segnali può richiedere delle conoscenze del processo e in generale competenze ingegneristiche di un certo livello. La risoluzione dei problemi che innescano i segnali deboli rappresenta un patrimonio di informazioni sempre più prezioso per l’azienda e la sua conservazione è ora possibile grazie proprio alla digitalizzazione. Per entrambe le categorie esistono poi dei livelli di priorità “Low”, “Medium” e “High” per classificarne l’importanza.
Ogni output deve essere considerato sulla base di chi e di come dovrà essere gestito, programmando la giusta sequenza di azioni che dovrà scatenare, attivando tutte le risorse necessarie con competenze adeguate.
Una serie di segnali deboli che non risultano sufficienti per la formulazione di una diagnosi corretta devono scatenare più azioni di approfondimento (non solo “visual inspection” sul campo ma anche analisi di dato) richiamando l’attenzione di operatori, che sulla base del loro background, attivano gli interventi necessari.
Si tratta sempre di un problema di processo e di risorse con skill adeguati al compito, in cui occorre, prima di tutto, che la soluzione che lo supporta sia conforme e non generalista, in grado cioè di entrare in merito di ciascuna questione a seconda della casistica, adeguando il processo.
Possiamo affermare che per governare un progetto 4.0 di “re-maintenance” oltre a skill “evoluti” con competenze di “data scientist”, “domain expert”, occorrono anche competenze di ingegneria gestionale per comprendere l’impatto e per attuare la re-ingegnerizzazione del processo nel miglior modo possibile.
Occorre prima di tutto “conoscere per decidere”, per arrivare all’approccio più adeguato e alle modalità di coinvolgimento delle risorse.
Cosa intendiamo per “conoscere”: definire in modo strutturato le strategie, calcolare i rischi (tutti), valutare gli strumenti e le risorse che possiamo mettere in campo, stimare saving generabili e ROI/Ritorni di Investimento, considerare gli impatti di quello che si andrà a fare, programmare l’intervento, avendo un approccio globale, … ed infine definire come misurare i risultati.
Gli aspetti legati alla gestione degli output impattano sulle modalità lavorative e gli elementi sopra menzionati non sono negoziabili se si vogliono ottenere certi risultati nel lungo periodo.
AS-IS iniziale per valutare il TO-BE meditato
Dal punto di vista metodologico, ogni fase del progetto deve essere, il più possibile “quick” e Agile: non è più pensabile applicare progetti di miglioramento che restino solo teorici o se applicati (Piloti, PoC, test, ...) non vengano messi a “sistema”.
Il modello Agile utilizza tecniche di pianificazione adattative e predittive più leggere del classico modello “a cascata”, che presuppone una sequenza ben definita di azioni da espletare, incoraggiando il lavoro di squadra, l’assunzione delle responsabilità tra tutti i membri del gruppo di lavoro e l’organizzazione di ognuno di loro.
L’assessment in una prima fase prevede la scomposizione funzionale (WBS - Work Breakdown Structure) del ciclo produttivo e degli impianti sulla base delle criticità rilevate a 360°: dalla HSE (Health Safety Operation) alla reputation, dalla normativa alla produzione. In sintesi occorre predisporre una Risk Analysis basata su:
- un’analisi dello storico degli eventi in senso ampio, in quanto la loro rilevazione è storicamente carente sia dal punto di vista quantitativo che qualitativo. L’attenzione deve essere focalizzata non solo sui guasti ma anche sugli eventi incidentali e di blocco: a tal riguardo costituiscono un elemento imprescindibile le informazioni raccolte dai conduttori/manutentori per identificare, anche su base esperienziale, le casistiche, le cause, l’eventuale ricambio coinvolto, gli impatti, le soluzioni adottate (azioni correttive);
- documenti progettuali, se esistenti, di analisi di rischio (HazOp, FMECA, LOPA, etc.)
L’assessment quindi procede con l’analisi dell’infrastruttura esistente, prevedendo il censimento delle seguenti informazioni:
1. Identificazione dei macchinari critici che, in caso di guasto:
- impattano fortemente sulla produzione (fermi e/o rallentamenti)
- comportano alti costi di manutenzione sono coinvolti in eventi di rischio catastrofici (Top Event)
2. Automazione
- identificazione del livello di automazione presente (PLC, DCS, SCADA, etc.)
- valutazione di un possibile upgrade
3. Sensoristica
- identificazione del livello di sensori installati (età, caratteristiche, storico manutentivo, livello di utilizzo, etc.)
- identificazione di nuovi sensori da installare o di esistenti da sostituire/manutenere
4. Misure acquisite
- Identificazione dei dati (misure, allarmi, soglie) esistenti in funzione della gestione del processo produttivo, del prodotto e della sua qualità, degli asset, di performance esempio energetiche;
- Valutazione della qualità del dato acquisito, della modalità, del tempo di campionamento e della storicizzazione;
- Valutazione dell’affidabilità del dato che deve essere messa in relazione alla finalità a cui è chiamato a dare una risposta. Il grado di accettabilità varia a seconda dell’impatto: sul semplice monitoraggio del sistema, sulla rilevazione (più o meno precoce) di malfunzionamenti, sul Plant and Production Performance, sull’identificazione automatica dello stato di funzionamento corretto del sistema (Health Status Index), sul controllo in real-time del rischio residuo. A questo aspetto storicamente non si dà il giusto peso in quanto si dà per scontato di avere a disposizione tutti i dati perfetti senza problemi di acquisizione, campionamento etc.
Invece per nostra esperienza diretta e indiretta, abbiamo appurato che il più grande limite in questi progetti è proprio la qualità del dato ed è anche la fase su cui si spende più tempo in assoluto (circa il 60% di un progetto).
5. Valutazione, in funzione degli scopi, di quali misure mancanti siano necessarie (con aggiunta di sensori o che possono essere determinate tramite “virtual sensor”) e che possono essere convenientemente utilizzate per la determinazione di “firme di guasto” o per una performance produttiva e in particolare:
- Valutazione puntuale di eventuali tecniche diagnostiche di Condition Based Maintenance adottate in passato e analisi dei benefici ottenuti.
- Valutazione della re-introduzione di tali tecniche e/o di nuove sia in logica service (a spot) sia in continuo.
Il To-Be: un modello predittivo
Un modello predittivo deve sempre essere messo in discussione, per cui nell’implementazione dello stesso ha un ruolo essenziale la gestione delle verifiche e dei “feedback”.
Sulla base delle valutazioni effettuate nell’assessment, nella prima fase del To-Be occorre fornire un quadro dettagliato degli output utili per la corretta comprensione dei fenomeni di guasto e/o di degrado:
1. Parametri/indici di salute del sistema
- Health Status Index (HSI): indice che fornisce lo stato di salute attuale di un generico asset e/o in generale del ciclo produttivo.
- Parametri ottimali di processo: variabili fisiche (pressioni, temperature, portate, livelli, etc.) mantenute all’interno della cosiddetta “forchetta” di buon funzionamento dal sistema di controllo.
2. Modalità di rilevamento delle anomalie
Allarme di superamento soglia con persistenza: generato quando l’indice considerato supera una soglia predeterminata e persiste in quella condizione anomala per un certo tempo prefissato.
Allarme di deviazione: generato quando l’indice o i parametri di processo considerati deviano rispetto al comportamento atteso (“forchetta” di buon funzionamento).
3. Classificazione delle anomalie
- Identificazione probabilistica della causa su base storica (a una certa rilevazione corrispondono una o più cause probabili).
- Identificazione della causa tramite correlazione tra tecniche CBM e funzionamento attuale del sistema.
- Identificazione della causa tramite correlazione con interventi manutentivi (esecuzione manutenzioni programmate nei tempi previsti, mancato censimento di interventi “piccoli” ma cruciali per la garanzia della continuità produttiva, etc.).
Sulla base degli output vengono definite quali azioni / interventi direttamente sul campo si devono intraprendere, cosa occorre verificare nell’esecuzione delle stesse e quali feedback trasmettere al sistema intelligente al fine di confermare o revisionare l’azione che hanno attivato.
Per raggiungere risultati sempre più affidabili, significativi, e utilizzabili occorre esplorare e analizzare i dati acquisiti, definire e consolidare il modello predittivo (Reinforcement Learning) e aggiornare costantemente i sistemi di preallerta (Early Warning). Tali attività sono inizialmente erogabili in service in quanto necessitano di skill polivalenti e specialistiche.
I temi che riguardano la determinazione di parametri ottimali di processo (qualità e performance produttive) correlati allo stato del sistema diventano prioritari e spesso anche più “semplici” da ottenere rispetto a parametri prognostici.
In conclusione senza una valutazione puntuale di tutti questi aspetti e senza una ri-progettazione delle modalità operative, si rischia di effettuare interventi non solo inefficaci, ma addirittura dannosi. A tal proposito le necessità di change management e formative delle risorse umane giocano un ruolo cruciale.
L’applicazione del pacchetto monitoraggio-diagnostica-prognostica-feedback costituisce il vero “game changer” per molti stakeholder in grado di influenzare le strategie di scelta delle politiche preventive ispettive e di manutenzione preventiva in generale.
Maurizio Ricci
CEO di IB Influencing Business; Consigliere A.I.MAN.
Alessio Martini
Reliability & Machine Learning Engineer di IB Influencing Business
