Evidence-Modell und Korrelation

Das unveränderliche Evidence-Modell mit Qualitätsbewertung und die Korrelation, die verwandte Symptome mit ausgewiesener Konfidenz einer wahrscheinlichen Root Cause zuordnet.

Evidence-Modell

Was Evidence ist

Evidence ist ein strukturierter Nachweis, auf dessen Grundlage das System ein Issue anlegt, aktualisiert oder verifiziert.

Evidence kann sein:

automatisch berechnet;
vom Gerät empfangen;
aus einem Fremdsystem importiert;
von einem Benutzer hinzugefügt;
von einem Fachbericht erzeugt;
als Dokument, Foto oder Kommentar angehängt.

Aufbau von Evidence

yaml

evidence_id: EVD-830129
issue_id: OHM-2026-001842
type: detector_finding
source:
  provider: analyze_station
  detector_id: archive.tail_gap.v3
  detector_version: '3.2.1'
observed_at: '2026-07-23T04:00:00Z'
created_at: '2026-07-23T04:03:12Z'

payload:
  missing_hours: 73
  coverage_valid: 0.91
  last_valid_hour: '2026-07-20T03:00:00Z'

quality:
  completeness: 1.0
  freshness: 0.98
  consistency: 0.96
  confidence: 0.98

links:
  report: '/reports/analyze-station/5690'

Evidence-Typen

Typ	Beispiel
`detector_finding`	Ergebnis eines Detectors
`telemetry_sample`	Telemetriefragment
`archive_window`	Zusammenfassung eines Archivzeitraums
`event_log`	Ereignisprotokoll des Geräts
`configuration_snapshot`	Snapshot der Konfiguration
`operator_comment`	Kommentar des Disponenten
`field_report`	Bericht oder Protokoll des Außendienstteams
`photo`	Foto der Anlage
`external_ticket`	Link auf ein externes Ticket
`verification_result`	Bestätigung der Behebung
`root_cause_confirmation`	Bestätigung der Root Cause
`knowledge_application`	Anwendung eines Artikels aus der Knowledge Base

Evidence-Qualität

Für jedes Evidence wird die Qualität berechnet:

Q_{evidence} = w_c C + w_f F + w_s S + w_t T

wobei:

$C$ — completeness, Vollständigkeit;
$F$ — freshness, Aktualität;
$S$ — consistency, Konsistenz;
$T$ — trust, Vertrauen in die Quelle;
$w_c + w_f + w_s + w_t = 1$ .

Empfohlene Basisgewichte:

Komponente	Gewicht
$w_c$ — Vollständigkeit	0.30
$w_f$ — Aktualität	0.25
$w_s$ — Konsistenz	0.25
$w_t$ — Vertrauen in die Quelle	0.20

Das Ergebnis wird auf den Bereich 0 bis 1 normiert.

Unveränderlichkeit von Evidence

Ursprüngliches Evidence wird niemals nachträglich bearbeitet. Eine Korrektur erzeugt eine neue Version oder ein separates korrigierendes Evidence.

Das gewährleistet:

Auditierbarkeit;
Reproduzierbarkeit;
Schutz der Historie;
korrekte Aufarbeitung strittiger Fälle;
Möglichkeit zur Neuberechnung.

Ereigniskorrelation und Root Cause

Aufgabe der Korrelation

Die Korrelation verhindert, dass für ein und dieselbe technische Ursache viele voneinander unabhängige Issues entstehen.

Das System analysiert:

Übereinstimmung des Assets;
zeitliche Nähe;
topologische Abhängigkeit;
gemeinsame Firmware;
gemeinsames Gateway;
gemeinsamen Netzbetreiber;
gemeinsame Region;
gemeinsame Serverwarteschlange;
Abfolge der Symptome;
historische Zusammenhänge;
bestätigte Root Causes zurückliegender Fälle.

Korrelationsebenen

Innerhalb eines Assets

Mehrere Symptome werden um einen führenden Canon herum zusammengefasst.

flowchart TD
  A["stale_communication"] --> C{"Korrelation innerhalb des Assets"}
  B["no_hourly_archive"] --> C
  D["battery_unknown"] --> C
  C --> R["Führendes Issue stale_communication"]
  C --> S1["Sekundäres Signal no_hourly_archive"]
  C --> S2["Sekundäres Signal battery_unknown"]

Über Assets hinweg

Gleichartige Probleme werden zu einem Massive Incident gruppiert.

