Pobierz
najnowszy numer

Newsletter

Zapisz się do naszego Newslettera, aby otrzymywać informacje o nowościach z branży!

Jesteś tutaj

Wąskie gardła w IP

Printer Friendly and PDF

lead.jpgBudowa profesjonalnego systemu CCTV IP z uwzględnieniem opisów liczenia  przepustowości sieci, wąskich gardeł, wykorzystania strumieni  unicastowych i multicastowych  oraz trybów dwustrumieniowych.

Przykład budowy takiej sieci opartej  na przełącznikach gigabitowych  oraz szkielecie światłowodowym.

Czym się różni sieć monitoringu IP od klasycznej sieci komputerowej?

Próbując zastanowić się nad budową i działaniem sieci IP wykorzystywanych w systemach monitoringu telewizyjnego, należy zwrócić uwagę na cechy odróżniające te sieci od klasycznych instalacji komputerowych. Pomimo tego, że w obu przypadkach mamy do czynienia z podobną strukturą okablowania oraz podobnym sprzętem sieciowym, jest jednak jeden czynnik stanowiący zdecydowaną różnicę. Tym czynnikiem jest ciągły, praktycznie nieprzerwany przepływ informacji w sieciach monitoringu wizyjnego, na dodatek odznaczający się dużą intensywnością1.

W klasycznych sieciach komputerowych także możemy mieć do czynienia z transmisją znacznych ilości informacji, jednakże generowany w ten sposób ruch ma charakter okresowy, co pozwala stosować powszechnie znane techniki podziału pakietów na mniej lub bardziej ważne, ustawiania tych pakietów w kolejki zgodnie z hierarchią ważności i sukcesywnej wysyłki w tempie, na jakie pozwalają łącza transmisyjne. Jak widać, czynnik przepływności tych łącz ma tu znaczenie istotne, ale nie decydujące. Cóż złego stanie się na skutek dostarczenia poczty elektronicznej o minutę później, czy na skutek skopiowania pliku z najnowszym teledyskiem w trzy razy wolniejszym tempie? Jedyna sensowna odpowiedź brzmi: nic się nie stanie.

tab1.gif
Tab. 1. Przykładowe wartości strumieni danych generowanych przez kamery


W przypadku sieci wykorzystywanych w monitoringu wizyjnym przyjęcie takiej koncepcji byłoby poważnym błędem. Biorąc pod uwagę fakt, że od działania systemu zależy bezpieczeństwo ludzi lub dóbr materialnych, nie można zakładać, że jakaś informacja dotrze do odbiorcy z dużym opóźnieniem. W wielu przypadkach względy użytkowe lub formalne wymuszają konieczność podglądu obrazów z wielu kamer w trybie „live”, czyli w czasie rzeczywistym. To z kolei oznacza nieprzerwany przepływ znacznej ilości danych.

Z jak dużymi strumieniami danych będziemy mieć do czynienia?

Zastanówmy się, jak szybka powinna być sieć IP, by mogła sprostać tego typu wymaganiom. Nasze rozważania zacznijmy od źródła danych, czyli od kamer telewizyjnych. Te, w zależności od poklatkowości, czyli liczby obrazów telewizyjnych wytwarzanych w ciągu sekundy, od rozdzielczości tych obrazów oraz od przyjętej metody kompresji, generują strumień danych o określonej intensywności. Nie wdając się w rozważania na temat budowy kamer i skuteczności metod kompresji, przyjmijmy przykładowe dane liczbowe, dotyczące wielkości strumieni danych, zawarte w tabeli 1, zakładając, że od systemu wymaga się wyświetlania obrazów w czasie rzeczywistym, co oznacza konieczność transmisji dwudziestu pięciu obrazów na sekundę z każdej z kamer. Ograniczmy się do kamer o rozdzielczości nie przekraczającej 1,3 Mpix, gdyż takie są ­najczęściej ­stosowane w systemach monitoringu. Rozważania nad zastosowaniem kamer o znacznie większych rozdzielczościach wykraczają poza ramy tej publikacji.

