Hola a todos!

Probablemente no sea un secreto para nadie que recientemente los servicios de videovigilancia basados ​​en la nube estén ganando popularidad. Y es comprensible por qué sucede esto, el video es contenido "pesado", que requiere infraestructura y grandes cantidades de almacenamiento en disco para almacenar. El uso de un sistema de videovigilancia local requiere los medios para operar y dar soporte, tanto en el caso de una organización que usa cientos de cámaras de vigilancia, como en el caso de un usuario individual con varias cámaras.

Los sistemas de videovigilancia basados ​​en la nube resuelven este problema al proporcionar a los clientes una infraestructura de procesamiento y almacenamiento de video existente. Es suficiente que un cliente de vigilancia basado en la nube simplemente conecte la cámara a Internet y se una a su cuenta en la nube.

Hay varias formas tecnológicas de conectar cámaras a la nube. Sin duda, la forma más conveniente y económica: la cámara se conecta directamente y funciona con la nube, sin la participación de equipos adicionales, como un servidor o un registrador.

Para esto, es necesario que el módulo de software que trabaja con la nube esté instalado en la cámara. Sin embargo, si hablamos de cámaras baratas, tienen recursos de hardware muy limitados, que están casi al 100% ocupados por el firmware nativo del proveedor de la cámara, pero no hay recursos necesarios para el complemento en la nube. Los desarrolladores de ivideon dedicaron un artículo a este problema, que dice 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 millones de dinero gastado en equipos.

Hemos resuelto con éxito este problema. Si está interesado en cómo: Bienvenido a Cat.

Un poco de historia

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

En la parte del 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 de la cámara del proveedor y funciona con nuestra nube. Sin embargo, vale la pena señalar que durante el diseño usamos las soluciones más livianas y eficientes (por ejemplo, la implementación C simple de protobuf, libev, mbedtls y bibliotecas convenientes pero pesadas completamente abandonadas como boost)

Ahora en el mercado de cámaras IP no hay soluciones de integración universal: cada proveedor tiene su propia forma de instalar el complemento, su propio conjunto de API para que funcione el firmware y un mecanismo de actualización único.

Esto significa que para cada proveedor de cámaras es necesario desarrollar individualmente una capa de volumen de software de integración. Y en el momento del inicio del desarrollo, es recomendable trabajar solo con el primer proveedor para centrar los esfuerzos del equipo en desarrollar la lógica de trabajar con la nube.

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

En las cámaras Hikvision, lanzamos nuestro primer proyecto piloto, videovigilancia en la nube, Video Comfort.

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

Descarté la opción con la implementación de la capa de integración para cada proveedor casi de inmediato, ya que es poco escalable y presenta requisitos técnicos serios para el hardware de la cámara. El costo de la cámara, que satisface tales requisitos en la entrada: ~ 60-70 $

Por lo tanto, decidí profundizar más: hacer completamente mi firmware para cámaras de cualquier proveedor. Este enfoque reduce significativamente los requisitos de hardware de la cámara, ya que la capa de la nube es un orden de magnitud más eficientemente integrado con la aplicación de video, y no hay grasa innecesaria en el firmware.

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

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

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

Las respuestas a todas las preguntas tenían que obtenerse mediante ingeniería inversa: prueba y error. Pero lo hicimos.

Los primeros modelos de cámaras en los que llenamos los baches fueron Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, cámaras D-Link y varias cámaras chinas súper baratas 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:

Comenzamos con ellos.

Actualmente admitimos los conjuntos de chips Hisilicon 3516/3518, así como Ambarella S2L / S2LM. El número de modelos de cámaras es decenas.

Composición de firmware

uboot

uboot es el gestor de arranque, después de encender la alimentación, se inicia primero, 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 

De las características, bootm se llama bootm , más sobre eso más adelante, cuando llegamos al subsistema de actualización.

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

También al lado de uboot hay un bloque especial llamado reg_info , que contiene un script de inicialización DDR de bajo nivel y varios registros del sistema SoC. El contenido de reg_info depende del modelo de la cámara, y si no es correcto, la cámara ni siquiera podrá descargar uboot, pero se bloqueará en la etapa inicial de carga.

Al principio, cuando trabajamos sin el apoyo de los proveedores, simplemente copiamos este bloque del firmware original de la cámara.

El kernel de linux y rootfs

Las cámaras usan el kernel de Linux, que es parte del chip SDK, por lo general, estos no son los kernel más recientes de la rama 3.x, por lo que a menudo tenemos que encontrar que los controladores de hardware adicionales no son compatibles con el kernel utilizado, y tenemos que respaldarlos en el kernel cámaras

Otro problema es el tamaño del núcleo. Cuando el tamaño de FLASH es de solo 8 MB, entonces cada byte en la cuenta y nuestra tarea es deshabilitar cuidadosamente todas las funciones del núcleo no utilizadas para reducir el tamaño al mínimo.

