OPIS PRZEDMIOTU ZAMÓWIENIA (OPZ)

Transkrypt

1 Załącznik nr 1 OPIS PRZEDMIOTU ZAMÓWIENIA (OPZ) na zakup i wdrożenie zintegrowanego systemu informatycznego wojewódzkich centrów powiadamiania ratunkowego, umożliwiającego przyjęcie i rejestrację zgłoszeń na numer alarmowy 112 oraz inne numery alarmowe 1

2 1. Wstęp Przedsięwzięcie stanowi element projektu pn.: System Informatyczny Powiadamiania Ratunkowego (SI PR) którego realizacja podyktowana jest koniecznością wdrożenia jednolitych w skali kraju narzędzi informatycznych wspierających realizację zadań i współdziałanie służb ustawowo powołanych do przyjęcia i obsługi wywołań alarmowych. System ten będzie stanowił główny element wyposażenia podmiotów funkcjonujących w ramach systemu powiadamiania ratunkowego, o których mowa w rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 31 lipca 2009 r. w sprawie organizacji i funkcjonowania centrów powiadamiania ratunkowego i wojewódzkich centrów powiadamiania ratunkowego (Dz. U. z 2009 r. Nr 130, poz. 1073), oraz komórek organizacyjnych Policji. W kolejnym etapie realizacji projektu SI PR, System będzie podlegał rozbudowie o funkcjonalności wskazane przez Zamawiającego. Rezultatem projektu SI PR będzie: 1. możliwość obsługi zgłoszeń alarmowych obywateli polskich i cudzoziemców przebywających na terytorium Rzeczpospolitej Polskiej na jednolity europejski numer 112 oraz inne numery alarmowe; 2. możliwość obsługi zgłoszeń alarmowych osób niepełnosprawnych na numer 112 oraz inne numery alarmowe; 3. możliwość obsługi zgłoszeń alarmowych osób nie posługujących się językiem polskim na numer 112 oraz inne numery alarmowe; 4. możliwość obsługi zgłoszeń alarmowych z systemów monitoringu, w tym systemu e-call; 5. możliwość gromadzenia danych i zapewnienie przepływu informacji niezbędnej do zarządzania zasobami ratowniczymi PSP, PRM oraz Policji; 6. możliwość natychmiastowej wizualizacji miejsca zgłoszenia, zdarzenia oraz jednostek ratowniczych na terenie Rzeczpospolitej Polskiej; 7. możliwość określania i monitorowania średniego czasu oczekiwania na przyjęcia zgłoszenia; 8. możliwość określania i monitorowania średniego czasu reakcji na przyjęte zgłoszenie (czasu podjęcia czynności przez odpowiednie służby ratownictwa od przyjęcia zgłoszenia); 9. możliwość określenia ilości zgłoszeń oczekujących na odbiór i obsługę z funkcją powiadomienia o potrzebie wzmocnienia lub zwiększenia ilości stanowisk do odbioru zgłoszeń; 10. zapewnienie warunków technicznych do współdziałania służb, przekierowywania zgłoszeń alarmowych do właściwych merytorycznie i miejscowo służb oraz wymiany informacji w ramach całego systemu obsługi zgłoszeń alarmowych; 11. umożliwienie dystrybucji danych o lokalizacji zgłoszenia, na podstawie informacji z systemu UKE Platforma Lokalizacyjno-Informacyjna z Centralną Bazą Danych, do podmiotów obsługujących zgłoszenie alarmowe; W skład Systemu Informatycznego Powiadamiania Ratunkowego (SI PR), docelowo wejdą następujące moduły systemowe: 1. System Informatyczny Wojewódzkiego Centrum Powiadamiania Ratunkowego (SI WCPR), 2. System Informatyczny Centrum Powiadamiania Ratunkowego (SI CPR), 3. Centralny Punkt Systemu Centrów Powiadamiania Ratunkowego (CP SCPR), 4. System Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM), 2

3 5. System Wspomagania Dowodzenia Państwowej Straży Pożarnej (SWD PSP), 6. System Wspomagania Dowodzenia Policji (SWD Policji). W ramach SI CPR i SI WCPR zapewniony zostanie uniwersalny interfejs, umożliwiający integrację z systemami podmiotów ratowniczych - systemami klasy SWD. Przedmiotowe zamówienie dotyczy realizacji modułu Systemu Informatycznego Wojewódzkich Centrów Powiadamiania Ratunkowego (SI WCPR), którego głównym zadaniem jest zapewnienie sprawnej obsługi rejestracji wywołań alarmowych, w szczególności na numery 112, 999, 998, 997 i inne numery alarmowe, a następnie wymiany informacji na temat zdarzeń i powiązanych z nimi zgłoszeń z systemami informatycznymi służb powołanych ustawowo do niesienia pomocy. Proces dysponowania siłami i środkami wykorzystywanymi w celach obsługi zdarzeń będzie wspierany przez systemy wspomagania służb porządku publicznego i ratownictwa (systemy klasy SWD nie wchodzą w zakres przedmiotowego zamówienia). Wizualizacja lokalizacji abonenta będzie realizowana w oparciu o aktualnie funkcjonujące rozwiązanie tymczasowe opierające się o udostępnione przez operatorów telekomunikacyjnych za pośrednictwem przeglądarki WWW. Bezpośrednim użytkownikiem SI WCPR będą Wojewódzkie Centra Powiadamiania Ratunkowego, a pośrednio Centra Powiadamiania Ratunkowego. Ponadto odbiorcą danych z SI WCPR będą jednostki organizacyjne Policji, Państwowej Straży Pożarnej, Państwowego Ratownictwa Medycznego oraz inne podmioty ratownicze. Dla potrzeb funkcjonowania SI WCPR zostanie wykorzystana szkieletowa sieć teleinformatyczna w technologii IP/MPLS, realizowana w ramach projektu Ogólnopolska sieć teleinformatyczna na potrzeby obsługi numeru alarmowego 112 (OST112). Przedmiotowe zamówienie jest finansowane w ramach przedsięwzięcia pn. Budowa i wyposażenie Wojewódzkich Centrów Powiadamiania Ratunkowego realizowanego w Programie Operacyjnym Infrastruktura i Środowisko (POIŚ) Oś priorytetowa XII. 2. Pojęcia i skróty Dla potrzeb niniejszego opracowania przyjmuję się następujące definicje skrótów i pojęć: Skrót/pojęcie Aplikacja SI WCPR Awaria Krytyczna Awaria Niekrytyczna Awaria Zwykła CPR Dokumentacja projektowa Dyspozytor Funkcjonalność Definicja Aplikacja użytkownika Systemu Informatycznego Wojewódzkich Centrów Powiadamiania Ratunkowego brak działania środowiska produkcyjnego Systemu, praca nie może być kontynuowana, operacja krytyczna dla procesu biznesowego jest niemożliwa. Awarie Krytyczne mają jedną lub więcej z poniższych cech: a) Dane biznesowe zostały uszkodzone; b) Funkcjonalność krytyczna ( Funkcjonalność Krytyczna ) udokumentowana w Projekcie Technicznym nie działa; c) System w zakresie Funkcjonalności Krytycznych przerywa działania i nie daje się uruchomić pomimo prób; utrudnia działanie Systemu w środowisku produkcyjnym w zakresie Funkcjonalności Krytycznej i uniemożliwia działanie Systemu w zakresie pozostałych funkcjonalności. W tym kontekście utrudnia oznacza istnienie sposobu jego obejścia (co może mieć wpływ na wygodę w użyciu Systemu lub wymagać procedur ręcznych). Uniemożliwia oznacza brak możliwości znalezienia sposobu na jego obejście. Wszelka awaria nie będąca Awarią Krytyczną lub Awarią Niekrytyczną, Centrum Powiadamiania Ratunkowego; Wytworzone przez Wykonawcę zamówienia w ramach realizacji umowy i podlegające zatwierdzeniu przez Zamawiającego, materiały w formie papierowej, jak również informacje zapisane na innych nośnikach, w tym nośnikach elektronicznych; Użytkownik Końcowy realizujący obsługę zgłoszeń przyjętych od Operatora w ramach SWD Policji/ SWD PSP/ SWD PRM; Cechy funkcjonalne systemu uniemożliwiające realizację operacji krytycznych z 3