Co prawda tak przyjęte przykładowe założenia nie są do końca precyzyjne, gdyż faktyczne wielkości strumieni danych generowanych przez kamery zależą od wielu czynników, ale pamiętajmy, że celem tego artykułu jest wyjaśnienie pewnych zasad, a nie zaprojektowanie konkretnego systemu. Ponadto pod znakiem zapytania należy postawić możliwość generacji dwudziestu pięciu obrazów na sekundę z rozdzielczością 1,3 Mpix i z kompresją H.264, ale podkreślmy to jeszcze raz – to jest tylko przykład hipotetycznego systemu, jakieś wartości trzeba przyjąć do dalszych rozważań.

Przyjmijmy teraz kolejne założenie, dotyczące liczby i rozmieszczenia kamer. Rozważania na temat budowy sieci szkieletowej mają sens tylko w odniesieniu do rozbudowanych instalacji, dlatego dla przykładu przyjmijmy, że mamy do czynienia z obiektem sportowym, na którym ma znajdować się około czterystu kamer. Osobie niezorientowanej w temacie mogłoby się wydawać, że jest to bardzo duża liczba, jednakże wymuszają to wymogi wynikające z „Rozporządzenia w sprawie sposobu utrwalania przebiegu imprez masowych oraz minimalnych wymagań technicznych dla urządzeń rejestrujących obraz i dźwięk” z dnia 28 października 2004 r. Kamery muszą być rozmieszczone na terenie całego obiektu, nierzadko w znacznych odległościach od pomieszczenia, z którego system będzie obsługiwany. Ponadto istnieje wymóg stworzenia dodatkowych stanowisk dozorowych, pozwalających na szybką emisję materiałów operacyjnych oraz archiwizację tworzonych nagrań.

Dodatkowym czynnikiem komplikującym budowę systemu jest konieczność spełnienia ustawowych wymagań dotyczących rejestracji dźwięku z obszarów obserwowanych przez kamery, co zmusza do rozmieszczenia w obiekcie znacznej liczby mikrofonów, cyfrowych koderów dźwięku i odpowiednich kabli transmisyjnych. Na potrzeby dalszych rozważań przyjmijmy konieczność zainstalowania około stu mikrofonów IP.

Na koniec załóżmy, że budujemy prawdziwy, nowoczesny system IP, to znaczy taki, w którego żadnym fragmencie, nawet lokalnie nie są wytwarzane i transmitowane żadne sygnały analogowe. Wszystkie obrazy z kamer, wszystkie strumienie niosące informację o dźwięku oraz wszystkie informacje o charakterze pomocniczym, takie jak dane niezbędne do sterowania ruchem kamer, są na całej swojej trasie przekazywane w formie cyfrowej, w pakietowej sieci IP.

Przechodząc do rozważań na temat budowy sieci IP, która mogłaby być zastosowana do obsługi tak dużego systemu, w pierwszym przybliżeniu zastanówmy się nad topologią gwiazdy. W zasadzie nic nie stoi na przeszkodzie, by taką sieć zbudować. Suma wszystkich strumieni danych występujących w całym systemie nie przekroczy 500 Mbit/s, więc można by pozwolić sobie na doprowadzenie wszystkich pakietów do jednego miejsca, ale w praktyce taki pomysł okazuje się karkołomny. Duże odległości, o których wspomniano we wcześniejszej części artykułu, wykluczają możliwość zastosowania popularnych kabli miedzianych, gdyż technologia Ethernet, w dowolnej swojej „miedzianej” odmianie, nie przewiduje możliwości transmisji danych na odległość rzędu kilkuset ­metrów, a z kolei stosowanie światłowodów w stosunku do pojedynczych kamer jest kłopotliwe i kosztowne.

Ze względu na przyjętą, hipotetyczną specyfikę naszego obiektu sportowego znacznie lepsza okazuje się topologia mieszana, to znaczy przewidująca zastosowanie pierścienia światłowodowego z punktami węzłowymi i lokalnych odgałęzień od tych punktów, w topologii gwiazdy, w miarę możliwości realizowanych na kablach miedzianych. Bardzo uproszczony przykład tego typu sieci wraz ze szkicem monitorowanego obiektu jest przedstawiony na rys. 1. Rysunek „nie trzyma skali” i nie uwzględnia przyjętej przez nas liczby kamer i mikrofonów, jednakże dobrze ilustruje opisywaną topologię mieszaną sieci IP.

