Hallo an alle!

Es ist wahrscheinlich kein Geheimnis, dass Cloud-Videoüberwachungsdienste in letzter Zeit immer beliebter werden. Und der Grund dafür ist klar: Videos sind „schwere“ Inhalte, deren Speicherung eine entsprechende Infrastruktur und große Mengen an Festplattenspeicher erfordert. Die Verwendung eines lokalen Videoüberwachungssystems erfordert Mittel für Betrieb und Support, sowohl im Fall einer Organisation, die Hunderte von Überwachungskameras verwendet, als auch im Fall eines einzelnen Benutzers mit mehreren Kameras.

Cloudbasierte Videoüberwachungssysteme lösen dieses Problem, indem sie den Kunden eine vorhandene Infrastruktur zum Speichern und Verarbeiten von Videos zur Verfügung stellen. Ein Kunde der Cloud-Videoüberwachung muss die Kamera lediglich mit dem Internet verbinden und mit seinem Cloud-Konto verknüpfen.

Es gibt verschiedene technologische Methoden, um Kameras mit der Cloud zu verbinden. Die bequemste und kostengünstigste Methode ist zweifellos die direkte Verbindung und der Betrieb der Kamera mit der Cloud, ohne dass zusätzliche Geräte wie z. B. … erforderlich sind. Server oder Standesbeamter.

Dazu muss auf der Kamera ein Softwaremodul installiert sein, das mit der Cloud funktioniert. Wenn wir jedoch über billige Kameras sprechen, verfügen diese über sehr begrenzte Hardwareressourcen, die fast zu 100 % von der nativen Firmware des Kameraherstellers belegt sind, und für das Cloud-Plugin sind keine Ressourcen erforderlich. Die Entwickler von ivideon haben diesem Problem viel Arbeit gewidmet. Artikel, was erklärt, warum sie das Plugin nicht auf billigen Kameras installieren können. Infolgedessen beträgt der Mindestpreis der Kamera 5000 Rubel (80 Dollar) und es werden Millionenbeträge für die Ausrüstung ausgegeben.

Wir haben dieses Problem erfolgreich gelöst. Wenn Sie daran interessiert sind, wie, willkommen unter dem Schnitt

Ein wenig Geschichte

Im Jahr 2016 begannen wir mit der Entwicklung einer Cloud-Videoüberwachungsplattform für Rostelecom.

In Bezug auf die Kamerasoftware haben wir im ersten Schritt den „Standardweg“ für solche Aufgaben gewählt: Wir haben ein eigenes Plug-In entwickelt, das in der Standard-Kamera-Firmware des Anbieters installiert wird 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. eine einfache C-Implementierung von Protobuf, Libev, Mbedtls und den vollständigen Verzicht auf praktische, aber schwere Bibliotheken wie Boost).

Derzeit gibt es auf dem IP-Kameramarkt keine universellen Integrationslösungen: Jeder Anbieter verfügt über seine eigene Methode zur Installation eines Plug-Ins, seinen eigenen Satz von APIs für den Firmware-Betrieb und einen einzigartigen Aktualisierungsmechanismus.

Dies bedeutet, dass für jeden Kameraanbieter individuell eine große Ebene an Integrationssoftware entwickelt werden muss. Und zu Beginn der Entwicklung ist es ratsam, mit nur einem Anbieter zusammenzuarbeiten, um die Bemühungen des Teams auf die Entwicklung der Logik für die Arbeit mit der Cloud zu konzentrieren.

Als erster Anbieter wurde Hikvision ausgewählt, einer der weltweit führenden Anbieter im Kameramarkt, der eine gut dokumentierte API und kompetenten technischen Support bietet.

Wir haben unser erstes Pilotprojekt, die Cloud-Videoüberwachung Videocomfort, mit Hikvision-Kameras gestartet.

Fast unmittelbar nach dem Start begannen unsere Benutzer, Fragen zur Möglichkeit zu stellen, günstigere Kameras anderer Hersteller an den Dienst anzuschließen.

Die Möglichkeit, für jeden Anbieter eine eigene Integrationsschicht zu implementieren, habe ich fast sofort verworfen, da sie schlecht skalierbar ist und erhebliche technische Anforderungen an die Kamera-Hardware stellt. Die Kosten für eine Kamera, die diese Einstiegsvoraussetzungen erfüllt: ~60-70$

Deshalb habe ich beschlossen, tiefer zu graben und meine eigene Firmware für Kameras beliebiger Hersteller zu erstellen. Dieser Ansatz reduziert die Anforderungen an die Hardwareressourcen der Kamera erheblich, da die Cloud-Schicht viel effektiver in die Videoanwendung integriert ist und die Firmware keinen zusätzlichen ungenutzten Ballast aufweist.

Und was wichtig ist: Beim Arbeiten mit der Kamera auf niedrigem Niveau ist die Verwendung von Hardware-AES möglich, das Daten verschlüsselt, ohne die stromsparende CPU zusätzlich zu belasten.

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

