Ahoj všichni!

Pravděpodobně není žádným tajemstvím, že cloudové video sledovací služby v poslední době získávají na popularitě. A je jasné, proč se to děje, video je „těžký“ obsah, jehož uložení vyžaduje infrastrukturu a velké množství diskového úložiště. Použití místního video monitorovacího systému vyžaduje finanční prostředky na provoz a podporu, a to jak pro organizaci používající stovky monitorovacích kamer, tak pro jednotlivého uživatele s několika kamerami.

Cloudové video monitorovací systémy řeší tento problém tím, že zákazníkům poskytují stávající infrastrukturu pro ukládání a zpracování videa. Klient pro cloudové video sledování jednoduše potřebuje připojit kameru k internetu a propojit ji se svým cloudovým účtem.

Existuje několik technologických způsobů, jak připojit kamery ke cloudu. Nejpohodlnější a nejlevnější metodou je bezesporu to, že se kamera přímo připojuje a pracuje s cloudem, bez účasti dalšího zařízení, jako je server nebo rekordér.

K tomu je nutné, aby byl na kameře nainstalován softwarový modul pracující s cloudem. Pokud však mluvíme o levných fotoaparátech, pak mají velmi omezené hardwarové zdroje, které jsou téměř 100% obsazeny nativním firmwarem dodavatele fotoaparátu a pro cloudový plugin nejsou žádné prostředky. Vývojáři z ivideonu se tomuto problému věnovali Článek, což vysvětluje, proč nemohou nainstalovat plugin na levné fotoaparáty. V důsledku toho je minimální cena fotoaparátu 5000 rublů (80 dolarů) a miliony peněz vynaložené na vybavení.

Tento problém jsme úspěšně vyřešili. Pokud vás zajímá jak - vítejte na střihu

Trocha historie

V roce 2016 jsme začali vyvíjet cloudovou video monitorovací platformu pro Rostelecom.

Pokud jde o software fotoaparátu, v první fázi jsme pro takové úkoly postupovali „standardní“ cestou: vyvinuli jsme vlastní plugin, který je nainstalován ve standardním firmwaru fotoaparátu dodavatele a pracuje s naším cloudem. Je však třeba poznamenat, že při návrhu jsme použili nejlehčí a nejefektivnější řešení (například implementace protobuf, libev, mbedtls v prostém C a zcela opuštěné pohodlné, ale těžké knihovny jako boost)

V současné době na trhu IP kamer neexistují žádná univerzální integrační řešení: každý dodavatel má svůj vlastní způsob instalace pluginu, vlastní sadu API pro provoz firmwaru a jedinečný aktualizační mechanismus.

To znamená, že pro každého dodavatele kamer je nutné individuálně vyvinout komplexní vrstvu integračního softwaru. A v době zahájení vývoje je vhodné spolupracovat pouze s 1 dodavatelem, abyste mohli soustředit úsilí týmu na vývoj logiky pro práci s cloudem.

Prvním vybraným dodavatelem byl Hikvision, jeden ze světových lídrů na trhu fotoaparátů, poskytující dobře zdokumentované API a kompetentní technickou podporu.

Spustili jsme náš první pilotní projekt, cloudové video sledování Video Comfort, pomocí kamer Hikvision.

Téměř okamžitě po spuštění se naši uživatelé začali ptát na možnost připojení levnějších fotoaparátů jiných výrobců ke službě.

Možnost implementace integrační vrstvy pro každého dodavatele jsem prakticky okamžitě zavrhl – protože je špatně škálovatelná a klade vážné technické požadavky na hardware fotoaparátu. Cena kamery, která splňuje tyto vstupní požadavky: ~60-70 $

Proto jsem se rozhodl sáhnout hlouběji – vyrobit si vlastní firmware pro fotoaparáty od libovolného výrobce. Tento přístup výrazně snižuje požadavky na hardwarové zdroje fotoaparátu – protože Vrstva pro práci s cloudem je mnohem efektivněji integrována s video aplikací a ve firmwaru není zbytečný nevyužitý tuk.

A co je důležité, při práci s kamerou na nízké úrovni je možné využít hardwarové AES, které šifruje data bez dodatečného zatížení procesoru s nízkou spotřebou.

V tu chvíli jsme neměli vůbec nic. Vůbec nic.

