Halló allir!

Það er líklega ekkert leyndarmál að vídeóeftirlitsþjónusta í skýi hefur notið vinsælda undanfarið. Og það er ljóst hvers vegna þetta gerist, myndband er „þungt“ efni, geymsla þess krefst innviða og mikið magn af diskgeymslu. Notkun myndbandseftirlitskerfis á staðnum krefst fjármuna til að reka og styðja, bæði fyrir fyrirtæki sem notar hundruð eftirlitsmyndavéla og fyrir einstakan notanda með nokkrar myndavélar.

Skýmyndaeftirlitskerfi leysa þetta vandamál með því að veita viðskiptavinum núverandi myndbandsgeymslu og vinnsluinnviði. Myndbandseftirlitsmaður í skýi þarf einfaldlega að tengja myndavélina við internetið og tengja hana við skýjareikninginn sinn.

Það eru nokkrar tæknilegar leiðir til að tengja myndavélar við skýið. Án efa er þægilegasta og ódýrasta aðferðin sú að myndavélin tengist beint og vinnur með skýinu, án þátttöku viðbótarbúnaðar eins og netþjóns eða upptökutækis.

Til að gera þetta er nauðsynlegt að hugbúnaðareining sem vinnur með skýinu sé sett upp á myndavélinni. Hins vegar, ef við tölum um ódýrar myndavélar, þá eru þær með mjög takmarkaðar vélbúnaðarauðlindir, sem eru næstum 100% uppteknar af innfæddum vélbúnaði myndavélaframleiðandans, og það eru engin úrræði nauðsynleg fyrir skýviðbótina. Hönnuðir frá ivideon helguðu þessu vandamáli grein, sem útskýrir hvers vegna þeir geta ekki sett viðbótina upp á ódýrar myndavélar. Fyrir vikið er lágmarksverð myndavélarinnar 5000 rúblur ($80 dollarar) og milljónum peninga varið í búnað.

Við höfum leyst þetta vandamál með góðum árangri. Ef þú hefur áhuga á hvernig - velkomin í klippinguna

Smá saga

Árið 2016 byrjuðum við að þróa skýmyndaeftirlitsvettvang fyrir Rostelecom.

Hvað varðar myndavélarhugbúnað, á fyrsta stigi fylgdum við „stöðluðu“ slóðinni fyrir slík verkefni: við þróuðum okkar eigin viðbót, sem er sett upp í stöðluðum vélbúnaði myndavélar seljanda og vinnur með skýinu okkar. Hins vegar er rétt að taka fram að við hönnunina notuðum við léttustu og skilvirkustu lausnirnar (til dæmis venjuleg C útfærsla á protobuf, libev, mbedtls og algjörlega yfirgefin þægileg en þung bókasöfn eins og boost)

Eins og er, eru engar alhliða samþættingarlausnir á IP myndavélamarkaðnum: hver söluaðili hefur sína eigin leið til að setja upp viðbótina, sitt eigið sett af API til að stjórna fastbúnaðinum og einstakt uppfærslukerfi.

Þetta þýðir að fyrir hvern myndavélaframleiðanda er nauðsynlegt að þróa fyrir sig yfirgripsmikið lag af samþættingarhugbúnaði. Og á þeim tíma sem þróun er hafin er ráðlegt að vinna aðeins með 1 söluaðila til að einbeita viðleitni liðsins að því að þróa rökfræði fyrir að vinna með skýið.

Fyrsti söluaðilinn sem valinn var var Hikvision, einn af leiðtogum heims á myndavélamarkaði, sem útvegaði vel skjalfest API og hæfa verkfræðiaðstoð.

Við settum af stað fyrsta tilraunaverkefnið okkar, skýmyndaeftirlit Video Comfort, með Hikvision myndavélum.

Nánast strax eftir kynningu fóru notendur okkar að spyrja spurninga um möguleikann á að tengja ódýrari myndavélar frá öðrum framleiðendum við þjónustuna.

