Hallo allerseits!

Es ist wahrscheinlich kein Geheimnis für jemanden, dass Cloud-basierte Videoüberwachungsdienste in letzter Zeit immer beliebter werden. Und es ist verständlich, warum dies passiert. Videos sind „schwere“ Inhalte, für deren Speicherung Infrastruktur und große Mengen an Festplattenspeicher erforderlich sind. Die Verwendung eines lokalen Videoüberwachungssystems erfordert die Mittel zum Betrieb und zur Unterstützung, sowohl im Fall einer Organisation, die Hunderte von Überwachungskameras verwendet, als auch im Fall eines einzelnen Benutzers mit mehreren Kameras.

Cloud-basierte Videoüberwachungssysteme lösen dieses Problem, indem sie Kunden eine vorhandene Videospeicher- und -verarbeitungsinfrastruktur zur Verfügung stellen. Für einen Cloud-basierten Überwachungsclient reicht es aus, die Kamera einfach mit dem Internet zu verbinden und sich an sein Konto in der Cloud zu binden.

Es gibt verschiedene technologische Möglichkeiten, Kameras mit der Cloud zu verbinden. Zweifellos der bequemste und billigste Weg - die Kamera verbindet sich direkt mit der Cloud und arbeitet mit ihr, ohne dass zusätzliche Geräte wie ein Server oder ein Registrar beteiligt sind.

Dazu muss das mit der Cloud arbeitende Softwaremodul auf der Kamera installiert sein. Wenn es sich jedoch um billige Kameras handelt, verfügen diese über sehr begrenzte Hardwareressourcen, die fast zu 100% von der nativen Firmware des Kameraherstellers belegt sind. Für das Cloud-Plug-In sind jedoch keine Ressourcen erforderlich. Entwickler von ivideon haben diesem Problem einen Artikel gewidmet, in dem erklärt wird, warum sie das Plug-in nicht auf billigen Kameras installieren können. Infolgedessen beträgt der Mindestpreis der Kamera 5000 Rubel (80 US-Dollar) und Millionen von Geld, das für Geräte ausgegeben wird.

Wir haben dieses Problem erfolgreich gelöst. Wenn Sie daran interessiert sind, wie - Willkommen unter Katze

Ein bisschen Geschichte

2016 haben wir mit der Entwicklung einer Cloud-basierten Videoüberwachungsplattform für Rostelecom begonnen.

Im Bereich der Kamera-Software haben wir in der ersten Phase den "Standard" -Weg für solche Aufgaben gewählt: Wir haben ein eigenes Plug-In entwickelt, das in der Kamera-Firmware des Anbieters installiert ist und mit unserer Cloud funktioniert. Es ist jedoch erwähnenswert, dass wir während des Entwurfs die leichtesten und effizientesten Lösungen verwendet haben (z. B. einfache C-Implementierung von Protobuf, Libev, Mbedtls und vollständig aufgegebene praktische, aber schwere Bibliotheken wie Boost).

Jetzt gibt es auf dem IP-Kameramarkt keine universellen Integrationslösungen: Jeder Anbieter hat seine eigene Art, das Plugin zu installieren, seine eigenen APIs, damit die Firmware funktioniert, und einen einzigartigen Update-Mechanismus.

Dies bedeutet, dass für jeden Kamerahersteller eine individuelle Ebene der Integrationssoftware entwickelt werden muss. Zum Zeitpunkt des Beginns der Entwicklung ist es ratsam, nur mit dem ersten Anbieter zusammenzuarbeiten, um die Bemühungen des Teams auf die Entwicklung der Logik für die Arbeit mit der Cloud zu konzentrieren.

Der erste Anbieter war Hikvision - einer der weltweit führenden Anbieter auf dem Kameramarkt, der eine gut dokumentierte API und kompetenten technischen technischen Support bietet.

Mit Hikvision-Kameras haben wir unser erstes Pilotprojekt gestartet, die Cloud-Videoüberwachung, Video Comfort.

