Integracja sensorów analogowych w systemach monitoringu wizyjnego

Transkrypt

1 Telekomunikacja Cyfrowa Technologie i Us³ugi Tom 10. Rok 2010/2011 Integracja sensorów analogowych w systemach monitoringu wizyjnego Andrzej G³owacz, Maciej Burczyk, Marcin Hartung ( aglowacz@agh.edu.pl) AGH Akademia Górniczo-Hutnicza w Krakowie STRESZCZENIE Niniejszy artyku³ poœwiêcony jest integracji czujników analogowych w obrêbie systemów monitoringu. Do realizacji tego celu opracowano uk³ad s³u ¹cy do pomiaru wielkoœci fizycznych oraz aplikacjê operatora systemu wraz z us³ug¹ sieciow¹ dzia³aj¹c¹ po stronie serwera. Dziêki proponowanemu rozwi¹zaniu sensory analogowe mog¹ byæ pod³¹czane bezpoœrednio do kamer sieciowych, co pozwala na rozszerzenie istniej¹cych instalacji monitoringu. Zaprezentowane podejœcie pozwala na efektywne przetwarzanie danych pomiarowych przy jednoczesnym zapewnieniu niskich kosztów wdro enia kompletnego systemu wizyjno-pomiarowego. S³owa kluczowe: sensory analogowe, kamery IP, systemy monitoringu wizyjnego ABSTRACT Integration of Analog Sensors within Visual Surveillance Systems This paper addresses an issue of integration of analog sensors within modern visual surveillance systems that include network cameras. In order to achieve such integration, a dedicated adapter for quantity measurements, an operator application and a corresponding network service have been developed. In presented approach analog sensors can be connected through the adapter to network camera, what allows for convenient extension of existing surveillance installations. The complete solution clears the way for effective measurements processing and low-cost implementation of the whole system. Key words: analog sensors, IP cameras, video surveillance systems 1. WSTÊP Istniej¹ce systemy monitoringu wizyjnego na ogó³ sk³adaj¹ siê z analogowych kamer CCTV (Closed-Circuit TeleVision) i wdra ane s¹ w jednej wybranej lokalizacji. Takie instalacje s¹ ukierunkowane na podstawowe funkcje zwi¹zane z nadzorem operatora, a mianowicie obserwacjê wyœwietlanego obrazu (analogowego) i odtwarzanie rejestrowanych sekwencji wideo. Taki system wizyjny mo e byæ ponadto po³¹czony z systemem alarmowym, co pozwala na realizacjê pewnych dodatkowych funkcji, np. alarmu wyzwalanego automatycznie przez kamerê w przypadku wykrycia ruchu obiektów czy reakcjê na detekcjê w podczerwieni. Zakres funkcjonalny systemu alarmowego mo e byæ rozszerzony przy u yciu wspomagaj¹cych sensorów analogowych, jednak zasiêg przekazywania informacji jest zazwyczaj ograniczony do jednej lokalizacji. Instalacje monitoringu, które pozwalaj¹ na wymianê danych poprzez protokó³ IP, sk³adaj¹ siê m.in. z zaawansowanych kamer sieciowych. Tego typu systemy s¹ u ywane do po³¹czenia np. placówek przedsiêbiorstw lub innych odleg³ych lokalizacji. Dodatkow¹ zalet¹ w stosunku do systemów analogowych jest w tym przypadku w pe³ni cyfrowe przetwarzanie danych, pozwalaj¹ce na uzyskanie wy szej jakoœci transmitowanego obrazu, oraz mo liwoœæ rejestrowania obrazu bezpoœrednio na kartach pamiêci do 32 GB [1]. Ponadto kamery sieciowe wyposa one w matryce wykonane w technologii CMOS zapewniaj¹ obraz w rozdzielczoœci 1080p (lub wy szej), jak równie zawansowan¹ kompresjê, np. z u yciem protoko³u H.264. Rozwój rozwi¹zañ, których dzia³anie jest oparte na protokole IP, pozwala na uniwersaln¹ integracjê systemów komputerowych [2]. W przypadku zdalnego systemu pomiarowego, pod³¹czenie wielu sensorów do serwera pomiarowego wymaga zazwyczaj dodatkowego okablowania i dostêpnych portów wejœciowych w serwerze. Szczególnie w przypadku, gdy dane z sensorów musz¹ byæ odczytane niezale nie, liczba portów mo- e okazaæ siê niewystarczaj¹ca. Aby rozwi¹zaæ ten problem, w pracy postawiono za cel zaprojektowanie i wykonanie systemu wizyjno-pomiarowego. W jego ramach mo liwe jest pod³¹czenie szerokiej gamy sensorów bezpoœrednio do kamery, która pe³ni w tym przypadku funkcjê serwera. W pozosta³ej czêœci artyku³u przedstawiono: ogólne architektury sensorów w Rozdziale 2, zaproponowany system w Rozdziale 3 i opis zbudowanego urz¹dzenia pomiarowego w Rozdziale 4. Rozdzia³ 5 zawiera przyk³adowe rezultaty uzyskane w demonstratorze systemu. Na koñcu artyku³u zawarto wnioski i kierunki przysz³ych badañ. 59

