Hola a tots!

Probablement no és cap secret que els serveis de videovigilància al núvol han guanyat popularitat recentment. I és clar per què passa això, el vídeo és contingut "pesat", l'emmagatzematge del qual requereix infraestructura i grans quantitats d'emmagatzematge en disc. L'ús d'un sistema de videovigilància local requereix fons per funcionar i donar suport, tant per a una organització que utilitza centenars de càmeres de vigilància com per a un usuari individual amb diverses càmeres.

Els sistemes de videovigilància al núvol resolen aquest problema proporcionant als clients una infraestructura d'emmagatzematge i processament de vídeo existent. Un client de videovigilància al núvol només ha de connectar la càmera a Internet i enllaçar-la al seu compte al núvol.

Hi ha diverses maneres tecnològiques de connectar càmeres al núvol. Sens dubte, el mètode més còmode i econòmic és que la càmera es connecti directament i funcioni amb el núvol, sense la participació d'equips addicionals com un servidor o una gravadora.

Per fer-ho, cal instal·lar a la càmera un mòdul de programari que funcioni amb el núvol. Tanmateix, si parlem de càmeres barates, aleshores tenen recursos de maquinari molt limitats, que estan gairebé al 100% ocupats pel microprogramari natiu del proveïdor de càmeres, i no hi ha recursos necessaris per al connector al núvol. Els desenvolupadors d'ivideon van dedicar aquest problema un article, que explica per què no poden instal·lar el connector a càmeres barates. Com a resultat, el preu mínim de la càmera és de 5000 rubles (80 dòlars) i milions de diners gastats en equips.

Hem resolt aquest problema amb èxit. Si estàs interessat en com, benvingut al tall

Una mica d'història

El 2016, vam començar a desenvolupar una plataforma de videovigilància al núvol per a Rostelecom.

Pel que fa al programari de la càmera, en la primera etapa vam seguir el camí "estàndard" per a aquestes tasques: vam desenvolupar el nostre propi connector, que s'instal·la al firmware estàndard de la càmera del proveïdor i funciona amb el nostre núvol. No obstant això, val la pena assenyalar que durant el disseny hem utilitzat les solucions més lleugeres i eficients (per exemple, implementació C simple de protobuf, libev, mbedtls i biblioteques còmodes però pesades completament abandonades com Boost)

Actualment, no hi ha solucions d'integració universals al mercat de càmeres IP: cada venedor té la seva pròpia manera d'instal·lar el connector, el seu propi conjunt d'API per operar el microprogramari i un mecanisme d'actualització únic.

Això vol dir que per a cada proveïdor de càmeres és necessari desenvolupar individualment una capa completa de programari d'integració. I en el moment d'iniciar el desenvolupament, s'aconsella treballar només amb 1 proveïdor per tal de concentrar els esforços de l'equip a desenvolupar la lògica per treballar amb el núvol.

El primer venedor escollit va ser Hikvision, un dels líders mundials en el mercat de càmeres, que proporciona una API ben documentada i un suport tècnic d'enginyeria competent.

Vam llançar el nostre primer projecte pilot, Videovigilància al núvol Video Comfort, amb càmeres Hikvision.

Gairebé immediatament després del llançament, els nostres usuaris van començar a fer preguntes sobre la possibilitat de connectar al servei càmeres més barates d'altres fabricants.

Vaig rebutjar l'opció d'implementar una capa d'integració per a cada proveïdor gairebé immediatament, ja que és poc escalable i imposa seriosos requisits tècnics al maquinari de la càmera. El cost d'una càmera que compleixi aquests requisits d'entrada: ~60-70$

Per tant, vaig decidir aprofundir: crear el meu propi firmware per a càmeres de qualsevol proveïdor. Aquest enfocament redueix significativament els requisits dels recursos de maquinari de la càmera, perquè La capa per treballar amb el núvol s'integra de manera molt més eficaç amb l'aplicació de vídeo i no hi ha cap greix inutilitzat innecessari al microprogramari.

I el que és important és que quan es treballa amb la càmera a un nivell baix, és possible utilitzar el maquinari AES, que xifra les dades sense crear càrrega addicional a la CPU de baix consum.

En aquell moment no teníem res de res. Res en absolut.

Gairebé tots els venedors no estaven preparats per treballar amb nosaltres a un nivell tan baix. No hi ha informació sobre els circuits i components, no hi ha cap SDK oficial de chipsets i documentació del sensor.
Tampoc hi ha suport tècnic.

