Hola a todos!

Probablemente no sea ningún secreto que los servicios de videovigilancia en la nube han ido ganando popularidad últimamente. Y está claro por qué sucede esto: el vídeo es un contenido "pesado", cuyo almacenamiento requiere infraestructura y grandes cantidades de almacenamiento en disco. El uso de un sistema de videovigilancia local requiere fondos para su funcionamiento y soporte, tanto para una organización que utiliza cientos de cámaras de vigilancia como para un usuario individual con varias cámaras.

Los sistemas de videovigilancia en la nube resuelven este problema proporcionando a los clientes una infraestructura de procesamiento y almacenamiento de vídeo existente. Un cliente de videovigilancia en la nube simplemente necesita conectar la cámara a Internet y vincularla a su cuenta en la nube.

Existen varias formas tecnológicas de conectar cámaras a la nube. Sin duda, el método más cómodo y económico es que la cámara se conecte y funcione directamente con la nube, sin la participación de equipos adicionales como un servidor o una grabadora.

Para hacer esto, es necesario que la cámara tenga instalado un módulo de software que funcione con la nube. Sin embargo, si hablamos de cámaras baratas, entonces tienen recursos de hardware muy limitados, que están ocupados casi al 100% por el firmware nativo del proveedor de la cámara, y no hay recursos necesarios para el complemento en la nube. Los desarrolladores de ivideon dedicaron este problema Artículo, lo que explica por qué no pueden instalar el complemento en cámaras baratas. Como resultado, el precio mínimo de la cámara es de 5000 rublos (80 dólares) y se gastan millones de dinero en equipos.

Hemos resuelto con éxito este problema. Si está interesado en cómo hacerlo, bienvenido al corte.

Un poco de historia

En 2016, comenzamos a desarrollar una plataforma de videovigilancia en la nube para Rostelecom.

En cuanto al software de la cámara, en la primera etapa seguimos el camino "estándar" para tales tareas: desarrollamos nuestro propio complemento, que se instala en el firmware estándar de la cámara del proveedor y funciona con nuestra nube. Sin embargo, vale la pena señalar que durante el diseño utilizamos las soluciones más livianas y eficientes (por ejemplo, implementación en C simple de protobuf, libev, mbedtls y bibliotecas convenientes pero pesadas completamente abandonadas como boost)

Actualmente, no existen soluciones de integración universales en el mercado de cámaras IP: cada proveedor tiene su propia forma de instalar el complemento, su propio conjunto de API para operar el firmware y un mecanismo de actualización único.

Esto significa que para cada proveedor de cámaras es necesario desarrollar individualmente una capa integral de software de integración. Y al momento de iniciar el desarrollo, es recomendable trabajar solo con 1 proveedor para poder concentrar los esfuerzos del equipo en desarrollar la lógica para trabajar con la nube.

El primer proveedor elegido fue Hikvision, uno de los líderes mundiales en el mercado de cámaras, que ofrece una API bien documentada y soporte técnico de ingeniería competente.

Lanzamos nuestro primer proyecto piloto, videovigilancia en la nube Video Comfort, utilizando cámaras Hikvision.

Casi inmediatamente después del lanzamiento, nuestros usuarios comenzaron a hacer preguntas sobre la posibilidad de conectar al servicio cámaras más baratas de otros fabricantes.

Rechacé la opción de implementar una capa de integración para cada proveedor casi de inmediato, ya que es poco escalable e impone serios requisitos técnicos al hardware de la cámara. El costo de una cámara que cumpla con estos requisitos de entrada: ~60-70$

Por lo tanto, decidí profundizar más: crear mi propio firmware para cámaras de cualquier proveedor. Este enfoque reduce significativamente los requisitos de recursos de hardware de la cámara, porque La capa para trabajar con la nube se integra de manera mucho más efectiva con la aplicación de video y no hay grasa innecesaria y no utilizada en el firmware.

Y lo importante es que cuando se trabaja con la cámara a bajo nivel, es posible utilizar hardware AES, que cifra los datos sin crear una carga adicional en la CPU de bajo consumo.

En ese momento no teníamos nada en absoluto. Nada en absoluto.

Casi todos los proveedores no estaban preparados para trabajar con nosotros a un nivel tan bajo. No hay información sobre los circuitos y los componentes, no hay un SDK oficial de conjuntos de chips ni documentación de sensores.
Tampoco hay soporte técnico.

