Saluton ĉiuj!

Verŝajne ne estas sekreto, ke nubaj videogvatado servoj lastatempe akiris popularecon. Kaj estas klare, kial tio okazas, video estas "peza" enhavo, kies stokado postulas infrastrukturon kaj grandajn kvantojn da disko-stokado. Uzi surlokan videogvatsistemon postulas financon por funkcii kaj subteni, kaj por organizo uzanta centojn da gvatkameraoj kaj por individua uzanto kun pluraj fotiloj.

Nubaj videogvatsistemoj solvas ĉi tiun problemon provizante klientojn per ekzistanta videostokado kaj prilabora infrastrukturo. Nuba videogvatkliento simple bezonas konekti la fotilon al la Interreto kaj ligi ĝin al sia nuba konto.

Estas pluraj teknologiaj manieroj konekti fotilojn al la nubo. Sendube, la plej oportuna kaj plej malmultekosta metodo estas, ke la fotilo rekte konektas kaj funkcias kun la nubo, sen partopreno de pliaj ekipaĵoj kiel servilo aŭ registrilo.

Por fari tion, necesas ke programaro-modulo laboranta kun la nubo estu instalita sur la fotilo. Tamen, se ni parolas pri malmultekostaj fotiloj, tiam ili havas tre limigitajn aparatajn rimedojn, kiuj estas preskaŭ 100% okupataj de la denaska firmvaro de la fotila vendisto, kaj ne estas necesaj rimedoj por la nuba kromaĵo. Programistoj de ivideon dediĉis ĉi tiun problemon artikolo, kio klarigas kial ili ne povas instali la kromprogramon sur malmultekostaj fotiloj. Kiel rezulto, la minimuma prezo de la fotilo estas 5000 rubloj ($ 80 dolaroj) kaj milionoj da mono elspezitaj por ekipaĵo.

Ni sukcese solvis ĉi tiun problemon. Se vi interesiĝas pri kiel - bonvenon al la tranĉo

Iom da historio

En 2016, ni komencis evoluigi nuban videogvatadplatformon por Rostelecom.

Koncerne al fotilprogramaro, en la unua etapo ni sekvis la "norman" vojon por tiaj taskoj: ni evoluigis nian propran kromprogramon, kiu estas instalita en la norma firmvaro de la fotilo de la vendisto kaj funkcias kun nia nubo. Tamen, indas noti, ke dum la dezajno ni uzis la plej malpezajn kaj efikajn solvojn (ekzemple, simpla C-efektivigo de protobuf, libev, mbedtls kaj tute forlasitaj oportunaj sed pezaj bibliotekoj kiel boost)

Nuntempe, ne ekzistas universalaj integrigaj solvoj sur la IP-fotila merkato: ĉiu vendisto havas sian propran manieron instali la kromprogramon, sian propran aron de API-oj por funkciigado de la firmvaro kaj unikan ĝisdatigmekanismon.

Ĉi tio signifas, ke por ĉiu fotila vendisto necesas individue evoluigi ampleksan tavolon de integriga programaro. Kaj en la momento de komenci disvolviĝon, estas konsilinde labori nur kun 1 vendisto por koncentri la klopodojn de la teamo por disvolvi la logikon por labori kun la nubo.

La unua vendisto elektita estis Hikvision, unu el la mondaj gvidantoj en la fotilmerkato, disponigante bone dokumentitan API kaj kompetentan inĝenieran teknikan subtenon.

Ni lanĉis nian unuan pilotprojekton, nuba videogvatado Video Comfort, uzante Hikvision-fotilojn.

Preskaŭ tuj post la lanĉo, niaj uzantoj komencis demandi demandojn pri la ebleco konekti pli malmultekostajn fotilojn de aliaj fabrikantoj al la servo.

Mi malakceptis la eblon efektivigi integrigan tavolon por ĉiu vendisto preskaŭ tuj - ĉar ĝi estas malbone skalebla kaj trudas seriozajn teknikajn postulojn al la fotila aparataro. La kosto de fotilo, kiu plenumas ĉi tiujn enigpostulojn: ~60-70$

Tial mi decidis fosi pli profunde - fari mian propran firmvaron por fotiloj de iu ajn vendisto. Ĉi tiu aliro signife reduktas la postulojn por fotila aparataro rimedoj - ĉar La tavolo por labori kun la nubo estas multe pli efike integrita kun la videoapliko, kaj ne estas nenecesa neuzata graso en la firmvaro.

Kaj kio gravas estas, ke kiam oni laboras kun la fotilo je malalta nivelo, eblas uzi aparataron AES, kiu ĉifras datumojn sen krei plian ŝarĝon sur la malalta potenco CPU.

En tiu momento ni havis nenion. Nenio ajn.

Preskaŭ ĉiuj vendistoj ne estis pretaj labori kun ni sur tiel malalta nivelo. Ne ekzistas informoj pri cirkvitodezajno kaj komponantoj, ne ekzistas oficiala SDK de pecetaroj kaj sensildokumentado.
Ankaŭ ne ekzistas teknika subteno.

