Národní informační systém integrovaného záchranného systému (NIS IZS)

Signature Not Verified

INTEGROVANÉ OPERAČNÍ Ing. Stanislav Loskot STŘEDISKO POLICIE ČR

21.3.2013 13:03:48

Příloha č. 25 k Č.j.: PPR-17905-10/ČJ-2012-990790

SPECIFIKACE ROZHRANÍ Projektu

Národní informační systém integrovaného záchranného systému (NIS IZS) Dodavatel:

Česká pošta, s.p., Odštěpný závod ICT služby

Zadavatel:

MV – GŘ HZS

Datum aktualizace:

11. 02. 2013

Verze:

verze 1

Registrační číslo projektu

CZ.1.06/3.4.00/11.07071

Obsah 01.

Krycí list dokumentu..................................................................................................................................................... 3

02.

Manažerské shrnutí ....................................................................................................................................................... 4

03.

Popis architektury NIS IZS .......................................................................................................................................... 5 Síťová architektura ........................................................................................................................................................................................................... 5 Centrální DC LAN ................................................................................................................................................................................................................... 13 Krajská DC ................................................................................................................................................................................................................................ 20

HW architektura .............................................................................................................................................................................................................. 21 Storage pro virtualizaci a NFS........................................................................................................................................................................................... 21 Datový archiv .......................................................................................................................................................................................................................... 22 Servery ....................................................................................................................................................................................................................................... 23 Pracoviště klientů .................................................................................................................................................................................................................. 25 Koncepce redundance a dostupnosti na úrovni HW................................................................................................................................................ 27

Aplikační architektura .................................................................................................................................................................................................. 33 Integrační platforma (IPL) ................................................................................................................................................................................................. 37 Telefonie (TEL) ....................................................................................................................................................................................................................... 38 Nahrávání (REC) .................................................................................................................................................................................................................... 40 Aplikace NSPTV ...................................................................................................................................................................................................................... 44 Centrální GIS (CGIS) a krajský GIS (KGIS) .................................................................................................................................................................... 45 Infrastruktura systému ....................................................................................................................................................................................................... 53 Koncepce redundance a dostupnosti na úrovni SW................................................................................................................................................. 54

04.

Rozhraní systému NIS IZS ........................................................................................................................................ 58 Typy komunikace ........................................................................................................................................................................................................... 58 Synchronní komunikace ..................................................................................................................................................................................................... 58 Asynchronní komunikace ................................................................................................................................................................................................... 58

Pravidla komunikace .................................................................................................................................................................................................... 59 Scénáře komunikace ..................................................................................................................................................................................................... 60 Odeslání založené události................................................................................................................................................................................................. 60 Odeslání aktualizované události ...................................................................................................................................................................................... 61 Předání události jiné složce / operačnímu středisku .............................................................................................................................................. 62 Sloučení událostí .................................................................................................................................................................................................................... 62 Řešení výpadků ...................................................................................................................................................................................................................... 63 Stav SaP ..................................................................................................................................................................................................................................... 64 Operační situace ..................................................................................................................................................................................................................... 65 Management hovorů ............................................................................................................................................................................................................ 65 Administrace systému ......................................................................................................................................................................................................... 65

Struktura zpráv................................................................................................................................................................................................................ 66 Validace ..................................................................................................................................................................................................................................... 66 Datová struktura zpráv ....................................................................................................................................................................................................... 67 Číselníky .................................................................................................................................................................................................................................... 68

VERZE 01

SPECIFIKACE ROZHRANÍ

strana 2 (celkem stran 75)

01. Krycí list dokumentu Základní údaje o dokumentu Název dokumentu


Zkrácený název dokumentu


Příloha dokumentu

NIS_ROZHRANI_V0.XML

Název projektu

Národní informační systém integrovaného záchranného systému

Zkrácený název projektu

NIS IZS

Registrační číslo projektu

CZ.1.06/3.4.00/11.07071

Dotační titul projektu

Integrovaný operační program

Zadavatel

MINISTERSTVO VNITRA - generální ředitelství Hasičského záchranného sboru České republiky Kloknerova 2295/26, 148 01 Praha 414

Věcný gestor projektu

plk. Luděk Prudil, věcný gestor projektu

Dodavatel

Česká pošta, s.p., Odštěpný závod ICT služby Olšanská 4, 130 00 Praha 3

Vedoucí projektu

Ing. Václav Kalenda, vedoucí projektu

Verze dokumentu VERZE

ÚČEL

DNE

DOKUMENT

01 DRAFT

pouze pro předběžnou informaci

05/02/2013

bez dokumentu - mailem

VERZE 01



02. Manažerské shrnutí Účel dokumentu

Dokument je podrobně popisuje architekturu NIS včetně jejích služeb, rozhraní a způsob komunikace se systémy operačního řízení, které budou upravovány v rámci dílčích krajských projektů. Účelem dokumentu je poskytnout zadání pro vývoj a úpravy systémů pro operační řízení jednotlivých základních složek IZS tak, aby byly splněny cíle programu IS IZS. Tento dokument je pouze předběžný. Specifikace rozhraní bude obsažena v dokumentu Rámcový koncept SW (RK) a tento dokument nebude dále udržován aktuální.

Vstupní dokumentace

Nabídka a smlouva

Navazující dokument

Rámcový koncept SW řešení (RK)

Omezení

Všechny technické specifikace uvedené v tomto dokumentu jsou předběžné a mohou být zpřesněny na základě praktických poznatků získaných při vývoji funkčního prototypu.

Prokázání plnění akceptačních kritérií OZN.

KRITÉRIUM

SPLNĚNÍ

KOMENTÁŘ

Q35

Jsou zprávy přenášené mezi komponentami systému ve formátu SOAP?

ANO

V celém systému je používán pro přenos zpráv výhradně formát SOAP. Pouze pro zobrazení výsledku volání služeb GIS je z důvodu rychlosti zpracování využit protokol REST. Zapouzdřeno do SOAP je i volání služeb telefonie (JTAPI).

Výsledek akceptace:

VERZE 01

Akceptační kritéria nebyla v tomto dokumentu separátně hodnocena.



03. Popis architektury NIS IZS Síťová architektura Komunikační infrastrukturu pro NIS IZS tvoří čtyři vzájemně propojené celky: • Síť centrálních datových center NIS • Síť DC krajských pracovišť • Síť pracovišť na krajských operačních střediscích jednotlivých složek • Propojovací WAN síť Sítě datových center tvoří komunikační páteř jak pro datovou komunikaci protokolem IP, tak pro komunikaci serverů s datovými úložišti protokolem FibreChannel a pro propojení datových center navzájem. Sítě DC krajských pracovišť slouží k připojení decentralizovaných systémů NIS, které jsou umístěny v krajích z důvodu podpory výkonu nebo zálohování systémů centrálních. Vybudování této sítě je předmětem projektu NIS IZS. Sítě pracovišť umožňují připojení koncových uživatelů v jednotlivých lokalitách ke službám datových center protokolem IP prostřednictvím hardwarového vybavení jednotlivých pracovišť, zejména pomocí tenkých terminálových klientů a IP telefonů. Vybudování této sítě je předmětem projektu NIS IZS. Propojovací WAN síť slouží jako síť připojující sítě pracovišť k sítím datových center. Tato síť není předmětem projektu NIS IZS, ale bude vybudována jako zvláštní VPN v rámci sítí ITS. Propojovací WAN síť není předmětem projektu NIS IZS a předpokládá se, že bude realizována projektem ITS. V rámci této dokumentace jsou stanoveny požadavky na propojovací WAN síť kladené. Obrázek 1: Celková koncepce sítí v kontextu komunikační infrastruktury ITS ITS MV

DC1 Olšanská

DC3 Olomouc

DC2 Malešice

VPN ZZS Data+Hlas

VPN PČR Data

VPN NIS

VPN HZS Data+Hlas

VPN PČR Hlas

Krajská operační střediska (3 x 14)

Krajská DC (14 x)

VERZE 01



Architektura VPN

NIS IZS bude využívat služeb ITS. Bude se jednat o sadu MPLS VPN. Alokace VPN bude: • NIS IZS_data - aplikační část NIS IZS - servery, databáze, pracovní stanice • NIS IZS_voice - hlasová část NIS IZS - hlasové brány, řídící servery, telefony • NIS IZS_management - správa a dohled celého systému, jinými slovy "out-of-band management" Out-of-band management omezí přístup administrátorů k ostrým datům. Dále pak umožní přístup k hraničním zařízením, která mohou konfigurovat i správci z jiných sítí (např. SW firewally na krajské úrovni), nebo těmto správcům umožní alespoň diagnostiku některých prvků NIS IZS. Oddělení datového a hlasového provozu do samostatných VPN umožní řešit specifické požadavky na návaznost ostatních sítí. Propojení hlasových sítí může být otevřenější nebo vedeno ve více směrech než u datových VPN. Důvodem může být např. širší nasazení VoIP v rámci státní správy a samosprávy. Navazující VPN

NIS IZS bude obousměrně přenášet data a hlas s operačním řízením složek IZS, tj. PČR, HZS a ZZS. PČR a HZS jsou připojeny do ITS, u ZZS je to plánováno. V návrhu řešení předpokládáme, že jednotlivé složky budou v ITS dostupné jako jedna nebo dvě VPN (dvě v případě, že složka má samostatnou VPN pro hlas). Dále vycházíme z těchto předpokladů: • operační řízení musí být schopno autonomního provozu na úrovni kraje. Výpadek ITS směrem do centra nesmí omezit fungování operačního řízení. • NIS IZS na krajské úrovni poskytuje operačnímu řízení služby Geografického Informačního Systému (GIS) a Integrační Platformy (IPL) pro vzájemnou výměnu dat mezi jak mezi složkami, tak mezi NIS IZS a složkami. • jednotlivé VPN nebudou používat překryvné IP adresní prostory - IP adresace jednotlivých složek a NIS IZS bude harmonizována tak, aby pro vzájemnou komunikaci nebylo nutné nasadit mezi sítěmi NAT. NAT může zkomplikovat nebo znemožnit propojení sítí na krajské úrovni. Jestliže nebude možná úplná harmonizace IP adres, navrhujeme síť NIS IZS adresovat z rozsahu, který nepoužívá žádná složka a pro komunikaci se složkami vybrat jednu z těchto variant: 1. jestliže se překryv adres týká částí sítě, které nekomunikují s NIS IZS, vyřadit konfliktní adresy z prefixů, které jsou ze složky propagovány do NIS IZS 2. provést harmonizaci na úrovni IP adres serverů ve složkách, které jediné budou oprávněny komunikovat se servery NIS IZS. Adresy těchto serverů pak budou propagovány z jednotlivých VPN do NIS IZS jako host route. 3. adresy serverů ve složkách neměnit a nasadit na hranici mezi složkami a NIS IZS NAT 1:1 pro tyto servery. Při návrhu IP adresace je nutno prověřit i konflikt IP adres mezi složkami, tj. zda servery ve složkách, se kterými bude NIS IZS komunikovat, nejsou adresovány ze stejných rozsahů adres. Dynamický IP routing

Síť NIS IZS je jednou z VPN v rámci ITS. Fyzické propojení tedy předpokládáme standardním způsobem mezi PE a CE routery. PE na straně ITS, CE na NIS IZS. Směrování mezi PE a CE

VERZE 01



bude dynamické, preferujeme protokol BGP. NIS IZS bude propojena s ostatními VPN v Centrálních i v Krajských DC. Tato propojení budou z pohledu konektivity rovnocenná. Dynamický routing pak zajistí automatické zálohování komunikace bez narušení provozu. Propojení VPN

Systém NIS IZS si bude vyměňovat data s krajskými operačními středisky základních složek IZS. Každá z nich bude mít v ITS minimálně jednu VPN. Tyto VPN jsou autonomní a slouží především pro interní provoz složky. Propojení s NIS IZS nesmí narušit jejich bezpečnost ani spolehlivost provozu. Protože kraje musí být schopny samostatného provozu, bude nutné propojit VPN nejen na úrovni centrálních datových center, ale i v jednotlivých krajích. Varianty propojení jsou popsány dále. Jak jsme již uvedli, chceme se vyhnout použití NAT mezi NIS IZS a složkami. VPN budou propojeny v mnoha bodech a udržování konfigurace NAT ve všech těchto bodech by bylo zbytečnou komplikací a zdrojem chyb. MPLS VPN umožňují řízení redistribuce směrovacích informací mezi VPN. Informace lze nezávisle exportovat a importovat, takže lze vytvořit tzv. "hub and spoke" topologii. Obrázek 2: Propagace směrovacích informací Propagace směrových informací 10.X.0.0./16

10.A.0.0./10

PCR_data 10.A.0.0/10

10.X.0.0./16 NIS_data 10.X.0.0/16

HZS 10.B.0.0/10 10.B.0.0/10

10.C.0.0/10

ZZS 10.C.0.0/10

10.X.0.0./16

Do NIS IZS_data jsou propagovány směrovací informace z VPN jednotlivých složek. Tyto informace mohou být úplné nebo se mohou týkat jen vybraných serverů nebo sítí, které si budou vyměňovat informace s NIS IZS. Do jednotlivých složek jsou propagovány pouze směrovací informace NIS IZS_data, takže NIS IZS a složky mohou obousměrně komunikovat, ale mezi složkami navzájem komunikace možná není. Slovem "komunikace" myslíme přímou IP konektivitu. Výměna dat mezi složkami možná bude a to přes servery NIS IZS. Výsledná topologie propojení VPN a směry komunikace jsou na následujícím obrázku. Zeleně jsou označeny otevřené směry, červeně zakázané.

VERZE 01



Obrázek 3: Směry komunikace

PCR_data 10.A.0.0/10

HZS 10.B.0.0/10

NIS_data 10.X.0.0/16

ZZS 10.C.0.0/10

Redistribuci směrovacích informací lze provést buď na PE nebo CE routerech. PE routery jsou ve správě ITS, CE routery podléhají NIS IZS. Řízeno ITS Obrázek 4: Redistribuce na PE routerech DC

NIS_data DC_LAN

CE

PE

ITS (MPLS)

NIS_data

ZZS PCR_data

HZS

PE routery v jednotlivých lokalitách dostávají od CE routerů směrovací informace o lokalitě (např. prefix 10.X.123.0/24 nebo host route na NIS IZS server 10.X.123.100/32). Tyto směrovací informace jsou PE routerem redistribuovány nejen do NIS IZS_data, ale i do VPN složek IZS. CE routery dostávají od PE kompletní směrovací tabulku VPN NIS IZS_data.

VERZE 01



Obrázek 5: PE-CE připojení složky DC PČR

PCR_data

CE

PE

ITS (MPLS)

NIS_data

ZZS

PCR_data

HZS

PE router dostává v tomto případě směrovací informace PCR_data z příslušné lokality (např. prefix 10.A.212.0/24 nebo host 10.A.212.80/32). Tyto informace doplní do směrovací tabulky VPN PCR_data a NIS IZS_data. Hlavní výhodou tohoto řešení je optimální IP směrování mezi jednotlivými lokalitami a automatický přechod na záložní trasu při výpadku. Řešení dobře škáluje a nabízí prakticky neomezený počet propojovacích bodů. Řízeno NIS IZS

Redistribuci směrovacích informací lze stejným způsobem realizovat i na straně CE. Protože centrálním uzlem výměny informací je NIS IZS, redistribuce by se měla dělat na jeho CE routerech.

VERZE 01



Obrázek 6: Redistribuce na CE routerech DC

DC_LAN

NIS_data

HZS multi-VRF CE

PCR_data

ZZS

PE

ITS (MPLS)

CE router NIS IZS jede v módu tzv. "multi-VRF CE". Jednotlivé VPN jsou na něj přivedeny z PE routeru jako samostatné VLAN. CE pak mezi nimi dělá stejnou řízenou redistribuci, jaká byla popsána v předchozí kapitole. I toto řešení dobře škáluje v počtu propojených bodů. Řízeno NIS IZS, doplněno o firewall

Řešení popsané v předchozí kapitole lze doplnit o firewally. Může se jednat např. o virtuální firewally běžící na serverech datového centra.

VERZE 01



Obrázek 7: Řešení s firewally DC

DC_LAN

multi-VRF CE2

Virtuální firewall PCR

Virtuální firewall HZS

Virtuální firewall ZZS

PCR_data

HZS

ZZS

NIS_data

multi-VRF CE1

PE

ITS (MPLS)

NIS_data

ZZS

PCR_data

HZS

Jednotlivé VPN lze propojit do datového centra buď přímo (NIS IZS) nebo přes firewall. CE1 a CE2 jsou ve skutečnosti jedno zařízení. Na obrázku je nakreslené dvakrát kvůli přehlednosti propojení VPN. Správu firewallu lze přidělit příslušné složce. Výhodou řešení tedy je jasně daný demarkační bod mezi složkou a NIS IZS v každém datovém centru (centrálním i krajském). Administrátoři složek ale musí počítat s náročnou správou. Firewall také bude zodpovědný za odesílání IP směrovacích informací ze složky do NIS IZS. Bylo by vhodné zachovat dynamické směrování a vyhnout se nastavování statického směrování na CE routerech NIS IZS.

VERZE 01



Připojení hlavních DC

Hlavní datová centra budou vzájemně propojena 10GE linkami. Do ITS, tj. pro komunikaci s krajskými DC, klientskými pracovišti NIS IZS a složkami, bude každé datové centrum připojeno přes dvojici CE routerů proti dvěma PE routerům ITS. Oba CE routery budou mít dvojici GE přípojek pro zajištění redundance. Obrázek 8: Připojení hlavních DC 2 x 10 GE

DC1

DC3

DC2 2 x 10 GE

CE

CE

4 x 1 GE

PE

CE

CE

4 x 1 GE

PE

PE

CE

CE

4 x 1 GE

PE

PE

PE

ITS (MPLS)

Kraj

Na úrovni kraje bude mít NIS IZS vždy jedno datové centrum vybavené tak, aby bylo operační řízení složek schopno autonomního provozu v rámci kraje (např. při výpadku ITS a spojení se všemi hlavními DC). Pracoviště NIS IZS ale mohou být umístěna ve všech složkách. V návrhu tedy rozlišujeme krajské centrum se servery (krajské DC) a bez serverů. Oba typy krajských center budou vybaveny dvojicí CE routerů s GE porty a redundantní LAN. V případě, že bude zvoleno propojení VPN na úrovni CE routeru nebo s doplněním o firewally, bude tato konfigurace realizována v krajském DC. Ostatní krajská centra NIS IZS budou mít pouze konektivitu do VPN NIS IZS.

VERZE 01



Obrázek 9: Připojení KDC

Krajské DC

stack

2 x 1 GE

CE

CE

4 x 1 GE

PE

PE

ITS (MPLS)

Předpokládá se, že ITS poskytne konektivitu podle požadavků v této dokumentaci, zřízení a provoz jednotlivých VPN sítí pro účely projektu NIS IZS a zajistí hraniční zařízení ve všech lokalitách, kde je to třeba. Dále zajistí koordinační roli při finalizaci koncepce a zřizování směrování a zajištění bezpečnosti mezi VPN jednotlivých účastnických organizací. Centrální DC LAN Sítě datových center budou mít identickou architekturu i hardwarové vybavení. Datová centra budou vybudována v lokalitách: • DC1 Praha Olšanská 4 • DC2 Praha Malešice • DC3 Olomouc Datová centra Praha Olšanská a Praha Malešice budou primární, vzájemně se kontinuálně zálohující datová centra, jejichž úkolem je poskytovat služby NIS IZS v režimu maximální dostupnosti i v případě výpadku jednotlivých komponent nebo v případě výpadku celého datového centra. Datové centrum Olomouc bude sekundární datové centrum s asynchronní replikou dat a možnosti rozjetí provozu v definovaném čase a definovanými postupy v případě havárie nebo nedostupnosti obou pražských datových center.

VERZE 01



Datová centra Praha Olšanská a Praha Malešice budou připojena do ITS v obou lokalitách redundantním připojením k hraničním prvkům ITS pomocí směrovače s funkcionalitou MultiVRF CE tak, aby do datových center NIS IZS bylo možno propojit libovolnou VPN, která je v ITS provozována. Datová centra budou též propojena navzájem dvojicí párů optických vláken, jejichž prostřednictvím budou propojeny jak sítě LAN, tak sítě SAN obou datových center. Pro efektivní přenos datových okruhů po optických okruzích budou využity systémy DWDM, které umožní přenos více okruhů po stejném vlákně pomocí modulace signálů různou vlnovou délkou a jejich optického multiplexu a demultiplexu. Připojení obou datových center do ITS a propojení navzájem je znázorněno na následujícím obrázku. Obrázek 10: Začlenění DC1 a DC2 do kontextu komunikačníinfrastruktury ITS DC1

DC2 2 x (2 x 10GE + 2 x 8G FC) přes DWDM systémy

VPN NIS

CE

CE

CE

CE

Hranice zodpovědnosti NIS IZS / KI ITS

4 x 1 GE

4 x 1 GE

ITS (MPLS) PE

PE

PE

PE

VPN NIS

VPN PČR Data

VPN PČR Hlas

VPN HZS Data+Hlas

VPN ZZS Data+Hlas

