Witam wszystkich!

Prawdopodobnie nie jest tajemnicą, że usługi nadzoru wideo w chmurze cieszą się ostatnio coraz większą popularnością. I jasne jest, dlaczego tak się dzieje, wideo to „ciężka” treść, której przechowywanie wymaga infrastruktury i dużej ilości miejsca na dysku. Korzystanie z lokalnego systemu nadzoru wideo wymaga środków finansowych i wsparcia, zarówno w przypadku organizacji korzystającej z setek kamer monitorujących, jak i dla indywidualnego użytkownika posiadającego kilka kamer.

Systemy nadzoru wideo w chmurze rozwiązują ten problem, zapewniając klientom istniejącą infrastrukturę do przechowywania i przetwarzania wideo. Klient nadzoru wideo w chmurze musi po prostu podłączyć kamerę do Internetu i połączyć ją ze swoim kontem w chmurze.

Istnieje kilka technologicznych sposobów podłączenia kamer do chmury. Niewątpliwie najwygodniejszym i najtańszym sposobem jest to, że kamera bezpośrednio łączy się i współpracuje z chmurą, bez udziału dodatkowego sprzętu takiego jak serwer czy rejestrator.

Aby to zrobić, konieczne jest zainstalowanie w kamerze modułu oprogramowania współpracującego z chmurą. Jeśli jednak mówimy o tanich aparatach, to mają one bardzo ograniczone zasoby sprzętowe, które są prawie w 100% zajęte przez natywne oprogramowanie producenta kamery i nie ma żadnych zasobów niezbędnych dla wtyczki chmurowej. Deweloperzy z ivideon poświęcili temu problemowi статью, co wyjaśnia, dlaczego nie można zainstalować wtyczki na tanich aparatach. W rezultacie minimalna cena aparatu to 5000 rubli (80 dolarów) i miliony pieniędzy wydanych na sprzęt.

Udało nam się rozwiązać ten problem. Jeśli ciekawi Cię jak - zapraszamy na cięcie

Trochę historii

W 2016 roku rozpoczęliśmy rozwój platformy nadzoru wideo w chmurze dla Rostelecom.

Jeśli chodzi o oprogramowanie kamery, w pierwszym etapie poszliśmy „standardową” ścieżką dla takich zadań: opracowaliśmy własną wtyczkę, która jest instalowana w standardowym oprogramowaniu kamery dostawcy i współpracuje z naszą chmurą. Warto jednak zaznaczyć, że podczas projektowania zastosowaliśmy najlżejsze i najbardziej wydajne rozwiązania (na przykład prostą implementację C protobuf, libev, mbedtls i całkowicie porzucono wygodne, ale ciężkie biblioteki typu boost)

Obecnie na rynku kamer IP nie ma uniwersalnych rozwiązań integracyjnych: każdy sprzedawca ma swój własny sposób instalacji wtyczki, własny zestaw API do obsługi oprogramowania oraz unikalny mechanizm aktualizacji.

Oznacza to, że dla każdego dostawcy kamer konieczne jest indywidualne opracowanie kompleksowej warstwy oprogramowania integracyjnego. W momencie rozpoczęcia programowania zaleca się współpracę tylko z 1 dostawcą, aby skoncentrować wysiłki zespołu na opracowaniu logiki pracy z chmurą.

Pierwszym wybranym dostawcą był Hikvision, jeden ze światowych liderów na rynku kamer, zapewniający dobrze udokumentowane API i kompetentne wsparcie techniczne.

Uruchomiliśmy nasz pierwszy projekt pilotażowy, monitoring wideo w chmurze Video Comfort, z wykorzystaniem kamer Hikvision.

Niemal natychmiast po uruchomieniu nasi użytkownicy zaczęli zadawać pytania o możliwość podłączenia do usługi tańszych aparatów innych producentów.

Odrzuciłem opcję wdrożenia warstwy integracyjnej u każdego dostawcy niemal od razu – jest ona bowiem słabo skalowalna i nakłada poważne wymagania techniczne na sprzęt kamery. Koszt aparatu spełniającego te wymagania wejściowe: ~60-70$

Dlatego postanowiłem kopać głębiej - stworzyć własne oprogramowanie sprzętowe dla aparatów dowolnego dostawcy. Takie podejście znacznie zmniejsza wymagania dotyczące zasobów sprzętowych aparatu - ponieważ Warstwa do pracy z chmurą jest znacznie efektywniej zintegrowana z aplikacją wideo, a w oprogramowaniu nie ma niepotrzebnego, niewykorzystanego tłuszczu.

A co ważne, pracując z kamerą na niskim poziomie, można zastosować sprzętowy AES, który szyfruje dane bez dodatkowego obciążania energooszczędnego procesora.

W tamtym momencie nie mieliśmy zupełnie nic. Nic.

Prawie wszyscy dostawcy nie byli gotowi na współpracę z nami na tak niskim poziomie. Nie ma informacji o obwodach i komponentach, nie ma oficjalnego pakietu SDK zawierającego chipsety i dokumentację czujników.
Nie ma też wsparcia technicznego.

