Ola a todos!

Probablemente non sexa ningún segredo que os servizos de videovixilancia na nube foron gañando popularidade recentemente. E está claro por que isto ocorre, o vídeo é contido "pesado", cuxo almacenamento require infraestrutura e grandes cantidades de almacenamento en disco. O uso dun sistema de videovixilancia local require fondos para funcionar e apoiar, tanto para unha organización que utiliza centos de cámaras de vixilancia como para un usuario individual con varias cámaras.

Os sistemas de videovixilancia na nube resolven este problema proporcionando aos clientes unha infraestrutura de almacenamento e procesamento de vídeo existente. Un cliente de videovixilancia na nube só precisa conectar a cámara a Internet e vinculala á súa conta na nube.

Existen varias formas tecnolóxicas de conectar cámaras á nube. Sen dúbida, o método máis cómodo e barato é que a cámara se conecte directamente e funcione coa nube, sen a participación de equipos adicionais como un servidor ou unha gravadora.

Para iso, é necesario que se instale na cámara un módulo de software que funcione coa nube. Non obstante, se falamos de cámaras baratas, entón teñen recursos de hardware moi limitados, que están case o 100% ocupados polo firmware nativo do vendedor da cámara, e non hai recursos necesarios para o complemento na nube. Os desenvolvedores de ivideon dedicaron este problema un artigo, o que explica por que non poden instalar o complemento en cámaras baratas. Como resultado, o prezo mínimo da cámara é de 5000 rublos (80 dólares) e millóns de diñeiro gastados en equipos.

Resolvemos con éxito este problema. Se estás interesado en saber como - benvido ao corte

Un pouco de historia

En 2016, comezamos a desenvolver unha plataforma de videovixilancia na nube para Rostelecom.

En canto ao software da cámara, na primeira etapa seguimos o camiño "estándar" para tales tarefas: desenvolvemos o noso propio complemento, que está instalado no firmware estándar da cámara do provedor e funciona coa nosa nube. Non obstante, paga a pena notar que durante o deseño usamos as solucións máis lixeiras e eficientes (por exemplo, a implementación en C simple de protobuf, libev, mbedtls e bibliotecas convenientes pero pesadas completamente abandonadas como o boost)

Actualmente, non hai solucións de integración universal no mercado de cámaras IP: cada provedor ten a súa propia forma de instalar o complemento, o seu propio conxunto de API para operar o firmware e un mecanismo de actualización único.

Isto significa que para cada vendedor de cámaras é necesario desenvolver individualmente unha capa completa de software de integración. E no momento de comezar o desenvolvemento, é recomendable traballar só con 1 provedor para concentrar os esforzos do equipo no desenvolvemento da lóxica para traballar coa nube.

O primeiro provedor elixido foi Hikvision, un dos líderes mundiais no mercado de cámaras, que ofrece unha API ben documentada e soporte técnico de enxeñería competente.

Lanzamos o noso primeiro proxecto piloto, videovixilancia na nube Video Comfort, utilizando cámaras Hikvision.

Case inmediatamente despois do lanzamento, os nosos usuarios comezaron a facer preguntas sobre a posibilidade de conectar cámaras máis baratas doutros fabricantes ao servizo.

Rexeitei a opción de implementar unha capa de integración para cada provedor case de inmediato, xa que é pouco escalable e impón serios requisitos técnicos ao hardware da cámara. O custo dunha cámara que cumpra estes requisitos de entrada: ~60-70 $

Polo tanto, decidín afondar: facer o meu propio firmware para cámaras de calquera vendedor. Este enfoque reduce significativamente os requisitos para os recursos de hardware da cámara - porque A capa para traballar coa nube está integrada de forma moito máis eficaz coa aplicación de vídeo e non hai graxa innecesaria non utilizada no firmware.

E o importante é que cando se traballa coa cámara a un nivel baixo, é posible usar AES de hardware, que cifra os datos sen crear carga adicional na CPU de baixa potencia.

Nese momento non tiñamos nada de nada. Non é nada.

Case todos os provedores non estaban preparados para traballar connosco a un nivel tan baixo. Non hai información sobre os circuítos e os compoñentes, non hai ningún SDK oficial de conxuntos de chips e documentación de sensores.
Tampouco hai soporte técnico.