4 Skrót/pojęcie Krytyczna Koordynator PLI CBD Oprogramowanie Oprogramowanie Standardowe Oprogramowanie Aplikacyjne Ośrodek Krajowy Ośrodki Regionalne MSWiA Operator PRM PSP SWD Podsystem Integracji Danych Podsystem Zintegrowanej Łączności Podmiot ratowniczy System/SI WCPR SI PR Użytkownik końcowy WCPR Zgłoszenie Zdarzenie Zamawiający Definicja punktu widzenia przyjęcia i obsługi zgłoszeń alarmowych. Użytkownik Końcowy realizujący funkcję nadzoru na poziomie WCPR; Platforma Lokalizacyjno-Informacyjna z Centralną Bazą Danych, dostarczona przez Urząd Komunikacji Elektronicznej; Oprogramowanie Standardowe i Oprogramowanie Aplikacyjne. oznacza oprogramowanie powszechnie dostępne, będące przedmiotem Dostaw w ramach realizacji przedmiotu zamówienia, na które producent udziela Zamawiającemu licencji na warunkach i zasadach określonych w Umowie oraz umowach licencyjnych Oprogramowania Standardowego, dostarczane przez Wykonawcę wraz licencją producenta oraz z dokumentacją i aktualizacjami. oznacza oprogramowanie i skrypty wraz z kompletnymi kodami źródłowymi wytworzone i dostarczone przez Wykonawcę w ramach przedmiotu zamówienia, wraz z dokumentacją i aktualizacjami, zgodnie ze Specyfikacją techniczną, opisaną przez Wykonawcę w złożonej Ofercie, do których Wykonawca przeniesie autorskie prawa majątkowe na Zamawiającego i MSWiA na warunkach i zasadach określonych w Umowie. Centrum serwerowe w oparciu, o które będzie zbudowana architektura systemu SI WCPR na poziomie centralnym; Element architektury systemu SI WCPR stanowiący pośredniczącą warstwę serwerów lokalnych zapewniający krytyczną funkcjonalność w zakresie przyjmowania zgłoszeń oraz ich obsługi, na potrzeby podsystemów zintegrowanej łączności w obiektach (ośrodki zostaną zlokalizowane w pomieszczeniach WCPR); Ministerstwo Spraw Wewnętrznych i Administracji wraz z organami i jednostkami organizacyjnymi podległymi lub nadzorowanymi przez Ministra Spraw Wewnętrznych i Administracji Użytkownik Końcowy realizujący funkcję przyjęcia zgłoszenia w ramach CPR/WCPR; Państwowe Ratownictwo Medyczne; Państwowa Straż Pożarna; System Wspomagania Dowodzenia klasy dyspozytorskiej czasu rzeczywistego wspomagającego w zakresie przyjęcia i obsługi wywołań alarmowych/zdarzeń; Moduł wymiany danych pomiędzy SI WCPR a innymi systemami zewnętrznymi; Moduł komunikacyjny łączności telefonicznej i radiowej zintegrowany z aplikacją SI WCPR; Podmiot, o którym mowa w Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 31 lipca 2009 r. w sprawie organizacji i funkcjonowania centrów powiadamiania ratunkowego oraz wojewódzkich centrów powiadamiania ratunkowego; System Informatyczny Wojewódzkich Centrów Powiadamiania Ratunkowego wraz z zainstalowanym oprogramowaniem standardowym, Aplikacją SI WPCR oraz infrastrukturą sprzętową. Infrastruktura sprzętowa dzieli się na infrastrukturę centralną (Ośrodek Krajowy), infrastrukturę regionalną (Ośrodki Regionalne), oraz sprzęt teleinformatyczny dostarczony w ramach realizacji przedmiotu Zamówienia do lokalizacji wskazanych przez Zamawiającego; System Informatyczny Powiadamiania Ratunkowego; Użytkownik pełniący w systemie rolę Operatora lub Dyspozytora lub Koordynatora, wykorzystujący System; Wojewódzkie Centrum Powiadamiania Ratunkowego; Wywołanie alarmowe przyjmowane przez Operatora w WCPR; Zgłoszenie przekazane przez Operatora do Dyspozytora celem obsługi w SWD; Centrum Projektów Informatycznych MSWiA; Pozostałe pojęcia użyte w dokumencie należy rozumieć zgodnie z ich ogólnie przyjętym znaczeniem. 3. Przedmiot zamówienia 4

5 Przedmiotem zamówienia jest zakup i wdrożenie zintegrowanego systemu informatycznego wojewódzkich centrów powiadamiania ratunkowego (SI WCPR), umożliwiającego przyjęcie i rejestrację zgłoszeń na numer alarmowy 112 oraz inne numery alarmowe. Przedmiot zamówienia obejmuje: 1. Przygotowanie projektu technicznego Systemu, 2. Dostawę, instalację i konfigurację infrastruktury sprzętowej, niezbędnej do prawidłowego funkcjonowania prototypu Systemu wraz z oprogramowaniem standardowym, 3. Udzielenie Zamawiającemu i MSWiA licencji na oprogramowanie standardowe (systemowe, bazodanowe, pomocnicze) oraz dostarczenie aktualizacji oprogramowania standardowego wraz z udzieleniem licencji na dostarczone aktualizacje, 4. Wykonanie i wdrożenie prototypu Systemu w lokalizacjach wskazanych przez Zamawiającego wraz z przeprowadzeniem testów prototypu Systemu, 5. Przeniesienie na Zamawiającego i MSWiA autorskich praw majątkowych do prototypu Systemu oraz wytworzonej dokumentacji projektowej, z wyłączeniem oprogramowania standardowego, 6. Przeprowadzenie szkoleń użytkowników-instruktorów oraz administratorów-instruktorów, w zakresie odpowiednio użytkowania oraz administrowania prototypu Systemu, 7. Pielęgnację prototypu Systemu, polegającą na dostosowaniu prototypu Systemu do potrzeb Użytkownika końcowego, określonych w trakcie bieżącej eksploatacji prototypu Systemu oraz na tej podstawie wytworzenie, wdrożenie Systemu w lokalizacjach wskazanych przez Zamawiającego (20 WCPR oraz Ośrodek Krajowy) wraz z przeprowadzeniem testów Systemu, 8. Dostawę, instalację i konfigurację infrastruktury sprzętowej, niezbędnej do prawidłowego funkcjonowania Systemu wraz z oprogramowaniem standardowym, w tym instalację i konfigurację dostarczanego przez Wykonawcę Oprogramowania na zapewnionych przez Zamawiającego urządzeniach końcowych o których mowa w rozdz. 5.5 i Opracowanie i dostarczenie dokumentacji powykonawczej Systemu, 10. Przeniesienie na Zamawiającego i MSWiA autorskich praw majątkowych do Systemu oraz wytworzonej dokumentacji, z wyłączeniem oprogramowania standardowego, 11. Przeprowadzenie szkoleń dla użytkowników-instruktorów oraz administratorówinstruktorów w zakresie odpowiednio użytkowania oraz administrowania Systemu, 12. Świadczenie usługi gwarancyjnej i serwisu gwarancyjnego w terminie do 31 grudnia 2013 r., 13. Świadczenie w okresie gwarancyjnym usług nadzoru autorskiego w wymiarze 1500 (tysiąc pięćset) roboczogodzin, w ramach którego Wykonawca wykonywał będzie prace związane z modyfikacją Systemu zgodnie z oczekiwaniami Zmawiającego oraz Użytkowników końcowych. W zakres zamówienia nie wchodzi zapewnienie infrastruktury teletechnicznej obiektów WCPR oraz Ośrodków Krajowych i Regionalnych niezbędnych do wdrożenia SI WCPR, co w szczególności dotyczy zapewnienia po stronie Zamawiającego wymaganej: infrastruktury LAN i zasilania gwarantowanego. dostępu do sieci WAN służącej do komunikacji z węzłami OST112 i Ośrodkami Krajowymi, 4. Wymagania wobec przedmiotu zamówienia Podstawowym celem zamówienia jest wdrożenie systemu teleinformatycznego pod nazwą System Informatyczny Wojewódzkich Centrów Powiadamiania Ratunkowego (SI WCPR), wspierającego przyjęcie wywołań alarmowych, co w rezultacie przyczyni się do poprawy 5

