Analýza technického řešení projektu Koncept TO-BE

Analýza technického řešení projektu Koncept TO-BE 2. července 2009 FINAL

Obsah Úvodní informace... 3 I. Cíle projektu... 4 Hodnocené období... 5 Kauzalita cílů... 5 Specifikace cílů... 7 Cíle v perspektivě Finance (rozpočtová omezení)... 7 Cíle v perspektivě Zákazník (veřejný zájem)... 8 Cíle v perspektivě Procesy... 10 Cíle v perspektivě Zdroje (ICT)... 13 Vazba cílů a ukazatelů projektu a standardů... 14 II. Procesní koncept... 15 Cílový procesní koncept... 16 Proces Zajistit příjem tísňového volání... 17 Proces Zajistit operační řízení... 23 Kvantifikace procesů... 31 Vstupní data a parametry simulace... 31 Simulace extrémní situace... 37 Návrh kapacit ICT na základě simulace... 42 Simulace běžné situace... 43 Krajské ZZS a přelivy... 46 III. ICT koncept... 47 Zadání pro cílový koncept... 48 Cílová architektura IS... 49 Integrační platforma... 51 NSPTV... 53 GIS... 55 Konektivita... 58 IV. Rizika... 60 Projektová rizika... 61 Stanovení projektových rizik... 61 Technická a implementační projektová rizika... 62 Operační rizika... 63 Standardy... 64 V. Zajištění projektu... 66 Ucelené části projektu... 67 Možné formy zajištění projektu... 67 Požadavky na navazující projektovou dokumentaci... 67 Fáze, etapy a harmonogram projektu... 68 Fáze projektu... 68 Etapy realizační fáze... 68 Přílohy... 69 Zdroje dat pro definici cílů projektu... 70 Datové modely ICT... 77 Konektivita... 83 Trasy nových přípojek... 84 Věcný obsah typového projektu... 92 Rejstříky a seznamy... 93 Seznam obrázků... 93 Seznam modelů... 94 Seznam tabulek... 95 Pojmy a zkratky... 97 strana 2 (celkem 99 stran)

Úvodní informace Název dokumentu Účel dokumentu Termíny zpracování Koncept TO-BE Shrnutí výstupů projektu zadání cílového stavu (TO-BE) z hlediska procesů a jejich kvantifikace, řešení ICT, rizik a etapizace projektu. zpracováno předáno k připomínkám připomínky projednány připomínky zapracovány akceptace 21/6/09 22/6/09 25/6/2009 26/6/2009 2/72009 Verze dokumentu FINAL (akceptováno) Zadavatel Projektový tým Za HZS dále spolupracovali Za ZZS dále spolupracovali Za PČR dále spolupracovali Zpracovatel Ministerstvo vnitra Generální ředitelství Hasičského záchranného sboru České republiky plk. Ing. Luděk Prudil (Věcný gestor projektu), Bc. Jiří Lazar Žižka (Projektový manager), Mgr. László Hajnal (Projektový manager PMO MV ČR), mjr. Mgr. Jaroslav Lepeška (Architekt metodik projektu), plk. Mgr. Jiří Němec (Vedoucí řešitelského týmu HZS ČR), plk. JUDr. Milan Zapletal (Vedoucí řešitelského týmu PČR), Patrik Merhaut (Vedoucí řešitelského týmu ZZS), Ing. Václav Kalenda (Vedoucí realizačního týmu), Miroslav Janda (IQUAPČR) plk. Ing. Petr Skřivánek, plk. Ing. Miroslav Blažek, kpt. Ing. Jan Urbánek, plk. Ing. Vladislav Ulrych, plk. Ing. Šárka Veselá, pplk. Ing. Zdeněk Červenka, mjr. Bc. František Špaček, plk. Ing. Miloslav Soukup, mjr. Ing. Radek Mencl, mjr. Ing. Petr Luciak, plk. Ing. Petr Majer, plk. Ing. Petr Berglowiec, kpt. Bc. Jan Forman, plk. Ing. Jiří Vojtíšek Miroslav Wolf, Ing. Vlastimil Křížek, Ing. Iva Urbancová, Ing. Martin Němeček, Ing. Jindřich Vintr, Miroslav Lares, Ivo Božek, Martin Repko, Aleš Kroupa npor. Hana Vrabcová, plk. Mgr. Karel Pospíšil, Jiří Stiglitz, por. Bc. Richard Máca, kpt. Bc. Zdenka Durajova, por. Bc. Robert Korsa, ktp. Bc. Jiří Martínek, plk. JUDr. Květuše Kondrysová, plk. Bc. Michal Kolečko, por. Ivo Hasalík, JUDr. Karel Hartl BPS Business Process Services s.r.o. Odpovědní specialisté Ing. František Marek, CSc. (procesy), Ing. Ján Satin (ICT), Ing. Jan Honek (QA) Za zpracovatele schválil Za zadavatele akceptoval Ing. Václav Kalenda, vedoucí realizačního týmu, BPS Business Process Services s.r.o. Akceptační komise odběratele ve složení: MZ ČR Ing. Iva Urbancová ŘT ZZS Patrik Merhaut ŘT PČR plk. JUDr. Milan Zapletal ŘT HZS plk. Mgr. Jiří Němec Věcný gestor plk. Ing. Luděk Prudil Metodik projektu pplk. Mgr. Jaroslav Lepeška Projektový manažer Bc. Jiří Lazar Žižka schvaluje bez výhrad. strana 3 (celkem 99 stran)

I. Cíle projektu Tato kapitola definuje výchozí a cílový stav pomocí cílů a jejich ukazatelů. Cíle ve finanční perspektivě zaručují dlouhodobou udržitelnost projektu přes masivní investici do nových technologií nedojde ke zvýšení budoucích provozních nákladů. Podaří se to díky lepší organizaci práce, nasazením vhodných (na údržbu nenáročných) technologií a využitím již vybudované komunikační infrastruktury pro eliminaci nákladů plynoucích z vyšších datových přenosů. Hlavním přínosem tohoto projektu pro zákazníka občana je snížení následků mimořádných událostí v případě společných akcí více složek IZS díky rychlejším a provázanějším zásahům. Ty umožňuje plně dostupné tísňové volání, přesnější určení místa mimořádné události, okamžité zahájení činnosti potřebných složek a rychlejší přeprava na místo. Předpokladem je jednotná technologie tísňového volání a GIS, všestranný tok operačních dat včetně možnosti vizualizace společné operační situace a podpora pro široké využívání navigačních systémů. strana 4 (celkem 99 stran)

Složka Rozpočtová omezení Veřejný zájem Procesy Infrastruktura Analýza technického řešení projektu Hodnocené období Jako referenční výchozí období byl pro projekt zvolen rok 2008 (AS-IS). Jako rok, kdy budou dosaženy cílové hodnoty indikátorů, byl zvolen rok 2013 (TO-BE). Pohled Kauzalita cílů Kauzální model cílů definuje cíle projektu a jejich nejdůležitější vzájemné ovlivnění 1. Model 1: Kauzální model cílů (BSC) Standardy Národní standard operačních středisek IZS Finance Nezvýšit provozní náklady IZS Zlepšit poskytování pomoci občanům při MU Zákazník Zvýšit účinnost operačního řízení Procesy Zvýšit účinnost tísňového volání Zvýšit přesnost lokalizace MU Zrychlit zahájení činnosti všech nezbytných základních složek IZS Zkrátit čas přepravy SaP na místo MU Zajistit využití ITS MV všemi složkami IZS Zajistit jednotnou technologii pro příjem tísňového volání Zajistit jednotný GIS Zajistit všestranný tok operačních dat Vytvořit podmínky pro nasazení navigačních systémů Zajistit sdílení vizualizace operační situace Zdroje Klíčovým cílem projektu je cíl ze zákaznické perspektivy, který naplňuje smysl projektu Zlepšit poskytování pomoci občanům při MU. Aby tento cíl sledující veřejný zájem byl dlouhodobě udržitelný, musí být současně splněn cíl ve finanční perspektivě Nezvýšit provozní náklady IZS tedy aby realizace projektu respektovala budoucí rozpočtová omezení. Zlepšení pomoci občanům při MU je podmíněno zvýšením účinnosti dvou klíčových procesů tísňového volání a operačního řízení. Zlepšení procesu tísňového volání deklaruje cíl Zvýšit účinnost tísňového volání. Výsledná účinnost procesu operačního řízení je měřena cílem Zvýšit účinnost operačního řízení. Tento cíl je opřen o zlepšení tísňového volání a další tři cíle, které jsou zaměřeny na přesnost určení místa MU cíl Zvýšit přesnost lokalizace MU, 1 V modelu jsou vyznačeny pouze nejdůležitější vzájemné vazby. Vzájemné ovlivnění dosažení cílů je však daleko širší (např. cíl Zajistit jednotná GIS data ovlivňuje nejen cíl Zvýšit přesnost lokalizace MU, ale částečně podmiňuje i dosažení cíle Zkrátit čas přepravy SaP na místo MU). strana 5 (celkem 99 stran)

na schopnost co nejdříve zahájit společnou činnost všech nezbytných složek IZS cíl Zrychlit zahájení činnosti všech nezbytných složek IZS a na tom, aby potřebné složky byly včas na místě MU cíl Zkrátit čas přepravy SaP na místo MU. Procesní cíle se opírají o technologickou infrastrukturu, která jejich splnění podmiňuje. Zkvalitnění tísňového volání je primárně podmíněno cílem Zajistit jednotnou technologii pro příjem tísňového volání. Kvalitnější lokalizace se opírá o kvalitnější a společný GIS, jak stanovuje cíl Zajistit jednotný GIS. Možnost neprodleného zahájení činnosti všech potřebných složek IZS je podmíněna cílem Zajistit všestranný tok operačních dat. Zkrácení přepravy SaP na místo MU vychází z cíle Vytvořit standardy pro nasazení navigačních systémů. A účinnost celého operačního řízení ovlivňuje cíl Zajistit sdílení vizualizace operační situace. Dlouhodobá udržitelnost projektu je ovšem podmíněna tím, aby nové IS služby, které jsou náročné na přenos dat, nezvýšily náklady na nakupované telekomunikační služby. To naplňuje cíl Zajistit využití ITS MV všemi složkami IZS, který zajistí, aby datově náročné přenosy byly vedeny především po již vybudované komunikační infrastruktuře ITS MV. Interpretace modelu Projektem vytváříme jednotnou úroveň informačních systémů operačního řízení a modernizujeme technologie pro příjem tísňového volání základních složek integrovaného záchranného systému. Základním cílem tohoto projektu je prokazatelné snížení následků MU méně mrtvých, zraněných, menší škody na majetku a vyšší uchráněná hodnota při těchto událostech, a to tam, kde při MU zasahuje současně více složek IZS. Typickými příklady takových zásahů jsou např. požáry a dopravní nehody. Závažnost následků MU je nepřímo úměrná času od jejího vzniku do zahájení zásahu potřebné složky IZS. Občan účastník nebo svědek MU především potřebuje možnost o této události informovat a jeho informace musí být kvalitně vytěžena. Na stranu druhou je nutné, aby všechny potřebné složky IZS zahájily svou činnost neprodleně a při vlastním zásahu postupovaly v součinnosti. A to vše musí být zajištěno tak, aby nevzrostly budoucí nároky na státní rozpočet. Obr. 1: Logika cílů přínosy Menší následky MU jak se dozvědět Rychlejší a provázanější zásah jak zrychlit Vazba na ISKŘ jak integrovat Dostupné tísňové volání Přesnější určení místa MU Okamžité zahájení činnosti všech potřebných složek Rychlejší přeprava na místo MU Koordinovaná činnost všech složek na místě MU o co technologicky opřít Jednotná technologie pro příjem tísňového volání Jednotný GIS Všestranný tok operačních dat Využití navigačních systémů Vizualizace operační situace negativní dopady Využít existující infrastrukturu Vyšší nároky na datové přenosy Lépe organizovat jak je eliminovat Nároky na údržbu a obnovu nových technologií Využít vhodné na údržbu nenákladné technologie Efektivně využít externích služeb dlouhodobá udržitelnost strana 6 (celkem 99 stran)

Specifikace cílů Cíle v perspektivě Finance (rozpočtová omezení) Tabulka 1: Cíle a ukazatele ve finanční perspektivě Finance Název Váha Typ Jednotka měření Žádoucí trend Složka IZS Hodnota AS-IS Hodnota TO-BE Cíl 01 Nezvýšit provozní náklady IZS HZS 588 588 KPI 011 Počet pracovníků operačního řízení 0,3 Předstižný počet udržet PČR 1022 1022 ZZS 434 408 HZS 27 19 KPI 012 Počet operačních středisek 0,3 Předstižný počet snížit PČR 86 15 ZZS 35 22 KPI 013 Náklady na údržbu a obnovu ICT 0,1 Výsledkový mil. Kč udržet HZS 12 12 HZS 164 164 KPI 014 Náklady na externí služby 0,1 Výsledkový mil. Kč udržet PČR 610 610 ZZS 410 390 KPI 015 Náklady na telekomunikační služby 0,2 Výsledkový mil. Kč snížit HZS 5,4 2,0 ZZS 97 65 Cíl 01: Nezvýšit provozní náklady IZS Realizací projektu zavedením národního standardu operačních středisek IZS nesmí dojít ke zvýšení provozních nákladů jednotlivých složek. Aplikací nových technologií nesmí dojít ani ke zvýšení nákladů na údržbu a obnovu zařízení ani na nákup služeb. To je podmínkou udržitelnosti projektu. Kritické budoucí provozní náklady jsou generovány potřebným počtem pracovníků operačního řízení (mzdové náklady), počtem operačních středisek (režijní náklady) a dále náklady na údržbu a obnovu ICT, na externí služby a na telekomunikační služby. Finanční ukazatele KPI013, KPI014 a KPI015 jsou výsledkové mají přímý dopad na udržitelnost projektu. Ukazatele o počtech pracovníků KPI011 a počtech OS KPI012 jsou pro finanční ukazatele předstižné. strana 7 (celkem 99 stran)

Cíle v perspektivě Zákazník (veřejný zájem) Tabulka 2: Cíle a ukazatele v perspektivě veřejný zájem Zákazník Název Váha Typ Jednotka měření Žádoucí trend Složka IZS Hodnota AS-IS Hodnota TO-BE Cíl 02 Zlepšit poskytování pomoci občanům při MU KPI 021 Uchráněná hodnota při požárech 0,1 Výsledkový mil. Kč zvýšit všechny 13 510 14 483 KPI 022 Mrtví při požárech 0,3 Výsledkový počet snížit všechny 127 122 KPI 023 Zranění při požárech 0,1 Výsledkový počet snížit všechny 850 827 KPI 024 Mrtví při dopravních nehodách 0,4 Výsledkový počet snížit všechny 748 693 KPI 025 Zranění při dopravních nehodách 0,1 Výsledkový počet snížit všechny 13 289 13 105 Cíl 02: Zlepšit poskytování pomoci občanům při MU Primární cílovou skupinou projektu jsou občané ČR a cizinci pobývající na území ČR, kteří byli postiženi MU. Realizací projektu dojde zlepšením spolupráce složek IZS ke zkrácení reakčního času pro poskytnutí pomoci občanům při společných zásazích složek IZS a tím ke snížení následků těchto MU. Měřitelně dojde ke snížení následků u dvou typových společných zásahů složek IZS u požárů a dopravních nehod. Ty dnes z hlediska počtu tvoří 98% všech společných zásahů a téměř stejný podíl mají i z hlediska následků 2. Graf uvádí dvě nejtypičtější události, kdy je nejčastější spolupráce složek IZS požár a dopravní nehoda. I u ostatních společných zásahů dojde k významnému zlepšení, které však není možné s ohledem na různorodost zásahů typizovat. Přímá vazba mezi zkrácením reakčního času a snížením následků je u požárů následující 3 : Obr. 2: Vazba mezi zkrácením reakčního času a snížením následků u požárů 4 20% 19% 18% 17% 16% 15% 14% 13% 12% 11% 10% 9% 8% 7% 6% Počet úmrtí Počet zranění Zachráněno osob Uchráněný majetek 5% 4% 3% 2% 1% 0% 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 minut 2 Podrobněji data viz HZS ČR Statistické sledování událostí. 3 Rozbor uveden v samostatném dokumentu Závislost následků požárů na čase dojezdu jednotek PO (podkladový materiál k Usnesení vlády č. 4 k plošnému rozmístění SaP jednotek PO). 4 Modře podbarvená je oblast ideální rychlosti zásahu s ohledem na minimalizaci následků mimořádné události. strana 8 (celkem 99 stran)

Vazba mezi zkrácením reakčního času a snížením následků je u dopravních nehod následující 5 : Obr. 3: Vazba mezi zkrácením reakčního času a snížením následků u dopravních nehod 100% 95% 90% 85% 80% 75% 70% 65% 60% 55% 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% Pra vd 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 minut Uvedené ukazatele zobrazují pouze přímo měřitelné, tedy metodicky podložené ukazatele. Faktické přínosy jsou výrazně vyšší z hlediska celospolečenských dopadů (např. uchráněné životy při jiných druzích událostí, uchráněné životní prostředí). Pro KPI024 a KPI025 (mrtví a zranění při dopravních nehodách) byly použity statistiky HZS. Týkají se výhradně společných akcí složek IZS a nezahrnují statistické údaje PČR, která eviduje jako smrtelný následek i úmrtí do 24 hodin. Tyto údaje jsou z oblasti cca 20 000 nejvážnějších nehod, u kterých zasahuje HZS. Všechny ukazatele jsou výsledkové mají přímý dopad na primární cílovou skupinu. 5 Podle statistického sledování. Závislost mortality na rychlosti zásahu viz např. studie The relationship between distance to hospitál and patient mortality in emergencies, Emerg. Med. J., vol. 24/2007. strana 9 (celkem 99 stran)

Cíle v perspektivě Procesy Tabulka 3: Cíle a ukazatele v perspektivě procesy Procesy Název Váha Typ Jednotka měření Žádoucí trend Složka IZS Hodnota AS-IS Hodnota TO-BE Cíl 03 Zvýšit účinnost operačního řízení KPI 031 Průměrná reakční doba při společných zásazích 1,0 Předstižný minuty snížit všechny 13,48 10,50 26.4.2015 Cíl 04 Snížení průměrné doby reakce na hrozící či nastalé bezpečnostní riziko Zvýšit účinnost tísňového volání Metrika % dosáhnout všechny 0% 22% KPI 041 Rychlost sestavení telefonického hovoru 0,2 Předstižný čas snížit všechny 0:00:03 0:00:01 KPI 042 Podíl odrazených hovorů 0,2 Předstižný % snížit všechny 0,060% 0,002% HZS 2 102 KPI 043 Max. počet souběžně odbavovaných hovorů 0,4 Předstižný počet zvýšit PČR 2 64 ZZS 2 62 KPI 044 Systémová možnost příjmu tísňového volání v cizích jazycích 0,2 Předstižný ano/ne vytvořit PČR NE ANO ZZS NE ANO Cíl 05 Zvýšit přesnost lokalizace MU Dostupnost lokalizace tísňově volajícího z mobilních sítí pro KPI 051 1,0 jednotlivá operační střediska IZS Cíl 06 Zrychlit zahájení činnosti všech nezbytných základních složek IZS Předstižný Cíl 03: Zvýšit účinnost operačního řízení Účinnost operačního řízení při společných zásazích je dána jak kvalitní technologií pro příjem tísňového volání, která umožní občanu se rychle a úspěšně dovolat a složkám IZS zahájit společný zásah neprodleně, tak kvalitní informační podporou operačního řízení nasazením moderních technologií, které umožní sdílení operačních dat v reálném čase. Tím dojde k eliminaci dnešních prodlev a celkovému zkrácení zahájení společného zásahu. Použitý ukazatel je předstižný a použitá metrika je tímto ukazatelem generována podle vzorce: PČR NE ANO ZZS NE ANO KPI 061 Čas do zahájení činnosti všech nezbytných složek IZS 1,0 Předstižný čas snížit všechny 0:02:33 0:00:03 = (průměrná reakční doba AS-IS - průměrná reakční doba TO-BE) / průměrná reakční doba AS-IS * 100 (%) Indikátor projektu váže na podporovanou aktivitu (6.3.4.) 6 a)vybudování informačního systému operačních středisek IZS. ano/ne vytvořit 6 V systému Benefit nelze vybrat metriku26.04.15 a metriky nelze správně systémově provázat na podporovanou aktivitu. strana 10 (celkem 99 stran)

