---
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._ Кожен «залиплий» інтервал отримує старт/кінець/довжину/значення. Довгі інтервали з однаковим значенням майже завжди є ознакою відмови АЦП / sensor reset / експлуатаційної зупинки потоку, **а не** реальної фізики. Спайки — різкі стрибки ≥ порогу за одну годину — навпаки, ознака артефакту телеметрії або sensor reset.
_Інтерпретація і план дій за сенсорами._ «Стан сенсорів: КРИТИЧНО» — підсумкова словесна згортка за обома каналами. Кожній знайденій проблемі автоматично призначається рекомендація з пріоритетом, роллю-виконавцем і коротким тригером (що саме спрацювало).
### Залиплий сенсор
Сенсор вважається залиплим, якщо значення майже не змінюється довше за поріг (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), він автоматично виноситься у шапку з пропозицією перевірити стрічку подій, паспорт і технологічні причини.
Цей блок оцінює, скільки газу могло пройти у години без валідних архівних даних.
Це **не підтверджена втрата**. Не сума розкрадання і не автоматичний збиток. Це оцінка **blind
spot** — обсягу, не покритого валідним архівом.
### Години без валідних даних
$$
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 / антена / живлення |
| сеанси OK, архів не оновлюється | доставка hourly archive / parser / import |
| сеанси OK, але частина архіву відсутня | неповне зчитування / обрив сторінок / 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 rollback АБО
- Passport неповний у комерційних полях АБО
- Критична проблема з сенсором
**Not usable:**
- Coverage критично низький АБО
- архів пошкоджений АБО
- V має великий rollback/spikes АБО
- 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 | номер рекомендації |
| Priority | P0 / P1 / P2 / P3 |
| Action | що зробити |
| Role | хто відповідає |
| Deadline | коли виконати |
| Cause | чому ця дія з'явилася |
| Status | open / assigned / done / verified |
### Приклади правил
| Умова | Дія |
| ----------------------------- | -------------------------------------------------------------- |
| хвіст > 24 год, сеанси свіжі | backend: відновити доставку hourly archive |
| хвіст > 24 год, сеансів немає | зв'язок: перевірити модем/SIM/живлення |
| T stuck ≥ 24 год | метролог: перевірити датчик T (OIML R 137) |
| P stuck ≥ 24 год | метролог: перевірити датчик P або налаштування P_const |
| Q/V mismatch | метролог + білінг: звірити V, Q, ціну імпульсу (EN 12405-1 §7) |
| паспорт неповний | адміністратор / метролог: заповнити паспорт |
| suspicious patterns | виїзна бригада: перевірити пломби, імпульсний вхід, крани |
## Чек-лист виїзду
### Що взяти
еталонний манометр • еталонний термометр • мультиметр • тестер сигналу/антени • комплект пломб • протокол огляду • доступ до архіву і паспорта • фотофіксація.
### Що перевірити
пломби коректора і лічильника • імпульсний кабель • датчики 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 інцидентів • план дій за ролями • чек-лист виїзду;
- три обов'язкові дисклеймери:
- за недообліком (це оцінка blind spot, а не сума втрат);
- за підозрою на втручання (патерни ≠ докази);
- за LLM-коментарем (не юридичний висновок).
## Параметри запуску
| Параметр | Опис |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Вузол обліку # | вузол обліку для аналізу |
| Період з | початок вікна аналізу (за замовчуванням: рік тому) |
| Період по | кінець вікна аналізу (за замовчуванням: вчора) |
| Розширений аналіз | додатково завантажує архів сеансів зв'язку і архів позаштатних подій коректора. Вмикає блоки Data Source Readiness, Communication Health і Device Abnormal Log і заповнює Root Cause Matrix впевненістю і першопричиною за кожною подією. Додає 5–15 секунд до часу побудови звіту. |