Bonjour à tous!

Ce n'est probablement un secret pour personne que les services de vidéosurveillance en nuage ont récemment gagné en popularité. Et on comprend pourquoi cela se produit, la vidéo est un contenu «lourd», qui nécessite une infrastructure et de grandes quantités de stockage sur disque pour être stocké. L'utilisation d'un système de vidéosurveillance local nécessite des moyens de fonctionnement et d'assistance, à la fois dans le cas d'une organisation utilisant des centaines de caméras de surveillance, et dans le cas d'un utilisateur individuel avec plusieurs caméras.

Les systèmes de vidéosurveillance basés sur le cloud résolvent ce problème en fournissant aux clients une infrastructure de stockage et de traitement vidéo existante. Il suffit qu'un client de surveillance basé sur le cloud connecte simplement la caméra à Internet et se lie à son compte dans le cloud.

Il existe plusieurs façons technologiques de connecter des caméras au cloud. Sans aucun doute, le moyen le plus pratique et le moins cher - la caméra se connecte directement et fonctionne avec le cloud, sans la participation d'équipements supplémentaires tels qu'un serveur ou un registraire.

Pour cela, il est nécessaire que le 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 la caméra, mais aucune ressource n'est nécessaire pour le plug-in cloud. Les développeurs d'ivideon ont consacré un article à ce problème, qui explique pourquoi ils ne peuvent pas installer le plug-in sur des caméras bon marché. En conséquence, le prix minimum de l'appareil photo est de 5000 roubles (80 dollars) et des millions d'argent dépensés en équipement.

Nous avons réussi à résoudre ce problème. Si vous souhaitez savoir comment - Bienvenue sous cat

Un peu d'histoire

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

Dans la partie logiciel de la caméra, à la première étape, nous avons opté pour la méthode "standard" pour ces tâches: nous avons développé notre propre plug-in, qui est installé dans le firmware 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, la mise en œuvre en C simple de protobuf, libev, mbedtls et des bibliothèques pratiques mais lourdes complètement abandonnées comme boost)

Maintenant, sur le marché des caméras IP, il n'y a pas de solutions d'intégration universelles: chaque fournisseur a sa propre façon d'installer le plug-in, son propre ensemble d'API pour que le firmware fonctionne 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 de volume de logiciels d'intégration. Et au moment du début du développement, il est conseillé de travailler uniquement avec le 1er fournisseur afin de concentrer les efforts de l'équipe sur le développement de la logique de travail avec le cloud.

Le premier fournisseur 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.

Sur les caméras Hikvision, nous avons lancé notre premier projet pilote, la vidéosurveillance dans le cloud, Video Comfort.

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

J'ai rejeté l'option avec l'implémentation de la couche d'intégration pour chaque fournisseur presque immédiatement - car peu évolutive et présentant de sérieuses exigences techniques pour le matériel de la caméra. Le coût de la caméra, répondant à ces exigences à l'entrée: ~ 60-70 $

Par conséquent, j'ai décidé de creuser plus profondément - de créer complètement mon firmware pour les caméras de tous les fournisseurs. Cette approche réduit considérablement les exigences matérielles de la caméra - comme la couche cloud est d'un ordre de grandeur plus efficacement intégrée à l'application vidéo, et il n'y a pas de graisse inutile dans le firmware.

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

A ce moment, 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 chipset SDK officiel ni de documentation sur les capteurs.
Il n'y a pas non plus de support technique.

Les réponses à toutes les questions devaient être obtenues par rétro-ingénierie - essais et erreurs. Mais nous l'avons fait.

Les premiers modèles de caméras sur lesquels nous avons rempli les bosses étaient les fourmis Xiaomi Yi, Hikvision, Dahua, Spezvision, D-Link et plusieurs caméras chinoises super bon marché sans nom.

Technique

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

Nous avons commencé avec eux.

Nous prenons actuellement en charge les chipsets Hisilicon 3516/3518, ainsi que Ambarella S2L / S2LM. Le nombre de modèles d'appareils photo est de plusieurs dizaines.

Composition du micrologiciel

uboot

uboot est le chargeur de démarrage, après avoir mis sous tension, il démarre en premier, initialise le matériel et charge le noyau Linux.

Le script de chargement de la caméra est assez banal:

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 

Parmi les fonctionnalités, bootm est appelé bootm , plus à ce sujet 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 - seulement 38 mégaoctets de RAM sont disponibles pour le noyau Linux et les applications tout-tout.

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

Au début, lorsque nous travaillions sans le soutien des fournisseurs, nous copions simplement ce bloc à partir du micrologiciel de la caméra d'origine.

Le noyau Linux et rootfs

