Bonjour à tous!

Ce n’est probablement un secret pour personne que les services de vidéosurveillance dans le cloud ont récemment gagné en popularité. Et la raison pour laquelle cela se produit est claire : la vidéo est un contenu « lourd », dont le stockage nécessite une infrastructure et de grandes quantités de stockage sur disque. L’utilisation d’un système de vidéosurveillance sur site nécessite des fonds pour son fonctionnement et son support, à la fois pour une organisation utilisant des centaines de caméras de surveillance et pour un utilisateur individuel disposant de plusieurs caméras.

Les systèmes de vidéosurveillance cloud résolvent ce problème en fournissant aux clients une infrastructure de stockage et de traitement vidéo existante. Un client de vidéosurveillance cloud doit simplement connecter la caméra à Internet et la lier à son compte cloud.

Il existe plusieurs moyens technologiques pour connecter des caméras au cloud. Sans aucun doute, la méthode la plus pratique et la moins chère est que la caméra se connecte et fonctionne directement avec le cloud, sans la participation d'équipements supplémentaires tels qu'un serveur ou un enregistreur.

Pour ce faire, il est nécessaire qu'un module logiciel fonctionnant avec le cloud soit installé sur la caméra. Cependant, si nous parlons de caméras bon marché, elles disposent de ressources matérielles très limitées, qui sont occupées à près de 100 % par le firmware natif du fournisseur de caméras, et aucune ressource n'est nécessaire pour le plugin cloud. Les développeurs d'ivideon ont consacré ce problème статью, ce qui explique pourquoi ils ne peuvent pas installer le plugin sur des caméras bon marché. En conséquence, le prix minimum de la caméra est de 5000 80 roubles (XNUMX dollars) et des millions d'argent sont dépensés en équipement.

Nous avons résolu ce problème avec succès. Si vous êtes intéressé par comment - bienvenue dans la coupe

Un peu d'histoire

En 2016, nous avons commencé à développer une plateforme de vidéosurveillance cloud pour Rostelecom.