Todas as preguntas tiñan que ser respondidas mediante enxeñería inversa: proba e erro. Pero conseguimos.

Os primeiros modelos de cámara que probamos foron Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, cámaras D-Link e varias cámaras chinesas sen nome ultrabaratas.

Técnica

Cámaras baseadas no chipset Hisilicon 3518E. As características do hardware das cámaras son as seguintes:

Formigas Xiaomi Yi
Sen nome

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensores
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

micrófono
+
+

Altofalante
+
+

IRLed
+
+

IRCut
+
+

Comezamos con eles.

Actualmente admitimos chipsets Hisilicon 3516/3518, así como Ambarella S2L/S2LM. Hai decenas de modelos de cámaras.

Composición do firmware

submarino

uboot é o cargador de arranque, arranca primeiro despois de acendelo, inicializa o hardware e carga o núcleo de Linux.

O script de carga da cámara é 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

Unha das características é que se chama dúas veces bootm, máis sobre isto un pouco máis tarde, cando cheguemos ao subsistema de actualización.

Preste atención á liña mem=38M. Si, si, isto non é un erro: o núcleo de Linux e todas, todas, todas as aplicacións teñen acceso a só 38 megabytes de RAM.

Tamén xunto a uboot hai un bloque especial chamado reg_info, que contén un script de baixo nivel para inicializar DDR e unha serie de rexistros do sistema do SoC. Contido reg_info depende do modelo de cámara e, se non é correcta, a cámara nin sequera poderá cargar uboot, pero conxelarase na fase inicial da carga.

Ao principio, cando traballabamos sen soporte do vendedor, simplemente copiamos este bloque do firmware orixinal da cámara.

Núcleo Linux e rootfs

As cámaras usan o núcleo Linux, que forma parte do SDK do chip, normalmente estes non son os últimos núcleos da rama 3.x, polo que moitas veces temos que lidiar co feito de que os controladores para equipos adicionais non son compatibles co núcleo utilizado. , e temos que retroportalos ás cámaras do núcleo.

Outro problema é o tamaño do núcleo. Cando o tamaño de FLASH é só de 8 MB, entón cada byte conta e a nosa tarefa é desactivar coidadosamente todas as funcións do núcleo non utilizadas para reducir o tamaño ao mínimo.

Rootfs é un sistema de ficheiros básico. Inclúe busybox, controladores de módulo wifi, un conxunto de bibliotecas de sistema estándar, como libld и libc, así como o noso software, que é responsable da lóxica de control de LED, a xestión da conexión de rede e as actualizacións de firmware.

O sistema de ficheiros raíz está conectado ao núcleo como initramfs e, como resultado da compilación, obtemos un ficheiro uImage, que contén tanto o núcleo como o rootfs.

Aplicación de vídeo

A parte máis complexa e que consume máis recursos do firmware é a aplicación, que proporciona captura de audio e vídeo, codificación de vídeo, configura os parámetros de imaxe, implementa análises de vídeo, por exemplo, detectores de movemento ou de son, controla PTZ e é responsable do cambio de día e modos nocturnos.

Unha característica importante, incluso diría clave, é como interactúa a aplicación de vídeo co complemento na nube.

Nas solucións tradicionais "firmware do vendedor + complemento na nube", que non poden funcionar con hardware barato, o vídeo dentro da cámara transmítese a través do protocolo RTSP, e isto supón unha sobrecarga enorme: copia e transmisión de datos a través de socket, chamadas de sistema innecesarias.

Aquí usamos o mecanismo de memoria compartida: o vídeo non se copia nin se envía a través do socket entre os compoñentes do software da cámara, polo que se utiliza de forma óptima e coidadosa as capacidades de hardware modestas da cámara.

Actualizar o subsistema

Un punto de orgullo especial é o subsistema tolerante a fallos para as actualizacións de firmware en liña.

Déixame explicar o problema. A actualización do firmware tecnicamente non é unha operación atómica, e se se produce un fallo de enerxía no medio da actualización, a memoria flash conterá parte do novo firmware "subscripto". Se non tomas medidas especiais, a cámara converterase nun "ladrillo" que debes levar a un centro de servizo.

