Olá pessoal!

Provavelmente não é segredo para ninguém que os serviços de vigilância por vídeo recentemente baseados em nuvem estão ganhando popularidade. E é compreensível que isso aconteça, o vídeo é um conteúdo "pesado", que requer infraestrutura e grandes quantidades de armazenamento em disco para armazenar. O uso de um sistema local de vigilância por vídeo requer os meios para operar e dar suporte, tanto no caso de uma organização que usa centenas de câmeras de vigilância, quanto no caso de um usuário individual com várias câmeras.

Os sistemas de vigilância por vídeo baseados na nuvem resolvem esse problema, fornecendo aos clientes uma infraestrutura existente de armazenamento e processamento de vídeo. É suficiente para um cliente de vigilância baseado na nuvem simplesmente conectar a câmera à Internet e vincular sua conta na nuvem.

Existem várias maneiras tecnológicas de conectar câmeras à nuvem. Sem dúvida, a maneira mais conveniente e barata - a câmera se conecta e trabalha diretamente com a nuvem, sem a participação de equipamentos adicionais, como um servidor ou registrador.

Para isso, é necessário que o módulo de software que trabalha com a nuvem seja instalado na câmera. No entanto, se falamos de câmeras baratas, elas têm recursos de hardware muito limitados, que são quase 100% ocupados pelo firmware nativo do fornecedor da câmera, mas não há recursos necessários para o plug-in de nuvem. Os desenvolvedores da ivideon dedicaram um artigo a esse problema, que diz por que eles não podem instalar o plug-in em câmeras baratas. Como resultado, o preço mínimo da câmera é de 5000 rublos (US $ 80) e milhões de dinheiro gasto em equipamentos.

Resolvemos esse problema com sucesso. Se você está interessado em saber como - Wellcome under cat

Um pouco de história

Em 2016, começamos a desenvolver uma plataforma de vigilância por vídeo baseada em nuvem para a Rostelecom.

Na parte do software da câmera, na primeira etapa, seguimos o caminho "padrão" para essas tarefas: desenvolvemos nosso próprio plug-in, que é instalado no firmware da câmera do fornecedor e funciona com nossa nuvem. No entanto, vale ressaltar que durante o design, usamos as soluções mais leves e eficientes (por exemplo, implementação C simples de protobuf, libev, mbedtls e bibliotecas convenientes, mas pesadas, completamente abandonadas, como boost)

Agora, no mercado de câmeras IP, não há soluções de integração universal: cada fornecedor tem sua própria maneira de instalar o plug-in, seu próprio conjunto de APIs para o firmware funcionar e um mecanismo de atualização exclusivo.

Isso significa que, para cada fornecedor de câmera, é necessário desenvolver individualmente uma camada de volume do software de integração. E no momento do início do desenvolvimento, é aconselhável trabalhar apenas com o 1º fornecedor para concentrar os esforços da equipe no desenvolvimento da lógica de trabalhar com a nuvem.

O primeiro fornecedor foi a Hikvision - uma das líderes mundiais no mercado de câmeras, fornecendo uma API bem documentada e suporte técnico de engenharia competente.

Nas câmeras Hikvision, lançamos nosso primeiro projeto piloto, vigilância por vídeo em nuvem, Video Comfort.

Quase imediatamente após o lançamento, nossos usuários começaram a fazer perguntas sobre a possibilidade de conectar câmeras de terceiros mais baratas ao serviço.

Descartar a opção com a implementação da camada de integração para cada fornecedor quase que imediatamente - como pouco escalável e apresentando sérios requisitos técnicos ao hardware da câmera. O custo da câmera, atendendo a esses requisitos na entrada: ~ 60-70 $

Portanto, decidi ir mais fundo - fazer meu firmware completamente para câmeras de qualquer fornecedor. Essa abordagem reduz significativamente os requisitos de hardware da câmera - como a camada de nuvem é uma ordem de magnitude mais eficientemente integrada ao aplicativo de vídeo e não há gordura desnecessária no firmware.

E o que é importante, ao trabalhar com a câmera em um nível baixo, é possível usar o AES de hardware, que criptografa os dados sem criar carga adicional em uma CPU de baixa potência.

Naquele momento, não tínhamos nada. Nada mesmo.