Fast unmittelbar nach dem Start stellten unsere Benutzer Fragen zur Möglichkeit, billigere Kameras von Drittanbietern an den Dienst anzuschließen.

Ich habe die Option mit der Implementierung der Integrationsschicht für jeden Anbieter fast sofort verworfen - als schlecht skalierbar und mit ernsthaften technischen Anforderungen an die Kamerahardware. Die Kosten für die Kamera, die diese Anforderungen am Eingang erfüllen: ~ 60-70 $

Aus diesem Grund habe ich mich entschlossen, tiefer zu graben - meine Firmware für Kameras aller Hersteller komplett zu erstellen. Dieser Ansatz reduziert die Hardwareanforderungen der Kamera erheblich Die Cloud-Schicht ist um eine Größenordnung effizienter in die Videoanwendung integriert, und die Firmware enthält kein unnötiges Fett.

Und was wichtig ist, wenn Sie mit der Kamera auf niedrigem Niveau arbeiten, ist es möglich, Hardware-AES zu verwenden, das Daten verschlüsselt, ohne eine CPU mit geringem Stromverbrauch zusätzlich zu belasten.

In diesem Moment hatten wir überhaupt nichts. Gar nichts.

Fast alle Anbieter waren nicht bereit, auf so niedrigem Niveau mit uns zusammenzuarbeiten. Es gibt keine Informationen zu Schaltkreisen und Komponenten, es gibt keine offiziellen SDK-Chipsätze und Sensordokumentationen.
Es gibt auch keinen technischen Support.

Antworten auf alle Fragen mussten durch Reverse Engineering erhalten werden - Versuch und Irrtum. Aber wir haben es geschafft.

Die ersten Kameramodelle, bei denen wir die Unebenheiten füllten, waren Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link-Kameras und mehrere supergünstige unbenannte chinesische Kameras.

Technik

Kameras basierend auf dem Hisilicon 3518E-Chipsatz. Die Hardwareeigenschaften der Kameras sind wie folgt:

Wir haben mit ihnen angefangen.

Wir unterstützen derzeit Hisilicon 3516/3518 Chipsätze sowie Ambarella S2L / S2LM. Die Anzahl der Kameramodelle beträgt Dutzende.

Firmware-Zusammensetzung

uboot

uboot ist der Bootloader. Nach dem Einschalten startet er zuerst, initialisiert die Hardware und lädt den Linux-Kernel.

Das Skript zum Laden der Kamera ist ziemlich trivial:

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 

Von den Funktionen wird bootm aufgerufen, dazu später mehr, wenn wir zum Update-Subsystem gelangen.

Achten Sie auf die Zeile mem=38M . Ja, ja, dies ist kein Tippfehler. Dem Linux-Kernel und allen Anwendungen stehen nur 38 Megabyte RAM zur Verfügung.

Neben uboot befindet sich auch ein spezieller Block namens reg_info , der ein DDR-Initialisierungsskript auf niedriger Ebene und eine Reihe von SoC-Systemregistern enthält. Der Inhalt von reg_info hängt vom Modell der Kamera ab. Wenn dies nicht korrekt ist, kann die Kamera uboot nicht einmal herunterladen, sondern hängt bereits in einem sehr frühen Stadium des Ladens.

Als wir ohne die Unterstützung von Anbietern arbeiteten, haben wir diesen Block zunächst einfach von der ursprünglichen Kamera-Firmware kopiert.

Der Linux-Kernel und rootfs

Die Kameras verwenden den Linux-Kernel, der Teil des SDK-Chips ist. In der Regel handelt es sich hierbei nicht um die neuesten Kernel aus dem 3.x-Zweig. Daher müssen wir häufig feststellen, dass die zusätzlichen Hardwaretreiber nicht mit dem verwendeten Kernel kompatibel sind, und sie auf den Kernel zurückportieren Kameras.

