Detektory a kanonické problémy

Architektura detektorů

Detector (detektor)

Detector je algoritmus, který analyzuje vymezenou množinu dat a vytváří formalizovaný nález.

Detektor neřídí realizaci prací a negeneruje libovolný text. Jeho výstup má strukturovaný formát.

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

Řetězec Detector → Canon → Issue

flowchart TD
  D["Detector"] -->|"klasifikace"| C["Canon"]
  C -->|"řízení"| I["Operational Issue"]

• Detector — konkrétní algoritmus;
• Canon — stabilní typ provozního problému;
• Operational Issue — instance problému v konkrétním kontextu.

Tentýž kánon může potvrdit několik různých detektorů.

Příklad:

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

Třídy detektorů

Požadavky na každý detektor

Každý produkční detektor má:

• jedinečný detector_id;
• sémantickou verzi;
• deklarovaný účel;
• vlastníka;
• popis vstupních dat;
• řízené prahové hodnoty;
• pravidla vyloučení;
• požadavky na minimální vzorek;
• brány kvality dat;
• vzorec severity;
• vzorec confidence;
• odpovídající kánon;
• sadu Evidence;
• testy;
• kontrolní vzorek;
• odhad false positive;
• datum uvedení do provozu;
• protokol změn;
• režim vypnutí a rollback.

Brány kvality dat (DQ gates)

Detektor nesmí vykazovat vysokou úroveň confidence, pokud jsou zdrojová data neúplná nebo rozporná.

Příklady bran:

Zdraví detektorů (Detector Health)

OHM sleduje kvalitu samotných detektorů.

Klíčové ukazatele:

• počet detekcí;
• podíl potvrzených detekcí;
• false positive rate;
• podíl ručních zrušení;
• podíl opětovných otevření;
• rozdělení confidence;
• drift vstupních dat;
• změna struktury vzorku;
• průměrná doba do potvrzení;
• verze algoritmu;
• počet aktivních Issues podle verze.

Kanonické problémy

Canon je stabilní byznysová klasifikace problému, která nezávisí na konkrétní implementaci detektoru.

Proč jsou kánony potřeba

Bez kánonů se analytický systém rychle zvrhne v soubor nekonzistentních hlášení:

• archive_missing
• no_archive
• archive_gap
• hourly_data_absent
• delivery_error

Kánon sjednocuje všechny tyto ekvivalentní signály pod jediným identifikátorem: canon: no_hourly_archive.

To zajišťuje:

• jednotný workflow;
• jednotné SLA;
• srozumitelnou analytiku;
• stabilní KPI;
• společnou znalostní bázi;
• srovnatelnost mezi verzemi;
• překlad rozhraní bez zásahu do logiky;
• integraci s externími systémy.

Struktura kánonu

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

Základní sada kánonů

Verzování kánonů

Změna textu nebo překladu nevyžaduje změnu identifikátoru.

Novou verzi kánonu je nutné vydat, pokud se změní:

• byznysový význam;
• pravidlo přiřazení;
• kritérium actionability;
• způsob verifikace;
• princip SLA;
• logika slučování s jinými problémy.

Analytika kvality detektorů

Operational Health Matrix hodnotí nejen zařízení, ale i kvalitu vlastních analytických algoritmů.

Pro každý Detector systém počítá:

• Accuracy;
• Precision;
• Recall;
• False Positive Rate;
• False Negative Rate;
• průměrnou úroveň confidence (Average Confidence);
• Drift;
• Stability;
• průměrnou dobu verifikace (Mean Verification Time);
• míru akceptace (Acceptance Rate).

Tento přístup umožňuje průběžně zdokonalovat analytický model Platformy IIoT, aniž by se narušila reprodukovatelnost výsledků.

Samotné portfolio detektorů se rozvíjí podle etapové roadmapy: nové detektory se zavádějí ve vlnách a každou vlnu otevírá připravenost odpovídajících API platformy.