--- 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`, применимость физической модели, паспортные пробелы | | Инженер по телеметрии | связь с архивом сеансов, полноту источников, подозрительные пропуски | | Выездная бригада | топовые окна для проверки и чек-лист осмотра | | Служба контроля | список подозрительных паттернов, событий устройства и альтернативных гипотез | | Биллинг-аналитик | ориентировочный объём exposure как масштаб потенциального «слепого пятна» | | Юрист энергоснабжающей организации | базу для подготовки акта при подтверждённых hard evidence | ## Что отчёт не должен делать Отчёт не должен: - автоматически обвинять потребителя в обходе учёта; - называть расчётный exposure подтверждённым ущербом; - трактовать нулевой расход как нарушение без проверки эксплуатационного режима; - считать залипший датчик доказательством tampering; - применять закон Gay-Lussac без проверки физической применимости; - считать `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 дней (год даёт сезонность для всех паттернов). ## Карта доказательств

_Карта доказательств._ Какие источники данных использованы для скоринга и насколько они полны. Чем больше зелёных «ОК», тем выше уверенность доказательств. Каждый источник имеет вес в формуле 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`. ## Проверка по закону Gay-Lussac ### Физическая формула Для замкнутого объёма газа при постоянном количестве вещества: $$ \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` велик, отчёт пишет, что ожидаемое изменение давления во много раз больше фактической вариативности. ### Важное физическое ограничение Закон Gay-Lussac применим только к **замкнутому объёму газа**. Он неприменим или ограниченно применим, если: - узел подключён к сети; - давление поддерживается регулятором; - открыт upstream/downstream; - давление является избыточным, а не абсолютным; - в паспорте указан режим `P_const`; - объём не изолирован; - датчик давления округляет или фильтрует значения. Нарушение модели Gay-Lussac не является самостоятельным доказательством вмешательства. Это физическая эвристика, применимость которой нужно проверять. ## Каталог обнаруживаемых паттернов

