Обхід обліку (вузол)

Скоринг підозри на обхід обліку для одного вузла (0–100) з патернами, формулами, доказовістю, юридичною готовністю та чек-листом виїзної перевірки.

Звіт Обхід обліку виконує формалізований аналіз одного вузла обліку за вибраний період з метою виявлення ознак можливого недообліку, підміни вимірювального каналу, некоректної роботи датчиків або інших подій, що потребують уваги служби обліку. Він спирається на ті самі стандарти, що регулюють облік газу: ISO 5167 (звужувальні пристрої), ISO 6976 (теплота згоряння), EN 12405-1 (електронне перетворення обʼєму газу), OIML R 137 (лічильники газу), OIML R 140 (вимірювальні системи для газоподібного палива) та EN 1359 (мембранні лічильники).

Призначення звіту

Шапка звіту. Перше, що бачить читач: ідентифікатор вузла, ідентифікатор приладу, тип коректора, охоплений період, час генерації, підсумковий бал підозри та його словесний рівень. Бал сам по собі нічого не доводить — це композитний показник, який обовʼязково треба читати разом із шістьма сусідніми індикаторами (див. зведення для розслідування нижче).

Звіт не є актом про порушення. Він не встановлює факт викрадення, не замінює виїзну перевірку і не є юридичним висновком. Його завдання — математично та метрологічно описати підозрілі патерни, показати доказовість джерел, визначити пріоритет перевірки і дати виїзній бригаді чіткий перелік того, що треба перевірити на місці.

Звіт відповідає на такі запитання:

чи є в годинному архіві періоди Q≈0, які виглядають нетипово;
чи фіксувався канал тиску P на підставному або майже незмінному значенні;
чи змінювалася температура T за нерухомого тиску;
чи був різкий повернення Q і P після нульового періоду;
чи є збіги з архівом позаштатних ситуацій;
чи є прямі сигнали пристрою: фізичний доступ, зміна параметрів, скидання, зміна часу;
наскільки повні джерела даних;
чи можна вважати підозру підтвердженою;
чи потрібен виїзд і з яким пріоритетом;
який потенційний масштаб неврахованого обʼєму потребує перевірки;
які альтернативні гіпотези треба виключити до будь-яких висновків про втручання.

Цільова аудиторія

Роль	Що отримує зі звіту
Керівник служби обліку	загальний рівень підозри, доказовість, юридичну готовність, пріоритет виїзду
Метролог	перевірку каналів `Q/P/T`, режим `P_const`, застосовність фізичної моделі, паспортні прогалини
Інженер з телеметрії	звʼязок з архівом сеансів, повноту джерел, підозрілі пропуски
Виїзна бригада	top-вікна для перевірки та чек-лист огляду
Служба контролю	перелік підозрілих патернів, подій пристрою та альтернативних гіпотез
Білінг-аналітик	орієнтовний exposure-обʼєм як масштаб потенційного blind spot
Юрист газопостачальної організації	базу для підготовки акта за підтверджених hard evidence

Чого звіт робити НЕ повинен

Звіт не повинен:

автоматично звинувачувати споживача в обході обліку;
називати розрахунковий exposure підтвердженою шкодою;
трактувати нульову витрату як порушення без перевірки експлуатаційного режиму;
вважати залиплий датчик доказом втручання;
застосовувати закон Гей-Люссака без перевірки фізичної застосовності;
вважати P=100 kPa незаконним без паспорта і режиму P_const;
підвищувати юридичну готовність лише за AI-коментарем;
будувати висновок про втручання за відсутнього годинного архіву;
підміняти польовий акт автоматичним балом.

Основні терміни

Термін	Значення
`Q`	годинна витрата газу, m³/h
`P`	тиск, kPa
`T`	температура газу, °C
`Q≈0`	витрата нижче порога near-zero
`P_default`	тиск, близький до підставного значення: наприклад 100, 101.325, 103, 105 або 0 kPa
`P_stuck`	тиск майже не змінюється протягом періоду
`zero-flow run`	безперервний період, де витрата близька до нуля
`recovery`	різкий повернення витрати та/або тиску після нульового періоду
`event`	виявлене вікно підозрілого патерну
`severity`	сила ознаки: `low` / `medium` / `high` / `high_plus`
`pattern score`	математичний бал підозри за патернами архіву (0..100)
`event score`	бал за прямими або класифікованими подіями пристрою (0..100)
`final score`	підсумкова оцінка підозри, `max(pattern, event)`
`evidence confidence`	повнота доказової бази
`legal readiness`	готовність до юридично значущого висновку
`field priority`	пріоритет виїзної перевірки `P0..P3`
`exposure`	оцінний потенційно неврахований обʼєм, не доведена шкода
`hard evidence`	прямий доказ: розкриття корпусу, зміна параметрів, скидання архіву, підтверджена подія пристрою, акт

Загальна логіка звіту

Загальна логіка звіту будується у кілька шарів:

text

Годинний архів Q/P/T
→ пошук нульових періодів витрати
→ перевірка каналу тиску P
→ перевірка температури T
→ перевірка recovery після нульового вікна
→ перевірка додаткових патернів
→ зіставлення з журналом пристрою
→ розрахунок pattern score
→ розрахунок event score
→ обмеження severity cap
→ оцінка evidence confidence
→ legal readiness
→ field priority
→ exposure estimate
→ root cause matrix
→ чек-лист виїзду

