Construcción de NVRs basados en Linux

Resumen

Este artículo describe los pasos comunes para un socio que quiere hacer un producto de hardware similar a un NVR – un ordenador embebido (llamado aquí «NVR») con una aplicación de servidor preinstalada. Normalmente, un NVR de este tipo es un ordenador basado en Linux con una CPU ARM.

Los pasos básicos para hacer tal producto incluyen lo siguiente:

Elegir el hardware

Plataforma
Almacenamiento

Elegir el sabor de Linux
Instalar la aplicación de Servidor
Implementar características extra
Establecer una política de soporte

Estos pasos se describen a continuación en detalle.

Elegir el hardware

Para que un producto tenga éxito, debe ser rentable y ofrecer el rendimiento necesario: soportar el número de cámaras deseado con la tasa de bits/resolución deseada. El hardware utilizado debe tener al menos 1GB de RAM y un chipset ARM Cortex A7 o superior.

Se recomienda estudiar primero el rendimiento de las plataformas ARM soportadas (consulte la política de soporte de ARM para ver la lista de dichas plataformas) y, a continuación, elegir la plataforma que más se acerque a sus requisitos.

Plataforma

La plataforma ARM soportada elegida puede utilizarse como una de las siguientes:

un ordenador listo para comprar (por ejemplo una placa base Raspberry Pi estándar), posiblemente con una carcasa y una fuente de alimentación personalizadas;
una referencia para diseñar un ordenador personalizado con la placa base que puede albergar componentes de hardware adicionales como interfaces periféricas o controladores de disco duro.

Si se espera que el NVR tenga software adicional a bordo además de la aplicación del servidor, como un servidor web que proporcione una interfaz web al usuario, software de análisis de vídeo (por ejemplo, un plugin VMS y/o su backend), o similares, asegúrese de añadir suficiente RAM y potencia de procesamiento de la CPU para cubrirlo.

La transcodificación de vídeo no es compatible con los dispositivos ARM debido a la limitada potencia de cálculo. Además, algunas dependencias como OpenSSL pueden tener problemas de compatibilidad. Si el análisis inicial muestra que una plataforma típica basada en ARM no proporcionará el rendimiento requerido, se puede considerar una plataforma x64.

El rendimiento de almacenamiento de la plataforma debe ser lo suficientemente bueno para la carga prevista. Por ejemplo, se sabe que soluciones como SATA-sobre-USB pueden dar lugar a un rendimiento deficiente del disco duro, insuficiente para grabar el número de cámaras necesario.

El rendimiento de la red de la plataforma debe ser lo suficientemente bueno para la carga prevista. Por ejemplo, se sabe que soluciones como la implementación de Ethernet basada en software requieren muchos recursos de la CPU y, por tanto, pueden provocar caídas de fotogramas durante la grabación de las cámaras o la transmisión a los clientes, u otros problemas. Además, los modelos de hardware que implementan Ethernet a través de un concentrador USB pueden tener un ancho de banda de red inferior al anunciado.

La plataforma debe estar equipada con un hardware de reloj en tiempo real (RTC), y/o la sincronización de la hora a través de la red (por ejemplo, utilizando el protocolo NTP) debe estar habilitada – para que el VMS funcione correctamente, la fecha y la hora del sistema operativo deben ser correctas. Si no hay RTC por hardware, y la única fuente de fecha/hora está prevista que sea la red, se recomienda que el dispositivo se niegue a arrancar en caso de que no pueda sincronizar la fecha/hora.

Almacenamiento

Asegúrese de que hay suficiente espacio en el sistema de archivos para que el VMS funcione correctamente. El Servidor utiliza las siguientes ubicaciones de almacenamiento:

Instalación del VMS – binarios y librerías dinámicas (archivos .so)

Situado en /opt/<vendor>/mediaserver/
Espacio necesario: se puede calcular midiendo el tamaño total de los respectivos archivos de la distribución con algún margen añadido; cuanto mayor sea el margen – menos posibilidades de problemas con la actualización a futuras versiones. Generalmente, se recomienda un margen del 30%.
Si no hay suficiente almacenamiento en /opt, los archivos .so se pueden mover a través de enlaces simbólicos a otra ubicación, incluyendo el almacenamiento FAT32 (pero en este caso sólo se pueden mover los archivos que no son enlaces simbólicos).

Archivos de la base de datos del servidor: almacena información sobre las cámaras y otros Servidores, registros de eventos, etc.

Típicamente se encuentra en /opt/<vendor>/mediaserver/var/; puede cambiarse en el archivo de configuración del Servidor.
Requiere un sistema de archivos ext4
Espacio requerido: depende del número de cámaras y Servidores en el Sistema VMS, pero generalmente se recomiendan al menos 500 MB.

Base de datos de análisis del servidor: almacena los metadatos de análisis de vídeo generados por los plugins de análisis