En termes de logiciel de caméra, dans un premier temps, nous avons suivi la voie « standard » pour de telles tâches : nous avons développé notre propre plugin, qui est installé dans le firmware standard de la caméra du fournisseur et fonctionne avec notre cloud. Cependant, il convient de noter que lors de la conception, nous avons utilisé les solutions les plus légères et les plus efficaces (par exemple, l'implémentation en C simple de protobuf, libev, mbedtls et des bibliothèques complètement abandonnées, pratiques mais lourdes comme boost)

Actuellement, il n'existe pas de solutions d'intégration universelles sur le marché des caméras IP : chaque fournisseur a sa propre manière d'installer le plugin, son propre ensemble d'API pour faire fonctionner le micrologiciel et un mécanisme de mise à jour unique.

Cela signifie que pour chaque fournisseur de caméras, il est nécessaire de développer individuellement une couche complète de logiciel d'intégration. Et au moment du démarrage du développement, il est conseillé de travailler avec un seul fournisseur afin de concentrer les efforts de l'équipe sur le développement de la logique de travail avec le cloud.

Le premier fournisseur choisi a été Hikvision, l'un des leaders mondiaux sur le marché des caméras, fournissant une API bien documentée et un support technique d'ingénierie compétent.

Nous avons lancé notre premier projet pilote, la vidéosurveillance cloud Video Comfort, à l'aide de caméras Hikvision.

Presque immédiatement après le lancement, nos utilisateurs ont commencé à poser des questions sur la possibilité de connecter au service des caméras moins chères d'autres fabricants.

J'ai rejeté presque immédiatement l'option de mettre en œuvre une couche d'intégration pour chaque fournisseur - car elle est peu évolutive et impose de sérieuses exigences techniques sur le matériel de la caméra. Le coût d'une caméra qui répond à ces exigences d'entrée : ~60-70$

Par conséquent, j'ai décidé d'aller plus loin - de créer mon propre firmware pour les caméras de n'importe quel fournisseur. Cette approche réduit considérablement les besoins en ressources matérielles de la caméra, car La couche permettant de travailler avec le cloud est intégrée beaucoup plus efficacement à l'application vidéo et il n'y a pas de graisse inutile et inutilisée dans le firmware.

Et ce qui est important, c'est que lorsque l'on travaille avec la caméra à un niveau bas, il est possible d'utiliser le matériel AES, qui crypte les données sans créer de charge supplémentaire sur le processeur basse consommation.

A ce moment-là, nous n'avions rien du tout. Rien du tout.

Presque tous les fournisseurs n’étaient pas prêts à travailler avec nous à un niveau aussi bas. Il n'y a aucune information sur les circuits et les composants, il n'y a pas de SDK officiel des chipsets ni de documentation sur les capteurs.
Il n’y a pas non plus de support technique.

Il a fallu répondre à toutes les questions par l’ingénierie inverse, par essais et erreurs. Mais nous avons réussi.

Les premiers modèles de caméras que nous avons testés étaient les caméras Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link et plusieurs caméras chinoises anonymes ultra bon marché.

Technique

Caméras basées sur le chipset Hisilicon 3518E. Les caractéristiques matérielles des caméras sont les suivantes :

Fourmis Xiaomi Yi
noname

SoC
Hisilicium 3518E
Hisilicium 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Capteur
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Microphone
+
+

Speaker
+
+

IRLed
+
+

IRCoupe
+
+

Nous avons commencé avec eux.

Nous prenons actuellement en charge les chipsets Hisilicon 3516/3518, ainsi qu'Ambarella S2L/S2LM. Il existe des dizaines de modèles d'appareils photo.

Composition du micrologiciel

sous-marin

uboot est le chargeur de démarrage, il démarre d'abord après la mise sous tension, initialise le matériel et charge le noyau Linux.

Le script de chargement de la caméra est assez 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

L'une des caractéristiques est qu'il est appelé deux fois bootm, nous en reparlerons un peu plus tard, lorsque nous arriverons au sous-système de mise à jour.

Faites attention à la ligne mem=38M. Oui, oui, ce n'est pas une faute de frappe - le noyau Linux et toutes les applications n'ont accès qu'à 38 Mo de RAM.

À côté de uboot se trouve également un bloc spécial appelé reg_info, qui contient un script de bas niveau pour initialiser le DDR et un certain nombre de registres système du SoC. Contenu reg_info Cela dépend du modèle de caméra, et si ce n'est pas correct, la caméra ne pourra même pas charger uboot, mais se bloquera au tout début du chargement.

Au début, lorsque nous travaillions sans l'assistance d'un fournisseur, nous copiions simplement ce bloc du firmware d'origine de l'appareil photo.

Noyau Linux et rootfs

Les caméras utilisent le noyau Linux, qui fait partie du SDK de la puce ; ce ne sont généralement pas les derniers noyaux de la branche 3.x, nous devons donc souvent faire face au fait que les pilotes pour les équipements supplémentaires ne sont pas compatibles avec le noyau utilisé , et nous devons les rétroporter sur les caméras du noyau.

Un autre problème est la taille du noyau. Lorsque la taille du FLASH n'est que de 8 Mo, alors chaque octet compte et notre tâche consiste à désactiver soigneusement toutes les fonctions inutilisées du noyau afin de réduire la taille au minimum.

Rootfs est un système de fichiers de base. Il comprend busybox, les pilotes de module wifi, un ensemble de bibliothèques système standard, telles que libld и libc, ainsi que notre logiciel, responsable de la logique de contrôle des LED, de la gestion des connexions réseau et des mises à jour du firmware.

Le système de fichiers racine est connecté au noyau en tant qu'initramfs et à la suite de la construction, nous obtenons un fichier uImage, qui contient à la fois le noyau et rootfs.

Application vidéo

La partie la plus complexe et la plus gourmande en ressources du micrologiciel est l'application, qui assure la capture vidéo-audio, l'encodage vidéo, configure les paramètres d'image, met en œuvre l'analyse vidéo, par exemple des détecteurs de mouvement ou de son, contrôle le PTZ et est responsable de la commutation jour et modes nuit.

Une fonctionnalité importante, je dirais même clé, est la façon dont l’application vidéo interagit avec le plugin cloud.

Dans les solutions traditionnelles « firmware fournisseur + plugin cloud », qui ne peuvent pas fonctionner sur du matériel bon marché, la vidéo à l'intérieur de la caméra est transmise via le protocole RTSP - et cela représente une énorme surcharge : copie et transmission de données via socket, appels système inutiles.

Ici, nous utilisons le mécanisme de mémoire partagée - la vidéo n'est pas copiée ou envoyée via un socket entre les composants logiciels de la caméra, utilisant ainsi de manière optimale et prudente les modestes capacités matérielles de la caméra.

Mettre à jour le sous-système

Un point de fierté particulier est le sous-système tolérant aux pannes pour les mises à jour du micrologiciel en ligne.

Laissez-moi vous expliquer le problème. La mise à jour du micrologiciel n'est techniquement pas une opération atomique, et si une panne de courant se produit au milieu de la mise à jour, la mémoire flash contiendra une partie du nouveau micrologiciel « sous-écrit ». Si vous ne prenez pas de mesures particulières, la caméra deviendra alors une « brique » qu’il faudra apporter à un centre de service.

Nous avons également résolu ce problème. Même si la caméra est éteinte pendant la mise à jour, elle téléchargera automatiquement et sans intervention de l'utilisateur le micrologiciel depuis le cloud et restaurera le fonctionnement.

Regardons la technique plus en détail :

Le point le plus vulnérable est l'écrasement de la partition avec le noyau Linux et le système de fichiers racine. Si l'un de ces composants est endommagé, la caméra ne démarrera pas du tout au-delà du chargeur de démarrage uboot, qui ne peut pas télécharger le firmware depuis le cloud.

Cela signifie que nous devons nous assurer que la caméra dispose d'un noyau et d'un rootfs fonctionnels à tout moment pendant le processus de mise à jour. Il semblerait que la solution la plus simple serait de stocker en permanence deux copies du noyau avec rootfs sur la mémoire flash et, si le noyau principal est endommagé, de le charger à partir de la copie de sauvegarde.

Une bonne solution - cependant, le noyau avec rootfs occupe environ 3.5 Mo et pour une sauvegarde permanente, vous devez allouer 3.5 Mo. Les caméras les moins chères n’ont tout simplement pas beaucoup d’espace libre pour un noyau de sauvegarde.

Par conséquent, pour sauvegarder le noyau lors d’une mise à jour du firmware, nous utilisons la partition d’application.
Et pour sélectionner la partition souhaitée avec le noyau, deux commandes sont utilisées bootm dans uboot - au début, nous essayons de charger le noyau principal et s'il est endommagé, alors celui de sauvegarde.

Cela garantit qu'à tout moment, la caméra disposera du bon noyau avec rootfs, et qu'elle pourra démarrer et restaurer le micrologiciel.

Système CI/CD pour la création et le déploiement de micrologiciels

Pour créer le micrologiciel, nous utilisons gitlab CI, qui crée automatiquement le micrologiciel pour tous les modèles de caméras pris en charge, et après avoir créé le micrologiciel, il est automatiquement déployé sur le service de mise à jour du logiciel de la caméra.

À partir du service, les mises à jour du micrologiciel sont fournies à nos caméras de test QA et, une fois toutes les étapes de test terminées, aux caméras des utilisateurs.

Sécurité de l'information

Ce n’est un secret pour personne : la sécurité des informations est aujourd’hui l’aspect le plus important de tout appareil IoT, y compris les caméras. Des botnets comme Mirai parcourent Internet, infectant des millions de caméras avec des micrologiciels standards provenant de fournisseurs. Avec tout le respect que je dois aux fournisseurs de caméras, je ne peux m'empêcher de noter que le micrologiciel standard contient de nombreuses fonctionnalités qui ne sont pas nécessaires pour travailler avec le cloud, mais contient de nombreuses vulnérabilités dont profitent les botnets.

Par conséquent, toutes les fonctionnalités inutilisées de notre firmware sont désactivées, tous les ports TCP/UDP sont fermés et lors de la mise à jour du firmware, la signature numérique du logiciel est vérifiée.

Et en plus de cela, le firmware est soumis à des tests réguliers dans le laboratoire de sécurité de l'information.

Conclusion

Désormais, notre firmware est activement utilisé dans les projets de vidéosurveillance. Le plus important d’entre eux est peut-être la diffusion du vote le jour de l’élection du Président de la Fédération de Russie.
Le projet impliquait plus de 70 XNUMX caméras équipées de notre firmware, qui ont été installées dans les bureaux de vote de notre pays.

Après avoir résolu un certain nombre de problèmes complexes, et dans certains endroits, même à l'époque presque impossibles, nous avons bien sûr reçu une grande satisfaction en tant qu'ingénieurs, mais en plus de cela, nous avons également économisé des millions de dollars sur l'achat de caméras. Et dans ce cas, les économies ne sont pas seulement des mots et des calculs théoriques, mais les résultats d'un appel d'offres déjà réalisé pour l'achat d'équipement. Par conséquent, si nous parlons de vidéosurveillance dans le cloud : il existe deux approches : s'appuyer stratégiquement sur une expertise et un développement de bas niveau, ce qui entraîne d'énormes économies sur l'équipement, ou utiliser des équipements coûteux, ce qui, si l'on regarde spécifiquement les caractéristiques des consommateurs, n'est pratiquement pas différent des similaires bon marché.

Pourquoi est-il stratégiquement important de décider le plus tôt possible du choix de l’approche d’intégration ? Lors du développement d'un plugin, les développeurs s'appuient sur certaines technologies (bibliothèques, protocoles, standards). Et si un ensemble de technologies est choisi uniquement pour des équipements coûteux, alors à l'avenir, une tentative de passage à des caméras bon marché prendra très probablement, au minimum, un temps incroyablement long, voire échouera, et un retour à des équipements coûteux se produira.

Source: habr.com