Hello everyone!
Հավանաբար, գաղտնիք չէ, որ ամպային տեսահսկման ծառայությունները վերջերս ժողովրդականություն են վայելում: Եվ պարզ է, թե ինչու է դա տեղի ունենում, տեսանյութը «ծանր» բովանդակություն է, որի պահպանումը պահանջում է ենթակառուցվածք և մեծ քանակությամբ սկավառակի պահեստավորում: Ներքին տեսահսկման համակարգ օգտագործելու համար անհրաժեշտ է միջոցներ գործելու և աջակցելու համար, ինչպես հարյուրավոր տեսահսկման տեսախցիկներ օգտագործող կազմակերպության, այնպես էլ մի քանի տեսախցիկ ունեցող անհատ օգտատիրոջ համար:
Ամպային տեսահսկման համակարգերը լուծում են այս խնդիրը՝ հաճախորդներին տրամադրելով առկա տեսապահպանման և մշակման ենթակառուցվածք: Ամպային տեսահսկման հաճախորդը պարզապես պետք է տեսախցիկը միացնի ինտերնետին և կապի այն իր ամպային հաշվին:
Տեսախցիկները ամպին միացնելու մի քանի տեխնոլոգիական եղանակներ կան։ Անկասկած, ամենահարմար և ամենաէժան մեթոդն այն է, որ տեսախցիկը ուղղակիորեն միանում և աշխատում է ամպի հետ՝ առանց լրացուցիչ սարքավորումների, ինչպիսիք են սերվերը կամ ձայնագրիչը:
Դա անելու համար անհրաժեշտ է, որ տեսախցիկի վրա տեղադրվի ամպի հետ աշխատող ծրագրային մոդուլ։ Այնուամենայնիվ, եթե խոսենք էժան տեսախցիկների մասին, ապա դրանք ունեն շատ սահմանափակ ապարատային ռեսուրսներ, որոնք գրեթե 100%-ով զբաղված են տեսախցիկի վաճառողի հայրենի որոնվածով, և ամպային հավելվածի համար անհրաժեշտ ռեսուրսներ չկան: Այս խնդրին են նվիրված ivideon-ի մշակողները , ինչը բացատրում է, թե ինչու նրանք չեն կարող տեղադրել plugin-ը էժան տեսախցիկների վրա: Արդյունքում տեսախցիկի նվազագույն գինը 5000 ռուբլի է (80 դոլար) և միլիոնավոր գումարներ ծախսվել սարքավորումների վրա։
Մենք հաջողությամբ լուծել ենք այս խնդիրը։ Եթե դուք հետաքրքրված եք, թե ինչպես - բարի գալուստ կտրվածք
Մի քիչ պատմություն
2016 թվականին մենք սկսեցինք մշակել Ռոստելեկոմի համար ամպային տեսահսկման հարթակ։
Տեսախցիկի ծրագրային ապահովման առումով, առաջին փուլում մենք գնացինք նման առաջադրանքների «ստանդարտ» ճանապարհով. մենք մշակեցինք մեր սեփական փլագինը, որը տեղադրված է վաճառողի տեսախցիկի ստանդարտ որոնվածում և աշխատում է մեր ամպի հետ: Այնուամենայնիվ, հարկ է նշել, որ նախագծման ընթացքում մենք օգտագործել ենք ամենաթեթև և արդյունավետ լուծումները (օրինակ, պարզ C-ի իրականացումը protobuf, libev, mbedtls և ամբողջովին լքված հարմար, բայց ծանր գրադարաններ, ինչպիսիք են boost-ը):
Ներկայում IP տեսախցիկների շուկայում համընդհանուր ինտեգրացիոն լուծումներ չկան. յուրաքանչյուր վաճառող ունի plugin-ի տեղադրման իր ձևը, որոնվածը գործարկելու համար API-ների իր հավաքածուն և թարմացման յուրահատուկ մեխանիզմ:
Սա նշանակում է, որ յուրաքանչյուր տեսախցիկի վաճառողի համար անհրաժեշտ է անհատապես մշակել ինտեգրացիոն ծրագրային ապահովման համապարփակ շերտ: Իսկ մշակումը սկսելու պահին նպատակահարմար է աշխատել միայն 1 վաճառողի հետ՝ թիմի ջանքերը կենտրոնացնելու ամպի հետ աշխատելու տրամաբանությունը զարգացնելու համար։
Ընտրված առաջին վաճառողը Hikvision-ն էր՝ տեսախցիկների շուկայում համաշխարհային առաջատարներից մեկը, որն ապահովում էր լավ փաստագրված API և իրավասու ինժեներական տեխնիկական աջակցություն:
Մենք գործարկեցինք մեր առաջին փորձնական նախագիծը՝ ամպային տեսահսկման Video Comfort՝ օգտագործելով Hikvision տեսախցիկներ:
Գործարկումից գրեթե անմիջապես հետո մեր օգտատերերը սկսեցին հարցեր տալ ծառայությանն այլ արտադրողների ավելի էժան տեսախցիկներ միացնելու հնարավորության մասին:
Ես մերժեցի յուրաքանչյուր վաճառողի համար ինտեգրացիոն շերտի ներդրման տարբերակը գրեթե անմիջապես, քանի որ այն վատ մասշտաբելի է և լուրջ տեխնիկական պահանջներ է դնում տեսախցիկի սարքավորման վրա: Տեսախցիկի արժեքը, որը համապատասխանում է այս մուտքային պահանջներին՝ ~60-70$
Հետևաբար, ես որոշեցի ավելի խորանալ՝ ցանկացած վաճառողից տեսախցիկների համար իմ որոնվածը պատրաստել: Այս մոտեցումը զգալիորեն նվազեցնում է տեսախցիկի ապարատային ռեսուրսների պահանջները, քանի որ Ամպի հետ աշխատելու շերտը շատ ավելի արդյունավետ կերպով ինտեգրված է վիդեո հավելվածի հետ, և որոնվածում ավելորդ չօգտագործված ճարպ չկա:
Եվ ամենակարևորն այն է, որ տեսախցիկի հետ ցածր մակարդակով աշխատելիս հնարավոր է օգտագործել ապարատային AES, որը կոդավորում է տվյալները՝ առանց լրացուցիչ բեռ ստեղծելու ցածր էներգիայի պրոցեսորի վրա:
Այդ պահին մենք ընդհանրապես ոչինչ չունեինք։ Ընդհանրապես ոչինչ։
Գրեթե բոլոր վաճառողները պատրաստ չէին մեզ հետ աշխատել այդքան ցածր մակարդակով: Չկա տեղեկատվություն սխեմաների և բաղադրիչների մասին, չկա չիպսեթների և սենսորների փաստաթղթերի պաշտոնական SDK:
Չկա նաև տեխնիկական աջակցություն։
Բոլոր հարցերին պետք էր պատասխանել հակադարձ ճարտարագիտության՝ փորձության և սխալի միջոցով: Բայց մենք կարողացանք։
Առաջին տեսախցիկների մոդելները, որոնք մենք փորձարկեցինք, Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link տեսախցիկներն էին և մի քանի ծայրահեղ էժան անանուն չինական տեսախցիկներ:
Տեխնիկա
Տեսախցիկներ՝ հիմնված Hisilicon 3518E չիպսեթի վրա: Տեսախցիկների ապարատային բնութագրերը հետևյալն են.
Xiaomi Yi Ants
Noname
SoC
Hisilicon 3518E
Hisilicon 3518E
RAM
64MB
64MB
FLASH
16MB
8MB
WiFi
mt7601/bcm43143
-
ցուցիչ
ov9732 (720p)
ov9712 (720p)
Ethernet
-
+
MicroSD- ն
+
+
միկրոֆոն
+
+
Նախագահ
+
+
IRLed
+
+
IRCut
+
+
Մենք սկսեցինք նրանցից:
Ներկայումս մենք աջակցում ենք Hisilicon 3516/3518 չիպսեթներին, ինչպես նաև Ambarella S2L/S2LM-ին: Կան տասնյակ տեսախցիկների մոդելներ:
Որոնվածի կազմը
սուզանավ
uboot-ը boot loader-ն է, այն միացնելուց հետո սկզբում բեռնվում է, սկզբնավորում է սարքաշարը և բեռնում Linux միջուկը:
Տեսախցիկի բեռնման սցենարը բավականին աննշան է.
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Հատկանիշներից մեկն այն է, որ այն կոչվում է կրկնակի bootm, այս մասին ավելին մի փոքր ուշ, երբ հասնենք թարմացման ենթահամակարգին։
Ուշադրություն դարձրեք գծին mem=38M. Այո, այո, սա տառասխալ չէ. Linux միջուկը և բոլոր, բոլոր, բոլոր հավելվածները մուտք ունեն ընդամենը 38 մեգաբայթ RAM:
Նաև uboot-ի կողքին կա հատուկ բլոկ, որը կոչվում է reg_info, որը պարունակում է DDR-ի սկզբնավորման համար ցածր մակարդակի սկրիպտ և SoC-ի մի շարք համակարգային ռեգիստրներ։ Բովանդակություն reg_info կախված է տեսախցիկի մոդելից, և եթե այն ճիշտ չէ, տեսախցիկը նույնիսկ չի կարողանա բեռնել uboot-ը, այլ կսառչի բեռնման շատ վաղ փուլում:
Սկզբում, երբ մենք աշխատում էինք առանց վաճառողի աջակցության, մենք պարզապես պատճենեցինք այս բլոկը ֆոտոխցիկի բնօրինակ որոնվածից:
Linux միջուկ և rootfs
Տեսախցիկները օգտագործում են Linux միջուկը, որը չիպի SDK-ի մի մասն է, սովորաբար դրանք 3.x ճյուղի վերջին միջուկները չեն, ուստի մենք հաճախ ստիպված ենք լինում գործ ունենալ այն փաստի հետ, որ լրացուցիչ սարքավորումների դրայվերները համատեղելի չեն օգտագործվող միջուկի հետ։ և մենք պետք է դրանք տեղափոխենք միջուկի տեսախցիկներ:
Մեկ այլ խնդիր միջուկի չափն է: Երբ FLASH-ի չափն ընդամենը 8 ՄԲ է, ապա յուրաքանչյուր բայթը հաշվում է, և մեր խնդիրն է զգուշորեն անջատել բոլոր չօգտագործված միջուկի գործառույթները՝ չափը նվազագույնի հասցնելու համար:
Rootfs-ը հիմնական ֆայլային համակարգ է: Այն ներառում է busybox, wifi մոդուլի վարորդներ, ստանդարտ համակարգի գրադարանների մի շարք, ինչպիսիք են libld и libc, ինչպես նաև մեր ծրագրաշարը, որը պատասխանատու է LED կառավարման տրամաբանության, ցանցային կապի կառավարման և որոնվածի թարմացումների համար:
Արմատային ֆայլային համակարգը միացված է միջուկին որպես initramfs և կառուցման արդյունքում ստանում ենք մեկ ֆայլ uImage, որը պարունակում է և՛ միջուկը, և՛ rootfs:
Վիդեո հավելված
Որոնվածի ամենաբարդ և ռեսուրսներով ինտենսիվ մասը հավելվածն է, որն ապահովում է վիդեո-աուդիո նկարահանում, վիդեո կոդավորում, կարգավորում է նկարի պարամետրերը, իրականացնում է վիդեո վերլուծություն, օրինակ՝ շարժման կամ ձայնի դետեկտորներ, վերահսկում է PTZ-ը և պատասխանատու է օրվա փոխարկման համար և գիշերային ռեժիմներ.
Կարևոր, ես նույնիսկ կասեի հիմնական հատկանիշն այն է, թե ինչպես է վիդեո հավելվածը փոխազդում ամպային հավելվածի հետ:
Ավանդական լուծումներում «վաճառողի որոնվածը + ամպային պլագին», որը չի կարող աշխատել էժան ապարատների վրա, տեսախցիկի ներսում տեսանյութը փոխանցվում է RTSP արձանագրության միջոցով, և սա հսկայական ծախս է.
Այստեղ մենք օգտագործում ենք ընդհանուր հիշողության մեխանիզմը. տեսանյութը չի պատճենվում կամ ուղարկվում վարդակից խցիկի ծրագրային ապահովման բաղադրիչների միջև, դրանով իսկ օպտիմալ և ուշադիր օգտագործելով խցիկի համեստ ապարատային հնարավորությունները:
Թարմացնել ենթահամակարգը
Առանձնահատուկ հպարտության կետը անսարքության հանդուրժող ենթահամակարգն է առցանց որոնվածի թարմացումների համար:
Բացատրեմ խնդիրը։ Որոնվածը թարմացնելը տեխնիկապես ատոմային գործողություն չէ, և եթե թարմացման կեսին հոսանքի խափանում է տեղի ունենում, ապա ֆլեշ հիշողությունը կպարունակի «թերի գրված» նոր որոնվածի մի մասը: Եթե հատուկ միջոցներ չձեռնարկեք, տեսախցիկը կդառնա «աղյուս», որը պետք է տեղափոխվի սպասարկման կենտրոն:
Մենք այս խնդրին էլ ենք առնչվել։ Նույնիսկ եթե թարմացման ընթացքում տեսախցիկը անջատված է, այն ավտոմատ կերպով և առանց օգտագործողի միջամտության կներբեռնի որոնվածը ամպից և կվերականգնի աշխատանքը:
Դիտարկենք տեխնիկան ավելի մանրամասն.
Ամենախոցելի կետը բաժանման վերագրանցումն է Linux միջուկով և արմատային ֆայլային համակարգով: Եթե այս բաղադրիչներից մեկը վնասված է, տեսախցիկը ընդհանրապես չի բեռնվի uboot bootloader-ից այն կողմ, որը չի կարող ներբեռնել որոնվածը ամպից:
Սա նշանակում է, որ մենք պետք է ապահովենք, որ տեսախցիկը թարմացման գործընթացում ցանկացած պահի ունենա աշխատող միջուկ և rootfs: Թվում է, թե ամենապարզ լուծումը կլինի միջուկի երկու օրինակները rootf-ներով անընդհատ պահել ֆլեշ հիշողության վրա և, եթե հիմնական միջուկը վնասված է, բեռնել այն կրկնօրինակից:
Լավ լուծում. այնուամենայնիվ, rootf-ով միջուկը զբաղեցնում է մոտ 3.5 ՄԲ, իսկ մշտական պահուստավորման համար անհրաժեշտ է հատկացնել 3.5 ՄԲ: Ամենաէժան տեսախցիկները պարզապես չունեն այդքան ազատ տարածք պահեստային միջուկի համար:
Հետևաբար, որոնվածը թարմացնելու ժամանակ միջուկը կրկնօրինակելու համար մենք օգտագործում ենք հավելվածի բաժանումը:
Իսկ միջուկով ցանկալի միջնորմն ընտրելու համար օգտագործվում է երկու հրաման bootm uboot-ում - սկզբում փորձում ենք բեռնել հիմնական միջուկը և եթե այն վնասված է, ապա պահեստայինը։
Սա ապահովում է, որ ցանկացած պահի տեսախցիկը կունենա ճիշտ միջուկը rootf-ներով, և այն կկարողանա բեռնել և վերականգնել որոնվածը:
CI/CD համակարգ որոնվածը ստեղծելու և տեղադրելու համար
Որոնվածը ստեղծելու համար մենք օգտագործում ենք gitlab CI-ն, որն ավտոմատ կերպով կառուցում է որոնվածը բոլոր աջակցվող տեսախցիկների մոդելների համար, և որոնվածը կառուցելուց հետո այն ավտոմատ կերպով տեղադրվում է տեսախցիկի ծրագրակազմի թարմացման ծառայության մեջ:
Ծառայությունից որոնվածի թարմացումները փոխանցվում են մեր QA թեստային տեսախցիկներին, իսկ բոլոր թեստավորման փուլերն ավարտելուց հետո՝ օգտատերերի տեսախցիկներին:
Տեղեկատվական անվտանգություն
Գաղտնիք չէ, որ մեր օրերում տեղեկատվական անվտանգությունը ցանկացած IoT սարքի, ներառյալ տեսախցիկների, ամենակարեւոր կողմն է։ Mirai-ի նման բոտնետները շրջում են ինտերնետում՝ վարակելով միլիոնավոր տեսախցիկներ վաճառողների ստանդարտ որոնվածով: Խցիկի վաճառողների հանդեպ հարգանքով հանդերձ՝ ես չեմ կարող չնկատել, որ ստանդարտ որոնվածը պարունակում է բազմաթիվ գործառույթներ, որոնք անհրաժեշտ չեն ամպի հետ աշխատելու համար, բայց պարունակում են բազմաթիվ խոցելիություններ, որոնցից օգտվում են բոտնետները:
Հետևաբար, մեր որոնվածի բոլոր չօգտագործված գործառույթներն անջատված են, բոլոր tcp/udp պորտերը փակ են, և որոնվածը թարմացնելիս ստուգվում է ծրագրաշարի թվային ստորագրությունը:
Եվ բացի այդ, որոնվածը կանոնավոր փորձարկում է անցնում տեղեկատվական անվտանգության լաբորատորիայում։
Ամփոփում
Այժմ մեր որոնվածը ակտիվորեն օգտագործվում է տեսահսկման նախագծերում: Դրանցից ամենամեծը, թերեւս, Ռուսաստանի Դաշնության նախագահի ընտրության օրը քվեարկության հեռարձակումն է։
Նախագիծը ներառում էր ավելի քան 70 հազար տեսախցիկ մեր որոնվածով, որոնք տեղադրվեցին մեր երկրի ընտրատեղամասերում։
Լուծելով մի շարք բարդ, իսկ որոշ տեղերում՝ նույնիսկ այն ժամանակ գրեթե անհնարին խնդիրներ, մենք, իհարկե, որպես ինժեներներ մեծ գոհունակություն ստացանք, բայց բացի այդ, խնայեցինք նաև միլիոնավոր դոլարներ տեսախցիկներ գնելու համար։ Եվ այս դեպքում խնայողությունները ոչ միայն խոսքերն ու տեսական հաշվարկներն են, այլ սարքավորումների գնման արդեն ավարտված մրցույթի արդյունքները։ Համապատասխանաբար, եթե խոսենք ամպային տեսահսկման մասին, կա երկու մոտեցում՝ ռազմավարականորեն ապավինել ցածր մակարդակի փորձաքննության և զարգացմանը, ինչը հանգեցնում է սարքավորումների վրա հսկայական խնայողությունների կամ օգտագործել թանկարժեք սարքավորումներ, որոնք, եթե նայենք կոնկրետ սպառողների բնութագրերին, գործնականում բացակայում են։ տարբերվում է նմանատիպ էժաններից:
Ինչո՞ւ է ռազմավարական առումով կարևոր ինտեգրացիոն մոտեցման ընտրության հարցում որքան հնարավոր է շուտ որոշելը: Պլագին մշակելիս մշակողները ապավինում են որոշակի տեխնոլոգիաների (գրադարաններ, արձանագրություններ, ստանդարտներ): Եվ եթե տեխնոլոգիաների մի շարք ընտրվի միայն թանկարժեք սարքավորումների համար, ապա ապագայում էժան տեսախցիկների անցնելու փորձը, ամենայն հավանականությամբ, առնվազն խելագարորեն երկար ժամանակ կպահանջի կամ նույնիսկ ձախողվի, և վերադարձ թանկարժեք սարքավորումներին:
Source: www.habr.com