Принципово важливо, що звіт відокремлює:

статистичний патерн у годинному архіві;
подію пристрою в журналі коректора;
доказовість джерел;
юридичну готовність;
польову перевірку.

Кожен із пʼяти шарів оцінюється незалежно. Високий бал за одним з них не підвищує готовність до дії за іншим. Наприклад, score=100 за відсутніх подій пристрою і без виїзду може залишитися partial за legal readiness і P1 за field priority.

Вхідні дані

Обовʼязкові дані

Джерело	Призначення
Годинний архів `Q/P/T`	основне джерело для пошуку патернів
Період аналізу	межі вікна
Ідентифікатори вузла і приладу	привʼязка результату до конкретного обʼєкта

Без годинного архіву звіт може показати лише відсутність даних і не має будувати повноцінний висновок про підозру.

Бажані дані

Джерело	Призначення
Архів сеансів звʼязку	перевірка, чи був вузол онлайн під час подій
Архів позаштатних ситуацій	пошук hard evidence: розкриття корпусу, скидання, parameter_change
Паспорт коректора	перевірка законності `P_const`, Qmin/Qmax, ціни імпульсу
Польовий огляд	підтвердження пломб, схеми трубопроводу, фактичного режиму
Фото дисплея коректора	фіксація `Q/P/T/V`, дати, часу, режиму
Покази зовнішнього лічильника	звірення накопиченого обʼєму

Мінімальний надійний період

Період коротший за 30 днів автоматично знижує впевненість доказової бази на один щабель: high → medium, medium → low. Розумний мінімум — 90 днів; рекомендований період — 366 днів (рік дає сезонність для всіх патернів).

Карта доказів

Карта доказів. Які джерела даних використано для скорингу і наскільки вони повні. Чим більше зелених «OK», тим вища впевненість у доказах. Кожне джерело має вагу у формулі evidence confidence, а статус partial або missing знижує підсумковий відсоток.

Джерело	Статус	Вага в доказовості
Годинний архів Q/P/T	ok / partial / missing	3
Архів сеансів звʼязку	ok / partial / missing	2
Архів позаштатних ситуацій	ok / partial / missing	3
Паспорт коректора	ok / partial / missing	1
Польовий огляд	ok / partial / missing	3

Формула доказовості джерел

Нехай:

w_i — вага джерела;
s_i — коефіцієнт статусу джерела.

Статуси:

s_i = \begin{cases} 1, & status_i = ok \\ 0.5, & status_i = partial \\ 0, & status_i = missing \end{cases}

Тоді загальний відсоток доказовості джерел:

EvidenceSourcePct = \frac{\sum (w_i \times s_i)}{\sum w_i} \times 100\%

Інтерпретація evidence confidence

EvidenceSourcePct	Evidence confidence
≥ 70%	high
35–70%	medium
< 35%	low

Нульовий період витрати

Більшість ознак звіту починається з пошуку періодів, де витрата близька до нуля.

Near-zero поріг

Базовий поріг:

Q_{nearzero} = 0.5 \; m³/h

Година вважається нульовою, якщо:

Q_h \le Q_{nearzero}

Мінімальна тривалість

Нульовий період стає кандидатом для аналізу, якщо триває не менше:

H_{zero\_run} \ge 6 \; hours

Тобто:

text

Q≈0 безперервно 6 годин або більше

Чому саме 6 годин

Поріг 6 годин дає змогу не реагувати на короткі експлуатаційні паузи, випадкові простої або поодинокі нульові точки. Для патерну обходу або підміни цікаві не окремі нулі, а стійке вікно, в якому витрата відсутня, тоді як інші канали поводяться підозріло.

Емпірично 6 годин покривають більшість реальних патернів «нічне вимкнення → ранковий запуск з підміною» без хибних спрацювань на обідні паузи або короткі планові зупинки промислових обʼєктів.

Підставний тиск P_default

Одна з ключових ознак — тиск, близький до типових підставних значень.

Підставні значення

Група	Значення
Атмосферні / договірні	100.0, 101.325, 103.0, 105.0 kPa
Нульове / вимкнений датчик	0.0 kPa

Допуск

Для атмосферних і договірних значень:

Tolerance_{atm} = 0.5 \; kPa

Для нульового значення:

Tolerance_{zero} = 0.3 \; kPa

Формула близькості

Тиск вважається близьким до підставного значення, якщо:

|P_{mean} - P_{default}| \le Tolerance

де:

P_mean — середній тиск всередині нульового вікна;
P_default — одне з підставних значень.

Важливе обмеження

P_default не є доказом порушення сам по собі. Він може бути:

законним режимом P_const;
налаштуванням приладу за відсутності датчика;
аварійним fallback-значенням;
наслідком вимкнення датчика;
особливістю конкретного коректора.

Тому для будь-якого висновку потрібен паспорт:

text

Перевірити: чи дозволений P_const, яке значення P_const задано, чому воно застосовувалося.

Зафіксований канал тиску P_stuck

Стандартне відхилення тиску

Всередині нульового вікна розраховується стандартне відхилення тиску:

\sigma_P = \sqrt{ \frac{1}{n-1} \sum_{i=1}^{n} (P_i - \overline{P})^2 }

