Камери відеоспостереження – як змусити їх працювати?

Під катом – одразу до справи.

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

Модулі тісно взаємодіють між собою на основі різноманітних технологій (в основному – JSON, REST API та SOAP). Самі ж модулі реалізовано на різних мовах (Java, C#, Java Script та інші), із використанням фреймворків (ASP.NET Web API, WCF, NLog, Entity Framework, MySQL ADO.NET managed drivers, Unity 3, EPPlus, Json.NET, EmitMapper, DotNetZip, jQuery, knockoutjs, Moment.js, underscore.js тощо).

Все це програмне розмаїття  функціонує під управлінням різноманітних операційних систем (Windows Server, SUSE Linux Enterprise Server, CentOS тощо) у середовищі віртуалізації VMware vSphere 5.

Всі модулі мають власні механізми відмовостійкості та балансування. Для цього використовуються кластерні технології, різноманітні варіанти балансування HTTP-запитів на основі nginx, а також управління чергами та пріоритетами на прикладному рівні. Окрім цього, всі модулі об’єднані за принципом слабкої пов’язаності, що суттєво підвищує можливості розвитку та модифікації системи в цілому.

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

Опис основних компонентів системи

Відеоядро, що забезпечує отримання та обробку відеопотоків, являє собою кілька сотень відеосерверів, які працюють на ресурсах виділених віртуальних машин під управлінням Linux, що забезпечують приймання відеотрафіка із кодерів та інших систем формування відеопотоку. Прийом трафіка здійснюється за протоколом RTSP (відео у форматі H.264), схема прийому трафіка може використовуватися різноманітна – на постійній основі із настроюваною глибиною запису (періодом зберігання) або за запитом в разі необхідності простого перегляду відео. Такий гнучкий підхід дозволяє економити як серверні ресурси, так і знижувати завантаженість каналів зв’язку.

В якості протоколу транспортного рівня в основному використовується TCP, але в ряді випадків може використовуватися і UDP. Відеосервери виконують декілька задач:

– Основну: отримання відеопотоку, його запис та подальшу видачу потокового або архівного відео серверам ретрансляції або довготривале зберігання частини архівного відео на окремому виділеному сховищі;
– Ряд додаткових: контроль доступності відеоджерела, контроль отримання та відповідності відеопотоку заданим параметрам (fps, bitrate, втрати пакетів), а також через спеціалізовані шини обміну даними інформація від відеосерверів поступає до системи контролю надання послуги для подальшого обліку та передачі до служби експлуатації.

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

Рестримінг – сервери ретрансляції – пов’язуюча ланка між відеоядром (що здійснюють первинний прийом відео та його запис) та користувачами (по суті основними споживачами відеоконтенту). Вбудовані механізми реінкапсуляції та дистрибуції потокового відео дозволяє забезпечувати ретрансляцію «живого» та архівного відеоконтенту на ПК та портативні пристрої (планшети, телефони). Рестримінг також може забезпечувати потокову видачу відеоконтенту по RTSP для додаткових систем, наприклад, для систем відеоаналітики або системи управління транскодуванням, – адже користувачі інколи потребують і «стислий» відеопотік, якщо раптом «просів» канал, а подивитись відео вкрай хочеться. Також користувачі можуть скористатися і спеціальним режимом перегляду у вигляді слайд-шоу. Сервери ретрансляції працюють в кластері та підтримують режим динамічного резервування, а також ізолюють відеоядро від можливих сплесків створюваного користувачами навантаження.

Інтерфейс користувача – веб-інтерфейс (front-end) забезпечує авторизований доступ для декількох десятків тисяч зареєстрованих користувачів до системи відеоспостереження та надає широкий набір різноманітних функціональних можливостей, доступних з будь-якої точки корпоративної мережі, а у ряді випадків і через закриті виділені Інтернет-ресурси.

Робота забезпечується в середовищі різноманітних операційних систем (Windows, MacOS, Linux) на всіх основних браузерах, що суттєво полегшує організацію робочих місць. Також підтримується робота і з ряду мобільних пристроїв, наприклад, на базі iOS.

Функціональні можливості достатньо різноманітні – починаючи від звичайного перегляду потокового  та архівного відео (через flash-плеєр на ПК і нативні засоби на iOS) та управління PTZ-функціями камер, пошукових механізмів із прив’язками до різних шарів картографії та інтеграції з даними систем міста, і до виконання гнучкої рольової моделі, формування персонального, призначеного для користувача, інтерфейсу та вбудованих механізмів навчання користувачів.

Front-end використовує такі технології як RequireJS, knockout, lodash, leaflet та інші. Back-end побудовано за модульним принципом, який дозволяє забезпечувати необхідний рівень резервування та масштабування компонентів, використовується система управління конфігураціями. ПО та технології: Java/Tomcat, MariaDB, RabbitMQ та ряд інших.

Шлюз інтеграції – набір модулів підсистем, які забезпечують ізоляцію зовнішніх споживачів інформації від ядра системи. Видає різноманітну інформацію зовнішнім системам після проходження авторизації та з урахуванням заданих повноважень (тобто доступного об’єму даних та функціональних можливостей). Функціонує три основних логічних компоненти:

• Компонент сервісної взаємодії – це HTTP API, через який забезпечується видача заданого набору інформації (найменування камер, адреси та координати розміщення, скріншоти та інша супровідна інформація).
• Компонент ретрансляції– призначений для мінімізації навантаження на відеоядро та надання трансляції відеопотоків зовнішнім системам (підтримуються мовлення на flash, а також HLS для iOS-пристроїв). Відеоядро та сервери рестримінгу мають функціональність CDN, а даний компонент працює як додаткова CDN- ланка розповсюдження відеоконтенту.
• Компонент надання інтерфейса– передбачений для встроювання до зовнішніх систем в якості готового інтерфейса відтворення потокової та архівної відеоінформації, наприклад, шляхом вбудовування через iframe та простої кастомізації (настройки візуального представлення – кольору, необхідні функціональні кнопки тощо) через прості параметризовані виклики.

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

Для надання користувачам доступу до камер системи відеоспостереження існує цілий комплекс взаємопов’язаних компонентів, що забезпечують аутентифікацію та авторизацію користувачів, пріоритизацію доступу до функцій PTZ-управління, протоколювання дій користувачів та взаємодія окремих модулів.

Система підтримує два види аутентифікації: із використанням облікових записів користувачів ЕЦХД та із використанням єдиної системи управління доступу до ресурсів. При цьому, для одного фізичного користувача можливе використання поєднань різноманітних видів аутентифікації. Ключова аутентифікація інформації користувачів ЕЦХД зберігається в Active Directory, а вся додаткова інформація – в БД Microsoft SQL.

Всі паролі, зрозуміло, передаються між модулями в зашифрованому вигляді. Або не передаються взагалі.

Надання повноважень та пріоритетів доступу реалізовано на основі єдиної для всіх модулів рольової моделі, яка дозволяє надавати доступ не лише до камер відеонагляду, але й до окремих функцій системи. На поточний момент в системі існує більше 100 різноманітних повноважень: доступ до «живої» трансляції, можливість перегляду та експорту архіву фото- та відеозображень, PTZ-управління, внесення змін до окремих системних реєстрів, а також довідники, створення розкладу для отримання знімків, створення маршрутів патрулювання, можливість доступу з мобільних пристроїв та багато іншого. Система постійно розвивається: підключаються нові групи користувачів зі своїми задачами та додавання нових повноважень до системи відбувається, фактично, на льоту.

Додатково існує декілька рівнів пріоритетів для різноманітних груп користувачів та системних сервісів, що дозволяє уникати конфліктів між різними групами користувачів та «прозоро» перехоплювати PTZ-управління камерами, забезпечувати управління в режимах патрулювання або розміщати зону огляду за розкладом.

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

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