Tere kõigile!

Pole ilmselt saladus, et pilvevideovalveteenused on viimasel ajal populaarsust kogunud. Ja on selge, miks see juhtub, video on "raske" sisu, mille salvestamiseks on vaja infrastruktuuri ja palju kettaruumi. Kohapealse videovalvesüsteemi kasutamine nõuab rahalisi vahendeid nii sadu valvekaameraid kasutava organisatsiooni kui ka mitme kaameraga üksikkasutaja jaoks.

Pilvvideovalvesüsteemid lahendavad selle probleemi, pakkudes klientidele olemasolevat videosalvestuse ja -töötluse infrastruktuuri. Pilvevideovalve klient peab lihtsalt ühendama kaamera Internetti ja siduma selle oma pilvekontoga.

Kaamerate pilvega ühendamiseks on mitmeid tehnoloogilisi viise. Kõige mugavam ja odavam meetod on kahtlemata see, et kaamera loob otseühenduse ja töötab pilvega, ilma lisaseadmete, näiteks serveri või salvesti osaluseta.

Selleks on vajalik, et kaamerasse oleks installitud pilvega töötav tarkvaramoodul. Kui aga rääkida odavatest kaameratest, siis neil on väga piiratud riistvararessursid, mis on peaaegu 100% hõivatud kaamera müüja natiivse püsivara poolt ning pilve plugina jaoks vajalikke ressursse pole. Ivideoni arendajad pühendasid sellele probleemile artiklit, mis selgitab, miks nad ei saa odavatesse kaameratesse pistikprogrammi installida. Selle tulemusena on kaamera minimaalne hind 5000 rubla (80 dollarit) ja varustusele kulub miljoneid raha.

Oleme selle probleemi edukalt lahendanud. Kui olete huvitatud, kuidas - tere tulemast lõikama

Veidi ajalugu

2016. aastal alustasime Rostelecomi pilvvideovalveplatvormi arendamist.

Kaamera tarkvara osas järgisime esimeses etapis selliste ülesannete jaoks "standardset" teed: töötasime välja oma pistikprogrammi, mis on installitud müüja kaamera standardsesse püsivara ja töötab meie pilvega. Siiski väärib märkimist, et projekteerimisel kasutasime kõige kergemaid ja tõhusamaid lahendusi (näiteks protobuf, libev, mbedtls ja libev, mbedtls ja täiesti hüljatud mugavad, kuid rasked teegid nagu boost)

Praegu pole IP-kaamerate turul universaalseid integratsioonilahendusi: igal müüjal on oma viis pistikprogrammi installimiseks, oma API-de komplekt püsivara kasutamiseks ja ainulaadne värskendusmehhanism.

See tähendab, et iga kaameramüüja jaoks on vaja individuaalselt välja töötada terviklik integratsioonitarkvara kiht. Ja arenduse alustamise ajal on soovitatav töötada ainult ühe tarnijaga, et koondada meeskonna jõupingutused pilvega töötamise loogika arendamisele.

Esimeseks müüjaks valiti Hikvision, üks maailma kaameraturu liidritest, pakkudes hästi dokumenteeritud API-d ja pädevat tehnilist tuge.

Hikvisioni kaamerate abil käivitasime oma esimese pilootprojekti, pilvvideovalve Video Comfort.

Peaaegu kohe pärast turuletoomist hakkasid meie kasutajad küsima, kas on võimalik teenusega ühendada teiste tootjate odavamaid kaameraid.

Lükkasin peaaegu kohe tagasi võimaluse rakendada iga müüja jaoks integratsioonikiht - kuna see on halvasti skaleeritav ja seab kaamera riistvarale tõsised tehnilised nõuded. Nendele sisendnõuetele vastava kaamera maksumus: ~60-70$

Seetõttu otsustasin kaevata sügavamale - teha oma püsivara mis tahes müüja kaamerate jaoks. Selline lähenemine vähendab oluliselt nõudeid kaamera riistvararessurssidele – kuna Pilvega töötamise kiht on videorakendusega palju tõhusamalt integreeritud ja püsivarasse ei jää tarbetut kasutamata rasva.

Ja mis on oluline, on see, et kaameraga madalal tasemel töötades on võimalik kasutada riistvaralist AES-i, mis krüpteerib andmed ilma vähese energiatarbega protsessorile täiendavat koormust tekitamata.

Sel hetkel polnud meil üldse mitte midagi. Mitte midagi.

Peaaegu kõik müüjad ei olnud valmis meiega nii madalal tasemel koostööd tegema. Puudub teave vooluringide ja komponentide kohta, puudub ametlik kiibikomplektide SDK ja andurite dokumentatsioon.
Samuti puudub tehniline tugi.

