Hello!

Valószínűleg nem titok, hogy a felhőalapú videofelügyeleti szolgáltatások az utóbbi időben egyre népszerűbbek. És egyértelmű, hogy miért történik ez, a videó „nehéz” tartalom, amelynek tárolása infrastruktúrát és nagy mennyiségű lemeztárat igényel. A helyszíni videomegfigyelő rendszer használatához pénzeszközökre van szükség a működéshez és támogatáshoz, mind a több száz térfigyelő kamerát használó szervezet, mind a több kamerával rendelkező egyéni felhasználó számára.

A felhőalapú videofelügyeleti rendszerek megoldják ezt a problémát azáltal, hogy meglévő videótároló és -feldolgozási infrastruktúrát biztosítanak az ügyfeleknek. A felhőalapú videó megfigyelő kliensnek egyszerűen csatlakoztatnia kell a kamerát az internethez, és össze kell kapcsolnia felhőfiókjával.

Számos technológiai módszer létezik a kamerák felhőhöz való csatlakoztatására. Kétségtelenül a legkényelmesebb és legolcsóbb módszer az, hogy a kamera közvetlenül csatlakozik a felhőhöz és működik vele, további berendezések, például szerver vagy felvevő részvétele nélkül.

Ehhez egy felhővel együttműködő szoftvermodul telepítése szükséges a kamerára. Ha azonban olcsó kamerákról beszélünk, akkor ezek nagyon korlátozott hardvererőforrással rendelkeznek, amelyeket szinte 100%-ban a kameragyártó natív firmware-e foglal el, és a felhőbővítményhez nem szükséges erőforrás. Az ivideon fejlesztői ezt a problémát szentelték статью, ami megmagyarázza, miért nem tudják telepíteni a plugint olcsó kamerákra. Ennek eredményeként a kamera minimális ára 5000 rubel (80 dollár), és több millió pénzt költöttek felszerelésre.

Sikeresen megoldottuk ezt a problémát. Ha érdekel, hogyan - üdvözöljük a vágás

Egy kis történelem

2016-ban elkezdtük a Rostelecom felhőalapú videó megfigyelési platformjának fejlesztését.

A kameraszoftverek terén az első szakaszban a „szabványos” utat követtük az ilyen feladatokhoz: kifejlesztettük saját bővítményünket, amely a gyártó kamerájának szabványos firmware-ébe van telepítve, és működik a felhőnkkel. Érdemes azonban megjegyezni, hogy a tervezés során a legkönnyebb és leghatékonyabb megoldásokat használtuk (például protobuf, libev, mbedtls sima C implementációja és teljesen elhagyott kényelmes, de nehéz könyvtárak, mint a boost)

Jelenleg nincsenek univerzális integrációs megoldások az IP-kamerák piacán: minden gyártó saját módszerrel telepíti a bővítményt, saját API-készlettel rendelkezik a firmware működtetéséhez, és egyedi frissítési mechanizmussal rendelkezik.

Ez azt jelenti, hogy minden kameragyártó számára egyedileg kell kifejleszteni egy átfogó integrációs szoftverréteget. A fejlesztés megkezdésekor pedig tanácsos csak 1 szállítóval együttműködni, hogy a csapat erőfeszítéseit a felhővel való munka logikájának fejlesztésére koncentrálhassa.

Elsőként a Hikvisiont választották, amely a világ egyik vezető kamerapiaca, amely jól dokumentált API-t és hozzáértő műszaki műszaki támogatást biztosít.

Elindítottuk első kísérleti projektünket, a Video Comfort felhőalapú videófelügyeletet Hikvision kamerák segítségével.

Szinte azonnal az indulás után felhasználóiink elkezdtek kérdéseket feltenni azzal kapcsolatban, hogy más gyártók olcsóbb kameráit is csatlakoztatni lehet-e a szolgáltatáshoz.

Szinte azonnal elvetettem azt a lehetőséget, hogy minden gyártónál beépítsenek egy integrációs réteget - mivel az rosszul skálázható, és komoly technikai követelményeket támaszt a kamera hardverével szemben. A bemeneti követelményeknek megfelelő kamera ára: ~60-70$

Ezért úgy döntöttem, hogy mélyebbre ások - saját firmware-t készítek bármely gyártó kameráihoz. Ez a megközelítés jelentősen csökkenti a kamera hardver erőforrásaival szemben támasztott követelményeket - mert A felhővel való munkavégzés rétege sokkal hatékonyabban integrálódik a videoalkalmazásba, és nincs felesleges, nem használt zsír a firmware-ben.

És ami fontos, hogy ha alacsony szinten dolgozik a kamerával, akkor lehetőség van hardveres AES használatára, amely titkosítja az adatokat anélkül, hogy további terhelést okozna az alacsony fogyasztású CPU-nak.

Abban a pillanatban nem volt semmink. Semmi sem.