Nós tamén tratamos con este problema. Aínda que a cámara estea desactivada durante a actualización, descargará automaticamente e sen intervención do usuario o firmware da nube e restaurará o funcionamento.

Vexamos a técnica con máis detalle:

O punto máis vulnerable é sobrescribir a partición co núcleo de Linux e o sistema de ficheiros raíz. Se un destes compoñentes está danado, a cámara non arrancará máis aló do cargador de arranque de uboot, que non pode descargar firmware da nube.

Isto significa que debemos asegurarnos de que a cámara teña un núcleo e rootfs que funcionen en calquera momento durante o proceso de actualización. Parece que a solución máis sinxela sería almacenar constantemente dúas copias do núcleo con rootfs na memoria flash e, se o núcleo principal está danado, cargalo desde a copia de seguridade.

Unha boa solución; non obstante, o núcleo con rootfs ocupa uns 3.5 MB e para unha copia de seguridade permanente cómpre asignar 3.5 MB. As cámaras máis baratas simplemente non teñen tanto espazo libre para un núcleo de copia de seguridade.

Polo tanto, para facer unha copia de seguridade do núcleo durante unha actualización de firmware, usamos a partición da aplicación.
E para seleccionar a partición desexada co núcleo, utilízanse dous comandos bootm en uboot - ao principio tentamos cargar o núcleo principal e se está danado, entón o de copia de seguridade.

Isto garante que en cada momento a cámara terá o núcleo correcto con rootfs, e poderá iniciar e restaurar o firmware.

Sistema CI/CD para crear e implantar firmware

Para crear o firmware, usamos gitlab CI, que crea automaticamente o firmware para todos os modelos de cámara compatibles e, despois de construír o firmware, desprégase automaticamente no servizo de actualización de software da cámara.

Desde o servizo, as actualizacións de firmware entréganse ás nosas cámaras de proba de control de calidade e, ao rematar todas as fases de proba, ás cámaras dos usuarios.

Seguridade da información

Non é ningún segredo que hoxe en día a seguridade da información é o aspecto máis importante de calquera dispositivo IoT, incluídas as cámaras. Botnets como Mirai están en itinerancia por Internet, infectando millóns de cámaras con firmware estándar dos provedores. Con todo o respecto aos provedores de cámaras, non podo deixar de ter en conta que o firmware estándar contén unha gran cantidade de funcionalidades que non son necesarias para traballar coa nube, pero contén moitas vulnerabilidades das que aproveitan as botnets.

Polo tanto, todas as funcións non utilizadas do noso firmware están desactivadas, todos os portos tcp/udp están pechados e, ao actualizar o firmware, compróbase a sinatura dixital do software.

Ademais, o firmware é sometido a probas regulares no laboratorio de seguridade da información.

Conclusión

Agora o noso firmware úsase activamente en proxectos de videovixilancia. Quizais o maior deles sexa a emisión de votacións o día da elección do presidente da Federación Rusa.
O proxecto implicou máis de 70 mil cámaras co noso firmware, que foron instaladas nos colexios electorais do noso país.

Despois de resolver unha serie de problemas complexos e, nalgúns lugares, mesmo naquel momento case imposibles, obviamos, por suposto, unha gran satisfacción como enxeñeiros, pero ademais diso, tamén aforramos millóns de dólares na compra de cámaras. E neste caso, o aforro non son só palabras e cálculos teóricos, senón o resultado dunha licitación xa rematada para a compra de equipos. En consecuencia, se falamos de videovixilancia na nube: hai dous enfoques: confiar estratexicamente en coñecementos e desenvolvemento de baixo nivel, o que resulta en grandes aforros en equipos, ou usar equipos caros, que, se observas especificamente as características do consumidor, practicamente non é ningún. diferentes dos similares baratos.

Por que é estratexicamente importante decidir sobre a elección do enfoque de integración canto antes? Ao desenvolver un complemento, os desenvolvedores confían en certas tecnoloxías (bibliotecas, protocolos, estándares). E se se escolle un conxunto de tecnoloxías só para equipos caros, entón, no futuro, un intento de cambiar a cámaras baratas probablemente levará, como mínimo, un tempo moi longo ou mesmo fallará e producirase un retorno a equipos caros.

Fonte: www.habr.com