Požadavky na ITS z hlediska připojení datových center: • 4 porty 1GE pro připojení multi-VRF CE podle obrázku výše • Vytvoření a propagace VPN pro projekt NIS IZS do všech relevantních lokalit • 10GE garantovaná kapacita do každého DC Propojení datových center pomocí systémů DWDM není součástí projektu NIS IZS a předpokládá se dodávka výše uvedené konektivity ze strany ITS. Lokalita datového centra Olomouc bude připojena obdobně bez přímého připojení prostřednictvím protokolu FibreChannel (FC). Diagram připojení datového centra Olomouc k sítím ITS je znázorněn na následujícím obrázku:

VERZE 01



Obrázek 11: Začlenění DC3 do kontextu komunikační infrastruktury ITS

DC3

VPN NIS

CE

CE


4 x 1 GE

ITS (MPLS) PE

PE

VPN HZS Data+Hlas

VPN NIS VPN ZZS Data+Hlas VPN PČR Data

VPN PČR Hlas

Požadavky na hraniční směrovače Multi-VRF CE ve správě NIS IZS: • multi-VRF CE funkce • podpora alespoň 16 VRF • podpora protokolu OSPF, sub-second timers • podpora protokolu BGP • podpora LISP podle draft-ietf-lisp-24 Architektura sítí všech tři datových center bude totožná. Sítě datových center umožňují: • vybudování a provozování telefonních služeb na bázi IP telefonie • připojení IP telefonie do veřejné telefonní sítě • vybudování a připojení serverové farmy pro provoz jak na fyzických serverech: o IP telefonie o Mapových systémů GIS o Integrační platformy systémů NIS IZS o Databázových systémů

VERZE 01



o Virtuálních desktopů, jejich správy a prostředků přístupu • služby firewallu datového centra • služby po rozkládání zátěže a kontrolu dostupnosti služeb s možností reakce na chybové stavy • připojení do ITS • vzájemné propojení v případě datových center Praha Olšanská a Praha Malešice Architektura datového centra je znázorněna na následujícím obrázku: Obrázek 12: Fyzická infrastruktura DC Síťové služby GSLB Hlasové brány

VTS

DC FW

SLB

Přístupová vrstva DC LAN

TO2 Agregační vrstva DC LAN

Multi-VFR směrovače NIS

ITS

T-Mobile Vodafone

GSLB

DC FW

SLB

Optické trasy do záložních DC

Serverová farma fyzické a virtuální servery

Datové úložiště FC a NAS

DC SAN B

DC SAN A

Agregační vrstva DC LAN plní následující funkce: • L3 směrování protokolu IPv4 a IPv6 mezi sítěmi v DC a vůči vnějším sítím • Připojení služeb pro o Rozkládání zátěže a zajištění dostupnosti služeb (loadbalancing, SLB a GSLB) o Připojení firewallů datového centra a jejich začlenění do datových toků o Propagaci informací o dostupnosti služeb a datového centra do VPN sítí v rámci ITS pomocí směrovacích informací a pomocí podmíněných překladů DNS • Propojení datových center navzájem na L3 OSI modelu s virtuálním propojením L2 sítí mezi datovými centry s bezpečným oddělením DC z hlediska L2 protokolů, jako například SpanningTree

VERZE 01



• Lokální IP default gateway jak pro čistě lokální sítě, tak pro L2 segmenty propojené do sesterského datového centra • Přístupová vrstva DC LAN slouží pro připojení fyzických serverů v serverové farmě a dalších prvků, například hlasových bran do veřejné telefonní sítě. Požadavky na prvky agregační vrstvy: • Architektura modulárního L3 přepínače • Alespoň 96 10GE portů • Redundantní řídící jednotka • Statefull failover řídících jednotek v případě selhání • Podpora sdružení dvou prvků do redundantního páru s podporou EtherChannel s fyzickými okruhy z obou prvků zároveň • Podpora protokolu FCoE • Podpora pro propojení na úrovni L2 do vzdálené lokality prostřednictvím sítě s L3 architekturou, podpora pro lokální IP default gateway se stejnou IP adresou v obou lokalitách • Možnost rozdělení prvku na virtuální prvky s autonomní správou, alespoň čtyř VPN Požadavky na prvky přístupové vrstvy: • Architektura modulárního L3 přepínače • Alespoň 96 10GE portů • Redundantní řídící jednotka • Statefull failover řídících jednotek v případě selhání • Podpora sdružení dvou prvků do redundantního páru s podporou EtherChannel s fyzickými okruhy z obou prvků zároveň • Podpora protokolu FcoE • Možno řešit jako virtuální instance prvku v agregační vrstvě Požadavky na loadbalancery: • Loadbalancing protokolů na vrstvách L3 a L4 podle OSI definice • Možnost virtualizace do prvků s autonomní správou, alespoň šesti • Možnost kontroly dostupnosti a stavu aplikace pomocí protokolu ICMP a HTTP • Možnost injekce směrovacích informací do libovolného dynamického směrovacího protokolu podle dostupnosti loadbalancovaných a monitorovaných aplikačních služeb • Propustnost alespoň 4Gbit/sec • Provoz jak v režimu L2, tak režimu L3 Požadavky na prvky pro geografický loadbalancing: • Funkce dynamického inteligentního DNS

VERZE 01



• Možnost spolupráce s loadbalancery serverů, stanovení optimálního překladu DNS pomocí metrik • Možnost pracovat jako plnohodnotný odolný a bezpečný DNS server Z hlediska L3 topologie je předpokládána architektura podle následujícího obrázku: Obrázek 13: L3 model DC

Každá logicky ucelená část aplikačního vybavení bude mít svůj vlastní adresní prostor z důvodu možného oddělení do bezpečnostních zón a z důvodu jednodušší autonomní správy dané aplikační komponenty. Aplikační komponenty, které neřeší vysokou dostupnost aplikačními prostředky, budou pro zajištění vysoké dostupnosti využívat loadbalancery, která zajistí přesměrování požadavků na danou komponentu na server, na kterém bude daná aplikační komponenta funkční a dostupná. V případě nedostupnosti zajistí přesměrování na záložní komponentu. Předpokládá se využití logických loadbalancerů, které se chovají autonomně, pro každý takový případ, byť se z hlediska prvků může jednat o jedno fyzické zařízení. SAN

Síť SAN je koncipována jako síť umožňující propojení serverů a datových úložišť v jednotlivých datových centrech rodinou protokolů FibreChannel umožňující spolehlivé, redundantní a vysoce kapacitní komunikaci. V případě datových center v Praze je SAN síť navíc koncipována i jako síť propojující obě lokality navzájem pro účely zajištění redundance ukládání dat do obou datových center zároveň. SAN síť je navržena v tradičním duálním režimu dvou nezávislých SAN sítí (SAN A a SAN B), přičemž jak servery, tak datová úložiště jsou vždy připojeny do obou z nich. Propojení SAN sítí mezi pražskými lokalitami bude realizováno prostřednictvím DWDM systémů pomocí redundantních okruhů 8G FC. Sítě budou na úrovni protokolu FC odděleny prostřednictvím FibreChannel routingu tak, aby se obě lokality v případě topologických změn neovlivňovaly a nepropagovaly případně chybové stavy mezi lokalitami.

VERZE 01



Obrázek 14: Koncepce SAN sítí v Praze (DC1 a DC2)

Síť SAN v lokalitě Olomouc (DC3) bude autonomní. Požadavky na prvky SAN: • Podpora FC 1/2/4/8G FC • Modulární koncepce • Redundantní řídící prvky • Redundantní zdroje • Podpora virtuálních SAN • Funkce pro routování FC mezi virtuálními SAN • Podpora port channelu pro sdružování fyzických okruhů do jednoho logického okruhu. Fyzické okruhy mohou být různě dlouhé s tolerancí nejméně 30km. • Podpora propojení prvků okruhy s více virtuálními SAN • Podpora FCIP • Alespoň 48 portů s možností dalšího rozšíření • Podpora integrované akcelerace zápisových operací mezi lokalitami DC-DC propojení

Propojení všech DC bude realizováno prostřednictvím sítě ITS jako kapacitní routované IP sítě, jak je uvedeno výše. Pražská datová centra budou mít navíc propojení prostřednictvím dedikovaných optických vláken s využitím DWDM systémů. Propojení moderních datových center vyžaduje flexibilní optický systém, který je schopen splnit specifické požadavky dané instalace s ohledem na současnou matici provozu, použitá optická vlákna, dostupný prostor v rozvaděčích, napájení atd. Musí rovněž poskytnout prostor pro dostatečné rozšíření spojené s růstem počtu požadovaných přenášených kanálů,

VERZE 01



jejich rychlosti nebo podporu nově se objevujících rozhraní. Samozřejmostí je existence návrhového nástroje, který umožňuje snadný návrh, instalaci a rozvoj optické sítě a rovněž musí být v dispozici efektivní nástroj na správu a dohled. Pro přenos mezi datovými centry Praha Malešice a Praha Olšanská bude použito: • 2 x 10GE • 2 x 8G FC Požadavky na systémy DWDM: • Podpora rozhraní: o Ethernet 100/1G/10G/40G/100G o FibreChannel 1/2/4/8G FC o TDM E1/E3/STM-1/4/16/64/256 • Vysoká flexibilita optické vrstvy pomocí konfigurace • Redundantní řešení • Aplikace pro návrh optické sítě a jejích změn • Aplikace pro dohled systému a monitorování jednotlivých kanálů na optické vrstvě DWDM systém poskytující konektivitu mezi datovými centry není součástí dodávky NSPTV a předpokládá se poskytnutí výše uvedené konektivity ze strany ITS. Krajská DC Krajská datová centra jsou z pohledu začlenění do síťového prostředí podobná centrálním datovým centrům. Svým rozsahem jsou výrazně menší a z hlediska hardwarového vybavení síťovými prvky disponují základní redundantní konektivitou pro lokální servery a připojení do ITS. Připojení do IT je znázorněno na následujícím obrázku:

VERZE 01



Obrázek 15: Začlenění krajského DC do kontextu infrastruktury ITS Krajské DC

VPN NIS

CE

CE


4 x 1 GE

ITS (MPLS) PE

PE

VPN HZS Data+Hlas

VPN NIS VPN ZZS Data+Hlas VPN PČR Data

VPN PČR Hlas

Obrázek 16: Fyzická infrastruktura krajského DC

Prvky DC LAN v krajském datovém centru budou plnit úlohu přístupové a agregační vrstvy datového centra a zároveň zajišťovat připojení k ITS.

HW architektura Storage pro virtualizaci a NFS Datová úložiště budou umístěna ve všech třech datových centrech s identickou konfigurací. Poskytnou prostor a výkon pro provoz všech aplikací v rámci NSPTV včetně manipulačního prostoru pro provozní zásahy a změny a zálohování. Datová úložiště jsou koncipována tak, aby umožňovala synchronní a asynchronní mód replikace dat mezi datovými centry a v případě datových center v Praze i práci v active/active

VERZE 01



režimu nad stejným diskovým svazkem z důvodu způsobu zajištění redundance a zotavení se ze ztráty jedné z těchto lokalit. Kapacita diskových polí v DC1, DC2 a DC3 činí 25TB (minimálně 5% - SSD disky se SAS 3.0 interface, 45% - SAS 3.0 disky s min. 10k RPM, 50% - NL_SAS disky). Řešení musí garantovat kompatibilitu a certifikaci kompatibility s VMware HA, VMware FT, Microsoft Cluster a Oracle RAC. Pro DC1 a DC2 bude obsahovat technologie poskytující kontinuální provoz aplikací s RPO=0 i RTO=0 formou synchronní replikace s active/active daty v obou lokalitách. Řešení musí umožnit realizaci geograficky vzdálených serverových clusterů, s možností čtení a zápisu stejných dat v obou lokalitách Požadované vlastnosti řešení pro asynchronní replikaci dat mezi primárním centrem DC1 a vzdáleným záložním centrem DC3 zahrnují zejména funkcionalitu pro asynchronní replikaci dat mezi primárním a záložním centrem s parametrem RPO=15 minut. Řešení musí poskytovat možnost návratu do jednotlivých předchozích datových stavů s krokem max. 15 min. (RPO) a s historií min. 24 hodin a „semi-manuální“ označování vybraných aplikačně konzistentních datových stavů (s maximálním krokem jedna hodina) pro rychlou detekci bodu obnovy. Řešení bude provádět snímky datových změn s možností přechodu do historického datového stavu v rozsahu menším než 1 minuta. Datový archiv Datový archiv slouží k dlouhodobému ukládání dat, u kterých se předpokládá, že mohou sloužit k průkaznosti činnosti systému NIS IZS v průběhu příjmu události a jejího řešení. Datový archiv je koncipován jako zařízení, do kterého je data možno průběžně ukládat bez další možnosti smazání nebo změny těchto dat s ohledem na zajištění jejich průkaznosti. Datový archiv umožňuje data oprávněnými osobami a aplikacemi zpětně prohledávat a číst, nikoli měnit. Architektura úložiště musí splňovat podmínky standardu CAS (Content addressed storage), tedy data musí ukládat nezávisle na jejich obsahu (ve smyslu původu dokumentu) a jejich uložení musí být určeno na základě jejich binárního obsahu, který zajistí jedinečnost uložení – tedy data musí být interpretována bezrozměrným identifikátorem. Architektura úložiště musí umožnit snadnou škálovatelnost až do velikosti PB, a to bez přerušení provozu, v rámci jednoho fyzického systému (z důvodů škálovatelnosti a snadnosti správy není povolen cluster standardních diskových úložišť, který bude obsluhován soustavou serverů). Operační systém úložiště musí umožnit vynucení skartační doby pro ukládaná data. Operační systém úložiště musí umožnit definici skartačních tříd podle druhu ukládaného obsahu, elektronickou skartaci, nativní auditované smazání obsahu s důkazem uloženým přímo na úložišti, konfiguraci výchozí skartační periody. Úložiště musí garantovat neměnnost uložených dat (prokazatelná neměnnost díky speciálnímu algoritmu), jedinečnost dat (jsou-li ukládána shodná data, pak jsou uložena pouze jednou), dlouhodobé uchování – nastavení politiky pro uchování dat (různé doby skartace až po neomezenou dobu uchování dat).

VERZE 01



Úložiště musí také umožňovat garantovanou nesmazatelnost uložených dat – možnost nastavení selektivně pro každý objekt příznak nesmazatelnosti na definovanou libovolně dlouhou dobu (i nekonečno). Vyžaduje se prokázání shody s paragrafy, které se týkají důvěryhodného uložení dat na diskové úložiště, následujících norem: zákon č. 499/2004 Sb. vyhláška č. 191/2009 Sb., Národní standard pro vedení elektronického systému spisové služby. Tuto shodu je nutno prokázat certifikátem české certifikační autority. Úložiště musí být vybaveno funkcí automatického tzv. read fail-over – tedy v případě, že vypadne primární důvěryhodné úložiště je požadavek automaticky přesměrován a data jsou poskytnuta z důvěryhodného úložiště v záložní lokalitě. Vzhledem k tomu, že data vhodná pro elektronický archiv nejsou obsažena pouze v systémech uvedených výše, ale i v jiných systémech (jako např. elektronická pošta, ekonomický systém, personální systém a další), požaduje zadavatel maximální modularitu systému s ohledem na integraci do stávající infrastruktury. Pro integraci na úrovni aplikační je požadováno rozhraní standardu XAM, dále pak možnost rozšíření zařízení o nativní funkcionalitu systému pro přístup k datům prostřednictvím CIFS, NFS, FTP a http. Servery Servery DC

Všechna DC budou vybavena z hlediska serverů identicky. Požadavky na fyzické servery: • Koncepce blade serverů • Procesory Intel E5-2650 • Paměťové moduly DDR3-1600-MHz • Bez lokálních disků • Možnost bootovat z flash disku (USB, SD a pod.) • Možnost boot from SAN • CNA adaptéry podporující alespoň 16 virtuálních rozhraní Ethernet a FibreChannel a s rychlostí alespoň 2 x 40GE • Centrální správa blade serverů s možností konfigurace identifikačních parametrů, jako UUID, WWN, MAC adres a konfiguračních parametrů jako boot order, LAN a SAN konektivity, verze firmware pro jednotlivé komponenty serverů včetně verze BIOSu pomocí profilů. Možnost přenosu profilů mezi servery bez ohledu na jejich umístění v rámci datového centra • Možnost aplikace identického profilu na různé HW konfigurace kvůli minimalizaci počtu záložních fyzických serverů • Externí konektivita serverového řešení nejméně 8 x 10 GE a 8 x 8G FC z každého síťového modulu v rámci redundantního páru • Podpora pro failover ethernet rozhraní v serverech mezi výstupními porty na úrovni infrastruktury (bez speciálních driverů) • Plně redundantní zdroje

VERZE 01



• Vzdálená virtuální konzole přístupná pomocí IP • Autentizace správy serverů proti LDAP nebo ActiveDirectory • Podpora role-based access control • Podpora správy spotřeby serverů na úrovni jednotlivých serverů, chassis, nebo racku

Tabulka 1: Fyzické servery pro 1 DC

Socket / Cores per socket 2/ 8

Velikost RAM (GB) 96

OZN.

Účel

Počet

DCx_S_01-02

Integrační platforma a GIS

DCx_S_11-26

Virtuální desktopy

2/ 8

128

16

DCx_S_31-32

IP telefonie

2/ 8

96

2

DCx_S_41-42

Správa báze dat

1/ 6

1

2

DCx_S_51-52

Správa prostředí

2/ 8

96

2

Počet vCPU

Velikost RAM (GB)

Počet

2

Tabulka 2: Virtuální stroje pro 1 DC

OZN.

Účel

DCx_V_01-03

IP telefonie

4

4

3

DCx_V_11-14

Integrační platforma - komponenty

4

8

4

DCx_V_21-22

GIS

4

32

2

DCx_V_101-350 Virtuální desktop

1

4

250

DCx_V_31_32

Connection Broker

2

8

2

DCx_V_41_44

Správa prostředí

2

8

4

Servery pro krajská DC

Všechna krajská DC budou vybavena z hlediska serverů identicky. Požadavky na fyzické servery: • Rack mount řešení • Procesory Intel E5-2650 • Paměťové moduly DDR3-1600-MHz • Disková kapacita: o 10 x 1TB SATA 7.2k otáček o 8 x 300GB SAS 15k otáček o RAID kontrolér s podporou RAID10 a RAID5 • Síťový adaptér 2 x 10GE • Redundantní zdroje

VERZE 01



• Vzdálená virtuální konzole přístupná pomocí IP • Autentizace správy serverů proti LDAP nebo ActiveDirectory • Podpora role-based access control • Podpora správy spotřeby serverů na úrovni jednotlivých serverů, chassis, nebo racku Tabulka 3: Fyzické servery pro 1 krajské DC

OZN.

Účel

KCxx_S_01-02

Integrační platforma a GIS

Socket / Cores per socket

Velikost RAM (GB)

Počet

2/ 8

96

2

Počet vCPU

Velikost RAM (GB)

Počet

Tabulka 4: Virtuální stroje pro 1 krajské DC

OZN.

Účel

DCx_V_11-14

Integrační platforma - komponenty

4

8

4

DCx_V_21-22

GIS

4

32

2

DCx_V_41_44

Správa prostředí

2

8

4

Pracoviště klientů Pracoviště NSPTV

Tato pracoviště budou umožňovat výhradně příjem tísňového volání a další činnosti v rámci systému NIS IZS (supervizi, administraci a dohled NIS IZS). Pracoviště NSPTV budou vybavena: Tenkým PCoIP klientem s touto specifikací: • 3 DVI porty • HW akcelerace • další specifikace bude doplněna Monitory s touto specifikací: • počet monitorů 3 • uhlopříčka 24“ • rozlišení 1920x1080 • další specifikace bude doplněna Klávesnicí a myší s touto specifikací: • připojení USB Náhlavní soupravou s touto specifikací: • další specifikace bude doplněna

VERZE 01



IP telefonem, který umožní připojení náhlavní soupravy operátora příjmu, práci s hovorem z aplikace NSPTV nebo přímo pomocí ovládacích tlačítek telefonu. IP telefony lze rozmístit libovolně v celé VPN NSPTV. IP telefony umožní jak práci s hovorem, tak zobrazení textových informací na displeji telefonu - např. stav systému, informace pro operátora příjmu mimo aplikační prostředí apod. Obrázek 17: Schéma pracoviště NSPTV

Virtuální klient

TEL

IPL

DC GIS server

IP telefon

HW klient

B

A

C

3 x monitor

klávesnice myš

Náhlavní souprava

operátor

sál pro operační řízení

Pracoviště hybridní

Tato pracoviště umožní práci v režimu buď příjem tísňového volání, nebo v režimu operační řízení. Využití jednoho pracoviště souběžně pro příjem tísňového volání i operační řízení není možné. Přepojením pracoviště do režimu operační řízení je klient NSPTV neaktivní a nemůže mu být přidělen tísňový hovor. Všechna hybridní pracoviště budou vybavena stejně jako pracoviště NSPTV, a to: • tenkým klientem • 3 monitory 24“ s rozlišením 1920x1080 • klávesnicí • myší • náhlavní soupravou • IP telefonem Jejich technická specifikace je uvedena výše. Navíc budou obsahovat KVM přepínač s touto specifikací: • ovládání z jedné klávesnice a myši 2 separátních vstupů do monitorů, jejich reproduktorů nebo externích reproduktorů nebo náhlavních sluchátek • přepínání softwarově, prostřednictvím klávesových zkratek, myši, tlačítka na čelním panelu KVM, prostřednictvím RS-232 nebo na dálkovém ovladači • počet monitorů nejméně 4, podpora rozlišení monitorů až 1920 x 1080 • připojení klávesnice a myši prostřednictvím portu USB

