Building Linux-based NVRs

Overview

Este artigo descreve passos comuns para um parceiro que deseja fazer um produto de hardware semelhante a NVR – um computador embutido (chamado aqui de “NVR”) com um aplicativo de servidor pré-instalado. Tipicamente, tal NVR é um computador baseado em Linux com uma CPU ARM.

Os passos básicos para fazer um produto desse tipo incluem o seguinte:

• Selecionar hardware
• Plataforma
• Armazenamento
• Selecionar sabor Linux
• Instalar aplicativo Servidor
• Implementar recursos extras
• Estabelecer uma política de suporte

Estes passos são descritos abaixo em detalhes.

Selecionar hardware

Para que um produto tenha sucesso, ele deve ser econômico e fornecer o desempenho necessário – suportar o número desejado de câmeras com a taxa de bits/resolução desejada. O hardware utilizado deve ter pelo menos 1GB de RAM e um chipset ARM Cortex A7 ou superior.

É recomendado primeiro estudar o desempenho das plataformas ARM suportadas (veja Política de Suporte ARM para a lista de tais plataformas), e então escolher uma plataforma mais próxima às suas necessidades.

Plataforma

A plataforma ARM suportada escolhida pode ser usada como uma das seguintes:

• um computador pronto para comprar (por exemplo uma placa principal padrão Raspberry Pi), possivelmente com uma caixa personalizada e uma unidade de alimentação;
• uma referência para projetar um computador personalizado com a placa principal que pode hospedar componentes de hardware adicionais, como interfaces periféricas ou controladores de disco rígido.

Se for esperado que o NVR tenha software adicional na placa além do aplicativo do servidor, como um servidor web que forneça uma interface web ao usuário, software de análise de vídeo (por exemplo, um plugin VMS e/ou seu backend), ou algo semelhante, certifique-se de adicionar memória RAM e poder de processamento da CPU suficientes para cobrir isso.

Transcodificação de vídeo não é suportada em dispositivos ARM devido ao limitado poder de computação. Além disso, algumas dependências como o OpenSSL podem ter problemas de compatibilidade. Se a análise inicial mostrar que uma plataforma típica baseada no ARM não fornecerá o desempenho necessário, uma plataforma x64 pode ser considerada.

O desempenho de armazenamento da plataforma deve ser bom o suficiente para a carga planejada. Por exemplo, sabe-se que soluções como SATA-over-USB podem levar a um baixo desempenho de HDD, insuficiente para gravar o número necessário de câmeras.

O desempenho da rede da plataforma deve ser bom o suficiente para a carga planejada. Por exemplo, sabe-se que soluções como a implementação de Ethernet baseada em software exigem muitos recursos da CPU e, portanto, podem levar a quedas de quadros durante a gravação de câmeras ou streaming para os Clientes, ou outros problemas. Além disso, os modelos de hardware que implementam a Ethernet via hub USB podem ter menos largura de banda do que a anunciada na rede.

A plataforma deve estar equipada com um hardware Real-Time Clock (RTC), e/ou a sincronização de tempo através da rede (por exemplo, usando o protocolo NTP) deve estar ativada – para que o VMS funcione corretamente, a data e a hora do SO devem estar corretas. Se não houver nenhum RTC de hardware, e a única fonte de data/hora planejada para ser a rede, é recomendado que o dispositivo se recuse a iniciar caso não possa sincronizar a data/hora.

Armazenamento

Certifique-se de que há espaço suficiente no sistema de arquivos para que o VMS funcione corretamente. O servidor usa os seguintes locais de armazenamento:

• Instalação do VMS – binários e bibliotecas dinâmicas (.so files)
• Localizado em /opt/<vendor>/mediaserver/
• Espaço necessário: pode ser calculado medindo o tamanho total dos respectivos arquivos na distribuição com alguma margem adicionada; quanto maior a margem – menores as chances de problemas com atualização para versões futuras. Geralmente, uma margem de 30% é recomendada.
• Se não houver armazenamento suficiente em /opt, .so arquivos podem ser movidos via symlinks para outro local, incluindo armazenamento FAT32 (mas neste caso apenas arquivos que não são symlinks podem ser movidos).
• Arquivos do banco de dados do servidor – armazena informações sobre câmeras e outros Servidores, logs de eventos, etc.
• Tipicamente localizado em /opt/<vendor>/mediaserver/var/; pode ser alterado no arquivo de configuração do Servidor.
• Requer ext4 filesystem
• Espaço requerido: depende do número de câmeras e Servidores no Sistema VMS, mas geralmente é recomendado pelo menos 500 MB.
• Base de dados de análise do servidor – armazena metadados de análise de vídeo gerados pelos Plugins de análise
• Tipicamente localizado em /opt/<vendor>/mediaserver/var/data; pode ser alterado no arquivo de configuração do servidor.
• Espaço requerido: depende se os Plugins de Análise estão em uso neste Servidor, e quanto metadados os Plugins enviarão. Geralmente, 20% do tamanho de armazenamento do Arquivo de Vídeo é recomendado se Plugins de Análise forem usados neste Servidor.
• Logs do Servidor
• Localizado em /opt/<vendor>/mediaserver/var/log/
  • Pode ser realocado via mediaserver.conf.
