Hej alle!

Det er nok ingen hemmelighed, at cloud-videoovervågningstjenester er blevet mere og mere populære på det seneste. Og det er tydeligt, hvorfor dette sker: video er "tungt" indhold, hvis lagring kræver infrastruktur og store mængder diskplads. Brug af et lokalt videoovervågningssystem kræver midler til drift og support, både i tilfælde af en organisation, der bruger hundredvis af overvågningskameraer, og i tilfælde af en individuel bruger med flere kameraer.

Cloudbaserede videoovervågningssystemer løser dette problem ved at give kunderne adgang til en eksisterende infrastruktur til lagring og behandling af video. En cloud-videoovervågningsklient skal blot forbinde kameraet til internettet og linke det til sin cloud-konto.

Der findes adskillige teknologiske metoder til at forbinde kameraer til skyen. Den mest bekvemme og omkostningseffektive metode er uden tvivl, at kameraet opretter direkte forbindelse til og arbejder med skyen, uden behov for yderligere udstyr som f.eks. server eller registrator.

For at gøre dette skal kameraet have et softwaremodul installeret, der fungerer med skyen. Men hvis vi taler om billige kameraer, har de meget begrænsede hardwareressourcer, som næsten 100% er optaget af kameraleverandørens native firmware, og der kræves ingen ressourcer til cloud-plugin'et. Udviklerne fra ivideon har dedikeret meget arbejde til dette problem. en artikel, hvilket forklarer hvorfor de ikke kan installere plugin'et på billige kameraer. Som følge heraf er minimumsprisen for kameraet 5000 rubler ($80 dollars), og millioner af penge er brugt på udstyr.

Vi har løst dette problem med succes. Hvis du er interesseret i hvordan, er du velkommen under snittet

Lidt historie

I 2016 begyndte vi at udvikle en cloud-baseret videoovervågningsplatform til Rostelecom.

Med hensyn til kamerasoftware valgte vi i første fase den "standard" løsning til sådanne opgaver: Vi udviklede vores eget plugin, som er installeret i leverandørens standard kamerafirmware og fungerer med vores cloud. Det er dog værd at bemærke, at vi under designet brugte de letteste og mest effektive løsninger (for eksempel en almindelig C-implementering af protobuf, libev, mbedtls og helt opgivne praktiske, men tunge biblioteker som boost)

I øjeblikket findes der ingen universelle integrationsløsninger på markedet for IP-kameraer: hver leverandør har sin egen metode til at installere et plugin, sit eget sæt API'er til firmwaredrift og en unik opdateringsmekanisme.

Det betyder, at et stort lag af integrationssoftware skal udvikles individuelt for hver kameraleverandør. Og i starten af ​​udviklingen er det tilrådeligt kun at arbejde med én leverandør for at fokusere teamets indsats på at udvikle logikken bag at arbejde med skyen.

Den første valgte leverandør var Hikvision, en af ​​verdens førende på kameramarkedet, der tilbyder en veldokumenteret API og kompetent teknisk support.

Vi lancerede vores første pilotprojekt, cloud-videoovervågning Videocomfort, ved hjælp af Hikvision-kameraer.

Næsten umiddelbart efter lanceringen begyndte vores brugere at stille spørgsmål om muligheden for at forbinde billigere kameraer fra andre producenter til tjenesten.

Jeg afviste næsten øjeblikkeligt muligheden for at implementere et integrationslag for hver leverandør - da det var dårligt skalerbart og stillede alvorlige tekniske krav til kamerahardwaren. Prisen for et kamera, der opfylder disse adgangskrav: ~60-70$

Derfor besluttede jeg at grave dybere - at lave min egen firmware til kameraer fra enhver leverandør. Denne tilgang reducerer kravene til kameraets hardwareressourcer betydeligt - fordi cloud-laget er meget mere effektivt integreret med videoapplikationen, og firmwaren ikke har noget ekstra ubrugt fedt.

Og det vigtige er, at når man arbejder med kameraet på et lavt niveau, er det muligt at bruge hardware-AES, som krypterer data uden at skabe en ekstra belastning på den strømbesparende CPU.

I det øjeblik havde vi slet ingenting. Slet ingenting.

Næsten alle leverandører var ikke klar til at samarbejde med os på et så lavt niveau. Der er ingen information om kredsløb og komponenter, ingen officiel SDK til chipsættene eller dokumentation til sensorerne.
Der er heller ingen teknisk support.

