Detectors und kanonische Probleme

Detector-Architektur

Detector (Detektor)

Detector ist ein Algorithmus, der einen definierten Datenbestand analysiert und daraus einen formalisierten Befund (finding) erzeugt.

Ein Detector steuert keine Ausführung und erzeugt keinen Freitext. Sein Ergebnis hat ein strukturiertes Format.

detector_id: archive.tail_gap.v3
detector_version: '3.2.1'
run_id: 'run-20260723-0400'
asset_id: 'station-5690'
observed_at: '2026-07-23T04:00:00Z'

finding:
  canon: no_hourly_archive
  detected: true
  severity: critical
  confidence: 0.98
  value: 73
  unit: 'hours'
  threshold: 24
  baseline: 0

evidence:
  last_valid_hour: '2026-07-20T03:00:00Z'
  expected_end: '2026-07-23T04:00:00Z'
  missing_hours: 73

Kette Detector → Canon → Issue

flowchart TD
  D["Detector"] -->|"Klassifizierung"| C["Canon"]
  C -->|"Steuerung"| I["Operational Issue"]

• Detector — ein konkreter Algorithmus;
• Canon — ein stabiler Typ eines betrieblichen Problems;
• Operational Issue — eine Ausprägung des Problems in einem konkreten Kontext.

Mehrere verschiedene Detectors können denselben Canon bestätigen.

Beispiel:

flowchart TD
  D1["archive.tail_gap.v3"] --> CANON["no_hourly_archive"]
  D2["archive.coverage.v2"] --> CANON
  D3["archive.delivery_queue.v1"] --> CANON
  D4["session.freshness.v4"] --> CANON
  CANON --> ISSUE["OHM-2026-001842"]

Detector-Klassen

Anforderungen an jeden Detector

Jeder produktive Detector hat:

• eine eindeutige detector_id;
• eine semantische Version;
• einen definierten Zweck;
• einen Verantwortlichen;
• eine Beschreibung der Eingangsdaten;
• kontrollierte Schwellenwerte;
• Ausschlussregeln;
• Anforderungen an die Mindeststichprobe;
• DQ-Gates;
• eine Formel für Severity;
• eine Formel für Confidence;
• einen zugehörigen Canon;
• einen Satz von Evidence;
• Tests;
• eine Kontrollstichprobe;
• eine Abschätzung der False Positives;
• ein Datum der Inbetriebnahme;
• ein Änderungsprotokoll;
• einen Abschaltmodus und Rollback.

Gates für Datenqualität (DQ-Gates)

Ein Detector darf keine hohe Confidence ausweisen, wenn die Ausgangsdaten unvollständig oder widersprüchlich sind.

Beispiele für Gates:

Zustand der Detectors (Detector Health)

OHM überwacht die Qualität der Detectors selbst.

Wesentliche Kennzahlen:

• Anzahl der Auslösungen;
• Anteil bestätigter Auslösungen;
• False Positive Rate;
• Anteil manueller Abbrüche;
• Anteil der Wiedereröffnungen;
• Verteilung der Confidence;
• Drift der Eingangsdaten;
• Veränderung der Stichprobenstruktur;
• mittlere Zeit bis zur Bestätigung;
• Version des Algorithmus;
• Anzahl aktiver Issues je Version.

Kanonische Probleme

Canon ist eine stabile fachliche Klassifizierung eines Problems, die nicht von der konkreten Implementierung eines Detectors abhängt.

Warum Canons notwendig sind

Ohne Canons zerfällt ein analytisches System schnell in eine Sammlung uneinheitlicher Meldungen:

• archive_missing
• no_archive
• archive_gap
• hourly_data_absent
• delivery_error

Ein Canon fasst all diese gleichwertigen Signale unter einer einzigen Kennung zusammen: canon: no_hourly_archive.

Das ergibt:

• einen einheitlichen Workflow;
• ein einheitliches SLA;
• eine verständliche Analytik;
• stabile KPIs;
• eine gemeinsame Knowledge Base;
• Vergleichbarkeit zwischen Versionen;
• Übersetzung der Oberfläche ohne Änderung der Logik;
• Integration mit externen Systemen.

Aufbau eines Canons

canon_id: no_hourly_archive
name: 'Hourly archive is missing'
domain: archive
default_owner_zone: backend_integration
default_priority: P1
actionable: true
verification_mode: data
sla_policy: archive_p1
suppression_group: communication_archive
knowledge_tags:
  - archive
  - delivery
  - communication

Basissatz an Canons

Versionierung von Canons

Eine Änderung des Textes oder der Übersetzung erfordert keine Änderung der Kennung.

Eine neue Canon-Version ist erforderlich, wenn sich eines der folgenden Merkmale ändert:

• die fachliche Bedeutung;
• die Zuweisungsregel;
• das Kriterium der Actionability;
• die Art der Verifikation;
• das SLA-Prinzip;
• die Logik der Zusammenführung mit anderen Problemen.

Analytik der Detector-Qualität

Die Operational Health Matrix bewertet nicht nur die Anlagentechnik, sondern auch die Qualität der eigenen analytischen Algorithmen.

Für jeden Detector berechnet das System:

• Accuracy;
• Precision;
• Recall;
• False Positive Rate;
• False Negative Rate;
• mittlere Confidence;
• Drift;
• Stability;
• mittlere Verifikationsdauer;
• Annahmequote.

Dieser Ansatz erlaubt es, das analytische Modell der IIoT-Plattform kontinuierlich zu verbessern, ohne die Reproduzierbarkeit der Ergebnisse zu beeinträchtigen.

Das Detector-Portfolio selbst entwickelt sich entlang einer stufenweisen Roadmap: Neue Detectors werden in Wellen eingeführt, und jede Welle wird erst durch die Bereitschaft der zugrunde liegenden Plattform-APIs freigegeben.