• Logs são automaticamente sobrescritos em um loop.
• Espaço requerido: pelo menos 260 MB é recomendado.
• NOTE: Notamos que em dispositivos ARM específicos (por exemplo Raspberry Pi 3), a memória flash interna (Micro SD, nesse caso) não era suficientemente boa para aceitar logs. O sistema congelaria por até 4 segundos. Recomendamos redirecionar os logs para o mesmo local do arquivo de vídeo para tais dispositivos.
• Arquivo de vídeo – armazena o vídeo gravado das câmeras
  • Tipicamente localizado em /opt/<vendor>/mediaserver; pode ser alterado no arquivo de configuração do Servidor.
  • A partição do sistema será provavelmente impedida de gravar por padrão, a menos que haja pelo menos 10 GB de espaço livre.
  • Memória flash interna (eMMC) ou Cartão SD
    • Estime quantos ciclos de gravação a memória pode aceitar. O arquivo de vídeo é automaticamente sobrescrito em um loop, assim, a duração de um único ciclo de gravação pode ser calculada dividindo o espaço livre pela taxa de bits combinada de todas as câmeras sendo gravadas no Servidor.
    • Certifique-se de que o débito da memória é suficiente para a taxa de bits combinada de todas as câmaras a serem gravadas no Servidor, com uma margem de segurança de 30%.
  • HDD interno ou SSD
    • Certifique-se de que o débito do disco é suficiente para a taxa de bits combinada de todas as câmaras a serem gravadas no Servidor, com uma margem de segurança de 30%.
  • NAS externo
    • Certifique-se de que a largura de banda real do adaptador de rede é suficiente para a taxa de bits combinada de todas as câmeras sendo gravadas no Servidor multiplicada por 2 (porque as câmeras presumivelmente enviam seus fluxos para o Servidor usando o mesmo adaptador de rede), com uma margem de segurança de 30%.
• Arquivos de atualização da aplicação Servidor
• Para poder atualizar, a aplicação Servidor precisa baixar sua versão mais recente e descompactá-la.
• Localizado em /tmp/
• Espaço necessário: o tamanho total do arquivo de distribuição do Servidor empacotado multiplicado por 2,6; isto inclui a margem. Mais espaço pode ser recomendado para minimizar as chances de problemas com a atualização para versões futuras.

• OS arquivos temporários
• Tipicamente localizado em /tmp/
• Espaço requerido: pelo menos 100 MB é recomendado, não incluindo o espaço requerido para os arquivos de atualização da aplicação Servidor (veja acima).

A maior parte das coisas listadas acima pode ser atribuída para ser armazenada em um local diferente no arquivo de configuração do Servidor: /opt/<vendor>/mediaserver/etc/mediaserver.conf

Desde que o armazenamento típico do cartão SD não é fiável e conhecido por falhar durante operações intensivas de leitura-escrita, recomendamos instalar o SO e armazenar o arquivo de vídeo num(s) disco(s) rígido(s). Se um drive SSD/SD ou cartão SD for considerado para armazenar o arquivo de vídeo, avalie sua capacidade para múltiplas operações de reescrita usando a taxa de bits típica de uma câmera suportada multiplicada pelo número desejado de câmeras suportadas.

Por exemplo, para o Raspberry Pi 3 B+:

• Utilizar adaptador USB-SATA e disco rígido externo para o arquivo.
• Instalar SO (Raspbian) em um disco rígido externo. Veja o artigo Como inicializar seu Raspberry Pi a partir de um dispositivo de armazenamento em massa USB para mais detalhes. Este processo deve ser automatizado dependendo de como os dispositivos ARM vão ser distribuídos: com ou sem disco rígido:

• Com disco rígido – faça uma imagem pré-configurada com o VMS instalado e clone-a para discos rígidos.
• Sem disco rígido – você terá que criar um conjunto de scripts que formata o HDD, copia o SO e faz todos os ajustes necessários. Esta é uma tarefa bastante complexa e demorada.

Escolha o Linux Flavor

Existem normalmente várias opções para o SO Linux num determinado NVR:

• “Busybox” – apenas o kernel Linux e o conjunto básico de ferramentas de linha de comando; utilizado em NVRs de relativamente baixo desempenho, tais como câmaras “edge” (câmaras com o Servidor VMS a correr nelas).
• Standard Debian, ou uma das suas variantes como Ubuntu.
• Versão modificada de Debian ou outra distribuição Linux, normalmente modificada pelo vendedor de dispositivos (por exemplo, Raspbian para Raspberry Pi).

Geralmente, é recomendado escolher uma variante do Linux que é a escolha nativa para a plataforma na qual o NVR é baseado. Por exemplo, ao desenvolver um NVR similar em hardware ao Raspberry Pi (ou mesmo usando a placa principal exata do Raspberry Pi), é recomendado escolher Raspbian.

