Ahoj všichni!

Pravděpodobně není žádným tajemstvím, že cloudové služby video dohledu v poslední době získávají na popularitě. To je pochopitelné: video je náročný obsah, který vyžaduje infrastrukturu a velké množství diskového úložiště pro jeho uložení. Používání místního systému video dohledu vyžaduje provozní a podpůrné náklady, ať už pro organizaci se stovkami kamer, nebo pro jednotlivého uživatele s jen několika kamerami.

Cloudové systémy video dohledu řeší tento problém tím, že klientům poskytují stávající infrastrukturu pro ukládání a zpracování videa. Klienti cloudového video dohledu jednoduše připojí kameru k internetu a propojí ji se svým cloudovým účtem.

Existuje několik technologických metod pro připojení kamer ke cloudu. Nepochybně nejpohodlnější a nejnákladově efektivnější metodou je přímé připojení kamery a spolupráce s cloudem, bez nutnosti dalšího vybavení, jako je například server nebo registrátor.

To vyžaduje, aby kamera měla nainstalovaný cloudově kompatibilní softwarový modul. Levné kamery však mají velmi omezené hardwarové prostředky, které jsou téměř výhradně obsazeny firmwarem dodavatele kamery, a chybí jim prostředky potřebné pro cloudový plugin. Vývojáři z ivideonu věnovali tomuto problému specializovaný projekt. Článek, což vysvětluje, proč nemohou plugin nainstalovat na levné fotoaparáty. V důsledku toho je minimální cena fotoaparátu 5 000 rublů (80 dolarů) a za vybavení byly utraceny miliony dolarů.

Tento problém jsme úspěšně vyřešili. Pokud vás zajímá jak, vítejte u článku.

Trocha historie

V roce 2016 jsme začali s vývojem cloudové platformy pro video dohled pro Rostelecom.

Pokud jde o software kamery, zpočátku jsme se řídili standardním přístupem pro takové úkoly: vyvinuli jsme vlastní plugin, který se instaluje do firmwaru kamery dodavatele a spolupracuje s naším cloudem. Stojí však za zmínku, že během procesu návrhu jsme použili nejlehčí a nejefektivnější řešení (například jednoduchou implementaci protobufu, libev a mbedtls v jazyce C a zcela jsme opustili praktické, ale těžké knihovny jako boost).

V současné době na trhu s IP kamerami neexistují žádná univerzální integrační řešení: každý dodavatel má vlastní metodu instalace pluginů, vlastní sadu API pro provoz firmwaru a jedinečný mechanismus aktualizace.

To znamená, že pro každého dodavatele kamery musí být individuálně vyvinuta komplexní softwarová vrstva pro integraci. Na začátku vývoje je rozumné spolupracovat pouze s jedním dodavatelem, aby se tým mohl soustředit na vývoj cloudové logiky.

Prvním vybraným dodavatelem byla společnost Hikvision, jeden ze světových lídrů na trhu s kamerami, poskytující dobře zdokumentované API a kompetentní technickou podporu.

Spustili jsme náš první pilotní projekt Videocomfort s využitím 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ů od jiných výrobců ke službě.

Možnost implementace integrační vrstvy pro každého dodavatele jsem téměř okamžitě zavrhl, protože by byla špatně škálovatelná a kladla by značné technické nároky na hardware kamery. Cena kamery, která splňuje tyto vstupní požadavky, se pohybuje kolem 60–70 dolarů.

Rozhodl jsem se tedy ponořit hlouběji do problematiky a vytvořit si vlastní firmware pro kamery od libovolného dodavatele. Tento přístup výrazně snižuje hardwarové nároky kamery, protože cloudová vrstva je mnohem efektivněji integrována s video aplikací a firmware nepředstavuje žádné zbytečné režijní náklady.

A co je důležité, je to, že při práci s kamerou na nízké úrovni je možné použít hardwarové AES, které šifruje data bez vytváření dodatečné zátěže pro nízkoenergetický procesor.

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