Ég hafnaði möguleikanum á að innleiða samþættingarlag fyrir hvern söluaðila nánast samstundis - þar sem það er illa skalanlegt og setur alvarlegar tæknilegar kröfur á vélbúnað myndavélarinnar. Kostnaður við myndavél sem uppfyllir þessar inntakskröfur: ~60-70$

Þess vegna ákvað ég að kafa dýpra - að búa til eigin vélbúnaðar fyrir myndavélar frá hvaða söluaðila sem er. Þessi nálgun dregur verulega úr kröfum um vélbúnað myndavélar - vegna þess Lagið til að vinna með skýið er miklu skilvirkara samþætt við myndbandsforritið og það er engin óþarfa ónotuð fita í vélbúnaðinum.

Og það sem er mikilvægt er að þegar unnið er með myndavélina á lágu stigi er hægt að nota vélbúnað AES, sem dulkóðar gögn án þess að skapa aukið álag á örgjörva sem er lítill.

Á þeirri stundu áttum við alls ekkert. Ekki neitt.

Næstum allir söluaðilar voru ekki tilbúnir til að vinna með okkur á svo lágu stigi. Það eru engar upplýsingar um rafrásina og íhlutina, það er engin opinber SDK af flísum og skynjaraskjölum.
Það er heldur engin tæknileg aðstoð.

Öllum spurningum þurfti að svara með öfugum verkfræði—tilraun og villa. En okkur tókst.

Fyrstu myndavélagerðirnar sem við prófuðum á voru Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link myndavélar og nokkrar ofuródýrar nafnlausar kínverskar myndavélar.

Technique

Myndavélar byggðar á Hisilicon 3518E flís. Vélbúnaðareiginleikar myndavélanna eru sem hér segir:

Xiaomi Yi maurar
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Hljóðnemi
+
+

Ræðumaður
+
+

IRLed
+
+

IRCut
+
+

Við byrjuðum á þeim.

Við styðjum nú Hisilicon 3516/3518 flísasett, sem og Ambarella S2L/S2LM. Það eru heilmikið af myndavélamódelum.

Samsetning vélbúnaðar

uboot

uboot er ræsiforritið, það ræsir fyrst eftir að kveikt er á honum, frumstillir vélbúnaðinn og hleður linux kjarnanum.

Hleðsluforrit myndavélarinnar er frekar léttvægt:

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

Einn af eiginleikum er að það er kallað tvisvar bootm, meira um þetta aðeins síðar, þegar við komum að uppfærsluundirkerfinu.

Gefðu gaum að línunni mem=38M. Já, já, þetta er ekki innsláttarvilla - Linux kjarninn og allt, öll, öll forrit hafa aðgang að aðeins 38 megabæti af vinnsluminni.

Einnig við hlið uboot er sérstakur blokk sem heitir reg_info, sem inniheldur lág-stigs forskrift til að frumstilla DDR og fjölda kerfisskráa SoC. Efni reg_info fer eftir gerð myndavélarinnar og ef það er ekki rétt mun myndavélin ekki einu sinni geta hlaðið uboot, heldur frjósar hún mjög snemma í hleðslu.

Í fyrstu, þegar við unnum án stuðnings söluaðila, afrituðum við einfaldlega þennan blokk úr upprunalegu vélbúnaðar myndavélarinnar.

Linux kjarna og rootfs

Myndavélarnar nota Linux kjarnann, sem er hluti af SDK flísarinnar, venjulega eru þetta ekki nýjustu kjarnanir úr 3.x greininni, þannig að við þurfum oft að glíma við þá staðreynd að reklar fyrir viðbótarbúnað eru ekki samhæfðir kjarnanum sem notaður er. , og við verðum að flytja þær aftur í kjarnamyndavélarnar.

