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


Numer ogłoszenia: 97553 - 2011; data zamieszczenia: 28.03.2011

OGŁOSZENIE O ZAMÓWIENIU - dostawy


Zamieszczanie ogłoszenia:
obowiązkowe.


Ogłoszenie dotyczy:
zamówienia publicznego.

SEKCJA I: ZAMAWIAJĄCY


I. 1) NAZWA I ADRES:
Gmina Sosnowiec - miasto posiadające prawa powiatu - reprezentowana przez Prezydenta Miasta , al. Zwycięstwa 20, 41-200 Sosnowiec, woj. śląskie, tel. 32 2960600, faks 32 296 06 05.


  • Adres strony internetowej zamawiającego:
    www.um.sosnowiec.pl


I. 2) RODZAJ ZAMAWIAJĄCEGO:
Administracja samorządowa.

SEKCJA II: PRZEDMIOT ZAMÓWIENIA


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) Czy przewiduje się udzielenie zamówień uzupełniających:
nie.


II.1.5) Wspólny Słownik Zamówień (CPV):
35.12.53.00-2, 32.33.31.00-7, 30.23.60.00-2, 51.61.20.00-5, 72.26.80.00-1.


II.1.6) Czy dopuszcza się złożenie oferty częściowej:
nie.


II.1.7) Czy dopuszcza się złożenie oferty wariantowej:
nie.



II.2) CZAS TRWANIA ZAMÓWIENIA LUB TERMIN WYKONANIA:
Okres w miesiącach: 4.

SEKCJA III: INFORMACJE O CHARAKTERZE PRAWNYM, EKONOMICZNYM, FINANSOWYM I TECHNICZNYM


III.1) WADIUM


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


III.2) ZALICZKI


  • Czy przewiduje się udzielenie zaliczek na poczet wykonania zamówienia:
    nie