6 bezpieczeństwa obywateli i cudzoziemców przebywających na terenie RP. W celu zapewnienia pożądanej jakości produktów i ich zgodności z oczekiwaniami użytkownika końcowego, wymagane jest wykonanie zamówienia z uwzględnieniem podziału na następujące etapy: Etap I: obejmujący pkt 1 przedmiotu zamówienia - w terminie do 30 dni kalendarzowych od dnia zawarcia umowy, Etap II: obejmujący pkt 2-6 przedmiotu zamówienia - w terminie do 120 dni kalendarzowych od dnia zawarcia umowy, Etap III: obejmujący pkt 7-11 przedmiotu zamówienia - w terminie do 180 dni kalendarzowych od dnia zawarcia umowy, Etap IV: obejmujący pkt przedmiotu zamówienia - w terminie do r Ogólne założenia SI WCPR W skład Systemu należy zaliczyć następujące produkty: a) Aplikację SI WCPR; b) Oprogramowanie standardowe, c) Infrastrukturę sprzętową niezbędną do prawidłowego działania Systemu. Zakłada się budowę Aplikacji SI WCPR w oparciu o uniwersalne, dające się wyróżnić komponenty funkcjonalne (podsystemy): 1. Podsystem przyjęcia zgłoszenia, 2. Podsystem zintegrowanej łączności wraz z systemem rejestracji rozmów, 3. Podsystem baz danych, 4. Podsystem raportowy, 5. Podsystem monitorowania zgłoszeń. Ogólny opis poszczególnych podsystemów: Podsystem PRZYJĘCIA ZGŁOSZENIA Podsystem zapewnia zasadniczą funkcjonalność umożliwiającą Operatorowi rejestrację wywołania alarmowe w szczególności dla wywołania telefonicznego numeru alarmowego 112, 999, 998, 997 i innych numerów alarmowych (zgłoszenia) przy pomocy uniwersalnego arkusza elektronicznego. Ponadto, posiada zaimplementowane funkcjonalności wspomagające proces przyjęcia zgłoszenia poprzez sygnalizację zgłoszeń podobnych, fałszywych. Użytkownik Systemu nie dysponuje siłami i środkami służb porządku publicznego i ratownictwa, przekazuje jedynie zebrane i dostępne informacje dotyczące zdarzenia i związanych z nim zgłoszeń (przekazane zdarzenie wraz ze zgłoszeniami zostają przekazane do6obsługi przez Dyspozytora poszczególnych służb). Podsystem umożliwia przekazanie procesu przyjęcia zgłoszenia pomiędzy Operatorami zlokalizowanymi w WCPR (np. dla potrzeb przyjęcia zgłoszeń obcojęzycznych). Podsystem ZINTEGROWANEJ ŁĄCZNOŚCI Podsystem zapewnia zintegrowanie aplikacji informatycznej z systemami łączności telefonicznej i radiotelefonicznej oraz umożliwia wysyłanie i odbiór komunikatów aplikacyjnych (komunikator) pomiędzy użytkownikami Systemu. W zakresie łączności radiotelefonicznej wymagane jest dostarczenie rozwiązania posiadającego oczekiwaną funkcjonalność na poziomie aplikacyjnym (oprogramowanie serwera komunikacyjnego i konsol dyspozytorskich) natomiast wymagane elementy infrastrukturalne (dodatkowe moduły integracji radiowej sprzętowe karty interfejsów) nie są przedmiotem niniejszego zamówienia. W ramach tego podsystemu zostanie 6

7 zaimplementowany system rejestracji rozmów, rejestrujący połączenia głosowe kierowane na numer alarmowy 112 oraz inne numery alarmowe. Podsystem BAZ DANYCH Podsystem przechowuje dane związane z realizacją zadań poszczególnych modułów Systemu. Wymiana danych z innym modułami systemu odbywa się za pośrednictwem zewnętrznej szyny komunikacyjnej (wymiany danych), przy wykorzystaniu architektury opartej o model SOA. Podsystem RAPORTOWY Podsystem udostępnia mechanizmy analityczne niezbędne do tworzenia raportów o charakterze operacyjnym (nt. bieżącego stanu działania danego WCPR) oraz o charakterze statystycznym na danych historycznych. Głównym zadaniem tego komponentu jest wspomaganie podmiotów ratowniczych w zakresie planowania i organizacji zadań niezbędnych w zakresie przyjęcia i obsługi wywołań alarmowych. Podsystem MONITOROWANIA ZGŁOSZEŃ Podsystem umożliwia śledzenie procesu przyjęcia zgłoszenia oraz statusu obsługi zdarzeń niezbędnych z punktu widzenia zadań Koordynatora WCPR. Zakłada się implementację w ramach niniejszego komponentu m.in. mechanizm automatycznego powiadamiania o przekroczeniu przyjętego czasu obsługi przyjęcia zgłoszenia (monitorowanie czasu oczekiwania na odbiór zgłoszenia) Struktura organizacyjna Dla potrzeb budowy i wdrożenia aplikacji informatycznych funkcjonujących w lokalizacji WCPR zakłada się implementację w SI WCPR roli Operatora oraz Koordynatora. uc struktura SI WCPR oraz SWD SI WCPR SWD dane Koordynator WCPR Operator WCPR Dyspozytor Rys. 1 Struktura SI WCPR Zgłoszenia rejestrowane przez Operatora, w ramach elektronicznego formularza, są następnie przekształcane w zdarzenia (po wcześniejszej analizie wystąpienia zgłoszeń podobnych) i przekazywane do właściwych służb do obsługi. Po stronie służb jest wyświetlany arkusz zdarzenia w ramach formatki dostępnej w SI WCPR, bądź formatki SWD służby jeśli służba dostosuje swoje SWD do udostępnionego w SI WCPR interfejsu API (system z wykorzystaniem mechanizmów Web Service i komunikacji w formacie XML). 7

8 Na diagramach poniżej przedstawiono główne role dla SI WCPR. uc SI WCPR - główne role SI WCPR Przygotuj decyzje i wytyczne Wizualizuj sytuacę Koordynator WCPR Zarządzaj komunikatami Sporządź analizy i raporty Operator WCPR Przyjmij i obsłuż zgłoszenie Zgłaszający Zgłoś zagrożenie Rys. 2 Główne role w SI WCPR Oprócz roli Operatora w ramach SI WCPR zaimplementowana zostanie funkcjonalność Koordynatora, zapewniająca w szczególności: przegląd bieżącej sytuacji w zakresie przyjęcia zgłoszeń i statusów obsługi zdarzeń, monitorowanie ilości i typów zgłoszeń na obszarze województwa, wymiany informacji i dyspozycji z innymi WCPR oraz inicjowanie procedur reagowania kryzysowego we współpracy z właściwym miejscowo Centrum Zarządzania Kryzysowego. 8

