Hallo almal!
Dit is waarskynlik geen geheim vir enigiemand dat wolkvideo-toesigdienste die afgelope paar jaar gewild geword het nie. En dit is verstaanbaar hoekom dit gebeur, video is "swaar" inhoud, wat infrastruktuur en groot hoeveelhede skyfberging vereis om te stoor. Die gebruik van 'n plaaslike video-toesigstelsel vereis fondse vir bedryf en ondersteuning, beide in die geval van 'n organisasie wat honderde toesigkameras gebruik, en in die geval van 'n individuele gebruiker met verskeie kameras.
Wolk-videobewakingstelsels los hierdie probleem op deur kliënte van 'n bestaande videoberging- en verwerkingsinfrastruktuur te voorsien. ’n Wolkvideo-toesigkliënt moet eenvoudig die kamera aan die internet koppel en dit aan hul rekening in die wolk koppel.
Daar is verskeie tegnologiese maniere om kameras aan die wolk te koppel. Ongetwyfeld, die gerieflikste en goedkoopste manier - die kamera verbind direk en werk met die wolk, sonder die deelname van bykomende toerusting soos 'n bediener of registrateur.
Om dit te doen, is dit nodig dat die sagtewaremodule wat met die wolk werk, op die kamera geïnstalleer is. As ons egter van goedkoop kameras praat, dan het hulle baie beperkte hardewarehulpbronne, wat byna 100% beset word deur die inheemse firmware van die kameraverkoper, maar daar is geen hulpbronne nodig vir die wolkinprop nie. Ontwikkelaars van ivideon toegewy aan hierdie probleem , wat sê hoekom hulle nie die inprop op goedkoop kameras kan installeer nie. Gevolglik is die minimum prys van die kamera 5000r ($80) en miljoene geld spandeer aan toerusting.
Ons het hierdie probleem suksesvol opgelos. As jy belangstel in hoe - welkom onder die kat
'N bietjie geskiedenis
In 2016 het ons begin om 'n wolkvideo-toesigplatform vir Rostelecom te ontwikkel.
Wat kamerasagteware betref, het ons in die eerste stadium die "standaard" manier vir sulke take gegaan: ons het ons eie inprop ontwikkel, wat in die firmware van die verskaffer se kamera geïnstalleer is en met ons wolk werk. Dit is egter opmerklik dat ons tydens die ontwerp die mees liggewig en doeltreffende oplossings gebruik het (byvoorbeeld, gewone C-implementering van protobuf, libev, mbedtls en heeltemal verlate gerieflike, maar swaar biblioteke soos hupstoot)
Nou is daar geen universele integrasie-oplossings op die IP-kameramark nie: elke verkoper het sy eie manier om die inprop te installeer, sy eie stel API's vir fermware-werking en 'n unieke opdateringsmeganisme.
Dit beteken dat dit vir elke kameraverkoper nodig is om individueel 'n volumetriese laag integrasiesagteware te ontwikkel. En ten tyde van die begin van ontwikkeling, is dit raadsaam om met slegs 1 verskaffer te werk om die span se pogings te fokus op die ontwikkeling van die logika van werk met die wolk.
Hikvision is gekies as die eerste verskaffer, een van die wêreldleiers in die kameramark, wat 'n goed gedokumenteerde API en bekwame tegniese tegniese ondersteuning bied.
Met behulp van Hikvision-kameras het ons ons eerste loodsprojek van stapel gestuur - wolkvideo-toesig Videocomfort.
Byna onmiddellik ná die bekendstelling het ons gebruikers vrae begin vra oor die moontlikheid om goedkoper kameras van ander vervaardigers aan die diens te koppel.
Ek het die opsie van die implementering van 'n integrasielaag vir elke verskaffer feitlik onmiddellik verwerp – aangesien dit swak skaalbaar is en ernstige tegniese vereistes aan die kamerahardeware stel. Die koste van 'n kamera wat aan hierdie vereistes by die ingang voldoen: ~ 60-70 $
Daarom het ek besluit om dieper te delf - om my eie firmware vir kameras van enige verskaffers te maak. Hierdie benadering verminder die vereistes vir kamera hardeware hulpbronne aansienlik. die wolklaag is 'n orde van grootte meer effektief geïntegreer met die videotoepassing, en daar is geen ekstra ongebruikte vet in die firmware nie.
En wat belangrik is, wanneer jy met 'n kamera op 'n lae vlak werk, is dit moontlik om hardeware AES te gebruik, wat data enkripteer sonder om bykomende las op 'n lae-krag SVE te skep.
Op daardie oomblik het ons niks gehad nie. Hoegenaamd niks.
Byna alle verkopers was nie gereed om op so 'n lae vlak met ons te werk nie. Daar is geen inligting oor stroombane en komponente nie, daar is geen amptelike skyfiestel SDK en sensordokumentasie nie.
Daar is ook geen tegniese ondersteuning nie.
Antwoorde op alle vrae moes deur omgekeerde ingenieurswese verkry word – deur proef en fout. Maar ons het dit gedoen.
Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link-kameras en 'n paar super goedkoop naamlose Chinese kameras was die eerste kameramodelle waarop ons bulte gestop het.
Tegniek
Kameras gebaseer op die Hisilicon 3518E-skyfiestel. Die hardeware-eienskappe van die kameras is soos volg:
Xiaomi Yi Miere
noname
SoC
Hisilicon 3518E
Hisilicon 3518E
RAM
64MB
64MB
FLASH
16MB
8MB
WiFi
mt7601/bcm43143
-
Sensor
ov9732 (720p)
ov9712 (720p)
Ethernet
-
+
MicroSD
+
+
Mikrofoon
+
+
Speaker
+
+
IRLed
+
+
IRCut
+
+
Ons het met hulle begin.
Ons ondersteun tans Hisilicon 3516/3518-skyfiestelle, sowel as Ambarella S2L/S2LM. Die aantal kameramodelle is dosyne.
Die samestelling van die firmware
uboot
uboot is die selflaaiprogram, nadat dit eers begin laai, inisialiseer die hardeware en laai die linux-kern.
Die kamera selflaaiskrif is nogal triviaal:
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 0x82000000Van die kenmerke - dit word twee keer genoem bootm, meer hieroor 'n bietjie later, wanneer ons by die opdateringsubstelsel kom.
Gee aandag aan die lyn mem=38M. Ja, ja, dit is nie 'n tikfout nie - die Linux-kern en alles-alles-toepassings het slegs 38 megagrepe RAM beskikbaar.
Ook langs uboot is 'n spesiale blok genoem reg_info, wat 'n laevlak DDR-inisialiseringskrip en 'n aantal SoC-stelselregisters bevat. Inhoud reg_info hang af van die kameramodel, en as dit nie korrek is nie, sal die kamera nie eers uboot kan laai nie, maar sal in die baie vroeë stadium van laai hang.
Aanvanklik, toe ons sonder verskafferondersteuning gewerk het, het ons hierdie blok eenvoudig vanaf die oorspronklike kamera-firmware gekopieer.
Linux-kern en rootfs
Die kameras gebruik die Linux-kern, wat deel is van die SDK van die chip, gewoonlik is dit nie die nuutste pitte van die 3.x-tak nie, so ons moet dikwels die feit hanteer dat addisionele toerustingdrywers nie met die kern versoenbaar is nie gebruik, en ons moet hulle terugporteer na die kernkameras.
Nog 'n probleem is die kerngrootte. Wanneer die FLASH-grootte slegs 8MB is, dan tel elke greep, en ons taak is om alle ongebruikte kernfunksies versigtig te deaktiveer om die grootte tot 'n minimum te verminder.
Rootfs is die basis lêerstelsel. Dit sluit in busybox, wifi module drywers, 'n stel standaard stelsel biblioteke, soos libld и libc, sowel as sagteware van ons eie ontwikkeling, wat verantwoordelik is vir die LED-beheerlogika, netwerkverbindingbestuur en firmware-opdaterings.
Die wortellêerstelsel is as 'n initramfs aan die kern gekoppel en as gevolg van die samestelling kry ons een lêer uImage, wat beide kern en rootfs het.
video aansoek
Die mees komplekse en hulpbron-intensiewe deel van die firmware is 'n toepassing wat video-oudio-opname, video-kodering verskaf, beeldparameters konfigureer, video-analise implementeer, soos beweging- of klankdetektors, PTZ beheer en verantwoordelik is vir die oorskakeling van dag- en nagmodusse .
'n Belangrike, ek sou selfs sê 'n sleutelkenmerk is hoe die video-toepassing met die wolkinprop in wisselwerking tree.
In tradisionele 'firmware + cloud plug-in'-oplossings wat nie op goedkoop hardeware kan werk nie, word die video binne die kamera via RTSP-protokol oorgedra - en dit is 'n groot oorhoofse koste: kopieer en versend data via sok, ekstra stelseloproepe.
Op hierdie stadium gebruik ons die gedeelde geheue-meganisme – die video word nie gekopieer of via 'n sok tussen die kamerasagteware-komponente gestuur nie, waardeur die kamera se beskeie hardeware-vermoëns optimaal en versigtig gebruik word.
Dateer substelsel op
Die onderwerp van aparte trots is die foutverdraagsame substelsel vir aanlyn-firmware-opdaterings.
Kom ek verduidelik die probleem. Die opdatering van die firmware is tegnies nie 'n atoombewerking nie, en as daar 'n kragonderbreking in die middel van die opdatering is, sal daar 'n deel van die "ondergeskrewe" nuwe firmware op die flitsgeheue wees. As jy nie spesiale maatreëls tref nie, sal die kamera dan 'n "baksteen" word wat na die dienssentrum gedra moet word.
Ons het ook hierdie probleem hanteer. Selfs al is die kamera afgeskakel ten tyde van die opdatering, sal dit outomaties en sonder gebruikersingryping die firmware van die wolk aflaai en die werking herstel.
Kom ons ontleed die tegniek in meer detail:
Die mees kwesbare punt is om die partisie met die Linux-kern en die wortellêerstelsel te oorskryf. As een van hierdie komponente beskadig blyk te wees, sal die kamera glad nie self begin as die uboot-laaier nie, wat nie firmware van die wolk kan aflaai nie.
Dit beteken dat ons te eniger tyd tydens die opdateringsproses moet verseker dat die kamera 'n werkende kern en rootfs het. Dit wil voorkom asof die eenvoudigste oplossing sou wees om twee kopieë van die kern permanent met rootfs op flitsgeheue te stoor en, in die geval van skade aan die hoofkern, dit vanaf die rugsteunkopie te laai.
'n Goeie oplossing - die kern met rootfs neem egter ongeveer 3.5MB en 3.5MB moet vir 'n permanente rugsteun toegewys word. Op die goedkoopste kameras is daar eenvoudig nie soveel vrye spasie vir rugsteunpitte nie.
Daarom, vir die rugsteunkern tydens die firmware-opdatering, gebruik ons die toepassingpartisie.
En om die gewenste partisie met die kern te kies, word twee opdragte gebruik bootm in uboot - aan die begin probeer ons om die hoofkern te laai en as dit beskadig is, dan die rugsteun een.
Dit verseker dat die kamera op enige gegewe tydstip die korrekte kern met rootfs het, sodat dit die firmware kan selflaai en herstel.
CI / CD-stelsel vir die bou en implementering van firmware
Om die firmware te bou, gebruik ons gitlab CI, waarin firmware vir alle ondersteunde kameramodelle outomaties versamel word, nadat die firmware gebou is, word dit outomaties na die kamerasagteware-opdateringdiens ontplooi.
Van die diens af word fermware-opdaterings aan die toetskameras van ons QA gelewer, en na voltooiing van alle toetsfases, aan die gebruikers se kameras.
Inligtings sekuriteit
Dit is geen geheim nie dat inligtingsekuriteit in ons tyd die belangrikste aspek van enige IoT-toestel is, insluitend kameras. Botnets soos Mirai dwaal op die internet en val miljoene kameras aan met standaard-firmware van verskaffers. Met alle respek vir kameraverkopers, kan ek nie anders as om daarop te let dat die standaard-firmware baie funksionaliteit bevat wat nie nodig is om met die wolk te werk nie, maar baie kwesbaarhede bevat wat deur botnets gebruik word.
Daarom is alle ongebruikte funksionaliteit in ons firmware gedeaktiveer, alle tcp / udp-poorte is gesluit, en wanneer die firmware opgedateer word, word die digitale handtekening van die sagteware nagegaan.
En boonop word die firmware gereeld in die inligtingsekuriteitslaboratorium getoets.
Gevolgtrekking
Nou word ons firmware aktief gebruik in video-toesigprojekte. Miskien is die mees ambisieuse van hulle die uitsending van stemming op die dag van die verkiesing van die president van die Russiese Federasie.
Die projek het meer as 70 duisend kameras met ons firmware behels, wat in die stemlokale van ons land geïnstalleer is.
Nadat ons 'n aantal komplekse, en op sommige plekke, selfs in daardie tyd amper onmoontlike take opgelos het, het ons natuurlik groot bevrediging as ingenieurs ontvang, maar boonop het ons miljoene dollars gespaar op die aankoop van kameras. En in hierdie geval is besparings nie net woorde en teoretiese berekeninge nie, maar die resultate van 'n tender vir die aankoop van toerusting wat reeds gebeur het. Gevolglik, as ons oor wolkvideo-toesig praat: daar is twee benaderings – om strategies op laevlak kundigheid en ontwikkeling staat te maak, wat groot besparings op toerusting tot gevolg het, of om duur toerusting te gebruik, wat, as jy spesifiek na verbruikerskenmerke kyk, is feitlik nie anders as soortgelyke goedkoops nie.
Waarom is dit strategies belangrik om so vroeg as moontlik 'n besluit oor die keuse van benadering tot die integrasiemetode te neem? Wanneer 'n inprop ontwikkel word, maak ontwikkelaars staat op sekere tegnologieë (biblioteke, protokolle, standaarde). En as 'n stel tegnologieë slegs vir duur toerusting gekies word, sal 'n poging om na goedkoop kameras oor te skakel in die toekoms heel waarskynlik 'n waansinnige lang tyd neem of selfs misluk en daar sal 'n terugkeer na duur toerusting wees.
Bron: will.com