Guida operativa · Procedura operativa

Manutenzione Predittiva basata su Sensori IoT

Dal sensore alla decisione: dati riconoscibili e confrontabili aiutano a osservare le condizioni, verificare un’anomalia e seguire il lavoro. Diagnosi e prognosi richiedono riscontri e limiti; il PMS conserva responsabilità, attività ed esiti.

manutenzione predittivaIoTcondition monitoringdigital twin

Spiegazione operativa

Il sensore misura un fenomeno; la rete IoT rende disponibili dati e contesto. Il valore per la manutenzione nasce dal collegamento tra componente, modo di guasto, misura significativa e risposta prevista. Una curva che cambia non è ancora una diagnosi: può riflettere usura, un diverso carico o un problema del sensore.

Passaggio	Domanda cui risponde
Monitoraggio delle condizioni	Che cosa misuriamo e come cambia rispetto a una baseline pertinente?
Diagnosi	Quale condizione o causa può spiegare l’anomalia, con quali riscontri?
Prognosi	Come può evolvere la condizione, sotto quali ipotesi e con quale incertezza?
Decisione manutentiva	Quale azione è giustificata e autorizzata, chi la esegue e come se ne verifica l’esito?

Una strategia condition-based usa la condizione osservata per orientare l’intervento; la manutenzione predittiva aggiunge una previsione dell’evoluzione. Non ogni allarme contiene una previsione di vita residua. Un digital twin è una possibile rappresentazione dell’asset a supporto di determinate analisi, non il nome alternativo di un sensore o di ogni modello di anomalia. CIMAC 2025-04, concetti collegati.

Riferimento normativo

ISM 10.1–10.4: manutenzione secondo requisiti applicabili e Company, controlli a intervalli appropriati, segnalazione dei difetti con possibile causa se nota, azioni e registrazioni. La gestione digitale deve mantenere queste funzioni. ISM Code, §10.

Approved PMS/machinery survey arrangement, class notation, maker recommendations, ISM risk assessment e data governance.

Come esempio di schema di classe, DNV descrive un assetto CBM che combina manutenzione programmata e predittiva con un fornitore di servizio approvato. Verificare le regole e l’accettazione applicabili alla nave: la descrizione del servizio non autorizza da sola a prorogare visite o manutenzioni. DNV: Condition Based Maintenance.

Nel piano operativo identificare sensore, unità, carico e baseline; assegnare a una persona la verifica dell’allarme e la decisione documentata. Dati mancanti o un sensore guasto richiedono il metodo alternativo previsto e una segnalazione: l’assenza di allarmi non dimostra che il componente sia sano. IMO: ISM safety management.

La pagina DNV citata descrive un servizio di classificazione offshore: è un esempio di schema, non l’approvazione della nave. Se una modifica incide su attività o visite previste dall’assetto accettato, verificare la specifica accettazione prima di cambiare il piano; il dato non autorizza a superare una scadenza statutaria o un limite del maker.

Campo di applicazione

Applicare il monitoraggio ai componenti e ai modi di guasto per cui esistono misure significative e un processo di risposta. Definire quali attività restano a scadenza e quali rientrano nello schema condition-based accettato; una piattaforma IoT non estende da sola il campo dell’approvazione.

Procedura / Come si compila

Definire la domanda. Identificare componente e modo di guasto che si vuole osservare, misura utile e decisione supportata. Chiarire quali attività restano a scadenza e quale eventuale ramo condition-based è accettato.
Rendere il dato riconoscibile. Collegare sensore, ubicazione, unità, timestamp, condizioni di carico, stato di taratura e acquisizione. Individuare dati mancanti, ritardi o modifiche della catena; applicare il metodo alternativo previsto se il monitoraggio non è affidabile.
Confrontare in modo pertinente. Usare baseline e condizioni comparabili. Verificare sul macchinario e sul sensore un’anomalia prima di attribuirla a un guasto; distinguere osservazione, ipotesi diagnostica e previsione.
Assegnare la risposta. Il responsabile segue le istruzioni, valuta l’urgenza e attiva escalation o supporto tecnico previsti. La previsione dichiarata deve riportare ipotesi, campo d’uso e incertezza; non ignorare un segnale pericoloso in attesa del fornitore.
Collegare decisione e lavoro. Registrare dato/anomalia, valutazione, responsabile, decisione e attività nel PMS. Confermare accettazione e limiti prima di cambiare una scadenza; un alert chiuso sul software non prova che il difetto sia risolto.
Verificare il seguito. Confrontare l’esito del lavoro con i dati successivi e consegnare difetti aperti. Dopo modifiche al componente o alla misura, riesaminare la baseline secondo il programma. Valutare prestazioni documentate del sistema, comprese anomalie non rilevate e falsi allarmi, senza trasformarle in una promessa di risparmio.

