Costruire NVR basati su Linux

Panoramica

Questo articolo descrive i passi comuni per un partner che vuole fare un prodotto hardware simile a un NVR – un computer incorporato (chiamato qui “NVR”) con un’applicazione Server preinstallata. Tipicamente, un tale NVR è un computer basato su Linux con una CPU ARM.

I passi fondamentali per realizzare un tale prodotto includono quanto segue:

  • Scegliere l’hardware
    • Piattaforma
    • Storage
  • Scegliere il gusto Linux
  • Installare l’applicazione Server
  • Implementare caratteristiche extra
  • Stabilire una politica di supporto

Questi passi sono descritti in dettaglio di seguito.

Scegliere l’hardware

Per avere successo un prodotto dovrebbe essere conveniente e fornire le prestazioni richieste – supportare il numero desiderato di telecamere con il bitrate/risoluzione desiderato. L’hardware utilizzato dovrebbe avere almeno 1GB di RAM e un chipset ARM Cortex A7 o superiore.

Si raccomanda di studiare prima le prestazioni delle piattaforme ARM supportate (vedi ARM Support Policy per la lista di tali piattaforme), e poi scegliere una piattaforma più vicina alle tue esigenze.

Piattaforma

La piattaforma ARM supportata scelta può essere usata come una delle seguenti:

  • un computer pronto all’acquisto (per esempio una scheda madre standard Raspberry Pi), possibilmente con un case e un alimentatore personalizzati;
  • un riferimento per progettare un computer personalizzato con la scheda madre che può ospitare componenti hardware aggiuntivi come interfacce periferiche o controller di dischi rigidi.

Se si prevede che l’NVR abbia software aggiuntivo a bordo oltre all’applicazione Server, come un server web che fornisce un’interfaccia web all’utente, un software di analisi video (ad esempio un plugin VMS e/o il suo backend), o simili, assicurarsi di aggiungere sufficiente RAM e potenza di elaborazione della CPU per coprire questo.

La transcodifica video non è supportata sui dispositivi ARM a causa della limitata potenza di calcolo. Inoltre, alcune dipendenze come OpenSSL possono avere problemi di compatibilità. Se l’analisi iniziale mostra che una tipica piattaforma basata su ARM non fornirà le prestazioni richieste, si può considerare una piattaforma x64.

Le prestazioni di memorizzazione della piattaforma dovrebbero essere abbastanza buone per il carico previsto. Per esempio, è noto che soluzioni come SATA-over-USB possono portare a scarse prestazioni HDD, insufficienti per la registrazione del numero richiesto di telecamere.

Le prestazioni di rete della piattaforma dovrebbero essere abbastanza buone per il carico previsto. Per esempio, è noto che soluzioni come l’implementazione Ethernet basata su software richiedono molte risorse della CPU e quindi possono portare a cali di frame durante la registrazione delle telecamere o lo streaming ai client, o altri problemi. Inoltre, i modelli hardware che implementano ethernet tramite hub USB possono avere una larghezza di banda di rete inferiore a quella pubblicizzata.

La piattaforma dovrebbe essere dotata di un Real-Time Clock (RTC) hardware, e/o la sincronizzazione del tempo attraverso la rete (ad esempio utilizzando il protocollo NTP) dovrebbe essere abilitata – perché il VMS funzioni correttamente, la data e l’ora del sistema operativo devono essere corrette. Se non c’è un RTC hardware, e l’unica fonte di data/ora è prevista essere la rete, si raccomanda che il dispositivo si rifiuti di avviarsi del tutto nel caso in cui non possa sincronizzare la data/ora.

Storage