Rootfs es un sistema de archivos básico. Incluye busybox , controladores del módulo wifi, un conjunto de bibliotecas de sistema estándar, como libld y libc , así como nuestro software de desarrollo, que es responsable de la lógica de control del LED, la gestión de la conexión de red y la actualización del firmware.

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

Aplicación de video

La parte más compleja y que consume más recursos del firmware es una aplicación que proporciona captura de audio y video, codificación de video, ajusta los parámetros de imagen, implementa análisis de video, por ejemplo, detectores de movimiento o sonido, controla PTZ y es responsable de cambiar los modos diurno y nocturno.

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

En las soluciones tradicionales 'proveedor de firmware + plug-in en la nube', que no pueden funcionar en hardware barato, el video dentro de la cámara se transmite utilizando el protocolo RTSP, y esto es una gran sobrecarga: copiar y transferir datos a través de sockets, syscalls superfluos.

En este lugar, utilizamos el mecanismo de memoria compartida: el video no se copia ni se envía a través del zócalo entre los componentes del software de la cámara, por lo tanto, de manera óptima y cuidadosa, utilizando las modestas capacidades de hardware de la cámara.

Actualizar subsistema

Un objeto de especial orgullo es el subsistema tolerante a fallas de las actualizaciones de firmware en línea.

Explicaré los problemas. Técnicamente, una actualización de firmware no es una operación atómica, y si ocurre una falla de energía en el medio de la actualización, entonces habrá una parte del nuevo firmware "no grabado" en la memoria flash. Si no toma medidas especiales, la cámara se convertirá en un "ladrillo", que debe llevarse a un centro de servicio.

Hemos tratado este problema. Incluso si la cámara está apagada en el momento de la actualización, descargará automáticamente el firmware de la nube y restaurará la operación sin intervención del usuario.

Analicemos 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 resulta dañado, la cámara no arranca más allá del cargador de arranque uboot, que no sabe cómo descargar firmware desde la nube.

Por lo tanto, debemos asegurarnos de que la cámara tenga un kernel y rootfs en funcionamiento en cualquier momento durante el proceso de actualización. Parece que la solución más simple sería almacenar permanentemente en la memoria flash dos copias del kernel con rootfs y, en caso de daño al kernel principal, cargarlo desde la copia de seguridad.

Una buena solución: sin embargo, el kernel con rootfs ocupa aproximadamente 3.5 MB y para la copia de seguridad permanente debe asignar 3.5 MB. En las cámaras más baratas, simplemente no hay tanto espacio libre para el kernel de respaldo.

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

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

Sistema CI / CD para ensamblar y desplegar firmware

Para construir el firmware, utilizamos gitlab CI, en el cual el firmware para todos los modelos de cámaras compatibles se recopila automáticamente, después de que se construye el firmware, se implementan automáticamente en el servicio de actualización de software de la cámara.

Desde el servicio, las actualizaciones de firmware se entregan a las cámaras de prueba de nuestro control de calidad, y al finalizar todas las etapas de prueba, a las cámaras de los usuarios.

Seguridad de la información

No es ningún secreto que en nuestro tiempo, la seguridad de la información es el aspecto más importante de cualquier dispositivo IoT, incluidas las cámaras. Las botnets como Mirai caminan por Internet, afectando a millones de cámaras con firmware estándar de los proveedores. Con el debido respeto a los vendedores de cámaras, no puedo dejar de notar que el firmware estándar contiene muchas funcionalidades que no son necesarias para trabajar con la nube, pero contiene muchas vulnerabilidades que usan las botnets.

Por lo tanto, toda la funcionalidad no utilizada en nuestro firmware está desactivada, todos los puertos tcp / udp están cerrados y, al actualizar el firmware, se verifica la firma digital del software.

Y además de esto, el firmware se prueba regularmente en el laboratorio de seguridad de la información.

Conclusión

Ahora nuestro firmware se usa activamente en proyectos de videovigilancia. Quizás el más ambicioso de ellos es la transmisión de la votación el día de la elección del Presidente de la Federación de Rusia.
El proyecto involucró más de 70 mil cámaras con nuestro firmware, que se instalaron en los colegios electorales de nuestro país.

Habiendo resuelto una serie de tareas complejas, y a veces incluso prácticamente imposibles en ese momento, por supuesto, recibimos una gran satisfacción como ingenieros, pero además de esto, ahorramos millones de dólares en la compra de cámaras. Y en este caso, los ahorros no son solo palabras y cálculos teóricos, sino los resultados de una licitación ya realizada 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, obtener grandes ahorros en equipos en la salida o usar equipos caros, que, si observa las características del consumidor, prácticamente no es diferente de uno similar barato.

¿Por qué es estratégicamente importante decidir sobre un enfoque del método de integración lo antes posible? Al desarrollar un complemento, los desarrolladores utilizan ciertas tecnologías (bibliotecas, protocolos, estándares). Y si se selecciona un conjunto de tecnologías solo para equipos costosos, en el futuro un intento de cambiar a cámaras baratas con una alta probabilidad al menos llevará un tiempo increíblemente largo o incluso fallará y se producirá un retorno a equipos costosos.