Pozdravljeni vsi!

Verjetno ni skrivnost, da storitve videonadzora v oblaku v zadnjem času postajajo vse bolj priljubljene. In jasno je, zakaj se to zgodi, video je »težka« vsebina, katere shranjevanje zahteva infrastrukturo in velike količine diskovnega prostora. Uporaba lokalnega videonadzornega sistema zahteva sredstva za delovanje in podporo, tako za organizacijo, ki uporablja na stotine nadzornih kamer, kot za posameznega uporabnika z več kamerami.

Sistemi videonadzora v oblaku rešujejo to težavo tako, da strankam zagotavljajo obstoječo infrastrukturo za shranjevanje in obdelavo videa. Odjemalec videonadzora v oblaku mora preprosto povezati kamero z internetom in jo povezati s svojim računom v oblaku.

Obstaja več tehnoloških načinov povezovanja kamer v oblak. Nedvomno najprimernejši in najcenejši način je, da se kamera neposredno poveže in deluje z oblakom, brez sodelovanja dodatne opreme, kot je strežnik ali snemalnik.

Za to mora biti na kameri nameščen programski modul, ki deluje z oblakom. Če pa govorimo o poceni kamerah, potem imajo zelo omejene strojne vire, ki jih skoraj 100% zaseda izvorna strojna programska oprema prodajalca fotoaparata, za vtičnik v oblaku pa ni potrebnih virov. Razvijalci iz ivideon so se posvetili tej težavi статью, kar pojasnjuje, zakaj vtičnika ne morejo namestiti na poceni fotoaparate. Posledično je najnižja cena kamere 5000 rubljev (80 dolarjev) in milijoni denarja, porabljenega za opremo.

Ta problem smo uspešno rešili. Če vas zanima kako - dobrodošli v rezu

Malo zgodovine

Leta 2016 smo začeli razvijati platformo za videonadzor v oblaku za Rostelecom.

Kar zadeva programsko opremo kamere, smo na prvi stopnji sledili »standardni« poti za tovrstna opravila: razvili smo lasten vtičnik, ki je nameščen v standardni firmware kamere proizvajalca in deluje z našim oblakom. Vendar je treba omeniti, da smo med načrtovanjem uporabili najbolj lahke in učinkovite rešitve (na primer, navadna C implementacija protobuf, libev, mbedtls in popolnoma opuščene priročne, a težke knjižnice, kot je boost)

Trenutno na trgu kamer IP ni univerzalnih integracijskih rešitev: vsak prodajalec ima svoj način namestitve vtičnika, svoj nabor API-jev za delovanje vdelane programske opreme in edinstven mehanizem za posodabljanje.

To pomeni, da je treba za vsakega prodajalca kamer posebej razviti celovito plast integracijske programske opreme. In v času začetka razvoja je priporočljivo sodelovati samo z enim prodajalcem, da se prizadevanja ekipe osredotočijo na razvoj logike za delo z oblakom.

Prvi izbrani prodajalec je bil Hikvision, eden od vodilnih v svetu na trgu kamer, ki zagotavlja dobro dokumentiran API in kompetentno inženirsko tehnično podporo.

Zagnali smo prvi pilotni projekt oblačnega videonadzora Video Comfort s kamerami Hikvision.

Skoraj takoj po lansiranju so naši uporabniki začeli postavljati vprašanja o možnostih priključitve cenejših kamer drugih proizvajalcev na storitev.

Možnost implementacije integracijskega sloja za vsakega prodajalca sem zavrnil skoraj takoj - saj je slabo razširljiv in nalaga resne tehnične zahteve strojni opremi kamere. Cena kamere, ki izpolnjuje te vhodne zahteve: ~60-70$

Zato sem se odločil kopati globlje - narediti lastno programsko opremo za kamere katerega koli prodajalca. Ta pristop bistveno zmanjša zahteve za vire strojne opreme kamere - ker Plast za delo z oblakom je veliko bolj učinkovito integrirana z video aplikacijo, v vdelani programski opremi pa ni nepotrebne neporabljene maščobe.

In kar je pomembno, je pri delu s kamero na nizki ravni možna uporaba strojne opreme AES, ki šifrira podatke brez ustvarjanja dodatne obremenitve CPU z nizko porabo energije.

V tistem trenutku nismo imeli čisto nič. Popolnoma nič.

Skoraj vsi prodajalci niso bili pripravljeni sodelovati z nami na tako nizki ravni. Ni informacij o vezju in komponentah, ni uradnega SDK naborov čipov in dokumentacije senzorjev.
Prav tako ni tehnične podpore.

