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

Де ламається відеоаналітика дорожнього трафіку на реальних об'єктах

Пілотна відеоаналітика дорожнього трафіку майже завжди дає рівний звіт до першого порівняння з ручним підрахунком на тій самій ділянці.

Розбіжність у межах п'ятої частини на щільному потоці — звична справа, і означає вона не «слабку модель», а конкретні сцени, де детектор втрачає об'єкт або рахує його двічі.

Найчастіше джерело — перекриття огляду камер. Фура в крайній смузі, гілка дерева, новий рекламний щит або зміщена розмітка після ремонту відрізають частину зони детекції, і все, що відбувається за перешкодою, для системи не існує.

Окремий випадок — розворотні петлі та примикання: автомобіль виходить із кадру й повертається до нього, і без коректної прив'язки до зон він враховується повторно.

Знімання в темний час і в опади ламає детектор інакше.

Засвітлення від фар, відблиски на мокрому асфальті, довгі тіні від огорож знижують контраст об'єкта, супроводження розривається, і розрив перетворюється або на пропуск транспортних одиниць, або на подвійний підрахунок однієї машини. Дощ і сніг додають шум, який модель упевнено розпізнає як рухомий об'єкт.

Хибні спрацьовування детектора частіше надходять не від транспорту: відображення в калюжах, тіні, пішоходи біля краю проїзної частини, конструкції, що гойдаються від вітру.

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

Усі ці відмови лежать у калібруванні та локальних даних, а не у виборі моделі.

Розбираємо, як це закривається: встановленням зон під реальну геометрію об'єкта, донавчанням на власних сценах ділянки та регулярним звірянням із ручним підрахунком як обов'язковою перевіркою перед здаванням.

Що змінюється після впровадження: точність підрахунку та час реакції

Ефект від відеоаналітики зводиться до трьох чисел: частка правильно розпізнаних одиниць потоку, медіана часу від події до оповіщення та обсяг архіву, який оператор переглядає вручну.

Вимірюємо їх на розмічених відрізках записів до старту — інакше «стало точніше» нічим не підтверджується.

• Точність підрахунку потоку. Алгоритм утримує той самий об'єкт між кадрами, тому в щільному ряду машини не двояться й не губляться в тіні. Добовий звіт по смузі починає сходитися з ручним перерахунком без правок.
• Час виявлення інциденту. Зупинка в смузі, зустрічний рух, вантаж, що випав, надходять оператору за секунди — з прив'язкою до камери та позначкою часу, а не після розбору зміни.
• Класифікація транспорту за типами. Легкові, вантажні, автобуси та спецтехніка розділяються за габаритами й силуетом, склад потоку рахується автоматично, без ручної розмітки.
• Зниження ручного перегляду записів. Оператор відкриває список подій і короткі фрагменти навколо них замість доби архіву: розбір зміни займає хвилини, при цьому кожне спрацьовування перевіряється.

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

Варіанти розгортання: на об'єкті, в центрі обробки, гібрид

Схема розгортання визначає, де стоїть обчислювальний вузол — на перехресті чи в центрі, — і яке навантаження лягає на канал зв'язку. Сирий відеопотік із камер займає смугу постійно, тоді як події та метадані надходять лише в момент спрацьовування.

Тому вибір диктують не моделі розпізнавання, а кількість камер на об'єкті, стабільність каналу та вимога до безперервного архіву.

На об'єктах зі стійким зв'язком централізована схема дає загальну картину по всій мережі та єдині правила обробки.

Там, де виведення сирого відео неможливе, розпізнавання переїжджає на перехрестя, а в центр надходять лише події: при обриві зв'язку вони накопичуються локально й надсилаються після відновлення каналу.

Гібрид збирається з обох контурів і найчастіше виявляється робочим компромісом для міста, де об'єкти сильно різняться за умовами експлуатації.

Етапи впровадження відеоаналітики: від обстеження до передачі

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

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

2. Проєктування схеми. Узгоджуємо класи об'єктів (легкові, вантажні, автобуси, пішоходи), лінії підрахунку, зони контролю та правила спрацьовування — що вважається порушенням, що інцидентом, а що шумом.

3. Калібрування зон детекції. Прив'язка зон до розмітки та смуг, пороги чутливості, маски на тіні, гілки й рекламні конструкції. Окремо перевіряємо ніч, дощ і контрове світло.

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

5. Дослідна експлуатація на живому потоці. Система працює паралельно зі звичайним спостереженням, оператори фіксують пропуски та хибні тривоги. Правки вносимо в конфігурацію, а не в код на ходу.

6. Приймання та передача системи. Здавання за узгодженими метриками точності й повноти, передача документації, конфігурацій і доступів, навчання операторів. Окремо — порядок відкату та відновлення після збою.

Комплект постачання: конфігурації зон, схеми, регламенти експлуатації

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

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

• Паспорт зон контролю: межі кожної зони, правила спрацьовування, пороги чутливості та логіка придушення хибних спрацьовувань — тінь, світло фар, коротка зупинка в потоці.
• Схеми розміщення камер: плани встановлення, поля зору, зони перекриття, точки підключення та живлення, прив'язка кожної камери до зон паспорта.
• Політики доступу до відеопотоку: ролі користувачів, розділення живого перегляду й архіву, терміни зберігання, журналювання кожного звернення до відео.
• Регламент експлуатації: періодичність перевірки ракурсів і якості зображення, калібрування зон, порядок дій при зникненні сигналу та при спірній події.
• Журнал подій: склад полів запису, вивантаження у звітність, звіряння автоматичних даних із ручними вимірами на контрольних ділянках.
• Інструкції для операторів і матриця змін: що вважається інцидентом, хто узгоджує правку зон і правил, як версіонуються конфігурації та виконується відкат.

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

