Разработка системы видеоаналитики на YOLOv8 для безопасности объектов

Почему видеоаналитика не находит события на объекте

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

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

Отраслевой обзор по интеллектуальному видеонаблюдению оценивает долю инцидентов, которые не превращаются в события, как значительную — и она почти не падает от того, сколько камер добавили.

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

Что даёт видеоаналитика на объекте: измеримые эффекты

Детектор работает на объекте, а не в облаке: поток с камер фильтруется на месте, и на пост охраны попадают не кадры, а готовые события с типом, камерой и моментом времени.

Меньше ложных срабатываний и пропусков

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

Реакция охраны вместо разбора архива

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

Оператор держит больше камер

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

Способы развёртывания видеоаналитики: на объекте, в облаке, гибрид

Способ развёртывания определяет не точность модели, а требования к каналу связи, приватность кадров и поведение системы при обрыве сети. Ниже — сравнение четырёх схем, между которыми реально выбирают на старте проекта.

Обработка на объекте

Наружу уходят не кадры, а метаданные событий, поэтому приватность обеспечивается по построению, а не настройками доступа. При обрыве связи детекция продолжает работать локально: события складываются в буфер и уходят в центр после восстановления канала — наблюдение не прерывается.

Гибридная схема

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

Как проходит внедрение: от обследования до сдачи

Порядок работ выстроен так, что каждый этап опирается на данные предыдущего: переделка на развёртывании стоит кратно дороже, чем уточнение на обследовании, поэтому первые два шага мы не сокращаем даже при сжатых сроках.

1. Обследование объекта. Проходим территорию вместе с охраной и службой эксплуатации: фиксируем ракурсы, слепые участки, ночную освещённость и точки, где пересекаются потоки людей и техники.
2. Схема зон покрытия и сценариев. На плане отмечаем зоны интереса и линии, пересечение которых считается событием: периметр, ворота, склад, кассовая зона. Для каждой зоны задаём свой сценарий — проход, нахождение дольше заданного времени, скопление.
3. Развёртывание и подключение потоков. Считаем, сколько камер держит один вычислительный узел, какой запас остаётся на пиковые сцены и как система ведёт себя при обрыве связи с регистратором.
4. Настройка моделей под объект. Подбираем пороги чувствительности и фильтры по классу объекта, маскируем зоны с бликами, тенями и отражениями — иначе смена утонет в ложных срабатываниях.
5. Тестовый прогон. Прогоняем архив за характерные сутки и живой поток в часы пик, считаем долю пропусков и ложных тревог, при необходимости возвращаемся к настройкам.
6. Передача и обучение охраны. Передаём регламент реакции на каждый тип события, разбираем типовые сработки и остаёмся на связи первые недели эксплуатации.

Работа с уже установленными камерами

Парк камер чаще уже стоит, и менять его целиком не нужно: проверяем, что вытягивают существующие ракурсы, а недостающее закрываем точечно — двумя-тремя камерами в проблемных точках.

Проверка на реальных событиях

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

Пакет настроек, схем и регламентов после внедрения

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

Конфигурация сценариев и карта зон

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

Политики доступа к записям

• Матрица ролей: кто видит поток, кто выгружает фрагмент, кто согласует экспорт и как каждый факт выгрузки фиксируется в журнале.
• Сроки и глубина хранения архива по типам камер, порядок удаления по истечении срока и правила изъятия фрагмента по запросу.

Документация и инструкции смены

• Инструкция оператора и охраны: разбор типовых событий, порядок действий при срабатывании, эскалация и поведение при отказе камеры.
• Регламент дообучения: при каких изменениях на объекте — новая техника, перестановка, другая спецодежда — модель переобучается и как проверяется результат на контрольной выборке.

Кейс: видеоаналитика на складе, показатели до и после

Исходная ситуация

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

Отдельная проблема — зоны хранения. Система не отличала сотрудника, прошедшего по проходу, от того, кто зашёл в зону отбора товара. События падали одним списком, без привязки к конкретной зоне и понятной картины произошедшего.

Изменили модель детекции объектов актуальной ветки и наложили поверх правила зон, настроенные под планировку склада. Сопровождение объекта по кадрам подтверждает событие несколькими последовательными попаданиями и отсекает одиночные срабатывания, поэтому нарушение периметра и вход в зону хранения стали разными типами событий со своей логикой оповещения.

Результат после внедрения

Метрики снимали до и после на одном и том же контуре, поэтому сравнимы напрямую — обе точки фиксирует Протокол приёмочных замеров.

• Ложные тревоги за смену: десятки → единицы, оператор смотрит только подтверждённые события.
• Время разбора инцидента: с получаса перебора архива до двух-трёх минут по карточке с готовым фрагментом.
• Нарушения периметра: доля зафиксированных с видеоподтверждением выросла с трети до практически всех.
• Зоны хранения: у каждого события есть конкретная зона и тип, ручной поиск в архиве больше не нужен.

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

Чем отличается разбор потока от разбора архива?

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

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

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

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

Технические вопросы, которые задают перед стартом

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

Часть параметров зависит от ракурсов камер, освещения и состояния сети — эти вводные мы снимаем на обследовании, до проектирования. Ответы ниже описывают логику системы и то, как она ведёт себя в нештатных режимах.

Можно ли дообучить систему под наши сценарии?

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

Как решается вопрос приватности сотрудников?

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

Как система ведёт себя зимой и в темноте?

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

Что делать с уже установленным парком камер?

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

Обсудим задачу и вернёмся с планом внедрения

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

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

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

• Ждать, что готовая модель распознаёт любые события «из коробки»: она уверенно работает на типовых сценах, а ваши спецовки, тара, погрузчики и ракурсы требуют дообучения на кадрах именно с объекта
• Проектировать зоны контроля после монтажа камер, а не до него: контровой свет, перекрытие стеллажами, слишком острый угол и низкая точка съёмки съедают событие, которое потом невозможно вернуть настройками
• Путать разбор потока и разбор архива и закладывать один режим вместо двух: оперативные оповещения и последующий поиск по записям решают разные задачи и по-разному настраиваются
• Считать внедрение разовым мероприятием: после перестановки оборудования, смены сезонной одежды или замены тары точность падает, поэтому нужен регламент регулярной проверки и обновления набора примеров
• Требовать абсолютной точности и нулевых лишних сигналов вместо выбора приоритетов: важнее договориться, какие события критичны, а какие достаточно фиксировать без оповещения дежурного
• Подключать к системе все камеры сразу, вместо пробного запуска на двух-трёх зонах, где видно реальное качество срабатываний и нагрузку на людей, которые разбирают сигналы
• Оставлять без ответа вопрос «что делать с событием»: без назначенного ответственного и понятного порядка действий даже точная видеоаналитика превращается в ленту уведомлений, которую перестают читать