Hei!

Det er sannsynligvis ingen hemmelighet at skyvideoovervåkingstjenester har blitt populært i det siste. Og det er klart hvorfor dette skjer, video er "tungt" innhold, hvis lagring krever infrastruktur og store mengder disklagring. Bruk av et lokalt videoovervåkingssystem krever midler til drift og støtte, både for en organisasjon som bruker hundrevis av overvåkingskameraer og for en individuell bruker med flere kameraer.

Cloud videoovervåkingssystemer løser dette problemet ved å gi kundene en eksisterende videolagrings- og prosesseringsinfrastruktur. En skyvideoovervåkingsklient trenger ganske enkelt å koble kameraet til Internett og koble det til skykontoen sin.

Det er flere teknologiske måter å koble kameraer til skyen på. Den mest praktiske og billigste metoden er utvilsomt at kameraet kobles direkte til og fungerer med skyen, uten deltagelse av tilleggsutstyr som server eller opptaker.

For å gjøre dette er det nødvendig at en programvaremodul som fungerer med skyen er installert på kameraet. Men hvis vi snakker om billige kameraer, så har de svært begrensede maskinvareressurser, som er nesten 100% okkupert av den opprinnelige firmwaren til kameraleverandøren, og det er ingen ressurser som er nødvendige for skypluginen. Utviklere fra ivideon viet dette problemet artikkel, som forklarer hvorfor de ikke kan installere plugin på billige kameraer. Som et resultat er minimumsprisen på kameraet 5000 rubler ($80 dollar) og millioner av penger brukt på utstyr.

Vi har løst dette problemet. Hvis du er interessert i hvordan - velkommen til kuttet

En bit av historien

I 2016 begynte vi å utvikle en skyvideoovervåkingsplattform for Rostelecom.

Når det gjelder kameraprogramvare, fulgte vi i det første trinnet "standard" banen for slike oppgaver: vi utviklet vår egen plugin, som er installert i standard fastvaren til leverandørens kamera og fungerer med skyen vår. Det er imidlertid verdt å merke seg at under utformingen brukte vi de mest lette og effektive løsningene (for eksempel vanlig C-implementering av protobuf, libev, mbedtls og fullstendig forlatte praktiske, men tunge biblioteker som boost)

For øyeblikket er det ingen universelle integrasjonsløsninger på IP-kameramarkedet: hver leverandør har sin egen måte å installere plugin på, sitt eget sett med APIer for drift av fastvaren og en unik oppdateringsmekanisme.

Dette betyr at for hver kameraleverandør er det nødvendig å individuelt utvikle et omfattende lag med integreringsprogramvare. Og når utviklingen startes, er det tilrådelig å kun jobbe med én leverandør for å konsentrere teamets innsats om å utvikle logikken for å jobbe med skyen.

Den første leverandøren som ble valgt var Hikvision, en av verdenslederne på kameramarkedet, og ga et godt dokumentert API og kompetent teknisk teknisk støtte.

Vi lanserte vårt første pilotprosjekt, skyvideoovervåking Video Comfort, med Hikvision-kameraer.

Nesten umiddelbart etter lanseringen begynte våre brukere å stille spørsmål om muligheten for å koble billigere kameraer fra andre produsenter til tjenesten.

Jeg avviste muligheten for å implementere et integreringslag for hver leverandør nesten umiddelbart - siden det er dårlig skalerbart og stiller alvorlige tekniske krav til kameraets maskinvare. Kostnaden for et kamera som oppfyller disse inngangskravene: ~60-70$

Derfor bestemte jeg meg for å grave dypere - å lage min egen firmware for kameraer fra hvilken som helst leverandør. Denne tilnærmingen reduserer kravene til kameraets maskinvareressurser betydelig - fordi Laget for å jobbe med skyen er mye mer effektivt integrert med videoapplikasjonen, og det er ikke noe unødvendig ubrukt fett i fastvaren.

Og det som er viktig er at når du arbeider med kameraet på et lavt nivå, er det mulig å bruke maskinvare AES, som krypterer data uten å skape ekstra belastning på laveffekts-CPU.

I det øyeblikket hadde vi ingenting i det hele tatt. Ingenting i det hele tatt.

Nesten alle leverandører var ikke klare til å jobbe med oss ​​på et så lavt nivå. Det er ingen informasjon om kretsene og komponentene, det er ingen offisiell SDK for brikkesett og sensordokumentasjon.
Det er heller ingen teknisk støtte.

