Верификация тревог по видео: как убрать пустые выезды

Верификация тревоги — это процедура, при которой сигнал от датчика (охранного извещателя, детектора аналитики, радара) до принятия решения сопоставляется с видео из той же зоны за секунды до и после события. Оператор видит причину: человек, животное, ветка, фары в дождь. Сокращается при этом не поток тревог, а поток реакций на них — выездов, звонков, эскалаций.

Разделять эти две величины принципиально важно, иначе ожидания от системы не совпадут с результатом. Датчик как срабатывал от кошки, так и будет срабатывать: физика его чувствительного элемента от установки камеры не меняется. Меняется то, что происходит после сигнала — вместо автоматической отправки группы включается 20–40 секунд просмотра. В whitepaper «Perimeter protection with intelligent surveillance» Axis формулирует функцию видео прямо: оно позволяет не только подтвердить проникновение, но и установить причину тревоги. Без такой возможности причину устанавливают единственным доступным способом — выездом на объект.

Есть и второй, более слабый эффект — уменьшение самого числа событий, доходящих до оператора. Он возникает, когда детектирование ведёт видеоаналитика с классификацией объектов и фильтрацией по типу «человек / транспорт»: часть шумовых событий отсеивается на камере и до пульта не доходит. Но это уже не верификация, а настройка детектора, и работает она только при выполнении геометрических условий из раздела ниже.

Источников ровно три, и лечатся они разными средствами: среда (погода, животные, растительность, свет), техника (неверная установка, разъюстировка, помехи, износ) и человек (ошибки постановки и снятия с охраны, неверные зоны, отсутствие регламента). Верификация видео закрывает только последствия первых двух — причину она не устраняет.

По среде Axis в том же whitepaper перечисляет типичные триггеры ложных положительных срабатываний: животные, движущаяся растительность и деревья, тяжёлые погодные условия. В руководстве AXIS Object Analytics список конкретнее — туман, прямой свет в объектив, недостаточная освещённость, шумное изображение, частично перекрытые объекты, насекомые на стекле, фары автомобиля в сильный дождь, объекты размером с животное и резкие тени от яркого света.

По человеческому фактору отраслевой ответ давно оформлен стандартом: ANSI/SIA CP-01 «Control Panel Standard — Features for False Alarm Reduction» описывает функции приборов приёмно-контрольных, снижающие ложные тревоги от ошибок пользователя (задержки на вход и выход, отмена передачи сигнала, ограничение повторных передач). Это международный отраслевой стандарт, а не требование законодательства Казахстана, но логика применима: часть шума убирается настройкой прибора, а не камерами.

Отдельно отметим смежный контур — пожарную автоматику. Там природа ложных сработок иная (запылённость, влажность, некорректный тип извещателя, отсутствие обслуживания), и мы разбирали её в материале о том, почему пожарная сигнализация даёт ложные сработки. Переносить на неё логику видеоверификации нельзя — почему, объясняем ниже.

Для верификации нужен не «хороший обзор», а измеримая плотность пикселей в точке тревоги. Минимум для ответа «человек или животное» — уровень обнаружения 50 пикс/м. Для ответа «что за человек и что он делает» — 150 пикс/м (узнавание). Для описания признаков и работы с материалом дальше — 250 пикс/м (идентификация). Эти три значения задаёт Приложение 2 к Правилам НСВМ.

Ширина кадра считается по формуле ширина кадра (м) = разрешение по горизонтали / требуемая плотность. Разрешение по горизонтали: 2 Мп = 1920, 4 Мп = 2688, 8 Мп = 3840 пикселей.

Читать таблицу нужно как максимальную ширину сцены, на которой заявленная плотность ещё выдерживается. Практический вывод: обзорная камера с шириной кадра 50 м годится для ответа «кто-то есть», но не для ответа «это наш электрик» — для второго нужна отдельная позиция.

Если верификацию ведёт не человек, а детектор аналитики, порог задаётся иначе — через долю объекта в кадре. В руководстве AXIS Object Analytics минимальная высота человека — 4 % высоты изображения, рекомендуемая — 8 % (для транспорта 3 % и 6 %), а объект должен двигаться в сцене не менее двух секунд. Пересчитаем: при высоте потока 1080 пикселей 8 % — это 1080 × 0,08 = 86,4 ≈ 86 пикселей на фигуру; для человека ростом 1,7 м получаем 86,4 / 1,7 = 50,8 ≈ 51 пикс/м. То есть рекомендованный порог детектора почти совпадает с нижней ступенью 50 пикс/м из нормы — совпадение удобное, и именно от него мы отсчитываем зоны.

Обратная проверка идёт через объектив: f (мм) = ширина матрицы (мм) × дистанция (м) / ширина кадра (м). Для камеры 4 Мп на воротах, дистанция 30 м, задача «узнавание» (150 пикс/м, ширина кадра 17,92 м), матрица 1/2,8″ (≈5,6 мм): f = 5,6 × 30 / 17,92 = 9,4 мм. Если в спецификации при этих же вводных стоит объектив 2,8 мм, верификация на воротах не состоится — оператор увидит силуэт и всё равно отправит группу.