III.3) WARUNKI UDZIAŁU W POSTĘPOWANIU ORAZ OPIS SPOSOBU DOKONYWANIA OCENY SPEŁNIANIA TYCH WARUNKÓW


  • III. 3.1) Uprawnienia do wykonywania określonej działalności lub czynności, jeżeli przepisy prawa nakładają obowiązek ich posiadania


    Opis sposobu dokonywania oceny spełniania tego warunku

    • Nie dotyczy


  • III.3.2) Wiedza i doświadczenie


    Opis sposobu dokonywania oceny spełniania tego warunku

    • Wiedza i doświadczenie wykonawców ocenione zostanie na podstawie złożonego wraz z wnioskiem wykazu wykonanych lub wykonywanych dostaw w okresie ostatnich trzech lat przed upływem terminu składania wniosków, a jeżeli okres prowadzenia działalności jest krótszy - w tym okresie, w zakresie niezbędnym do wykazania spełniania warunku wiedzy i doświadczenia z podaniem ich wartości, przedmiotu,dat wykonania i odbiorców oraz załączeniem dokumentów potwierdzających, że dostawy ujęte w wykazie zostały należycie wykonane. Za dostawy potwierdzające spełnianie warunku wiedzy i doświadczenia zamawiający uzna wykonanie co najmniej dwóch dostaw urządzeń i oprogramowania wraz z zainstalowaniem dla monitoringu, o wartości nie mniejszej niż 400 000,00 zł(słownie: czterysta tysięcy złotych 00/100) każda.


  • III.3.3) Potencjał techniczny


    Opis sposobu dokonywania oceny spełniania tego warunku

    • Nie dotyczy


  • III.3.4) Osoby zdolne do wykonania zamówienia


    Opis sposobu dokonywania oceny spełniania tego warunku

    • Dysponowanie przez wykonawcę osobami, które będą uczestniczyć w wykonaniu zamówienia - ocenione zostanie na podstawie złożonego wraz z wnioskiem wykazu osób, które będą uczestniczyć w wykonywaniu zamówienia wraz z pisemnym zobowiązaniem innych podmiotów do udostępnienia potencjału technicznego i osób zdolnych do wykonania zamówienia. 1.Zamawiający wymaga dysponowania: a) co najmniej jedną osobę specjalistą do spraw teleinformatyki, który posiada wyższe wykształcenie techniczne oraz 5 letnie doświadczenie w budowie sieci komputerowych oraz montażu oprogramowania dla monitoringu. b) co najmniej jedną osobą posiadającą potwierdzenie przygotowania do projektowania w specjalności telekomunikacyjnej bez ograniczeń, 2. oświadczenia, że osoby wskazane oraz ujęte w w/w wykazie posiadają wymagane uprawnienia budowlane w rozumieniu Rozporządzenia Ministra Transportu i Budownictwa z dnia 28 kwietnia 2006 r. w sprawie samodzielnych funkcji technicznych w budownictwie (Dz. U. z 2006 r., Nr 83, poz. 578, z późniejszymi zmianami) potwierdzone stosownymi decyzjami, o których mowa w art. 12 ust. 2 (z uwzględnieniem art. 104) ustawy z dnia 07 lipca 1994 r. Prawo budowlane (tekst jednolity Dz. U. z 2010 r., Nr 243, poz. 1623) lub odpowiadające wymaganym uprawnienia budowlane, które zostały wydane na podstawie wcześniej obowiązujących przepisów (zgodnie z zapisem art. 104 ustawy Prawo budowlane) i są wpisane na listę członków właściwej izby samorządu zawodowego, albo jako obywatele państw członkowskich posiadają wymagane uprawnienia do wykonywania zawodu na terytorium Rzeczypospolitej Polskiej; przez obywateli państw członkowskich należy rozumieć obywateli państw członkowskich Unii Europejskiej, Konfederacji Szwajcarskiej oraz państwa członkowskiego Europejskiego Porozumienia o Wolnym Handlu (EFTA) - strony umowy o Europejskim Obszarze Gospodarczym, a także członków ich rodzin w rozumieniu przepisów ustawy z dnia 14 lipca 2006 r. o wjeździe na terytorium Rzeczypospolitej Polskiej, pobycie oraz wyjeździe z tego terytorium obywateli państw członkowskich Unii Europejskiej i członków ich rodzin (Dz.U. Nr 144, poz. 1043 oraz z 2007 r. nr 120, poz. 818) oraz obywateli państw trzecich posiadających zezwolenie na pobyt rezydenta długoterminowego Wspólnot Europejskich w rozumieniu przepisów ustawy z dnia 13 czerwca 2003 r. o cudzoziemcach (Dz.U. z 2006 r. Nr 234, poz. 1694, z późniejszymi zmianami).


  • III.3.5) Sytuacja ekonomiczna i finansowa


    Opis sposobu dokonywania oceny spełniania tego warunku

    • Zamawiający wymaga aby wykonawca posiadał: 1. środki finansowe lub zdolność kredytową w wysokości nie mniejszej niż 400 000,00 zł (słownie: czterysta tysięcy zł) lub dla walut obcych na kwotę w wysokości równoważnej liczonej wg średniego kursu złotego w stosunku do walut obcych, ogłaszanego przez Narodowy Bank Polski, obowiązującego w dniu, w którym opublikowane zostało niniejsze ogłoszenie o zamówieniu w Biuletynie Zamówień Publicznych. Potwierdzeniem spełniania warunku będzie informacja z banku lub spółdzielczej kasy oszczędnościowo - kredytowej, w których wykonawca posiada rachunek, potwierdzający wysokość posiadanych środków finansowych lub zdolność kredytową wykonawcy, wystawioną nie wcześniej niż 3 miesiące przed upływem terminu składania wniosków. 2. ubezpieczenie od odpowiedzialności cywilnej w zakresie prowadzonej działalności związanej z przedmiotem zamówienia. Potwierdzeniem spełniania warunku będzie opłacona polisa a w przypadku jej braku inny dokument potwierdzający, że wykonawca jest ubezpieczony od odpowiedzialności cywilnej w zakresie prowadzonej działalności związanej z przedmiotem zamówienia.


