Всім привіт!

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

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

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

Для цього необхідно, щоб на камері було встановлено модуль ПЗ, що працює з хмарою. Однак, якщо говорити про дешеві камери, то вони дуже обмежені апаратні ресурси, які майже на 100% займає рідна прошивка вендора камери, а ресурсів необхідних для хмарного плагіна — ні. Цій проблемі розробники з ivideon присвятили статтю, в якій говориться, чому вони не можуть встановити плагін на дешеві камери. Як результат, мінімальна ціна камери — 5000р ($80 доларів) та мільйони витрачених грошей на обладнання.

Ми цю проблему успішно вирішили. Якщо цікаво як - велком під кат

Трохи історії

У 2016 році ми розпочали розробку платформи хмарного відеоспостереження для Ростелекому.

У частині ПЗ камер на першому етапі пішли «стандартним» для таких завдань шляхом: розробили свій плагін, який встановлюється у штатну прошивку камери вендора та працює з нашою хмарою. Однак, варто зазначити, що при проектуванні ми використовували найбільш легковажні та ефективні рішення (наприклад, plain C реалізацію protobuf, libev, mbedtls та повністю відмовилися від зручних, але важких бібліотек типу boost)

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

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

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

На камерах Hikvision ми запустили наш перший пілотний проект хмарний відеоспостереження Відеокомфорт.

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

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

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

І що важливо, при роботі з камерою на низькому рівні можна використовувати апаратний AES, який шифрує дані, не створюючи додаткового навантаження на малопотужний CPU.

У той момент у нас взагалі нічого не було. Взагалі нічого.

Практично всі вендори були готові працювати з нами на такому низькому рівні. Інформації про схемотехніку та компоненти – ні, офіційних SDK чіпсетів та документації сенсорів – немає.
Технічної підтримки також немає.

Відповіді на всі питання доводилося отримувати реверс інжинірингом методом проб і помилок. Але ми впоралися.

Першими моделями камер, на яких ми набивали шишки стали камери Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link і дещо дешевих безіменних китайських камер.

Техніка

Камери на чіпсеті Hisilicon 3518E. Апаратні характеристики камер такі:

Xiaomi Yi Ants
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

Оперативна пам'ять
64MB
64MB

FLASH
16MB
8MB

Wi-Fi
mt7601/bcm43143
-

датчик
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Мікрофон
+
+

Гучномовець
+
+

IRLed
+
+

IRCut
+
+

З них ми розпочинали.

Зараз підтримуємо чіпсети Hisilicon 3516/3518, а також Ambarella S2L/S2LM. Кількість моделей камер – десятки.

Склад прошивки

підводний човен

uboot - це початковий завантажувач, після включення живлення завантажується першим, ініціалізує обладнання та завантажує ядро ​​linux.

Скрипт завантаження камери досить тривіальний:

bootargs=mem=38M console=ttyAMA0,115200 rootfstype=ramfs mtdparts=hi_sfc:256K(boot),64K(tech),4096K(kernel),8192K(app),-(config) hw_type=101
bootcmd=sf probe 0; sf read 0x82000000 0x50000 0x400000; bootm 0x82000000; setenv bootargs $(bootargs) bkp=1; sf read 0x82000000 0x450000 0x400000; bootm 0x82000000

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

Зверніть увагу на рядок mem=38M. Так, так, це не друкарська помилка - ядру Linux і всім-усім додаткам доступно всього лише 38 мегабайт оперативної пам'яті.

Також поруч із uboot знаходиться спеціальний блок, званий reg_info, В якому знаходиться низькорівневий скрипт ініціалізації DDR та ряду системних регістрів SoC. Вміст reg_info залежить від моделі камери, і якщо вона буде не коректною, то камера навіть не зможе завантажити uboot, а зависне на ранньому етапі завантаження.

Перший час, коли ми працювали без підтримки вендорів, ми просто копіювали цей блок із оригінальної прошивки камери.

Ядро linux та rootfs

На камерах використовується ядро ​​Linux, що входить до складу SDK чіпа, зазвичай це не найсвіжіші ядра з гілки 3.x, тому часто доводиться стикатися з тим, що драйвера додаткового обладнання не сумісні з ядром, що використовується, і нам доводиться їх бек-портувати під ядро камери.

Інша проблема – це розмір ядра. Коли розмір FLASH всього 8MB, то кожен байт на рахунок і наше завдання — акуратно відключити всі функції ядра, що не використовуються, щоб скоротити розмір до мінімуму.

Rootfs – це базова файлова система. До неї включені busybox, драйвера wifi модуля, набір стандартних системних бібліотек, типу libld и libc, а також ПЗ нашої розробки, що відповідає за логіку управління світлодіодами, управління мережевими підключеннями та за оновлення прошивки.

Коренева файлова система підключена до ядра як initramfs і в результаті збирання ми отримуємо один файл uImage, в якому є ядро ​​і rootfs.

Відео додаток

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

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

У традиційних рішеннях 'прошивка вендора + хмарний плагін', які не можуть працювати на дешевому залозі, відео всередині камери передається за протоколом RTSP - а це величезний оверхед: копіювання та передача даних через socket, зайві syscall-и.

Ми в цьому місці використовуємо механізм shared memory - відео не копіюється і не пересилається через socket між компонентами камери, тим самим оптимально і дбайливо використовуючи скромні апаратні можливості камери.

Підсистема оновлення

Предмет окремої гордості - підсистема fault-tolerant онлайн оновлення прошивки.

Поясню проблематику. Оновлення прошивки - це технічно не атомарна операція і якщо посередині оновлення відбудеться збій живлення, то на флеш пам'яті буде частина "недозаписаної" нової прошивки. Якщо не вжити спеціальних заходів, то камера після цього стане «цеглою», яку потрібно нести до сервісного центру.

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

Розберемо техніку докладніше:

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

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

Придатне рішення - однак, ядро ​​з rootfs займає близько 3.5MB і для постійної резервної копії потрібно виділити 3.5MB. На найдешевших камерах просто нема стільки вільного місця під backup ядра.

Тому для backup ядра під час оновлення прошивки використовуємо application партію.
А для вибору потрібної партиції з ядром якраз і використовують дві команди bootm в uboot — спочатку намагаємося завантажити основне ядро ​​і якщо воно пошкоджене, то резервне.

Це гарантує, що в будь-який час на камері буде коректне ядро ​​з rootfs, і вона зможе завантажитися і відновити прошивку.

CI/CD система складання та деплою прошивок

Для складання прошивок ми використовуємо gitlab CI, в якому автоматично збираються прошивки під всі моделі камер, що підтримуються, після складання прошивки автоматично деплояться на сервіс оновлення ПЗ камер.

З сервісу оновлення програмного забезпечення прошивки доставляються на тестові камери наших QA, а після завершення всіх етапів тестування і на камери користувачів.

Інформаційна безпека

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

Тому весь функціонал, що не використовується, в нашій прошивці відключений, всі tcp/udp порти закриті і при оновленні прошивки перевіряється цифровий підпис ПЗ.

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

Висновок

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

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

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

Джерело: habr.com