Канал тиску вважається зафіксованим, якщо:

\sigma_P < 0.1 \; kPa

Зміна температури

Для фізичної перевірки потрібно, щоб температура у вікні змінювалася помітно:

\Delta T = max(T_i) - min(T_i)

Умова:

\Delta T \ge 1^\circ C

Якщо температура майже не змінювалася, неможливо впевнено сказати, чи мав змінюватися P.

Перевірка за законом Гей-Люссака

Фізична формула

Для замкнутого обʼєму газу за постійної кількості речовини виконується:

\frac{P}{T_K} = const

де:

T_K = T_C + 273.15

Якщо відомі початкові значення:

P_{expected,i} = P_1 \times \frac{T_{K,i}}{T_{K,1}}

Очікувана зміна тиску:

\Delta P_{expected} = max(P_{expected,i}) - min(P_{expected,i})

Порівняння з фактичною зміною

Фактична варіативність тиску оцінюється через стандартне відхилення або діапазон:

P_{std} = \sigma_P

або:

\Delta P_{actual} = max(P_i) - min(P_i)

Якщо:

\Delta P_{expected} \gg \Delta P_{actual}

і одночасно:

\sigma_P < 0.1 \; kPa

то канал тиску вважається підозріло зафіксованим.

Коефіцієнт розбіжності

Для пояснення у звіті може використовуватися відношення:

K_{GL} = \frac{\Delta P_{expected}}{max(\sigma_P, \varepsilon)}

де ε — мала константа для захисту від ділення на нуль.

Якщо K_GL великий, звіт вказує, що очікувана зміна тиску в багато разів більша за фактичну варіативність.

Важливе фізичне обмеження

Закон Гей-Люссака застосовний лише для замкнутого обʼєму газу.

Він незастосовний або обмежено застосовний, якщо:

вузол підключений до мережі;
тиск підтримується регулятором;
відкритий upstream/downstream;
тиск є надлишковим, а не абсолютним;
у паспорті вказано режим P_const;
обʼєм не ізольований;
датчик тиску округлює або фільтрує значення.

Каталог виявлюваних патернів

Таблиця методології. Усі девʼять ознак, які звіт уміє шукати, з їхньою формальною умовою, рівнем серйозності (low / medium / high / very_high) та клікабельною позначкою «спрацювало в цьому звіті». З таблиці одразу видно, які ознаки спрацювали на заданому вузлі, і можна перейти прямо до картки події.

Підміна P підставним значенням

Формальна умова:

Q \approx 0 \; for \; H \ge 6h

і:

\sigma_P < 0.1 \; kPa

і:

P_{mean} \in P_{default}

і:

\Delta T \ge 1^\circ C

Сенс: тиск стоїть на типовому підставному значенні під час тривалого періоду нульової витрати. Це може вказувати на підміну каналу тиску, але може бути і законним режимом P_const.

Зафіксований канал тиску P (порушення Гей-Люссака)

Формальна умова:

Q \approx 0 \; for \; H \ge 6h

\sigma_P < 0.1 \; kPa

\Delta T \ge 1^\circ C

і модель Гей-Люссака показує, що очікувана зміна тиску має бути помітною.

Сенс: температура змінюється, але тиск майже нерухомий. Це може вказувати на залиплий канал тиску, режим P_const, мережевий регулятор або підміну вимірювального каналу.

Синхронний стрибок Q+P після нульового періоду

Формальна умова:

Є нульовий період:

Q \approx 0 \; for \; H \ge 6h

і після його закінчення, у вікні:

\pm 2 \; hours

фіксується:

Q_{recovery} \ge 10 \; m³/h

і:

\Delta P_{recovery} \ge 20 \; kPa

Сенс: після тривалого нуля одночасно відновлюються і витрата, і тиск. Це може вказувати на повернення обліку після режимного перемикання, але також може бути нормальним технологічним запуском.

Діра в архіві за успішних сеансів звʼязку

Формальна умова:

Є пропуск у годинному архіві:

H_{gap} \ge 24h

і в цьому ж вікні були успішні сеанси звʼязку:

FailRatio < 30\%

Сенс: вузол виходив на звʼязок, але годинний архів не було доставлено або записано. Це більше схоже на проблему доставки, вивантаження, парсингу чи інтеграції, ніж на фізичний обхід обліку.

Занадто рівні Q і P (плато)

Формальна умова:

Період триває:

H \ge 24h

витрата ненульова:

\overline{Q} > 1 \; m³/h

витрата занадто рівна:

\frac{\sigma_Q}{\overline{Q}} < 0.02

тиск майже зафіксований:

\sigma_P < 1 \; kPa

Сенс: дуже рівна крива може бути нормальною для деяких технологічних процесів, але також може вказувати на синтетичний або заміщений профіль.

Нічне Q=0 за теплої температури

Формальна умова:

У нічні години:

02:00 \le hour \le 05:00

витрата дорівнює нулю:

Q \approx 0

температура вище порога:

T > 15^\circ C

і це відбувається не менше ніж у 5 ночах.

Сенс: слабка ознака. Для шкіл, офісів, сезонних обʼєктів і житлових будинків нічна нульова витрата може бути нормою.

Стрибки тиску без витрати

Формальна умова:

Не менше 3 випадків:

|\Delta P_h| \ge 30 \; kPa