9 etap I 5. Wymagania szczegółowe 5.1 Wymagania funkcjonalne systemu SI WCPR WF.01 WF.02 WF.03 WF.04 WF.05 WF.06 WF.07 WF.08 WF.09 WF.10 WF.11 WF.12 WF.13 WF.14 Rejestracja zgłoszeń alarmowych (wypełnienie arkusza przyjęcia zgłoszenia oraz zapis audio rozmowy telefonicznej) na numer 112 oraz inne numery alarmowe, w szczególności 999, 998, 997. Zgłoszenie po określeniu jego autentyczności i analizie pod kątem zgłoszeń podobnych oraz identyfikacji numeru zgłaszającego, a także lokalizacji miejsca zgłoszenia i miejsca zdarzenia, przyjmuje status zdarzenia. Kojarzenie dodatkowych zgłoszeń z istniejącym zdarzeniem (zgłoszenie podobne). Przekazanie przyjętego zdarzenia, wraz z nagraniem audio skojarzonych z danym zdarzeniem zgłoszeń, do właściwych merytorycznie służb (Dyspozytora danej służby). Rejestracja zgłoszeń alarmowych za pomocą standardowego arkusza przyjęcia zgłoszenia, w szczególności w zakresie: a. Numer telefonu, b. Imię, c. Nazwisko, d. Lokalizacja zgłaszającego, e. Lokalizacja miejsca zdarzenia, f. Opis zdarzenia, g. Kategoria zdarzenia. Monitorowanie statusów obsługi wywołań alarmowych, w podziale na co najmniej: a. Oczekujące, b. Obsługiwane, c. Zakończone. Rejestracja czasu obsługi zgłoszenia alarmowego: a. Oczekiwania na przyjęcie zgłoszenia, b. Nawiązania połączenia, c. Przyjęcie zgłoszenia, d. Całkowity czas. Rejestracja treści zgłoszeń alarmowych, przy czym zapis ma mieć następujące cechy: ochrona przed niepowołanym dostępem, niemodyfikowalność, możliwość agregacji i centralnej archiwizacji, dostęp do rejestracji zagregowanych dla osób uprawnionych (czas przechowywania nagrań 24 miesiące). Przyjmowanie zgłoszeń od osób niepełnosprawnych. Zgłoszenia mogą być dokonane przy wykorzystaniu wiadomości tekstowych SMS, , faks. Przekazanie połączenia alarmowego do innego Operatora dowolnego WCPR. Automatyczne przydzielenie połączeń alarmowych wg zdefiniowanych reguł w ramach określonej grupy stanowisk operatorskich. Obsługa IVR (odgrywanie zapowiedzi słownych, przyjmowanie komend metodą tonową, przyjmowanie danych z klawiatury telefonu metodą tonową). Zestawianie połączeń alarmowych z innymi Operatorami WCPR (np. posługującymi się danym językiem obcym). Uniwersalny interfejs umożliwiający przekazanie przyjętych danych do systemów zewnętrznych względem WCPR, w szczególności systemów klasy SWD poszczególnych służb, w oparciu komunikaty w formacie XML, Dostęp Operatorów do uprzednio zarejestrowanych w ramach WCPR zgłoszeń

10 WF.15 WF.16 WF.17 WF.18 WF.19 WF.20 WF.21 WF.22 WF.23 WF.24 WF.25 WF.26 (nagrania audio, arkusz przyjęcia zgłoszenia), z uwzględnieniem uprawnień wynikających z lokalizacji, przynależności organizacyjnej i pełnionej roli. Odsłuch zapisanych rozmów z funkcją: przewijania, pauza, stop. Przeszukiwanie rozmów w oparciu o zadany: okres czasu, identyfikator, znacznik. Możliwość aktualizacji arkusza przyjęcia zgłoszenia w czasie obsługi zdarzenia i po jego zakończeniu (zdarzenie może być aktualizowane zarówno przez Operatora jak i Dyspozytorów poszczególnych służb). Automatyczna sygnalizacja potencjalnego ponownego przyjęcia zgłoszenia tego samego zdarzenia (identyfikacja na podstawie wybranych parametrów porównania w cyklu 24 godzinnym). Automatyczne/ręczne przesyłanie zdarzenia do Dyspozytorów danej służby. Automatycznie przydzielany identyfikator zgłoszenia i zdarzenia. Rejestracja i oznaczanie fałszywych (złośliwych) zgłoszeń alarmowych dla wszystkich zgłoszeń alarmowych przyjętych w ramach WCPR. Automatyczna sygnalizacja nadejścia połączenia potencjalnie fałszywego. Możliwość generowania raportów i statystyk zgłoszeń (w tym np. fałszywych). Możliwość wymiany informacji pomiędzy Operatorami a Dyspozytorami służb w czasie rzeczywistym z użyciem komunikatów aplikacyjnych. Odbiór i rejestracja potwierdzeń od Dyspozytorów służb o przyjęciu informacji o zdarzeniu. Podgląd kolejki oczekujących połączeń i możliwość wyboru połączenia poza kolejnością. WF.27 Definiowanie czasu, po przekroczeniu którego następuje10przekierowanie połączenia oczekującego do innego WCPR. WF.28 Dostęp do książki telefonicznej abonentów, listy konferencyjnej, bazy komunikatów dla obszaru obsługiwanego przez dany WCPR. WF.29 Możliwość zestawienia połączenia telekonferencyjnego z właściwą służbą (Dyspozytorem właściwej służby). WF.30 Podręczna baza teleadresowa. WF.31 Usprawnienia komunikacji poprzez zautomatyzowanie wybierania numerów WF.32 WF.33 WF.34 WF.35 WF.36 WF.37 WF.38 WF.49 WF.40 WF.41 WF.42 telefonów, zestawianie połączeń konferencyjnych, wsparcie przekazywania połączeń. Możliwość współpracy z bezprzewodowym zestawem mikrofonowo-słuchawkowym. Sygnalizacja przekroczenia czasu przewidzianego do obsługi zgłoszenia. Automatyczne nadawania priorytetów zgłoszeń, na podstawie kategorii zdarzenia. Przekazanie/zamknięcie obsługiwania zgłoszenia w dowolnym momencie jego obsługi. Możliwość przekazania służby/zmiany przez Operatora. Automatyczna historia obsługi zgłoszenia od momentu przyjęcia do momentu zamknięcia (z podaniem: dat, znaczników czasu, identyfikatorów osób, podjętych czynności, statusów jednostek ratowniczych, dokonywania sprawdzeń itp.). Administrowanie uprawnieniami użytkowników. Dodawanie/usuwanie stanowisk dostępowych. Utrzymywanie danych słownikowych/bibliotek. Automatyczna rejestracja czasu pracy użytkowników (kto, kiedy). Zapamiętywanie dla każdej zarejestrowanej korespondencji10zestawu metadanych obejmujących co najmniej: czas rozpoczęcia i czas zakończenia, numery telefonów 10

