Ahoj všetci!

Pravdepodobne nie je žiadnym tajomstvom, že služby cloudového video sledovania si v poslednej dobe získavajú na popularite. A je jasné, prečo sa to deje, video je „ťažký“ obsah, ktorého ukladanie si vyžaduje infraštruktúru a veľké množstvo diskového priestoru. Používanie lokálneho video monitorovacieho systému vyžaduje finančné prostriedky na prevádzku a podporu, a to ako pre organizáciu používajúcu stovky monitorovacích kamier, tak aj pre jednotlivého používateľa s niekoľkými kamerami.

Cloudové video monitorovacie systémy riešia tento problém tým, že zákazníkom poskytujú existujúcu infraštruktúru na ukladanie a spracovanie videa. Cloudový monitorovací klient jednoducho potrebuje pripojiť kameru k internetu a prepojiť ju so svojím cloudovým účtom.

Existuje niekoľko technologických spôsobov, ako pripojiť kamery ku cloudu. Najpohodlnejšou a najlacnejšou metódou je nepochybne to, že sa kamera priamo pripája a pracuje s cloudom, bez účasti ďalších zariadení, ako je server alebo rekordér.

K tomu je potrebné, aby bol na kamere nainštalovaný softvérový modul pracujúci s cloudom. Ak však hovoríme o lacných fotoaparátoch, potom majú veľmi obmedzené hardvérové ​​​​zdroje, ktoré sú takmer na 100% obsadené natívnym firmvérom dodávateľa fotoaparátu a nie sú potrebné žiadne zdroje pre cloud plugin. Vývojári z ivideon venovali tomuto problému статью, čo vysvetľuje, prečo nemôžu nainštalovať plugin na lacné fotoaparáty. V dôsledku toho je minimálna cena fotoaparátu 5000 80 rubľov (XNUMX dolárov) a milióny peňazí vynaložených na vybavenie.

Tento problém sme úspešne vyriešili. Ak vás zaujíma ako - vitajte v strihu

Trocha histórie

V roku 2016 sme začali vyvíjať cloudovú platformu video sledovania pre Rostelecom.

Pokiaľ ide o softvér fotoaparátu, v prvej fáze sme pre takéto úlohy postupovali „štandardnou“ cestou: vyvinuli sme vlastný plugin, ktorý je nainštalovaný v štandardnom firmvéri fotoaparátu dodávateľa a funguje s naším cloudom. Stojí však za zmienku, že pri návrhu sme použili najľahšie a najefektívnejšie riešenia (napríklad implementáciu protobuf, libev, mbedtls v obyčajnom C a úplne opustené pohodlné, ale ťažké knižnice ako boost)

V súčasnosti na trhu IP kamier neexistujú žiadne univerzálne integračné riešenia: každý predajca má svoj vlastný spôsob inštalácie doplnku, vlastnú sadu API na obsluhu firmvéru a jedinečný aktualizačný mechanizmus.

To znamená, že pre každého dodávateľa kamier je potrebné individuálne vyvinúť komplexnú vrstvu integračného softvéru. A v čase spustenia vývoja je vhodné spolupracovať iba s 1 dodávateľom, aby sa úsilie tímu sústredilo na vývoj logiky pre prácu s cloudom.

Prvým vybraným dodávateľom bol Hikvision, jeden zo svetových lídrov na trhu fotoaparátov, ktorý poskytuje dobre zdokumentované API a kompetentnú technickú podporu.

Spustili sme náš prvý pilotný projekt, cloudové video sledovanie Video Comfort, pomocou kamier Hikvision.

Takmer okamžite po spustení sa naši používatelia začali pýtať na možnosť pripojenia lacnejších kamier iných výrobcov k službe.

Možnosť implementácie integračnej vrstvy pre každého dodávateľa som zamietol takmer okamžite – pretože je zle škálovateľná a kladie vážne technické požiadavky na hardvér fotoaparátu. Náklady na fotoaparát, ktorý spĺňa tieto vstupné požiadavky: ~ 60 – 70 $

Preto som sa rozhodol siahnuť hlbšie – vyrobiť si vlastný firmvér pre fotoaparáty od akéhokoľvek predajcu. Tento prístup výrazne znižuje požiadavky na hardvérové ​​zdroje fotoaparátu – pretože Vrstva pre prácu s cloudom je oveľa efektívnejšie integrovaná s video aplikáciou a vo firmvéri nie je zbytočný nevyužitý tuk.

A čo je dôležité, pri práci s kamerou na nízkej úrovni je možné použiť hardvérové ​​AES, ktoré šifruje dáta bez dodatočnej záťaže procesora s nízkou spotrebou.

V tej chvíli sme nemali vôbec nič. Vôbec nič.

