Інженерний огляд

Коли відео стає даними: що змінюється для служби безпеки

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

Різниця тут не в якості зображення. Різниця в тому, що система отримала з побаченого.

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

Структуровані дані з’являються в Security Center двома шляхами. Перший — власна спеціалізована аналітика виробника; найповніший приклад тут AutoVu, підсистема автоматичного розпізнавання номерних знаків. Другий — аналітика, яку виконує сама камера або стороннє рішення, а платформа отримує готовий результат. Почати варто з першого: він найкраще показує, що взагалі означає «структуровані дані».

Зчитування номера — це не рядок символів

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

Результатом є структурований запис:

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

Такі записи збираються у звіті Reads, де їх шукають за будь-якою з доступних ознак.

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

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

Для архітектора тут важлива ще одна деталь: дані розпізнавання і пов’язані з ними зображення обслуговують різні ролі платформи — ALPR Manager і Archiver. Глибину зберігання для них планують окремо, інакше через півроку структуровані зчитування залишаться без пов’язаних зображень: дані для пошуку ще є, а візуального контексту вже немає.

Схема: зчитування номерного знака стає збігом і далі йде у звіти, зовнішні системи або в дію системи
Малюнок 1. Зчитування стає збігом — і далі йде у звіти, зовнішні системи або в дію системи.

Які дані з’являться — вирішує точка спостереження

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

В AutoVu це два окремі типи точок спостереження. SharpV — стаціонарна камера розпізнавання, яка працює з фіксованою сценою і несе всю обробку на борту. SharpZ3 — мобільна система для патрульного автомобіля з окремим обчислювальним блоком, яка передає зчитування через програму Genetec Patroller.

Схема: стаціонарна та мобільна точки спостереження ведуть до тих самих ролей Security Center
Малюнок 2. Стаціонарна і мобільна точки спостереження ведуть до тих самих ролей Security Center.

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

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

Неправильну архітектуру точки спостереження не компенсувати хорошим рушієм розпізнавання. І навпаки.

Ціна допуску: пропущений збіг проти хибного спрацювання

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

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

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

Одне зчитування — три різні продовження

Те саме зчитування може піти трьома архітектурно різними шляхами. Від вибору залежить не лише те, що система зробить зараз, а й те, що залишиться в ній потім.

Одне зчитування

  • 01 · Подія

    Автомобіль потребує уваги просто зараз.

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

  • 02 · Ідентифікатор доступу

    Номер бере участь у рішенні про доступ.

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

  • 03 · Паркувальна сесія

    Номер стає частиною спеціалізованого процесу.

    У Free-Flow, підсистемі контролю зайнятості парковки, зчитування на в’їзді та на виїзді утворюють паркувальну сесію — самостійний об’єкт із власним станом. Далі він живе за своїми правилами: показує зайнятість майданчика, відстежує перевищення оплаченого часу, формує перелік порушників.

Три різні відповіді на те саме розпізнавання.

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

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

Схема: одне зчитування номера з трьома продовженнями — подія, ідентифікатор доступу, паркувальна сесія
Малюнок 4. Одне зчитування, три різні продовження: подія, ідентифікатор доступу, паркувальна сесія.

Чи має платформа виконувати кожен алгоритм сама

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

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

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

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

Питання до постачальника

Тому питання до постачальника коректніше ставити не як «чи підтримує система виявлення X», а як «де воно виконується і що система зробить із результатом далі».

Є й випадок, коли отримана аналітична подія не зіставлена з окремим стандартним типом Security Center. Систему це не зупиняє: вона фіксує таку подію і зберігає додаткову інформацію про неї в метаданих. Універсальної сумісності з будь-якою аналітикою це не означає — конкретні можливості залежать від інтеграції.

Якщо ж аналіз виконує зовнішня система, їй спершу потрібно отримати відео з платформи. Для цього в архітектурі є окрема роль Media Gateway, через яку потік передається зовнішньому споживачу. Але віддати відео назовні й повернути результат назад у Security Center — дві різні інтеграційні задачі, і друга залежить від конкретного рішення.

Подія і дані — відповіді на різні питання

Одне виявлення

  • 01 · Подія

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

  • 02 · Метадані

    Метадані — на інше: що система визначила у відео і що з цього можна використати згодом.

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

Схема: з одного виявлення подія веде до реакції, а метадані — до пошуку
Малюнок 5. Подія веде до реакції, метадані — до пошуку. Два різні шляхи з одного виявлення.

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

Проєктувати треба не аналітику

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

Що саме система має дізнатися про спостережувану сцену. Які дані мають з’явитися в результаті аналізу. Що має статися з цими даними далі.

Якщо відповіді на третє немає, проєкт фактично закінчується на виявленні. Якщо є — проєктується весь ланцюг:

  1. задача
  2. об’єкт аналізу
  3. умови сцени
  4. потрібні дані
  5. джерело аналітики
  6. інтеграція
  7. наступний процес
  8. критерії приймання

Вибір конкретного рішення — остання позиція в цьому списку, а не перша.