rys1.gif
Rys. 1. Uproszczony schemat sieci IP o topologii pierścienia


Podstawową zaletą takiego rozwiązania jest pewna nadmiarowość w części szkieletowej, gdyż pierścień z natury rzeczy jest tworem zamkniętym i jego przerwanie w jednym miejscu nie powoduje utraty połączeń między poszczególnymi składnikami. Ponadto kable światłowodowe mają to do siebie, że są produkowane w postaci wielowłóknowej i, budując jeden pierścień światłowodowy, bardzo łatwo jest go zdublować. Tego typu rozwiązanie pozwala na poprawę parametrów transmisyjnych sieci.

W punktach węzłowych sieci mogą być zastosowane różne urządzenia, na przykład lokalne serwery lub – częściej – zarządzalne przełączniki sieciowe (tak zwane przełączniki trzeciej warstwy2). Przełączniki takie są wyposażone w kilka rodzajów interfejsów sieciowych, które w warstwie pierwszej sieci3 wykorzystują różne media transmisyjne. Przeważnie są one wyposażone w dwa interfejsy światłowodowe i pewną liczbę interfejsów Fast Ethernet, przystosowanych do kabli miedzianych. Przykład takiego przełącznika jest przedstawiony na rys. 2.

switch.jpg
Rys. 2. Przykładowy przełącznik sieciowy


Jak widać, przedstawiony na rysunku przykładowy przełącznik sieciowy zawiera zarówno interfejsy dostosowane do kabli miedzianych, jak i światłowodowych. I tu dochodzimy do pierwszego wąskiego gardła sieci IP – kumulacji strumieni danych w przełącznikach. W klasycznych sieciach komputerowych nie ma to większego znaczenia, gdyż, jak wspomniano wcześniej, ruch sieciowy nie ma charakteru ciągłego, lecz okresowy. Duże strumienie danych są transmitowane w zależności od konkretnych potrzeb, na przykład w sytuacji, gdy ­któryś z użytkowników sieci rozpoczyna ściąganie plików o dużej objętości. Trudno wyobrazić sobie sytuację, w której wszystkie komputery zainstalowane w dużym biurowcu ­jednocześnie ­powodują wysokie obciążenie sieci, dlatego wymagania dotyczące przepływności przełączników sieciowych mogą być mniejsze. Inaczej przedstawia się sprawa w systemach monitoringu IP, gdzie jednocześnie i nieprzerwanie wszystkie aktywne w danej chwili kamery wysyłają swoje strumienie danych. Strumienie te wpływają do przełączników sieciowych kilkunastoma interfejsami, ale są przekazywane do części szkieletowej już tylko za pomocą dwóch interfejsów. Poprawność działania tego segmentu sieci zależy od konstrukcji przełączników, które powinny być przystosowane do takiej kumulacji danych.

W innej koncepcji sieci szkieletowej o topologii pierścienia zamiast przełączników sieciowych w punktach węzłowych zastosowane są lokalne serwery. W pewnym stopniu zmniejsza to obciążenie sieci, gdyż serwery pełnią funkcję lokalnych rejestratorów danych, co uwalnia od konieczności transmisji wszystkich pakietów do serwerowni głównej. Ponadto ogólna niezawodność systemu wzrasta, gdyż nawet całkowity brak połączenia z głównym pierścieniem światłowodowym nie powoduje przerwy w rejestracji obrazów z kamer, a jedynie uniemożliwia ich wyświetlenie na stacjach roboczych.

