Bygga Linux-baserade NVR:er

Översikt

Denna artikel beskriver de vanligaste stegen för en partner som vill tillverka en NVR-liknande hårdvaruprodukt – en inbäddad dator (som här kallas ”NVR”) med ett förinstallerat serverprogram. Vanligtvis är en sådan NVR en Linuxbaserad dator med en ARM-CPU.

De grundläggande stegen för att göra en sådan produkt är följande:

  • Välj hårdvara
    • Plattform
    • Lagring
  • Välj Linux-smak
  • Installera Server-applikation
  • Installera extra funktioner
  • Etablera en supportpolicy

Dessa steg beskrivs nedan i detalj.

Välj hårdvara

För att en produkt ska bli framgångsrik bör den vara kostnadseffektiv och ge den prestanda som krävs – stödja önskat antal kameror med önskad bithastighet/upplösning. Den maskinvara som används bör ha minst 1 GB RAM och ett ARM Cortex A7-chipset eller högre.

Det rekommenderas att först studera prestandan hos de ARM-plattformar som stöds (se ARM Support Policy för en förteckning över sådana plattformar) och sedan välja en plattform som ligger närmast dina krav.

Plattform

Den valda ARM-plattformen som stöds kan användas som något av följande:

  • En färdig dator (t.ex. ett standard Raspberry Pi-huvudkort), eventuellt med ett anpassat hölje och nätaggregat;
  • en referens för utformning av en anpassad dator med huvudkortet som kan hysa ytterligare hårdvarukomponenter som perifera gränssnitt eller hårddiskstyrenheter.

Om NVR:n förväntas ha ytterligare programvara ombord utöver serverprogrammet, t.ex. en webbserver som tillhandahåller ett webbgränssnitt för användaren, programvara för videoanalys (t.ex. ett VMS-plugin och/eller dess backend) eller liknande, se till att lägga till tillräckligt med RAM- och CPU-processorkraft för att täcka detta.

Videoomkodning stöds inte på ARM-enheter på grund av begränsad beräkningskraft. Dessutom kan vissa beroenden som OpenSSL ha kompatibilitetsproblem. Om den inledande analysen visar att en typisk ARM-baserad plattform inte kommer att ge den prestanda som krävs kan en x64-plattform övervägas.

Plattformens lagringsprestanda bör vara tillräckligt bra för den planerade belastningen. Det är till exempel känt att sådana lösningar som SATA-over-USB kan leda till dålig HDD-prestanda, vilket är otillräckligt för att spela in det erforderliga antalet kameror.

Nätverksprestanda för plattformen bör vara tillräckligt bra för den planerade belastningen. Det är till exempel känt att sådana lösningar som mjukvarubaserad Ethernet-implementering tar mycket CPU-resurser och därmed kan leda till bildförluster vid inspelning av kameror eller streaming till klienter, eller andra problem. Dessutom kan hårdvarumodeller som implementerar Ethernet via USB-hubb ha mindre än den annonserade nätverksbandbredden.

Plattformen bör vara utrustad med hårdvara för realtidsklocka (Real-Time Clock, RTC) och/eller tidssynkronisering via nätverket (t.ex. med hjälp av NTP-protokollet) bör vara aktiverad – för att VMS ska fungera korrekt måste operativsystemets datum och tid vara korrekta. Om det inte finns någon RTC-hårdvara och den enda datum/tidskällan planeras vara nätverket, rekommenderas att enheten vägrar att starta överhuvudtaget om den inte kan synkronisera datum/tid.

Storage