III.4) INFORMACJA O OŚWIADCZENIACH LUB DOKUMENTACH, JAKIE MAJĄ DOSTARCZYĆ WYKONAWCY W CELU POTWIERDZENIA SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU ORAZ NIEPODLEGANIA WYKLUCZENIU NA PODSTAWIE ART. 24 UST. 1 USTAWY


  • III.4.1) W zakresie wykazania spełniania przez wykonawcę warunków, o których mowa w art. 22 ust. 1 ustawy, oprócz oświadczenia o spełnieniu warunków udziału w postępowaniu, należy przedłożyć:

    • wykaz wykonanych, a w przypadku świadczeń okresowych lub ciągłych również wykonywanych, dostaw lub usług w zakresie niezbędnym do wykazania spełniania warunku wiedzy i doświadczenia w okresie ostatnich trzech lat przed upływem terminu składania ofert albo wniosków o dopuszczenie do udziału w postępowaniu, a jeżeli okres prowadzenia działalności jest krótszy - w tym okresie, z podaniem ich wartości, przedmiotu, dat wykonania i odbiorców, oraz załączeniem dokumentu potwierdzającego, że te dostawy lub usługi zostały wykonane lub są wykonywane należycie
    • wykaz osób, które będą uczestniczyć w wykonywaniu zamówienia, w szczególności odpowiedzialnych za świadczenie usług, kontrolę jakości lub kierowanie robotami budowlanymi, wraz z informacjami na temat ich kwalifikacji zawodowych, doświadczenia i wykształcenia niezbędnych dla wykonania zamówienia, a także zakresu wykonywanych przez nie czynności, oraz informacją o podstawie do dysponowania tymi osobami
    • oświadczenie, że osoby, które będą uczestniczyć w wykonywaniu zamówienia, posiadają wymagane uprawnienia, jeżeli ustawy nakładają obowiązek posiadania takich uprawnień
    • informację banku lub spółdzielczej kasy oszczędnościowo-kredytowej, w których wykonawca posiada rachunek, potwierdzającą wysokość posiadanych środków finansowych lub zdolność kredytową wykonawcy, wystawioną nie wcześniej niż 3 miesiące przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert
    • opłaconą polisę, a w przypadku jej braku inny dokument potwierdzający, że wykonawca jest ubezpieczony od odpowiedzialności cywilnej w zakresie prowadzonej działalności związanej z przedmiotem zamówienia
  • Wykonawca powołujący się przy wykazywaniu spełnienia warunków udziału w postępowaniu na zdolność finansową innych podmiotów, przedkłada informację banku lub spółdzielczej kasy oszczędnościowo-kredytowej, dotyczącą podmiotu, z którego zdolności finansowej korzysta na podstawie art. 26 ust. 2b ustawy, potwierdzającą wysokość posiadanych przez ten podmiot środków finansowych lub jego zdolność kredytową, wystawioną nie wcześniej niż 3 miesiące przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert.


  • III.4.2) W zakresie potwierdzenia niepodlegania wykluczeniu na podstawie art. 24 ust. 1 ustawy, należy przedłożyć:

    • oświadczenie o braku podstaw do wykluczenia
    • aktualny odpis z właściwego rejestru, jeżeli odrębne przepisy wymagają wpisu do rejestru, w celu wykazania braku podstaw do wykluczenia w oparciu o art. 24 ust. 1 pkt 2 ustawy, wystawiony nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert, a w stosunku do osób fizycznych oświadczenie w zakresie art. 24 ust. 1 pkt 2 ustawy
    • wykonawca powołujący się przy wykazywaniu spełniania warunków udziału w postępowaniu na potencjał innych podmiotów, które będą brały udział w realizacji części zamówienia, przedkłada także dokumenty dotyczące tego podmiotu w zakresie wymaganym dla wykonawcy, określonym w pkt III.4.2.
  • III.4.3) Dokumenty podmiotów zagranicznych

    Jeżeli wykonawca ma siedzibę lub miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej, przedkłada:

    III.4.3.1) dokument wystawiony w kraju, w którym ma siedzibę lub miejsce zamieszkania potwierdzający, że:

    • nie otwarto jego likwidacji ani nie ogłoszono upadłości - wystawiony nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert

III.6) INNE DOKUMENTY

Inne dokumenty niewymienione w pkt III.4) albo w pkt III.5)