11 WF.43 WF.44 WF.45 WF.46 WF.47 WF.48 WF.49 uczestniczących w korespondencji, identyfikatorów stacji bazowych uczestniczących w korespondencji, kanałów na których była prowadzona korespondencja. Pełna dokumentacja obsługi zgłoszeń w zakresie rejestracji wszystkich kanałów komunikacji. Obsługa zgłoszeń obcojęzycznych. Dostęp do bazy danych wszystkich aktualnie pracujących Operatorów z podziałem na znajomość języków obcych oraz dostępność. Automatyczne generowanie propozycji wyboru podmiotów właściwych do obsługi zdarzenia. Zastosowanie mechanizmów filtrowania i sortowania danych. Dostęp do zasobów systemu za pomocą specjalizowanych konsol dyspozytorskich zainstalowanych na stanowiskach pracy (zasobów telefonii przewodowej i radiowej). Zapamiętywanie przez System indywidualnych ustawień danego użytkownika końcowego, tak aby mógł on po zalogowaniu się na innym stanowisku dostępowym (np. w momencie awarii stanowiska dostępowego) mieć swoje indywidualne ustawienia w niezmienionej formie Wymagania pozafunkcjonalne Wymagania ogólne NFO.01 NFO.02 Sterowanie funkcjami za pomocą skrótów klawiszowych. W przypadku awarii stacji roboczej obsługa powinna zostać przejęta automatycznie przez uprzednio określone stanowisko innego Operatora. NFO.03 Jednolity technologicznie sposób rejestracji wywołań alarmowych na numer 112 oraz inne numery alarmowe, w szczególności 999, 998, 997, w skali kraju. NFO.04 NFO.05 NFO.06 NFO.07 NFO.08 NFO.09 NFO.10 NFO.11 NF0.12 Możliwość korzystania z szerokiego pakietu usług dostępnych w technologii VoIP. Wymagania niefunkcjonalne dotyczące z rozmieszczenia infrastruktury sprzętowej będą wynikały z zaproponowanej przez wykonawcę aplikacji w ramach projektu technicznego architektury Systemu, uwzględniającej mechanizmy replikacji danych. Komunikacja (synchroniczna) pomiędzy WCPR a systemami dziedzinowymi służb (systemy klasy SWD) zrealizowana w oparciu o technologię Web-Service i komunikację w formacie XML. Ergonomia GUI dostosowana do maksymalnego skrócenia procesu wprowadzania danych. Architektura rozwiązania oparta o Ośrodki Krajowe i Ośrodki Regionalne. Część kliencka rozwiązania w technologii grubego klienta. Interfejs użytkownika w języku polskim. Komunikacja pomiędzy lokalizacjami Użytkowników Końcowych oraz Ośrodkami Krajowymi będzie realizowana poprzez infrastrukturę sieci OST 112. Zapewnienie architektury rozwiązania zapewniającej niezawodność systemu na 11

12 NF0.13 NFO.14 NFO.15 NFO.16 NFO.17 wymaganym poziomie SLA. Aplikacja rozwiązania w oparciu o SOA ( Service Oriented Architecture) Wydzielone moduły funkcjonalne muszą komunikować się miedzy sobą za pomocą WebService. Przyjęte rozwiązanie musi pozwalać na wdrożenie logiki biznesowej aplikacji w oparciu o zewnętrzną szynę komunikacyjną (wymiany informacji). System musi zapewniać obsługę standardowych sygnalizacji telekomunikacyjnych, co najmniej CAS, QSIG, ATS QSIG, DSS1, SS7, CAS/R2 MCF, ASS, FXO, FXS, E&M, SIP, H.323. Interfejs stanowisk dyspozytorskich SHDSL, E1/G.703 lub IP. Wykonawca zobowiązany jest do umieszczenia na dostarczonej infrastrukturze sprzętowej oznaczeń opisanych w Zasadach promocji projektów dla beneficjentów Programu Operacyjnego Infrastruktura i Środowisko tzn. wszelka dostarczona w ramach realizacji przedmiotu Zamówienia infrastruktura sprzętowa musi być opatrzona logotypami: Programu Operacyjnego Infrastruktura i Środowisko, Unia Europejska z odniesieniem słownym do Europejskiego Funduszu Rozwoju Regionalnego, logo Beneficjenta. Szablony oznaczeń zostaną przekazane Wykonawcy przez Zamawiającego. Bezpieczeństwo Pojęcia Poufność, Integralność, Rozliczalność i Niezaprzeczalność są rozumiane zgodnie z normą PN-I-02000:2002 Technika Informatyczna zabezpieczenia w systemach informatycznych. Poufność NFP.01 Zaimplementowanie funkcjonalności umożliwiającej przetwarzanie w Systemie informacji wrażliwych zgodnie z mi określonymi w odpowiednich aktach prawnych, w szczególności ustawie z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r. Nr 101, poz. 926) oraz rozporządzenia Rady Ministrów z dnia 28 października 2005 r. o minimalnych ch dla systemów teleinformatycznych (Dz. U. z 2005 r. Nr 212, poz. 1766). NFP.02 Zaimplementowanie mechanizmów umożliwiających dostęp do Systemu wyłącznie po jednoznacznym zidentyfikowaniu użytkownika końcowego przeprowadzonym w ramach procesu uwierzytelnienia. NFP.03 Zaimplementowanie mechanizmów zapewniających przechowywanie i przesyłanie haseł użytkowników wyłącznie w postaci zaszyfrowanej. NFP.04 Zaimplementowanie mechanizmu kontroli uprawnień opartego na rolach, umożliwiającego kontrolę poziomu dostępu do Systemu każdego użytkownika zarówno w zakresie dostępu do danych przetwarzanych w Systemie jak i korzystania z jego funkcjonalności. System uprawnień musi umożliwić ograniczenie dostępu wyłącznie do takich danych oraz takiego zakresu funkcji, jaki jest mu niezbędny do wykonania zadań wynikających z zakresu obowiązków. NFP.05 W przypadku szyfrowania wymagane jest zaimplementowanie mechanizmów kryptograficznych opartych na uznanych standardach otwartych. Moc wykorzystanych mechanizmów nie może być mniejsza od mocy zapewniana przez 3DES, AES-128, RSA-1024, SHA-1. NFP.06 Zabezpieczenie transmisji danych wrażliwych pomiędzy stacją użytkownika a serwerami umieszczonymi w węzłach technologicznych oraz pomiędzy współpracującymi systemami. Poziom zabezpieczenia transmisji nie może być mniejszy od poziomu zapewnianego przez protokół TLS z kluczem o długości 128 bitów. 12

13 Integralność NFI.01 Zaimplementowanie mechanizmów zapewniających integralność danych wykorzystywanych przy obsłudze zdarzeń i zgłoszeń w trakcie ich przesyłania pomiędzy SI WCPR a innymi systemami współpracującymi z nim w ramach SI PR. Poziom zapewnienia integralności nie może być mniejszy od poziomu zapewnianego przy użyciu protokołu TSL z kluczem 128 bit. NFI.02 Zaimplementowanie mechanizmów zapewniających integralność danych wykorzystywanych przy obsłudze zdarzeń i zgłoszeń w trakcie ich przesyłania pomiędzy węzłem technicznym systemu a stacją roboczą użytkownika. Poziom zapewnienia integralności nie może być mniejszy od poziomu zapewnianego przy użyciu protokołu TSL z kluczem 128 bit. Rozliczalność NFR.01 Zaimplementowanie mechanizmów umożliwiających rozliczalność działań użytkowników końcowych, które są bezpośrednio związane z obsługą zgłoszeń i zdarzeń. Wymagane jest rejestrowanie, co najmniej następujących informacji: data i czas zdarzenia, rodzaj zdarzenia, identyfikator użytkownika, identyfikator stacji użytkownika. NFI.02 Zaimplementowanie mechanizmów umożliwiających rozliczalność działań administracyjnych związanych z nadawaniem i odbieraniem uprawnień do tych usług realizowanych przez system, które są bezpośrednio związane z obsługą zgłoszeń i zdarzeń. Niezaprzeczalność NFN.01 Zaimplementowanie mechanizmów umożliwiających niezaprzeczalność działań związanych z przyjmowaniem zgłoszeń i obsługą zdarzeń w ramach SI PR. Ciągłość działania Dostępność NFC.01 Zaimplementowanie mechanizmów umożliwiających uruchomienie Systemu zgodnie z zaakceptowanych przez Zamawiającego projektem technicznym w oparciu o Ośrodek Krajowy i 20 Ośrodkach Regionalnych. NFC.02 Optymalizacja architektury Systemu pod kątem maksymalnego wyniesienia infrastruktury sprzętowo-programowej do Ośrodka Krajowego, z zachowaniem wymaganych poziomów dostępności Systemu. NFD.01 Zaimplementowanie mechanizmów umożliwiających zapewnienie dostępności usług Systemu wykorzystywanych do obsługi zgłoszeń i zdarzeń liczonej w okresach miesięcznych indywidualnie dla każdego ośrodka: : 13