Téměř všichni prodejci nebyli připraveni s námi spolupracovat na tak nízké úrovni. Neexistují žádné informace o návrhu obvodu a součástkách, neexistuje oficiální SDK čipových sad a dokumentace snímačů.
Nechybí ani technická podpora.

Všechny otázky musely být zodpovězeny pomocí reverzního inženýrství – metodou pokusů a omylů. Ale zvládli jsme to.

První modely kamer, na kterých jsme testovali, byly kamery Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link a několik ultra levných bezejmenných čínských kamer.

Technika

Kamery založené na čipové sadě Hisilicon 3518E. Hardwarové vlastnosti kamer jsou následující:

Xiaomi Yi Ants
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

BLIKAT
16MB
8MB

WiFi
mt7601/bcm43143
-

Senzor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Mluvčí
+
+

IRled
+
+

IRCut
+
+

Začali jsme s nimi.

V současné době podporujeme čipové sady Hisilicon 3516/3518 a také Ambarella S2L/S2LM. Existují desítky modelů fotoaparátů.

Složení firmwaru

ponorka

uboot je zavaděč, který se zavede jako první po zapnutí, inicializuje hardware a načte linuxové jádro.

Skript načítání kamery je docela triviální:

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 funkcí je, že se volá dvakrát bootm, více o tom trochu později, až se dostaneme k aktualizačnímu subsystému.

Věnujte pozornost linii mem=38M. Ano, ano, nejedná se o překlep – linuxové jádro a všechny, všechny, všechny aplikace mají přístup pouze k 38 MB RAM.

Vedle ubootu je také speciální blok nazvaný reg_info, který obsahuje nízkoúrovňový skript pro inicializaci DDR a řadu systémových registrů SoC. Obsah reg_info závisí na modelu kamery, a pokud není správný, kamera ani nebude moci načíst uboot, ale zamrzne ve velmi rané fázi načítání.

Nejprve, když jsme pracovali bez podpory dodavatele, jsme tento blok jednoduše zkopírovali z původního firmwaru fotoaparátu.

Linuxové jádro a rootfs

Kamery využívají linuxové jádro, které je součástí SDK čipu, většinou se nejedná o nejnovější jádra z větve 3.x, takže se často musíme potýkat s tím, že ovladače pro přídavná zařízení nejsou kompatibilní s použitým jádrem a musíme je zpětně portovat do kamer jádra.

Dalším problémem je velikost jádra. Když je velikost FLASH pouhých 8 MB, pak se počítá každý bajt a naším úkolem je pečlivě deaktivovat všechny nepoužívané funkce jádra, aby se velikost zmenšila na minimum.

Rootfs je základní souborový systém. To zahrnuje busybox, ovladače wifi modulu, sada standardních systémových knihoven, jako např libld и libc, stejně jako náš software, který je zodpovědný za logiku ovládání LED, správu síťových připojení a aktualizace firmwaru.

Kořenový souborový systém je připojen k jádru jako initramfs a jako výsledek sestavení získáme jeden soubor uImage, který obsahuje jak jádro, tak rootfs.

Video aplikace

Nejsložitější a na zdroje nejnáročnější část firmwaru je aplikace, která zajišťuje zachycení videa a zvuku, kódování videa, konfiguruje parametry obrazu, implementuje analýzu obrazu, například detektory pohybu nebo zvuku, ovládá PTZ a je zodpovědná za přepínání dne a noční režimy.

Důležitou, dokonce bych řekl klíčovou funkcí je, jak video aplikace spolupracuje s cloudovým pluginem.

V tradičních řešeních 'firmware dodavatele + cloud plugin', které nemohou fungovat na levném hardwaru, se video uvnitř kamery přenáší přes protokol RTSP - a to je obrovská režie: kopírování a přenos dat přes zásuvku, zbytečné systémové volání.

V tomto místě využíváme mechanismus sdílené paměti – video se nekopíruje ani neodesílá přes zdířku mezi softwarovými komponentami kamery, čímž optimálně a pečlivě využíváme skromné ​​hardwarové možnosti kamery.

Aktualizovat subsystém

Zvláštní pýchou je subsystém odolný proti chybám pro online aktualizace firmwaru.

Dovolte mi vysvětlit problém. Aktualizace firmwaru technicky není atomická operace a pokud dojde k výpadku napájení uprostřed aktualizace, pak bude flash paměť obsahovat část „podepsaného“ nového firmwaru. Pokud nepodniknete speciální opatření, z kamery se stane „cihla“, kterou je třeba odnést do servisního střediska.