a) Podpisany wniosek o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia. b) W przypadku wspólnego ubiegania się o udzielenie zamówienia przez kilku wykonawców - wykonawca winien załączyć do wniosku o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia pełnomocnictwo podpisane przez wszystkie podmioty wspólnie ubiegające się o udzielenie zamówienia, złożone w formie oryginału lub notarialnie potwierdzonej kopii. c) W przypadku ustanowienia przez Wykonawcę pełnomocnika, do wniosku o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia należy załączyć oryginał udzielonego pełnomocnictwa lub notarialnie potwierdzoną jego kopię. Z treści pełnomocnictwa musi wynikać zakres umocowania do czynności związanych z postępowaniem o udzielenie zamówienia publicznego, w szczególności do podpisania i złożenia wniosku o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia i ewentualnie oferty.d) Pisemne zobowiązanie podmiotów do oddania do dyspozycji niezbędnych zasobów na okres korzystania z nich przy wykonywaniu zamówienia.


III.7) Czy ogranicza się możliwość ubiegania się o zamówienie publiczne tylko dla wykonawców, u których ponad 50 % pracowników stanowią osoby niepełnosprawne:
nie

SEKCJA IV: PROCEDURA


IV.1) TRYB UDZIELENIA ZAMÓWIENIA


IV.1.1) Tryb udzielenia zamówienia:
przetarg ograniczony.


IV.1.2) Przewidywana liczba wykonawców, którzy zostaną zaproszeni do udziału w postępowaniu:
5.

Znaczenie warunków wyboru wykonawców, którzy zostaną zaproszeni do udziału w postępowaniu

Za ujęte w wykazie wykonanych dostaw w okresie ostatnich trzech lat przed upływem terminu składania wniosków, a jeżeli okres prowadzenia działalności jest krótszy - w tym okresie i potwierdzone dokumentem o należytym wykonaniu lub wykonywaniu dwie dostawy wykonawca otrzyma ocenę - warunek spełnia, za każdą dalszą ujętą w wykazie i potwierdzoną dokumentem o należytym wykonaniu lub wykonywaniu dostawy, wykonawca otrzyma jeden punkt. Pozostałe oceny spełniania warunków zostaną dokonane przez zamawiającego wg formuły spełnia / nie spełnia - w oparciu o analizę treści oświadczeń i dokumentów. Przy ocenie spełniania warunków przez wykonawców występujących wspólnie, dotyczących: - posiadania niezbędnej wiedzy i doświadczenia, - znajdowania się w sytuacji ekonomicznej i finansowej zapewniającej wykonanie zamówienia, zamawiający będzie brał pod uwagę łączny potencjał wykonawców występujących wspólnie. Jeżeli liczba wykonawców, którzy spełniają warunki udziału w postępowaniu w zakresie wskazanym przez Zamawiającego w Sekcji III.3), będzie mniejsza niż 5, Zamawiający zaprosi do składania ofert wszystkich Wykonawców spełniających te warunki. W przypadku, gdy liczba wykonawców, którzy wykażą spełnianie warunków udziału w postępowaniu będzie większa niż 5, Zamawiający zaprosi do składania ofert tych wykonawców, którzy uzyskają najwyższą ilość punktów za spełnianie warunków.


IV.2) KRYTERIA OCENY OFERT


IV.2.1) Kryteria oceny ofert:
najniższa cena.


IV.2.2) Czy przeprowadzona będzie aukcja elektroniczna:
nie.


IV.3) ZMIANA UMOWY


Czy przewiduje się istotne zmiany postanowień zawartej umowy w stosunku do treści oferty, na podstawie której dokonano wyboru wykonawcy:
tak


Dopuszczalne zmiany postanowień umowy oraz określenie warunków zmian

Zamawiający dopuszcza możliwość zmiany postanowień umowy zawartej z wykonawcą wyłonionym w toku niniejszego postępowania w przypadku zaistnienia nw. okoliczności: a) w przypadku zmiany obowiązującego prawa w trakcie realizacji umowy, zamawiający dopuszcza możliwość zmiany wynagrodzenia na skutek zmiany stawki podatku VAT,wówczas do kwoty netto zostanie naliczony podatek VAT w wysokości obowiązującej na dzień wystawienia faktury, b) w przypadku wystąpienia okoliczności, których nie można było przewidzieć w chwili zawarcia umowy, a nie wprowadzenie tych zmian powodowałoby niemożność wykonania przedmiotu zamówienia i osiągnięcia założonego celu, c) w przypadku wystąpienia okoliczności określonych w pkt b) termin realizacji zamówienia może ulec zmianie.


