Hallo iedereen!

Het is waarschijnlijk geen geheim dat cloudvideobewakingsdiensten de laatste tijd aan populariteit winnen. En het is duidelijk waarom dit gebeurt: video is ‘zware’ inhoud, waarvan de opslag infrastructuur en grote hoeveelheden schijfopslag vereist. Het gebruik van een videobewakingssysteem op locatie vereist geld voor de werking en ondersteuning, zowel voor een organisatie die honderden bewakingscamera's gebruikt als voor een individuele gebruiker met meerdere camera's.

Cloud-videobewakingssystemen lossen dit probleem op door klanten te voorzien van een bestaande video-opslag- en verwerkingsinfrastructuur. Een klant voor videobewaking in de cloud hoeft alleen maar de camera met internet te verbinden en deze aan zijn cloudaccount te koppelen.

Er zijn verschillende technologische manieren om camera’s met de cloud te verbinden. De handigste en goedkoopste methode is ongetwijfeld dat de camera rechtstreeks verbinding maakt en werkt met de cloud, zonder de deelname van extra apparatuur zoals een server of recorder.

Hiervoor is het noodzakelijk dat er een softwaremodule die met de cloud werkt op de camera wordt geïnstalleerd. Als we het echter over goedkope camera's hebben, dan hebben ze zeer beperkte hardwarebronnen, die bijna 100% worden bezet door de native firmware van de cameraleverancier, en zijn er geen bronnen nodig voor de cloudplug-in. Ontwikkelaars van ivideon hebben dit probleem gewijd статью, wat verklaart waarom ze de plug-in niet op goedkope camera's kunnen installeren. Als gevolg hiervan is de minimumprijs van de camera 5000 roebel ($80 dollar) en worden er miljoenen geld uitgegeven aan apparatuur.

Wij hebben dit probleem succesvol opgelost. Als je geïnteresseerd bent in hoe, welkom bij de cut

Een beetje geschiedenis

In 2016 zijn we begonnen met de ontwikkeling van een cloudvideobewakingsplatform voor Rostelecom.

Wat de camerasoftware betreft, volgden we in de eerste fase het “standaard” pad voor dergelijke taken: we ontwikkelden onze eigen plug-in, die wordt geïnstalleerd in de standaardfirmware van de camera van de leverancier en werkt met onze cloud. Het is echter vermeldenswaard dat we tijdens het ontwerp de meest lichtgewicht en efficiënte oplossingen hebben gebruikt (bijvoorbeeld een eenvoudige C-implementatie van protobuf, libev, mbedtls en volledig verlaten handige maar zware bibliotheken zoals boost)

Momenteel zijn er geen universele integratieoplossingen op de IP-cameramarkt: elke leverancier heeft zijn eigen manier om de plug-in te installeren, zijn eigen set API's voor het bedienen van de firmware en een uniek updatemechanisme.

Dit betekent dat het voor elke cameraleverancier noodzakelijk is om individueel een uitgebreide laag integratiesoftware te ontwikkelen. En op het moment dat de ontwikkeling begint, is het raadzaam om slechts met één leverancier te werken, zodat de inspanningen van het team kunnen worden geconcentreerd op het ontwikkelen van de logica voor het werken met de cloud.

De eerste gekozen leverancier was Hikvision, een van de wereldleiders op de cameramarkt, die een goed gedocumenteerde API en competente technische ondersteuning bood.

We lanceerden ons eerste proefproject, cloudvideobewaking Video Comfort, met behulp van Hikvision-camera's.

Vrijwel onmiddellijk na de lancering begonnen onze gebruikers vragen te stellen over de mogelijkheid om goedkopere camera's van andere fabrikanten op de dienst aan te sluiten.

Ik heb de optie om voor elke leverancier een integratielaag te implementeren vrijwel onmiddellijk afgewezen, omdat deze slecht schaalbaar is en ernstige technische eisen stelt aan de camerahardware. De kosten van een camera die aan deze invoervereisten voldoet: ~60-70$

Daarom besloot ik dieper te graven - om mijn eigen firmware voor camera's van welke leverancier dan ook te maken. Deze aanpak vermindert de vereisten voor camerahardwarebronnen aanzienlijk - omdat De laag voor het werken met de cloud is veel effectiever geïntegreerd met de videoapplicatie en er zit geen onnodig ongebruikt vet in de firmware.

En wat belangrijk is, is dat wanneer je op een laag niveau met de camera werkt, het mogelijk is om hardware-AES te gebruiken, die gegevens codeert zonder extra belasting te creëren voor de energiezuinige CPU.

Op dat moment hadden we helemaal niets. Helemaal niets.

