Hola a todos!

Seguruenik ez da sekretua hodeiko bideo-zaintza zerbitzuak ospea irabazten ari direla azkenaldian. Eta argi dago zergatik gertatzen den hori, bideoa eduki "astuna" da, eta horren biltegiratzeak azpiegitura eta disko biltegiratze kopuru handiak behar ditu. Bideozaintza-sistema lokal bat erabiltzeak funtsak behar ditu funtzionatzeko eta laguntzeko, bai ehunka zaintza-kamera erabiltzen dituen erakunde batek, bai hainbat kamera dituen erabiltzaile indibidual batek.

Hodeiko bideo-zaintza sistemek arazo hau konpontzen dute bezeroei lehendik dauden bideoak biltegiratzeko eta prozesatzeko azpiegitura bat eskainiz. Hodeiko bideo-zaintzako bezero batek kamera Internetera konektatu eta bere hodeiko kontuarekin lotu besterik ez du behar.

Kamerak hodeira konektatzeko hainbat modu teknologiko daude. Zalantzarik gabe, metodorik erosoena eta merkeena kamera hodeiarekin zuzenean konektatzea eta lan egitea da, zerbitzari edo grabagailu bat bezalako ekipamendu gehigarririk parte hartu gabe.

Horretarako, beharrezkoa da hodeiarekin lan egiten duen software-modulu bat instalatzea kameran. Hala ere, kamera merkeei buruz hitz egiten badugu, hardware-baliabide oso mugatuak dituzte, kamera-saltzailearen jatorrizko firmwareak ia % 100 okupatzen dituenak, eta ez dago hodeiko pluginerako beharrezkoak diren baliabideak. ivideon-eko garatzaileek arazo honi eskaini diote artikulu bat, eta horrek azaltzen du zergatik ezin duten instalatu plugina kamera merkeetan. Ondorioz, kameraren gutxieneko prezioa 5000 errublo (80 dolar) eta ekipoetan gastatutako milioika dirua da.

Arazo hau arrakastaz konpondu dugu. Nola interesatzen bazaizu - ongi etorri ebakira

Historia apur bat

2016an, hodeiko bideo-zaintza plataforma bat garatzen hasi ginen Rostelecom-entzat.

Kameraren softwareari dagokionez, lehen fasean horrelako zereginetarako bide "estandarra" jarraitu genuen: gure plugin propioa garatu genuen, saltzaileen kameraren firmware estandarrean instalatuta dagoena eta gure hodeiarekin funtzionatzen duena. Hala ere, nabarmentzekoa da diseinuan soluzio arin eta eraginkorrenak erabili genituela (adibidez, protobuf, libev, mbedtls eta guztiz abandonatuta dauden liburutegi erosoak baina astunak boost bezalako C inplementazio arrunta)

Gaur egun, IP kameren merkatuan ez dago integrazio soluzio unibertsala: saltzaile bakoitzak plugina instalatzeko bere modua du, firmwarea funtzionatzeko API multzo propioa eta eguneratze mekanismo bakarra.

Horrek esan nahi du kamera-saltzaile bakoitzarentzat beharrezkoa dela integrazio-softwarearen geruza integrala banaka garatzea. Eta garapena hasten den unean, saltzaile bakarrarekin lan egitea komeni da, taldearen ahaleginak hodeiarekin lan egiteko logika garatzeko kontzentratzeko.

Aukeratutako lehen saltzailea Hikvision izan zen, kameraren merkatuan munduko liderretako bat, ondo dokumentatutako API bat eta ingeniaritza-laguntza tekniko eskuduna eskainiz.

Gure lehen proiektu pilotua abian jarri genuen, hodeiko bideo-zaintza Video Comfort, Hikvision kamerak erabiliz.

Abian jarri eta ia berehala, gure erabiltzaileak beste fabrikatzaile batzuen kamera merkeagoak zerbitzura konektatzeko aukerari buruzko galderak egiten hasi ziren.

Saltzaile bakoitzarentzat integrazio geruza bat ezartzeko aukera baztertu nuen ia berehala, eskala eskasa baita eta kameraren hardwareari eskakizun tekniko larriak ezartzen dizkiolako. Sarrera-baldintza hauek betetzen dituen kamera baten kostua: ~60-70$

Hori dela eta, sakontzea erabaki nuen - edozein saltzailetako kamerentzako nire firmwarea egitea. Ikuspegi honek kameraren hardware-baliabideen eskakizunak nabarmen murrizten ditu - zeren Hodeiarekin lan egiteko geruza askoz modu eraginkorragoan integratuta dago bideo-aplikazioarekin, eta ez dago alferrikako koiperik firmwarean.

Eta garrantzitsua dena da kamerarekin maila baxuan lan egiten denean, hardware AES erabiltzea posible dela, datuak enkriptatzen dituena potentzia baxuko CPUan karga gehigarririk sortu gabe.

Momentu horretan ez genuen ezer. Ezer ere ez.

Ia saltzaile guztiak ez zeuden prest gurekin hain maila baxuan lan egiteko. Ez dago zirkuituei eta osagaiei buruzko informaziorik, ez dago chipset eta sentsoreen dokumentazio SDK ofizialik.
Ez dago laguntza teknikorik ere.