Ein weiteres Problem ist die Kernelgröße. Wenn die FLASH-Größe nur 8 MB beträgt, wird jedes Byte im Konto gespeichert. Unsere Aufgabe besteht darin, alle nicht verwendeten Kernelfunktionen sorgfältig zu deaktivieren, um die Größe auf ein Minimum zu reduzieren.

Rootfs ist ein grundlegendes Dateisystem. Es enthält eine busybox , Treiber des WLAN-Moduls, eine Reihe von Standardsystembibliotheken wie libld und libc sowie unsere Entwicklungssoftware, die für die LED-Verwaltungslogik, die Verwaltung der Netzwerkverbindungen und die Aktualisierung der Firmware verantwortlich ist.

Das Root-Dateisystem ist als initramfs mit dem Kernel verbunden, und als Ergebnis der Assembly erhalten wir eine uImage Datei, die sowohl den Kernel als auch rootfs enthält.

Videoanwendung

Der komplexeste und ressourcenintensivste Teil der Firmware ist eine Anwendung, die Video-Audio-Erfassung, Videokodierung, Anpassung von Bildparametern, Implementierung von Videoanalysen, z. B. Bewegungs- oder Tondetektoren, Steuerung der PTZ und Verantwortung für das Umschalten des Tag- und Nachtmodus bietet.

Eine wichtige, ich würde sogar sagen, eine wichtige Funktion - wie die Videoanwendung mit dem Cloud-Plugin interagiert.

Bei herkömmlichen Lösungen (Hersteller-Firmware + Cloud-Plug-In), die mit billiger Hardware nicht funktionieren können, wird das Video in der Kamera mithilfe des RTSP-Protokolls übertragen - und dies ist ein enormer Aufwand: Kopieren und Übertragen von Daten über Socket, zusätzliche Systemaufrufe.

Wir verwenden an dieser Stelle den Shared-Memory-Mechanismus - das Video wird nicht über den Sockel zwischen den Kamerasoftwarekomponenten kopiert oder gesendet, wodurch die bescheidenen Hardwarefunktionen der Kamera optimal und sorgfältig genutzt werden.

Subsystem aktualisieren

Besonders hervorzuheben ist das fehlertolerante Subsystem von Online-Firmware-Updates.

Ich werde die Probleme erklären. Ein Firmware-Update ist technisch gesehen keine atomare Operation. Wenn während des Updates ein Stromausfall auftritt, befindet sich ein Teil der „nicht aufgezeichneten“ neuen Firmware im Flash-Speicher. Wenn Sie keine besonderen Maßnahmen ergreifen, wird die Kamera zu einem "Baustein", der zu einem Servicecenter gebracht werden muss.

Wir haben uns mit diesem Problem befasst. Selbst wenn die Kamera zum Zeitpunkt der Aktualisierung ausgeschaltet ist, wird die Firmware automatisch und ohne Benutzereingriff aus der Cloud heruntergeladen und der Vorgang wiederhergestellt.

Lassen Sie uns die Technik genauer analysieren:

Der anfälligste Punkt ist das Überschreiben der Partition mit dem Linux-Kernel und dem Root-Dateisystem. Wenn sich herausstellt, dass eine dieser Komponenten beschädigt ist, bootet die Kamera überhaupt nicht über den Uboot-Bootloader hinaus, der nicht weiß, wie Firmware aus der Cloud heruntergeladen werden kann.

Daher müssen wir sicherstellen, dass die Kamera während des Aktualisierungsprozesses jederzeit über einen funktionierenden Kernel und Rootfs verfügt. Es scheint, dass die einfachste Lösung darin besteht, zwei Kopien des Kernels mit rootfs dauerhaft im Flash-Speicher zu speichern und im Falle einer Beschädigung des Hauptkerns aus dem Backup zu laden.

Eine gute Lösung - der Kernel mit rootfs benötigt jedoch ungefähr 3,5 MB und für eine dauerhafte Sicherung müssen Sie 3,5 MB zuweisen. Bei den billigsten Kameras gibt es einfach nicht so viel freien Speicherplatz für den Backup-Kernel.