Esempio pratico

Scenario didattico: la vibrazione di una pompa cresce rispetto al riferimento. Il team verifica identità e stato del sensore, carico e condizione dell’impianto, confrontando misure pertinenti. Il cambiamento è confermato, ma non basta per dichiarare un danno al cuscinetto o stimarne la vita residua: servono la valutazione tecnica e i riscontri previsti. Il responsabile registra la valutazione e segue il work order e la risposta operativa applicabili; dopo l’intervento collega il risultato al controllo successivo. L’alert non cancella le attività PMS e la sua tacitazione non chiude il seguito.

Cosa va tipicamente storto

Una serie dati apparentemente stabile può essere in realtà ferma all’ultima trasmissione; un’anomalia può dipendere da carico o sensore anziché dal componente. Se si interpreta ogni punto come una diagnosi certa, si può intervenire sulla causa sbagliata oppure rinviare un lavoro necessario. Stato del dato, contesto e riscontro tecnico devono restare visibili anche quando il software mostra un indicatore favorevole.

Errori ricorrenti Mistake Library

Errore	Conseguenza	Come evitarlo
Scambiare dati mancanti o non aggiornati per assenza di anomalie	Un problema può restare non osservato mentre il sistema sembra normale	Controllare timestamp, completezza e stato del sensore; attivare il metodo alternativo previsto
Confrontare misure a carichi diversi senza contesto	Un cambio operativo può essere interpretato come degrado	Confrontare condizioni pertinenti e registrare il carico
Trattare un alert o una stima di vita residua come ordine automatico	Decisione senza riscontro o rinvio fuori dal campo accettato	Separare diagnosi/prognosi, decisione del responsabile e limiti PMS/maker
Chiudere l’allarme senza documentare azione ed esito	Il difetto e il relativo seguito possono restare aperti	Collegare dato, work order, intervento e verifica successiva

Cosa controlla il PSCO

Se il monitoraggio è usato per sostenere manutenzione o condizioni di sicurezza, sono pertinenti piano applicabile, attività effettuate, difetti e relativo seguito. Il personale deve poter collegare dati e registrazioni allo stato reale del macchinario, chiarire cosa accade quando i dati non sono disponibili e mostrare il campo dell’eventuale schema accettato. Una dashboard favorevole non sostituisce questi riscontri. PSC 2025, appendici 6 e 7.

Suggerimenti operativi

Usare lo stesso identificativo del componente nei dati, nel PMS e nelle comunicazioni con il fornitore.
Annotare modifiche di carico, sensore o configurazione che cambiano il confronto con la baseline.
Rendere distinguibili fatti, ipotesi e previsioni nel passaggio di consegne.
Definire accesso, disponibilità e gestione sicura dei dati; per il quadro pertinente vedere Cyber Risk dei Sistemi di Automazione.

Checklist di preparazione

Componente, modo di guasto e decisione supportata individuati
Sensore, unità, tempo, carico e baseline riconoscibili
Qualità del dato, taratura e metodo alternativo identificati
Monitoraggio, diagnosi e prognosi distinguibili
Responsabile, risposta ed escalation previsti
Decisione/attività/esito collegati al PMS entro limiti e accettazioni applicabili
Difetti aperti e verifica successiva consegnati

FAQ

Predictive sostituisce automaticamente PMS?

No. Integrare le decisioni nel PMS e rispettare il campo dello schema accettato. Un allarme, una previsione di vita residua o dati mancanti non autorizzano automaticamente a rinviare un’attività.

Come si gestiscono dati mancanti o non aggiornati?

Identificare la lacuna e il suo effetto sull’analisi, segnalarla e applicare il metodo alternativo previsto. Tenere visibile la validità dei risultati: l’assenza di nuovi allarmi non dimostra la condizione del componente.

Un sensore IoT dà già una diagnosi o una prognosi?

Il sensore fornisce misure. L’interpretazione richiede contesto e riscontri; una prognosi aggiunge una previsione con ipotesi e incertezza. La decisione manutentiva segue il processo applicabile.

Argomenti correlati

Revisione sostanziale certificata: 12 ottobre 2026 · impronta della pagina 4af981a01b8f