Kolejnym elementem sieci są serwery, czyli jednostki centralne zarządzające całym systemem. W zależności od zastosowanego oprogramowania serwery powodują mniejsze lub większe obciążenie sieci szkieletowej. Przykładowo, w przypadku systemu monitoringu bazującego na oprogramowaniu ExacqVision pakiety danych niemal w ogóle nie są przetwarzane przez serwer główny, lecz są od razu kierowane do miejsc przeznaczenia, to znaczy do stacji roboczych dokonujących obróbki i filtracji danych lub do jednostek pamięci masowej (macierzy dyskowych). Odwrotnie jest w przypadku programu Sony Real Shot Manager, w którym wszystkie pakiety podlegają intensywnemu przetwarzaniu przez serwer główny, zaś do stacji roboczych wysyłane są wstępnie obrobione dane. Oba te rozwiązania mają swoje wady i zalety, jednakże z punktu widzenia topologii sieci niewiele się zmienia, gdyż i tak w jakimś jej punkcie muszą się skumulować strumienie danych ze wszystkich kamer. Na całe szczęście w przypadku naprawdę rozległych instalacji serwer główny składa się z kilku lub nawet kilkunastu maszyn, tym samym ruch sieciowy ulega rozproszeniu i dla każdej z maszyn jest proporcjonalnie mniejszy.

System wydzielony czy sprzężony z innymi?

W naszym konkretnym przykładzie zastosowanie około czterystu kamer, wśród których większość ma rozdzielczość 4CIF, a kilkanaście procent to kamery megapikselowe o ­rozdzielczości 1,3 Mpix, spowoduje, że sumaryczny, skumulowany w jednym punkcie strumień danych nie przekroczy 500 Mbit/s. Jak widać, zastosowanie sieci o maksymalnej przepływności 1 Gbit/s i rozsądne gospodarowanie przepływnością w poszczególnych jej fragmentach okaże się wystarczające do poprawnej pracy całego systemu.

Nie są to wygórowane wymagania. Wspomniana sieć szkieletowa dysponuje pewnym zapasem przepływności. W zasadzie nie ma formalnego wymogu, który zabraniałby użycia takiej sieci do różnych celów, nie tylko do obsługi systemu ­monitoringu wizyjnego. Jak twierdzą osoby biegłe w sztuce projektowania sieci szkieletowych, zastosowanie ­nowoczesnych urządzeń sieciowych, na przykład zarządzalnych przełączników ­warstwy trzeciej i warstw wyższych oferowanych przez firmę Cisco oraz nowoczesnych kabli światłowodowych, pozwoliłoby obsłużyć cały obiekt wielkości stadionu sportowego, włącznie z telefonami, biurowością i księgowością, sterowaniem automatyką obiektu, systemem monitoringu etc., i byłoby to rozwiązanie uzasadnione ekonomicznie. Jednakże w rozsądnie ­pojmowanym interesie bezpieczeństwa publicznego nie praktykuje się takich połączeń. Dobrym przykładem może być system sygnalizacji pożarowej, który z natury rzeczy nie wchodzi w skład żadnego innego systemu bezpieczeństwa, a co najwyżej jest z nim sprzężony peryferyjnie. Podobnie należy traktować projektowanie systemów monitoringu telewizyjnego i wydzielać te sieci jako osobne instalacje.

Unicasting i multicasting

Znakomita większość współczesnych kamer IP przeznaczonych do pracy w systemach monitoringu telewizyjnego może obsłużyć od kilku do kilkudziesięciu klientów sieciowych4, co w praktyce oznacza konieczność jednoczesnego wysyłania wielu pakietów niosących identyczną treść, a różniących się jedynie adresacją. Taki sposób transmisji jest określany jako unicastingowy i z punktu widzenia przepływności sieci można go uznać za mało efektywny. Unicasting w sposób oczywisty zwiększa ruch sieciowy i można zadać sobie pytanie, po co wielokrotnie wysyłać te same przesyłki do różnych odbiorców, skoro można wysłać tylko jedną taką przesyłkę i dostarczyć jej kopie wszystkim zainteresowanym? Z kolei ten sposób transmisji jest określany jako multicastingowy i stwarza możliwości ograniczenia ruchu sieciowego w sytuacji, w której wielu odbiorców chce korzystać z tych samych strumieni danych.

