Operatives Domänenmodell

Operatives Domänenmodell

Die Operational Health Matrix baut auf einem einheitlichen operativen Domänenmodell auf, das die Kernentitäten, Beziehungen und Zuständigkeiten in der gesamten IIoT-Plattform festlegt.

Jeder Prozess, jeder Detector, jeder API-Endpunkt und jede analytische Komponente arbeitet mit demselben Domänenmodell, wodurch Konsistenz im gesamten System sichergestellt wird.

Das Domänenmodell beseitigt Mehrdeutigkeiten, minimiert die Duplizierung von Daten und gibt allen Komponenten der Plattform eine gemeinsame operative Sprache.

Kernentitäten

Die Domäne der Operational Health Matrix besteht aus den folgenden primären Entitäten:

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

Jede Entität besitzt einen eigenen Lebenszyklus und ist an einem oder mehreren operativen Arbeitsabläufen beteiligt.

Asset (Betriebsmittel)

Asset ist die zentrale Entität der Plattform.

Jedes überwachte physische oder logische Objekt wird als Asset abgebildet.

Typische Beispiele:

• Gaszähler
• Drucksensor
• Mengenumwerter
• RTU
• Gateway
• Ventilsteuerung
• Telemetrieeinheit
• Kommunikationsgerät
• Softwarekomponente

Jedes Asset enthält:

• eindeutige Kennung;
• Typ;
• Modell;
• Hersteller;
• Seriennummer;
• Eigentümer;
• Betriebsregion;
• Konfiguration;
• Firmware-Version;
• Kommunikationsprofil;
• Lebenszyklusstatus.

Detector (Detektor)

Detector ist eine analytische Komponente, die dafür zuständig ist, Telemetrie in operative Beobachtungen zu überführen.

Ein Detector erzeugt keine Geschäftslogik.

Seine Verantwortung beschränkt sich darauf, beobachtbare Muster zu erkennen und Evidence zu erzeugen.

Detector hat unter anderem folgende Attribute:

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

Evidence (Nachweis)

Evidence ist ein unveränderlicher Nachweis, der eine operative Schlussfolgerung stützt.

Evidence kann stammen aus:

• Telemetrie;
• Kommunikationslogs;
• Audit-Aufzeichnungen;
• Bestätigung durch den Benutzer;
• hochgeladenen Fotos;
• Systemdiagnose;
• externen Systemen.

Evidence kann nach der Erstellung nicht mehr geändert werden.

Ist eine Korrektur erforderlich, wird ein neues Evidence-Objekt angelegt, während die vorherige Version erhalten bleibt.

Operational Issue (operatives Problem)

Operational Issue steht für ein bestätigtes betriebliches Problem, das untersucht oder behoben werden muss.

Jedes Operational Issue enthält:

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

Operational Issue ist das primäre operative Objekt der Plattform.

Task (Aufgabe)

Task steht für eine ausführbare Aktion, die erforderlich ist, um ein Operational Issue zu beheben.

Tasks können nicht eigenständig existieren.

Jeder Task gehört zu genau einem Operational Issue.

Ein Operational Issue kann mehrere Tasks enthalten.

Root Cause (Grundursache)

Root Cause steht für die bestätigte zugrunde liegende Ursache eines oder mehrerer Operational Issues.

Mehrere Operational Issues können auf dieselbe Root Cause verweisen.

Diese Beziehung ermöglicht eine unternehmensweite Betriebsanalytik und das Erkennen wiederkehrender Probleme.

Health (Zustandsbewertung)

Health ist eine berechnete operative Kennzahl.

Health existiert für:

• Asset;
• Standort;
• Region;
• Organisation;
• gesamtes Ökosystem.

Health-Werte werden immer automatisch berechnet.

Knowledge Article (Wissensartikel)

Knowledge Article speichert geprüfte betriebliche Erfahrung.

Jeder Artikel kann verweisen auf:

• kanonische Issues;
• Root Causes;
• Asset-Typen;
• Firmware-Versionen;
• Betriebsanweisungen;
• Herstellerdokumentation.

Massive Incident (Großstörung)

Massive Incident gruppiert mehrere Operational Issues, die aus einem gemeinsamen betrieblichen Ereignis hervorgehen.

Er bietet ein einziges Verwaltungsobjekt für großflächige Infrastrukturstörungen.

Operative Prinzipien

Die Operational Health Matrix folgt mehreren Architekturprinzipien, die das Verhalten jedes Teilsystems bestimmen.

Asset an erster Stelle (Asset First)

Jedes betriebliche Ereignis wird einem Asset zugeordnet.

Assets bleiben über den gesamten Lebenszyklus hinweg die primären Objekte.

Issue-zentrierter Betrieb

Der Betrieb wird über Operational Issues gesteuert und nicht über einzelne Alarme oder Telemetrieereignisse.

Evidence-basierte Entscheidungen

Jede operative Schlussfolgerung muss durch ein oder mehrere Evidence-Objekte gestützt sein.

Unbelegte Annahmen werden niemals als gesicherte Fakten behandelt.

Erst die Root Cause, dann die Behebung

Korrekturmaßnahmen richten sich nach Möglichkeit gegen bestätigte Ursachen und nicht gegen beobachtbare Symptome.

Der Mensch im Regelkreis (Human-in-the-Loop)

Die Plattform unterstützt operative Entscheidungen, ersetzt aber niemals die Verantwortung der Ingenieure.

Kritische Aktionen erfordern eine ausdrückliche Bestätigung durch den Menschen.

Erklärbare Analytik

Analytische Schlussfolgerungen bleiben nachvollziehbar.

Jede Empfehlung enthält die stützende Evidence sowie Angaben zum Konfidenzniveau.

Unveränderliches Audit

Die Betriebshistorie kann nicht nachträglich umgeschrieben werden.

Jede Änderung erzeugt einen neuen Audit Record.

API-First-Ansatz

Jede Fähigkeit der Plattform ist über dokumentierte APIs zugänglich.

Benutzeroberflächen und externe Integrationen greifen auf dieselben operativen Dienste zu.

Ereignisgesteuerte Architektur

Operative Änderungen werden als Ereignisse weitergegeben.

Das ermöglicht asynchrone Integrationen und skalierbare Verarbeitungspipelines.

Operatives Datenmodell

Die Plattform folgt einem einheitlichen operativen Datenmodell.

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

Zuständigkeit

Jede Entität hat genau einen Verantwortlichen für ihren Lebenszyklus.

Lebenszyklusregeln

Das Domänenmodell hält mehrere Invarianten ein:

• Assets werden niemals gelöscht, solange historische Operational Issues existieren.
• Evidence ist unveränderlich.
• Tasks können nicht ohne Operational Issue existieren.
• Root Causes können von mehreren Issues gemeinsam genutzt werden.
• Health-Werte werden berechnet und lassen sich nicht manuell bearbeiten.
• Audit Records sind append-only.
• Knowledge Articles bleiben über ihren gesamten Lebenszyklus versioniert.

Diese Einschränkungen sichern Konsistenz, Nachvollziehbarkeit und Reproduzierbarkeit über die gesamte Plattform Operational Health Matrix hinweg.