за:

Q_h < 5 \; m³/h

Сенс: сильні стрибки тиску без відповідної витрати можуть вказувати на збій датчика, телеметричний артефакт або ручну правку каналу.

Тривала серія однакових значень Q

Формальна умова:

Витрата залишається ідентичною протягом:

H \ge 48h

з точністю:

|Q_i - Q_{run}| \le 0.001 \; m³/h

Сенс: природна витрата зазвичай має шум і варіативність. Тривала ідентичність може вказувати на константу, помилку передавання або вимкнений датчик витрати.

Відновлення лише в робочі години

Формальна умова:

Є не менше 3 подій відновлення, і частка відновлень у робочі години становить:

Share_{business} \ge 70\%

Робочі години:

09:00 \le hour < 17:00

і день тижня — будній.

Сенс: якщо відновлення обліку часто відбувається лише в робочі години, це може вказувати на ручне обслуговування, візити оператора або режимні дії. Але це не доказ втручання.

Попередні фільтри якості даних

Перед інтерпретацією патернів втручання звіт має виключити очевидні артефакти.

Фізично неможливий тиск

Якщо:

P > 500 \; kPa

для низько- або середньонапірного вузла, це може бути телеметричний артефакт.

Такі точки не повинні роздувати підозру.

Спайк витрати

Спайк витрати можна вважати артефактом, якщо:

Q_h > 20 \times median(Q)

і одночасно:

Q_h > 1000 \; m³/h

Така точка може бути скиданням лічильника, помилкою передавання або скиданням архіву.

Зламаний датчик P

Якщо канал тиску залип на:

H_{Pstuck} \ge 168h

то P-залежні детектори втручання мають бути вимкнені або позначені як недоказові.

Це означає:

text

Проблема: метрологічна надійність датчика P.
Не висновок: доказ обходу.

Мережевий вузол, де закон Гей-Люссака незастосовний

Якщо:

median(P) < 10 \; kPa

і:

\sigma_P < 2 \; kPa

і датчик не визнано зламаним, вузол може бути мережевим низьконапірним обʼєктом, де тиск утримується регулятором.

У такому разі GL-залежні ознаки мають бути знижені або виключені зі скорингу.

Рівні severity та ймовірнісні ваги

Кожній спрацьованій ознаці призначається рівень сили.

Severity	Імовірнісна вага `p_i`
info	0.00
low	0.10
medium	0.30
high	0.50
high_plus	0.65

Ці значення не є ймовірністю юридичного порушення. Це внутрішні ваги для комбінування незалежних ознак.

Композитний бал підозри

Чому не проста сума

Якщо просто скласти всі ознаки, вузол з великою кількістю слабких подій отримав би надмірно високий бал. Тому використовується мультиплікативна логіка незалежних сигналів.

Формула

Для кожної події береться вага p_i за її severity.

Імовірність того, що жодна ознака не вказує на підозру:

P_{none} = \prod_{i=1}^{n}(1 - p_i)

Тоді комбінована оцінка:

P_{combined} = 1 - \prod_{i=1}^{n}(1 - p_i)

Score:

SuspicionScore = 100 \times P_{combined}

або, розгорнуто:

SuspicionScore = 100 \times \left(1 - \prod_{i=1}^{n}(1 - p_i)\right)

Приклад

Припустимо, є дві події:

medium: p=0.30;
low: p=0.10.

Тоді:

P_{combined} = 1 - (1-0.30)(1-0.10)

P_{combined} = 1 - 0.70 \times 0.90 = 0.37

SuspicionScore = 37

Події, виключені з балу

Деякі події можуть відображатися у звіті, але не брати участі в балі:

інформаційні події;
події з незастосовною фізикою;
події, пригнічені quality gate;
мережеві GL-події;
події, пояснені зламаним датчиком.

Severity cap

Навіть якщо бал виходить високим, підсумковий текстовий рівень не має бути завищений, коли всі події слабкі.

Матриця обмеження

Склад подій	Максимальний рівень
є `high_plus`	very_high
є `high`	high
є 2 і більше `medium`	high
є 1 `medium`	medium
лише `low`	medium
лише `info`	low / no suspicion

Навіщо потрібен cap

Cap захищає звіт від ситуації, коли багато слабких подій створюють дуже високий математичний бал, тоді як доказова вага кожної події залишається низькою.

Приклад:

text

Score = 100
Але high/high_plus подій немає.
Підсумковий рівень: medium.

Event score — події пристрою

Звіт враховує не лише статистику Q/P/T, а й події пристрою.

Класи подій пристрою

Клас	Сенс
`physical`	фізичний доступ, розкриття корпусу, зміна часу, події доступу
`substitution`	ознаки підстановки або зміни вимірювального режиму
`metrology`	метрологічні відхилення
`system_error`	системні помилки приладу
`comm`	комунікаційні події
`other`	інші події

Чому event score може домінувати

Події пристрою можуть бути надійнішими за статистичну евристику. Наприклад:

розкриття корпусу;
зміна параметрів;
скидання;
скидання архіву;
зміна дати/часу;
доступ за паролем/default;
parameter_change.

Якщо такі події є, підсумковий бал може визначатися ними, навіть коли статистичний бал нижчий.

Важливе обмеження

Не кожна подія пристрою є прямим доказом втручання.