Vazba průměrné reakční doby na následky Vazbu ukazuje následující tabulka: Tabulka 4: Vazba průměrné reakční doby na následky MU Ukazatel Název Jednotka AS-IS TO-BE pravděpodobnost následek pravděpodobnost následek KPI 031 Průměrná reakční doba při společných zásazích minuty 13,48 10,50 KPI 021 Uchráněná hodnota při požárech mil. Kč 5,78% 13 510 6,20% 14 483 KPI 022 Mrtví při požárech počet 2,11% 127 2,03% 122 KPI 023 Zranění při požárech počet 15,98% 850 15,55% 827 KPI 024 Mrtví při dopravních nehodách počet 7,29% 748 6,75% 693 KPI 025 Zranění při dopravních nehodách počet 89,02% 13 289 87,79% 13 105 Snížený počet zraněných při dopravních nehodách v důsledku rychlejšího reakčního času složek IZS zahrnuje zabránění dalším zraněním v důsledku eskalace dopravní nehody. Vazba reakční doby na předstižné ukazatele Tabulka 5: Složení reakční doby při společných zásazích KPI Název Jednotka AS-IS TO-BE KPI 031 Průměrná reakční doba při společných zásazích minuty 13,48 10,50 KPI 041 Rychlost sestavení telefonického hovoru čas 0:00:03 0:00:01 KPI 061 Čas do zahájení činnosti všech nezbytných složek IZS čas 0:02:33 0:00:03 KPI 071 Čas dojezdu na místo určení (zkrácení) čas 0:10:53 0:10:26 Cíl 04: Zvýšit účinnost tísňového volání Účinnost tísňového volání je dána dostupnými kanály, kterými může občan složky IZS kontaktovat, dostupností GSM signálu a především rychlostí sestavení telefonického hovoru a schopností občana se na tísňovou linku dovolat jak za normální, tak za krizové situace. Z hlediska občanů jiných národností jde i o systémovou schopnost odbavit hovor v cizích jazycích (vyhledání volného operátora s příslušnou jazykovou vybaveností, možností vést konferenční hovor). Zásadní změnou je možnost využít k příjmu tísňového volání veškeré volné operátory bez jakéhokoliv regionálního omezení. Za odrazené hovory jsou považovány ty, kdy volající zavěsí v čekací frontě. Novou technologií bude eliminována celá čekací fronta, pokud budou volní operátoři. Příjem hovoru v cizích jazycích je dnes u PČR možný v určitých regionech, systémová možnost vytvoří podmínky pro příjem hovoru v cizím jazyce celorepublikově. Všechny použité ukazatele jsou předstižné. Cíl 05: Zvýšit přesnost lokalizace MU Využitím kvalitního GIS, lepších možností lokalizace místa MU a sdílením dat mezi složkami IZS dojde ke zpřesnění místa nasazení SaP. Tento cíl souvisí s plněním požadavků EU 7. Použitý ukazatel je předstižný. Cíl 06: Zrychlit zahájení činnosti všech nezbytných základních složek IZS Okamžitým sdílením dat o operační situaci dojde k eliminaci prodlevy do zahájení činnosti dalších nezbytných složek IZS. Použitý ukazatel je předstižný. 7 Např. povinnost lokalizace při tísňovém volání (čl. 26 směrnice 2002/22/ES). strana 11 (celkem 99 stran)

Cíl 07: Zkrátit čas přepravy SaP na místo MU Vizualizací pozice a pohybu vozidel, nasazením moderních navigačních systémů a jednotného GIS dojde ke snížení průměrných dojezdových časů SaP na místo MU. Podmínkou dosažení tohoto ukazatele je instalace koncových polohovacích a navigačních zařízení ve vozidlech SaP, která bude součástí separátních projektů. Použitý ukazatel je předstižný. strana 12 (celkem 99 stran)

Cíle v perspektivě Zdroje (ICT) Tabulka 6: Cíle a ukazatele v perspektivě zdroje Zdroje Název Váha Typ Jednotka měření Žádoucí trend Složka IZS Hodnota AS-IS Hodnota TO-BE Cíl 07 Zkrátit čas přepravy SaP na místo MU KPI 071 Čas dojezdu na místo určení 1,0 Předstižný čas snížit všechny 0:10:53 0:10:26 Cíl 08 Zajistit využití ITS MV všemi složkami IZS KPI 081 Komunikace mezi složkami IZS po ITS MV 1,0 Předstižný ano/ne vytvořit HZS NE ANO ZZS NE ANO Cíl 09 Zajistit jednotnou technologii pro příjem tísňového volání KPI 091 Aplikovaná jednotná technologická zařízení pro příjem TV 1,0 Předstižný počet zvýšit všechny 0 44 Cíl 10 Zajistit jednotný GIS KPI 101 Aplikovaný jednotný GIS 1,0 Předstižný počet zvýšit všechny 0 44 Cíl 11 Zajistit všestranný tok operačních dat KPI 111 Aplikovaná technologická zařízení pro sdílení operačních dat 1,0 Předstižný počet zvýšit všechny 0 44 Cíl 12 Vytvořit podmínky pro nasazení navigačních systémů KPI 121 Aplikovaná technologická zařízení pro navigační systémy 1,0 Předstižný počet zvýšit všechny 0 42 Cíl 13 Zajistit sdílení vizualizace operační situace KPI 131 Aplikovaná technologická zařízení pro vizualizaci operační situace 1,0 Předstižný počet zvýšit všechny 0 44 Cíl 08: Zajistit využití ITS MV všemi složkami IZS Sdílením operačních dat v reálném čase dojde ke značnému zvýšení nároků na přenosy dat. Tyto dodatečné nároky, které by následně zvyšovaly provozní náklady, budou eliminovány převedením vzájemné komunikace mezi složkami IZS na již vybudovanou infrastrukturu ITS MV 8. Využití ITS je přímo podpořeno 18 odst. 2 zákona č. 239/2000 Sb. o IZS. Použitý ukazatel je předstižný podmiňuje dosažení cíle ve finanční perspektivě. Cíl 09: Zajistit jednotnou technologii pro příjem tísňového volání Podle Usnesení vlády č. 923/2008 hlavní zásadou i nadále zůstává zachování stávajících národních čísel tísňového volání, aby je mohl občan využít zejména v případech požadavku řešení mimořádné události jednou ze složek IZS. Vybavení všech složek IZS jednotnou technologií pro příjem TV umožní hlasové i datové sdílení i předání identifikovaných údajů kooperující složce IZS. Takové informace nebude již nutné vytěžit z volajícího na operačním středisku složky příslušné IZS. Tato skutečnost zkrátí celkovou dobu tísňového volání a současně zvýší komfort volání pro oznamovatele. Zahrnuje 14 krajů vždy s pracovišti pro všechny základní složky IZS plus 2 celorepubliková centra (HZS, PČR). Samostatné celorepublikové centrum pro ZZS se neuvažuje, bude využito centra HZS. Použitý ukazatel je předstižný podmiňuje dosažení cíle v procesní perspektivě. Cíl 10: Zajistit jednotný GIS V současné době jednotlivé složky IZS využívají své proprietární GIS včetně nesourodých mapových podkladů. Kromě zvýšených pořizovacích a udržovacích nároků tato situace znemožňuje společnou lokalizaci událostí a sdílení operační situace v reálném čase. Jednotný GIS společný jak pro tísňové volání, tak pro podporu operačního řízení, umožní sdílená data vizualizovat. Použitý ukazatel je předstižný podmiňuje dosažení cíle v procesní perspektivě. Cíl 11: Zajistit všestranný tok operačních dat Dnešní tok operačních informací představuje předání základních dat o mimořádné události a další sdílení je omezeno jen na hlasovou komunikaci příslušných složek. Cílem je vybudovat sdílení jak identifikovaných událostí, které mohou mít význam pro ostatní složky IZS, tak trvale aktualizovaných dat o těchto událostech, pokud k nim byla součinnost již vyžádána. Použitý ukazatel je předstižný podmiňuje dosažení cíle v procesní perspektivě. 8 Účelová telekomunikační síť MV. strana 13 (celkem 99 stran)

Cíl 12: Vytvořit podmínky pro nasazení navigačních systémů Podmínky pro obousměrný tok lokalizačních dat mezi SaP a systémem operačního řízení musí být vytvořeny tímto centrálním projektem. Dále musí být zajištěny systémové podmínky pro využití navigačních systémů v koncových zařízení. Použitý ukazatel je předstižný podmiňuje dosažení cíle v procesní perspektivě. Cíl 13: Zajistit sdílení vizualizace operační situace Cílem je zajistit pro všechny zasahující složky společnou vizualizaci operační situace, která zahrnuje zobrazení místa události, kontaminovanou a uzavřenou oblast, místo velitelského stanoviště, aktuální pozice velitelů anebo vedoucích složek IZS, pozici SaP složek IZS - mobilní (např. hlídky pro uzavření komunikací), zvýraznění směrů dopravy (příjezd a odjezd složek IZS, dálková doprava vody) a účelový prostor. Použitý ukazatel je předstižný podmiňuje dosažení cíle v procesní perspektivě. Vazba cílů a ukazatelů projektu a standardů Cíle vymezují základní stav, kterého má být realizací projektu dosaženo a uvedené ukazatele zajišťují měřitelnost jeho dosažení. Chování budovaného systému zajišťují standardy, které zajišťující jednotnou úroveň služeb tísňového volání. Jsou specifikovány v kapitole Standardy. strana 14 (celkem 99 stran)

II. Procesní koncept Tato kapitola popisuje dosažené sjednocení cílových procesů u všech složek IZS, a to nejen v procesu Zajistit příjem tísňového volání, ale typově i v procesu Zajistit operační řízení. Byla dohodnuta klíčová pravidla pro obsluhu tísňových volání (příjem, přidělování operátorům, předávání hovorů mezi složkami IZS a do operačního řízení), pro vizualizaci sdílených událostí a vyžádání součinnosti a pro vizualizaci společné operační situace (co, kdy, komu). strana 15 (celkem 99 stran)

Cílový procesní koncept Oblast operačního řízení byla rozdělena do 2 samostatných procesů, které mají odlišný charakter, vyžadují různou formu zajištění i podporu ze strany ICT. Přesto jsou oba klíčové procesy vzájemně bezešvě provázány a využívají i jednotné organizační zdroje pro své personální zajištění. Následující model ukazuje jejich vzájemné propojení: Model 2: Procesy tísňového volání a operačního řízení IZS Standard Občan chce oznámit událost tísňovým voláním Úroveň: 0 Přehled procesů Zvolit linku a vytočit číslo tísňového volání Občan 112 150 155 158 Zajistit příjem tísňového volání Hovor nevyžadující vyslání SaP ukončen Zlomyslný hovor nespojen Volající přerušil hovor během spojování Hovor vytěžen a událost předána operačnímu řízení Hovor přepojen na operační řízení Událost pro/z jiného kraje / složky IZS vizualizována Součinnost vyžádána Jiné zdroje informací k dispozici Zajistit operační řízení Obyvatelstvo varováno Událost vyřešena Komunikace s kompetentními orgány ukončena strana 16 (celkem 99 stran)

Proces Zajistit příjem tísňového volání Model 3: Proces Zajistit příjem tísňového volání strana 17 (celkem 99 stran)

Model 4: Subproces Spojit hovor Automatická identifikace zahrnuje zjištění identifikačních i lokalizačních údajů. Plně automatizovaný subproces umožňuje volně definovat pravidla pro vyhledání volného operátora, zaručuje okamžité spojení, provádí automatickou lokalizaci a vizualizaci polohy a dává možnost pracovat se specifickými skupinami volajících podle definovaných pravidel. Současně je plně otevřen nasazení nových technologií pro analýzu a rozpoznání hlasu, kterou bude možné do budoucna využít jak pro přidělení jazykově vybaveného operátora, tak pro další specifickou práci s volajícím na úrovni speciálních složek PČR. strana 18 (celkem 99 stran)

Model 5: Subproces Zajistit jazykovou podporu Je třeba jazyková podpora Jazyk volajícího rozpoznán? Zajistit jazykovou podporu Úroveň: 2 Subproces Jazyk volajícího určen operátorem Automaticky identifikovat jazyk volajícího SYS Vyhledat operátora s příslušnou jazykovou kvalifikací SYS Operátor s příslušnou jazykovou kvalifikací není připojen Vytvořit konferenční hovor Vyhledat tlumočníka SYS SYS Hovor přepojen na jiného operátora Vytvořit konferenční hovor SYS Zavěsit SYS Jazyková podpora zajištěna Znalost systému operátorů se specifickou kvalifikací zároveň s možností definovat pravidla pro jejich vyhledávání a přidělování hovorů dává možnost využít tuto funkcionalitu i pro jiné specifické kvalifikace a spojení se specialistou. Pokud není v systému přihlášen žádný operátor s požadovanou kvalifikací, může být vytvořena konference s externím specialistou. strana 19 (celkem 99 stran)

Model 6: Subproces Předat hovor na jinou složku IZS Jde o specifický hovor výhradně pro jinou složku IZS Předat hovor na jinou složku IZS Úroveň: 2 Subproces Vyhledat operátora složky podle kraje volání a jazyka SYS Potvrdit vybraného operátora nebo změnit Operátor NSPTV Vytvořit konferenční hovor SYS Hovor přepojen Zavěsit SYS Hovor výhradně pro jinou složku IZS přepojen na NSPTV příslušné složky IZS Model 7: Subproces Zjistit základní informace o události Standardní průběh tísňového volání zajišťuje u událostí, které mají potenciál budoucího vyžádání součinnosti, jejich neprodlenou vizualizaci pro ostatní složky IZS. strana 20 (celkem 99 stran)

Obr. 4: Sdílení událostí během tísňového volání Událost vizualizovaná Viditelnost (znemožnění) Typ události Klasifikace události Mj. možnost bližší lokalizace události pomocí vyspělých GIS funkcí Stav události Číselník společný Stavy událostí TimeStamp společné číselníky s vazbou na číselníky jednotlivých složek Místo události Automatické identifikační a lokalizační údaje Závažnost události Číselník společný Závažnost události nová funkcionalita Klíčové je u příjmu tísňového volání předání výstupů do operačního řízení. Obr. 5: Vazba na operační řízení Je třeba vyžádat součinnost (jiného kraje, jiné složky) Jde o vícenásobnou událost Zpracovat informace pro součinnost Operátor NSPTV Sloučit událost SYS součinnost Vyžádat součinnost SYS Je třeba předat hovor k dalšímu dovytěžení operačnímu řízení? možnost seskupování u hromadných událostí (dílčí události zachovány) Součinnost vyžádána ano Událost pro součinnost Složka IZS Skutečnosti o události pro součinnost Zajistit operační řízení Zavěsit SYS Vytvořit konferenční hovor SYS Hovor přepojen Zavěsit Oznamovatel SYS Prvotní popis události Hovor vytěžen a událost předána operačnímu řízení Hovor přepojen na operační řízení a samozřejmě nahrávání hovorů, vyhledávání a přehrávání nahrávek Zajistit operační řízení možnost předání hovoru do operačního řízení Rekapitulace změn v příjmu tísňového volání Přínosy jednotné technologie NSPTV jsou především následující: strana 21 (celkem 99 stran)

Zkrácení času tísňového volání. Kvalitnější informace pro vytěžení informací určení místa události. Bezpečnější a spolehlivější technologie pro zajištění nepřetržité funkcionality. Zavedení automatické lokalizace polohy při tísňovém volání z mobilů (splnění požadavku EU, bude řešená lokalizace z VOIP). Kvalitní napojení na INFO 35 (lokalizace v pevných sítích). Zkrácení času pro předání údajů jiným složkám IZS. Lepší spolupráce s partnery v IZS. Snížení nákladů není třeba vyvíjet a udržovat separátně technologie pro příjem tísňového volání a pro lokalizaci polohy. Bude zajištěno společné (silné) vyjednávání s telefonními operátory, ČTU aj. Organizační zajištění NSPTV Složky HZS, PČR a část krajských ZZS již má nebo do budoucna počítá s vyčleněním pracovníků pouze na příjem tísňového volání operátorů. Shodné zkušenosti HZS a PČR, které tuto formu zajištění již déle používají, jsou výhradně pozitivní, protože zajišťují: kratší průměrnou délku tísňového hovoru výrazně kvalitnější vytěžení hovorů možnost specifické kvalifikace operátorů větší klid na vlastní operační řízení Možné negativní dopady tohoto způsobu zajištění nevytížení operátora TV a vyšší nároky na kapacity operačního řízení již při centralizaci na úrovni kraje nenastávají. Technicky toto organizační zajištění budovaný systém nutně nevyžaduje. Je však nutné, aby příslušný pracovník, který má (také) přijímat tísňová volání byl přihlášen do systému NSPTV a systém mu tak mohl podle definovaných pravidel přidělovat hovory. strana 22 (celkem 99 stran)

Proces Zajistit operační řízení Model 8: Proces Zajistit operační řízení strana 23 (celkem 99 stran)

Model 9: Subproces Monitorovat operační situaci Jiné zdroje informací k dispozici Monitorovat operační situaci - standard Úroveň: 2 Subproces Událost pro/z jiného kraje / složky IZS vizualizována Monitorovat bezpečnostní situaci Monitorovat Monitorovat Monitorovat stav SaP Dispečer OŘ Dispečer OŘ Dispečer OŘ ostatní zdroje Dispečer OŘ dopravní situaci a zdrojů informací a komunikova... Založit událost Dispečer OŘ Potvrdit převzetí události Dispečer OŘ Událost vyžaduje nasazení SaP strana 24 (celkem 99 stran)

Subproces Nasadit a řídit SaP Pouze tento subproces je po standardizaci ve variantách podle složek. Model 10: Subproces Nasadit a řídit SaP - varianta HZS strana 25 (celkem 99 stran)

Model 11: Subproces Nasadit a řídit SaP - varianta ZZS strana 26 (celkem 99 stran)

Model 12: Subproces Nasadit a řídit SaP - varianta PČR strana 27 (celkem 99 stran)

Model 13: Subproces Komunikovat s kompetentními orgány Model 14: Subproces Varovat obyvatelstvo (provádí pouze HZS) Je nutné varovat obyvatelstvo Varovat obyvatelstvo Úroveň: 2 Subproces Vyrozumět hejtmany a starosty Dispečer OŘ Zvolit území Dispečer OŘ Zajistit předání tísňové informace obyvatelstvu Dispečer OŘ Zvolit přijímače Dispečer OŘ Odvysílání zajištěno Zvolit typ poplachu Dispečer OŘ Všechny údaje vpořádku? ne, nutno opravit ano Provést varování Dispečer OŘ Obyvatelstvo varováno strana 28 (celkem 99 stran)

Rekapitulace změn v operačním řízení V procesu vlastního operačního řízení nastávají pouze dvě klíčové změny bezešvé vyžádání součinnosti a vizualizace společné operační situace. Současně je pro jednotlivé IS operačního řízení vytvářena možnost volat společné služby GIS. Obr. 6: Změny v operačním řízení vyžádání součinnosti bez časové prodlevy možnost využít služeb GIS vizualizace společné operační situace strana 29 (celkem 99 stran)