Quase todos os fornecedores não estavam prontos para trabalhar conosco em um nível tão baixo. Não há informações sobre circuitos e componentes, não há chipsets SDK oficiais e documentação do sensor.
Também não há suporte técnico.

As respostas a todas as perguntas tiveram que ser obtidas por engenharia reversa - tentativa e erro. Mas nós conseguimos.

Os primeiros modelos de câmera nos quais preenchemos os detalhes foram as câmeras Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link e várias câmeras chinesas sem nome e super baratas.

Técnica

Câmeras baseadas no chipset Hisilicon 3518E. As características de hardware das câmeras são as seguintes:

Começamos com eles.

Atualmente, suportamos os chipsets Hisilicon 3516/3518, bem como o Ambarella S2L / S2LM. O número de modelos de câmera é dezenas.

Composição do firmware

uboot

O uboot é o carregador de inicialização, depois de ligar a energia, ele inicializa primeiro, inicializa o hardware e carrega o kernel do linux.

O script de carregamento da câmera é 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 

Entre os recursos, o bootm é chamado bootm , mais tarde, quando chegamos ao subsistema de atualização.

Preste atenção à linha mem=38M . Sim, sim, isso não é um erro de digitação - apenas 38 megabytes de RAM estão disponíveis para o kernel do Linux e para todos os aplicativos.

Também ao lado do uboot está um bloco especial chamado reg_info , que contém um script de inicialização de DDR de baixo nível e vários registros do sistema SoC. O conteúdo de reg_info depende do modelo da câmera e, se não estiver correto, a câmera nem poderá fazer o download do uboot, mas travará no estágio inicial de carregamento.

Inicialmente, quando trabalhamos sem o apoio de fornecedores, simplesmente copiamos esse bloco do firmware original da câmera.

O kernel do linux e rootfs

As câmeras usam o kernel do Linux, que faz parte do chip SDK, geralmente esses não são os kernels mais recentes da ramificação 3.x, portanto, muitas vezes precisamos descobrir que os drivers de hardware adicionais não são compatíveis com o kernel usado e precisamos fazer o backport deles para o kernel. câmeras

Outro problema é o tamanho do kernel. Quando o tamanho do FLASH é de apenas 8 MB, cada byte na conta e nossa tarefa é desativar cuidadosamente todas as funções não utilizadas do kernel para reduzir o tamanho ao mínimo.

Rootfs é um sistema de arquivos básico. Ele inclui o busybox , drivers do módulo wifi, um conjunto de bibliotecas padrão do sistema, como libld e libc , além de nosso software de desenvolvimento, responsável pela lógica de controle do LED, gerenciamento de conexões de rede e atualização de firmware.

O sistema de arquivos raiz está conectado ao kernel como initramfs e, como resultado da montagem, obtemos um arquivo uImage , que contém o kernel e o rootfs.

Aplicação de vídeo

A parte mais complexa e consumidora de recursos do firmware é um aplicativo que fornece captura de vídeo e áudio, codificação de vídeo, ajusta parâmetros de imagem, implementa análise de vídeo, por exemplo, detectores de movimento ou som, controla PTZ e é responsável por alternar os modos diurno e noturno.

Um importante, diria até um recurso importante - como o aplicativo de vídeo interage com o plug-in na nuvem.

Nas soluções tradicionais 'firmware do fornecedor + plug-in de nuvem', que não funcionam em hardware barato, o vídeo dentro da câmera é transmitido usando o protocolo RTSP - e isso é uma enorme sobrecarga: copiar e transferir dados via soquete, syscalls extras.

Usamos o mecanismo de memória compartilhada neste local - o vídeo não é copiado ou enviado através do soquete entre os componentes do software da câmera, assim, de maneira ideal e cuidadosa, usando os modestos recursos de hardware da câmera.

Atualizar subsistema

Um objeto de especial orgulho é o subsistema tolerante a falhas das atualizações de firmware online.

Eu vou explicar os problemas. Tecnicamente, uma atualização de firmware não é uma operação atômica e, se ocorrer uma falha de energia no meio da atualização, haverá uma parte do novo firmware "não registrado" na memória flash. Se você não tomar medidas especiais, a câmera se tornará um "tijolo", que deve ser transportado para um centro de serviço.