Svar på alle spørgsmål skulle findes gennem reverse engineering - trial and error. Men vi klarede det.

De første kameramodeller, vi lærte vores lektie om, var Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link og adskillige super billige, ukendte kinesiske kameraer.

Teknik

Kameraer på Hisilicon 3518E chipsæt. Kameraernes hardwarespecifikationer er som følger:

Xiaomi Yi myrer
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
—

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
—
+

MicroSD
+
+

Mikrofon
+
+

Højttaler
+
+

I virkeligheden
+
+

IRCut
+
+

Vi startede med dem.

Vi understøtter i øjeblikket Hisilicon 3516/3518 chipsæt samt Ambarella S2L/S2LM. Der findes snesevis af kameramodeller.

Firmware-komposition

undervandsbåd

uboot er bootloaderen, den starter først efter opstart, initialiserer hardwaren og indlæser Linux-kernen.

Kameraindlæsningsskriptet er ret trivielt:

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 af funktionerne er, at den kaldes to gange. bootm, mere om dette lidt senere, når vi kommer til opdateringsundersystemet.

Vær opmærksom på linjen mem=38MJa, ja, det er ikke en tastefejl - kernen Linux og alle-alle-alle applikationer har kun adgang til 38 megabyte RAM.

Ved siden af ​​uboot er der også en særlig blok kaldet reg_info, som indeholder et lavniveau-script til initialisering af DDR og et antal SoC-systemregistre. Tilfreds reg_info afhænger af kameramodellen, og hvis det ikke er korrekt, vil kameraet ikke engang kunne indlæse uboot, men vil fryse i den tidligste fase af indlæsningen.

I starten, da vi arbejdede uden leverandørsupport, kopierede vi blot denne blok fra den originale kamerafirmware.

Linux-kerne og rootfs

Kameraerne bruger en kerne Linux, som er en del af chip-SDK'et, er normalt ikke de nyeste kerner fra 3.x-grenen, så vi støder ofte på den situation, at driverne til ekstraudstyr ikke er kompatible med den anvendte kerne, og vi er nødt til at backporte dem til kamerakernen.

Et andet problem er kernens størrelse. Når FLASH-størrelsen kun er 8 MB, tæller hver byte, og vores opgave er omhyggeligt at deaktivere alle ubrugte kernefunktioner for at reducere størrelsen til et minimum.

Rootfs er et basisfilsystem. Det omfatter busybox, wifi-moduldrivere, et sæt standard systembiblioteker, såsom libld и libc, samt software af vores eget design, der er ansvarlig for LED-styringslogik, styring af netværksforbindelser og firmwareopdateringer.

Rodfilsystemet er forbundet til kernen som initramfs, og som et resultat af buildet får vi én fil. uImage, som indeholder både kernen og rootfs.

Videoapplikation

Den mest komplekse og ressourcekrævende del af firmwaren er den applikation, der leverer video- og lydoptagelse, videokodning, konfigurerer billedparametre, implementerer videoanalyse, såsom bevægelses- eller lyddetektorer, styrer PTZ og er ansvarlig for at skifte mellem dag- og nattilstande.

En vigtig, jeg vil endda sige nøglefunktion, er, hvordan videoapplikationen interagerer med cloud-pluginnet.

I traditionelle løsninger med 'leverandørfirmware + cloud-plugin', som ikke kan fungere på billig hardware, transmitteres video inde i kameraet via RTSP-protokollen - og det er en enorm omkostning: kopiering og transmission af data via socket, ekstra syscalls.

Her bruger vi den delte hukommelsesmekanisme - videoen kopieres eller sendes ikke via socket mellem kameraets softwarekomponenter, hvorved kameraets beskedne hardwarefunktioner udnyttes optimalt og omhyggeligt.

Opdater delsystem

En særlig kilde til stolthed er det fejltolerante online firmwareopdateringssystem.

Lad mig forklare problemet. Opdatering af firmwaren er teknisk set ikke en atomar operation, og hvis der opstår strømsvigt midt i opdateringen, vil flashhukommelsen indeholde en del af den "uskrevede" nye firmware. Hvis du ikke tager særlige forholdsregler, bliver kameraet til en "mursten", der skal tages til et servicecenter.

