Przetargi.pl
Dostawa urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem dla monitoringu miejskiego w ramach zadania:- MONITORING MIASTA - ETAP III-

Gmina Sosnowiec - miasto posiadające prawa powiatu - reprezentowana przez Prezydenta Miasta ogłasza przetarg

  • Adres: 41-200 Sosnowiec, al. Zwycięstwa 20
  • Województwo: śląskie
  • Telefon/fax: tel. 32 2960600 , fax. 32 296 06 05
  • Data zamieszczenia: 2011-03-28
  • Zamieszczanie ogłoszenia: obowiązkowe

Sekcja I - Zamawiający

  • I.1. Nazwa i adres: Gmina Sosnowiec - miasto posiadające prawa powiatu - reprezentowana przez Prezydenta Miasta
    al. Zwycięstwa 20 20
    41-200 Sosnowiec, woj. śląskie
    tel. 32 2960600, fax. 32 296 06 05
    REGON: 27625548200000
  • Adres strony internetowej zamawiającego: www.um.sosnowiec.pl
  • I.2. Rodzaj zamawiającego: Administracja samorządowa

Sekcja II - Przedmiot zamówienia, przetargu

  • II.1. Określenie przedmiotu zamówienia
  • II.1.1. Nazwa nadana zamówieniu przez zamawiającego:
    Dostawa urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem dla monitoringu miejskiego w ramach zadania:- MONITORING MIASTA - ETAP III-
  • II.1.2. Rodzaj zamówienia: dostawy
  • II.1.3. Określenie przedmiotu oraz wielkości lub zakresu zamówienia:
    Przedmiotem zamówienia jest dostawa wraz z rozmieszczeniem i zainstalowaniem niżej wyszczególnionych urządzeń i oprogramowania dla monitoringu miejskiego: - 15szt kamer szybkoobrotowych, - 2szt komputer użytkownika (client) z czterema wyjściami video (jeden komputer do obsługi ściany video i jeden do korzystania z Systemu Zarządzania Video), -1 x powierzchnia magazynowania o pojemności 20 TB w tzw. konfiguracji Raid 6E (szafa ), - 4szt monitor 32 cal w rozdzielczości nie mniejszej niż1920 x 1080, - 3szt monitor 20cal w rozdzielczości nie mniejszej niż 1920 x 1080 - 1szt 19 cal szafa z chłodzeniem, - oprogramowanie do Zarządzania System Video, - ok. 150 mb okablowania. Dodatkowo wyposażenie pomieszczenia nadzoru (stół o długości 2,5mb z regulowaną wysokością blatu ,krzesła obrotowe 5 szt). Ponadto w ramach zamówienia przewiduje się przeprowadzenie przez wykonawcę 2 szkoleń dotyczących użytkowania zmodernizowanego systemu oraz wykonanie 5 raportów okresowych wraz z analizą i wnioskami , w tym 4 raporty kwartalne oraz jeden roczny. Uszczegółowienie wymagań wyposażenia sprzętowego i oprogramowania : 1. Kamery video 1.1 Informacje ogólne 1.1.1 Kamery powinny być zaprojektowane w celu dostarczania co najmniej trzech niezależnie skonfigurowanych, jednoczesnych sygnałów video z poklatkowością wynoszącą 30 klatek na sekundę (w systemie NTSC) lub 25 klatek na sekundę (w systemie PAL) we wszystkich rozdzielczościach aż do 704x480 pikseli (w systemie NTSC) lub 704x576 pikseli (w systemie PAL), w kompresji JPEG i H.264 oraz powinny obsługiwać łącznie 20 jednoczesnych sygnałów w transmisji unicast. 1.1.2 Kamery szybkoobrotowe dzień-noc, wyposażone przynajmniej w 35-krotny zoom optyczny i 12-krotny zoom cyfrowy. 1.1.3 Kamery powinny operować w trybie tzw. otwartego źródła być kompatybilne z platformą opartą o system Linux, uwzględniając wbudowany web server. 1.1.4 Powinny być wyposażone w wyjścia dla kart pamięci SD-SDHC. 1.1.5 Powinny mieć obudowę metalową oraz funkcjonować w temperaturze do minus 40 st .C. 1.1.6 Powinny wykorzystywać oddzielny zasilacz pozwalający kamerze na zasilenie funkcji ogrzewania i wiatraka poprzez kabel sieciowy. 1.2 Hardware 1.2.1 Kamery powinny używać wysokiej jakości sensor CCD o wartości 1 przez 4 cal lub lepszej. 1.2.2 Powinny być wyposażone w automatycznie i ręcznie wymieniany filtr IR, umożliwiający funkcjonalność dzień-noc. 1.2.3 Obiektyw na poziomie F1.4 - F4.2 DC-iris, wyposażony w 35-krotny zoom optyczny, umożliwiający widoczność w kącie poziomym pomiędzy 55.8st i 1.73st. 1.2.4 Powinny umożliwiać obserwację na poziomie poniżej 0.5 lux przy czułości F1.4 w trybie dziennym (uwzględniając filtr IR) oraz poniżej 0.008 lux w trybie nocnym (bez filtra IR). 1.2.5 Kamery szybkoobrotowe z tzw. -niekończącym się- zasięgiem 360st w poziomym obrocie (ang. pan) oraz z zasięgiem 220st w przechyle (ang. tilt). 1.2.6 Prędkość funkcji pan i tilt powinna zawierać się w zakresie pomiędzy 0.05st - 450st na sekundę. 1.3 Rozdzielczość 1.3.1 Kamera powinna dostarczać przynajmniej trzy indywidualnie skonfigurowane strumienie video, w pełnej rozdzielczości i poklatkowości poprzez sieć IP. 1.3.2 Obsługiwane rozdzielczości video powinny zawierać następujące wartości pikseli: A. 176x120 (NTSC) przez 176x144 (PAL) B. 352x240 (NTSC) przez 352x288 (PAL) C. 704x480 (NTSC) przez 704x576 (PAL) 1.4 Kodowanie 1.4.1 Kodowanie Motion JPEG w wybranym zakresie od 1 do 30 klatek na sekundę (NTSC) lub od 1 do 25 klatek na sekundę (PAL) w każdej rozdzielczości. 1.4.2 Obsługa kodeku H.264 w wybranym zakresie od 1 do 30 klatek na sekundę (NTSC) lub od 1 do 25 klatek na sekundę (PAL) w każdej rozdzielczości. 1.4.3 Należy udostępnić niezależnie skonfigurowane i równoczesne strumienie H.264 i Motion JPEG. 1.4.4 Obsługa zarówno tzw. Constant Bit Rate (CBR), jak i Variable Bit Rate (VBR) przez kodek H.264. 1.4.5 Udostępnić konfigurowalne poziomy kompresji. 1.4.6 Obsługa tzw. obliczeń ruchu (Motion estimation) poprzez kodek H.264. 1.5 Kontrola obrazów 1.5.1 Kamera powinna zawierać automatyczny i ręczny balans bieli oraz elektroniczną migawkę działającą w zakresie 0.5 - jednej trzydziestotysięcznej sekundy (NTSC) oraz 1.5 - jednej trzydziestotysięcznej sekundy (PAL). 1.5.2 Kamera powinna udostępniać funkcje szerokiego obrazu, elektronicznej stabilizacji obrazu oraz kompensacji tylnego światła z automatycznymi i definiowalnymi strefami ekspozycji. 1.6 Dalsza wymagalna funkcjonalność 1.6.1 Udostępnienie przynajmniej 100 tzw. presetów. 1.6.2 Udostępnienie funkcji automatycznej, elektronicznej rotacji obrazu o 180st. podczas śledzenia poruszającego się obiektu, który przemieszcza się pod kamerą mijając ją. 1.6.3 Udostępnienie funkcji -obchód strażnika-, która umożliwia kamerze automatyczny ruch pomiędzy wybranymi presetami, używając indywidualnej prędkości oraz indywidualnego czasu wyświetlania każdego presetu. 1.6.4 Kamera musi mieć możliwość detekcji oraz automatycznego śledzenia obiektów w polu widzenia danej kamery. 1.7 Funkcjonalność dotycząca zdarzeń (tj. incydentów na obszarze nadzorowanym oraz wewnątrz samego systemu) 1.7.1 Kamery powinny być wyposażone w zintegrowaną funkcjonalność dotyczącą zdarzeń, która może być uruchamiana przez następujące funkcje: A. detekcję ruchu video B. automatyczne śledzenie C. pozycje pan i tilt D. harmonogram działań E. zapełnienie lokalnej przestrzeni magazynowania F. awaria wiatraka 1.8 Obsługa protokołu 1.8.1 Kamery powinny zawierać obsługę przynajmniej następujących protokołów (łącznie): IP, HTTP, HTTPS, SSL przez TLS, TCP, ICMP, SNMPv1przez v2c przezv3 (MIB-II), RTSP, RTP, UDP, IGMP, RTCP, SMTP, FTP, DHCP, UPnP, ARP, DNS, DynDNS, SOCKS, NTP i Bonjour. 1.8.2 Implementacja protokołu SMTP powinna zawierać obsługę uwierzytelnienia dla SMPT. 1.9 Nakładki tekstowe 1.9.1 Udostępnić tekst osadzony na ekranie, zawierający datę i czas, specjalny tekst klienta, nazwę kamery. Tekst musi mieć objętość przynajmniej 45 znaków zgodnie z kodem ASCII. 1.9.2 W celu zapewnienia precyzji, kamery powinny akceptować zewnętrzną synchronizację czasu z tzw. serwera NPT (Network Time Protocol). 1.9.3 Udostępnić 8 indywidualnie konfigurowalnych, tzw. prywatnych masek obszarów, uznanych za takie, których nie będzie można wyświetlać. Maski te będą dynamicznie dostosowywane w oparciu o bieżący czynnik zoom i nie będzie można ich obejść. 1.10 Interfejs sieciowy 1.10.1 Kamery powinny być wyposażone w jeden szybki port Ethernet (100BASE-TX), używający standardowego gniazda RJ-45, obsługujący zmianę prędkości sieci (100 MBitprzez s i 10 MBit przez s) oraz tryb transferu (tzw. full i half duplex). 1.11 Obudowa 1.11.1Obudowa kamer powinna spełniać co najmniej następujące parametry: 1.11.1.1 Wyprodukowana z metalu 1.11.1.2 Przezroczysta pokrywa 1.11.1.3 Klasyfikacja IP66 1.11.1.4 Klasyfikacja NEMA 4X 1.11.1.5 Cztery czujniki temperatury, dwie grzałki oraz dwa wiatraki wewnątrz obudowy 1.11.1.6 Zdejmowana osłona przeciwsłoneczna 1.12 Wymagania dotyczące zasilania 1.12.1 100-240 VAC przez 50-60 Hz, max 60 W - udostępnione do kamery poprzez kabel sieciowy za pomocą oddzielnego iniektora, dostarczone razem z kamerą. 1.13 Czynniki środowiskowe 1.13.1Operacyjność kamer w zakresie temperatur: -40stC do +50stC (-40stF to +122stF). 1.13.2 Operacyjność kamer w zakresie wilgotności: 20-80% (bez kondensacji). 2. System Zarządzania Video (SZV) - wymagania ogólne SZV powinien być skalowalnym przedsięwzięciem opartym o zaawansowane oprogramowanie komputerowe. SZV ma oferować kompletne rozwiązanie w obszarze nadzoru video, które będzie skalowalne od jednej do dziesiątków tysięcy kamer. Zgodnie z założeniem kolejne kamery obsługiwane przez oprogramowanie będzie można dodać na zasadzie -jedna po drugiej-. SZV powinno zawierać co najmniej następujące aplikacje: 2.1 Moduły Oprogramowania Serwera 2.1.1 Informator przez Katalog (Serwer Systemowy) 2.1.2 Bramka (ang. Gateway) 2.1.3 tzw. Federation Server 2.1.4 Archiwum 2.1.5 Silnik Metadaty 2.1.6 Silnik Standby Metadaty 2.1.7 Wirtualna matryca 2.1.8 tzw. Watchdog 2.1.9 Administrator Serwera 2.2 Aplikacje Użytkownika Oprogramowania 2.2.1 Narzędzia konfiguracyjne 2.2.2 Przekaz na żywo 2.2.3 Odtwarzanie nagrań 2.2.4 Web Live Viewer 2.2.5 Web Archive Player 2.2.6 Edytor Makr 2.2.7 Prezentacja raportów 2.3 IP Video 2.3.1 Wszystkie strumienie video dostarczane z kamer analogowych lub kamer IP powinny być cyfrowo zakodowane w formacie kompresji MPEG-4, MPEG-2, MJPEG, H.264, Wavelet lub JPEG2000 oraz jednocześnie nagrane -zapisane w czasie rzeczywistym. 2.3.2 SZV powinno komunikować się z zakodowanymi sygnałami analogowymi (zakodowany sygnał analogowy do sygnału cyfrowego) oraz z kamerami IP, co dalej jest zwane cyfrowym serwerem video. SZV powinno obsługiwać cyfrowe serwery video różnych producentów. SZV powinno obsługiwać serwery video IP następujących producentów (łącznie): 2.3.2.1 ACTi serwery video 2.3.2.2 American Dynamics serwery video 2.3.2.3 Arecont Vision serwery video 2.3.2.4 AutoVu serwery video 2.3.2.5 Axis serwery video 2.3.2.6 Basler serwery video 2.3.2.7 Bosch przez VCS serwery video 2.3.2.8 Canon serwery video 2.3.2.9 CBC Ganz serwery video 2.3.2.10 DigiSensory serwery video 2.3.2.11 Dynacolor serwery video 2.3.2.12 Econolite Autoscope serwery video 2.3.2.13 GE serwery video 2.3.2.14 GSG International serwery video 2.3.2.15 HIKVISION serwery video 2.3.2.16 Impath Networks serwery video 2.3.2.17 ioimage serwery video 2.3.2.18 IONODES serwery video 2.3.2.19 IQinVision serwery video 2.3.2.20 JVC serwery video 2.3.2.21 Lumenera serwery video 2.3.2.22 Mango DSP serwery video 2.3.2.23 March Networks serwery video 2.3.2.24 Mobotix serwery video 2.3.2.25 Optelecom-NKF serwery video 2.3.2.26 OTN serwery video 2.3.2.27 Panasonic serwery video 2.3.2.28 Pelco serwery video 2.3.2.29 Phoenix IVS serwery video 2.3.2.30 Samsung serwery video 2.3.2.31 Sightlogix serwery video 2.3.2.32 Sony serwery video 2.3.2.33 Stardot serwery video 2.3.2.34 Teleste serwery video 2.3.2.35 Toshiba serwery video 2.3.2.36 UDP serwery video 2.3.2.37 Verint serwery video 2.3.2.38 VideoIQ serwery video 2.3.2.39 Vivotek serwery video 2.4 Niezależność sprzętu 2.4.1 Liczba bitów, klatek oraz rozdzielczość każdej kamery będzie ustawiona niezależnie od innych kamer w systemie, a zmiana tych ustawień nie będzie miała wpływu na nagrywanie oraz ustawienia obrazu innych kamer. 2.4.2 Dla nagrywania sygnałów video i dźwięku oraz dla monitorowania SZV nie wymaga własnego sprzętu do nagrywania, ani sprzętu typu multiplekser. 2.4.3 SZV powinien być oparty na całkowicie otwartej architekturze, która powinna uwzględniać stopniowe usprawnienia powierzchni do nagrywania. 2.4.4 SZV powinno umożliwiać używanie wielu klawiatur przez kontrolerów do sterowania wszystkimi kamerami (tzw. cctv keyboards), włączając w to kamery różnych producentów oraz ich funkcjonalność pan i tilt, np. keyboard firmy A umożliwia kontrolę kamery obrotowej marki B i na odwrót). 2.5 Archiwum - oprogramowanie do nagrywania strumienia video na serwerze 2.5.1 Archiwum powinno używać bazy danych zdarzeń i znaczników czasu dla zaawansowanego wyszukiwania nagrań video i dźwiękowych. Ta baza danych powinna być zbudowana w oparciu o Microsoft SQL 2005, Microsoft SQL 2008 lub Microsoft SQL 2000 Enterprise server z dodatkiem Service Pack 4. 2.5.2 Archiwum powinno chronić zarchiwizowane pliki zawierające nagrania video i dźwięku oraz systemową bazę danych przeciw dostępowi sieciowemu oraz dostępowi użytkownika, niebędącego administratorem. 2.5.3 Archiwum powinno cyfrowo oznaczać zarejestrowane nagrania video używając kryptografię klucza publicznego/prywatnego o wartości 248 bitów. 2.5.4 Archiwum powinno oferować dodatkowe funkcjonalności: 2.5.4.1Automatyczne wykrywanie cyfrowych serwerów video, które zostaną podłączone do sieci. 2.5.4.2Wykrywanie jednostek cyfrowych serwerów video w innych segmentach sieci, uwzględniając Internet oraz poprzez routery zawierające lub nie zawierające zdolności tłumaczenia adresów sieciowych. 2.5.4.3Archiwum powinno udostępniać opcje nagrywania przed alarmem i po alarmie, które mogą być ustawiane pomiędzy jedną sekundą a pięcioma minutami w zależności od wybranej kamery. 2.6 Tzw. Federation Server 2.6.1 Tzw. Federation Server powinien być mostem, który łączy razem wiele niezależnych systemów SZV w jeden wielki system, zwany Federacją. SZV zakładający Federację zwany jest Gospodarzem Federacji. 2.6.2 Tzw. Federation Server powinien umożliwiać użytkownikom Gospodarza Federacji jednoczesne wyświetlenie kamer należących do innych członków Federacji (niezależne systemy SZV), jak gdyby należały one do jednego SZV. 2.6.3 Tzw. Federation Server powinien móc łączyć systemy SZV, które posiadają różne wersje oprogramowania. 2.6.4 Tzw. Federation Server powinien umożliwiać wyświetlanie nagrań na żywo oraz nagrań zarchiwizowanych z innych systemów SZV w ramach Federacji. 2.6.5 Tzw. Federation Server powinien umożliwiać Gospodarzowi Federacji otrzymywanie zdarzeń wygenerowanych przez cyfrowe serwery video, których posiadaczami są członkowie Federacji. 3. System Zarządzania Video (SZV) - wymagania szczegółowe 3.1 System powinien umożliwiać generowanie automatycznego przeglądu poleceń wydawanych przez obserwatorów. Te polecenia powinny być generowane w oparciu o poszczególne profile konkretnych obserwatorów, o wybrane pola obserwacji z przypisanym ryzykiem występowania incydentów oraz o zachowanie obserwatorów podczas prowadzenia nadzoru wizyjnego. Dzięki temu ma nastąpić zapobieganie pomijania miejsc obserwacji z niższym ryzykiem występowania zdarzeń. Przegląd poleceń ma zawierać informacje na temat poszczególnych lokalizacji nadzorowanych oraz o natężeniu występowania poszczególnych zdarzeń. 3.2 Profile ryzyka powinny być wygenerowane w oparciu o incydenty zapisane w przeszłości oraz o ryzyka wprowadzone do systemu ręcznie, skategoryzowane i nazwane. 3.3 Obserwatorzy powinni mieć monitor poglądowy, na którym będą prezentowane przeglądy poleceń. 3.4 Obserwatorzy oraz ich przełożeni powinni mieć możliwość otrzymywania automatycznie generowanych raportów na temat wykonanych poleceń. Raporty te mają wskazywać czy polecenia zostały wykonane. Informacje takie mają być ponadto używane dla przygotowania tzw. okresowych raportów wydajności oraz powinna być możliwość zaprezentowania ich na żywo w pomieszczeniu nadzoru. 3.5 Użytkownicy powinni mieć możliwość łatwego wyboru (za pomocą kliknięcia myszką) określonej uprzednio listy zdefiniowanych incydentów. Taka lista ma być zorganizowana na zasadzie (struktury drzewa), z zachowaną spójną hierarchią poszczególnych incydentów, od incydentu najbardziej ogólnego do incydentu najbardziej szczegółowego w ramach jednej kategorii incydentu. Administrator systemu ma posiadać możliwość utworzenia takiej listy. Takie same wyliczenia dotyczące podjętych reakcji w odpowiedzi na incydenty powinny być udostępnione administratorowi do zarządzania, w tym do obróbki statystycznej. 3.6 Podczas obsługiwania incydentów użytkownik (np. obserwator) powinien mieć możliwość dodania zdjęć lub nagrań video z określonym limitem czasowym, w ramach jednego, ciągłego i kompletnego procesu obsługi danego incydentu. Następnie użytkownik powinien mieć możliwość generowania dodatkowych zdjęć z nagranego materiału video oraz mieć możliwość dodania tych zdjęć do raportu na temat incydentu. Dlatego, w celu generowania tych dodatkowych zdjęć, materiał video powinien być prezentowany klatka po klatce w dedykowanym panelu. 3.7 Administrator powinien mieć możliwość przyporządkowania poszczególnym kodom incydentów tzw. pliki następujące, które będą automatycznie prezentowane w momencie, gdy incydent o określonym kodzie zostanie wychwycony. System powinien umożliwiać użytkownikom kreowania standardowych procedur postępowania dla tych celów. 3.8 System powinien mieć możliwość generowania makr. Za pomocą makr zaprogramowane będą następujące funkcje: 3.8.1 Automatyczne obiegi na wszystkich monitorach. 3.8.2 Wykonywanie zdjęć i nagrań video. 3.8.3 Kreowanie określonych nagrań incydentów, uwzględniając automatyczne dodawanie zdjęć i nagrań video z wybranych momentów. 3.8.4 Aktywowanie wybranych monitorów jako monitorów zarządzających. 3.8.5 Programowanie i wykonywanie presetów. 3.8.6 Wzywanie makra z innym makrem. 3.9 Dla administratorów - te same makra powinny być gotowe do użycia z różnych stacji/miejsc roboczych w tym samym czasie. 3.10 Użytkownik powinien mieć możliwość wgrywania nazw ulic obserwowanego terytorium. Na cyfrowej mapie system ma pokazywać najbliższą kamerę. Klikając na ikonę kamery na mapie ma nastąpić bezpośrednie połączenie z tą kamerą i wyświetlenie jej na osobistym monitorze użytkownika. 3.11 Wewnątrz systemu obserwator powinien mieć dostęp do tzw. dynamicznej mapy obszaru nadzorowanego, którą będzie można przybliżać i oddalać. Przy wyborze kamery automatycznie powinna zostać zaprezentowana określona część mapy (tam, gdzie kamera jest zainstalowana). Mapa powinna umożliwiać dołączenie do planów wybranych części miasta planów wewnętrznych budynków. 3.12 Ma być udostępniona możliwość wyświetlania kamer zarówno na ścianie video, jak i na osobistym monitorze użytkownika (np. na biurku). 3.13 Użytkownicy mają mieć dostęp do następujących informacji: 3.13.1Numery kamer na mapie, które są przełączone na monitorze osobistym. 3.13.2Numery kamer, które są wyświetlane na ścianie video. 3.13.3Numery kamer, które są wyświetlane na monitorach osób trzecich. Taka informacja powinna być niezależna od operatora, który rozpoczął dany proces przełączania kamer podczas swojej zmiany pracy. W ten sposób powinny być dostępne szczegółowe raporty na temat wyświetleń poszczególnych kamer na konkretne monitory podczas określonych zmian pracy. 3.14 Powinna być udostępniona funkcja, w myśl której możliwa będzie zmiana prezentowanych nagrań na żądanych monitorach, które są połączone z monitorem osobistym konkretnego użytkownika. W ten sposób przełożony obserwatora ma mieć wgląd w aktualny sposób prowadzenia nadzoru przez obserwatora, pozostając przy tym także w innym pomieszczeniu niż centrum nadzoru. Zmiana wyświetlanych obrazów na monitorze osobistym obserwatora ma być także połączona ze zmianą wyświetleń na ścianie video, zgodnie z zaprogramowanym ustawieniem. 3.15 Powinno być umożliwione generowanie raportów na temat zarejestrowanych incydentów. Reporty te mają z łatwością i czytelnie pokazywać lokalizację (z której kamery wygenerowano nagranie/zdjęcie), datę, czas, moment w tygodniu (pora dnia, np. piątek wieczór), przedsięwzięte działania następujące po rejestracji incydentu, kod użytkownika oraz kod incydentu. Tak wygenerowane raporty mają być filtrowane za pomocą: 3.15.1Użytkownika. 3.15.2Kodu incydentu. 3.15.3Kamery. 3.15.4Grupy kamer (lokalizacja). 3.15.5Daty i czasu. (Dzięki filtrom czas wyszukiwania konkretnego incydentu w archiwum ma zostać skrócony.) 3.16 Opisywane raporty mają zawierać następujące informacje: 3.16.110 topowych raportów (najważniejszych / najczęściej powtarzających się) 3.16.2Raport dzienny. 3.16.3Analizy trendów. 3.16.4Analizy ryzyka dla konkretnych obszarów. 3.16.5Raporty dotyczące sposobu wykonywania pracy przez obserwatorów, bazujące na częstotliwości zmieniania kamer oraz ilości rejestrowanych zdarzeń. 3.16.6Informacje na temat przeglądu poleceń podzielone na użytkowników oraz lokalizacje. 3.16.7Sposób użytkowania makr. 3.17 System powinien umożliwić wyświetlenie przeglądu powyższych informacji do zarządzania na oddzielnym monitorze z ciągłym odświeżaniem, bez ingerencji obserwatora. Ma być udostępniony wgląd w liczbę zarejestrowanych i obsłużonych incydentów, prognozy na przyszłość oraz liczby wszystkich poleceń wydanych w pomieszczeniu nadzoru. 4.Przechowywanie Poniższy opis przedstawia podstawowe funkcje niezbędne dla skalowalnej, elastycznej platformy nadzoru wizyjnego, która zawiera zarówno System Zarządzania Video (SZV), serwer oraz architekturę SAN (Storage Area Network). 4.1Wymagany serwer oraz funkcjonalność architektury SAN (Storage Area Network) 4.1.1 Platforma sprzętowa powinna mieć możliwość uruchamiania aplikacji do zarządzania video przy jednoczesnym udostępnianiu powierzchni magazynowania, przy dodatkowych założeniach: 4.1.1.1Oddzielne fizyczne serwery SZV nie są wymagane. 4.1.1.2Oddzielne fizyczne awaryjne serwery SZV nie są wymagane. 4.1.1.3Zasilanie i chłodzenie serwera i powierzchni magazynowania są załączone wewnątrz tzw. wspólnej platformy 2U. 4.1.1.4 Tzw. powierzchnia Rack zarówno dla serwera, jak i powierzchni magazynowania jest zawarta wewnątrz tzw. wspólnej platformy 2U. 4.1.1.5 Aplikacje SZV działające na każdej zintegrowanej platformie powinny mieć dostęp do łącznej powierzchni magazynowania na wszystkich platformach złączonych razem. 4.1.1.6 Aplikacje SZV działające na każdej zintegrowanej platformie powinny mieć dostęp do częstotliwości powierzchni magazynowania na wszystkich platformach złączonych razem. 4.1.2 Zintegrowany Serwer/platforma SAN powinna obsługiwać zautomatyzowany system zarządzania video. 4.1.3 Zintegrowany Serwer/platforma SAN powinna obsługiwać systemy operacyjne Serwera Microsoft Windows i Linux. 4.1.4 Platforma powinna obsługiwać Microsoft Storage Server 2003. 4.2 Podstawowa konfiguracja magazynowania 4.2.1 Magazynowanie powinno być adresowalne wzwyż do 128 zewnętrznych serwerów lub hostów. 4.2.2 Magazynowanie powinno być podłączone sposobem IP poprzez Gigabit Ethernet używając ogólnie dostępnych konfiguracji sieciowych i wyposażenia: 4.2.2.1Spełniać standardy iSCSI. 4.2.2.2Bazować na rozwiązaniu SATA dla zmniejszenia kosztów oraz obsługiwać 20TB. 4.2.2.3Posiadać certyfikaty UL i CE. 4.2.2.4Powinien być możliwy do zamontowania w standardowej szafie Rack 19cal. 4.3 Dostępność 4.3.1 System magazynowania powinien obsługiwać wysoką dostępność bez pojedynczych punktów awaryjnych powodujących utratę danych lub naruszających dostęp do danych. 4.3.1.1Ochrona danych do poziomu pięciu jednoczesnych awarii dysków bez starty danych lub dostępu do danych. 4.3.1.2Ochrona przed utratą ścieżki sieciowej pomiędzy serwerami i powierzchnią magazynowania, uwzględniając kartę interfejsu sieciowego, kable i switche oraz możliwość dynamicznej zmiany na alternatywną ścieżkę sieciową. 4.3.2 System magazynowania powinien obsługiwać dynamiczną wymianę komponentów sprzętowych bez przerywania dostępu do danych. Wymagania: 4.3.2.1Obsługa wymiany dysków bez przerywania dostępu do danych. 4.3.2.2Obsługa wymiany zasilaczy bez przerywania dostępu do danych. 4.3.2.3Możliwość wymiany wiatraków bez przerywania dostępu do danych. 4.3.2.4Możliwość wymiany całych urządzeń bez przerywania dostępu do danych. 4.3.2.5Możliwość wymiany switchy sieciowych bez przerywania dostępu do danych. 4.3.3 System magazynowania powinien obsługiwać dynamiczne zarządzanie funkcjami w celu zapewnienia ciągłego dostępu do danych. 4.3.3.1Możliwość rozszerzenia pojemności dysków poprzez dodanie kolejnych dysków bez przerywania dostępu do danych. 4.3.3.2Możliwość rozszerzania poprzez dodawanie częstotliwości sieciowych bez przerywania dostępu do danych. 4.3.3.3Możliwość dynamicznej zmiany opcji ochrony danych (poziom RAID) bez przerywania dostępu do danych, które zostały naruszone. 4.3.4 System magazynowania powinien udostępniać elastyczne, wybieralne opcje ochrony danych. 4.3.4.1Udostępnienie wzmocnionej ochrony danych (RAID 6) dla ochrony środowiska danych krytycznych. 4.3.4.2Udostępnienie wzmocnionej ochrony danych (RAID 5) dla ochrony wydajnego system magazynowania. 4.3.5 System magazynowania powinien umożliwiać dostęp do zaawansowanych metod odzyskiwania danych w celu zmaksymalizowania dostępności danych. Wymaganie: 4.3.5.1Dynamiczna ekonomika zarządzania powierzchnią w celu odbudowywania uszkodzonych dysków. 4.4 Skalowalność 4.4.1 System magazynowania powinien być skalowalny co do pojemności, obsługując pojedynczą wzrost rozmiaru aż do 288 TB. 4.4.1.1Pojemność powinna być dodawana do system na zasadzie przyrostów modularnych od 12 do 24 TB. 4.4.1.2Skalowalność pojemności nie może być uciążliwa, umożliwiając dynamiczne dodawanie kolejnej pojemności do systemu bez przerywania dostępu do danych. 4.4.1.3Fizyczna pojemność dodana do systemu powinna dać się konfigurować do nowych lub do istniejących wolumenów bez konieczności przerywania dostępu do danych. 4.4.2 System powinien umożliwiać skalowalność kontrolerów: 4.4.2.1Obsługa do 12 kontrolerów w trybie aktywnym. 4.4.2.2Obsługa do 54 GB pamięci kontrolerów (cache). 4.4.3 System magazynowania powinien obsługiwać przyszłe rozszerzenia pojemności o nowe technologie. 4.5 Zarządzanie 4.5.1 System powinien umożliwiać łatwe w użyciu graficzne możliwości zarządzania. 4.5.1.1System powinien samodzielnie wykrywać konfigurację sprzętową. 4.5.1.2System powinien udostępniać statystyki dotyczące wykorzystania powierzchni. 4.5.2 System powinien umożliwiać dynamiczną konfigurację wolumenów. 4.5.2.1System powinien udostępniać atrybuty wolumenów uwzględniając typ RAID oraz rozmiar wolumenu, który ma być zmieniony dynamiczne, bez przerywania dostępu do danych. 4.5.2.2System powinien umożliwiać ustalanie priorytetów pomiędzy migracją danych a dostępem do danych oraz umożliwiać dynamiczną zmianę tych priorytetów przed i podczas migracją danych. 4.5.3 System powinien udostępniać kontrolę zabezpieczeń administratora. 4.5.4 System powinien uwzględniać tzw. interfejs linii poleceń. 4.5.5 System powinien zawierać zaawansowane urządzenia utrzymania i zarządzania. 4.5.5.1System powinien rejestrować zmiany konfiguracji oraz wydarzenia systemowe. 4.5.5.2System powinien wykrywać awarie dysków oraz graficznie (poprzez graficzny interfejs użytkownika) i fizycznie (poprzez lampki) identyfikować dysk, który uległ awarii. 4.5.5.3System powinien umożliwiać opcję słyszalnego alarmu. 4.5.5.4System powinien wykrywać awarie kontrolerów oraz graficznie identyfikować uszkodzony kontroler. 4.5.5.5System powinien dokonywać przewidywań i oszacowań w zakresie awarii dysków w celu proaktywnego zarządzania dyskami. 4.5.6 System powinien uwzględniać tzw. wsparcie zarządzania SNMP. 5. Klienci (użytkownicy) - sprzęt komputerowy 5.1Intel Quad Core Xeon E5420 2.50 GHz. 5.2Pamięć: 4096MB (4x1024) 667MHz DDR2 Quad Channel 5.3Dysk twardy: 320GB Serial ATA II (7200 RPM) Hard Drive 5.4Dodatkowy dysk twardy: 320GB Serial ATA II (7200 RPM) Hard Drive 5.5C4 All SATA, RAID 1(Mirroring) dla 2 dysków twardych 5.6Optical Drive: PowerDVD 8.3 Software and Media incl. 5.7Optical Drive : 8X DVD+ przez -RW Drive 5.8Keyboard : US przez Euro (QWERTY) Dell Standard Quietkey USB Keyboard Black 5.9Windows XP ,Optical Drive : Roxio Creator 10.3 incl. software 5.10 AntiVirus : Trend Micro Internet Security 16.6(36-miesięczna sybskrypcja) AntiVirus Software 5.11 Karta Video Matrox M9148, punkt dostępowy RS 232 i drukarka z punktem dostępowym. 6.Pomieszczenie nadzoru 6.1Wizerunki dostępne na monitorach muszą być wyświetlane w sposób ergonomiczny z punktu widzenia odległości oczu obserwatora od monitorów (7 x przekątna monitora). 6.2Konieczne jest dostosowanie wysokości biurek i krzeseł. 6.3Konieczne jest uwzględnienie kolorystyki i natężenia światła w pomieszczeniu nadzoru. 6.4Należy przedstawić uproszczoną koncepcję aranżacji pomieszczenia nadzoru ze szczególnym uwzględnieniem ściany video. Zamawiający informuje, że po zainstalowaniu kamer oraz całego oprogramowania i usprzętowienia oczekuje uzyskanie wzmocnienia sygnału z kamer a w przypadku gdy sygnał ulegnie pogorszeniu wykonawca będzie zobowiązany do użycia wzmacniaczy sygnału lub wymiany wybranych odcinków kabli.
  • II.1.4. Wspólny Słownik Zamówień (CPV): 351253002
  • II.1.5. Czy dopuszcza się złożenie oferty częściowej: nie
  • II.1.6. Czy dopuszcza się złożenie oferty wariantowej: nie
  • II.1.7. Czy przewiduje się udzielenie zamówień uzupełniających: nie
  • II.2. Czas trwania zamówienia lub termin wykonania: 4 miesięcy