Les caméras utilisent le noyau Linux, qui fait partie de la puce SDK, ce ne sont généralement pas les derniers noyaux de la branche 3.x, nous devons donc souvent constater que les pilotes matériels supplémentaires ne sont pas compatibles avec le noyau utilisé, et nous devons les rétroporter vers le noyau caméras.

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

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

Le système de fichiers racine est connecté au noyau en tant qu'initramfs, et à la suite de l'assemblage, 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 une application qui fournit la capture vidéo-audio, l'encodage vidéo, ajuste les paramètres d'image, implémente l'analyse vidéo, par exemple, des détecteurs de mouvement ou de son, contrôle PTZ et est responsable du changement de modes jour et nuit.

Un élément important, je dirais même une caractéristique clé - la façon dont l'application vidéo interagit avec le plugin cloud.

Dans les solutions traditionnelles `` firmware du fabricant + plug-in cloud '', qui ne peuvent pas fonctionner sur du matériel bon marché, la vidéo à l'intérieur de la caméra est transmise en utilisant le protocole RTSP - et cela représente un énorme surcoût: copie et transfert de données via socket, appels sys supplémentaires.

Nous utilisons le mécanisme de mémoire partagée à cet endroit - la vidéo n'est pas copiée ou envoyée via le 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 objet de fierté particulière est le sous-système tolérant aux pannes des mises à jour du firmware en ligne.

Je vais vous expliquer les problèmes. Une 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, alors il y aura une partie du nouveau micrologiciel «non enregistré» sur la mémoire flash. Si vous ne prenez pas de mesures spéciales, l'appareil photo deviendra alors une "brique", qui devra être portée dans un centre de service.

Nous avons réglé ce problème. Même si la caméra est éteinte au moment de la mise à jour, elle téléchargera automatiquement et sans intervention de l'utilisateur le firmware depuis le cloud et restaurera l'opération.

Analysons la technique plus en détail:

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

Nous devons donc nous assurer que la caméra dispose d'un noyau et de rootfs fonctionnels à tout moment pendant le processus de mise à jour. Il semblerait que la solution la plus simple serait de stocker en permanence sur la mémoire flash deux copies du noyau avec rootfs et en cas d'endommagement du noyau principal, de le charger depuis la sauvegarde.

Une bonne solution - cependant, le noyau avec rootfs prend environ 3,5 Mo et pour une sauvegarde permanente, vous devez allouer 3,5 Mo. Sur les caméras les moins chères, il n'y a tout simplement pas autant d'espace libre pour le noyau de sauvegarde.

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

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

Système CI / CD pour assembler et déployer le firmware

Pour construire le firmware, nous utilisons gitlab CI, dans lequel le firmware de tous les modèles de caméras pris en charge est automatiquement collecté, une fois le firmware construit, ils sont automatiquement déployés sur le service de mise à jour du logiciel de la caméra.

À partir du service, les mises à jour du micrologiciel sont livrées aux caméras de test de notre AQ, et à la fin de toutes les étapes des tests, aux caméras des utilisateurs.

Sécurité de l'information

Ce n'est un secret pour personne qu'à notre époque, la sécurité des informations est l'aspect le plus important de tout appareil IoT, y compris les caméras. Les botnets comme Mirai se promènent sur Internet, affectant des millions de caméras avec le firmware standard des fournisseurs. Avec tout le respect que je dois aux fournisseurs de caméras, je ne peux que noter que le firmware standard a beaucoup de fonctionnalités qui ne sont pas demandées pour travailler avec le cloud, mais il contient de nombreuses vulnérabilités que les botnets utilisent.

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

Et en plus de cela, le firmware est régulièrement testé dans le laboratoire de sécurité de l'information.

Conclusion

Maintenant, notre firmware est activement utilisé dans les projets de vidéosurveillance. Le plus ambitieux 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 a impliqué plus de 70 000 caméras avec notre firmware, qui ont été installées dans les bureaux de vote de notre pays.

Ayant résolu un certain nombre de tâches complexes et parfois même pratiquement impossibles à l'époque, nous avons bien sûr reçu une grande satisfaction en tant qu'ingénieurs, mais en plus de cela, nous avons économisé des millions de dollars en achetant des 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à en cours pour l'achat d'équipements. En conséquence, 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, réaliser d'énormes économies sur les équipements en sortie, ou utiliser des équipements coûteux, qui, si vous regardez les caractéristiques des consommateurs, ne sont pratiquement pas différents d'un modèle similaire bon marché.

Pourquoi est-il stratégiquement important de décider le plus tôt possible d'une approche de la méthode 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 sélectionné uniquement pour des équipements coûteux, alors à l'avenir, une tentative de passer à des caméras bon marché avec une forte probabilité prendra au moins un temps incroyablement long ou même échouera et un retour à un équipement coûteux se produira.