IV.4) INFORMACJE ADMINISTRACYJNE


IV.4.1)
 
Adres strony internetowej, na której jest dostępna specyfikacja istotnych warunków zamówienia:
Nie dotyczy

Specyfikację istotnych warunków zamówienia można uzyskać pod adresem:
Nie dotyczy.


IV.4.4) Termin składania wniosków o dopuszczenie do udziału w postępowaniu lub ofert:
06.04.2011 godzina 09:00, miejsce: Urząd Miejski w Sosnowcu, Wydział Inwestycji Miejskich, ul. I. Mościckiego 14, pokój nr 129 (I piętro)..


IV.4.5) Termin związania ofertą:
okres w dniach: 30 (od ostatecznego terminu składania ofert).


IV.4.16) Informacje dodatkowe, w tym dotyczące finansowania projektu/programu ze środków Unii Europejskiej:
Zamawiający nie przewiduje dofinansowania inwestycji ze środków Unii Europejskiej. Zamawiający będzie żądał wniesienia zabezpieczenia należytego wykonania umowy w wysokości 10% ceny całkowitej podanej w ofercie od wykonawcy, którego oferta zostanie oceniona jako najkorzystniejsza i wybrana przez zamawiającego do realizacji niniejszego przedmiotu zamówienia. Sposób przygotowania wniosku o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia: Wykonawca powinien złożyć tylko jeden wniosek. Wniosek musi być przygotowany w języku polskim. Wniosek musi zawierać oświadczenie wykonawcy o chęci wzięcia udziału w postępowaniu o udzielenie zamówienia publicznego na dostawę urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem dla monitoringu miejskiego w ramach zadania : Monitoring miasta - etap III . Wniosek musi być sporządzony w sposób czytelny, pisemnie na papierze, opieczętowany pieczęcią firmową i pieczęciami imiennymi oraz podpisany przez osoby upoważnione do reprezentowania wykonawcy. Wraz z wnioskiem należy złożyć pełnomocnictwo (o ile prawo do podpisania wniosku nie wynika z innych dokumentów złożonych wraz z wnioskiem) do reprezentowania wszystkich wykonawców wspólnie ubiegających się o udzielenie zamówienia i ewentualnie umowę o współdziałaniu, z której będzie wynikać ww. pełnomocnictwo. Pełnomocnik powinien być ustanowiony do reprezentowania wykonawców w postępowaniu albo do reprezentowania w postępowaniu i zawarcia umowy. Pełnomocnictwo musi być załączone do wniosku o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia w oryginale lub kopii poświadczonej za zgodność z oryginałem przez notariusza. Każdy dokument składany wraz z wnioskiem o dopuszczenie do udziału w postępowaniu sporządzony w innym języku niż język polski powinien być złożony wraz z tłumaczeniem na język polski, poświadczonym za zgodność z oryginałem przez wykonawcę. Oświadczenia wystawiane przez wykonawcę muszą być przedstawione w oryginale i być przez niego podpisane. Dokumenty składane wraz z wnioskiem o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia, inne niż pełnomocnictwo i oświadczenia , mogą być złożone w oryginale lub kserokopii potwierdzonej za zgodność z oryginałem przez wykonawcę lub w formie odpisów poświadczonych notarialnie. Poświadczenie za zgodność z oryginałem powinno być sporządzone w sposób umożliwiający identyfikację osoby poświadczającej kopię dokumentu za zgodność z oryginałem (np. imienną pieczątką). Wniosek musi być złożony w trwale zamkniętym opakowaniu z nazwą i dokładnym adresem wykonawcy (dopuszcza się odcisk pieczęci) z następującym opisem: Gmina Sosnowiec, Urząd Miejski - Wydział Inwestycji Miejskich, ul. I. Mościckiego 14, 41-200 Sosnowiec, wniosek o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia publicznego na dostawę urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem dla monitoringu miejskiego w ramach zadania : Monitoring miasta - etap III . Wnioski, zawiadomienia oraz informacje zamawiający i wykonawcy przekazują pisemnie lub za pomocą faksu, każda ze stron na żądanie drugiej niezwłocznie potwierdza fakt jego otrzymania. Każdy z wykonawców składa oświadczenie o spełnianiu warunków udziału w postępowaniu o udzielenie zamówienia publicznego określonych w ustawie Prawo zamówień publicznych(art.22 ust.1) na usługę dostawy i instalowania urządzeń i oprogramowania dla monitoringu miejskiego w ramach zadania : Monitoring miasta - etap III o treści: Oświadczam, że spełniam warunki udziału w postępowaniu,zgodnie z art. 22 ust. 1 ustawy Prawo zamówień publicznych.W przypadku wykonawców wspólnie składających wniosek zamawiający wymaga, aby każdy z wykonawców indywidualnie złożył:oświadczenie o braku podstaw do wykluczenia z postępowania o udzielenie zamówienia na dostawę urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem dla monitoringu miejskiego w ramach zadania : Monitoring miasta - etap III .- z przyczyn opisanych w art. 24 ust. 1 ustawy stosowne do sytuacji faktycznej wykonawcy oraz stosowne do formy prawnej prowadzonej działalności o treści: Oświadczam, że nie podlegam wykluczeniu na podstawie art. 24 ustawy Prawo zamówień publicznych oraz aktualny odpis z właściwego rejestru, jeżeli odrębne przepisy wymagają wpisu do rejestru, w celu wykazania braku podstaw do wykluczenia w oparciu o art. 24 ust. 1 pkt 2 ustawy, wystawiony nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia, a w stosunku do osób fizycznych oświadczenia w zakresie art. 24 ust. 1 pkt 2 ustawy.


