Manutenzione predittiva AI per PMI manifatturiere: 6 casi d’uso nel 2022

Nelle PMI manifatturiere italiane il downtime non pianificato erode tra il 5% e il 15% del fatturato annuo. Quando una pressa si ferma per un cuscinetto grippato o un compressore va in blocco per una valvola che nessuno controllava da mesi, il costo non e’ solo la riparazione: e’ l’ordine cliente saltato, l’operatore fermo, la consegna in penale e l’effetto a catena su tutta la linea. La manutenzione predittiva basata su AI e’ una delle promesse piu’ concrete dell’Industria 4.0: usare sensori IoT e modelli di machine learning per anticipare il guasto giorni o settimane prima che accada, programmando l’intervento quando conviene e non quando il guasto impone.

Nel 2022 questa tecnologia ha smesso di essere un esperimento da multinazionali: la combinazione di Transizione 4.0 (credito d’imposta confermato dal PNRR), hardware edge low-cost (Raspberry Pi, NVIDIA Jetson Nano) e librerie open source mature (scikit-learn, TensorFlow 2.x, PyTorch 1.10) ha abbassato la barriera d’ingresso anche per le PMI. Servono pero’ una data foundation, storici dei guasti e manutentori coinvolti. In questo articolo vediamo sei casi d’uso reali per il manifatturiero italiano, l’architettura tipica, i modelli ML praticabili, il ROI realistico e una roadmap di 90 giorni per il pilota.

Reactive, preventive, predictive, prescriptive: capire le differenze prima di partire

Confondere questi quattro approcci e’ l’errore numero uno. La manutenzione reattiva (“run-to-failure”) interviene dopo il guasto: economica all’apparenza ma costosa nei fatti, perche’ il guasto avviene quando vuole lui. La manutenzione preventiva (PvM) interviene su calendario o ore di funzionamento — cambio cuscinetto ogni 4.000 ore, sostituzione olio ogni 6 mesi. E’ lo standard di chi segue lo schema del costruttore. Riduce i guasti ma butta valore: sostituisci componenti che avrebbero retto altre 1.500 ore e a volte cambi un pezzo OK lasciando in linea uno che sta cedendo.

La manutenzione predittiva (PdM) cambia l’angolo: monitora la macchina in tempo reale tramite sensori e usa modelli statistici o ML per stimare quando un componente sta degradando. L’intervento avviene quando il modello segnala anomalia, idealmente con 5-30 giorni di anticipo. La manutenzione prescrittiva aggiunge il consiglio sull’intervento, l’ordine dei pezzi e la finestra ottimale. Per la maggior parte delle PMI italiane il salto realistico nel 2022 e’ dalla preventiva alla predittiva: la prescrittiva resta un obiettivo a 2-3 anni una volta che il monitoraggio condizionale (ISO 17359) e’ stabile.

Prerequisiti: la data foundation che nessuno ti racconta

Tutti i fornitori PdM mostrano dashboard luccicanti, ma il primo discorso onesto da fare in azienda e’: “Il tuo modello vale quanto i tuoi dati”. Servono tre cose. Prima: uno storico guasti etichettato, anche un Excel iniziale, dove per ogni macchina critica sia tracciato quando si e’ rotta, cosa, quante ore di fermo, che intervento. Senza questo storico anche sei mesi di dati IoT non bastano. Seconda: sensori coerenti con il modo di rottura. Se l’80% dei guasti sui motori sono da squilibrio o disallineamento, serve un accelerometro triassiale a 10+ kHz, non una sonda di temperatura. Mappare i failure modes (FMEA) prima dei sensori risparmia mesi.

Terza: una baseline “sana”. Il modello impara l’anomalia confrontandola col normale: servono 30-90 giorni di dati operativi tipici prima che un autoencoder o un Isolation Forest diano output affidabili. Se la macchina e’ gia’ degradata, il “normale” del modello sara’ il “degradato”: rischi di non vedere nulla fino al guasto catastrofico. In quel caso conviene un modello supervisionato dopo aver raccolto guasti reali, o sensori temporanei a noleggio per costruire una baseline aggiuntiva.