Ĉiuj demandoj devis esti responditaj per inversa inĝenierado - provo kaj eraro. Sed ni sukcesis.

La unuaj fotilaj modeloj, pri kiuj ni testis, estis fotiloj Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link kaj pluraj tre malmultekostaj sennomaj ĉinaj fotiloj.

Tekniko

Fotiloj bazitaj sur Hisilicon 3518E pecetaro. La aparataj karakterizaĵoj de la fotiloj estas kiel sekvas:

Xiaomi Yi Formikoj
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensilo
ov9732 (720p)
ov9712 (720p)

ethernet
-
+

MicroSD
+
+

mikrofono
+
+

Parolanto
+
+

IRLed
+
+

IRCut
+
+

Ni komencis kun ili.

Ni nuntempe subtenas Hisilicon 3516/3518 pecetarojn, same kiel Ambarella S2L/S2LM. Estas dekoj da fotilmodeloj.

Firmware-konsisto

submarŝipo

uboot estas la ekŝargilo, ĝi startas unue post ekŝalto, pravigas la aparataron kaj ŝargas la linuksan kernon.

La fotila ŝarĝa skripto estas sufiĉe bagatela:

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

Unu el la trajtoj estas, ke ĝi nomiĝas dufoje bootm, pli pri tio iom poste, kiam ni alvenos al la ĝisdatiga subsistemo.

Atentu la linion mem=38M. Jes, jes, ĉi tio ne estas tajperaro - la Linukso-kerno kaj ĉiuj, ĉiuj, ĉiuj aplikaĵoj havas aliron al nur 38 megabajtoj da RAM.

Ankaŭ apud uboot estas speciala bloko nomita reg_info, kiu enhavas malaltnivelan skripton por pravalorigi DDR kaj kelkajn sistemajn registrojn de la SoC. Enhavo reg_info dependas de la fotila modelo, kaj se ĝi ne estas ĝusta, la fotilo eĉ ne povos ŝargi uboot, sed frostiĝos en la tre frua stadio de ŝarĝo.

Komence, kiam ni laboris sen vendisto-subteno, ni simple kopiis ĉi tiun blokon de la originala fotila firmvaro.

Linukso-kerno kaj radikoj

La fotiloj uzas la Linuksan kernon, kiu estas parto de la SDK de la peceto; kutime ĉi tiuj ne estas la plej novaj kernoj de la branĉo 3.x, do ni ofte devas trakti la fakton, ke ŝoforoj por pliaj ekipaĵoj ne kongruas kun la uzata kerno. , kaj ni devas malantaŭenporti ilin al la kernaj fotiloj.

Alia afero estas la grandeco de la kerno. Kiam la FLASH-grandeco estas nur 8MB, tiam ĉiu bajto validas kaj nia tasko estas zorge malŝalti ĉiujn neuzatajn kernfunkciojn por redukti la grandecon al minimumo.

Rootfs estas baza dosiersistemo. Ĝi inkluzivas busybox, wifi-modulŝoforoj, aro de normaj sistembibliotekoj, kiel ekzemple libld и libc, same kiel nia programaro, kiu respondecas pri la LED-kontrollogiko, administrado de retkonekto kaj firmware-ĝisdatigoj.

La radika dosiersistemo estas konektita al la kerno kiel initramfs kaj kiel rezulto de la konstruo ni ricevas unu dosieron uImage, kiu enhavas kaj la kernon kaj radikojn.

Video-apliko

La plej kompleksa kaj rimeda parto de la firmvaro estas la aplikaĵo, kiu provizas video-aŭdian kapton, videokodigon, agordas bildajn parametrojn, efektivigas video-analitikojn, ekzemple, moviĝajn aŭ sondetektilojn, kontrolas PTZ kaj respondecas pri ŝanĝado de tago kaj noktaj reĝimoj.

Grava, mi eĉ dirus ŝlosila, trajto estas kiel la videoapliko interagas kun la nuba kromaĵo.

En tradiciaj solvoj 'vendisto-firmvaro + nuba kromaĵo', kiuj ne povas funkcii sur malmultekosta aparataro, video ene de la fotilo estas transdonita per la RTSP-protokolo - kaj ĉi tio estas grandega ŝarĝo: kopiado kaj transsendo de datumoj per ingo, nenecesaj syscalls.

Ĉi tie ni uzas la komunan memormekanismon - la video ne estas kopiita aŭ sendita per ingo inter la fotilprogramaraj komponantoj, tiel optimume kaj zorge uzante la modestajn aparatajn kapablojn de la fotilo.

Ĝisdatigu subsistemon

Punkto de speciala fiero estas la mistolerema subsistemo por interretaj firmvaraj ĝisdatigoj.

Lasu min klarigi la problemon. Ĝisdatigo de la firmvaro estas teknike ne atoma operacio, kaj se elektropaneo okazas meze de la ĝisdatigo, tiam la fulmmemoro enhavos parton de la "subskribita" nova firmvaro. Se vi ne prenas specialajn mezurojn, la fotilo tiam fariĝos "briko", kiu devas esti prenita al servocentro.