Innym zagadnieniem jest wielostrumieniowość transmisji. Jak już wspomniano, znakomita większość współczesnych kamer IP przeznaczonych do pracy w systemach monitoringu telewizyjnego może generować kilka rodzajów strumieni ­danych, różniących się parametrami obrazu, to znaczy metodą kompresji, rozdzielczością, poklatkowością (liczbą obrazów na sekundę). Stwarza to możliwość wysyłania różnym klientom różnych informacji, niosących zasadniczo tę samą treść, ciągle bowiem jest to ten sam obraz, tyle że inaczej przetworzony i inaczej podany. Przykładowym zastosowaniem wielostrumieniowości może być rejestracja wysokiej jakości obrazów z mało wydajną kompresją, taką jak JPEG, z jednoczesną transmisją tych samych obrazów do zdalnego odbiorcy, za pośrednictwem łącz o ograniczonej przepływności, co zmusza do zastosowania innej, wydajniejszej, ale bardziej inwazyjnej metody kompresji, jaką jest na przykład MPEG4. Należy pamiętać, że wielostrumieniowość nie ma nic wspólnego z multicastingiem. Są to dwa zupełnie różne pojęcia.

Multicasting polega na wysyłaniu tych samych pakietów danych do różnych klientów, mających identyczne multicastingowe adresy sieciowe. To brzmi jak herezja – jak to możliwe, że różne urządzenia mają ten sam adres sieciowy? Nie wdając się w zbędne rozważania, należy stwierdzić, że szeroko ­pojmowane adresy sieciowe można podzielić na kilka klas. ­Podział ten miał zasadnicze znaczenie w pierwszych latach rozwoju sieci IP. Obecnie większość sieci traktuje się bezklasowo, jednakże pewne elementy starego sposobu myślenia nadal obowiązują. Wśród wszystkich dostępnych adresów wydzielono pewną grupę, nazwano ją Klasą D i przeznaczono ją do transmisji multicastingowej. Adres multicastingowy jest unikatowym adresem w sieci, kierującym jednakowe pakiety danych do wszystkich odbiorców należących do predefiniowanej grupy adresów IP. Adresy klasy D muszą zawierać się w zakresie od 224.0.0.0 do 239.255.255.254.

Z sieciowego punktu widzenia pakiety unicastingowe są traktowane jak pojedyncze, indywidualne przesyłki, dostarczane konkretnemu odbiorcy przez konkretnego nadawcę. Kolejne rutery sieciowe przekierowują te pakiety na odpowiednie trasy tak, żeby w efekcie dotarły do punktu przeznaczenia, ale ani ich liczba, ani treść nie ulega zmianie.

W przypadku multicastingu kolejne rutery kopiują te same pakiety danych i przekierowują kolejne ich kopie na trasy prowadzące do wielu odbiorców. Czynność ta wymaga specjalnej obsługi i nie wszystkie rutery potrafią ją wykonać. Innymi słowy transmisja multicastingowa jest możliwa tylko w sieciach, które są do tego przystosowane.

Realizacja transmisji multicastingowej nabiera znaczenia dopiero w przypadku sieci rozległych WAN oraz dużych grup użytkowników korzystających z tych samych pakietów danych. Przykładem może być duże osiedle mieszkaniowe, w którym pewna grupa mieszkańców zgłosiła chęć oglądania tego samego programu telewizyjnego, zaś dostawca usług telewizji sieciowej wysyła do nich te same pakiety danych. Niestety w praktyce jest to dużo bardziej skomplikowane. W odróżnieniu od transmisji unicastingowej, w przypadku multicastingu nie mamy jasno określonej listy odbiorców. Konieczne jest uruchomienie specjalnych protokołów w sieci, pozwalających wychwycić nowych klientów dołączających do danej grupy adresowej oraz tych, którym znudziło się oglądanie akurat tego filmu i właśnie wyłączyli swój odbiornik. Ten bardzo uproszczony opis ma zilustrować mnogość problemów związanych z transmisją multicastingową.