2 2. ISTNIEJ CE ARCHITEKTURY SENSORÓW W SYSTEMACH MONITORINGU W systemie nadzoru czêsto sam obraz wideo nie jest wystarczaj¹cy i zachodzi potrzeba pomiaru tak e innych wielkoœci fizycznych. Sensorami u ywanymi w tym celu mog¹ byæ np. detektory t³uczonego szk³a, czujniki ruchu lub tzw. styki informuj¹ce o otwarciu drzwi lub okna [3]. Maj¹ one tylko dwa stany, reprezentuj¹ce logiczne 0 lub 1 i s¹ proste w u yciu. Niektóre aplikacje wymagaj¹ analizy warunków atmosferycznych, takich jak: temperatura, wilgotnoœæ lub ciœnienie. Przyk³adowo, w Bibliotece Jagielloñskiej w Krakowie specjalne zbiory przechowywane s¹ temperaturze o C przy wilgotnoœci powietrza na poziomie 40 50%. Kolejnym przyk³adem s¹ ogrody botaniczne i szklarnie, które potrzebuj¹ utrzymania warunków korzystnych dla wzrostu hodowanych roœlin. Zwykle u ywa siê modelu sterowania tych parametrów opartego na termostatach, a pracê systemu nadzoruje operator. Czujniki wymienionych wielkoœci fizycznych s¹ cyfrowe lub analogowe. Skuteczny system ochrony powinien wykrywaæ ulatniaj¹ce siê gazy, takie jak: tlenek wêgla, metan czy dym, poniewa w przypadku tych zagro eñ szybka reakcja mo e nawet uratowaæ ludzkie ycie. U ywane s¹ czujniki, które zmieniaj¹ rezystancje pod wp³ywem niebezpiecznego gazu lub czujniki z wyjœciem dwuwartoœciowym. W tradycyjnej architekturze pomiarowej z analogowymi kamerami u ywa siê schematu po³¹czeñ pokazanego na rysunku 1. Kamery i czujniki s¹ niezale nie po³¹czone z serwerem, gdzie analizowane s¹ nietypowe sytuacje i alarmy [4]. G³ównym problemem jest indywidualne ³¹czenie urz¹dzeñ za pomoc¹ sieci Ethernet. Ostatnio w tym obszarze zastosowañ produkuje siê coraz wiêcej urz¹dzeñ typu serwer HTTP-COM oraz zdalnych, internetowych stacji pomiarowych. Producenci mikrokontrolerów oferuj¹ coraz czêœciej uk³ady ze sprzêtow¹ obs³ug¹ stosu TCP/IP lub nawet z wbudowan¹ warstw¹ fizyczn¹ gotowe do wspó³pracy w sieci. Mimo takich u³atwieñ rozwi¹zania wci¹ s¹ stosunkowo drogie, a budowa opartych na nich urz¹dzeñ dosyæ skomplikowana i czasoch³onna. Kolejnym utrudnieniem jest koniecznoœæ instalacji dodatkowej linii przewodów sieciowych oraz obecnoœæ urz¹dzenia, które nale y umiejscowiæ i zasiliæ. Z powodu tych problemów firmy montuj¹ce systemy nadzoru czêsto decyduj¹ siê na wykonanie dwu lub wiêcej niezale nych podsystemów, np. monitoringu, przeciwpo arowego i pomiarowego. W systemach zawieraj¹cych kamery sieciowe architektura wspierana przez producentów ma formê przedstawion¹ na rysunku 2 [3, 5]. Rys. 2. Rozszerzona architektura czujników Rys. 1. Tradycyjna architektura czujników W takim rozwi¹zaniu mo na u yæ jednego lub kilku prostych czujników z wyjœciem logicznym. Zmiana ich stanu wyzwala alarm, który jest analizowany w kamerze i mo e byæ u yty do w³¹czenia urz¹dzenia sygnalizuj¹cego, np. lampy lub syreny alarmowej. Rozwi¹zanie umo liwia podstawow¹ integracjê, ale jego funkcjonalnoœæ jest bardzo ograniczona u yte mog¹ byæ tylko proste urz¹dzenia. Bardziej z³o one pomiary wci¹ musz¹ byæ przeprowadzane w inny sposób. Oba prezentowane rozwi¹zania nie daj¹ mo liwoœci pomiaru dowolnych wartoœci prostym i niedrogim sposobem. Uniwersalny i w pe³ni zintegrowany system móg³by okazaæ siê lepszym rozwi¹zaniem. 60