Galdera guztiak alderantzizko ingeniaritzaren bidez erantzun behar izan ziren: saiakuntza eta errorea. Baina lortu genuen.

Probatu genituen lehen kamera modeloak Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link kamera eta izenik gabeko txinatar kamera ultramerkeak izan ziren.

Teknika

Hisilicon 3518E chipsetean oinarritutako kamerak. Kameren hardwarearen ezaugarriak hauek dira:

Xiaomi Yi Inurriak
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofonoa
+
+

Hizlaria
+
+

IRLed
+
+

IRCut
+
+

Haiekin hasi ginen.

Gaur egun Hisilicon 3516/3518 chipset-ak onartzen ditugu, baita Ambarella S2L/S2LM ere. Dozenaka kamera modelo daude.

Firmwarearen osaera

itsaspeko

uboot abioko kargatzailea da, piztu ondoren lehenik abiarazten du, hardwarea hasieratzen du eta linux nukleoa kargatzen du.

Kamera kargatzeko gidoia nahiko hutsala da:

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

Ezaugarrietako bat bi aldiz deitzen dela da bootm, honi buruz gehiago pixka bat geroago, eguneratze azpisistemara iristen garenean.

Erreparatu lerroari mem=38M. Bai, bai, hau ez da akatsa - Linux kernelak eta aplikazio guztiek, guztiek, 38 megabyte RAM soilik dute sarbidea.

Era berean, uboot-en ondoan deitzen den bloke berezi bat dago reg_info, DDR hasieratzeko maila baxuko script bat eta SoC-ren sistema-erregistro batzuk dituena. Edukia reg_info kamera-ereduaren araberakoa da, eta zuzena ez bada, kamera ezingo du uboot kargatu ere egin, baina kargatzearen hasierako fasean izoztuko da.

Hasieran, saltzaileen laguntzarik gabe lan egiten genuenean, bloke hau jatorrizko kameraren firmwaretik kopiatu genuen.

Linux kernel eta rootfs

Kamerek Linux nukleoa erabiltzen dute, txiparen SDK-aren parte dena; normalean hauek ez dira 3.x adarreko azken nukleoak, beraz, askotan, ekipamendu gehigarrietarako kontrolatzaileak erabiltzen diren nukleoarekin bateragarriak ez direla aurre egin behar izaten dugu. , eta atzera eraman behar ditugu nukleoko kameretara.

Beste arazo bat nukleoaren tamaina da. FLASH tamaina 8MB baino ez denean, byte bakoitzak balio du eta gure zeregina da erabiltzen ez diren nukleoaren funtzio guztiak arretaz desgaitzea, tamaina minimora murrizteko.

Rootfs oinarrizko fitxategi sistema bat da. barne hartzen ditu busybox, wifi moduluen kontrolatzaileak, sistemaren liburutegi estandar multzo bat, esaterako libld и libc, baita gure softwarea ere, hau da, LED kontrol logikaren, sareko konexioen kudeaketaren eta firmware eguneratzearen arduraduna.

Erro fitxategi-sistema initramfs gisa konektatzen da nukleoarekin eta eraikitzearen ondorioz fitxategi bat lortzen dugu uImage, nukleoa eta rootfs dituena.

Bideo aplikazioa

Firmwarearen zatirik konplexuena eta baliabiderik handiena duen aplikazioa da, bideo-audio harrapaketa, bideo-kodeketa eskaintzen duena, irudi-parametroak konfiguratzen dituena, bideo-analisiak ezartzen dituena, adibidez, mugimendu- edo soinu-detektagailuak, PTZ kontrolatzen duena eta eguna aldatzeaz arduratzen dena. gaueko moduak.

Ezaugarri garrantzitsu bat, gakoa ere esango nuke, bideo-aplikazioak hodeiko pluginarekin nola elkarreragiten duen da.

Soluzio tradizionaletan, hardware merkean funtzionatu ezin duten "saltzaileen firmwarea + hodeiko plugina", kameraren barruko bideoa RTSP protokoloaren bidez transmititzen da, eta hau kostu handia da: datuak socket bidez kopiatzea eta transmititzea, alferrikako syscall-ak.

Leku honetan partekatutako memoria-mekanismoa erabiltzen dugu - bideoa ez da kameraren softwarearen osagaien artean socket bidez kopiatzen edo bidaltzen, eta horrela kameraren hardware gaitasun xumeak modu ezin hobean eta arretaz erabiliz.

Eguneratu azpisistema

Harrotasun bereziko puntu bat lineako firmware eguneratzeak akatsekiko tolerantzia duen azpisistema da.

Utzidazu arazoa azaltzen. Firmwarea eguneratzea teknikoki ez da eragiketa atomiko bat, eta eguneraketaren erdian elektrizitate hutsegite bat gertatzen bada, flash memoriak "azpian idatzitako" firmware berriaren zati bat edukiko du. Neurri berezirik hartzen ez baduzu, kamera zerbitzu zentro batera eraman beharreko "adreilu" bihurtuko da.