Todas las preguntas debían responderse mediante ingeniería inversa: prueba y error. Pero lo logramos.

Los primeros modelos de cámaras que probamos fueron cámaras Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link y varias cámaras chinas ultrabaratas y sin nombre.

Técnica

Cámaras basadas en el chipset Hisilicon 3518E. Las características de hardware de las cámaras son las siguientes:

Hormigas Xiaomi Yi
Noname

SoC
Hisilicón 3518E
Hisilicón 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Micrófono
+
+

Speaker
+
+

IRLed
+
+

Corte IR
+
+

Empezamos con ellos.

Actualmente admitimos los conjuntos de chips Hisilicon 3516/3518, así como Ambarella S2L/S2LM. Hay decenas de modelos de cámaras.

Composición del firmware

submarino

uboot es el cargador de arranque, arranca primero después del encendido, inicializa el hardware y carga el kernel de Linux.

El script de carga de la cámara es bastante 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

Una de las características es que se llama dos veces. bootm, hablaremos más sobre esto un poco más adelante, cuando lleguemos al subsistema de actualización.

Presta atención a la línea. mem=38M. Sí, sí, esto no es un error tipográfico: el kernel de Linux y todas, todas, todas las aplicaciones tienen acceso a solo 38 megabytes de RAM.

También al lado de uboot hay un bloque especial llamado reg_info, que contiene un script de bajo nivel para inicializar DDR y varios registros del sistema del SoC. Contenido reg_info Depende del modelo de cámara, y si no es correcto, la cámara ni siquiera podrá cargar uboot, sino que se congelará en la etapa inicial de carga.

Al principio, cuando trabajábamos sin el soporte del proveedor, simplemente copiamos este bloque del firmware original de la cámara.

Kernel de Linux y rootfs

Las cámaras utilizan el kernel de Linux, que forma parte del SDK del chip; normalmente estos no son los kernels más recientes de la rama 3.x, por lo que a menudo tenemos que lidiar con el hecho de que los controladores de equipos adicionales no son compatibles con el kernel utilizado. , y tenemos que volver a portarlos a las cámaras del kernel.

Otro problema es el tamaño del kernel. Cuando el tamaño de FLASH es de sólo 8 MB, entonces cada byte cuenta y nuestra tarea es desactivar cuidadosamente todas las funciones del kernel no utilizadas para reducir el tamaño al mínimo.

Rootfs es un sistema de archivos básico. Incluye busybox, controladores de módulos wifi, un conjunto de bibliotecas de sistema estándar, como libld и libc, así como nuestro software, que se encarga de la lógica de control de los LED, la gestión de la conexión de red y las actualizaciones de firmware.

El sistema de archivos raíz está conectado al kernel como initramfs y como resultado de la compilación obtenemos un archivo uImage, que contiene tanto el kernel como rootfs.

Aplicación de vídeo

La parte del firmware más compleja y que consume muchos recursos es la aplicación, que proporciona captura de audio y video, codificación de video, configura parámetros de imagen, implementa análisis de video, por ejemplo, detectores de movimiento o sonido, controla PTZ y es responsable de cambiar el día y Modos nocturnos.

Una característica importante, incluso diría clave, es cómo interactúa la aplicación de vídeo con el complemento de la nube.

En las soluciones tradicionales 'firmware de proveedor + complemento en la nube', que no pueden funcionar en hardware barato, el vídeo dentro de la cámara se transmite a través del protocolo RTSP, y esto supone una sobrecarga enorme: copiar y transmitir datos a través de un socket, llamadas al sistema innecesarias.

Aquí utilizamos el mecanismo de memoria compartida: el vídeo no se copia ni se envía a través de un conector entre los componentes del software de la cámara, por lo que utilizamos de forma óptima y cuidadosa las modestas capacidades del hardware de la cámara.

Subsistema de actualización

Un motivo de especial orgullo es el subsistema tolerante a fallos para actualizaciones de firmware en línea.

Déjame explicarte el problema. La actualización del firmware no es técnicamente una operación atómica, y si se produce un corte de energía en medio de la actualización, la memoria flash contendrá parte del nuevo firmware "suscrito". Si no se toman medidas especiales, la cámara se convertirá en un "ladrillo" que deberá llevarse a un centro de servicio.

