Bonghjornu ognunu!

Probabilmente ùn hè micca un sicretu chì i servizii di sorveglianza di video in nuvola anu guadagnatu popularità recentemente. È hè chjaru perchè questu succede, u video hè un cuntenutu "pesante", u almacenamentu di quale deve esse infrastruttura è grandi quantità di almacenamiento di discu. L'usu di un sistema di surviglianza video in situ richiede fondi per operare è supportu, sia per una urganizazione chì usa centinaie di camere di surviglianza è per un utilizatore individuale cù parechje camere.

I sistemi di sorveglianza di video in nuvola risolvenu stu prublema fornendu à i clienti una infrastruttura di almacenamiento è trasfurmazione di video esistenti. Un cliente di videovigilanza in nuvola hà solu bisognu di cunnette a camera à Internet è ligà à u so contu nuvola.

Ci hè parechje manere tecnologichi per cunnette e camere à u nuvulu. Indubbiamente, u metudu più convenientu è più prezzu hè chì a camera cunnetta direttamente è travaglia cù u nuvulu, senza a participazione di l'equipaggiu supplementu cum'è un servitore o un registratore.

Per fà questu, hè necessariu chì un modulu di software chì travaglia cù u nuvulu sia installatu nantu à a camera. In ogni casu, se parlemu di camere economiche, allora anu risorsi hardware assai limitati, chì sò quasi 100% occupati da u firmware nativu di u vinditore di càmera, è ùn sò micca risorse necessarii per u plugin cloud. I sviluppatori di ivideon anu dedicatu stu prublema articulu, chì spiega perchè ùn ponu micca installà u plugin nantu à e camere economiche. In u risultatu, u prezzu minimu di a camera hè 5000 rubles ($ 80 dollars) è milioni di soldi spesi in l'equipaggiu.

Avemu risoltu cù successu stu prublema. Sè site interessatu in cumu - benvenutu à u cut

Un pocu di storia

In 2016, avemu cuminciatu à sviluppà una piattaforma di surviglianza video in nuvola per Rostelecom.