Szinte minden gyártó nem állt készen arra, hogy ilyen alacsony szinten dolgozzon velünk. Nincs információ az áramkörről és a komponensekről, nincs hivatalos chipkészlet SDK és érzékelő dokumentáció.
Nincs technikai támogatás sem.

Minden kérdésre visszafejtés útján kellett válaszolni – próba és hiba. De sikerült.

Az első kameramodellek, amelyeket teszteltünk, a Xiaomi Yi Ants, a Hikvision, a Dahua, a Spezvision, a D-Link kamerák és számos rendkívül olcsó névtelen kínai fényképezőgép volt.

Technika

Hisilicon 3518E lapkakészleten alapuló kamerák. A kamerák hardveres jellemzői a következők:

Xiaomi Yi Ants
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

VAKU
16MB
8MB

WiFi
mt7601/bcm43143
-

Érzékelő
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Hangszóró
+
+

IRLed
+
+

IRCut
+
+

Velük kezdtük.

Jelenleg a Hisilicon 3516/3518 lapkakészleteket, valamint az Ambarella S2L/S2LM-et támogatjuk. Több tucat kameramodell létezik.

Firmware összetétele

uboot

Az uboot az indító betöltő, bekapcsolás után először indul el, inicializálja a hardvert és betölti a linux kernelt.

A kamerabetöltési szkript meglehetősen triviális:

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

Az egyik jellemzője, hogy kétszer hívják bootm, erről kicsit később, amikor a frissítési alrendszerhez érünk.

Ügyeljen a vonalra mem=38M. Igen, igen, ez nem elírás – a Linux kernel és minden, minden alkalmazás mindössze 38 megabájt RAM-hoz fér hozzá.

Szintén az uboot mellett van egy speciális blokk, az úgynevezett reg_info, amely egy alacsony szintű szkriptet tartalmaz a DDR inicializálásához és számos rendszerregisztert az SoC. Tartalom reg_info fényképezőgép modelltől függ, és ha nem megfelelő, akkor a kamera nem is tudja betölteni az uboot-ot, hanem a betöltés nagyon korai szakaszában lefagy.

Eleinte, amikor a gyártói támogatás nélkül dolgoztunk, egyszerűen másoltuk ezt a blokkot a fényképezőgép eredeti firmware-éről.

Linux kernel és rootf

A kamerák a chip SDK részét képező Linux kernelt használnak, ezek általában nem a legújabb kernelek a 3.x ágból, így gyakran szembe kell néznünk azzal a ténnyel, hogy a kiegészítő berendezések illesztőprogramjai nem kompatibilisek a használt kernellel. , és vissza kell portolnunk őket a kernel kameráira.

Egy másik probléma a kernel mérete. Ha a FLASH mérete csak 8 MB, akkor minden bájt számít, és a feladatunk az, hogy gondosan letiltsuk az összes nem használt kernelfunkciót, hogy a méretet minimálisra csökkentsük.

A Rootfs egy alapvető fájlrendszer. Magába foglalja busybox, wifi modul illesztőprogramok, szabványos rendszerkönyvtárak készlete, mint pl libld и libc, valamint szoftverünk, amely a LED vezérlési logikáért, a hálózati kapcsolat kezeléséért és a firmware frissítésekért felel.

A gyökér fájlrendszer initramfs-ként kapcsolódik a kernelhez, és a build eredményeként egy fájlt kapunk uImage, amely tartalmazza a rendszermagot és a rootfeket is.

Videó alkalmazás

A firmware legbonyolultabb és erőforrásigényesebb része az alkalmazás, amely video-audio rögzítést, videó kódolást biztosít, képparamétereket konfigurál, videóelemzést valósít meg, például mozgás- vagy hangérzékelőket, vezérli a PTZ-t, és felelős a nap-, ill. éjszakai módok.

Fontos, akár kulcsfontosságú funkció, hogy a videoalkalmazás hogyan kommunikál a felhőbővítménnyel.

A hagyományos megoldásokban, ami olcsó hardveren nem tud működni, a kamerán belüli videót RTSP protokollon keresztül továbbítják – ez pedig óriási többletköltséget jelent: adatmásolás és socketen keresztüli továbbítás, felesleges syscall.

Itt az osztott memória mechanizmust használjuk – a videót nem másoljuk vagy küldjük el a kamera szoftverkomponensei közötti aljzaton keresztül, ezáltal optimálisan és körültekintően használjuk ki a kamera szerény hardveres képességeit.

Frissítse az alrendszert

Külön büszkeség az online firmware-frissítések hibatűrő alrendszere.

Hadd magyarázzam el a problémát. A firmware frissítése technikailag nem atomi művelet, és ha a frissítés közepén áramszünet következik be, akkor a flash memória az „alulírt” új firmware egy részét tartalmazza. Ha nem tesz különleges intézkedéseket, a kamera „téglává” válik, amelyet szervizbe kell vinni.