IV.4.17) Czy przewiduje się unieważnienie postępowania o udzielenie zamówienia, w przypadku nieprzyznania środków pochodzących z budżetu Unii Europejskiej oraz niepodlegających zwrotowi środków z pomocy udzielonej przez państwa członkowskie Europejskiego Porozumienia o Wolnym Handlu (EFTA), które miały być przeznaczone na sfinansowanie całości lub części zamówienia:
nie


Sosnowiec: Dostawa urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem dla monitoringu miejskiego w ramach zadania - Monitoring miasta - etap III-.


Numer ogłoszenia: 196343 - 2011; data zamieszczenia: 19.07.2011

OGŁOSZENIE O UDZIELENIU ZAMÓWIENIA - Dostawy


Zamieszczanie ogłoszenia:
obowiązkowe.


Ogłoszenie dotyczy:
zamówienia publicznego.


Czy zamówienie było przedmiotem ogłoszenia w Biuletynie Zamówień Publicznych:
tak, numer ogłoszenia w BZP: 97553 - 2011r.


Czy w Biuletynie Zamówień Publicznych zostało zamieszczone ogłoszenie o zmianie ogłoszenia:
nie.

SEKCJA I: ZAMAWIAJĄCY


I. 1) NAZWA I ADRES:
Gmina Sosnowiec - miasto posiadające prawa powiatu - reprezentowana przez Prezydenta Miasta, al. Zwycięstwa 20, 41-200 Sosnowiec, woj. śląskie, tel. 32 2960600, faks 32 296 06 05.


I. 2) RODZAJ ZAMAWIAJĄCEGO:
Administracja samorządowa.

SEKCJA II: PRZEDMIOT ZAMÓWIENIA


II.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.2) Rodzaj zamówienia:
Dostawy.


