196343 / 2011-07-19 - Administracja samorzÄ…dowa / Gmina Sosnowiec - miasto posiadajÄ…ce prawa powiatu - reprezentowana przez Prezydenta Miasta (Sosnowiec)

Oryginalny tusz S020143 Purpurowo czerwony + jasno Purpurowy marki Epson

Cena: 485.22 PLN

Ogłoszenie zawiera informacje aktualizacyjne dotyczące publikacji w biuletynie 1 z dnia 2011-03-28 pod pozycją 97553. Zobacz ogłoszenie 97553 / 2011-03-28 - Administracja samorzÄ…dowa.

Numer biuletynu: 1

Pozycja w biuletynie: 196343

Data publikacji: 2011-07-19

Nazwa:
Gmina Sosnowiec - miasto posiadające prawa powiatu - reprezentowana przez Prezydenta Miasta

Ulica: al. Zwycięstwa 20

Numer domu: 20

Miejscowość: Sosnowiec

Kod pocztowy: 41-200

Województwo / kraj: śląskie

Numer telefonu: 32 2960600

Numer faxu: 32 296 06 05

Adres strony internetowej: www.um.sosnowiec.pl

Regon: 27625548200000

Typ ogłoszenia: ZP-403

Numer biuletynu: 1

Numer pozycji: 97553

Data wydania biuletynu: 2011-03-28

Czy jest obowiązek publikacji w biuletynie: Tak

Czy zamówienie było ogłoszone w BZP: Tak

Rok ogłoszenia: 2011

Pozycja ogłoszenia: 97553

Czy w BZP zostało zamieszczone ogłoszenie o zmianie: Nie

Ogłoszenie dotyczy: 1

Rodzaj zamawiającego: Administracja samorządowa

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-.

Rodzaj zamówienia: D

Przedmiot 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.

Kod trybu postepowania: PO

Czy zamówienie dotyczy programu UE: Nie

Nazwa wykonawcy: Lider Konsorcjum TKP S.A.

Adres pocztowy wykonawcy: ul.Chorzowska 50

Miejscowość: Gliwice

Kod pocztowy: 44-100

ID województwa: 11

Województwo / kraj: śląskie

Nazwa wykonawcy:
Członek Konsorcjum
Przedsiębiorstwo Techniczno-Handlowe -SECURAL-

Adres pocztowy wykonawcy: ul.Puławskiego 4

Miejscowość: Sosnowiec

Kod pocztowy: 41-200

ID województwa: 11

Województwo / kraj: śląskie

Nr częsci: 1

Data udzielenie zamówienia: 18/07/2011

Liczba ofert: 3

Liczba odrzuconych ofert: 0

Szacunkowa wartość zamówienia: 480000,00

Cena wybranej oferty: 540041,34

Cena minimalna: 540041,34

Cena maksymalna: 823854,00

Kod waluty: 1

Waluta (PLN): PLN

Kody CPV:
351253002 (Kamery bezpieczeństwa)

Kod CPV drugiej częsci zamówienia:
323331007 (Rejestratory obrazu wideo)

Kod CPV trzeciej częsci zamówienia:
302360002 (Różny sprzęt komputerowy)

Kod CPV czwartej częsci zamówienia:
516120005 (Usługi instalowania urządzeń do przetwarzania informacji)

Kod CPV piątej częsci zamówienia:
722680001 (Usługi dostawy oprogramowania)

Podobne przetargi