Hei kaikille!

Ei ole luultavasti mikään salaisuus, että pilvivideovalvontapalvelut ovat yleistyneet viime aikoina. Ja on selvää, miksi näin tapahtuu, video on "raskasta" sisältöä, jonka tallentaminen vaatii infrastruktuuria ja suuria määriä levytilaa. Paikallisen videovalvontajärjestelmän käyttö vaatii varoja toimiakseen ja tukeen sekä satoja valvontakameroita käyttävältä organisaatiolta että yksittäiseltä käyttäjältä, jolla on useita kameroita.

Pilvivideovalvontajärjestelmät ratkaisevat tämän ongelman tarjoamalla asiakkaille olemassa olevan videon tallennus- ja käsittelyinfrastruktuurin. Pilvivideovalvonta-asiakkaan tarvitsee vain liittää kamera Internetiin ja linkittää se pilvitiliinsä.

On olemassa useita teknisiä tapoja yhdistää kamerat pilveen. Epäilemättä kätevin ja halvin tapa on, että kamera muodostaa yhteyden suoraan pilveen ja toimii sen kanssa ilman lisälaitteiden, kuten palvelimen tai tallentimen, osallistumista.

Tätä varten kameraan on asennettava pilven kanssa toimiva ohjelmistomoduuli. Kuitenkin, jos puhumme halvoista kameroista, niillä on hyvin rajalliset laitteistoresurssit, jotka ovat lähes 100% kameran toimittajan alkuperäisen laiteohjelmiston käytössä, eikä pilvilaajennukselle tarvita resursseja. Ivideonin kehittäjät kiinnittivät tämän ongelman Artikkeli, mikä selittää, miksi he eivät voi asentaa laajennusta halpoihin kameroihin. Seurauksena on, että kameran vähimmäishinta on 5000 ruplaa (80 dollaria) ja laitteisiin käytetty miljoonia rahaa.

Olemme ratkaisseet tämän ongelman onnistuneesti. Jos olet kiinnostunut miten - tervetuloa leikkaukseen

Vähän historiaa

Vuonna 2016 aloitimme Rostelecomille pilvivideovalvontaalustan kehittämisen.

Kameraohjelmiston osalta noudatimme ensimmäisessä vaiheessa tällaisiin tehtäviin ”standardi” polkua: kehitimme oman liitännäisen, joka on asennettu toimittajan kameran vakiolaiteohjelmistoon ja toimii pilvemme kanssa. On kuitenkin syytä huomata, että suunnittelussa käytimme kevyimpiä ja tehokkaimpia ratkaisuja (esim. pelkkä protobuf, libev, mbedtls C-toteutus ja kokonaan hylätty kätevät mutta raskaat kirjastot, kuten boost)

Tällä hetkellä IP-kameramarkkinoilla ei ole universaaleja integraatioratkaisuja: jokaisella toimittajalla on oma tapa asentaa laajennus, omat API-sarjansa laiteohjelmiston käyttöä varten ja ainutlaatuinen päivitysmekanismi.

Tämä tarkoittaa, että jokaiselle kameran toimittajalle on tarpeen kehittää yksilöllisesti kattava integraatioohjelmistokerros. Ja kehittämisen aloittamisen yhteydessä on suositeltavaa työskennellä vain yhden toimittajan kanssa, jotta tiimi voi keskittyä pilven kanssa työskentelyn logiikan kehittämiseen.

Ensimmäiseksi toimittajaksi valittiin Hikvision, yksi maailman johtavista kameramarkkinoiden johtajista, joka tarjoaa hyvin dokumentoidun API:n ja pätevän teknisen tuen.

Aloitimme ensimmäisen pilottiprojektimme, pilvivideovalvonnan Video Comfortin Hikvision-kameroilla.

Melkein heti julkaisun jälkeen käyttäjämme alkoivat kysellä mahdollisuudesta yhdistää palveluun muiden valmistajien halvempia kameroita.

