Інженерний огляд
Genetec Security Center: як працює єдина архітектура безпеки
На великому об’єкті рідко працює лише одна система безпеки. Зазвичай паралельно існують відеоспостереження, СКУД, розпізнавання номерних знаків, охоронна сигналізація, інтеркоми. Кожна система виконує свою функцію — і окремо з цим може не бути жодних проблем.
Під час інциденту оператор бачить подію контролю доступу в одному вікні, відео — в іншому, тривогу від сигналізації — у третьому. Технічно всі системи відпрацювали правильно. Але пов’язати окремі події в одну картину все одно має людина.
Спільний інтерфейс — це ще не спільна система
Security Center створює спільний платформний рівень для різних напрямів фізичної безпеки. Серед основних — Omnicast для відеоспостереження, Synergis для контролю доступу та AutoVu для розпізнавання номерних знаків. До них можуть додаватися охоронна сигналізація, комунікації та інтеграції зі сторонніми системами.
Але важливіше не те, скільки компонентів можна підключити. Важливо, на якому рівні вони працюють разом.
Найпростіший рівень — спільний інтерфейс.
Оператор працює в одному застосунку і не перемикається між клієнтами різних виробників. Це зручно, але саме по собі ще не робить систему єдиною.
Наступний рівень — спільні сутності та події.
Камери, двері, зони, ALPR-пристрої та тривоги існують у межах спільного середовища з єдиними правами доступу, механізмами реакції та звітністю. Це зменшує потребу будувати окремі point-to-point зв’язки між підсистемами для кожного нового сценарію.
І нарешті — операційний контекст.
Подія однієї підсистеми може доповнюватися даними іншої, щоб оператору не доводилося вручну збирати картину того, що відбувається.
Саме це і відрізняє єдину платформу від простого об’єднання кількох інтерфейсів.
При цьому unified-підхід не означає, що все обладнання на об’єкті має бути одного виробника. Security Center працює з екосистемою IP-пристроїв та партнерських інтеграцій, а Synergis підтримує сторонні контролери, зчитувачі та електронні замки.
Для проєкту це важлива деталь: перехід до спільної платформи не обов’язково починається з повної заміни вже встановленої периферії. Спочатку варто зрозуміти, що з наявної інфраструктури можна зберегти і наскільки глибоко вона може працювати в новій архітектурі.
Централізувати управління — не означає централізувати всю інфраструктуру
Коли об’єктів стає більше одного, виникає наступне питання: чи потрібно збирати всі майданчики в одну фізично централізовану систему, щоб оператор міг працювати з ними як з єдиним цілим?
У Security Center для цього використовується Federation.
Окремі майданчики можуть залишатися самостійними системами Security Center — зі своєю інфраструктурою, архівом і локальною логікою. Federation підключає їх до центральної системи, звідки оператор може працювати з камерами, дверима, тривогами, ALPR та іншими доступними сутностями віддалених майданчиків.
Принциповий момент у тому, що локальні системи при цьому не перестають бути локальними. Вони продовжують працювати самостійно, а центральний рівень отримує необхідну видимість і можливості керування.
Для архітектора це дає важливе розділення двох понять:
А для presales це змінює саму постановку питання. Замість «який центральний сервер потрібен для всіх наших об’єктів?» спочатку варто визначити, які дані, події та функції мають бути доступні на центральному рівні, а що повинно залишатися локальним.
Оператору важливо знати не лише «що сталося», а й «де»
Зі зростанням системи виникає інша проблема: як не втратити контекст у великій кількості подій.
Тривога у вигляді рядка в списку відповідає лише на питання «що сталося». Оператору майже завжди потрібно знати більше: де це сталося і що знаходиться поруч.
Для цього в Security Center використовуються карти. Вони дозволяють бачити камери, двері, зони та інші об’єкти системи в їхньому фізичному контексті, локалізувати подію на плані поверху або географічній карті й одразу зрозуміти, які пристрої пов’язані з місцем події.
Замість того щоб після отримання тривоги шукати потрібну камеру чи двері в окремих списках, оператор може почати роботу з самого місця події.
Умовно цей сценарій виглядає так:
подія → місце → камера поруч → точка доступу → дія оператора.
І це ще один прояв unified-архітектури — вже не на схемі системи, а безпосередньо на робочому місці.
Коли дані однієї системи працюють в іншій
Ще наочніше принцип спільної архітектури видно на стику AutoVu і Synergis.
Розпізнаний номерний знак автомобіля може використовуватися в логіці контролю доступу як ідентифікатор. AutoVu розпізнає номер, а Synergis використовує отримані дані в access-control workflow відповідно до заданих правил доступу.
Тобто:
автомобіль → розпізнавання номера → ідентифікатор → рішення про доступ.
Цінність тут не в тому, що оператор бачить ALPR і СКУД в одному вікні.
Та сама логіка може поширюватися й на інші джерела даних — від інтеркомів до зовнішніх сенсорів. Важливий не сам факт підключення ще одного пристрою, а можливість використати його подію в спільному операційному контексті.
Питання не в кількості підключених систем
Єдина система безпеки — це не про те, скільки підсистем підключено і чи відкриваються вони в одному вікні.
Архітектурна цінність
Архітектурна цінність починається тоді, коли ці підсистеми працюють у спільному операційному контексті: дані однієї можуть доповнювати подію іншої, розподілені майданчики залишаються автономними, але доступні для централізованої роботи, а оператор бачить не лише тривогу, а й місце події та пов’язані з нею об’єкти.
Саме під цим кутом варто дивитися на Genetec Security Center. У межах платформи Omnicast, Synergis, AutoVu та інші компоненти можуть працювати як частини спільної архітектури, а не лише як окремі системи в одному інтерфейсі.
У наступних матеріалах циклу розберемо, що такий підхід змінює вже на рівні окремих задач — відеоспостереження, контролю доступу, роботи з інцидентами та відеоаналітики.