Típicamente se encuentra en /opt/<vendor>/mediaserver/var/data; se puede cambiar en el archivo de configuración del servidor.
Espacio necesario: depende de si se utilizan plugins de análisis en este servidor y de la cantidad de metadatos que envíen los plugins. Por lo general, se recomienda el 20% del tamaño de almacenamiento del archivo de vídeo si se utilizan plugins de análisis en este servidor.

Los registros del servidor

Se encuentran en /opt/<vendor>/mediaserver/var/log/
- Pueden reubicarse mediante mediaserver.conf.
Los registros se sobrescriben automáticamente en un bucle.
Espacio requerido: se recomiendan al menos 260 MB.
NOTA: Hemos observado que en determinados dispositivos ARM (por ejemplo, Raspberry Pi 3), la memoria flash interna (Micro SD en ese caso) no era lo suficientemente buena para aceptar registros. El sistema se congelaba hasta 4 segundos. Recomendamos redirigir los registros a la misma ubicación que el archivo de vídeo para tales dispositivos.

Archivo de vídeo – almacena el vídeo grabado de las cámaras
- Normalmente se encuentra en /opt/<vendor>/mediaserver; se puede cambiar en el archivo de configuración del servidor.
- Es probable que la partición del sistema tenga restringida la grabación por defecto a menos que haya al menos 10 GB de espacio libre.
- Memoria flash interna (eMMC) o tarjeta SD
- Disco duro interno o SSD
- NAS externo

Archivos de actualización de la aplicación del Servidor

Para poder actualizarse, la aplicación del Servidor necesita descargar su versión más reciente y desempaquetarla.
Se encuentra en /tmp/
Espacio necesario: el tamaño total del archivo de distribución del Servidor empaquetado multiplicado por 2,6; esto incluye el margen. Se puede recomendar más espacio para minimizar las posibilidades de problemas con la actualización a futuras versiones.

Archivos temporales del SO

Típicamente se encuentra en /tmp/
Espacio requerido: se recomienda al menos 100 MB, sin incluir el espacio requerido para los archivos de actualización de la aplicación Server (ver arriba).

La mayoría de las cosas enumeradas anteriormente pueden ser asignadas para ser almacenadas en una ubicación diferente en el archivo de configuración del Servidor: /opt/<vendor>/mediaserver/etc/mediaserver.conf

Dado que el almacenamiento típico de la tarjeta SD no es fiable y se sabe que falla durante las operaciones intensivas de lectura y escritura, recomendamos instalar el SO y almacenar el archivo de vídeo en un disco(s) duro(s). Si se considera un SSD/disco duro o una tarjeta SD para almacenar el archivo de vídeo, evalúe su capacidad para múltiples operaciones de reescritura utilizando la tasa de bits típica de una cámara compatible deseada multiplicada por el número deseado de cámaras compatibles.

Por ejemplo, para la Raspberry Pi 3 B+:

Utilice un adaptador USB-SATA y un disco duro externo para el archivo.
Instalar el SO (Raspbian) en un disco duro externo. Consulte el artículo Cómo arrancar su Raspberry Pi desde un dispositivo de almacenamiento masivo USB para más detalles. Este proceso debe ser automatizado en función de cómo se van a distribuir los dispositivos ARM: con o sin disco duro:

Con disco duro – hacer una imagen preconfigurada con VMS instalado y clonarla en los discos duros.
Sin disco duro – tendrá que crear un conjunto de scripts que formatee el HDD, copie el SO y haga todos los ajustes necesarios. Esta es una tarea bastante compleja y que requiere mucho tiempo.

Elija el sabor de Linux

Por lo general, hay varias opciones para el sistema operativo Linux en un determinado NVR:

«Busybox» – sólo el kernel de Linux y el conjunto básico de herramientas de línea de comandos; se utiliza en NVRs de relativamente bajo rendimiento, como las cámaras «de borde» (cámaras con el servidor VMS que se ejecuta en ellas).
Deben estándar, o uno de sus sabores como Ubuntu.
Versión modificada de Debian u otra distribución de Linux, normalmente modificada por el proveedor del dispositivo (por ejemplo, Raspbian para Raspberry Pi).

En general, se recomienda elegir una variante de Linux que sea la opción nativa para la plataforma en la que se basa el NVR. Por ejemplo, cuando se desarrolla un NVR similar en hardware a Raspberry Pi (o incluso utilizando la placa base exacta de Raspberry Pi), se recomienda elegir Raspbian.

Si hay varias distribuciones de Linux con diferentes conjuntos de paquetes disponibles para el dispositivo, se recomienda la menos pesada. Por ejemplo, si no hay ningún plan para mostrar la GUI en el NVR, no es necesario el sistema X Window.