Bijna alle leveranciers waren niet bereid om op zo’n laag niveau met ons samen te werken. Er is geen informatie over de circuits en componenten, er is geen officiële SDK van chipsets en sensordocumentatie.
Er is ook geen technische ondersteuning.

Alle vragen moesten worden beantwoord via reverse engineering: vallen en opstaan. Maar het is ons gelukt.

De eerste cameramodellen waarop we testten waren Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link-camera's en verschillende ultragoedkope naamloze Chinese camera's.

Techniek

Camera's gebaseerd op Hisilicon 3518E-chipset. De hardwarekenmerken van de camera's zijn als volgt:

Xiaomi Yi-mieren
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Microfoon
+
+

Spreker
+
+

IRLed
+
+

IRCut
+
+

Wij zijn met hen begonnen.

We ondersteunen momenteel Hisilicon 3516/3518-chipsets, evenals Ambarella S2L/S2LM. Er zijn tientallen cameramodellen.

Firmware-samenstelling

opstarten

uboot is de bootloader, deze start eerst op na het inschakelen, initialiseert de hardware en laadt de Linux-kernel.

Het cameralaadscript is vrij 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 0x82000000

Een van de kenmerken is dat het twee keer wordt aangeroepen bootm, hierover later meer, als we bij het update-subsysteem komen.

Let op de lijn mem=38M. Ja, ja, dit is geen typefout - de Linux-kernel en alle, alle, alle applicaties hebben toegang tot slechts 38 megabytes RAM.

Ook naast uboot is er een speciaal blok genaamd reg_info, dat een low-level script bevat voor het initialiseren van DDR en een aantal systeemregisters van de SoC. Inhoud reg_info hangt af van het cameramodel, en als het niet correct is, kan de camera niet eens tijdens het opstarten worden geladen, maar loopt hij vast in een zeer vroeg stadium van het laden.

Toen we in eerste instantie zonder ondersteuning van leveranciers werkten, kopieerden we dit blok eenvoudigweg van de originele camerafirmware.

Linux-kernel en rootfs

De camera's gebruiken de Linux-kernel, die deel uitmaakt van de SDK van de chip; meestal zijn dit niet de nieuwste kernels uit de 3.x-tak, waardoor we vaak te maken hebben met het feit dat stuurprogramma's voor extra apparatuur niet compatibel zijn met de gebruikte kernel , en we moeten ze back-porten naar de kernelcamera's.

Een ander probleem is de grootte van de kernel. Als de FLASH-grootte slechts 8 MB bedraagt, telt elke byte en is het onze taak om zorgvuldig alle ongebruikte kernelfuncties uit te schakelen om de grootte tot een minimum te beperken.

Rootfs is een basisbestandssysteem. Het bevat busybox, stuurprogramma's voor wifi-modules, een reeks standaardsysteembibliotheken, zoals libld и libc, evenals onze software, die verantwoordelijk is voor de LED-besturingslogica, netwerkverbindingsbeheer en firmware-updates.

Het rootbestandssysteem is als initramfs met de kernel verbonden en als resultaat van de build krijgen we één bestand uImage, die zowel de kernel als rootfs bevat.

Videotoepassing

Het meest complexe en resource-intensieve deel van de firmware is de applicatie, die video-audio-opname en videocodering biedt, beeldparameters configureert, video-analyses implementeert, bijvoorbeeld bewegings- of geluidsdetectoren, PTZ bestuurt en verantwoordelijk is voor het schakelen van dag- en nachtmodi.

Een belangrijke, ik zou zelfs zeggen sleutelfunctie, is hoe de videoapplicatie samenwerkt met de cloudplug-in.

In traditionele oplossingen 'vendor firmware + cloud plugin', die niet kunnen werken op goedkope hardware, wordt video in de camera verzonden via het RTSP-protocol - en dit is een enorme overhead: het kopiëren en verzenden van gegevens via socket, onnodige systeemaanroepen.

Hier gebruiken we het gedeelde geheugenmechanisme - de video wordt niet gekopieerd of verzonden via een socket tussen de camerasoftwarecomponenten, waardoor optimaal en zorgvuldig gebruik wordt gemaakt van de bescheiden hardwaremogelijkheden van de camera.

Subsysteem bijwerken

Een punt van bijzondere trots is het fouttolerante subsysteem voor online firmware-updates.

Laat me het probleem uitleggen. Het updaten van de firmware is technisch gezien geen atomaire handeling, en als er midden in de update een stroomstoring optreedt, zal het flashgeheugen een deel van de “onderschreven” nieuwe firmware bevatten. Als u geen speciale maatregelen neemt, wordt de camera een ‘steen’ die naar een servicecentrum moet worden gebracht.