Assicurati che ci sia abbastanza spazio sul filesystem perché il VMS funzioni correttamente. Il server usa le seguenti locazioni di immagazzinamento:

  • Installazione del VMS – binari e librerie dinamiche (file .so)
    • Localizzate in /opt/<vendor>/mediaserver/
    • Spazio richiesto: può essere calcolato misurando la dimensione totale dei rispettivi file nella distribuzione con un margine aggiunto; più alto è il margine – meno possibilità ci sono di problemi con l’aggiornamento alle versioni future. Generalmente, si raccomanda un margine del 30%.
    • Se non c’è abbastanza spazio in /opt, i file .so possono essere spostati tramite link simbolici in un’altra posizione, inclusa la memoria FAT32 (ma in questo caso solo i file che non sono link simbolici possono essere spostati).
  • File del database del server – memorizza informazioni sulle telecamere e altri server, log degli eventi, ecc.
    • Di solito si trova in /opt/<vendor>/mediaserver/var/; può essere cambiato nel file di configurazione del server.
    • Richiede un filesystem ext4
    • Spazio richiesto: dipende dal numero di telecamere e server nel sistema VMS, ma generalmente si raccomandano almeno 500 MB.
  • Base di dati analitici del server – memorizza i metadati di analisi video generati dai plugin di analisi
    • Di solito si trova in /opt/<vendor>/mediaserver/var/data; può essere cambiato nel file di configurazione del server.
    • Spazio richiesto: dipende se i plugin di Analytics sono in uso su questo server, e quanti metadati invieranno i plugin. Generalmente, il 20% della dimensione del Video Archive Storage è raccomandato se gli Analytics Plugins sono usati su questo Server.
  • Server logs
    • Localizzato in /opt/<vendor>/mediaserver/var/log/
      • Può essere riposizionato tramite mediaserver.conf.
    • I log vengono sovrascritti automaticamente in un ciclo.
    • Spazio richiesto: si raccomandano almeno 260 MB.
    • NOTA: Abbiamo notato che su specifici dispositivi ARM (es, Raspberry Pi 3), la memoria flash interna (Micro SD in quel caso) non era abbastanza buona per accettare i log. Il sistema si bloccava fino a 4 secondi. Abbiamo raccomandato di reindirizzare i log alla stessa posizione dell’archivio video per tali dispositivi.
  • Archivio video – memorizza i video registrati dalle telecamere
    • Tipicamente situato in /opt/<vendor>/mediaserver; può essere cambiato nel file di configurazione del server.
    • La partizione di sistema sarà probabilmente limitata dalla registrazione per impostazione predefinita a meno che non ci siano almeno 10 GB di spazio libero.
    • Memoria flash interna (eMMC) o scheda SD
        • Stima quanti cicli di scrittura può accettare la memoria. L’archivio video si sovrascrive automaticamente in un ciclo, quindi la durata di un singolo ciclo di scrittura può essere calcolata dividendo lo spazio libero per il bitrate combinato di tutte le telecamere registrate sul server.
        • Assicurarsi che il throughput della memoria sia sufficiente per il bitrate combinato di tutte le telecamere registrate sul server, con un margine di sicurezza del 30%.
    • HDD interno o SSD
        • Assicurarsi che il throughput del disco sia sufficiente per il bitrate combinato di tutte le telecamere registrate sul server, con un margine di sicurezza del 30%.
    • NAS esterno
        • Assicurati che la larghezza di banda effettiva dell’adattatore di rete sia sufficiente per il bitrate combinato di tutte le telecamere registrate sul server moltiplicato per 2 (perché le telecamere presumibilmente inviano i loro flussi al server usando lo stesso adattatore di rete), con un margine di sicurezza del 30%.
  • File di aggiornamento dell’applicazione Server
    • Per poter aggiornare, l’applicazione Server deve scaricare la sua versione più recente e scompattarla.
    • Si trova in /tmp/
    • Spazio richiesto: la dimensione totale del file di distribuzione Server compresso moltiplicato per 2,6; questo include il margine. Più spazio può essere raccomandato per minimizzare le possibilità di problemi con l’aggiornamento alle versioni future.

  • File temporanei dell’OS
    • Tipo situato in /tmp/
    • Spazio richiesto: almeno 100 MB sono raccomandati, senza includere lo spazio richiesto per i file di aggiornamento dell’applicazione Server (vedi sopra).