Säkerställ att det finns tillräckligt med utrymme i filsystemet för att VMS ska fungera korrekt. Servern använder följande lagringsplatser:

  • VMS-installation – binärer och dynamiska bibliotek (.so-filer)
    • Lokaliserad på /opt/<vendor>/mediaserver/
    • Behövligt utrymme: kan beräknas genom att man mäter den totala storleken på de respektive filerna i distributionen med en viss extra marginal; ju större marginal – desto mindre risk för problem vid uppdatering till framtida versioner. Generellt rekommenderas en marginal på 30 %.
    • Om det inte finns tillräckligt med lagringsutrymme på /opt kan .so-filer flyttas via symlänkar till en annan plats, inklusive FAT32-lagring (men i detta fall kan endast filer som inte är symlänkar flyttas).
  • Serverdatabasfiler – lagrar information om kameror och andra servrar, händelseloggar osv.
    • Typiskt placerad i /opt/<vendor>/mediaserver/var/; kan ändras i Serverkonfigurationsfilen.
    • Kräver ext4-filsystem
    • Krävs utrymme: beror på antalet kameror och Servrar i VMS-systemet, men generellt rekommenderas minst 500 MB.
  • Server Analytics-databas – lagrar videoanalysmetadata som genereras av Analytics-plugins
    • Ligger vanligtvis på /opt/<vendor>/mediaserver/var/data; kan ändras i serverkonfigurationsfilen.
    • Behov av utrymme: beror på om Analytics Plugins används på den här servern och hur mycket metadata plugins skickar. Generellt rekommenderas 20 % av storleken på lagringsutrymmet för videoarkiv om Analytics Plugins används på den här servern.
  • Serverloggar
    • Ligger på /opt/<vendor>/mediaserver/var/log/
      • Kan flyttas via mediaserver.conf.
    • Loggar skrivs automatiskt över i en slinga.
    • Krävande utrymme: minst 260 MB rekommenderas.
    • ANMÄRKNING: Vi har märkt att på vissa ARM-enheter (t.ex, Raspberry Pi 3), det interna flashminnet (Micro SD i det fallet) inte var tillräckligt bra för att ta emot loggar. Systemet frös då i upp till 4 sekunder. Vi rekommenderade att omdirigera loggar till samma plats som videoarkivet för sådana enheter.
  • Videoarkiv – lagrar inspelad video från kameror
    • Ligger vanligtvis på /opt/<vendor>/mediaserver; kan ändras i konfigurationsfilen Server.
    • Systempartitionen kommer sannolikt att begränsas från inspelning som standard om det inte finns minst 10 GB ledigt utrymme.
    • Internt flashminne (eMMC) eller SD-kort
        • Skatta hur många skrivcykler minnet kan acceptera. Videoarkivet skriver automatiskt över sig självt i en slinga, därför kan varaktigheten för en enskild skrivcykel beräknas genom att dividera det fria utrymmet med den kombinerade bithastigheten för alla kameror som spelas in på servern.
        • Säkerställ att minnesgenomströmningen är tillräcklig för den kombinerade bithastigheten för alla kameror som spelas in på servern, med en säkerhetsmarginal på 30 %.
    • Intern hårddisk eller SSD
        • Säkerställ att diskgenomströmningen är tillräcklig för den kombinerade bithastigheten för alla kameror som spelas in på servern, med en säkerhetsmarginal på 30 %.
    • Extern NAS
        • Säkerställ att nätverksadapterns faktiska bandbredd är tillräcklig för den kombinerade bithastigheten för alla kameror som spelas in på servern multiplicerad med 2 (eftersom kamerorna förmodligen skickar sina strömmar till servern med samma nätverksadapter), med en säkerhetsmarginal på 30 %.
  • Filer för uppdatering av Serverprogrammet
    • För att kunna uppdatera måste Serverprogrammet hämta sin nyare version och packa upp den.
    • Lokaliseras i /tmp/
    • Behövligt utrymme: den totala storleken på den packade Serverdistributionsfilen multiplicerad med 2,6; detta inkluderar marginalen. Mer utrymme kan rekommenderas för att minimera risken för problem vid uppdatering till framtida versioner.

  • Temporära filer för operativsystemet
    • Typiskt placerade i /tmp/
    • Krävande utrymme: Minst 100 MB rekommenderas, exklusive det nödvändiga utrymmet för uppdateringsfilerna för Serverprogrammet (se ovan).

De flesta av de saker som anges ovan kan tilldelas att lagras på en annan plats i Server-konfigurationsfilen: /opt/<vendor>/mediaserver/etc/mediaserver.conf

Då den typiska SD-kortlagringen inte är tillförlitlig och är känd för att gå sönder under intensiva läs- och skrivoperationer, rekommenderar vi att installera operativsystemet och lagra videoarkivet på en eller flera hårddiskar. Om en SSD/hårddisk eller ett SD-kort övervägs för lagring av videoarkivet, bedöm dess kapacitet för flera omskrivningar med hjälp av den typiska bithastigheten för en önskad kamera som stöds multiplicerad med det önskade antalet kameror som stöds.

Till exempel för Raspberry Pi 3 B+:

    • Använd USB-SATA-adapter och extern hårddisk för arkivet.
    • Installera operativsystemet (Raspbian) på en extern hårddisk. Se artikeln Hur du startar din Raspberry Pi från en USB-massalagringsenhet för mer information. Denna process bör automatiseras beroende på hur ARM-enheterna ska distribueras: med eller utan hårddisk:
      • Med hårddisk – gör en förkonfigurerad avbildning med VMS installerat och klona den till hårddiskar.
      • Och utan hårddisk – du måste skapa en uppsättning skript som formaterar hårddisken, kopierar operativsystemet och gör alla nödvändiga justeringar. Detta är en ganska komplex och tidskrävande uppgift.

Välj Linux-smak

Det finns vanligtvis flera alternativ för Linux OS på en given NVR:

  • ”Busybox” – bara Linux-kärnan och den grundläggande uppsättningen kommandoradsverktyg; används på NVR:er med relativt låg prestanda, t.ex. ”edge”-kameror (kameror med VMS-servern körd på dem).
  • Standard-Debian, eller en av dess varianter som Ubuntu.
  • Modifierad version av Debian eller en annan Linuxdistribution, vanligtvis modifierad av enhetsleverantören (t.ex, Raspbian för Raspberry Pi).

Generellt rekommenderas det att välja en Linuxvariant som är det ursprungliga valet för den plattform som NVR:n är baserad på. Om man till exempel utvecklar en NVR som till maskinvaran liknar Raspberry Pi (eller till och med använder det exakta huvudkortet för Raspberry Pi) rekommenderas att man väljer Raspbian.