II.3) Określenie przedmiotu zamówienia:
Przedmiotem zamówienia jest dostawa urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem niżej wyszczególnionych urządzeń i oprogramowania dla monitoringu miejskiego: - 15 szt. kamer szybkoobrotowych, - 2 szt. komputerów 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 powierzchni magazynowania o pojemności 20 TB w tzw. konfiguracji Raid 6E (szafa ), - 4 szt. monitorów 32 cal w rozdzielczości nie mniejszej niż1920 x 1080, - 3 szt. monitorów 20 cal w rozdzielczości nie mniejszej niż 1920 x 1080 - 1 szt. 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,5 mb 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.1 Automatyczne wykrywanie cyfrowych serwerów video, które zostaną podłączone do sieci. 2.5.4.2 Wykrywanie 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.3 Archiwum 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.1 Numery kamer na mapie, które są przełączone na monitorze osobistym. 3.13.2 Numery kamer, które są wyświetlane na ścianie video. 3.13.3 Numery 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.1 Użytkownika. 3.15.2 Kodu incydentu. 3.15.3 Kamery. 3.15.4 Grupy kamer (lokalizacja). 3.15.5 Daty 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.1 10 topowych raportów (najważniejszych / najczęściej powtarzających się) 3.16.2 Raport dzienny. 3.16.3 Analizy trendów. 3.16.4 Analizy ryzyka dla konkretnych obszarów. 3.16.5 Raporty dotyczące sposobu wykonywania pracy przez obserwatorów, bazujące na częstotliwości zmieniania kamer oraz ilości rejestrowanych zdarzeń. 3.16.6 Informacje na temat przeglądu poleceń podzielone na użytkowników oraz lokalizacje. 3.16.7 Sposó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.1 Wymagany 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.1 Oddzielne fizyczne serwery SZV nie są wymagane. 4.1.1.2 Oddzielne fizyczne awaryjne serwery SZV nie są wymagane. 4.1.1.3 Zasilanie 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.1 Spełniać standardy iSCSI. 4.2.2.2 Bazować na rozwiązaniu SATA dla zmniejszenia kosztów oraz obsługiwać 20TB. 4.2.2.3 Posiadać certyfikaty UL i CE. 4.2.2.4 Powinien 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.1 Ochrona danych do poziomu pięciu jednoczesnych awarii dysków bez starty danych lub dostępu do danych. 4.3.1.2 Ochrona 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.1 Obsługa wymiany dysków bez przerywania dostępu do danych. 4.3.2.2 Obsługa wymiany zasilaczy bez przerywania dostępu do danych. 4.3.2.3 Możliwość wymiany wiatraków bez przerywania dostępu do danych. 4.3.2.4 Możliwość wymiany całych urządzeń bez przerywania dostępu do danych. 4.3.2.5 Moż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.1 Możliwość rozszerzenia pojemności dysków poprzez dodanie kolejnych dysków bez przerywania dostępu do danych. 4.3.3.2 Możliwość rozszerzania poprzez dodawanie częstotliwości sieciowych bez przerywania dostępu do danych. 4.3.3.3 Moż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.1 Udostępnienie wzmocnionej ochrony danych (RAID 6) dla ochrony środowiska danych krytycznych. 4.3.4.2 Udostę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.1 Dynamiczna 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.1 Pojemność powinna być dodawana do system na zasadzie przyrostów modularnych od 12 do 24 TB. 4.4.1.2 Skalowalność 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.3 Fizyczna 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.1 Obsługa do 12 kontrolerów w trybie aktywnym. 4.4.2.2 Obsł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.1 System powinien samodzielnie wykrywać konfigurację sprzętową. 4.5.1.2 System powinien udostępniać statystyki dotyczące wykorzystania powierzchni. 4.5.2 System powinien umożliwiać dynamiczną konfigurację wolumenów. 4.5.2.1 System 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.2 System 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.1 System powinien rejestrować zmiany konfiguracji oraz wydarzenia systemowe. 4.5.5.2 System 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.3 System powinien umożliwiać opcję słyszalnego alarmu. 4.5.5.4 System powinien wykrywać awarie kontrolerów oraz graficznie identyfikować uszkodzony kontroler. 4.5.5.5 System 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.1 Intel Quad Core Xeon E5420 2.50 GHz. 5.2 Pamięć: 4096MB (4x1024) 667MHz DDR2 Quad Channel 5.3 Dysk twardy: 320GB Serial ATA II (7200 RPM) Hard Drive 5.4 Dodatkowy dysk twardy: 320GB Serial ATA II (7200 RPM) Hard Drive 5.5C4 All SATA, RAID 1(Mirroring) dla 2 dysków twardych 5.6 Optical Drive: PowerDVD 8.3 Software and Media incl. 5.7 Optical Drive : 8X DVD+ przez -RW Drive 5.8 Keyboard : US przez Euro (QWERTY) Dell Standard Quietkey USB Keyboard Black 5.9 Windows 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.2 Konieczne jest dostosowanie wysokości biurek i krzeseł. 6.3 Konieczne jest uwzględnienie kolorystyki i natężenia światła w pomieszczeniu nadzoru. 6.4 Należ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.4) Wspólny Słownik Zamówień (CPV):
35.12.53.00-2, 32.33.31.00-7, 30.23.60.00-2, 51.61.20.00-5, 72.26.80.00-1.