Architettura tipica di un sistema PdM per PMI

L’architettura che vediamo funzionare meglio in stabilimenti da 20-200 macchine ha cinque strati ben definiti. Al livello campo ci sono i sensori: accelerometri MEMS triassiali (range 0-16 g, banda 0-10 kHz tipica), termocoppie K, RTD Pt100, sensori di corrente Hall, sensori di pressione 4-20 mA, eventualmente microfoni industriali. I sensori si collegano a un gateway edge: un Raspberry Pi 4 va bene per progetti pilota fino a 8-16 canali; per linee critiche o ML in locale si passa a NVIDIA Jetson Nano (4 GB) o Jetson Xavier NX dove serve potenza GPU.

Il gateway pubblica le metriche su MQTT (broker Mosquitto, EMQX o HiveMQ self-hosted) o legge dal PLC via OPC UA quando il PLC e’ moderno (Siemens S7-1500, Beckhoff TwinCAT). Da li i dati vanno in un database time-series: InfluxDB 2.x o TimescaleDB su PostgreSQL sono le scelte piu’ diffuse, entrambe open source, entrambe scalabili. Sopra il database gira il layer ML: scikit-learn per modelli classici, TensorFlow 2.x o PyTorch 1.10 per le reti neurali, MLflow come model registry. Il modello puo’ girare in edge (sulla Jetson, con TensorFlow Lite o ONNX Runtime) oppure in cloud (AWS IoT Greengrass, Azure IoT Edge, Siemens MindSphere, PTC ThingWorx, Schneider EcoStruxure). Infine il layer di visualizzazione e alert: Grafana per le dashboard, integrazione con il MES e con il CMMS (Computerized Maintenance Management System) per generare l’ordine di lavoro automatico.

Caso 1: motori elettrici asincroni — analisi vibrazionale

I motori asincroni sono ovunque nello stabilimento manifatturiero: ventilatori, pompe, nastri, agitatori. Le tre cause di guasto principali — squilibrio, disallineamento, problemi al cuscinetto — hanno tutte una firma vibrazionale ben definita. Lo squilibrio appare come picco a 1x la frequenza di rotazione, il disallineamento a 2x, il difetto cuscinetto a frequenze specifiche calcolabili dalla geometria del cuscinetto (BPFO, BPFI, FTF, BSF). Un accelerometro triassiale piazzato in prossimita’ del cuscinetto, che campiona a 10-25 kHz, fornisce il segnale necessario.

Il modello ML praticabile e’ duplice. Un primo strato non supervisionato (Isolation Forest o autoencoder convoluzionale 1D) impara la “firma sana” e segnala quando il segnale si discosta. Un secondo strato supervisionato — un Random Forest o un XGBoost addestrato su feature estratte dallo spettro FFT — classifica il tipo di guasto. Una PMI metalmeccanica veneta con 35 motori critici nel 2021 ha installato accelerometri wireless su 12 motori prioritari e in 8 mesi ha intercettato 4 guasti con oltre 15 giorni di anticipo, evitando circa 60.000 € di mancata produzione su uno dei motori che alimentava un’isola robotizzata. Il payback dei sensori (circa 18.000 € hardware + 22.000 € integrazione) si e’ chiuso in meno di un anno.

Caso 2: cuscinetti volventi — FFT, envelope e deep learning

I cuscinetti meritano un caso a parte perche’ sono ovunque e perche’ la diagnostica vibrazionale dei cuscinetti e’ una scienza matura da decenni. Le frequenze caratteristiche dei difetti (BPFO per pista esterna, BPFI per pista interna, BSF per sfere, FTF per gabbia) sono calcolabili in modo deterministico. La tecnica classica e’ l’analisi dell’inviluppo (envelope analysis): il segnale viene filtrato in un range di alta frequenza, raddrizzato e demodulato per rivelare le frequenze caratteristiche, anche quando il difetto e’ incipiente e mascherato dal rumore.

