Construire des NVR basés sur Linux

Overview

Cet article décrit les étapes communes pour un partenaire qui veut fabriquer un produit matériel de type NVR – un ordinateur embarqué (appelé ici « NVR ») avec une application serveur pré-installée. Typiquement, un tel NVR est un ordinateur basé sur Linux avec un processeur ARM.

Les étapes de base pour fabriquer un tel produit sont les suivantes :

Choisir le matériel

Plateforme
Stockage

Choisir la saveur Linux
Installer l’application Serveur
Mettre en place des fonctionnalités supplémentaires
Établir une politique de support

Ces étapes sont décrites ci-dessous en détail.

Choisir le matériel

Pour qu’un produit ait du succès, il doit être rentable et fournir les performances requises – supporter le nombre souhaité de caméras avec le débit binaire/la résolution souhaités. Le matériel utilisé doit avoir au moins 1 Go de RAM et un chipset ARM Cortex A7 ou supérieur.

Il est recommandé d’étudier d’abord les performances des plateformes ARM supportées (voir la politique de support ARM pour la liste de ces plateformes), puis de choisir la plateforme la plus proche de vos besoins.

Plateforme

La plateforme ARM supportée choisie peut être utilisée comme l’un des éléments suivants :

un ordinateur prêt à acheter (par ex. une carte mère standard Raspberry Pi), éventuellement avec un boîtier et un bloc d’alimentation personnalisés ;
une référence pour la conception d’un ordinateur personnalisé avec la carte mère qui peut accueillir des composants matériels supplémentaires comme des interfaces périphériques ou des contrôleurs de disque dur.

Si le NVR est censé embarquer des logiciels supplémentaires en plus de l’application serveur, comme un serveur web fournissant une interface web à l’utilisateur, un logiciel d’analyse vidéo (par exemple un plugin VMS et/ou son backend), ou autre, assurez-vous d’ajouter suffisamment de RAM et de puissance de traitement CPU pour couvrir cela.

Le transcodage vidéo n’est pas pris en charge sur les appareils ARM en raison de la puissance de calcul limitée. De plus, certaines dépendances telles qu’OpenSSL peuvent avoir des problèmes de compatibilité. Si l’analyse initiale montre qu’une plateforme typique basée sur ARM ne fournira pas les performances requises, une plateforme x64 peut être envisagée.

Les performances de stockage de la plateforme doivent être suffisamment bonnes pour la charge prévue. Par exemple, il est connu que des solutions telles que SATA-over-USB peuvent conduire à des performances médiocres du disque dur, insuffisantes pour enregistrer le nombre requis de caméras.

Les performances réseau de la plate-forme doivent être suffisamment bonnes pour la charge prévue. Par exemple, il est connu que des solutions telles que la mise en œuvre d’Ethernet basée sur le logiciel prend beaucoup de ressources CPU et peut donc conduire à des chutes de trames lors de l’enregistrement des caméras ou de la diffusion en continu vers les clients, ou d’autres problèmes. En outre, les modèles de matériel qui mettent en œuvre l’Ethernet via un hub USB peuvent avoir une bande passante réseau inférieure à celle annoncée.

La plate-forme doit être équipée d’une horloge en temps réel (RTC) matérielle, et/ou la synchronisation de l’heure via le réseau (par exemple, en utilisant le protocole NTP) doit être activée – pour que le VMS fonctionne correctement, la date et l’heure du système d’exploitation doivent être correctes. S’il n’y a pas de RTC matériel, et que la seule source de date/heure est prévue pour être le réseau, il est recommandé que le périphérique refuse de démarrer du tout au cas où il ne pourrait pas synchroniser la date/heure.

Storage

Vérifiez qu’il y a suffisamment d’espace sur le système de fichiers pour que le VMS fonctionne correctement. Le serveur utilise les emplacements de stockage suivants :

Installation du VMS – binaires et bibliothèques dynamiques (fichiers .so)

Situé dans /opt/<vendor>/mediaserver/
Espace requis : peut être calculé en mesurant la taille totale des fichiers respectifs dans la distribution avec une certaine marge ajoutée ; plus la marge est élevée – moins il y a de chances de problèmes avec la mise à jour des versions futures. Généralement, une marge de 30% est recommandée.
S’il n’y a pas assez de stockage à /opt, les fichiers .so peuvent être déplacés via des liens symboliques vers un autre emplacement, y compris le stockage FAT32 (mais dans ce cas, seuls les fichiers qui ne sont pas des liens symboliques peuvent être déplacés).

Fichiers de base de données du serveur – stocke les informations sur les caméras et les autres serveurs, les journaux d’événements, etc.

Typiquement situé à /opt/<vendor>/mediaserver/var/ ; peut être modifié dans le fichier de configuration du Serveur.
Requiert un système de fichiers ext4
Espace requis : dépend du nombre de caméras et de Serveurs dans le système VMS, mais généralement au moins 500 Mo sont recommandés.

Base de données analytique du serveur – stocke les métadonnées d’analyse vidéo générées par les plugins d’analyse

