---
title: 'Detektori i kanonski problemi'
description: 'Kako detektori pretvaraju telemetriju u nalaze, a kanonski problemi pretvaraju nalaze u probleme kojima se upravlja – klase detektora, kontrolne točke kvalitete podataka, katalog kanonskih problema i analitika kvalitete detektora.'
section: 'Operations Center'
weight: 5
related:
- evidence-and-correlation
- ai-intelligence
---
import Alert from '@/components/docs/Alert.astro';
import Image from '@/components/docs/Image.astro';
## Arhitektura detektora
### Detektor (Detector)
`Detector` je algoritam koji analizira zadani skup podataka i daje formaliziran nalaz.
Detektor ne upravlja izvršavanjem i ne generira proizvoljan tekst. Izlaz detektora ima strukturiran format.
```yaml
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
```
### Lanac Detector → Canon → Issue
```mermaid
flowchart TD
D["Detector"] -->|"klasifikacija"| C["Canon"]
C -->|"upravljanje"| I["Operational Issue"]
```
- `Detector` – konkretan algoritam;
- `Canon` – stabilan tip operativnog problema;
- `Operational Issue` – pojava problema u konkretnom kontekstu.
Isti kanonski problem može potvrditi nekoliko različitih detektora.
Primjer:
```mermaid
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"]
```
### Klase detektora
| Klasa | Namjena |
| ------------ | ------------------------------------------------------- |
| Connectivity | komunikacija, sesije, dostupnost, signal |
| Archive | potpunost i isporuka arhiva |
| Data Quality | valjanost, praznine, proturječnosti |
| Metering | protok, obujam, mjeriteljski odnosi |
| Pressure | rasponi, skokovi, zaglavljene vrijednosti |
| Temperature | rasponi, trendovi, fizikalna dosljednost |
| Power | baterija, napajanje, degradacija |
| Registry | registar, duplikati, fantomski objekti |
| Passport | popunjenost i ispravnost putovnice |
| Integrity | znakovi neovlaštenih zahvata i narušavanja cjelovitosti |
| Security | anomalni događaji pristupa i konfiguracije |
| Firmware | pogreške, nekompatibilnost, regresije |
| Topology | ovisnosti između uređaja, pristupnika i servisa |
| Operations | prekoračeni rokovi, nema odgovorne osobe, ponavljanje |
| Predictive | prognoza kvara ili degradacije |
### Zahtjevi za svaki detektor
Svaki detektor u produkcijskom okruženju ima:
- jedinstveni identifikator `detector_id`;
- semantičku verziju;
- definiranu namjenu;
- vlasnika;
- opis ulaznih podataka;
- kontrolirane pragove;
- pravila izuzimanja;
- zahtjeve za minimalnu veličinu uzorka;
- kontrolne točke kvalitete podataka (DQ gates);
- formulu za izračunavanje ozbiljnosti;
- formulu za izračunavanje razine pouzdanosti;
- odgovarajući kanonski problem;
- skup dokaza (Evidence);
- testove;
- kontrolni uzorak;
- procjenu lažno pozitivnih rezultata;
- datum puštanja u rad;
- dnevnik izmjena;
- režim isključivanja i vraćanje na prethodnu verziju.
### Kontrolne točke kvalitete podataka
Detektor ne smije davati visoku razinu pouzdanosti ako su izvorni podaci nepotpuni ili proturječni.
Primjeri kontrolnih točaka:
| Uvjet | Utjecaj na detektor |
| --------------------------------------- | ------------------------------------------------------ |
| Nema valjanog identifikatora `asset_id` | blokirati automatsku radnju |
| Nedovoljna povijest podataka | sniziti razinu pouzdanosti |
| Pogreška u vremenskoj oznaci | ne izračunavati ažurnost |
| Nema jedinice mjere | ne uspoređivati s fizikalnim pragom |
| Premali uzorak | ne izrađivati prognozu |
| Fantomski objekt u registru | povezane probleme označiti kao probleme bez postupanja |
### Stanje detektora
OHM prati kvalitetu samih detektora.
Ključni pokazatelji:
- broj aktiviranja;
- udio potvrđenih aktiviranja;
- stopa lažno pozitivnih rezultata;
- udio ručnih otkazivanja;
- udio ponovnih otvaranja;
- raspodjela razina pouzdanosti;
- drift ulaznih podataka;
- promjena strukture uzorka;
- prosječno vrijeme do potvrde;
- verzija algoritma;
- broj aktivnih problema po verziji.
## Kanonski problemi (Canon)
`Canon` je stabilna poslovna klasifikacija problema koja ne ovisi o konkretnoj implementaciji detektora.
### Zašto su potrebni kanonski problemi
Bez kanonskih problema analitički se sustav brzo izrodi u skup neusklađenih poruka:
- `archive_missing`
- `no_archive`
- `archive_gap`
- `hourly_data_absent`
- `delivery_error`
Kanonski problem objedinjuje sve ove ekvivalentne signale pod jednim identifikatorom: `canon: no_hourly_archive`.
To osigurava:
- jedinstveni tijek rada;
- jedinstveni sporazum o razini usluge (SLA);
- preglednu analitiku;
- stabilne ključne pokazatelje uspješnosti (KPI);
- zajedničku bazu znanja;
- usporedivost između verzija;
- prijevod sučelja bez izmjena u logici;
- integraciju s vanjskim sustavima.
### Struktura kanonskog problema
```yaml
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
```
### Osnovni skup kanonskih problema
| Kanonski problem | Značenje | Primarna zona |
| ----------------------------- | ------------------------------------------------------------------------------ | -------------------------------------- |
| `no_sessions_in_period` | nema sesija u analiziranom razdoblju | integracija / komunikacija |
| `stale_communication` | uređaj se dugo nije javljao | teren / komunikacija |
| `no_hourly_archive` | nema satne arhive | poslužiteljska strana / integracija |
| `archive_delivery_failure` | arhiva je formirana, ali nije isporučena | poslužiteljska strana / integracija |
| `archive_incomplete` | arhiva je nepotpuna | služba mjerenja |
| `abnormal_session_length` | anomalno trajanje sesije | komunikacija / integracija |
| `battery_low` | kritično nizak preostali kapacitet baterije | servis |
| `battery_unknown` | stanje baterije je nepoznato | servis / integracija |
| `passport_incomplete` | podaci u putovnici su nepotpuni | mjeriteljstvo |
| `registry_ghost` | objekt postoji logički, ali nije fizički potvrđen | registar |
| `registry_duplicate` | sukob identifikatora ili duplikat | registar |
| `pressure_out_of_range` | tlak izvan dopuštenog raspona | operativno poslovanje |
| `pressure_sensor_stuck` | senzor tlaka ne pokazuje promjene unatoč očekivanoj dinamici | mjeriteljstvo / servis |
| `temperature_out_of_range` | temperatura izvan dopuštenog raspona | operativno poslovanje |
| `data_quality_degraded` | kvaliteta podataka ne omogućuje pouzdanu analizu | integracija |
| `firmware_regression` | problemi su povezani s verzijom firmvera | firmver / poslužiteljska strana |
| `tampering_suspected` | otkriveni su znakovi mogućeg neovlaštenog zahvata | sigurnost / mjeriteljstvo |
| `leak_suspected` | otkriveni su posredni znakovi mogućeg curenja | operativno poslovanje |
| `topology_dependency_failure` | simptomi su posljedica kvara zajedničke komponente o kojoj ovisi više objekata | poslužiteljska strana / infrastruktura |
Kanonski problemi `tampering_suspected` i `leak_suspected` analitičke su hipoteze. Ne dokazuju
nepravilnost, curenje, krađu ni krivnju bilo koje konkretne osobe. Za potvrdu je potreban tehnički
pregled proveden prema propisanom postupku.
### Verzioniranje kanonskih problema
Izmjena teksta ili prijevoda ne zahtijeva promjenu identifikatora.
Nova verzija kanonskog problema potrebna je kada se promijeni bilo što od sljedećeg:
- poslovno značenje;
- pravilo dodjele;
- kriterij potrebe za postupanjem;
- način verifikacije;
- SLA načelo;
- logika spajanja s drugim problemima.
## Analitika kvalitete detektora
Operational Health Matrix ne ocjenjuje samo opremu, nego i kvalitetu vlastitih analitičkih algoritama.
Za svaki detektor sustav izračunava:
- točnost;
- preciznost;
- odziv;
- stopu lažno pozitivnih rezultata;
- stopu lažno negativnih rezultata;
- prosječnu razinu pouzdanosti;
- drift;
- stabilnost;
- prosječno vrijeme verifikacije;
- stopu prihvaćanja.
Ovakav pristup omogućuje stalno unaprjeđivanje analitičkog modela podsustava Data Platform bez narušavanja ponovljivosti rezultata.
Sam portfelj detektora razvija se prema planu po fazama: novi se detektori uvode u valovima, a svaki je val uvjetovan spremnošću API sučelja platforme na koja se oslanja.