Pozdrav!

Vjerojatno nije tajna da usluge videonadzora u oblaku u posljednje vrijeme postaju sve popularnije. I jasno je zašto se to događa, video je "težak" sadržaj, čija pohrana zahtijeva infrastrukturu i velike količine diskovne memorije. Korištenje lokalnog sustava videonadzora zahtijeva sredstva za rad i podršku, kako za organizaciju koja koristi stotine nadzornih kamera tako i za pojedinačnog korisnika s nekoliko kamera.

Sustavi videonadzora u oblaku rješavaju ovaj problem pružajući korisnicima postojeću infrastrukturu za pohranu i obradu videa. Klijent videonadzora u oblaku jednostavno treba povezati kameru s internetom i povezati je sa svojim računom u oblaku.

Postoji nekoliko tehnoloških načina povezivanja kamera s oblakom. Bez sumnje, najprikladnija i najjeftinija metoda je da se kamera izravno povezuje i radi s oblakom, bez sudjelovanja dodatne opreme poput poslužitelja ili snimača.

Da biste to učinili, potrebno je da na kameri bude instaliran softverski modul koji radi s oblakom. Međutim, ako govorimo o jeftinim kamerama, onda one imaju vrlo ograničene hardverske resurse, koji su gotovo 100% zauzeti izvornim firmverom dobavljača kamere, a nema resursa potrebnih za dodatak za oblak. Programeri iz ivideona posvetili su se ovom problemu članak, što objašnjava zašto ne mogu instalirati dodatak na jeftine kamere. Kao rezultat toga, minimalna cijena kamere je 5000 rubalja ($80 dolara) i milijuni novca potrošeni na opremu.

Taj smo problem uspješno riješili. Ako vas zanima kako - dobrodošli u rez

Malo povijesti

U 2016. smo za Rostelecom počeli razvijati platformu za videonadzor u oblaku.

Što se tiče softvera kamere, u prvoj smo fazi slijedili "standardni" put za takve zadatke: razvili smo vlastiti dodatak koji je instaliran u standardni firmware kamere dobavljača i radi s našim oblakom. Međutim, vrijedno je napomenuti da smo tijekom dizajna koristili najlakša i najučinkovitija rješenja (na primjer, običnu C implementaciju protobuf, libev, mbedtls i potpuno napuštene zgodne, ali teške biblioteke poput boosta)

Trenutačno ne postoje univerzalna integracijska rješenja na tržištu IP kamera: svaki dobavljač ima vlastiti način instaliranja dodatka, vlastiti skup API-ja za upravljanje firmverom i jedinstveni mehanizam ažuriranja.

To znači da je za svakog dobavljača kamere potrebno pojedinačno razviti opsežan sloj integracijskog softvera. A u vrijeme početka razvoja, preporučljivo je raditi samo s 1 dobavljačem kako bi se timski napori koncentrirali na razvoj logike za rad s oblakom.

Prvi odabrani dobavljač bio je Hikvision, jedan od svjetskih lidera na tržištu kamera, koji pruža dobro dokumentiran API i kompetentnu inženjersku tehničku podršku.

Pokrenuli smo naš prvi pilot projekt, video nadzor u oblaku Video Comfort, koristeći Hikvision kamere.

Gotovo odmah nakon pokretanja, naši su korisnici počeli postavljati pitanja o mogućnosti spajanja jeftinijih kamera drugih proizvođača na uslugu.

Odbacio sam opciju implementacije integracijskog sloja za svakog dobavljača gotovo odmah - jer je slabo skalabilan i nameće ozbiljne tehničke zahtjeve za hardver kamere. Cijena kamere koja zadovoljava ove ulazne zahtjeve: ~60-70$

Stoga sam odlučio kopati dublje - napraviti vlastiti firmware za kamere bilo kojeg dobavljača. Ovaj pristup značajno smanjuje zahtjeve za hardverskim resursima kamere – jer Sloj za rad s oblakom puno je učinkovitije integriran s video aplikacijom, a nema nepotrebne neiskorištene masti u firmwareu.

A ono što je važno jest da je pri radu s kamerom na niskoj razini moguće koristiti hardverski AES, koji šifrira podatke bez dodatnog opterećenja CPU-a male snage.

U tom trenutku nismo imali baš ništa. Baš ništa.

Gotovo svi dobavljači nisu bili spremni surađivati ​​s nama na tako niskoj razini. Nema informacija o strujnim krugovima i komponentama, nema službenog SDK-a čipseta i dokumentacije senzora.
Također nema tehničke podrške.

