Усім прывітанне!

Мусіць, ні для каго не сакрэт, што ў апошні час хмарныя сэрвісы відэаназірання набіраюць папулярнасць. І зразумела чаму так адбываецца, відэа - гэта "цяжкі" кантэнт, для захоўвання якога неабходна інфраструктура і вялікія аб'ёмы дыскавага сховішча. Выкарыстанне лакальнай сістэмы відэаназірання патрабуе сродкаў на эксплуатацыю і падтрымку, як у выпадку арганізацыі, якая выкарыстоўвае сотні камер назірання, так і ў выпадку індывідуальнага карыстальніка з некалькімі камерамі.

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

Ёсць некалькі тэхналагічных спосабаў падлучэння камер да воблака. Бясспрэчна, найбольш зручны і танны спосаб - камера напрамую падключаецца і працуе з воблакам, без удзелу дадатковага абсталявання тыпу сервера або рэгістратара.

Для гэтага неабходна, каб на камеры быў усталяваны модуль ПА які працуе з воблакам. Аднак, калі казаць пра танныя камеры, то ў іх вельмі абмежаваныя апаратныя рэсурсы, якія амаль на 100% займае родная прашыўка вендара камеры, а рэсурсаў неабходных для хмарнага плагіна – не. Гэтай праблеме распрацоўшчыкі з ivideon прысвяцілі артыкул, у якой гаворыцца чаму яны не могуць усталяваць убудову на танныя камеры. Як вынік, мінімальны кошт камеры - 5000р ($80 даляраў) і мільёны выдаткаваных грошай на абсталяванне.

Мы гэтую праблему паспяхова вырашылі. Калі цікава як - велком пад кат

Трохі гісторыі

У 2016 годзе мы стартавалі распрацоўку платформы хмарнага відэаназірання для Растэлекама.

У частцы ПА камер на першым этапе пайшлі "стандартным" для такіх задач шляхам: распрацавалі сваю ўбудову, які ўсталёўваецца ў штатную прашыўку камеры вендара і працуе з нашым воблакам. Аднак, варта адзначыць, што пры праектаванні мы выкарыстоўвалі найболей легкаважныя і эфектыўныя рашэнні (напрыклад, plain C рэалізацыю protobuf, libev, mbedtls і цалкам адмовіліся ад зручных, але цяжкіх бібліятэк тыпу boost)

Цяпер на рынку IP камер няма ўніверсальных рашэнняў па інтэграцыі: у кожнага вендара свой спосаб усталёўкі плагіна, свой набор API для працы прашыўкі і ўнікальны механізм абнаўлення.

Гэта азначае, што для кожнага вендара камер неабходна індывідуальна распрацоўваць аб'ёмны пласт інтэграцыйнага ПА. І на момант старту распрацоўкі мэтазгодна працаваць толькі з 1-ым вендарам, каб засяродзіць намаганні каманды на распрацоўцы логікі працы з воблакам.

Першым вендарам быў абраны 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

RAM
64MB
64MB

FLASH
16MB
8MB

Wi-Fi
mt7601/bcm43143
-

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

Ethernet
-
+

MicroSD
+
+

Мікрафон
+
+

Гучнагаварыцель
+
+

IRLed
+
+

IRCut
+
+

З іх мы пачыналі.

Цяпер падтрымліваем чыпсэты Hisilicon 3516/3518, а гэтак жа Ambarella S2L/S2LM. Колькасць мадэляў камер – дзясяткі.

Склад прашыўкі

uboot

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.

Video application

Найбольш складаная і рэсурсаёмістая частка прашыўкі - дадатак, якое забяспечвае відэа-аўдыё захоп, кадаваньне відэа, наладжвае параметры карцінкі, рэалізуе відэа-аналітыкі, напрыклад, дэтэктары руху або гуку, кіруе 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