Se várias distribuições Linux com diferentes conjuntos de pacotes estiverem disponíveis para o dispositivo, a menos pesada é recomendada. Por exemplo, se não há nenhum plano para mostrar a GUI no NVR, não há necessidade do Sistema X Window.

Certifique-se de que a versão Linux e seu conjunto de pacotes satisfazem os requisitos do VMS. Para dispositivos baseados no ARM, consulte os detalhes do SO especificados na Política de Suporte do ARM.

Instalar aplicativo Servidor

Após o NVR ser carregado com um SO Linux adequado, o aplicativo Servidor deve ser instalado no NVR. Existem basicamente duas opções:

1. Para SO baseado em Debian: instale o pacote .deb oficial da distribuição VMS usando dpkg.

• Veja as instruções detalhadas para instalar o VMS em um dispositivo: Instruções de instalação do ARM SBC

Para SO baseado no Busybox: extraia os arquivos necessários do pacote .deb do VMS para o diretório desejado e cuide manualmente dos seguintes aspectos:

• Como o Servidor será iniciado no momento do boot e se o suporte system.d da distribuição não for adequado?
• Onde o Servidor levará as bibliotecas .so que faltam no Linux instalado?
• O sistema de actualização automática VMS padrão será activado?

Para configurações de SO menos típicas, poderá ser necessária alguma combinação de opções 1 e 2.

Implementar funcionalidades extra

Tipicamente, um NVR não é apenas um computador Linux padrão com a aplicação Servidor instalada – frequentemente fornece funcionalidades adicionais ao utilizador:

• Botões de Hardware, LEDs ou mesmo monitores embebidos.
• Interface web que lhe permite personalizar o NVR para além da simples configuração do aplicativo Servidor através da sua própria interface web, tais como
• Opções de rede: endereço IP, sub-rede, etc.;
• hora e fuso horário do sistema;
• saída vídeo (por exemplo, HDMI) que mostra uma GUI ou pelo menos uma tela de boas-vindas com valores básicos de configuração como o endereço IP do NVR;
• Software adicional que roda em paralelo ao VMS, como um daemon de configuração ou um backend de análise de vídeo.
  • Se o software adicional tiver uma autenticação baseada em senha para o usuário final, considere implementar a sincronização de senha, para que a senha do servidor do VMS seja sempre a mesma do software adicional. Se o ssh for oferecido ao usuário para acessar o NVR, considere sincronizar sua senha também.
• Ajustes adicionais, como a minimização da memória de vídeo (GPU). Por exemplo, para o Raspberry Pi 3 B+, defina a memória da GPU para 16 MB. Veja a documentação do Raspberry Pi para detalhes.

Para implementar tais recursos, pode ser necessário escrever ou modificar scripts que controlam o aplicativo Servidor, ou escrever programas adicionais em C/C++.

Sincronização de tempo

Certifique-se de que o NVR tem uma bateria CMOS incorporada para evitar que seu relógio seja reinicializado no caso de perda de energia. Por exemplo, o Raspberry Pi 3 B+ não tem uma bateria CMOS a bordo. Se o dispositivo for reinicializado, o tempo será reinicializado e resultará na escrita incorreta do arquivo. Para evitar isso, existem algumas opções:

• Conecte-se à internet para sincronizar o tempo.
• Se for uma rede fechada, você terá que configurar um servidor NTP.
• Adicionar um módulo de Relógio em Tempo Real (RTC) à placa e pré-configurá-lo. Veja Adicionando um Relógio em Tempo Real ao seu Raspberry Pi.

Finding/Building an Enclosure for Your NVR

É necessário encontrar ou projetar um estojo que se ajuste a todo o hardware mencionado acima.

Conduct Extensive Load/Stress Test

Para garantir que tudo funcione em conjunto, é necessário planejar um teste de estresse intensivo para garantir que não haja superaquecimento ou mau funcionamento dos componentes. O teste deve ser capaz de carregar todos os componentes do sistema como CPU, memória, disco(s) rígido(s), rede e Wi-Fi (se necessário), etc.

Política de suporte estabelecido

O NVR será fornecido aos seus usuários finais, e eles definitivamente necessitarão de algum tipo de suporte técnico. A equipe de suporte do fornecedor do VMS não pode prestar tais serviços aos usuários finais, portanto, uma política para fornecer tal suporte deve ser desenvolvida, como uma mesa de suporte online, um fórum da comunidade, ou algo semelhante.

Quando a equipe de suporte do fornecedor de NVR tem certeza de que o problema em particular não está relacionado com as especificidades do NVR em si, mas sim é um problema no VMS, ela pode solicitar o suporte do fornecedor de VMS de acordo com a Política de Suporte ARM acima mencionada, e então usar o resultado deste caso de suporte para satisfazer o pedido de suporte de um usuário final.

Questões

Se você tiver alguma dúvida relacionada a este tópico ou quiser compartilhar sua experiência com outros membros da comunidade ou com nossa equipe, por favor, visite e se envolva em nossa comunidade de suporte ou entre em contato com o seu revendedor local.