Hylkäsin vaihtoehdon ottaa käyttöön integrointikerros jokaiselle toimittajalle lähes välittömästi - koska se on huonosti skaalautuva ja asettaa kameralaitteistolle vakavia teknisiä vaatimuksia. Nämä syöttövaatimukset täyttävän kameran hinta: ~60-70$

Siksi päätin kaivaa syvemmälle - tehdä oman laiteohjelmistoni minkä tahansa valmistajan kameroille. Tämä lähestymistapa vähentää merkittävästi kameran laitteistoresurssien vaatimuksia - koska Pilven kanssa työskentelyn kerros on integroitu paljon tehokkaammin videosovellukseen, eikä laiteohjelmistossa ole tarpeetonta käyttämätöntä rasvaa.

Ja mikä on tärkeää, on se, että työskennellessäsi kameran kanssa alhaisella tasolla on mahdollista käyttää laitteistoa AES, joka salaa tiedot aiheuttamatta lisäkuormitusta pienitehoiselle prosessorille.

Sillä hetkellä meillä ei ollut juuri mitään. Ei mitään.

Lähes kaikki toimittajat eivät olleet valmiita työskentelemään kanssamme näin alhaisella tasolla. Piiristä ja komponenteista ei ole tietoa, ei ole virallista piirisarjojen SDK:ta ja anturidokumentaatiota.
Myöskään teknistä tukea ei ole.

Kaikkiin kysymyksiin oli vastattava käänteistekniikalla – yrityksen ja erehdyksen avulla. Mutta onnistuimme.

Ensimmäiset kameramallit, joita testasimme, olivat Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link-kamerat ja useita erittäin edullisia nimettömiä kiinalaisia ​​kameroita.

Tekniikka

Kamerat perustuvat Hisilicon 3518E -piirisarjaan. Kameroiden laitteisto-ominaisuudet ovat seuraavat:

Xiaomi Yi Ants
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Tunnistin
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofoni
+
+

Kaiutin
+
+

IRLed
+
+

IRCut
+
+

Aloitimme heidän kanssaan.

Tuemme tällä hetkellä Hisilicon 3516/3518 -piirisarjoja sekä Ambarella S2L/S2LM:ää. Kameramalleja on kymmeniä.

Laiteohjelmiston koostumus

sukellusvene

uboot on käynnistyslatain, se käynnistyy ensin virran kytkemisen jälkeen, alustaa laitteiston ja lataa Linux-ytimen.

Kameran latausskripti on melko triviaali:

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

Yksi ominaisuuksista on, että sitä kutsutaan kahdesti bootm, tästä lisää hieman myöhemmin, kun pääsemme päivitysalijärjestelmään.

Kiinnitä huomiota linjaan mem=38M. Kyllä, kyllä, tämä ei ole kirjoitusvirhe - Linux-ytimellä ja kaikilla, kaikilla sovelluksilla on pääsy vain 38 megatavuun RAM-muistiin.

Myös ubootin vieressä on erityinen lohko nimeltään reg_info, joka sisältää matalan tason komentosarjan DDR:n alustamiseksi ja joukon SoC:n järjestelmärekisterejä. Sisältö reg_info riippuu kameran mallista, ja jos se ei ole oikein, kamera ei edes pysty lataamaan ubootia, vaan jäätyy lataamisen varhaisessa vaiheessa.

Aluksi, kun työskentelimme ilman toimittajan tukea, kopioimme tämän lohkon kameran alkuperäisestä laiteohjelmistosta.

Linux-ydin ja rootfs

Kamerat käyttävät Linux-ydintä, joka on osa sirun SDK:ta; yleensä nämä eivät ole uusimpia ytimiä 3.x-haaralta, joten joudumme usein käsittelemään sitä tosiasiaa, että lisälaitteiden ajurit eivät ole yhteensopivia käytetyn ytimen kanssa. , ja meidän on siirrettävä ne takaisin ytimen kameroihin.