Téměř všichni dodavatelé s námi nebyli ochotni spolupracovat na tak nízké úrovni. Nebyly k dispozici žádné informace o návrhu obvodů ani součástek a žádné oficiální SDK pro čipsety ani dokumentace k senzorům.
Neexistuje ani žádná technická podpora.

Všechny odpovědi musely být nalezeny reverzním inženýrstvím – metodou pokus-omyl. Ale zvládli jsme to.

První modely kamer, se kterými jsme se setkali, byly Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link a několik superlevných čínských kamer bez názvu.

Technika

Kamery jsou založeny na čipové sadě Hisilicon 3518E. Hardwarové specifikace kamery jsou následující:

Xiaomi Yi Ants
noname

SoC
Hisilicón 3518E
Hisilicón 3518E

RAM
64MB
64MB

BLIKAT
16MB
8MB

WiFi
mt7601/bcm43143
-

Senzor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Mluvčí
+
+

V reálném životě
+
+

IRCut
+
+

Začali jsme s nimi.

Aktuálně podporujeme čipové sady Hisilicon 3516/3518 a také Ambarella S2L/S2LM. Nabízíme desítky modelů kamer.

Složení firmwaru

uboot

uboot je bootloader, který se po zapnutí počítače jako první spustí, inicializuje hardware a načte linuxové jádro.

Skript pro 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 vlastností je, že se volá dvakrát. bootm, o tom více o něco později, až se dostaneme k subsystému aktualizace.

Věnujte pozornost linii mem=38MAno, ano, to není překlep - jádro Linux a všechny-všechny-všechny aplikace mají přístup pouze k 38 megabajtům RAM.

Vedle ubootu se nachází také speciální blok s názvem reg_info, který obsahuje nízkoúrovňový skript pro inicializaci DDR a řady systémových registrů SoC. Obsah reg_info Záleží na modelu fotoaparátu a pokud není správný, fotoaparát ani nebude schopen načíst uboot, ale zamrzne v úplně rané fázi načítání.

Zpočátku, 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 používají jádro Linux, který je součástí SDK čipu, obvykle nebývá nejnovějšími jádry z větve 3.x, takže se často setkáváme se situací, kdy ovladače pro přídavné zařízení nejsou kompatibilní s použitým jádrem a musíme je zpětně portovat do jádra fotoaparátu.

Dalším problémem je velikost jádra. Pokud má flash paměť pouze 8 MB, počítá se každý bajt a naším úkolem je pečlivě deaktivovat všechny nepoužívané funkce jádra, abychom velikost zmenšili na minimum.

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

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

Videoaplikace

Nejsložitější a nejnáročnější částí firmwaru je aplikace, která zajišťuje záznam videa a zvuku, kódování videa, konfiguruje parametry obrazu, implementuje video analytiku, jako jsou detektory pohybu nebo zvuku, ovládá PTZ a je zodpovědná za přepínání mezi denním a nočním režimem.

Důležitou, dokonce bych řekl klíčovou, funkcí je interakce videoaplikace s cloudovým pluginem.

V tradičních řešeních typu „firmware od dodavatele + cloudový plugin“, která nemohou běžet na levném hardwaru, se video uvnitř kamery přenáší protokolem RTSP – což s sebou nese značné režijní náklady: kopírování a přenos dat přes sockety a zbytečná systémová volání.

Zde používáme mechanismus sdílené paměti – video se nekopíruje ani neodesílá přes socket mezi softwarovými komponentami kamery, čímž optimálně a efektivně využíváme omezené hardwarové možnosti kamery.

Aktualizační subsystém

Zdrojem zvláštní hrdosti je subsystém online aktualizace firmwaru odolný vůči chybám.

Dovolte mi vysvětlit problém. Aktualizace firmwaru technicky není atomická operace a pokud dojde k výpadku napájení během aktualizace, flash paměť bude obsahovat nějaký nedokončený firmware. Pokud nepodniknete speciální opatření, fotoaparát se stane cihlou, kterou bude nutné odvézt do servisního střediska.

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