_Таблица методологии._ Все девять признаков, которые отчёт умеет искать, со своим формальным условием, уровнем серьёзности (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 (нарушение Gay-Lussac) Формальное условие: $$ Q \approx 0 \; for \; H \ge 6h $$ $$ \sigma_P < 0.1 \; kPa $$ $$ \Delta T \ge 1^\circ C $$ и модель Gay-Lussac показывает, что ожидаемое изменение давления должно быть заметным. Смысл: температура меняется, но давление почти неподвижно. Это может указывать на залипший канал давления, режим `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. Не вывод: доказательство обхода. ``` ### Сетевой узел, где Gay-Lussac неприменим Если: $$ 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 $$ ### События, исключённые из score Некоторые события могут отображаться в отчёте, но не участвовать в score: - информационные события; - события с неприменимой физикой; - события, подавленные quality gate; - сетевые GL-события; - события, объяснённые сломанным датчиком. ## Severity cap Даже если score получается высоким, итоговый текстовый уровень не должен быть завышен, когда все события слабые. ### Матрица cap | Состав событий | Максимальный уровень | | ----------------------- | -------------------- | | есть `high_plus` | very_high | | есть `high` | high | | есть 2 и более `medium` | high | | есть 1 `medium` | medium | | только `low` | medium | | только `info` | low / no suspicion | ### Зачем нужен cap Cap защищает отчёт от ситуации, когда много слабых событий создают очень высокий математический score, но доказательность каждого события остаётся низкой. Пример: ```text Score = 100 Но high/high_plus событий нет. Итоговый уровень: medium. ``` ## Event score — события устройства Отчёт учитывает не только статистику Q/P/T, но и события устройства. ### Классы событий устройства | Класс | Смысл | | -------------- | ----------------------------------------------------------------------- | | `physical` | физический доступ, вскрытие корпуса, изменение времени, события доступа | | `substitution` | признаки подстановки или изменения измерительного режима | | `metrology` | метрологические отклонения | | `system_error` | системные ошибки прибора | | `comm` | коммуникационные события | | `other` | прочие события | ### Почему event score может доминировать События устройства могут быть надёжнее статистических эвристик. Например: - вскрытие корпуса; - изменение параметров; - сброс; - сброс архива; - изменение даты/времени; - доступ по паролю/умолчанию; - parameter_change. Если такие события есть, итоговый score может определяться ими, даже когда статистический score ниже. ### Важное ограничение Не каждое событие устройства является прямым доказательством вмешательства. Например: - метрологические отклонения могут быть штатными; - сводки нештатных ситуаций требуют расшифровки; - повторяющиеся RAISE/CLEAR нужно группировать; - «расход = 0» может быть нормальной эксплуатацией. ## Итоговый score и Root Cause Matrix

_Финальный score и матрица гипотез._ Блок показывает, какой из двух слоёв (статистический паттерн или event score) определил итоговый балл, и сразу даёт root cause matrix с альтернативными гипотезами. Все гипотезы, кроме «обхода», проверяются на выезде. Финальный root cause устанавливается только после выезда и расшифровки журнала нештатных ситуаций. Итоговый score должен учитывать оба слоя: ```text statistical pattern score device event score ``` Один из принципов: $$ FinalScore = max(PatternScore, EventScore) $$ Если `EventScore` выше, отчёт должен объяснить: ```text Финальный score определяется прямыми/классифицированными событиями устройства. Статистический детектор дал меньший score. ``` Если `PatternScore` выше, отчёт должен объяснить: ```text Финальный score определяется повторяемым 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 | сила математических признаков | hourly archive | | Evidence Confidence | полнота доказательной базы | карта источников | | Confirmed Tampering | факт вмешательства (юридический) | field act + 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 только статистические паттерны и нет field visit и нет hard device evidence и паспорт неполный ``` ### Условия `partial` ```text есть substitution events или высокая evidence confidence или есть field visit, но не хватает части источников ``` ### Условия `ready` `ready` возможен только при наличии достаточной доказательной базы. Примеры: - hard physical event из журнала устройства; - подтверждённое вскрытие корпуса; - подтверждённое изменение параметров; - field visit + device events; - актовая фотофиксация; - доказанный незаконный `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 Если score высокий, но: - событий мало; - нет `high` / `high_plus`; - confidence средняя; - нет field visit; - паспорт неполный; - нет hard evidence; то выезд может быть `P1`, а не `P0`. ## Metrology reliability Metrology reliability показывает, насколько корректны физические и метрологические предпосылки. ### Что снижает надёжность - паспорт не подтверждён; - `P_const` неизвестен; - неизвестна цена импульса; - неизвестны `Qmin/Qmax`; - `P≈100 kPa` повторяется без объяснения; - канал P залипает; - канал T залипает; - тип давления неизвестен: абсолютное или избыточное; - Gay-Lussac применяется к незамкнутому сетевому узлу. ### Уровни | Уровень | Значение | | ------- | --------------------------------------------------------------------------- | | 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 | нет field proof, нет 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 имеет низкую или среднюю доказательность, пока нет: - field visit; - показаний внешнего счётчика; - подтверждения режима объекта; - подтверждения, что Q действительно должен был быть >0; - проверки паспортных параметров. ## Корреляция с архивом нештатных ситуаций

_События по группам._ Каждое окно подозрительного паттерна разворачивается в полную карточку: детальные значения, корреляцию с журналом нештатных ситуаций (события устройства в окне ±24ч), список альтернативных гипотез и часовой архив этого окна. Сильная корреляция (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; - подтвердить вмешательство; - заменить журнал устройства; - заменить паспорт; - заменить field visit; - создать доказательство. ### Обязательный дисклеймер ```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` или значение по умолчанию, разрешённое паспортом. ### Ошибка: Gay-Lussac нарушен = вмешательство Неверно. Модель применима только к замкнутому объёму. ### Ошибка: Q=0 при P>0 = обход Неверно. Может быть простой, закрытый клапан или технологический режим. ### Ошибка: exposure = ущерб Неверно. Exposure — оценка масштаба для проверки. ### Ошибка: AI написал «подозрение» = доказано Неверно. AI-комментарий — только пояснение. ### Ошибка: «не сработало» = «нет проблемы» Неверно. Признак мог быть подавлен quality gate, отключён из-за залипшего датчика или просто неприменим к типу узла. Внимательно читайте раздел ограничений. ## Минимальные критерии полноценного отчёта Отчёт считается методически полным, если содержит: - период анализа; - карточку узла; - pattern suspicion score; - evidence confidence; - confirmed tampering status; - legal readiness; - field priority; - карту источников данных; - список найденных паттернов; - формальное условие каждого паттерна; - severity и cap-логику; - event score или объяснение его отсутствия; - root cause matrix; - exposure estimate; - корреляцию с device events; - AI-дисклеймер; - чек-лист выезда; - методологию с формулами и порогами; - указание ограничений и альтернативных гипотез. ## Рекомендуемая формулировка итогового вывода Корректный итоговый вывод должен быть нейтральным: ```text На узле обнаружены признаки, требующие проверки: длительные периоды Q≈0, зафиксированный канал давления и/или совпадения с событиями устройства. Это не является самостоятельным доказательством вмешательства. Для финального вывода требуется проверка паспортного P_const, журнала нештатных ситуаций, пломб, импульсного кабеля, показаний корректора и фактической схемы узла. ``` Если доказательность высокая: ```text Наличие прямых событий устройства повышает доказательность, но окончательная квалификация должна учитывать расшифровку кодов, паспортные параметры и результаты полевого осмотра. ``` Если доказательность низкая: ```text Обнаруженные признаки имеют эвристический характер и используются только для планирования проверки. ``` ## Связанные отчёты - **[Обход учёта (парк)](/ru/platform/v3/ai-analytics/fleet-reports/metering-bypass-fleet)** — та же оценка по всему парку сразу, без блоков для разбирательства. - **[Подозрительные узлы](/ru/platform/v3/ai-analytics/fleet-reports/suspicious-nodes)** — главный парковый инструмент выявления обхода. - **[Аналитика потребления](/ru/platform/v3/ai-analytics/node-reports/consumption-analytics)** — общий разбор узла с журналом событий; рекомендуется запускать перед или вместе с этим отчётом. - **[Паспортный аудит](/ru/platform/v3/ai-analytics/fleet-reports/passport-audit)** — проверка полноты паспортных данных, без которой legal readiness не может быть `ready`.