Toinen ongelma on ytimen koko. Kun FLASH-koko on vain 8 Mt, jokainen tavu on tärkeä ja tehtävämme on poistaa kaikki käyttämättömät ytimen toiminnot huolellisesti käytöstä koon pienentämiseksi minimiin.

Rootfs on perustiedostojärjestelmä. Se sisältää busybox, wifi-moduulin ajurit, joukko tavallisia järjestelmäkirjastoja, kuten libld и libc, sekä ohjelmistomme, joka vastaa LED-ohjauslogiikasta, verkkoyhteyksien hallinnasta ja laiteohjelmistopäivityksistä.

Juuritiedostojärjestelmä on yhdistetty ytimeen initramfs-muodossa ja rakentamisen tuloksena saamme yhden tiedoston uImage, joka sisältää sekä ytimen että rootfs.

Videosovellus

Ohjelmiston monimutkaisin ja resurssiintensiivisin osa on sovellus, joka tarjoaa video-audiokaappauksen, videokoodauksen, konfiguroi kuvaparametreja, toteuttaa videoanalytiikkaa, esimerkiksi liike- tai äänitunnistimet, ohjaa PTZ:tä ja vastaa vuorokauden ja vuorokauden vaihtamisesta. yötilat.

Tärkeä, sanoisin jopa avainominaisuus, on se, miten videosovellus on vuorovaikutuksessa pilvilaajennuksen kanssa.

Perinteisissä ratkaisuissa 'toimittajan laiteohjelmisto + pilvilaajennus', joka ei toimi halvalla laitteistolla, kameran sisällä oleva video välitetään RTSP-protokollan kautta - ja tämä on valtava lisäkustannus: tietojen kopiointi ja siirtäminen socketin kautta, turhat syscalls.

Tässä käytetään jaettua muistimekanismia - videota ei kopioida tai lähetetä kameran ohjelmistokomponenttien välisen pistorasian kautta, jolloin kameran vaatimattomia laitteistoominaisuuksia käytetään optimaalisesti ja huolellisesti.

Päivitä alijärjestelmä

Erityinen ylpeys on vikasietoinen alijärjestelmä online-laiteohjelmistopäivityksille.

Selitän ongelman. Laiteohjelmiston päivittäminen ei ole teknisesti ydinoperaatiota, ja jos sähkökatko tapahtuu kesken päivityksen, niin flash-muisti sisältää osan "alikirjoitetusta" uudesta laiteohjelmistosta. Jos et ryhdy erityistoimenpiteisiin, kamerasta tulee sitten "tiili", joka on vietävä huoltokeskukseen.

Olemme myös käsitelleet tätä ongelmaa. Vaikka kamera sammutettaisiin päivityksen aikana, se lataa laiteohjelmiston automaattisesti ja ilman käyttäjän toimia pilvestä ja palauttaa toiminnan.

Katsotaanpa tekniikkaa tarkemmin:

Haavoittuvin kohta on osion päällekirjoittaminen Linux-ytimellä ja juuritiedostojärjestelmällä. Jos jokin näistä komponenteista on vaurioitunut, kamera ei käynnisty lainkaan uboot-käynnistyslataimen ulkopuolella, joka ei voi ladata laiteohjelmistoa pilvestä.

Tämä tarkoittaa, että meidän on varmistettava, että kamerassa on toimiva ydin ja rootfs milloin tahansa päivitysprosessin aikana. Vaikuttaa siltä, ​​​​että yksinkertaisin ratkaisu olisi tallentaa jatkuvasti kaksi kopiota ytimestä rootf-tiedostojen kanssa flash-muistiin ja jos pääydin on vaurioitunut, ladata se varmuuskopiosta.

Hyvä ratkaisu - kuitenkin rootfs-ydin vie noin 3.5 Mt ja pysyvää varmuuskopiota varten sinun on varattava 3.5 Mt. Halvimmista kameroista ei yksinkertaisesti ole niin paljon vapaata tilaa varmuuskopioytimelle.