Kõikidele küsimustele tuli vastata pöördprojekteerimise teel – katse-eksituse meetodil. Aga saime hakkama.

Esimesed kaameramudelid, millega testisime, olid Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Linki kaamerad ja mitmed üliodavad nimetu Hiina kaamerad.

Tehnika

Hisilicon 3518E kiibistikul põhinevad kaamerad. Kaamerate riistvara omadused on järgmised:

Xiaomi Yi Ants
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Andur
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Kõneleja
+
+

IRLed
+
+

IRCut
+
+

Alustasime nendega.

Toetame praegu Hisilicon 3516/3518 kiibikomplekte, aga ka Ambarella S2L/S2LM. Kaameramudeleid on kümneid.

Püsivara koostis

allveelaev

uboot on alglaadur, see käivitub kõigepealt pärast sisselülitamist, lähtestab riistvara ja laadib Linuxi tuuma.

Kaamera laadimisskript on üsna triviaalne:

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

Üks omadusi on see, et seda kutsutakse kaks korda bootm, sellest lähemalt veidi hiljem, kui jõuame värskenduse alamsüsteemini.

Pöörake tähelepanu joonele mem=38M. Jah, jah, see pole kirjaviga – Linuxi kernel ja kõik, kõik, kõik rakendused pääsevad ligi vaid 38 megabaidile RAM-ile.

Ka ubooti kõrval on spetsiaalne plokk nimega reg_info, mis sisaldab madala taseme skripti DDR-i lähtestamiseks ja mitmeid SoC süsteemiregistreid. Sisu reg_info oleneb kaamera mudelist ja kui see pole õige, ei saa kaamera isegi ubooti laadida, vaid hangub juba laadimise alguses.

Alguses, kui töötasime ilma tarnija toeta, kopeerisime selle ploki lihtsalt kaamera algsest püsivarast.

Linuxi kernel ja juurfailid

Kaamerad kasutavad Linuxi kernelit, mis on osa kiibi SDK-st; tavaliselt pole need 3.x haru uusimad tuumad, mistõttu peame sageli leppima tõsiasjaga, et lisaseadmete draiverid ei ühildu kasutatava tuumaga , ja me peame need kerneli kaameratesse tagasi portima.

Teine probleem on tuuma suurus. Kui FLASH-i suurus on ainult 8 MB, loeb iga bait ja meie ülesanne on hoolikalt keelata kõik kasutamata kerneli funktsioonid, et vähendada suurust miinimumini.

Rootfs on põhiline failisüsteem. See sisaldab busybox, wifi mooduli draiverid, standardsete süsteemiteekide komplekt, nt libld и libc, samuti meie tarkvara, mis vastutab LED-juhtimise loogika, võrguühenduse haldamise ja püsivara värskenduste eest.

Juurfailisüsteem on kerneliga ühendatud initramfs-ina ja ehitamise tulemusena saame ühe faili uImage, mis sisaldab nii tuuma kui ka juurfaile.

Videorakendus

Püsivara kõige keerulisem ja ressursimahukam osa on rakendus, mis pakub video-heli jäädvustamist, video kodeerimist, konfigureerib pildiparameetreid, rakendab videoanalüüsi, näiteks liikumis- või heliandureid, juhib PTZ-d ning vastutab päevade ja päevade vahetamise eest. öörežiimid.

Oluline, ma isegi ütleksin võtmefunktsioon, on see, kuidas videorakendus pilve pistikprogrammiga suhtleb.

Traditsioonilistes lahendustes "müüja püsivara + pilve pistikprogramm", mis ei saa töötada odava riistvaraga, edastatakse kaamera sees video RTSP-protokolli kaudu - ja see on tohutu kulu: andmete kopeerimine ja edastamine pistikupesa kaudu, mittevajalikud süsteemikõned.

Selles kohas kasutame ühismälu mehhanismi – videot ei kopeerita ega edastata kaamera tarkvarakomponentide vahelise pesa kaudu, kasutades seeläbi optimaalselt ja hoolikalt kaamera tagasihoidlikke riistvaralisi võimalusi.

Värskendage allsüsteemi

Eriline uhkus on veebipõhise püsivara värskenduste tõrketaluv alamsüsteem.

Las ma selgitan probleemi. Püsivara värskendamine ei ole tehniliselt aatomioperatsioon ja kui keset värskendust tekib voolukatkestus, sisaldab välkmälu osa "alla kirjutatud" uuest püsivarast. Kui te erimeetmeid ei võta, muutub kaamera "telliskiviks", mis tuleb teeninduskeskusesse viia.

