Здравейте на всички!

Вероятно за никого не е тайна, че облачните услуги за видеонаблюдение набират популярност през последните години. И е разбираемо защо това се случва, видеото е „тежко“ съдържание, което изисква инфраструктура и големи количества дисково пространство за съхранение. Използването на локална система за видеонаблюдение изисква средства за работа и поддръжка, както в случай на организация, използваща стотици камери за наблюдение, така и в случай на отделен потребител с няколко камери.

Облачните системи за видеонаблюдение решават този проблем, като предоставят на клиентите съществуваща инфраструктура за съхранение и обработка на видео. Клиентът за облачно видеонаблюдение просто трябва да свърже камерата към интернет и да я свърже към своя облачен акаунт.

Има няколко технологични начина за свързване на камери към облака. Несъмнено най-удобният и евтин начин - камерата се свързва директно и работи с облака, без участието на допълнително оборудване като сървър или регистратор.

За да направите това, е необходимо софтуерният модул, работещ с облака, да е инсталиран на камерата. Ако обаче говорим за евтини камери, тогава те имат много ограничени хардуерни ресурси, които са почти 100% заети от родния фърмуер на производителя на камерата, но няма ресурси, необходими за облачния плъгин. Разработчици от ivideon, посветени на този проблем Статия, което обяснява защо не могат да инсталират плъгина на евтини камери. В резултат на това минималната цена на камерата е 5000 рубли ($80 долара) и милиони пари, похарчени за оборудване.

Ние успешно решихме този проблем. Ако ви интересува как - добре дошли под котката

Малко история

През 2016 г. започнахме да разработваме облачна платформа за видеонаблюдение за Ростелеком.

По отношение на софтуера на камерата, на първия етап следвахме „стандартния“ път за такива задачи: разработихме собствен плъгин, който е инсталиран в стандартния фърмуер на камерата на доставчика и работи с нашия облак. Заслужава обаче да се отбележи, че по време на дизайна използвахме най-леките и ефективни решения (например обикновена C реализация на protobuf, libev, mbedtls и напълно изоставени удобни, но тежки библиотеки като boost)

Сега на пазара на IP камери няма универсални решения за интеграция: всеки доставчик има свой собствен начин за инсталиране на приставката, свой собствен набор от API за работа с фърмуера и уникален механизъм за актуализиране.

Това означава, че за всеки доставчик на камера е необходимо индивидуално да се разработи обемен слой софтуер за интеграция. И в момента на започване на разработката е препоръчително да работите само с 1 доставчик, за да фокусирате усилията на екипа върху развитието на логиката на работа с облака.

Hikvision беше избран за първия доставчик, един от световните лидери на пазара на камери, предоставящ добре документиран API и компетентна инженерна техническа поддръжка.

Стартирахме първия си пилотен проект, облачно видеонаблюдение Video Comfort, използвайки камери Hikvision.

Почти веднага след стартирането нашите потребители започнаха да задават въпроси относно възможността за свързване на по-евтини камери от други производители към услугата.

Изхвърлих почти веднага опцията за внедряване на интеграционен слой за всеки доставчик - тъй като е слабо скалируем и налага сериозни технически изисквания към хардуера на камерата. Цената на камера, която отговаря на тези изисквания на входа: ~ 60-70 $

Затова реших да копая по-дълбоко - да направя свой собствен фърмуер за камери на всякакви доставчици. Този подход значително намалява изискванията за хардуерни ресурси на камерата. облачният слой е с порядък по-ефективно интегриран с видео приложението и няма допълнителна неизползвана мазнина във фърмуера.

И което е важно, когато работите с камера на ниско ниво, е възможно да използвате хардуерен AES, който криптира данните, без да създава допълнително натоварване на процесора с ниска мощност.

В този момент нямахме абсолютно нищо. Нищичко.

Почти всички доставчици не бяха готови да работят с нас на такова ниско ниво. Няма информация за схемите и компонентите, няма официален SDK на чипсети и сензорна документация.
Няма и техническа поддръжка.

На всички въпроси трябваше да се отговори чрез обратно инженерство — проба-грешка. Но успяхме.

Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link камери и няколко супер евтини неназовани китайски камери бяха първите модели камери, на които напълнихме неравности.

Техника

Камери, базирани на чипсет Hisilicon 3518E. Хардуерните характеристики на камерите са както следва:

Xiaomi Yi Ants
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
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 мегабайта RAM.

Освен това до uboot има специален блок, наречен reg_info, който съдържа DDR инициализиращ скрипт на ниско ниво и редица SoC системни регистри. Съдържание reg_info зависи от модела на камерата и ако не е правилен, тогава камерата дори няма да може да зареди uboot, но ще виси на много ранен етап на зареждане.

Първоначално, когато работихме без поддръжка на доставчика, ние просто копирахме този блок от оригиналния фърмуер на камерата.

Linux ядро ​​и rootfs

Камерите използват ядрото на Linux, което е част от SDK на чипа; обикновено това не са най-новите ядра от клона 3.x, така че често трябва да се справяме с факта, че драйверите за допълнително оборудване не са съвместими с използваното ядро и ние трябва да ги портираме обратно към камерите на ядрото.

Друг проблем е размерът на ядрото. Когато размерът на FLASH е само 8 MB, тогава всеки байт се брои и нашата задача е внимателно да деактивираме всички неизползвани функции на ядрото, за да намалим размера до минимум.

Rootfs е основна файлова система. Включва busybox, драйвери за wifi модул, набор от стандартни системни библиотеки, като напр libld и libc, както и софтуер на наша собствена разработка, който отговаря за логиката за управление на LED, управление на мрежовите връзки и актуализации на фърмуера.

