Kumusta sa lahat!

Malamang na hindi lihim na ang mga serbisyo ng cloud video surveillance ay nakakakuha ng katanyagan kamakailan. At malinaw kung bakit ito nangyayari, ang video ay "mabigat" na nilalaman, ang imbakan na nangangailangan ng imprastraktura at malaking halaga ng imbakan ng disk. Ang paggamit ng on-premises na video surveillance system ay nangangailangan ng mga pondo para gumana at suportahan, para sa isang organisasyong gumagamit ng daan-daang surveillance camera at para sa isang indibidwal na user na may ilang camera.

Nilulutas ng mga cloud video surveillance system ang problemang ito sa pamamagitan ng pagbibigay sa mga customer ng isang umiiral nang imprastraktura ng pag-imbak at pagproseso ng video. Kailangan lang ikonekta ng cloud video surveillance client ang camera sa Internet at i-link ito sa kanyang cloud account.

Mayroong ilang mga teknolohikal na paraan upang ikonekta ang mga camera sa cloud. Walang alinlangan, ang pinaka-maginhawa at pinakamurang paraan ay ang camera ay direktang kumokonekta at gumagana sa cloud, nang walang paglahok ng karagdagang kagamitan tulad ng isang server o recorder.

Upang gawin ito, kinakailangan na ang isang software module na gumagana sa cloud ay mai-install sa camera. Gayunpaman, kung pag-uusapan natin ang tungkol sa mga murang camera, kung gayon mayroon silang napakalimitadong mapagkukunan ng hardware, na halos 100% ay inookupahan ng katutubong firmware ng vendor ng camera, at walang mga mapagkukunang kinakailangan para sa cloud plugin. Inilaan ng mga developer mula sa ivideon ang problemang ito isang artikulo, na nagpapaliwanag kung bakit hindi nila mai-install ang plugin sa mga murang camera. Bilang resulta, ang pinakamababang presyo ng camera ay 5000 rubles ($80 dollars) at milyon-milyong pera na ginugol sa kagamitan.

Matagumpay naming nalutas ang problemang ito. Kung interesado ka sa kung paano - maligayang pagdating sa hiwa

Ang isang maliit na kasaysayan

Noong 2016, nagsimula kaming bumuo ng cloud video surveillance platform para sa Rostelecom.

Sa mga tuntunin ng software ng camera, sa unang yugto ay sinundan namin ang "standard" na landas para sa mga naturang gawain: bumuo kami ng aming sariling plugin, na naka-install sa karaniwang firmware ng camera ng vendor at gumagana sa aming cloud. Gayunpaman, ito ay nagkakahalaga ng noting na sa panahon ng disenyo ginamit namin ang pinaka magaan at mahusay na mga solusyon (halimbawa, plain C na pagpapatupad ng protobuf, libev, mbedtls at ganap na inabandunang maginhawa ngunit mabibigat na mga aklatan tulad ng boost)

Sa kasalukuyan, walang mga unibersal na solusyon sa pagsasama sa merkado ng IP camera: ang bawat vendor ay may sariling paraan ng pag-install ng plugin, sarili nitong hanay ng mga API para sa pagpapatakbo ng firmware, at isang natatanging mekanismo ng pag-update.

Nangangahulugan ito na para sa bawat vendor ng camera ay kinakailangan na indibidwal na bumuo ng isang komprehensibong layer ng software ng pagsasama. At sa oras ng pagsisimula ng pag-unlad, ipinapayong makipagtulungan lamang sa 1 vendor upang ituon ang mga pagsisikap ng koponan sa pagbuo ng lohika para sa pagtatrabaho sa cloud.

Ang unang vendor na napili ay ang Hikvision, isa sa mga pinuno ng mundo sa merkado ng camera, na nagbibigay ng isang mahusay na dokumentado na API at karampatang suporta sa teknikal na engineering.

Inilunsad namin ang aming unang pilot project, ang cloud video surveillance na Video Comfort, gamit ang mga Hikvision camera.

Halos kaagad pagkatapos ng paglunsad, nagsimulang magtanong ang aming mga user tungkol sa posibilidad ng pagkonekta ng mga mas murang camera mula sa ibang mga tagagawa sa serbisyo.

Tinanggihan ko ang opsyon na magpatupad ng integration layer para sa bawat vendor halos kaagad - dahil ito ay hindi gaanong nasusukat at nagpapataw ng mga seryosong teknikal na kinakailangan sa hardware ng camera. Ang halaga ng isang camera na nakakatugon sa mga kinakailangan sa input na ito: ~60-70$

Samakatuwid, nagpasya akong maghukay ng mas malalim - upang gumawa ng sarili kong firmware para sa mga camera mula sa anumang vendor. Ang diskarte na ito ay makabuluhang binabawasan ang mga kinakailangan para sa mga mapagkukunan ng hardware ng camera - dahil Ang layer para sa pagtatrabaho sa cloud ay mas epektibong isinama sa application ng video, at walang hindi kinakailangang hindi nagamit na taba sa firmware.

At ang mahalaga ay kapag nagtatrabaho sa camera sa mababang antas, posibleng gumamit ng hardware na AES, na nag-e-encrypt ng data nang hindi gumagawa ng karagdagang pagkarga sa mababang-power na CPU.

Sa sandaling iyon ay wala kaming lahat. Wala naman.

Halos lahat ng mga vendor ay hindi handang makipagtulungan sa amin sa mababang antas. Walang impormasyon tungkol sa circuitry at mga bahagi, walang opisyal na SDK ng mga chipset at dokumentasyon ng sensor.
Wala ring teknikal na suporta.

Kailangang sagutin ang lahat ng tanong sa pamamagitan ng reverse engineering—trial and error. Pero nakayanan namin.

Ang mga unang modelo ng camera na sinubukan namin ay ang Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link camera at ilang ultra-cheap na walang pangalan na Chinese camera.

Pamamaraan

Mga camera batay sa Hisilicon 3518E chipset. Ang mga katangian ng hardware ng mga camera ay ang mga sumusunod:

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
+
+

mikropono
+
+

Nagsasalita
+
+

IRLed
+
+

IRCut
+
+

Nagsimula kami sa kanila.

Kasalukuyan naming sinusuportahan ang Hisilicon 3516/3518 chipset, pati na rin ang Ambarella S2L/S2LM. Mayroong dose-dosenang mga modelo ng camera.

Komposisyon ng firmware

submarino

Ang uboot ay ang boot loader, nagbo-boot muna ito pagkatapos ng power on, nag-initialize ng hardware at naglo-load ng linux kernel.

Ang script ng paglo-load ng camera ay medyo walang halaga:

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

Ang isa sa mga tampok ay na ito ay tinatawag na dalawang beses bootm, higit pa tungkol dito sa ibang pagkakataon, kapag nakarating na tayo sa subsystem ng pag-update.

Bigyang-pansin ang linya mem=38M. Oo, oo, hindi ito isang typo - ang Linux kernel at lahat, lahat, lahat ng mga application ay may access sa 38 megabytes lamang ng RAM.

Gayundin sa tabi ng uboot mayroong isang espesyal na bloke na tinatawag reg_info, na naglalaman ng isang mababang antas ng script para sa pagsisimula ng DDR at isang bilang ng mga rehistro ng system ng SoC. Nilalaman reg_info depende sa modelo ng camera, at kung ito ay hindi tama, ang camera ay hindi rin makakapag-load ng uboot, ngunit mag-freeze sa pinakaunang yugto ng pag-load.

Noong una, noong nagtrabaho kami nang walang suporta sa vendor, kinopya lang namin ang block na ito mula sa orihinal na firmware ng camera.

Linux kernel at rootfs

Ginagamit ng mga camera ang Linux kernel, na bahagi ng SDK ng chip; kadalasan ay hindi ito ang pinakabagong mga kernel mula sa 3.x branch, kaya madalas nating harapin ang katotohanan na ang mga driver para sa karagdagang kagamitan ay hindi tugma sa kernel na ginamit. , at kailangan nating i-back-port ang mga ito sa mga kernel camera.

Ang isa pang isyu ay ang laki ng kernel. Kapag ang laki ng FLASH ay 8MB lamang, ang bawat byte ay mabibilang at ang aming gawain ay maingat na huwag paganahin ang lahat ng hindi nagamit na mga function ng kernel upang mabawasan ang laki sa pinakamababa.

Ang Rootfs ay isang pangunahing sistema ng file. Kasama dito busybox, mga driver ng wifi module, isang set ng mga karaniwang library ng system, tulad ng libld и libc, pati na rin ang aming software, na responsable para sa LED control logic, network connection management at firmware update.

Ang root file system ay konektado sa kernel bilang initramfs at bilang resulta ng build ay nakakakuha tayo ng isang file uImage, na naglalaman ng parehong kernel at rootfs.

Application ng video

Ang pinaka-kumplikado at resource-intensive na bahagi ng firmware ay ang application, na nagbibigay ng video-audio capture, video encoding, nagko-configure ng mga parameter ng larawan, nagpapatupad ng video analytics, halimbawa, mga motion o sound detector, kinokontrol ang PTZ at responsable para sa paglipat ng araw at mga night mode.

Ang isang mahalagang, sasabihin ko pa nga na susi, ang tampok ay kung paano nakikipag-ugnayan ang application ng video sa cloud plugin.

Sa mga tradisyunal na solusyon 'firmware + cloud plugin', na hindi maaaring gumana sa murang hardware, ang video sa loob ng camera ay ipinapadala sa pamamagitan ng RTSP protocol - at ito ay isang malaking overhead: pagkopya at pagpapadala ng data sa pamamagitan ng socket, mga hindi kinakailangang syscalls.

Dito ginagamit namin ang mekanismo ng nakabahaging memorya - ang video ay hindi kinopya o ipinadala sa pamamagitan ng socket sa pagitan ng mga bahagi ng software ng camera, sa gayon ay mahusay at maingat na ginagamit ang mga katamtamang kakayahan ng hardware ng camera.

I-update ang subsystem

Ang isang punto ng espesyal na pagmamalaki ay ang fault-tolerant subsystem para sa mga online na pag-update ng firmware.

Hayaan akong ipaliwanag ang problema. Ang pag-update ng firmware ay teknikal na hindi isang atomic na operasyon, at kung ang power failure ay nangyari sa gitna ng pag-update, ang flash memory ay maglalaman ng bahagi ng "under-written" na bagong firmware. Kung hindi ka gagawa ng mga espesyal na hakbang, ang camera ay magiging isang "brick" na kailangang dalhin sa isang service center.

Naharap din namin ang problemang ito. Kahit na ang camera ay naka-off sa panahon ng pag-update, awtomatiko at walang interbensyon ng gumagamit na i-download ang firmware mula sa cloud at ibalik ang operasyon.

Tingnan natin ang pamamaraan nang mas detalyado:

Ang pinaka-mahina na punto ay ang pag-overwrite sa partition gamit ang Linux kernel at root file system. Kung nasira ang isa sa mga bahaging ito, hindi magbo-boot ang camera sa kabila ng uboot bootloader, na hindi makapag-download ng firmware mula sa cloud.

Nangangahulugan ito na kailangan nating tiyakin na ang camera ay may gumaganang kernel at rootfs anumang oras sa panahon ng proseso ng pag-update. Tila ang pinakasimpleng solusyon ay ang patuloy na pag-imbak ng dalawang kopya ng kernel na may rootfs sa flash memory at, kung ang pangunahing kernel ay nasira, i-load ito mula sa backup na kopya.

Isang magandang solusyon - gayunpaman, ang kernel na may rootfs ay tumatagal ng humigit-kumulang 3.5MB at para sa isang permanenteng backup kailangan mong maglaan ng 3.5MB. Ang mga pinakamurang camera ay walang ganoong karaming libreng espasyo para sa isang backup na kernel.

Samakatuwid, upang i-backup ang kernel sa panahon ng pag-update ng firmware, ginagamit namin ang partition ng application.
At upang piliin ang nais na pagkahati sa kernel, dalawang utos ang ginagamit bootm sa uboot - sa simula sinusubukan naming i-load ang pangunahing kernel at kung ito ay nasira, pagkatapos ay ang backup na isa.

Tinitiyak nito na sa anumang oras ay magkakaroon ang camera ng tamang kernel na may mga rootf, at magagawa nitong i-boot at i-restore ang firmware.

CI/CD system para sa pagbuo at pag-deploy ng firmware

Upang bumuo ng firmware, ginagamit namin ang gitlab CI, na awtomatikong gumagawa ng firmware para sa lahat ng sinusuportahang modelo ng camera, at pagkatapos na buuin ang firmware, awtomatiko itong idine-deploy sa serbisyo ng pag-update ng software ng camera.

Mula sa serbisyo, ang mga update sa firmware ay inihahatid sa aming mga QA test camera, at sa pagkumpleto ng lahat ng mga yugto ng pagsubok, sa mga camera ng mga user.

Seguridad ng impormasyon

Hindi lihim na sa ngayon ang seguridad ng impormasyon ang pinakamahalagang aspeto ng anumang IoT device, kabilang ang mga camera. Ang mga botnet tulad ng Mirai ay gumagala sa Internet, na nakahahawa sa milyun-milyong camera na may karaniwang firmware mula sa mga vendor. Sa lahat ng nararapat na paggalang sa mga nagtitinda ng camera, hindi ko maiwasang tandaan na ang karaniwang firmware ay naglalaman ng maraming pag-andar na hindi kailangan para sa pagtatrabaho sa cloud, ngunit naglalaman ng maraming mga kahinaan na sinasamantala ng mga botnet.

Samakatuwid, ang lahat ng hindi nagamit na functionality sa aming firmware ay hindi pinagana, lahat ng tcp/udp port ay sarado, at kapag ina-update ang firmware, ang digital signature ng software ay sinusuri.

At bukod dito, ang firmware ay sumasailalim sa regular na pagsubok sa laboratoryo ng seguridad ng impormasyon.

Konklusyon

Ngayon ang aming firmware ay aktibong ginagamit sa mga proyekto ng video surveillance. Marahil ang pinakamalaking sa kanila ay ang pagsasahimpapawid ng pagboto sa araw ng halalan ng Pangulo ng Russian Federation.
Ang proyekto ay nagsasangkot ng higit sa 70 libong mga camera sa aming firmware, na na-install sa mga istasyon ng botohan sa ating bansa.

Ang pagkakaroon ng paglutas ng isang bilang ng mga kumplikado, at sa ilang mga lugar, kahit na sa oras na iyon halos imposible na mga problema, kami, siyempre, ay nakatanggap ng malaking kasiyahan bilang mga inhinyero, ngunit bukod dito, naka-save din kami ng milyun-milyong dolyar sa pagbili ng mga camera. At sa kasong ito, ang pagtitipid ay hindi lamang mga salita at teoretikal na kalkulasyon, ngunit ang mga resulta ng isang nakumpletong tender para sa pagbili ng kagamitan. Alinsunod dito, kung pag-uusapan natin ang tungkol sa cloud video surveillance: mayroong dalawang diskarte - estratehikong umaasa sa mababang antas ng kadalubhasaan at pag-unlad, na nagreresulta sa malaking pagtitipid sa kagamitan, o gumamit ng mga mamahaling kagamitan, na, kung titingnan mo ang partikular na mga katangian ng consumer, ay halos wala. iba sa mga katulad na mura.

Bakit mahalagang madiskarteng magpasya sa pagpili ng diskarte sa pagsasama sa lalong madaling panahon? Kapag bumubuo ng isang plugin, umaasa ang mga developer sa ilang partikular na teknolohiya (mga aklatan, protocol, pamantayan). At kung ang isang hanay ng mga teknolohiya ay pipiliin lamang para sa mga mamahaling kagamitan, kung gayon sa hinaharap ang isang pagtatangka na lumipat sa murang mga camera ay malamang, sa pinakamababa, ay magtatagal ng napakahabang panahon o mabibigo at ang pagbabalik sa mga mamahaling kagamitan ay magaganap.

Pinagmulan: www.habr.com