3 3. INTERFEJSY KAMERY SIECIOWEJ Obecnie kamery sieciowe IP budowane s¹ przy wykorzystaniu zawansowanych uk³adów scalonych, miêdzy innymi ETRAX 100LX, ARTPEC-3 oraz uk³ady oparte na procesorach z rdzeniem ARM. Uk³ady te s¹ projektowane dla systemów operacyjnych opartych na j¹drze Linux. Mo liwoœæ integracji chipu z systemem operacyjnym oraz wyposa enie go w stosunkowo du e zasoby sprzêtowe (pamiêæ RAM ok. 256 MB, pamiêæ flash ok. 128 MB i opcjonalne karty pamiêci SD/SDHC do 32 GB) [1], dostarczaj¹ obecnie twórcom szerokich mo liwoœci integracji systemów monitoringu. Rozwa any uk³ad pokazany na rysunku 3 posiada przydatne komponenty. Na p³ycie oprócz kontrolera Ethernet znajduj¹ siê kontrolery obs³uguj¹ce porty I/O oraz port RS-232 lub RS-485. Oba standardy maj¹ okreœlone elektryczne specyfikacje zgodne z protoko- ³em UART i s¹ obs³ugiwane poprzez interfejs sterowania API przy u yciu skryptów CGI [6]. Standard RS-232 okreœla poziomy napiêcia odpowiadaj¹ce logicznej jedynce i logicznemu zeru dla transmisji danych. By³ on niegdyœ stosowany do po³¹czeñ np. komputera z urz¹dzeniami peryferyjnymi, takimi jak klawiatura czy mysz. W tym standardzie mo na osi¹gn¹æ jedynie niski transfer, u ywaj¹c krótkich przewodów (do 10 metrów), co mo e okazaæ siê niewystarczaj¹ce w systemie monitoringu. Standard RS-485 rozwi¹zuje te problemy. Dziêki wysy³aniu danych poprzez skrêcon¹ parê ró nicow¹ margines szumu jest zredukowany. W konsekwencji mo emy uzyskaæ prêdkoœci transmisji do 10 Mb/s lub zasiêg do 1200 metrów. W praktyce pozwala to na objêcie du ego obszaru za pomoc¹ jednego tylko urz¹dzenia serwerowego. Wybrane kamery sieciowe posiadaj¹ zaimplementowane podstawowe programy do obs³ugi zdarzeñ portów I/O. Zapewnia to ³atwe programowanie obs³ugi elementarnych wyj¹tków, np. detekcji ruchu. Oprócz podstawowych regu³ mo na tworzyæ bardziej skomplikowane zale noœci (np. automatyczne podejmowanie decyzji na podstawie statusów portów), a dziêki zainstalowanemu systemowi operacyjnemu mo na zaimplementowaæ je w kamerze sieciowej [8]. Z kolei, powszechnie stosowane porty szeregowe RS przeznaczone s¹ g³ównie do obs³ugi elementów obrotowych PTZ (Pan-Tilt-Zoom) poprzez protokó³ Pelco-D w kamerach, które nie maj¹ wbudowanej funkcjonalnoœci sterowania obiektywem. Ze wzglêdu na zastosowan¹ architekturê uk³adów oraz integracjê ze œrodowiskiem systemu operacyjnego, implementacja programów do obs³ugi portów jest zbli ona do innych rozwi¹zañ, poniewa ETRAX 100LX bardzo dobrze wspiera jêzyki C i C++ [7]. Problemem mog¹ okazaæ siê jednak ograniczenia w dostêpie do portów narzucone przez producentów kamer. Rys. 3. Schemat blokowy p³yty ETRAX 100LX [7] 61

