---
title: 'Детекторы и канонические проблемы'
description: 'Как детекторы превращают телеметрию в находки, а каноны — находки в управляемые проблемы: классы детекторов, гейты качества данных, каталог канонов и аналитика качества детекторов.'
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';
## Детекторная архитектура
### Детектор (Detector)
`Detector` — алгоритм, который анализирует определённый набор данных и создаёт формализованный finding.
Детектор не управляет исполнением и не создаёт произвольный текст. Его результат имеет структурированный формат.
```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
```
### Цепочка Detector → Canon → Issue
```mermaid
flowchart TD
D["Detector"] -->|"классификация"| C["Canon"]
C -->|"управление"| I["Operational Issue"]
```
- `Detector` — конкретный алгоритм;
- `Canon` — стабильный тип эксплуатационной проблемы;
- `Operational Issue` — экземпляр проблемы в конкретном контексте.
Несколько разных детекторов могут подтверждать один канон.
Пример:
```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"]
```
### Классы детекторов
| Класс | Назначение |
| ------------ | ---------------------------------------------- |
| Connectivity | связь, сеансы, доступность, сигнал |
| Archive | полнота и доставка архивов |
| Data Quality | валидность, пропуски, противоречия |
| Metering | расход, объём, метрологические соотношения |
| Pressure | диапазоны, скачки, залипание |
| Temperature | диапазоны, тренды, физическая согласованность |
| Power | батарея, питание, деградация |
| Registry | реестр, дубли, ghost-объекты |
| Passport | комплектность и корректность паспорта |
| Integrity | признаки вмешательства и нарушения целостности |
| Security | аномальные события доступа и конфигурации |
| Firmware | ошибки, несовместимость, регрессии |
| Topology | зависимость устройств, шлюзов и сервисов |
| Operations | просрочки, отсутствие владельца, повторяемость |
| Predictive | прогноз отказа или деградации |
### Требования к каждому детектору
Каждый production-детектор имеет:
- уникальный `detector_id`;
- семантическую версию;
- назначение;
- владельца;
- описание входных данных;
- контролируемые пороги;
- правила исключения;
- требования к минимальной выборке;
- DQ-гейты;
- формулу severity;
- формулу confidence;
- соответствующий канон;
- набор Evidence;
- тесты;
- контрольную выборку;
- оценку false positive;
- дату ввода;
- журнал изменений;
- режим отключения и rollback.
### Гейты качества данных (DQ-гейты)
Детектор не должен формировать высокий уровень уверенности, если исходные данные неполны или противоречивы.
Примеры гейтов:
| Условие | Действие детектора |
| ------------------------ | --------------------------------------- |
| Нет валидного `asset_id` | блокировать автоматическое действие |
| Недостаточно истории | понизить confidence |
| Ошибка timestamp | не вычислять freshness |
| Нет единицы измерения | не сравнивать с физическим порогом |
| Слишком малая выборка | не строить прогноз |
| Ghost-объект реестра | сделать связанные Issues non-actionable |
### Здоровье детекторов (Detector Health)
OHM контролирует качество самих детекторов.
Основные показатели:
- число срабатываний;
- доля подтверждённых срабатываний;
- false positive rate;
- доля ручных отмен;
- доля повторных открытий;
- распределение confidence;
- drift входных данных;
- изменение структуры выборки;
- среднее время до подтверждения;
- версия алгоритма;
- число активных Issues по версии.
## Канонические проблемы
`Canon` — стабильная бизнес-классификация проблемы, не зависящая от конкретной реализации детектора.
### Зачем нужны каноны
Без канонов аналитическая система быстро превращается в набор несогласованных сообщений:
- `archive_missing`
- `no_archive`
- `archive_gap`
- `hourly_data_absent`
- `delivery_error`
Канон объединяет все эти эквивалентные сигналы под единым идентификатором: `canon: no_hourly_archive`.
Это обеспечивает:
- единый workflow;
- единый SLA;
- понятную аналитику;
- устойчивые KPI;
- общую базу знаний;
- сопоставимость между версиями;
- перевод интерфейса без изменения логики;
- интеграцию с внешними системами.
### Структура канона
```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
```
### Базовый набор канонов
| Канон | Смысл | Основная зона |
| ----------------------------- | -------------------------------------------------------- | ------------------------- |
| `no_sessions_in_period` | в анализируемом периоде нет сеансов | интеграция / связь |
| `stale_communication` | устройство давно не выходило на связь | поле / связь |
| `no_hourly_archive` | отсутствует часовой архив | backend / integration |
| `archive_delivery_failure` | архив сформирован, но не доставлен | backend / integration |
| `archive_incomplete` | архив неполный | служба учёта |
| `abnormal_session_length` | аномальная длительность сеансов | связь / интеграция |
| `battery_low` | критически низкий ресурс батареи | сервис |
| `battery_unknown` | состояние батареи неизвестно | сервис / интеграция |
| `passport_incomplete` | паспортные данные некомплектны | метрология |
| `registry_ghost` | объект существует логически, но не подтверждён физически | реестр |
| `registry_duplicate` | конфликт или дубль идентификаторов | реестр |
| `pressure_out_of_range` | давление вне допустимого диапазона | эксплуатация |
| `pressure_sensor_stuck` | датчик давления не изменяется при ожидаемой динамике | метрология / сервис |
| `temperature_out_of_range` | температура вне допустимого диапазона | эксплуатация |
| `data_quality_degraded` | качество данных не позволяет надёжный анализ | integration |
| `firmware_regression` | проблемы связаны с версией прошивки | firmware / backend |
| `tampering_suspected` | обнаружены признаки возможного вмешательства | безопасность / метрология |
| `leak_suspected` | обнаружены косвенные признаки возможной утечки | эксплуатация |
| `topology_dependency_failure` | симптомы вызваны отказом общего зависимого компонента | backend / infrastructure |
Каноны `tampering_suspected` и `leak_suspected` являются аналитическими гипотезами. Они не
доказывают нарушение, утечку, хищение или вину конкретного лица. Для подтверждения требуется
регламентированная техническая проверка.
### Версионирование канонов
Изменение текста или перевода не требует изменения идентификатора.
Новая версия канона требуется, если меняется:
- бизнес-смысл;
- правило назначения;
- критерий actionability;
- способ верификации;
- принцип SLA;
- логика объединения с другими проблемами.
## Аналитика качества детекторов
Operational Health Matrix оценивает не только оборудование, но и качество собственных аналитических алгоритмов.
Для каждого Detector рассчитываются:
- Accuracy;
- Precision;
- Recall;
- False Positive Rate;
- False Negative Rate;
- Average Confidence;
- Drift;
- Stability;
- Mean Verification Time;
- Acceptance Rate.
Подобный подход позволяет непрерывно совершенствовать аналитическую модель IIoT Платформы без нарушения воспроизводимости результатов.
Сам портфель детекторов развивается по поэтапному roadmap: новые детекторы вводятся волнами, и каждая волна открывается по готовности соответствующих API платформы.