Architektura Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM)

Strona 1 /34 Załącznik nr 3 do OPZ Architektura Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM)

Strona 2 /34 SPIS TREŚCI SPIS RYSUNKÓW... 4 SPIS TABEL... 4 1. WSTĘP... 5 2. ZAŁOŻENIA ARCHITEKTURY SYSTEMU... 6 3. ARCHITEKTURA LOGICZNA SYSTEMU... 7 3.1. ARCHITEKTURA OGÓLNA... 7 3.2. OŚRODEK KRAJOWY... 8 3.2.1. Podstawowe centrum serwerowe Ośrodka Krajowego... 9 3.2.2. Zapasowe centrum serwerowe Ośrodka Krajowego... 10 3.3. OŚRODKI REGIONALNE... 10 3.4. PLATFORMA INTEGRACYJNA... 11 3.5. ARCHITEKTURA WDROŻENIA... 12 3.6. MECHANIZMY ZAPEWNIAJĄCE NIEZAWODNOŚĆ... 13 3.6.1. Ośrodek regionalny... 14 3.6.2. Ośrodek krajowy... 15 3.6.3. Mechanizmy replikacji danych.... 16 4. ARCHITEKTURA FIZYCZNA SYSTEMU... 18 4.1. INFRASTRUKTURA SERWEROWA... 18 4.1.1. Komunikacja APN z terminalami mobilnymi ZRM... 18 WYKONAWCA SWD PRM SWD PRM ZAGWARANTUJE ZAPEWNIENIE MIESIĘCZNEGO PAKIETU DANYCH DLA 32 SZTUK TERMINALI MOBILNYCH ORAZ URZĄDZEŃ GPS, W RAMACH SYSTEMU SWD PRM, PRZEPŁYWU DANYCH DLA URZĄDZEŃ MOBILNYCH... 18 4.2. USŁUGI DNS... 19 4.3. SERWERY RÓWNOWAŻENIA OBCIĄŻENIA SIECIOWEGO... 20 4.4. SERWERY VPN... 21 4.5. CENTRALNY SERWER LOGOWANIA... 21 4.6. USŁUGA POCZTOWA... 22 4.7. SYSTEMY OPERACYJNE... 22 4.8. OPROGRAMOWANIE DO WIRTUALIZACJI ZASOBÓW... 22 4.8.1. Wymagania dla serwerów wirtualnych w lokalizacjach krajowych... 23 4.8.2. Wymagania dla serwerów wirtualnych w OR... 25 5. DODATKOWE ŚRODOWISKA SYSTEMU... 27 6. BRAMKI GSM... 28 7. LISTA OPROGRAMOWANIA... 29 MODUŁ APLIKACJI DLA POTRZEB DYSPOZYTORÓW ZRM... 29 MODUŁ APLIKACJI DLA POTRZEB ZRM... 29 MODUŁ ANALITYCZNO-RAPORTOWY... 29

Strona 3 /34 MODUŁ DO ROZLICZEŃ Z NFZ... 29 MODUŁ SZPITALNYCH SIŁ I ŚRODKÓW... 29 OPROGRAMOWANIE APLIKACYJNE... 29 POZOSTAŁE OPROGRAMOWANIE STANDARDOWE... 29 8. STANOWISKA DOSTĘPOWE... 30 9. TERMINALE MOBILNE ZRM... 31 10. LISTA LOKALIZACJI... 32 10.1.1. Lokalizacje POK i ZOK... 32 10.1.2. Lokalizacje OR... 32 10.1.3. Lokalizacje Dyspozytorni... 32 10.1.4. Lokalizacje ZRM... 33 10.1.5. Rozmieszczenie stanowisk dostępowych... 33

Strona 4 /34 SPIS RYSUNKÓW Rysunek 1 Architektura systemu - rysunek ogólny... 6 Rysunek 2 Architektura ogólna... 7 Rysunek 3 Architektura logiczna Systemu... 8 Rysunek 4 Architektura logiczna OR... 11 Rysunek 5 Architektura wdrożenia dla OR, Dysponentów, ZRM i MS ZRM... 13 Rysunek 6 Architektura dla serwerów aplikacji i bazy danych w kontekście zapewnienia niezawodności Ośrodków Regionalnych... 14 Rysunek 7 Architektura dla mechanizmów integracyjnych w kontekście zapewnienia niezawodności... 16 Rysunek 8 Architektura replikacji danych w bazach danych... 17 Rysunek 9 Schemat systemu rysunek ogólny... 18 Rysunek 10 Połączenia sieci SAN w obrębie OK... Błąd! Nie zdefiniowano zakładki. Rysunek 11 Baza danych... 19 Rysunek 12 Usługa katalogowa... Błąd! Nie zdefiniowano zakładki. Rysunek 13 Usługa DNS... 20 Rysunek 14 Usługa równoważenia obciążenia sieciowego... 21 Rysunek 15 Usługa zapisu logów zdarzeń systemowych i aplikacyjnych... 22 Rysunek 16 Rozmieszczenie maszyn wirtualnych w POK... 24 Rysunek 17 Rozmieszczenie maszyn wirtualnych w ZOK... 25 Rysunek 18 Rozmieszczenie maszyn wirtualnych w OR... 26 Rysunek 19 Środowisko testowo szkoleniowe i developerskie... 27 SPIS TABEL Tabela 1 Zestawienie serwerów fizycznych w OK... Błąd! Nie zdefiniowano zakładki. Tabela 2 Zestawienie serwerów fizycznych w OR... Błąd! Nie zdefiniowano zakładki. Tabela 3 Podział dysków w macierzy HUS110 na grupy RAIDBłąd! Nie zdefiniowano zakładki. Tabela 4 Konfiguracja grup hostów na macierzach HUS110. Błąd! Nie zdefiniowano zakładki. Tabela 5 Zestawienie stref DNS i revdns... Błąd! Nie zdefiniowano zakładki. Tabela 6 Parametry bramki GSM... Błąd! Nie zdefiniowano zakładki. Tabela 7 Bilans mocy dla jednego serwera maszyn wirtualnych w OR.. Błąd! Nie zdefiniowano zakładki. Tabela 8 Bilans mocy dla pojedynczego Ośrodka Regionalnego... Błąd! Nie zdefiniowano zakładki. Tabela 9 Bilans mocy dla macierzy HUS110 w POK... Błąd! Nie zdefiniowano zakładki. Tabela 10 Bilans mocy dla jednego serwera maszyn wirtualnych w POK Błąd! Nie zdefiniowano zakładki. Tabela 11 Bilans mocy dla POK... Błąd! Nie zdefiniowano zakładki. Tabela 12 Lista lokalizacji OK... 32 Tabela 13 Lista lokalizacji OR wariant I OR w Warszawie... 32 Tabela 14 Lista lokalizacji OR wariant II OR w Krakowie... Błąd! Nie zdefiniowano zakładki. Tabela 15 Lista lokalizacji Dyspozytorni... 32