Наприклад:

метрологічні відхилення можуть бути штатними;
зведення позаштатних ситуацій потребують розшифрування;
повторювані RAISE/CLEAR треба групувати;
«витрата = 0» може бути нормальною експлуатацією.

Підсумковий бал та Root Cause Matrix

Підсумковий бал та матриця гіпотез. Блок показує, який із двох шарів (статистичний патерн чи event score) визначив підсумковий бал, і одразу дає root-cause matrix з альтернативними гіпотезами. Усі гіпотези, крім «обходу», перевіряються на виїзді. Фінальний root cause встановлюється лише після польового візиту та розшифрування журналу позаштатних ситуацій.

Підсумковий бал має враховувати обидва шари:

text

statistical pattern score
device event score

Один з принципів:

FinalScore = max(PatternScore, EventScore)

Якщо EventScore вищий, звіт має пояснити:

text

Підсумковий бал визначається прямими або класифікованими подіями пристрою.
Статистичний детектор дав менший бал.

Якщо PatternScore вищий, звіт має пояснити:

text

Підсумковий бал визначається повторюваним Q/P/T-патерном.
Прямих сигналів пристрою недостатньо.

Evidence confidence

Evidence confidence показує не силу підозри, а повноту доказової бази.

Формула

Використовується карта джерел:

Джерело	Вага
Hourly archive	3
Sessions	2
Device events	3
Passport	1
Field visit	3

Статус джерела:

s_i = \begin{cases} 1, & ok \\ 0.5, & partial \\ 0, & missing \end{cases}

Загальний відсоток:

EvidenceConfidencePct = \frac{\sum w_i s_i}{\sum w_i} \times 100\%

Рівні

Відсоток	Рівень
≥ 70%	high
35–70%	medium
< 35%	low

Важлива інтерпретація

Suspicion score відповідає: наскільки сильний патерн.
Evidence confidence відповідає: чи вистачає джерел для впевненого висновку.
Legal readiness відповідає: чи можна робити юридично значущий висновок.

Це три різні шкали, і одна не виводиться з іншої.

Зведення для розслідування: сім шкал

Зведення для розслідування. Одразу під шапкою звіту — сім індикаторів, які читаються разом, а не окремо. Наприклад, Pattern Score = 100 за Evidence Confidence = 58% і Confirmed Tampering = «—» означає: математично вузол виглядає дуже підозрілим, але доказів для акта поки недостатньо — потрібен виїзд.

Кожна з семи шкал має свій сенс, свою формулу та свої джерела:

Шкала	Що показує	Джерело
Pattern Suspicion	сила математичних ознак	годинний архів
Evidence Confidence	повнота доказової бази	карта джерел
Confirmed Tampering	факт втручання (юридично)	польовий акт + hard events
Legal Readiness	готовність до юридичної дії	confidence + hard events
Field Priority	терміновість виїзду	score + confidence + recency
Metrology Reliability	надійність фізичних передумов	паспорт + датчики
Data Integrity Risk	цілісність джерел	архіви + sessions

Legal readiness

Legal readiness — це оцінка того, чи готовий висновок до юридично значущої дії.

Можливі статуси

Статус	Значення
`not_ready`	недостатньо доказів
`partial`	є сильні ознаки, але потрібні підтвердження
`ready`	достатньо доказів для акта або формальної дії

Умови `not_ready`

text

лише статистичні патерни
і немає польового візиту
і немає hard device evidence
і паспорт неповний

Умови `partial`

text

є substitution events
або висока evidence confidence
або є польовий візит, але частини джерел не вистачає

Умови `ready`

ready можливий лише за достатньої доказової бази. Приклади:

hard physical event у журналі пристрою;
підтверджене розкриття корпусу;
підтверджена зміна параметрів;
польовий візит + події пристрою;
актова фотофіксація;
доведений незаконний P_const / parameter_change.

Field priority

Field priority визначає терміновість виїзду.

Можливі рівні

Пріоритет	Значення
`P0`	терміново, сьогодні / 24–48 годин
`P1`	виїзд протягом тижня
`P2`	планова перевірка
`P3`	спостереження

Матриця

Умова	Пріоритет
physical event за останні 7 діб	P0
physical event старше 7 діб	P1
score ≥ 70 і confidence medium/high	P0
score ≥ 70 і confidence low	P1
score 50–70	P1
score 30–50	P2
score < 30	P3

Чому score 100 може бути P1

Якщо бал високий, але:

подій мало;
немає high / high_plus;
confidence середня;
немає польового візиту;
паспорт неповний;
немає hard evidence;

то виїзд може бути P1, а не P0.

Metrology reliability

Метрологічна надійність показує, наскільки коректні фізичні та метрологічні передумови.

Що знижує надійність

паспорт не підтверджено;
P_const невідомий;
невідома ціна імпульсу;
невідомі Qmin/Qmax;
P≈100 kPa повторюється без пояснення;
канал P залипає;
канал T залипає;
тип тиску невідомий: абсолютний чи надлишковий;
закон Гей-Люссака застосовується до незамкнутого мережевого вузла.

Рівні

Рівень	Значення
high	паспорт і канали підтверджено, суттєвих метрологічних обмежень немає
medium	є прогалини паспорта або поодинокі аномалії
low	фізична модель незастосовна або датчики явно деградовані