Vi håndterede også dette problem. Selv hvis kameraet er slukket under opdateringen, vil det automatisk og uden brugerindgriben downloade firmwaren fra skyen og genoprette driften.

Lad os se nærmere på teknikken:

Det mest sårbare øjeblik er at overskrive kernepartitionen Linux og rodfilsystemet. Hvis en af ​​disse komponenter er beskadiget, vil kameraet ikke starte efter Ubuntu bootloader, som ikke kan downloade firmware fra skyen.

Det betyder, at vi skal sikre os, at kameraet har en fungerende kerne og rootfs på ethvert tidspunkt under opdateringsprocessen. Det ser ud til, at den enkleste løsning ville være konstant at gemme to kopier af kernen med rootfs på flashhukommelsen og, i tilfælde af skade på hovedkernen, indlæse den fra sikkerhedskopien.

En god løsning - dog fylder kernen med rootfs omkring 3.5 MB, og til en permanent backup skal du allokere 3.5 MB. De billigste kameraer har simpelthen ikke nok ledig plads til en core-backup.

Derfor bruger vi applikationspartitionen til kernelbackup under firmwareopdatering.
Og for at vælge den nødvendige partition med kernen bruges to kommandoer bootm i uboot - først forsøger vi at indlæse hovedkernen, og hvis den er beskadiget, derefter backup-kernen.

Dette sikrer, at kameraet til enhver tid har en korrekt kerne med rootfs og vil være i stand til at starte og gendanne firmwaren.

CI/CD-system til opbygning og implementering af firmware

Til at bygge firmware bruger vi gitlab CI, som automatisk bygger firmware til alle understøttede kameramodeller, hvorefter firmwaren automatisk implementeres i kameraets softwareopdateringstjeneste.

Fra softwareopdateringstjenesten leveres firmware til vores QA-testkameraer, og når alle testfaser er afsluttet, til brugernes kameraer.

Informationssikkerhed

Det er ingen hemmelighed, at informationssikkerhed i vores tid er det vigtigste aspekt af enhver IoT-enhed, inklusive et kamera. Der cirkulerer botnets som Mirai på internettet og inficerer millioner af kameraer med standardfirmware fra leverandører. Med al respekt for kameraleverandører, kan jeg ikke lade være med at bemærke, at standardfirmwaren indeholder en masse funktionalitet, der ikke er efterspurgt til at arbejde med skyen, men indeholder mange sårbarheder, der bruges af botnets.

Derfor er al ubrugt funktionalitet i vores firmware deaktiveret, alle tcp/udp-porte er lukkede, og når firmwaren opdateres, kontrolleres softwarens digitale signatur.

Derudover gennemgår firmwaren regelmæssig test i informationssikkerhedslaboratoriet.

Konklusion

Nu bruges vores firmware aktivt i videoovervågningsprojekter. Måske den mest omfattende af dem er udsendelsen af ​​​​afstemningen på dagen for valget af præsidenten for Den Russiske Føderation.
Projektet involverede mere end 70 tusind kameraer med vores firmware, som blev installeret på valgsteder i vores land.

Efter at have løst en række komplekse, og på nogle steder endda på det tidspunkt praktisk talt umulige, problemer, fik vi naturligvis stor tilfredsstillelse som ingeniører, men derudover sparede vi også millioner af dollars på køb af kameraer. Og i dette tilfælde er besparelser ikke blot ord og teoretiske beregninger, men resultaterne af et allerede gennemført udbud af udstyr. Hvis vi derfor taler om cloud-videoovervågning, er der to tilgange - at strategisk stole på lavniveau-ekspertise og udvikling, hvilket resulterer i enorme besparelser på udstyr, eller at bruge dyrt udstyr, som, hvis man ser på forbrugernes karakteristika, praktisk talt ikke adskiller sig fra lignende billigt udstyr.

Hvorfor er det strategisk vigtigt at træffe en beslutning om valg af tilgang til integrationsmetoden så tidligt som muligt? Når udviklere udvikler et plugin, bruger de bestemte teknologier (biblioteker, protokoller, standarder). Og hvis et sæt teknologier kun vælges til dyrt udstyr, vil et forsøg på at skifte til billige kameraer i fremtiden højst sandsynligt i det mindste tage vanvittigt lang tid eller endda mislykkes, og der vil være en tilbagevenden til dyrt udstyr.

Kilde: www.habr.com