Daher verwenden wir für den Sicherungskern während des Firmware-Updates die Anwendungspartition.
Und um die erforderliche Partition mit dem Kernel auszuwählen, werden zwei bootm in uboot verwendet - zu Beginn versuchen wir, den Hauptkernel zu laden, und wenn er beschädigt ist, dann die Sicherung.

Dies stellt sicher, dass die Kamera jederzeit über den richtigen Kernel mit rootfs verfügt und die Firmware starten und wiederherstellen kann.

CI / CD-System zum Zusammenstellen und Bereitstellen von Firmware

Zum Erstellen der Firmware verwenden wir gitlab CI, bei dem die Firmware für alle unterstützten Kameramodelle automatisch erfasst wird. Nach dem Erstellen der Firmware werden sie automatisch für den Aktualisierungsdienst der Kamerasoftware bereitgestellt.

Vom Service werden Firmware-Updates an die Testkameras unserer Qualitätssicherung und nach Abschluss aller Testphasen an die Kameras der Benutzer geliefert.

Informationssicherheit

Es ist kein Geheimnis, dass Informationssicherheit in unserer Zeit der wichtigste Aspekt jedes IoT-Geräts ist, einschließlich Kameras. Botnets wie Mirai laufen im Internet herum und betreffen Millionen von Kameras mit Standard-Firmware von Anbietern. Bei allem Respekt gegenüber den Kameraherstellern kann ich nur feststellen, dass die Standard-Firmware viele Funktionen bietet, die für die Arbeit mit der Cloud nicht erforderlich sind, aber viele Schwachstellen enthalten, die Botnets verwenden.

Daher sind alle nicht verwendeten Funktionen in unserer Firmware deaktiviert, alle TCP / UDP-Ports sind geschlossen und beim Aktualisieren der Firmware wird die digitale Signatur der Software überprüft.

Außerdem wird die Firmware regelmäßig im Informationssicherheitslabor getestet.

Fazit

Jetzt wird unsere Firmware aktiv in Videoüberwachungsprojekten eingesetzt. Das vielleicht ehrgeizigste von ihnen ist die Ausstrahlung der Abstimmung am Tag der Wahl des Präsidenten der Russischen Föderation.
Das Projekt umfasste mehr als 70.000 Kameras mit unserer Firmware, die in Wahllokalen unseres Landes installiert wurden.

Nachdem wir zu dieser Zeit eine Reihe komplexer und manchmal sogar praktisch unmöglicher Aufgaben gelöst hatten, waren wir als Ingenieure natürlich sehr zufrieden, aber außerdem haben wir beim Kauf von Kameras Millionen von Dollar gespart. In diesem Fall sind Einsparungen nicht nur Wörter und theoretische Berechnungen, sondern auch die Ergebnisse einer bereits durchgeführten Ausschreibung für den Kauf von Geräten. Wenn wir also über Cloud-Videoüberwachung sprechen: Es gibt zwei Ansätze: Strategisch auf geringes Fachwissen und Entwicklung zurückgreifen, enorme Einsparungen bei den Geräten am Ausgang erzielen oder teure Geräte verwenden, die sich, wenn man die Verbrauchereigenschaften betrachtet, praktisch nicht von einem ähnlich billigen unterscheiden.

Warum ist es strategisch wichtig, so früh wie möglich über einen Ansatz für die Integrationsmethode zu entscheiden? Bei der Entwicklung eines Plugins werden Entwickler auf bestimmte Technologien (Bibliotheken, Protokolle, Standards) festgelegt. Und wenn eine Reihe von Technologien nur für teure Geräte ausgewählt wird, wird der Versuch, mit hoher Wahrscheinlichkeit auf billige Kameras umzusteigen, in Zukunft zumindest wahnsinnig lange dauern oder sogar scheitern und zu teuren Geräten zurückkehren.