Na sva se pitanja moralo odgovoriti obrnutim inženjeringom — pokušajem i pogreškom. Ali uspjeli smo.

Prvi modeli kamera na kojima smo testirali bili su Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link kamere i nekoliko ultra jeftinih bezimenih kineskih kamera.

Tehnika

Kamere temeljene na Hisilicon 3518E čipsetu. Hardverske karakteristike kamera su sljedeće:

Xiaomi Yi Mravi
noname

SoC
Hisilicij 3518E
Hisilicij 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Senzor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Govornik
+
+

IRLed
+
+

IRCut
+
+

Počeli smo s njima.

Trenutno podržavamo Hisilicon 3516/3518 skupove čipova, kao i Ambarella S2L/S2LM. Postoje deseci modela kamera.

Sastav firmvera

podmornica

uboot je pokretač sustava, prvi se pokreće nakon uključivanja, inicijalizira hardver i učitava jezgru linuxa.

Skripta za učitavanje kamere prilično je trivijalna:

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

Jedna od karakteristika je da se poziva dva puta bootm, više o tome malo kasnije, kada dođemo do podsustava ažuriranja.

Obratite pozornost na liniju mem=38M. Da, da, ovo nije tipfeler - Linux kernel i sve, sve, sve aplikacije imaju pristup samo 38 megabajta RAM-a.

Također pored uboot postoji poseban blok pod nazivom reg_info, koji sadrži skriptu niske razine za inicijalizaciju DDR-a i niz sistemskih registara SoC-a. Sadržaj reg_info ovisi o modelu kamere, a ako nije ispravna, kamera neće moći niti učitati uboot, nego će se smrznuti u vrlo ranoj fazi učitavanja.

U početku, kada smo radili bez podrške dobavljača, jednostavno smo kopirali ovaj blok iz originalnog firmvera fotoaparata.

Linux kernel i rootfs

Kamere koriste Linux kernel, koji je dio SDK-a čipa; obično to nisu najnoviji kerneli iz grane 3.x, pa se često moramo suočiti s činjenicom da drajveri za dodatnu opremu nisu kompatibilni s kernelom koji se koristi , i moramo ih vratiti u kernel kamere.

Drugi problem je veličina kernela. Kada je veličina FLASH-a samo 8 MB, tada se svaki bajt računa i naš je zadatak pažljivo onemogućiti sve neiskorištene funkcije kernela kako bismo smanjili veličinu na minimum.

Rootfs je osnovni datotečni sustav. Uključuje busybox, upravljački programi wifi modula, skup standardnih sistemskih biblioteka, kao što je libld и libc, kao i naš softver koji je odgovoran za logiku upravljanja LED diodama, upravljanje mrežnom vezom i ažuriranje firmvera.

Korijenski datotečni sustav povezan je s kernelom kao initramfs i kao rezultat izgradnje dobivamo jednu datoteku uImage, koji sadrži i kernel i rootfs.

Video aplikacija

Najsloženiji i najzahtjevniji dio firmvera je aplikacija koja omogućuje video-audio snimanje, video kodiranje, konfigurira parametre slike, implementira video analitiku, na primjer, detektore pokreta ili zvuka, kontrolira PTZ i odgovorna je za prebacivanje dana i noćni načini rada.

Važna, rekao bih čak i ključna značajka je način na koji video aplikacija komunicira s dodatkom za oblak.

U tradicionalnim rješenjima 'programska oprema dobavljača + dodatak za oblak', koja ne mogu raditi na jeftinom hardveru, video unutar kamere prenosi se putem RTSP protokola - a to je veliki trošak: kopiranje i prijenos podataka putem utičnice, nepotrebni sistemski pozivi.

Ovdje koristimo mehanizam dijeljene memorije - video se ne kopira niti šalje putem utičnice između softverskih komponenti kamere, čime se optimalno i pažljivo koriste skromne hardverske mogućnosti kamere.

Ažurirajte podsustav

Točka posebnog ponosa je podsustav otporan na greške za online ažuriranje firmvera.

Dopustite mi da objasnim problem. Ažuriranje firmvera tehnički nije atomska operacija i ako dođe do nestanka struje usred ažuriranja, tada će flash memorija sadržavati dio "ispod zapisanog" novog firmvera. Ako ne poduzmete posebne mjere, kamera će tada postati "cigla" koju treba odnijeti u servis.