VERZE 01



Obrázek 18: Schéma hybridního pracoviště krajské DC Virtuální klient

TEL

IPL

DC složky IPL S

DC GIS server

GIS K server

RDS

replikace

IP telefon

HW klient

A

B

křížový přepínač

C

3 x monitor s audiopanely

Náhlavní souprava

dispečer

sál pro operační řízení

Koncepce redundance a dostupnosti na úrovni HW Koncepce dostupnosti systémů NIS IZS je postavena na řešení, které kombinuje zálohování systémů a jejich dostupnost prostředky aplikačními a prostředky infrastrukturními. Tato kapitola popisuje koncepce použité v řešení dostupnosti prostředky hardwarové infrastruktury. Redundance komponent

Všechny komponenty síťové infrastruktury v centrálních datových centrech a v krajských datových centrech jsou zdvojeny a zdvojeno je i jejich připojení tak, aby pro servery (virtuální i fyzické), hlasové brány a další prvky existovaly vždy dvě redundantní datové cesty k ostatním komponentám i směrem k ITS a případně do dalších lokalit. Konfigurace prvků pak zajišťuje, že výpadek libovolného prvku nebo datového okruhu neznamená výpadek celého systému nebo jeho části z hlediska dostupnosti poskytovaných služeb. Rychlost detekce poruchy

Síťová infrastruktura poskytuje podporu zálohování a vysoké dostupnosti aplikací tam, kde aplikace toto neřeší přímo aplikačními prostředky, prostřednictvím loadbalancerů (SLB a GSLB). Protože vyjma IP telefonie uživatelé přistupují ke službám prostřednictvím centralizovaných virtuálních desktopových stanic, dostupnost služeb lze z hlediska prostředků a koncepce zajištění rozdělit na dva okruhy: • Dostupnost služeb v rámci datového centra nebo více center z hlediska virtuálního desktopu • Dostupnost vlastního virtuálního desktopu uživatelem konkrétního pracoviště Dostupnost služeb v rámci datového centra je řešena prostřednictvím loadbalancerů, které jsou konfigurovány tak, že: • Pro danou službu prezentují virtuální IP adresu, vůči které jsou konfigurovány klientské strany této služby. Klient tak nezná identitu konkrétních serverů, na nichž služba může být dostupná, ale pouze tuto virtuální adresu.

VERZE 01



• Tato virtuální adresa je zveřejněna směrovacím protokolem OSPF jako host route v případě, že je k dispozici alespoň jeden skutečný server s dostupnou službou. Host route může být v různých datových centrech zveřejňována s různou metrikou a tímto způsobem je zvoleno primární a záložní datové centrum • Loadbalancer kontroluje dostupnost služby • Loadbalancer zprostředkuje komunikaci mezi klientem a vybraným skutečným serverem, na němž je služba dostupná Pro kontrolu dostupnosti může loadbalancer využít řady metod, v případě NIS IZS nabídnou aplikace, které budou mít dostupnost zajištěnu prostřednictvím loadbalanceru, službu pro zjištění dostupnosti IP ve formě html stránky s obsahem indikujícím, zda je daná služba dostupná pro vyřizování požadavků, či nikoli. To pokrývá dostupnost služby jako takové a všech služeb, které jsou pro danou službu podmiňující, jako je například dostupnost databázového stroje. Toto řešení umožní detekci chyby v řádu sekund (nejméně 3 sekund) a následně reakci na tuto chybu. Dostupnost virtuálních desktopů bude řešena prostřednictvím dvou komponent. Infrastruktura virtuálních desktopů obsahuje pro zprostředkování připojení klientského pracoviště k virtuálnímu desktopu daného uživatele komponentu, které se říká connection broker. Jedná se o virtuální server s funkčností onoho “zprostředkovatele”. Tato komponenta je opět zdvojena a ve virtuální infrastruktuře provozována na různých fyzických serverech. Výběr connection brokera má na starosti opět loadbalancer a opět používá pro zveřejnění služby virtuální IP adresu, kterou redistribuuje do směrovacích algoritmů jako host route s danou metrikou. Obrázek 19: Dvojí úroveň zajištění dostupnosti

Doba zotavení

Doba zotavení je dána jednak rychlostí detekce poruchy (minimálně 3 sekundy), dobou reakce na ni, resp. změna směrovacích informací na základě detekce chyby (lze dosáhnout změny v řádu jedné sekundy) a dobou reakce klientské aplikace nebo zařízení.

VERZE 01



U síťové vrstvy tak lze očekávat zotavení v řádu 5 až 10 sekund. Záložní scénáře

Datová centra vybudovaná podle výše uvedených principů umožní provoz v pražských datových centech tak, že jedno bude považováno za primární a druhé za sekundární, nebo že obě datová centra budou provozována v režimu active-active a výpadek mezi lokalitami bude transparentně vykrýván od poruch jednotlivých komponent po selhání celé jedné lokality nebo připojení k ní. Zvolený provozní režim z hlediska vysoké dostupnosti a zejména z důvodu rychlého zotavení se z chybových stavů je režim active-active, zejména u farmy virtuálních desktopů, jejichž znovuspuštění v záložní lokalitě by představovalo nejdelší výpadek provozu z důvodu nutnosti interance uživatele. Farma virtuálních desktopů, kde část virtuálních desktopů bude provozována v jednom a část v druhém pražském datovém centru bude transparentně přistupovat ke službám v jednom nebo druhém datovém centru podle aktuálního stavu provozu pomocí mechanismů popsaných v kapitole Koncepce redundance. Odolnost jednotlivých HW prvků řešení Obrázek 20: Možné výpadky a jejich řešení

Redundance datového úložiště (storage) a virtualizace Návrh disaster revovery počítá se třemi DC umístěnými v těchto lokalitách:

VERZE 01

•

DC1 – MV, Olšanská 4, Praha

•

DC2 - Česká pošta, Sazečská, Praha – Malešice

•

DC3 – HZS Olomouc (nový objekt)



První dvojice DC vzdálených do 10km v lokalitě Praha počítá s provozem Active/Active. Třetí datové centrum v Olomouci vzdálené 300km reprezentuje Active/Active zálohu datových center. Celková RAW kapacita úložiště 40TB bude rozdělená na 30/10TB. Menší část kapacity bude replikovaná mezi DC Active/Active. Nereplikovanou kapacitu 30TB využijeme pro lokální aplikace v každém DC a pro aplikace, které řeší DR na aplikační úrovni. Vysoká dostupnost hlasového systému Hlasový systém bude modulární, jeho jednotlivé prvky propojené IP sítí. Redundanci lze tedy řešit v následujících blocích: Obrázek 21: Bloky k řešení redundance telefonie

V uvedených blocích pak očekáváme následující druhy poruchy a reakci na ni: ISDN připojení do VTS/složky •

fyzická ztráta spojení na E1 okruhu - použití záložního okruhu podle zálohovacích scénářů

•

ztráta signalizace - použití záložního okruhu podle zálohovacích scénářů

Hlasová brána •

ztráta LAN - použití záložního LAN portu bez ztráty probíhajících hovorů

•

výpadek celého hardware - přechod na záložní bránu

LAN/WAN

VERZE 01

•

částečný výpadek - konvergence sítě bez ztráty probíhajících hovorů

•

úplný výpadek - hlasová brána odpojí ISDN linky. VTS a složky použijí záložní směrování do ostatních datových center NSPTV



Call Control/CTI/Media •

výpadek služby - přechod na jiný člen clusteru

•

výpadek hardware - přechod na jiný člen clusteru

Integrační platforma •

výpadek služby - přesun aktivního serveru na záložní server Integrační Platformy

•

výpadek hardware - přesun aktivního serveru na záložní server Integrační Platformy

Nahrávání Pro nahrávání hovorů bude využito záznamového zařízení VoIP recorder, které je určeno pro nahráván všech příchozích a odchozích hovorů na definovaných linkách (poboček, či agentů), včetně podpory centrálního nahrávacího aplikačního serveru, který je určený pro práci se záznamy a k jejich archivaci. Možné způsoby pořízení záznamu: •

Pro záznam VoIP linek může být využit aktivní způsobu záznamu hovorů. Tato funkcionalita zajistí přeposílání kopie RTP paketů z nahrávaného telefonu přes nakonfigurovaný „záznamový“ SIP trunk k určenému VoIP recorder (podle přiřazeného Recording Profile).

•

Pro záznam VoIP linek může být využit pasivní způsob záznamu pomocí vyhrazeného SPAN portu, přes který budou odesílány kopie RTP paketů do záznamového zařízení VoIP recorder.

Pro řízení záznamu a pro získávání požadovaných údajů k hovorům je využita CTI integrace s centrálním uzlem řízení hovorů. Návrh řešení záznamového systému je navržen v plně geograficky redundantní topologii DC (geografické redundance 1:1) - primární část systému je umístěna v lokalitě DC1, sekundární v lokalitě DC2. Každá z obou částí záznamového systému je schopna zajistit požadavky na záznam všech hovorů a to i v případě kompletního či částečného výpadku jednoho z DC. Každá lokalita (primární i záložní) se skládá z jednoho aplikačního serveru a dvou záznamových jednotek VoIP recorder. Nahrávání v DC3 nemá redundantní topologii. Návrh řešení dále počítá s využitím aplikace porovnání, která zajistí vzájemným porovnáním databáze záznamů obou aplikačních serverů dostupnost všech záznamů na centrálním a redundantním aplikačním serveru současně. Návrh řešení je postaven tak, aby byl schopný pokrýt předpokládaný počet 300 operátorských pozic. Všechny zaznamenané hovory (audio soubory + údaje o hovoru) na záznamovém zařízení jsou po jejich nahrání na záznamovém zařízení VoIP recorder replikovány a uloženy v SQL databázi a v archivu na externím úložišti. Přístup uživatelů k záznamům je zajištěn prostřednictvím www prohlížeče (http(s) klient) z jednotlivých desktopů agentů a supervizorů, dle nastaveného oprávnění. Předpokladem návrhu řešení je, že pro instalaci všech součástí záznamového systému budou vyžity virtuální stroje, včetně externího úložiště (diskového pole). Architektura návrhu řešení záznamového systému počítá s aktivním i pasivním záznamem hovorů pro NSPTV. Rozdíl je v tom, že aktivní nahrávání používá pro zrcadlení hlasového

VERZE 01



provozu koncové IP telefony, zatímco pasivní využívá zrcadlení provozu z LAN prvků, tzv. SPAN porty. Obě technologie lze kombinovat do společného řešení. CTI integrace Základní atributy hovorů (ANI, DNIS, ID agenta, datum a čas volání, délka volání, linka, segment, kampaň, lokalita, informace o agentovy atd.) jsou doplňovány automaticky z CTI přímo na záznamovém zařízení, odkud jsou spolu s audio soubory replikovány do aplikačního serveru. Rozsah těchto atributů je limitován tím, co je v CTI integraci použité technologie dostupné.

VERZE 01



Aplikační architektura Aplikační architektura zachycuje základní subsystémy NIS na úrovni komponent a protokoly pro komunikaci mezi těmito subsystémy. Obrázek 22: Konceptuální model NIS 1xKRAJ (HZS)

DC

KRAJ / SLOŽKA

Telefonie

CGIS TEL

REC

Hlasová brána

APP Telefonie

KGIS NFS Replikace

Centrální GIS

Nahrávání

Krajský GIS

IS pro operační řízení (OŘ)

REST

ITS náhradní konektivita

JTAPI VTS

není předmětem dodáveky

IPL Routing

JTAPI Service

WS-Stack

Klient OŘ GIS SDK

IPL Krajský routing

Konektor IPL

Není předmětem dodávky

REST SOAP

BPM

Monitoring

Rules

ITS

NSPTV Registry

Messaging

Extensions

Virtuální klient NSPTV

INFRA

TCP/IP

Pracoviště TCTV

SOAP PCoIP Terminál s telefonem ITS

LDAP

Persistent Layer

IDM TCP/IP

RDBMS (HA)

Shared FS (HA)

LDAP

TCP/IP

Systém je z hlediska funkčního členěn do těchto subsystémů: • IPL – Integrační platforma • TEL – Telefonie • REC – Nahrávání • NSPTV – Aplikace NSPTV (příjem tísňových hovorů) • GIS – Centrální GIS (pro potřeby NSPTV) • KGIS – Krajský GIS (pro potřeby operačního řízení) • ADM – Administrace systému • INFRA – Infrastruktura systému (persistentní úroveň – DBMS a FS, IDM) Členění funkcionality do těchto subsystémů je provedeno bez ohledu, v jaké vrstvě systému je příslušná funkcionalita zajištěna (např. na úrovni síťové vrstvy či HW architektury, na persistentní či vlastní aplikační úrovni), ale naopak s ohledem na to, kde je tato funkcionalita dostupná uživateli (prezentační vrstva funkcionality, pokud existuje) nebo jiným subsystémům. Každý subsystém může vystupovat jak v roli klienta, tak v roli serveru. U všech služeb je vyznačeno, zda při vzájemné komunikace využívají funkcionalitu integrační platformy. Funkce jsou dále tříděny podle dostupnosti na: • Public – služba je dostupná pro ostatní systémy v registru služeb. • Private – jde o interní funkci systému, která není volatelná z jiného subsystému.

VERZE 01



U všech funkcí je také uvedeno, zda jde o funkci automatickou (běží na pozadí systému bez uživatelské interakce) nebo uživatelskou (s výstupem na obrazovku a s předpokládanou interakcí s uživatelem). Forma zajištění těchto funkcí na úrovni aplikační je uvedena ve sloupci Služba. Tabulka 5: Funkcionalita NIS IZS OZN. Funkce

VERZE 01

Client

IPL

automatická Public

APL

ANO

IPL

iplSpojitHovor

Automaticky lokalizovat volajícího podle BTS a sig.

automatická Private

IPL

IPL

IPL

iplZjistitLokalizaci

Ověřit volající číslo na blacklistu a whitelistu


IPL

ANO

IPL

iplKontrolaListu

4

Aktivovat upozornění a nabídku pro operátora (list)


APL

NE

APL

aplAktivaceNabidky

5

Přehrát výstražnou hlášku


IPL

ANO

TEL

iplPrehratHlasku

6

Zařadit volající číslo na blacklist

uživatelská

Public

APL

ANO

IPL

iplUpravitList

7

Odstranit číslo z blacklistu

uživatelská

Public

APL

ANO

IPL

iplUpravitList

8

Přepojit hovor na zadané číslo ve whitelistu

automatická Public

IPL

ANO

TEL

iplVytvoritKonferenci

9

Přehrát úvodní hlásku


IPL

ANO

TEL

iplPrehratHlasku

10

Vyhledat volného operátora nebo zařadit do fronty


IPL

ANO

IPL

iplVyhledatOperatora

11

Přehrát hlásku operátora nebo fronty


IPL

ANO

TEL

iplPrehratHlasku

12

Vizualizovat oblast volání

automatická Public

APL

NE

GIS

aplVizualizovatVolani

13

Přepojit informační hovor

uživatelská

Public

APL

ANO

TEL


14

Přepojit hovor konferencí

uživatelská

Public

APL

ANO

TEL


15

Založit událost

uživatelská

Public

APL

ANO

IPL

iplZalozitUdalost

19

Editovat událost

uživatelská

Public

APL

ANO

IPL

iplUpravitUdalost

18

Vizualizovat událost v NIS

automatická Public

APL

NE

GIS

aplVizualizovatUdalost

18

Poskytnout TASR

uživatelská

APL

ANO

IPL

iplVyhledatSkript

19

Provést klasifikaci události

uživatelská

Public

APL

ANO

IPL

iplUpravitUdalost

20

Definovat typ události

uživatelská

Public

APL

ANO

IPL

iplUpravitUdalost

21

Definovat závažnost a neodkladnost události

uživatelská

Public

APL

ANO

IPL

iplUpravitUdalost

24

Lokalizovat místo události

uživatelská

Private

APL

NE

GIS

aplLokalizovatUdalost

25

Vyhledat data podle zadání

uživatelská

Public

APL

NE

GIS

aplVyhledatGisData

26

Upravit rajonizaci

automatická Public

APL

NE

GIS

aplUpravitRajonizaci

27

Určit rajonizaci


IPL

ANO

IPL

iplUrcitRajonizaci

26

Verifikovat rajonizaci

uživatelská

Private

APL

NE

APL

aplUpravitUdalost

27

Dovytěžit hovor

uživatelská

Public

APL

ANO

IPL

iplUpravitUdalost

28

Zpracovat informace pro součinnost

uživatelská

Public

APL

ANO

IPL

iplUpravitUdalost

29

Vyžádat součinnost

uživatelská

Public

APL

ANO

IPL

iplPredatUdalost

30

Vyhledat subjekt pro konferenci

uživatelská

Public

APL

ANO

IPL

iplVyhledatSubjekt

31

Spojit konferenci

uživatelská

Public

APL

ANO

TEL


32

Ukončit hovor

uživatelská

Public

APL

ANO

TEL

iplUkoncitHovor

33

Aktualizovat událost

automatická Public

APL

ANO

IPL

iplUpravitUdalost

34

Zahájit nahrávání

automatická Public

APL

ANO

REC

iplZahajitNahravani

35

Ukončit nahrávání

automatická Public

APL

ANO

REC

iplUkoncitNahravani

36

Zadat parametry vyhledání nahrávky

uživatelská

APL

NE

APL

aplVyhledatNahravku

37

Vyhledat nahrávky

automatická Public

IPL

ANO

REC

iplVyhledatNahravky

38

Přehrát nahrávku

uživatelská

Public

IPL

ANO

REC

iplPrehratNahravku

39

Exportovat nahrávky

uživatelská

Public

APL

ANO

REC

admExportovatNahravku

40

Zálohovat nahrávky

automatická Public

IPL

ANO

REC

admZalohovatNahravky

1

Převzít hovor s polohou volajícího

2 3

Typ funkce

Dostupnost

Public

Private


Server Služba


OZN. Funkce

VERZE 01

Typ funkce

Dostupnost

automatická Public

Client

IPL

APL

ANO

Server Služba

41

Předat zprávu s aktualizací události

IPL

iplPredatUdalost

42

Předat zprávu s vyžádáním součinnost

automatická Public

APL

ANO

IPL

iplPredatUdalost

43

Předat zprávu o potvrzení součinnosti

automatická Public

APL

ANO

IPL

iplPredatUdalost

44

Eskalovat vyžádání součinnosti

automatická Public

APL

ANO

IPL

iplPredatUdalost

48

Aktualizovat vizualizaci operační situace

automatická Public

APL

NE

GIS

aplAktualVizualizaci

46

Odeslat filtrovanou událost náhradní cestou

automatická Public

APL

ANO

IPL

iplPredatUdalost

47

Aktualizovat odeslanou událost do OR

automatická Public

APL

ANO

IPL

iplPredatUdalost

48

Zpracovat a odeslat požadavek CGIS

uživatelská

Public

APL

NE

APL

aplZobrazitMapovePodklady

49

Odhlásit uživatele

uživatelská

Public

APL

ANO

IPL

iplOdhlasitUzivatele

50

Spravovat uživatele NSPTV

uživatelská

Private

ADM

NE

ADM

admCRUDUzivatele

51

Importovat aktuální seznam uživatelů OŘ

uživatelská

Private

ADM

NE

ADM

admImportovatUzivatele

52

Exportovat aktuální seznam uživatelů pro OŘ

uživatelská

Private

ADM

NE

ADM

admExportovatUzivatele

53

Spravovat uživatele a jejich oprávnění

uživatelská

Private

ADM

NE

ADM

admSynchronizovateUzivatele

54

Spravovat znalosti

uživatelská

Private

ADM

NE

ADM

admCRUDZnalost

55

Vyhledat logy

uživatelská

Private

ADM

NE

ADM

admVyhledatLog

67

Zobrazit detail logu

uživatelská

Private

ADM

NE

ADM

admDetailLogu

57

Spravovat pravidla NSPTV

uživatelská

Private

ADM

NE

ADM

admCRUDPravidlo

58

Spravovat pravidla přidělování hovorů

uživatelská

Private

ADM

NE

ADM

admCRUDPravidlo

59

Spravovat pravidla vizualizace

uživatelská

Private

ADM

NE

ADM

admCRUDPravidlo

60

Spravovat pravidla směrování

uživatelská

Private

ADM

NE

ADM

admCRUDPravidlo

61

Spravovat procesy NSPTV

uživatelská

Private

ADM

NE

ADM

admCRUDProces

62

Spravovat blacklist a whitelist

uživatelská

Private

ADM

NE

ADM

admCRUDList

63

Zálohovat data NSPTV


ADM

NE

ADM

admZalohovatData

64

Extrahovat data do datového skladu


ADM

NE

ADM

admExtrahovatData

65

Spustit připravený report

uživatelská

Private

MON

NE

MON

monVytvoritReport

66

Vytvořit ad-hoc report

uživatelská

Private

MON

NE

MON

monVytvoritReport

67

Publikovat report

uživatelská

Private

MON

NE

MON

monPublikovatReport

68