Na vsa vprašanja je bilo treba odgovoriti z obratnim inženiringom – poskusi in napake. Ampak nama je uspelo.

Prvi modeli kamer, ki smo jih testirali, so bile kamere Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link in več ultra poceni brezimnih kitajskih kamer.

Tehnika

Kamere na osnovi nabora čipov Hisilicon 3518E. Lastnosti strojne opreme kamer so naslednje:

Xiaomi Yi Ants
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Senzor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

microSD
+
+

mikrofon
+
+

Zvočniki
+
+

IRLed
+
+

IRCut
+
+

Z njimi smo začeli.

Trenutno podpiramo nabore čipov Hisilicon 3516/3518, kot tudi Ambarella S2L/S2LM. Obstaja na desetine modelov kamer.

Sestava vdelane programske opreme

uboot

uboot je zagonski nalagalnik, po vklopu se najprej zažene, inicializira strojno opremo in naloži jedro linux.

Skript za nalaganje kamere je precej trivialen:

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

Ena od značilnosti je, da se kliče dvakrat bootm, več o tem malo kasneje, ko pridemo do posodobitvenega podsistema.

Bodite pozorni na linijo mem=38M. Da, da, to ni tipkarska napaka - jedro Linuxa in vse, vse, vse aplikacije imajo dostop do samo 38 megabajtov RAM-a.

Tudi poleg uboot obstaja poseben blok, imenovan reg_info, ki vsebuje nizkonivojski skript za inicializacijo DDR in številne sistemske registre SoC. Vsebina reg_info odvisno od modela kamere in če ni pravilna, kamera sploh ne bo mogla naložiti uboot, ampak bo zamrznila v zelo zgodnji fazi nalaganja.

Sprva, ko smo delali brez podpore proizvajalca, smo preprosto kopirali ta blok iz originalne vdelane programske opreme fotoaparata.

Jedro Linuxa in rootfs

Kamere uporabljajo jedro Linuxa, ki je del SDK-ja čipa; ponavadi to niso najnovejša jedra iz veje 3.x, zato se moramo pogosto soočati z dejstvom, da gonilniki za dodatno opremo niso združljivi z uporabljenim jedrom. , in jih moramo nazaj prenesti v kamere jedra.

Druga težava je velikost jedra. Ko je velikost FLASH samo 8 MB, šteje vsak bajt in naša naloga je skrbno onemogočiti vse neuporabljene funkcije jedra, da zmanjšamo velikost na minimum.

Rootfs je osnovni datotečni sistem. Vključuje busybox, gonilniki modulov wifi, niz standardnih sistemskih knjižnic, kot je npr libld и libc, kot tudi našo programsko opremo, ki je odgovorna za krmilno logiko LED, upravljanje omrežne povezave in posodobitve vdelane programske opreme.

Korenski datotečni sistem je povezan z jedrom kot initramfs in kot rezultat gradnje dobimo eno datoteko uImage, ki vsebuje tako jedro kot rootfs.

Video aplikacija

Najbolj zapleten in zahteven del vdelane programske opreme je aplikacija, ki omogoča zajem videa in zvoka, kodiranje videa, konfiguracijo slikovnih parametrov, implementacijo video analitike, na primer detektorje gibanja ali zvoka, nadzor PTZ in je odgovoren za preklop dneva in nočni načini.

Pomembna, rekel bi celo ključna lastnost je, kako video aplikacija komunicira z vtičnikom za oblak.

Pri tradicionalnih rešitvah 'vdelana programska oprema proizvajalca + vtičnik v oblaku', ki ne more delovati na poceni strojni opremi, se video znotraj kamere prenaša prek protokola RTSP - in to je velik strošek: kopiranje in prenos podatkov prek vtičnice, nepotrebni sistemski klici.

Pri tem uporabljamo mehanizem deljenega pomnilnika - videoposnetek se ne kopira ali pošilja prek vtičnice med komponentami programske opreme kamere, s čimer optimalno in previdno uporabljamo skromne zmogljivosti strojne opreme kamere.

Posodobi podsistem

Točka posebnega ponosa je odporen na napake podsistem za spletne posodobitve vdelane programske opreme.

Naj razložim težavo. Posodobitev vdelane programske opreme tehnično ni atomska operacija in če sredi posodobitve pride do izpada električne energije, bo bliskovni pomnilnik vseboval del "podpisane" nove vdelane programske opreme. Če ne boste sprejeli posebnih ukrepov, bo kamera postala "opeka", ki jo je treba odnesti na servis.