SEKCJA III: PROCEDURA


III.1) TRYB UDZIELENIA ZAMÓWIENIA:
Przetarg ograniczony


III.2) INFORMACJE ADMINISTRACYJNE


  • Zamówienie dotyczy projektu/programu finansowanego ze środków Unii Europejskiej:
    nie

SEKCJA IV: UDZIELENIE ZAMÓWIENIA


Część NR:
1   


Nazwa:


IV.1) DATA UDZIELENIA ZAMÓWIENIA:
18.07.2011.


IV.2) LICZBA OTRZYMANYCH OFERT:
3.


IV.3) LICZBA ODRZUCONYCH OFERT:
0.


IV.4) NAZWA I ADRES WYKONAWCY, KTÓREMU UDZIELONO ZAMÓWIENIA:

  • Lider Konsorcjum TKP S.A., {Dane ukryte}, 44-100 Gliwice, kraj/woj. śląskie.
  • Członek Konsorcjum Przedsiębiorstwo Techniczno-Handlowe -SECURAL-, {Dane ukryte}, 41-200 Sosnowiec, kraj/woj. śląskie.


IV.5) Szacunkowa wartość zamówienia
(bez VAT): 480000,00 PLN.


IV.6) INFORMACJA O CENIE WYBRANEJ OFERTY ORAZ O OFERTACH Z NAJNIŻSZĄ I NAJWYŻSZĄ CENĄ


  • Cena wybranej oferty:
    540041,34


  • Oferta z najniższą ceną:
    540041,34
    / Oferta z najwyższą ceną:
    823854,00


  • Waluta:
    PLN.

Adres: al. Zwycięstwa 20, 41-200 Sosnowiec
woj. śląskie
Dane kontaktowe: email: informatyk@um.sosnowiec.pl
tel: 322 960 600
fax: 32 296 06 05
Termin składania wniosków lub ofert:
2011-04-05
Dane postępowania
ID postępowania BZP/TED: 9755320110
ID postępowania Zamawiającego:
Data publikacji zamówienia: 2011-03-27
Rodzaj zamówienia: dostawy
Tryb& postępowania [PO]: Przetarg Ograniczony
Czas na realizację: 4 miesięcy
Wadium: -
Oferty uzupełniające: NIE
Oferty częściowe: NIE
Oferty wariantowe: NIE
Przewidywana licyctacja: NIE
Ilość części: 1
Kryterium ceny: 100%
WWW ogłoszenia: www.um.sosnowiec.pl
Informacja dostępna pod: Nie dotyczy
Okres związania ofertą: 30 dni
Kody CPV
30236000-2 Różny sprzęt komputerowy
32333100-7 Rejestratory obrazu wideo
35125300-2 Kamery bezpieczeństwa
51612000-5 Usługi instalowania urządzeń do przetwarzania informacji
72268000-1 Usługi dostawy oprogramowania
Wyniki
Nazwa części Wykonawca Data udzielenia Wartość
Dostawa urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem dla monitoringu miejskiego w ramach zadania - Monitoring miasta - etap III-. Lider Konsorcjum TKP S.A.
Gliwice
2011-07-19 270 020,00
Dostawa urządzeń i oprogramowania wraz z rozmieszczeniem i zainstalowaniem dla monitoringu miejskiego w ramach zadania - Monitoring miasta - etap III-. Członek Konsorcjum Przedsiębiorstwo Techniczno-Handlowe -SECURAL-
Sosnowiec
2011-07-19 270 020,00