Здраво на сите!

Веројатно не е тајна дека услугите за видео надзор во облак неодамна добиваат популарност. И јасно е зошто тоа се случува, видеото е „тешка“ содржина, чие складирање бара инфраструктура и големи количини складирање на дискот. Употребата на систем за видео надзор во просториите бара средства за работа и поддршка, како за организација која користи стотици камери за надзор, така и за индивидуален корисник со неколку камери.

Системите за видео надзор во облак го решаваат овој проблем обезбедувајќи им на клиентите постоечка инфраструктура за складирање и обработка на видео. Клиент за видео надзор во облак едноставно треба да ја поврзе камерата на Интернет и да ја поврзе со неговата сметка во облак.

Постојат неколку технолошки начини за поврзување на камерите со облакот. Несомнено, најзгодниот и најевтин метод е камерата директно да се поврзува и работи со облакот, без учество на дополнителна опрема како сервер или рекордер.

За да го направите ова, неопходно е на камерата да се инсталира софтверски модул што работи со облакот. Меѓутоа, ако зборуваме за евтини камери, тогаш тие имаат многу ограничени хардверски ресурси, кои се речиси 100% окупирани од мајчин фирмвер на продавачот на камерата и нема ресурси потребни за приклучокот за облак. Програмерите од ivideon го посветија овој проблем статью, што објаснува зошто не можат да го инсталираат додатокот на евтини камери. Како резултат на тоа, минималната цена на камерата е 5000 рубли (80 долари) и милиони пари потрошени за опрема.

Успешно го решивме овој проблем. Ако ве интересира како - добредојде на сечењето

Малку историја

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

Во однос на софтверот за камерата, во првата фаза го следевме „стандардниот“ пат за такви задачи: развивме сопствен приклучок, кој е инсталиран во стандардниот фирмвер на камерата на продавачот и работи со нашиот облак. Сепак, вреди да се напомене дека за време на дизајнот ги користевме најлесните и најефикасните решенија (на пример, обична имплементација на C на protobuf, libev, mbedtls и целосно напуштени удобни, но тешки библиотеки како засилување)

Во моментов, нема универзални решенија за интеграција на пазарот на IP-камери: секој продавач има свој начин на инсталирање на приклучокот, свој сет на API за ракување со фирмверот и уникатен механизам за ажурирање.

Ова значи дека за секој продавач на фотоапарати потребно е индивидуално да се развие сеопфатен слој на софтвер за интеграција. И во моментот на започнување на развојот, препорачливо е да се работи само со 1 продавач за да се концентрираат напорите на тимот на развивање на логиката за работа со облакот.

Првиот избран продавач беше Hikvision, еден од светските лидери на пазарот на фотоапарати, обезбедувајќи добро документиран API и компетентна инженерска техничка поддршка.

Го започнавме нашиот прв пилот-проект, видео надзор во облак Видео удобност, користејќи камери на Hikvision.

Речиси веднаш по лансирањето, нашите корисници почнаа да поставуваат прашања за можноста за поврзување на поевтини камери од други производители на услугата.

Ја одбив опцијата за имплементирање на слој за интеграција за секој продавач речиси веднаш - бидејќи е слабо скалабилен и наметнува сериозни технички барања на хардверот на камерата. Цената на камерата што ги исполнува овие влезни барања: ~60-70$

Затоа, решив да копам подлабоко - да направам свој фирмвер за камери од кој било продавач. Овој пристап значително ги намалува барањата за хардверски ресурси на камерата - затоа што Слојот за работа со облакот е многу поефективно интегриран со видео апликацијата, а во фирмверот нема непотребни неискористени масти.

И она што е важно е дека кога работите со камерата на ниско ниво, можно е да се користи хардверски AES, кој ги шифрира податоците без да создава дополнително оптоварување на процесорот со мала моќност.

Во тој момент немавме ништо. Воопшто ништо.

Речиси сите продавачи не беа подготвени да работат со нас на толку ниско ниво. Нема информации за кола и компоненти, нема официјална SDK на чипсети и документација за сензори.
Исто така, нема техничка поддршка.

Сите прашања требаше да се одговорат преку обратно инженерство - обиди и грешки. Но, успеавме.

Првите модели на камери што ги тестиравме беа Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link камери и неколку ултра евтини безимени кинески камери.

Техника

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

Xiaomi Yi Ants
Нема име

СПЦ
Hisilicon 3518E
Hisilicon 3518E

RAM меморија
64MB
64MB

ФЛЕШ
16MB
8MB

WiFi
mt7601/bcm43143
-

Сензор
ov9732 (720p)
ov9712 (720p)

Етернет
-
+

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, туку ќе замрзне во многу рана фаза на вчитување.

На почетокот, кога работевме без поддршка од продавачот, едноставно го копиравме овој блок од оригиналниот фирмвер на камерата.

Линукс кернелот и rootfs

Камерите го користат кернелот на Linux, кој е дел од SDK на чипот; обично ова не се најновите кернели од гранката 3.x, така што честопати треба да се справиме со фактот дека двигателите за дополнителна опрема не се компатибилни со користениот кернел , и мораме да ги вратиме на камерите на јадрото.

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

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

Коренот датотечен систем е поврзан со кернелот како initramfs и како резултат на изградбата добиваме една датотека uImage, кој ги содржи и кернелот и rootfs.