Верификация чаще всего рушится ночью — именно тогда, когда она нужнее всего. Причина не в камере как таковой, а в связке «освещённость сцены — светочувствительность — выдержка»: при недостаточном свете картинка становится шумной, детали пропадают, а детектор аналитики выдаёт задержки и пропуски. Нормативные и технические ориентиры здесь есть, и они конкретные.

Первый ориентир — охранное освещение. Постановление Правительства РК от 06.05.2021 № 305 (adilet.zan.kz, P2100000305) в пункте 68 задаёт освещаемую полосу шириной 3–4 м с уровнем не менее 10 люкс. Второй — светочувствительность камеры не хуже 0,01 лк, разрешение не ниже 1920×1080, 25 кадров/с, битрейт от 5000 кбит/с, исполнение IP66: это технические минимумы из Приложения 2 к Правилам НСВМ. Если полоса освещения не выдержана, а камера взята «по мегапикселям», ночная верификация не заработает ни при каком разрешении.

Третий фактор — контровый свет и фары. В руководстве AXIS Object Analytics прямо названы прямой свет в объектив, резкие тени от яркого света и фары автомобиля в сильный дождь как причины ложных и пропущенных детекций. Практический вывод для проектирования: на въездах и у ворот камеру ставят так, чтобы источник света не бил в объектив, и закладывают широкий динамический диапазон, а не просто более «мегапиксельную» модель.

Отдельная типовая ошибка — камера, которая физически не видит зону тревожного датчика. Мы регулярно находим это при аудитах: извещатель закрывает торец здания, а ближайшая камера смотрит на въезд. Какие зоны объекта вообще должны попадать под наблюдение, мы разбирали в материале какие именно зоны должны быть закрыты видеонаблюдением.

Технически верификация — это четыре связки, каждая из которых должна быть выполнена явно, а не «по умолчанию»: тревожная зона привязана к конкретной камере (лучше к двум — обзорной и детальной), включена предзапись, синхронизировано время между прибором и видеосервером, оператор получает ролик, а не приглашение искать событие в архиве вручную.

Предзапись — та деталь, которую чаще всего забывают. Без буфера оператор видит сцену уже после события: человек ушёл из кадра, ветка перестала качаться, причина не установлена. Посчитаем объём: при битрейте 5000 кбит/с поток даёт 0,625 МБ/с, значит ролик «10 секунд до + 20 секунд после» = 30 с × 0,625 МБ/с = 18,75 МБ на одно событие. Даже сотня событий в сутки — это меньше 2 ГБ, то есть на фоне непрерывного архива величина пренебрежимая.

А вот непрерывный архив предзапись не отменяет: срок хранения задан нормативно, поэтому одна камера по-прежнему пишет 54 ГБ в сутки и 1,62 ТБ за 30 суток. Верификация ускоряет разбор инцидента, но объём хранения и его стоимость остаются прежними — это первое, что мы поправляем в чужих расчётах окупаемости.

Синхронизация времени — четвёртая связка и самая недооценённая. Если часы прибора охранной сигнализации расходятся с видеосервером на минуту, оператор при тревоге смотрит не тот фрагмент, а служебное расследование потом упирается в несоответствие журналов. По нашему опыту на объектах это лечится единым источником времени и проверкой расхождения в регламенте ТО — работа на полчаса, которую почти никто не делает.

Верификация — это не бесплатная опция, а рабочее время. Считать её нужно в человеко-минутах на смену, иначе на объекте появится процедура, которую физически некому выполнять. Расчёт простой: количество событий за сутки, умноженное на время просмотра одного ролика, плюс время на оформление решения по тем событиям, которые признаны реальными.

Возьмём условный периметр с 40 срабатываниями за сутки и 30 секундами на просмотр каждого: 40 × 30 = 1200 секунд, то есть 20 минут чистого времени оператора в сутки. Это немного — при условии, что события распределены равномерно и оператор один. Если же на объекте 200 событий за сутки, тот же расчёт даёт 200 × 30 = 6000 секунд, или 1 час 40 минут, и это уже отдельная задача: сначала снижают поток настройкой зон и фильтрацией по типу объекта, потом внедряют верификацию.

Сравним два режима на одном и том же потоке тревог:

Строка про привыкание — не риторика. В whitepaper «Perimeter protection for airports with intelligent video surveillance» Axis прямо указывает: повторяющиеся ложные срабатывания ведут к безразличию персонала, из-за чего сигналы начинают игнорировать и реальная угроза в итоге может быть пропущена. Именно поэтому «шум» — это не только про деньги на выезды, но и про надёжность реакции. Кто и в какой срок реагирует на сигнал ночью, стоит проверять отдельно — мы писали об этом в материале кто будет реагировать на отказ системы ночью.

Метод не универсален, и границы у него жёсткие. Первое: он не снижает число срабатываний датчика — только число реакций на них. Второе: он не работает там, где камера физически не видит зону или не даёт нужной плотности пикселей. Третье и главное: он неприменим к пожарной тревоге.