Fast alle Anbieter waren nicht bereit, auf einem so niedrigen Niveau mit uns zusammenzuarbeiten. Es gibt keine Informationen zu den Schaltkreisen und Komponenten, kein offizielles SDK für die Chipsätze oder Dokumentation für die Sensoren.
Es gibt auch keinen technischen Support.

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

Die ersten Kameramodelle, bei denen wir unsere Lektion gelernt haben, waren Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link und mehrere superbillige No-Name-Kameras aus China.

Ausrüstung

Kameras auf Hisilicon 3518E-Chipsatz. Die Hardwarespezifikationen der Kameras sind wie folgt:

Xiaomi Yi Ameisen
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

BLINKEN
16MB
8MB

WLAN
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Speaker
+
+

Im echten Leben
+
+

IRCut
+
+

Wir haben mit ihnen angefangen.

Wir unterstützen derzeit Hisilicon 3516/3518-Chipsätze sowie Ambarella S2L/S2LM. Es gibt Dutzende von Kameramodellen.

Firmware-Zusammensetzung

uboot

uboot ist der Bootloader, er bootet zuerst nach dem Einschalten, 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

Eine der Besonderheiten besteht darin, dass es zweimal aufgerufen wird. bootm, mehr dazu etwas später, wenn wir zum Update-Subsystem kommen.

Achten Sie auf die Linie mem=38MJa, ja, das ist kein Tippfehler – der Kernel Linux und alle Anwendungen haben nur Zugriff auf 38 Megabyte RAM.

Außerdem gibt es neben uboot einen speziellen Block namens reg_info, das ein Low-Level-Skript zum Initialisieren von DDR und einer Reihe von SoC-Systemregistern enthält. Inhalt reg_info hängt vom Kameramodell ab. Wenn es nicht korrekt ist, kann die Kamera Uboot nicht einmal laden, sondern friert bereits im frühesten Ladestadium ein.

Als wir zunächst ohne Herstellerunterstützung arbeiteten, haben wir diesen Block einfach aus der Original-Firmware der Kamera kopiert.

Linux-Kernel und RootFS

Die Kameras verwenden einen Kern Linux, das Teil des Chip-SDK ist, sind in der Regel nicht die neuesten Kernel aus dem 3.x-Zweig, daher kommt es häufig vor, dass die Treiber für zusätzliche Geräte nicht mit dem verwendeten Kernel kompatibel sind und wir sie auf den Kamerakernel zurückportieren müssen.

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

Rootfs ist ein Basisdateisystem. Es beinhaltet busybox, WLAN-Modultreiber, eine Reihe von Standardsystembibliotheken, wie z. B. libld и libc, sowie Software aus unserem eigenen Design, die für die LED-Steuerungslogik, das Netzwerkverbindungsmanagement und Firmware-Updates verantwortlich ist.

Das Root-Dateisystem ist als initramfs mit dem Kernel verbunden und als Ergebnis des Builds erhalten wir eine Datei uImage, das sowohl den Kernel als auch das Root-FS enthält.

Videobewerbung

Der komplexeste und ressourcenintensivste Teil der Firmware ist die Anwendung, die Video- und Audioaufnahme sowie Videokodierung bereitstellt, Bildparameter konfiguriert, Videoanalysen wie Bewegungs- oder Geräuschmelder implementiert, PTZ steuert und für die Umschaltung zwischen Tag- und Nachtmodus verantwortlich ist.

Ein wichtiges, ich würde sogar sagen zentrales Feature ist die Art und Weise, wie die Videoanwendung mit dem Cloud-Plugin interagiert.

Bei herkömmlichen Lösungen mit „Hersteller-Firmware + Cloud-Plugin“, die auf billiger Hardware nicht funktionieren, wird das Video innerhalb der Kamera über das RTSP-Protokoll übertragen – und das ist ein enormer Aufwand: Kopieren und Übertragen von Daten über Socket, zusätzliche Systemaufrufe.

An dieser Stelle verwenden wir den Shared-Memory-Mechanismus – das Video wird nicht kopiert oder über Sockets zwischen den Softwarekomponenten der Kamera gesendet, wodurch die bescheidenen Hardwarefunktionen der Kamera optimal und sorgfältig genutzt werden.

Subsystem aktualisieren

Ein besonderer Grund zum Stolz ist das fehlertolerante Online-Subsystem zur Firmware-Aktualisierung.

Lassen Sie mich das Problem erklären. Das Aktualisieren der Firmware ist technisch gesehen kein atomarer Vorgang. Wenn während des Updates ein Stromausfall auftritt, enthält der Flash-Speicher einen Teil der „ungeschriebenen“ neuen Firmware. Wenn Sie keine besonderen Maßnahmen ergreifen, wird die Kamera zu einem „Baustein“, der zu einem Servicecenter gebracht werden muss.

