Përshëndetje të gjithëve!

Ndoshta nuk është sekret që shërbimet e mbikqyrjes video në cloud kanë fituar popullaritet kohët e fundit. Dhe është e qartë pse ndodh kjo, video është një përmbajtje "e rëndë", ruajtja e së cilës kërkon infrastrukturë dhe sasi të mëdha të ruajtjes së diskut. Përdorimi i një sistemi të mbikqyrjes video në ambiente kërkon fonde për funksionimin dhe mbështetjen, si për një organizatë që përdor qindra kamera vëzhgimi, ashtu edhe për një përdorues individual me disa kamera.

Sistemet e mbikqyrjes video në re e zgjidhin këtë problem duke u ofruar klientëve një infrastrukturë ekzistuese të ruajtjes dhe përpunimit të videos. Një klient i mbikëqyrjes video në cloud thjesht duhet të lidhë kamerën me internetin dhe ta lidhë atë me llogarinë e tij cloud.

Ka disa mënyra teknologjike për të lidhur kamerat me cloud. Padyshim, metoda më e përshtatshme dhe më e lirë është që kamera lidhet dhe funksionon drejtpërdrejt me cloud, pa pjesëmarrjen e pajisjeve shtesë si serveri ose regjistruesi.

Për ta bërë këtë, është e nevojshme që një modul softuerësh që punon me cloud të instalohet në kamerë. Sidoqoftë, nëse flasim për kamera të lira, atëherë ato kanë burime harduerike shumë të kufizuara, të cilat janë pothuajse 100% të zëna nga firmware-i vendas i shitësit të kamerës dhe nuk ka burime të nevojshme për shtojcën cloud. Zhvilluesit nga ivideon i kushtuan këtij problemi një artikull, gjë që shpjegon pse ata nuk mund ta instalojnë shtesën në kamera të lira. Si rezultat, çmimi minimal i kamerës është 5000 rubla (80 dollarë) dhe miliona para të shpenzuara për pajisje.

Ne e kemi zgjidhur me sukses këtë problem. Nëse jeni të interesuar se si - mirë se vini në prerje

Pak histori

Në vitin 2016, ne filluam të zhvillojmë një platformë të mbikëqyrjes video cloud për Rostelecom.

Për sa i përket softuerit të kamerës, në fazën e parë ne ndoqëm rrugën "standarde" për detyra të tilla: zhvilluam shtojcën tonë, e cila është e instaluar në firmuerin standard të kamerës së shitësit dhe punon me renë tonë. Sidoqoftë, vlen të përmendet se gjatë projektimit kemi përdorur zgjidhjet më të lehta dhe më efikase (për shembull, zbatimi i thjeshtë C i protobuf, libev, mbedtls dhe bibliotekat e rehatshme por të rënda të braktisura si boost)

Aktualisht, nuk ka zgjidhje universale integrimi në tregun e kamerës IP: çdo shitës ka mënyrën e vet të instalimit të shtojcës, grupin e vet të API-ve për funksionimin e firmuerit dhe një mekanizëm unik përditësimi.

Kjo do të thotë se për çdo shitës kamerash është e nevojshme që individualisht të zhvillohet një shtresë gjithëpërfshirëse e softuerit integrues. Dhe në momentin e fillimit të zhvillimit, këshillohet të punoni vetëm me 1 shitës në mënyrë që të përqendroni përpjekjet e ekipit në zhvillimin e logjikës për të punuar me cloud.

Shitësi i parë i zgjedhur ishte Hikvision, një nga liderët botërorë në tregun e kamerave, duke ofruar një API të mirë-dokumentuar dhe mbështetje teknike inxhinierike kompetente.

Ne lançuam projektin tonë të parë pilot, video-mbikëqyrjen e reve, Video Comfort, duke përdorur kamerat Hikvision.

Pothuajse menjëherë pas lançimit, përdoruesit tanë filluan të bënin pyetje në lidhje me mundësinë e lidhjes së kamerave më të lira nga prodhues të tjerë me shërbimin.