Data integrity risk

Data integrity risk показує, наскільки повні дані розслідування.

Що підвищує ризик

частковий архів сеансів;
відсутній журнал подій пристрою;
неповний годинний архів;
пропуски з успішними сеансами;
суперечності між джерелами;
timestamp з майбутнього;
неповне розшифрування подій;
raw logs недоступні.

Рівні

Рівень	Умова
low	джерела повні та узгоджені
medium	частина джерел partial/missing
high	є події цілісності даних або серйозні суперечності

Root Cause Matrix — типові гіпотези

Root Cause Matrix існує для того, щоб звіт не зводився до єдиного звинувачення.

Типові гіпотези

Гіпотеза	Що може підтверджувати	Що може спростовувати
Законний `P_const`	P близько до default, паспорт допускає режим	паспорт не підтверджує `P_const`
Датчик P завис	низьке `std(P)`, повторюваність	P змінюється нормально поза вікном
Обхід обліку	Q=0 + P default + recovery + hard evidence	немає польового доказу, немає device evidence
Плановий простій	Q=0 у робочому режимі обʼєкта	`P_default` / recovery нетипові
Помилка архіву / парсера	пропуски, повторювані патерни, sessions mismatch	raw device logs підтверджують реальність
Downstream-клапан закритий	Q=0 за робочого P	немає підтвердження положення крана
Мережевий регулятор	P стабільний за низького тиску	обʼєкт не є мережевим вузлом
Сезонна зупинка	профіль обʼєкта допускає простій	споживання мало бути за договором

Статуси гіпотез

Статус	Значення
`not_checked`	не перевірено
`possible`	можливо
`unlikely`	малоймовірно
`likely`	ймовірно
`confirmed`	підтверджено

Фінальний root cause встановлюється лише після польового візиту та розшифрування журналу позаштатних ситуацій.

Оцінка потенційного exposure-обʼєму

Оцінка потенційного exposure-обʼєму. Не обʼєм викрадення, а оцінка масштабу для пріоритизації перевірки. Три цифри (low / expected / high) утворюють діапазон ±30% навколо очікуваного значення. Baseline рахується як медіана ненульових витрат для тієї ж години тижня поза подіями. Без польового огляду всі цифри залишаються евристикою.

Exposure — це розрахунок масштабу потенційно неврахованого споживання у підозрілих вікнах.

Baseline

Для кожної години будується baseline за історичними не-подієвими даними.

Використовується медіана ненульових витрат для тієї ж комбінації:

text

година доби + день тижня

Формула:

Baseline_{h,d} = median(Q \; | \; hour=h,\; weekday=d,\; Q>0,\; outside\; events)

Exposure для години

Для кожної години підозрілого вікна:

Exposure_t = max(0, Baseline_t - Q_t)

Обмеження зверху

Щоб не завищити оцінку, годинний exposure обмежується історичним P95:

Exposure_t = min(Exposure_t, Q_{P95})

Якщо відомий Qmax, обмеження можна посилити:

Exposure_t = min(Exposure_t, Q_{P95}, Q_{max})

Дедуплікація

Якщо підозрілі вікна перетинаються, одна й та сама година враховується лише один раз:

SuspiciousHours = unique(hours \; inside \; all \; suspicious \; windows)

Загальний очікуваний exposure

Exposure_{expected} = \sum_{t \in SuspiciousHours} Exposure_t

Діапазон невизначеності

Для орієнтовного діапазону використовується ±30%:

Exposure_{low} = 0.7 \times Exposure_{expected}

Exposure_{high} = 1.3 \times Exposure_{expected}

Доказова вага exposure

Exposure має низьку або середню доказову вагу, поки немає:

польового візиту;
показів зовнішнього лічильника;
підтвердження режиму обʼєкта;
підтвердження, що Q дійсно мав бути >0;
перевірки паспортних параметрів.

Кореляція з архівом позаштатних ситуацій

Події за групами. Кожне вікно підозрілого патерну розгортається у повну картку: детальні значення, кореляція з журналом позаштатних ситуацій (події пристрою у вікні ±24h), перелік альтернативних гіпотез і годинний архів цього вікна. Сильна кореляція (parameter_change / reset у вікні) — кандидат на hard evidence.

Кореляція показує, чи є події пристрою поруч із підозрілим вікном.

Вікно кореляції

Для кожної події використовується вікно:

[event\_start - 24h,\; event\_end + 24h]

Що вважається збігом

Збігом вважається будь-яка подія пристрою, що потрапила всередину вікна.

Приклади:

зведення позаштатних ситуацій;
поодинока позаштатна ситуація;
parameter_change — зміна параметра приладу;
reset — скидання;
cover_open — розкриття корпусу;
clock_change — зміна часу;
archive_reset — скидання архіву.

Інтерпретація

Результат	Значення
немає збігів	журнал пристрою не підтверджує вікно
лише зведення	слабка кореляція
`parameter_change` / `reset`	сильна кореляція
`cover` / `magnet` / `physical`	кандидат на hard evidence
журнал порожній	підтвердження неможливе

AI-коментарі

AI-коментарі. Допоміжний текст для оператора: один блок пояснює події пристрою, інший формулює методологічне зведення. Дисклеймер зверху підкреслює, що AI не бере участі у скорингу і не підміняє польовий огляд.