Il valore aggiunto dell’AI rispetto al solo envelope sta nella stima del Remaining Useful Life (RUL). Modelli LSTM addestrati su sequenze di feature spettrali storiche permettono di stimare, con un intervallo di confidenza, quante ore di funzionamento rimangono prima del guasto. Per una PMI con presse a controllo numerico questo significa pianificare la sostituzione cuscinetto durante un fermo programmato anziche’ un giovedi’ alle 17 con l’ordine cliente da chiudere. Esistono dataset pubblici molto utili per addestrare modelli di base (NASA Bearing Dataset, FEMTO-ST PRONOSTIA, Case Western Reserve University) che permettono di partire anche con pochi dati propri usando tecniche di transfer learning.

Caso 3: presse idrauliche — pressione, flusso e anomaly detection

Sulle presse idrauliche i guasti tipici sono la perdita di pressione (valvola sporca, guarnizione consumata), il degrado dell’olio (viscosita’, contaminazione metallica) e l’usura della pompa. I sensori chiave sono trasduttori di pressione installati a monte e a valle delle valvole principali, sensori di portata, termocoppie per la temperatura dell’olio e — sempre piu’ diffusi — sensori di particelle metalliche per il monitoraggio dell’olio in linea.

La pressione di lavoro segue cicli ben definiti (compressione, mantenimento, rilascio): un autoencoder ricorrente addestrato sui cicli “sani” diventa molto sensibile a deviazioni minime nella forma d’onda, che spesso anticipano di settimane il guasto manifesto. Una variante particolarmente efficace per le presse e’ confrontare cicli omologhi (stesso codice articolo, stesso stampo): il modello impara la forma del ciclo per quel prodotto e segnala quando la pressione di picco scende di pochi punti percentuali — segnale tipico di una valvola che inizia a perdere. Integrare il sensore con il MES (per sapere quale articolo si sta producendo) raddoppia l’accuratezza del modello.

Caso 4: compressori — temperatura, vibrazione e modelli ibridi

I compressori d’aria o frigoriferi sono asset critici: quando si fermano, si ferma mezzo stabilimento. I parametri da monitorare sono la temperatura di mandata, la pressione differenziale, il consumo di corrente, le vibrazioni del compressore stesso e, sui rotativi a vite, la temperatura olio. Il caso d’uso classico e’ il riconoscimento precoce del degrado del separatore aria-olio, della valvola di minima pressione e del cuscinetto del rotore.

Sui compressori funzionano molto bene i modelli ibridi physics-informed: si parte da un modello termodinamico semplificato del compressore (in base al ciclo di lavoro teorico ti aspetti certe temperature e potenze) e si addestra un modello ML a stimare il residuo tra valore osservato e valore atteso. Quando il residuo cresce in modo sistematico, qualcosa nel compressore non e’ piu’ come da progetto: spesso 7-15 giorni prima del guasto manifesto. Aziende come Atlas Copco, Kaeser e Boge offrono gia’ nel 2022 servizi PdM nativi sui loro compressori connessi; per parchi misti o piu’ datati conviene una soluzione di terze parti con sensori applicati a posteriori (retrofit).

Caso 5: robot industriali a 6 assi — firme di corrente e usura riduttori

Su un braccio robot collaborativo o industriale a 6 assi (KUKA, ABB, FANUC, Universal Robots, Comau) i guasti piu’ frequenti riguardano i riduttori epicicloidali Harmonic Drive o RV e i motori brushless degli assi. Il vantaggio enorme rispetto agli asset “stupidi” e’ che il controller del robot espone gia’ tramite OPC UA o Profinet le correnti di asse, le coppie, le posizioni: spesso non servono sensori aggiuntivi, basta leggere ad alta frequenza i registri del controller.

