Hej alla!

Det är förmodligen ingen hemlighet att molnvideoövervakningstjänster har blivit populärare nyligen. Och det är tydligt varför detta händer, video är "tungt" innehåll, vars lagring kräver infrastruktur och stora mängder disklagring. Att använda ett lokalt videoövervakningssystem kräver pengar för att driva och stödja, både för en organisation som använder hundratals övervakningskameror och för en enskild användare med flera kameror.

Molnvideoövervakningssystem löser detta problem genom att förse kunderna med en befintlig videolagrings- och bearbetningsinfrastruktur. En molnvideoövervakningsklient behöver helt enkelt ansluta kameran till Internet och länka den till sitt molnkonto.

Det finns flera tekniska sätt att koppla kameror till molnet. Utan tvekan är den mest bekväma och billigaste metoden att kameran direkt ansluter och arbetar med molnet, utan medverkan av ytterligare utrustning som en server eller inspelare.

För att göra detta är det nödvändigt att en mjukvarumodul som fungerar med molnet är installerad på kameran. Men om vi pratar om billiga kameror, så har de mycket begränsade hårdvaruresurser, som nästan 100% upptas av kameraleverantörens inbyggda firmware, och det finns inga resurser som behövs för molnplugin. Utvecklare från ivideon ägnade detta problem Artikel, vilket förklarar varför de inte kan installera plugin på billiga kameror. Som ett resultat är minimipriset för kameran 5000 rubel ($80 dollar) och miljontals pengar spenderas på utrustning.

Vi har framgångsrikt löst detta problem. Om du är intresserad av hur - välkommen till klippet

Lite historia

Under 2016 började vi utveckla en molnvideoövervakningsplattform för Rostelecom.

När det gäller kameramjukvara följde vi i det första skedet "standard"-vägen för sådana uppgifter: vi utvecklade vår egen plugin, som är installerad i standardfirmwaren för leverantörens kamera och fungerar med vårt moln. Det är dock värt att notera att vi under designen använde de mest lätta och effektiva lösningarna (till exempel vanlig C-implementering av protobuf, libev, mbedtls och helt övergivna bekväma men tunga bibliotek som boost)

För närvarande finns det inga universella integrationslösningar på IP-kameramarknaden: varje leverantör har sitt eget sätt att installera plugin, sin egen uppsättning API:er för drift av den fasta programvaran och en unik uppdateringsmekanism.

Detta innebär att för varje kameraleverantör är det nödvändigt att individuellt utveckla ett omfattande lager av integrationsprogramvara. Och när utvecklingen påbörjas är det tillrådligt att endast arbeta med en leverantör för att koncentrera teamets ansträngningar på att utveckla logiken för att arbeta med molnet.

Den första leverantören som valdes var Hikvision, en av världsledande på kameramarknaden, som tillhandahåller ett väldokumenterat API och kompetent teknisk teknisk support.

Vi lanserade vårt första pilotprojekt, molnvideoövervakning Video Comfort, med hjälp av Hikvision-kameror.

Nästan direkt efter lanseringen började våra användare ställa frågor om möjligheten att koppla billigare kameror från andra tillverkare till tjänsten.

Jag avvisade alternativet att implementera ett integrationslager för varje leverantör nästan omedelbart - eftersom det är dåligt skalbart och ställer allvarliga tekniska krav på kamerans hårdvara. Kostnaden för en kamera som uppfyller dessa ingångskrav: ~60-70$

Därför bestämde jag mig för att gräva djupare - att göra min egen firmware för kameror från vilken leverantör som helst. Detta tillvägagångssätt minskar avsevärt kraven på kamerahårdvaruresurser - eftersom Lagret för att arbeta med molnet är mycket mer effektivt integrerat med videoapplikationen, och det finns inget onödigt oanvänt fett i firmwaren.

Och det som är viktigt är att när man arbetar med kameran på en låg nivå, är det möjligt att använda hårdvaru-AES, som krypterar data utan att skapa ytterligare belastning på lågeffektprocessorn.

I det ögonblicket hade vi ingenting alls. Ingenting alls.

Nästan alla leverantörer var inte redo att arbeta med oss ​​på en så låg nivå. Det finns ingen information om kretsar och komponenter, det finns ingen officiell SDK för chipset och sensordokumentation.
Det finns heller ingen teknisk support.