Alle spørsmål måtte besvares gjennom reverse engineering – prøving og feiling. Men vi klarte det.

De første kameramodellene vi testet på var Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link-kameraer og flere ultrabillige navnløse kinesiske kameraer.

Teknikk

Kameraer basert på Hisilicon 3518E brikkesett. Maskinvareegenskapene til kameraene er som følger:

Xiaomi Yi-maur
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Høyttaler
+
+

IRLed
+
+

IRCut
+
+

Vi begynte med dem.

Vi støtter for tiden Hisilicon 3516/3518 brikkesett, samt Ambarella S2L/S2LM. Det finnes dusinvis av kameramodeller.

Fastvaresammensetning

uboot

uboot er oppstartslasteren, den starter opp først etter at den er slått på, initialiserer maskinvaren og laster linux-kjernen.

Kamerainnlastingsskriptet er ganske 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 av funksjonene er at den kalles to ganger bootm, mer om dette litt senere, når vi kommer til oppdateringsundersystemet.

Vær oppmerksom på linjen mem=38M. Ja, ja, dette er ikke en skrivefeil - Linux-kjernen og alt, alle, alle applikasjoner har tilgang til kun 38 megabyte RAM.

Også ved siden av uboot er det en spesiell blokk kalt reg_info, som inneholder et lavnivåskript for initialisering av DDR og en rekke systemregistre for SoC. Innhold reg_info avhenger av kameramodellen, og hvis det ikke er riktig, vil kameraet ikke engang kunne laste uboot, men vil fryse på et veldig tidlig stadium av lasting.

Til å begynne med, da vi jobbet uten leverandørstøtte, kopierte vi ganske enkelt denne blokken fra den originale kamerafastvaren.

Linux-kjerne og rootfs

Kameraene bruker Linux-kjernen, som er en del av brikkens SDK; vanligvis er dette ikke de nyeste kjernene fra 3.x-grenen, så vi må ofte forholde oss til det faktum at drivere for tilleggsutstyr ikke er kompatible med kjernen som brukes , og vi må tilbakeportere dem til kjernekameraene.

Et annet problem er størrelsen på kjernen. Når FLASH-størrelsen bare er 8MB, teller hver byte og vår oppgave er å nøye deaktivere alle ubrukte kjernefunksjoner for å redusere størrelsen til et minimum.

Rootfs er et grunnleggende filsystem. Det inkluderer busybox, wifi-moduldrivere, et sett med standard systembiblioteker, som f.eks libld и libc, samt programvaren vår, som er ansvarlig for LED-kontrolllogikken, nettverkstilkoblingsadministrasjon og fastvareoppdateringer.

Rotfilsystemet er koblet til kjernen som initramfs og som et resultat av byggingen får vi én fil uImage, som inneholder både kjernen og rootfs.

Videoapplikasjon

Den mest komplekse og ressurskrevende delen av fastvaren er applikasjonen, som gir video-lydfangst, videokoding, konfigurerer bildeparametere, implementerer videoanalyse, for eksempel bevegelses- eller lyddetektorer, kontrollerer PTZ og er ansvarlig for byttedag og nattmoduser.

En viktig, jeg vil til og med si nøkkelfunksjon, er hvordan videoapplikasjonen samhandler med skypluginen.

I tradisjonelle løsninger 'leverandørfastvare + skyplugin', som ikke kan fungere på billig maskinvare, overføres video inne i kameraet via RTSP-protokollen - og dette er en enorm overhead: kopiering og overføring av data via socket, unødvendige syscalls.

Her bruker vi mekanismen for delt minne - videoen kopieres eller sendes ikke via socket mellom kameraets programvarekomponenter, og bruker dermed de beskjedne maskinvarekapasitetene til kameraet optimalt og forsiktig.

Oppdater delsystemet

Et punkt med spesiell stolthet er det feiltolerante undersystemet for online fastvareoppdateringer.

La meg forklare problemet. Oppdatering av fastvaren er teknisk sett ikke en atomoperasjon, og hvis det oppstår et strømbrudd midt i oppdateringen, vil flashminnet inneholde en del av den "underskrevne" nye fastvaren. Hvis du ikke tar spesielle tiltak, vil kameraet bli en "kloss" som må tas med til et servicesenter.

Vi har også håndtert dette problemet. Selv om kameraet er slått av under oppdateringen, vil det automatisk og uten brukerintervensjon laste ned fastvaren fra skyen og gjenopprette driften.

