Operational Health Matrix (OHM)

Operational Health Matrix (OHM) è il modulo operativo centrale della Piattaforma IIoT. Trasforma il flusso di telemetria, i risultati dell’analisi e gli eventi di esercizio in un ciclo di lavoro gestito: dal rilevamento automatico del problema alla risoluzione confermata dai dati.

OHM riunisce in un unico sistema:

• il rilevamento dei problemi tecnici, metrologici e di integrazione;
• la correlazione dei sintomi e l’individuazione della probabile causa radice;
• la creazione e la gestione degli oggetti Operational Issue;
• l’assegnazione dei reparti responsabili e degli assegnatari;
• la gestione di scadenze, priorità e SLA;
• la tenuta di attività, commenti, evidenze e cronologia delle azioni;
• la verifica automatica del risultato sui nuovi dati;
• la gestione degli incidenti massivi;
• la valutazione dello stato delle apparecchiature e del parco;
• il calcolo dei KPI operativi e di team;
• l’accumulo delle soluzioni confermate nella base di conoscenza;
• il supporto AI all’analisi, senza delegare all’intelligenza artificiale il potere di prendere decisioni critiche.

flowchart TD
  A["Telemetria"] --> B["Detector"]
  B --> C["Evidence"]
  C --> D["Correlazione e Root Cause"]
  D --> E["Operational Issue"]
  E --> F["Assegnazione ed esecuzione"]
  F --> G["Verifica sui dati"]
  G --> H["Chiusura e Knowledge Base"]
  H --> I["KPI e miglioramento continuo"]

Scopo del modulo

I sistemi di telemetria tradizionali rispondono bene alla domanda:

Che cosa è successo al dispositivo o ai dati?

Ma per gestire un parco di grandi dimensioni questo non basta. Dopo il rilevamento di un evento, l’organizzazione deve stabilire:

• se il segnale rappresenti un problema reale;
• se riguardi un singolo dispositivo o costituisca un incidente sistemico;
• quali altri sintomi siano collegati alla stessa causa radice;
• chi sia responsabile della risoluzione;
• entro quando debba essere completato il lavoro;
• quali azioni siano già state intraprese;
• se la risoluzione sia stata confermata da dati oggettivi;
• se il problema sia ricorrente;
• quanto sia efficace il processo operativo.

OHM chiude l’intero ciclo.

Il risultato principale del modulo non è una notifica né una riga di report, ma un oggetto operativo gestito dotato di:

• un identificatore;
• un tipo di problema;
• gli Asset interessati;
• le evidenze;
• una severità (Severity);
• un livello di confidenza;
• una causa radice probabile e una confermata;
• un responsabile;
• un assegnatario;
• una scadenza;
• le attività;
• la cronologia;
• uno stato di verifica;
• l’esito della risoluzione;
• un collegamento alla base di conoscenza;
• un impatto sui KPI.

Vantaggio chiave

La piattaforma non si limita a registrare gli scostamenti. La piattaforma segue il problema fino a un risultato confermato.

flowchart TD
  subgraph OPS["Piattaforma IIoT e OHM"]
    direction TB
    O1["Ha rilevato il problema"] --> O2["Ha verificato le evidenze"]
    O2 --> O3["Ha consolidato i segnali correlati"]
    O3 --> O4["Ha determinato la priorità"]
    O4 --> O5["Ha assegnato la zona di responsabilità"]
    O5 --> O6["Controlla la scadenza"]
    O6 --> O7["Ha verificato il risultato sui dati"]
    O7 --> O8["Ha conservato la soluzione confermata"]
  end
  subgraph MON["Sistema di monitoraggio"]
    direction TB
    M1["Ha rilevato il problema"] --> M2["Qui il lavoro del sistema finisce"]
  end

Di conseguenza OHM porta l’esercizio da una modalità reattiva a un modello gestito, in cui ogni scostamento significativo ha un responsabile, una scadenza, le proprie evidenze e un risultato misurabile.

Principi fondamentali

Issues al posto degli allarmi

Un singolo allarme non equivale sempre a un problema operativo.

Un solo guasto fisico può generare decine o centinaia di eventi:

• assenza di sessione di comunicazione;
• assenza di archivio;
• dati obsoleti;
• stato della batteria sconosciuto;
• assenza della pressione attuale;
• errore di consegna.