Auch wir haben uns mit diesem Problem befasst. Auch wenn die Kamera während der Aktualisierung ausgeschaltet wird, lädt sie automatisch und ohne Benutzereingriff die Firmware aus der Cloud herunter und stellt den Betrieb wieder her.

Schauen wir uns die Technik genauer an:

Der kritischste Moment ist das Überschreiben der Kernel-Partition. Linux und das Root-Dateisystem. Wenn eine dieser Komponenten beschädigt ist, startet die Kamera nicht über den Ubuntu-Bootloader hinaus, wodurch die Firmware nicht aus der Cloud heruntergeladen werden kann.

Das bedeutet, dass wir während des gesamten Aktualisierungsvorgangs sicherstellen müssen, dass die Kamera über einen funktionierenden Kernel und ein funktionierendes Root-FS verfügt. Die einfachste Lösung scheint darin zu bestehen, ständig zwei Kopien des Kernels mit Root-FS im Flash-Speicher zu speichern und ihn im Falle einer Beschädigung des Hauptkernels aus der Sicherungskopie zu laden.

Eine gute Lösung – allerdings benötigt der Kernel mit RootFS etwa 3.5 MB und für eine dauerhafte Sicherung müssen Sie 3.5 MB zuweisen. Die billigsten Kameras haben einfach nicht genügend freien Speicherplatz für eine Kernsicherung.

Daher verwenden wir für die Kernelsicherung während der Firmware-Aktualisierung die Anwendungspartition.
Und um die gewünschte Partition mit dem Kernel auszuwählen, werden zwei Befehle verwendet bootm in uboot versuchen wir zuerst, den Hauptkernel zu laden und wenn dieser beschädigt ist, dann den Backup-Kernel.

Dadurch wird sichergestellt, dass die Kamera jederzeit über einen korrekten Kernel mit Root-FS verfügt und die Firmware booten und wiederherstellen kann.

CI/CD-System zum Erstellen und Bereitstellen von Firmware

Zum Erstellen der Firmware verwenden wir Gitlab CI, das automatisch Firmware für alle unterstützten Kameramodelle erstellt. Anschließend wird die Firmware automatisch im Software-Update-Dienst der Kamera bereitgestellt.

Vom Software-Update-Dienst wird die Firmware an unsere QA-Testkameras und nach Abschluss aller Testphasen an die Kameras der Benutzer geliefert.

Informationssicherheit

Es ist kein Geheimnis, dass Informationssicherheit heutzutage der wichtigste Aspekt jedes IoT-Geräts ist, einschließlich einer Kamera. Im Internet kursieren Botnetze wie Mirai, die Millionen von Kameras mit Standard-Firmware von Herstellern infizieren. Bei allem Respekt gegenüber den Kameraherstellern muss ich jedoch anmerken, dass die Standard-Firmware viele Funktionen enthält, die für die Arbeit mit der Cloud nicht erforderlich sind, dafür aber viele Schwachstellen aufweist, die von Botnetzen ausgenutzt werden.

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

Darüber hinaus wird die Firmware regelmäßig im Informationssicherheitslabor getestet.

Fazit

Jetzt wird unsere Firmware aktiv in Videoüberwachungsprojekten verwendet. Die vielleicht umfangreichste davon ist die Übertragung der Abstimmung am Tag der Präsidentschaftswahlen der Russischen Föderation.
Das Projekt umfasste mehr als 70 Kameras mit unserer Firmware, die in Wahllokalen in unserem Land installiert wurden.

Nachdem wir eine Reihe komplexer und an manchen Stellen sogar zu dieser Zeit praktisch unmöglicher Probleme gelöst hatten, waren wir als Ingenieure natürlich sehr zufrieden, aber darüber hinaus sparten wir auch Millionen von Dollar beim Kauf von Kameras. Und in diesem Fall sind Einsparungen nicht nur Worte und theoretische Berechnungen, sondern das Ergebnis einer bereits abgeschlossenen Ausschreibung für den Kauf von Geräten. Wenn wir also über Cloud-Videoüberwachung sprechen, gibt es zwei Ansätze: Entweder man verlässt sich strategisch auf Fachwissen und Entwicklung auf niedrigem Niveau und erhält dadurch enorme Einsparungen bei der Ausrüstung, oder man verwendet teure Ausrüstung, die sich hinsichtlich der Verbrauchereigenschaften praktisch nicht von ähnlicher billiger Ausrüstung unterscheidet.

Warum ist es strategisch wichtig, möglichst früh eine Entscheidung über die Wahl des Ansatzes bzw. der Integrationsmethode zu treffen? Bei der Entwicklung eines Plugins sind Entwickler auf bestimmte Technologien (Bibliotheken, Protokolle, Standards) angewiesen. Und wenn ein Technologie-Set nur für teure Geräte ausgewählt wird, dann wird ein Versuch, in Zukunft auf billige Kameras umzusteigen, höchstwahrscheinlich zumindest wahnsinnig lange dauern oder sogar scheitern und es wird eine Rückkehr zu teuren Geräten geben.

Source: habr.com