L’analisi delle firme di corrente (motor current signature analysis, MCSA) e’ una tecnica matura: traiettorie ripetute generano profili di corrente ripetibili, e un modello LSTM o un autoencoder addestrati sulle firme “buone” individuano rapidamente le derive. L’esperienza pratica mostra che il primo segnale di un riduttore che sta cedendo e’ un piccolo incremento della corrente RMS dell’asse coinvolto (1-3%) accompagnato da micro-oscillazioni di velocita’: segnali invisibili a occhio nudo ma chiarissimi al modello. Su una linea di assemblaggio automotive italiana con 24 robot, un’azienda partner ha implementato il monitoraggio sul software interno e nel 2021 ha intercettato 3 cedimenti di riduttori RV in tempo per pianificare il cambio durante i fermi natalizi, risparmiando oltre 70.000 € di mancata produzione.

Caso 6: linee di produzione — vision AI per qualita’ e usura utensili

Il sesto caso d’uso spinge la PdM oltre i sensori tradizionali con la visione artificiale. Una telecamera industriale (Basler, IDS, Cognex) che inquadra il prodotto in uscita o un dettaglio dell’utensile diventa un sensore di anomalia potentissimo. Due i casi pratici. Primo: controllo qualita’ automatico via CNN addestrate su immagini di pezzi conformi, che rilevano graffi, sbavature e deformazioni prima che diventino sistematici. Un aumento statisticamente significativo dei difetti e’ spesso il segnale che un utensile (stampo, punzone, fresa) sta arrivando a fine vita.

Secondo: monitoraggio diretto dell’utensile. Su fresatrici CNC una telecamera che ispeziona il tagliente tra le lavorazioni, accoppiata a un modello di classificazione, predice quando sostituire evitando sia lo spreco da sostituzione anticipata sia il guasto durante la lavorazione. PyTorch + Detectron2 o TensorFlow + Object Detection API portano modelli accurati anche su Jetson edge. E’ il caso che richiede piu’ attenzione su data quality (illuminazione costante, calibrazione camera) ma che paga di piu’ in qualita’ percepita dal cliente.

Edge vs cloud: dove far girare il modello

La scelta edge/cloud non e’ ideologica ma operativa. Far girare il modello in edge (Jetson o Raspberry Pi accanto al macchinario) ha tre vantaggi: latenza minima, nessuna dipendenza dalla rete e riduzione del costo banda. Lo svantaggio e’ la complessita’ di gestione: aggiornare un modello su 30 edge device richiede una pipeline OTA ben fatta, e l’hardware in campo soffre polvere, temperatura e vibrazioni.

Il cloud (AWS IoT Core + SageMaker, Azure IoT Hub + ML, Siemens MindSphere, PTC ThingWorx) e’ piu’ semplice da gestire e scala bene. La raccomandazione pratica e’ un’architettura ibrida: training in cloud, inferenza in edge per il real-time, sincronizzazione cloud per dashboard aggregate. AWS IoT Greengrass e Azure IoT Edge sono progettati per questo scenario, con distribuzione automatica dei modelli agli edge device.

I modelli ML che funzionano davvero in PdM

Nella pratica industriale del 2022, su PMI manifatturiere, quattro famiglie di modelli coprono il 90% dei casi. Il primo, da cui si parte quasi sempre, e’ l’anomaly detection non supervisionata: Isolation Forest, One-Class SVM, autoencoder densi o convoluzionali. Si usa quando hai abbondanza di dati “normali” e pochi guasti etichettati. Output tipico: un punteggio di anomalia per finestra temporale.