Na wszystkie pytania trzeba było odpowiedzieć metodą inżynierii odwrotnej – metodą prób i błędów. Ale daliśmy radę.

Pierwszymi modelami aparatów, na których testowaliśmy, były kamery Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link i kilka ultratanich bezimiennych chińskich aparatów.

Technika

Kamery oparte na chipsecie Hisilicon 3518E. Charakterystyka sprzętowa kamer jest następująca:

Mrówki Xiaomi Yi
noname

SoC
Hisilikon 3518E
Hisilikon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Czujnik
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikrofon
+
+

Głośnik
+
+

IRL
+
+

IRCut
+
+

Zaczęliśmy od nich.

Obecnie obsługujemy chipsety Hisilicon 3516/3518, a także Ambarella S2L/S2LM. Istnieją dziesiątki modeli aparatów.

Skład oprogramowania

Łódź podwodna

uboot to program ładujący, uruchamia się jako pierwszy po włączeniu zasilania, inicjuje sprzęt i ładuje jądro Linuksa.

Skrypt ładowania kamery jest dość trywialny:

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

Jedną z cech jest to, że nazywa się go dwukrotnie bootm, więcej o tym nieco później, gdy dotrzemy do podsystemu aktualizacji.

Zwróć uwagę na linię mem=38M. Tak, tak, to nie jest literówka - jądro Linuksa i w ogóle, wszystkie aplikacje mają dostęp tylko do 38 megabajtów RAM-u.

Również obok uboot znajduje się specjalny blok o nazwie reg_info, który zawiera skrypt niskiego poziomu do inicjowania pamięci DDR i szereg rejestrów systemowych SoC. Treść reg_info zależy od modelu kamery i jeśli nie będzie ona poprawna, kamera nie będzie mogła nawet załadować uboota, ale zawiesi się na bardzo wczesnym etapie ładowania.

Na początku, gdy pracowaliśmy bez wsparcia dostawcy, po prostu skopiowaliśmy ten blok z oryginalnego oprogramowania aparatu.

Jądro Linuksa i rootfs

Kamery korzystają z jądra Linux, które wchodzi w skład SDK chipa, zazwyczaj nie są to najnowsze jądra z gałęzi 3.x, dlatego często musimy się liczyć z tym, że sterowniki dodatkowego sprzętu nie są kompatybilne z używanym jądrem i musimy przenieść je z powrotem do kamer jądra.

Kolejną kwestią jest rozmiar jądra. Gdy rozmiar FLASH-a wynosi zaledwie 8MB, liczy się każdy bajt i naszym zadaniem jest ostrożne wyłączenie wszystkich nieużywanych funkcji jądra, aby zmniejszyć rozmiar do minimum.

Rootfs to podstawowy system plików. Zawiera busybox, sterowniki modułu Wi-Fi, zestaw standardowych bibliotek systemowych, takich jak libld и libc, a także nasze oprogramowanie, które odpowiada za logikę sterowania diodami LED, zarządzanie połączeniami sieciowymi i aktualizację oprogramowania sprzętowego.

Główny system plików jest podłączony do jądra jako initramfs i w wyniku kompilacji otrzymujemy jeden plik uImage, który zawiera zarówno jądro, jak i rootfs.

Aplikacja wideo

Najbardziej złożoną i wymagającą dużych zasobów częścią oprogramowania sprzętowego jest aplikacja, która zapewnia przechwytywanie wideo-audio, kodowanie wideo, konfiguruje parametry obrazu, wdraża analitykę wideo, na przykład czujniki ruchu lub dźwięku, steruje PTZ i odpowiada za przełączanie dnia i tryby nocne.

Ważną, powiedziałbym nawet kluczową funkcją jest sposób interakcji aplikacji wideo z wtyczką do chmury.

W tradycyjnych rozwiązaniach „firmware producenta + wtyczka do chmury”, które nie mogą działać na tanim sprzęcie, wideo wewnątrz kamery przesyłane jest protokołem RTSP – a to jest ogromny narzut: kopiowanie i przesyłanie danych przez gniazdo, niepotrzebne wywołania systemowe.

Wykorzystujemy tu mechanizm pamięci współdzielonej – wideo nie jest kopiowane ani przesyłane poprzez gniazdo pomiędzy elementami oprogramowania kamery, dzięki czemu optymalnie i ostrożnie wykorzystujemy skromne możliwości sprzętowe kamery.

Zaktualizuj podsystem

Szczególnym powodem do dumy jest odporny na awarie podsystem aktualizacji oprogramowania sprzętowego online.

Pozwól mi wyjaśnić problem. Aktualizacja oprogramowania sprzętowego nie jest technicznie operacją atomową i jeśli w trakcie aktualizacji wystąpi awaria zasilania, pamięć flash będzie zawierać część „zapisanego” nowego oprogramowania sprzętowego. Jeśli nie podejmiesz specjalnych środków, aparat stanie się „cegłą”, którą należy zanieść do centrum serwisowego.