Alla frågor måste besvaras genom omvänd ingenjörskonst – försök och misstag. Men vi klarade oss.

De första kameramodellerna vi testade på var Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link-kameror och flera ultrabilliga namnlösa kinesiska kameror.

Teknik

Kameror baserade på Hisilicon 3518E chipset. Kamerornas hårdvaruegenskaper är följande:

Xiaomi Yi-myror
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

ethernet
-
+

MicroSD
+
+

Mikrofonen
+
+

Högtalare
+
+

IRLed
+
+

IRCut
+
+

Vi började med dem.

Vi stöder för närvarande Hisilicon 3516/3518-chipset, såväl som Ambarella S2L/S2LM. Det finns dussintals kameramodeller.

Firmware sammansättning

u-båt

uboot är starthanteraren, den startar först efter påslagning, initierar hårdvaran och laddar linux-kärnan.

Kameraladdningsskriptet är ganska trivialt:

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

En av funktionerna är att den kallas två gånger bootm, mer om detta lite senare, när vi kommer till uppdateringsundersystemet.

Var uppmärksam på linjen mem=38M. Ja, ja, det här är inget stavfel - Linux-kärnan och alla, alla, alla applikationer har tillgång till endast 38 megabyte RAM.

Bredvid uboot finns också ett speciellt block som heter reg_info, som innehåller ett lågnivåskript för initialisering av DDR och ett antal systemregister för SoC. Innehåll reg_info beror på kameramodell, och om det inte är korrekt kommer kameran inte ens att kunna ladda uboot, utan kommer att frysa i ett mycket tidigt skede av laddning.

Till en början, när vi arbetade utan leverantörsstöd, kopierade vi helt enkelt detta block från den ursprungliga kamerans firmware.

Linux-kärna och rootfs

Kamerorna använder Linux-kärnan, som är en del av chipets SDK, vanligtvis är dessa inte de senaste kärnorna från 3.x-grenen, så vi måste ofta hantera det faktum att drivrutiner för ytterligare utrustning inte är kompatibla med kärnan som används , och vi måste backporta dem till kärnkamerorna.

En annan fråga är storleken på kärnan. När FLASH-storleken bara är 8MB, räknas varje byte och vår uppgift är att försiktigt inaktivera alla oanvända kärnfunktioner för att minska storleken till ett minimum.

Rootfs är ett grundläggande filsystem. Det inkluderar busybox, wifi-moduldrivrutiner, en uppsättning standardsystembibliotek, som t.ex libld и libc, samt vår programvara, som ansvarar för LED-kontrolllogiken, nätverksanslutningshantering och firmwareuppdateringar.

Rotfilsystemet är kopplat till kärnan som initramfs och som ett resultat av bygget får vi en fil uImage, som innehåller både kärnan och rootfs.

Videoapplikation

Den mest komplexa och resurskrävande delen av firmware är applikationen, som tillhandahåller video-ljudfångst, videokodning, konfigurerar bildparametrar, implementerar videoanalyser, till exempel rörelse- eller ljuddetektorer, styr PTZ och ansvarar för växlingsdag och nattlägen.

En viktig, jag skulle till och med säga nyckelfunktion är hur videoapplikationen interagerar med molnplugin.

I traditionella lösningar 'leverantörsfirmware + molnplugin', som inte kan fungera på billig hårdvara, överförs video inuti kameran via RTSP-protokollet - och detta är en enorm overhead: kopiering och överföring av data via socket, onödiga syscalls.

Här använder vi den delade minnesmekanismen - videon kopieras inte eller skickas via socket mellan kamerans mjukvarukomponenter, och använder därigenom optimalt och noggrant kamerans blygsamma hårdvarukapacitet.

Uppdatera delsystem

En speciell stolthet är det feltoleranta delsystemet för uppdateringar av firmware online.

Låt mig förklara problemet. Att uppdatera firmware är tekniskt sett inte en atomär operation, och om ett strömavbrott inträffar mitt under uppdateringen kommer flashminnet att innehålla en del av den "underskrivna" nya firmwaren. Om du inte vidtar särskilda åtgärder blir kameran en "kloss" som måste föras till ett servicecenter.