Oleme ka selle probleemiga tegelenud. Isegi kui kaamera on värskendamise ajal välja lülitatud, laadib see püsivara automaatselt ja ilma kasutaja sekkumiseta pilvest alla ja taastab töö.

Vaatame tehnikat üksikasjalikumalt:

Kõige haavatavam punkt on partitsiooni ülekirjutamine Linuxi tuuma ja juurfailisüsteemiga. Kui üks neist komponentidest on kahjustatud, ei käivitu kaamera üldse peale uboot bootloaderit, mis ei saa püsivara pilvest alla laadida.

See tähendab, et peame tagama, et kaameral oleks igal ajal värskendusprotsessi ajal töötav kernel ja juurfailid. Tundub, et lihtsaim lahendus oleks hoida pidevalt välkmällu kaks kerneli juurte koopiat ja kui põhituum on kahjustatud, laadida see varukoopiast.

Hea lahendus – rootfsiga kernel aga võtab enda alla ca 3.5MB ja püsivaks varukoopiaks tuleb eraldada 3.5MB. Odavaimatel kaameratel pole lihtsalt varutuuma jaoks nii palju vaba ruumi.

Seetõttu kasutame püsivara värskenduse ajal kerneli varundamiseks rakenduse partitsiooni.
Ja kerneliga soovitud partitsiooni valimiseks kasutatakse kahte käsku bootm in uboot - alguses proovime laadida põhikerneli ja kui see on kahjustatud, siis varutuuma.

See tagab, et kaameral on igal ajahetkel õige kernel koos rootfsidega ning see suudab püsivara alglaadida ja taastada.

CI/CD süsteem püsivara loomiseks ja juurutamiseks

Püsivara ehitamiseks kasutame gitlab CI-d, mis ehitab automaatselt püsivara kõikidele toetatud kaameramudelitele ja pärast püsivara koostamist juurutatakse see automaatselt kaamera tarkvara värskendusteenusesse.

Teenusest tarnitakse püsivara värskendused meie kvaliteedikontrolli testkaameratesse ja pärast kõigi testimisetappide lõppemist kasutajate kaameratesse.

Infoturbe

Pole saladus, et infoturve on tänapäeval iga IoT-seadme, sealhulgas kaamerate, kõige olulisem aspekt. Sellised robotvõrgud nagu Mirai rändlevad Internetis, nakatades miljoneid kaameraid tarnijate standardse püsivaraga. Kogu lugupidamise juures kaameramüüjate vastu ei saa ma jätta märkimata, et standardne püsivara sisaldab palju funktsioone, mida pole pilvega töötamiseks vaja, kuid see sisaldab palju turvaauke, mida robotvõrgud ära kasutavad.

Seetõttu on kõik meie püsivara kasutamata funktsioonid keelatud, kõik tcp/udp pordid on suletud ja püsivara värskendamisel kontrollitakse tarkvara digitaalset allkirja.

Ja lisaks sellele testitakse püsivara regulaarselt infoturbe laboris.

Järeldus

Nüüd kasutatakse meie püsivara aktiivselt videovalveprojektides. Võib-olla suurim neist on hääletusülekanne Vene Föderatsiooni presidendi valimise päeval.
Projekt hõlmas enam kui 70 tuhat meie püsivaraga kaamerat, mis paigaldati meie riigi valimisjaoskondadesse.

Olles lahendanud mitmeid keerulisi ja kohati isegi tollal peaaegu võimatuid probleeme, saime inseneridena mõistagi suure rahulduse osaliseks, kuid peale selle hoidsime ka miljoneid dollareid kokku kaamerate ostmise pealt. Ja sel juhul pole kokkuhoid ainult sõnad ja teoreetilised arvutused, vaid juba lõppenud seadmete ostmise hanke tulemused. Seega, kui me räägime pilvevideovalvest: on kaks lähenemisviisi - tugineda strateegiliselt madalale asjatundlikkusele ja arendustegevusele, mille tulemuseks on tohutu seadmete kokkuhoid, või kasutada kalleid seadmeid, mis, kui vaadata konkreetselt tarbija omadusi, on praktiliselt olematu. erinevad sarnastest odavatest.

Miks on strateegiliselt oluline otsustada lõimumisviisi valiku üle võimalikult varakult? Plugina väljatöötamisel tuginevad arendajad teatud tehnoloogiatele (teegid, protokollid, standardid). Ja kui tehnoloogiate komplekt valitakse ainult kallite seadmete jaoks, siis tulevikus võtab katse minna üle odavatele kaameratele tõenäoliselt vähemalt meeletult kaua või isegi ebaõnnestub ja naaseb kallite seadmete juurde.

Allikas: www.habr.com