OHM non crea un’attività separata per ogni sintomo. Il sistema correla i segnali e genera un unico Operational Issue quando essi hanno una causa comune.

Operazioni guidate dalle evidenze (Evidence)

Ogni conclusione automatica deve essere spiegabile.

Un Issue contiene:

• i valori di origine;
• le marche temporali;
• l’identificatore del Detector;
• la versione dell’algoritmo;
• le soglie applicate;
• il collegamento al report specializzato di riferimento;
• la cronologia delle ricorrenze;
• i segnali correlati;
• il risultato della correlazione.

L’utente può sempre ricostruire il percorso dalla telemetria grezza fino all’Issue creato.

Prima la causa radice (Root Cause)

OHM distingue tra:

• il sintomo — lo scostamento osservato;
• la causa — il fattore tecnico o organizzativo che ha prodotto lo scostamento;
• la causa radice — il fattore primario la cui eliminazione impedisce il ripetersi di un gruppo di sintomi.

Esempio:

flowchart LR
  S1["Sintomo 1: archivio orario mancante"] --> RC["Probabile causa radice: degrado della fonte di alimentazione"]
  S2["Sintomo 2: ultima sessione 9 giorni fa"] --> RC
  S3["Sintomo 3: la tensione della batteria era in calo"] --> RC
  S4["Sintomo 4: la durata delle sessioni era in aumento"] --> RC

Chiusura confermata dai dati

L’assegnatario dichiara che il lavoro è stato eseguito, ma lo stato finale resolved viene impostato solo dopo la verifica del risultato.

flowchart TD
  V1["Lavoro eseguito"] --> V2["awaiting_verification"]
  V2 --> V3["I nuovi dati confermano la normalizzazione"]
  V3 --> V4["resolved"]

Per i problemi non verificabili tramite telemetria si applica una verifica manuale controllata, con commento obbligatorio ed evidenza a supporto.

L’Asset al centro del modello

Tutti gli eventi, gli Issues, le lavorazioni e gli indicatori sono collegati agli Asset:

• nodi di misura;
• correttori;
• contatori;
• sensori;
• modem;
• gateway;
• schede SIM;
• componenti server;
• canali di integrazione;
• versioni software.

La scheda dell’Asset mostra la salute attuale, la cronologia del degrado, gli Issues attivi, i lavori eseguiti e la ricorrenza dei problemi.

La responsabilità resta all’uomo, l’AI assiste

L’AI aiuta a:

• sintetizzare le Evidence;
• ordinare le ipotesi per rilevanza;
• trovare casi simili;
• proporre soluzioni note;
• individuare nuovi cluster;
• prevedere il rischio di guasto.

L’AI non può, autonomamente:

• modificare la priorità;
• assegnare la responsabilità;
• chiudere un Issue;
• confermare una root cause come fatto accertato;
• modificare gli SLA;
• eseguire azioni critiche sulle apparecchiature.

Riproducibilità per costruzione

Tutti i calcoli significativi sono riproducibili. Per ogni risultato la piattaforma conserva:

• la versione del Detector;
• la versione del Canon;
• la versione del modello di correlazione;
• il set di dati utilizzato;
• l’ora del calcolo;
• le soglie;
• la configurazione;
• l’origine della modifica.

OHM nell’architettura della Piattaforma IIoT

OHM si colloca tra il livello analitico e la gestione operativa.

flowchart TD
  PHY["Asset fisici"] --> DATA["Livello dati e integrazione IIoT"]
  DATA -->|"Dati normalizzati"| ANL["Analisi e rilevamento"]
  ANL -->|"Evidence e risultati dell'analisi"| OHM["Operational Health Matrix"]
  OHM -->|"API, eventi, integrazione"| ENT["Sistemi aziendali"]

Composizione dei livelli:

Fonti di dati

OHM utilizza:

• la telemetria attuale;
• gli archivi orari, giornalieri e a evento;
• i log delle sessioni di comunicazione;
• i dati di passaporto e di registro;
• gli stati dei dispositivi;
• i dati della batteria;
• pressione, temperatura, portata e volume;
• gli eventi di manomissione;
• le versioni del firmware;
• i parametri di comunicazione;
• i risultati dei report specializzati;
• le osservazioni manuali degli utenti;
• gli eventi dei sistemi esterni.

Fornitori di Evidence

Qualsiasi modulo analitico della piattaforma può fungere da fonte di evidenza.

Esempi:

Esplora il modulo