Modèle de domaine opérationnel

Modèle de domaine opérationnel

Operational Health Matrix repose sur un modèle de domaine opérationnel unifié qui définit les entités principales, les relations et les responsabilités à l’échelle de toute la Plateforme IIoT.

Chaque processus, chaque détecteur, chaque point de terminaison API et chaque composant analytique travaille sur ce même modèle de domaine, ce qui garantit la cohérence dans l’ensemble du système.

Le modèle de domaine lève les ambiguïtés, réduit au minimum la duplication des données et fournit un langage opérationnel commun à tous les composants de la plateforme.

Entités principales

Le domaine Operational Health Matrix se compose des entités principales suivantes :

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

Chaque entité possède son propre cycle de vie et participe à un ou plusieurs processus opérationnels.

Asset (actif)

Asset est l’entité centrale de la plateforme.

Tout objet physique ou logique supervisé est représenté par un Asset.

Exemples typiques :

• compteur de gaz
• capteur de pression
• correcteur
• RTU
• passerelle
• contrôleur de vanne
• unité de télémétrie
• équipement de communication
• composant logiciel

Chaque Asset contient :

• un identifiant unique ;
• le type ;
• le modèle ;
• le fabricant ;
• le numéro de série ;
• le propriétaire ;
• la région d’exploitation ;
• la configuration ;
• la version du firmware ;
• le profil de communication ;
• l’état du cycle de vie.

Detector (détecteur)

Detector est un composant analytique chargé de transformer la télémétrie en observations opérationnelles.

Detector ne crée pas de logique métier.

Sa responsabilité se limite à identifier des motifs observables et à produire des Evidence.

Les attributs de Detector sont les suivants :

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

Evidence (preuve)

Evidence est une preuve immuable qui étaye une conclusion opérationnelle.

Une Evidence peut provenir :

• de la télémétrie ;
• des journaux de communication ;
• des enregistrements d’audit ;
• d’une confirmation utilisateur ;
• de photographies téléversées ;
• des diagnostics système ;
• de systèmes externes.

Une Evidence ne peut pas être modifiée après sa création.

Si une correction est nécessaire, une nouvelle Evidence est créée et la version précédente est conservée.

Operational Issue (problème d’exploitation)

Operational Issue représente un problème d’exploitation confirmé qui nécessite une investigation ou une résolution.

Chaque Operational Issue contient :

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

Operational Issue est le principal objet opérationnel de la plateforme.

Task (tâche)

Task représente une action exécutable nécessaire à la résolution d’une Operational Issue.

Les Tasks ne peuvent pas exister de façon autonome.

Chaque Task appartient à exactement une Operational Issue.

Une Operational Issue peut contenir plusieurs Tasks.

Root Cause (cause racine)

Root Cause représente la raison sous-jacente confirmée d’une ou de plusieurs Operational Issues.

Plusieurs Operational Issues peuvent renvoyer à la même Root Cause.

Cette relation permet une analytique opérationnelle à l’échelle de l’entreprise et l’identification des problèmes récurrents.

Health (santé)

Health est un indicateur opérationnel calculé.

Health existe pour :

• un Asset ;
• un site ;
• une région ;
• une organisation ;
• l’écosystème dans son ensemble.

Les valeurs de Health sont toujours calculées automatiquement.

Knowledge Article (article de la base de connaissances)

Knowledge Article conserve un retour d’expérience opérationnel validé.

Chaque article peut faire référence :

• aux problèmes canoniques ;
• aux causes racines ;
• aux types d’actifs ;
• aux versions de firmware ;
• aux procédures d’exploitation ;
• à la documentation du fabricant.

Massive Incident (incident massif)

Massive Incident regroupe plusieurs Operational Issues nées d’un même événement d’exploitation.

Il offre un objet de gestion unique pour les incidents d’infrastructure de grande ampleur.

Principes opérationnels

Operational Health Matrix suit plusieurs principes d’architecture qui déterminent le comportement de chaque sous-système.

L’actif d’abord (Asset First)

Chaque événement d’exploitation est rattaché à un Asset.

Les Assets restent les objets principaux tout au long du cycle de vie.

Une exploitation centrée sur les Issues

L’exploitation est pilotée par les Operational Issues, et non par des alarmes ou des événements de télémétrie isolés.

Des décisions fondées sur les Evidence

Chaque conclusion opérationnelle doit être étayée par une ou plusieurs Evidence.

Les hypothèses non étayées ne sont jamais tenues pour des faits établis.

La cause racine avant la résolution

Les actions correctives visent, chaque fois que c’est possible, des causes confirmées plutôt que des symptômes observables.

L’humain dans la boucle (Human-in-the-Loop)

La plateforme accompagne la prise de décision opérationnelle, mais ne se substitue jamais à la responsabilité de l’ingénieur.

Les actions critiques exigent une confirmation humaine explicite.

Une analytique explicable

Les conclusions analytiques restent transparentes.

Chaque recommandation comporte les Evidence à l’appui et des informations sur le niveau de confiance.

Un audit immuable

L’historique d’exploitation ne peut pas être réécrit.

Chaque modification produit un nouvel enregistrement d’audit.

Approche API-first

Chaque fonctionnalité de la plateforme est accessible via des API documentées.

Les interfaces utilisateur et les intégrations externes s’appuient sur les mêmes services opérationnels.

Architecture pilotée par les événements

Les changements opérationnels sont propagés sous forme d’événements.

Cela permet des intégrations asynchrones et des chaînes de traitement évolutives.

Modèle de données opérationnel

La plateforme suit un modèle de données opérationnel unifié.

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"]

Propriété

Chaque entité a exactement un propriétaire de cycle de vie.

Règles de cycle de vie

Le modèle de domaine respecte plusieurs invariants :

• Les Assets ne sont jamais supprimés tant qu’il existe des Operational Issues historiques.
• Evidence est immuable.
• Les Tasks ne peuvent pas exister sans Operational Issue.
• Les Root Causes peuvent être partagées par plusieurs Issues.
• Les valeurs de Health sont calculées et ne peuvent pas être modifiées manuellement.
• Les Audit Records fonctionnent en mode append-only (ajout uniquement).
• Les Knowledge Articles restent versionnés tout au long de leur cycle de vie.

Ces contraintes garantissent la cohérence, la traçabilité et la reproductibilité dans toute la plateforme Operational Health Matrix.