La oss se på teknikken mer detaljert:

Det mest sårbare punktet er å overskrive partisjonen med Linux-kjernen og rotfilsystemet. Hvis en av disse komponentene er skadet, vil ikke kameraet starte opp i det hele tatt utover uboot bootloader, som ikke kan laste ned fastvare fra skyen.

Dette betyr at vi må sørge for at kameraet har en fungerende kjerne og rootfs når som helst under oppdateringsprosessen. Det ser ut til at den enkleste løsningen ville være å hele tiden lagre to kopier av kjernen med rootfs på flash-minne og, hvis hovedkjernen er skadet, laste den fra sikkerhetskopien.

En god løsning - kjernen med rootfs tar imidlertid opp ca 3.5 MB og for en permanent sikkerhetskopi må du allokere 3.5 MB. De billigste kameraene har rett og slett ikke så mye ledig plass for en sikkerhetskopikjerne.

Derfor, for å sikkerhetskopiere kjernen under en fastvareoppdatering, bruker vi applikasjonspartisjonen.
Og for å velge ønsket partisjon med kjernen, brukes to kommandoer bootm i uboot - i begynnelsen prøver vi å laste inn hovedkjernen, og hvis den er skadet, deretter sikkerhetskopien.

Dette sikrer at kameraet til enhver tid vil ha riktig kjerne med rootfs, og det vil kunne starte opp og gjenopprette fastvaren.

CI/CD-system for å bygge og distribuere fastvare

For å bygge fastvare bruker vi gitlab CI, som automatisk bygger fastvare for alle støttede kameramodeller, og etter å ha bygget fastvaren, distribueres den automatisk til kameraets programvareoppdateringstjeneste.

Fra tjenesten leveres fastvareoppdateringer til våre QA-testkameraer, og etter fullføring av alle teststadier, til brukernes kameraer.

Informasjonssikkerhet

Det er ingen hemmelighet at informasjonssikkerhet i dag er det viktigste aspektet ved enhver IoT-enhet, inkludert kameraer. Botnett som Mirai streifer rundt på Internett og infiserer millioner av kameraer med standard fastvare fra leverandører. Med all respekt for kameraleverandører kan jeg ikke la være å merke meg at standard fastvare inneholder mye funksjonalitet som ikke er nødvendig for å jobbe med skyen, men inneholder mange sårbarheter som botnett utnytter.

Derfor er all ubrukt funksjonalitet i fastvaren vår deaktivert, alle tcp/udp-porter lukkes, og ved oppdatering av fastvaren kontrolleres den digitale signaturen til programvaren.

Og i tillegg gjennomgår fastvaren regelmessig testing i informasjonssikkerhetslaboratoriet.

Konklusjon

Nå brukes fastvaren vår aktivt i videoovervåkingsprosjekter. Kanskje den største av dem er sendingen av stemmegivning på dagen for valget av presidenten i Den russiske føderasjonen.
Prosjektet involverte mer enn 70 tusen kameraer med fastvaren vår, som ble installert på valglokalene i vårt land.

Etter å ha løst en rekke komplekse, og noen steder, selv på den tiden nesten umulige problemer, fikk vi selvfølgelig stor tilfredshet som ingeniører, men i tillegg sparte vi også millioner av dollar på kjøp av kameraer. Og i dette tilfellet er besparelser ikke bare ord og teoretiske beregninger, men resultatene av et allerede gjennomført anbud for kjøp av utstyr. Følgelig, hvis vi snakker om skyvideoovervåking: det er to tilnærminger - strategisk stole på ekspertise og utvikling på lavt nivå, noe som resulterer i enorme besparelser på utstyr, eller bruk dyrt utstyr, som, hvis du ser spesifikt på forbrukeregenskaper, praktisk talt ikke er forskjellig fra lignende billige.

Hvorfor er det strategisk viktig å ta stilling til valg av integreringstilnærming så tidlig som mulig? Når utviklere utvikler en plugin, er de avhengige av visse teknologier (biblioteker, protokoller, standarder). Og hvis et sett med teknologier bare velges for dyrt utstyr, vil et forsøk på å bytte til billige kameraer i fremtiden mest sannsynlig, i det minste, ta vanvittig lang tid eller til og med mislykkes, og en retur til dyrt utstyr vil skje.

Kilde: www.habr.com