4 4. PROPONOWANY SYSTEM POMIAROWY Proponowany przez autorów system bazuje na zastosowaniu sieciowych kamer IP oraz analogowych zestawów czujników zintegrowanych w jedn¹ funkcjonaln¹ ca³oœæ przy u yciu adaptera RS-485. W celu zrealizowania tak okreœlonego zadania, zaproponowano nastêpuj¹c¹ architekturê czujników (rys. 4). Stosuj¹c powy szy schemat po³¹czenia sensorów mo na wzbogaciæ system monitoringu, a na podstawie danych z wielu czujników podejmowaæ optymalne decyzje. Dziêki mo liwoœciom systemu operacyjnego mo na tworzyæ aplikacje, które systematycznie pobieraj¹ i analizuj¹ dane, a na tej podstawie wykonuj¹ w³aœciwe dla danej sytuacji dzia³ania. Dodatkowo administrator systemu otrzymuje zbiorcze dane z sensorów, prezentowane w dedykowanym interfejsie. Innowacyjnoœæ tego podejœcia polega na zastosowaniu kamery jako serwera pomiarowego i jednostki steruj¹cej, a nie tylko jako urz¹dzenia do rejestracji obrazu. Do wymiany danych pomiêdzy kamer¹ a sensorem jest u ywany port szeregowy. Skorzystano tutaj ze stosunkowo du ych, w zakresie przetwarzania pomiarów, zasobów sprzêtowych nowoczesnej kamery. Dziêki temu, jak równie dziêki integracji na bazie protoko³u IP, koszty przesy³ania danych do serwera mog¹ byæ niskie, szczególnie przy przetwarzaniu du ego wolumenu danych. Kolejnym atutem rozwi¹zania jest integracja transmisji obrazu i informacji z czujników za pomoc¹ jednego urz¹dzenia kamery IP, która umo liwia transmisjê sieciow¹. Dziêki temu rozwi¹zano problemy architektury z serwerem typu HTTP-COM. Wszystkie dane przesy- ³ane s¹ z u yciem jednego zestawu przewodów (przeznaczonych pierwotnie do transmisji samego obrazu). Nie ma tak e koniecznoœci stosowania dodatkowego urz¹dzenia do samej transmisji. 5. TERMINAL POMIAROWY W trakcie prac zbudowano terminal RS-485, który ma za zadanie zbieraæ wyniki pomiarów, przetworzyæ je i wys³aæ do kamery za pomoc¹ interfejsu RS-485 w trybie half-duplex. Dodatkowymi celami by³y tak e: uniwersalnoœæ urz¹dzenia i niskie koszty wytworzenia. Osi¹gniêto je poprzez u ycie mikrokontrolera z rodziny AVR (rys. 5 i 6). Rys. 4. Proponowana architektura czujników Rys. 5. Schemat blokowy zaproponowanego terminala Rys. 6. Zdjêcie zaproponowanego terminala Zastosowane urz¹dzenie posiada potrzebne poduk³ady s³u ¹ce do akwizycji danych z czujników. Mo e komunikowaæ siê z nimi za pomoc¹ najbardziej popularnych protoko³ów szeregowych: UART, SPI, I2C i 1WIRE. 62

