Pozdrav svima!

Vjerovatno nije tajna da su usluge video nadzora u oblaku u posljednje vrijeme sve popularnije. I jasno je zašto se to događa, video je "težak" sadržaj, za čije skladištenje je potrebna infrastruktura i velike količine pohrane na disku. Upotreba lokalnog sistema video nadzora zahtijeva sredstva za rad i podršku, kako za organizaciju koja koristi stotine nadzornih kamera, tako i za pojedinačnog korisnika sa nekoliko kamera.

Sistemi za video nadzor u oblaku rešavaju ovaj problem tako što korisnicima pružaju postojeću infrastrukturu za skladištenje i obradu video zapisa. Klijent za video nadzor u oblaku jednostavno treba da poveže kameru na internet i poveže je sa svojim cloud nalogom.

Postoji nekoliko tehnoloških načina za povezivanje kamera sa oblakom. Bez sumnje, najpovoljnija i najjeftinija metoda je da se kamera direktno povezuje i radi sa oblakom, bez sudjelovanja dodatne opreme kao što je server ili snimač.

Da biste to učinili, potrebno je da na kameru bude instaliran softverski modul koji radi sa oblakom. Međutim, ako govorimo o jeftinim kamerama, onda one imaju vrlo ograničene hardverske resurse, koje gotovo 100% zauzima izvorni firmver proizvođača kamere, a nema resursa potrebnih za cloud plugin. 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 milioni novca potrošenih na opremu.

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

Malo istorije

U 2016. godini započeli smo razvoj platforme za video nadzor u oblaku za Rostelecom.

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

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

To znači da je za svakog dobavljača kamere potrebno individualno razviti sveobuhvatan sloj softvera za integraciju. A u vrijeme početka razvoja, preporučljivo je raditi samo s 1 dobavljačem kako bi se napore tima koncentrirali na razvoj logike za rad sa oblakom.

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

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

Gotovo odmah nakon lansiranja, naši korisnici su počeli postavljati pitanja o mogućnostima povezivanja jeftinijih kamera drugih proizvođača na servis.

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

Stoga sam odlučio kopati dublje - napraviti vlastiti firmver za kamere bilo kojeg proizvođača. Ovakav pristup značajno smanjuje zahtjeve za hardverskim resursima kamere – jer Sloj za rad sa oblakom je mnogo efikasnije integrisan sa video aplikacijom, a u firmveru nema nepotrebnih neiskorišćenih masti.

I ono što je važno je da je pri radu s kamerom na niskom nivou moguće koristiti hardverski AES, koji šifrira podatke bez stvaranja dodatnog opterećenja na procesoru male snage.

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

Gotovo svi dobavljači nisu bili spremni da rade s nama na tako niskom nivou. Nema informacija o kolima i komponentama, ne postoji službeni SDK čipseta i senzorske dokumentacije.
Također nema tehničke podrške.

Na sva pitanja trebalo je odgovoriti putem obrnutog inženjeringa — pokušaja i greške. 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 bazirane na Hisilicon 3518E čipsetu. Hardverske karakteristike kamera su sljedeće:

Xiaomi Yi Ants
Bez imena

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

Wi-Fi
mt7601/bcm43143
-

senzor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

mikrofon
+
+

zvučnik
+
+

IRLed
+
+

IRCut
+
+

Počeli smo sa njima.

Trenutno podržavamo Hisilicon 3516/3518 čipsete, kao i Ambarella S2L/S2LM. Postoje desetine modela kamera.

Sastav firmvera

podmornica

uboot je pokretač, prvi se pokreće nakon uključivanja, inicijalizira hardver i učitava jezgro Linuxa.

Skripta za učitavanje kamere je prilično 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 ovome malo kasnije, kada dođemo do podsistema ažuriranja.

Obratite pažnju na liniju mem=38M. Da, da, ovo nije greška - Linux kernel i sve, sve, sve aplikacije imaju pristup samo 38 megabajta RAM-a.

Takođe pored uboot-a postoji poseban blok koji se zove reg_info, koji sadrži skriptu niskog nivoa za inicijalizaciju DDR-a i niz sistemskih registara SoC-a. Sadržaj reg_info zavisi od modela kamere, a ako nije ispravan, kamera neće moći ni da se učita uboot, već će se zamrznuti 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 kamere.

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 sa kernelom koji se koristi , i moramo ih vratiti nazad u kamere kernela.

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

Rootfs je osnovni sistem datoteka. To uključuje busybox, drajveri wifi modula, skup standardnih sistemskih biblioteka, kao što su libld и libc, kao i naš softver, koji je odgovoran za logiku LED kontrole, upravljanje mrežnim vezom i ažuriranje firmvera.

