Виявлення залишених предметів: де ламається система
Виявлення залишених предметів впирається в просту річ: це статичний об'єкт — сумка, рюкзак, коробка біля стіни. Класична відеоаналітика на рух його не бачить, тому що детектор реагує на переміщення, а не на появу нового нерухомого об'єкта в зоні контролю. Подія спливає через десятки хвилин, коли її випадково помічає оператор, — або не спливає взагалі.
Далі втручаються перекриття. Людина закриває пакет собою на кілька секунд, трекер втрачає зв'язок між «людина була» і «річ залишилася», і об'єкт іде у фон сцени.
Якщо ж модель тримає об'єкт у пам'яті занадто довго, починається зворотна крайність: хибні спрацювання на кожному портфелі, який власник поставив поруч із собою й відійшов на пару метрів.
Плата за обидва режими однакова. Або пропущена подія в зоні контролю, де зволікання коштує найдорожче, або потік хибних спрацювань, після якого зміна перестає реагувати на сигнали в принципі.
Поверх цього — розрив між подією та реакцією: знайдений предмет треба довести до чергового з картинкою, прив'язкою до камери та позначкою часу, інакше він залишається рядком у журналі.
Ми вбудовуємо цю логіку в уже працюючий відеоконтур, включно із системами рівня Milestone, а не будуємо другий паралельний контур з окремими камерами.
Далі розбираємо, як це закривається на практиці: логікою володіння об'єктом, порогами за часом статичності та прив'язкою до меж зони контролю.
Що дає впровадження: вимірюваний ефект для об'єкта
На об'єкті без налаштованої аналітики залишений предмет помічає людина — і помічає не завжди. Система переводить це в правило: об'єкт перебуває в зоні інтересу довше заданого порога і поруч немає руху — формується тривога з прив'язкою до часу та камери.
Час реакції охорони падає з кількох хвилин до десятків секунд, тому що оператор отримує готову подію, а не потік відео.
Навантаження на оператора визначається не числом камер, а числом хибних спрацювань. Пороги підбираються під конкретну сцену: окремо для вулиці з рослинністю, окремо для касової зони та вхідної групи, окремо для місць із мінливим освітленням.
Після такого налаштування один пост впевнено веде втричі більше камер, а частка пропущених подій знижується завдяки тому, що увага не розпорошується на шум.
Якість відеоаналітики зростає разом із накопиченим архівом подій. Кожне хибне спрацювання розбирається й іде на донавчання, тому через кілька тижнів роботи точність на конкретному об'єкті вища, ніж у типової моделі.
Архів подій зберігає не лише кліпи, а й метадані: тип події, зона, інтервал, статус обробки. Розбір інциденту займає хвилини — потрібний фрагмент знаходиться за фільтром, а не перемотуванням доби запису.
Працюємо на професійному обладнанні Hikvision, тому система вбудовується в уже змонтовану мережу спостереження без заміни парку камер.
Варіанти виявлення: локальний, серверний, гібридний
У всіх трьох схемах джерело одне — потік з камер, різниться лише місце розбору кадрів: обчислювальний вузол на об'єкті, сервер або обидва рівні одразу.
Вибір визначається числом камер, стабільністю каналу, вимогами до зберігання відео і тим, як швидко тривога має дійти до оператора.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Локальна обробка | Невелика кількість камер, слабкий або нестабільний канал, вимога тримати відео всередині об'єкта | Потужність вузла обмежує число потоків і моделей; оновлення моделей потребує виїзду або окремого механізму доставки |
| Серверна аналітика | Багато камер, єдиний архів, керування моделями з центру, кілька об'єктів на одному майданчику | Канал має витримувати одночасну передачу всіх потоків; у разі обриву зв'язку детекція на об'єкті зупиняється |
| Гібридна схема | Об'єкт із великою кількістю камер і вузьким каналом, потрібні і швидка тривога, і централізоване оновлення моделей | Складніша в супроводі: потрібно синхронізувати налаштування між рівнями й заздалегідь домовитися, який рівень вважає подію підтвердженою |
Обмеження системи не зникають при зміні схеми — вони перерозподіляються. Гібрид розвантажує канал ціною другої точки оновлення, серверна аналітика спрощує керування моделями, але робить об'єкт залежним від зв'язку.
Тому вибір перевіряємо на записах з конкретного об'єкта: рахуємо частку пропущених залишених предметів і число хибних тривог на нічному записі, при перекриттях і в зонах із щільним потоком людей. Схема годиться, якщо метрики тримаються на всіх цих умовах, а не лише на денному тестовому ролику.
Етапи впровадження: від обстеження об'єкта до передачі
Детекція залишених предметів не купується готовою коробкою: правила спрацювання залежать від геометрії залу, щільності потоку та режиму роботи об'єкта. Тому впровадження йде фіксованою послідовністю — на кожному кроці зрозуміло, що вже перевірено і що залишилося налаштувати.
- Обстеження об'єкта. Проходимо зони разом зі службою безпеки, звіряємо план приміщень зі схемою камер: відзначаємо сліпі ділянки, перекриття ракурсів і місця, де залишений предмет не бачить жодна камера.
- Схема розміщення та зони інтересу. Визначаємо контрольовані області та виключення — виходи, ескалатори, ділянки постійного руху. На схему лягають ракурси й набір правил для кожної зони.
- Налаштування правил. Задаємо час нерухомості, мінімальний розмір об'єкта, розклад для різних змін. Окремо розводимо предмет, залишений людиною, і об'єкт, який довго стоїть за регламентом.
- Тестовий період. Система працює в режимі спостереження: оператори фіксують спрацювання, ми розбираємо кожне й правимо пороги — прибираємо хибні, не втрачаючи реальні.
- Приймання системи. Дивимося вимірювані показники: частка пропущених подій, число хибних тривог за зміну, час від появи предмета до сигналу. Результат фіксується протоколом.
- Передача в експлуатацію. Навчаємо операторів, віддаємо регламент реакції на тривогу та інструкцію зі зміни зон при переплануванні.
Кожен етап закінчується артефактом — схемою, конфігурацією правил або протоколом. Замовник бачить, на якому кроці проєкт і що станеться після передачі.
Склад постачання: конфігурації, схеми та регламенти
Постачання влаштоване так, щоб система залишилася робочою без нас: усе, що описує поведінку, зберігається в текстових конфігураціях і схемах, а не в голові інженера. Нижче — що саме переходить команді замовника і що з цим можна робити далі самостійно.
- Конфігурації детекції — пороги чутливості, мінімальний час перебування предмета в зоні, перелік класів об'єктів і зони виключень. Правиться без перезбирання моделі, зміни набувають чинності після перевірки на тестовій підбірці записів.
- Схема розміщення камер — плани приміщень із точками встановлення, напрямками огляду, зонами перекриття та явно позначеними сліпими ділянками. З неї видно, чому обрано таку геометрію і які місця залишаються поза контролем.
- Регламент реагування — хто отримує тривогу, за який час, що робить оператор до приходу групи, за яких умов подія закривається як хибна, кому ескалюється.
- Документація — опис стикування з чинною відеосистемою, структура зберігання подій і відеофрагментів, інструкції для оператора й адміністратора, порядок оновлення моделей.
- Права доступу — матриця ролей: хто бачить потік, хто змінює пороги, хто вивантажує архів, хто керує зонами. Розділення виключає правку правил тими, хто лише дивиться зміну.
- Тестові сценарії — підбірка записів із залишеними предметами та складними випадками: тіні, відображення, люди, що стоять поруч. За нею перевіряється будь-яка зміна конфігурації перед виведенням у роботу.
- Журнал версій конфігурацій — що змінювалося, коли і з яким результатом на тестовій підбірці, щоб відкотитися до попереднього набору правил за одну операцію.
Такий склад дає замовнику можливість розвивати систему своїми силами: доналаштовувати зони, змінювати регламент під зміну служби безпеки, підключати нові камери — і повертатися до нас лише за зміною логіки виявлення залишених предметів.
Кейс: як скоротили час реакції на складі
Розподільчий склад із прийманням, зберіганням і відвантаженням в одному контурі: залишена палета або коробка в проїзді блокує навантажувач, а диспетчер дізнається про це від змінника по телефону — на момент реакції предмет стоїть у зоні вже кілька хвилин.
Що показали заміри до впровадження
Почали з двох тижнів спостереження: подію вважали пропущеною, якщо оператор не відреагував, поки предмет залишався в проїзді. Частка пропущених трималася близько 30%, середній час реакції — 4-6 хвилин.
Причина не в людях: один оператор фізично не утримує увагу на стіні екранів усю зміну, до третьої години воно падає.
Що змінили
Детекцію побудували на YOLO, донавчивши модель на записі цього самого об'єкта — так вона знає місцеві типи тари і не плутає палету, що стоїть у комірці, із залишеною в проїзді.
Тривога спрацьовує не на появу об'єкта, а на його нерухомість у забороненій зоні довше порога, прив'язаного до темпу розвантаження. Оператор отримує не потік відео, а чергу тривог: камера, фрагмент навколо події, позначка «в роботі».
Що стало за метриками
Частка пропущених подій пішла нижче 2%: майже всі розбираються, поки предмет ще в проїзді. Середній час реакції скоротився з 4-6 хвилин до 20-40 секунд, хибні тривоги — з 15-20 за зміну до 2-3 після налаштування зон і порогів разом із начальником зміни. Вивільнену увагу зміна витрачає на розбір черги тривог замість пошуку порушення очима.
Що робити, якщо на об'єкті вже стоять камери
Міняти парк камер при запуску детекції залишених предметів у більшості випадків не потрібно: аналітика ставиться окремим шаром, який отримує потік з уже встановлених камер і віддає події далі в контур спостереження.
Вузьке місце тут не роздільна здатність матриці, а три речі — стабільність потоку, кут огляду зони та освітленість. Камера, яка «бачить» прохід, але пише ривками або дивиться в підлогу, дасть хибні спрацювання незалежно від якості моделі.
Перед стартом наші інженери знімають інвентаризацію: моделі камер, доступні потоки, завантаження мережі та сховища, глибина архіву, схема розміщення. Якщо камери віддають потік у стандартному мережевому форматі — вони підходять, і питання зводиться до розрахунку навантаження.
Якщо потік закритий усередині реєстратора без можливості виведення, розглядаємо шлюз на боці реєстратора або часткову заміну по зонах.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Аналітика окремим шаром поверх наявних камер | Потоки відкриті, картинка стабільна, парк міняти не потрібно | Потрібен сервер обробки й доступ до потоків |
| Вбудовування в наявний реєстратор | Парк однотипний, є вільні канали й запас за записом | Набір сценаріїв обмежений можливостями реєстратора |
| Часткова заміна камер у критичних зонах | Старі камери не дають потрібного кута або потоку | Заміна йде по зонах, а не по всьому об'єкту |
Поетапна модернізація виглядає так: спочатку пілот на двох-чотирьох камерах у найчутливіших зонах — калібруємо зони контролю й час утримання об'єкта, рахуємо частку хибних спрацювань на реальних змінах.
Далі розширюємо на решту камер, де якість потоку це дозволяє, і тільки після цього міняємо поодинокі камери, які не проходять за оглядом. Реєстратор залишається в контурі: події приходять у нього, оператор працює у звичному інтерфейсі, запис і архів не перебудовуються.
Часті технічні сумніви та відповіді інженерів
Перед пілотом замовник перевіряє не точність моделі, а поведінку системи в реальному залі: хибні спрацювання на перехожих, перекриття колонами та стелажами, обрив зв'язку з камерою, планове перепланування. Розбираємо ці сумніви предметно.
Система буде спрацьовувати на все підряд?
Чутливість — це набір правил, а не один регулятор: зони інтересу, поріг упевненості детектора, мінімальний розмір об'єкта і витримка часу. Предмет має залишатися нерухомим заданий інтервал, перш ніж з'явиться тривога, — коротка зупинка людини або відкинута тінь її не викликають.
Пороги калібруємо на записах із вашого майданчика, тому вони відображають реальну геометрію та освітлення.
Що станеться при втраті зв'язку з камерою або сервером?
Обрив потоку — окрема подія, а не тиша: оператор бачить, який канал втрачено і що ділянка не контролюється. Розбір кадрів продовжується на локальному вузлі, буфер зберігається й довантажується після відновлення каналу. Стан камер і активні тривоги синхронізуються — дублів не виникає.
Плануємо перепланування — систему доведеться переробляти?
Зони інтересу, правила й розклади зберігаються окремо від моделі, як конфігурація. Переставити стелажі, звузити прохід або змінити призначення залу можна без перенавчання — достатньо заново розмітити зони на новому плані.
Зміна ракурсу камери потребує повторного калібрування сцени, а при перекриттях трек предмета відновлюється, тому одиночний прохід людини не розриває історію спостереження.
Обговоримо задачу: що потрібно для старту робіт
Обговорити задачу предметно простіше, коли є конкретні ввідні: тоді оцінка проєкту спирається на факти, а не на припущення. Нижче — мінімум вихідних даних, який прибирає уточнювальні ітерації та дозволяє одразу зібрати план робіт.
- Камери та зони: де встановлено обладнання, які ділянки перекриваються, де залишаються сліпі зони — платформи, стійки, виходи.
- Що вважаємо подією: сумку без власника, коробку біля огорожі, візок; через який час предмет визнається залишеним.
- Наявна інфраструктура: відеосервер, система контролю доступу, пульт охорони — куди логічно надсилати тривогу, щоб не створювати другий паралельний інтерфейс.
- Правила реагування: хто отримує повідомлення і в який строк, чи потрібна ескалація, чи ведеться журнал дій оператора.
- Приватність і зберігання: строк зберігання фрагментів, маскування облич, розмежування доступу за ролями.
- Критерії приймання: допустима частка хибних спрацювань, час від появи події до тривоги, набір сцен для перевірки.
- Доступ до тестового середовища: архів записів або потік з однієї камери, окремий контур, що не впливає на бойове відеоспостереження.
Опишіть задачу в такому обсязі — повернемося з оцінкою проєкту, схемою рішення та планом робіт за етапами, узгодимо порядок запуску.