Exportovat report

uživatelská

Private

MON

NE

MON

69

Rozeslat eskalační alert via SMS


ADM

IPL

IPL

70

Analyzovat data z NSPTV

uživatelská

Private

MON

NE

MON

monAnalyzovatData

71

Archivovat data z NSPTV


ADM

NE

ADM

admArchivovatData

72

Importovat aktualizaci INFO35


ADM

NE

ADM

admImportovatDataInfo35

73

Analyzovat zlomyslná volání

uživatelská

Private

MON

NE

MON

74

Zablokovat časově číslo na blacklistu

uživatelská

Public

APL

ANO

IPL

75

Exportovat zlomyslné volání

uživatelská

Private

MON

NE

MON

88

Sloučit událost

uživatelská

Public

APL

ANO

IPL

iplSloucitUdalost

89

Vytvořit příposlech

uživatelská

Public

APL

ANO

TEL


90

Přehrát výstrahu

uživatelská

Private

IPL

ANO

TEL

iplPrehratHlasku

92

Zobrazit seznam aktivních operátorů

uživatelská

Private

IPL

ANO

IPL


93

Logovat systémové události


IPL

ANO

IPL

iplAuditSystem


monExportovatReport iplOdeslatAlert

monAnalyzovatData iplUpravitList monExportovatReport


Služby dostupné v rámci NIS jsou dále specifikovány popisem své funkce a specifikací svých vstupů a výstupů: Tabulka 6: Popis služeb NIS OZN. Služba

VERZE 01

Popis služby

Vstup

1

admArchivovatData

Apl ika ční podpora pro a rchi va ci da t NIS

[typ_a rchivace]

Výstup [status ]

2

admCRUDList

Apl ika ční podpora pro správu bla ckli s tu a whitel is tu

[pol ozka]CU|[fil ter]R|[i d_polozky]D

[id_polozky]C|[sezna m_pol ozek]R|[-]UD

3

admCRUDPravidlo

Apl ika ční podpora pro prá ci s pra vi dly

[pra vi dl o]CU|[fil ter]R|[id_pravidla ]D

[id_pra vidla ]C|[s ezna m_pra videl]R|[-]UD

4

admCRUDProces

Apl ika ční podpora pro prá ci s proces y

[proces ]CU|[fi lter]R|[id_procesu]D

[id_proces u]C|[s eznam_proces u]R|[-]UD

5

admCRUDUzivatele

Apl ika ční podpora pro a dmi nis tra ci a sprá vu uživa telů

[uzi va tel]CU|[fil ter]R|[i d_uziva tel e]D

[id_uzivatel e]C|[sezna m_uziva telu]R|[-]UD

6

admCRUDZnalost

Apl ika ční podpora pro a dmi nis tra ci a sprá vu zna lostí

[zna los t]CU|[filter]R|[i d_zna los ti ]D

[id_znal os ti]C|[s eznam_zna l os ti ]R|[-]UD

67

admDetailLogu

Apl ika ční podpora pro a na lýzu logů

[id_log]

[log]

8

admExportovatNahravku

Apl ika ční podpora pro export na hrá vek.

[s eznam na hra vek]

[-]

9

admExportovatUzivatele

Apl ika ční podpora pro exportování uži va telů

[s eznam_uzi va tel u]

[status ]

10

admExtrahovatData

Apl ika ční podpora pro extra kci da t do DS.

[typ_extra kce]

[status ]

11

admImportovatDataInfo35

Apl ika ční podpora pro a dmi nis tra ci i mportů z INFO35

[typ_i mportu]

[status ]

12

admImportovatUzivatele

Apl ika ční podpora pro importová ní uži va tel ů


[status ]

13

admSynchronizovateUzivatele

Apl ika ční podpora pro synchroniza ci uži va telů


[status ]

14

admVyhledatLog

Apl ika ční podpora pro a na lýzu logů

[fi lter]

[sezna m_id_l ogu]

15

admZalohovatData

Apl ika ční podpora pro zá l ohová ní da t.

[typ_zal ohy]

[status ]

16

admZalohovatNahravky

Apl ika ční podpora pro zá l ohová ní na hrá vek.

[s eznam na hra vek]

[-]

17

aplAktivovatNabidku

Apl ika ční podpora pro a ktivaci přís luš né formulá řové na bídky.

[typ_hovoru,typ_formul are]

[-]

48

aplAktualVizualizaci

Apl ika ční podpora pro a ktua l iza ci vizual iza ce

[id_uda los ti ]

[status ]

24

aplLokalizovatUdalost

Apl ika ční podpora pro lokal izaci mís ta udál osti.

[te xt, geometri e]

[geometri e]

26

aplUpravitRajonizaci

Apl ika ční podpora pro vi zua li za ci rajoni za ce a její úpra vu

[geometrie]

[feature]

21

aplUpravitUdalost

Apl ika ční podpora pro změnu nebo určení vla stní rajoni za ce.

[s eznam_ra jonu]

[-]

18

aplVizualizovatUdalost

Apl ika ční podpora pro vi zua li za ci místa udá los ti

[geometrie]

[status ]

23

aplVizualizovatVolani

Apl ika ční podpora pro vi zua li za ci místa volá ní. Funkciona li ta těžkého klienta .

[mís to_vola ni]

[-]

25

aplVyhledatGisData

Apl ika ční podpora pro vyhledává ní v datech GIS

[text]

[featureset]

25

aplVyhledatNahravku

Apl ika ční podpora pro vyhledává ní v nahrá vká ch.

[nahravka _dotaz]

[sezna m_na hra vek]

26

aplZobrazitMapovePodklady

Interní s lužba APL pro odesl á ní poža da vku na centrá lní GIS server.

[ma pove_podkla dy]

[status ]

93

iplAuditSystem

Interní a pl ika ční podpora pro logová ní udál ostí.

[para metry fce, ča s]

[-]

28

iplKontrolaListu

Interní s lužba IPL pro kontrolu oprá vnění vola jícího.

[tel_cis lo, typ_li stu]

[boolea n]

29

iplOdeslatAlert

Sl užba IPL pro rozesl ání va rování.

[s eznam_uzi va tel u,da ta _notifikace]

[status ]

30

iplOdhlasitUzivatele

Sl užba IPL pro odhl áš ení uži va tel e.

[s es s ion_id]

[status ]

31

iplPredatPotvrzeni

Sl užba IPL pro předání udá los ti s potvrzením.

[uda l os t]

[status ]

32

iplPredatUdalost

Sl užba IPL pro předání udá los ti z APL nebo OŘ.

[zprava ]

[status ]

33

iplPredatUdalostNahradni

Sl užba pro předá ní udá l os ti z OŘ (na př. po výpa dku a obnově konektivity).

[zprava ]

[status ]

34

iplPrehratHlasku

Sl užba IPL pro přehrá ní hlá š ky z čís el níku na zá kl adě i denti fi ká toru

[id_hl a sky]

[-]

35

iplPrehratNahravku

Sl užba IPL pro přehrá ní da né na hrá vky.

[id_na hra vky]

[-]

88

iplSloucitUdalost

Sl užba IPL pro úpra vu a s loučení udá los ti.

[uda l os t]

[status ]

37

iplSpojitHovor

Sl užba IPL pro převzetí informace o příchozím hovoru.

[id_hovoru]

[id_hovoru]

38

iplUkoncitHovor

Sl užba IPL pro ukončení hovoru.

[id_opera tora]

[da ta _za ves eni ]

39

iplUkoncitNahravani

Interní s lužba IPL pro ukončení na hrá vání (v rá mci procesu PTV)

[operator]

[status ]

40

iplUpravitList

Sl užba IPL pro úpra vy bla ckl is tu či whi teli stu.

[pol ozka_li s t, typ_li stu, opera ce]

[status ]

19

iplUpravitUdalost

Sl užba pro úpra vu udá losti

[uda l os t]

[status ]

27

iplUrcitRajonizaci

Sl užba pro a utoma tické určení ra joni za ce

[mís to_vola ni]

[sezna m_ra jonu]

43

iplVyhledatNahravky

Sl užba IPL pro vyhledá ní nahrávky dle za daných pa ra metrů.

[nahravka _dotaz]

[sezna m_na hra vek]

44


Sl užba IPL pro vyhledá ní operátora na zá kla dě za daných kri téri í.

[operator_dota z]

[sezna m_opera toru]

92


Sl užba IPL pro vyhledá ní operátora na zá kla dě za daných kri téri í.

[operator_dota z]

[sezna m_opera toru]

46

iplVyhledatSkript

Sl užba IPL pro s pouš tění s kriptů pro podporu res us cita ce

[s kript_dotaz]

[skri pt]

47

iplVyhledatSubjekt

Sl užba pro zobrazení čísel níkových hodnot

[typ_s ubjektu]

[sezna m_subjektu]

48


Sl užba IPL pro přepojení hovoru na za da né čís lo.

[tel_cis lo, ca ll _i d]

[status ]

49

iplZahajitNahravani

Interní s lužba IPL pro zahá jení na hrá vá ní (v rá mci proces u PTV)

[operator]

[status ]

50

iplZalozitUdalost

Sl užba IPL pro vytvoření udá losti.

[uda l os t]

[id_uda losti]

51

iplZjistitLokalizaci

Interní s lužba IPL pro zjiš tění loka l izačních úda jů vol ajícího.

[vol ajici_da ta]

[x,y,vki d]

52

monAnalyzovatData

Proces ní moni tori ng. Podpora pro a nal ýzu dat NSPTV.

[typ_a nal yzy]

[status ]

53

monAnalyzovatData

Proces ní moni tori ng. Podpora pro a nal ýzu dat.

[typ_a nal yzy]

[status ]

54

monExportovatReport

Proces ní moni tori ng. Funkce pro export poža dova ného reportu

[id_reportu]

[status ]

55

monExportovatReport

Proces ní moni tori ng. Funkce pro export poža dova ného reportu

[id_reportu]

[status ]

56

monPublikovatReport

Proces ní moni tori ng. Funkce pro publi ková ní požadova ného reportu

[id_reportu]

[status ]

57

monVytvoritReport

Proces ní moni tori ng. Funkce pro vytvoření požadova ného reportu

[typ_reportu, pa ra metry]

[report]



Integrační platforma (IPL) Routing

Routing modul zajišťuje snadnou realizaci a implementaci routovacích pravidel. Poskytuje sadu integračních patternů a umožňuje realizaci těchto typických integračních scénářů: • Message filter • Message dispatcher • Dynamic router • Recipient list • Splitter • Aggregator • Throttler • Idempotent consumer • WireTap Routing modul též poskytuje celou řadu konektorů (HTTP, TCP, UDP, SMTP, FTP, JMS, LDAP, JDBC). V případě specifických požadavků je možné programově rozšířit o další konektory. Monitoring

Integrační platforma poskytne standardizované rozhraní JMX pro monitoring jednotlivých služeb a modulů. Tyto metriky bude možné sledovat na úrovni každé komponenty: • Exchanges completed • Exchanges failed • Exchanges total • Inflight Exchanges • MaxProcessingTime • MeanProcessingTime • MinProcessingTime • LastProcessingTime • RedeliveriesCount Díky standardizovanému rozhraní je možné připojit externí již existující monitorovací systémy Dodavatele, který bude zajišťovat provoz NIS. Rules

Integrační platforma bude poskytovat mechanismus pro deklaraci a parametrickou realizaci systémových a business pravidel. Rule engine umožňuje oddělit data systému (fakta) od logiky vyjádřené prostřednictvím pravidel. Takto popsaná logika je snazší na údržbu a je možno nad ní lépe provádět dynamické změny systému. BPM

Služby, které poskytuje IZS budou realizovány sadou volání dílčích služeb poskytovaných buď okolními systémy, nebo samotnou integrační platformou a následnou kompozicí jejich

VERZE 01



výstupů – půjde tedy o komplexní procesy. Komplexní procesy mohou mít různou dobu trvání (od rychlých dotazů až po několikadenní proces se zapojením různých složek). Komponenta BPM umožní vytvořit jednotnou správu a řízení procesů. Registry

Registry představují katalog publikovaných služeb. Uchovávají jejich metadata, klasifikaci a umožňují službám nastavit některé provozní parametry, tak aby byly měnitelné za chodu systému. Umožňují též oddělit logické pojmenování služby (endpoint reference) a její fyzické umístění. WS-Stack

Komunikace mezi systémy bude až na výjimky (REST pro přímou komunikaci s GIS serverem) postavena na webových službách a otevřených standardech (SOAP/HTTP). Služby však lze vybudovat nad celou řadou protokolů jako SOAP, REST, XML / HTTP a využívat na různých transportních protokolech, jako je HTTP, JMS nebo CORBA. WS-Stack integrační platformy podporuje tyto standardy a kromě toho umožňuje využít i další rozšíření z oblasti WS-*. Systém je tak otevřený pro případné další rozšiřování včetně snadné integrace komponent třetích stran. JTAPI Service

JTAPI Service modul zprostředkovává komunikaci integrační platformy s telefonním subsystémem. Komunikační protokol mezi JTAPI Service a integrační platformou je SOAP. JTAPI Service pak komunikuje s telefonii prostřednictvím nativního JTAPI protokolu. Telefonní subsystém je tak zapouzdřený a je možné využívat jeho funkcionalitu voláním bezestavových služeb protokolem SOAP. Telefonie (TEL) Obrázek 23: Konceptuální model Telefonie (hlasového systému) ITS/WAN

DC1

KRAJ / SLOŽKA

Hlasová brána

Hlasová brána

PBX OŘ

Hlasová brána

PBX složky

Hlasová brána

PBX OŘ

Hlasová brána

PBX složky

APP Telefonie

Hlasová brána

Call Control Server

CTIl Server

Media Server

Call Control Server

CTIl Server

Media Server

ISDN VTS

Hlasová brána

Hlasová brána

Aplikační cluster

DC2

Není předmětem dodávky ISDN/IP

Systém využívá otevřená a dokumentovaná API a i jeho vnitřní komunikace je založena na otevřených standardech. Všechny komponenty hlasového systému budou virtualizované. Nahrávací systém bude virtualizován částečně - jeho nahrávací servery jsou hardwarové, archivační virtualizované. Architektura nahrávání souvisí se síťovou infrastrukturou, protože využívá její prvky k zrcadlení provozu.

VERZE 01