La maggior parte delle cose elencate sopra possono essere assegnate per essere memorizzate in una posizione diversa nel file di configurazione del Server: /opt/<vendor>/mediaserver/etc/mediaserver.conf

Siccome l’archiviazione tipica della scheda SD non è affidabile ed è nota per fallire durante operazioni intensive di lettura-scrittura, raccomandiamo di installare il sistema operativo e memorizzare l’archivio video su un disco rigido. Se si considera un’unità SSD/hard drive o una scheda SD per memorizzare l’archivio video, valutare la sua capacità per operazioni di riscrittura multiple utilizzando il bitrate tipico di una telecamera supportata desiderata moltiplicato per il numero desiderato di telecamere supportate.

Ad esempio, per il Raspberry Pi 3 B+:

    • Utilizzare un adattatore USB-SATA e un disco rigido esterno per l’archivio.
    • Installare il sistema operativo (Raspbian) su un disco rigido esterno. Vedere l’articolo Come avviare il Raspberry Pi da un dispositivo di archiviazione di massa USB per i dettagli. Questo processo dovrebbe essere automatizzato a seconda di come i dispositivi ARM saranno distribuiti: con o senza hard disk:
      • Con hard disk – fare un’immagine preconfigurata con VMS installato e clonarla su hard disk.
      • Senza hard disk – si dovrà creare un set di script che formatta l’HDD, copia il sistema operativo e fa tutte le modifiche necessarie. Questo è un compito piuttosto complesso e che richiede tempo.

Scegliere il gusto di Linux

Ci sono di solito diverse opzioni per il sistema operativo Linux su un dato NVR:

  • “Busybox” – solo il kernel Linux e il set base di strumenti a riga di comando; usato su NVR a prestazioni relativamente basse come le telecamere “edge” (telecamere con il server VMS in esecuzione).
  • Standard Debian, o uno dei suoi gusti come Ubuntu.
  • Versione modificata di Debian o un’altra distribuzione Linux, di solito modificata dal fornitore del dispositivo (es, Raspbian per Raspberry Pi).

Generalmente, si raccomanda di scegliere una variante di Linux che è la scelta nativa per la piattaforma su cui è basato l’NVR. Per esempio, quando si sviluppa un NVR simile nell’hardware a Raspberry Pi (o anche usando l’esatta scheda madre di Raspberry Pi), si raccomanda di scegliere Raspbian.

Se diverse distribuzioni Linux con diversi set di pacchetti sono disponibili per il dispositivo, si raccomanda quella meno pesante. Per esempio, se non c’è l’intenzione di mostrare l’interfaccia grafica sull’NVR, non c’è bisogno del sistema X Window.

Assicurati che la versione di Linux e il suo set di pacchetti soddisfino i requisiti del VMS. Per i dispositivi basati su ARM, consultare i dettagli del sistema operativo specificati nella ARM Support Policy.

Installa l’applicazione Server

