Operational Health Matrix (OHM)

Operational Health Matrix (OHM) ist das zentrale Betriebsmodul der IIoT-Plattform. Das Modul überführt den Telemetriestrom, die Analyseergebnisse und die Betriebsereignisse in einen gesteuerten Arbeitszyklus: von der automatischen Problemerkennung bis zur datenbestätigten Behebung.

OHM vereint in einem einzigen System:

• Erkennung technischer, messtechnischer und integrationsbezogener Probleme;
• Korrelation von Symptomen und Bestimmung der wahrscheinlichen Grundursache (Root Cause);
• Anlegen und Führen von Operational Issue-Objekten;
• Zuweisung verantwortlicher Teams und Bearbeiter;
• Steuerung von Fristen, Prioritäten und SLA;
• Nachverfolgung von Tasks, Kommentaren, Nachweisen (Evidence) und Aktionshistorie;
• automatische Verifikation der Ergebnisse anhand neuer Daten;
• Management von Großstörungen (Massive Incidents);
• Bewertung des Zustands von Geräten und Gerätepark;
• Berechnung operativer und teambezogener KPI;
• Sammlung bestätigter Lösungen in der Wissensdatenbank (Knowledge Base);
• AI-gestützte Analyse, ohne der künstlichen Intelligenz die Befugnis für kritische Entscheidungen zu übertragen.

flowchart TD
  A["Telemetrie"] --> B["Detectors"]
  B --> C["Evidence"]
  C --> D["Korrelation und Root Cause"]
  D --> E["Operational Issue"]
  E --> F["Zuweisung und Ausführung"]
  F --> G["Verifikation anhand von Daten"]
  G --> H["Abschluss und Knowledge Base"]
  H --> I["KPI und kontinuierliche Verbesserung"]

Zweck des Moduls

Traditionelle Telemetriesysteme beantworten die folgende Frage gut:

Was ist mit dem Gerät oder den Daten passiert?

Für die Steuerung eines großen Geräteparks reicht das jedoch nicht aus. Nach der Erkennung eines Ereignisses muss die Organisation bestimmen:

• ob das Signal ein reales Problem darstellt;
• ob es ein einzelnes Gerät betrifft oder eine systemweite Störung ist;
• welche weiteren Symptome auf dieselbe Grundursache zurückgehen;
• wer für die Behebung verantwortlich ist;
• bis wann die Arbeiten abgeschlossen sein müssen;
• welche Maßnahmen bereits ergriffen wurden;
• ob die Behebung durch objektive Daten bestätigt ist;
• ob das Problem wiederkehrt;
• wie effektiv der operative Prozess arbeitet.

OHM schließt diesen gesamten Zyklus.

Das primäre Ergebnis des Moduls ist weder eine Benachrichtigung noch eine Berichtszeile, sondern ein gesteuertes Betriebsobjekt, das Folgendes besitzt:

• einen Identifikator;
• einen Problemtyp;
• betroffene Assets;
• Evidence;
• eine Severity;
• ein Konfidenzniveau;
• eine wahrscheinliche und eine bestätigte Grundursache;
• einen Verantwortlichen;
• einen Bearbeiter;
• eine Frist;
• Tasks;
• eine Historie;
• einen Verifikationsstatus;
• ein Behebungsergebnis;
• eine Verknüpfung mit der Knowledge Base;
• eine Auswirkung auf die KPI.

Der entscheidende Vorteil

Die Plattform beschränkt sich nicht auf das Erfassen von Abweichungen. Die Plattform begleitet das Problem bis zum bestätigten Ergebnis.

flowchart TD
  subgraph OPS["IIoT-Plattform und OHM"]
    direction TB
    O1["Problem erkannt"] --> O2["Evidence geprüft"]
    O2 --> O3["Verwandte Signale zusammengeführt"]
    O3 --> O4["Priorität bestimmt"]
    O4 --> O5["Verantwortungsbereich zugewiesen"]
    O5 --> O6["Frist wird überwacht"]
    O6 --> O7["Ergebnis anhand von Daten geprüft"]
    O7 --> O8["Bestätigte Lösung gespeichert"]
  end
  subgraph MON["Monitoringsystem"]
    direction TB
    M1["Problem erkannt"] --> M2["Hier endet die Arbeit des Systems"]
  end

Dadurch überführt OHM den Betrieb aus einem reaktiven Modus in ein gesteuertes Modell, in dem jede wesentliche Abweichung einen Verantwortlichen, eine Frist, Evidence und ein messbares Ergebnis hat.

Grundprinzipien

Issues statt Alarme

Ein einzelner Alarm ist nicht immer gleichbedeutend mit einem Betriebsproblem.

Ein einziger physischer Ausfall kann Dutzende oder Hunderte von Ereignissen erzeugen:

• keine Kommunikationssitzung;
• kein Archiv;
• veraltete Daten;
• Batteriezustand unbekannt;
• kein aktueller Druck;
• Zustellfehler.