Unë hodha poshtë opsionin e zbatimit të një shtrese integrimi për çdo shitës pothuajse menjëherë - pasi është i shkallëzuar dobët dhe imponon kërkesa serioze teknike në harduerin e kamerës. Kostoja e një aparati fotografik që plotëson këto kërkesa hyrëse: ~60-70$

Prandaj, vendosa të gërmoj më thellë - të bëj firmware-in tim për kamera nga çdo shitës. Kjo qasje redukton ndjeshëm kërkesat për burimet e harduerit të kamerës - sepse Shtresa për të punuar me cloud është shumë më efektive e integruar me aplikacionin video dhe nuk ka yndyrë të panevojshme të papërdorur në firmware.

Dhe ajo që është e rëndësishme është se kur punoni me kamerën në një nivel të ulët, është e mundur të përdorni harduerin AES, i cili kodon të dhënat pa krijuar ngarkesë shtesë në CPU me fuqi të ulët.

Në atë moment nuk kishim asgjë. Asgjë fare.

Pothuajse të gjithë shitësit nuk ishin të gatshëm të punonin me ne në një nivel kaq të ulët. Nuk ka asnjë informacion në lidhje me qarkun dhe komponentët, nuk ka asnjë SDK zyrtare të çipave dhe dokumentacionit të sensorëve.
Nuk ka as mbështetje teknike.

Të gjitha pyetjet duhej të përgjigjeshin përmes inxhinierisë së kundërt - provë dhe gabim. Por ia dolëm.

Modelet e para të kamerave që testuam ishin kamerat Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link dhe disa kamera kineze pa emër jashtëzakonisht të lira.

Teknikë

Kamerat e bazuara në chipset Hisilicon 3518E. Karakteristikat harduerike të kamerave janë si më poshtë:

Xiaomi Yi Ants
noname

KOS
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

microSD
+
+

mikrofon
+
+

Folës
+
+

IRLed
+
+

IRCut
+
+

Ne filluam me ta.

Aktualisht ne mbështesim chipset Hisilicon 3516/3518, si dhe Ambarella S2L/S2LM. Ka dhjetëra modele kamerash.

Përbërja e firmuerit

nëndetëse

uboot është ngarkuesi i nisjes, ai nis fillimisht pas ndezjes, inicializon harduerin dhe ngarkon kernelin linux.

Skripti i ngarkimit të kamerës është mjaft i parëndësishëm:

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

Një nga veçoritë është se thirret dy herë bootm, më shumë për këtë pak më vonë, kur të arrijmë te nënsistemi i përditësimit.

Kushtojini vëmendje linjës mem=38M. Po, po, kjo nuk është një gabim shtypi - kerneli i Linux dhe të gjitha, të gjitha, të gjitha aplikacionet kanë qasje në vetëm 38 megabajt RAM.

Gjithashtu pranë uboot ka një bllok të veçantë të quajtur reg_info, i cili përmban një skript të nivelit të ulët për inicializimin e DDR dhe një numër regjistrash të sistemit të SoC. përmbajtja reg_info varet nga modeli i kamerës dhe nëse nuk është i saktë, kamera nuk do të jetë në gjendje as të ngarkojë uboot, por do të ngrijë në fazën shumë të hershme të ngarkimit.

Në fillim, kur punuam pa mbështetjen e shitësit, thjesht e kopjuam këtë bllok nga firmware-i origjinal i kamerës.

Kernel Linux dhe rootfs

Kamerat përdorin kernelin Linux, i cili është pjesë e SDK-së së çipit; zakonisht këto nuk janë kernelet më të fundit nga dega 3.x, kështu që shpesh duhet të merremi me faktin që drejtuesit për pajisje shtesë nuk janë në përputhje me kernelin e përdorur. , dhe ne duhet t'i kthejmë ato në kamerat e kernelit.