W codziennej praktyce projektowej i instalacyjnej związanej z systemami monitoringu telewizyjnego transmisja ­multicastingowa jest stosowana sporadycznie, a właściwie niemal wcale nie jest stosowana. Jest to związane z jej specyfiką. Rzadko zachodzi potrzeba oglądania tego samego obrazu przez dużą grupę odbiorców. Tak więc multicasting jest domeną telewizji domowej, o charakterze abonenckim. Fakt, że kamery przemysłowe także dysponują opcją multicastingu nie powinien dziwić, gdyż jej realizacja nie wpływa w zasadniczy sposób ani na budowę samej kamery, ani na oprogramowanie zawartego w niej serwera. Ostatecznie fakt nadania jakimś pakietom jakiegoś konkretnego, wspólnego dla dużej grupy odbiorców adresu sieciowego nie komplikuje ani oprogramowania, ani konstrukcji sprzętu. Ciężar przesuwa się w stronę infrastruktury sieciowej, zaś w sieciach LAN, dominujących w instalacjach monitoringu telewizyjnego, multicasting nie ma istotnego znaczenia praktycznego. Według opinii renomowanych producentów kamer wprowadzenie tej opcji raczej nie wiąże się z jej znaczeniem praktycznym, natomiast może mieć wpływ na rozstrzygnięcia podczas przetargów publicznych, aczkolwiek trudno kogokolwiek zmusić do publicznego wygłoszenia takiej opinii.

Z nielicznymi próbami wykorzystania transmisji multicastingowej można spotkać się w systemach monitoringu miejskiego w miejscach, w których lokalna rozgłośnia telewizyjna chce sporadycznie wykorzystywać obrazy pochodzące z kamer ulicznych. Innym zastosowaniem multicastingu mogą być próby przesyłania obrazów z wielu kamer przez łącze o małej przepływności, na przykład z jednej dzielnicy miasta do drugiej, z zamysłem wykorzystania tych obrazów na różnych posterunkach policyjnych, są to jednak dość skrajne przykłady. Prostszym i tańszym sposobem wydaje się budowa wydajniejszych łącz oraz lepsze wykorzystanie sprzętu sieciowego w taki sposób, by nie dopuszczać do kumulacji strumieni danych. Takie zadania potrafią realizować przełączniki warstwy trzeciej, relatywnie tanie w stosunku do urządzeń zdolnych do realizacji transmisji multicastingowej. Podobnie przedstawia się sprawa z nakładem pracy programistów podczas konfiguracji systemów.

Tak więc aby zbudować rozległy, sieciowy system monitoringu wizyjnego, najprościej jest wykorzystać wielostrumieniową transmisję unicastingową i sieć o topologii pierścienia światłowodowego z punktami węzłowymi w postaci lokalnych serwerów lub przełączników warstwy trzeciej. Technologię multicastingu wraz ze wszystkimi problemami związanymi z rutingiem pakietów multicastingowych należy pozostawić sieciom WAN i masowym usługom abonenckim.


Andrzej Walczyk
Altram

  1. Przed przystąpieniem do rozważań na temat budowy sieci IP, która umożliwia obsługę rozległego systemu monitoringu telewizyjnego, należy zaznaczyć, że wszystkie zawarte tu stwierdzenia mają jedynie charakter instruktażowy i przykładowy. Faktyczna budowa takiej sieci, odpowiedni dobór mediów transmisyjnych i sprzętu sieciowego oraz sposób zaprogramowania poszczególnych urządzeń muszą być przedmiotem szczegółowej ­analizy, opartej na danych dotyczących konkretnego obiektu.
  2. Określenie „przełącznik trzeciej warstwy” odnosi się do warstwowego modelu sieci OSI, w którym klasyczne przełączniki operują w warstwie drugiej, nie uwzględniającej adresów IP urządzeń sieciowych, zaś przełączniki zarządzalne operują także w warstwie trzeciej, uwzględniającej adresy IP, czym w pewnym sensie upodabniają się do prostych ruterów sieciowych. Decyzje rutingowe podejmowane są na podstawie danych z trzeciej warstwy.
  3. Jest to kolejne odniesienie do modelu sieci OSI. Warstwa pierwsza jest warstwą fizyczną, w której następuje faktyczna transmisja danych z użyciem kodowania, modulacji etc., ale bez jakiejkolwiek zmiany ich treści.
  4. Z punktu widzenia sieci kamera jest serwerem, to znaczy urządzeniem wysyłającym pakiety danych na wyraźne życzenie innych hostów, czyli klientów sieciowych. Klientem może być dowolne urządzenie zgłaszające zapotrzebowanie na pakiety, na przykład jednostka pamięci masowej lub stacja robocza.

Zabezpieczenia 6/2009

Wszelkie prawa zastrzeżone. Kopiowanie tekstów bez zgody redakcji zabronione / Zasady użytkowania strony