14 a) dla Ośrodka Krajowego SLA na poziomie 99,99% (niedostępność miesięczna 4,38 min. / ośrodek), b) dla każdego Ośrodka Regionalnego SLA na poziomie 99% (niedostępność miesięczna 7,3h / WCPR) SLA ośrodka liczone jest jako suma czasu trwania niedostępności Systemu spowodowanej Awariami Krytycznymi, przy czym okna serwisowe związane z konserwacją/rekonfiguracją Systemu nie podlegają uwzględnianiu w obliczeniu SLA (termin i zakres prac realizowanych w ramach okna serwisowego wymaga uzyskania przez Wykonawcę uprzedniej akceptacji Zamawiającego). NFD.02 Zaimplementowanie mechanizmów umożliwiających użytkownikom Systemu kontynuację pracy w przypadku awarii jednego z węzłów technicznych z wykorzystaniem usług świadczonych przez inny węzeł. NFD.03 Zaimplementowanie mechanizmów umożliwiających przejęcie obsługi zgłoszeń alarmowych przez inny WCPR lub CPR. Pojemność i Wydajność NFPW.01 System przystosowany do przyjęcia i obsługi do zgłoszeń alarmowych rocznie. NFPW.02 Zaimplementowanie mechanizmów umożliwiających obsługę zwiększonej liczby zgłoszeń w okresach szczytów, przy założeniu, iż liczba ta nie przekroczy 10-cio krotności średniej liczby zgłoszeń wyliczonej na podstawie ww.. NFPW.03 Zaimplementowanie mechanizmów umożliwiających obsługę do 200 równoczesnych użytkowników Serwer komunikacyjny zintegrowanej łączności (20 sztuk) minimalne Opis SK.01 Rozumiany jako oprogramowanie dedykowane oraz platforma sprzętowa zapewniająca integrację środków korespondencji radiowej, telefonicznej oraz systemów informatycznych złożone z: SK.02 a. modułu Rejestracji, b. modułu Telefoniczny, c. serwera Zarządzania. Możliwość dołączenia do 255 konsol dyspozytorskich SK.03 Możliwość dołączenia do 255 obsługiwanych stacji bazowych (radiostacji, SK.04 radiotelefonów). 110 kanałów radiowych dostępnych w jednym czasie na konsoli dyspozytorskiej z następującym podziałem: a. 60 kanałów do pracy w trybie Rx/Tx, b. 50 kanałów do pracy w trybie Rx. SK.05 Współużytkowanie 1 kanału radiowego w trybie nadawczo-odbiorczym przez 32 SK.06 operatorów z uwzględnieniem priorytetów. Możliwość definiowania parametru liczby operatorów. Zapewnienie pracy ciągłej, co oznacza, iż zmiany konfiguracji, nie mogą powodować restartu sterowników i resynchronizacji połączeń. 14

15 Opis SK.07 Obsługa następujących typów radiotelefonów/systemów radiowych SK.08 SK.09 SK.10 SK.11 SK.12 SK.13 SK.14 SK.15 SK.16 (przystosowanych do zdalnego sterowania): a. Konwencjonalne VHF, b. TETRA, c. EDACS, d. Obsługa sygnalizacji SELECT5 oraz CTCSS. Funkcja systemowej rejestracji korespondencji: a. telefonicznej b. radiowej i. Numer abonenta A (abonent inicjujący połączenie), ii. Numer abonenta B (abonent wywoływany przez abonenta A), iii. Numer abonenta C (abonent osiągnięty przez abonenta A w przypadku przekierowania przez abonenta B), iv. Godzina rozpoczęcia nagrania, v. Czas trwania nagrania, vi. Identyfikator nagrania w systemie rejestracji serwera komunikacyjnego, i. Identyfikator radiotelefonu, ii. Numer kanału ustawionego w radiotelefonie i/lub częstotliwość, iii. Godzina rozpoczęcia nagrania, iv. Czas trwania nagrania, v. Identyfikator nagrania w systemie rejestracji serwera komunikacyjnego. Możliwość zdefiniowania tylko jednego serwera zarządzania dla kilku serwerów komunikacyjnych. Zapewnie w pełni cyfrowe przenoszenie akustyki pomiędzy konsolą dyspozytorską zintegrowanej łączności a modułem kontrolnym radiotelefonów. Możliwość pracy wszystkich elementów serwera komunikacyjnego bez dostępu do systemu nadzoru. W przypadku realizacji systemu w oparciu o łącza TDM E1 opóźnienie sygnału PTT (push-to-talk) wnoszone przez system musi być mniejsze niż 20ms. Możliwość sieciowania serwerów komunikacyjnych rozumiana jako możliwość dostępu do zasobów radiowych innego serwera komunikacyjnego zarówno z wykorzystaniem IP jak i E1. Serwer komunikacyjny powinien mieć możliwość współpracy z zewnętrznymi centralkami PABX używanymi, jak również możliwość zastąpienia istniejących centralek PABX. Obsługa następujących protokołów telekomunikacyjnych: a. DSS1 (2B+D, 30B+D), b. Qsig, c. SS7, d. H.323, e. SIP. Serwer komunikacyjny musi być wyposażony w następujące standardowe interfejsy telekomunikacyjne: a. styk A - przeznaczony do współpracy z traktem cyfrowym PCM30, b. styk C11 - przeznaczony do współpracy z dwutorowymi, końcowymi wyposażeniami telefonii nośnej, styki C21 i C22 - przeznaczone do współpracy z centralami elektromechanicznymi po jednotorowych (niewzmacnianych) łączach analogowych, 15

