Розробка системи відеоаналітики на YOLOv8 для безпеки об'єктів

Чому відеоаналітика не знаходить події на об'єкті

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

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

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

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

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

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

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

Що дає відеоаналітика на об'єкті: вимірювані ефекти

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

Менше хибних спрацювань і пропусків

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

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

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

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

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

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

Оператор тримає більше камер

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

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

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

Обробка на об'єкті

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

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

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

Як відбувається впровадження: від обстеження до здачі

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

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

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

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

Перевірка на реальних подіях

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

Пакет налаштувань, схем і регламентів після впровадження

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

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

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

Політики доступу до записів

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

Документація та інструкції зміни

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

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

Вихідна ситуація

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

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

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

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

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

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

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

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

• Хибні тривоги за зміну: десятки → одиниці, оператор дивиться лише підтверджені події.
• Час розбору інциденту: з півгодини перебору архіву до двох-трьох хвилин за карткою з готовим фрагментом.
• Порушення периметру: частка зафіксованих із відеопідтвердженням зросла з третини до практично всіх.
• Зони зберігання: у кожної події є конкретна зона й тип, ручний пошук в архіві більше не потрібен.

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

Чим відрізняється розбір потоку від розбору архіву?

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

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

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

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

Технічні питання, які ставлять перед стартом

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

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

Чи можна донавчити систему під наші сценарії?

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

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

Як вирішується питання приватності співробітників?

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

Як система поводиться взимку й у темряві?

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

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

Що робити з уже встановленим парком камер?

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

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

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

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

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

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

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

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