Totes les preguntes s'havien de respondre mitjançant enginyeria inversa: assaig i error. Però ho vam aconseguir.

Els primers models de càmeres que vam provar van ser Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, càmeres D-Link i diverses càmeres xineses sense nom ultra econòmiques.

Tècnica

Càmeres basades en el chipset Hisilicon 3518E. Les característiques del maquinari de les càmeres són les següents:

Les formigues Xiaomi Yi
Sense nom

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

Wi-Fi
mt7601/bcm43143
-

sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Micròfon
+
+

Altaveu
+
+

IRLed
+
+

IRCut
+
+

Vam començar amb ells.

Actualment admetem els chipsets Hisilicon 3516/3518, així com Ambarella S2L/S2LM. Hi ha desenes de models de càmera.

Composició del firmware

uboot

uboot és el carregador d'arrencada, s'engega primer després de l'encesa, inicialitza el maquinari i carrega el nucli de Linux.

L'script de càrrega de la càmera és bastant trivial:

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

Una de les característiques és que es diu dues vegades bootm, més sobre això una mica més tard, quan arribem al subsistema d'actualització.

Pareu atenció a la línia mem=38M. Sí, sí, això no és una errada d'ortografia: el nucli de Linux i totes, totes, totes les aplicacions tenen accés només a 38 megabytes de RAM.

També al costat d'uboot hi ha un bloc especial anomenat reg_info, que conté un script de baix nivell per inicialitzar DDR i una sèrie de registres del sistema del SoC. Contingut reg_info depèn del model de càmera i, si no és correcta, la càmera ni tan sols podrà carregar uboot, però es congelarà en la fase inicial de la càrrega.

Al principi, quan treballàvem sense suport del venedor, simplement vam copiar aquest bloc del microprogramari original de la càmera.

Nucli de Linux i rootfs

Les càmeres utilitzen el nucli Linux, que forma part de l'SDK del xip; normalment aquests no són els darrers nuclis de la branca 3.x, de manera que sovint hem de tractar amb el fet que els controladors per a equips addicionals no són compatibles amb el nucli utilitzat. , i hem de retroportar-los a les càmeres del nucli.

Un altre problema és la mida del nucli. Quan la mida FLASH només és de 8 MB, llavors cada byte compta i la nostra tasca és desactivar amb cura totes les funcions del nucli no utilitzades per reduir la mida al mínim.

Rootfs és un sistema de fitxers bàsic. Inclou busybox, controladors de mòduls wifi, un conjunt de biblioteques de sistema estàndard, com ara libld и libc, així com el nostre programari, responsable de la lògica de control de LED, la gestió de la connexió de xarxa i les actualitzacions de firmware.

El sistema de fitxers arrel està connectat al nucli com a initramfs i com a resultat de la compilació obtenim un fitxer uImage, que conté tant el nucli com les arrels.

Aplicació de vídeo

La part més complexa i intensiva de recursos del firmware és l'aplicació, que proporciona captura de vídeo-àudio, codificació de vídeo, configura els paràmetres d'imatge, implementa l'anàlisi de vídeo, per exemple, detectors de moviment o de so, controla PTZ i s'encarrega de canviar el dia i el modes nocturns.

Una característica important, fins i tot diria clau, és com l'aplicació de vídeo interactua amb el connector del núvol.

A les solucions tradicionals 'vendor firmware + cloud connector', que no poden funcionar amb maquinari barat, el vídeo dins de la càmera es transmet mitjançant el protocol RTSP, i això és una sobrecàrrega enorme: còpia i transmissió de dades a través de socket, trucades de sistema innecessàries.

Aquí utilitzem el mecanisme de memòria compartida: el vídeo no es copia ni s'envia a través d'un sòcol entre els components del programari de la càmera, fent servir de manera òptima i acurada les capacitats de maquinari modestes de la càmera.

Actualitzar el subsistema

Un punt d'orgull especial és el subsistema tolerant a errors per a les actualitzacions de microprogramari en línia.

Deixa'm explicar el problema. L'actualització del microprogramari tècnicament no és una operació atòmica, i si es produeix una fallada d'alimentació al mig de l'actualització, la memòria flaix contindrà part del nou microprogramari "subescrit". Si no preneu mesures especials, la càmera es convertirà en un "maó" que s'ha de portar a un centre de servei.