Dopo aver caricato l’NVR con un sistema operativo Linux adatto, è necessario installare l’applicazione Server sull’NVR. Ci sono fondamentalmente due opzioni:

  1. Per i sistemi operativi basati su Debian: installare il pacchetto ufficiale .deb dalla distribuzione VMS usando dpkg.
  • Vedi le istruzioni dettagliate per installare il VMS su un dispositivo: ARM SBC installation instructions
  • Per i sistemi operativi basati su Busybox: estrarre i file necessari dal pacchetto .deb del VMS nella directory desiderata, e occuparsi manualmente dei seguenti aspetti:
    • Come verrà avviato il Server all’avvio e se il supporto system.d della distribuzione non è adatto?
    • Dove il Server porterà le librerie .so mancanti nel Linux installato?
    • Sarà abilitato il sistema di aggiornamento automatico standard di VMS?

    Per configurazioni OS meno tipiche, potrebbe essere necessaria una combinazione delle opzioni 1 e 2.

    Implementare caratteristiche extra

    In genere, un NVR non è solo un computer Linux standard con l’applicazione Server installata – spesso fornisce caratteristiche aggiuntive all’utente:

    • Pulsanti hardware, LED o anche display integrati.
    • Un’interfaccia web che permette di personalizzare l’NVR oltre alla semplice impostazione dell’applicazione Server tramite la propria interfaccia web, come
      • opzioni di rete: Indirizzo IP, subnet, ecc;
      • ora di sistema e fuso orario;
    • uscita video (ad es, HDMI) che mostra una GUI o almeno una schermata di benvenuto con valori di configurazione di base come l’indirizzo IP dell’NVR;
    • Software aggiuntivo che gira in parallelo al VMS, come un demone di configurazione o un backend di analisi video.
      • Se il software aggiuntivo ha un’autenticazione basata su password per l’utente finale, considera di implementare la sincronizzazione delle password, in modo che la password del server VMS sia sempre la stessa del software aggiuntivo. Se ssh viene offerto all’utente per accedere all’NVR, considera di sincronizzare anche la sua password.
    • Ulteriori accorgimenti, come minimizzare la memoria video (GPU). Per esempio, per il Raspberry Pi 3 B+ impostare la memoria della GPU a 16 MB. Vedere la documentazione di Raspberry Pi per i dettagli.

    Per implementare tali caratteristiche, potrebbe essere necessario scrivere o modificare gli script che controllano l’applicazione Server, o scrivere programmi aggiuntivi in C/C++.

    Sincronizzazione temporale

    Assicurarsi che l’NVR abbia una batteria CMOS integrata per evitare che il suo orologio si resetti in caso di perdita di corrente. Per esempio, Raspberry Pi 3 B+ non ha una batteria CMOS a bordo. Se il dispositivo viene riavviato, l’ora si resetterà e ciò comporterà una scrittura errata dell’archivio. Per evitare questo, ci sono alcune opzioni:

    • Assicurarsi che sia collegato a internet per sincronizzare l’ora.
    • Se è una rete chiusa, dovrai impostare un server NTP.
    • Aggiungi un modulo Real Time Clock (RTC) alla scheda e preconfiguralo. Vedi Aggiungere un orologio in tempo reale al tuo Raspberry Pi.

    Trovare/costruire un contenitore per il tuo NVR

    È necessario trovare o progettare un contenitore che si adatti a tutto l’hardware di cui sopra.

    Condurre un test di carico/stress intensivo

    Per assicurarsi che tutto funzioni insieme, è necessario pianificare un test di stress intensivo per assicurarsi che non ci sia surriscaldamento o malfunzionamento dei componenti. Il test dovrebbe essere in grado di caricare tutti i componenti del sistema come CPU, memoria, disco/i rigido/i, rete e Wi-Fi (se necessario), ecc.

    Stabilire una politica di supporto

    L’NVR sarà fornito ai suoi utenti finali, e questi avranno sicuramente bisogno di qualche tipo di supporto tecnico. Il team di supporto del fornitore di VMS non può rendere tali servizi agli utenti finali, quindi, dovrebbe essere sviluppata una politica per fornire tale supporto, come un desk di supporto online, un forum di comunità o simili.

    Quando il team di supporto del fornitore di RIN è sicuro che il problema particolare non è legato alle specifiche del RIN stesso, ma piuttosto è un problema nel VMS, può richiedere il supporto al fornitore di VMS secondo la politica di supporto ARM di cui sopra, e quindi utilizzare il risultato di questo caso di supporto per soddisfare la richiesta di supporto da un utente finale.

    Domande

    Se hai domande relative a questo argomento o vuoi condividere la tua esperienza con altri membri della comunità o con il nostro team, visita e partecipa alla nostra comunità di supporto o contatta il tuo rivenditore locale.

    Lascia un commento

    Il tuo indirizzo email non sarà pubblicato.