AI-коментарі є допоміжним текстом.

Що AI може робити

стисло пояснити проблему;
перелічити головні ризики;
сформулювати гіпотези;
запропонувати порядок перевірок;
зробити зрозумілий висновок для оператора.

Чого AI робити не може

AI не може:

змінити score;
змінити legal readiness;
підтвердити втручання;
замінити журнал пристрою;
замінити паспорт;
замінити польовий візит;
створити доказ.

Обовʼязковий дисклеймер

text

AI-коментар не бере участі в розрахунку Legal Readiness, Evidence Confidence чи Pattern Score і не є частиною доказової бази.

Чек-лист огляду для виїзної бригади

Чек-лист виїзду. Мінімальний набір фото та вимірювань, потрібних для складання акта. Друкується або відкривається на планшеті перед виїздом. Привʼязаний до виявлених ознак: якщо спрацював патерн P_default — обовʼязковий пункт про режим P_const; якщо спрацював патерн діри в архіві — обовʼязковий пункт про журнал позаштатних ситуацій.

Чек-лист має бути привʼязаний до виявлених ознак.

Загальні пункти

пломби лічильника;
пломби коректора;
імпульсний кабель / reed / encoder;
датчик тиску;
датчик температури;
байпасна лінія;
положення кранів до і після лічильника;
режим P_const;
журнал позаштатних ситуацій;
накопичений обʼєм на лічильнику і коректорі;
фото дисплея коректора;
схема трубопроводу;
договірний режим обʼєкта.

Обовʼязкові фото

дисплей коректора: Q, P, T, V;
дата і час коректора;
режим P_const;
серійний номер лічильника;
серійний номер коректора;
пломби;
датчик P;
датчик T;
імпульсний кабель;
байпас і крани;
загальний вигляд вузла.

Що виміряти

фактичний тиск еталонним манометром;
фактичну температуру;
накопичений обʼєм;
покази зовнішнього лічильника;
наявність імпульсів;
стан живлення;
параметри звʼязку;
Qmin/Qmax за паспортом;
ціну імпульсу.

Графік Q/P та підозрілі вікна

Графік Q/P. Основна візуалізація. Синя лінія — годинна витрата, помаранчева — тиск. Червоні та жовті штрихові зони відмічають вікна спрацьованих патернів: при наведенні показуються точні значення години. Подвійний графік дозволяє бачити весь період цілком і не пропустити довгострокові тренди.

Tooltip графіка. При наведенні на будь-яку точку відображаються точні годинні значення Q і P. Це потрібно для перевірки гіпотез: наприклад, щоб дізнатися значення тиску всередині підозрілого вікна або порівняти витрату з baseline.

Що шукати на графіку

довгі горизонтальні ділянки P (плато → P_stuck);
провали Q в нуль (нульові періоди);
одночасні стрибки Q і P (recovery);
стрибки тиску без витрати;
ідеально рівну Q за ненульового середнього (синтетичний профіль);
розриви в часі (пропуск в архіві).

Що не можна інтерпретувати самостійно

поодинокий нульовий час;
одноразовий спайк P;
будь-яку аномалію без перевірки журналу позаштатних ситуацій і паспорта.

Зведення по вузлу та розподіл за годинами

Зведення по вузлу. Один погляд на «сиру фактуру»: скільки подій, наскільки різноманітні ознаки, сумарна тривалість, покриття періоду. Гістограма «коли починалися» корисна для виявлення режимних патернів: події лише вночі або лише в робочі години діагностично важливі (див. патерн «відновлення лише в робочі години»).

Метрики зведення

Метрика	Що показує
Усього подій	загальна кількість виявлених патернів
Унікальних типів	скільки різних детекторів спрацювало
Тривалість	сумарна тривалість усіх вікон (з дедуплікацією)
Покриття	частка періоду, зайнята підозрілими вікнами
Рівні	розбивка за `low`/`medium`/`high`/`high_plus`
Найсерйозніше	назва і severity найсильнішої ознаки

Розподіл за годинами

Гістограма «коли починалися» використовує кольорове кодування:

ніч (00–05) — синій;
ранок (06–08) — блакитний;
день (09–17) — помаранчевий;
вечір (18–23) — фіолетовий.

Концентрація в одному кольорі — сильний діагностичний сигнал (наприклад, усі події в робочі години → ручне обслуговування).

Top-5 вікон для польового огляду

Top-5 вікон для бригади. Якщо бригада обмежена часом — починайте з цих 5 вікон. Повний перелік доступний нижче в розділі «всі події за групами». Колонка «що перевірити» автоматично збирається зі спрацьованих ознак: для zero_flow_p_default це режим P_const, для gap_with_clean_sessions — журнал позаштатних ситуацій і перевірка парсера архіву.

Алгоритм відбору Top-5

text

1. відфільтрувати події з severity >= medium
2. відсортувати за weight (high_plus > high > medium > low)
3. всередині кожного weight — за часом спадання
4. залишити перші 5
5. зібрати об'єднання checklist за спрацьованими ознаками

Колонка «що перевірити»

