--- title: 'Обхід обліку (вузол)' description: Скоринг підозри на обхід обліку для одного вузла (0–100) з патернами, формулами, доказовістю, юридичною готовністю та чек-листом виїзної перевірки. section: AI Analytics weight: 7 related: - ai-analytics/fleet-reports/suspicious-nodes - ai-analytics/node-reports/consumption-analytics - ai-analytics/fleet-reports/metering-bypass-fleet --- import Alert from '@/components/docs/Alert.astro'; import Image from '@/components/docs/Image.astro'; Звіт **Обхід обліку** виконує формалізований аналіз **одного вузла обліку** за вибраний період з метою виявлення ознак можливого недообліку, підміни вимірювального каналу, некоректної роботи датчиків або інших подій, що потребують уваги служби обліку. Він спирається на ті самі стандарти, що регулюють облік газу: 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 → чек-лист виїзду ``` Принципово важливо, що звіт відокремлює: 1. **статистичний патерн** у годинному архіві; 2. **подію пристрою** в журналі коректора; 3. **доказовість джерел**; 4. **юридичну готовність**; 5. **польову перевірку**. Кожен із пʼяти шарів оцінюється незалежно. Високий бал за одним з них не підвищує готовність до дії за іншим. Наприклад, 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 | Навіть `high evidence confidence` не означає автоматичного підтвердження втручання. Це лише означає, що джерел достатньо для більш упевненого розслідування. ## Нульовий період витрати Більшість ознак звіту починається з пошуку періодів, де витрата близька до нуля. ### 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`. Legal readiness не має ставати `ready` лише через високий pattern score. За відсутності hard evidence і польового візиту статус має залишатися `not_ready` або максимум `partial`. ## 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 — це розрахунок масштабу потенційно неврахованого споживання у підозрілих вікнах. 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-дисклеймер; - чек-лист виїзду; - методологію з формулами та порогами; - зазначення обмежень і альтернативних гіпотез. ## Рекомендоване формулювання підсумкового висновку Коректний підсумковий висновок має бути нейтральним: ```text На вузлі виявлено ознаки, що потребують перевірки: тривалі періоди Q≈0, зафіксований канал тиску та/або збіги з подіями пристрою. Це не є самостійним доказом втручання. Для фінального висновку потрібна перевірка паспорта P_const, журналу позаштатних ситуацій, пломб, імпульсного кабелю, показів коректора і фактичної схеми вузла. ``` Якщо доказовість висока: ```text Наявність прямих подій пристрою підвищує доказову вагу, але остаточна кваліфікація має враховувати розшифрування кодів, паспортні параметри і результати польового огляду. ``` Якщо доказовість низька: ```text Виявлені ознаки мають евристичний характер і використовуються лише для планування перевірки. ``` ## Повʼязані звіти - **[Обхід обліку (парк)](/ua/platform/v3/ai-analytics/fleet-reports/metering-bypass-fleet)** — та сама оцінка по всьому парку одразу, без блоків для розгляду. - **[Підозрілі вузли](/ua/platform/v3/ai-analytics/fleet-reports/suspicious-nodes)** — головний парковий інструмент виявлення обходу. - **[Аналітика споживання](/ua/platform/v3/ai-analytics/node-reports/consumption-analytics)** — загальний розбір вузла з журналом подій; рекомендується запускати перед або разом із цим звітом. - **[Паспортний аудит](/ua/platform/v3/ai-analytics/fleet-reports/passport-audit)** — перевірка повноти паспортних даних, без яких legal readiness не може бути `ready`.