Strona 5 /34 1. Wstęp W niniejszym dokumencie zaprezentowane zostały założenia architektury logicznej i fizycznej Systemu.

Strona 6 /34 2. Założenia architektury systemu System SWD PRM będzie pracował w oparciu o n/w Lokalizacje: 1 Ośrodek Krajowym (OK), którego elementy rozmieszczone zostaną w dwóch niezależnych centrach serwerowych (POK i ZOK); 16 Ośrodków Regionalnych (OR); 43 Dyspozytornie; 32 Karetki ZRM. W lokalizacjach centrów serwerowych OK zlokalizowane zostaną Elementy Systemu środowiska produkcyjnego, deweloperskiego i szkoleniowo-testowego. W ośrodkach regionalnych OR rozlokowane zostaną regionalne centra przetwarzania danych zwane OR. Wszystkie centra przetwarzania danych (OK i OR) połączone zostaną za pomocą sieci OST 112 udostępnionej przez Zamawiającego. Klient aplikacji zwany Użytkownikiem końcowym będzie połączony z serwerem aplikacji uruchomionym w OR. Wymiana informacji pomiędzy OR a OK odbywać się będzie poprzez bazę danych, która jest wspólna dla wszystkich Ośrodków. Rysunek 1 przedstawia ogólną architekturę sprzętową systemu SWD PRM. Rysunek 1 Architektura systemu - rysunek ogólny

Strona 7 /34 3. Architektura logiczna systemu 3.1. Architektura ogólna Przyjęto założenie, iż architektura centrum przetwarzania danych SWD PRM zostanie oparta o Ośrodek Krajowy w ramach, którego wyodrębniono: podstawowe i zapasowe centrum serwerowe Ośrodka Krajowego, w sposób umożliwiający rozproszenie geograficzne, oraz szesnaście Ośrodków Regionalnych. Poglądowy schemat architektury przedstawia rysunek 2. cmp Architektura ogólna Podstawowe centrum serwerowe Ośrodek Krajowy replikacja danych Zapasowe centrum serwerowe Systemy zewnętrzne integrowane na poziomie OK Serwery platformy integracyjnej (klaster) ZRM replikacja danych replikacja danych Aplikacja kliencka SWD dla ZRM na terminal mobilny Ośrodek Regionalny 1 Ośrodek Regionalny 2 Systemy Serwer regionalny 1 zewnętrzne Serwer regionalny 2 integrowane na poziomie OR Dysponent 1 MS ZRM Dysponent 2 Aplikacja kliencka SWD Aplikacja kliencka SWD Aplikacja kliencka SWD Aplikacja kliencka SWD Rysunek 2 Architektura ogólna Ośrodki Regionalne - w szesnastu lokalizacjach, wskazanych przez Zamawiającego, uruchomiona zostanie infrastruktura sprzętowa i Oprogramowanie umożliwiające pracę Ośrodków Regionalnych systemu SWD PRM. Każdy z Ośrodków Regionalnych będzie udostępniał usługi dla Użytkowników końcowych na określonym obszarze geograficznym (Dyspozytornie podległe logicznie danemu Ośrodkowi Regionalnemu). Na poziomie Ośrodka Regionalnego zostaną uruchomione usługi umożliwiające realizację integracji z systemami zewnętrznymi w zakresie niezbędnym dla zapewnienia Funkcjonalności Krytycznej zdefiniowanej w Tomie 2 Projektu Technicznego. Ośrodek Krajowy w Ośrodku Krajowym zbudowana zostanie infrastruktura posiadająca logiczną kopię infrastruktury programowej każdego Ośrodka Regionalnego, zapewniającą nieprzerwane działanie SWD PRM w przypadku niedostępności dowolnego OR lub kilku OR. Ośrodek Krajowy będzie się składał z podstawowego centrum serwerowego (POK) oraz zapasowego centrum

Strona 8 /34 serwerowego (ZOK). W Ośrodku Krajowym będą znajdować się Serwery platformy integracyjnej, pracujące w ramach klastra niezawodnościowego uruchomionego w POK i ZOK. Serwery platformy integracyjnej stanowić będą warstwę pośredniczących serwerów, które udostępniać będą usługi zapewniające realizację integracji z systemami zewnętrznymi w wymaganym zakresie oraz zapewniać komunikację pomiędzy poszczególnymi elementami SWD PRM. Podstawowe centrum serwerowe Ośrodka Krajowego w POK zostanie zbudowana infrastruktura zapewniająca działanie SWD PRM w przypadku niedostępności jednego lub kilku Ośrodków Regionalnych. Zapasowe centrum serwerowe Ośrodka Krajowego lokalizacja ZOK będzie redundantną lokalizacją dla POK. W ZOK zostanie zbudowana infrastruktura zapewniająca działanie SWD PRM w przypadku niedostępności jednego lub więcej Ośrodków Regionalnych. 3.2. Ośrodek Krajowy Ośrodek Krajowy zostanie zlokalizowany w lokalizacjach POK i ZOK. cmp Architektura OK Ośrodek Krajowy Aplikacja kliencka przeglądu zdarzeń archiwalnych Aplikacja kliencka koordynatora Aplikacja kliencka administratora głównego Systemy zewnętrzne CSIOZ Centralny serwer aplikacji SWD Serwery aplikacji SWD Centralna baza danych Serwery baz danych. Produkcyjne bazy danych ETL Serwery raportowej bazy danych. Raportowe bazy danych. Usługa raportów Aplikacja kliencka systemu raportów Kadry i płace. Finanse i Księgowość Serwery platformy integracyjnej replikacja Serwery integracyjne ZRM, GPS Serwer komunikatora Centralny moduł mapowy, AVL Systemy szpitalne, szpitalny moduł apteki PLI CBD Usługa katalogowa, DNS. Ośrodki Regionalne Serwer baz danych Urządzenie GPS ZRM Aplikacja kliencka SWD dla ZRM na terminal mobilny SI WCPR, SI CPR LPR Serwery aplikacji SWD Aplikacja kliencka SWD Dysponent, MS ZRM Aplikacja kliencka komunikatora Wojewódzkie serwery komunikacyjne Rysunek 3 Architektura logiczna Systemu Powyższy schemat przedstawia architekturę logiczną Systemu.