Il secondo gruppo e’ la classificazione supervisionata dei guasti: Random Forest, XGBoost, LightGBM, CNN su spettri FFT. Si usa quando hai uno storico etichettato e vuoi sapere il tipo di anomalia. Il terzo e’ la regressione per Remaining Useful Life: LSTM o GRU su sequenze, modelli di sopravvivenza statistici. Richiede dati run-to-failure storici. Il quarto sono gli autoencoder convoluzionali e architetture transformer-light per sequenze multivariate (vibrazione + temperatura + corrente). MLflow come model registry e Databricks o Snowflake come data platform sono sempre piu’ lo standard anche mid-market.

ROI tipico, business case e Transizione 4.0

Parlare di ROI in PdM senza numeri seri e’ inutile. Sulla base di progetti reali italiani 2020-2022, una PMI manifatturiera con 50-200 dipendenti che implementa un programma PdM su 10-20 asset critici puo’ aspettarsi: 15-30% di riduzione del downtime non pianificato, 10-20% di riduzione dei costi di manutenzione totale (perche’ si interviene meno su componenti sani e meno in emergenza), 5-15% di aumento dell’OEE (Overall Equipment Effectiveness) e un payback dell’investimento iniziale tra i 12 e i 18 mesi. Quando il programma e’ fatto bene il payback puo’ scendere sotto i 9 mesi.

L’investimento per partire e’ meno alto di quanto si pensi: 800-2.500 € per asset in hardware sensori e gateway, 15.000-40.000 € per software, integrazione e modelli ML per un pilota su 8-15 asset. Sui beni 4.0 (e i sistemi PdM lo sono, se interconnessi con il MES) il credito d’imposta Transizione 4.0 previsto dal PNRR copre quote significative dell’investimento: fino al 40-50% per beni strumentali immateriali 4.0 e quote rilevanti anche sui materiali, con tetti di spesa pluriennali. Le aliquote sono cambiate piu’ volte tra leggi di Bilancio: vanno verificate per l’anno di investimento, ma il principio resta. Il credito si fruisce in compensazione su F24 in tre quote annuali, quindi conviene strutturare il progetto in modo da rispettare i requisiti di interconnessione e perizia tecnica.

I cinque errori che vediamo piu’ spesso (e come evitarli)

Avendo seguito decine di progetti PdM in PMI italiane, gli errori si ripetono. Primo: sottostimare la qualita’ dei dati. Se i timestamp non sono allineati, se il segnale ha rumore EMI, se il sensore e’ montato male, il modello impara spazzatura. Investi su un buon ingegnere dei dati prima che su un data scientist. Secondo: non avere guasti etichettati. Senza storico parti unsupervised, raccoglie esempi i primi 6 mesi e l’anno dopo classifica.

Terzo: ignorare i manutentori. Un modello che alza alert ignorati e’ peggio di nessun modello. Coinvolgi i manutentori dalla FMEA al design dell’alert. Quarto: aspettarsi il modello universale: non esiste, ogni macchina ha la sua firma, la PdM e’ fatta di 50 modelli specifici. Quinto: non integrare con MES e CMMS. Un alert su Grafana che nessuno trasforma in ordine di lavoro automatico nel CMMS muore in due settimane.

Il team che serve davvero

Una PMI non deve assumere un dipartimento di data scientist. Il team minimo per un pilota di 90 giorni e’ di tre profili: un data engineer / IoT engineer per sensori, gateway, broker MQTT e time-series DB; un data scientist con esperienza specifica di segnali industriali; un esperto di dominio, tipicamente il capo manutenzione, che conosce le macchine. Senza l’esperto di dominio il progetto resta accademico. Si aggiunge un system integrator per il collegamento MES/CMMS, spesso esterno. Il data scientist puo’ essere esternalizzato i primi 6-12 mesi; poi conviene internalizzare almeno parzialmente per gestire il re-training continuo dei modelli.

Roadmap di un pilota PdM in 90 giorni

Concludiamo con un piano concreto. Un pilota PdM ben fatto in 90 giorni e’ assolutamente fattibile e produce risultati misurabili. La sequenza che funziona e’:

Domande frequenti sulla manutenzione predittiva AI per PMI