Një çështje tjetër është madhësia e kernelit. Kur madhësia e FLASH është vetëm 8 MB, atëherë çdo bajt vlen dhe detyra jonë është të çaktivizojmë me kujdes të gjitha funksionet e kernelit të papërdorura në mënyrë që të zvogëlojmë madhësinë në minimum.

Rootfs është një sistem skedari bazë. Ai përfshin busybox, drejtuesit e modulit wifi, një grup bibliotekash standarde të sistemit, si p.sh libld и libc, si dhe softuerin tonë, i cili është përgjegjës për logjikën e kontrollit LED, menaxhimin e lidhjes së rrjetit dhe përditësimet e firmuerit.

Sistemi i skedarëve rrënjë është i lidhur me kernelin si initramfs dhe si rezultat i ndërtimit marrim një skedar uImage, i cili përmban si kernelin ashtu edhe rrënjët.

Aplikacioni video

Pjesa më komplekse dhe me burime intensive të firmuerit është aplikacioni, i cili ofron kapje video-audio, kodim video, konfiguron parametrat e figurës, zbaton analitikë video, për shembull, detektorë lëvizjeje ose zëri, kontrollon PTZ dhe është përgjegjës për ndërrimin e ditës dhe mënyrat e natës.

Një veçori e rëndësishme, madje do të thoja kryesore, është se si aplikacioni video ndërvepron me shtojcën cloud.

Në zgjidhjet tradicionale 'firmware-i i shitësit + shtojca cloud', e cila nuk mund të funksionojë në harduer të lirë, video brenda kamerës transmetohet përmes protokollit RTSP - dhe kjo është një shpenzim i madh: kopjimi dhe transmetimi i të dhënave përmes prizës, thirrjet e panevojshme të sistemit.

Këtu ne përdorim mekanizmin e kujtesës së përbashkët - videoja nuk kopjohet ose dërgohet përmes prizës midis komponentëve të softuerit të kamerës, duke përdorur kështu në mënyrë optimale dhe me kujdes aftësitë modeste harduerike të kamerës.

Përditëso nënsistemin

Një pikë krenarie e veçantë është nënsistemi tolerant ndaj gabimeve për përditësimet në internet të firmuerit.

Më lejoni të shpjegoj problemin. Përditësimi i firmuerit teknikisht nuk është një operacion atomik, dhe nëse ndodh një ndërprerje e energjisë në mes të përditësimit, atëherë memoria flash do të përmbajë një pjesë të firmware-it të ri "të nënshkruar". Nëse nuk merrni masa të veçanta, kamera do të bëhet më pas një "tullë" që duhet të dërgohet në një qendër shërbimi.

Ne jemi marrë edhe me këtë problem. Edhe nëse kamera fiket gjatë përditësimit, ajo automatikisht dhe pa ndërhyrjen e përdoruesit do të shkarkojë firmuerin nga cloud dhe do të rivendosë funksionimin.

Le të shohim teknikën në më shumë detaje:

Pika më e cenueshme është mbishkrimi i ndarjes me kernelin Linux dhe sistemin e skedarëve rrënjë. Nëse një nga këta komponentë është i dëmtuar, kamera nuk do të niset fare përtej ngarkuesit të uboot, i cili nuk mund të shkarkojë firmware nga cloud.

Kjo do të thotë që ne duhet të sigurohemi që kamera të ketë një kernel funksional dhe rootf në çdo kohë gjatë procesit të përditësimit. Duket se zgjidhja më e thjeshtë do të ishte ruajtja e vazhdueshme e dy kopjeve të kernelit me rootf në memorie flash dhe, nëse kerneli kryesor është i dëmtuar, ngarkoni atë nga kopja rezervë.

Një zgjidhje e mirë - megjithatë, kerneli me rootfs zë rreth 3.5 MB dhe për një kopje rezervë të përhershme duhet të ndani 3.5 MB. Kamerat më të lira thjesht nuk kanë aq hapësirë ​​​​të lirë për një kernel rezervë.