Strona 9 /34 3.2.1. Podstawowe centrum serwerowe Ośrodka Krajowego W ramach Podstawowego centrum serwerowego Ośrodka Krajowego wyodrębniono następujące komponenty: Serwery aplikacji SWD - Serwery aplikacji odpowiedzialne będą za realizowanie logiki biznesowej aplikacji w zakresie modułów: moduły aplikacji dla potrzeb Dyspozytorów ZRM (moduł dyspozytornia, moduł grafik, moduł apteka), moduły pomocnicze (moduł szpitalny sił i środków), moduły koordynatorskie (moduł koordynatora OR), moduły administracyjne (moduł konfiguracji Dysponenta), moduł rozliczeń z NFZ oraz dostęp do baz danych. W sytuacji niedostępności jednego z OR, serwer aplikacji SWD PRM znajdujący się w POK lub ZOK przejmie rolę serwera aplikacji Ośrodka Regionalnego. Serwery baz danych w ramach, których zostaną udostępnione wszystkie bazy danych wymagane na poziomie Ośrodka Krajowego: Centralna baza danych, Produkcyjne bazy danych, Raportowe bazy danych. Centralna Baza Danych będzie przechowywała dane globalne dla systemu i udostępniała dane archiwalne. W ramach Produkcyjnych baz danych zostaną utworzone niezależne instancje bazy danych dla każdego z Ośrodków Regionalnych, które będą przechowywały kopię danych z odpowiadającego im Ośrodka Regionalnego. Każda instancja bazy danych będzie zasilana danymi z właściwego Ośrodka Regionalnego poprzez mechanizm replikacji danych. Grupa serwerów baz danych dla danego Ośrodka Regionalnego znajdująca się w Ośrodku Regionalnym oraz w POK i ZOK będzie stanowić klaster wysokiej dostępności. Dodatkowo w ramach Produkcyjnych baz danych zostaną utworzone niezależne instancje baz danych wymagane przez mechanizmy platformy integracyjnej, serwer komunikatora oraz pomocnicze bazy danych. Serwery raportowej bazy danych udostępniać będą dane na potrzeby oprogramowania raportowego. Zostanie uruchomiona jedna instancja bazy raportowej, która będzie zasilana danymi z baz Ośrodków Regionalnych znajdujących się w POK. Dane pomiędzy produkcyjną a raportową bazą danych przenoszone będą z wykorzystaniem mechanizmów ETL. Dodatkowo w ramach serwerów raportowej bazy danych zostanie uruchomiona część serwerowa modułu analityczno raportowego. Centralna baza danych - wykorzystywana będzie do udostępniania danych archiwalnych, centralne zarządzanie danymi globalnymi (konfiguracja i słowniki), udostępnianie danych ze wszystkich Ośrodków Regionalnych dla usług na poziomie Ośrodka Krajowego np.: związanymi z przekazywaniem lokalizacji GPS do Centralnego Modułu Mapowego, kopiowaniem danych do bazy raportowej, sprawną koordynacją akcji na granicy ośrodków oraz obsługą funkcjonalności dla koordynatora (wyświetlanie statusu wszystkich zespołów ratownictwa medycznego oraz statusów zgłoszeń i zdarzeń będących w trakcie realizacji). Serwery platformy integracyjnej Funkcjonalności SWD PRM realizujące integrację z systemami zewnętrznymi: AVL, Centralnym Modułem Mapowym, szpitalami oraz zapewniające komunikację pomiędzy serwerami w Ośrodkach Regionalnych. Centralny serwer aplikacji SWD - na serwerze tym uruchomiona zostanie aplikacja udostępniająca logikę dla modułu koordynatorskiego, modułu administracyjnego (moduł zarządzania konfiguracją globalną oraz dla mechanizmów przeglądu danych archiwalnych z wszystkich OR. Aplikacja kliencka SWD część kliencka oprogramowania SWD, która będzie realizowała funkcjonalności modułów: moduły aplikacji dla potrzeb Dyspozytorów ZRM (moduł dyspozytornia, moduł grafik, moduł apteka), moduły pomocnicze (moduł szpitalny sił i środków), moduły koordynatorskie (moduł koordynatora OR), moduły administracyjne (moduł konfiguracji Dysponenta), modułu aplikacji dla potrzeb ZRM.

Strona 10 /34 Usługa katalogowa, DNS. Serwery, które będą realizowały funkcjonalność obsługi mechanizmów centralnego zarządzania użytkownikami, oraz DNS. Aplikacja kliencka SWD dla ZRM oprogramowanie przeznaczone dla pracowników ZRM realizujące funkcjonalności modułu aplikacji dla potrzeb ZRM. Integracja ZRM - serwery warstwy integracyjnej, które będą realizowały logikę integracji serwera systemu SWD z aplikacjami mobilnymi dla potrzeb ZRM. Integracja GPS - serwery na potrzeby integracji urządzeń lokalizacyjnych GPS z usługą AVL będącą częścią Centralnego Modułu Mapowego. Klient systemu raportów cześć kliencka aplikacji, która będzie realizowała funkcjonalności modułu analityczno - raportowego. Serwer komunikatora tekstowego, Aplikacja kliencka komunikatora tekstowego. Serwerowa i kliencka część oprogramowania, która będzie realizowała funkcjonalność modułów komunikatora (moduł komunikatora, moduł komunikatora ZRM, moduł komunikatora dla koordynatora). Aplikacja kliencka koordynatora - aplikacja, która będzie zapewniała w szczególności: monitorowanie działalności jednostek pogotowia ratunkowego na terenie całego kraju, dostęp do danych o siłach i środkach i stanie aktualnie realizowanych zdarzeń, mechanizmy koordynacji i wymiany informacji. Aplikacja kliencka administratora głównego, aplikacja kliencka przeglądu zdarzeń archiwalnych aplikacja, która będzie zapewniała funkcjonalność wprowadzania i modyfikacji danych konfiguracyjnych oraz słowników, które są wspólne dla wszystkich Ośrodków Regionalnych. Aplikacja zapewniać będzie również dostęp w trybie online do danych archiwalnych ze wszystkich Ośrodków Regionalnych. 3.2.2. Zapasowe centrum serwerowe Ośrodka Krajowego Dla zapewnienia ciągłości działania i dostępności usług Ośrodka Krajowego, w przypadku niedostępności lokalizacji POK, zostanie utworzona zapasowa lokalizacja - ZOK, w której będą znajdowały się redundantne dla POK serwery o konfiguracji i parametrach tożsamych dla POK. 3.3. Ośrodki Regionalne Przewiduje się wyposażenie szesnastu Ośrodków Regionalnych w Elementy Systemu SWD PRM. Zadaniem każdego z Ośrodków Regionalnych będzie zapewnienie ciągłości pracy Systemu SWD PRM nawet w przypadku niedostępności usług Ośrodka Krajowego. Architektura Ośrodka Regionalnego została zaprezentowana na poniższym rysunku.

Strona 11 /34 cmp Architektura OR Ośrodek Krajowy Systemy zewnętrzne Serwery platformy integracyjnej LPR SI WCPR, SI CPR Wojewódzkie serwery komunikacyjne Ośrodek Regionalny Usługa katalogowa, DNS. Serwery aplikacji SWD Serwer baz danych Dysponent, MS ZRM Aplikacja kliencka SWD Rysunek 4 Architektura logiczna OR W ramach Ośrodka Regionalnego wyodrębniono następujące komponenty: Serwer aplikacji SWD, w ramach, którego uruchomione zostaną elementy Oprogramowania odpowiedzialne za realizowanie logiki biznesowej aplikacji (zakres obsługiwanych modułów zgodny z opisem dla serwerów aplikacji SWD w punkcie dotyczącym POK) oraz dostęp do bazy danych. Serwer aplikacji Ośrodka Regionalnego udostępniał będzie usługi dla części klienckiej Oprogramowania eksploatowanego w Dyspozytorniach, karetkach oraz MS ZRM-ach podległych danemu Ośrodkowi Regionalnemu. Serwer baz danych, w ramach, którego gromadzone będą dane operacyjne z Dyspozytorni podległych danemu OR. Usługa katalogowa, DNS, Serwery, które będą udostępniały funkcjonalności związane z obsługą mechanizmów zarządzania użytkownikami oraz DNS. Pozostałe elementy, przedstawione na rysunku kolorem szarym, stanowią elementy zewnętrzne w stosunku do systemu SWD PRM, z którymi będzie realizowana integracja na poziomie Ośrodków Regionalnych. 3.4. Platforma integracyjna W ramach systemu SWD PRM wdrożona zostanie platforma integracyjna udostępniająca interfejsy do systemów zewnętrznych względem SWD PRM oparta o: szynę danych ESB udostępniającej usługi z poziomu Ośrodka Krajowego, która będzie pośredniczyć w części komunikacji między systemem SWD PRM i systemami zewnętrznymi; usługi integracyjne udostępniane bezpośrednio z serwerów aplikacyjnych OR;

Strona 12 /34 Z wykorzystanie szyny ESB realizowana będzie integracja SWD PRM w n/w systemami zewnętrznymi: systemy szpitale, systemy kadrowo-płacowe i finansowo-księgowe, CSiOZ, UMM i AVL/APL, PLI CBD, NFZ Z wykorzystaniem usług integracyjnych udostępnianych bezpośrednio z serwerów aplikacyjnych w OR realizowana będzie integracja z n/w systemami zewnętrznymi: SI WCPR/SI CPR, LPR,, wojewódzkie serwery komunikacyjne PZŁ SI WCPR. Szyna danych zbudowana zostanie w oparciu o narzędzie open-source Mule ESB w wersji Community i składać się będzie z wydzielonych i konfigurowalnych adapterów komunikacyjnych (wyjściowych i wejściowych). Mule ESB pozwala na utworzenie adapterów obsługujących różne kanały komunikacyjne (REST, SOAP / Web Services, JDBC, JMS, HTTP/S, FTP/S, Email / SMTP). W przypadku SWD PRM komunikacja między ESB a systemami zewnętrznymi oraz pomiędzy serwerami aplikacyjnymi udostępniającymi usługi dla platformy integracyjnej, będzie realizowana za pomocą dedykowanych interfejsów wyspecyfikowanych w Tomie 2 Projektu Technicznego. Adaptery wyjściowe/wejściowe odpowiedzialne będą za buforowanie, weryfikację integralności danych, weryfikację informatyczną komunikatów (w przypadku Webservice zgodność z definicją XSD i WSDL). Komunikaty wysyłane przez systemy zewnętrzne do SWD PRM będą odbierane przez ESB i na podstawie informacji zawartych w samych komunikatach, zostaną skierowane do właściwych Ośrodków Regionalnych. Podobnie komunikaty wysyłane przez Ośrodki Regionalne będą przekazywane przez ESB do odpowiednich systemów zewnętrznych. Zastosowanie szyny danych ESB w celu pośredniczenia w komunikacji pozwoli uniknąć wiązania każdego systemu zewnętrznego z każdym Ośrodkiem Regionalnym, dzięki czemu zostanie uproszczona konfiguracja, a także wprowadzanie zmian w komunikacji. 3.5. Architektura wdrożenia Rysunek 5 przedstawia architekturę posadowienia poszczególnych modułów logicznych systemu na infrastrukturze sprzętowej w Ośrodkach Regionalnych, Dyspozytorni i Karetkach ZRM. Analogiczna architektura posadowienia elementów systemu dla OK została zaprezentowana w rozdziale 4.8.1.

Strona 13 /34 cmp Diagram wdrożenia OR OR / Dyspozytornia «device» Stanowisko modułu aplikacji dla potrzeb Dyspozytorów ZRM «executionenvironment» Aplikacja kliencka SWD (moduł aplikacji dla potrzeb Dyspozytorów ZRM) «executionenvironment» Aplikacja kliencka modułu komunikatora OR «device» Serwer 1 (maszyny wirtualne) «executionenvironment» Serwer bazy danych 1 «executionenvironment» Serwer aplikacji 1 «device» Czytnik kart inteligentnych «device» Stanowisko modułu koordynatorskiego «executionenvironment» Aplikacja kliencka SWD (moduł koordynatora) «device» Macierz dyskowa «device» Serwer 2 (maszyny wirtualne) «executionenvironment» Serwer bazy danych 1 «executionenvironment» Serwer aplikacji 2 «executionenvironment» Aplikacja kliencka modułu komunikatora «device» Czytnik kart inteligentnych «device» Stanowisko modułu administracyjnego «executionenvironment» Aplikacja kliencka SWD (moduł konfiguracji Dysponenta, moduł konfiguracji ZRM) «executionenvironment» Aplikacja kliencka SWD (moduł zarządzania konfiguracją globalną) «executionenvironment» Czytnik kart inteligentnych «device» Stanowisko pomocnicze «executionenvironment» Aplikacja kliencka SWD (moduł szpitalnych sił i środków) «executionenvironment» Aplikacja kliencka systemy raportów (moduł analityczno-raportowy) «executionenvironment» Aplikacja kliencka modułu rozliczeń z NFZ «executionenvironment» Czytnik kart inteligentnych Karetki «device» Tablet «executionenvironment» Aplikacja dla potrzeb ZRM «executionenvironment» Aplikacja kliencka modułu komunikatora Rysunek 5 Architektura wdrożenia dla OR, Dysponentów, ZRM i MS ZRM 3.6. Mechanizmy zapewniające niezawodność Oczekiwany poziom niezawodności (zgodnie z przyjętym SLA) zostanie osiągnięty poprzez zastosowanie serwerów równoważenia obciążenia sieciowego. Zadaniem serwerów równoważenia obciążenia sieciowego będzie: monitorowanie podległych serwerów aplikacyjnych pod kątem poprawności działania serwer równoważenia obciążenia sieciowego odpytuje serwer aplikacji, i jeżeli w odpowiedzi otrzyma status wskazujący na niepoprawną pracę wyłącza go z produkcji nie kierując na niego ruch sieciowy; utrzymywanie klastrowego wirtualnego adresu VIP za realizację wysokiej dostępności klastrowego adresu VIP odpowiada protokół VRRP, który w przypadku

Strona 14 /34 wykrycia niedostępności jednego z serwerów równoważenia obciążenia sieciowego wyśle komunikat do przełącznika Zamawiającego przejmując działanie uszkodzonego serwera równoważenia obciążenia sieciowego. Do poprawnej pracy protokołu VRRP wymagane jest praca redundantnych serwerów równoważenia obciążenia sieciowego w warstwie L2 modelu OSI; balansowanie ruchu pomiędzy poprawnie działające serwery aplikacyjne jest realizowane przy pomocy oprogramowania LVS (z ang. linux virtual server), terminowanie połączeń SSL dodatkowym zadaniem serwerów równoważenia obciążenia sieciowego będzie terminowanie ruchu SSL odciążając tym samym serwery aplikacyjne, powiadamianie Administratora systemu SWD PRM o zdarzeniach za pomocą komunikatów e-mail. Wszystkie lokalizacje są połączone ze sobą w warstwie L2 modelu OSI, co umożliwia wpięcie urządzeń w różnej lokalizacjach (load balancer) pracjących w trybie wysokiej dostępności w oparciu o protokół VRRP. 3.6.1. Ośrodek regionalny cmp Architektura niezawodnościowa - ośrodki regionalne OR 1 OR 2 Serwer aplikacji - JBoss Serwer bazy danych - MySQL Serwer bazy danych - MySQL Serwer aplikacji - JBoss Węzeł 1 (podstawowy) Węzeł 1 (podstawowy) Węzeł 1 (podstawowy) Węzeł 1 (podstawowy) replikacja replikacja POK ZOK POK ZOK Serwer bazy danych - MySQL dla OR 1 Serwer bazy danych - MySQL dla OR 1 Serwer bazy danych - MySQL dla OR 2 Serwer bazy danych - MySQL dla OR 2 replikacja replikacja Węzeł 2 (zapasowy 1) Węzeł 3 (zapasowy 2) Węzeł 3 (zapasowy 2) Węzeł 2 (zapasowy 1) Serwer aplikacji - JBoss dla OR 1 Serwer aplikacji - JBoss dla OR 1 Serwer aplikacji - JBoss dla OR 2 Serwer aplikacji - JBoss dla OR 2 Węzeł 2 (zapasowy 1) Węzeł 3 (zapasowy 2) Węzeł 3 (zapasowy 2) Węzeł 2 (zapasowy 1) Połączenie failover 1 Połączenie failover 2 Połączenie failover 2 Połączenie failover 1 Dysponenci, lokalizacje wyniesione - OR 1 Dysponenci, lokalizacje wyniesione - OR 2 Połączenie podstawowe Aplikacja kliencka SWD Aplikacja kliencka SWD Połączenie podstawowe Rysunek 6 Architektura dla serwerów aplikacji i bazy danych w kontekście zapewnienia niezawodności Ośrodków Regionalnych Rysunek 6 prezentuje architekturę związana z zapewnieniem niezawodności dla serwerów aplikacji oraz serwerów baz danych dla OR. Zostanie wykorzystane rozwiązanie

Strona 15 /34 klastra z węzłami podstawowymi znajdującymi się w OR oraz węzłami zapasowymi znajdującymi się w obu centrach serwerowych Ośrodka Krajowego. W przypadku niedostępności serwera aplikacji i / lub serwera bazy danych w OR następuje przełączenie wszystkich aplikacji klienckich oraz systemów zewnętrznych komunikujących się bezpośrednio z serwerem aplikacji danego Ośrodka Regionalnego na podstawowe lub zapasowe centrum serwerowe Ośrodka Krajowego. Przed przełączeniem na poziom Ośrodka Krajowego w pierwszej kolejności zostanie wykorzystana redundancja serwerów zapewniana na poziomie Ośrodka Regionalnego. 3.6.2. Ośrodek krajowy Na rysunek 7 została zaprezentowana architektura związana z zapewnieniem niezawodności dla mechanizmów integracyjnych w kontekście zapewnienia niezawodności Ośrodka Krajowego oraz Ośrodka Regionalnego w zakresie integracji z systemami zewnętrznymi. Serwery warstwy integracyjnej zostaną uruchomione w ramach klastra składającego się z dwóch węzłów po jednym w ramach każdego z Ośrodków Krajowych (POK i ZOK). Ruch pomiędzy poszczególnymi węzłami będzie rozdzielany przez serwer równoważenia obciążenia. W przypadku niedostępności POK funkcjonalność systemu będzie realizowana przez ZOK.

Strona 16 /34 cmp Architektura niezawodnościowa -ośrodki krajowe OR X WebService - połączenie podstawowe z OR WebService - połączenie podstawowe Architektura::PLI CBD Wojewódzkie serwery komunikacyjne Podstawowe Serwer aplikacji - JBoss Węzeł 1 (podstawowy) MySQL Węzeł podstawowy SI WCPR WebService połączenie zapasowe z POK, ZOK Zapasowe POK i ZOK POK MySQL dla OR X Węzeł zapasowy Połączenie podstawowe ZOK MySQL dla OR X Węzeł zapasowy Połączenie zapasowe POK i ZOK Połączenie podstawowe Aplikacja NFZ WebService połączenie zapasowe POK, ZOK Serwer aplikacji - JBoss dla OR X Serwer aplikacji - JBoss dla OR X Węzeł zapasowy Węzeł zapasowy Systemy zewnętrzne np: CSIOZ, LPR Podstawowe / zapasowe Połączenie zapasowe x Połączenie zapasowe x WebService. Podstawowe / zapasowe Kadry i płace, księgowość Węzeł 1 Serwery platformy integracyjnej - klaster Węzeł 2 WebService. Podstawowe / zapasowe Centralny moduł mapowy - AVL WebService. Podstawowe / zapasowe Szpitale Węzeł 1 Serwery integracyjne GPS, ZRM - klaster Węzeł 2 Podstawowe / zapasowe Aplikacja mobilna - ZRM Podstawowe / zapasowe Lokalizator GPS Rysunek 7 Architektura dla mechanizmów integracyjnych w kontekście zapewnienia niezawodności W przypadku niedostępności węzła podstawowego serwera platformy integracyjnej nastąpi przełączenie wszystkich systemów korzystających z usług platformy na węzeł zapasowy znajdujący się w ZOK. Analogicznie jak dla scenariusza opisanego w poprzednim punkcie dotyczącym OR w przypadku niedostępności podstawowego węzła serwera aplikacyjnego lub serwera bazy danych na poziomie OR nastąpi przełączenie wszystkich usług do węzła zapasowego znajdującego się w Ośrodku Krajowym. 3.6.3. Mechanizmy replikacji danych. System replikacji danych składa się z szeregu komponentów w oparciu, o które zakłada się pracę systemu. Rysunek 8 przedstawia schemat replikacji danych pomiędzy ośrodkami.

Strona 17 /34 Rysunek 8 Architektura replikacji danych w bazach danych W systemie SWD PRM kwestie replikacji danych należy rozpatrywać w trzech płaszczyznach: Replikacja pomiędzy bazą danych znajdującą się w OR, a węzłami bazy danych OR znajdującymi się w POK i ZOK. W czasie normalnej pracy (w konfiguracji podstawowej) dane z OR będą replikowane do pierwszego z centrów serwerowych Ośrodka Krajowego, a następnie z pierwszego centrum Ośrodka Krajowego do drugiego centrum serwerowego Ośrodka Krajowego. Replikacja będzie wykorzystywała mechanizmy replikacji dostępne w ramach serwera bazy danych MySQL. Replikacja pomiędzy centralną bazą danych znajdującą się w POK, a centralną bazą danych znajdującą się w ZOK. Replikacja ta będzie wykorzystywała mechanizmy replikacji dostępne w ramach serwera bazy danych MySQL i będzie obejmowała wszystkie dane przechowywane w centralnej bazie danych. Mechanizm replikacji danych globalnych (konfiguracja, słowniki) pomiędzy centralną bazą danych, a bazami w Ośrodkach Regionalnych. Dane, które są globalne dla systemu (konfiguracja, słowniki itp.) będą wprowadzane i modyfikowane w Ośrodku Krajowym w centralnej bazie danych (poprzez aplikację dostępną na poziomie centralnego serwera aplikacji), a następnie replikowane do baz danych w poszczególnych Ośrodkach Regionalnych. Replikacja tych danych zostanie zrealizowana poprzez warstwę serwerów platformy integracyjnej. Nie będzie możliwa edycja tych danych w Ośrodkach Regionalnych. Opisane mechanizmy replikacji danych będą stanowiły część rozwiązania zapewniającego niezawodność i wysoką dostępność systemu SWD PRM.

Strona 18 /34 4. Architektura fizyczna systemu 4.1. Infrastruktura serwerowa Rysunek 9 Schemat systemu rysunek ogólny 4.1.1. Komunikacja APN z terminalami mobilnymi ZRM Wykonawca SWD PRM SWD PRM zagwarantuje zapewnienie miesięcznego pakietu danych dla 32 sztuk terminali mobilnych oraz urządzeń GPS, w ramach systemu SWD PRM, przepływu danych dla urządzeń mobilnych Bazy danych systemu SWD PRM będą pracowały w oparciu o oprogramowanie MySQL 5.6 Rozproszona Baza Danych i Microsoft SQL 2012 dla celów raportowych nazywana bazą raportową. Obie bazy dostarczone są przez wykonawcę, jako oprogramowanie standardowe oprogramowanie bazodanowe. Rozproszona baza danych będzie pracowała w architekturze rozproszonej w trybie wysokiej dostępności pomiędzy lokalizacjami krajowymi i lokalizacjami regionalnymi. Instancja bazodanowa będzie składała się z kilku elementów. Bazy danych w lokalizacjach centralnych odpowiedzialne za przechowywanie i przetwarzanie zgromadzonych danych. Dane w lokalizacjach centralnych przechowywane będą w 4 kopiach na szybkich dyskach SSD zapewniających wymaganą w SIWZ wydajność. Zasilane bazy odbywać się przy pomocy pracującego redundantnie interfejsu zmian. Bazy danych w lokalizacjach regionalnych odpowiedzialne za lokalne przechowywanie swojej kopii bazy danych i udostępnienie jej serwerom aplikacyjnym. Bazy regionalne będą mieć skonfigurowaną replikacje jednokierunkową pobierającą dane z interfejsu zmian.

Strona 19 /34 Interfejs zmian to bazy pracujące redundantnie, których zadaniem będzie przechowywanie wszystkich zmian do czasu aż nie zostaną zapisane we wszystkich wymaganych bazach danych znajdujących się w lokalizacjach krajowych i lokalizacjach regionalnych. Bazy danych interfejsu zmian nie posiadają pełnej kopii danych system SWD PRM, a jedynie zmiany, które nie zostały zapisane w wymaganych bazach. W przypadku niedostępności serwera, dane w bazie zmian pozostają na dysku i zostaną rozpropagowane po przywróceniu serwera do pracy produkcyjnej. Do tego czasu funkcjonalność interfejsu zmian przejmuje redundantnie pracujący serwer zapobiegając sytuacji niedostępności usług. Interfejs proxy to bazy danych pracujące redundantnie, których zadaniem będzie przyjmowanie danych wysyłanych z lokalizacji regionalnych i przenoszenie ich do interfejsu zmian. Baza raportowa wykorzystywana będzie do przetwarzania zgromadzonych informacji w centralnej bazie danych. Baza raportowa będzie używała niezależnej przestrzeni dyskowej, co zapewni ochronę przed wpływem bazy raportowej na pozostałe elementy systemu w kontekście obciążenia podsystemów dyskowych. Rysunek 10 Baza danych 4.2. Usługi DNS Usługi DNS będą skonfigurowane tak, aby użytkownik za pomocą protokołu kerberos mógł uaktualnić swój wpis w odpowiedniej strefie. Usługi DNS będą pracowały w trybie master/master w każdej lokalizacji. Serwer posiadający możliwość edycji rekordów SOA będzie znajdował się w lokalizacji POK.

Strona 20 /34 Rysunek 11 Usługa DNS 4.3. Serwery równoważenia obciążenia sieciowego Usługa równoważenia obciążenia sieciowego będzie pracować pod kontrolą oprogramowania keepalived dostarczonego przez Wykonawcę. Usługa równoważenia obciążenia sieciowego będzie odpowiedzialna za realizację funkcjonalności DR, wymaganej przez Zamawiającego, niezbędnej do zapewnienia przez Wykonawcę odpowiedniego poziomu SLA dla systemu SWD PRM. Mechanizmem zastosowanym do realizacji DR przez usługę równoważenia obciążenia sieciowego jest protokół VRRP. Usługa keepalived posiada dodatkowy interfejs na potrzeby komunikacji wewnątrz klastrowej. Usługa równoważenia obciążenia sieciowego będzie miała skonfigurowane wirtualne serwery równoważenia obciążenia po jednym dla każdego Ośrodka Regionalnego. Zadaniem serwerów równoważenia obciążenia sieciowego będzie: równoważenie obciążenia sieciowego w lokalizacjach centralnych, zapewnienie nieprzerwanego dostępu usług integracyjnych do systemu SWD PRM oraz zapewnienie nieprzerwanego dostępu dyspozytorów do aplikacji SWD PRM. Mechanizm równoważenia ruchu sieciowego pomiędzy serwery aplikacyjne realizowany jest przez Linux Virtual Server stanowiący część jądra systemu linux. Zadaniem usługi równoważenia obciążenia sieciowego będzie również monitorowanie podległych im serwerów usługowych, na który kierowany jest ruch przychodzący pod kątem dostępności i poprawności działania. Funkcja monitorująca uruchamiana będzie dla każdego serwera w określonym, podczas konfiguracji, odstępie czasu. W przypadku braku odpowiedzi na zapytanie monitorujące serwer aplikacyjny zostanie wyłączony z produkcji

Strona 21 /34 Rysunek 12 Usługa równoważenia obciążenia sieciowego 4.4. Serwery VPN Ze względu na zapewnienie bezpiecznej komunikacji w sieci OST-112 po stronie Zamawiającego, Wykonawca SWD PRM nie będzie dodatkowo zestawiał bezpiecznej programowej komunikacji pomiędzy Dysponentami a OR, do którego należy dany Dysponent. Wykonawca SWD PRM w celu zabezpieczenia transmisji danych pomiędzy systemem SWD PRM a terminalami mobilnymi, w OK zainstaluje serwery VPN oparte na oprogramowaniu dostarczonym przez Wykonawcę. Połączenie VPN z serwerami SWD PRM, będzie zestawiane podczas uruchamiania systemu operacyjnego. 4.5. Centralny serwer logowania Na potrzeby logowania i audytu zostanie użyte oprogramowanie syslog-ng dostarczone przez Wykonawcę. Usługa logowania będzie uruchomiona lokalnie na wszystkich serwerach fizycznych i wirtualnych. Zadaniem lokalnej usługi logowania jest przesyłanie logów i zdarzeń systemowych za pomocą protokołu TCP na centralne serwery logowania znajdujące się w OK w trybie klient-serwer. Lokalne serwery logowania w lokalizacjach regionalnych będą wysyłać logi bezpiecznym tunelem SSL do centralnego serwera logowania w formie skompresowanej. Lokalne serwery logowania będą przechowywać logi przez okres 7 dni usuwając starsze. Centralne serwery logowania znajdujące się w lokalizacjach krajowych będą przechowywać logi przez okres 30 dni. Wybrane logi będą podpisywane i powinny być archiwizowane. Za archiwizowanie i przechowywanie logów odpowiada Zamawiający. Wykonawca SWD PRM SWD PRM w Dokumentacji Powykonawczej wskaże Zamawiającemu, które elementy Systemu powinny być archiwizowane i przechowywane przez Zamawiającego.

Strona 22 /34 Rysunek 13 Usługa zapisu logów zdarzeń systemowych i aplikacyjnych 4.6. Usługa pocztowa Na potrzeby systemu SWD-PRM oraz informowania administratorów systemu o zaistniałych zdarzeniach zostanie zainstalowane oprogramowanie postfix należące do oprogramowania standardowego i świadczące usługi: serwera SMTP odbierającego komunikaty pocztowe z całej infrastruktury SWD PRM oraz sendmail wysyłającego komunikaty do Wykonawcy SWD PRM na zewnętrzne adresy poczty elektronicznej. Serwery pocztowe nie będą posiadały przestrzeni dyskowej dla skrzynek pocztowych, dlatego wszystkie wiadomości pocztowe będą od razu przekazywane na zewnętrzne adresy kont pocztowych. Na serwerach, z których komunikaty mailowe będą przesłane do adresata zewnętrznego usługi pocztowe zostaną skonfigurowane w taki sposób, aby poczta wychodząca była przekazywana na aktywne centralne serwery pocztowe zlokalizowane w OK. Lista aktywnych centralnych serwerów pocztowych będzie pobierana z serwera DNS, na którym zostaną skonfigurowane odpowiednie rekordy MX. 4.7. Systemy operacyjne W systemie SWD PRM zostaną użyte systemy operacyjne z rodziny Windows i Linux. Wszystkie serwery za wyjątkiem systemów operacyjnych bazy raportowej będą pracowały pod kontrolą systemu operacyjnego Enterprise Linux zgodnego z RHEL w wersji 6. Na potrzeby bazy raportowej zostanie użyty system operacyjny Windows Server 2008 R2 Enterprise Edition. 4.8. Oprogramowanie do wirtualizacji zasobów W systemie SWD PRM w lokalizacjach centralnych i lokalizacjach regionalnych serwery aplikacyjne będą pracować, jako maszyny wirtualne. Jako narzędzie do wirtualizacji zasobów zostanie wykorzystany mechanizm KVM, dostarczany przez Wykonawcę w ramach

Strona 23 /34 oprogramowania standardowego. Serwery maszyn wirtualnych zostaną skonfigurowane przy założeniach: System operacyjny serwerów maszyn wirtualnych w lokalizacjach centralnych będzie znajdować się na macierzy dyskowej, przez co uruchamianie systemu będzie odbywać się bezpośrednio z macierzy. System operacyjny serwerów maszyn wirtualnych w lokalizacjach regionalnych zostanie zainstalowany na dysku flash. Mechanizm restartów serwerów maszyn wirtualnych zostanie skonfigurowany w taki sposób, aby w pierwszej kolejności restartował serwery maszyn wirtualnych za pomocą protokołu IPMI w następnej za pomocą przełączników FC i zarządzania. W lokalizacjach centralnych obrazy systemów maszyn wirtualnych znajdować się będą na wolumenach udostępnionych z macierzy i półki dyskowej natomiast w lokalizacjach regionalnych obrazy systemów maszyn wirtualnych znajdować się będą na zasobach udostępnionych z półki dyskowej. Przeniesienie maszyny wirtualnej pomiędzy serwerami maszyn wirtualnych będzie realizowane bez przerwy w pracy maszyny wirtualnej. Powinien zostać włączony mechanizm deduplikacji danych znajdujących się w pamięci operacyjnej maszyn wirtualnych, mechanizm wirtualizacji kart sieciowych oraz tryb pracy, w którym zwalniania jest nieużywana przez maszynę wirtualna pamięć. Klastry HA serwerów maszyn wirtualnych w lokalizacjach centralnych będą posiadać skonfigurowany quorum dysk wystawiony z macierzy z wolumenu znajdującego się w pamięci macierzy. Klaster serwerów maszyn wirtualnych będzie migrował wszystkie maszyny wirtualne w przypadku informacji o niedostępności serwera maszyn wirtualnych. 4.8.1. Wymagania dla serwerów wirtualnych w lokalizacjach krajowych Wymagania dla serwerów SWD PRM w lokalizacjach krajowych przedstawione zostały w Załączniku nr 1 do Tomu 3 Projektu Technicznego dołączonym do dokumentu. Rysunek 16 przedstawia rozmieszczenie maszyn wirtualnych na serwerach w Ośrodku Krajowym. Uwaga: Liczba i rozmieszczenie maszyn wirtualnych może ulec zmianie na etapie realizacji ze względu na to, że serwery pracować będą w klastrze niezawodnościowym, dodatkowo ze względu na optymalizację rozwiązania, niektóre usługi udostępniane przez maszyny wirtualne mogą zostać rozdzielone na niezależne maszyny wirtualne.

Rysunek 14 Rozmieszczenie maszyn wirtualnych w POK Strona 24 /34

Strona 25 /34 Rysunek 15 Rozmieszczenie maszyn wirtualnych w ZOK 4.8.2. Wymagania dla serwerów wirtualnych w OR Regionalnym. Rysunek 16 przedstawia rozmieszczenie maszyn wirtualnych na serwerach w Ośrodku Uwaga:

Rysunek 16 Rozmieszczenie maszyn wirtualnych w OR Strona 26 /34

Strona 27 /34 5. Dodatkowe środowiska Systemu W ramach środowiska Systemu SWD PRM wyodrębnione zostaną dodatkowe środowiska: Środowisko testowo-szkoleniowe (TSW SWD PRM); Środowisko deweloperskie (DEW SWD PRM). Środowiska wymienione powyżej współdzielić będą te same elementy infrastruktury sprzętowej wydzielone w ramach Ośrodka Krajowego z Elementów Systemu zlokalizowanych w centrach serwerowych OK. Środowiska zorganizowane zostanie w oparciu o serwery wirtualne pracujące w trybie wysokiej dostępności pomiędzy lokalizacjami POK i ZOK. Mechanizm DR oparty będzie na protokole VRRP realizowanym przez usługę równoważenia obciążenia sieciowego. Serwery aplikacyjne środowiska testowo-szkoleniowego oraz środowiska deweloperskiego będą przyłączone do niezależnych od środowiska produkcyjnego, sieci LAN w obrębie przydzielonego przez Zamawiającego VPN-PRM. Rysunek 17 przedstawia elementy, z jakich będzie składać się środowisko testowo-szkoleniowe jak i środowisku deweloperskie.. Rysunek 17 Środowisko testowo szkoleniowe i developerskie

Strona 28 /34 6. Bramki GSM W celu udostępnienia w SWD PRM funkcjonalności dodatkowej dostarczanej przez Wykonawcę tj. powiadamiania osób, Wykonawca SWD PRM zapewni niezbędne bramki GSM w ilości 2 sztuk, i dokona ich instalacji w POK i ZOK.

Strona 29 /34 7. Lista oprogramowania W rozdziale wypisano listę oprogramowania standardowego dostarczanego w ramach zamówienia i realizacji projektu. Moduł aplikacji dla potrzeb Dyspozytorów ZRM Moduł aplikacji dla potrzeb ZRM Moduł analityczno-raportowy Moduł do rozliczeń z NFZ Moduł szpitalnych sił i środków Oprogramowanie aplikacyjne Pozostałe oprogramowanie standardowe

Strona 30 /34 8. Stanowiska dostępowe Stanowiska dostępowe muszą być odpowiednio skonfigurowane przed uruchomieniem na nich aplikacji SWD PRM. Stanowiska dostępowe oraz podłączenie do sieci OST112 wraz z konfiguracją zapewniane są przez Zamawiającego.

Strona 31 /34 9. Terminale mobilne ZRM Wykonawca SWD PRM dostarczy i zainstaluje 32 terminale mobilne zgodnie z wymaganiami Zamawiającego.

Strona 32 /34 10. Lista lokalizacji 10.1.1. Lokalizacje POK i ZOK Tabela 1 przedstawia lokalizacje, w których zostanie zainstalowany sprzęt dla OK. Tabela 1 Lista lokalizacji OK Lp Nazwa Województwo Miejscowość Ulica Nr domu/ 1 Mazowieckie Warszawa 2 Mazowieckie Warszawa lokalu Kod pocztowy 10.1.2. Lokalizacje OR Tabela 2 przedstawia lokalizacje, w których zostanie zainstalowany sprzęt dla OR. Tabela 2 Lista lokalizacji OR wariant I OR w Warszawie Lp Nazwa Województwo Miejscowość Ulica Nr domu/ 1 Dolnośląskie Wrocław 2 Lubelskie Lublin 3 Lubuskie Gorzów Wielkopolski 4 Łódzkie Łódź 5 Mazowieckie Warszawa 6 Mazowieckie Radom 7 Opolskie Opole 8 Podkarpackie Rzeszów 9 Podlaskie Białystok 10 Śląskie Katowice 11 Świętokrzyskie Kielce 12 Warmińsko - Olsztyn Mazurskie 13 Wielkopolskie Poznań 14 Zachodniopomo Szczecin rskie 15 Pomorskie Gdańsk 16 Kujawsko - Bydgoszcz Pomorskie lokalu Kod poczt owy 10.1.3. Lokalizacje Dyspozytorni Tabela 3 przedstawia lokalizacje, w których zostanie aplikacja SWD-PRM. Tabela 3 Lista lokalizacji Dyspozytorni Lp Nazwa Przynależność WCPR 1 Wrocław Wrocław 2 Wrocław Legnica Miejscowość Ulica Nr domu / lokalu Kod poczto wy

Strona 33 /34 Lp Nazwa Przynależność WCPR 3 Bydgoszcz Toruń 4 Bydgoszcz Bydgoszcz 5 Lublin Lublin 6 Lublin Biała Podlaska 7 Lublin Chełm 8 Lublin Zamość 9 Gorzów Wielkopolski Gorzów Wielkopolski 10 Gorzów Zielona Góra Wielkopolski 11 Łódź Łódź 12 Łódź Sieradz 13 Kraków Kraków 14 Warszawa Warszawa 15 Radom Radom 16 Radom Ostrołęka 17 Radom Siedlce 18 Radom Płock 19 Opole Opole 20 Rzeszów Rzeszów 21 Rzeszów Krosno 22 Rzeszów Sanok 23 Rzeszów Przemyśl 24 Rzeszów Mielec 25 Białystok Białystok 26 Białystok Łomża 27 Białystok Suwałki 28 Gdańsk Gdańsk 29 Katowice Sosnowiec 30 Katowice Bielsko-Biała 31 Katowice Katowice 32 Katowice Gliwice 33 Katowice Częstochowa 34 Katowice Jastrzębie- Zdrój 35 Kielce Kielce 36 Olsztyn Olsztyn 37 Poznań Poznań 38 Poznań Piła 39 Poznań Kalisz 40 Poznań Konin 41 Poznań Leszno 42 Szczecin Szczecin 43 Szczecin Kołobrzeg Miejscowość Ulica Nr domu / lokalu Kod poczto wy 10.1.4. Lokalizacje ZRM Zgodnie z wymaganiami Zamawiającego Wykonawca SWD PRM wyposaży w zestaw urządzeń (terminal, drukarka, urządzenie GPS) 32 karetki. 10.1.5. Rozmieszczenie stanowisk dostępowych Zgodnie z wymaganiami Zamawiającego, Wykonawca SWD PRM wykona instalację i konfigurację dostarczanego przez Wykonawcę oprogramowania na zapewnianych przez

Zamawiającego Stanowiskach Dostępowych maksymalnie do 240 szt.. Ostateczna ilość oraz rozmieszczenie stanowisk dostępowych zostanie przedstawiona przez Zamawiającego. Strona 34 /34