Účelový prostor Analýza technického řešení projektu Obr. 7: Vizualizace operační situace Operační situace vizualizovaná Místo události Příjem TV Operační úroveň Taktická úroveń Řešená událost nabyla příslušného rozsahu V pohledu V pohledu V pohledu Únik Společná operační situace - dopřesňuje dopřesňuje dopřesňuje Dopravní Událost s V pohledu V pohledu Požárem s nebezpečnýc vizualizace informací mezi KOPIS HZS ČR IOS PČR OPS ZZS ČR V pohledu nehoda s evakuací dopřesňuje dopřesňuje velkým h látek (z Povodně (dle Do pohledu (nebo (nebo (nebo dopřesňuje velkým velkého základními složkami IZS na úrovni velitel vedoucí lékař rozsahem objektu, z povodňové zanáší technologie technologie technologie velitel JPO počtem počtu operačního řízení opatření "VL" (ZZS 1000 a více vozidla) situace) GPS v případě GPS v případě GPS v případě "VZ" (HZS ČR) zranění (20 a obyvatel (nad "VO" (PČR) kraje) mxm ohrožení prohlášení prohlášení prohlášení více) 100) obyvatel vitelnosti) vitelnosti) vitelnosti) Kontaminovaná oblast Místo události Kontaminovaná oblast NSPTV - - - - - - NSPTV NSPTV NSPTV NSPTV NSPTV - A - v případě nemožnosti - - A - - - - A - - splnit úkol VZ Uzavřená oblast Pozice velitelského stanoviště Aktuální pozice VJ, VO, VL Pozice SaP složek IZS Dopravní situace Účelové prostory Číselník společný Typy SaP pro vizualizaci A - v případě A - v případě A - v případě nemožnosti nemožnosti Uzavřená oblast - nemožnosti A A - A A A A A úkol splnit úkol splnit splnit úkol VZ VO VL A - v případě A - v případě A - v případě A - v případě A - v případě A - v případě nemožnosti nemožnosti Místo velitelské stanoviště - nemožnosti že události že události že události A A A A A úkol splnit úkol splnit splnit úkol VZ velí velí velí VO VL A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS Aktuální pozice VS, VO, VL - - - - (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS SaP složek IZS - mobilní (např. - (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení hlídky pro uzavření komunikací) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) Zvýraznění směrů A - v případě dopravy,vstupních stanovišť do nemožnosti - - - - A - A A A A A oblasti a pevných stanovišť k úkol splnit uzavření oblasti (příjezd a odjezd VO - dekontaminační A - v případě stanoviště (osob a - nemožnosti - - A - - - - A - - splnit úkol VZ techniky) - shromaždiště A - v případě A - v případě A - v případě A - v případě - nemožnosti - - A - - - evakuace evakuace evakuace A evakuovaných osob splnit úkol VZ osob osob osob A - v případě - obvaziště - - - nemožnosti - - A A - - - - úkol splnit A - v případě A - v případě - místo pro oběti (exitus) - - - nemožnosti - - - A evakuace - - - úkol splnit osob A - GPS v - soustředěné SaP HZS ČR - mobilní - - - - - A A A A A technice A - GPS v A - GPS A - GPS A - GPS A - GPS A - GPS - soustředěné SaP PČR - - mobilní - - - - (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení technice viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) - soustředěné SaP ZZS A - GPS v - - - mobilní - - - A A A A A kraje technice Jiné další účelový prostot A - v případě A - v případě A - v případě - nemožnosti nemožnosti nemožnosti A A A A A A A A (dle potřeby) splnit úkol VZ úkol splnit úkol splnit strana 30 (celkem 99 stran)

Analýza technického řešení projektu Kvantifikace procesů Vstupní data a parametry simulace Kvantifikace procesů proběhla formou simulace na základě těchto vstupních dat: Obr. 8: Časové řezy dat pro simulaci zdrojová data Průměrný měsíc výběr dat simulace rozložení po hodinách průměry a maxima Minimální počet operátorů ve směnách (12/08) Extrémní měsíc Přelivy hovorů mezi kraji Kapacity vstupních linek a hlasových bran rozložení po hodinách absolutní maxima (03/08)-EMMA Kapacity operátorských pracovišť Na základě průměrných dat jsou na výstupu simulace zjišťovány tyto údaje: minimální počet operátorů v nejzatíženější směně, a to na úrovni kraje a složky přelivy hovorů, ke kterým může dojít při tomto minimálním obsazení počtu operátorů, a to jak mezi kraji v rámci složky IZS, tak případně mezi složkami Na základě extrémních dat, pro která bylo vybráno období s největším počtem tísňových hovorů za dobu, kdy jsou vedeny statistiky, byly simulačně navrženy: počty vstupních linek z JTS kapacity hlasových bran / vstupních PBX pro příjem tísňových volání počty operátorských pracovišť, které je možné v případě takové extrémní události obsadit Propady hovorů V systému dochází k významnému propadu hovorů při jejich příjmu a zpracování: Volání od operátora - počet hovorů identifikovaných operátorem Spojená volání - počet hovorů na bráně od JTS do NSPTV, kdy došlo k faktickému spojení Přijatá volání - počet hovorů spojených na operátora, kdy volající nezavěsil během vstupní hlásky Vytěžená volání - počet hovorů, kdy operátor vedl smysluplný hovor (odpadají předčasně ukončená zlomyslná volání) Vizualizované události - počet událostí, které budou vizualizovány ostatním složkám IZS Propady se výrazně u jednotlivých složek IZS liší: Tabulka 7: Absolutní propady tísňových hovorů (průměrný den) Propady PČR HZS ZZS Celkem Volání od operátora 10 742 12 048 9 227 32 017 Spojená volání 8 916 10 000 7 685 26 600 Přijatá volání 7 400 8 300 6 400 22 100 Vytěžená volání 5 994 2 158 5 312 13 464 599 638 425 1 663 Vizualizované události (společné) strana 31 (celkem 99 stran)

Pro simulaci byly tyto propady hovorů zohledněny pomocí pravidel s touto pravděpodobností pro jednotlivé složky IZS: Tabulka 8: Relativní propady tísňových hovorů (zadání simulace) Propady PČR HZS ZZS Volání od operátora 100% 100% 100% Spojená volání 83% 83% 83% Přijatá volání 85% 67% 85% Vytěžená volání 81% 26% 83% Vizualizované události (společné) 10% 30% 8% V simulaci byly propady hovorů aplikovány následovně: Model 15: Zjednodušený simulační model (příklad HZS) 112, 150 Zavěsit MAN1 SYS Linky MAIN1 99 Spojit hovor (operátor) SYS 0,17 Hovor nespojen (operátor) 0,83 Spojená volání 0 Spojit hovor MAIN1 0,33 SYS Hovor nespojen 0,67 Přijatá volání 0 Navázat kontakt s volajícím a přijmout prvotní informace Operátor HZS 0,74 Hovor nevytěžován 0,26 Vytěžovaná volání 0 Vytěžit hovor 1,00 Hovor ukončen 0,30 Událost vizualizována strana 32 (celkem 99 stran)

Analýza technického řešení projektu Propady hovorů mají tento dopad do stanovení cílových kapacit: Obr. 9: Vliv propadů hovorů na kapacitní simulaci kapacita vstupních linek Propady PČR HZS ZZS Volání od operátora 100% 100% 100% Spojená volání 83% 83% 83% Přijatá volání 85% 67% 85% Vytěžená volání 81% 26% 83% Vizualizované události 10% 30% 8% kapacita hlasové brány kapacita nahrávání a přepojování kapacita vytěžených hovorů kapacita vizualizovaných událostí Rozložení zátěže Bylo zjišťováno v několika dimenzích. Rozložení zátěže na jednotlivé kraje bylo zjišťováno podle dlouhodobého průměru volání a následně expertně korigováno s ohledem na zjištěné extrémy a současně podle počtu obyvatel kraje. Tabulka 9: Rozložení zátěže na kraje (denní průměry) Demografická data Přijaté hovory (za den) Jihočeský Obyvatel PČR HZS ZZS Podíl Průměr K počtu obyvatel Korekce Podíl Průměr K počtu obyvatel Korekce Podíl Průměr K počtu obyvatel Korekce Podíl 627 766 6,1% 495 403 500 7% 363 473 450 5% 212 336 350 5% 1 130 358 11,0% 589 725 700 9% 765 852 850 10% 532 605 650 10% Královehradecký 548 368 5,3% 198 352 400 5% 337 413 400 5% 231 293 300 5% Karlovarský 304 274 3,0% 305 195 350 5% 346 229 350 4% 254 163 250 4% Liberecký 429 031 4,2% 264 275 300 4% 338 323 350 4% 235 230 250 4% 1 250 769 12,2% 738 803 800 11% 1 200 942 1 200 14% 508 669 700 11% Olomoucký 639 161 6,2% 370 410 400 5% 433 482 450 5% 331 342 350 5% Pardubický 506 024 4,9% 252 325 300 4% 293 381 350 4% 280 271 300 5% Plzeňský 551 528 5,4% 394 354 400 5% 404 416 450 5% 305 295 350 5% Praha 1 181 610 11,5% 1 200 758 1 200 16% 787 890 900 11% 964 632 1 000 16% Středočeský Jihomoravský Moravskoslezský 1 158 108 11,3% 549 743 750 10% 905 873 900 11% 719 620 750 12% Ústecký 823 173 8,0% 649 528 650 9% 995 620 900 11% 395 440 450 7% Vysočina 510 767 5,0% 183 328 300 4% 259 385 350 4% 302 273 350 5% Zlínský 590 142 5,8% 392 379 400 5% 299 445 400 5% 216 316 350 5% Celkem 10 251 079 strana 33 (celkem 99 stran) 6 578 7 450 7 723 8 300 5 484 6 400

Rozložení zátěže během dne po hodinách, bylo opět zjišťováno podle dlouhodobých průměrů s vyloučením extrémů: Tabulka 10: Rozložení zátěže po hodinách Hodina PČR HZS ZZS 0 187 85 104 600 1 150 63 102 2 125 49 77 3 112 46 75 4 87 49 78 5 100 71 81 6 137 147 174 7 231 198 221 8 318 379 267 9 337 441 290 10 362 474 296 11 362 491 299 12 380 519 305 13 387 536 318 14 405 540 319 15 412 539 325 16 405 554 340 17 387 555 339 18 380 532 338 19 324 483 334 20 287 383 277 21 249 294 207 22 243 181 174 23 212 114 144 Pro simulaci bylo vypočteno toto hodinové rozložení zátěže: Tabulka 11: Rozložení zátěže po hodinách (zadání simulace) 500 400 300 200 100 Hodina PČR HZS ZZS 0 3% 1% 2% 1 2% 1% 2% 2 2% 1% 1% 3 2% 1% 1% 4 1% 1% 1% 5 2% 1% 1% 6 2% 2% 3% 7 4% 3% 4% 8 5% 5% 5% 9 5% 6% 5% 10 5% 6% 5% 11 5% 6% 5% 12 6% 7% 6% 13 6% 7% 6% 14 6% 7% 6% 15 6% 7% 6% 16 6% 7% 6% 17 6% 7% 6% 18 6% 7% 6% 19 5% 6% 6% 20 4% 5% 5% 21 4% 4% 4% 22 4% 2% 3% 23 3% 1% 3% 0 PČR HZS ZZS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 strana 34 (celkem 99 stran)

Extrémní zátěž byla zjišťována podle nejzatíženějšího dne během vichřice EMMA, a to jak z hlediska rozložení po krajích, tak v rámci nejvíce postiženého kraje a dále v nejzatíženější hodiny vše u složky s nejvyšším dopadem (HZS): Tabulka 12: Extrémní zatížení - kraje Den Běžná Mimořádná Navýšení Jihočeský 363 1 099 303% Jihomoravský 765 1 722 225% Královehradecký 337 707 210% Karlovarský 346 902 261% Liberecký 338 618 183% Moravskoslezský 1 200 1 606 134% Olomoucký 433 695 161% Pardubický 293 1 030 351% Plzeňský 404 969 240% Praha 787 1 073 136% Středočeský 905 2 277 252% Ústecký 995 1 594 160% Vysočina 259 877 339% Zlínský 299 480 161% Celkem 7 723 15 649 203% Tabulka 13: Extrémní zatížení - po hodinách Hodina Běžná Mimořádná Navýšení 0 85 121 142% 1 63 103 163% 2 49 83 171% 3 46 111 240% 4 49 81 166% 5 71 62 87% 6 147 128 87% 7 198 268 135% 8 379 506 134% 9 441 1 130 256% 10 474 1 630 344% 11 491 1 750 356% 12 519 1 469 283% 13 536 1 280 239% 14 540 1 001 185% 15 539 945 175% 16 554 869 157% 17 555 840 151% 18 532 870 164% 19 483 817 169% 20 383 686 179% 21 294 414 141% 22 181 309 170% 23 114 176 154% strana 35 (celkem 99 stran)

Tabulka 14: extrémní zatížení - nejvíce zatížený kraj po hodinách Pardubický Běžná Mimořádná Navýšení 0 9 3 34% 1 4 2 45% 2 2 5 213% 3 2 6 387% 4 2 8 374% 5 3 5 167% 6 9 8 90% 7 14 10 72% 8 20 9 44% 9 26 24 91% 10 25 236 940% 11 18 207 1148% 12 24 91 384% 13 24 50 209% 14 24 58 242% 15 22 36 167% 16 25 51 203% 17 21 39 183% 18 23 42 185% 19 18 82 456% 20 14 37 258% 21 14 13 91% 22 8 10 123% 23 6 12 216% Při extrémní události byla zjištěna celkově dvojnásobná zátěž, na úrovni kraje až 3,5x, hodinová špička až 3,6x, nejvíce zatížený kraj při hodinové špičce až 12x. Pro simulaci extrémní zátěže byly proto zvoleny tyto hodnoty: HZS - celkově 4 x PČR a ZZS 1,5 x Dimenze operátorských pracovišť a vstupních linek musí odpovídat: až 53 000 přijatých hovorů za den až 3 450 přijatých hovorů za hodinu Tabulka 15: Extrémní zátěž (zadání pro simulaci) Den PČR HZS ZZS Celkem Standard 7 400 8 300 6 400 22 100 Extrém 11 100 33 200 9 600 53 900 Hodina PČR HZS ZZS Celkem Standard 412 555 340 1 307 Extrém 618 2 220 510 3 348 Délka hovoru u všech složek pro přijatá, ale nevytěžená volání, byla zjištěna shodná, a to: strana 36 (celkem 99 stran)

střední hodnota 6,5 max. hodnota 15 min. hodnota 4 Délka vytěženého hovoru se pro jednotlivé složky významně liší. Pro simulaci proto byla zvolena data odpovídající skutečným délkám hovorů bez extrémů: Tabulka 16: Délka vytěženého hovoru (zadání pro simulaci) Byly zvoleny tyto simulační metody: Délka (s) PČR HZS ZZS Průměrná 98,1 60,3 89,0 Maximální 109,8 76,6 236,9 Minimální 53,3 49,9 78,1 Erlang - pro technickou část (komunikační zatížení) Brillouin-Wigner - pro výskyty událostí (tísňových volání) v rámci hodiny a délky volání (na základě teorie poruch) Simulace extrémní situace Pro výchozí zadání byly zvoleny tyto kapacity operátorských pracovišť, jak je složky IZS navrhly: Tabulka 17: Kapacity operátorských pracovišť (vstupní zadání simulace) Kraj PČR HZS ZZS Praha 12 15 8 Středočeský kraj 6 9 12 Jihočeský kraj 4 6 10 Plzeňský kraj 4 6 8 Karlovarský kraj 3 6 8 Ústecký kraj 4 6 7 Liberecký kraj 3 6 8 Královehradecký kraj 3 6 6 Pardubický kraj 3 6 6 Kraj Vysočina 3 6 9 Jihomoravský kraj 6 9 12 Zlínský kraj 3 6 6 Olomoucký kraj 4 6 6 Moravskoslezský kraj 6 9 10 Složka IZS celkem 64 102 116 Byla zvolena extrémní situace, kdy příjem bude probíhat pouze přes jediný vstupní bod omezený počtem 270 vstupních linek. strana 37 (celkem 99 stran)

Simulace probíhala v tomto modelu: Model 16: Simulace extrémní situace celková - výchozí zadání 2 219 112, 150 EMMA 618 158 mimořádné 510 155 mimořádné Spojit hovor (JTS) Vstupní linky SYS 389 3 347 Spojit hovor SYS 2 770 1 056 935 779 0000:05:05:35 HZS Navázat kontakt s volajícím a přijmout prvotn... Operátorské pracoviště HZS 102 0000:05:27:09 PČR Navázat kontakt s volajícím a přijmout prvotn... Operátorské pracoviště PČR 64 0000:04:37:55 ZZS Navázat kontakt s volajícím a přijmout prvotn... Operátor ZZS směna 116 710 781 661 HZS Vytěžit hovor PČR Vytěžit hovor ZZS Vytěžit hovor 169 617 550 1 046 Hovor ukončen 148 Událost pro vizualizaci 1 488 Hovor ukončen 148 Událost pro vizualizaci 764 Hovor ukončen 148 Událost pro vizualizaci Zavěsit MAIN Vstupní linky Vizualizovat událost SYS SYS 389 3 294 Hovor zavěšen Výsledky simulace Podrobné výsledky simulace jsou vzhledem k rozsahu uloženy v projektové knihovně. Z hlediska počtu vstupních linek byla situace kritická došlo ke zpoždění více než 90% volání s čekací dobou ve frontě až 9 minut. Naopak na základě nastavených kapacit byl zjištěn výrazný přebytek kapacit i na úrovni operátorských pracovišť (výrazný zejména u ZZS). Tabulka 18: Výsledky simulace extrémní situace celková - výchozí zadání - vytížení kapacit Zdroj Zpracované funkce Celková doba zpracování Stupeň vytížení Operátorské pracoviště HZS 1 531 112 669 30% Operátorské pracoviště PČR 811 78 878 34% Operátorské pracoviště ZZS 609 57 572 14% Proto bylo po jednotlivých složkách zkoumáno, jakou kapacitu je nutno vytvořit, aby ke vzniku prodlev na vstupu nedocházelo resp. aby max. délka čekání na vstupu činila 30 s. strana 38 (celkem 99 stran)

Optimální kapacita operátorských pracovišť pro HZS činí 56 pracovišť. Při této kapacitě již nedochází k delší dynamické prodlevě na vstupu než 30 s (s pravděpodobností vyšší než 0,045106%): Obr. 10: Podíl přijatých hovorů a délka čekání - extrémní situace HZS (56 pracovišť) Délka čekání (s) Podíl přijatých hovorů Počet přijatých hovorů 0 91,73% 1164 1 91,96% 1167 2 92,67% 1176 3 92,99% 1180 4 93,38% 1185 5 94,17% 1195 6 94,56% 1200 7 94,80% 1203 8 95,19% 1208 9 95,90% 1217 10 96,22% 1221 11 96,45% 1224 12 97,01% 1231 13 97,56% 1238 14 97,95% 1243 15 98,27% 1247 16 98,58% 1251 18 98,82% 1254 19 99,05% 1257 20 99,29% 1260 22 99,37% 1261 23 99,45% 1262 24 99,61% 1264 25 99,68% 1265 26 99,84% 1267 27 99,92% 1268 28 100,00% 1269 Optimální kapacita operátorských pracovišť pro PČR činí 28 pracovišť. Při této kapacitě již nedochází k častější dynamické prodlevě na vstupu delší než 30 s (s pravděpodobností vyšší než 0,688%): Obr. 11: Podíl přijatých hovorů a délka čekání - extrémní situace PČR (28 pracovišť) Délka čekání (s) Podíl přijatých hovorů Počet přijatých hovorů 0 71,79% 313 1 73,39% 320 2 74,08% 323 3 76,15% 332 4 76,83% 335 5 79,13% 345 6 80,50% 351 7 81,88% 357 8 83,49% 364 9 84,86% 370 10 86,70% 378 11 87,16% 380 12 89,22% 389 13 89,91% 392 14 90,37% 394 15 91,74% 400 16 93,58% 408 17 94,27% 411 18 94,72% 413 19 94,95% 414 20 95,64% 417 21 96,33% 420 22 97,25% 424 23 97,48% 425 24 97,94% 427 25 98,39% 429 27 98,85% 431 28 99,08% 432 31 99,31% 433 34 99,77% 435 35 100,00% 436 100,00% 99,00% 98,00% 97,00% 96,00% 95,00% 94,00% 93,00% 92,00% 91,00% 100,00% 95,00% 90,00% 85,00% 80,00% 75,00% 70,00% 0 5 10 15 20 25 30 délka čekání (s) 0 10 20 30 40 délka čekání (s) Optimální kapacita operátorských pracovišť pro ZZS činí 28 pracovišť. Při této kapacitě již nedochází k častější dynamické prodlevě na vstupu delší než 30 s (s pravděpodobností vyšší než 0,600601%): Obr. 12: Podíl přijatých hovorů a délka čekání - extrémní situace ZZS (28 pracovišť) strana 39 (celkem 99 stran)

Délka čekání (s) Podíl přijatých hovorů Počet přijatých hovorů 0 85,89% 286 1 87,09% 290 2 87,99% 293 3 88,29% 294 4 90,09% 300 5 90,69% 302 6 92,19% 307 7 93,99% 313 8 94,29% 314 9 94,89% 316 12 95,20% 317 13 96,10% 320 14 96,40% 321 15 97,60% 325 18 97,90% 326 20 98,50% 328 23 99,10% 330 28 99,40% 331 33 100,00% 333 99,00% 97,00% 95,00% 93,00% 91,00% 89,00% 87,00% 85,00% 0 5 10 15 20 25 30 35 délka čekání (s) Při umožnění přelivu mezi složkami v extrémní situaci postačí obsadit dokonce pouze 104 pracovišť (celkový nutný počet bez přelivů mezi složkami IZS by činil 111 pracovišť). Limity pro extrémní situace Proto byla zkoumána situace, kterou by byl schopen zvládnout navržený počet pracovišť s výjimkou evidentně předimenzovaných pracovišť pro ZZS, jejich počet byl redukován tak, aby byla stejně zatížena jako pracoviště HZS a PČR. Tabulka 19: Výsledky simulace - počet pracovišť 9 (standard = Optimálně) Kraj PČR HZS ZZS Navrženo Optimálně Minimálně Navrženo Optimálně Minimálně Navrženo Optimálně Minimálně Jihočeský kraj 4 4 2 6 6 3 10 3 2 Jihomoravský kraj 6 6 2 9 10 6 12 6 3 Karlovarský kraj 3 3 1 6 4 2 8 3 1 Královehradecký kraj 3 3 2 6 5 3 6 3 2 Liberecký kraj 3 3 1 6 4 2 8 3 1 Moravskoslezský kraj 6 7 3 9 15 8 10 7 3 Olomoucký kraj 4 3 2 6 6 3 6 3 2 Pardubický kraj 3 3 1 6 4 2 6 3 1 Plzeňský kraj 4 3 2 6 6 3 8 3 2 Praha 12 11 4 15 11 6 8 10 4 Středočeský kraj 6 6 3 9 11 6 12 8 3 Ústecký kraj 4 6 2 6 11 6 7 5 2 Vysočina 3 3 1 6 4 2 9 4 1 Zlínský kraj 3 3 2 6 5 3 6 3 1 Složka IZS celkem 64 64 28 102 102 55 116 64 28 9 Sloupec Navrženo počty pracovišť navržených původně složkou IZS. Sloupec Optimálně počet pracovišť, které budou zřízeny v rámci projektu. Počty pracovišť v jednotlivých krajích jsou navrženy s ohledem na minimalizaci přelivů. HZS a PČR mohou počty pracovišť v krajích upravit při zachování celkového počtu zřizovaných pracovišť s ohledem na další provozní potřeby. Sloupec Minimálně nezbytný počet pracovišť pro zajištění funkcionality bez jakýchkoliv omezení přelivů. Červeně jsou podbarveny buňky v krajích, kde navržený počet pracovišť je podle výsledků simulace nižší, než je vhodné. Modře naopak kraje, kde je navržen počet vyšší. Pokud nebude počet pracovišť v krajích optimalizován podle výsledků simulace, lze předpokládat, že bude docházet k vyšším přelivům v rámci sousedních krajů (simulace byla optimalizována na přelivy do 1%). strana 40 (celkem 99 stran)

Jednotlivé složky budou moci nad rámec NSPTV pracovišť zřizovat další operátorská pracoviště, a to z rozpočtu jednotlivých typových projektů. Celkový max. počet připojených operátorských pracovišť činí 300 při zachování stanovených odezev. Celkově je při výše uvedeném počtu pracovišť systém připraven na tento rozsah extrémních situací: Tabulka 20: Přípustné zatížení systému (hodinově) Aktivita Celkově je systém schopen řádně přijmout 7 327 hovorů za hodinu a spojit na operátora celkem 4 409 hovorů, z toho pouze 1,7% s prodlevou do 30 s (pravděpodobnost prodlevy vyšší než 30 s je menší než 0,009072%), což představuje 1,3 násobek zatížení, ke kterému došlo v případě vichřice EMMA. Při tomto zatížení dochází stále ještě k adekvátnímu zatížení operátorů 10. Je třeba ovšem počítat, že zde jde o aktuálně přihlášené operátory skutečný počet operátorů pro zvládnutí extrémní situace musí být nejméně 1,2x vyšší (povinné přestávky v práci a hygienické pauzy). Tabulka 21: Přípustné zatížení operátorů (hodinově) Počet zpracování Celková doba dynamické prodlevy Celková doba zpracování Spojit hovor (JTS) 7 327 0 0 Spojit hovor 6 067 0 5 174 HZS Navázat kontakt s volajícím a přijmout prvotní informace 2 672 311,17 140 079 HZS Vytěžit hovor 683 71,49 95 068 PČR Navázat kontakt s volajícím a přijmout prvotní informace 916 41,71 51 184 PČR Vytěžit hovor 722 41,33 98 212 ZZS Navázat kontakt s volajícím a přijmout prvotní informace 821 4,17 43 603 ZZS Vytěžit hovor 670 1,69 96 837 Vizualizovat událost 369 0 0 Zavěsit MAIN 7 223 0 35 116 Pracoviště Zpracované funkce Celková doba zpracování Stupeň vytížení Operátorské pracoviště HZS 3 355 235 147 63% Operátorské pracoviště PČR 1 638 149 396 63% Operátorské pracoviště ZZS 1 491 140 440 62% K odbavení tohoto počtu hovorů bez jakéhokoliv zdržení na vstupu obsazenými linkami je zapotřebí celkem 233 vstupních kanálů. Tabulka 22: Nejvyšší přípustné zatížení systému Aktivita Počet zpracování Celková doba dynamické prodlevy Celková doba zpracování Spojit hovor (JTS) 11 125 620 570 0 Spojit hovor 9 190 0 7 792 HZS Navázat kontakt s volajícím a přijmout prvotní informace 3 977 443 476 219 796 HZS Vytěžit hovor 1 009 116 713 136 500 PČR Navázat kontakt s volajícím a přijmout prvotní informace 1 329 114 355 72 947 PČR Vytěžit hovor 1 043 93 200 151 348 ZZS Navázat kontakt s volajícím a přijmout prvotní informace 1 303 121 269 68 067 ZZS Vytěžit hovor 1 047 103 228 149 848 Zavěsit MAIN 10 952 0 54 594 Vizualizovat událost 512 0 0 10 Odborné publikace uvádí pro emergency call centra jako krátkodobě přípustné (do 3 dnů ve 12 hodinových směnách) zatížení do 75%, dlouhodobě do 40%. strana 41 (celkem 99 stran)

Zcela limitní je pro systém příjem 11 125 hovorů hodinově. Při tomto počtu dochází ke kolapsu systému jak technickému, tak lidskému. Pouze 50% hovorů je odbaveno ihned, 89% do 30 s, 94,2% do 60 s a 98,6% hovorů do 2 minut a to při počtu 630 vstupních plně vytížených linek. Tabulka 23: Nejvyšší přípustné zatížení operátorů (hodinově) Zdroje Aktivity Celková doba zpracování Operátoři jsou přitom využiti na více než 95%, což není možné více než 1 hodinu. Návrh kapacit ICT na základě simulace Návrh kapacit návazných systémů je navržen na nejvyšší přípustné zatížení a činí: Tabulka 24: Návrh kapacit služeb 11 Stupeň vytížení Operátorské pracoviště HZS 4 986 356 296 96% Operátorské pracoviště PČR 2 372 224 295 95% Operátorské pracoviště ZZS 2 350 217 915 96% Služba Hodina Souběžně Počet vstupních linek neuvádí se 810 Počet aktivně přihlášených operátorů neuvádí se 230 Předat hovor na rozhraní se signalizací 11 125 224 Spojit hovor 9 190 157 Založit událost 9 190 157 Provést automatickou identifikaci 9 190 157 Provést automatickou lokalizaci GSM 7 812 133 Provést automatickou lokalizaci pevná 1 379 24 Vyhledat volného operátora 9 190 157 Přehrát úvodní systémovou hlásku 9 190 157 Spojit hovor na operátora 6 609 110 Zajistit jazykovou podporu EN/DE 26 2 Zobrazit specifika zvláštního účastníka 17 2 Vizualizovat oblast volání GIS - prvotní 6 609 110 Překreslit polohu v GIS 19 827 230 Hledat nejbližší objekt podle polohy v GIS 1 322 22 Provést analytický výpočet v GIS (nad více vrstvami) 529 9 Provést výpočet v GIS (nad externími daty) 3 965 66 Předat hovor v NSPTV 500 10 Hledat v místopisu - omezeně 42 959 230 Hledat v místopisu - neomezeně (3 znaky) 16 523 230 Vizualizovat událost pro ostatní operátory NSPTV 369 10 Vyžádat součinnost 465 7 Předat událost do OŘ na rozhraní 3 099 44 Předat hovor do OŘ 186 9 Celkový max. počet připojených operátorských pracovišť činí 300 při zachování stanovených odezev. 11 Hodina je uváděn počet spuštění příslušné služby za 1 hodinu celkem. Souběžně je uváděn počet souběžně spuštěných žádostí o službu. strana 42 (celkem 99 stran)

Simulace běžné situace Běžná situace, na jejímž základě je navrženo minimální přihlášení operátorů k systému, je definována takto: Tabulka 25: Hodinová zátěž (počty hovorů) běžná 12 Hodina PČR HZS ZZS 0 300 165 171 1 240 123 168 2 200 94 127 3 180 90 124 4 140 95 129 5 160 138 134 6 220 285 287 7 370 385 364 8 510 736 440 9 541 856 478 10 581 921 488 11 581 954 493 12 611 1008 503 13 621 1042 524 14 651 1048 526 15 661 1047 536 16 651 1075 561 17 621 1078 559 18 611 1033 557 19 520 939 551 20 460 744 457 21 400 572 341 22 390 352 287 23 340 222 237 CELKEM 10560 15002 9042 Minimální obsazení pro kritickou hodinu je následující: Tabulka 26: Minimální počet operátorů přihlášených do systému pro kritickou hodinu denní směny 13 Složka Počet Aktivity Celková doba zpracování Stupeň vytížení Operátor HZS 30 709 52 229 47% Operátor PČR 29 833 78 284 73% Operátor ZZS 27 712 68 538 68% 12 Zeleně jsou podbarvena pole, kdy se předpokládá služba denní směny, bíle směny noční. Červeným písmem je vyznačena kritická hodina. 13 Celková doba zpracování uváděna v s. strana 43 (celkem 99 stran)

Při tomto obsazení může v kritické hodině směna dosahovat takovéto úspěšnosti: Tabulka 27: Výsledky simulace pro běžné zatížení - kritická hodina 14 Aktivity Počet zpracování Celková doba dynamické prodlevy Celková doba zpracování Spojit hovor (JTS) 2 268 0 0 Spojit hovor 1 878 0 1 589 HZS Navázat kontakt s volajícím a přijmout prvotní informace 551 344 30 462 HZS Vytěžit hovor 158 90 21 767 PČR Navázat kontakt s volajícím a přijmout prvotní informace 459 3 257 24 980 PČR Vytěžit hovor 374 3 450 53 304 ZZS Navázat kontakt s volajícím a přijmout prvotní informace 391 1 864 21 822 ZZS Vytěžit hovor 321 2 614 46 716 Vizualizovat událost 110 0 0 Zavěsit MAIN 2 175 0 10 675 Tyto výsledky garantují, že při nastavení okamžitých mezisložkových přepadů: jsou přijaty všechny hovory do 30 s (nejsou přijaty do 30 s s pravděpodobností 0,00867%) z HZS přepadne max. 1,356% hovorů, z toho 1,061% na PČR z PČR přepadne max. 4,882%, z toho všechny na HZS ze ZZS přepadne max. 4,371% z toho všechny na HZS V případě nastavení 30 s čekání před přepadem na jinou složku již k přepadům dochází zcela výjimečně (0,034%). 14 Počet zpracování celkový počet jednotlivých aktivit, celková doba dynamické prodlevy čekání na uvolnění lidských nebo technických zdrojů, celková doba zpracování uváděna v s. strana 44 (celkem 99 stran)

Kolísající zátěž i během jednotlivých směn nedává prostor pro obsazování směn fixním počtem pracovníků bez ztráty jejich vytížení. Pokud chceme docílit trvalé doporučené vytížení pracovníků 40%, je nutné řešit obsazování operátorských pozic během dne buď klouzavými směnami, nebo dočasně posilovat směny operátorů pracovníky z operačního řízení. Následující tabulka uvádí nezbytné počty pracovníků pro jednotlivé hodiny, pokud má být dosaženo výše uvedené úspěšnosti: Tabulka 28: Výsledky simulace pro běžné zatížení - během dne závazný standard Hodina PČR HZS ZZS 0 14 5 9 1 11 4 9 2 9 3 7 3 8 3 6 4 7 3 7 5 8 4 7 6 10 9 14 7 17 12 18 8 23 22 22 9 24 25 24 10 26 27 24 11 26 28 24 12 27 29 25 13 28 30 26 14 29 30 26 15 29 30 26 16 29 30 27 17 28 20 27 18 27 30 27 19 23 27 27 20 21 22 22 21 18 17 17 22 18 11 14 23 15 7 12 Tento počet operátorů aktuálně přihlášených k systému je závazným standardem, bude trvale monitorován a jeho případná porušení reportována. strana 45 (celkem 99 stran)

Jihočeský Jihomoravský Karlovarský Královehradecký Liberecký Moravskoslezský Olomoucký Pardubický Plzeňský Praha Středočeský Ústecký Vysočina Zlínský Jihočeský Jihomoravský Karlovarský Královehradecký Liberecký Moravskoslezský Olomoucký Pardubický Plzeňský Praha Středočeský Ústecký Vysočina Zlínský Analýza technického řešení projektu Krajské ZZS a přelivy Pro jednotlivé krajské ZZS je vhodné toto obsazení: Tabulka 29: Výsledky simulace pro běžné zatížení - kraje ZZS s min. obsazením Hodina ZZS minimální ZZS s obsazením krajů 0 9 14 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 14 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 7 14 1 1 1 1 1 1 1 1 1 1 1 1 1 1 3 6 14 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 7 14 1 1 1 1 1 1 1 1 1 1 1 1 1 1 5 7 14 1 1 1 1 1 1 1 1 1 1 1 1 1 1 6 14 17 1 1 1 1 1 2 1 1 1 2 2 1 1 1 7 18 19 1 2 1 1 1 2 1 1 1 3 2 1 1 1 8 22 23 1 2 1 1 1 3 1 1 1 4 3 2 1 1 9 24 24 1 3 1 1 1 3 1 1 1 4 3 2 1 1 10 24 24 1 3 1 1 1 3 1 1 1 4 3 2 1 1 11 24 24 1 3 1 1 1 3 1 1 1 4 3 2 1 1 12 25 27 1 3 1 1 1 3 2 1 2 4 3 2 2 1 13 26 29 2 3 1 1 1 3 2 1 2 4 3 2 2 2 14 26 29 2 3 1 1 1 3 2 1 2 4 3 2 2 2 15 26 29 2 3 1 1 1 3 2 1 2 4 3 2 2 2 16 27 29 2 3 1 1 1 3 2 1 2 4 3 2 2 2 17 27 29 2 3 1 1 1 3 2 1 2 4 3 2 2 2 18 27 29 2 3 1 1 1 3 2 1 2 4 3 2 2 2 19 27 29 2 3 1 1 1 3 2 1 2 4 3 2 2 2 20 22 23 1 2 1 1 1 3 1 1 1 4 3 2 1 1 21 17 19 1 2 1 1 1 2 1 1 1 3 2 1 1 1 22 14 18 1 2 1 1 1 2 1 1 1 2 2 1 1 1 23 12 16 1 1 1 1 1 1 1 1 1 2 2 1 1 1 Na úrovni krajů bude při výše uvedeném obsazení docházet k přelivům až ve výši 18%, celkově během dne ve výši 4,723%. Pokud by měl být počet krajských přelivů omezen pod 0,5% a současně bylo nastaveno čekání max. 30 s před přelivem do jiného kraje, bude min. obsazení krajů následující: Tabulka 30: Výsledky simulace pro běžné zatížení - kraje ZZS bez přelivů Hodina ZZS minimální ZZS s obsazením krajů ZZS bez přelivů 0 9 14 16 1 1 1 1 1 1 1 1 1 2 2 1 1 1 1 9 14 16 1 1 1 1 1 1 1 1 1 2 2 1 1 1 2 7 14 15 1 1 1 1 1 1 1 1 1 2 1 1 1 1 3 6 14 14 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 7 14 15 1 1 1 1 1 1 1 1 1 2 1 1 1 1 5 7 14 15 1 1 1 1 1 1 1 1 1 2 1 1 1 1 6 14 17 19 1 2 1 1 1 2 1 1 1 3 2 1 1 1 7 18 19 21 1 2 1 1 1 2 1 1 1 3 3 2 1 1 8 22 23 31 2 3 1 2 1 3 2 2 2 4 3 2 2 2 9 24 24 31 2 3 1 2 1 3 2 2 2 4 3 2 2 2 10 24 24 31 2 3 1 2 1 3 2 2 2 4 3 2 2 2 11 24 24 31 2 3 1 2 1 3 2 2 2 4 3 2 2 2 12 25 27 31 2 3 1 2 1 3 2 2 2 4 3 2 2 2 13 26 29 35 2 3 2 2 2 3 2 2 2 5 4 2 2 2 14 26 29 35 2 3 2 2 2 3 2 2 2 5 4 2 2 2 15 26 29 35 2 3 2 2 2 3 2 2 2 5 4 2 2 2 16 27 29 35 2 3 2 2 2 3 2 2 2 5 4 2 2 2 17 27 29 35 2 3 2 2 2 3 2 2 2 5 4 2 2 2 18 27 29 35 2 3 2 2 2 3 2 2 2 5 4 2 2 2 19 27 29 35 2 3 2 2 2 3 2 2 2 5 4 2 2 2 20 22 23 31 2 3 1 2 1 3 2 2 2 4 3 2 2 2 21 17 19 20 1 2 1 1 1 2 1 1 1 3 2 2 1 1 22 14 18 19 1 2 1 1 1 2 1 1 1 3 2 1 1 1 23 12 16 18 1 2 1 1 1 2 1 1 1 2 2 1 1 1 Toto obsazení představuje denně nutnost blokovat operátora o 98 hodin více (oproti minimální verzi dokonce o 172 hodin více). To představuje ročně 4 470 člověkodnů ročně a po přepočtu na zaměstnance nutnost trvale zaměstnávat nejméně o 13 pracovníků více. strana 46 (celkem 99 stran)

III. ICT koncept Technické řešení podpory procesů ze strany ICT bylo založeno na principech zachování autonomie jednotlivých složek IZS, respektování existující heterogenity IS a nutnosti zvládnout organizačně i dodavatelsky roztříštěný cyklus změn. Proto byla zvolena architektura SOA s uplatněním sběrnice služeb (ESB), které umožňují poskytovat vytvářené služby na standardním vysokoúrovňovém rozhraní, které mohou jednotlivé systémy volat. V rámci společného řešení tak bude vybudována integrační platforma, která bude zároveň zajišťovat řízení výměny dat pro sdílení událostí, vizualizaci operační situace a přístup k centrálně poskytovaným registrům (adresním UirAdr resp. RUJÁN. atd.), příjem tísňového volání (NSPTV) až na úroveň operátorských pracovišť s využitím konektivity ITS MV a jednotný GIS s možností snadné integrace do IS pro operační řízení. Celé technické řešení bylo navrženo tak, aby nebyl předem žádným způsobem omezen budoucí výběr dodavatelů. strana 47 (celkem 99 stran)

Zadání pro cílový koncept Bylo definováno v rámci stanovení cílů projektu takto: 1. Zavést jednotnou technologii pro příjem tísňového volání při zachování národních čísel 15. Řešení bude vycházet z již zavedené a osvědčené technologie TCTV112. 2. Zavést jednotný GIS pro podporu příjmu tísňového volání a operačního řízení 16, a to jak na úrovni společných mapových podkladů, tak z hlediska poskytované funkcionality (služeb), která musí být k dispozici i pro IS operačního řízení a poskytovat i všechny jím využívané služby. 3. Zajistit sdílení informací o událostech v celém jejich životním cyklu 17 včetně jejich lokalizace 18 mezi složkami IZS. 4. Zajistit sdílení informací umožňujících společnou vizualizaci operační situace 19 mezi složkami IZS. V rámci cílového konceptu bylo třeba dbát těchto omezení: 1. Nezvýšit budoucí provozní nároky 20 z hlediska nákladů na obsluhu, provozních nákladů, nákladů na údržbu a obnovu a nákladů na služby. Vzhledem ke značně zvýšeným nárokům na přenosy vyplývající z požadované interoperability bylo rozhodnuto využít pro vzájemnou komunikaci (hlasovou i datovou) mezi složkami IZS především ITS MV 21. 2. Zajistit vysokou dostupnost a provozuschopnost všech uvedených služeb provozovaných v režimu 24x7x365, z hlediska spolehlivosti celého systému. Zajistit vždy nejméně 200% zálohu poskytované služby. U kritických služeb je třeba zajistit adekvátní dostupnost. Jde o tyto služby: hlasový příjem tísňového volání (doručení hovoru až k operátorovi), aplikační podporu operátorů tísňového volání vč. GIS. 3. Zajistit adekvátní řešení bezpečnosti budovaného systému 22. 4. Minimalizovat dopady nových řešení do stávajících IS pro podporu operačního řízení a umožnit inkrementální vývoj i nasazování nových řešení, jak z hlediska jednotlivých funkcí, tak z hlediska složek IZS a jednotlivých lokalit. 23 15 Viz Cíl 09: Zajistit jednotnou technologii pro příjem tísňového volání. 16 Viz Cíl 10: Zajistit jednotný GIS. 17 Viz Cíl 11: Zajistit všestranný tok operačních dat. 18 Viz Cíl 12: Vytvořit podmínky pro nasazení navigačních systémů a sledování polohy. 19 Viz Cíl 13: Zajistit sdílení vizualizace operační situace. 20 Viz Cíl 01: Nezvýšit provozní náklady IZS. 21 Viz Cíl 08: Zajistit využití ITS MV všemi složkami IZS. 22 V souladu s analýzou rizik podle norem ISO 27001 a ISO 17799. 23 Krajská operační střediska jsou postupně inovována, v řadě případů stěhována do nových prostor a/nebo centralizována. strana 48 (celkem 99 stran)

Cílová architektura IS Cílová architektura IS/IT musí být vystavěna na konceptu SOA 24 a doplněna o její dynamické řízení prostřednictvím BPMS. 25 Lze předpokládat, že v budoucnu nebude postačovat pro podporu kvalitního rozhodování a nastavení pravidel řízení (BR) pouze mezi složkami sdílená data operačního řízení, ale bude nutné integrovat a čistit data i z dílčích systémů operačního řízení a provádět analýzy nad nimi prostřednictvím nástrojů charakteru BI 26. Základní koncept integrace jednotlivých IS je následující: Model 17: Koncept procesní a aplikační integrace Sběrnice služeb (ESB) ISKŘ Registr a repository služeb Procesní monitoring Process Server BPE (WS-BPEL) Technický monitoring (správa systému) NSPTV GIS Archivace dat IZS Centrum automatizace testování systému Sběrnice služeb (ESB/Message Broker) ISIZS IS Výjezd DISPEČER Maják158 S.O.S. PROFIA KTTP ZZS Dispečer MediumSoft HZS P ČR Jihomoravský, Ústecký, Plzeňský, Pardubický Vysočina, Středočeský, Jihočeský, Hradecký, Karlovarský, Olomoucký Praha Liberecký Zlínský IS složek IZS pro operační řízení V navržené architektuře předpokládáme tyto vrstvy: Databázové úložiště, kde budou uloženy a vzájemně integrována strukturovaná i nestrukturovaná data. Tato vrstva (včetně funkcionality uložených procedur) bude přístupná pomocí objektově relačního mapování, které zajistí základní operace nad databázovým úložištěm včetně případného transakčního zpracování. Základní funkcionalita bude doplněna o služby zajišťující validaci dat, eliminaci chybných údajů a duplicit a rozšířené možnosti vyhledávání, resp. ztotožňování záznamů. Sběrnice služeb (ESB), která zpřístupní jednotlivé business operace (služby 27 ) dílčích IS odpovídající procesním činnostem pomocí vysokoúrovňového rozhraní. Tato vrstva zajistí procesní integraci s jinými IS prostřednictvím procesního serveru (BPE) případně serveru pro řízení podle pravidel (BRE). Ten poskytuje ucelenou aplikační platformu pro spouštění procesů kódovaných v BPEL včetně definovaných pravidel a návazných SOA služeb 28 a/nebo interpretaci vysokoúrovňových pravidel. Sběrnice zajistí bezpečnou procesní integraci služeb dílčích IS i služeb aplikací operačního řízení. Z hlediska nových řešení IS i integrace stávajících IS je možno očekávat tyto scénáře: komerční balík funkcionalitou vyhoví požadavkům a bude současně obsahovat i integrovanou platformu BPMS 29 komerční balík úplně nebo částečně vyhoví funkcionalitou, bude postaven na jiné komerční či open-source platformě BPMS a případně doplněn externalizovaným vývojem žádný komerční balík nebude poskytovat ani základ potřebné funkcionality 30 a bude nutný zákaznický vývoj, ať už úplný nebo částečný 24 Servisně orientovaná architektura. Ucelená funkcionalita jednotlivých aplikací (komponent) v podobě služeb je k dispozici na ESB (sběrnici služeb) pro volání pomocí vysokoúrovňového rozhraní. SOA zde vnímáme jak z pohledu životního cyklu potřeb operačního řízení, tak i životního cyklu služeb (vývoje IS). Znamená to tedy, že bude implementována přírůstkově, po jednotlivých fázích. Při použití architektury SOA dochází navíc k vytvoření společného standardu, do kterého všechny aplikace musí konvertovat svá data - vzniká tedy pouze n propojek mezi aplikacemi a ESB. Architektura zaměřená na služby spolu s webovými službami přináší jednotný a standardizovaný komunikační protokol a standard pro popis rozhraní, které aplikace nabízejí. Díky webovým službám a jejich rozšíření je pak implementace této integrace velmi rychlá a nabízí otevřenou architekturu založenou na standardech. Při integraci aplikací pomocí webových služeb vzniká společný datový model, do kterého všechny aplikace konvertují data. 25 Business Process Management Suite. 26 Business Intelligence. 27 Webové služby nejsnadněji naplňují podstatu architektury orientované na služby, nicméně nepředstavují jediný prostředek k její realizaci. Komunikačním protokolem tedy nemusí být pouze SOAP a transportním protokolem nemusí být jen HTTP či HTTPS. Ve světě J2EE je možné definovat službu jako bezestavovou komponentu (tzv. stateless session bean), která komunikuje pomocí RMI/IIOP, ve světě standardních Java aplikací může být služba reprezentována pomocí tzv. Plain Old Java Objectu (POJO). 28 Nasazení procesního serveru předpokládá modelování procesů, ale také posouzení existujících služeb. Tato úloha je realizována prostřednictvím dvou metodik - pro procesní a UML modelování, na jehož základě probíhá vlastní aplikační vývoj. Výstupem z modelování jsou podnikové procesy popsané ve standardizované notaci BPEL resp. WS-BPEL (Business Process Execution Language). Následně jsou jednotlivé kroky v procesu provázány na existující aplikační funkce zpřístupněné prostřednictvím standardů (např. webové služby) a dalšími alternativními způsoby (např. pomocí aplikačních technologických adaptérů). 29 To lze očekávat jen u největších a nejdražších aplikačních balíků (např. Oracle, částečně i MS). strana 49 (celkem 99 stran)

IS specialisté uživatelé Analýza technického řešení projektu komerční nebo open source BPMS bude poskytovat dostatečnou funkcionalitu pro integraci, také současné IS operačního řízení budou z velké části nabízet potřebnou funkcionalitu a bude možné alespoň část stávajícího kódu rozčlenit do komponent tak, aby byly schopné pracovat s ESB, pouze nová nebo nevyhovující funkcionalita bude znovu vyvíjena Podle naší zkušenosti a znalosti funkcionalit komerčních řešení předpokládáme, že právě poslední varianta bude nejrychlejší, nejefektivnější a přitom i do budoucna nejperspektivnější. Vývoj a nasazování integrační platformy i možné budoucí řízení změn v IS bude probíhat tímto způsobem: Obr. 13: Logika řízení změn v integrační platformě strategické požadavky složek IZS požadavky operačního řízení Modelování procesů Monitoring Procesní modely (BPMN) Design IS Orchestrace služeb Nastavení BPE (BPEL) Procesní server IS modely (UML) může se podílet řada různých dodavatelů Sběrnice služeb ESB Vývoj služeb Zveřejnění služeb (WS) SOA governance (repository) V případě vývoje potřebné funkcionality jak nových společných funkcionalit pro příjem tísňového volání a vizualizace operační situace musí být dodrženy tyto klíčové zásady pro vývoj: 1. Musí být založen na komponentách (CBD). 2. Musí být založen na metodice, která podporuje iterativní vývoj (např. Select Perspective). 3. Musí být celý veden v jediném BPM/CASE nástroji a modelován v notacích UML a BPMN/BPEL (plus datové modelování) v konceptu MDA (CIM IS nezávislý model, PIM platformově nezávislý model, PSM platformově specifický model, Code výsledná aplikace). 4. Nový vývoj nesmí být prováděn, pokud není žádána nová funkcionalita postačí stávající kód rozčlenit do komponent a doplnit příslušná vysokoúrovňová rozhraní. 5. Nový vývoj provádět ve vyšším programovacím jazyce, který podporuje oboustranný převod z/do BPM/CASE nástroje. Dodržení těchto zásad je nutné uplatnit v následném projektovém stupni řešení tímto metodickým postupem 31 : 1. Návrh logického datového modelu (ERM model). 2. Celkový model objektových tříd (na úroveň jejich atributů) a jejich seskupení do komponent. 3. Model komunikace komponent (příp. vč. sekvenčních modelů) s návrhem jejich rozhraní pro všechny dotčené IS). 4. Rozčlenění stávajícího kódu do komponent 32 a rozhodnutí o formě změn (zapouzdření a úprava stávajícího kódu, přepis kódu ve vyšším jazyce s doplněním funkcionality, vývoj nové komponenty s novou funkcionalitou). 5. Zadání pro vývoj (interní externí), řízení vývoje. Vytvoření nových komponent s nově požadovanou funkcionalitou (přírůstkově). 30 Ve vyváženém mixu kvalita-cena-perspektiva, nebo jeho funkcionalita nebude na rozhraních dostatečně otevřená. 31 Vynucování dodržení těchto pravidel je vhodné již výběrovém řízení. Trvalou kontrolou by měla být pověřena projektová kancelář nebo specifický technický dozor. 32 Tomu může předcházet extrakce předem vymezené funkcionality do uložených procedur a následná migrace dat a cut-over. Tento krok je možné očekávat především v případě zjištění datových nekonzistentností. strana 50 (celkem 99 stran)

6. Testování a implementace přírůstkově po zavedení procesního serveru a převedení na ESB Integrační platforma Zvolená integrační platforma (ESB + BPMS resp. minimálně BPE/BRE) vychází ze současných technologických standardů a respektuje existující heterogenitu integrovaných systémů. Současně je zacílena na abstrahování logiky rozhodování z jednotlivých dílčích IS, kde je dnes zanořeno. To přináší velké obtíže nejen pro samotnou integraci, ale vzhledem k řadě dodavatelů dílčích IS prakticky znemožňuje dosažení jednotné úrovně služeb. Model 18: Architektura integrační platformy 33 Technický monitoring (správa systému) Jiná sběrnice služeb (ESB) Registr a repository služeb Procesní monitoring Technický monitoring (Dohled) Process Server BPE (WS-BPEL) Web aplikační server Portál Kolaborační / WF server Engine pro řízení pravidel BRE Sběrnice služeb (ESB/Message Broker) ISIZS Správa identit Řízení přístupu ke službám DB komponeta Konektor WebServices Konektor XML Konektor J2EE Aplikační adaptéry Technologické adaptéry HW akcelerace replikace, federace... DBMS n Uvedené komponenty jsou virtuální mohou být instalovány ve více instancích podle očekávaného zatížení na virtuálních strojích, nevyžadují tedy vždy svůj samostatný fyzický server. Registr služeb bude trvale k dispozici minimálně na všech MAIN platformách. ESB Základním stavebním kamenem provozního prostředí je koncept Enterprise Service Bus, podnikové sběrnice služeb 34. Ta představuje flexibilní propojovací infrastrukturu pro integraci aplikací a služeb. ESB zajišťuje nízkoúrovňové funkce, jako je přenos dat, jejich transformace, validace, transformace protokolů a řízení událostí. ESB lze realizovat různými softwarovými technologiemi, a to i na bázi open source řešení. ESB funkce musí být k dispozici na bázi standardů WebServices, XML, J2EE, dalších otevřených, ale i specifických standardů (data a aplikační zdroje na bázi proprietálních či průmyslově specifických formátů, např. EDI, SWIFT, zákaznické formáty jiné než XML povahy). K tomu budou sloužit aplikační a technologické adaptéry. Vesměs specifická komponenta (u některých komerčních řešení součást ESB) zajišťuje vazbu na databázovou vrstvu a úkoly spojené s datovou integrací. Poskytuje služby datových replikací relačních i nerelačních zdrojů, federaci dat a je současně prostředkem pro plnění datových skladů. Nelze vyloučit ani nasazení hardwarových technologií zajišťujících akceleraci operací spojených s provozním prostředím. Jedná se například o parsování XML souborů, bezpečnostní verifikace, transformace dat a protokolů apod. Tyto operace mohou být pak realizovány na HW úrovni, proto je jejich zpracování výkonnější. V případě ucelených BPMS platforem je součástí řešení webový aplikační server pro provoz nových (webových) služeb, který může nahradit řadu dílčích aplikačních serverů, kolaborační server podporující workflow a týmovou práci a portál jako jednotné prostředí pro interakci uživatele s informačním systémem. V oblasti procesního řízení umožňuje uživatelům iniciovat podnikové procesy a ovlivňovat jejich průběh. Řídícím pracovníkům pak poskytuje údaje o průběhu procesů a poskytuje informace nezbytné pro řízení společnosti. Process Server (BPE) Je základním provozním prostředím pro implementaci procesů na úrovni IT. Bývá založen na robustní technologii J2EE a musí být plně kompatibilní s otevřeným standardem WS-BPEL, který zaručuje jednoduchou přenositelnost procesů 35. Doplněním či dokonce náhradou BPE může být engine pro řízení pravidel (BRE) či business rule 33 Kolaborační server je využitelný pro změnová řízení atd. 34 Služba je komponenta, která má přesně definované rozhraní a toto rozhraní určuje funkcionalitu, kterou poskytuje. Služby jsou bezestavové a jejich rozhraní je popsané pomocí standardizovaného rozhraní (WSDL) a komunikují pomocí standardního komunikačního protokolu (SOAP) po transportním kanálu uvedeném v rozhraní. WSDL a SOAP tvoří základní specifikací webových služeb - WebServices. Nejčastějším transportním kanálem pro webové služby bývá standard HTTP nebo HTTPS. 35 Procesor jazyka WS-BPEL obsahuje korelační a transformační mechanismy, které by si programátor implementující choreografii musel programovat sám. Dále choreografie služeb více externalizuje lokaci služeb a její záměna je zde možná standardním způsobem. strana 51 (celkem 99 stran)

management system (BRMS), který může sběr událostí a jejich směřování také zařídit. Volba konkrétního enginu závisí na tom, zda bude zvolena ucelená BPMS platforma nebo bude integrační řešení skládáno z různých dílčích komponent. Monitoring Nedílnou součástí provozu podnikových procesů je jejich monitorování, které lze realizovat na technologické a procesní úrovni. Procesní monitor umožňuje komplexní monitoring procesů, sledování stavu jednotlivých instancí procesů, sledování klíčových ukazatelů výkonnosti, vyhodnocení procesních ukazatelů (průběžná doby, zatížení, odezvy apod.) a také kritické aspekty procesů. Zajišťuje prezentaci agregovaných údajů v textové i grafické podobě. Předpokládá se velmi zásadní využití procesního monitoringu ke sledování definovaných standardů a s využitím integrovaného WF i podporu reportovacích a eskalačních procedur. Technologický monitor poskytuje údaje nezbytné k IT monitorování podnikových procesů 36. Umožňuje vizualizovat toky dat mezi webovými službami v procesu, identifikovat problematická místa ve zpracování, sledovat dodržování SLA a provádět monitoring vlastní infrastruktury. U technologického monitoringu lze předpokládat externí dohled. Registr a repository služeb Soubor pravidel a metodik, kterými je provoz IT řízen a měřen příp. vyhodnocován. SOA Governance je rozšířením IT Governance se zaměřením na řízení životního cyklu služeb ve světě SOA. Je realizován prostřednictvím Service Registry and Repository, které plní 2 klíčové role: je servisním registrem (obdobně jako UDDI) a současně udržuje metadata spojená se službami. Řídí tak kompletní životní cyklus služeb počínaje publikováním služeb, přes vyhledávání služeb podle různých kritérií (dostupnost, kvalita služby), dynamický výběr služeb až po jejich vyřazení. SOA Governance musí být integrovatelný s různými provozními prostředími ESB, procesním serverem, ale i s generickými klienty. V případě ucelených BPMS platforem je součástí řešení i správa identit, řízení přístupu ke službám a řízení přístupu mezi bezpečnostními doménami. Řízení výměny dat IZS Systém zajišťuje sdílení dat určených k vizualizaci událostí a operační situace. Funkcionalita je postavena na definovaných strukturách sdílených dat, číselnících a pravidlech sdílení a vizualizace realizovaných prostřednictvím ESB resp. řízené BPE/BRE. Sdílená data (výhledově i služby) jsou prostřednictvím ESB podle pravidel, která spravuje procesní server nebo BRE, sdílena mezi NSPTV a jednotlivými IS operačního řízení. ESB současně zajišťuje platformu pro toto sdílení a zajišťuje bezestavové předávání dat mezi jednotlivými středisky operačního řízení. Systém zajišťuje archivaci těchto událostí a poskytuje možnost jejich administrace a reportingu podle stanovených oprávnění. Řízení kvality IS Důležitým předpokladem úspěšnosti projektu je zabezpečit řízení jakosti implementace IS v procesu realizace. Vhodným řešením je realizace těchto služeb externím subjektem nezávislým na případných dodavatelích systému. Tyto služby by měly zahrnovat zejména následující aktivity: Řízení kontroly shody se schválenými požadavky a Plán jakosti, Řízení shody technologického návrhu s potřebami zadavatele (technologický dozor), Návrh metrik, plánu akceptací a funkčních testů, Objektivní hodnocení splnění požadavků, Pravidelná hodnocení kvality, Identifikace rizik v oblasti dosažení nastavených metrik a revize plánu k jejich eliminaci, Odborné konzultační služby v oblasti optimalizace funkcionality systému, bezpečnosti a řízení jakosti, Reporting o kvalitě a stavu projektu, závěrečný audit a závěrečná zpráva. 36 Monitorovací systém sbírá informace a události ze všech komponent infrastruktury. Takto získané informace je následně možno korelovat a statisticky zpracovat. Monitorovací nástroje tak mohou vracet informace do registrů služeb, které se mohou využít např. ke zmíněnému směrování provozu, nebo je možno vyhodnocovat využití služeb (nutné před vyřazením služby z provozu). Díky korelacím je také usnadněna detekce závislosti služeb na sobě a řešení dopadových analýz při změnách služby. Při spojení registru služeb a monitorovacích nástrojů pro SOA je snadné sledovat např. neautorizované služby (služba neevidovaná v registru služeb, na kterou však chodí provoz tyto nepodchycené služby často představují nezanedbatelné bezpečnostní, výkonnostní a stabilitní ohrožení), nevyužívané služby, které zbytečně plýtvají prostředky v systému. Dále může být monitorovací nástroj ve spojení s registrem služeb použit k monitorování dodržení SLA pro službu (např. dostupnost a odezvy služby z pohledu klienta), ale také k vynucení zachování podmínek pro dodržení SLA. Např. pokud volaná služba může provést bez ohrožení stability 30 transakcí za sekundu, je vhodné pro tento systém tuto podmínku zajistit a nadlimitní provoz buď směrovat na jiné systémy, nebo vrátit klientovi informaci, že kapacita systému je plně využita. Protože ESB bude využito jako vstupní bod ke službám, které jsou poskytovány externími systémy, je možno velmi efektivně chránit poskytovatele služeb před přetížením, nestabilitou a následnými kaskádovými pády. strana 52 (celkem 99 stran)

Dále je vzhledem ke složitosti ISIZS nezbytné zajistit vysokou spolehlivost celého systému a to jak ve fázi uvedení do provozu, tak i v případě průběžných změn nebo úprav systému. Vzhledem k rozsahu systému i očekávané četnosti změn je při standardním přístupu k testování třeba předpokládat vysokou míru náročnosti (alokace lidských zdrojů) pro zajištění těchto činností. Vhodným řešením se jeví vybudování centra pro automatizované testování, které zajistí jak standardizaci procesního rámce pro testování, tak i technologické prostředí pro funkční a zátěžové testování systému. Takové řešení zvýší spolehlivost systému při zachování rozumné míry nároků na lidské zdroje provozovatele. V neposlední řadě umožní i výrazné zkrácení testovacích období a bezpečnou simulaci zátěže při krizových situacích. NSPTV Funkcionalita NSPTV je definována procesním modelem a zahrnuje tyto komponenty a funkce: Model 19: Funkcionalita NSPTV PBX Operátorský IS Operátorský IS Nahrávání hovorů GIS Operátorský IS Operátorský IS PBX služby Správa událostí Správa pravidel přidělování hovorů Správa hlásek a nahrávání Vizualizace (GIS) Správa čísel Správa kontaktů F Provést automatickou identifikaci F Založit událost F Definovat pravidla distribuce hovorů F Přehrát úvodní systémovou hlásku F Vizualizovat událost Spravovat seznamy a pravidla čísel F F Spravovat kontakty F Spojit operátora F Validovat událost F Spravovat operátory a pracoviště F Přehrát hlásku představení operátora F Vizualizovat oblast volání Provést kontrolu speciálního seznamu čísel a IMEI F F Vyhledat tlumočníka F Vytvořit příposlech F Klasifikovat událost F Vyhledat volného operátora F Přehrát výstrahu F Lokalizovat MU pomocí GIS F Zobrazit specifika zvláštního účastníka F Vyhledat jiný kontakt F Vytvořit konferenční hovor F Editovat událost Vyhledat volného operátora ve zvolené složce F F Nahrát hlásku Podpora automatizace reportingu chybových stavů F F Určit rajonizaci F Zařadit do čekací fronty F Sloučit událost Vyhledat operátora složky podle kraje volání a jazyka F F Nahrát hovor F Podpora výkonu služby F Vyjmout z čekací fronty F Odeslat událost Vyhledat operátora s příslušnou jazykovou kvalifikací F F Vyhledat hovor Vizualizace událostí vzniklých ke stejnému číslu F Zavěsit Přijmout událost Exportovat hovor F F F F Automaticky identifikovat jazyk volajícího F Aktualizovat událost F Přehrát záznam do konference F Vyžádat součinnost Poskytnout stav operátora a volání F F Administrovat události strana 53 (celkem 99 stran)

Základní technický koncept může plně využít výhod IP telefonie nebo využít duálního přenosu hlas/data nebo dokonce kombinovat oba systémy (duální telefonie pro MAIN, plná IP telefonie pro REMOTE). Volba konkrétního řešení závisí na cenové kalkulaci a nabídnutých licenčních podmínkách. Model 20: Architektura NSPTV kombinovaná duální telefonie IP REMOTE Operátorské pracoviště IP telefon IP VPN Router LAN (separovaná) Operátorský IS Klient Vstupní linky SDH SS7 PRA CDD UA LAN (separovaná) Operátorské pracoviště IP telefon Digitální telefon Operátorský IS Klient Aplikační server Dispečerské aplikace Operátorský IS Serverová část Další servery... ESB Další služby... MAIN PCM Nahrávání hovorů Nahrávání hovorů STA Server CTI CTI SDH-SDH PBX Model 21: Architektura NSPTV IP telefonie ITS páteř (10GE/1 GE) QoS Router Router Router Router Switch 2x (QoS) LAN (separovaná) FW LAN složky Switch 2x (QoS) LAN (separovaná) FW LAN složky 112 150 155 158 PBX sig ESB GIS Nahrávání hovorů Operátorská pracoviště ESB Repository CallMgr Operátorská pracoviště VTS (PSTN) odchozí CallMgr/ server Signalling server BPE/BRE Aplikační/DBMS server GIS IP PBX TRUNK (stávající) Aplikační/DBMS server GIS Nahrávání hovorů MAIN CTI Základna geodat lokalita IP PBX TRUNK (stávající) REMOTE Všude bude NSPTV vedeno po separátní LAN. Všechny klíčové prvky konektivity (směrovače, přepínače, modemy ) budou zdvojeny. Platformy MAIN fungují jako vstupní body do systému z veřejné služby. Podle výstupu simulace postačí zachování stávajícího celkového počtu vstupních linek 37. Vzhledem k tomu, že jediná MAIN platforma musí být schopna uřídit celou republiku, je nutné počet vstupních linek rozšířit na každé platformě na 270 vstupních a 90 výstupních kanálů. Počet primárních platforem (3) a jejich lokalizace bude zřejmě zachována (Praha, Plzeň, Olomouc) s ohledem na 37 Každá MAIN lokalita je připojena 4 2MB ISDN 30 linkami, z toho 3 jsou použity pro příchozí hovory a 1 je pro hovory odchozí. V celém systému je k dispozici 270 (3x90) vstupních kanálů a 90 (3x30) kanálů výstupních. Odchozí hovory (zpětná volání a konference) nesnižují vstupní kapacitu systému. strana 54 (celkem 99 stran)

existující zdvojené připojení k veřejné síti. Minimálně platformy MAIN budou mít přímé propojení do ITS a do hlasové sítě HZS. V dalším projektovém stupni bude rozhodnuto, zda umístění MAIN platforem bude ponecháno ve stávajících lokalitách a zda vybudovat v Hradci Králové další MAIN platformu. Ta by pak sloužila během implementace pro vývoj pilotního řešení a návazně buď pro rozložení zátěže, nebo jako platforma pro vývoj a testování. Každá MAIN platforma musí být schopna řídit hovory v celém systému NSPTV v krizovém stavu včetně registrace operátorů v NSPTV, dále musí umět předat hovor do PBX operačního řízení každé složky (včetně signalizace, záložně přes PSTN). Rekonfigurování při výpadku kterékoliv platformy musí proběhnout do 5 minut. Součástí MAIN a případně i REMOTE platforem bude nahrávání hovorů s možností jejich vyhledání a přehrání příp. dalšího zpracování (hlasové analýzy apod.). Výstup ze systému nahrávání se předpokládá centrální. Systém musí zajistit i nahrání hovorů předávaných do operačního řízení. GIS Systém GIS je budován v souladu se Směrnicí INSPIRE 2007/2/ES. Z hlediska tísňového volání bude systém umožňovat: Lokalizaci místa události na základě vstupní informace o poloze a korekci chybně zadané informace. Touto informací může být souřadnice, adresa, blízkost orientačního bodu apod. Vizualizaci informace o stavu události. Z hlediska operačního řízení bude systém dále umožňovat: Vizualizaci operační situace včetně dynamické vizualizace polohy SaP v území se základními informacemi o nich. Podporu navigace SaP dynamickým návrhem optimální trasy k místu události. Podpora vizualizace dynamických vrstev. Tyto funkcionality jsou kritické z hlediska rychlosti odezvy. Rozšířené funkcionality pro podporu operačního (a případně krizové) řízení, které již nejsou kriticky citlivé na rychlost odezvy, jsou: Překryvné operace (např. polygon znázorňující oblast šíření nebezpečné látky a vrstva budov). Síťové analýzy (plány posilování SaP). 3D modelování (např. povodně, šíření nebezpečných látek). Statistické funkce. Funkce pro správu metadat a dat. Data uložená v základnách geodat složek na úrovni krajů mohou být archivována. Archivy těchto dat, pokud budou nasazeny, musí být řešeny v typových projektech operačního řízení každé složky. strana 55 (celkem 99 stran)

Přehled funkcionality, která bude dostupná pro systém NSPTV a IS operačního řízení prostřednictvím služeb, je uveden v následujícím modelu: GIS GIS Správa dat GIS Zobrazení dat GIS Hledání GIS Měření a analýzy Správa metadat Lokalizace entit v mapě Nalezení entit podle polygonu Měření obvodu Import mapových podkladů Vizualizace entit Nalezení entit prostorově Měření plochy Export datových vrstev Vyvolání akce svázané s entitou Nalezení entit prostorově Měření v mapě Import datových vrstev Zobrazení vlastností bodu v prostoru Nalezení entit přes popisná data Měření vzdálenosti Vytvoření mapové kompozice Výpis informací o vybraných entitách Nalezení entit ručně Výpočet průniku Uložení mapové kompozice Nalezení entit v mapě Výpočet rozdílu Tisk mapové Nalezení Výpočet kompozice nejbližší entity sjednocení Zobrazení mapové kompozice Nalezení optimální trasy Analýza 3D Přidání vrstvy kompozice Nalezení protínajících se entit Analýza profilu linie Odebrání vrstvy Nalezení prvků Analýza kompozice v okolí překryvu vrstev Změna pořadí vrstev v kompozici Nalezení území obslužnosti Analýza sítí Vygenerování obrázku z kompozice Výběr nalezených entit Analýza spádu a orientace Správa popisné Analýza složky entit viditelnosti Správa prostorové složky entit Analýza vrstevnic Správa symboliky vrstvy Nastavení měřítkových omezení Datová základna geografických dat Bude vytvořena společná datová základna, 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 (např. RES). Bude mít následující tříúrovňovou hierarchii: Model 22: Základny geodat Základna geodat IZS Základna Základna Základna geodat geodat Sběrnice služeb (ESB/Message Broker) ISIZS geodat HZS PČR ZZS Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat Základna geodat České Budějovice Karlovy Vary Plzeň Ústí nad Labem Brno Jihlava Pardubice Praha Liberec Kladno Hradec Králové Olomouc Ostrava Zlín Na každé úrovni budou k dispozici funkce pro správu metadat a možnost vkládat vlastní vrstvy. Geodata nadřízené hierarchie budou automaticky replikována do všech podřízených datových základen38. Takto bude v případě výpadku centrální služby nebo datového spoje zajištěna plná funkčnost příslušného operačního střediska. Všechna geodata na všech úrovních budou zálohována. Přidaná hodnota lokálních základen geodat budou zálohována na nadřízené základně geodat složky. (v případě výpadku lokální základny geodat budou tyto data k dispozici ve verzi poslední replikace z podřízené na nadřízenou základu geodat). Na centrální úrovni bude zajištěno sdílení a aktualizace těchto základních geodat 39 : Geodata ČUZK Ortofotomapamy, digitální modely reliéfu (letecké laserové skenování) 38 GIS geodata speciálních složek nejsou budován v rámci projektu ISIZS. 39 Výčet bude průběžně aktualizován v souladu s vývojem dalších dostupných sad prostorových dat. strana 56 (celkem 99 stran)

Základní báze geografických dat ZABAGED (informace o sídlech, komunikacích, rozvodných sítí a produktovodech, vodstvu, územních jednotkách a chráněných územích, vegetaci, povrchu a terénního reliéfu, výškopisu, bodových polích, adresních bodech a správním členění) Mapová díla IS katastru nemovitostí (ISKN) Geonames, mapové dílo Registr územní identifikace adres a nemovitostí RÚIAN (připravovaný nahradí mj. ÚIR-ADR) Digitální mapa veřejné správy DMVS (připravovaný - jednotlivé vrstvy budou tvořeny Katastrální mapou, Ortofotomapou a Technickou mapou) Další tematická data od VÚV (data o vodních tocích a vodních plochách), ČD, ŘSD, MŽP, SHOCart (cyklotrasy a turistické trasy), CEDA (jednotná silniční a uliční síť, vrstvy objektů) Specifické datové sady, které tvoří klíčové vrstvy místopisu, využívané pro lokalizaci místa události. Funkcionalita na centrální úrovni bude poskytovat: Metadatové služby s hierarchickými vazbami na vnitřní i vnější datové zdroje Import a začlenění základních geodat 40 Přímý přístup s automatickou synchronizací dat (replikací geodat) mezi všemi úrovněmi základen geodat, který bude umožňovat vzdálený dohled. Mapové služby pro centrální úroveň složek IZS (ve formě WMS, WFS, CSW, WPS, CS-W) na základě autorizace a uživatelských oprávnění Rozšířená funkcionalita na centrální úrovni bude poskytovat GIS podporu ISKŘ: mapové služby IZS pro širší okruh (ve formě WMS, WFS, WCS, CS-W ), ve formě intranetového/extranetového mapového portálu (např. kartograficky zpracované statistické informace) na základě publikační databáze Základny geodat jednotlivých složek IZS budou obsahovat geodata specifická pro jednotlivé složky včetně začlenění dat z externích zdrojů (jiné mapové služby a zdroje dat než ty, které budou dostupné prostřednictvím centrální úrovně, např. data mezinárodního charakteru). Základny geodat na úrovni lokalit budou zajišťovat mapovou službu pro NSPTV a IS OŘ, popř. na základě autorizace a uživatelských oprávnění jednotlivých útvarů nebo vybraných mobilních jednotek, 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. Zdrojová data pro vizualizaci bude poskytovat ESB. Rozšířená funkcionalita bude zahrnovat další GIS služby včetně vyhledávání a analýz a vizualizaci mobilních SaP včetně navigační podpory (jako volitelnou službu pro IS operačního řízení). Správa metadat je zajištěna na všech 3 úrovních základen geodat. Základní mapové podklady jsou získávány a zpracovány centrálně a dále distribuovány na všechny základny systému. Specifické vrstvy jednotlivých složek jsou uchovávány na úrovni základen složek IZS. Základny složek jsou schopny v případě výpadku centrální základny zajistit dílčí replikace a synchronizace. Pohybová data pro vizualizaci jsou poskytována službami přes ESB. Funkcionalita GIS pro tísňové volání a pro operační řízení je buď volána z příslušných aplikací, nebo poskytována formou tenkého klienta. Analytické funkce GIS se předpokládají na každém středisku OŘ prostřednictvím tlustého klienta. Navržený technický koncept je otevřený z hlediska volby konkrétního GIS systému. Při výběru bude rozhodovat cenová kalkulace s ohledem na licenční politiku a možnost využít již zakoupená řešení a licence. 40 Automatizovaný import a harmonizace dat se předpokládá v čase s minimální zátěží a musí umožnit pravidelné načítání, transformaci a ukládání údajů takovým způsobem, aby při jejím průběhu nedošlo k přerušení činnosti distribuce dat. Nebude omezen přístup ke stávajícím datům a databázím včetně správy a údržby. Načtení dat pro převod a aktualizace bude umožněno z jednoho (např. Integrovaný informační systém) či více zdrojů. Načítání, optimalizace dat pro publikaci či výdej a uložení zpracovaných dat do cílových struktur bude možno administrátorsky konfigurovat. strana 57 (celkem 99 stran)

Konektivita Podle cílů projektu bude maximum provozu v IS IZS převedeno na ITS MV. Z hlediska připojení poslední míle existují tyto 4 možné situace 41 : 1. Objekty PČR, HZS a ZZS jsou a zůstanou umístěny separátně, připojení k ITS MV je ve stávajícím objektu PČR. Zde se předpokládá využití existujícího optopropojení mezi HZS a PČR a dále vybudování přípojek mezi PČR a ZZS a též mezi HZS a ZZS, které by v případě narušení jedné z přípojek poskytla náhradní konektivitu. páteř páteř Existující PČR bude budováno HZS bude budováno ZZS 2. Objekty HZS a ZZS jsou nebo budou prostorově integrovány. Zde bude vybudováno dvojité propojení mezi PČR a tímto integrovaným středisek po nezávislých trasách. páteř páteř Existující PČR bude budováno HZS ZZS LAN 3. Střediska všech tří složek IZS jsou prostorově integrována a přípojný bod ITS MV je umístěn v této budově. Vnitřní konektivita se předpokládá po LAN, nebude nutné budovat žádné přípojky. 41 Uváděné přenosové kapacity odpovídají času vzniku dokumentu (ITS je průběžně posilována). strana 58 (celkem 99 stran)

páteř páteř PČR HZS ZZS LAN 4. Střediska všech tří složek IZS budou prostorově integrována a přípojný bod ITS MV je umístěn v původní lokalitě PČR. Zde je nutné provést buď dotažení tohoto bodu do nové budovy, nebo propojit přípojný bod s novou budovou dvěma nezávislými trasami. páteř páteř PČR HZS ZZS LAN Ve všech případech zůstává nezdvojená trasa ITS od místa souběhu optických vláken z různých směrů (většinou nádraží) až k přípojnému bodu. V případě poškození této trasy bude využito náhradní konektivity ITS (většinou ATM 155 Mbps). Situaci shrnuje tabulka v příloze Konektivita. Projekt IS IZS předpokládá, že výše uvedená konektivita bude vytvořena samostatným projektem v rámci rozvoje ITS. Druhou základní podmínkou pro zajištění funkcionality budovaného systému je nastavení QoS příp. vytvoření dedikovaného pásma s šířkou 9xE1 a to jak v ITS, tak v jednotlivých připojených LAN (všechny použité síťové prvky musí nastavení QoS podporovat). strana 59 (celkem 99 stran)

IV. Rizika Tato kapitola specifikuje projektová rizika spojená s technickým řešením. Dále uvádí vybraná operační rizika spojená s procesy. Tato procesní rizika jsou definována v 6 úrovních závažnosti a současně slouží jako závazné standardy pro cílový stav. strana 60 (celkem 99 stran)

Projektová rizika Rizika spojená s realizací tohoto projektu a jejich řízení je komplexně specifikováno v samostatném výstupu firmy Deloitte. V této analýze technického řešení byla pozornost věnována pouze těm projektovým rizikům, která vyplývají ze zvoleného technického konceptu a jsou spojena s jeho implementací. Stanovení projektových rizik Byly zvoleny tyto 3 dimenze možného dopadu rizika: Tabulka 31: Dimenze dopadu rizik Z hlediska hodnocení úrovně dopadu byla zvolena 6 stupňová škála. Ta nepřímo i determinuje, jaké emergency nebo eskalační procedury je nutné použít pro redukci rizika příslušné úrovně. Tabulka 32: Úrovně dopadu rizik Pro stanovení četnosti výskytu rizik byla stanovena 6 bodová škála jejich pravděpodobnosti: Tabulka 33: Pravděpodobnost rizik Pro hodnocení závažnosti rizika byl zvolen tento způsob výpočtu: Dimenze dopadu rizika Úroveň služby Náklady Čas (zpoždění) Závažnost = maximální úroveň dopadu v libovolné dimenzi x pravděpodobnost Tabulka 34: Závažnost rizik Označení S N T Úroveň dopadu Váha Standardní eskalační / emergency procedura Žádný 1 Běžná úroveň Neznatelný 2 Reporting na operativní úrovni (PT) Řešitelný 3 Reporting na řídící úroveň (ŘV), opatření na operativní úrovni (PT) Vážný 4 Reporting na zadávací úroveň, opatření na řídící úrovni (ŘV) Kritický 5 Nutnost redefinice projektu Neřešitelný 6 Zastavení projektu Pravděpodobnost výskytu rizika Váha téměř nemožné (do 0,01%) 1 výjimečně možné (do 2%) 2 běžně možné (do 20%) 3 pravděpodobné (do 50%) 4 velmi pravděpodobné (do 90%) 5 jisté (nad 90%) 6 Hodnocení závažnosti rizika Výše Méně závažné pod 10 Závažné 10 až 14 Velmi závažné nad 14 Pro řízení projektových rizik doporučujeme uplatnit pravidlo, které omezí max. výši závažnosti kteréhokoliv projektového rizika na úroveň max. 10. strana 61 (celkem 99 stran)

Technická a implementační projektová rizika V rámci analýzy byla identifikována rizika technického řešení, byla kvantifikována a byla stanovena jejich maximálně přípustná výše (redukovaná). Tuto redukci rizik musí garantovat projektové řízení a zvolené procedury monitoringu rizik resp. emergency a eskalační procedury. Tabulka 35: Technická projektová rizika 42 Oblast Cut-over Cut-over Cut-over Cut-over Cut-over Riziko Selhání příjmu TV po přesměrování na nový systémz důvodu nefunkčnosti technologie Omezení funkcionality TCTV po přesměrování na nový systém Selhání funkcionality GIS po přesměrování na nový systém Selhání funkcionality sdílení dat po přesměrování na nový systém Selhání integrace NSPTV s IS OŘ po přesměrování na nový systém Služba Náklady Čas Dopady rizika - bez opatření Max. dopad Výskyt Závažnost Služba Náklady Čas Požadovaná redukce dopadů rizika Max. dopad Výskyt Závažnost 6 1 4 6 3 18 5 1 2 5 2 10 4 1 3 4 4 16 4 1 2 4 2 8 3 1 2 3 5 15 3 1 2 3 2 6 3 1 2 3 5 15 3 1 2 3 2 6 3 1 3 3 5 15 3 1 2 3 2 6 Připravenost Nedokončené připojení MAIN do ITS 1 1 5 5 3 15 1 1 2 2 2 4 Připravenost Nedokončené připojení REMOTE do ITS 1 1 3 3 4 12 1 1 2 2 2 4 Připravenost Nenastavené nebo nevyhovující QoS v ITS 4 1 2 4 3 12 3 1 2 3 2 6 Připravenost Připravenost Připravenost Nedokončené nebo nevyhovující technologické prostory pro MAIN Nedokončené nebo nevyhovující technologické prostory pro REMOTE Nedokončené nebo nevyhovující prostory pro operátorská pracoviště 1 1 4 4 4 16 1 1 2 2 2 4 1 1 3 3 5 15 1 1 2 2 2 4 1 1 3 3 5 15 1 1 2 2 2 4 Implementace Nevyhovující propustnost ITS 1 4 6 6 3 18 1 4 6 6 1 6 Implementace Pomalé odezvy ESB / chybný sizing 1 4 4 4 4 16 1 4 4 4 2 8 Implementace Pomalé odezvy GIS / chybný sizing 1 5 4 5 3 15 1 5 5 5 2 10 Implementace Pomalé odezvy NSPTV / chybný sizing 1 5 4 5 3 15 1 5 5 5 2 10 Implementace Nízká kvalita hovorů nebo ztráta signalizace v NSPTV 4 3 3 4 4 16 1 3 3 3 3 9 Implementace Závady v nahrávání hovorů 1 3 3 3 3 9 1 3 3 3 3 9 Implementace Závady v integraci IS OŘ - volání služeb sdílení událostí 1 4 4 4 4 16 1 4 4 4 2 8 Implementace Závady ve funkčnosti monitoringu 1 3 3 3 4 12 1 3 3 3 3 9 Implementace Závady v integraci IS OŘ - nemožnost volání pokročilých funkcí GIS 1 3 3 3 5 15 1 3 5 5 2 10 42 Zelená méně závažná, žlutá závažná, červená velmi závažná. strana 62 (celkem 99 stran)

Operační rizika Operační rizika jsou ta rizika budoucího provozu, která mohou vzniknout po provedení cut over v provozní fázi projektu. Z celé škály možných operačních rizik se analýza technického řešení soustředila na rizika procesní tedy na rizika, která jsou způsobena chybným fungováním procesu, ať už z důvodu problémů s technickým řešením či jeho infrastrukturou, tak s řídícím a organizačním zajištěním procesů. Při definování procesních rizik bylo důsledně postupováno podle procesů, subprocesů a aktivit a bylo analyzováno, jaké výstupní parametry příslušná aktivita služba musí vykazovat, aby byla funkční. Bylo zvoleno 6 úrovní služby a specifikováno, s jakou pravděpodobností mohou nastat a jaké důsledky mají pro zákazníka i obsluhu: Tabulka 36: Úrovně procesních rizik Označení Úroveň služby Pravděpodobnost Možnost výskytu Dopad na zákazníka S1 Standardní více než 98% běžně žádný žádný Dopad na obsluhu S2 Přechodná do 2% během extrémního měsíčního zatížení a/nebo náběhu neznatelný minimální S3 Výjimečná do 0,5% během extrémního ročního zatížení a/nebo pilotního projektuminimální zatěžující S4 Extrémní do 0,01% během katastrofy mimořádných rozměrů znatelný omezující S5 Kritická do 0,0001% při katastrofické situaci - fyzickém zničení části infrastrukutryomezující zásadní S6 Vyloučená do 0,000001% vyloučená služba nefunkční služba nefunkční strana 63 (celkem 99 stran)

Standardy Tyto definované úrovně procesních rizik zároveň tvoří standardy zajišťující jednotnou úroveň služeb tísňového volání a jsou kromě cílů projektu druhým měřitelným výstupem tohoto projektu: Tabulka 37: Standardy tísňového volání Procesní rizika - úroveň služeb (SLA) S1 S2 S3 S4 S5 S6 Předat hovor na rozhraní se signalizací A/A A/A A/A A/N A/N N/N Spojit hovor A A A A A N Založit událost A A A A A N Provést automatickou identifikaci A A A N N N Provést automatickou lokalizaci GSM A A A N N N Provést automatickou lokalizaci pevná 2 s 5 s 7 s nad 7 s N N Vyhledat volného operátora 0 s 5 s 5 s 10 s 30 s N Přehrát úvodní systémovou hlásku A A A N N N Zajistit jazykovou podporu EN/DE A A A A A N Zajistit jazykovou podporu pro vybrané jazyky A N N N N N Zajistit jazykovou podporu - systémovou A A A A A N Zobrazit specifika zvláštního účastníka A A A N N N Vizualizovat oblast volání GIS - prvotní 0,3 s 1 s 3 s 10 s nad 10 s N Překreslit polohu v GIS 0,3 s 1 s 3 s 10 s nad 10 s N Předat hovor v NSPTV - technologická prodleva 0,5 s 1 s 5 s 30 s nad 30 s N Předat hovor v NSPTV - lidská prodleva 3 s 6 s nad 6 s nad 6 s nad 6 s nad 6 s Předat hovor FHQ - technologická prodleva 0,5 s 1 s 5 s 30 s nad 30 s N Předat hovor FHQ - lidská prodleva 0 s 0 s 3 s nad 3 s nad 3 s nad 3 s Spojit hovor člověk - člověk (od přidělení operátoru) 3 s 6 s 6 s nad 6 s nad 6 s N Hledat v místopisu - omezeně 0,3 s 0,6 s 3 s 6 s nad 6 s N Hledat v místopisu - neomezeně (3 znaky) 1 s 3 s 10 s 30 s nad 30 s N Zajistit odezvu aplikace pro příjem TV 0,3 s 0,6 s 3 s 6 s nad 6 s N Vizualizovat událost pro ostatní operátory NSPTV 3 s 6 s 10 s 30 s N N Vyžádat součinnost - technologická prodleva 3 s 6 s 10 s 30 s N N Vyžádat součinnost - lidská prodleva (zahájeno řešení) 9 s 15 s 30 s nad 30 s nad 30 s nad 30 s Předat událost do OŘ na rozhraní 3 s 6 s 10 s 30 s N N Hledat nejbližší objekt podle polohy v GIS 1 s 3 s 10 s 30 s nad 30 s N Provést analytický výpočet v GIS (nad více vrstvami) 10 s 20 s 30 s 60 s N N Provést výpočet v GIS (nad externími daty) A A A N N N Předat hovor do OŘ - technologická prodleva 10 s 10 s 10 s A A N Předat hovor do OŘ - lidská prodleva 15 s 15 s 30 s nad 30 s nad 30 s nad 30 s strana 64 (celkem 99 stran)

Prosazení standardů V metodice projektového řízení musí být pro tyto standardy stanoveny eskalační a nápravné procedury při zjištění vyšší než standardní úrovně služby. Zároveň musí být definovány kompetentní orgány, které tyto procedury budou zajišťovat, a to na úrovni: 1. složky IZS a kraje v případě krátkodobého nebo výjimečného dosažení úrovně S2 2. složky centrálně v případě opakovaného nebo dlouhodobějšího výskytu úrovně S2 a/nebo výjimečného dosažení úrovně S3 3. průřezově přes všechny složky v případě opakovaného nebo dlouhodobějšího výskytu úrovně S3 a/nebo výjimečného dosažení úrovně vyšší než S3 Případy 1 a 2 budou tedy řešeny v rámci běžného organizačního řízení a kompetencí. Pro případ 3 43 se předpokládá vznik orgánu na úrovni řídícího výboru, který bude fungovat po celou dobu provozní fáze a který bude vrcholově garantovat udržitelnost projektu. Tento orgán musí být vybaven takovými kompetencemi, aby mohl účinně řešit případná porušení standardů, ale i rozhodovat o změnách vyvolaných dalším rozvojem systému. 43 Případně i pro úroveň 2 v případě ZZS, pokud nebude na platformě Asociace ZZS vytvořen kompetentní zastřešující orgán. strana 65 (celkem 99 stran)

V. Zajištění projektu Tato kapitola obsahuje ucelení změn do souvisejících oblastí tak, aby bylo možné vymezit dílčí předměty dodávky, a specifikuje nezbytné projektové výstupy navazující dokumentace. Dále obsahuje orientační rámcový rozpočet a harmonogram projektu včetně etapizace se zvláštním důrazem na cut-over. Z umístění jednotlivých komponent IS a harmonogramu je pak odvozeno jak čerpání finančních prostředků v čase, tak lokalizace tohoto čerpání. strana 66 (celkem 99 stran)

Analýza technického řešení projektu Ucelené části projektu Možné formy zajištění projektu V rámci analýzy technického řešení byl cílový stav důsledně navrhován tak, aby nebylo pro jeho implementaci nutné předem zvolit formu dodávky. Je tedy možné využít těchto forem: Jediný generální dodavatel Výhodou takovéhoto řešení je menší zatížení projektové kanceláře, která se může plně soustředit na kontrolu dodržování milníků projektu, audit kvality výstupů a administrativu spojenou s čerpáním finančních prostředků. Nevýhodou tohoto postupu je nemožnost v rámci dílčích výběrových řízení zvolit technicky nejvyspělejší dílčí platformy a dosáhnout nejnižších dílčích nákladů. Systémový integrátor Dodávka by byla rozdělena na 3 věcně i technicky ucelené části integrační platformu, NSPTV a GIS. Systémový integrátor by zajišťoval implementaci integrační platformy včetně integrace dotčených IS pro operační řízení, systémy NSPTV a GIS by byly řešeny separátními dodávkami. Výhodou této formy je možnost optimalizovat poměr cena/výkon i na úrovni subsystémů. Toto je však spojeno s rizikem obtížného zajišťování garancí za celkové parametry budovaného systému vzhledem k silnému, ale obtížně exaktně kvantifikovatelnému vzájemnému ovlivnění dílčích systémů. Dílčí dodávky Existuje i možnost realizovat projekt řadou dílčích dodávek, kdy i procesní a systémová integrace je jen jednou z řady dílčích dodávek. Tato forma vyžaduje extrémně silnou projektovou kancelář a je spojena s celou řadou jak projektových rizik, tak rizik z hlediska udržitelnosti projektu (např. s ohledem uzavírat řadu dílčích smluv o podpoře). Navíc tato forma neumožňuje efektivní implementaci formou pilotních projektů, a proto tuto formu dodávky nedoporučujeme. Požadavky na navazující projektovou dokumentaci Projekt tvoří střechu jednotné úrovně IS operačního řízení tím, že buduje ty procesy a části IS, které jsou společné pro všechny základní složky IZS: Ý CK jednotné datové prostředí FI RA OG GE Národní systém příjmu tísňového volání IS OŘ HZS IS OŘ PČR IS OŘ ZZS ZZS Ostatní složky IZS Orgány krizového řízení - orgány státní správy - orgány samosprávy Právnické osoby Fyzické osoby? PČR HZS ČR předpokládaná míra dosažení standardu? co je pro všechny složky IZS společné M TÉ YS Informační systém krizového řízení? část řešená tímto projektem S NÍ AČ RM FO IN op N er ár ač od ní ní ch s st tan ře da di rd se k IZ S Obr. 14: Ideové vymezení projektu samostatné projekty jednotlivých složek IZS (po krajích) To klade vysoké nároky na kompatibilitu návazných samostatných projektů realizovaných na úrovni složek a krajů jak směrem k tomuto zastřešujícímu projektu, tak mezi těmito dílčími projekty navzájem s ohledem na dosažení shodné úrovně služby pro zákazníka i technické úrovně IS IZS. Toto lze zajistit pouze zpracováním typového projektu, který přesně vymezí rámec dílčích řešení a jejich společné standardy. Doporučený obsah tohoto typového projektu z hlediska výstupů je uveden v příloze (viz Věcný obsah typového projektu). strana 67 (celkem 99 stran)

Fáze, etapy a harmonogram projektu Fáze projektu Projekt je rozdělen na tyto typové fáze: Přípravná fáze zaměřená na zpracování dokumentace, zajištění agendy projektu, projektové kanceláře a dodavatelské zajištění včetně organizace výběrových řízení. Realizační fáze faktické vybudování a zprovoznění IS IZS včetně funkčního, procesního a zátěžového testování až po cut-over a náběh ostrého provozu. Provozní fáze provozní využívání vybudovaného systému se zaměřením na zvyšování jeho výkonnosti a plné zvládnutí řízení změn. Obr. 15: Rámcový průběh projektu 2010 2011 2012 2013 Přípravná fáze Pilotní nasazení Roll-out Provozní fáze Specifikem realizační fáze tohoto projektu je pilotní nasazování. Tento postup je vynucen vysokou mírou integrace, kterou projekt musí zajistit i rozložením fyzického řešení do řady lokalit (krajů) a složek IZS. Etapy realizační fáze Realizační fáze bude probíhat 30 měsíců. Budou provedeny 3 pilotní implementace - systému MAIN, systému REM a systému MAIN včetně jeho řídící a integrační nadstavby. strana 68 (celkem 99 stran)

Přílohy strana 69 (celkem 99 stran)

Zdroje dat pro definici cílů projektu Tabulka 38: Následky MU podle společně zasahujících složek Zasahující složky Zásahů Počet úmrtí Počet zranění Zachráněno osob Uchráněný majetek HZS, PČR 22 239 67 811 209 9 399 719 HZS, ZZS 228 1 171 35 40 725 HZS, PČR, ZZS 11 687 829 13 252 2 892 4 078 905 Celkem IZS 34 154 897 14 234 3 136 13 519 349 Uchráněný majetek v mil. Kč. Tabulka 39: Následky MU podle typu MU Typ události Zásahů Počet úmrtí Počet zranění Zachráněno osob Uchráněný majetek DOPRAVNÍ NEHODA 18 005 748 13 289 2 598 1 745 POŽÁR 15 507 127 850 521 13 509 822 OSTATNÍ 642 22 95 17 7 782 Celkem 34 154 897 14 234 3 136 13 519 349 strana 70 (celkem 99 stran)

Tabulka 40: Následky MU typ požár podle času dojezdu statistika HZS Dojezd (minut) Počet úmrtí Počet zranění Zachráněno osob Uchráněný majetek Uchráněný majetek 0 0,006% 2,180% 23,100% 22,463% 1 980 1 0,093% 2,356% 16,520% 21,655% 1 909 2 0,208% 2,772% 13,230% 20,327% 1 792 3 0,411% 3,156% 9,940% 19,023% 1 677 4 0,498% 3,583% 6,650% 18,227% 1 607 5 0,610% 4,023% 4,100% 17,529% 1 545 6 0,692% 4,559% 3,200% 16,343% 1 441 7 0,811% 5,481% 2,900% 14,080% 1 241 8 1,120% 7,220% 2,670% 12,999% 1 146 9 1,812% 9,123% 2,440% 10,875% 959 10 1,981% 13,041% 2,210% 8,435% 743 11 2,030% 14,226% 1,980% 7,466% 658 12 2,110% 15,039% 1,750% 6,823% 601 13 2,111% 15,552% 1,520% 6,201% 547 14 2,112% 15,866% 1,290% 5,932% 523 15 2,114% 15,979% 1,215% 5,784% 510 16 2,115% 16,092% 1,140% 5,468% 482 17 2,116% 16,205% 1,065% 5,371% 473 18 2,117% 16,319% 0,990% 5,346% 471 19 2,118% 16,432% 0,916% 5,126% 452 20 2,119% 16,545% 0,841% 4,834% 426 21 2,121% 16,658% 0,766% 4,662% 411 22 2,122% 16,772% 0,691% 4,598% 405 23 2,123% 16,885% 0,616% 4,333% 382 24 2,124% 16,998% 0,541% 4,240% 374 25 2,125% 17,111% 0,466% 4,189% 369 26 2,126% 17,225% 0,391% 4,154% 366 27 2,128% 17,338% 0,317% 4,147% 366 28 2,129% 17,351% 0,242% 4,114% 363 29 2,130% 17,400% 0,167% 3,982% 351 30 2,131% 17,451% 0,092% 3,978% 351 strana 71 (celkem 99 stran)

Tabulka 41: Následky MU typ nehoda podle času dojezdu statistika ZZS Dojezd (minut) Případů Pravd. úmrtí Pravd. zranění 0 67 3,01% 81,3% 1 123 3,30% 81,4% 2 167 3,97% 81,5% 3 291 4,42% 81,8% 4 432 4,98% 82,3% 5 608 5,33% 82,6% 6 733 5,67% 83,4% 7 828 5,83% 83,7% 8 812 6,07% 84,9% 9 864 6,21% 85,5% 10 870 6,45% 86,9% 11 830 6,75% 87,8% 12 765 7,05% 88,5% 13 757 7,29% 89,0% 14 678 7,43% 89,1% 15 628 7,67% 89,2% 16 568 7,82% 89,7% 17 505 8,02% 90,1% 18 398 8,34% 90,6% 19 359 8,48% 91,0% 20 348 8,71% 90,2% 21 302 8,87% 91,1% 22 315 8,99% 91,7% 23 245 9,17% 92,5% 24 242 9,26% 93,2% 25 180 9,41% 94,7% 26 181 9,53% 95,2% 27 172 9,65% 96,9% 28 152 9,79% 97,7% 29 129 9,91% 98,2% 30 137 10,04% 98,6% strana 72 (celkem 99 stran)

Tabulka 42: Vazba doby dojezdu a vzdálenosti (počty událostí) statistika HZS Dojezd (minut) vzdálenost (km) 0 až 5 6 až 10 11 až 15 16 až 20 21 až 25 26 až 30 nad 30 Celkem 0 6 0 1 1 1 2 0 11 1 31 4 2 2 0 2 4 45 2 143 7 0 0 2 0 1 153 3 473 6 1 1 0 1 0 482 4 1143 20 4 2 1 0 1 1 171 5 1681 51 5 0 1 1 2 1 741 6 1815 92 5 3 0 0 1 1 916 7 1403 228 10 1 1 1 1 1 645 8 1049 364 36 7 2 0 0 1 458 9 667 506 54 13 2 0 1 1 243 10 392 588 84 10 4 1 0 1 079 11 247 505 133 16 3 2 0 906 12 164 412 170 13 4 1 2 766 13 115 317 244 29 4 2 0 711 14 88 251 239 38 3 2 1 622 15 67 171 241 45 8 0 1 533 16 61 134 228 82 8 3 3 519 17 30 117 196 90 18 1 3 455 18 27 52 137 98 21 2 2 339 19 16 51 127 90 16 3 2 305 20 14 43 97 85 30 0 3 272 21 12 37 66 76 27 4 4 226 22 17 24 44 64 18 3 3 173 23 9 12 37 54 22 1 3 138 24 5 19 36 31 22 6 3 122 25 10 12 41 36 31 8 2 140 26 9 12 25 32 25 11 1 115 27 5 9 12 20 21 11 2 80 28 3 11 17 21 25 5 3 85 29 5 4 12 9 10 7 3 50 30 3 8 18 7 8 12 4 60 nad 30 33 61 88 87 66 45 46 426 strana 73 (celkem 99 stran)

Tabulka 43: Současná doba dojezdu a doba dojezdu s navigací Dojezd (minut) Vysvětlivky: Počet událostí Kumulativně Procent AS-IS Navigace AS-IS Navigace AS-IS Navigace 0 11 11 11 11 0,1% 0,1% 1 45 45 56 56 0,3% 0,3% 2 153 153 209 209 1,2% 1,2% 3 482 482 691 691 3,8% 3,8% 4 1 171 1 172 1 862 1 863 10,4% 10,4% 5 1 741 1 745 3 603 3 608 20,0% 20,1% 6 1 916 1 929 5 519 5 537 30,7% 30,8% 7 1 645 1 688 7 164 7 225 39,8% 40,2% 8 1 458 1 503 8 622 8 728 47,9% 48,5% 9 1 243 1 304 9 865 10 032 54,8% 55,8% 10 1 079 1 154 10 944 11 186 60,8% 62,2% 11 906 1 002 11 850 12 188 65,9% 67,8% 12 766 883 12 616 13 071 70,1% 72,7% 13 711 739 13 327 13 810 74,1% 76,8% 14 622 688 13 949 14 498 77,6% 80,6% 15 533 569 14 482 15 067 80,5% 83,8% 16 519 483 15 001 15 550 83,4% 86,5% 17 455 404 15 456 15 954 85,9% 88,7% 18 339 295 15 795 16 249 87,8% 90,3% 19 305 254 16 100 16 503 89,5% 91,7% 20 272 196 16 372 16 699 91,0% 92,8% 21 226 172 16 598 16 871 92,3% 93,8% 22 173 163 16 771 17 034 93,2% 94,7% 23 138 130 16 909 17 164 94,0% 95,4% 24 122 120 17 031 17 284 94,7% 96,1% 25 140 89 17 171 17 373 95,5% 96,6% 26 115 81 17 286 17 454 96,1% 97,0% 27 80 56 17 366 17 510 96,5% 97,3% 28 85 62 17 451 17 572 97,0% 97,7% 29 50 47 17 501 17 619 97,3% 98,0% 30 60 45 17 561 17 664 97,6% 98,2% nad 30 426 323 17 987 17 987 100,0% 100,0% V tabulce jsou zachyceny počty událostí při současných dojezdových časech a výsledky simulace počtu dojezdových časů dojezdových časů s navigační podporou. Klíčové pro posuzování účinnosti jsou údaje kumulativně, tedy počet událostí, ke kterým záchranná složka dojede v příslušném čase nebo kratším. Např. v současné době do 10% minut dojede složka k 10 944 případů, v cílovém již k 11 186. strana 74 (celkem 99 stran)

Tabulka 44: Rychlost sestavení hovorů (rychlost sestavení v s) Rychlosti sestavení hovoru 112 150 158 155 prům. Průměrný měsíční počet volání 326 971 47 541 180 690 168 720 Rychlost sestavení hovoru (mobil) 0,77 1,20 2,55 2,05 1,64 Rychlost sestavení hovoru (pevná) 0,69 0,98 2,01 1,54 1,31 Současná průměrná rychlost 0,73 1,09 2,28 1,80 1,47 Cílová rychlost sestavení hovoru 0,70 0,72 1,12 1,18 0,93 Tabulka 45: Rychlost předání BI mezi složkami IZS v operačním řízení Předání BI mezi složkami IZS AS-IS Min. Max. Průměr TO-BE Vyhledání kontaktu 3,5 30,0 16,8 0 Sestavení spojení 4,5 5,5 5,0 2,5 Vyzvánění 3,0 3,0 3,0 0 Obsazeno, zavěsit, znovu 0,0 9,0 1,0 0 Vyzvednutí a sestavení 1,0 1,0 1,0 0 Představení se 5,0 5,0 5,0 0 Předání BI 50,0 150,0 100,0 0 Ukončení hovoru 1,0 1,0 1,0 0 Doplnění záznamu o vyrozumění 10,0 30,0 20,0 0 Celkem 78,0 234,5 152,8 2,5 0:02:33 0:00:03 Tabulka uvádí případy klasického předávání informací pomocí telefonu, nikoliv přes datovou větu prostřednictvím TCTV112. Uvádí ve sloupci AS- IS optimální časy předávání základních informací z tísňového hovoru na ostatní složky IZS, které lze dosáhnout pouze za předpokladu společného vyrozumění dvou složek. V praxi se často vyskytuje, že dochází k sekvenčnímu vyrozumívání a čas se pak znásobuje. strana 75 (celkem 99 stran)

Tabulka 46: Zdroje dat v knihovně projektu Následující zdroje dat jsou uvedeny v knihovně projektu: Dokument Soubor Zdroj - složka IZS Celkové pošty operačních středisek, pracovišť a pracovníků ISIZS_001_Pocty.xls HZS, PČR, ZZS Rychlosti sestavení hovorů ISIZS_004_HZS_Rychlosti_sestaveni_hovoru_COCO HZS Rychlosti odbavení hovorů M07.doc ISIZS_005_HZS_Odbavovani_hovoru.xls HZS Dojezdové vzálenosti ISIZS_006_HZS_Dojezdy_2008.xlsx HZS Náklady na provoz, údržbu a obnovu ISIZS_007_HZS_Naklady.xls HZS Statistika požárů 2008 ISIZS_010_HZS_Pozary_2008.xlsx HZS Statistika společných akcí složek IZS 2008 ISIZS_010_HZS_Spolecne_akce_2008.xlsx HZS Závislost následků požárů na čase dojezdu jednotek PO ISIZS_011_HZS_Poz_zavisl_nasled_20090428.doc HZS Závislost následků dopravních nehod na čase dojezdu ZS (studie) ISIZS_014_ZZS_Dopravni_nehody_eskalace.pdf ZZS Statistika dopravních nehod 2008 ISIZS_013_PCR_Pocty_dopravnich_nehod_2008.xls PČR Prodleva při příjmu sdílené informace ISIZS_017_PCR_Prodleva pýed nˇ informace jin PČR Dislokace dojezdových míst slo ce_pcr.xls ISIZS_ZZS_PCR_dislokace_dojezdovych_mist.xls PČR, ZZS strana 76 (celkem 99 stran)

Datové modely ICT Události Sdílení a vizualizace jsou postaveny na následujícím datovém modelu: Události ID události Čas založení události Storno události ID společné události ID události složek Událost vizualizovaná Viditelnost (znemožnění) Typ události Klasifikace události Stav události Číselník společný Stavy událostí TimeStamp Místo události Automatické identifikační a lokalizační údaje Závažnost události Číselník společný Závažnost události Událost pro součinnost Složka IZS Skutečnosti o události pro součinnost Oznamovatel Prvotní popis události Nahrávka Vyhledatelnost (znemožnění) Nahrávka identifikace Nahrávka soubor strana 77 (celkem 99 stran)

Účelový prostor Analýza technického řešení projektu Operační situace Sdílení a vizualizace jsou postaveny na následujícím datovém modelu: Operační situace vizualizovaná Místo události Příjem TV Operační úroveň Taktická úroveń Řešená událost nabyla příslušného rozsahu V pohledu V pohledu V pohledu Únik Společná operační situace - dopřesňuje dopřesňuje dopřesňuje Dopravní Událost s V pohledu V pohledu Požárem s nebezpečnýc vizualizace informací mezi KOPIS HZS ČR IOS PČR OPS ZZS ČR V pohledu nehoda s evakuací dopřesňuje dopřesňuje velkým h látek (z Povodně (dle Do pohledu (nebo (nebo (nebo dopřesňuje velkým velkého základními složkami IZS na úrovni velitel vedoucí lékař rozsahem objektu, z povodňové zanáší technologie technologie technologie velitel JPO počtem počtu operačního řízení opatření "VL" (ZZS 1000 a více vozidla) situace) GPS v případě GPS v případě GPS v případě "VZ" (HZS ČR) zranění (20 a obyvatel (nad "VO" (PČR) kraje) mxm ohrožení prohlášení prohlášení prohlášení více) 100) obyvatel vitelnosti) vitelnosti) vitelnosti) Místo události NSPTV - - - - - - NSPTV NSPTV NSPTV NSPTV NSPTV Kontaminovaná oblast Uzavřená oblast Pozice velitelského stanoviště Aktuální pozice VJ, VO, VL Pozice SaP složek IZS Dopravní situace Účelové prostory Číselník společný Typy SaP pro vizualizaci A - v případě Kontaminovaná oblast - nemožnosti - - A - - - - A - - splnit úkol VZ A - v případě A - v případě A - v případě nemožnosti nemožnosti Uzavřená oblast - nemožnosti A A - A A A A A úkol splnit úkol splnit splnit úkol VZ VO VL A - v případě A - v případě A - v případě A - v případě A - v případě A - v případě nemožnosti nemožnosti Místo velitelské stanoviště - nemožnosti že události že události že události A A A A A úkol splnit úkol splnit splnit úkol VZ velí velí velí VO VL A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS Aktuální pozice VS, VO, VL - - - - (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS SaP složek IZS - mobilní (např. - (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení hlídky pro uzavření komunikací) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) Zvýraznění směrů A - v případě dopravy,vstupních stanovišť do nemožnosti - - - - A - A A A A A oblasti a pevných stanovišť k úkol splnit uzavření oblasti (příjezd a odjezd VO - dekontaminační A - v případě stanoviště (osob a - nemožnosti - - A - - - - A - - splnit úkol VZ techniky) - shromaždiště A - v případě A - v případě A - v případě A - v případě - nemožnosti - - A - - - evakuace evakuace evakuace A evakuovaných osob splnit úkol VZ osob osob osob A - v případě - obvaziště - - - nemožnosti - - A A - - - - úkol splnit A - v případě A - v případě - místo pro oběti (exitus) - - - nemožnosti - - - A evakuace - - - úkol splnit osob A - GPS v - soustředěné SaP HZS ČR - mobilní - - - - - A A A A A technice A - GPS v A - GPS A - GPS A - GPS A - GPS A - GPS - soustředěné SaP PČR - - mobilní - - - - (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení technice viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) - soustředěné SaP ZZS A - GPS v - - - mobilní - - - A A A A A kraje technice Jiné další účelový prostot A - v případě A - v případě A - v případě - nemožnosti nemožnosti nemožnosti A A A A A A A A (dle potřeby) splnit úkol VZ úkol splnit úkol splnit Pozice SaP Pozice SaP složek IZS Typ SaP Aktuální pozice SaP RFSI Aktualizace vizualizace pohybu SaP interval 15-30 s. strana 78 (celkem 99 stran)

Identifikační a lokalizační údaje INFO 35 Poskytují data pro Automatické identifikační a lokalizační údaje Systémová signalizace Číslo volané Číslo volajícího Název operátora Pevná síť Jméno nebo název osoby neb... Adresa Kód UIADR Doplňkové informace Souřadnice Mobilní síť Informace o oblasti nebo zvláštním... Maják Útvar H H Složka Přidělení operačnímu středisku Rajonizace složky IZS strana 79 (celkem 99 stran)

Číselníky Složkami IZS jsou společně využívány následující číselníky: Klasifikace událostí Klasifikace události FHQ (ano/ne) Klasifikace události (věta) Číselník společný Typy událostí Typ události pro všechny složky Neodkladnost HZS (ano/ne) Neodkladnost PČR (ano/ne) Neodkladnost ZZS (ano/ne) Vozidel nákladních (---,N,A,99) Vozidel osobních (---,0,A,99) Osob zraněných (---,0,A,99) Osob ohrožených (---,0,A,99) Nutnost vyproštění (ano/ne) strana 80 (celkem 99 stran)

Typy událostí Číselník společný Typy událostí Typ události Název typu události Typ události A B C D E F G H I J K L M N O Název typu 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 PLANÝ POPLACH Stavy událostí Číselník společný Stavy událostí Stav události Stav Název stavu události události 1 Událost oznámena 2 Výjezd prvních SaP složky 3 Na místě první SaP složky 4 Požár lokalizován 5 Odjezd posledních SaP složky 6 Událost uzavřena OS Název stavu události Složka IZS Typ spolupráce složky Typ Název typu spolupráce spolupráce 1 Primární 2 Informovaná 3 Přizvaná Stav reakce složky Stav Název stavu reakce reakce 1 Výzva 2 Přijato Závažnost událostí Číselník společný Závažnost události Závažnost události Popis závažnosti situace Závažnost situace Popis závažnosti situace 0 Spolupráce dosud nevyžádána 1 Spolupracují 2 a více složek IZS 2 Stupeň poplachu v IZS 3 Stupeň poplachu v IZS Z Stupeň poplachu v IZS strana 81 (celkem 99 stran)

Účelový prostor Analýza technického řešení projektu Účelové prostory Účelové prostory - dekontaminační stanoviště (osob a techniky) - shromaždiště evakuovaných osob - obvaziště - místo pro oběti (exitus) - soustředěné SaP HZS ČR - soustředěné SaP PČR - soustředěné SaP ZZS kraje Jiné další účelový prostot (dle potřeby) Typy SaP pro vizualizaci Číselník společný Typy SaP pro vizualizaci Typ SaP Název SaP Složka IZS Typ SaP Název SaP Složka IZS 1 Hlídka PČR PČR 2 Velitel opatření PČR PČR 3 Vrtulník PČR PČR 4 Vodní prostředek PČR PČR 5 Mobilní požární technika HZS 6 Velitel jednotek HZS HZS 7 Vzdušný prostředek HZS 8 Vodní prostředek HZS HZS 9 Sanitka ZZS 10 Vedoucí lékař ZZS 11 Vrtulník LZS ZZS 12 Vodní prostředek ZZS ZZS 13 Ostatní SaP PČR PČR 14 Ostatní SaP HZS HZS 15 Ostatní SaP ZZS ZZS strana 82 (celkem 99 stran)

Konektivita Tabulka 47: Konektivita v síti ITS pro předpokládané lokality NSPTV Složka Kraj Adresa Stav Km PČR Policejní prezídium MV Praha, Olšanská 1951/4 10 Gbps PČR HL. m. Praha KŘ PČR, Praha 4, Kongresová 2 10 Gbps PČR Středočeský KŘ PČR Praha 5 Zbraslav RRL PČR Středočeský OŘ PČR Kladno, Havířská 632 155Mbps 32,9 PČR Jihočeský KŘ PČR Č. Budějovice, Lannova 193/26 10 Gbps PČR Plzeňský KŘ PČR Plzeň, Anglické nábřeží 1778/7 10 Gbps PČR Karlovarský KŘ PČR Karlovy Vary, I.P.Pavlova 26/1381 1 Gbps - původní objekt PČR Ústecký KŘ PČR Ústí n. Labem, Lidické nám. 9 10 Gbps PČR Liberecký KŘ PČR Liberec, Pastýřská 375/3 1 Gbps PČR Královéhradecký KŘ PČR Hr. Králové, Ulrichovo nám. 810/4 10 Gbps PČR Pardubický KŘ PČR Pardubice, Na Spravedlnosti 2516 1 Gbps PČR Vysočina KŘ PČR Jihlava, Vrchlického 2627/46 10 Gbps PČR Jihomoravský KŘ PČR Brno, Kounicova 687/24 10 Gbps PČR Zlínský KŘ PČR Zlín, nám. T. G. Masaryka 3218 1 Gbps PČR Olomoucký KŘ PČR Olomouc, Žižkovo nám. 600/4 10 Gbps - původní objekt PČR Moravskoslezský KŘ PČR Ostrava, 30. dubna 1682/24, 10Gbps - původní objekt Celkem PČR 32,9 HZS GŘ HZS Praha 4, Kloknerova 26/2295 ANO HZS HL. m. Praha Praha 2, Sokolská 62 ANO 2,1 HZS Středočeský Kladno, J.Palacha 1970 ANO, optický propoj na PČR, dále RRL 0,9 HZS Jihočeský České Budějovice, Pražská 52 b ANO 3,2 HZS Plzeňský Plzeň, Kaplířova 2726/9 ANO 1,6 HZS Karlovarský Karlovy Vary, Závodní 205/70 ANO HZS Ústecký Ústí nad Labem, Masarykova 342/380 ANO 3,1 HZS Liberecký Liberec, Šumavská 414/11 ANO 2,1 HZS Královéhradecký Hradec Králové-Kukleny, Pražská tř. 230/88 NE 6,0 HZS Pardubický Pardubice, Teplého 1526 ANO 5,0 HZS Vysočina Jihlava, Ke skalce 4960/32 NE 3,3 HZS Jihomoravský Brno, Cihlářská 978/26a ANO 1,0 HZS Zlínský Zlín, Přílucká 213 ANO 4,5 HZS Olomoucký Olomouc, Schweitzerova 222/91 ANO 5,4 HZS Moravskoslezský CTV u KŘ PČR Ostrava, 30. dubna 1682/24, ANO Celkem HZS - ZZS (trojúhelník) 38,2 ZZS Praha Korunní 98 Praha 10 NE, počítáno k PČR Olšanská 1,7 ZZS Středočeský kraj Vančurova 1544, Kladno NE, počítáno k HZS Kladno 0,6 ZZS Jihočeský kraj B.Němcové 1931/6 NE 1,7 ZZS Plzeňský kraj Edvarda Beneše 19Plzeň 3 NE 2,8 ZZS Karlovarský kraj Závodní 205, Karlovy Vary možno propoj LAN přes HZS (jeden objekt) ZZS Ústecký kraj Ústí nad Labem, Sociální péče 799/7A NE 4,6 ZZS Liberecký kraj Husova 976/37, Liberec 1 NE 1,5 ZZS Královehradecký kraj Hradecká 1690/2A nyní NE,po přestěhování propoj LAN přes HZS (jeden objekt) ZZS Pardubický kraj Průmyslová 450,Pardubice NE, vzdálenost zprůměrována 2,5 ZZS Kraj Vysočina Vrchlického 61, Jihlava NE 0,9 ZZS Jihomoravský nám. 28 října 23 Brno NE 1,5 ZZS Zlínský kraj Váchy 602 76001 Zlín NE 2,0 ZZS Olomoucký Aksamitova 8, Olomouc NE, předpoklad prostorová integrace 5,4 ZZS Moravskoslezský kraj CTV u KŘ PČR Ostrava, 30. dubna 1682/24 ANO Celkem PČR - ZZS CELKEM 25,2 96,3 strana 83 (celkem 99 stran)

Trasy nových přípojek Jsou uvedeny pouze rámcové trasy potřebné z hlediska výpočtu vzdáleností. Konkrétní trasy jednotlivých přípojek se mohou lišit až o +20%. Praha, PČR Olšanská Kladno, Havířská K současnému mikrovlnnému spoji 155 Mbps. Vzdálenost: 32,9 km Praha ZZS Korunní - Olšanská Vzdálenost: 1,7 km strana 84 (celkem 99 stran)

Kladno ZZS - PČR Vzdálenost: 0,6 km Plzeň ZZS - PČR Vzdálenost: 2,8 km strana 85 (celkem 99 stran)

Ústí nad Labem ZZS - PČR Vzdálenost: 4,6 km Liberec ZZS - PČR Vzdálenost: 1,5 km Pardubice ZZS - PČR Vzdálenost: vzdušně 1,5 km, trasa 4,6 km strana 86 (celkem 99 stran)

Zlín ZZS - PČR Vzdálenost: 2 km Olomouc uzel Žst ČD - Tabulový vrch Vzdálenost: 5,4 km Brno ZZS - PČR Vzdálenost: 1,5 km strana 87 (celkem 99 stran)

České Budějovice ZZS - PČR Vzdálenost: 1,7 km Konektivita ZZS HZS S ohledem na potřebu záložní trasy, ale i s ohledem na snížení provozu na uzlech PČR, je nutné vybudovat přímé propojení mezi operačními středisky ZZS a HZS. Praha HZS - ZZS Vzdálenost: 2,1 km Kladno HZS - ZZS Vzdálenost: 0,9 km strana 88 (celkem 99 stran)

České Budějovice HZS - ZZS Vzdálenost: 3,2 km Plzeň HZS - ZZS Vzdálenost: 1,6 km Ústí nad Labem HZS - ZZS Vzdálenost: 3,1 km strana 89 (celkem 99 stran)

Liberec HZS - ZZS Vzdálenost: 2,1 km Pardubice HZS - ZZS Vzdálenost: 5,0 km nejrychlejší strana 90 (celkem 99 stran)

Brno HZS - ZZS Vzdálenost: 1,0 km Zlín HZS - ZZS Vzdálenost: 4,5 km strana 91 (celkem 99 stran)