Takmer všetci predajcovia neboli pripravení s nami spolupracovať na tak nízkej úrovni. Neexistujú žiadne informácie o obvodoch a komponentoch, neexistuje žiadna oficiálna súprava SDK čipových súprav a dokumentácia snímačov.
Nechýba ani technická podpora.

Všetky otázky museli byť zodpovedané prostredníctvom reverzného inžinierstva – pokus-omyl. Ale zvládli sme to.

Prvé modely fotoaparátov, na ktorých sme testovali, boli fotoaparáty Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link a niekoľko ultralacných bezmenných čínskych fotoaparátov.

Technika

Kamery založené na čipovej sade Hisilicon 3518E. Hardvérové ​​vlastnosti kamier sú nasledovné:

Xiaomi Yi Ants
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

senzor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofón
+
+

Reproduktor
+
+

IRLed
+
+

IRCut
+
+

Začali sme s nimi.

V súčasnosti podporujeme čipsety Hisilicon 3516/3518, ako aj Ambarella S2L/S2LM. Existujú desiatky modelov fotoaparátov.

Zloženie firmvéru

ponorka

uboot je zavádzač, ktorý sa po zapnutí spustí ako prvý, inicializuje hardvér a načíta linuxové jadro.

Skript načítania kamery je celkom triviálny:

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

Jednou z vlastností je, že sa volá dvakrát bootm, viac o tom trochu neskôr, keď sa dostaneme k subsystému aktualizácie.

Venujte pozornosť línii mem=38M. Áno, áno, toto nie je preklep – linuxové jadro a všetky, všetky, všetky aplikácie majú prístup len k 38 megabajtom RAM.

Vedľa uboot je tiež špeciálny blok tzv reg_info, ktorý obsahuje nízkoúrovňový skript na inicializáciu DDR a množstvo systémových registrov SoC. Obsah reg_info závisí od modelu fotoaparátu, a ak nie je správny, fotoaparát nebude môcť ani načítať uboot, ale zamrzne vo veľmi skorom štádiu načítania.

Najprv, keď sme pracovali bez podpory dodávateľa, sme tento blok jednoducho skopírovali z pôvodného firmvéru fotoaparátu.

Linuxové jadro a rootfs

Kamery využívajú linuxové jadro, ktoré je súčasťou SDK čipu, väčšinou sa nejedná o najnovšie jadrá z vetvy 3.x, takže sa často musíme potýkať s tým, že ovládače pre prídavné zariadenia nie sú kompatibilné s použitým jadrom a musíme ich spätne portovať do kamier jadra.

Ďalším problémom je veľkosť jadra. Keď je veľkosť FLASH iba 8 MB, potom sa počíta každý bajt a našou úlohou je opatrne vypnúť všetky nepoužívané funkcie jadra, aby sa veľkosť zmenšila na minimum.

Rootfs je základný súborový systém. Obsahuje busybox, ovládače wifi modulu, súbor štandardných systémových knižníc, ako napr libld и libc, ako aj náš softvér, ktorý je zodpovedný za logiku ovládania LED, správu sieťového pripojenia a aktualizácie firmvéru.

Koreňový súborový systém je pripojený k jadru ako initramfs a ako výsledok zostavenia dostaneme jeden súbor uImage, ktorý obsahuje jadro aj rootfs.

Video aplikácia

Najkomplexnejšou a najnáročnejšou časťou firmvéru je aplikácia, ktorá poskytuje video-audio snímanie, kódovanie videa, konfiguruje parametre obrazu, implementuje analýzu videa, napríklad detektory pohybu alebo zvuku, riadi PTZ a je zodpovedná za prepínanie dňa a nočné režimy.

Dôležitou, dokonca by som povedal kľúčovou funkciou je, ako video aplikácia interaguje s cloudovým doplnkom.

V tradičných riešeniach 'firmware dodávateľa + cloud plugin', ktoré nemôžu fungovať na lacnom hardvéri, sa video vo vnútri kamery prenáša cez protokol RTSP – a to je obrovská réžia: kopírovanie a prenos dát cez zásuvku, zbytočné systémové volania.

Na tomto mieste využívame mechanizmus zdieľanej pamäte - video sa nekopíruje ani neposiela cez zásuvku medzi softvérovými komponentmi kamery, čím sa optimálne a opatrne využívajú skromné ​​hardvérové ​​možnosti kamery.

Aktualizovať podsystém

Zvláštnou hrdosťou je subsystém odolný voči chybám pre online aktualizácie firmvéru.

Dovoľte mi vysvetliť problém. Aktualizácia firmvéru technicky nie je atómová operácia a ak dôjde k výpadku napájania uprostred aktualizácie, flash pamäť bude obsahovať časť „podpísaného“ nového firmvéru. Ak neprijmete špeciálne opatrenia, z fotoaparátu sa stane „tehla“, ktorú je potrebné odniesť do servisného strediska.