Nosaltres també hem tractat aquest problema. Fins i tot si la càmera s'apaga durant l'actualització, automàticament i sense intervenció de l'usuari descarregarà el microprogramari del núvol i restablirà el funcionament.

Vegem la tècnica amb més detall:

El punt més vulnerable és sobreescriure la partició amb el nucli de Linux i el sistema de fitxers arrel. Si un d'aquests components està danyat, la càmera no arrencarà més enllà del carregador d'arrencada uboot, que no pot descarregar el microprogramari del núvol.

Això vol dir que hem d'assegurar-nos que la càmera tingui un nucli i rootfs que funcionin en qualsevol moment durant el procés d'actualització. Sembla que la solució més senzilla seria emmagatzemar constantment dues còpies del nucli amb rootfs a la memòria flash i, si el nucli principal està malmès, carregar-lo des de la còpia de seguretat.

Una bona solució; tanmateix, el nucli amb rootfs ocupa uns 3.5 MB i per a una còpia de seguretat permanent cal assignar 3.5 MB. Les càmeres més barates simplement no tenen tant espai lliure per a un nucli de còpia de seguretat.

Per tant, per fer una còpia de seguretat del nucli durant una actualització del microprogramari, utilitzem la partició de l'aplicació.
I per seleccionar la partició desitjada amb el nucli, s'utilitzen dues ordres bootm a uboot: al principi intentem carregar el nucli principal i, si està danyat, el de còpia de seguretat.

Això garanteix que en un moment donat la càmera tindrà el nucli correcte amb rootfs, i podrà arrencar i restaurar el microprogramari.

Sistema CI/CD per construir i desplegar firmware

Per crear el microprogramari, utilitzem gitlab CI, que crea automàticament el microprogramari per a tots els models de càmeres compatibles i, després de crear el microprogramari, s'implementa automàticament al servei d'actualització del programari de la càmera.

Des del servei, les actualitzacions de microprogramari es lliuren a les nostres càmeres de prova de control de qualitat i, un cop finalitzades totes les etapes de prova, a les càmeres dels usuaris.

Seguretat de la informació

No és cap secret que avui dia la seguretat de la informació és l'aspecte més important de qualsevol dispositiu IoT, incloses les càmeres. Botnets com Mirai estan deambulant per Internet, infectant milions de càmeres amb firmware estàndard dels venedors. Amb tot el respecte als venedors de càmeres, no puc deixar de notar que el microprogramari estàndard conté moltes funcionalitats que no són necessàries per treballar amb el núvol, però conté moltes vulnerabilitats de les quals aprofiten les botnets.

Per tant, totes les funcionalitats no utilitzades del nostre microprogramari estan desactivades, tots els ports tcp/udp estan tancats i, en actualitzar el microprogramari, es comprova la signatura digital del programari.

I a més d'això, el microprogramari es sotmet a proves regulars al laboratori de seguretat de la informació.

Conclusió

Ara el nostre firmware s'utilitza activament en projectes de videovigilància. Potser el més gran d'ells és l'emissió de la votació el dia de l'elecció del president de la Federació Russa.
El projecte va implicar més de 70 mil càmeres amb el nostre firmware, que es van instal·lar als col·legis electorals del nostre país.

Després d'haver resolt una sèrie de problemes complexos, i en alguns llocs, fins i tot en aquell moment gairebé impossibles, vam rebre, per descomptat, una gran satisfacció com a enginyers, però a més d'això, també vam estalviar milions de dòlars en la compra de càmeres. I en aquest cas, l'estalvi no són només paraules i càlculs teòrics, sinó els resultats d'una licitació ja finalitzada per a la compra d'equips. En conseqüència, si parlem de videovigilància al núvol: hi ha dos enfocaments: confiar estratègicament en l'experiència i el desenvolupament de baix nivell, que es tradueix en un gran estalvi en equips, o utilitzar equips cars, que, si ens fixem específicament en les característiques del consumidor, pràcticament no és diferents dels semblants barats.

Per què és estratègicament important decidir sobre l'elecció de l'enfocament d'integració el més aviat possible? Quan desenvolupen un connector, els desenvolupadors es basen en certes tecnologies (biblioteques, protocols, estàndards). I si s'escull un conjunt de tecnologies només per a equips cars, en el futur, el més probable és que un intent de canviar a càmeres barates, com a mínim, trigui un temps increïblement llarg o fins i tot falli i es torni a un equip car.

Font: www.habr.com