Ni ankaŭ traktis ĉi tiun problemon. Eĉ se la fotilo estas malŝaltita dum la ĝisdatigo, ĝi aŭtomate kaj sen interveno de la uzanto elŝutos la firmware el la nubo kaj restarigos operacion.

Ni rigardu la teknikon pli detale:

La plej vundebla punkto estas anstataŭi la subdiskon per la Linukso-kerno kaj radika dosiersistemo. Se unu el ĉi tiuj komponantoj estas difektita, la fotilo tute ne ekŝargos preter la uboot-ŝargilo, kiu ne povas elŝuti firmware el la nubo.

Ĉi tio signifas, ke ni devas certigi, ke la fotilo havas funkciantajn kernon kaj rootfs iam ajn dum la ĝisdatiga procezo. Ŝajnus, ke la plej simpla solvo estus konstante stoki du kopiojn de la kerno kun rootfs sur fulmmemoro kaj, se la ĉefa kerno estas difektita, ŝargi ĝin el la rezerva kopio.

Bona solvo - tamen, la kerno kun rootfs okupas ĉirkaŭ 3.5MB kaj por konstanta sekurkopio vi devas asigni 3.5MB. La plej malmultekostaj fotiloj simple ne havas tiom da libera spaco por rezerva kerno.

Tial, por sekurkopii la kernon dum firmvara ĝisdatigo, ni uzas la aplikaĵdiskon.
Kaj por elekti la deziratan subdiskon kun la kerno, du komandoj estas uzataj bootm en uboot - komence ni provas ŝargi la ĉefan kernon kaj se ĝi estas difektita, tiam la rezerva.

Ĉi tio certigas, ke iam ajn la fotilo havos la ĝustan kernon kun rootfs, kaj ĝi povos ekbruligi kaj restarigi la firmware.

CI/KD-sistemo por konstruado kaj deplojado de firmvaro

Por konstrui firmware, ni uzas gitlab CI, kiu aŭtomate konstruas firmvaro por ĉiuj subtenataj fotilmodeloj, kaj post konstruado de la firmvaro, ĝi estas aŭtomate deplojita al la fotila programaro ĝisdatiga servo.

De la servo, firmware ĝisdatigoj estas liveritaj al niaj QA-testfotiloj, kaj post kompletigo de ĉiuj testaj etapoj, al la fotiloj de uzantoj.

Informa Sekureco

Ne estas sekreto, ke nuntempe informa sekureco estas la plej grava aspekto de iu ajn IoT-aparato, inkluzive de fotiloj. Botnets kiel Mirai travagas la Interreton, infektante milionojn da fotiloj per norma firmvaro de vendistoj. Kun ĉia respekto al fotilaj vendistoj, mi ne povas ne rimarki, ke norma firmvaro enhavas multajn funkciojn, kiuj ne estas bezonataj por labori kun la nubo, sed enhavas multajn vundeblecojn, kiujn botnetoj utiligas.

Sekve, ĉiuj neuzataj funkcioj en nia firmvaro estas malŝaltita, ĉiuj tcp/udp-havenoj estas fermitaj, kaj kiam ĝi ĝisdatigas la firmware, la cifereca subskribo de la programaro estas kontrolita.

Kaj krom tio, la firmvaro spertas regulajn provojn en la laboratorio pri informa sekureco.

konkludo

Nun nia firmvaro estas aktive uzata en videogvatado projektoj. Eble la plej granda el ili estas la elsendo de voĉdonado en la tago de la elekto de la Prezidanto de la Rusa Federacio.
La projekto implikis pli ol 70 mil fotilojn kun nia firmware, kiuj estis instalitaj ĉe balotejoj en nia lando.

Solvinte kelkajn kompleksajn, kaj kelkloke, eĉ tiam preskaŭ neeblajn problemojn, ni kompreneble ricevis grandan kontenton kiel inĝenieroj, sed krom tio ni ankaŭ ŝparis milionojn da dolaroj por aĉeto de fotiloj. Kaj en ĉi tiu kazo, ŝparadoj ne estas nur vortoj kaj teoriaj kalkuloj, sed la rezultoj de jam finita oferto por aĉeto de ekipaĵo. Sekve, se ni parolas pri nuba videogvatado: estas du aliroj - strategie fidi malaltnivelan kompetentecon kaj evoluon, rezultigante grandegajn ŝparojn pri ekipaĵo, aŭ uzu multekostajn ekipaĵojn, kiuj, se vi specife rigardas konsumantkarakterizaĵojn, preskaŭ ne estas. malsamaj de similaj malmultekostaj.

Kial estas strategie grave decidi kiel eble plej frue pri la elekto de integriĝa aliro? Dum disvolvado de kromaĵo, programistoj dependas de certaj teknologioj (bibliotekoj, protokoloj, normoj). Kaj se aro da teknologioj estas elektita nur por multekostaj ekipaĵoj, tiam estonte provo ŝanĝi al malmultekostaj fotiloj plej verŝajne daŭros freneze longan tempon aŭ eĉ malsukcesos kaj reveno al multekostaj ekipaĵoj okazos.

fonto: www.habr.com