Nativním API hlasové platformy je JTAPI (http://www.oracle.com/technetwork/java/indexjsp-140696.html). Na úrovni integrační platformy bude ovládání a události hlasových služeb k dispozici pomocí SOA (WebServices na SOAP) v komponentě IPL: JTAPI Service. Důvodem je maximální otevřenost řešení. Interní komunikace je založena na protokolu SIP (RFC 3261). Díky tomu bude možné systém rozšiřovat o další prvky podle potřeby. Přenos hlasu (a případně obrazu) zajistí Real Time Protocol (RTP), případně Secure RTP (S-RTP). Kódování hlasového provozu bude v codecu G.711 nebo G.722, obraz v codecu H.264 AVC. Hlasový systém je složen z následujících komponent: Hlasové brány (GW)

Hlasové brány lze umístit na libovolné místo v síti, tedy i mimo datové centrum a lze tak vybudovat distribuovaný systém s centrálním řízením. Díky tomu bude možné např. využít hlasové přípojky ve všech datových centrech nebo na krajské úrovni a rozložit tak zátěž nebo optimalizovat scénáře zálohování. Hlasové brány umožní připojení těchto typů linek (umístění hlasových bran bude upřesněno v Rámcovém konceptu SW řešení): ISDN z VTS (veřejné telefonní sítě) - ISDN PRI od vybrané sady telefonních operátorů. Operátoři budou zodpovídat za doplnění lokačních a regionálních informací o volajícím podle stejného schématu, které používá služba TCTV112, směrování hovorů do odpovídajícího datového centra NIS, v případě výpadku některé z ISDN přípojek nebo datového centra budou mít nastaveno automatické přesměrování do záložního centra. k ostatním složkám IZS - po privátních ISDN PRI nebo E1 Q.sig linkách. Pokud to telefonní technologie na straně složek umožní, preferujeme namísto ISDN/Q.sig přímé SIP propojení. Hlasová brána bude nasazena i v případě SIP, protože telefonie složek je v jiných VPN než NSPTV. Brána pak bude fungovat jako hlasové/video proxy mezi těmito VPN, pojede v tzv. IPIP režimu. Hlasová brána je zodpovědná za: • signalizace s VTS nebo PBX složky - přijetí/odmítnutí hovoru, signalizace chybového stavu pro přesměrování na záložní linky nebo záložní datové centrum • přehrávání hlášek - obecné hlášky NSPTV, operátorské hlášky • signalizace s Call control serverem - sestavení hovoru na operátora • signalizace s Integrační platformou - informace o volajícím (číslo, poloha) • signalizace s nahrávacím serverem - aktivace nahrávání Call Control Server (CC)

• IP ústředna zajišťující základní funkce systému: • správa IP telefonů - konfigurace, dohled, aktualizace firmware • signalizace všech typů hovorů - mezi telefony, s VTS nebo se složkami; přímý hovor, konference, manipulace s probíhajícím hovorem. Call Control Server je zodpovědný za: • směrování hovorů na operátora (za jeho výběr zodpovídá Integrační platforma) • manipulace s hovorem - přijetí/přidržení/ukončení hovoru, sestavení konference

VERZE 01



• call detail records - záznamy o hovorech CTI Server (CTI)

Aplikační server integrovaný s Call Control serverem umožňující řízení všech hovorových scénářů a integraci hlasového systému s aplikační vrstvou skrze standardizované rozhraní. Z pohledu Integrační platformy to bude protokol SOAP. CTI Server je zodpovědný za ovládání IP telefonů z Integrační platformy. K dispozici jsou tyto funkce: • indikace příchozích hovorů • sestavení odchozího hovoru • aktuální stav koncových přístrojů (SW/HW) • aktivace/deaktivace nahrávání • konference - až 24 účastníků • odeslání textové zprávy na displej HW telefonu • manipulace s hovorem na telefonu:

přidržení přepojení přepojení v konferenci sestavení konference

Media Server (MS)

Media server integrovaný s Call Control Serverem sloužící pro terminaci RTP streamů, řízení konferencí více účastníků. Media Server je zodpovědný za: • míchání konferencí • přepojování v konferenci Call Control, CTI a Media Servery budou postaveny jako aplikační cluster s minimálně dvěma aktivními uzly v každém datovém centru. Každý uzel clusteru (virtuální server) bude schopen plnit některou nebo všechny serverové funkce (např. pouze CTI nebo call control + CTI + media). Konfigurace a provozní data budou jednotná přes celý cluster. Nahrávání (REC) Záznamový systém bude poskytovat nahrávání veškerých volání provedených v rámci systému NSPTV a to včetně interních volání. Záznamový systém bude rozložen do tří center NSPTV. Každé centrum bude vybaveno dvěma loggery (primary a secondary) - záznamovými zařízeními, které se vzájemně zálohují a jedním aplikačním serverem, který poskytují funkce www uživatelského prostředí pro práci se záznamy, integrační funkce s telekomunikační technologií, integrační funkce s informačními systémy NSPTV a zajišťuje dlouhodobou archivaci záznamů na společném externím úložišti. Aplikační servery v centrech vzájemně zálohují veškeré svoje funkce. Veškeré komponenty záznamového systému budou provozovány pod OS Windows server 2008. Systém podporuje virtualizaci. Celá sestava bude přísně navržena jako redundantní řešení v souladu s konceptem „no single point of failure“. Pevné disky systému budou zálohované v RAID systému.

VERZE 01



Záznamy ze všech center budou společně dlouhodobě ukládány na datové úložiště umístěné v datovém centru společném pro celé NSPTV. Záznamový systém bude úzce integrován s telekomunikační technologií Cisco UCM, která bude implementována v rámci NSPTV. Záznamový systém bude integrován se záznamovými systémy operačního řízení krajských operačních středisek a bude zpřístupňovat do krajů záznamy tísňových volání příslušných danému kraji a složce. Obrázek 24: Konceptuální model Nahrávání DC1 CTI-integration

CTIl Server

Primary Recorder 1

Primary Recorder 2

Eth. switch LAN

SPAN port

HTTP klient Terminál s telefonem

Primary APP Server

Persistent Layer

IP Extension Agent

DC/DC

Terminál s telefonem

PBX

compare

Recording Storage

Back-up APP Server

Eth. switch SPAN port

Back-up Recorder 1

Back-up Recorder 2

IP Extension Agent

DC2

Systém bude splňovat tyto požadavky pro záznam a integraci se systémy NSPTV: • Záznam IP telefonie včetně identifikací, podpora pro aktivní i pasivní způsob řešení nahrávání a jejich kombinace. • Integrace přes CTI rozhraní s telefonním systémem za účelem doplňování dalších parametrů o volání (ANI, DNIS, call ID, předaný/převzatý hovor, call flow, …) a pro online kontrolu správné funkce nahrávání. • Základní identifikace (směr hovoru, číslo volaného, volajícího) systém zajišťuje na základě telekomunikačních protokolů i při výpadku CTI rozhraní. • Nahrávky jsou ve formátu stereo s rozdělením směrů volaný a volající. • Nahrávky jsou pořizovány a ukládány ve formě a v kvalitě umožňující následné zpracování hlasovými analýzami. • Možnost archivování nahrávek v menším kompresním formátu, po uplynutí zákazníkem definované doby (šetření místa na datovém úložišti). • Systém je integrován s informačním systémem pro obsluhu tísňových volání NSPTV, jsou požadovány tyto funkce:

VERZE 01



o automatizované vzájemné párování hlasových záznamů k událostem systému NSPTV, o doplňování údajů z informačního systému do záznamového systému (ID události, …) o provozní přehrávání záznamů do pracovních náhlavních souprav operátorů ovládané přímo z uživatelského prostředí informačního systému NSPTV. Systém bude splňovat tyto požadavky na práci s hovory a přehrávání záznamů: • Provozní přehrávání záznamů z pozice operátorů NSPTV je řešeno integrací přes informační systém NSPTV viz výše. • Přímý přístup k systému, ovládání systému, práce s nahrávkami a přehrávání je přes webové rozhraní s podporou šifrovaného přenosu. • Možnost přehrávat odděleně oba směry hovoru. • Možnost přeskakování ticha v hovoru při přehrávání. • Vkládání značek do hovoru, možnost přehrávání ve smyčce mezi značkami. • Systém umožňuje vkládání několika textových poznámek do konkrétních míst hovoru v přehrávači pro podporu analýzy průběhu řešení události. • Grafické zobrazení průběhu signálu pro oba směry komunikace. • On-line příposlech hovorů. • Funkce wallboardu pro online monitoring práce operátorů NSPTV v lokalitách z pozice vedoucího směny: prostředí wallboardu zobrazuje aktivitu jednotlivých operátorů, z prostředí lze aktivovat příposlechy hovorů a vstupy do hovorů. • Přehrávání neukončeného hovoru a příposlech hovorů ze záznamu (příposlech ze zaznamenaných dat s minimálním zpožděním za probíhajícím hovorem s možností posuvů v čase). • Přehrávač s vypínatelnou funkcí AVC. • Možnost synchronního (souběžného) přehrávání záznamů z více kanálů (min 4) současně pro analýzu následností řešení hromadných krizových událostí. • Možnost přiřazení pravý/levý reproduktor pro přehrávaný kanál/kanály. • Hromadné grafické zobrazení provozu na záznamových kanálech v časové ose. • Podpora exportu záznamů (včetně synchronizace více kanálů) v obecných zvukových formátech. • Ochrana proti možnosti zmanipulování exportovaných záznamů digitálním podpisem verifikace. • Podpora pro manuální přepis (transkripci) záznamů do textu, snadné ovládání převíjení při přehrávání při vyhotovování přepisu a export textu (ovládáno klávesovými zkratkami). Z hlediska administrace přístupových práv a zabezpečení:

VERZE 01



• Hierarchická přístupová práva sestavená ve stromové struktuře. • Konfigurace profilů zpřístupněných funkcí a dat pro jednotlivá oprávnění. • Jednotná uživatelská oprávnění pro celý systém, podpora autentizace přes LDAP. • Konfigurovatelná dobu platnosti uživatelského účtu, po níž je účet automaticky zrušen, stejně tak i jeho tvar (síla). Dohledy a diagnostika

Podpora komplexní diagnostiky systému na úroveň jednotlivých komponent a aplikací: • Podpora SNMP protokolu pro dohledování a monitoring systému: o monitoring výsledné statusové proměnné jednoduše popisující stav systému, o komplexní informace až na úroveň jednotlivých komponent systému. • Online diagnostika funkce nahrávání na základě korelace s CTI událostmi. • Audit veškerých činností na záznamovém systému, přístup k informacím auditu podle úrovní oprávnění. • Propracovaný systém chybových kódů jednoznačně identifikující nestandardní stavy systému. Požadavky na integrační funkce

Systém poskytuje API rozhraní pro integraci s informačním systémem NSPTV prostřednictvím integrační platformy. Integrace musí zabezpečovat následující funkce: • párování záznamů mezi záznamovým systémem a informační systémem, • přenos údajů z databáze systému oběma směry, • online předávání informací o průběhu záznamu včetně doplňujících údajů, • import audio souborů záznamů, • přehrávání záznamů a řízení pohybu v záznamu při přehrávání prostřednictvím IP telefonu i v prostředí aplikace, • aktivace příposlechů, • systém nahrává příchozí stranu volání již od okamžiku spojení pro vyzvánění, tato část záznamu je zpřístupněna ve zvláštním režimu pro analýzu záznamu pro případ kritických událostí. Podpora pro hodnocení práce operátorů NSPTV

Systém obsahuje aplikaci pro hodnocení práce operátorů NSPTV (Quality management systém) - systém je založen na uživatelsky konfigurovatelných formulářích. Systém obsahuje analytickou a reportingovou aplikaci - upravitelné prostředí pro definici jednorázových i pravidelných reportů nad daty systému. Systém podporuje nahrávání screenů obrazovek pro účely dokumentace a hodnocení práce operátorů, podporuje synchronní přehrávání screenu s hovorem.

VERZE 01



Aplikace NSPTV Aplikace NSPTV je sestavena voláním služeb NIS (viz tabulka Popis služeb NIS) a služeb KGIS (viz tabulka Popis služeb GIS). Pro interakci s uživatelem jsou navrženy tyto obrazovky: Tabulka 7: Obrazovky NSPTV OZN. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 19 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

VERZE 01

Obrazovka / Formulář Seznam událostí Detail události Seznam čísel BL/WL Detail čísla BL/WL Seznam hlášek Detail hlášky Seznam operátorů Detail operátora Oblast volání (GIS) Seznam rajonizace Detail rajonizace Seznam krajů Detail kraje Seznam klasifikací udál. Detail klasifikace události Seznam typů událostí Detail typu události Seznam závažností události Detail závažnosti události Seznam subjektů pro konferenci Detail subjektu pro konferenci Export nahrávek Seznam nahrávek Detail nahrávky Záloha nahrávek Seznam uživatelů Detail uživatele Seznam pravidel směrování Detail pravidla směrování Import uživatelů Export uživatelů Detail logu Seznam pravidel vizualizace Detail pravidel vizualizace Seznam pravidel Detail pravidla Zálohování dat Seznam pravidel přidělování hovorů Detail pravidla přidělování hovorů Extrakce dat do DS Seznam reportů Detail reportu (definice) Export reportu Publikace reportu Archivace dat (nastaveni) Import INFO35 Seznam znalostí Detail znalosti Seznam složek Detail složky Seznam OŘ Detail OŘ Změna hesla Seznam dispečerů Seznam posledních hovorů Seznam důležitých čísel a kontaktů Vývoj události Předání služby Nastavení aplikace



Centrální GIS (CGIS) a krajský GIS (KGIS) Technologické požadavky na systém GIS

Z hlediska architektury musí být řešení založeno na principech SOA a obsahovat API pro vývoj webových aplikací. Dále musí splňovat tyto požadavky: Správa datového skladu a datového modelu: • Podpora správy prostorových dat v Oracle, MS SQL Server 2008, Postgre SQL • Podpora replikace dat • Podpora víceuživatelské editace dat • Podpora verzování dat a řešení konfliktů • Podpora historizace dat (sledování historie změn geodat) • Podpora subtypů a domén/číselníků • Identifikace doby změny a identity editujícího uživatele • Podpora všech běžných souřadnicových systémů na území ČR (minimálně S JTSK, UTM, WGS84, ETRS, S-42) • Podpora správy přiřazení dokumentů (PDF,rastry a další přílohy) k jednotlivým geometrickým prvkům v desktop GIS klientovi • Integrace dat z národních registrů Technologické možnosti GIS serveru •

Podpora komunikace se síťovými GIS službami pomocí REST a OGC rozhraní

•

Správa GIS aplikačního serveru pomocí REST API

•

Webová editace geometrie a atributových informací prvků pomocí JavaScript +HTML5, popř. Silverlight API a FLEX API

•

Publikování dynamicky generovaných nebo kešovaných mapových podkladů

•

Webová editace geometrie a atributových informací prvků podle šablon definovaných v GIS klientovi administrátora

•

Dynamická publikace popisků prvků dle uživatelem definovaných pravidel v desktop GIS klientovi

•

Zpřístupnění analytických nástrojů a procesních modelů definovaných Zadavatelem v CGIS i v KGIS

•

Možnost využití geometrické služby pro výpočty obalových zón, ploch a délek

•

Zprostředkování přístupu k datům transakční databáze prostorových dat prostřednictvím internetové sítě

•

Replikace datového obsahu a vytváření jednorázových replik a záloh

Vlastnosti a nastavení tvorby mapových dlaždic: •

VERZE 01

Nastavení měřítek dlaždicového schématu



•

Nástroje pro tvorbu, aktualizaci, mazání dlaždic

•

Přidání nebo odebrání dlaždic pro určité měřítko

•

Plánování obnovy dlaždic pomocí nástrojů operačního systému

•

Uložení a načtení definice dlaždicového schématu

•

Tvorby tzv. kompaktní mapové cache za účelem snadného a rychlého zálohy a kopírování

•

Podporované formáty dlaždic PNG8, PNG24, PNG32, JPEG

•

Tvorba smíšené mapové cache (propojení JPEG a PNG dlaždic v jednom dlaždicovém měřítku)

Možnosti nástroje pro zpracování a analýzu geodat – geoprocessing: •

Konfigurovat úlohy z desktopového prostředí oprávněných správců

Požadavky na webové aplikační rozhraní - vývojová prostředí pro webové aplikace JavaScript, Adobe Flex, Microsoft Silverlight: •

Možnost vývoje vlastních webových aplikací dle zdokumentovaného a přístupného API

•

Vizualizace dat dle časových záznamů

•

Možnost vytvořit webovou službu, která vygeneruje pro vyznačenou oblast mapu v požadovaném formátu

•

Vývojové prostředí pro mobilní klienty na platformách Windows Mobile, Windows Phone, Apple iOS, Android

Funkční požadavky na systém GIS

Systém zajistí jednotnou datovou základnu geografických dat, která bude zdrojem referenčních geografických dat pro všechny složky IZS. Tato základna bude obsahovat všechny sdílené jednotné číselníky a registry. Specifické vrstvy jednotlivých složek budou uchovány na úrovni krajských základen geodat (KGIS). Je zajištěna dostupnost těchto geodat formou veřejných mapových služeb: • geodata ČÚZK – ZABAGED, ortofoto mapy, referenční mapa malého měřítka • základní mapa sousedních států (openstreet map) • mapová díla IS katastru nemovitostí (ISKN) • registr územní identifikace, adres a nemovitostí (RÚIAN) • digitální mapa veřejné správy, bude-li v době realizace projektu dostupná Je zajištěna dostupnost těchto geodat formou mapových služeb GIS serveru: • základní báze geografických dat ZABAGED • Geonames • tematická data od vybraných poskytovatelů dat (např. VÚV, ČD, ŘSD, MŽP)

VERZE 01



Publikování metadatové služby s hierarchickými vazbami na vnitřní i vnější datové zdroje zobrazení popisných informací o jednotlivých službách. Založeno na katalogové službě pro přístup k metadatům. Publikované mapové služby budou implementovat rozhraní GeoServices REST a OGC WMS. Geodata jsou replikována jak mezi jednotlivými DC, tak vybraná geodata i mezi DC a jednotlivými krajskými GIS. Je zajištěna možnost přidání mapových služeb z externích zdrojů přes standardizovaná rozhraní (SOAP, REST, OGC WMS) - tím je umožněno konfigurování specifických mapových kompozic pro specifické účely jednotlivých složek IZS, pokud nedojde k překročení dohodnutých SLA. Základny geodat na úrovni KGIS budou zajišťovat mapovou službu pro IS OŘ, popř. na základě autorizace a uživatelských oprávnění jednotlivých uživatelů, která bude zahrnovat funkcionalitu: • Vizualizace podle automatické identifikace polohy (mobilního telefonu, polohy pevné stanice či dalšího interního komunikačního prostředku), manuální identifikace (podle souřadnic, zájmových bodů, např. adres, místopisu, výrazných objektů, ID objektů s početným výskytem apod.) • Vizualizaci informací o události. • Vizualizaci společné operační situace. Služby GIS budou poskytovány serverem ve formě služeb a volány klientem NSPTV s využitím příslušné knihovny (SDK) formou REST. Pro NSPTV budou k dispozici tyto služby, které budou využívány aplikací NSPTV: Mapová služba poskytující mapový podklad formou mapových dlaždic: • Zobrazení polohy volajícího - zobrazení bodového objektu reprezentujícího polohu volajícího na mapovém podkladě. • Zobrazení místa události - zobrazení bodového objektu reprezentujícího místo události na mapovém podkladě. • Zobrazení polohy vozidel a SaP - zobrazení aktuální polohy vozidel a SaP spojených s reakcí na MU na mapovém podkladě. • Zobrazení aktuálně realizovaných MU - zobrazení vyhledaných/všech aktuálně realizovaných MU na mapovém podkladě. • Zobrazení reakcí - zobrazení reakcí v rámci kraje nebo místní části. Mapová služba poskytující data o rajonizaci: • Určení rajonizace Standardní funkce GIS pro operační řízení dostupné v CGIS

Síťová služba poskytující analytické operace nad silniční sítí. Analytické operace umožní vyhledání optimální trasy, dojezdnosti a nejbližších lokalit na silniční síti: • Ideální trasa k místu MU • Zobrazení ideální trasy k MU na mapovém podkladě.

VERZE 01



• Trasa odpovídá zadaným vstupním parametrům. Analytická služba poskytující operaci pro výpočet oblasti šíření nebezpečné látky: • Zobrazení oblasti šíření nebezpečné látky na mapovém podkladě. • Oblast odpovídá zadaným vstupním parametrům. Analytická služba pro výpočet oblasti zaplavené povodní: • Zobrazení oblasti zaplavené povodní na mapovém podkladě. • Oblast odpovídá zadaným vstupním parametrům. Vytváření mapových kompozic: • Skládáním mapových vrstev s možností manipulace s pořadím vykreslení mapových vrstev v mapě, změna viditelnost mapových vrstev a jejich pod-vrstev. • Možnost uložit a otevřít mapovou kompozici. • Aplikace uživateli umožní interaktivně změnit měřítko mapy. Mapa se při změně měřítka postará o překreslení mapové kompozice získáním aktuálních mapových výstupů pro jednotlivé mapové vrstvy. • Aplikace umožní přidat do mapy novou mapovou vrstvu (výběrem ze seznamu dostupných mapových služeb) a odebrat přidanou mapovou vrstvu z mapy. Publikace dat požadovaných entit (benzínová stanice, skladiště chemických a nebezpečných látek aj.) - serverová část GIS umožní vytvoření mapové služby s rozhraním pro prostorové vyhledání vybraných druhů entit v definované vzdálenosti od MU: • Nalezení vybraných druhů entit v okolí MU (benzínová stanice, skladiště chemických a nebezpečných látek aj.) • V definované vzdálenosti od MU (kružnice v mapě) budou vybrány a zvýrazněny objekty z předdefinovaného seznamu vrstev. Operátor bude mít možnost tuto vzdálenost dynamicky měnit. Správa dat bude realizovaná na úrovni CGIS a oprávněných správců KGIS bude dostupná prostřednictvím klienta: • import mapových podkladů • import datových vrstev • správa popisné složky entit • správa prostorové složky entit" • vytvoření mapové kompozice • uložení mapové kompozice • tisk mapové kompozice • zobrazení mapové kompozice • odebrání vrstvy kompozice • změna pořadí vrstev v kompozici

VERZE 01



• vygenerování obrázku z kompozice • správa symboliky vrstvy • nastavení měřítkových omezení • lokalizaci entit v mapě • vizualizace entit • vyvolání akce svázané s entitou Specifické funkce GIS pro operační řízení

Pro specifické účely operačního řízení bude nutné využít klienta, který není součástí dodávky NIS IZS a musí být pořízen z KSP. Funkce klienta pro práci s entitami: • vyvolání akce svázané s entitou • zobrazení vlastnosti bodu v prostoru • výpis informací o vybraných entitách • nalezení entit podle polygonu • prostorové nalezení entit • nalezení entit přes popisná data • nalezení entit ručně • nalezení entit v mapě • nalezení nejbližší entity • nalezení protínajících se entit • nalezení prvků v okolí entity • výběr nalezených entit Funkce klienta pro výpočty a měření: • měření obvodu • měření plochy • měření spojnice jednoho nebo více bodů • výpočet průniku • výpočet rozdílu • výpočet sjednocení • analýza překryvu vrstev Funkce klienta pro výpočty a měření povrchu: • analýza spádu a orientace • analýza vrstevnic

VERZE 01



• analýza viditelnosti Funkce klienta pro analýzy dopravních sítí: • nalezení optimální trasy • nalezení územní obslužnosti

Ostatní funkce klienta pro podporu OŘ: • podpora 3D zobrazení

VERZE 01



Tabulka 8: Popis služeb GIS OZN.

Název

Popis

1

Catalog

Ca ta l og je hl a vním uzlem a výchozím vs tupním bodem GIS Serveru. Reprezentuje ka ta log s ložek a s l uže b, které js ou na hos tujícím s erveru publ iková ny.

11

111

Export Map (Operace)

112

Identify (Operace)

113

Find (Operace)

114

Generate KML (Operace)

115

Map Tile

116

Layer/Table

1161

Query (Operace)

Opera ce query je prová děna na d zdrojem la yer / ta bl e. Výs le dkem této ope ra ce je s a da prvků (fea tures et).

1162

Query Related Records (Operace)

Opera ce query re la ted records je prová děna na d zdrojem la yer / ta bl e. Výs l edkem této ope ra ce je jedna nebo více s a d prvků (fea tures ets ) s es kupených podle ID zdrojové vrs tvy/ta bulky.

1163

Feature - Map Service

Zdroj fea ture předs ta vuje jednotli vý prvek ve vrs tvě ma pové s l užby.

11631 116311 11632 1164

Attachment Infos - Map Service Attachment - Map Service HTML Popup Image - Map Service

117

Legend

118

All Layers and Tables

119

KML Image (for Map Services)

1110

Map Service Extension

12

VERZE 01

Map Service

Ma p s ervi ce (ma pová s l užba ) na bízí přís tup k obs a hu v podobě ma p a vrs te v. Ma pové s l užby mohou být ca chova né nebo dyna mi cké. Ma pová s lužba , která pl ní poža da vky zobra zová ním připra vených dla ždic z ca che a nevykres l uje je tedy dyna micky, s e na zývá ca chova ná ma pová s l užba . Dyna mická ma pová s lužba vyža duje s erve r k vykres l ení ma py při ka ždém poža da vku. Ca chova ná ma pová s lužba může význa mně zvýš it výkon při zobra zová ní ma p, za tímco dyna mická ma pová s lužba na bízí větš í fl exi bil itu. Ma pové s l užby by měl y být vždy publi ková ny ja ko s druže né s lužby. Opera ce export je prová děna na d ma p s ervice zdrojem. Výs ledkem této opera ce je zdroj ma p i ma ge. Tento zdroj pos kytuje i nforma ce o exportova ném ma povém obra zu – URL, jeho výš ku a š ířku, rozs a h a měřítko. Opera ce i denti fy je prová děna na d ma p s ervice zdrojem. Vyhledá vá prvky, které ma jí určité geogra fi cké umís tě ní. Výs l edkem této opera ce je zdroj i denti fy res ul ts . Ka ždý výs l edek i denti fi ka ce obs a huje s vé jméno, ID vrs tvy, ná ze v vrs tvy, geometri i, typ geometri e a da lš í a tributy v podobě ná zev-hodnota . Opera ce find je prová děna na d ma p s ervi ce zdrojem. Výs l edkem této opera ce je zdroj find re s ults . Ka ždý výs l edek vyhledá vá ní obs a huje s vou hodnotu, ID prvku, ná ze v pole, ID vrs tvy, ná zev vrs tvy, geometrii , typ geome trie a da lš í a tributy v podobě ná zev-hodnota . Opera ce ge nera teKml je prová děna na d ma p s ervi ce zdrojem. Výs l edkem této opera ce je dokument KML za ba le ný v s ouboru KMZ. Dokument obs a huje s íťový l ink ke koncovému bodu KML Servi ce s e s peci fi kova nými vl a s tnos tmi a pa ra me try. Tento zdroj repre zentuje jednotli vou ca chova nou ma povou dla ždici (pro ca chova né ma py). Obra zové ba jty dl a ždi ce ve s pe cifikova né úrovni , řá dek a s loupe c js ou přená š eny (s trea mová ny) přímo kl ientovi . Pokud je dl a ždi ce nena l eze na , vrá tí s e HTTP kód 404 (Not found). Zdroj l a ye r / ta bl e reprezentuje jednotli vé vrs tvy/ta bul ky v ma pové s l užbě publi kova né GIS Serverem. Pos kytuje zá kla dní i nforma ce o vrs tvě/ta bulce – ná zev, typ a jednotl ivá pol e. V přípa dě vrs tev pos kytuje da l š í i nforma ce ja ko na př. rodičovs ká vrs tva , podvrs tvy, mi n. a ma x. měřítka , rozs a h, copyri ght (text). Od verze 10 pos kytuje ta ké i nforma ce týka jící s e vzta hu vrs tvy/ta bulky s da l š ími vrs tva mi /ta bulka mi ma pové s lužby, s tejně ja ko pa ra metr určující, zda má vrs tva /ta bulka příl ohy.

Geocode Service

121

Find Address Candidates (Operace)

122

Reverse Geocode (Operace)

13

GP Service

131

GP Task

1311

Execute GP Task (Operace)

1312

Submit GP Job (Operace)

1313

GP Job

13131

GP Result

13132

GP Input

Zdroj a tta chment i nfos vra cí informa ci o přílohá ch (a tta chements ) při pojených k prvku. Tento zdroj je dos tupný pouze v přípa dě, že vrs tva obs a huje i nforma ci , že má přílohy. Zdroj a tta chment reprezentuje jednotli vou přílohu připojenou k prvku. Tento zdroj je dos tupný pouze v přípa dě, že vrs tva obs a huje i nforma ci , že má přílohy. Zdroj htmlPopup pos kytuje deta i ly o HTML popupu vytvoře ném uživa tel em pomocí GIS Des ktop. Zdroj i ma ge repreze ntuje jednotl ivý obrá zek a s oci ova ný s obra zovým s ymbol em. Tento zdroj je k di s pozi ci pouze v přípa dě, že vrs tva obs a huje Picture Ma rker Symbols nebo Pi cture Fi ll Symbols . Zdroj l egend repre zentuje l egendu ma pové s l užby. Vra cí i nforma ce o lege ndě pro vš e chny vrs tvy té to s l užby. Tyto i nforma ce za hrnují obra zy s ymbolů (20x20 pi xel ů, 96 DPI) a popis ky vš ech s ymbol ů, s oučá s tí js ou ta ké i nforma ce typu ID vrs tvy, ná zev, mi n. a ma x. měřítka . Zdroj l a ye rs reprezentuje vš echny vrs tvy a s a mos ta tně s tojící ta bul ky v rá mci ma pové s l užby publi kova né GIS Serve rem. Pos kytuje zá kla dní i nforma ce o vrs tvá ch a ta bul ká ch ja ko ná zev, typ, rodičovs ká vrs tva , podvrs tvy, pol e, mi n. a ma x. měřítka , rozs a h, text copywri ghtu. Zdroj KML Ima ge res ource předs ta vuje KML Regi on nebo „ground overla y document“ za ba l ený v s ouboru KMZ. Orga ni za ce, které rozš i řují funkci ona l itu GIS Serveru pros tředni ctvím SOE (Server Object Exte ns ions ), chtějí tyto doda tečné funkce vys ta vi t ta ké přes webová API. GIS REST API, které pos kytuje zá kl a dní funkce GIS Services webovým API, lze rozš íři t ta k, a by podporova l uživa tel s ké SOE funkce GIS v podobě zdrojů a opera cí. Geokódová ní je proces přiřa zová ní umís tění, obvykle ve formě s ouřa dnic (bodů), k a dres e ta k, že s e porovná va jí popis né prvky umís tění v a dres e s těmi, které js ou preze ntová ny v refere nčním ma te ri á lu. Adres y js ou v různých formá ch – od běžného formá tu čís la domu, ná zvu ul ice a ná s l edných informa cí ja ko PSČ a d. Adres ou je ja kýkol i typ informa ce, který ozna čuje konkrétní umís tění. Opera ce findAddres s Ca ndi da tes je prová děna na d zdrojem geocode s ervi ce. Výs le dkem této opera ce je zdroj repre zentující s ezna m ka ndi dá tů a dres y. Tento zdroj pos kytuje informa ce o ka ndidá tech včetně a dres y, jejího umís tě ní a s kóre. Opera ce revers eGeocode je prová děna na d zdrojem ge ocode s ervi ce. Výs l edkem této ope ra ce je zpětně geokódova ný zdroj a dres y. Pos kytuje informa ce o vš ech pol ích zpětně geokódova né a dres y, s tejně ja ko její přes né umís tění. Geoproces s i ng je s těžejní s oučá s tí opera cí cel opodni kového GIS. Pos kytuje ná s troje nezbytné pro a na l ýzy da t, s prá vu da t a jejich konverzi . Zdroj GP ta s k re prezentuje je dnotl ivou úlohu v rá mci geoproces ingové s lužbz publ ikova né GIS Serve rem. Pos kytuje zá kl a dní i nforma ce o úloze včetně ná zvu a zobra zova ného ná zvu nebo deta ilních i nforma cích o různých vs tupních a výs tupních pa ra metrech. Opera ce execute je prová děna na d zdrojem GP ta s k pro geoproce s ingové s l užby, kte ré s e s pouš tějí s ynchronně. Výs le dkem této ope ra ce je zdroj GP res ult, který obs a huje pol e s pa ra metry výs l edku a i nforma ce o průběhu zpra cová ní úlohy. Opera ce s ubmi tJob je prová děna na d a s ynchronním GP ta s k zdroje m. Výs l edkem této opera ce je zdroj GP job. Zdroj GP job repreze ntuje úlohu za da nou s použi tím ope ra ce s ubmi t job. Pos kytuje zá kla dní informa ce o úl oze ja ko job ID, s ta v a zprá vy (mes s a ges ). Zdroj GP res ul t repreze ntuje pa ra metry výs l edku pro GP job. Pos kytuje i nforma ce o pa ra metrech výs l edku, ja ko je ná zev, da tový typ a hodnota . Zdroj GP i nput předs ta vuje vs tpuní pa ra metr pro GP job. Pos kytuje informa ce o vs tupních pa ra metrech – ná zvu, da tové m typu, hodnotě.



OZN.

Název

Popis

14

Geometry Service

Geometry s ervi ce obs a huje uži tečné metody, které umožňují přís tup k s ofi s tikova ným a ča s to používa ným geometri ckým opera cím. GIS Serve r může vys ta vi t pouze jednu geometrickou s l užbu s e s ta ti ckým ná zvem „Geometry“. Vs tup a výs tup geometri e, pokud je poža dová n, je vždy v podobě pole .

141

Project Geometries (Operace)

142

Simplify Geometries (Operace)

143

Buffer Geometries (Operace)

144

Areas and Lengths (Operace)

145

Lengths (Operace)

146

Relation (Operace)

147

Label Points (Operace)

148

Distance (Operace)

149

Densify (Operace)

1410

Generalize (Operace)

1411

Convex Hull (Operace)

1412

Offset (Operace)

1413

Trim / Extend (Operace)

1414

Auto Complete (Operace)

1415

Cut (Operace)

1416

Difference (Operace)

1417

Intersect (Operace)

1418

Reshape (Operace)

1419

Union (Operace)

15

VERZE 01

Image Service

151

Export Image (Operace)

152

Query - Image Service (Operace)

153

Identify - Image Service (Operace)

154

Download Rasters (Operace)

155

Raster Functions

156

Raster Catalog Item

Opera ce project je prová děna na d zdrojem geometry s ervice. Výs l edkem této opera ce je pole projektova ných geometri í. Tento zdroj promítá pol e vs tupních geometri í ze vs tupní s pa tia l reference do výs tupní s pa ti a l refere nce. Opera ce s i mpli fy je prová děna na d zdroje m geome try s ervi ce. Ta to ope ra ce trva l e změní vs tupní ge ometrii ta k, že s e s ta ne topologicky konzi s te ntní. Tento zdroj a pl ikuje opera ci GIS s i mpli fy na ka ždou geometri i ve vs tupním poli . Opera ce buffer je prová děna na d zdrojem geometry s ervi ce. Výs ledkem této opera ce js ou polygony oba lové zóny v urče né vzdá lenos ti od pol e vs tupní geometrie . K dis pozi ci je možnos t s jednoti t oba l ové zóny pro ka ždou vzdá lenos t. Opera ce a rea s AndLengths je prová děna na d zdroje m geome try s ervi ce. Vypočítá vá pl ochy a obvodové dél ky pro ka ždý polygon s peci fi kova ný ve vs tupním pol i. Opera ce le ngths je prová děna na d zdrojem geometry s ervi ce. Vypočítá vá délky ka ždé polyli nie s peci fi kova né ve vs tupním poli . Opera ce re la tion je prová děna na d zdroje m geome try s ervi ce. Sta noví dvojice geometri í z geometri í za da ných ve vs tupním poli , které s e úča s tní s peci fi kova ného pros torového vzta hu. Opera ce la belPoints je prová děna na d zdrojem geometry s ervice. Ta to opera ce vypočítá vni třní bod pro ka ždý polygon s peci fi kova ný ve vs tupním pol i. Tyto „vni třní body“ mohou být pa k použi ty kli enty pro popis ová ní polygonů. Opera ce di s ta nce je prová děna na d zdrojem geometry s ervice. Vra cí pla ná rní, geodeticky nejkra tš í vzdá l enos t me zi body A a B. Pa ra metr s r zna me ná s ouřa dni cový s ys tém. Vzdá l enos t je v l ine á rních jednotká ch s pecifikova ných v pa ra metru uni ts nebo v jednotká ch s ouřa dni cového s ys tému, pokud pa ra me tr „units “ je nul l. Opera ce dens ify je prová děna na d zdrojem geometry s e rvi ce . Zhuš ťuje geometri i ta k, že dokres l uje body mezi s tá va jící l omové body. Opera ce gene ra l ize je prová děna na d zdrojem geometry s ervi ce. Vra cí ge nera li zova né (Dougla s -Poiker) verze vs tupních ge ometrií. Opera ce convexHull je prová dě na na d zdrojem ge ometry s ervi ce. Vra cí konvexní oba l vs tupní geometri e. Vs tupní geometri í může být bod, vícená s obný bod (mul ti point), pol yl ini e nebo pol ygon. Oba l je typi cky polygonem, a le může to být i pol yl ini e nebo bod (v degenerova ných přípa dech). Opera ce offs et je prová děna na d zdrojem geometry s ervi ce . Kons truuje ods a zení da ných vs tupních geometri í. Pokud je pa ra metr ods a zení pozitivní hodnota , bude vykres l en na pra vé s tra ně od vs tupní geometrie . Nega ti vní hodnota zna čí vykres l ová ní na le vé s tra ně . Sl edová ní ge ometrie od prvního lomového bodu k pos le dnímu dá vá s měr podé l geometri e. Opera ce trimExte nd je prová děna na d zdrojem geometry s ervi ce. Opera ce zkra cuje /rozš i řuje ka ždou pol yl ini i s pecifikova nou ve vs tupním poli , s použitím uži va tel s ky de fi nova ných vodi cích pol yl ini í. Opera ce Auto Comple te je prová děna na d zdrojem geometry s ervice. Zjednoduš uje proces kons trukce nových polygonů, které s ous edí s da lš ími polygony. Kons truuje polygony, které vypl ňují meze ry mezi s tá va jícími polygony a množinou polyli nií. Opera ce cut je prová děna na d zdrojem geometry s ervi ce. Rozdělí vs tupní polyli nii nebo pol ygon ta m, kde s e kříží s rozděl ova cí pol yl ini í. Opera ce di fference je prová děna na d zdrojem geometry s e rvice . Kons truuje množi nu – teoretický rozdíl mezi pole m geome trií a jinou geometri í. Opera ce inters ect je prová děna na d zdrojem geometry s e rvice . Kons truuje množi nu – teroetický průnik mezi pole m geome trií a jinou geometri í. Opera ce re s ha pe je prová děna na d zdrojem geometry s ervice. Změní tva r pol yl inie nebo čá s ti pol ygonu s použi tím změnové l inie. Opera ce uni on je prová děna na d zdrojem geometry s ervi ce . Kons truuje množi nu – teoreti cké s je dnoce ní geometri í ve vs tupním pol i. Vš echny vs tupy mus í být s tejného typu. Ima ge s e rvice pos kytuje přís tup k publ ikova ným obra zovým da tům. Podporuje dva způs oby zobra zení publ ikova ných da t: moza ikova ný obra z a zobra zení ka ta logu ra s trů. Opera ce export i ma ge je prová děna na d zdrojem ima ge s ervice. Výs le dkem této opera ce je zdroj ima ge, který pos kytuje i nforma ce o exportova ném obra zu – URL, jeho š ířku, výš ku a rozs a h. Opera ce query je prová děna na d zdrojem ima ge s e rvice . Dota zuje s e na ka ta l og ra s trů a pli ková ním fil tru s pecifikova ného uži va telem. Výs l edkem této ope ra ce je buď množina prvků v ra s trovém ka ta logu, nebo pole ra s trových ID (pokud je pa ra metr returnIds Onl y na s ta ven na true). Opera ce identi fy je prová dě na na d zdrojem i ma ge s ervi ce. Identi fi kuje obs a h i ma ge s ervice pro da né umís tění a moza ikova cí pra vi dl o. Umís těním může být bod nebo pol ygon. Opera ce downl oa d ra s te rs je prová děna na d zdrojem ima ge s ervice. Vra cí informa ci (ID s ouboru), kterou lze použít při downloa du nezpra cova ných ra s trových s ouborů, které js ou propojeny s e s peci fi kova nou množinou ra s trů v ka ta logu ra s trů. Opera ce export i ma ge, kte rá probíhá na d na d zdrojem i ma ge s ervi ce, podporuje na s ta vení způs obu vykres lová ní (pa ra metr renderi ngRul e). Zdroj ra s te r ca ta l og item reprezentuje jednotl i vou pol ožku (prvek) ka ta logu ra s trů. Ka ždá z nich má s vůj a s ociova ný ra s tr. Zdroj ra s te r ima ge vra cí kompozi tní obra z ka ždé položky ka ta l ogu ra s trů. Uživa telé mohou tento zdroj využít pro generová ní dyna mických obra zů za l ože ných na jedi né pol ožce ka ta l ogu ra s trů.

1561

Raster Image

1562 1563

Raster Thumbnail

Zdroj ra s te r thumbna il vra cí mi nia turu jedné položky ka ta l ogu ra s trů.

Raster Info

Zdroj ra s te r info vra cí informa ci o a s ociova ném ra s tru (š ířka , výš ka , počet pá s em, typ pixelů a td.).

157

Raster File

158

KML Image (for Image Services)

Zdroj ra s te r fi le reprezentuje jednotl ivé nezpra cova né ra s trové s oubory. Vyža dova né ID lze zís ka t s použi tím opera ce Downl oa d Ra s ters . Zdroj KML Ima ge reprezentuje ground overl a y document za ba l ený v s ouboru KMZ. Když je používá na Ima ge Service, ne js ou podporová ny KML Regions .



OZN.

Název

16

Network Service

161

Network Layer

1611 1612 1613 17 171 1711 1712 1713 1714 1715 1716

Solve Route (Operace)

Ne twork s e rvice res ource předs tavuje s lužbu s íťové analýzy publ ikovanou pomocí GIS Serve ru. Pos kytuje i nforma ce o s l užbě – popi s s l užby a různé s íťové vrs tvy (tras y, nejbli žš í za řízení, obl as ti dos tupnos ti s lužeb), které obs ahují s lužbu s íťové analýzy (network anal ys is s ervice). Zdroj network la yer reprezentuje jednotli vou s íťovou vrs tvu v rá mci s lužby ne twork ana lys is s ervi ce publi kované GIS Se rvere m. Pos kytuje zákla dní i nforma ce o s íťové vrs tvě – ná zev, typ a s íťové třídy. Opera ce s olve je prová děna na d zdrojem network l aye r.

Solve Closest Facility (Operace)

Opera ce s olve je prová děna na d zdrojem network l aye r typu nejbl ižš í zařízení (clos es t facil ity).

Solve Service Area (Operace)

Opera ce s olve je prová děna na d zdrojem network l aye r typu s e rvis ní obl as t.

Feature Service Layer - Feature Service

17171

Add Attachment (Operace)

17172

Update Attachment (Operace)

17173

Delete Attachments (Operace)

17174

Attachment Infos - Feature Service

1718

Zdroj l ayer reprezentuje je dnotli vou e ditovate lnou vrs tvu prvků ne bo nepros torovou tabulku ve s l užbě fea ture.

Opera ce que ry je prová děna na d zdrojem feature s ervi ce l ayer. Výs l edkem této operace je buď s ada prvků (fe ature s e t) nebo pol e ID prvků (pokud je parametr re turnIds Only na s taven na true). Opera ce que ry ope rati on je prováděna nad zdrojem fea ture s ervi ce l ayer. Výs l edkem této operace js ou s ady Query Related Records - Feature Service (Operace) prvků s es kupe né podl e ID zdrojové vrs tvy/tabul kového obje ktu. Tato operace přidává prvky k as oci ova né třídě prvků nebo tabulce (jen POST). Ope race add feature s je Add Features (Operace) prováděna nad zdrojem fe ature s e rvice l ayer. Je jím výs ledkem je pole editova ných výs le dků. Tato operace aktua li zuje prvky ve třídě prvků nebo ta bul ce (jen POST). Opera ce update features je provádě na Update Features (Operace) nad zdrojem fea ture s ervi ce l aye r. Výs ledkem této ope race je pole editova ných výs le dků. Tato operace maže prvky ve třídě prvků nebo tabulce (jen POST). Operace del ete feature je prová děna na d Delete Features (Operace) zdroje m feature s ervi ce la yer. Výs l edkem operace je pol e edi tovaných výs l edků. Tato operace přidává , aktual i zuje a maže prvky as oci ované třídy prvků ne bo tabulky v jedi ném vol ání (pouze Apply Edits (Operace) POST). Opera ce apply e dits je provádě na nad zdrojem fe ature s e rvice layer. Výs le dkem této opera ce js ou 3 pole e ditovaných prvků (pro při dání, a ktual izaci a mazání).

Feature - Feature Service

17175

Feature Service umožňuje kli entům dotazovat a e ditovat prvky v mapě. Je ji ch s oučá s tí je geometri e, a tributy, s ymbol i ka a js ou organi zovány ve vrs tvách a podtypech v rámci vrs te v.

Query - Feature Service (Operace)

1717

171741

Popis

Attachment - Feature Service HTML Popups Image - Feature Service

Zdroj feature repreze ntuje jednotl ivý prvek ve vrs tvě v rámci s lužby feature s ervi ce. Tato operace přidává přílohu (atta chment) a s ociované mu prvku (jen POST). Ope race add atta chment je prováděn nad zdrojem fea ture s ervi ce feature. Tato operace aktua li zuje příl ohu (attachment) prvku (pouze POST). Opera ce update attachme nt je provádě na nad zdrojem fea ture s ervi ce feature. Tato operace maže příl ohy připojené k prvku (pouze POST). Operace del ete attachme nts je prová děna na d zdroje m feature s ervi ce fe ature. Zdroj atta chment infos vra cí i nforma ci o přílohách připojených k prvku. Tento zdroj je dos tupný, pouze pokud je ve vrs tvě nas taveno, že má příl ohy. Zdroj atta chment předs tavuje jednotl i vou přílohu při pojenou k prvku. Tento zdroj je dos tupný, pouze pokud je ve vrs tvě nas taveno, že má příl ohy. Zdroj htmlPopup pos kytuje detai ly o HTML popupu vytvoře ném uži va tel em pomocí GIS Des ktop. Zdroj i ma ge re pre zentuje jednotl ivý obráze k as ociovaný s obrazovým s ymbol em. Te nto zdroj je dos tupný, pouze pokud vrs tva obs ahuje Picture Marker Symbols ne bo Pi cture Fil l Symbol s .

Infrastruktura systému Datová centra (DC) jsou koncipována tak, aby splňovala co nejvyšší dostupnost, proto všechny komponenty v centrálních datových centrech jsou zdvojeny. Toto se týká i databázových serverů použitých v DC pro ukládání provozních dat NIS IZS. Základním požadavkem na databázi je, že použitá databáze bude relační s transakčním zpracováním a bude respektovat základní ANSI normy pro SQL jazyk. Důležitým požadavkem je replikace dat ukládaných do databáze DC mezi jednotlivými DC a to online s možností, pokud dojde k rozpadu spojení mezi DC, s následnou synchronizací dat mezi servery. Z hlediska provozu musí být možno provést nastavení tak, kdy žádná databáze nebyla primární, ale replikace mohou přijít z libovolné databáze. Třetí datové centrum bude zároveň školící. Z tohoto důvodu je nutné, aby bylo možné toto DC vyjmout z replikací na ostatní. Příjem dat od ostatních DC musí být zachován. Pro kontrolu dostupnosti databázového serveru se bude používat loadbalancer. Databázový server musí ale umožnit místo loadbalanceru použít clusterové řešení pomocí prostředků dodávaného SW pro databázový server. Databázový server musí umožnit zálohování provozních logů tak zálohy dat libovolné úrovně na páskové jednotky a na file systém.

VERZE 01



Databázový server a jeho komponenty (replikace, cluster) musí být provozovatelné na virtuálních serverech. Jako operační systém se pro provoz databázového serveru a ostatních komponent databázového serveru se předpokládá Windows Server 2012 (Intel platforma). Data ukládaná do databáze v DC budou uložena na diskovém poli. Databázový server musí umožnit přístup k více databázím s velkým množstvím dat (používají se i data GIS). Dodávaný SW musí obsahovat knihovnu JDBC minimálně v3 pro JAVA v6.0 a vyšší. Databázový server musí umožnit ukládat xml data (databáze má podporu pro přímé ukládání xml dat) a binární data. DC jsou zabezpečena, z toho důvodu není potřeba řešit bezpečnost dat pomocí prostředků dodávaného SW. Použitý databázový systém musí umožnit integraci na datový sklad tak, aby dodávaný databázový systém šlo rozšířit o komponentu realizující datový sklad a licence byla součástí základní licence dodávaného SW. Databázový systém musí obsahovat komponenty, které umožní připojení (integraci) do dohledového centra pro monitorování běhu a stavu databázového serveru a dalších použitých komponent (replikace, cluster… ). Koncepce redundance a dostupnosti na úrovni SW Pro celý systém NIS je požadováno 200% zálohování poskytovaných služeb. Z tohoto důvodu byla navržena architektura vysoké dostupnosti. Koncepce dostupnosti NIS je postavena na řešení, které kombinuje zálohování systémů a jejich dostupnost prostředky aplikačními a prostředky infrastrukturními. Tato kapitola popisuje koncepce použité v řešení dostupnosti prostředky aplikačními. Obrázek 25: Architektura vysoké dostupnosti komponent

Schémata komunikace komponent a failover scénáře

Klient na základě konfigurace vytvoří připojení (9) k aktivnímu master uzlu integrační platformy v hlavní lokalitě (DC1). V případě výpadku integrační platformy dojde podle definované failover strategie k přepojení na záložní uzel.

VERZE 01



Klient komunikuje přes HA-LB (2,5) s GIS server clusterem. V případě výpadku jednoho z GIS serverů zodpovídá za failover a výběr jiného GIS server HA-LB. V případě výpadku všech uzlů v jedné lokalitě zajistí HA-LB přesměrování do jiné lokality. Integrační platforma zajišťuje komunikaci s telefonním subsystémem prostřednictvím JTAPI modulu (8). JTAPI modul sám zodpovídá za failover v případě selhání uzlu v CUCM clusteru. Integrační platforma komunikuje přes HA-LB (3,1) s LDAP clusterem. V případě výpadku jednoho z LDAP serverů zodpovídá za failover a výběr jiného LDAP server HA-LB. V případě výpadku všech uzlů v jedné lokalitě zajistí HA-LB přesměrování do jiné lokality. Integrační platforma komunikuje přes HA-LB (3,7) s DB servery. GIS komunikuje s databází prostřednictvím HA-LB (5,7). IPL

Integrační platforma běží v každém DC na dvou aktivních uzlech. Samotné uzly integrační platformy IPL1 a IPL2 jsou bezestavové komponenty. Vysoká dostupnost je řešena na úrovni databáze a messaging vrstvy - fyzicky na úrovni message brokeru (MB). Message broker poběží v režimu broker cluster v kombinaci s master-slave. Broker cluster zajišťuje prostřednictvím store and forward spolehlivé doručení zprávy v rámci clusteru. Zprávy jsou v rámci clusteru směrovány a distribuovány vždy do active master uzlu, na kterém poslouchají klienti. Při výpadku master uzlu dochází k převzetí funkcionality záložním (slave) uzlem (jednotky sekund). Současně proběhne klientský failover buď na master uzel do sekundární lokality (jednotky sekund) nebo na záložní uzel do stejné lokality v závislosti na rychlosti aktivace záložního uzlu (klientský failover je rychlejší než aktivace záložního uzlu). Vyřízení nových zpráv zajišťuje uzel, na který proběhl reconnect. Vyřízení již uložených zpráv zajišťuje záložní uzel. Obrázek 26: Architektura vysoké dostupnosti se záložním DC3

VERZE 01



Master-Slave model používá vysoce dostupný sdílený souborový systém na bázi SAN. V každé lokalitě je aktivní pouze master uzel, tj. uzel, který první získal souborový zámek (souborový systém musí podporovat sdílené souborové zámky – exclusive locks). V případě specifických problémů s doručením zprávy umožňuje integrační platforma nastavit různá schémata pro redelivery policy a dead letter fronty pro trasování požadavků či záložní scénáře zpracování. Přímou konektivitu s CUCM farmou zajišťuje JTAPI Service. JTAPI konektory zajišťují klientský load balancing jak v rámci clusteru v jedné lokalitě, tak i v rámci jednotlivých lokalit. Aplikace NSPTV

Klientské aplikace běžící ve virtuálních stanicích VCS jsou po přihlášení uživatele trvale připojeny k integrační platformě. Při výpadku některého z uzlů IPL se klient automaticky přepojí na jiný dostupný uzel (klientský failover). Tím bude jednak snížen overhead při navazování nového spojení a jednak vyřešena nutnost oboustranné komunikace klienta s IPL, např. ovládání telefonu z klienta prostřednictvím IPL a propagace notifikací a událostí ze strany Telefonie a IPL směrem na klienta (server push). Zde bude využit protokol SOAP over JMS. GIS

Pro produkční deployment GIS serveru je doporučené využít dvou vrstvou architekturu. Vzhledem k použití privátní sítě zadavatele není nutné řešit bezpečnostní model a oddělení webové a aplikační vrstvy GISu zónou DMZ. Webový server a aplikační komponenty GIS představují jednu vrstvu a sdílený databázový server představuje druhou vrstvu. Většina produkčních operací GIS vyžaduje redundantní serverové řešení nakonfigurované tak, aby v případě výpadku jednoho uzlu zůstala veškerá funkcionalita pro klienty zachována. V každém DC poběží dvě instance GIS serveru s předřazeným HA LB. Tato konfigurace umožní v případě výpadku nebo odstávky jednoho uzlu pokračovat v obsluze klientů na druhém uzlu. Součástí konfigurace je přístup k vysoce dostupnému sdílenému diskovému poli pro ConfigStore a SvrDirectory a dále přístup na RDBMS servery, které zajišťují dotazovací služby. GIS server může publikovat služby skrze nativní port 6090 nebo prostřednictvím externího web serveru a web adaptérem, který umožňuje zabezpečit přístup k mapovým službám. Infrastruktura

Databáze V každém datovém centru budou na dvou fyzických serverech instalovány databázové servery (podle typu zvoleného databázového serveru se spojí do clusteru nebo ponechají jako samostatné instance a přepínání se bude dít pomocí vlastností JDBC). Jeden server bude primární a druhý sekundární. Na sekundární server se zpracování přepne při výpadku primárního serveru. Pokud budou v poruše oba databázové servery, převezme činnost druhé (třetí) datové centrum. V každém datovém centru budou na oddělených discích dvě databáze. Mezi těmito databázemi bude prováděna replikace v reálném čase. Pokud dojde k výpadku jedné databáze (disků), provoz se přepne na druhou databázi. Pokud dojde k výpadku obou databází (disků), převezme činnost druhé (třetí) datové centrum. Pokud dochází k přepnutí na druhé (třetí)

VERZE 01



datové centrum, budou se v druhém (třetím) centru používat databázové servery i databáze daného centra. Mezi datovými centry bude docházek k replikaci dat v reálném čase. Pokud nebude záložní datové centrum přístupné, budou transakce odloženy do doby, až bude navázáno spojení. Zálohování provozní databáze se bude provádět jednou denně na určený disk. Během provozu se bude provádět ukládání transakčních logů na disk. LDAP Aby bylo v prostředí zadavatele dosaženo očekávaných odezev, bude za tímto účelem na základě interních zátěžových testů vybalancován: 1. 2. 3. 4.

Výkon virtuálních serverů Počet instancí LDAP komponenty Konfigurace vlastní LDAP komponenty Optimalizace na straně klientů. (např. connection pool)

Nasazený produkt podporuje současný běh několika vzájemně clusterovaných synchronizovaných instancí a tím i požadovanou škálovatelnost a vysokou dostupnost.

VERZE 01



04. Rozhraní systému NIS IZS Tato kapitola popisuje scénáře komunikace jak mezi systémem NSPTV a IS OŘ, tak mezi jednotlivými IS OŘ, které jsou realizovány prostřednictvím IPL.

Typy komunikace Veškerá komunikace bude probíhat v protokolu SOAP na bázi volání webových služeb. Komunikace bude probíhat jako asynchronní (budou existovat i synchronní služby) a tento asynchronní (popř. synchronní) model bude zapouzdřený uvnitř integrační platformy. Součástí hlavičky odesílané/přijímané zprávy bude identifikátor typu zprávy (způsob zpracování zprávy pro cílový systém). Tabulka 9: Číselník Typ zprávy

IdTypZpravy NEV NPO SMS POT

Typ zprávy Zpráva nevyžaduje potvrzení Zpráva vyžaduje potvrzení Zpráva současně odesílána SMS a vyžaduje potvrzení Zpráva potvrzena

Synchronní komunikace Synchronní služby budou realizovány pouze pro potvrzení předání zprávy na úroveň IPL. Dále budou synchronní služby využity pro volání nahrávání, správu číselníků a administraci. Obrázek 27: Model synchronní komunikace

NSPTV

Synchronní komunikace

IPL

IS OŘ

Odeslaná zpráva

Status odpovědi

Pro návratové kódy synchronního volání bude využit tento číselník: Tabulka 10: Číselník Status odpovědi

IdStatusOdpovedi OK ERR WAR

Status odpovědi Odpověď byla přijata Chyba Varování

Asynchronní komunikace Asynchronní komunikace přináší tyto výhody:

VERZE 01



• Volnější vazby mezi jednotlivými systémy • Stabilizaci časových odezev pro klientské aplikace • Spolehlivé a transakční doručení zpráv • Regulace zátěže (throttling) • Paralelismus zpracování a efektivnější thread management (neblok. operace) • Disconnected operace (na úrovni krajského routingu, při výpadku ITS) • Škálovatelnost. Současně je nutné, aby IPL jako jediná komunikační platforma mezi systémy dokázala eliminovat nevýhody této formy komunikace: • Složitější programovací model • Sequence problém - message channel garantuje doručení či zpracování zprávy, ale již negarantuje, kdy bude zpráva doručena (paralelní zpracování, redelivery, error handling), což může ovlivnit konečné pořadí doručených zpráv (typický problém závislosti odeslání – aktualizace události). Toto lze řešit prostřednictvím Resequenceru, Message groupami či Exkluzivním konzumentem nebo též potvrzováním zpráv vyžadujících pořadí doručení. Popř. chybovým stavem a zamezením odeslání navazující zprávy pokud událost má tento stav. • Ne všechny scénáře mohou operovat asynchronně na úrovni „send and forget“. Pro ty je nutné definovat kombinované řešení.

Pravidla komunikace Pro komunikaci byly definovány tyto zásady: • Zpráva je jednoznačně identifikována odesílatelem pomocí GUID (IdZpravy). • Při potvrzení (např. u součinnosti nebo vyžadovaná uvnitř zprávy) je nutné uvádět v hlavičce ID potvrzované zprávy (IdZpravy). Zprávy budou přenášeny protokolem http. Tento protokol je bezestavový a proto neumožňuje potvrdit spolehlivý přenos dat (chybová hláška odesilatele i při úspěšném odeslání). Když klient navazuje spojení se serverem a server neodpoví v požadovaném časovém limitu, který nastavil klient (příliš nízký timeout před zahájením komunikace), jeví se zpráva pro klientskou stranu jako nedoručená (SocketTimeout), i když na straně serveru byla zpráva korektně přijata a transakčně zpracována. IPL na základě vydefinovaných polit zajišťuje opětovné pokusy o doručení. Obecně tedy může docházek duplicitám při opakovaných pokusech o doručení. Koncové systémy proto musí umět ztotožnit a unifikovat zprávy (IdZpravy). Doručení zpráv ve správném pořadí je řešeno na IPL prostřednictvím časových razítek IPL. Pro každou zprávu je možné stanovit čas avizace, po jehož uplynutí bude odesilatel zprávy, kterou se nepodařilo IPL úspěšně odeslat cílovému systému, informován o neúspěšnosti doručení. Dále je možné po zprávu stanovit platnost, po jejímž uplynutí bude nedoručena zpráva vyloučena z doručování. Při nevyplnění těchto atributů odesílajícím systémem, budou jednotlivým typům zpráv přiřazeny defaultní časy avizace a platnosti.

VERZE 01



Každé zprávě lze také nastavit atribut potvrzení doručení, kdy odesilatel bude informován o úspěšném doručení zprávy cílovému systému prostřednictvím potvrzovací zprávy od tohoto systému. Struktura v rámci hlavičky zprávy umožňuje trasovat průchod zprávy systémy. V případě požadavku na trasování zprávy bude každá komponenta systému (včetně odesilatele) schopna přidat jeden záznam do této struktury.

Scénáře komunikace Jsou podporovány následující scénáře komunikace: Odeslání založené události Obrázek 28: Odeslání založené události z NSPTV (APL) nebo z OŘ

NSPTV

Z1

IPL

Založená událost v NSPTV Z1

Z1

IS OŘ

Založená událost v NSPTV iplOdeslatUdalost

Založená událost v NSPTV Z2

Z2

Založená událost v OŘ

Založená událost v OŘ Z2

Založená událost v OŘ

Obrázek 29: Scénář Z1 - Odeslání založené události z NSPTV do OŘ / NSPTV (status OK)

VERZE 01



Obrázek 30: Scénář Z2 - Odeslání založené události z OŘ do OŘ / NSPTV (status OK)

Odeslání aktualizované události Obrázek 31: Odeslání aktualizované události z NSPTV nebo z OŘ

NSPTV

Z3

IPL

Aktualizovaná událost v NSPTV Z3

Z3

IS OŘ

Aktualizovaná událost v NSPTV iplUpravitUdalost

Aktualizovaná událost v NSPTV Z4

Z4

Aktualizovaná událost v OŘ

Aktualizovaná událost v OŘ Z4

Aktualizovaná událost v OŘ

VERZE 01



Předání události jiné složce / operačnímu středisku Obrázek 32: Předání události k řešení na jiné OŘ

IPL

Z5

IS OŘ

Předávaná událost

iplUpravitUdalost Z5

Předávaná událost

Sloučení událostí Obrázek 33: Sloučení události (vztah parent – child)

IPL

Z6

IS OŘ

Slučovaná událost

iplUpravitUdalost Z6

Slučovaná událost

VERZE 01



Řešení výpadků Obrázek 34: Scénář Z7 - Aktualizace informací o SaP (polling)

Obrázek 35: Scénář Z8 - Aktualizace informací na klientovi NSPTV (notify)

VERZE 01



Obrázek 36: Scénář Z9 – Nefunkční ITS

Obrázek 37: Scénář Z10 – Potvrzení

Potvrzení zpráv vyžadujících pořadí. Reakce na problémové a chybové stavy. Žádost o opětovné zaslání (zpráva nevyhovuje validačním kritériím). IPL

Z10

IS OŘ

Potvrzení

iplOdeslatStatus

Z10

Potvrzení

Stav SaP Obrázek 38: Status a pozice SaP

IPL

Z11

IS OŘ NSPTV

SaP

iplOdeslatInfoSaP

Z11

SaP

Pozice SaP budou odesílány v intervalu 5 sekund s doplňkovými informacemi o rychlosti, směru pohybu a stavu majáku.

VERZE 01



Operační situace Obrázek 39: Změny operační situace

IPL

Z12

IS OŘ NSPTV

Operační situace iplOdeslatOperacni

Z12

Operační situace

Obrázek 40: Obecná komunikace mezi operačními středisky

IPL

Z13

IS OŘ NSPTV

Hlášení

iplOdeslatHlaseni

Z13

Hlášení

Management hovorů Služby pro výpisy hovorů a přehrání záznamů dle zvoleného filtru jsou k dispozici na IPL jako webová služba. Administrace systému Služba pro registraci k odběru číselníkových změn je k dispozici na IPL jako webová služba. Obrázek 41: Scénář Z14 – Aktualizace číselníku

VERZE 01



Struktura zpráv Všechny zprávy budou posílány ve formátu XML a na úrovni IPL bude provedena jejich úplnosti a konzistence podle definovaných pravidel validace. Validace Mohou nastat tyto 3 scénáře: • zpráva neobsahuje povinný element (např. UID) – zpráva je vrácena odesilateli k doplnění • zpráva neobsahuje potřebný element – zpráva je doplněna o tento element na úrovni IPL a odeslaná úplná (např. OŘ odesílá žádost o součinnost, ale vyplněn je pouze element Součinnost, protože se ostatní atributy události nezměnily – IPL doplňuje všechny ostatní elementy z poslední aktuální zprávy o události) • zpráva obsahuje nevalidní element (např. poloha podle souřadnic neodpovídá zadané adrese) – IPL opravuje příslušný element podle definovaných pravidel. Pravidla validace jsou k dispozici též jako webová služba na úrovni IPL, takže je mohou volat IS OŘ (volání této služby bude umožněno výhradně při testování systému a verzování zpráv).

VERZE 01



Datová struktura zpráv Tabulka 11: Struktura zprávy Událost OZN

Název elementu

Popis

Datový typ

1 100 101 102 103 104 105 1051 1052 1053

ZpravaUdalost IdUdalost VolajiciCislo VolaneCislo CisloProVytezeni HovorId MístoOznameni Pozice Polygon SmerPohybu

Informace o události Unikátní identifikátor události UUID. Číslo nebo IMEI, ze kterého byla volána tísňová linka. Číslo volané tísňové linky. Číslo, pro případné další vytěžení hovoru. Identifikátor hovoru v telefonii. Místo oznámení hovoru. Pozice volajícího. Polygon, ve kterém se nachází volající. Směr pohybu, ve kterém se volající pohybuje. - e-calll Adresa, ze které volá volající z pevné linky podle INFO35 (bude domluveno - zřejmě kod RUIAN) Identifikace místa události- stejný typ elementu jako místo oper. situace. Informace, zda má byt misto vizualizováno Pozice místa události - bod. Polygon, místa události. Směr pohybu události. Adresa místa události - adresní bod RUIAN. Upřesnění místa události - patro budovy. Upřesnění místa události - číslo bytu. Způsob stanovení místa události. Adresa události. Adresa nemusí být uvedena, pokud uvedena je, musí obsahovat alespoň kód obce. Obec (RUIAN). Část obce (RUIAN). Městská část (RUIAN). Ulice (RUIAN). Superúsek. Superúsek nemusí být uveden, pokud uveden je, musí obsahovat identifikátor i kilometr. Identifikátor superúseku. Staničení (km) superúseku. Identifikátor zájmového budu - sloup apod. Poznámka k místu události. Identifikátor operátora nebo dispečera, který událost zanesl do systému. Identifikátor operačního střediska, které přijalo TV nebo založila událost v OŘ a která událost primárně řídí - viz číselník. Identifikátor rajónů podle místa události tak, jak jsou definovány ve vrstvě GIS. Typ vzniklé události – viz číselník. Podrobná klasifikace události HZS. Podrobná klasifikace události podle Policie ČR. Podrobná klasifikace události podle ZZS. Stav události - viz číselník - založena v NPSTV, založena v OŘ. Závažnost události – viz číselník (spolupráce nyvyžádána, poplach II stupně apod ). Závažnost události pro ZZS - viz číselník (selhání životních funkcí apod.). Poznamka ke klasifikace klasifikace - complex el. Poznámka 1 (tato poznámka není sdílená). Interní poznámka složky / kraje s bližším popisem události (poznámka není sdílená mimo vlastní OŘ).. Jméno a příjmení osoby, která událost oznámila. Informace o vozidlech, která se učastní události (jedná se např. o vozidla, která havarovala). Typ předmětu události - osobní auta, nákladní auta, zranění apod. Hodnota předmětu - počet osobních vozidel apod. Informace o součinnosti. Součinnost nemusí být uvedena, pokud uvedena je prázdný není, musí obsahovat identifikaci OS i stav. Identifikátor operačního střediska, které se týká součinnost (i OŘ stejné složky v jiném kraji) – viz číselník. Stav součinnosti – viz číselník. Poznámka Identifikace spojených nebo souvisejících událostí. Nemusí být uvedena, pokud uvedena je musí obsahovat všechny elementy kromě pozn. Typ spojení událostí - viz číselník. Identifikátor operačního střediska, pro které je spojení platné Unikátní identifikátor spojované události UUID. Poznámka ke spojení událostí.

Complex UuidType xs:string xs:string xs:string xs:string Complex PointN PolygonN Vektor

1054 106 1060 1061 1062 1063 1064 1065 1066 1067 1068 10681 10682 10683 10684 1069 10691 10692 1070 1071

AdresaOznameni MistoUdalosti VizualizaceMista Pozice Polygon SmerPohybu AdresaUdalosti Patro CisloBytu Zpusob Vyplneni AdresaUdalosti Obec CastObce MestskaCast Ulice Superusek Superusek SuperusekKm IdentifikatorBodu PoznamkaMistaUdalosti

107

IdOperator

108

IdOperacniStredisko

109

IdRajon

110 111 112 113 114

IdTypUdalosti IdTypUdalostiHZS IdTypUdalostiPCR IdTypUdalostiZZS IdStavUdalosti

115

IdZavaznostUdalosti

116

IdNeodkladnostUdalosti

117 1171

PoznamkaKlasif Poznamka

1172

Poznamka2

118

Oznamovatel

119

PredmetUdalosti

1901 1902 120

TypPredmetu Hodnota Soucinnost

1201

IdOperacniStredisko

1202 1203

IdStavSoucinnost SpecifikaceSoucinnosti

123 1231 1232 1233 1234

SpojeniUdalosti IdTypSpojeniUdalosti IdOperacniStredisko IdUdalost PoznamkaSpojeni

Číselník

Povinné u nově založené události

Povinné u aktualizované události

Násobnost

ano ano ano ano ano -

ano -

ano -

xs:string

-

-

-

Complex

ano

-

ano

xs:boolean Místo události PointN PolygonN Path xs:string xs:integer xs:integer xs:string Způsob vyplnění

ano ano ano

-

-

Complex

-

-

-

xs:string xs:string xs:string xs:string

ano -

ano -

-

Complex

-

-

-

xs:string xs:double xs:integer xs:string

ano ano -

ano ano -

ano -

xs:string

Operátoři

ano

ano

xs:string

Operační střediska

ano

-

-

ano

-

ano

ano u HZS u PČR u ZZS ano

ano ano

ano -

ano

-

-

xs:string xs:string xs:string xs:string xs:string xs:string

Typ události Typ události HZS Typ události PČR Typ události ZZS Stav události

xs:string

Závažnost události

xs:string

Neodkladnost události

u ZZS

xs:string

-

-

ano

xs:string

-

-

ano

xs:string

-

-

Complex

-

-

-

-

xs:string xs:string

Typ předmětu

Complex

ano

-

-

ano

xs:string


ano

ano

-

xs:integer

Stav součinnosti

ano -

ano -

-

-

-

ano

Typ spojení událostí Operační střediska

ano ano ano -

ano ano ano -

-

Complex xs:integer xs:string UuidType xs:string

Tabulka 12: Struktura zprávy Operační situace OZN

Název elementu

Popis

Datový typ

2 201 202 2021 2022 2023 2024 2025 2026 2027 2028

OperacniSituace IdTypOperacniSituace MistoOS VizualizaceMista Pozice Polygon SmerPohybu AdresaUdalosti Patro CisloBytu Zpusob Vyplneni

Informace o operační situaci. Typ operační situace - viz číselník. Identifikace místa OS - stejný typ elementu jako místo události. Informace, zda má být operační situace vizualizována Pozice operační situace - bod. Polygon, operační situace. Směr pohybu. Adresa operační situace - adresní bod RUIAN. Upřesnění operační situace - patro budovy. Upřesnění operační situace - číslo bytu. Způsob stanovení místa operační situace. Adresa události. Adresa nemusí být uvedena, pokud uvedena je, musí obsahovat alespoň kód obce. Obec (RUIAN). Část obce (RUIAN). Městská část (RUIAN). Ulice (RUIAN). Superúsek. Superúsek nemusí být uveden, pokud uveden je, musí obsahovat identifikátor i kilometr. Identifikátor superúseku. Staničení (km) superúseku. Identifikátor zájmového budu - sloup apod. Poznámka k místu události. Poznámka k upřesnění operační situace.

Complex xs:integer Typ operační situace Complex xs:boolean Místo události PointN PolygonN Path xs:string xs:integer xs:integer xs:string Způsob vyplnění

2029 20291 20292 20293 20294 2030

AdresaUdalosti Obec CastObce MestskaCast Ulice Superusek

20301 Superusek 20302 SuperusekKm 2031 IdentifikatorBodu 2032 PoznamkaMistaUdalosti 203 OperacniSituacePoznamka

VERZE 01


Číselník



Násobnost

ano ano ano ano ano

-

ano -

Complex

-

-

-

xs:string xs:string xs:string xs:string

ano -

ano -

-

Complex

-

-

-

xs:string xs:double xs:integer xs:string xs:string

ano ano -

ano ano -

ano -


Tabulka 13: Struktura zprávy SaP OZN

Název elementu

Popis

Datový typ Číselník

3 301 302 303

ZpravaSap IdSap IdTypSap IdStavSap

Informace o silách a prostředcích. Unikátní identifikátor Sap. Typ Sil a prostředků – viz číselník. Stav SaP– viz. číselník stavů SaP. Specifikace SaP obsahuje konkrétní informace o prostředku (volací znak, typ, SaP, apod.) podle potřeby složky v rozsahu 120 znaků. Pozice SaP. Směr pohybu SaP. Rychlost pohybu SaP. Informace, zda vozidlo jede se zapnutým majákem. Poznámka k nasazení SaP.

Complex UuidType xs:string xs:string

304

SpecifikaceSap

305 306 307 308 306

PoziceSap SmerPohybu Rychlost Majak PoznamkaSap

Typ SaP Stav SaP



Násobnost

ano ano ano

ano -

-

xs:integer

-

-

-

PointN Vektor xs:double xs:boolean xs:string

ano -

ano -

-

Tabulka 14: Struktura Obecné zprávy Povinné u nově založené události


Complex UuidType

ano

ano

-

UuidType

-

-

-

xs:dateTime

ano

ano

-

xs:dateTime xs:integer

ano -

ano -

-

OZN

Název elementu

Popis

Datový typ Číselník

4 401

Hlavička zprávy ZpravaId

402

PuvZpravaId

403

DatumVzniku

404 404

DatumIPL PlatnostZpravy

405

CasAvizace

406

Odesilatel

407 408

IdTypZprávy VerzeSchematuZprávy

409

IdOperator

410 4101

Vizualizace IdVizualizace

Obecná zpráva IS IZS. Unikátní identifikátor zprávy. Unikátní identifikátor původní zprávy, pokud zpráva reaguje na předchozí zprávu. Datum a čas založení /potvrzení zprávy v odesílajícím systému (NSPTV nebo IS OŘ). Datum a čas, kdy zprávu / potvrzení převzala IPL. Platnost zprávy od přijetí na IPL v sekundách Doba, po které bude zdrojovému systému odeslána informace o nedoručení zprávy v sekundách Identifikátor operačního střediska, ze kterého byla zpráva odeslána – viz číselník. Typ zprávy a její závažnosti - viz číselník. Verze xml schématu zprávy. Identifikátor operátora nebo dispečera, který zprávu napsal nebo potvrdil. Informace o vizualizaci (adresátu zprávy). Typ povolené vizualizace (pravidlo pro výběr adresáta)- viz číselník. Identifikátor operačního střediska, kterého se týká povolená vizualizace – viz číselník. Informace o povolení/zákazu

4102

IdOperacniStredisko

4103

ZakazVizualizace

xs:integer

Násobnost

-

-

-

xs:string


ano

ano

-

xs:string xs:string

Typ zprávy

ano ano

ano ano

-

xs:string

Operátoři

ano

ano

-

Complex xs:integer

Vizualizace

ano ano

ano ano

-

xs:string


-

-

ano

-

-

-

xs:boolean

Tabulka 15: Struktura zprávy Response OZN

Název elementu

Popis

Datový typ

5

Response

Complex

402

IdZpravyIPL

Odpověď systému (synchro volání). Unikátní identifikátor původní zprávy, pokud zpráva reaguje na předchozí zprávu.

407 4072 4073 4073

Status VysledekKod VysledekDetail DatumOdpoved

Číselník

xs:integer Complex xs:string Status xs:string xs:datetime

Výsledek - OK, Error. Detailní popis výsledku. Datum a čas odpovědi



-

-

-

ano ano ano

ano ano ano

-

Číselníky Používání těchto číselníků je povinné pro všechny systémy komunikující v rámci IS IZS prostřednictvím IPL. Služby pro jejich aktualizaci jsou k dispozici na IPL. Tabulka 16: Číselník Typ události

IdTypUdalosti AVY DON MRT NEM POH POZ ZIV TEP TRE NEL URA ZAC JIN TST

VERZE 01

Typ události Anonymní výhružka. Dopravní nehoda. Nález mrtvoly. Onemocnění. Pohřešovaná osoba. Požár. Přímé ohrožení života. Technická pomoc. Trestná činnost. Únik nebezpečných látek. Úraz. Záchrana osob a zvířat. Jiná událost. Technologický test.


Násobnost


Tabulka 17: Číselník Typ události HZS

Doplní gestor složky podle aktuálního stavu číselníku ve fázi Funkční prototyp. Bude umožněn dvouúrovňový číselník. Tabulka 18: Číselník Typ události PČR

Doplní gestor složky podle aktuálního stavu číselníku ve fázi Funkční prototyp. Bude umožněn dvouúrovňový číselník. Tabulka 19: Číselník Typ události ZZS

Doplní gestor složky podle aktuálního stavu číselníku ve fázi Funkční prototyp. Bude umožněn dvouúrovňový číselník. Tabulka 20: Číselník Stav události

IdStavUdalosti NER ZAL VYT ZOR VYJ DOJ NEE ODJ UZA UKO PRE JIN

Stav události Neřešeno Událost založena v NSPTV. Událost v NSPTV vytěžena. Událost založena v OŘ. Výjezd prvních SaP složky. Na místě první SaP složky. Událost neeskaluje. Odjezd posledních SaP složky. Událost uzavřena OS. Událost ukončena v OŘ. Předáno mimo ZS IZS. Řešeno v rámci jiné události.

Tabulka 21: Číselník Závažnost události

IdZavaznostUdalosti NEV VYZ PO2 PO3 POZ

Závažnost události Spolupráce dosud nevyžádána. Spolupracují 2 a více složek IZS. Stupeň poplachu v IZS - II. stupeň poplachu v IZS. Stupeň poplachu v IZS - III. stupeň poplachu v IZS. Zvláštní stupeň poplachu.

Tabulka 22: Číselník Neodkladnost události

IdNeodkladnostUdalosti SEL PSE ZZS OST

Neodkladnost události (pouze ZZS) Selhání základních životních funkcí nebo hromadné postižení osob. Pravděpodobné selhání základních životních funkcí. Vyžaduje poskytnutí zdravotnické záchranné služby. Ostatní.

Tabulka 23: Číselník Vizualizace

IdVizualizace VSK ASK VSE VYB ZAK SLK

VERZE 01

Vizualizace Vizualizace povolena pouze pro OŘ a NSPTV dané složky a kraje Vizualizace povolena pouze pro OŘ a NSPTV dané složky všech krajů Vizualizace povolena všem Vizualizace povolena vybraným složkám a/nebo krajům Vizualizace dodatečně zakázána mimo OŘ dané složky a kraje Vizualizace povolena pouze operátorům OŘ dané složky a kraje



Tabulka 24: Číselník Typ spojení události

IdTypSpojeníUdalosti ROD POT ZNP SOU

Typ spojení události Událost je rodič Událost je potomek Zneplatnění spojení Události souvisí

Tabulka 25: Číselník Stav součinnosti

IdStavSoucinnost NEV INF VYZ PRI SEP UKO ODM

Stav součinnosti Nevyžádaná Informovaná (při vizualizaci události) Vyžádáno (odeslání výzvy) Přijato (potvrzení z příslušného OŘ) Separace složky Ukončení součinnosti Odmítnutí součinnosti

Tabulka 26: Číselník Typ předmětu

IdTypPředmětu OVO NAV ZRAN JINY

Typ předmětu Osobní vozidla Nákladní vozidla Zranění Jiný typ informace

Tabulka 27: Číselník Způsob vyplnění

IdZpusob Vyplneni SOU ADR ASO

Způsob vyplnění Zadána souřadnice,adresa byla dopočtena. Zadána adresa,souřadnice byla dopočtena. Zadána adresa i souřadnice.

Tabulka 28: Číselník Typ operační situace

IdTypOperacniSituace DEK SHR OBV DET SPH SPP SPZ PRE JIP KON UZA SME VST DOP JIN

VERZE 01

Typ operační situace Dekontaminační stanoviště (osob a techniky) Shromaždiště evakuovaných osob Obvaziště Místo pro oběti Soustředěné SaP HZS Soustředěné SaP PČR Soustředěné SaP ZZS Překladové místo Jiný další účelový prostor (nutno upřesnit v poznámce) Kontaminovaná oblast (polygon) Uzavřená oblast (polygon) Směry a uzavírky dopravy (vektory) Vstupní stanoviště pro uzavřené oblasti (body) Dopravní informace Jiné informace



Tabulka 29: Číselník Typ SaP

IdTypSap HLP VOP VRP VPP VTH VJH VPH VOH SAZ VLZ VRZ VPZ OSP OSH OSZ VES JIN

Typ SaP Hlídka PČR Velitel opatření PČR Vrtulník PČR Vodní prostředek PČR Mobilní požární technika HZS Velitel jednotek HZS Vzdušný prostředek HZS Vodní prostředek HZS Sanitka ZZS Vedoucí lékař ZZS Vrtulník LZS Vodní prostředek ZZS Ostatní SaP PČR Ostatní SaP HZS Ostatní SaP ZZS Velitelské stanoviště Jiný typ SaP

Tabulka 30: Číselník Stav SaP

IdStavSap NEA VYZ VYJ UDA ODJ NAV JIN

Stav SaP Neaktivován (neodesílá se do NIS mimo PČR) Výzva (vyhlášení poplachu) Výjezd na místo události Na místě události Odjezd – pouze ZZS Návrat Jiný mimořádný stav SaP (např. havárie)

Tabulka 31: Číselník Složka

IdSlozky HZS ZZS PCR

VERZE 01

Složka Hasičský záchranný sbor Zdravotní záchranná služba Policie České republiky



Tabulka 32: Číselník Operační střediska

IdSlozka HPHA HJHM HJHC HHKK HVYS HSTC HKVK HLBK HOLK HMSK HPAK HPLK HULK HZLK PPHA PJHM PJHC PHKK PVYS PSTC PKVK PLB POLK PMSK PPAK PPLK PULK PZLK ZPHA ZJHM ZJHC ZHKK ZVYS ZSTC ZKVK ZLBK ZOLK ZMSK ZPAK ZPLK ZULK ZZLK GRHZ PPRE HTST PTST ZTST

Operační střediska HZS Hlavní město Praha HZS Jihomoravský kraj HZS Jihočeský kraj HZS Královéhradecký kraj HZS Kraj Vysočina HZS Středočeský kraj HZS Karlovarský kraj HZS Liberecký kraj HZS Olomoucký kraj HZS Moravskoslezský kraj HZS Pardubický kraj HZS Plzeňský kraj HZS Ústecký kraj HZS Zlínský kraj PČR Hlavní město Praha PČR Jihomoravský kraj PČR Jihočeský kraj PČR Královéhradecký kraj PČR Kraj Vysočina PČR Středočeský kraj PČR Karlovarský kraj PČR Liberecký kraj PČR Olomoucký kraj PČR Moravskoslezský kraj PČR Pardubický kraj PČR Plzeňský kraj PČR Ústecký kraj PČR Zlínský kraj ZZS Hlavní město Praha ZZS Jihomoravský kraj ZZS Jihočeský kraj ZZS Královéhradecký kraj ZZS Kraj Vysočina ZZS Středočeský kraj ZZS Karlovarský kraj ZZS Liberecký kraj ZZS Olomoucký kraj ZZS Moravskoslezský kraj ZZS Pardubický kraj ZZS Plzeňský kraj ZZS Ústecký kraj ZZS Zlínský kraj Generální ředitelství HZS Policejní prezidium test 1 - HZS test 2 - PCR test 3 - ZZS

Tabulka 33: Číselník Operátoři

IdOperator X99999 Z05023

VERZE 01

Operátoři IdOperatora ve tvaru SlozkaID + uid operátora. příklad - operátor ZZS kraje Vysočina s poř. Číslem 23.



VERZE 01



Rejstřík Seznam obrázků a modelů Obrázek 1: Celková koncepce sítí v kontextu komunikační infrastruktury ITS................................................... 5 Obrázek 2: Propagace směrovacích informací................................................................................................................... 7 Obrázek 3: Směry komunikace................................................................................................................................................. 8 Obrázek 4: Redistribuce na PE routerech ............................................................................................................................ 8 Obrázek 5: PE-CE připojení složky ......................................................................................................................................... 9 Obrázek 6: Redistribuce na CE routerech ......................................................................................................................... 10 Obrázek 7: Řešení s firewally ................................................................................................................................................. 11 Obrázek 8: Připojení hlavních DC......................................................................................................................................... 12 Obrázek 9: Připojení KDC ........................................................................................................................................................ 13 Obrázek 10: Začlenění DC1 a DC2 do kontextu komunikačníinfrastruktury ITS ............................................. 14 Obrázek 11: Začlenění DC3 do kontextu komunikační infrastruktury ITS ......................................................... 15 Obrázek 12: Fyzická infrastruktura DC ............................................................................................................................. 16 Obrázek 13: L3 model DC ........................................................................................................................................................ 18 Obrázek 14: Koncepce SAN sítí v Praze (DC1 a DC2) ................................................................................................... 19 Obrázek 15: Začlenění krajského DC do kontextu infrastruktury ITS .................................................................. 21 Obrázek 16: Fyzická infrastruktura krajského DC ........................................................................................................ 21 Obrázek 17: Schéma pracoviště NSPTV............................................................................................................................. 26 Obrázek 18: Schéma hybridního pracoviště .................................................................................................................... 27 Obrázek 19: Dvojí úroveň zajištění dostupnosti ............................................................................................................ 28 Obrázek 20: Možné výpadky a jejich řešení ..................................................................................................................... 29 Obrázek 21: Bloky k řešení redundance telefonie ........................................................................................................ 30 Obrázek 22: Konceptuální model NIS ................................................................................................................................. 33 Obrázek 23: Konceptuální model Telefonie (hlasového systému)......................................................................... 38 Obrázek 24: Konceptuální model Nahrávání .................................................................................................................. 41 Obrázek 25: Architektura vysoké dostupnosti komponent ...................................................................................... 54 Obrázek 26: Architektura vysoké dostupnosti se záložním DC3 ............................................................................ 55 Obrázek 27: Model synchronní komunikace ................................................................................................................... 58 Obrázek 28: Odeslání založené události z NSPTV (APL) nebo z OŘ ...................................................................... 60 Obrázek 29: Scénář Z1 - Odeslání založené události z NSPTV do OŘ / NSPTV (status OK)......................... 60 Obrázek 30: Scénář Z2 - Odeslání založené události z OŘ do OŘ / NSPTV (status OK)................................. 61 Obrázek 31: Odeslání aktualizované události z NSPTV nebo z OŘ ......................................................................... 61 Obrázek 32: Předání události k řešení na jiné OŘ ......................................................................................................... 62 Obrázek 33: Sloučení události (vztah parent – child) .................................................................................................. 62 Obrázek 34: Scénář Z7 - Aktualizace informací o SaP (polling) .............................................................................. 63 Obrázek 35: Scénář Z8 - Aktualizace informací na klientovi NSPTV (notify) .................................................... 63 Obrázek 36: Scénář Z9 – Nefunkční ITS............................................................................................................................. 64 Obrázek 37: Scénář Z10 – Potvrzení ................................................................................................................................... 64 Obrázek 38: Status a pozice SaP ........................................................................................................................................... 64 Obrázek 39: Změny operační situace.................................................................................................................................. 65 Obrázek 40: Obecná komunikace mezi operačními středisky ................................................................................. 65 Obrázek 41: Scénář Z14 – Aktualizace číselníku............................................................................................................ 65

VERZE 01



Seznam tabulek Tabulka 1: Fyzické servery pro 1 DC .................................................................................................................................. 24 Tabulka 2: Virtuální stroje pro 1 DC ................................................................................................................................... 24 Tabulka 3: Fyzické servery pro 1 krajské DC .................................................................................................................. 25 Tabulka 4: Virtuální stroje pro 1 krajské DC ................................................................................................................... 25 Tabulka 5: Funkcionalita NIS IZS.......................................................................................................................................... 34 Tabulka 6: Popis služeb NIS.................................................................................................................................................... 36 Tabulka 7: Obrazovky NSPTV ................................................................................................................................................ 44 Tabulka 8: Popis služeb GIS .................................................................................................................................................... 51 Tabulka 9: Číselník Typ zprávy ............................................................................................................................................. 58 Tabulka 10: Číselník Status odpovědi ................................................................................................................................ 58 Tabulka 11: Struktura zprávy Událost ............................................................................................................................... 67 Tabulka 12: Struktura zprávy Operační situace............................................................................................................. 67 Tabulka 13: Struktura zprávy SaP ....................................................................................................................................... 68 Tabulka 14: Struktura Obecné zprávy................................................................................................................................ 68 Tabulka 15: Struktura zprávy Response ........................................................................................................................... 68 Tabulka 16: Číselník Typ události ........................................................................................................................................ 68 Tabulka 17: Číselník Typ události HZS............................................................................................................................... 69 Tabulka 18: Číselník Typ události PČR .............................................................................................................................. 69 Tabulka 19: Číselník Typ události ZZS ............................................................................................................................... 69 Tabulka 20: Číselník Stav události ....................................................................................................................................... 69 Tabulka 21: Číselník Závažnost události ........................................................................................................................... 69 Tabulka 22: Číselník Neodkladnost události ................................................................................................................... 69 Tabulka 23: Číselník Vizualizace .......................................................................................................................................... 69 Tabulka 24: Číselník Typ spojení události ........................................................................................................................ 70 Tabulka 25: Číselník Stav součinnosti ................................................................................................................................ 70 Tabulka 26: Číselník Typ předmětu .................................................................................................................................... 70 Tabulka 27: Číselník Způsob vyplnění ............................................................................................................................... 70 Tabulka 28: Číselník Typ operační situace ....................................................................................................................... 70 Tabulka 29: Číselník Typ SaP ................................................................................................................................................. 71 Tabulka 30: Číselník Stav SaP ................................................................................................................................................ 71 Tabulka 31: Číselník Složka .................................................................................................................................................... 71 Tabulka 32: Číselník Operační střediska ........................................................................................................................... 72 Tabulka 33: Číselník Operátoři ............................................................................................................................................. 72

VERZE 01



Národní informační systém integrovaného záchranného systému (NIS IZS)

Recommend Documents