I tento problém jsme řešili. I když je fotoaparát během aktualizace vypnutý, automaticky a bez zásahu uživatele stáhne firmware z cloudu a obnoví provoz.

Podívejme se na techniku ​​podrobněji:

Nejzranitelnějším bodem je přepsání oddílu linuxovým jádrem a kořenovým souborovým systémem. Pokud je některá z těchto součástí poškozena, kamera se mimo bootloader uboot, který nemůže stáhnout firmware z cloudu, vůbec nespustí.

To znamená, že musíme zajistit, aby kamera měla funkční jádro a rootfs kdykoli během procesu aktualizace. Zdálo by se, že nejjednodušším řešením by bylo neustále ukládat dvě kopie jádra s rootfs na flash paměť a v případě poškození hlavního jádra je načíst ze záložní kopie.

Dobré řešení - nicméně jádro s rootfs zabírá cca 3.5 MB a pro trvalou zálohu je potřeba alokovat 3.5 MB. Nejlevnější kamery prostě nemají tolik volného místa pro záložní jádro.

Proto k zálohování jádra během aktualizace firmwaru používáme aplikační oddíl.
A k výběru požadovaného oddílu s jádrem se používají dva příkazy bootm v ubootu - na začátku zkusíme nahrát hlavní jádro a pokud je poškozené, tak záložní.

To zajišťuje, že v každém okamžiku bude mít kamera správné jádro s rootfs a bude schopna zavést a obnovit firmware.

CI/CD systém pro vytváření a nasazení firmwaru

K sestavení firmwaru používáme gitlab CI, který automaticky sestaví firmware pro všechny podporované modely fotoaparátů a po sestavení firmwaru je automaticky nasazen do služby aktualizace softwaru fotoaparátu.

Ze služby jsou aktualizace firmwaru dodávány do našich testovacích kamer QA a po dokončení všech fází testování do kamer uživatelů.

Informační bezpečnost

Není žádným tajemstvím, že v dnešní době je bezpečnost informací nejdůležitějším aspektem jakéhokoli zařízení IoT, včetně kamer. Botnety jako Mirai se potulují po internetu a infikují miliony fotoaparátů standardním firmwarem od prodejců. Při vší úctě k dodavatelům fotoaparátů si nemohu pomoci, ale poznamenat, že standardní firmware obsahuje spoustu funkcí, které nejsou pro práci s cloudem potřeba, ale obsahují mnoho zranitelností, kterých botnety využívají.

Proto jsou všechny nepoužívané funkce v našem firmwaru deaktivovány, všechny tcp/udp porty jsou uzavřeny a při aktualizaci firmwaru je kontrolován digitální podpis softwaru.

A kromě toho firmware prochází pravidelným testováním v laboratoři informační bezpečnosti.

Závěr

Nyní se náš firmware aktivně používá v projektech video dohledu. Snad největší z nich je vysílání hlasování v den voleb prezidenta Ruské federace.
Do projektu se zapojilo více než 70 tisíc kamer s naším firmwarem, které byly instalovány ve volebních místnostech u nás.

Po vyřešení řady složitých a místy i v té době téměř nemožných problémů jsme se samozřejmě jako inženýři dočkali velkého zadostiučinění, ale kromě toho jsme ušetřili i miliony dolarů na nákupu kamer. A úsporami nejsou v tomto případě jen slova a teoretické výpočty, ale výsledky již ukončeného výběrového řízení na nákup zařízení. Pokud tedy mluvíme o cloudovém video dohledu: existují dva přístupy – strategicky spoléhat na odbornost a vývoj na nízké úrovni, což vede k obrovským úsporám na zařízení, nebo používat drahé vybavení, které, pokud se podíváte konkrétně na vlastnosti spotřebitelů, prakticky neexistuje. odlišné od podobných levných.

Proč je strategicky důležité rozhodnout o volbě integračního přístupu co nejdříve? Při vývoji pluginu se vývojáři spoléhají na určité technologie (knihovny, protokoly, standardy). A pokud se zvolí sada technologií pouze pro drahé vybavení, pak pokus o přechod na levné kamery bude v budoucnu s největší pravděpodobností trvat minimálně šíleně dlouho nebo dokonce selže a dojde k návratu k drahému vybavení.

Zdroj: www.habr.com