Nós lidamos com esse problema. Mesmo que a câmera seja desligada no momento da atualização, ela fará o download automaticamente e sem a intervenção do usuário do firmware da nuvem e da operação de restauração.

Vamos analisar a técnica em mais detalhes:

O ponto mais vulnerável é sobrescrever a partição com o kernel do Linux e o sistema de arquivos raiz. Se um desses componentes estiver danificado, a câmera não inicializa além do uboot bootloader, que não sabe como baixar o firmware da nuvem.

Portanto, precisamos garantir que a câmera tenha um kernel e rootfs funcionando a qualquer momento durante o processo de atualização. Parece que a solução mais simples seria armazenar permanentemente na memória flash duas cópias do kernel com rootfs e, em caso de dano ao kernel principal, carregá-lo a partir do backup.

Uma boa solução - no entanto, o kernel com rootfs ocupa cerca de 3,5 MB e, para backup permanente, você precisa alocar 3,5 MB. Nas câmeras mais baratas, simplesmente não há muito espaço livre para o kernel de backup.

Portanto, para o kernel de backup durante a atualização do firmware, usamos a partição do aplicativo.
E para selecionar a partição necessária com o kernel, dois bootm no uboot são usados ​​- no início, tentamos carregar o kernel principal e, se estiver danificado, o backup.

Isso garante que a qualquer momento a câmera tenha o kernel correto com rootfs e poderá inicializar e restaurar o firmware.

Sistema de CI / CD para montagem e implantação de firmware

Para construir o firmware, usamos o gitlab CI, no qual o firmware para todos os modelos de câmera suportados é coletado automaticamente. Após a criação do firmware, eles são implantados automaticamente no serviço de atualização de software da câmera.

A partir do serviço, as atualizações de firmware são entregues às câmeras de teste do nosso controle de qualidade e, após a conclusão de todas as etapas do teste, às câmeras dos usuários.

Segurança da informação

Não é segredo que, em nosso tempo, a segurança das informações é o aspecto mais importante de qualquer dispositivo de IoT, incluindo câmeras. Botnets como Mirai andam pela Internet, afetando milhões de câmeras com firmware padrão de fornecedores. Com todo o respeito aos fornecedores de câmeras, não posso deixar de notar que o firmware padrão contém muitas funcionalidades que não são necessárias para trabalhar com a nuvem, mas contém muitas vulnerabilidades que as botnets usam.

Portanto, todas as funcionalidades não utilizadas em nosso firmware são desativadas, todas as portas TCP / UDP são fechadas e, ao atualizar o firmware, a assinatura digital do software é verificada.

Além disso, o firmware é testado regularmente no laboratório de segurança da informação.

Conclusão

Agora nosso firmware é usado ativamente em projetos de vigilância por vídeo. Talvez o mais ambicioso deles seja a transmissão da votação no dia da eleição do presidente da Federação Russa.
O projeto envolveu mais de 70 mil câmeras com nosso firmware, que foram instaladas nas assembleias de voto do nosso país.

Tendo resolvido várias tarefas complexas e, às vezes, praticamente impossíveis na época, é claro que recebemos grande satisfação como engenheiros, mas, além disso, economizamos milhões de dólares na compra de câmeras. E, nesse caso, a economia não são apenas palavras e cálculos teóricos, mas os resultados de uma licitação já realizada para a compra de equipamentos. Portanto, se falarmos sobre vigilância por vídeo em nuvem: existem duas abordagens - estrategicamente baseadas em conhecimento e desenvolvimento de baixo nível, obtendo enormes economias em equipamentos na saída ou usando equipamentos caros, que, se você observar as características do consumidor, não são praticamente diferentes dos baratos.

Por que é estrategicamente importante decidir sobre uma abordagem para o método de integração o mais cedo possível? Ao desenvolver um plug-in, os desenvolvedores aplicam-se a determinadas tecnologias (bibliotecas, protocolos, padrões). E se um conjunto de tecnologias for selecionado apenas para equipamentos caros, no futuro uma tentativa de mudar para câmeras baratas com alta probabilidade levará pelo menos um tempo incrivelmente longo ou até falhará e ocorrerá um retorno a equipamentos caros.