5 Standardy te ró ni¹ siê liczb¹ linii u ytych do transmisji i sposobem komunikacji. Producenci czujników u ywaj¹ ich wszystkich w ró nych konfiguracjach, zatem uniwersalny terminal równie oferuje wsparcie w tym zakresie. Do dyspozycji s¹ tak e cztery kana³y przetwornika analogowo-cyfrowego dla sensorów z wyjœciem napiêciowym lub zmienn¹ rezystancj¹. Do integracji kamery i terminala u yto protoko³u RS-485. Dziêki temu mo na mierzyæ wartoœci z czujników znajduj¹cych siê zarówno przy samej kamerze, jak i oddalonych od niej nawet o 100 metrów. Urz¹dzenie posiada tak e port RS-232 dla wspó³pracy z pozosta³ymi rodzajami kamer. Terminal mo e byæ indywidualnie dostosowywany do ka dego zastosowania dziêki u yciu programowalnego kontrolera. Jêzykiem programowania jest w tym przypadku ANSI C. Zalet¹ terminala jest tak e elastycznoœæ jego budowy. Dostêpne wejœcia mog¹ byæ u yte do sterowania urz¹dzeniami sygnalizuj¹cymi lub do zbierania informacji z prze³¹czników lub klawiatur. Dodatkowo, mo na tak- e sterowaæ zewnêtrznymi uk³adami, np. klimatyzacji lub ogrzewania. Proponowane rozwi¹zanie ca³oœciowe (rys. 4) jest ekonomiczne z uwagi na u ycie istniej¹cych kamer do przesy³ania danych do serwera. Relatywnie drogie urz¹dzenia komunikacyjne s¹ najwiêksz¹ bol¹czk¹ w stosowaniu poprzednich architektur. Natomiast g³ówn¹ niedogodnoœci¹ terminala jest koniecznoœæ zmiany programu mikrokontrolera w ka dej nowej implementacji, poniewa niemo liwe jest automatyczne wykrycie podpiêtych sensorów, gdy czujniki analogowe zmieniaj¹ tylko wartoœæ napiêcia wyjœciowego i nie wysy³aj¹ swoich identyfikatorów. Nie wydaje siê to jednak powa nym problemem w sytuacji, gdy przed uruchomieniem znane s¹ wymagania projektowe i mo liwe jest dostosowanie urz¹dzenia do aktualnych potrzeb. 6. TESTY SYSTEMU W ramach prac przetestowano akwizycjê, konwersjê i wysy³anie przyk³adowych danych pomiarowych (atmosferycznych) przez terminal RS-485. Pomiar warunków otoczenia zosta³ wykonany przy pomocy nastêpuj¹cych czujników: cyfrowy termometr protoko³u 1WIRE, analogowy barometr zmieniaj¹cy napiêcie liniowo wraz ze zmian¹ ciœnienia, analogowy czujnik wilgotnoœci z wyjœciem napiêciowym, analogowy czujnik obecnoœci niebezpiecznych gazów z wyjœciem rezystancyjnym. W celu wizualizacji wyników pomiarów zosta³a opracowana aplikacja w œrodowisku LabView (widok panelu operatora systemu przedstawiono na rys. 7). Widoczne s¹ dwa wykresy prezentuj¹ce mierzone wartoœci. Pierwszy zawiera informacjê na temat temperatury oraz niebezpiecznych gazów, natomiast drugi przedstawia zmiany ciœnienia i wilgotnoœci w czasie. Prezentowane s¹ tak e chwilowe wartoœci wymienionych wielkoœci fizycznych. Dodatkowo, dla temperatury i gazów, zamieszczone s¹ kontrolki ostrzegawcze w kolorach ó³tym i czerwonym, które zapalaj¹ siê przy przekroczeniu okreœlonych wartoœci. Rys. 7. Panel operatora systemu 63