Wij hebben dit probleem ook aangepakt. Zelfs als de camera tijdens de update wordt uitgeschakeld, zal deze automatisch en zonder tussenkomst van de gebruiker de firmware uit de cloud downloaden en de werking herstellen.

Laten we de techniek in meer detail bekijken:

Het meest kwetsbare punt is het overschrijven van de partitie met de Linux-kernel en het rootbestandssysteem. Als een van deze componenten beschadigd is, zal de camera helemaal niet opstarten buiten de uboot-bootloader, die geen firmware uit de cloud kan downloaden.

Dit betekent dat we ervoor moeten zorgen dat de camera op elk moment tijdens het updateproces een werkende kernel en rootfs heeft. Het lijkt erop dat de eenvoudigste oplossing zou zijn om voortdurend twee kopieën van de kernel met rootfs op flash-geheugen op te slaan en, als de hoofdkernel beschadigd is, deze vanaf de back-up te laden.

Een goede oplossing - de kernel met rootfs neemt echter ongeveer 3.5 MB in beslag en voor een permanente back-up moet je 3.5 MB toewijzen. De goedkoopste camera's hebben simpelweg niet zoveel vrije ruimte voor een back-upkernel.

Om tijdens een firmware-update een back-up van de kernel te maken, gebruiken we daarom de applicatiepartitie.
En om de gewenste partitie met de kernel te selecteren, worden twee opdrachten gebruikt bootm in uboot - in het begin proberen we de hoofdkernel te laden en als deze beschadigd is, dan de back-up.

Dit zorgt ervoor dat de camera op elk moment de juiste kernel met rootfs heeft, en dat hij in staat zal zijn om op te starten en de firmware te herstellen.

CI/CD-systeem voor het bouwen en implementeren van firmware

Om firmware te bouwen gebruiken we gitlab CI, dat automatisch firmware bouwt voor alle ondersteunde cameramodellen, en na het bouwen van de firmware wordt deze automatisch geïmplementeerd in de camerasoftware-updateservice.

Vanuit de service worden firmware-updates geleverd aan onze QA-testcamera's en, na voltooiing van alle testfasen, aan de camera's van gebruikers.

Informatiebeveiliging

Het is geen geheim dat informatiebeveiliging tegenwoordig het belangrijkste aspect is van elk IoT-apparaat, inclusief camera's. Botnets zoals Mirai zwerven over het internet en infecteren miljoenen camera's met standaardfirmware van leveranciers. Met alle respect voor cameraleveranciers kan ik niet anders dan constateren dat standaardfirmware veel functionaliteit bevat die niet nodig is voor het werken met de cloud, maar veel kwetsbaarheden bevat waar botnets misbruik van maken.

Daarom is alle ongebruikte functionaliteit in onze firmware uitgeschakeld, zijn alle tcp/udp-poorten gesloten en wordt bij het updaten van de firmware de digitale handtekening van de software gecontroleerd.

En daarnaast wordt de firmware regelmatig getest in het informatiebeveiligingslaboratorium.

Conclusie

Nu wordt onze firmware actief gebruikt in videobewakingsprojecten. Misschien wel de grootste daarvan is de uitzending van de stemming op de dag van de verkiezing van de president van de Russische Federatie.
Bij het project waren ruim 70 camera’s met onze firmware betrokken, die bij stembureaus in ons land werden geïnstalleerd.

Nadat we een aantal complexe en op sommige plaatsen zelfs toen bijna onmogelijke problemen hadden opgelost, kregen we als ingenieurs uiteraard grote voldoening, maar daarnaast bespaarden we ook miljoenen dollars op de aanschaf van camera's. En in dit geval zijn de besparingen niet alleen woorden en theoretische berekeningen, maar de resultaten van een reeds voltooide aanbesteding voor de aanschaf van apparatuur. Als we het dus hebben over videobewaking in de cloud: er zijn twee benaderingen: strategisch vertrouwen op expertise en ontwikkeling op een laag niveau, wat resulteert in enorme besparingen op apparatuur, of dure apparatuur gebruiken, wat, als je specifiek naar de kenmerken van de consument kijkt, praktisch geen optie is. anders dan soortgelijke goedkope.

Waarom is het van strategisch belang om zo vroeg mogelijk te beslissen over de keuze voor een integratieaanpak? Bij het ontwikkelen van een plug-in vertrouwen ontwikkelaars op bepaalde technologieën (bibliotheken, protocollen, standaarden). En als een reeks technologieën alleen voor dure apparatuur wordt gekozen, zal een poging om over te stappen op goedkope camera's in de toekomst hoogstwaarschijnlijk op zijn minst waanzinnig lang duren of zelfs mislukken en zal er een terugkeer naar dure apparatuur plaatsvinden.

Bron: www.habr.com