Bavili smo se i ovim problemom. Čak i ako se kamera isključi tijekom ažuriranja, ona će automatski i bez intervencije korisnika preuzeti firmware iz oblaka i vratiti rad.

Pogledajmo detaljnije tehniku:

Najranjivija točka je prepisivanje particije s Linux kernelom i korijenskim datotečnim sustavom. Ako je jedna od ovih komponenti oštećena, kamera se uopće neće pokrenuti osim uboot bootloadera, koji ne može preuzeti firmware iz oblaka.

To znači da moramo osigurati da kamera ima radni kernel i rootfs u bilo kojem trenutku tijekom procesa ažuriranja. Čini se da bi najjednostavnije rješenje bilo stalno pohranjivati ​​dvije kopije kernela s rootfs-om na flash memoriju i, ako je glavni kernel oštećen, učitati ga iz sigurnosne kopije.

Dobro rješenje - međutim, kernel s rootfs-om zauzima oko 3.5 MB, a za trajnu sigurnosnu kopiju morate izdvojiti 3.5 MB. Najjeftinije kamere jednostavno nemaju toliko slobodnog prostora za rezervni kernel.

Stoga, za izradu sigurnosne kopije kernela tijekom ažuriranja firmvera, koristimo particiju aplikacije.
A za odabir željene particije s kernelom koriste se dvije naredbe bootm u uboot - na početku pokušavamo učitati glavni kernel i ako je oštećen onda rezervni.

Ovo osigurava da će kamera u bilo kojem trenutku imati ispravan kernel s rootfs-om, te da će se moći pokrenuti i vratiti firmware.

CI/CD sustav za izgradnju i postavljanje firmvera

Za izradu firmvera koristimo gitlab CI, koji automatski gradi firmver za sve podržane modele kamera, a nakon izgradnje firmvera, automatski se postavlja na uslugu ažuriranja softvera kamere.

Iz usluge se ažuriranja firmvera isporučuju našim QA testnim kamerama, a nakon završetka svih faza testiranja, korisničkim kamerama.

Sigurnost informacija

Nije tajna da je informacijska sigurnost danas najvažniji aspekt svakog IoT uređaja, pa tako i kamera. Botneti kao što je Mirai lutaju internetom, inficirajući milijune kamera standardnim firmware-om od dobavljača. Uz dužno poštovanje prema proizvođačima kamera, ne mogu ne primijetiti da standardni firmware sadrži puno funkcionalnosti koje nisu potrebne za rad s oblakom, ali sadrži mnoge ranjivosti koje botnetovi iskorištavaju.

Stoga su sve neiskorištene funkcionalnosti u našem firmware-u onemogućene, svi tcp/udp portovi su zatvoreni, a prilikom ažuriranja firmware-a provjerava se digitalni potpis softvera.

Osim toga, firmware se redovito testira u laboratoriju za informacijsku sigurnost.

Zaključak

Sada se naš firmware aktivno koristi u projektima videonadzora. Možda najveći od njih je prijenos glasovanja na dan izbora predsjednika Ruske Federacije.
U projekt je uključeno više od 70 tisuća kamera s našim firmwareom koje su postavljene na biračkim mjestima u našoj zemlji.

Riješivši niz složenih, a ponegdje i tada gotovo nemogućih problema, dobili smo, naravno, veliko zadovoljstvo kao inženjeri, ali osim toga uštedjeli smo i milijune dolara na kupnji kamera. I u ovom slučaju uštede nisu samo riječi i teoretski izračuni, već rezultati već završenog natječaja za nabavu opreme. Sukladno tome, ako govorimo o videonadzoru u oblaku: postoje dva pristupa - strateški se osloniti na nisku razinu stručnosti i razvoja, što rezultira velikim uštedama na opremi, ili koristiti skupu opremu, koje, gledajući konkretno na potrošačke karakteristike, praktički nema drugačiji od sličnih jeftinih.

Zašto je strateški važno što ranije odlučiti o izboru integracijskog pristupa? Prilikom razvoja dodatka programeri se oslanjaju na određene tehnologije (biblioteke, protokole, standarde). A ako se skup tehnologija odabere samo za skupu opremu, onda će u budućnosti pokušaj prelaska na jeftine kamere najvjerojatnije, u najmanju ruku, trajati suludo dugo ili čak propasti i doći će do povratka na skupu opremu.

Izvor: www.habr.com