6 Aplikacja ma za zadanie: po³¹czyæ siê z urz¹dzeniem o podanym adresie przy u yciu protoko³u HTTP, za ¹daæ pobrania danych z czujników, odebraæ i zdekodowaæ przesy³ane informacje, przedstawiæ wyniki w jasny i czytelny sposób. Za pomoc¹ systemu pomiarowego zmierzono odpowiedzi czujników na ró norodne pobudzenia. Przyk³adowo rysunek 8 przedstawia pobudzenie cyfrowego termometru przez nag³e podgrzanie go do wysokiej temperatury. Czujnik posiada bezw³adnoœæ ciepln¹ wynikaj¹c¹ z rozgrzania obudowy. Powrót do stanu pocz¹tkowego nast¹pi³ po oko³o 2 minutach. W trakcie testów nie zauwa ono wp³ywu przeprowadzanych pomiarów na jakoœæ i p³ynnoœæ wyœwietlanego obrazu. Zadowalaj¹ce wyniki otrzymano przy aktualizacji danych nawet co 2 sekundy poni ej tego czasu pojawia³y siê opóÿnienia wynikaj¹ce ze zbierania próbek przez terminal pomiarowy oraz ograniczenia prêdkoœci przesy³ania danych w interfejsie szeregowym. Wynik ten jest wystarczaj¹cy dla systemu o charakterze informacyjnym. W przypadku zastosowania uk³adu w systemach sterowania nale y rozwin¹æ go pod k¹tem szybszej pracy oraz niezawodnej transmisji. W fazie testów wykryto oraz poprawiono b³êdne dzia³anie mikrokontrolera steruj¹cego terminalem, poprzez odpowiednie dobranie czasu zegara uk³adu nadzoru (Watchdog), dziêki czemu mo liwa sta³a siê praca systemu w sposób ci¹g³y z mo liwoœci¹ rejestracji wyników z okresu nawet wielu godzin. Zaproponowany system posiada zalety techniczne w stosunku do aplikacji, w których zachodzi potrzeba opracowania dedykowanego protoko³u komunikacyjnego, i jest od nich bardziej ekonomiczny. 7. PODSUMOWANIE Rys. 8. Nag³e podgrzanie termometru Rys. 9. Za³¹czanie czujnika gazów Innym zbadanym scenariuszem by³o pod³¹czanie czujnika gazów, który wymaga odczekania pewnego czasu po za³¹czeniu zasilania do uzyskania pe³nej funkcjonalnoœci. Pomiar tego parametru przedstawia rysunek 9. Mierzona wartoœæ roœnie od zera (bardzo du a rezystancja pocz¹tkowa) przez przek³amanie pomiaru w górê (intensywne ogrzewanie czujnika przez wbudowan¹ grza³kê) do poprawnego wyniku (stabilizacja pracy). Czas osi¹gniêcia rzeczywistych wartoœci wyniós³ 1 minutê. Przedstawione w artykule prace by³y ukierunkowane na integracjê czujników u ywanych w systemach monitoringu. Niedogodnoœci istniej¹cych architektur w tym zakresie zosta³y zidentyfikowane przez autorów jako czynnik utrudniaj¹cy wdro enia systemów wizyjno-pomiarowych na szerok¹ skalê. Dlatego te w pracy zaproponowano usprawnion¹ architekturê pomiarow¹, w której zaawansowane kamery sieciowe s¹ integrowane z szerok¹ gam¹ sensorów. Dla zapewnienia tak okreœlonej funkcjonalnoœci zbudowano terminal s³u ¹cy do pomiarów wielkoœci fizycznych oraz przygotowano oprogramowanie systemu. W przysz³ych pracach rozwiniêta zostanie aplikacja serwera, co pozwoli na wsparcie procesu decyzyjnego i pracy operatora systemu. Rozwiniêcia wymaga te protokó³ transmisyjny w celu zapewnienia szybkoœci i niezawodnoœci wymiany danych. Kamery sieciowe s¹ na ogó³ dro sze ni ich analogowe odpowiedniki, ale oferuj¹ wiêcej mo liwoœci. Wykazano, e oprócz wysokiej jakoœci oraz megapikselowej rozdzielczoœci obrazu urz¹dzenia te mog¹ pracowaæ jako lokalne wêz³y przetwarzaj¹ce, niezale ne serwery pomiarów, jednostki kontroluj¹ce oraz urz¹dzenia I/O. Proponowane rozwi¹zanie pozwala na optymalne u ycie dostêpnych zasobów sprzêtowych i sieciowych oraz umo liwia dalsze rozszerzenia istniej¹cych instalacji. 64

7 Praca wspó³finansowana przez Europejski Fundusz Rozwoju Regionalnego w ramach projektu INSIGMA nr POIG /09. Literatura [1] Axis Communications AB: Product Interface Guide. 2006, URL: [2] Microchip Technology Inc.: Connectivity Solutions for Embedded Design: USB, Ethernet, Wi-Fi, ZigBee, MiWi, CAN, LIN, IrDA and S-485 Protocols. 2010, URL: [3] Vivotek Inc.: IP Surveillance Handbook. Tajwan, 2009, URL: [4] Takeo Kanade, Robert Collins, Alan Lipton, Peter Burt, Lambert Wixson: Advances in Cooperative Multi-Sensor Video Surveillance. DARPA Image Understanding Workshop, Monterey, USA, 1998 [5] Axis Communications AB: Technical Guide to Network Video. Lund, Szwecja, 2009, URL: [6] Axis Communications AB: Vapix version 3, HTTP API. 2006, URL: [7] Axis Communications AB: Axis ETRAX 100LX Designer s Reference. Lund, Szwecja, 2006, URL: [8] Axis Communications AB: Axis Network Cameras and Video Servers. Lund, Szwecja, 2007, URL: