Industry4.0 è un tag molto utilizzato che qualifica la cosiddetta quarta rivoluzione industriale, caratterizzata dall’introduzione non tanto dell’automazione in sé, quanto degli automi interconnessi e intelligenti.
Una rivoluzione a diverse marce, che incanala svariati interventi di riqualificazione e ammodernamento, targati #industry40 anche per approfittare, nel nostro territorio, di qualche finanziamento orientato ad incentivare il cambiamento attraverso il piano Industria 4.0, ora Impresa 4.0.
Gli ingredienti
Comunque lo si nomini, il tag 4.0 indica l’introduzione di agenti intelligenti e interconnessi nei sistemi produttivi e arriva come sintesi applicata di alcune tecnologie abilitanti, quali l’IoT, i Big Data, il Cloud e gli Advanced Analytics.
L’IoT si basa su un principio di scambio di dati: oggetti più o meno complessi (things) in grado di raccogliere dati locali attraverso sensori e di renderli disponibili in rete (Internet) recuperando dalla rete stessa informazioni di altri oggetti, che vengono utilizzani per assolvere un compito o fornire un servizio. Gli oggetti moderni nascono ormai dotati di una ricca sensoristica di bordo, ma vi è anche un’importante produzione autonoma di sensori sempre più raffinati, con capacità anche propria di connessione ed elaborazione, che permette di trasformare in “oggetti connessi” anche macchinari più datati. La sensoristica produce enormi quantità di dati, che possono essere semplicemente consumati da qualche oggetto oppure collezionati per analisi a posteriori, arrivando rapidamente a volumi da Big Data.
Big Data è soprattutto una tipologia di architettura in grado di accogliere ed elaborare grandi moli di dati eterogenei, quale può essere la massa critica prodotta dai sensori nell’IoT in un contesto di manutenzione predittiva (Product Data Management, PdM nel seguito).
Cloud è la modalità implementativa più adottata per rapidità di allestimento e disponibilità di offerta: sia chi propone soluzioni più centrate sull’IoT (Siemens Mindsphere, GE predix, etc.), sia chi è più sbilanciato sul fronte Analytics (SAP Leonardo, Azure ML, etc.), lo fa sostanzialmente in cloud. In ogni caso si intendono sistemi remoti (da cui l’attenzione alla quantità di dati trasportati) che non devono pesare sull’infrastruttura d’impianto, onde non inficiare anche il sistema di raccolta e/o contendersi le risorse disponibili per la gestione del processo produttivo.
Anche grazie ai Big Data, i cosiddetti Advanced Analytics basati su Machine Learning e AI hanno finalmente valicato le mura delle accademie e stanno entrando seriamente e massicciamente nel contesto industriale. Potendo sfruttare, infatti, la potenza dei cluster abilitano molti e ricchi scenari d’uso di grande interesse per le aziende di tutti i settori.
La PdM si colloca proprio su questo filone di tecnologie e competenze, promettendo minori costi di manutenzione e massimo rendimento dei macchinari (come nella manutenzione correttiva) senza però mettere a rischio la continuità della produzione (come nella manutenzione preventiva). Si tratta però (come quasi sempre in tema di analytics) di questioni complesse, che richiedono un significativo impegno e un cambiamento di mentalità che può anche sfociare in un ripensamento dei consolidati modelli operativi, sfidando le abitudini e la concezione stessa della manutenzione come funzione aziendale. Purtroppo, però, la difficoltà, anche culturale, di gestire un orizzonte previsionale con il relativo rischio produttivo e comprendere cosa significhi lavorare a partire dai dati e cosa sia possibile aspettarsi da ML/AI rischia di generare false aspettative e conseguenti delusioni che potrebbero far perdere una grande occasione.
Il corretto posizionamento
La naturale tendenza a semplificare e rifugiarsi in un orizzonte familiare porta a continui scivolamenti dal tema della PdM alle più praticate problematiche del Condition Based Monitoring (CBM nel seguito). Già nel nome è però indicato un altro livello di azione: quello del monitoraggio operativo, confuso con la predittiva perché anch’esso orientato ad allarmare prima del guasto (ma ormai imminente) attraverso sistemi più o meno complessi di regole (quindi rule-driven anzichè data-driven), volte a rilevare la criticità non appena ve ne siano le prime avvisaglie (early warning).
Rilevare una condizione appena possibile e ricondurne le modalità di evoluzione a note criticità non significa però fare previsione quanto piuttosto anomaly detection più o meno sensibile. Anche se non ancora in allarme, un fenomeno di derivazione è però già iniziato ed è questo che il CBM rileva. Cosa molto diversa dal prevedere uno stato futuro di derivazione quando non ce ne siano ancora i segnali diretti. In sostanza la differenza non è tanto il punto di arrivo, quanto quello di partenza, nel CBM si parla di qualcosa che è iniziato e che si concluderà in un tempo più o meno breve; nella PdM si parla di qualcosa che inizierà in un certo tempo e diventerà critico in un tempo ulteriore e più distante.
CBM e PdM: quali differenze?
Entrambe sono comunque tecniche importanti a garanzia dell’operatività degli impianti, ma con spazi di respiro sostanzialmente diversi:
- nel CBM, e in generale nella manutenzione preventiva di cui è forse l’espressione più avanzata, si cerca di ragionare sullo stato reale dei macchinari senza limitarsi al dato teorico di targa, monitorandone il comportamento in maniera puntuale per rilevare al più presto l’inizio di derive pericolose dei singoli componenti, considerati come unità elementari ed isolate
- nella PdM l’orizzonte si allarga dal singolo componente all’ecosistema di cui questo fa parte, includendo il comportamento degli elementi esterni che possono influire sul suo buon funzionamento. Si basa sulla previsione di uno stato futuro dell’ecosistema e del singolo componente al suo interno, e può dare spazio a innesti successivi molto interessanti per quanto riguarda la manutenzione proattiva, il best setting degli impianti, la correlazione tra processo produttivo e qualità del prodotto.
Il Condition Based Monitoring è strettamente legato al controllo delle grandezze fisiche dell’apparecchio, motivo per cui spesso è indirizzato dagli stessi produttori dei macchinari o dei sensori, in grado di ricavare dati già ben qualificati e regole di taratura delle soglie di controllo, se non già una soluzione di monitoraggio completa e “a scaffale”. Ciò porta a credere nella possibilità di una PdM ugualmente a scaffale, da verificare rapidamente e magari gratuitamente, per poi aprire a un semplice costo di licenza e installazione. Il contesto però è significativamente diverso e la soluzione pronta all’uso è una lusinga poco realistica che spesso maschera un CBM più o meno evoluto o genera aspettative che verranno sistematicamente deluse.
Se Product Data Management considera l’ecosistema di produzione in cui opera il singolo macchinario e i molteplici fattori che ne possono condizionare il funzionamento, è chiaro che non vi possa essere un setting universalmente valido. Ogni sistema produttivo è diverso dagli altri, il che si riflette sui dati prodotti e collezionati, sempre differenti anche a parità di infrastruttura perché diversi sono i processi/programmi produttivi implementati e variegate sono le casistiche riversate nei dati che guideranno le analisi (data driven). Questo rende poco realistica l’idea di un prodotto a scaffale pronto all’uso ma, d’altro canto, non si può neanche sviluppare un modello customizzato per ciascuna realtà produttiva. Pur rimanendo l’analisi data driven un’attività molto time consuming, è certo possibile realizzare modelli e strategie lasche, che non impongano requisiti stringenti e che possano adattarsi a diversi contesti con una relativamente contenuta attività di messa in opera.
Input e output
L’estrema specializzazione sulle grandezze fisiche dei singoli macchinari e componenti, utile nel CBM, diventa poco sostenibile nella PdM, dove si opta per sistemi ad apprendimento più neutro, non dipendenti dalla specifica grandezza e maggiormente centrati su concetti più generali di ecosistema, comportamento normale e comportamento deviante, declinati in modelli anche molto articolati in grado di istanziarsi sulla singola realtà dopo un periodo più o meno lungo di addestramento. Sono preferibili i modelli non supervisionati per rimanere laschi sui requisiti in ingresso (potrebbe non esserci una storia di guasti coerente) e rendere maggiormente adattativo il sistema, non istruito su contenuti magari superati (per modifica del processo produttivo, della linea, del contesto).
Infine, anche l’output di un sistema di PdM deve fare i conti con la singola realtà di impianto (il modello di gestione, il processo e gli strumenti con cui si gestiscono gli interventi e la pianificazione) per diventare davvero efficace. Le indicazioni previsionali di un sistema di PdM (stato di vita o vita residua dei componenti) inseriscono un fattore di rischio che va commisurato ai benefici potenziali e gestito insieme a tutti gli altri fattori sui cui ruota un piano di manutenzione (scorte a magazzino, disponibilità delle squadre, obiettivi di produzione, etc.). Deve quindi innestarsi un modello di gestione del rischio, sintomo ulteriore del cambio di mentalità che richiede la PdM.
Sfida della PdM nell’Industry 4.0
Una delle sfide non tecnologiche abilitate dall’Industry 4.0 riguarda quindi la capacità di ricollocare il modello di manutenzione anche in relazione alle altre funzioni aziendali, pensarla non come un costo di gestione ma come una risorsa a garanzia degli obiettivi del CEO, secondo paradigmi anche diversi (manutenzione proattiva, best setting, performance/disponibilità garantita per gli obiettivi della produzione, etc). La tecnologia è abilitante ma la rivoluzione 4.0 si compie se questa accompagna una profonda revisione dei modelli produttivi e dei ruoli aziendali.
Grazia Cazzin