Видео апликација

Најкомплексниот и најинтензивен дел од фирмверот е апликацијата, која обезбедува снимање видео-аудио, кодирање видео, конфигурира параметри на сликата, имплементира видео аналитика, на пример, детектори за движење или звук, контролира PTZ и е одговорна за менување на денот и ноќни режими.

Важна, дури би рекол клучна, карактеристика е како видео апликацијата комуницира со приклучокот за облак.

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

Овде го користиме механизмот за заедничка меморија - видеото не се копира или испраќа преку приклучок помеѓу софтверските компоненти на камерата, со што оптимално и внимателно се користат скромните хардверски можности на камерата.

Ажурирајте го потсистемот

Посебна гордост е потсистемот толерантен за грешки за онлајн ажурирања на фирмверот.

Дозволете ми да го објаснам проблемот. Ажурирањето на фирмверот технички не е атомска операција и ако дојде до прекин на напојувањето на средината на ажурирањето, тогаш флеш меморијата ќе содржи дел од „не напишан“ нов фирмвер. Ако не преземете посебни мерки, тогаш камерата ќе стане „тула“ што треба да се однесе во сервисен центар.

И ние се справивме со овој проблем. Дури и ако камерата е исклучена за време на ажурирањето, таа автоматски и без интервенција на корисникот ќе го преземе фирмверот од облакот и ќе ја обнови работата.

Ајде да ја разгледаме техниката подетално:

Најранливата точка е презапишувањето на партицијата со кернелот на Linux и root датотечен систем. Ако една од овие компоненти е оштетена, камерата воопшто нема да се подигне надвор од подигнувачот на uboot, кој не може да преземе фирмвер од облакот.

Ова значи дека треба да се осигураме дека камерата има работен кернел и rootfs во секое време за време на процесот на ажурирање. Се чини дека наједноставното решение би било постојано да складирате две копии од кернелот со rootf на флеш меморија и, ако главниот кернел е оштетен, да го вчитате од резервната копија.

Добро решение - сепак, кернелот со rootfs зафаќа околу 3.5 MB, а за постојана резервна копија треба да одвоите 3.5 MB. Најевтините камери едноставно немаат толку многу слободен простор за резервно јадро.

Затоа, за да направиме резервна копија на кернелот за време на ажурирање на фирмверот, ја користиме партицијата на апликацијата.
И за да ја изберете саканата партиција со кернелот, се користат две команди bootm во uboot - на почетокот се обидуваме да го вчитаме главниот кернел и ако е оштетен, тогаш резервниот.

Ова осигурува дека во секое време камерата ќе го има точниот кернел со rootfs и ќе може да го подигне и обнови фирмверот.

CI/CD систем за градење и распоредување фирмвер

За да изградиме фирмвер, користиме gitlab CI, кој автоматски го гради фирмверот за сите поддржани модели на камери, а по изградбата на фирмверот, тој автоматски се распоредува на услугата за ажурирање на софтверот на камерата.

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

Безбедност на информации

Не е тајна дека во денешно време безбедноста на информациите е најважниот аспект на секој IoT уред, вклучувајќи ги и камерите. Ботнетите како Mirai шетаат на Интернет, инфицирајќи милиони камери со стандарден фирмвер од продавачите. Со сета почит кон продавачите на камери, не можам а да не забележам дека стандардниот фирмвер содржи многу функционалности што не се потребни за работа со облакот, но содржи многу пропусти што ги користат ботнетите.

Затоа, целата неискористена функционалност во нашиот фирмвер е оневозможена, сите tcp/udp порти се затворени, а при ажурирање на фирмверот се проверува дигиталниот потпис на софтверот.

И покрај ова, фирмверот е подложен на редовно тестирање во лабораторијата за безбедност на информации.

Заклучок

Сега нашиот фирмвер активно се користи во проекти за видео надзор. Можеби најголемиот од нив е преносот на гласањето на денот на изборот на претседателот на Руската Федерација.
Во проектот беа вклучени повеќе од 70 илјади камери со наш фирмвер, кои беа инсталирани на избирачките места во нашата земја.

Откако решивме голем број сложени, а на некои места, дури и во тоа време речиси невозможни проблеми, ние, се разбира, добивме големо задоволство како инженери, но покрај ова, заштедивме и милиони долари за купување камери. И во овој случај, заштедата не се само зборови и теоретски пресметки, туку резултати од веќе завршен тендер за набавка на опрема. Соодветно, ако зборуваме за видео надзор во облак: постојат два пристапа - стратешки потпирајте се на експертиза и развој на ниско ниво, што резултира со огромни заштеди на опрема или користете скапа опрема, која, ако ги погледнете конкретно карактеристиките на потрошувачите, практично не е различни од сличните евтини.

Зошто е стратешки важно да се одлучи за изборот на пристапот за интеграција што е можно порано? Кога развиваат приклучок, програмерите се потпираат на одредени технологии (библиотеки, протоколи, стандарди). И ако збир на технологии се избере само за скапа опрема, тогаш во иднина обидот да се префрли на евтини камери, најверојатно, ќе потрае лудо долго време или дури и ќе пропадне и ќе се случи враќање на скапата опрема.

Извор: www.habr.com