Typiquement située dans /opt/<vendor>/mediaserver/var/data ; peut être modifiée dans le fichier de configuration du serveur.
Espace requis : dépend de l’utilisation ou non de plugins d’analyse sur ce Serveur, et de la quantité de métadonnées que les plugins enverront. Généralement, 20 % de la taille de stockage de l’archive vidéo est recommandée si des Plugins d’analyse sont utilisés sur ce Serveur.

Les journaux du serveur

Situés dans /opt/<vendor>/mediaserver/var/log/
- Peut être déplacé via mediaserver.conf.
Les journaux sont automatiquement écrasés en boucle.
Espace requis : au moins 260 Mo est recommandé.
NOTE : Nous avons remarqué que sur certains appareils ARM (par ex, Raspberry Pi 3), la mémoire flash interne (Micro SD dans ce cas) n’était pas assez bonne pour accepter les journaux. Le système se figeait jusqu’à 4 secondes. Nous avons recommandé de rediriger les journaux vers le même emplacement que l’archive vidéo pour de tels appareils.

Archives vidéo – stocke les vidéos enregistrées des caméras
- Typiquement situé à /opt/<vendor>/mediaserver ; peut être modifié dans le fichier de configuration du serveur.
- La partition système sera probablement limitée à l’enregistrement par défaut, à moins qu’il n’y ait au moins 10 Go d’espace libre.
- Mémoire flash interne (eMMC) ou carte SD
- Disque dur interne ou SSD
- NAS externe
Fichiers de mise à jour de l’application Server

Pour pouvoir se mettre à jour, l’application Server doit télécharger sa version la plus récente et la décompresser.
Localisé dans /tmp/
Espace requis : la taille totale du fichier de distribution Server empaqueté multiplié par 2,6 ; ceci inclut la marge. Un espace plus important peut être recommandé pour minimiser les chances de problèmes lors de la mise à jour vers les versions futures.

Fichiers temporaires du système d’exploitation

Typiquement situés dans /tmp/
Espace requis : au moins 100 Mo sont recommandés, sans compter l’espace requis pour les fichiers de mise à jour de l’application Server (voir ci-dessus).

La plupart des choses énumérées ci-dessus peuvent être assignées pour être stockées dans un emplacement différent dans le fichier de configuration du serveur : /opt/<vendor>/mediaserver/etc/mediaserver.conf

Puisque le stockage typique sur carte SD n’est pas fiable et connu pour échouer lors d’opérations intensives de lecture-écriture, nous recommandons d’installer le système d’exploitation et de stocker l’archive vidéo sur un ou plusieurs disques durs. Si un SSD/disque dur ou une carte SD est envisagé pour stocker l’archive vidéo, évaluez sa capacité pour de multiples opérations de réécriture en utilisant le débit binaire typique d’une caméra prise en charge souhaitée multiplié par le nombre souhaité de caméras prises en charge.

Par exemple, pour le Raspberry Pi 3 B+ :

Utiliser un adaptateur USB-SATA et un disque dur externe pour l’archive.
Installer le système d’exploitation (Raspbian) sur un disque dur externe. Voir l’article Comment démarrer votre Raspberry Pi à partir d’un périphérique de stockage de masse USB pour plus de détails. Ce processus devrait être automatisé en fonction de la façon dont les périphériques ARM vont être distribués : avec ou sans disque dur :

Avec disque dur – faites une image préconfigurée avec VMS installé et clonez-la sur les disques durs.
Sans disque dur – vous devrez créer un ensemble de scripts qui formatent le disque dur, copient le système d’exploitation et font tous les ajustements nécessaires. C’est une tâche assez complexe et qui prend du temps.

Choisir la saveur Linux

Il y a généralement plusieurs options pour le système d’exploitation Linux sur un NVR donné :

« Busybox » – juste le noyau Linux et l’ensemble de base des outils de ligne de commande ; utilisé sur les NVR relativement peu performants tels que les caméras « edge » (caméras sur lesquelles tourne le serveur VMS).
Debian standard, ou une de ses saveurs comme Ubuntu.
Version modifiée de Debian ou d’une autre distribution Linux, généralement modifiée par le vendeur du périphérique (par ex, Raspbian pour Raspberry Pi).

Généralement, il est recommandé de choisir une variante de Linux qui est le choix natif pour la plateforme sur laquelle le NVR est basé. Par exemple, lors du développement d’un NVR similaire en termes de matériel au Raspberry Pi (ou même en utilisant la carte mère exacte du Raspberry Pi), il est recommandé de choisir Raspbian.

Si plusieurs distributions Linux avec différents ensembles de paquets sont disponibles pour le périphérique, la moins lourde est recommandée. Par exemple, s’il n’est pas prévu d’afficher une interface graphique sur le NVR, il n’y a pas besoin du système X Window.

S’assurer que la version de Linux et son ensemble de paquets satisfont aux exigences du VMS. Pour les appareils basés sur ARM, consultez les détails du système d’exploitation spécifiés dans la politique de support ARM.