flowchart TD
  A["38 Geräte"] --> G{"Gruppierung"}
  B["Eine Firmware-Version"] --> G
  C["Ein Zeitfenster"] --> G
  D["Ein Fehlertyp"] --> G
  G --> M["Massive Incident firmware_regression"]

Nach Abhängigkeit

Probleme untergeordneter Geräte werden mit dem Ausfall einer gemeinsam genutzten Komponente verknüpft.

flowchart TD
  A["Gateway-17 nicht erreichbar"] --> B["12 Korrektoren ohne Kommunikation"]
  B --> C["12 Archive nicht zugestellt"]
  C --> D["Ein Abhängigkeits-Incident"]

Bewertung der Verknüpfung (Correlation Score)

Zur Bewertung der Stärke einer Verknüpfung dient ein erklärbares Modell:

S_{corr} = w_a A + w_t T + w_p P + w_c C + w_h H

wobei:

$A$ — Übereinstimmung von Asset oder Abhängigkeit;
$T$ — zeitliche Nähe;
$P$ — Übereinstimmung des Musters;
$C$ — gemeinsamer Kontext;
$H$ — historische Bestätigung der Verknüpfung.

Beispielhafte Gewichte:

Faktor	Gewicht
$A$ — Übereinstimmung von Asset oder Abhängigkeit	0.30
$T$ — zeitliche Nähe	0.20
$P$ — Ähnlichkeit des Musters	0.20
$C$ — gemeinsamer Kontext	0.15
$H$ — historische Bestätigung	0.15

Die Schwelle für die Zusammenführung wird je Problemklasse festgelegt. Für kritische Security-Signale ist eine konservativere Schwelle zulässig.

Root-Cause-Klassen

OHM verwendet einen gepflegten Katalog von Root Causes:

Klasse	Beispiele
Power	Batterie, Stromversorgung, Wandler
Communication	Netz, SIM, Signal, Netzbetreiber
Firmware	Regression, Inkompatibilität
Configuration	fehlerhafter Parameter
Registry	Dublette, Ghost-Objekt, falsche Zuordnung
Sensor	Ausfall, Drift, festhängende Messwerte
Metering	messtechnisches Problem
Infrastructure	Server, Warteschlange, Gateway
Integration	API, Format, Mapping
Human	Fehler in einer Handlung oder einem Prozess
Environment	Temperatur, Feuchtigkeit, äußere Einwirkung
Security	Integritäts- oder Zugriffsverletzung
External	Fremdsystem oder Lieferant
Unknown	unzureichende Daten

Root-Cause-Status

Status	Bedeutung
`hypothesis`	automatisch vorgeschlagene Hypothese
`under_investigation`	die Hypothese wird geprüft
`probable`	durch mehrere unabhängige Indizien bestätigt
`confirmed`	durch einen berechtigten Benutzer und Evidence belegt
`rejected`	die Hypothese wurde verworfen
`unknown`	die Root Cause wurde nicht ermittelt

Konfidenz der Root Cause

Die Konfidenz einer Hypothese wird aus der Gesamtheit der Nachweise berechnet:

C_{root} = \frac{ \sum_{i=1}^{n} r_i q_i a_i }{ \sum_{i=1}^{n} r_i } \cdot K_{independence}

wobei:

$r_i$ — Zuverlässigkeit des Detectors oder der Quelle;
$q_i$ — Evidence-Qualität;
$a_i$ — Übereinstimmung des Evidence mit der Hypothese;
$K_{independence}$ — Koeffizient der Quellenunabhängigkeit.

Stammen mehrere Evidence aus demselben Ausgangsdatenbestand, gelten sie nicht als vollständig unabhängig.

Operative Konfidenz (Operational Confidence)

Operational Confidence gibt an, wie sicher das System ist, dass ein Issue ein reales und korrekt klassifiziertes Problem darstellt.

C_{issue} = w_d D + w_e E + w_r R + w_h H - w_x X

wobei:

$D$ — Zuverlässigkeit der Detectors;
$E$ — Evidence-Qualität;
$R$ — Konsistenz der Korrelation;
$H$ — historische Bestätigungsquote;
$X$ — Abschlag für Widersprüche und fehlende Daten.

Interpretation:

Konfidenz	Stufe	Aktion
≥ 0.85	hoch	automatische Erstellung eines actionable Issue
0.65–0.85	ausreichend	Erstellung eines Issue mit regulärer Triage
0.40–0.65	eingeschränkt	Prüfung erforderlich
< 0.40	niedrig	analytisches Signal, automatische Aktionen unzulässig

Verwandte Themen

Zuletzt aktualisiert am 3. August 2026

War diese Seite hilfreich?