Спрацьована ознака	Обовʼязкові пункти
`zero_flow_p_default`	пломби, паспорт `P_const`, журнал позаштатних ситуацій
`zero_flow_p_stuck`	датчик P, паспорт, фото дисплея
`zero_flow_recovery`	положення кранів, позаштатні ситуації, час відновлення
`gap_with_clean_sessions`	архів сеансів, парсер, raw logs
`plateau_q_p`	імпульсний кабель, encoder, паспорт `Qmin/Qmax`

Як читати верхній блок

Pattern suspicion

Відповідає на запитання:

Наскільки сильні математичні ознаки підозри?

Не відповідає на запитання:

Чи доведено втручання?

Evidence confidence

Відповідає на запитання:

Наскільки повна доказова база?

Не дорівнює suspicion score.

Confirmed tampering

Має залишатися NOT CONFIRMED, якщо немає hard evidence або польового акта.

Legal readiness

Показує, чи можна переходити до юридично значущої дії.

Field priority

Показує, наскільки терміново потрібен виїзд.

Metrology reliability

Показує, чи можна довіряти фізичним і метрологічним передумовам.

Data integrity risk

Показує, наскільки повні та узгоджені джерела даних.

Типові помилки інтерпретації

Помилка: score 100 = доказ

Невірно. Score 100 може бути результатом сильного статистичного патерну або event score. Доказ потребує джерел.

Помилка: P=100 kPa = незаконна підміна

Невірно. Це може бути P_const або default-значення, дозволене паспортом.

Помилка: Гей-Люссак порушено = втручання

Невірно. Модель застосовна лише до замкнутого обʼєму.

Помилка: Q=0 за P>0 = обхід

Невірно. Може бути простій, закритий клапан або технологічний режим.

Помилка: exposure = шкода

Невірно. Exposure — це оцінка масштабу для перевірки.

Помилка: AI написав «підозра» = доведено

Невірно. AI-коментар — лише пояснення.

Помилка: «не спрацювало» = «немає проблеми»

Невірно. Ознака могла бути пригнічена quality gate, вимкнена через залиплий датчик або просто незастосовна до типу вузла. Уважно читайте розділ обмежень.

Мінімальні критерії повноцінного звіту

Звіт вважається методично повним, якщо містить:

період аналізу;
картку вузла;
pattern suspicion score;
evidence confidence;
статус confirmed tampering;
legal readiness;
field priority;
карту джерел даних;
перелік виявлених патернів;
формальну умову кожного патерну;
логіку severity і cap;
event score або пояснення його відсутності;
root cause matrix;
exposure estimate;
кореляцію з подіями пристрою;
AI-дисклеймер;
чек-лист виїзду;
методологію з формулами та порогами;
зазначення обмежень і альтернативних гіпотез.

Повʼязані звіти

Обхід обліку (парк) — та сама оцінка по всьому парку одразу, без блоків для розгляду.
Підозрілі вузли — головний парковий інструмент виявлення обходу.
Аналітика споживання — загальний розбір вузла з журналом подій; рекомендується запускати перед або разом із цим звітом.
Паспортний аудит — перевірка повноти паспортних даних, без яких legal readiness не може бути ready.

Пов'язані теми

Останнє оновлення 26 червня 2026 р.

Чи була ця сторінка корисною?

Обхід обліку (вузол)

Призначення звіту

Цільова аудиторія

Чого звіт робити НЕ повинен

Основні терміни

Загальна логіка звіту

Вхідні дані

Обовʼязкові дані

Бажані дані

Мінімальний надійний період

Карта доказів

Формула доказовості джерел

Інтерпретація evidence confidence

Нульовий період витрати

Near-zero поріг

Мінімальна тривалість

Чому саме 6 годин

Підставний тиск P_default

Підставні значення

Допуск

Формула близькості

Важливе обмеження

Зафіксований канал тиску P_stuck

Стандартне відхилення тиску

Зміна температури

Перевірка за законом Гей-Люссака

Фізична формула

Порівняння з фактичною зміною

Коефіцієнт розбіжності

Важливе фізичне обмеження

Каталог виявлюваних патернів

Підміна P підставним значенням

Зафіксований канал тиску P (порушення Гей-Люссака)

Синхронний стрибок Q+P після нульового періоду

Діра в архіві за успішних сеансів звʼязку

Занадто рівні Q і P (плато)

Нічне Q=0 за теплої температури

Стрибки тиску без витрати

Тривала серія однакових значень Q

Відновлення лише в робочі години

Попередні фільтри якості даних

Фізично неможливий тиск

Спайк витрати

Зламаний датчик P

Мережевий вузол, де закон Гей-Люссака незастосовний

Рівні severity та ймовірнісні ваги

Композитний бал підозри

Чому не проста сума

Формула

Приклад

Події, виключені з балу

Severity cap

Матриця обмеження

Навіщо потрібен cap

Event score — події пристрою

Класи подій пристрою

Чому event score може домінувати

Важливе обмеження

Підсумковий бал та Root Cause Matrix

Evidence confidence

Формула

Рівні

Важлива інтерпретація

Зведення для розслідування: сім шкал

Legal readiness

Можливі статуси

Умови not_ready

Умови partial

Умови ready

Field priority

Можливі рівні

Матриця

Чому score 100 може бути P1

Metrology reliability

Що знижує надійність

Рівні

Data integrity risk

Що підвищує ризик

Рівні

Root Cause Matrix — типові гіпотези

Умови `not_ready`

Умови `partial`

Умови `ready`