Manutenzione predittiva ISO 13374 end-to-end: dal sensore alla prognosi, con un unico inbox di alert consolidato e un indice di salute che combina 5 segnali.

Monitoraggio Condizione

Il Monitoraggio Condizione è il sistema di manutenzione predittiva di Rela AI. Va oltre gli allarmi a soglia: impara come si comporta normalmente ogni asset, ne monitora la salute nel tempo, rileva anomalie con ML, stima quando potrebbe guastarsi e consolida tutti i segnali in una sola riga di alert per asset — non tre per lo stesso evento fisico.

Riepilogo esecutivo

Il cambio di gioco: smettere di reagire, iniziare ad anticipare. Prima tre sistemi indipendenti urlavano lo stesso e nessuno sapeva cosa fare. Oggi un unico inbox consolida rilevamenti meccanici, energetici e di vita utile in un solo alert per asset, con severità canonica A/B/C/D/F.

Prima vs Dopo

Dimensione	Prima (reattivo)	Dopo (Rela AI predittivo)
Rilevamento guasti	L'asset si rompe → chiamata → tecnico arriva	18–72h di anticipo con RUL stimato
Inbox operatore	3 alert per lo stesso picco	1 riga consolidata per asset
Decisione manutenzione	Calendario o reattiva	Condizione reale + confidenza + soglie per tenant
Segnale ML precoce	Ignorato fino all'allarme ISA-18.2	`anomaly_pressure` abbassa AHI dal primo evento
Drift silenzioso	Motore perde 0.5%/settimana per mesi	Page-Hinkley lo cattura entro 20 campioni
Tracciabilità	"Quale soglia era attiva quando fu A?" senza risposta	Ogni snapshot porta `config_version` tracciabile

A cosa serve

Manutenzione reattiva (aspettare il guasto) e preventiva a calendario sono i due estremi. La predittiva è il punto ottimale: intervenire esattamente quando serve, sulla base della condizione reale.

Il Monitoraggio Condizione permette di:

Rilevare il degrado graduale settimane prima del guasto.
Stimare la vita utile rimanente di un componente.
Prioritizzare manutenzione sugli asset che ne hanno davvero bisogno.
Ridurre fermi non pianificati.
Consolidare il rumore di più sistemi di rilevamento in un inbox azionabile.

Pipeline end-to-end

flowchart LR
  S[Sensori / PLC / SCADA] --> I[Ingestione MQTT / OPC UA / Modbus / S7 / EtherNet-IP / HTTP]
  I --> F[Field mapping + normalizzazione]
  F --> T[Trend + baseline]
  T --> A1[Rilevamento ML<br/>IsolationForest + LOF]
  T --> A2[Residui energia<br/>z-score + Page-Hinkley]
  T --> H[Asset Health Index<br/>5 sotto-indici]
  H --> P[Prognosi RUL<br/>+ CBM trigger]
  A1 --> AG[Alert Aggregator<br/>dedup per asset]
  A2 --> AG
  P --> AG
  AG --> INBOX[Inbox unificato<br/>1 riga per asset]
  INBOX --> TASK[Ordine di lavoro]
  INBOX --> CMMS[Sync CMMS]
  INBOX --> NOTIF[WhatsApp / Email]

Vedi Rilevamento Anomalie, Alert Aggregator, Protocolli Industriali.

ISO 13374 — 6 livelli

L1 — Acquisizione dati

Dati grezzi da sensori, PLC e SCADA arrivano via protocolli nativi: HTTP, MQTT, OPC UA (incl. Reverse Connect), Modbus TCP, S7comm, EtherNet/IP (CIP). Memorizzati con timestamp originale, normalizzati.

L2 — Analisi tendenze

Medie mobili, min/max, rate-of-change, deviazione standard.

L3 — Rilevamento stato

Due flussi complementari:

Condizione vs baseline.
Rilevamento anomalie ML — ensemble IsolationForest + LOF assegna score 0–1; >0.7 entra nell'inbox.

Ogni rilevamento viene tradotto in severità canonica (info/warning/high/critical).

L4 — Valutazione salute

AHI 0–100 combinando 5 sotto-indici:

Sotto-indice	Peso default	Misura
`condition`	0.35	Stato istantaneo vs baseline
`alarm_health`	0.20	Ore-allarme accumulate (ISA-18.2), cap per allarme
`maintenance_compliance`	0.15	Piani preventivi in ritardo
`trend_stability`	0.10	Direzione e r² delle tendenze 24h
`anomaly_pressure`	0.20	Densità di rilevamenti ML recenti (7g), pesato per severità

Pesi configurabili per tenant e per asset_type. Vedi Configurazione Predittiva.

Gradi:

Grado	AHI	Stato
A	90-100	Eccellente
B	70-89	Buono
C	50-69	Accettabile
D	30-49	Insoddisfacente
F	0-29	Critico

Soglie A/B/C/D configurabili via ahi_grades.

L5 — Prognosi

Da storia AHI: RUL con banda di confidenza bootstrap, tasso di degrado (punti AHI/giorno), trigger CBM, probabilità di guasto. Vedi Prognosi.

L6 — Raccomandazioni + inbox consolidato

IA genera raccomandazioni in linguaggio naturale. Ogni rilevamento finisce nell'Alert Aggregator.

Livelli di maturità predittiva

Livello	Nome	Requisiti	Capacità
0	Monitoraggio	Dati insufficienti	Alert basilari
1	Tracciamento salute	10+ snapshot	AHI attivo, tendenze visibili
2	Previsione	30+ snapshot + 1 guasto registrato	RUL affidabile, raccomandazioni
3	Ottimizzato	30+ snapshot + 3 guasti + confidenza > 70%	Automazione completa

Tracciabilità: `config_version`

Ogni snapshot di salute e ogni prognosi portano config_version — il numero della configurazione predittiva attiva al momento del calcolo. Gli alert passati non vengono riscritti; ogni uno mantiene la sua versione originale.

Casi d'uso con impatto misurabile

Caso 1 — Pompa catturata 18h prima. Compressore C-03 AHI passa 87 → 65 in 3 settimane. Prognosi stima 9 giorni a F. Task auto-creato; tecnico trova filtro olio ostruito. Sostituzione → AHI a 83 in 2 giorni.

Caso 2 — Drift silenzioso. Motore estrusore in ±2σ per 4 mesi ma deriva +0.3%/settimana. Page-Hinkley cattura il cambio di regime al campione 20.

Caso 3 — Inbox unificato. Picco di vibrazione su B-07 attiva 3 rilevatori. Prima: 3 alert. Dopo: 1 riga con source_systems = [anomaly, energy, prognostics]. Vedi caso Inbox Unificato.

Rollout

Fase 1 — collegare sorgenti, accumulare 7-14 giorni, rivedere trend. Fase 2 — calcolare baseline, addestrare modelli ML, attivare valutazione salute. Fase 3 — abilitare RUL, regolare alert_dedup_window_minutes, collegare raccomandazioni.

Benefici chiave

Reattivo → predittivo con giorni di anticipo.
Indice di salute a 5 segnali inclusa detection ML precoce.
Inbox unico con consolidamento cross-sistema.
Soglie per tenant e asset_type.
Tracciabilità config_version completa.
Rilevamento drift graduale (Page-Hinkley).
Standard ISO 13374.

Monitoraggio Condizione

In questa pagina