In quantu à u software di càmera, in u primu stadiu avemu seguitu u percorsu "standard" per tali compiti: avemu sviluppatu u nostru propiu plugin, chì hè stallatu in u firmware standard di a camera di u venditore è travaglia cù a nostra nuvola. Tuttavia, vale a pena nutà chì durante u disignu avemu usatu e suluzioni più ligere è efficaci (per esempiu, implementazione C semplice di protobuf, libev, mbedtls è completamente abbandunati librerie convenienti ma pesanti cum'è boost)

Attualmente, ùn ci sò micca solu suluzioni di integrazione universale in u mercatu di càmera IP: ogni venditore hà u so propiu modu di installà u plugin, u so propiu set di API per u funziunamentu di u firmware, è un mecanismu d'aghjurnamentu unicu.

Questu significa chì per ogni venditore di càmera hè necessariu di sviluppà individualmente una strata cumpleta di software di integrazione. È à u mumentu di inizià u sviluppu, hè cunsigliu di travaglià solu cù 1 venditore per cuncentrazione di l'sforzi di a squadra in u sviluppu di a logica per travaglià cù u nuvulu.

U primu venditore sceltu era Hikvision, unu di i capi mondiali in u mercatu di càmera, chì furnisce una API ben documentata è un supportu tecnicu di ingegneria competente.

Avemu lanciatu u nostru primu prughjettu pilotu, a videovigilanza in nuvola Video Comfort, utilizendu càmera Hikvision.

Quasi subitu dopu à u lanciamentu, i nostri utilizatori cuminciaru à dumandà dumande nantu à a pussibilità di cunnette camere più economiche da altri fabricatori à u serviziu.

Aghju rifiutatu l'opzione di implementà una strata d'integrazione per ogni venditore quasi immediatamente - postu chì hè pocu scalabile è impone esigenze tecniche serii à u hardware di a camera. U costu di una camera chì risponde à questi requisiti di input: ~ 60-70 $

Dunque, decisu di scavà più profonda - per fà u mo propiu firmware per e camere da qualsiasi venditore. Stu approcciu riduce significativamente i requisiti per e risorse di hardware di càmera - perchè A strata per travaglià cù u nuvulu hè assai più efficacemente integrata cù l'applicazione video, è ùn ci hè micca grassu inutilmente inutilizatu in u firmware.

E ciò chì hè impurtante hè chì quandu u travagliu cù a camera à un livellu bassu, hè pussibule usà hardware AES, chì cripta e dati senza creà una carica supplementaria nantu à u CPU di bassa putenza.

À quellu mumentu ùn aviamu nunda à tuttu. Nunda in tuttu.

Quasi tutti i venditori ùn eranu micca pronti à travaglià cun noi à un livellu cusì bassu. Ùn ci hè micca infurmazione nantu à i circuiti è cumpunenti, ùn ci hè micca un SDK ufficiale di chipsets è documentazione di sensori.
Ùn ci hè ancu un supportu tecnicu.

Tutte e dumande anu da esse risposte per via di l'ingegneria inversa - prova è errore. Ma avemu riesciutu.

I primi mudelli di càmera chì avemu testatu sò stati Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, camere D-Link è parechje camere cinesi senza nome ultra-economiche.

Tecniche

Fotocamere basate nantu à u chipset Hisilicon 3518E. E caratteristiche hardware di e camere sò i seguenti:

Xiaomi Yi Ants
Micca Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

Flash
16MB
8MB

WIFI
mt7601/bcm43143
-

Lichid
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Micròfon
+
+

parraturi
+
+

IRLed
+
+

IRCut
+
+

Avemu principiatu cun elli.

Attualmente supportemu i chipset Hisilicon 3516/3518, è ancu Ambarella S2L/S2LM. Ci sò decine di mudelli di càmera.

A cumpusizioni di u firmware

sottumarinu

uboot hè u boot loader, si avvia prima dopu l'accensione, inizializza u hardware è carica u kernel Linux.

U script di carica di a camera hè abbastanza triviale:

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

Una di e caratteristiche hè chì hè chjamatu duie volte bootm, più nantu à questu un pocu dopu, quandu ghjunghjemu à u subsistema di l'aghjurnamentu.

Prestate attenzione à a linea mem=38M. Iè, iè, questu ùn hè micca un typo - u kernel Linux è tutti, tutti, tutti l'applicazioni anu accessu à solu 38 megabytes di RAM.

Ancu accantu à uboot ci hè un bloccu speciale chjamatu reg_info, chì cuntene un script di livellu bassu per l'inizializazione di DDR è una quantità di registri di sistema di u SoC. Cuntinutu reg_info dipende da u mudellu di càmera, è s'ellu ùn hè micca currettu, a camera ùn serà ancu capace di carica uboot, ma si congelarà in a prima fase di carica.

À u principiu, quandu avemu travagliatu senza supportu di u venditore, avemu simpliciamente copiatu stu bloccu da u firmware di a camera originale.

kernel Linux è rootfs

E camere utilizanu u kernel Linux, chì face parte di u SDK di u chip; di solitu questi ùn sò micca l'ultimi kernels da u ramu 3.x, cusì spessu avemu da trattà cù u fattu chì i cunduttori per l'equipaggiu supplementu ùn sò micca cumpatibili cù u kernel utilizatu. , è avemu da retroportà à e camere di u kernel.

Un altru prublema hè a dimensione di u kernel. Quandu a dimensione FLASH hè solu 8MB, allora ogni byte conta è u nostru compitu hè di disattivà currettamente tutte e funzioni di kernel inutilizate per riduce a dimensione à u minimu.

Rootfs hè un sistema di fugliale di basa. Include busybox, driver di moduli wifi, un inseme di biblioteche di sistema standard, cum'è libld и libc, è ancu u nostru software, chì hè rispunsevule per a logica di cuntrollu LED, a gestione di a cunnessione di a rete è l'aghjurnamenti di firmware.

U sistema di fugliale radicali hè cunnessu à u kernel cum'è initramfs è per via di a custruzzione avemu un schedariu. uImage, chì cuntene u kernel è rootfs.

Applicazione Video

A parte più cumplessa è risorsa intensiva di u firmware hè l'applicazione, chì furnisce cattura video-audio, codificazione video, cunfigurà paràmetri di stampa, implementa analitiche video, per esempiu, detector di muvimentu o sonu, cuntrola PTZ è hè rispunsevule per cambià u ghjornu è modi di notte.

Una funzione impurtante, ancu diceraghju chjave, hè cumu l'applicazione video interagisce cù u plugin cloud.

In soluzioni tradiziunali "vendor firmware + cloud plugin", chì ùn pò micca travaglià in hardware economicu, u video in a camera hè trasmessu via u protocolu RTSP - è questu hè un overhead enormi: copià è trasmette dati via socket, syscalls innecessarii.

Quì avemu usatu u mecanismu di memoria spartutu - u video ùn hè micca copiatu o mandatu via un socket trà i cumpunenti di u software di a camera, per quessa, utilizendu in modu ottimale è cun cura e modeste capacità hardware di a camera.

Aghjurnà u sottusistema

Un puntu d'orgogliu speciale hè u subsistema tolerante à i difetti per l'aghjurnamenti di firmware in linea.

Lasciami spiegà u prublema. L'aghjurnamentu di u firmware ùn hè tecnicamente micca una operazione atomica, è se un fallimentu di l'energia si trova in u mità di l'aghjurnamentu, allora a memoria flash cuntene una parte di u novu firmware "sotto-scrittu". Se ùn pigliate micca misure speciali, a camera diventerà un "brick" chì deve esse purtatu à un centru di serviziu.

Avemu ancu trattatu stu prublema. Ancu s'è a camera hè spenta durante l'aghjurnamentu, automaticamente è senza intervenzione di l'utilizatori scaricate u firmware da u nuvulu è restaurà l'operazione.

Fighjemu a tecnica in più detail:

U puntu più vulnerabile hè di sovrascrive a partizione cù u kernel Linux è u sistema di file root. Se unu di sti cumpunenti hè dannatu, a camera ùn hà micca avviatu in tuttu oltre u bootloader uboot, chì ùn pò micca scaricà firmware da u nuvulu.

Questu significa chì avemu bisognu di assicurà chì a camera hà un kernel di travagliu è rootfs in ogni mumentu durante u prucessu d'aghjurnamentu. Sembra chì a suluzione più simplice seria di almacenà constantemente duie copie di u kernel cù rootfs nantu à a memoria flash è, se u kernel principale hè dannatu, carricà da a copia di salvezza.

Una bona suluzione - in ogni modu, u kernel cù rootfs occupa circa 3.5MB è per una copia di salvezza permanente avete bisognu di assignà 3.5MB. E camere più economiche simpricimenti ùn anu micca tantu spaziu liberu per un kernel di salvezza.

Dunque, per fà una copia di salvezza di u kernel durante un aghjurnamentu di firmware, usemu a partizione di l'applicazione.
È per selezziunà a partizione desiderata cù u kernel, sò usati dui cumandamenti bootm in uboot - à u principiu pruvemu di carricà u kernel principale è s'ellu hè dannatu, allora a copia di salvezza.

Questu assicura chì in ogni mumentu a camera avarà u kernel currettu cù rootfs, è puderà boot è restaurà u firmware.

Sistema CI/CD per custruisce è implementà firmware

Per custruisce firmware, usemu gitlab CI, chì automaticamente custruisce firmware per tutti i mudelli di càmera supportati, è dopu avè custruitu u firmware, hè automaticamente implementatu à u serviziu di l'aghjurnamentu di u software di càmera.

Da u serviziu, l'aghjurnamenti di firmware sò consegnati à e nostre camere di prova di QA, è dopu à a fine di tutte e tappe di teste, à e camere di l'utilizatori.

Sicurezza di l'infurmazione

Ùn hè un sicretu chì oghje a sicurità di l'infurmazioni hè l'aspettu più impurtante di qualsiasi dispositivu IoT, cumprese e camere. Botnets cum'è Mirai viaghjanu in Internet, infettendu milioni di camere cù firmware standard da i venditori. Cù tuttu u rispettu à i venditori di càmera, ùn possu micca aiutà à nutà chì u firmware standard cuntene assai funziunalità chì ùn hè micca necessariu per travaglià cù u nuvulu, ma cuntene assai vulnerabilità chì i botnets prufittà.

Dunque, tutte e funziunalità inutilizate in u nostru firmware hè disattivata, tutti i porti tcp / udp sò chjusi, è quandu aghjurnà u firmware, a firma digitale di u software hè verificata.

È in più di questu, u firmware hè sottumessu à una prova regulare in u laboratoriu di sicurità di l'infurmazioni.

cunchiusioni

Avà u nostru firmware hè attivamente utilizatu in i prughjetti di surviglianza video. Forsi u più grande di elli hè a trasmissione di votu in u ghjornu di l'elezzione di u presidente di a Federazione Russa.
U prughjettu hà implicatu più di 70 mila camere cù u nostru firmware, chì sò stati installati in stazioni di votazione in u nostru paese.

Dopu avè risoltu una quantità di cumplessu, è in certi lochi, ancu à quellu tempu prublemi quasi impussibili, avemu, sicuru, ricivutu una grande satisfaczione cum'è ingegneri, ma in più di questu, avemu ancu salvatu milioni di dollari nantu à l'acquistu di càmera. È in questu casu, u risparmiu ùn hè micca solu parolle è calculi teorichi, ma i risultati di una offerta digià cumpleta per a compra di l'equipaggiu. In cunsiquenza, se parlemu di surviglianza video in nuvola: ci sò dui approcci - strategicamente s'appoghjanu nantu à a cumpetenza è u sviluppu di livellu bassu, risultatu in un grande risparmiu nantu à l'equipaggiu, o l'usu di l'equipaggiu caru, chì, s'è vo fighjate specificamente à e caratteristiche di i cunsumatori, hè praticamente micca. differente da quelli simili à pocu prezzu.

Perchè hè strategicamente impurtante di decide nantu à a scelta di l'approcciu d'integrazione u più prestu pussibule? Quandu si sviluppanu un plugin, i sviluppatori si basanu nantu à certe tecnulugia (biblioteche, protokolli, standard). È se un settore di tecnulugii hè sceltu solu per l'equipaggiu caru, allora in u futuru un tentativu di cambià à e camere economiche più prubabilmente, à u minimu, piglià un tempu insanamente longu o ancu fallimentu è un ritornu à l'equipaggiu caru si farà.

Source: www.habr.com