Sekcja III - Informacje o charakterze prawnym, ekonomicznym, finansowym i technicznym

  • III.1. Warunki dotyczące zamówienia
  • Informacja na temat wadium: Wykonawcy, których zamawiający zaprosi do składania ofert zobowiązani będą do wniesienia wadium w wysokości 14 400,00zł słownie: czternaście tysięcy czterysta złotych. Wadium należy wnieść przed upływem terminu składania ofert , który zostanie określony w specyfikacji istotnych warunków zamówienia przekazanej wykonawcom wraz z zaproszeniem do składania ofert

Sekcja IV - Procedura przetargowa

  • IV.1. Tryb udzielenia zamówienia
  • IV.1.1. Tryb udzielenia zamówienia: przetarg ograniczony
  • IV.2. Kryteria oceny ofert
  • IV.2.2. Wykorzystana będzie aukcja elektroniczna: nie
  • IV.3. Informacje administracyjne
  • IV.3.1. Adres strony internetowej, na której dostępna jest specyfikacja istotnych warunków zamówienia: Nie dotyczy
  • IV.3.5. Termin związania ofertą, okres w dniach: 30 (od ostatecznego terminu składania ofert)

Zobacz następny przetargZobacz poprzedni przetargPobierz ofertę w pliku pdfPowrót na stronę główną

Podobne ogłoszenia o przetargach