Tudi s tem problemom smo se ukvarjali. Tudi če je kamera med posodobitvijo izklopljena, bo samodejno in brez posredovanja uporabnika prenesla vdelano programsko opremo iz oblaka in obnovila delovanje.

Oglejmo si tehniko podrobneje:

Najbolj ranljiva točka je prepisovanje particije z jedrom Linuxa in korenskim datotečnim sistemom. Če je ena od teh komponent poškodovana, se fotoaparat sploh ne bo zagnal prek zagonskega nalagalnika uboot, ki ne more prenesti vdelane programske opreme iz oblaka.

To pomeni, da moramo kadar koli med postopkom posodabljanja zagotoviti, da ima kamera delujoče jedro in rootfs. Zdi se, da bi bila najpreprostejša rešitev stalno shranjevanje dveh kopij jedra z rootfs v flash pomnilnik in, če je glavno jedro poškodovano, ga naložite iz varnostne kopije.

Dobra rešitev - vendar jedro z rootfs zavzame približno 3.5 MB in za trajno varnostno kopijo morate dodeliti 3.5 MB. Najcenejše kamere preprosto nimajo toliko prostega prostora za rezervno jedro.

Zato za varnostno kopiranje jedra med posodobitvijo vdelane programske opreme uporabimo particijo aplikacije.
Za izbiro želene particije z jedrom se uporabljata dva ukaza bootm v uboot - na začetku poskušamo naložiti glavno jedro in če je poškodovano, potem rezervno.

To zagotavlja, da bo imela kamera v danem trenutku pravilno jedro z rootfs ter da se bo lahko zagnala in obnovila vdelano programsko opremo.

Sistem CI/CD za gradnjo in namestitev vdelane programske opreme

Za izdelavo vdelane programske opreme uporabljamo gitlab CI, ki samodejno izdela vdelano programsko opremo za vse podprte modele kamer, po izgradnji vdelane programske opreme pa se samodejno uvede v storitev posodabljanja programske opreme kamere.

Iz storitve se posodobitve vdelane programske opreme dostavijo našim testnim kameram QA in po zaključku vseh stopenj testiranja kameram uporabnikov.

Informacijska varnost

Nobena skrivnost ni, da je dandanes informacijska varnost najpomembnejši vidik katere koli naprave IoT, vključno s kamerami. Botneti, kot je Mirai, gostujejo po internetu in okužijo milijone kamer s standardno vdelano programsko opremo proizvajalcev. Z vsem spoštovanjem do prodajalcev kamer, ne morem mimo ugotovitve, da standardna vdelana programska oprema vsebuje veliko funkcionalnosti, ki niso potrebne za delo z oblakom, vendar vsebuje veliko ranljivosti, ki jih botneti izkoriščajo.

Zato so vse neuporabljene funkcije v naši vdelani programski opremi onemogočene, vsa tcp/udp vrata so zaprta, pri posodabljanju vdelane programske opreme pa se preveri digitalni podpis programske opreme.

Poleg tega se vdelana programska oprema redno testira v laboratoriju za informacijsko varnost.

Zaključek

Zdaj se naša vdelana programska oprema aktivno uporablja v projektih videonadzora. Morda je največji med njimi prenos glasovanja na dan volitev predsednika Ruske federacije.
V projekt je bilo vključenih več kot 70 tisoč kamer z našo programsko opremo, ki so bile nameščene na voliščih v naši državi.

Ob rešitvi številnih zapletenih, ponekod tudi v tistem času skoraj nemogočih problemov, smo bili kot inženirji seveda deležni velikega zadovoljstva, poleg tega pa smo privarčevali tudi milijone dolarjev pri nakupu kamer. In v tem primeru prihranki niso le besede in teoretični izračuni, temveč rezultati že izvedenega razpisa za nakup opreme. V skladu s tem, če govorimo o videonadzoru v oblaku: obstajata dva pristopa - strateško zanašanje na nizko raven strokovnega znanja in razvoja, kar ima za posledico velike prihranke pri opremi, ali uporaba drage opreme, ki je, če pogledamo posebej na potrošniške lastnosti, praktično ni drugačen od podobnih poceni.

Zakaj je strateško pomembno, da se o izbiri integracijskega pristopa odločimo čim prej? Pri razvoju vtičnika se razvijalci zanašajo na določene tehnologije (knjižnice, protokole, standarde). In če je nabor tehnologij izbran samo za drago opremo, potem bo v prihodnosti poskus prehoda na poceni kamere najverjetneje trajal vsaj noro dolgo ali celo propadel in prišlo bo do vrnitve k dragi opremi.

Vir: www.habr.com