Annað mál er stærð kjarnans. Þegar FLASH stærðin er aðeins 8MB, þá telur hvert bæti og verkefni okkar er að slökkva vandlega á öllum ónotuðum kjarnaaðgerðum til að minnka stærðina í lágmarki.

Rootfs er grunnskráakerfi. Það innifelur busybox, WiFi mát rekla, sett af stöðluðum kerfissöfnum, svo sem libld и libc, auk hugbúnaðar okkar, sem er ábyrgur fyrir LED stjórnunarrökfræði, nettengingarstjórnun og fastbúnaðaruppfærslur.

Rótarskráarkerfið er tengt kjarnanum sem initramfs og sem afleiðing af byggingunni fáum við eina skrá uImage, sem inniheldur bæði kjarnann og rootfs.

Myndbandsforrit

Flóknasti og auðlindafrekasti hluti vélbúnaðarins er forritið, sem veitir myndbands-hljóðtöku, myndkóðun, stillir myndbreytur, útfærir myndbandsgreiningar, til dæmis hreyfi- eða hljóðskynjara, stjórnar PTZ og ber ábyrgð á að skipta um dag og næturstillingar.

Mikilvægur, ég myndi jafnvel segja lykilatriði, er hvernig myndbandsforritið hefur samskipti við skýjaviðbótina.

Í hefðbundnum lausnum, „fasteignabúnaði + skýjaviðbót“, sem getur ekki virkað á ódýrum vélbúnaði, er myndband inni í myndavélinni sent í gegnum RTSP samskiptareglur - og þetta er gríðarlegur kostnaður: afrita og senda gögn í gegnum fals, óþarfa kerfiskerfi.

Hér notum við samnýtt minni vélbúnaðinn - myndbandið er ekki afritað eða sent í gegnum innstunguna á milli hugbúnaðarhluta myndavélarinnar og notar þannig hóflega vélbúnaðargetu myndavélarinnar sem best og vandlega.

Uppfæra undirkerfi

Sérstakt stolt er bilunarþolið undirkerfi fyrir fastbúnaðaruppfærslur á netinu.

Leyfðu mér að útskýra vandamálið. Uppfærsla fastbúnaðarins er tæknilega séð ekki atómaðgerð og ef rafmagnsbilun verður í miðri uppfærslu, þá mun flassminnið innihalda hluta af „undirskrifuðu“ nýja fastbúnaðinum. Ef þú gerir ekki sérstakar ráðstafanir verður myndavélin að „múrsteinn“ sem þarf að fara með á þjónustumiðstöð.

Við höfum líka tekist á við þetta vandamál. Jafnvel þótt slökkt sé á myndavélinni meðan á uppfærslunni stendur mun hún sjálfkrafa og án afskipta notenda hlaða niður fastbúnaðinum úr skýinu og endurheimta aðgerðina.

Við skulum skoða tæknina nánar:

Viðkvæmasti punkturinn er að skrifa yfir skiptinguna með Linux kjarnanum og rótarskráarkerfinu. Ef einn af þessum hlutum er skemmdur mun myndavélin alls ekki ræsast umfram uboot ræsiforritið, sem getur ekki hlaðið niður fastbúnaði úr skýinu.

Þetta þýðir að við þurfum að tryggja að myndavélin sé með virkan kjarna og rootfs hvenær sem er meðan á uppfærsluferlinu stendur. Svo virðist sem einfaldasta lausnin væri að geyma stöðugt tvö eintök af kjarnanum með rootfs á flassminni og, ef aðalkjarnan er skemmd, hlaða hann úr öryggisafritinu.

Góð lausn - þó tekur kjarninn með rootfs um 3.5MB og fyrir varanlegt öryggisafrit þarf að úthluta 3.5MB. Ódýrustu myndavélarnar hafa einfaldlega ekki svo mikið laust pláss fyrir varakjarna.