Om flera Linuxdistributioner med olika paketuppsättningar finns tillgängliga för enheten, rekommenderas den minst tunga. Om det till exempel inte finns några planer på att visa GUI på NVR:n finns det inget behov av X Window System.

Säkerställ att Linuxversionen och dess paketuppsättning uppfyller kraven för VMS. För ARM-baserade enheter, se de uppgifter om operativsystemet som anges i ARM Support Policy.

Installera serverapplikationen

När NVR har laddats med ett lämpligt Linux-operativsystem ska serverapplikationen installeras på NVR. Det finns i princip två alternativ:

  1. För Debianbaserade operativsystem: Installera det officiella .deb-paketet från VMS-distributionen med hjälp av dpkg.
  • Se de detaljerade instruktionerna för installation av VMS på en enhet: För Busybox-baserade operativsystem: extrahera de nödvändiga filerna från VMS .deb-paketet till önskad katalog och ta hand om följande aspekter manuellt:
    • Hur servern kommer att startas vid uppstart och om system.d-stödet från distributionen inte är lämpligt?
    • Hur kommer servern att hämta .so-bibliotek som saknas i det installerade Linuxet?
    • Vill standard VMS automatiska uppdateringssystem aktiveras?

    För mindre typiska OS-installationer kan någon kombination av alternativ 1 och 2 krävas.

    Installerar extra funktioner

    Typiskt sett är en NVR inte bara en vanlig Linux-dator med Serverprogrammet installerat – den ger ofta ytterligare funktioner till användaren:

    • Knappar på hårdvara, lysdioder eller till och med inbäddade skärmar.
    • Ett webbgränssnitt som gör det möjligt att anpassa NVR:n utöver att ställa in Serverprogrammet via dess eget webbgränssnitt, t.ex.
      • nätverksalternativ: IP-adress, subnät etc.;
      • systemtid och tidszon;
    • Videoutgång (t.ex, HDMI) som visar ett GUI eller åtminstone en välkomstskärm med grundläggande konfigurationsvärden som NVR:s IP-adress;
    • Ytterligare programvara som körs parallellt med VMS, t.ex. en konfigurationsdemon eller en backend för videoanalys.
      • Om den ytterligare programvaran har en lösenordsbaserad autentisering för slutanvändaren, bör du överväga att implementera lösenordssynkronisering, så att lösenordet för VMS-servern alltid är detsamma som det för den ytterligare programvaran. Om ssh erbjuds användaren för åtkomst till NVR, överväg att synkronisera dess lösenord också.
    • Ytterligare finjusteringar, som att minimera videominnet (GPU). För Raspberry Pi 3 B+ kan du till exempel ställa in GPU-minnet till 16 MB. Se Raspberry Pi-dokumentationen för detaljer.

    För att implementera sådana funktioner kan det krävas att du skriver eller ändrar skript som styr Serverprogrammet eller skriver ytterligare program i C/C++.

    Tidsynkronisering

    Säkerställ att NVR:n har ett inbyggt CMOS-batteri för att förhindra att klockan nollställs i händelse av strömavbrott. Raspberry Pi 3 B+ har till exempel inget inbyggt CMOS-batteri. Om enheten startas om kommer klockan att nollställas och det kommer att resultera i felaktig arkivskrivning. För att undvika detta finns det några alternativ:

    • Säkerställ att den är ansluten till internet för att synkronisera tiden.
    • Om det är ett slutet nätverk måste du konfigurera en NTP-server.
    • Förbered en RTC-modul (Real-Time Clock) till kortet och förkonfigurera den. Se Lägga till en realtidsklocka till din Raspberry Pi.

    Hitta/bygga ett hölje för din NVR

    Det är nödvändigt att hitta eller utforma ett hölje som passar all den hårdvara som nämns ovan.

    Utför ett omfattande belastnings-/stress-test

    För att se till att allting fungerar tillsammans måste du planera ett intensivt stresstest för att se till att det inte uppstår någon överhettning eller något fel på komponenter. Testet ska kunna belasta alla systemkomponenter som CPU, minne, hårddisk(er), nätverk och Wi-Fi (vid behov) etc.

    Utarbeta supportpolicy

    NVR:n kommer att levereras till sina slutanvändare, och de kommer definitivt att behöva någon form av teknisk support. Supportteamet hos VMS-leverantören kan inte tillhandahålla sådana tjänster till slutanvändarna, och därför bör en policy för att tillhandahålla sådan support utarbetas, t.ex. en online-supportdisk, ett forum eller liknande.

    När NVR-leverantörens supportteam är säkert på att det särskilda problemet inte är relaterat till NVR:s specifika egenskaper, utan snarare är ett problem i VMS, kan det begära support från VMS-leverantören i enlighet med den ovan nämnda stödpolicyn för ARM-support, och sedan använda resultatet av detta supportärende för att tillgodose supportbegäran från en slutanvändare.

    Frågor

    Om du har några frågor relaterade till det här ämnet eller om du vill dela din erfarenhet med andra communitymedlemmar eller vårt team, besök och engagera dig i vår supportcommunity eller kontakta din lokala återförsäljare.

Lämna ett svar

Din e-postadress kommer inte publiceras.