Ezzel a problémával is foglalkoztunk. Még akkor is, ha a kamera a frissítés alatt ki van kapcsolva, automatikusan és felhasználói beavatkozás nélkül letölti a firmware-t a felhőből és visszaállítja a működést.

Nézzük részletesebben a technikát:

A legsebezhetőbb pont a partíció felülírása a Linux kernellel és a gyökér fájlrendszerrel. Ha ezen összetevők egyike megsérül, a kamera egyáltalán nem indul el az uboot bootloaderen túl, amely nem tudja letölteni a firmware-t a felhőből.

Ez azt jelenti, hogy a frissítési folyamat során bármikor gondoskodnunk kell arról, hogy a kamera működő kernellel és rootfokkal rendelkezzen. Úgy tűnik, hogy a legegyszerűbb megoldás az lenne, ha a kernel két példányát állandóan tárolnánk a flash memóriában, és ha a fő kernel megsérülne, betöltjük a biztonsági másolatból.

Jó megoldás – azonban a rootfs rendszermag körülbelül 3.5 MB-ot foglal el, az állandó biztonsági mentéshez pedig 3.5 MB-ot kell lefoglalnia. A legolcsóbb kamerákban egyszerűen nincs annyi szabad hely a tartalék kernel számára.

Ezért a kernel biztonsági mentéséhez a firmware-frissítés során az alkalmazáspartíciót használjuk.
És a kívánt partíció kiválasztásához a kernellel két parancsot használunk bootm uboot-ban - az elején megpróbáljuk betölteni a fő kernelt, és ha sérült, akkor a biztonsági másolatot.

Ez biztosítja, hogy a kamera bármikor a megfelelő kernellel rendelkezik rootfokkal, és képes legyen elindítani és visszaállítani a firmware-t.

CI/CD rendszer firmware építéséhez és telepítéséhez

A firmware elkészítéséhez a gitlab CI-t használjuk, amely automatikusan elkészíti az összes támogatott kameramodellhez tartozó firmware-t, majd a firmware elkészítése után automatikusan a kameraszoftver-frissítési szolgáltatásba kerül.

A szolgáltatásból a firmware-frissítések a minőségbiztosítási tesztkameráinkba, majd az összes tesztelési szakasz befejezése után a felhasználók kameráiba kerülnek.

Információ biztonság

Nem titok, hogy manapság az információbiztonság a legfontosabb szempont minden IoT-eszközben, beleértve a kamerákat is. A Miraihoz hasonló botnetek barangolnak az interneten, kamerák millióit fertőzve meg szabványos firmware-rel a gyártóktól. A kameragyártók iránti minden tiszteletem mellett nem tudom megjegyezni, hogy a szabványos firmware sok olyan funkciót tartalmaz, amelyek nem szükségesek a felhővel való munkavégzéshez, de számos sebezhetőséget tartalmaz, amelyeket a botnetek kihasználnak.

Emiatt a firmware-ünkben minden nem használt funkció le van tiltva, minden tcp/udp port le van zárva, és a firmware frissítésekor a szoftver digitális aláírását ellenőrzi.

Ezen kívül a firmware rendszeres tesztelésen esik át az információbiztonsági laboratóriumban.

Következtetés

Most firmware-ünket aktívan használják videó megfigyelési projektekben. Talán a legnagyobb közülük az Orosz Föderáció elnökének megválasztásának napján zajló szavazás közvetítése.
A projektben több mint 70 ezer kamera vett részt a firmware-ünkkel, amelyeket hazánkban a szavazóhelyiségeken telepítettek.

Számos bonyolult, helyenként még akkoriban szinte lehetetlen probléma megoldása után természetesen nagy megelégedésben volt részünk mérnökként, de emellett több millió dollárt is megtakarítottunk a kamerák vásárlásán. És ebben az esetben a megtakarítás nem csak szavak és elméleti számítások, hanem egy már lezárult eszközbeszerzési pályázat eredménye. Ennek megfelelően, ha a felhőalapú videó megfigyelésről beszélünk: két megközelítés létezik - stratégiailag támaszkodni az alacsony szintű szakértelemre és fejlesztésre, ami hatalmas megtakarítást eredményez a berendezésen, vagy drága berendezéseket használ, ami, ha konkrétan a fogyasztói jellemzőket nézzük, gyakorlatilag nem. különböznek a hasonló olcsóktól.

Miért fontos stratégiailag a lehető legkorábban dönteni az integrációs megközelítés megválasztásáról? A bővítmények fejlesztése során a fejlesztők bizonyos technológiákra (könyvtárak, protokollok, szabványok) támaszkodnak. És ha egy technológiai készletet csak a drága berendezésekhez választanak ki, akkor a jövőben az olcsó kamerákra való váltás kísérlete valószínűleg legalább őrülten hosszú ideig tart, vagy akár meghiúsul, és visszatér a drága berendezésekhez.

Forrás: will.com