Þess vegna, til að taka öryggisafrit af kjarnanum meðan á fastbúnaðaruppfærslu stendur, notum við forritaskiptinguna.
Og til að velja viðeigandi skipting með kjarnanum eru tvær skipanir notaðar bootm í uboot - í upphafi reynum við að hlaða aðalkjarnanum og ef hann er skemmdur, þá öryggisafritið.

Þetta tryggir að myndavélin á hverjum tíma sé með réttan kjarna með rootfs og hún mun geta ræst og endurheimt fastbúnaðinn.

CI/CD kerfi til að byggja upp og dreifa fastbúnaði

Til að smíða fastbúnað notum við gitlab CI, sem byggir sjálfkrafa fastbúnað fyrir allar studdar myndavélagerðir, og eftir að fastbúnaðinn hefur verið byggður er hann sjálfkrafa settur á uppfærsluþjónustu myndavélarhugbúnaðar.

Frá þjónustunni eru vélbúnaðaruppfærslur sendar til QA prófunarmyndavélanna okkar og að loknum öllum prófunarstigum, til myndavéla notenda.

Upplýsingaöryggi

Það er ekkert leyndarmál að nú á dögum er upplýsingaöryggi mikilvægasti þátturinn í hvaða IoT tæki sem er, þar á meðal myndavélar. Botnet eins og Mirai eru á reiki um internetið og smita milljónir myndavéla með venjulegu fastbúnaði frá söluaðilum. Með fullri virðingu fyrir framleiðendum myndavéla get ég ekki annað en tekið eftir því að staðall fastbúnaður inniheldur mikla virkni sem er ekki nauðsynleg til að vinna með skýið, en inniheldur marga veikleika sem botnet nýta sér.

Þess vegna er öll ónotuð virkni í fastbúnaðinum okkar óvirk, öll tcp/udp tengi eru lokuð og við uppfærslu á fastbúnaðinum er athugað með stafræna undirskrift hugbúnaðarins.

Og fyrir utan þetta fer vélbúnaðurinn í gegnum reglulegar prófanir á rannsóknarstofu upplýsingaöryggis.

Ályktun

Nú er fastbúnaður okkar virkur notaður í myndbandseftirlitsverkefnum. Kannski er stærst þeirra útsendingin á atkvæðagreiðslu á kjördegi forseta Rússlands.
Verkefnið fólst í meira en 70 þúsund myndavélum með fastbúnaði okkar, sem settar voru upp á kjörstöðum í okkar landi.

Eftir að hafa leyst ýmis flókin og sums staðar, jafnvel á þeim tíma nánast ómöguleg vandamál, fengum við að sjálfsögðu mikla ánægju sem verkfræðingar, en fyrir utan þetta söfnuðum við milljónum dollara við kaup á myndavélum. Og í þessu tilfelli er sparnaður ekki aðeins orð og fræðilegir útreikningar, heldur niðurstöður þegar lokið útboði á búnaðarkaupum. Í samræmi við það, ef við tölum um vídeóvöktun í skýi: það eru tvær aðferðir - treysta beitt á lág-stigi sérfræðiþekkingu og þróun, sem leiðir til mikils sparnaðar á búnaði, eða notaðu dýran búnað, sem, ef þú lítur sérstaklega á eiginleika neytenda, er nánast engin. öðruvísi en svipaðar ódýrar.

Hvers vegna er stefnumótandi mikilvægt að taka ákvörðun um val á samþættingaraðferð eins fljótt og auðið er? Þegar forritarar þróa viðbót treysta verktaki á ákveðna tækni (söfn, samskiptareglur, staðla). Og ef sett af tækni er aðeins valin fyrir dýran búnað, þá mun tilraun til að skipta yfir í ódýrar myndavélar í framtíðinni að minnsta kosti taka brjálæðislega langan tíma eða jafnvel mistakast og aftur til dýrs búnaðar mun eiga sér stað.

Heimild: www.habr.com