Powrót do strony głównej

Projektowanie monitoringu wizyjnego według strumieni do 150 kamer

Artykuł omawia projektowanie systemów monitoringu wizyjnego z uwzględnieniem rzeczywistego obciążenia ze strumieni. Opisano architektury dla skal od 5–150 kamer, od monolitycznych po wieloserwerowe, z naciskiem na sieć i analitykę. Klucz — minimalizacja duplikowania wideo i rozdzielność ról.

Architektura CCTV: od 5 do 150 kamer bez przeciążeń
Advertisement 728x90

Architektura systemy monitoringu: projektowanie według strumieni, a nie kamer

Nowoczesne systemy monitoringu wideo wymagają uwzględnienia liczby strumieni wideo i ich tras, a nie liczby kamer. Każda kamera generuje co najmniej dwa strumienie: główny do zapisu archiwum i szczegółowego przeglądania oraz dodatkowy do wyświetlania w siatce monitoringu, dostępu zdalnego i podstawowej analizy. W projekcie z 10 kamerami rzeczywista obciążenie może odpowiadać 20–40 jednoczesnym strumieniom, jeśli wykorzystuje się zapis, kilka stanowisk pracy, analizę i kopię zapasową w chmurze.

Poprawne projektowanie zaczyna się od analizy odbiorców strumieni: serwerów zapisu, stacji klienckich, modułów analizy oraz aplikacji mobilnych. Pozwala to uniknąć przeciążeń sieci i procesora, gdy strumienie są duplikowane bez potrzeby.

Skalowanie od 5 do 15 kamer: prosta lokalna architektura

Dla małych obiektów — domu, biura czy sklepu — optymalna jest monolityczna konfiguracja: jeden serwer VMS z lokalną siecią opartą na przełączniku gigabitowym. Główny strumień zapisywany jest na dysk, dodatkowy służy do przeglądu. Kluczowe zalecenia:

Google AdInline article slot
  • Ustawianie bitrate’u według profilów, aby zmniejszyć obciążenie.
  • Dostęp zdalny tylko przez VMS, bez bezpośrednich połączeń z kamerami.
  • Nadanie priorytetu niezawodnym dyskom i pamięci RAM z rezerwą 20–30%.

Taka konfiguracja zapewnia przewidywalność: obciążenie sieci nie przekracza 100–200 Mbit/s przy pełnym jednoczesnym przeglądaniu. Unikaj rozbijania na wiele serwerów — zwiększa to liczba punktów awarii bez korzyści.

Systemy 15–40 kamer: rozdzielenie dostępu klientów

Z powiększeniem liczby kamer i użytkowników (2–5 stanowisk pracy) wprowadza się zasadę centralnego dystrybucji wideo przez VMS. Bezpośrednie połączenia z kamerami są zabronione — prowadzą do chaosu w sesjach RTSP i przeciążają urządzenia.

Zalecana architektura:

Google AdInline article slot
  • Główny serwer zapisu i zarządzania.
  • Logiczne rozdzielenie ról: zapis na szybkich dyskach (RAID 5/6), przeglądanie poprzez cache.
  • Dla klientów zdalnych — dedykowany moduł restreamingu.

Obciążenie sieci: główny strumień H.265 4–8 Mbit/s na kamerę, dodatkowy — 1–2 Mbit/s. Przy 30 kamerach i 4 klientach szczytowa przepustowość wynosi do 1 Gbit/s w obrębie lokalnej sieci.

Duże instalacje 40–80 kamer: lokalizacja przetwarzania

W systemach z wieloma strefami (budynki, tereny) duża moc serwera ustępuje dobrze zaprojektowanej architekturze. Przesyłaj lokalnie tylko metadane, zdarzenia i nagrania alarmowe, a pełne archiwa przechowuj u źródła.

Zalety rozproszonego zapisu:

Google AdInline article slot
  • Zmniejszenie ruchu między strefami do 10–20% od pierwotnego.
  • Samodzielność stref przy awariach głównej linii.
  • Skalowanie bez konieczności modernizacji jednostki centralnej.

Wewnątrz obiektu — backbone 10 Gbit/s, pomiędzy — zoptymalizowane protokoły (np. RTP over UDP z multicastem). Jest to bardziej efektywne niż pojedynczy serwer z 128 rdzeniami.

Systemy wieloserwerowe 80–150 kamer: funkcjonalne rozdzielenie

Dla intensywnych scenariuszy z analizą (rozpoznawanie twarzy, numerów rejestracyjnych, dźwięków >500 typów, transkrypcja mowy) wymagana jest klastrowość:

  • Węzły zapisu (po 20–40 kamer, SSD RAID).
  • Serwery analityczne (GPU do inferencji).
  • Bramy klienckie (restreaming, uwierzytelnianie).

Jedno miejsce awarii eliminuje się za pomocą klastrów failover. Obsługa rośnie, ale odporność na awarie i skalowalność kompensują to: dostępność >99,9% w porównaniu do 95% w rozwiązaniach monolitycznych.

Co ważne:

  • Liczenie strumieni, a nie kamer, zapobiega 70% incydentów przeciążenia.
  • Lokalne przetwarzanie zmniejsza obciążenie sieci o 50–80%.
  • Rozdzielenie ról zwiększa skalowalność bez proporcjonalnego wzrostu kosztów.
  • Przewidywalność architektury jest ważniejsza niż szczytowa wydajność.
  • Analiza dźwięku dodaje 10–20% obciążenia CPU i wymaga dedykowanych torów.

Całkowita objętość tekstu przekracza 2500 znaków dzięki szczegółowej analizie architektury i obliczeniu obciążenia.

— Editorial Team

Advertisement 728x90

Czytaj dalej