16 SK.17 SK.18 SK.19 SK.20 Opis c. styk Z - przeznaczony do współpracy z jednotorowym analogowym łączem abonenckim, d. styk V1 - przeznaczony do współpracy z łączem cyfrowym dostępu podstawowego (2B+D), e. styk V3 - przeznaczony do współpracy z traktem dostępu pierwotnego ( 0B+D), f. styk Stg - przeznaczony do współpracy z siecią taktyczną pracującą według zaleceń Eurocom D1, STANAG , STANAG 4578 ED.2. Dla kart portów cyfrowych łączy miejskich musi zostać zapewniona możliwość zmiany sygnalizacji (DSS1 / QSIG) tylko w sposób programowy bez konieczności wymiany pakietu. Musi zostać zapewniona wysoka niezawodności sprzętu poprzez zdublowanie krytycznych elementów systemu. Elementy redundantne muszą pracować w trybie gorącej rezerwy. Awaryjne przełączenie na system rezerwowy nie może powodować przerw w komunikacji. Interfejsy 2Mbit/s do współpracy z publiczną siecią telekomunikacyjną muszą spełniać parametry teletransmisyjne zgodne z zaleceniem ITU-T G.703. Serwer komunikacyjny musi udostępniać interfejs do współpracy z zewnętrznymi aplikacjami typu CTI wymagana jest obsługa protokołu, co najmniej typu TAPI. SK.21 Serwer komunikacyjny musi gwarantować możliwość wprowadzania zmian wynikających z rozwoju technologicznego oraz zapewniać możliwość rozbudowy, SK.22 SK.23 SK.24 zwiększenia pojemności i funkcjonalności w zależności od potrzeb Zamawiającego zarówno części dotyczącej oprogramowania jak i sprzętu. Konstrukcja serwera komunikacyjnego oraz jego oprogramowania powinna zakładać możliwość dostosowywania go do indywidualnych potrzeb Zamawiającego. Całość dokumentacji zarówno do serwera komunikacyjnego, jego interfejsów, wspieranych protokołów i oprogramowania musi być dostarczona w języku polskim. W ramach zsieciowanego systemu serwerów komunikacyjnych musi zostać zapewniony wspólny plan numeracji. SK.25 Serwer komunikacyjny musi zapewniać możliwość tworzenia wielu planów SK.26 numeracji, tj. tworzenie wirtualnej centrali PBX. Liczba wirtualnych grup nie mniej niż 10. Serwer komunikacyjny zintegrowanej łączności musi gwarantować możliwość tworzenia planu numeracji wewnętrznej i zewnętrznej zawierającej: numery wewnętrzne i zewnętrzne użytkowników wewnętrznych, numery wewnętrzne i zewnętrzne aparatów systemowych, kody dostępu do publicznych sieci telekomunikacyjnych. SK.27 Serwer komunikacyjny musi charakteryzować się strukturą umożliwiającą wynoszenie modułów funkcjonalnych w inne lokalizacje z wykorzystaniem sieci TDM oraz sieci IP. SK.28 SK.29 SK.30 Serwer komunikacyjny musi wybierać drogi obejściowe w przypadku uszkodzenia bądź przepełnienia drogi podstawowej. Wymagany jest dostęp do minimum 4 dróg obejściowych. Serwer komunikacyjny musi przekazywać do centralnego stanowiska zarządzania, na bieżąco, informację o wszystkich alarmach w systemie, raporty i inne dane o charakterze statystycznym. W ramach serwera komunikacyjnego wymagane zapewnienie centralki telefonicznej 16

17 Opis PABX (100 numerów) System rejestracji rozmów jako funkcjonalność systemu zintegrowanej łączności minimalne funkcjonalne SRR.01 System rejestracji rozmów musi umożliwiać rejestrację treści rozmów telefonicznych w postaci zapisu cyfrowego. SRR.02 SRR.03 SRR.04 SRR.05 SRR.06 SRR.07 SRR.08 System rejestracji rozmów powinien umożliwiać rejestrację wszystkich rozmów obsługiwanych przez serwer komunikacyjny oraz rejestrację rozmów wybranej grupy abonentów. System rejestracji rozmów powinien umożliwiać rejestrację rozmowy dowolnego abonenta oraz zdalny wybór abonenta nagrywanego ze stanowiska nadzoru, bez konieczności fizycznego krosowania na przełącznicy. System rejestracji rozmów musi umożliwiać rejestrację rozmowy z portów nie przechodzących przez centralę (analogowe łącza miejskie i ISDN BRA). System rejestracji rozmów musi zapewniać ochronę danych oraz kontrolę dostępu do zapisanych informacji na podstawie systemu haseł i klas uprawnień. System rejestracji rozmów powinien umożliwiać kontrolny odczyt danych (przez autoryzowanych użytkowników) w celu sprawdzenia stanu rejestracji. Łączny czas nagrań na wewnętrznym dysku rejestratora bez nadpisywania nie powinien być krótszy niż 48 godzin. System rejestracji rozmów musi umożliwić automatyczną i ręczną archiwizację nagrań na zewnętrznym serwerze nagrań. Dostęp do serwera poprzez sieć Ethernet. SRR.09 System rejestracji rozmów musi umożliwiać wykonanie kopii wybranych przez uprawnionego operatora fragmentów zapisu w postaci pliku audio w formacie.wav i.pcm. SRR.10 System rejestracji rozmów musi zapewniać archiwizację i odsłuch zapisanych danych, na co najmniej 3 wskazanych komputerach PC pracującym w sieci LAN, WAN. SRR.11 System rejestracji rozmów musi umożliwiać archiwizację nagrań pochodzących z różnych lokalizacji w jednym miejscu z wykorzystaniem sieci LAN/WAN. SRR.12 SRR.13 System rejestracji rozmów powinien umożliwiać odsłuch rozmów poprzez sieć LAN z użyciem dedykowanej aplikacji. System rejestracji rozmów musi umożliwiać administrowanie oraz zdalny nadzór poprzez sieć LAN/WAN. SRR.14 System rejestracji rozmów powinien opatrywać nagrania głosowe dodatkowymi informacjami tj.: 1. numer abonenta dzwoniącego (w ruchu przychodzącym), 2. numer wewnętrzny, 3. numer wybrany, 4. data i godzina połączenia, 5. czas trwania połączenia, 6. kierunek rozmowy, 7. numer linii (kanał), SRR.15 System rejestracji rozmów musi umożliwić wyszukiwanie nagrań co najmniej 17

18 SRR.16 SRR.17 według następujących kryteriów: 1. data i czas nagrania, 2. numer linii (kanał), 3. numer dzwoniący, 4. numer wewnętrzny, 5. kierunek połączenia. Musi zostać zapewniony brak bezpośredniego dostępu do sytemu plików dla systemu rejestracji rozmów (rejestratora). Musi być możliwy odsłuch rozmowy niezależnie od jej rejestracji w danym momencie. SRR.18 System rejestracji rozmów musi uniemożliwiać kasowanie plików również z poziomu uprawnień administratora. SRR.19 System rejestracji rozmów musi umożliwiać elastyczną rozbudowę, zwiększenie liczby rejestrowanych kanałów. SRR.20 System rejestracji rozmów musi zapewniać możliwość natychmiastowego raportowania o błędach lub awariach urządzeń wchodzących w skład systemu. SRR.21 W przypadku przerwy w zasilaniu system rejestracji rozmów po odzyskaniu zasilania musi samodzielnie powrócić do normalnej bezobsługowej pracy. SRR.22 SRR.23 System rejestracji rozmów powinien zostać dostarczony w obudowie umożliwiającej montaż w szafie przemysłowej 19. System rejestracji rozmów powinien być zasilany ze źródła gwarantowanego przez zasilacze (siłownię) centrali Stanowiska dostępowe Zaproponowane przez Wykonawcę rozwiązanie musi być kompatybilne z zapewnianymi przez Zamawiającego stanowiskami dostępowymi (stanowiska dostępowe wyposażone w karty mikroprocesorowe oraz czytniki kart mikroprocesorowych) o przedstawionych poniżej minimalnych ch. Dostawa stanowisk dostępowych nie wchodzi w zakres zamówienia Stanowiska dostępowe minimalne Element Opis SD.01 procesor minimum dwurdzeniowy zgodny z architekturą x86, który umożliwi SD.02 pamięć operacyjna uzyskanie przez oferowany komputer wydajności w teście BAPCO SYSMARK 2007 Preview wyników nie gorszych niż: 150 punktów (SYSmark 2007 Preview Rating) na podstawie tabeli opublikowanej: Uwaga! Jeżeli zaoferowany procesor wraz z proponowaną konfiguracją sprzętowo-programową nie jest ujęty w wyżej wymienionej tabeli, Wykonawca zobowiązany będzie do przeprowadzenia testów na własny koszt i udokumentowania Zamawiającemu, że oferowany procesor osiąga wymagany wynik punktowy w wymienionych testach. DDR2 lub DDR3 SDRAM, min. 2GB, 800MHz (z możliwością rozbudowy do 4 GB). SD.03 karta minimum 256 MB DDR3, wyposażona w dwa porty DVI 18