Prandaj, për të kopjuar kernelin gjatë një përditësimi të firmuerit, ne përdorim ndarjen e aplikacionit.
Dhe për të zgjedhur ndarjen e dëshiruar me kernel, përdoren dy komanda bootm në uboot - në fillim përpiqemi të ngarkojmë kernelin kryesor dhe nëse është i dëmtuar, atëherë atë rezervë.

Kjo siguron që në çdo moment kamera do të ketë kernelin e duhur me rootfs dhe do të jetë në gjendje të nisë dhe të rivendosë firmuerin.

Sistemi CI/CD për ndërtimin dhe vendosjen e firmuerit

Për të ndërtuar firmuerin, ne përdorim gitlab CI, i cili ndërton automatikisht firmuerin për të gjitha modelet e kamerave të mbështetura dhe pas ndërtimit të firmuerit, ai vendoset automatikisht në shërbimin e përditësimit të softuerit të kamerës.

Nga shërbimi, përditësimet e firmuerit dorëzohen në kamerat tona të testimit të cilësisë së cilësisë dhe pas përfundimit të të gjitha fazave të testimit, në kamerat e përdoruesve.

Siguria e informacionit

Nuk është sekret se në ditët e sotme siguria e informacionit është aspekti më i rëndësishëm i çdo pajisjeje IoT, përfshirë kamerat. Botnets si Mirai po qarkullojnë në internet, duke infektuar miliona kamera me firmware standarde nga shitësit. Me gjithë respektin e duhur për shitësit e kamerave, nuk mund të mos vërej se firmware-i standard përmban shumë funksionalitete që nuk nevojiten për të punuar me cloud, por përmban shumë dobësi nga të cilat përfitojnë botnet-et.

Prandaj, i gjithë funksionaliteti i papërdorur në firmuerin tonë është i çaktivizuar, të gjitha portat tcp/udp janë të mbyllura dhe gjatë përditësimit të firmuerit, kontrollohet nënshkrimi dixhital i softuerit.

Dhe përveç kësaj, firmware i nënshtrohet testimit të rregullt në laboratorin e sigurisë së informacionit.

Përfundim

Tani firmware-i ynë përdoret në mënyrë aktive në projektet e mbikëqyrjes video. Ndoshta më i madhi prej tyre është transmetimi i votimit në ditën e zgjedhjes së Presidentit të Federatës Ruse.
Projekti përfshinte më shumë se 70 mijë kamera me firmuerin tonë, të cilat u instaluan në qendrat e votimit në vendin tonë.

Pasi zgjidhëm një sërë problemesh komplekse, dhe në disa vende, edhe në atë kohë pothuajse të pamundura, ne, natyrisht, morëm kënaqësi të madhe si inxhinierë, por përveç kësaj, kemi kursyer edhe miliona dollarë për blerjen e kamerave. Dhe në këtë rast, kursimet nuk janë vetëm fjalë dhe përllogaritje teorike, por rezultate të një tenderi tashmë të përfunduar për blerjen e pajisjeve. Prandaj, nëse flasim për mbikëqyrjen video në cloud: ekzistojnë dy qasje - mbështetuni strategjikisht në ekspertizë dhe zhvillim të nivelit të ulët, duke rezultuar në kursime të mëdha në pajisje, ose përdorni pajisje të shtrenjta, të cilat, nëse shikoni në mënyrë specifike karakteristikat e konsumatorit, praktikisht nuk janë. të ndryshme nga ato të lira të ngjashme.

Pse është strategjikisht e rëndësishme të vendoset për zgjedhjen e qasjes së integrimit sa më shpejt që të jetë e mundur? Kur zhvillojnë një shtojcë, zhvilluesit mbështeten në disa teknologji (biblioteka, protokolle, standarde). Dhe nëse një grup teknologjish zgjidhet vetëm për pajisje të shtrenjta, atëherë në të ardhmen një përpjekje për të kaluar në kamera të lira ka shumë të ngjarë, të paktën, të marrë një kohë jashtëzakonisht të gjatë ose edhe të dështojë dhe do të ndodhë një kthim në pajisjet e shtrenjta.

Burimi: www.habr.com