Root sistem datoteka je povezan sa kernelom kao initramfs i kao rezultat izgradnje dobijamo jednu datoteku uImage, koji sadrži i kernel i rootfs.

Video aplikacija

Najkompleksniji i najzahtjevniji dio firmvera je aplikacija koja omogućava video-audio snimanje, video kodiranje, konfiguriše parametre slike, implementira video analitiku, na primjer, detektore pokreta ili zvuka, kontrolira PTZ i odgovorna je za promjenu dana i noćni režimi.

Važna, čak bih rekao i ključna karakteristika je način na koji video aplikacija stupa u interakciju sa dodatkom u oblaku.

U tradicionalnim rješenjima 'proizvođač firmware + cloud plugin', koja ne mogu raditi na jeftinom hardveru, video unutar kamere se prenosi preko RTSP protokola - a to je ogroman trošak: kopiranje i prijenos podataka preko socketa, nepotrebni sistemski pozivi.

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

Podsistem ažuriranja

Tačka posebnog ponosa je podsistem otporan na greške za ažuriranje firmvera na mreži.

Dozvolite mi da objasnim problem. Ažuriranje firmvera tehnički nije atomska operacija, a ako dođe do nestanka struje usred ažuriranja, tada će fleš memorija sadržavati dio "nedovoljno napisanog" novog firmvera. Ako ne preduzmete posebne mjere, kamera će tada postati "cigla" koju treba odnijeti u servisni centar.

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

Pogledajmo detaljnije tehniku:

Najranjivija tačka je prepisivanje particije sa Linux kernelom i root datotečnim sistemom. Ako je jedna od ovih komponenti oštećena, kamera se uopće neće pokrenuti osim uboot bootloadera, koji ne može preuzeti firmver iz oblaka.

To znači da moramo osigurati da kamera ima ispravan kernel i rootfs u bilo kojem trenutku tokom 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 rezervne kopije.

Dobro rješenje - međutim, kernel sa rootfs-om zauzima oko 3.5MB, a za trajni backup potrebno je izdvojiti 3.5MB. Najjeftinije kamere jednostavno nemaju toliko slobodnog prostora za backup kernel.

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

Ovo osigurava da će kamera u svakom trenutku imati ispravan kernel sa rootfs-om i moći će da se pokrene i vrati firmver.

CI/CD sistem za izgradnju i implementaciju firmvera

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

Iz usluge se ažuriranja firmvera dostavljaju našim QA test kamerama, a po završetku svih faza testiranja i kamerama korisnika.

Sigurnost informacija

Nije tajna da je danas sigurnost informacija najvažniji aspekt svakog IoT uređaja, uključujući kamere. Botneti kao što je Mirai lutaju internetom, inficirajući milione kamera standardnim firmverom proizvođača. Uz svo poštovanje prema proizvođačima kamera, ne mogu a da ne primijetim da standardni firmver sadrži puno funkcionalnosti koje nisu potrebne za rad sa oblakom, ali sadrži mnoge ranjivosti koje botnetovi iskorištavaju.

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

Osim toga, firmver se redovno testira u laboratoriji za informatičku sigurnost.

zaključak

Sada se naš firmware aktivno koristi u projektima video nadzora. Možda najveći od njih je prenos glasanja na dan izbora za predsjednika Ruske Federacije.
Projekat je uključivao više od 70 hiljada kamera sa našim firmverom, koje su instalirane na biračkim mestima u našoj zemlji.

Rešavajući niz složenih, a ponegde i u to vreme skoro nemogućih problema, mi smo, naravno, kao inženjeri dobili veliko zadovoljstvo, ali smo pored toga uštedeli milione dolara na kupovini kamera. I u ovom slučaju uštede nisu samo riječi i teoretske računice, već rezultati već završenog tendera za nabavku opreme. Shodno tome, ako govorimo o videonadzoru u oblaku: postoje dva pristupa - strateški se oslanjati na nisku stručnost i razvoj, što rezultira ogromnim uštedama na opremi, ili koristiti skupu opremu, koja, ako se posebno pogledaju karakteristike potrošača, praktički nema. razlikuje se od sličnih jeftinih.

Zašto je strateški važno što ranije odlučiti o izboru pristupa integracije? Prilikom razvoja dodatka, programeri se oslanjaju na određene tehnologije (biblioteke, protokoli, standardi). 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, potrajati suludo dugo ili čak propasti i doći će do povratka na skupu opremu.

izvor: www.habr.com