Przegląd
Ten artykuł opisuje typowe kroki dla partnera, który chce stworzyć produkt sprzętowy podobny do NVR – wbudowany komputer (zwany tutaj „NVR”) z preinstalowaną aplikacją serwera. Zazwyczaj taki NVR jest komputerem opartym na systemie Linux z procesorem ARM.
Podstawowe kroki do wykonania takiego produktu obejmują następujące czynności:
- Wybór sprzętu
- Platforma
- Pamięć masowa
- Wybór smaku Linuksa
- Instalacja aplikacji Server
- Implementacja dodatkowych funkcji
- Ustalenie polityki wsparcia technicznego
Kroki te zostały szczegółowo opisane poniżej.
Wybór sprzętu
Aby produkt odniósł sukces, powinien być efektywny kosztowo i zapewniać wymaganą wydajność – obsługiwać wymaganą liczbę kamer z wymaganym bitrate/rozdzielczością. Używany sprzęt powinien mieć co najmniej 1GB pamięci RAM i chipset ARM Cortex A7 lub wyższy.
Zaleca się najpierw zbadać wydajność wspieranych platform ARM (lista takich platform znajduje się w ARM Support Policy), a następnie wybrać platformę najbliższą wymaganiom.
Platforma
Wybrana wspierana platforma ARM może być użyta jako jedna z następujących:
- gotowy do zakupu komputer (np. standardowa płyta główna Raspberry Pi), ewentualnie z niestandardową obudową i zasilaczem;
- odniesienie do projektowania niestandardowego komputera z płytą główną, która może zawierać dodatkowe elementy sprzętowe, takie jak interfejsy peryferyjne lub kontrolery dysku twardego.
Jeśli oczekuje się, że NVR będzie miał dodatkowe oprogramowanie na pokładzie oprócz aplikacji serwera, takie jak serwer sieciowy zapewniający interfejs sieciowy dla użytkownika, oprogramowanie do analizy wideo (np. wtyczka VMS i/lub jej backend) lub podobne, upewnij się, że dodajesz wystarczającą ilość pamięci RAM i moc przetwarzania procesora, aby to pokryć.
Transkodowanie wideo nie jest obsługiwane na urządzeniach ARM z powodu ograniczonej mocy obliczeniowej. Dodatkowo, niektóre zależności takie jak OpenSSL mogą mieć problemy z kompatybilnością. Jeśli wstępna analiza wykaże, że typowa platforma oparta na ARM nie zapewni wymaganej wydajności, można rozważyć platformę x64.
Wydajność pamięci masowej platformy powinna być wystarczająco dobra dla planowanego obciążenia. Wiadomo na przykład, że takie rozwiązania jak SATA-over-USB mogą prowadzić do słabej wydajności HDD, niewystarczającej do rejestracji wymaganej liczby kamer.
Wydajność sieciowa platformy powinna być wystarczająco dobra dla planowanego obciążenia. Wiadomo na przykład, że takie rozwiązania jak programowa implementacja sieci ethernet zajmują dużo zasobów procesora i mogą powodować spadki klatek przy nagrywaniu z kamer lub strumieniowaniu do klientów, czy inne problemy. Dodatkowo modele sprzętu, które implementują ethernet przez hub USB mogą mieć mniejszą niż reklamowana przepustowość sieci.
Platforma powinna być wyposażona w sprzętowy zegar czasu rzeczywistego (RTC), i/lub powinna być włączona synchronizacja czasu przez sieć (np. za pomocą protokołu NTP) – aby VMS działał poprawnie, data i czas systemu operacyjnego muszą być poprawne. Jeśli nie ma sprzętowego RTC, a jedynym źródłem daty/czasu ma być sieć, zaleca się, aby urządzenie w ogóle odmawiało startu w przypadku braku możliwości synchronizacji daty/czasu.
Storage
Upewnij się, że na systemie plików jest wystarczająco dużo miejsca, aby VMS działał poprawnie. Serwer używa następujących miejsc do przechowywania:
- Instalacja VMS – binaria i biblioteki dynamiczne (pliki .so)
- Zlokalizowane w /opt/<vendor>/mediaserver/
- Wymagane miejsce: może być obliczone mierząc całkowity rozmiar odpowiednich plików w dystrybucji z pewnym marginesem; im większy margines – tym mniejsze szanse na problemy z aktualizacją do przyszłych wersji. Generalnie zalecany jest margines 30%.
- Jeśli nie ma wystarczającej ilości miejsca w /opt, pliki .so mogą być przeniesione poprzez symlinki do innej lokalizacji, w tym do przestrzeni dyskowej FAT32 (ale w tym przypadku można przenieść tylko pliki, które nie są symlinkami).
- Pliki bazy danych serwera – przechowują informacje o kamerach i innych serwerach, dzienniki zdarzeń itp.
- Typowo znajdują się w /opt/<vendor>/mediaserver/var/; mogą być zmienione w pliku konfiguracyjnym Serwera.
- Wymaga systemu plików ext4
- Wymagana przestrzeń: zależy od liczby kamer i Serwerów w Systemie VMS, ale generalnie zalecane jest co najmniej 500 MB.
- Baza danych Analytics serwera – przechowuje metadane Video Analytics generowane przez wtyczki Analytics
- Zwykle znajduje się w /opt/<vendor>/mediaserver/var/data; może być zmieniona w pliku konfiguracyjnym serwera.
- Wymagane miejsce: zależy od tego, czy na tym Serwerze są używane wtyczki Analytics i jak dużo metadanych będą wysyłać wtyczki. Generalnie, 20% rozmiaru Video Archive Storage jest zalecane, jeśli Analytics Plugins są używane na tym Serwerze.
- Logi serwera
- Znajdują się w /opt/<vendor>/mediaserver/var/log/
- Mogą być przeniesione przez mediaserver.conf.
- Logi są automatycznie nadpisywane w pętli.
- Wymagane miejsce: zalecane co najmniej 260 MB.
- UWAGA: Zauważyliśmy, że na niektórych urządzeniach ARM (np., Raspberry Pi 3), wewnętrzna pamięć flash (Micro SD w tym przypadku) nie była wystarczająco dobra, aby przyjąć logi. System zawieszał się na maksymalnie 4 sekundy. Zalecaliśmy przekierowanie logów do tej samej lokalizacji co archiwum wideo dla takich urządzeń.
- Archiwum wideo – przechowuje nagrane wideo z kamer
- Typowo znajduje się w /opt/<vendor>/mediaserver; można zmienić w pliku konfiguracyjnym serwera.
- Partycja systemowa prawdopodobnie będzie domyślnie zablokowana przed nagrywaniem, jeśli nie ma co najmniej 10 GB wolnego miejsca.
- Wewnętrzna pamięć flash (eMMC) lub karta SD
- Oszacuj, ile cykli zapisu może przyjąć pamięć. Archiwum wideo automatycznie nadpisuje się w pętli, dlatego czas trwania pojedynczego cyklu zapisu można obliczyć dzieląc ilość wolnego miejsca przez łączny bitrate wszystkich kamer nagrywanych na serwerze.
- Upewnij się, że przepustowość pamięci jest wystarczająca dla sumarycznego bitrate wszystkich kamer nagrywanych na Serwerze, z marginesem bezpieczeństwa 30%.
- Wewnętrzny HDD lub SSD
- Upewnij się, że przepustowość dysku jest wystarczająca dla sumarycznego bitrate wszystkich kamer nagrywanych na Serwerze, z marginesem bezpieczeństwa 30%.
- Zewnętrzny NAS
- Upewnij się, że rzeczywista przepustowość karty sieciowej jest wystarczająca dla połączonego bitrate wszystkich kamer nagrywanych na serwerze pomnożonego przez 2 (ponieważ kamery prawdopodobnie wysyłają swoje strumienie do serwera za pomocą tej samej karty sieciowej), z marginesem bezpieczeństwa 30%.
- Pliki aktualizacyjne aplikacji Serwera
- Aby móc dokonać aktualizacji, aplikacja Serwera musi pobrać swoją nowszą wersję i rozpakować ją.
- Zlokalizowane w /tmp/
- Wymagane miejsce: całkowity rozmiar spakowanego pliku dystrybucyjnego Serwera pomnożony przez 2,6; obejmuje to margines. Więcej miejsca może być zalecane, aby zminimalizować szanse na problemy z aktualizacją do przyszłych wersji.
- Pliki tymczasowe systemu operacyjnego
- Typowo zlokalizowane w /tmp/
- Wymagane miejsce: zalecane co najmniej 100 MB, nie wliczając wymaganego miejsca na pliki aktualizacji aplikacji Serwera (patrz wyżej).
Większość z wymienionych powyżej rzeczy można przypisać do przechowywania w innej lokalizacji w pliku konfiguracyjnym Serwera: /opt/<vendor>/mediaserver/etc/mediaserver.conf
Ponieważ typowe przechowywanie na kartach SD nie jest niezawodne i znane z awarii podczas intensywnych operacji odczytu-zapisu, zalecamy instalację systemu operacyjnego i przechowywanie archiwum wideo na dysku(ach) twardym(ych). Jeśli do przechowywania archiwum wideo rozważane jest użycie dysku SSD/twardego lub karty SD, należy ocenić jego zdolność do wielokrotnego przepisywania przy użyciu typowego bitrate’u żądanej obsługiwanej kamery pomnożonego przez żądaną liczbę obsługiwanych kamer.
Na przykład dla Raspberry Pi 3 B+:
- Użyj adaptera USB-SATA i zewnętrznego dysku twardego do przechowywania archiwum.
- Instalacja systemu operacyjnego (Raspbian) na zewnętrznym dysku twardym. Zobacz artykuł Jak uruchomić Raspberry Pi z urządzenia pamięci masowej USB dla szczegółów. Ten proces powinien być zautomatyzowany w zależności od tego, jak urządzenia ARM będą dystrybuowane: z twardym dyskiem lub bez niego:
- Z twardym dyskiem – wykonaj wstępnie skonfigurowany obraz z zainstalowanym VMS i sklonuj go na dyski twarde.
- Bez twardego dysku – będziesz musiał stworzyć zestaw skryptów, które sformatują HDD, skopiują OS i zrobią wszystkie niezbędne tweaki. Jest to dość złożone i czasochłonne zadanie.
Wybierz smak Linuksa
Zazwyczaj istnieje kilka opcji dla systemu operacyjnego Linux w danym NVR:
- „Busybox” – tylko jądro Linuksa i podstawowy zestaw narzędzi wiersza poleceń; używany w stosunkowo mało wydajnych NVR, takich jak kamery „brzegowe” (kamery z uruchomionym serwerem VMS).
- Standardowy Debian, lub jeden z jego smaków jak Ubuntu.
- Zmodyfikowana wersja Debiana lub innej dystrybucji Linuksa, zwykle zmodyfikowana przez producenta urządzenia (np, Raspbian dla Raspberry Pi).
Ogólnie zaleca się wybór wariantu Linuksa, który jest natywnym wyborem dla platformy, na której oparty jest NVR. Na przykład, w przypadku tworzenia NVR podobnego sprzętowo do Raspberry Pi (lub nawet wykorzystującego dokładną płytę główną Raspberry Pi), zaleca się wybór Raspbiana.
Jeśli dla urządzenia dostępnych jest kilka dystrybucji Linuksa z różnymi zestawami pakietów, zaleca się wybór najmniej obciążającej. Na przykład, jeśli nie ma planów wyświetlania GUI na NVR, nie ma potrzeby stosowania X Window System.
Upewnij się, że wersja systemu Linux i jej zestaw pakietów spełnia wymagania systemu VMS. W przypadku urządzeń opartych na architekturze ARM należy zapoznać się ze szczegółami dotyczącymi systemu operacyjnego określonymi w dokumencie ARM Support Policy.
Instalacja aplikacji serwera
Po załadowaniu do NVR odpowiedniego systemu operacyjnego Linux należy zainstalować na nim aplikację serwera. Zasadniczo istnieją dwie opcje:
- W przypadku systemu operacyjnego opartego na Debianie: zainstaluj oficjalny pakiet .deb z dystrybucji VMS za pomocą dpkg.
- Zobacz szczegółowe instrukcje dotyczące instalacji systemu VMS na urządzeniu: ARM SBC installation instructions
- Jak serwer będzie uruchamiany przy starcie i czy obsługa system.d z dystrybucji nie jest odpowiednia?
- Gdzie serwer pobierze biblioteki .so brakujące w zainstalowanym Linuksie?
- Czy zostanie włączony standardowy system automatycznej aktualizacji VMS?
W przypadku mniej typowych konfiguracji systemu operacyjnego może być wymagana pewna kombinacja opcji 1 i 2.
Wdrażanie dodatkowych funkcji
Typowo, NVR to nie tylko standardowy komputer z systemem Linux z zainstalowaną aplikacją serwera – często zapewnia on użytkownikowi dodatkowe funkcje:
- Przyciski sprzętowe, diody LED lub nawet wbudowane wyświetlacze.
- Interfejs sieciowy, który umożliwia dostosowanie NVR w zakresie wykraczającym poza konfigurowanie aplikacji Server za pomocą własnego interfejsu sieciowego, takim jak
- opcje sieciowe: Adres IP, podsieć itp.;
- czas systemowy i strefa czasowa;
- Wyjście wideo (np, HDMI), które pokazuje GUI lub przynajmniej ekran powitalny z podstawowymi wartościami konfiguracyjnymi, takimi jak adres IP NVR;
- Dodatkowe oprogramowanie, które działa równolegle z systemem VMS, takie jak demon konfiguracyjny lub backend do analizy wideo.
- Jeśli dodatkowe oprogramowanie ma uwierzytelnianie oparte na haśle dla użytkownika końcowego, należy rozważyć wdrożenie synchronizacji haseł, tak aby hasło do serwera VMS było zawsze takie samo jak hasło do dodatkowego oprogramowania. Jeśli użytkownik ma dostęp do NVR przez ssh, rozważ również synchronizację jego hasła.
- Dodatkowe usprawnienia, takie jak minimalizacja pamięci wideo (GPU). Na przykład, dla Raspberry Pi 3 B+ ustaw pamięć GPU na 16 MB. Zobacz dokumentację Raspberry Pi dla szczegółów.
Aby zaimplementować takie funkcje, może być wymagane napisanie lub zmodyfikowanie skryptów sterujących aplikacją Server, lub napisanie dodatkowych programów w C/C++.
Synchronizacja czasu
Upewnij się, że NVR ma wbudowaną baterię CMOS, aby zapobiec zresetowaniu zegara w przypadku utraty zasilania. Na przykład Raspberry Pi 3 B+ nie ma baterii CMOS na pokładzie. Jeśli urządzenie zostanie zrestartowane, czas zostanie zresetowany, co spowoduje nieprawidłowy zapis do archiwum. Aby tego uniknąć, istnieją pewne opcje:
- Upewnij się, że jest podłączony do Internetu, aby zsynchronizować czas.
- Jeśli jest to sieć zamknięta, trzeba będzie skonfigurować serwer NTP.
- Dodaj moduł zegara czasu rzeczywistego (RTC) do płyty i skonfiguruj go wstępnie. Zobacz Adding a Real Time Clock to your Raspberry Pi.
Finding/Building an Enclosure for Your NVR
Niezbędne jest znalezienie lub zaprojektowanie obudowy, która będzie pasować do całego sprzętu wymienionego powyżej.
Conduct Extensive Load/Stress Test
Aby upewnić się, że wszystko działa razem, konieczne jest zaplanowanie intensywnego testu obciążeniowego, aby upewnić się, że nie ma przegrzania lub awarii komponentów. Test powinien być w stanie obciążyć wszystkie komponenty systemu, takie jak procesor, pamięć, dysk twardy, sieć i Wi-Fi (w razie potrzeby) itp.
Ostateczna polityka wsparcia
RTVR będzie dostarczany do użytkowników końcowych, a oni z pewnością będą wymagać pewnego rodzaju wsparcia technicznego. Zespół pomocy technicznej dostawcy VMS nie może świadczyć takich usług użytkownikom końcowym, dlatego należy opracować politykę zapewniania takiej pomocy, na przykład w postaci internetowego działu pomocy technicznej, forum społecznościowego lub podobnych rozwiązań.
Gdy zespół wsparcia producenta NVR jest pewien, że dany problem nie jest związany ze specyfiką samego NVR, ale raczej jest problemem w VMS, może zwrócić się o wsparcie do producenta VMS zgodnie z wyżej wymienioną polityką wsparcia ARM, a następnie wykorzystać wynik tego przypadku do zaspokojenia prośby o wsparcie od użytkownika końcowego.
Pytania
Jeśli masz jakiekolwiek pytania związane z tym tematem lub chcesz podzielić się swoimi doświadczeniami z innymi członkami społeczności lub naszym zespołem, odwiedź i zaangażuj się w naszą społeczność pomocy technicznej lub skontaktuj się z lokalnym sprzedawcą.