Helo bawb!
Mae'n debyg nad yw'n gyfrinach bod gwasanaethau gwyliadwriaeth fideo cwmwl wedi bod yn dod yn boblogaidd yn ddiweddar. Ac mae'n amlwg pam mae hyn yn digwydd, mae fideo yn gynnwys “trwm”, y mae angen seilwaith a llawer iawn o storio disg i'w storio. Mae defnyddio system gwyliadwriaeth fideo ar y safle yn gofyn am arian i weithredu a chefnogi, ar gyfer sefydliad sy'n defnyddio cannoedd o gamerâu gwyliadwriaeth ac ar gyfer defnyddiwr unigol â nifer o gamerâu.
Mae systemau gwyliadwriaeth fideo cwmwl yn datrys y broblem hon trwy ddarparu seilwaith storio a phrosesu fideo presennol i gwsmeriaid. Yn syml, mae angen i gleient gwyliadwriaeth fideo cwmwl gysylltu'r camera â'r Rhyngrwyd a'i gysylltu â'i gyfrif cwmwl.
Mae yna sawl ffordd dechnolegol i gysylltu camerâu i'r cwmwl. Yn ddi-os, y dull mwyaf cyfleus a rhataf yw bod y camera yn cysylltu'n uniongyrchol ac yn gweithio gyda'r cwmwl, heb gyfranogiad offer ychwanegol fel gweinydd neu recordydd.
I wneud hyn, mae angen gosod modiwl meddalwedd sy'n gweithio gyda'r cwmwl ar y camera. Fodd bynnag, os ydym yn siarad am gamerâu rhad, yna mae ganddynt adnoddau caledwedd cyfyngedig iawn, sydd bron i 100% yn cael eu meddiannu gan firmware brodorol y gwerthwr camera, ac nid oes unrhyw adnoddau angenrheidiol ar gyfer yr ategyn cwmwl. Neilltuodd datblygwyr o ivideon y broblem hon , sy'n esbonio pam na allant osod yr ategyn ar gamerâu rhad. O ganlyniad, isafswm pris y camera yw 5000 rubles ($ 80 doler) a gwariwyd miliynau o arian ar offer.
Rydym wedi llwyddo i ddatrys y broblem hon. Os oes gennych ddiddordeb mewn sut - croeso i'r toriad
Tipyn o hanes
Yn 2016, dechreuon ni ddatblygu llwyfan gwyliadwriaeth fideo cwmwl ar gyfer Rostelecom.
O ran meddalwedd camera, yn y cam cyntaf fe wnaethom ddilyn y llwybr “safonol” ar gyfer tasgau o'r fath: fe wnaethom ddatblygu ein ategyn ein hunain, sydd wedi'i osod yn firmware safonol camera'r gwerthwr ac sy'n gweithio gyda'n cwmwl. Fodd bynnag, mae'n werth nodi ein bod wedi defnyddio'r atebion mwyaf ysgafn ac effeithlon yn ystod y dyluniad (er enghraifft, gweithredu C plaen o protobuf, libev, mbedtls a llyfrgelloedd cyfleus ond trwm wedi'u gadael yn llwyr fel hwb)
Ar hyn o bryd, nid oes unrhyw atebion integreiddio cyffredinol ar y farchnad camera IP: mae gan bob gwerthwr ei ffordd ei hun o osod yr ategyn, ei set ei hun o APIs ar gyfer gweithredu'r firmware, a mecanwaith diweddaru unigryw.
Mae hyn yn golygu bod angen datblygu haen gynhwysfawr o feddalwedd integreiddio ar gyfer pob gwerthwr camera yn unigol. Ac ar adeg dechrau datblygu, fe'ch cynghorir i weithio gydag 1 gwerthwr yn unig er mwyn canolbwyntio ymdrechion y tîm ar ddatblygu'r rhesymeg ar gyfer gweithio gyda'r cwmwl.
Y gwerthwr cyntaf a ddewiswyd oedd Hikvision, un o arweinwyr y byd yn y farchnad gamerâu, gan ddarparu API wedi'i ddogfennu'n dda a chymorth technegol peirianneg cymwys.
Lansiwyd ein prosiect peilot cyntaf, gwyliadwriaeth fideo cwmwl Video Comfort, gan ddefnyddio camerâu Hikvision.
Bron yn syth ar ôl y lansiad, dechreuodd ein defnyddwyr ofyn cwestiynau am y posibilrwydd o gysylltu camerâu rhatach gan weithgynhyrchwyr eraill i'r gwasanaeth.
Gwrthodais yr opsiwn o weithredu haen integreiddio ar gyfer pob gwerthwr bron ar unwaith - gan ei fod yn scalable yn wael ac yn gosod gofynion technegol difrifol ar galedwedd y camera. Cost camera sy'n bodloni'r gofynion mewnbwn hyn: ~60-70$
Felly, penderfynais gloddio'n ddyfnach - i wneud fy firmware fy hun ar gyfer camerâu gan unrhyw werthwr. Mae'r dull hwn yn lleihau'n sylweddol y gofynion ar gyfer adnoddau caledwedd camera - oherwydd Mae'r haen ar gyfer gweithio gyda'r cwmwl wedi'i hintegreiddio'n llawer mwy effeithiol â'r cais fideo, ac nid oes unrhyw fraster diangen heb ei ddefnyddio yn y firmware.
A'r hyn sy'n bwysig yw, wrth weithio gyda'r camera ar lefel isel, ei bod hi'n bosibl defnyddio caledwedd AES, sy'n amgryptio data heb greu llwyth ychwanegol ar y CPU pŵer isel.
Ar y foment honno doedd gennym ni ddim byd o gwbl. Dim byd o gwbl.
Nid oedd bron pob gwerthwr yn barod i weithio gyda ni ar lefel mor isel. Nid oes unrhyw wybodaeth am y cylchedwaith a'r cydrannau, nid oes SDK swyddogol o sglodion a dogfennaeth synhwyrydd.
Nid oes cymorth technegol ychwaith.
Roedd yn rhaid ateb pob cwestiwn trwy beirianneg wrthdro - treial a chamgymeriad. Ond fe lwyddon ni.
Y modelau camera cyntaf y gwnaethom brofi arnynt oedd Xiaomi Yi Morgrug, Hikvision, Dahua, Spezvision, camerâu D-Link a sawl camera Tsieineaidd dienw rhad iawn.
Techneg
Camerâu yn seiliedig ar chipset Hisilicon 3518E. Mae nodweddion caledwedd y camerâu fel a ganlyn:
Morgrug Yi Xiaomi
noname
SoC
Hisilicon 3518E
Hisilicon 3518E
RAM
64MB
64MB
FLASH
16MB
8MB
WiFi
mt7601/bcm43143
-
Synhwyrydd
9732 (720p)
9712 (720p)
Ethernet
-
+
MicroSD
+
+
meicroffon
+
+
Siaradwr
+
+
IRLed
+
+
IRCut
+
+
Dechreuon ni gyda nhw.
Ar hyn o bryd rydym yn cefnogi chipsets Hisilicon 3516/3518, yn ogystal ag Ambarella S2L / S2LM. Mae yna ddwsinau o fodelau camera.
Cyfansoddiad cadarnwedd
llong danfor
uboot yw'r cychwynnwr, mae'n cychwyn yn gyntaf ar ôl pŵer ymlaen, yn cychwyn y caledwedd ac yn llwytho'r cnewyllyn linux.
Mae'r sgript llwytho camera yn eithaf dibwys:
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 0x82000000Un o'r nodweddion yw ei fod yn cael ei alw ddwywaith bootm, mwy am hyn ychydig yn ddiweddarach, pan gyrhaeddwn yr is-system ddiweddaru.
Rhowch sylw i'r llinell mem=38M. Ydy, ie, nid yw hwn yn deip - y cnewyllyn Linux a phob, pob un, mae gan bob cais fynediad i 38 megabeit yn unig o RAM.
Hefyd wrth ymyl uboot mae bloc arbennig o'r enw reg_info, sy'n cynnwys sgript lefel isel ar gyfer cychwyn DDR a nifer o gofrestrau system o'r SoC. Cynnwys reg_info yn dibynnu ar fodel y camera, ac os nad yw'n gywir, ni fydd y camera hyd yn oed yn gallu llwytho uboot, ond bydd yn rhewi yn ystod cyfnod cynnar iawn y llwytho.
Ar y dechrau, pan wnaethom weithio heb gefnogaeth gwerthwr, fe wnaethom gopïo'r bloc hwn o'r firmware camera gwreiddiol.
Cnewyllyn Linux a rootfs
Mae'r camerâu yn defnyddio'r cnewyllyn Linux, sy'n rhan o SDK y sglodyn; fel arfer nid dyma'r cnewyllyn diweddaraf o'r gangen 3.x, felly yn aml mae'n rhaid i ni ddelio â'r ffaith nad yw gyrwyr offer ychwanegol yn gydnaws â'r cnewyllyn a ddefnyddir , ac mae'n rhaid i ni eu hôl-borthi i'r camerâu cnewyllyn.
Mater arall yw maint y cnewyllyn. Pan mai dim ond 8MB yw maint FLASH, yna mae pob beit yn cyfrif a'n tasg ni yw analluogi'r holl swyddogaethau cnewyllyn nas defnyddiwyd yn ofalus er mwyn lleihau'r maint i'r lleiafswm.
Mae Rootfs yn system ffeiliau sylfaenol. Mae'n cynnwys busybox, gyrwyr modiwl wifi, set o lyfrgelloedd system safonol, megis libld и libc, yn ogystal â'n meddalwedd, sy'n gyfrifol am y rhesymeg rheoli LED, rheoli cysylltiad rhwydwaith a diweddariadau firmware.
Mae'r system ffeiliau gwraidd wedi'i gysylltu â'r cnewyllyn fel initramfs ac o ganlyniad i'r adeiladu rydym yn cael un ffeil uImage, sy'n cynnwys y cnewyllyn a'r rootfs.
Cais fideo
Y rhan fwyaf cymhleth a dwys o ran adnoddau o'r firmware yw'r cymhwysiad, sy'n darparu dal fideo-sain, amgodio fideo, yn ffurfweddu paramedrau llun, yn gweithredu dadansoddiadau fideo, er enghraifft, synwyryddion symud neu sain, yn rheoli PTZ ac yn gyfrifol am newid diwrnod a moddau nos.
Nodwedd bwysig, byddwn hyd yn oed yn dweud, yw sut mae'r cymhwysiad fideo yn rhyngweithio â'r ategyn cwmwl.
Mewn atebion traddodiadol 'firmware gwerthwr + ategyn cwmwl', na all weithio ar galedwedd rhad, trosglwyddir fideo y tu mewn i'r camera trwy'r protocol RTSP - ac mae hwn yn orbenion enfawr: copïo a throsglwyddo data trwy soced, syscalls diangen.
Yma rydym yn defnyddio'r mecanwaith cof a rennir - nid yw'r fideo yn cael ei gopïo na'i anfon trwy soced rhwng cydrannau meddalwedd y camera, a thrwy hynny ddefnyddio galluoedd caledwedd cymedrol y camera yn optimaidd ac yn ofalus.
Diweddaru'r is-system
Pwynt o falchder arbennig yw'r is-system sy'n goddef namau ar gyfer diweddariadau cadarnwedd ar-lein.
Gadewch imi egluro'r broblem. Yn dechnegol nid yw diweddaru'r firmware yn weithrediad atomig, ac os bydd methiant pŵer yn digwydd yng nghanol y diweddariad, yna bydd y cof fflach yn cynnwys rhan o'r cadarnwedd newydd "tanysgrifenedig". Os na chymerwch fesurau arbennig, bydd y camera wedyn yn dod yn “brics” y mae angen ei gludo i ganolfan wasanaeth.
Rydym wedi delio â’r broblem hon hefyd. Hyd yn oed os caiff y camera ei ddiffodd yn ystod y diweddariad, bydd yn lawrlwytho'r firmware o'r cwmwl yn awtomatig a heb ymyrraeth defnyddiwr ac yn adfer gweithrediad.
Edrychwn ar y dechneg yn fwy manwl:
Y pwynt mwyaf agored i niwed yw trosysgrifo'r rhaniad gyda'r cnewyllyn Linux a'r system ffeiliau gwraidd. Os caiff un o'r cydrannau hyn ei niweidio, ni fydd y camera yn cychwyn o gwbl y tu hwnt i'r cychwynnwr uboot, na all lawrlwytho firmware o'r cwmwl.
Mae hyn yn golygu bod angen inni sicrhau bod gan y camera gnewyllyn gweithio a rootfs ar unrhyw adeg yn ystod y broses ddiweddaru. Mae'n ymddangos mai'r ateb symlaf fyddai storio dau gopi o'r cnewyllyn yn gyson gyda rootfs ar gof fflach ac, os yw'r prif gnewyllyn wedi'i ddifrodi, ei lwytho o'r copi wrth gefn.
Datrysiad da - fodd bynnag, mae'r cnewyllyn gyda rootfs yn cymryd tua 3.5MB ac ar gyfer copi wrth gefn parhaol mae angen i chi ddyrannu 3.5MB. Yn syml, nid oes gan y camerâu rhataf gymaint o le am ddim ar gyfer cnewyllyn wrth gefn.
Felly, i wneud copi wrth gefn o'r cnewyllyn yn ystod diweddariad firmware, rydym yn defnyddio rhaniad y cais.
Ac i ddewis y rhaniad dymunol gyda'r cnewyllyn, defnyddir dau orchymyn bootm yn uboot - ar y dechrau rydym yn ceisio llwytho'r prif gnewyllyn ac os caiff ei ddifrodi, yna'r un wrth gefn.
Mae hyn yn sicrhau ar unrhyw adeg benodol y bydd gan y camera y cnewyllyn cywir gyda rootfs, a bydd yn gallu cychwyn ac adfer y firmware.
System CI/CD ar gyfer adeiladu a defnyddio firmware
I adeiladu firmware, rydym yn defnyddio gitlab CI, sy'n adeiladu firmware yn awtomatig ar gyfer pob model camera a gefnogir, ac ar ôl adeiladu'r firmware, caiff ei ddefnyddio'n awtomatig i'r gwasanaeth diweddaru meddalwedd camera.
O'r gwasanaeth, cyflwynir diweddariadau firmware i'n camerâu prawf SA, ac ar ôl cwblhau pob cam profi, i gamerâu defnyddwyr.
Diogelwch Gwybodaeth
Nid yw'n gyfrinach mai diogelwch gwybodaeth y dyddiau hyn yw'r agwedd bwysicaf ar unrhyw ddyfais IoT, gan gynnwys camerâu. Mae botnets fel Mirai yn crwydro'r Rhyngrwyd, gan heintio miliynau o gamerâu â firmware safonol gan werthwyr. Gyda phob parch i werthwyr camera, ni allaf helpu ond nodi bod firmware safonol yn cynnwys llawer o swyddogaethau nad oes eu hangen ar gyfer gweithio gyda'r cwmwl, ond mae'n cynnwys llawer o wendidau y mae botnets yn manteisio arnynt.
Felly, mae'r holl swyddogaethau nas defnyddiwyd yn ein firmware yn anabl, mae pob porthladd tcp / udp ar gau, ac wrth ddiweddaru'r firmware, mae llofnod digidol y meddalwedd yn cael ei wirio.
Ac ar wahân i hyn, mae'r firmware yn cael ei brofi'n rheolaidd yn y labordy diogelwch gwybodaeth.
Casgliad
Nawr mae ein firmware yn cael ei ddefnyddio'n weithredol mewn prosiectau gwyliadwriaeth fideo. Efallai mai'r mwyaf ohonynt yw'r darllediad o bleidleisio ar ddiwrnod etholiad Llywydd Ffederasiwn Rwsia.
Roedd y prosiect yn cynnwys mwy na 70 mil o gamerâu gyda'n firmware, a osodwyd mewn gorsafoedd pleidleisio yn ein gwlad.
Ar ôl datrys nifer o gymhleth, ac mewn rhai mannau, hyd yn oed ar y pryd bron yn amhosibl problemau, rydym, wrth gwrs, yn cael boddhad mawr fel peirianwyr, ond ar wahân i hyn, rydym hefyd yn arbed miliynau o ddoleri ar brynu camerâu. Ac yn yr achos hwn, nid yn unig geiriau a chyfrifiadau damcaniaethol yw arbedion, ond canlyniadau tendr a gwblhawyd eisoes ar gyfer prynu offer. Yn unol â hynny, os ydym yn siarad am wyliadwriaeth fideo cwmwl: mae dau ddull - dibynnu'n strategol ar arbenigedd a datblygiad lefel isel, gan arwain at arbedion enfawr ar offer, neu ddefnyddio offer drud, sydd, os edrychwch yn benodol ar nodweddion defnyddwyr, yn ymarferol ddim. yn wahanol i rai rhad tebyg.
Pam ei bod yn strategol bwysig penderfynu ar y dewis o ddull integreiddio cyn gynted â phosibl? Wrth ddatblygu ategyn, mae datblygwyr yn dibynnu ar rai technolegau (llyfrgelloedd, protocolau, safonau). Ac os dewisir set o dechnolegau ar gyfer offer drud yn unig, yna yn y dyfodol bydd ymgais i newid i gamerâu rhad yn fwyaf tebygol, o leiaf, yn cymryd amser gwallgof o hir neu hyd yn oed yn methu a bydd dychwelyd i offer drud yn digwydd.
Ffynhonnell: hab.com