Vi har också tagit itu med detta problem. Även om kameran stängs av under uppdateringen kommer den automatiskt och utan användaringripande att ladda ner den fasta programvaran från molnet och återställa driften.

Låt oss titta på tekniken mer i detalj:

Den mest sårbara punkten är att skriva över partitionen med Linux-kärnan och rotfilsystemet. Om en av dessa komponenter är skadad kommer kameran inte att starta upp alls utöver uboot-starthanteraren, som inte kan ladda ner firmware från molnet.

Detta innebär att vi måste se till att kameran har en fungerande kärna och rootfs när som helst under uppdateringsprocessen. Det verkar som om den enklaste lösningen skulle vara att ständigt lagra två kopior av kärnan med rootfs på flashminnet och, om huvudkärnan är skadad, ladda den från säkerhetskopian.

En bra lösning - kärnan med rootfs tar dock upp cirka 3.5 MB och för en permanent säkerhetskopiering behöver du allokera 3.5 MB. De billigaste kamerorna har helt enkelt inte så mycket ledigt utrymme för en backupkärna.

Därför använder vi applikationspartitionen för att säkerhetskopiera kärnan under en firmwareuppdatering.
Och för att välja önskad partition med kärnan används två kommandon bootm i uboot - i början försöker vi ladda huvudkärnan och om den är skadad, då backupen.

Detta säkerställer att kameran vid varje given tidpunkt kommer att ha rätt kärna med rootfs, och den kommer att kunna starta och återställa firmware.

CI/CD-system för att bygga och distribuera firmware

För att bygga firmware använder vi gitlab CI, som automatiskt bygger firmware för alla kameramodeller som stöds, och efter att den fasta programvaran har byggts distribueras den automatiskt till kamerans mjukvaruuppdateringstjänst.

Från tjänsten levereras firmwareuppdateringar till våra QA-testkameror och efter att alla teststeg är klara, till användarnas kameror.

Informationssäkerhet

Det är ingen hemlighet att informationssäkerhet nuförtiden är den viktigaste aspekten av alla IoT-enheter, inklusive kameror. Botnät som Mirai strövar runt på Internet och infekterar miljontals kameror med standardfirmware från leverantörer. Med all respekt för kameraleverantörer kan jag inte låta bli att notera att standardfirmware innehåller mycket funktionalitet som inte behövs för att arbeta med molnet, men innehåller många sårbarheter som botnät drar nytta av.

Därför är all oanvänd funktionalitet i vår firmware inaktiverad, alla tcp/udp-portar stängs och vid uppdatering av firmware kontrolleras programvarans digitala signatur.

Och förutom detta genomgår firmwaren regelbundet testning i informationssäkerhetslaboratoriet.

Slutsats

Nu används vår firmware aktivt i videoövervakningsprojekt. Den kanske största av dem är sändningen av omröstning på dagen för valet av Ryska federationens president.
Projektet involverade mer än 70 tusen kameror med vår firmware, som installerades vid vallokaler i vårt land.

Efter att ha löst ett antal komplexa, och på vissa ställen, även på den tiden nästan omöjliga problem, fick vi naturligtvis stor tillfredsställelse som ingenjörer, men förutom detta sparade vi också miljontals dollar på inköp av kameror. Och i det här fallet är besparingar inte bara ord och teoretiska beräkningar, utan resultatet av ett redan avslutat anbud för inköp av utrustning. Följaktligen, om vi talar om molnvideoövervakning: det finns två tillvägagångssätt - förlita dig strategiskt på expertis och utveckling på låg nivå, vilket resulterar i enorma besparingar på utrustning, eller använd dyr utrustning, vilket, om du tittar specifikt på konsumentegenskaper, praktiskt taget inte är skiljer sig från liknande billiga.

Varför är det strategiskt viktigt att besluta om valet av integrationssätt så tidigt som möjligt? När utvecklare utvecklar ett plugin förlitar sig de på vissa teknologier (bibliotek, protokoll, standarder). Och om en uppsättning tekniker endast väljs för dyr utrustning, kommer ett försök att byta till billiga kameror i framtiden med största sannolikhet, åtminstone, ta vansinnigt lång tid eller till och med misslyckas och en återgång till dyr utrustning kommer att inträffa.

Källa: will.com