Installer l’application serveur

Après avoir chargé le NVR avec un système d’exploitation Linux approprié, l’application serveur doit être installée sur le NVR. Il existe essentiellement deux options :

Pour les OS basés sur Debian : installer le paquet .deb officiel de la distribution du VMS en utilisant dpkg.

Voir les instructions détaillées pour l’installation du VMS sur un appareil : Instructions d’installation de l’ARM SBC

Pour les systèmes d’exploitation basés sur Busybox : extrayez les fichiers requis du paquet .deb du VMS dans le répertoire souhaité, et prenez soin manuellement des aspects suivants :

Comment le serveur sera lancé au démarrage et si le support system.d de la distribution ne convient pas ?
Où le serveur prendra-t-il les bibliothèques .so manquantes dans le Linux installé ?
Le système de mise à jour automatique standard VMS sera-t-il activé ?

Pour les configurations de systèmes d’exploitation moins typiques, une certaine combinaison des options 1 et 2 peut être nécessaire.

Implémenter des fonctionnalités supplémentaires

Typiquement, un NVR n’est pas seulement un ordinateur Linux standard avec l’application Server installée – il fournit souvent des fonctionnalités supplémentaires à l’utilisateur :

Des boutons matériels, des LED ou même des écrans intégrés.
Une interface web qui vous permet de personnaliser le NVR au-delà de la simple configuration de l’application Server via sa propre interface web, comme

des options de réseau : Adresse IP, sous-réseau, etc.;
heure système et fuseau horaire;

Sortie vidéo (par ex, HDMI) qui montre une interface graphique ou au moins un écran de bienvenue avec des valeurs de configuration de base comme l’adresse IP du NVR;
Les logiciels supplémentaires qui fonctionnent en parallèle au VMS, comme un démon de configuration ou un backend d’analyse vidéo.
- Si le logiciel supplémentaire a une authentification basée sur un mot de passe pour l’utilisateur final, envisagez de mettre en œuvre la synchronisation des mots de passe, de sorte que le mot de passe du serveur VMS soit toujours le même que celui du logiciel supplémentaire. Si ssh est proposé à l’utilisateur pour accéder au NVR, pensez à synchroniser son mot de passe également.
Des ajustements supplémentaires, comme la minimisation de la mémoire vidéo (GPU). Par exemple, pour le Raspberry Pi 3 B+, réglez la mémoire du GPU à 16 Mo. Voir la documentation du Raspberry Pi pour plus de détails.

Pour mettre en œuvre de telles fonctionnalités, il peut être nécessaire d’écrire ou de modifier les scripts qui contrôlent l’application Server, ou d’écrire des programmes supplémentaires en C/C++.

Synchronisation temporelle

Vérifiez que le NVR possède une batterie CMOS intégrée pour éviter que son horloge ne se réinitialise en cas de perte d’alimentation. Par exemple, le Raspberry Pi 3 B+ n’a pas de batterie CMOS intégrée. Si le périphérique est redémarré, l’heure se réinitialisera et cela entraînera une écriture incorrecte des archives. Pour éviter cela, il existe quelques options :

S’assurer qu’il est connecté à Internet pour synchroniser le temps.
S’il s’agit d’un réseau fermé, vous devrez configurer un serveur NTP.
Ajouter un module d’horloge en temps réel (RTC) à la carte et le pré-configurer. Voir Ajouter une horloge en temps réel à votre Raspberry Pi.

Trouver/construire un boîtier pour votre NVR

Il est nécessaire de trouver ou de concevoir un boîtier qui conviendra à tout le matériel mentionné ci-dessus.

Réaliser un test de charge/stress intensif

Pour s’assurer que tout fonctionne ensemble, il est nécessaire de planifier un test de stress intensif pour s’assurer qu’il n’y a pas de surchauffe ou de dysfonctionnement des composants. Le test doit pouvoir charger tous les composants du système comme le CPU, la mémoire, le ou les disques durs, le réseau et le Wi-Fi (si nécessaire), etc.

Établir une politique de support

Le NVR va être fourni à ses utilisateurs finaux, et ils auront certainement besoin d’une certaine forme de support technique. L’équipe de support du fournisseur de VMS ne peut pas rendre de tels services aux utilisateurs finaux, ainsi, une politique pour fournir un tel support devrait être développée, comme un bureau de support en ligne, un forum communautaire, ou autre.

Lorsque l’équipe de support du vendeur de NVR est sûre que le problème particulier n’est pas lié aux spécificités du NVR lui-même, mais qu’il s’agit plutôt d’un problème dans le VMS, elle peut demander le support du vendeur de VMS selon la politique de support ARM mentionnée ci-dessus, puis utiliser le résultat de ce cas de support pour satisfaire la demande de support d’un utilisateur final.

Questions

Si vous avez des questions relatives à ce sujet ou si vous souhaitez partager votre expérience avec d’autres membres de la communauté ou notre équipe, veuillez visiter et vous engager dans notre communauté de support ou vous rapprocher de votre revendeur local.

Arquidia Mantina