Разработка системы мониторинга дорожного трафика через видеоаналитику

Где ломается видеоаналитика дорожного трафика на реальных объектах

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

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

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

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

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

Что меняется после внедрения: точность подсчёта и время реакции

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

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

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

Варианты развёртывания: на объекте, в центре обработки, гибрид

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

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

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

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

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

2. Проектирование схемы. Согласуем классы объектов (легковые, грузовые, автобусы, пешеходы), линии подсчёта, зоны контроля и правила срабатывания — что считается нарушением, что инцидентом, а что шумом.

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

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

5. Опытная эксплуатация на живом потоке. Система работает параллельно с обычным наблюдением, операторы фиксируют пропуски и ложные тревоги. Правки вносим в конфигурацию, а не в код на ходу.

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

Комплект поставки: конфигурации зон, схемы, регламенты эксплуатации

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

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

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

Кейс: как выросла точность подсчёта на городском участке

Что было до

Участок — плотный городской поток с пешеходным переходом и поворотом на магистраль. Детектор, настроенный на «средний» поток, ошибался именно на пике: доля верных распознаваний держалась около 75%, а в вечерний час падала ниже 70%. Треки сливались, часть машин считалась дважды, часть терялась за фурой. Ложных срабатываний набегало несколько сотен в сутки — ночные засветки, тени, отражения от мокрой дороги.

Что изменили и что стало

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

Доля верных распознаваний — 93–96% за сутки и не ниже 90% в час пик. Ложные срабатывания сократились с нескольких сотен до 20–25 в сутки, и почти каждое подтверждается вторым кадром, а не одиночным срабатыванием. Время от события до сигнала оператору: было 20–40 минут, пока инцидент находили в записи, стало 3–5 секунд — на пульт уходит карточка с фрагментом и метками.

Метрики считали на одинаковых интервалах записи до и после, с той же разметкой зон, — поэтому сравнение сопоставимое, а не «на глаз».

Что делать, если на объекте уже стоят камеры другого поставщика

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

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

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

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

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

Частые технические сомнения перед стартом проекта

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

Насколько точна ночная съёмка?

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

Сколько хранятся записи?

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

Как убедиться, что подсчёт корректен?

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

Нужен ли постоянный оператор?

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

Обсудим задачу: соберём схему и вернёмся с оценкой

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

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

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

Опишите задачу в свободной форме — вернёмся с оценкой и планом.