Aj tento problém sme riešili. Aj keď je kamera počas aktualizácie vypnutá, automaticky a bez zásahu používateľa stiahne firmvér z cloudu a obnoví prevádzku.

Pozrime sa na techniku ​​podrobnejšie:

Najzraniteľnejším bodom je prepísanie oddielu linuxovým jadrom a koreňovým súborovým systémom. Ak je jedna z týchto súčastí poškodená, kamera sa vôbec nespustí mimo bootloadera uboot, ktorý nedokáže stiahnuť firmvér z cloudu.

To znamená, že musíme zabezpečiť, aby kamera mala funkčné jadro a rootfs kedykoľvek počas procesu aktualizácie. Zdalo by sa, že najjednoduchším riešením by bolo neustále ukladať dve kópie jadra s rootfs na flash pamäť a ak je hlavné jadro poškodené, načítať ho zo záložnej kópie.

Dobré riešenie – jadro s rootfs však zaberá asi 3.5 MB a pre trvalú zálohu je potrebné vyčleniť 3.5 MB. Najlacnejšie kamery jednoducho nemajú toľko voľného miesta pre záložné jadro.

Preto na zálohovanie jadra počas aktualizácie firmvéru používame oblasť aplikácie.
A na výber požadovaného oddielu s jadrom sa používajú dva príkazy bootm v uboot - na začiatku sa snažíme načítať hlavné jadro a ak je poškodené, tak záložné.

To zaisťuje, že v každom danom čase bude mať kamera správne jadro s rootfs a bude schopná zaviesť a obnoviť firmvér.

CI/CD systém na vytváranie a nasadzovanie firmvéru

Na zostavenie firmvéru používame gitlab CI, ktorý automaticky zostaví firmvér pre všetky podporované modely kamier a po zostavení firmvéru sa automaticky nasadí do služby aktualizácie softvéru fotoaparátu.

Prostredníctvom služby sa aktualizácie firmvéru doručujú do našich testovacích kamier QA a po dokončení všetkých fáz testovania do kamier používateľov.

Informačná bezpečnosť

Nie je žiadnym tajomstvom, že v súčasnosti je informačná bezpečnosť najdôležitejším aspektom akéhokoľvek zariadenia internetu vecí, vrátane kamier. Botnety ako Mirai sa potulujú po internete a infikujú milióny kamier so štandardným firmvérom od predajcov. Pri všetkej úcte k predajcom fotoaparátov mi nedá nepoznamenať, že štandardný firmvér obsahuje množstvo funkcionality, ktorá nie je potrebná pre prácu s cloudom, no obsahuje množstvo zraniteľností, ktoré botnety využívajú.

Preto sú všetky nepoužívané funkcie v našom firmvéri deaktivované, všetky porty tcp/udp sú zatvorené a pri aktualizácii firmvéru sa kontroluje digitálny podpis softvéru.

Firmvér okrem toho prechádza pravidelným testovaním v laboratóriu informačnej bezpečnosti.

Záver

Teraz sa náš firmvér aktívne používa v projektoch video sledovania. Azda najväčším z nich je vysielanie hlasovania v deň volieb prezidenta Ruskej federácie.
Do projektu sa zapojilo viac ako 70 tisíc kamier s naším firmvérom, ktoré boli nainštalované vo volebných miestnostiach u nás.

Po vyriešení množstva zložitých a miestami aj v tej dobe takmer nemožných problémov sme sa samozrejme ako inžinieri dočkali veľkej spokojnosti, no okrem toho sme ušetrili aj milióny dolárov na nákup kamier. A v tomto prípade úspory nie sú len slová a teoretické výpočty, ale výsledky už ukončeného výberového konania na nákup zariadení. V súlade s tým, ak hovoríme o cloudovom video dohľade: existujú dva prístupy – strategicky sa spoliehať na odbornosť a vývoj na nízkej úrovni, čo vedie k obrovským úsporám na zariadení, alebo používať drahé zariadenia, ktoré, ak sa pozriete konkrétne na charakteristiky spotrebiteľov, prakticky neexistujú. odlišné od podobných lacných.

Prečo je strategicky dôležité rozhodnúť o výbere integračného prístupu čo najskôr? Pri vývoji pluginu sa vývojári spoliehajú na určité technológie (knižnice, protokoly, štandardy). A ak sa súbor technológií vyberie len pre drahé zariadenia, tak v budúcnosti bude pokus o prechod na lacné kamery s najväčšou pravdepodobnosťou trvať prinajmenšom šialene dlho alebo dokonca zlyhá a dôjde k návratu k drahým zariadeniam.

Zdroj: hab.com