Кейс: як зросла точність підрахунку на міській ділянці

Що було до

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

Треки зливалися, частина машин рахувалася двічі, частина губилася за фурою. Хибних спрацьовувань набігало кілька сотень за добу — нічні засвітлення, тіні, відображення від мокрої дороги.

Що змінили і що стало

Донавчили детектор на базі YOLO на локальній вибірці кадрів цієї ділянки та додали модуль супроводження, який перевіряє об'єкт за траєкторією, а не за одним кадром.

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

Частка правильних розпізнавань — 93–96% за добу та не нижче 90% у час пік. Хибні спрацьовування скоротилися з кількох сотень до 20–25 за добу, і майже кожне підтверджується другим кадром, а не одиничним спрацьовуванням.

Час від події до сигналу оператору: було 20–40 хвилин, поки інцидент знаходили в записі, стало 3–5 секунд — на пульт надходить картка з фрагментом і позначками.

Метрики рахували на однакових інтервалах запису до й після, з тією ж розміткою зон, — тому порівняння зіставне, а не «на око».

Що робити, якщо на об'єкті вже стоять камери іншого постачальника

Коротка відповідь: міняти весь парк камер майже ніколи не потрібно. Починаємо з інвентаризації — які камери вже стоять на об'єкті, як вони віддають відеопотік і хто ними керує.

За її підсумками більша частина парку підключається до аналітики як є, частина потребує доопрацювання, і лише невеликий залишок змінюється фізично.

Придатність потоку визначається не брендом, а тим, чи віддає камера відео за відкритим мережевим стандартом, а не лише всередину спорідненого реєстратора; чи є до потоку доступ із правами на читання; чи дозволяє ракурс розрізняти транспорт і номер; чи залишається зображення робочим уночі та в негоду.

Різні моделі камер на одному об'єкті — норма: аналітика приймає різнорідний парк і приводить потоки до єдиного вигляду.

Заміна потрібна там, де камера пише лише в закритий архів виробника з шифруванням, де на виході аналоговий реєстратор без мережевого каналу, або де огляд перекритий, а якість не дає розрізняти класи.

Часто вигідніше не міняти камеру, а додати вузол: додаткову точку огляду на проблемній ділянці або локальний модуль обробки.

Інтеграція зі встановленим обладнанням будується так, щоб не ламати поточний контур: запис і спостереження продовжують працювати на попередньому реєстраторі, а аналітика отримує відеопотік паралельно й не змінює його налаштування.

Пропускну здатність каналу рахуємо заздалегідь — при нестачі виділяємо аналітиці окремий сегмент, а не відбираємо смугу в охорони.

Підсумок: спочатку перевірка придатності відеопотоку за кожною камерою, потім рішення — підключити, доопрацювати чи замінити. Замовник отримує список камер із вердиктом щодо кожної й бачить, де заміна неминуча, а де достатньо одного додаткового вузла.

Часті технічні сумніви перед стартом проєкту

Інженерні сумніви перед стартом стосуються не демонстрації, а поведінки системи в поганих умовах: опадів, ночі, засвітлення від фар, контрового світла.

Саме там падає точність детектора, тому кожну відповідь нижче ми підтверджуємо контрольними прогонами з ручною розміткою — до підписання плану робіт, а не після здавання.

Наскільки точне нічне знімання?

Уночі працюють інфрачервоне підсвічування та режим підвищеної чутливості, відблиски фар маскуємо за зонами. Модель донавчаємо на нічних фрагментах цієї ж ділянки, а точність рахуємо окремо за днем і ніччю — загальне середнє тут нічого не показує.

Скільки зберігаються записи?

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

Як переконатися, що підрахунок коректний?

Беремо контрольні інтервали та перераховуємо їх вручну, порівнюючи результат за кожним класом. Розбіжність вище заданого порогу — сигнал до перекалібрування. Додатково працюють автоматичні перевірки: баланс в'їзду та виїзду за добу і відсіювання дубльованих треків.

Чи потрібен постійний оператор?

Ні. Система працює автономно, оператор підключається лише до розбору спірних ситуацій. Повідомлення про збої камер, перекриття огляду або аномалії в даних надходять автоматично.

Обговоримо задачу: зберемо схему та повернемося з оцінкою

Щоб обговорити задачу за один круг, а не за тиждень листування, потрібен мінімум ввідних. Нижче — що ми запитуємо в замовника на старті та що повертаємо за підсумками розбору.

• Перелік камер і типів потоків: моделі, чи віддають вони відео напряму або лише архів, хто власник інфраструктури та чи є до неї доступ.
• Задачі розпізнавання: підрахунок транспорту за смугами й напрямками, класи об'єктів, фіксація зупинки, затору, виїзду на виділену смугу.
• Вимоги до подій: які дані потрібні на виході — лічильники, тривоги, звіти — і в яку систему їх передавати.
• Обмеження інфраструктури: де допустимо розмістити обчислення, який канал зв'язку доступний і як довго зберігати архів.
• Складні умови знімання: ніч, дощ, відблиски, перекриття — що вже відомо про проблемні ділянки та точки огляду.
• Критерії приймання: за якими метриками вважаємо систему робочою — точність детекції на тестовій вибірці, затримка оповіщення, частка пропущених подій.
• Контакт на стороні замовника, який узгоджує схему рішення та приймає етапи.

За підсумками розбору повертаємося зі схемою рішення: розстановка камер і організація потоків, набір моделей і правила детекції, необхідні інтеграції.

До схеми додаємо оцінку строків за етапами та план впровадження: пілот на обмеженій ділянці, калібрування моделей, приймання на тестовій вибірці, розгортання та передача документації.

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