Arazo honi ere aurre egin diogu. Eguneratzean kamera itzalita badago ere, automatikoki eta erabiltzaileen esku-hartzerik gabe deskargatuko du firmwarea hodeitik eta funtzionamendua berrezartuko du.

Ikus dezagun teknika zehatzago:

Puntu zaurgarriena Linux kernelarekin eta erro fitxategi sistemarekin partizioa gainidaztea da. Osagai horietako bat hondatuta badago, kamera ez da batere abiaraziko uboot abiaraztearen kargagailutik haratago, ezin baitu hodeitik firmwarea deskargatu.

Horrek esan nahi du kamerak funtzionatzen duen nukleoa eta rootf-ak dituela ziurtatu behar dugula eguneratze-prozesuan edozein unetan. Badirudi irtenbiderik errazena nukleoaren bi kopia rootfs-ekin etengabe gordetzea flash memorian eta, kernel nagusia hondatuta badago, babeskopiatik kargatzea.

Irtenbide ona - hala ere, rootfs duen nukleoak 3.5 MB inguru hartzen ditu eta babeskopia iraunkor bat izateko 3.5 MB esleitu behar dituzu. Kamera merkeenek, besterik gabe, ez dute horrenbeste leku librerik babeskopia-kernel baterako.

Hori dela eta, firmware-eguneratzean nukleoaren babeskopia egiteko, aplikazioaren partizioa erabiltzen dugu.
Eta nukleoarekin nahi den partizioa hautatzeko, bi komando erabiltzen dira bootm uboot-en - hasieran nukleo nagusia kargatzen saiatzen gara eta hondatuta badago, babeskopia.

Horrek bermatzen du edozein unetan kamerak kernel zuzena izango duela rootfs-ekin, eta firmwarea abiarazi eta leheneratu ahal izango duela.

Firmwarea eraikitzeko eta zabaltzeko CI/CD sistema

Firmwarea eraikitzeko, gitlab CI erabiltzen dugu, onartzen diren kamera-modelo guztietarako firmwarea automatikoki eraikitzen duena, eta firmwarea eraiki ondoren, kameraren softwarea eguneratzeko zerbitzura automatikoki zabaltzen da.

Zerbitzutik, firmware-eguneratzeak gure QA proba-kameretara bidaltzen dira, eta proba-fase guztiak amaitzean, erabiltzaileen kameretara.

Informazioaren Segurtasuna

Ez da sekretua gaur egun informazioaren segurtasuna dela edozein IoT gailuren alderdirik garrantzitsuena, kamerak barne. Mirai bezalako botnetak Interneten ibiltzen ari dira, eta milioika kamera kutsatzen dituzte saltzaileen firmware estandarrarekin. Kamera-saltzaileei errespetu osoz, ezin dut ohartu firmware estandarrak hodeiarekin lan egiteko beharrezkoak ez diren funtzionalitate asko dituela, baina botnetek aprobetxatzen dituzten ahultasun asko dituela.

Hori dela eta, gure firmwarean erabiltzen ez diren funtzionalitate guztiak desgaituta daude, tcp/udp ataka guztiak itxita daude eta firmwarea eguneratzean, softwarearen sinadura digitala egiaztatzen da.

Eta horretaz gain, firmwareak aldizka probak egiten ditu informazioaren segurtasun laborategian.

Ondorioa

Orain gure firmwarea modu aktiboan erabiltzen da bideo-zaintza proiektuetan. Horietako handiena, beharbada, Errusiar Federazioko presidentea aukeratzeko egunean bozketen emankizuna da.
Proiektuak gure firmwarearekin 70 mila kamera baino gehiago hartu zituen parte, gure herrialdeko hauteslekuetan instalatuta zeudenak.

Zenbait arazo konplexu konponduta, eta zenbait lekutan, garai hartan ia ezinezkoak ere, ingeniari bezala poztasun handia jaso genuen, noski, baina horretaz gain, kamerak erostean milioika dolar aurreztu genituen. Eta kasu honetan, aurrezpena ez dira hitzak eta kalkulu teorikoak soilik, ekipamenduak erosteko dagoeneko amaitutako lizitazio baten emaitzak baizik. Horren arabera, hodeiko bideo-zaintzari buruz hitz egiten badugu: bi ikuspegi daude: estrategikoki maila baxuko espezializazioan eta garapenean oinarritzea, ekipamenduetan aurrezpen handia lortuz, edo ekipamendu garestiak erabiltzea, kontsumitzaileen ezaugarriak bereziki aztertuz gero, ia ez da. antzeko merkeen desberdina.

Zergatik da estrategikoki garrantzitsua integrazio-ikuspegia aukeratzea lehenbailehen erabakitzea? Plugin bat garatzerakoan, garatzaileek teknologia jakin batzuetan oinarritzen dira (liburutegiak, protokoloak, estandarrak). Eta teknologia-multzo bat ekipo garestietarako soilik aukeratzen bada, etorkizunean kamera merkeetara aldatzeko saiakerak ziurrenik, gutxienez, denbora luzea beharko du edo are huts egin eta ekipo garestietara itzultzea gertatuko da.

Iturria: www.habr.com