Zajmowaliśmy się także tym problemem. Nawet jeśli aparat zostanie wyłączony podczas aktualizacji, automatycznie i bez interwencji użytkownika pobierze oprogramowanie z chmury i przywróci działanie.

Przyjrzyjmy się tej technice bardziej szczegółowo:

Najbardziej wrażliwym punktem jest nadpisanie partycji jądrem Linuksa i głównym systemem plików. Jeśli jeden z tych elementów zostanie uszkodzony, kamera w ogóle nie uruchomi się poza programem ładującym uboot, który nie może pobrać oprogramowania sprzętowego z chmury.

Oznacza to, że w dowolnym momencie procesu aktualizacji musimy upewnić się, że kamera ma działające jądro i rootfs. Wydawałoby się, że najprostszym rozwiązaniem byłoby ciągłe przechowywanie dwóch kopii jądra z rootfsami na pamięci flash i w przypadku uszkodzenia jądra głównego, załadowanie go z kopii zapasowej.

Dobre rozwiązanie - jednak jądro z rootfs zajmuje około 3.5MB i na stałą kopię zapasową trzeba przeznaczyć 3.5MB. Najtańsze aparaty po prostu nie mają tak dużo wolnego miejsca na jądro zapasowe.

Dlatego do tworzenia kopii zapasowej jądra podczas aktualizacji oprogramowania używamy partycji aplikacji.
Aby wybrać żądaną partycję z jądrem, stosuje się dwa polecenia bootm w uboot - na początek staramy się załadować jądro główne, a jeśli jest uszkodzone, to zapasowe.

Dzięki temu w każdej chwili kamera będzie miała prawidłowe jądro z rootfs, będzie mogła uruchomić się i przywrócić oprogramowanie.

System CI/CD do tworzenia i wdrażania oprogramowania sprzętowego

Do budowy oprogramowania używamy gitlab CI, który automatycznie tworzy oprogramowanie dla wszystkich obsługiwanych modeli kamer, a po zbudowaniu oprogramowania jest ono automatycznie wdrażane w usłudze aktualizacji oprogramowania aparatu.

Z usługi aktualizacje oprogramowania sprzętowego są dostarczane do kamer testowych zapewniających kontrolę jakości, a po zakończeniu wszystkich etapów testów – do kamer użytkowników.

Bezpieczeństwo informacji

Nie jest tajemnicą, że w dzisiejszych czasach bezpieczeństwo informacji jest najważniejszym aspektem każdego urządzenia IoT, w tym kamer. Botnety takie jak Mirai krążą po Internecie, infekując miliony kamer za pomocą standardowego oprogramowania sprzętowego pochodzącego od dostawców. Z całym szacunkiem dla dostawców kamer, nie mogę nie zauważyć, że standardowe oprogramowanie sprzętowe zawiera wiele funkcji, które nie są potrzebne do pracy z chmurą, ale zawierają wiele luk, z których korzystają botnety.

Dlatego wszystkie nieużywane funkcjonalności w naszym oprogramowaniu są wyłączone, wszystkie porty tcp/udp są zamknięte, a podczas aktualizacji oprogramowania sprawdzany jest podpis cyfrowy oprogramowania.

Poza tym oprogramowanie sprzętowe poddawane jest regularnym testom w laboratorium bezpieczeństwa informacji.

wniosek

Teraz nasze oprogramowanie jest aktywnie wykorzystywane w projektach nadzoru wideo. Być może największą z nich jest transmisja głosowania w dniu wyboru Prezydenta Federacji Rosyjskiej.
Projekt obejmował ponad 70 tysięcy kamer z naszym oprogramowaniem, które zostały zainstalowane w lokalach wyborczych na terenie naszego kraju.

Po rozwiązaniu szeregu skomplikowanych, a w niektórych miejscach nawet wówczas prawie niemożliwych problemów, my oczywiście jako inżynierowie mieliśmy ogromną satysfakcję, ale poza tym zaoszczędziliśmy także miliony dolarów na zakupie aparatów fotograficznych. I w tym przypadku oszczędności to nie tylko słowa i wyliczenia teoretyczne, ale wyniki zakończonego już przetargu na zakup sprzętu. W związku z tym, jeśli mówimy o monitoringu wideo w chmurze: istnieją dwa podejścia - strategicznie polegać na wiedzy specjalistycznej i rozwoju na niskim poziomie, co skutkuje ogromnymi oszczędnościami na sprzęcie, lub używać drogiego sprzętu, co, jeśli spojrzeć konkretnie na cechy konsumenckie, praktycznie nie ma różnią się od podobnych tanich.

Dlaczego strategicznie ważne jest, aby jak najwcześniej podjąć decyzję o wyborze podejścia integracyjnego? Tworząc wtyczkę, programiści opierają się na określonych technologiach (bibliotekach, protokołach, standardach). A jeśli zestaw technologii zostanie wybrany tylko dla drogiego sprzętu, to w przyszłości próba przejścia na tanie aparaty najprawdopodobniej zajmie co najmniej niesamowicie długo lub nawet zakończy się niepowodzeniem i nastąpi powrót do drogiego sprzętu.

Źródło: www.habr.com