---
title: 'Аналитика потребления'
description: Полный анализ одного узла учёта газа — качество данных, профиль потребления, паспорт прибора и журнал событий, с опциональной криминалистической детализацией.
section: AI Analytics
weight: 1
related:
- ai-analytics/node-reports/metering-bypass
- ai-analytics/node-reports/battery-forecast
- ai-analytics/fleet-reports/top-problem-nodes
---
import Alert from '@/components/docs/Alert.astro';
import Image from '@/components/docs/Image.astro';
Аналитика потребления — это подробный метрологический и эксплуатационный разбор **одного узла учёта газа** за выбранный период. Главная задача — не нарисовать график потребления, а ответить на практические вопросы службы учёта. Анализ опирается на международные метрологические нормы там, где они обосновывают конкретное число: ISO 5167 (метод сужающего устройства), EN 12405-1 (электронные корректоры объёма), OIML R 137 (счётчики газа), OIML R 140 (измерительные системы для газообразного топлива), ISO 6976 (теплота сгорания), EN 1359 (диафрагменные счётчики газа) и EN 14236 (ультразвуковые бытовые счётчики газа).
## Назначение
_Шапка отчёта._ Первое, что видит читатель: имя и адрес узла, тип корректора, ключевые метрики последнего часа (P, T), общий объём данных в окне (точек), число найденных событий, метод анализа (правила / правила+LLM / только LLM), длительность загрузки и охваченный период.
Отчёт отвечает на ежедневные вопросы службы учёта:
- полны ли данные за выбранный период;
- годен ли архив для коммерческого закрытия периода;
- есть ли хвостовой пропуск в конце периода;
- работает ли поточная телеметрия;
- сходится ли часовой расход с накопленным объёмом;
- есть ли залипание датчиков P/T;
- есть ли проблемы со связью или доставкой архива;
- достаточно ли заполнен метрологический паспорт;
- есть ли подозрительные паттерны недоучёта;
- нужен ли выезд на объект;
- какую роль должен выполнить каждый участник: метролог, диспетчер, инженер связи, инженер интеграции, выездная бригада или билинг-аналитик.
Отчёт **не является актом о нарушении**. Он не доказывает факт вмешательства, обхода учёта или
хищения газа. Он показывает технические и метрологические признаки, которые требуют проверки.
Юридическое заключение — отдельный процесс с обязательной полевой проверкой.
## Главная логика
Отчёт разделяет **три ортогональные оценки**, которые нельзя смешивать:
| Оценка | Что означает |
| ----------------------------------- | ----------------------------------------------------------- |
| Готовность данных периода | пригоден ли архив за выбранный период |
| Поточный статус телеметрии | работает ли узел на момент генерации отчёта |
| Готовность к коммерческому закрытию | можно ли использовать период для биллинга без ручной сверки |
Старый период может быть полностью пригоден для анализа, даже если узел сегодня уже не выходит на связь.
**Пример корректной интерпретации:**
```
Данные за период: пригодны с оговорками
Поточный мониторинг: деградирован
Биллинг: не готов к финальному закрытию
```
Это не противоречие. Это значит: исторические данные частично пригодны, но поточная телеметрия или коммерческое закрытие требует дополнительной проверки.
## Термины
| Термин | Пояснение |
| --------------------- | ------------------------------------------------- |
| Q | часовой расход, м³/ч |
| P | давление газа, кПа |
| T | температура газа, °C |
| V | накопленный объём, м³ |
| ΣQ | сумма часовых расходов за период |
| ΔV | прирост накопленного объёма за период |
| H_expected | сколько часов должно было быть в отчётном периоде |
| H_received | сколько часовых записей фактически получено |
| H_validQ | сколько записей имеют валидное значение расхода |
| H_nullQ | сколько записей есть, но расход пустой (NULL) |
| H_missing | сколько часов отсутствуют в архиве |
| final_tail_gap | отсутствие данных в конце периода |
| internal_gap | пропуск внутри периода |
| freshness | актуальность последнего часа архива |
| passport completeness | заполненность метрологического паспорта |
| incident | сгруппированная проблема, требующая действия |
## Временное окно анализа
### Начало и конец периода
Вы задаёте начало и конец периода. Отчёт анализирует все часы от 00:00 первых суток до 23:00 последних суток:
$$
\text{window\_start} = \text{report\_start } 00{:}00, \quad
\text{window\_end} = \text{report\_end } 23{:}00
$$
### Ожидаемое число часов
$$
H_\text{expected} = \mathrm{count}(\text{hours from window\_start to window\_end})
$$
Для годового периода обычно $H_\text{expected} \approx 8760$.
## Раскладка архива по доступности
| Категория | Значение |
| ------------------ | ----------------------------------------- |
| Валидный час | есть запись и корректное значение расхода |
| NULL-час | запись есть, но расход пустой |
| Внутренний пропуск | час отсутствует внутри периода |
| Хвостовой пропуск | отсутствующие часы в конце периода |
| Неохваченный час | любой час без валидного значения расхода |
**Формулы:**
$$
H_\text{received} = \mathrm{count}(\text{hourly records})
$$
$$
H_\text{validQ} = \mathrm{count}(\text{records where } Q \neq \text{NULL and } Q \geq 0)
$$
$$
H_\text{nullQ} = \mathrm{count}(\text{records where } Q = \text{NULL})
$$
$$
H_\text{missing} = \max(0, H_\text{expected} - H_\text{received})
$$
$$
H_\text{unobserved} = H_\text{missing} + H_\text{nullQ}
$$
Хвостовой пропуск **не учитывается дважды** поверх `missing_records`, если эти часы уже входят в
общее число отсутствующих записей.
## Полнота данных
_Доступность, свежесть и валидность_ — три ортогональных среза «проверки пригодности архива» перед содержательным анализом. **Полнота** отвечает: сколько часов из ожидаемых пришло. **Свежесть** — насколько данные актуальны _сейчас_. **Валидность** — попадают ли значения в физически разумные диапазоны.
### Формула покрытия
$$
\mathrm{Coverage}_\text{valid} = \frac{H_\text{validQ}}{H_\text{expected}} \times 100\,\%
$$
Дополнительно:
$$
\mathrm{Coverage}_\text{received} = \frac{H_\text{received}}{H_\text{expected}} \times 100\,\%
$$
Различие важно:
- `Coverage_received` — пришли ли записи в принципе;
- `Coverage_valid` — пригодны ли они для анализа расхода.
### Интерпретация покрытия
| Покрытие | Статус | Значение |
| -------- | --------- | ------------------------------------- |
| ≥ 98 % | Excellent | архив почти полный |
| 95–98 % | Good | пригоден с незначительными оговорками |
| 80–95 % | Warning | заметные пропуски |
| 50–80 % | Major | нужна ручная сверка |
| < 50 % | Critical | непригоден для большинства задач |
## Хвостовой пропуск
Хвостовой пропуск — отсутствие архивных данных в конце выбранного периода.
$$
H_\text{tail} = \text{window\_end} - \text{last\_valid\_archive\_hour}
$$
| Хвост | Статус |
| ------- | ------------------------------------------ |
| ≤ 2 ч | допустимо |
| 2–6 ч | warning |
| 6–24 ч | major |
| > 24 ч | critical |
| > 168 ч | прибор молчит более недели — срочный выезд |
Хвостовой пропуск отвечает на вопрос: **можно ли считать период закрытым до конца?** Если данных в конце нет, отчёт может быть пригоден для ретроспективного анализа, но **не готов** к финальному коммерческому закрытию (см. «Коммерческий вердикт учёта»).
## Свежесть данных
В отчёте две раздельные метрики свежести.
### Свежесть относительно конца периода
Используется для исторического анализа и биллинга:
$$
\mathrm{Lag}_\text{period} = \text{window\_end} - \text{last\_valid\_archive\_hour}
$$
Отвечает на вопрос: **есть ли данные до конца выбранного периода?**
### Свежесть относительно момента генерации
Используется для поточного мониторинга:
$$
\mathrm{Lag}_\text{current} = \text{generation\_time} - \text{last\_valid\_archive\_hour}
$$
Отвечает на вопрос: **работает ли узел сейчас?**
### Покрытие последних 24 часов
$$
\mathrm{Fresh}_{24h} = \frac{H_\text{validQ, last 24h}}{24} \times 100\,\%
$$
### Композитная оценка свежести
$$
\mathrm{LagScore} = \max(0, 100 - 2 \times \mathrm{Lag}_\text{period})
$$
$$
\mathrm{FreshnessScore} = \frac{\mathrm{LagScore} + \mathrm{Fresh}_{24h}}{2}
$$
## Поточный статус телеметрии
_Текущий мониторинг и сводка по узлу._ Этот блок отвечает на вопрос «можно ли принимать оперативные решения по этому архиву прямо сейчас?». Сравниваются три момента времени: последний архивный час, конец отчётного окна и момент генерации отчёта. Если связь свежая, а архив отстаёт — проблема **не у диспетчера**, а в парсере/выгрузке на стороне сервера. LLM-комментарий выдаёт короткую human-readable сводку для оператора, **не подменяя** формальные статусы.
Считается **относительно момента генерации**, не относительно периода:
$$
\mathrm{Lag}_\text{archive, current} = \text{generation\_time} - \text{last\_archive\_hour}
$$
$$
\mathrm{Age}_\text{session} = \text{generation\_time} - \text{last\_session\_time}
$$
| Отставание | Статус |
| ---------- | -------- |
| ≤ 6 ч | normal |
| 6–24 ч | warning |
| 24–72 ч | major |
| > 72 ч | critical |
| нет данных | critical |
**Дифференциальная диагностика:**
| Признак | Вероятная причина |
| ---------------------------- | ------------------------------------------------ |
| сеансы свежие, архив отстаёт | проблема **доставки / парсера / импорта** архива |
| нет сеансов, нет архива | модем / SIM / антенна / питание / батарея |
## Валидность данных
Проверка физических пределов по каналам:
| Канал | Условие |
| ------------- | ---------------------------------------------- |
| Расход Q | $Q \geq 0$ |
| Давление P | $0 < P \leq 5000\text{ kPa}$ |
| Температура T | $-50\,°\mathrm{C} \leq T \leq 80\,°\mathrm{C}$ |
Для каждого канала:
$$
\mathrm{Validity}_\text{ch} = \frac{N_\text{ok}}{N_\text{total}} \times 100\,\%,
\quad
N_\text{ok} = N_\text{total} - N_\text{null} - N_\text{below} - N_\text{above}
$$
Общая:
$$
\mathrm{Validity}_\text{total} = \frac{\sum N_\text{ok}}{\sum N_\text{checked}} \times 100\,\%
$$
## Стабильность сенсоров
_Детальная диагностика сенсоров P и T._ Каждый «залипший» интервал получает старт/конец/длину/значение. Длинные интервалы с одинаковым значением — почти всегда признак отказа АЦП / сброса датчика / эксплуатационной остановки потока, **а не** реальной физики. Спайки — резкие скачки ≥ порога за один час — наоборот, признак артефакта телеметрии или сброса датчика.
_Интерпретация и план действий по сенсорам._ «Состояние сенсоров: КРИТИЧНО» — итоговая словесная свёртка по обоим каналам. Каждой найденной проблеме автоматически назначается рекомендация с приоритетом, ролью-исполнителем и кратким триггером (что именно сработало).
### Залипание датчика
Сенсор считается залипшим, если значение почти не меняется длительнее порога (24 ч):
$$
H_\text{stuck} \geq 24 \text{ h}
$$
Допуск однородности (0.1 %):
$$
\mathrm{tol}(x) = \max\bigl(0.05,\ |x| \times 0.001\bigr)
$$
Точки считаются «той же самой», если $|x_i - x_\text{run}| \leq \mathrm{tol}(x_\text{run})$.
### Спайк температуры
$$
|T_i - T_{i-1}| > 20\,°\mathrm{C / h}
$$
### Спайк давления
$$
|P_i - P_{i-1}| > \max(1.0, 0.5 \times \overline{P})
$$
### Интерпретация
| Признак | Значение |
| ---------------------- | ----------------------------------------------- |
| Длительное залипание T | возможен отказ датчика T |
| Длительное залипание P | возможен отказ датчика P или режим `P_const` |
| Множественные спайки P | нестабильность канала или артефакт телеметрии |
| Множественные спайки T | ошибка датчика или резкий технологический режим |
Залипание датчика **не является доказательством** вмешательства. Это прежде всего метрологический
риск, требующий проверки по OIML R 137 / EN 12405-1.
## Сводная оценка качества архива
_Сводная панель качества._ Сверху — ключевые KPI отчёта (часы данных, объём, события, простои/дрейф). Ниже — вкладки по разделам (качество данных, профиль потребления, технический паспорт, недоучёт и вмешательство, аномалии и инциденты, суточные, источники). На вкладке качества данных — 6 суб-индикаторов 0–100 плюс словесный вердикт и веса композитного score.
Отчёт формирует **5 ортогональных score** (0–100 каждый), охватывающих отдельные грани качества:
| Score | О чём |
| ----------------------------- | --------------------------------------- |
| `score_historical_archive` | пригодность исторических данных периода |
| `score_data_validity` | корректность значений Q/P/T |
| `score_sensor_health` | состояние датчиков (залипание, спайки) |
| `score_timeliness` | свежесть архива и сеансов |
| `score_operational_readiness` | готовность к поточному мониторингу |
Единый **композитный скаляр** «общее качество» сознательно не формируется — смешивание
исторической пригодности со свежестью даёт ложно-успокаивающую картину. Каждый score читается
отдельно со своим вердиктом.
## Оценка потенциально неохваченного объёма
_Две разные оценки одного и того же объёма._ Среднее по периоду консервативно (хвостовое восстановление при ровном профиле), а профиль активных часов точнее учитывает суточную ритмику (рабочая смена / ночь / выходной). Разница между ними — это **диапазон неопределённости**, а не одна точка. Уровень риска зависит от длительности дыры и характерного среднего расхода.
_Аномальный месяц расхода._ Месячные аномалии — отдельный сигнал, который рассматривается на фоне годовой ритмики (отопительный сезон vs лето). Если конкретный месяц **существенно** превышает медиану остальных (порог × 2), он автоматически выносится в шапку с предложением проверить ленту событий, паспорт и наличие технологических причин.
Этот блок оценивает, сколько газа могло пройти в часы без валидных архивных данных.
Это **не подтверждённая потеря**. Не сумма хищения и не автоматический ущерб. Это оценка **слепой
зоны** — объёма, не покрытого валидным архивом.
### Часы без валидных данных
$$
H_\text{blind} = H_\text{missing} + H_\text{nullQ}
$$
### Оценка по среднему
$$
\overline{Q} = \frac{\sum Q_\text{valid}}{H_\text{validQ}},
\qquad
V_\text{blind, mean} = H_\text{blind} \times \overline{Q}
$$
Подходит для объектов с относительно равномерным потреблением.
### Оценка по профилю
Типовой расход для часа суток $h$ (медиана за период):
$$
\mathrm{Profile}(h) = \mathrm{median}(Q \mid \text{hour\_of\_day} = h)
$$
$$
V_\text{blind, profile} = \sum_{t \in \text{BlindHours}} \mathrm{Profile}(\text{hour}(t))
$$
Если профиль для часа ненадёжен — используется $\overline{Q}$.
### Диапазон оценки
В отчёте показываются обе оценки. Если они близки — суточный профиль стабилен. Если сильно расходятся — у объекта выраженный режим работы, и нужна осторожность.
## Узел не работал
Если узел почти весь период не имел реального потребления, отсутствие расхода **не трактуется как риск**.
### Idle-проверка
Адаптивный порог near-zero:
$$
Q_\text{nearzero} = \max(0.5, 0.05 \times \mathrm{median}(Q))
$$
Узел считается фактически остановленным, если выполнены **оба условия**:
$$
\overline{Q} \leq 0.05\text{ m³/h} \quad \text{and} \quad V_\text{blind, mean} < 5\text{ m³}
$$
### Эффект
Шкала severity становится мягче (максимум `medium` вместо `critical`), и отчёт пишет:
> Узел фактически не работал / сезонно остановлен. Отсутствие потребления не считается риском недоучёта.
## Q/V-сверка
_Сверка часового расхода с накопителем._ Метрологически коммерческий расчёт ведётся именно по приросту накопителя V, а не по сумме мгновенных Q. Совпадение ΣQ ≈ ΔV ≥ 80 % часов — норма для исправного узла. **Откаты V** (час → час, $V_{t+1} < V_t$) и **резкие скачки V** — критичные признаки сбоя архива и почти всегда требуют разбирательства.
Ключевой метрологический блок. Сравнивает сумму часовых расходов с приростом накопителя.
### Базовые величины
$$
\Sigma Q = \sum_{h=1}^{n} Q_h, \qquad
\Delta V = V_\text{end} - V_\text{start}
$$
$$
\mathrm{Diff} = \Sigma Q - \Delta V, \qquad
\mathrm{Diff}_\% = \frac{\Sigma Q - \Delta V}{\Delta V} \times 100\,\%
$$
### Интерпретация различия
| $\vert\mathrm{Diff}_\%\vert$ | Verdict |
| ---------------------------- | ------------------------------ |
| ≤ 2 % | `good` (aligned) |
| 2–5 % | `warn` (aligned with caveats) |
| > 5 % | `bad` (mismatch) |
| нет V | `unavailable` |
| база Q/V неизвестна | requires passport verification |
### Монотонность накопителя
Накопитель должен расти или оставаться постоянным.
Откат: $\Delta V_h < -0.5\text{ m³}$ → инцидент `V_ROLLBACK`.
Резкий скачок: $\Delta V_h > V_\text{jump\_threshold}$ → инцидент `V_JUMP`.
### Почасовая сверка $Q \cdot 1\text{h} \approx \Delta V$
Для каждого часа, где есть и $Q$, и $V$:
$$
\mathrm{Match}_h = \frac{|Q_h - \Delta V_h|}{\max(Q_h, \Delta V_h)}
$$
Час согласован, если $\mathrm{Match}_h \leq 20\,\%$. Доля согласованных часов:
$$
\mathrm{Match}_\% = \frac{H_\text{matched}}{H_\text{checked}} \times 100\,\%
$$
### Ограничения Q/V-сверки
Даже хорошее численное совпадение не равняется коммерческой пригодности. Нужно знать:
| Вопрос | Почему важно |
| ---------------------------------- | ---------------------------------------- |
| Q — стандартный или рабочий объём? | разные базы дают смещение |
| V — стандартный или рабочий объём? | нужна одна база |
| Какая цена импульса? | требуется для полной коммерческой сверки |
| Монотонен ли V? | откаты ставят архив под сомнение |
| Есть ли ручные коррекции? | могут объяснить расхождение |
Если база неизвестна:
> Q/V-сверка численно согласована, но коммерческая база не подтверждена. Требуется сверка паспорта, цены импульса и базы объёма (см. EN 12405-1 §7).
## Связь vs архив
_Дифференциальная диагностика «связь vs выгрузка»._ Если сеансы в окне есть, а архива нет — значит прибор отвечает по GSM/CSQ, но архив либо не пишется, либо не парсится сервером. Это **не** проблема диспетчерской / модема — её должен решать инженер интеграции.
### Базовые формулы
$$
N_\text{sessions} = \mathrm{count}(\text{sessions}), \quad
N_\text{success} = \mathrm{count}(\text{successful sessions})
$$
$$
\mathrm{SessionSuccess}_\% = \frac{N_\text{success}}{N_\text{sessions}} \times 100\,\%
$$
### Доставка архива
Для каждого пропуска проверяется, были ли сеансы связи в том же временном окне:
- `gap_with_sessions` — пропуск архива, но сеансы были;
- `gap_without_sessions` — пропуск архива и сеансов тоже не было.
### Дифференциальная диагностика
| Ситуация | Вероятная причина |
| ---------------------------------------- | --------------------------------------------- |
| нет сеансов, нет архива | модем / SIM / антенна / питание |
| сеансы есть, архив не обновляется | доставка часового архива / парсер / импорт |
| сеансы есть, но часть архива отсутствует | неполное считывание / обрыв страниц / backend |
| сеансы свежие, архив старый | проблема **не в GSM**, а в доставке архива |
| timestamp сеанса из будущего | clock / timezone mismatch |
### Качество связи
Если качество сигнала передано как CSQ:
$$
\mathrm{RSSI}_\text{dBm} \approx -113 + 2 \times \mathrm{CSQ}
$$
Пример: CSQ=29 → RSSI ≈ −55 dBm (отличный сигнал).
## Метрологический паспорт
### Обязательные поля и их веса
Паспорт определяет 11 полей с весами:
| Поле | Вес | Зачем |
| -------------------------- | ------- | ------------------------------------------ |
| equipment_serial_number | 1.0 | идентификация |
| equipment_type_id | 1.0 | тип/модель |
| installation_date | 0.8 | эксплуатационный контекст |
| **verification_date** | **1.5** | юридическая пригодность (OIML R 137 cl. 3) |
| next_verification_date | 1.0 | контроль срока |
| **flow_range** (Qmin/Qmax) | **1.5** | диапазон по EN 12405-1 |
| meter_serial_number | 1.0 | идентификация на месте |
| meter_type | 1.0 | метрологическая связка |
| firmware_version | 0.5 | совместимость и известные ошибки |
| p_const | 0.5 | подстановочное давление |
| pulse_weight | 0.8 | для Q/V-сверки |
### Формула заполненности
$$
\mathrm{PassportCompleteness} = \frac{\sum w_\text{filled}}{\sum w_\text{required}} \times 100\,\%
$$
### Интерпретация
| Заполненность | Статус |
| ------------- | ------------------- |
| ≥ 80 % | COMPLETE |
| 50–80 % | PARTIAL |
| 20–50 % | INCOMPLETE |
| < 20 % | CRITICAL_INCOMPLETE |
Если паспорт неполный, коммерческий вердикт обязан содержать оговорку:
> Метрологический паспорт неполный. Коммерческий вердикт требует ручной сверки и обращения к OIML R 137 / EN 12405-1.
## Подозрительные паттерны недоучёта
_Триаж сигналов._ Каждый сигнал классифицируется по категории, имеет уровень доказательности (низкая / средняя / высокая), полевой приоритет, формальное доказательство и рекомендуемое действие. **Это не приговор узлу** — это список окон, требующих ручной проверки оператором или сервисной службой.
Это **эвристики**, не доказательства.
### Порог near-zero
$$
Q_\text{nearzero} = \max(0.5, 0.05 \times \mathrm{median}(Q))
$$
### Нулевой расход в активные часы
Час считается подозрительно тихим, если $Q_h < Q_\text{nearzero}$ И час принадлежит к типовому активному интервалу объекта.
### Live-P + zero (Q≈0 при живом P)
Может быть:
- простой / закрытый downstream-клапан / сезонная остановка;
- режим P_const или неисправность датчика;
- ошибка импульсного входа;
- **возможный обход учёта** — но не доказанный.
Live-P + zero **не является доказательством** вмешательства. Это лишь причина для проверки режима
работы узла.
### Break-recovery
Паттерн: нормальный Q → Q≈0 → нормальный Q. Резкая смена режима, но не доказательство нарушения. Возможные пояснения: плановое отключение / остановка объекта / закрытие крана / сбой канала / ручное вмешательство / ошибка доставки архива.
### Подтверждённое вмешательство
Только статистический паттерн **не может** подтвердить вмешательство. Нужны **жёсткие доказательства**:
- открытие корпуса (cover_open в device events);
- магнитное воздействие;
- изменение параметров (parameter_change);
- несанкционированное изменение P_const;
- сброс архива;
- подтверждённая манипуляция импульсным входом;
- акт выездной проверки;
- фото / пломбы / показания на месте.
Правильная формула вердикта:
```
Confirmed tampering: NOT DETECTED
Suspicious patterns: PRESENT
Legal readiness: NOT READY
```
## Коммерческий вердикт учёта
_Управленческий статус._ 7 строк закрывают 7 разных вопросов руководителя: можно ли закрывать период (биллинг), работает ли узел сейчас (мониторинг), сходятся ли архив и накопитель (Q×h vs ΔV), нужен ли выезд, есть ли подозрительные паттерны, насколько целостны данные, есть ли все паспортные параметры. Каждая строка кликабельна и ведёт к доказательной части отчёта.
Главный вердикт для руководителя службы учёта.
### Архив для биллинга — правила
**Ready:**
- Coverage ≥ 98 %
- Tail gap ≤ 2 ч
- Q/V aligned (`good`)
- V монотонен
- Passport COMPLETE
- Нет критичных проблем с сенсорами
**Ready with caveats:**
- Coverage 95–98 %
- Tail gap 2–24 ч
- Q/V aligned with caveats (`warn`)
- Passport PARTIAL
- Нет критичного blocker'а
**Not ready for final closure:**
- Tail gap > 24 ч ИЛИ
- Q/V не классифицирован ИЛИ
- Присутствует откат V ИЛИ
- Passport неполон в коммерческих полях ИЛИ
- Критичная проблема с сенсором
**Not usable:**
- Coverage критически низкое ИЛИ
- Архив повреждён ИЛИ
- V имеет крупный откат/скачки ИЛИ
- Q/V полностью несогласован ИЛИ
- Ключевой канал недоступен
### Поточный мониторинг — оценивается отдельно
| Условие | Статус |
| -------------------------- | ------------------------------ |
| архив и сеанс свежие | usable |
| архив отстаёт, сеансы есть | degraded / delivery issue |
| архив и сеансы старые | critical / communication issue |
| timestamp некорректен | unreliable |
### Выездная инспекция
Выезд нужен, если выполняется **хотя бы одно** из:
- хвостовой пропуск не восстановлен;
- Q/V не классифицирован;
- есть откат накопителя;
- паспорт критически неполон;
- датчик P или T залип;
- есть подозрительные паттерны недоучёта;
- журнал событий недоступен, но есть сильные аномалии;
- поточная телеметрия критически деградирована.
## Инциденты
Инцидент — это **сгруппированная** проблема, а не каждая raw-запись.
### Типы
| Тип | Значение |
| ---------------------- | ----------------------------------------- |
| `FINAL_TAIL_GAP` | нет данных в конце периода |
| `COMMUNICATION_GAP` | разрыв связи |
| `ARCHIVE_DELIVERY_GAP` | сеансы есть, архив не доставлен |
| `Q_V_MISMATCH` | Q и V не сходятся |
| `V_ROLLBACK` | откат накопителя |
| `P_SENSOR_STUCK` | залипло давление |
| `T_SENSOR_STUCK` | залипла температура |
| `PASSPORT_INCOMPLETE` | не хватает паспортных полей |
| `TAMPERING_CANDIDATE` | подозрительный паттерн, не доказательство |
### Принцип группировки
```
raw events → grouped incidents → top priority incidents
```
Пример: 301 raw → 15 grouped → Top-5 for action. Оператору нельзя показывать 301 однотипное событие как 301 отдельную проблему.
## План действий
_Действия с приоритетами P0/P1/P2._ Каждое действие имеет роль-исполнителя, срок (сегодня / в течение дня / 1–3 дня) и **причину**, по которой оно появилось в списке. Чек-лист выезда строится автоматически из вердикта и открытых инцидентов: что взять, куда смотреть, что замерить — с метками P0/P1 для приоритезации на месте.
Каждая рекомендация привязана к причине.
| Поле | Описание |
| --------- | --------------------------------- |
| ID | номер рекомендации |
| Приоритет | P0 / P1 / P2 / P3 |
| Действие | что сделать |
| Роль | кто отвечает |
| Срок | когда выполнить |
| Причина | почему это действие появилось |
| Статус | open / assigned / done / verified |
### Примеры правил
| Условие | Действие |
| -------------------------- | --------------------------------------------------------------- |
| хвост > 24ч, сеансы свежие | backend: восстановить доставку часового архива |
| хвост > 24ч, сеансов нет | связь: проверить модем/SIM/питание |
| T залип ≥ 24ч | метролог: проверить датчик T (OIML R 137) |
| P залип ≥ 24ч | метролог: проверить датчик P или настройку P_const |
| Q/V mismatch | метролог + биллинг: сверить V, Q, цену импульса (EN 12405-1 §7) |
| паспорт неполон | администратор / метролог: дополнить паспорт |
| подозрительные паттерны | выездная бригада: проверить пломбы, импульсный вход, краны |
## Чек-лист выезда
### Что взять
эталонный манометр • эталонный термометр • мультиметр • тестер сигнала/антенны • комплект пломб • протокол осмотра • доступ к архиву и паспорту • средство фотофиксации.
### Что проверить
пломбы корректора и счётчика • импульсный кабель • датчики P, T • модем, антенну, питание, батарею • запорную арматуру • возможный байпас • соответствие паспорта фактическому оборудованию.
### Что замерить
эталонные P, T • текущий Q • накопленный V • показания внешнего счётчика • CSQ/RSSI • напряжение питания • импульсы на входе • дату/время корректора • P_const • Qmin/Qmax • цену импульса.
### Что сфотографировать
дисплей корректора (P/T/Q/V) • дату/время на приборе • серийные номера • пломбы • импульсный кабель • датчики • модем и антенну • общий вид • положение кранов.
## Источник данных по поведенческому профилю
Конкретный архив API и поле выбираются автоматически по поведению прибора. Три семейства:
### Непрерывный часовой архив
Прибор пишет показания **строго раз в час**. Приоритет источников:
1. прямое поле «расход за час» (если прибор сам его считает);
2. Δ накопленного стандартного объёма;
3. Δ накопленного рабочего объёма.
Допустимый разрыв — **ровно 1 час**.
### Сессионная передача с архивом текущего состояния
Прибор пишет показания при выходе на связь, не строго каждый час. Первичный источник — **мгновенный расход** (прибор сам считает); fallback — Δ накопленного объёма с нормализацией:
$$
\dot Q_h = \frac{V_t - V_{t-\Delta t}}{\Delta t / 3600}
$$
Допустимый разрыв — **до 6 часов**; при $\Delta t > 6\text{ h}$ точка считается невалидной (вероятная потеря данных, а не разряд счётчика).
### Чисто-телеметрические блоки
Прибор передаёт только связь/состояние, газ не меряет — отчёт показывает N/A с пометкой «учётной точки в этом приборе нет».
### Sparse-fallback
Если основной архив дал < 50 % ожидаемых точек, автоматически пробуется второстепенный архив сессий (как есть, без часовой сетки) и счёт идёт по нему.
## Ограничения методики
### Архив
Если часовой архив неполный, все оценки за пропущенные часы являются **приблизительными**.
### Q/V
Q/V-сверка имеет смысл только когда Q и V:
- в одной базе объёма (стандартной или рабочей);
- имеют корректную цену импульса;
- принадлежат к одному источнику учёта;
- синхронизированы по времени.
См. OIML R 137 для процедуры поверки и EN 12405-1 §7 для базы пересчёта.
### Паспорт
Без Qmin/Qmax, даты поверки, P_const или цены импульса коммерческий вердикт должен содержать оговорку.
### Подозрительные паттерны
Паттерны недоучёта — **не доказательство** вмешательства. Они только определяют приоритет проверки.
### LLM-комментарий
LLM-комментарий **не участвует** в юридическом вердикте и не заменяет формальные правила. Он только помогает объяснить ситуацию человеческим языком.
## Как читать отчёт
_Визуализация Q/P/T и поведенческие профили._ На основном графике события подсвечены полупрозрачными вертикальными полосами по типам (всплеск / простой / утечка / залипший датчик / нет данных) — любой тип можно скрыть/показать кликом по его чипу. Скользящие средние 7 / 30 дней дают сезонное сглаживание. Паттерн потребления — двойная разбивка: суточный профиль (час дня) с разделением будни/выходные и календарный heatmap «день недели × месяц», показывающий устойчивость рабочих смен.
_Сравнение период-к-периоду._ Year-over-year delta нагружено двумя ловушками: (1) **изменение покрытия предыдущего периода** (если там было 6 %, рост события «в 33 раза» — артефакт деления, а не реальность) и (2) **отсутствие нормализации** на длину окна. Поэтому при покрытии < 50 % система маскирует Δ % и показывает только абсолютные дельты, чтобы не подвести оператора к ложным выводам.
1. Начать с **Коммерческого вердикта учёта**.
2. Посмотреть, готов ли период к биллингу.
3. Отдельно проверить поточный мониторинг.
4. Перейти к **Top-5 инцидентов**.
5. Если есть хвост — смотреть «связь vs архив».
6. Если есть Q/V расхождение — смотреть анализ накопленного объёма.
7. Если залипли датчики P/T — смотреть стабильность сенсоров.
8. Если паспорт неполон — **не делать** жёстких коммерческих выводов.
9. Если есть подозрительные паттерны — планировать проверку, но **не выносить юридический вердикт**.
10. Выполнить план действий по ролям.
## Минимальные критерии полного отчёта
Отчёт считается полным, если содержит:
- период анализа • $H_\text{expected}$ • полученные записи • валидные записи • NULL-записи • внутренние пропуски • хвостовой пропуск • покрытие • свежесть • валидность Q/P/T • состояние сенсоров • оценку неохваченного объёма • Q/V-сверку • монотонность V • связь vs архив • заполненность паспорта • Top-5 инцидентов • план действий по ролям • чек-лист выезда;
- три обязательных дисклеймера:
- по недоучёту (это оценка слепой зоны, а не сумма потерь);
- по подозрению на вмешательство (паттерны ≠ доказательства);
- по LLM-комментарию (не юридический вердикт).
## Параметры запуска
| Параметр | Описание |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| № узла учёта | узел учёта для анализа |
| Период с | начало окна анализа (по умолчанию: год назад) |
| Период по | конец окна анализа (по умолчанию: вчера) |
| Расширенный анализ | дополнительно загружает архив сеансов связи и архив нештатных событий корректора. Включает блоки «Готовность источника данных», «Состояние связи» и «Журнал нештатных ситуаций прибора» и заполняет матрицу первопричин с уверенностью и первопричиной по каждому событию. Добавляет 5–15 секунд к времени построения отчёта. |