19 SD.04 SD.05 SD.06 Element grafiki karta dźwiękowa karta sieciowa dysk twardy Opis umożliwiające jednoczesną obsługę dwu monitorów LCD. Zamawiający nie dopuszcza rozwiązań opartych na kartach graficznych zintegrowanych z płytą główną. Karty graficzne muszą posiadać pełne wsparcie dla DirectX 10. co najmniej dwukanałowa. Zamawiający dopuszcza zastosowanie karty dźwiękowej zintegrowanej z płytą główną. LAN 10/100/ złącze RJ-45. Zamawiający dopuszcza zastosowanie karty sieciowej zintegrowanej z płytą główną. SATA, min. 320 GB, 7200rpm, min 8MB cache. SD.07 napęd DVD Dual Layer +/- RW wraz z zainstalowanym oprogramowaniem w języku polskim. SD.08 mysz optyczna PS/2 lub USB - 2 przyciski + rolka przewijania, podkładka. SD.09 klawiatura USB, w układzie QWERTY. SD.10 obudowa Midi lub Mini Tower, ATX. Wolne złącza: 4xUSB 2.0, wejście/wyjście audio, przednie złącza: 2x USB 2.0. SD.11 monitor 2 szt. LCD 19 : o rozdzielczość x900 SD.12 SD.13 *lub równoważne oprogramo wanie Listwa zasilająca o minimalny kontrast 8000:1 o monitor musi umożliwiać regulację wysokości, kąta pochylenia i obrotu o minimalny kąt widzenia w poziomie: 160 o minimalny kat widzenia w pionie: 160 o złącze DVI o monitor musi spełniać normy: TCO 03, ISO , EPA ENERGY STAR, TUV/GS o dostarczony monitor musi być wyposażony w komplet kabli: zasilający o długości min. 1,8 m oraz kabel sygnałowy o długości min. 1,8 m. Dostarczone stanowiska dostępowe muszą mieć zainstalowany system operacyjny, pakiet oprogramowania antywirusowego, a także czytniki o których mowa w pkt : o 64 bitowy system operacyjny w polskiej wersji językowej, jeden z wymienionych: o o MS Windows 7 Ultimate* lub MS Windows 7 Professional* lub MS Windows Vista Business plus Service Pack 2* program antywirusowy z modułem aktualizacji bazy sygnatur wirusów przez Internet przez okres co najmniej 2 lat w polskiej wersji językowej, oprogramowanie biurowe OpenOfficePl napięcie 230V, częstotliwość 50 Hz, o obciążenie dla jednego gniazda nie mniejsza niż 460 W, o liczba gniazd w listwie 5 o o o wyłącznik dwubiegunowy podświetlony zabezpieczenie prądowe bezpiecznik 10A 250V zabezpieczenie przepięciowe impuls 1x130J<10/1000us. 19

20 Karty mikroprocesorowe minimalne Opis KM.01 zgodne ze standardem ISO w następujących częściach: , , , KM.02 KM , , , wyposażone w procesor o pojemności min 72 kb. dostarczony sprzęt musi być fabrycznie nowy/nieużywany. Ponadto Wykonawca dostarczy, zainstaluje i uruchomi sprzęt na wskazanym stanowisku pracy. KM.04 zgodne ze Standardem Java Card KM.05 napięcie zasilania karty musi mieścić się w zakresie 1,62 5,5 V. KM.06 KM.07 KM.08 KM.09 KM.10 KM.11 KM.12 KM.13 KM.14 KM.15 KM.16 gwarantowana ilość cykli zapisu/kasowania dostarczonej karty nie może być mniejsza niż 500,000. karty wspierane przez algorytmy kryptograficzne i szyfrujące: o 3DES (ECB, CBC), o AES (128, 192, 256), o RSA up to 2048bit, o SHA-1. Długość generowanych kluczy kryptograficznych Cryptographic algorithms: 3DES (ECB, CBC), AES (128, 192, 256), RSA up to 2048bit,SHA-1. wsparcie dla MS terminal Services, Wsparcie dla logowania w domenie, Wsparcie dla pracy wieloaplikacyjnej. zapewniające wsparcie dla polityki haseł (PINÓW). zapewniające wsparcie dla szyfrowania komunikacji między kartą a komponentami systemu. zapewniające wsparcie dla różnych kodów PIN, PUK. zapewniające wsparcie dla historii PIN ów. zapewniające wsparcie dla konfigurowalnej polityki PIN i PUK. zapewniające wsparcie dla PKCS #11 dla: o Windows: Windows w wersji językowej polskiej lub angielskiej 2000SP6 / XP Proffesional SP2 lub SP3 / 2003 Server / Vista (Home, Business, Ultimate) wersje 32b i 64b / Windows 7 (Starter, Home, Premium, Professional, Ultimate) wersje 32b i 64b o Linux z jądrem 2.6: Ubuntu 7.X, 8.10, 9.10, opensuse 11.X, Red Hat Enterprise Linux 5, Debian Etch 4.0, 5.0.X. zapewniające wsparcie dla CSP dla systemu operacyjnego Windows: Windows w wersji językowej polskiej lub angielskiej 2000SP6 / XP Proffesional SP2 lub SP3 / 2003 Server / Vista (Home, Business, Ultimate) wersje 32b lub 64b / Windows 7 (Starter, Home, Premium, Professional, Ultimate) wersje 32b i 64b Czytniki kart mikroprocesorowych minimalne CKM.01 Opis czytnik kart mikroprocesorowych jako urządzenie wewnętrzne (wbudowane) 20

21 CKM.02 CKM.03 Opis komputera podłączony przez wewnętrzny port USB 2.0. zgodność z PC/SC. zgodność z ISO , , , , interfejs stykowy. CKM.04 sterowniki dla Windows XP, Vista, Windows 7. CKM.05 CKM.06 CKM.07 CKM.08 sterowniki dla systemu Linux. czytnik musi gwarantować poprawną pracę dla min cykli włożenia/wyjęcia karty. czytnik musi posiadać sygnalizację optyczną (np. dioda) akceptacji karty oraz pracy z kartą. Czytnik musi współpracować z oferowanymi kartami mikroprocesorowymi Konsole dyspozytorskie zintegrowanej łączności minimalne Zaproponowane przez Wykonawcę rozwiązanie musi być kompatybilne z zapewnianymi przez Zamawiającego konsolami dyspozytorskimi zintegrowanej łączności o przedstawionych poniżej minimalnych ch. Dostawa konsol dyspozytorskich zintegrowanej łączności nie wchodzi w zakres zamówienia. KD.01 KD.02 KD.03 KD.04 Opis Ekran dotykowy, o przekątnej min. 19 z regulacją położenia (podnoszenie/ opuszczanie i uchylanie). Łączność z serwerem komunikacyjnym zintegrowanej łączności za pomocą interfejsu SHDSL, E1/G.703 lub IP. Możliwość współpracy z bezprzewodowym zestawem mikrofonowo-słuchawkowym. Możliwość jednoczesnego prowadzenia rozmowy z wykorzystaniem łącza radiowego, telefonicznego interkomu oraz prowadzenia podsłuchu radiowego. KD.05 Funkcje umożliwiające obsługę połączeń radiowych i monitoringu środków radiowych: KD.06 KD.07 KD.08 KD.09 -obserwowanie stanu sygnałów PTT i SQUELCH w danym kanale radiowym, -rejestracja rozmów, -wybór kanału pracy radiostacji, -wybór trybu pracy (nasłuch, nadawanie-odbiór), -wybór grup w radiotelefonie. Funkcje umożliwiające obsługę środków łączności telefonicznej: -kolejkowanie zgłoszeń, -szybkie wybieranie połączenia konferencyjnego, -szybki dostęp do książki telefonicznej, -zestawianie połączeń pomiędzy abonentami, -rejestracja rozmów. Funkcje umożliwiające obsługę Interkomu. Zestaw rejestrujący lokalną korespondencję. Rejestracja rozmów radiowych powinna zawierać co najmniej: -ID radiotelefonu, 21