Pojďme se na techniku ​​podívat podrobněji:

Nejzranitelnějším momentem je přepsání oddílu s jádrem. Linux a kořenový souborový systém. Pokud je některá z těchto komponent poškozena, fotoaparát se nespustí za hranicí bootloaderu Ubuntu, který nedokáže stáhnout firmware z cloudu.

To znamená, že musíme zajistit, aby měl fotoaparát během aktualizace neustále funkční jádro a rootfs. Zdá se, že nejjednodušším řešením by bylo trvale uložit dvě kopie jádra a rootfs na flash paměť a v případě poškození primárního jádra jej spustit ze zálohy.

Slušné řešení, ale jádro s rootfs zabírá asi 3.5 MB a pro trvalou zálohu je potřeba alokovat 3.5 MB. Nejlevnější fotoaparáty prostě tolik volného místa pro zálohu jádra nemají.

Proto pro zálohování jádra během aktualizací firmwaru používáme aplikační oddíl.
A pro výběr požadovaného oddílu s jádrem se používají dva příkazy bootm V ubootu se nejprve pokusíme načíst hlavní jádro, a pokud je poškozené, tak záložní.

Díky tomu bude mít kamera v daném okamžiku správné jádro s rootfs a bude schopna spustit a obnovit firmware.

Systém pro sestavení a nasazení firmwaru CI/CD

Pro sestavení firmwaru používáme GitLab CI, který automaticky sestavuje firmware pro všechny podporované modely fotoaparátů. Po sestavení je firmware automaticky nasazen do služby aktualizace softwaru fotoaparátu.

Z aktualizační služby softwaru jsou aktualizace firmwaru doručovány do našich testovacích kamer pro kontrolu kvality a po dokončení všech fází testování do uživatelských kamer.

Informační bezpečnost

Není žádným tajemstvím, že informační bezpečnost je v dnešní době klíčovým aspektem jakéhokoli zařízení internetu věcí, včetně kamer. Botnety jako Mirai kolují online a infikují miliony kamer se standardním firmwarem od různých dodavatelů. S veškerou úctou k dodavatelům kamer nemohu nepoznamenat, že standardní firmware obsahuje mnoho funkcí, které nejsou pro cloud computing potřeba, ale obsahuje řadu zranitelností, které botnety zneužívají.

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

Firmware navíc prochází pravidelným testováním v laboratoři informační bezpečnosti.

Závěr

Náš firmware se v současné době aktivně používá v projektech video dohledu. Asi nejrozsáhlejším z nich je vysílání hlasování v den ruských prezidentských voleb.
Projekt zahrnoval více než 70 000 kamer s naším firmwarem, které byly instalovány ve volebních místnostech po celé naší zemi.

Po vyřešení řady složitých a v některých případech prakticky neřešitelných problémů jsme jako inženýři jistě dosáhli obrovské spokojenosti, ale také jsme ušetřili miliony dolarů za nákup kamer. A v tomto případě úspory nejsou jen rétorikou a teoretickými výpočty, ale výsledkem skutečného výběrového řízení na vybavení. Pokud jde o cloudový video dohled, existují tedy dva přístupy: strategické spoléhání se na nízkoúrovňovou expertízu a vývoj, což vede k obrovským úsporám na vybavení, nebo použití drahého vybavení, které je z hlediska výkonu prakticky nerozeznatelné od podobných, levnějších možností.

Proč je strategicky důležité rozhodnout se o integračním přístupu co nejdříve? Při vývoji pluginu se vývojáři spoléhají na specifické technologie (knihovny, protokoly, standardy). Pokud je sada technologií vybrána výhradně pro drahé vybavení, pak jakýkoli následný pokus o migraci na levnější kamery pravděpodobně bude trvat šíleně dlouho, nebo dokonce selže, což povede k návratu k drahému vybavení.

Zdroj: www.habr.com