Про пожарную тревогу поясним отдельно, потому что запрос «а давайте так же отсеивать ложные сработки АПС» звучит регулярно. Сигнал пожарной сигнализации запускает оповещение и эвакуацию, и решение об этом не отменяют по картинке с камеры: пожар в начальной стадии может не давать видимых признаков в поле зрения камеры, а задержка на «посмотреть» стоит минут эвакуации. Ложные сработки пожарной автоматики снижают обслуживанием, подбором типа извещателя и корректной проектной проработкой — это другой инструмент и другая ответственность.

Четвёртое ограничение — организационное. Верификация без регламента превращается в задержку реакции: оператор смотрит ролик, сомневается, звонит начальнику. В договоре должно быть записано, кто принимает решение, за какое время и что происходит при сомнении (по умолчанию — выезд). Практика показывает, что без зафиксированного SLA процедура разваливается за пару месяцев; как его формулировать, мы разбирали в материале какой SLA у сервиса и зафиксирован ли он договором.

Обязательными в Казахстане являются параметры изображения, хранения и оснащения, а не сама процедура верификации. Плотности 50 / 150 / 250 пикс/м по типам зон и технические минимумы (разрешение не ниже 1920×1080, 25 кадров/с, битрейт от 5000 кбит/с, светочувствительность 0,01 лк, IP66, архив не менее 30 суток, автономность от 60 минут) задаёт Приложение 2 к Правилам функционирования Национальной системы видеомониторинга — приказ Председателя КНБ РК от 27.10.2020 № 69-қе (adilet.zan.kz, V2000021693).

Обязательное оснащение объектов из перечня системами охранного телевидения, хранение архива не менее 30 суток и требования к охранному освещению устанавливает постановление Правительства РК от 06.05.2021 № 305 (adilet.zan.kz, P2100000305). Сама охранная деятельность и порядок реагирования регулируются Законом РК от 19.10.2000 № 85-II «Об охранной деятельности» (adilet.zan.kz, Z000000085_) — то есть регламент выезда и его основания вы фиксируете в договоре с охранной организацией, а не выводите из технических норм.

Порядок реагирования и процедуру верификации нормы РК не описывают: это зона ответственности заказчика и его подрядчиков. Отсюда практический вывод — если процедура нигде не записана, при разборе инцидента её как бы и не существовало, а вопрос «почему группа не выехала» останется без документального ответа.

Внедрение занимает один выезд на объект и одну итерацию настройки, если действовать по порядку. Задача — превратить общее пожелание «меньше пустых выездов» в измеримую процедуру с привязками камер, порогами плотности пикселей и зафиксированным временем реакции.

1. Составьте карту тревожных зон. Каждый извещатель и каждая зона аналитики — строкой: где, что охраняет, какая камера её видит.
2. Проверьте плотность пикселей в точке тревоги. Ширина кадра = разрешение по горизонтали / плотность. Для «человек или животное» достаточно 50 пикс/м, для описания признаков нужно 250 пикс/м.
3. Закройте свет. Полоса охранного освещения 3–4 м с уровнем не менее 10 люкс (п. 68 ПП РК № 305), камеры не «в контровик», светочувствительность не хуже 0,01 лк.
4. Включите предзапись и синхронизируйте время. Буфер 10 секунд до события, единый источник времени для прибора и видеосервера, проверка расхождения в регламенте ТО.
5. Опишите регламент решения. Кто смотрит, за сколько секунд, что делает при сомнении (по умолчанию — выезд), где фиксируется основание.
6. Считайте два показателя месяц. Доля подтверждённых тревог и среднее время верификации. Без этих двух цифр вы не отличите работающую процедуру от формальной.

Сводный пример по итогам всех шести шагов. Периметр склада длиной 200 м, задача первого контура — ответ «человек или животное», то есть 50 пикс/м. Камера 2 Мп даёт ширину кадра 1920 / 50 = 38,40 м; с коэффициентом перекрытия 0,9 рабочая ширина составляет 34,56 м, значит на 200 м нужно 200 / 34,56 = 5,79 → 6 камер (дробь округляем только вверх). Архив по первому контуру: 6 × 1,62 = 9,72 ТБ за 30 суток. Второй контур — ворота: 4 Мп, дистанция 30 м, узнавание 150 пикс/м, ширина кадра 17,92 м, объектив f = 5,6 × 30 / 17,92 = 9,4 мм. Тревожный ролик по каждому событию — 18,75 МБ. При 40 событиях в сутки нагрузка на оператора — 20 минут, и именно эти 40 выездов превращаются в те несколько, которые действительно нужны.

Обратите внимание, что ни на одном шаге решение не свелось к разрешению камеры. Мегапиксели задают только ширину кадра; ответ «сработает или нет» складывается из светочувствительности, динамического диапазона на контровом свете, фокусного расстояния и настроек аналитики. Мы разбирали этот выбор подробно в материале что важнее: мегапиксели, объектив, свет, WDR или аналитика.