Modello di dominio operativo

Modello di dominio operativo

Operational Health Matrix si fonda su un modello di dominio operativo unificato che definisce le entità principali, le relazioni e le responsabilità nell’intera Piattaforma IIoT.

Ogni processo, Detector, endpoint API e componente analitico opera sullo stesso modello di dominio, garantendo la coerenza dell’intero sistema.

Il modello di dominio elimina le ambiguità, riduce al minimo la duplicazione dei dati e fornisce un linguaggio operativo comune a tutti i componenti della piattaforma.

Entità principali

Il dominio di Operational Health Matrix è costituito dalle seguenti entità primarie:

• Asset
• Detector
• Evidence
• Operational Issue
• Task
• Root Cause
• Health
• Knowledge Article
• Massive Incident
• SLA Policy
• Team
• User
• Notification
• Attachment
• Comment
• Audit Record

Ogni entità è titolare del proprio ciclo di vita e partecipa a uno o più flussi di lavoro operativi.

Asset (risorsa)

Asset è l’entità centrale della piattaforma.

Ogni oggetto fisico o logico monitorato è rappresentato come Asset.

Esempi tipici:

• contatore del gas
• sensore di pressione
• correttore
• RTU
• gateway
• controllore di valvola
• unità di telemetria
• dispositivo di comunicazione
• componente software

Ogni Asset contiene:

• un identificatore univoco;
• il tipo;
• il modello;
• il produttore;
• il numero di serie;
• il proprietario;
• la regione di esercizio;
• la configurazione;
• la versione del firmware;
• il profilo di comunicazione;
• lo stato del ciclo di vita.

Detector (rilevatore)

Detector è il componente analitico responsabile della trasformazione della telemetria in osservazioni operative.

Detector non crea logica di business.

La sua responsabilità si limita a individuare schemi osservabili e a produrre evidenze.

Gli attributi di Detector comprendono:

• Identifier
• Version
• Canon
• Confidence
• Status
• Accuracy Metrics
• Health

Evidence (evidenza)

Evidence rappresenta una prova immutabile a sostegno di una conclusione operativa.

Evidence può provenire da:

• telemetria;
• log di comunicazione;
• record di audit;
• conferma dell’utente;
• fotografie caricate;
• diagnostica di sistema;
• sistemi esterni.

Evidence non può essere modificata dopo la creazione.

Se è necessaria una correzione, viene creato un nuovo oggetto Evidence e la versione precedente viene conservata.

Operational Issue (problema operativo)

Operational Issue rappresenta un problema di esercizio confermato che richiede indagine o risoluzione.

Ogni Operational Issue contiene:

• Canon;
• Severity;
• Priority;
• Status;
• Owner;
• Root Cause;
• SLA Policy;
• Verification State;
• Operational History.

Operational Issue è l’oggetto operativo principale della piattaforma.

Task (attività)

Task rappresenta un’azione eseguibile necessaria per risolvere un Operational Issue.

I Task non possono esistere in modo autonomo.

Ogni Task appartiene a un solo Operational Issue.

Un Operational Issue può contenere più Task.

Root Cause (causa radice)

Root Cause rappresenta la causa di fondo confermata di uno o più Operational Issues.

Più Operational Issues possono fare riferimento alla stessa Root Cause.

Questa relazione rende possibile l’analisi operativa su scala aziendale e l’individuazione dei problemi ricorrenti.

Health (salute)

Health è un indicatore operativo calcolato.

Health esiste per:

• l’Asset;
• il sito;
• la regione;
• l’organizzazione;
• l’intero ecosistema.

I valori di Health sono sempre calcolati automaticamente.

Knowledge Article (articolo della base di conoscenza)

Knowledge Article conserva l’esperienza operativa validata.

Ogni articolo può fare riferimento a:

• problemi canonici;
• cause radice;
• tipi di Asset;
• versioni del firmware;
• procedure operative;
• documentazione del produttore.

Massive Incident (incidente massivo)

Massive Incident raggruppa più Operational Issues originati da un evento di esercizio comune.

Fornisce un unico oggetto di gestione per gli incidenti infrastrutturali su larga scala.

Principi operativi

Operational Health Matrix segue alcuni principi architetturali che definiscono il comportamento di ogni sottosistema.

L’Asset prima di tutto (Asset First)

Ogni evento di esercizio è associato a un Asset.

Gli Asset restano gli oggetti primari lungo l’intero ciclo di vita.

Gestione attraverso gli Issues

L’esercizio è gestito attraverso gli Operational Issues e non attraverso singoli allarmi o eventi di telemetria.

Decisioni guidate dalle evidenze

Ogni conclusione operativa deve essere supportata da uno o più oggetti Evidence.

Le ipotesi non supportate non vengono mai considerate fatti accertati.

Prima la causa radice, poi la risoluzione

Le azioni correttive, quando possibile, mirano alle cause confermate anziché ai sintomi osservabili.

L’uomo nel ciclo (Human-in-the-Loop)

La piattaforma supporta il processo decisionale operativo, ma non sostituisce mai la responsabilità ingegneristica.

Le azioni critiche richiedono una conferma umana esplicita.

Analisi spiegabile

Le conclusioni analitiche restano trasparenti.

Ogni raccomandazione include le evidenze a supporto e le informazioni sul livello di confidenza.

Audit immutabile

La cronologia operativa non può essere riscritta.

Ogni modifica produce un nuovo record di audit.

Approccio API-first

Ogni funzionalità della piattaforma è accessibile tramite API documentate.

Le interfacce utente e le integrazioni esterne si appoggiano agli stessi servizi operativi.

Architettura orientata agli eventi

Le modifiche operative vengono propagate sotto forma di eventi.

Questo rende possibili integrazioni asincrone e pipeline di elaborazione scalabili.

Modello dei dati operativi

La piattaforma adotta un modello dei dati operativi unificato.

flowchart TD
    A["Asset"] --> DET["Detector"]
    A --> EV["Evidence"]
    A --> ISSUE["Operational Issue"]
    ISSUE --> TASK["Task"]
    ISSUE --> RC["Root Cause"]
    ISSUE --> SLA["SLA Policy"]
    ISSUE --> CMT["Comment"]
    ISSUE --> ATT["Attachment"]
    A --> HLT["Health"]
    A --> KB["Knowledge Articles"]

Titolarità

Ogni entità ha esattamente un titolare del ciclo di vita.

Regole del ciclo di vita

Il modello di dominio rispetta alcuni invarianti:

• Gli Asset non vengono mai eliminati finché esistono Operational Issues storici.
• Evidence è immutabile.
• I Task non possono esistere senza un Operational Issue.
• Le Root Causes possono essere condivise da più Issues.
• I valori di Health sono calcolati e non possono essere modificati manualmente.
• Gli Audit Records sono gestiti in modalità append-only.
• Le Knowledge Articles restano versionate lungo tutto il loro ciclo di vita.

Questi vincoli garantiscono coerenza, tracciabilità e riproducibilità nell’intera piattaforma Operational Health Matrix.