Siksi ytimen varmuuskopiointiin laiteohjelmistopäivityksen aikana käytämme sovellusosiota.
Ja halutun osion valitsemiseen ytimen kanssa käytetään kahta komentoa bootm ubootissa - aluksi yritämme ladata pääytimen ja jos se on vaurioitunut, niin sitten varmuuskopion.

Näin varmistetaan, että kamerassa on milloin tahansa oikea ydin rootfsilla ja että se pystyy käynnistämään ja palauttamaan laiteohjelmiston.

CI/CD-järjestelmä laiteohjelmiston rakentamiseen ja käyttöönottoon

Laiteohjelmiston rakentamiseen käytämme gitlab CI:tä, joka rakentaa automaattisesti laiteohjelmiston kaikille tuetuille kameramalleille, ja laiteohjelmiston rakentamisen jälkeen se otetaan automaattisesti käyttöön kameran ohjelmistopäivityspalvelussa.

Palvelusta laiteohjelmistopäivitykset toimitetaan QA-testikameroihimme ja kaikkien testausvaiheiden päätyttyä käyttäjien kameroihin.

Tietoturva

Ei ole mikään salaisuus, että tietoturva on nykyään IoT-laitteiden, myös kameroiden, tärkein osa. Bottiverkot, kuten Mirai, vaeltavat Internetiä ja saastuttavat miljoonia kameroita toimittajien vakiolaiteohjelmistolla. Kaikella kunnioituksella kameravalmistajia kohtaan en voi olla huomaamatta, että vakiolaiteohjelmisto sisältää paljon toimintoja, joita ei tarvita pilven kanssa työskentelemiseen, mutta sisältää monia haavoittuvuuksia, joita botnetit hyödyntävät.

Siksi kaikki laiteohjelmistomme käyttämättömät toiminnot poistetaan käytöstä, kaikki tcp/udp-portit suljetaan ja laiteohjelmistoa päivitettäessä tarkistetaan ohjelmiston digitaalinen allekirjoitus.

Ja tämän lisäksi laiteohjelmisto testataan säännöllisesti tietoturvalaboratoriossa.

Johtopäätös

Nyt laiteohjelmistoamme käytetään aktiivisesti videovalvontaprojekteissa. Ehkä suurin niistä on äänestyslähetys Venäjän federaation presidentin vaalipäivänä.
Projekti sisälsi yli 70 tuhatta kameraa laiteohjelmistollamme, jotka asennettiin maamme äänestyspaikoille.

Ratkaistuamme useita monimutkaisia ​​ja paikoin jopa tuolloin lähes mahdottomia ongelmia, saimme tietysti insinööreinä suuren tyytyväisyyden, mutta tämän lisäksi säästimme myös miljoonia dollareita kameroiden hankinnassa. Ja tässä tapauksessa säästöt eivät ole vain sanoja ja teoreettisia laskelmia, vaan tulokset jo päättyneestä tarjouskilpailusta laitteiden ostosta. Vastaavasti, jos puhumme pilvivideovalvonnasta: on olemassa kaksi lähestymistapaa - luottaa strategisesti matalan tason asiantuntemukseen ja kehitykseen, mikä johtaa valtaviin säästöihin laitteissa, tai käyttää kalliita laitteita, mikä, jos tarkastellaan erityisesti kuluttajan ominaisuuksia, ei käytännössä ole. eroavat vastaavista halvoista.

Miksi on strategisesti tärkeää päättää integraatiolähestymistavan valinnasta mahdollisimman aikaisessa vaiheessa? Laajennusta kehittäessään kehittäjät luottavat tiettyihin teknologioihin (kirjastot, protokollat, standardit). Ja jos joukko tekniikoita valitaan vain kalliille laitteille, niin tulevaisuudessa yritys siirtyä halpoihin kameroihin kestää todennäköisesti vähintään järjettömän kauan tai jopa epäonnistuu ja kalliisiin laitteisiin palataan.

Lähde: will.com