Asegúrese de que la versión de Linux y su conjunto de paquetes satisfacen los requisitos del VMS. En el caso de los dispositivos basados en ARM, consulte los detalles del sistema operativo especificados en la política de soporte de ARM.

Instalar la aplicación del servidor

Después de cargar el NVR con un sistema operativo Linux adecuado, se debe instalar la aplicación del servidor en el NVR. Existen básicamente dos opciones:

Para sistemas operativos basados en Debian: instale el paquete oficial .deb de la distribución VMS utilizando dpkg.

Vea las instrucciones detalladas para instalar el VMS en un dispositivo: Instrucciones de instalación de ARM SBC

Para sistemas operativos basados en Busybox: extraiga los archivos necesarios del paquete .deb del VMS al directorio deseado y ocúpese manualmente de los siguientes aspectos:

¿Cómo se iniciará el Servidor al arrancar y si el soporte de system.d de la distribución no es adecuado?
¿Dónde tomará el Servidor las bibliotecas .so que falten en el Linux instalado?
¿Se habilitará el sistema de actualización automática VMS estándar?

Para configuraciones de SO menos típicas, puede ser necesaria alguna combinación de las opciones 1 y 2.

Implementar características adicionales

Típicamente, un NVR no es sólo un ordenador Linux estándar con la aplicación Server instalada – a menudo proporciona características adicionales al usuario:

Botones de hardware, LEDs o incluso pantallas integradas.
Una interfaz web que permite personalizar el NVR más allá de la configuración de la aplicación Server a través de su propia interfaz web, como

opciones de red: Dirección IP, subred, etc.;
hora del sistema y zona horaria;

Salida de vídeo (por ejemplo, HDMI) que muestra una GUI o al menos una pantalla de bienvenida con valores de configuración básicos como la dirección IP del NVR;
Software adicional que se ejecuta en paralelo al VMS, como un demonio de configuración o un backend de análisis de vídeo.
- Si el software adicional tiene una autenticación basada en contraseña para el usuario final, considere la posibilidad de implementar la sincronización de contraseñas, de modo que la contraseña del servidor VMS sea siempre la misma que la del software adicional. Si se ofrece ssh al usuario para acceder al NVR, considere sincronizar su contraseña también.
Ajustes adicionales, como minimizar la memoria de vídeo (GPU). Por ejemplo, para la Raspberry Pi 3 B+ establece la memoria de la GPU a 16 MB. Consulte la documentación de la Raspberry Pi para más detalles.

Para implementar tales características, puede ser necesario escribir o modificar los scripts que controlan la aplicación del Servidor, o escribir programas adicionales en C/C++.

Sincronización de tiempo

Asegúrese de que el NVR tiene una batería CMOS incorporada para evitar que su reloj se reinicie en caso de pérdida de energía. Por ejemplo, la Raspberry Pi 3 B+ no tiene una batería CMOS a bordo. Si el dispositivo se reinicia, la hora se restablecerá y dará lugar a una escritura incorrecta del archivo. Para evitar esto, hay algunas opciones:

Asegúrese de que está conectado a Internet para sincronizar la hora.
Si es una red cerrada, tendrá que configurar un servidor NTP.
Añadir un módulo de reloj de tiempo real (RTC) a la placa y preconfigurarlo. Consulte Añadir un reloj de tiempo real a su Raspberry Pi.

Encontrar/construir una carcasa para su NVR

Es necesario encontrar o diseñar una carcasa en la que quepa todo el hardware mencionado anteriormente.

Realizar una prueba de carga/estrés intensiva

Para asegurarse de que todo funciona en conjunto, es necesario planificar una prueba de estrés intensiva para asegurarse de que no hay sobrecalentamiento o mal funcionamiento de los componentes. La prueba debe ser capaz de cargar todos los componentes del sistema, como la CPU, la memoria, los discos duros, la red y el Wi-Fi (si es necesario), etc.

Establezca una política de soporte

El NVR va a ser suministrado a sus usuarios finales, y definitivamente requerirán algún tipo de soporte técnico. El equipo de apoyo del proveedor de VMS no puede prestar tales servicios a los usuarios finales, por lo tanto, una política para proporcionar dicho apoyo debe ser desarrollado, como un escritorio de soporte en línea, un foro de la comunidad, o similares.

Cuando el equipo de soporte del proveedor de NVR esté seguro de que el problema concreto no está relacionado con las características específicas del propio NVR, sino que se trata de un problema en el VMS, puede solicitar el soporte del proveedor de VMS de acuerdo con la política de soporte de ARM mencionada anteriormente, y luego utilizar el resultado de este caso de soporte para satisfacer la solicitud de soporte de un usuario final.

Preguntas

Si tiene alguna pregunta relacionada con este tema o quiere compartir su experiencia con otros miembros de la comunidad o con nuestro equipo, visite y participe en nuestra comunidad de soporte o póngase en contacto con su distribuidor local.

Arquidia Mantina