También nos hemos ocupado de este problema. Incluso si la cámara se apaga durante la actualización, descargará automáticamente y sin intervención del usuario el firmware de la nube y restablecerá el funcionamiento.

Veamos la técnica con más detalle:

El punto más vulnerable es sobrescribir la partición con el kernel de Linux y el sistema de archivos raíz. Si uno de estos componentes está dañado, la cámara no arrancará más allá del gestor de arranque uboot, que no puede descargar firmware de la nube.

Esto significa que debemos asegurarnos de que la cámara tenga un kernel y rootfs que funcionen en cualquier momento durante el proceso de actualización. Parecería que la solución más sencilla sería almacenar constantemente dos copias del kernel con rootfs en la memoria flash y, si el kernel principal está dañado, cargarlo desde la copia de seguridad.

Una buena solución; sin embargo, el kernel con rootfs ocupa aproximadamente 3.5 MB y para una copia de seguridad permanente es necesario asignar 3.5 MB. Las cámaras más baratas simplemente no tienen tanto espacio libre para un kernel de respaldo.

Por lo tanto, para hacer una copia de seguridad del kernel durante una actualización de firmware, utilizamos la partición de la aplicación.
Y para seleccionar la partición deseada con el kernel, se utilizan dos comandos bootm en uboot: al principio intentamos cargar el kernel principal y, si está dañado, el de respaldo.

Esto garantiza que en cualquier momento la cámara tendrá el kernel correcto con rootfs y podrá iniciar y restaurar el firmware.

Sistema CI/CD para construir e implementar firmware

Para crear firmware, utilizamos gitlab CI, que crea automáticamente firmware para todos los modelos de cámaras compatibles y, después de crear el firmware, se implementa automáticamente en el servicio de actualización de software de la cámara.

Desde el servicio, las actualizaciones de firmware se envían a nuestras cámaras de prueba de control de calidad y, una vez completadas todas las etapas de prueba, a las cámaras de los usuarios.

Seguridad de la información

No es ningún secreto que hoy en día la seguridad de la información es el aspecto más importante de cualquier dispositivo IoT, incluidas las cámaras. Botnets como Mirai deambulan por Internet e infectan millones de cámaras con firmware estándar de los proveedores. Con el debido respeto a los proveedores de cámaras, no puedo dejar de señalar que el firmware estándar contiene muchas funciones que no son necesarias para trabajar con la nube, pero contiene muchas vulnerabilidades que aprovechan las botnets.

Por lo tanto, todas las funciones no utilizadas en nuestro firmware están deshabilitadas, todos los puertos tcp/udp están cerrados y, al actualizar el firmware, se verifica la firma digital del software.

Y además, el firmware se somete a pruebas periódicas en el laboratorio de seguridad de la información.

Conclusión

Ahora nuestro firmware se utiliza activamente en proyectos de videovigilancia. Quizás el mayor de ellos sea la retransmisión de la votación del día de la elección del Presidente de la Federación de Rusia.
En el proyecto participaron más de 70 mil cámaras con nuestro firmware, que fueron instaladas en los colegios electorales de nuestro país.

Habiendo resuelto una serie de problemas complejos, y en algunos lugares, incluso en ese momento casi imposibles, nosotros, por supuesto, recibimos una gran satisfacción como ingenieros, pero además, también ahorramos millones de dólares en la compra de cámaras. Y en este caso, los ahorros no son sólo palabras y cálculos teóricos, sino los resultados de una licitación ya finalizada para la compra de equipos. En consecuencia, si hablamos de videovigilancia en la nube: hay dos enfoques: confiar estratégicamente en la experiencia y el desarrollo de bajo nivel, lo que genera enormes ahorros en equipos, o utilizar equipos costosos que, si nos fijamos específicamente en las características del consumidor, prácticamente no existen. Diferentes de otros baratos similares.

¿Por qué es estratégicamente importante decidir la elección del enfoque de integración lo antes posible? Al desarrollar un complemento, los desarrolladores dependen de determinadas tecnologías (bibliotecas, protocolos, estándares). Y si se elige un conjunto de tecnologías solo para equipos costosos, entonces, en el futuro, un intento de cambiar a cámaras baratas probablemente llevará, como mínimo, un tiempo increíblemente largo o incluso fallará y se volverá a utilizar equipos costosos.

Fuente: habr.com