Основната файлова система е свързана с ядрото като initramfs и в резултат на изграждането получаваме един файл uImage, който съдържа както ядрото, така и rootfs.

Видео приложение

Най-сложната и ресурсоемка част от фърмуера е приложение, което осигурява видео-аудио заснемане, видео кодиране, конфигурира параметри на изображението, прилага видео анализи, като детектори за движение или звук, контролира PTZ и отговаря за превключването на дневни и нощни режими .

Важна, дори бих казал ключова, функция е как видео приложението взаимодейства с облачната добавка.

В традиционните решения „фърмуер на доставчика + облачен плъгин“, които не могат да работят на евтин хардуер, видеото вътре в камерата се предава чрез протокола RTSP – и това е огромен излишък: копиране и предаване на данни чрез сокет, ненужни системни извиквания.

На този етап ние използваме механизма на споделената памет - видеото не се копира или изпраща през сокет между компонентите на софтуера на камерата, като по този начин оптимално и внимателно използва скромните хардуерни възможности на камерата.

Актуализиране на подсистемата

Предмет на отделна гордост е устойчивата на грешки подсистема за онлайн актуализации на фърмуера.

Нека обясня проблема. Актуализирането на фърмуера технически не е атомарна операция и ако в средата на актуализацията възникне прекъсване на захранването, тогава флаш паметта ще съдържа част от „подписания“ нов фърмуер. Ако не вземете специални мерки, тогава камерата ще се превърне в „тухла“, която трябва да бъде занесена в сервиз.

Справихме се и с този проблем. Дори ако камерата е изключена по време на актуализацията, тя автоматично и без намеса на потребителя ще изтегли фърмуера от облака и ще възстанови работата.

Нека анализираме техниката по-подробно:

Най-уязвимата точка е презаписването на дяла с ядрото на Linux и основната файлова система. Ако един от тези компоненти е повреден, фотоапаратът изобщо няма да се зареди извън буутлоудъра uboot, който не може да изтегли фърмуер от облака.

Това означава, че трябва да гарантираме, че камерата има работещо ядро ​​и rootfs по всяко време на процеса на актуализиране. Изглежда, че най-простото решение би било постоянно да съхранявате две копия на ядрото с rootfs във флаш памет и в случай на повреда на основното ядро ​​да го заредите от резервното копие.

Добро решение - обаче ядрото с rootfs отнема около 3.5 MB и 3.5 MB трябва да бъдат разпределени за постоянно архивиране. На най-евтините камери просто няма толкова много свободно място за резервни ядра.

Следователно, за да архивираме ядрото по време на актуализация на фърмуера, ние използваме дяла на приложението.
И за да изберете желания дял с ядрото, се използват две команди bootm в uboot - в началото се опитваме да заредим основното ядро ​​и ако е повредено, тогава резервното.

Това гарантира, че във всеки един момент камерата ще има правилното ядро ​​с rootfs и ще може да зарежда и възстановява фърмуера.

CI/CD система за изграждане и внедряване на фърмуер

За да изградим фърмуер, ние използваме gitlab CI, който автоматично изгражда фърмуер за всички поддържани модели камери и след изграждането на фърмуера той автоматично се внедрява в услугата за актуализиране на софтуера на камерата.

От услугата актуализациите на фърмуера се доставят до нашите тестови камери за QA и след завършване на всички етапи на тестване, до камерите на потребителите.

Информационна сигурност

Не е тайна, че в днешно време информационната сигурност е най-важният аспект на всяко IoT устройство, включително камерите. Ботнет мрежи като Mirai бродят в интернет, заразявайки милиони камери със стандартен фърмуер от доставчици. С цялото ми уважение към производителите на камери, не мога да не отбележа, че стандартният фърмуер съдържа много функционалности, които не са необходими за работа с облака, но съдържа много уязвимости, от които се възползват ботнет мрежите.

Поради това цялата неизползвана функционалност в нашия фърмуер е деактивирана, всички tcp / udp портове са затворени и при актуализиране на фърмуера се проверява цифровият подпис на софтуера.

И освен това, фърмуерът се подлага на редовно тестване в лабораторията за информационна сигурност.

Заключение

Сега нашият фърмуер се използва активно в проекти за видеонаблюдение. Може би най-големият от тях е излъчването на гласуване в деня на изборите за президент на Руската федерация.
В проекта участваха над 70 хиляди камери с наш фърмуер, които бяха монтирани в избирателните секции у нас.

След като решихме редица сложни и на места дори почти невъзможни по това време задачи, ние, разбира се, получихме голямо удовлетворение като инженери, но освен това спестихме милиони долари от закупуването на камери. И в този случай спестяванията не са само думи и теоретични изчисления, а резултатите от вече проведен търг за закупуване на оборудване. Съответно, ако говорим за облачно видеонаблюдение: има два подхода - да се разчита стратегически на ниско ниво на експертиза и развитие, което води до огромни спестявания на оборудване, или да се използва скъпо оборудване, което, ако погледнете конкретно потребителските характеристики, е практически не се различава от подобни евтини.

Защо е стратегически важно да се вземе решение за избора на интеграционен подход възможно най-рано? Когато разработват плъгин, разработчиците разчитат на определени технологии (библиотеки, протоколи, стандарти). И ако набор от технологии е избран само за скъпо оборудване, тогава в бъдеще опитът за преминаване към евтини камери най-вероятно ще отнеме безумно много време или дори ще се провали и ще се върне към скъпо оборудване.

Източник: www.habr.com