OHM legt nicht für jedes Symptom einen eigenen Arbeitsauftrag an. Das System korreliert die Signale und erzeugt ein einziges Operational Issue, wenn sie auf eine gemeinsame Ursache zurückgehen.

Betrieb auf Basis von Evidence

Jede automatische Schlussfolgerung muss erklärbar sein.

Ein Issue enthält:

• die Ausgangswerte;
• die Zeitstempel;
• die Kennung des Detectors;
• die Version des Algorithmus;
• die angewendeten Schwellenwerte;
• einen Verweis auf den zugehörigen spezialisierten Bericht;
• die Wiederholungshistorie;
• verwandte Signale;
• das Korrelationsergebnis.

Anwender können den Weg von der Rohtelemetrie bis zum erzeugten Issue jederzeit nachvollziehen.

Zuerst die Grundursache (Root Cause First)

OHM unterscheidet:

• ein Symptom — eine beobachtete Abweichung;
• eine Ursache — den technischen oder organisatorischen Faktor, der die Abweichung hervorgerufen hat;
• eine Grundursache — den primären Faktor, dessen Beseitigung das Wiederauftreten einer ganzen Symptomgruppe verhindert.

Beispiel:

flowchart LR
  S1["Symptom 1: Stundenarchiv fehlt"] --> RC["Wahrscheinliche Grundursache: Degradation der Stromversorgung"]
  S2["Symptom 2: letzte Sitzung vor 9 Tagen"] --> RC
  S3["Symptom 3: Batteriespannung war rückläufig"] --> RC
  S4["Symptom 4: Sitzungsdauer nahm zu"] --> RC

Abschluss mit Datenbestätigung

Der Bearbeiter meldet die Arbeit als erledigt, doch der endgültige Status resolved wird erst gesetzt, nachdem das Ergebnis verifiziert wurde.

flowchart TD
  V1["Arbeit abgeschlossen"] --> V2["awaiting_verification"]
  V2 --> V3["Neue Daten bestätigen die Normalisierung"]
  V3 --> V4["resolved"]

Für Probleme, die sich nicht über Telemetrie prüfen lassen, kommt eine kontrollierte manuelle Verifikation mit verpflichtendem Kommentar und belegender Evidence zum Einsatz.

Das Asset im Zentrum

Alle Ereignisse, Issues, Arbeiten und Kennzahlen sind mit Assets verknüpft:

• Messstellen;
• Mengenumwerter;
• Zähler;
• Sensoren;
• Modems;
• Gateways;
• SIM-Karten;
• Serverkomponenten;
• Integrationskanäle;
• Softwareversionen.

Die Asset-Karte zeigt den aktuellen Gesundheitszustand, die Degradationshistorie, aktive Issues, abgeschlossene Arbeiten und die Wiederholung von Problemen.

Verantwortung beim Menschen, Unterstützung durch AI

AI hilft dabei:

• Evidence zusammenzufassen;
• Hypothesen in eine Rangfolge zu bringen;
• ähnliche Fälle zu finden;
• bekannte Lösungen vorzuschlagen;
• neue Cluster zu erkennen;
• das Ausfallrisiko zu prognostizieren.

AI kann nicht selbstständig:

• die Priorität ändern;
• Verantwortung zuweisen;
• ein Issue schließen;
• eine Root Cause als gesicherte Tatsache bestätigen;
• SLA ändern;
• kritische Aktionen an Geräten ausführen.

Reproduzierbarkeit als Konstruktionsprinzip

Alle wesentlichen Berechnungen sind reproduzierbar. Für jedes Ergebnis speichert die Plattform:

• die Version des Detectors;
• die Version des Canon;
• die Version des Korrelationsmodells;
• den verwendeten Datensatz;
• den Zeitpunkt der Berechnung;
• die Schwellenwerte;
• die Konfiguration;
• die Quelle der Änderung.

OHM in der Architektur der IIoT-Plattform

OHM ist zwischen der Analyseschicht und der Betriebssteuerung angesiedelt.

flowchart TD
  PHY["Physische Assets"] --> DATA["IIoT-Daten- und Integrationsschicht"]
  DATA -->|"Normalisierte Daten"| ANL["Analytik und Detektion"]
  ANL -->|"Evidence und Analyseergebnisse"| OHM["Operational Health Matrix"]
  OHM -->|"API, Ereignisse, Integration"| ENT["Unternehmenssysteme"]

Inhalt der Schichten:

Datenquellen

OHM nutzt:

• die aktuelle Telemetrie;
• Stunden-, Tages- und Ereignisarchive;
• Protokolle der Kommunikationssitzungen;
• Gerätepass- und Registerdaten;
• Gerätestatus;
• Batteriedaten;
• Druck, Temperatur, Durchfluss und Volumen;
• Manipulationsereignisse;
• Firmware-Versionen;
• Kommunikationsparameter;
• Ergebnisse spezialisierter Berichte;
• manuelle Beobachtungen der Anwender;
• Ereignisse aus externen Systemen.

Evidence-Quellen (Evidence Providers)

Jedes Analysemodul der Plattform kann als Evidence-Quelle dienen.

Beispiele:

Das Modul erkunden