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

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

Analýza technického řešení projektu

Koncept TO-BE (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

Koncept TO-BE

Účel dokumentu

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

Termíny zpracování

Verze dokumentu

FINAL (akceptováno)

Zadavatel

Ministerstvo vnitra – Generální ředitelství Hasičského záchranného sboru České republiky

Projektový tým

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)

Za HZS dále spolupracovali

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

Za ZZS dále spolupracovali

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

Za PČR dále spolupracovali

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

Zpracovatel

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

Ing. Václav Kalenda, vedoucí realizačního týmu, BPS Business Process Services s.r.o.

Za zadavatele akceptoval

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.




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




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

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) Pohled

Standardy

Složka Národní standard operačních středisek IZS

Rozpočtová omezení

Nezvýšit provozní náklady IZS

Finance

Veřejný zájem

Zlepšit poskytování pomoci občanům při MU Zákazník

Procesy

Zvýšit účinnost operačního řízení

Procesy

Infrastruktura

Zajistit využití ITS MV všemi složkami IZS

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

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




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

Rychlejší a provázanější zásah

Vazba na ISKŘ

jak se dozvědět

jak integrovat jak zrychlit

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 Nároky na údržbu a obnovu nových technologií

Vyšší nároky na datové přenosy

jak je eliminovat Využít existující infrastrukturu

Lépe organizovat

Využít vhodné na údržbu nenákladné technologie

dlouhodobá udržitelnost


Efektivně využít externích služeb



Specifikace cílů Cíle v perspektivě Finance (rozpočtová omezení) Tabulka 1: Cíle a ukazatele ve finanční perspektivě Finance

Název

Cíl 01

Nezvýšit provozní náklady IZS

KPI 011

KPI 012

KPI 013

KPI 014

KPI 015

Počet pracovníků operačního řízení

Počet operačních středisek

Náklady na údržbu a obnovu ICT

Náklady na externí služby

Náklady na telekomunikační služby

Váha

0,3

0,3

0,1

0,1

0,2

Typ

Předstižný

Předstižný

Výsledkový

Výsledkový

Výsledkový

Jednotka měření

počet

počet

mil. Kč

mil. Kč

mil. Kč

Žádoucí trend

udržet

snížit

udržet

udržet

Složka IZS

Hodnota AS-IS

Hodnota TO-BE

HZS

588

588

PČR

1022

1022

ZZS

434

408

HZS

27

19

PČR

86

15

ZZS

35

22

HZS

12

12

HZS

164

164

PČR

610

610

ZZS

410

390

HZS

5,4

2,0

ZZS

97

65

snížit

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




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%

Počet úmrtí

13%

12%

Počet zranění

11%

10%

Zachráněno osob

9%

8%

Uchráněný majetek

7%

6% 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í.

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

4

Modře podbarvená je oblast ideální rychlosti zásahu s ohledem na minimalizaci následků mimořádné události.




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.

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




Cíle v perspektivě Procesy Tabulka 3: Cíle a ukazatele v perspektivě procesy Procesy

Název

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

26.4.2015

Snížení průměrné doby reakce na hrozící či nastalé bezpečnostní riziko

Cíl 04

Zvýšit účinnost tísňového volání

KPI 041

Rychlost sestavení telefonického hovoru

KPI 042

Podíl odrazených hovorů

KPI 043

KPI 044

Max. počet souběžně odbavovaných hovorů

Systémová možnost příjmu tísňového volání v cizích jazycích

Cíl 05

Zvýšit přesnost lokalizace MU

KPI 051

Dostupnost lokalizace tísňově volajícího z mobilních sítí pro jednotlivá operační střediska IZS

Cíl 06

Zrychlit zahájení činnosti všech nezbytných základních složek IZS

KPI 061

Čas do zahájení činnosti všech nezbytných složek IZS

Váha

Typ

Jednotka měření

Žádoucí trend

Složka IZS

Hodnota AS-IS

Hodnota TO-BE

1,0

Předstižný

minuty

snížit

všechny

13,48

10,50

Metrika

%

dosáhnout

všechny

0%

22%

0,2

Předstižný

čas

snížit

všechny

0:00:03

0:00:01

0,2

Předstižný

%

snížit

všechny

0,060%

0,002%

HZS

2

102

PČR

2

64

ZZS

2

62

PČR

NE

ANO

ZZS

NE

ANO

PČR

NE

ANO

ZZS

NE

ANO

všechny

0:02:33

0:00:03

0,4

0,2

1,0

1,0

Předstižný

Předstižný

Předstižný

Předstižný

počet

ano/ne

ano/ne

čas

zvýšit

vytvořit

vytvořit

snížit

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: = (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.

6

V systému Benefit nelze vybrat metriku26.04.15 a metriky nelze správně systémově provázat na podporovanou aktivitu.




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 AS-IS Ukazatel

Název

TO-BE

Jednotka pravděpodobnost

následek

pravděpodobnost

13,48

následek

10,50

KPI 031


minuty

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


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ů EU7. 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).




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




Cíle v perspektivě Zdroje (ICT) Tabulka 6: Cíle a ukazatele v perspektivě zdroje Zdroje

Název

Cíl 07

Zkrátit čas přepravy SaP na místo MU

KPI 071

Čas dojezdu na místo určení

Cíl 08

Zajistit využití ITS MV všemi složkami IZS

KPI 081

Komunikace mezi složkami IZS po ITS MV

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

Cíl 10

Zajistit jednotný GIS

KPI 101

Aplikovaný jednotný GIS

Cíl 11

Zajistit všestranný tok operačních dat

KPI 111

Aplikovaná technologická zařízení pro sdílení operačních dat

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

Cíl 13

Zajistit sdílení vizualizace operační situace

KPI 131

Aplikovaná technologická zařízení pro vizualizaci operační situace

Váha

Typ

Jednotka měření

Žádoucí trend

Složka IZS

Hodnota AS-IS

Hodnota TO-BE

1,0

Předstižný

čas

snížit

všechny

0:10:53

0:10:26

HZS

NE

ANO

1,0

Předstižný

ano/ne

vytvořit ZZS

NE

ANO

1,0

Předstižný

počet

zvýšit

všechny

0

44

1,0

Předstižný

počet

zvýšit

všechny

0

44

1,0

Předstižný

počet

zvýšit

všechny

0

44

1,0

Předstižný

počet

zvýšit

všechny

0

42

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




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.




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




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í Občan chce oznámit událost tísňovým voláním

IZS Standard Úroveň: 0 Přehled procesů

Zvolit linku a vytočit číslo tísňového volání

112

150

Občan

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í

Zajistit operační řízení

Obyvatelstvo varováno


Událost vyřešena

Komunikace s kompetentními orgány ukončena

Událost pro/z jiného kraje / složky IZS vizualizována

Součinnost vyžádána

Jiné zdroje informací k dispozici



Proces Zajistit příjem tísňového volání Model 3: Proces Zajistit příjem tísňového volání




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.




Model 5: Subproces Zajistit jazykovou podporu Je třeba jazyková podpora

Zajistit jazykovou podporu Úroveň: 2 Subproces

Jazyk volajícího rozpoznán? 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

Hovor přepojen na jiného operátora

SYS

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.




Model 6: Subproces Předat hovor na jinou složku IZS Předat hovor na jinou složku IZS

Jde o specifický hovor výhradně pro 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

Stav události

Číselník společný Stavy událostí

Mj. možnost bližší lokalizace události pomocí vyspělých GIS funkcí

společné číselníky s vazbou na číselníky jednotlivých složek

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

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

Sloučit událost

Operátor NSPTV

SYS

součinnost

Vyžádat součinnost SYS

Součinnost vyžádána

Událost pro součinnost

ano

Složka IZS


Zavěsit

Skutečnosti o události pro součinnost

možnost seskupování u hromadných událostí (dílčí události zachovány)

Je třeba předat hovor k dalšímu dovytěžení operačnímu řízení?


SYS

SYS

Hovor přepojen

Zavěsit

Oznamovatel

SYS

Hovor vytěžen a událost předána operačnímu řízení

Prvotní popis události

a samozřejmě nahrávání hovorů, vyhledávání a přehrávání nahrávek…


Rekapitulace změn v příjmu tísňového volání Přínosy jednotné technologie NSPTV jsou především následující:


Hovor přepojen na operační řízení

možnost předání hovoru do operačního řízení





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.




Proces Zajistit operační řízení Model 8: Proces Zajistit operační řízení




Model 9: Subproces Monitorovat operační situaci Jiné zdroje informací k dispozici

Událost pro/z jiného kraje / složky IZS vizualizována

Monitorovat operační situaci - standard Úroveň: 2 Subproces

Monitorovat bezpečnostní situaci

Dispečer OŘ

Monitorovat dopravní situaci

Založit událost

Dispečer OŘ

Událost vyžaduje nasazení SaP


Dispečer OŘ

Monitorovat stav SaP a zdrojů a komunikova...

Dispečer OŘ

Monitorovat ostatní zdroje informací

Dispečer OŘ

Potvrdit převzetí události

Dispečer OŘ



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




Model 11: Subproces Nasadit a řídit SaP - varianta ZZS




Model 12: Subproces Nasadit a řídit SaP - varianta PČR




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

Odvysílání zajištěno Zvolit přijímače

Dispečer OŘ

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


Dispečer OŘ



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




Obr. 7: Vizualizace operační situace Operační situace vizualizovaná

Příjem TV

Operační úroveň V pohledu

Místo události

Místo události

Kontaminovaná oblast


Uzavřená oblast

Uzavřená oblast

Místo velitelské stanoviště

Pozice velitelského stanoviště

Účelové prostory


Číselník společný Typy SaP pro vizualizaci

Řešená událost nabyla příslušného rozsahu

V pohledu dopřesňuje velitel JPO "VZ" (HZS ČR)

Dopravní V pohledu V pohledu nehoda s dopřesňuje dopřesňuje velkým velitel vedoucí lékař počtem opatření "VL" (ZZS zranění (20 a "VO" (PČR) kraje) více)

Požárem s velkým rozsahem 1000 a více mxm

Únik Událost s nebezpečnýc evakuací h látek (z Povodně (dle velkého objektu, z povodňové počtu vozidla) situace) obyvatel (nad ohrožení 100) obyvatel

prohlášení vitelnosti)



-

-

-

-

-

-

NSPTV

NSPTV

NSPTV

NSPTV

NSPTV

-

A - v případě nemožnosti splnit úkol VZ

-

-

A

-

-

-

-

A

-

-

A

A

A

A

-


-


-

-

SaP složek IZS - mobilní (např. hlídky pro uzavření komunikací)

-

A - GPS (prohlášení viditelnosti)

-

-

Účelový prostor

Dopravní situace

Taktická úroveń

V pohledu

NSPTV

Aktuální pozice VS, VO, VL

Zvýraznění směrů dopravy,vstupních stanovišť do oblasti a pevných stanovišť k uzavření oblasti (příjezd a odjezd složek IZS, dálková doprava vody), - dekontaminační

Aktuální pozice VJ, VO, VL

Pozice SaP složek IZS

V pohledu

dopřesňuje dopřesňuje dopřesňuje Společná operační situace KOPIS HZS ČR IOS PČR OPS ZZS ČR vizualizace informací mezi (nebo (nebo (nebo základními složkami IZS na úrovni Do pohledu zanáší technologie technologie technologie operačního řízení GPS v případě GPS v případě GPS v případě

stanoviště (osob a techniky) - shromaždiště evakuovaných osob

-

- obvaziště

-

-

A - v případě nemožnosti splnit úkol VZ A - v případě nemožnosti splnit úkol VZ -

A - v případě A - v případě nemožnosti nemožnosti A A A úkol splnit úkol splnit VO VL A - v případě A - v případě A - v případě A - v případě A - v případě nemožnosti nemožnosti že události že události že události A úkol splnit úkol splnit velí velí velí VO VL A - GPS A - GPS A - GPS A - GPS (prohlášení (prohlášení (prohlášení (prohlášení viditelnosti) viditelnosti) viditelnosti) viditelnosti) A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti)

A

A

A

A

A - GPS (prohlášení viditelnosti) A - GPS (prohlášení viditelnosti)




A

A

A

A

-

A

-

A - v případě nemožnosti úkol splnit VO

-

-

A

-

A

-

-

A

-

-

-

-

-

A

-

-

-

-

-

A

A

-

-

A - v případě nemožnosti úkol splnit A - v případě nemožnosti úkol splnit

A - v případě A - v případě A - v případě evakuace evakuace evakuace osob osob osob -

-

-

A

-

- místo pro oběti (exitus)

-

-

-

-

-

-

A

A - v případě evakuace osob

-

-

-

- soustředěné SaP HZS ČR

-

A - GPS v mobilní technice

-

-

-

-

-

A

A

A

A

A

- soustředěné SaP PČR

-

-


-

-

-

-






- soustředěné SaP ZZS kraje

-

Jiné další účelový prostot (dle potřeby)

-

A - GPS v mobilní technice A - v případě A - v případě A - v případě nemožnosti nemožnosti nemožnosti splnit úkol VZ úkol splnit úkol splnit

-

-

-

A

A

A

A

A

A

A

A

A

A

A

A

A



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é)




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


100%

100%

100%

Spojená volání

83%

83%

83%

Přijatá volání

85%

67%

85%


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

Linky MAIN1 Spojit hovor (operátor)

Zavěsit MAN1 SYS

SYS

99 0,17

Hovor nespojen (operátor)

0,83

Spojená volání Spojit hovor MAIN1

0

SYS 0,33

Hovor nespojen

0,67

Přijatá volání

0

Navázat kontakt s volajícím a přijmout prvotní informace

0,74

Hovor nevytěžován

0,26

Vytěžovaná volání

Vytěžit hovor

0

1,00

Hovor ukončen


0,30

Událost vizualizována

Operátor HZS



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


100%

100%

100%

Spojená volání

83%

83%

83%

Přijatá volání

85%

67%

85%


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


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

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 18 19 20 21 22 23

387 380 324 287 249 243 212

555 532 483 383 294 181 114

339 338 334 277 207 174 144

600

500

400

PČR HZS ZZS

300

200

100

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

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)

Hodina 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

PČR

HZS

ZZS

3% 2% 2% 2% 1% 2% 2% 4% 5% 5% 5% 5% 6% 6% 6% 6% 6% 6% 6% 5% 4% 4% 4% 3%

1% 1% 1% 1% 1% 1% 2% 3% 5% 6% 6% 6% 7% 7% 7% 7% 7% 7% 7% 6% 5% 4% 2% 1%

2% 2% 1% 1% 1% 1% 3% 4% 5% 5% 5% 5% 6% 6% 6% 6% 6% 6% 6% 6% 5% 4% 3% 3%




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 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23


Běžná 85 63 49 46 49 71 147 198 379 441 474 491 519 536 540 539 554 555 532 483 383 294 181 114

Mimořádná 121 103 83 111 81 62 128 268 506 1 130 1 630 1 750 1 469 1 280 1 001 945 869 840 870 817 686 414 309 176

Navýšení 142% 163% 171% 240% 166% 87% 87% 135% 134% 256% 344% 356% 283% 239% 185% 175% 157% 151% 164% 169% 179% 141% 170% 154%



Tabulka 14: extrémní zatížení - nejvíce zatížený kraj po hodinách

Pardubický 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Běžná 9 4 2 2 2 3 9 14 20 26 25 18 24 24 24 22 25 21 23 18 14 14 8 6

Mimořádná 3 2 5 6 8 5 8 10 9 24 236 207 91 50 58 36 51 39 42 82 37 13 10 12

Navýšení 34% 45% 213% 387% 374% 167% 90% 72% 44% 91% 940% 1148% 384% 209% 242% 167% 203% 183% 185% 456% 258% 91% 123% 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)

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

Byly zvoleny tyto simulační metody: 

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

Praha

12

15

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




Simulace probíhala v tomto modelu: Model 16: Simulace extrémní situace celková - výchozí zadání 112, 150 EMMA

2 219

618

158 mimořádné

510

155 mimořádné

Vstupní linky Spojit hovor (JTS) SYS

389

3 347

Spojit hovor SYS 2 770

1 056

0000:05:05:35

1 046

Hovor ukončen

935

HZS Navázat kontakt s volajícím a přijmout prvotn...

Operátorské pracoviště HZS 102

0000:05:27:09

779

Operátorské pracoviště PČR 64

PČR Navázat kontakt s volajícím a přijmout prvotn...

0000:04:37:55

ZZS Navázat kontakt s volajícím a přijmout prvotn...

710

781

661

HZS Vytěžit hovor

PČR Vytěžit hovor

ZZS Vytěžit hovor

169

617

550

148

Událost pro vizualizaci

1 488

Hovor ukončen

148


764

Hovor ukončen

Vstupní linky


Vizualizovat událost

Zavěsit MAIN

SYS SYS

3 294

148

Operátor ZZS směna 116

389

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

Zdroj

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.




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 Podíl Počet čekání (s) přijatých přijatých hovorů hovorů 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 18 19 20 22 23 24 25 26 27 28

91,73% 91,96% 92,67% 92,99% 93,38% 94,17% 94,56% 94,80% 95,19% 95,90% 96,22% 96,45% 97,01% 97,56% 97,95% 98,27% 98,58% 98,82% 99,05% 99,29% 99,37% 99,45% 99,61% 99,68% 99,84% 99,92% 100,00%

1164 1167 1176 1180 1185 1195 1200 1203 1208 1217 1221 1224 1231 1238 1243 1247 1251 1254 1257 1260 1261 1262 1264 1265 1267 1268 1269

100,00%

99,00%

98,00%

97,00%

96,00%

95,00%

94,00%

93,00%

92,00%

91,00% 0

5

10

15

20

25

30

délka čekání (s)

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) 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 27 28 31 34 35

Podíl přijatých hovorů 71,79% 73,39% 74,08% 76,15% 76,83% 79,13% 80,50% 81,88% 83,49% 84,86% 86,70% 87,16% 89,22% 89,91% 90,37% 91,74% 93,58% 94,27% 94,72% 94,95% 95,64% 96,33% 97,25% 97,48% 97,94% 98,39% 98,85% 99,08% 99,31% 99,77% 100,00%

Počet přijatých hovorů 313 320 323 332 335 345 351 357 364 370 378 380 389 392 394 400 408 411 413 414 417 420 424 425 427 429 431 432 433 435 436

100,00%

95,00%

90,00%

85,00%

80,00%

75,00%

70,00% 0

10

20

30

40


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)


Koncept TO-BE (FINAL) Délka Podíl Počet čekání (s) přijatých přijatých hovorů 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


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

Tabulka 19: Výsledky simulace - počet pracovišť (standard = Optimálně) PČR

Kraj

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

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

Č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%).




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

Počet zpracování

Celková doba Celková doba dynamické zpracování prodlevy

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


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


369

0

0

7 223

0

35 116

Zavěsit MAIN

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ě) Pracoviště

Zpracované funkce


Stupeň vytížení


3 355

235 147

63%


1 638

149 396

63%


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


Spojit hovor (JTS)

11 125

620 570

0

Spojit hovor

9 190

0

7 792


3 977

443 476

219 796

HZS Vytěžit hovor

1 009

116 713

136 500


1 329

114 355

72 947


1 043

93 200

151 348


1 303

121 269

68 067

ZZS Vytěžit hovor

1 047

103 228

149 848

Zavěsit MAIN

10 952

0

54 594

512

0

0


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




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 Stupeň vytížení zpracování


4 986

356 296

96%


2 372

224 295

95%


2 350

217 915

96%

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

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 Zajistit jazykovou podporu EN/DE

6 609 26

110 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

529

9

3 965

66

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

3 099

44

186

9

Provést analytický výpočet v GIS (nad více vrstvami) Provést výpočet v GIS (nad externími daty) Předat hovor v NSPTV

Předat událost do OŘ na rozhraní Předat hovor do OŘ

Celkový max. počet připojených operátorských pracovišť činí 300 při zachování stanovených odezev.

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




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á

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 18 19 20 21 22 23

621 611 520 460 400 390 340 10560

1078 1033 939 744 572 352 222 15002

559 557 551 457 341 287 237 9042

CELKEM

12

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

Složka

13

Počet

Aktivity


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%

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

13

Celková doba zpracování uváděna v s.




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 Aktivity

14

Počet zpracování

Celková doba dynamické prodlevy


Spojit hovor (JTS)

2 268

0

0

Spojit hovor

1 878

0

1 589


551

344

30 462

HZS Vytěžit hovor

158

90

21 767


459

3 257

24 980


374

3 450

53 304


391

1 864

21 822

ZZS Vytěžit hovor

321

2 614

46 716


110

0

0

2 175

0

10 675

Zavěsit MAIN

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

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




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 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

PČR

HZS

ZZS

14 11 9 8 7 8 10 17 23 24 26 26 27 28 29 29 29 28 27 23 21 18 18 15

5 4 3 3 3 4 9 12 22 25 27 28 29 30 30 30 30 20 30 27 22 17 11 7

9 9 7 6 7 7 14 18 22 24 24 24 25 26 26 26 27 27 27 27 22 17 14 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.




Krajské ZZS a přelivy Pro jednotlivé krajské ZZS je vhodné toto obsazení:

ZZS s obsazením krajů

Karlovarský

Královehradecký

Liberecký

Moravskoslezský

Olomoucký

Pardubický

Plzeňský

Praha

Středočeský

Ústecký

Vysočina

Zlínský

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

ZZS minimální

Jihomoravský

Hodina

Jihočeský

Tabulka 29: Výsledky simulace pro běžné zatížení - kraje ZZS s min. obsazením

9 9 7 6 7 7 14 18 22 24 24 24 25 26 26 26 27 27 27 27 22 17 14 12

14 14 14 14 14 14 17 19 23 24 24 24 27 29 29 29 29 29 29 29 23 19 18 16

1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 1 1 1 1

1 1 1 1 1 1 1 2 2 3 3 3 3 3 3 3 3 3 3 3 2 2 2 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 1

1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 1 1 1 1

1 1 1 1 1 1 2 3 4 4 4 4 4 4 4 4 4 4 4 4 4 3 2 2

1 1 1 1 1 1 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 1 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í: Moravskoslezský

Olomoucký

Pardubický

Plzeňský

Praha

Středočeský

Ústecký

Vysočina

Zlínský

16 16 15 14 15 15 19 21 31 31 31 31 31 35 35 35 35 35 35 35 31 20 19 18

Liberecký

14 14 14 14 14 14 17 19 23 24 24 24 27 29 29 29 29 29 29 29 23 19 18 16

Královehradecký

9 9 7 6 7 7 14 18 22 24 24 24 25 26 26 26 27 27 27 27 22 17 14 12

ZZS s ZZS obsazením bez přelivů krajů

Karlovarský

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

ZZS minimální

Jihomoravský

Hodina

Jihočeský

Tabulka 30: Výsledky simulace pro běžné zatížení - kraje ZZS bez přelivů

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1

1 1 1 1 1 1 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2

1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 1 1 1 1

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 1 1 1 1

1 1 1 1 1 1 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1

2 2 2 1 2 2 3 3 4 4 4 4 4 5 5 5 5 5 5 5 4 3 3 2

2 2 1 1 1 1 2 3 3 3 3 3 3 4 4 4 4 4 4 4 3 2 2 2

1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1

1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1

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




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




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 cyklu17 včetně jejich lokalizace18 mezi složkami IZS.

4.

Zajistit sdílení informací umožňujících společnou vizualizaci operační situace19 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ároky20 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 MV21.

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

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.




Cílová architektura IS Cílová architektura IS/IT musí být vystavěna na konceptu SOA24 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

KTTP

ZZS Dispečer

MediumSoft

Praha

Liberecký

Zlínský

Sběrnice služeb (ESB/Message Broker) ISIZS

IS Výjezd

DISPEČER Maják158

HZS

P ČR

S.O.S.

PROFIA

Jihomoravský, Ústecký, Vysočina, Středočeský, Jihočeský, Plzeňský, Pardubický Hradecký, Karlovarský, Olomoucký

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 BPMS29



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é funkcionality30 a bude nutný zákaznický vývoj, ať už úplný nebo částečný

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

25

Business Process Management Suite.

26

Business Intelligence.

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

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ů). 28

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






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

uživatelé

požadavky operačního řízení

Modelování procesů

Monitoring

Procesní modely (BPMN)

IS specialisté

Design IS

IS modely (UML)

Vývoj služeb

Orchestrace služeb

může se podílet řada různých dodavatelů

Zveřejnění služeb (WS)

Nastavení BPE (BPEL)

Procesní server

Sběrnice služeb ESB

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 postupem31: 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 komponent32 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á.

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

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




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

Kolaborační / WF server

Portál

Engine pro řízení pravidel BRE

Sběrnice služeb (ESB/Message Broker) ISIZS Správa identit

Řízení přístupu ke službám

DB 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žeb34. 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.

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

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




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.

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




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 Operátorský IS

PBX

Operátorský IS


F

Založit událost

F

Spojit operátora

F

F

F

F

F

F

F

F

Zařadit do čekací fronty

F

Sloučit událost

F

Vyjmout z čekací fronty

F

Odeslat událost

F

F

Automaticky identifikovat jazyk volajícího

F

Vyžádat součinnost

F

Poskytnout stav operátora a volání

F


Vyhledat operátora složky podle kraje volání a jazyka F

Vyhledat operátora s příslušnou jazykovou kvalifikací F

Administrovat události

F


Přehrát hlásku představení operátora

F

Správa čísel

F

Spravovat seznamy a pravidla čísel

Vizualizovat oblast volání

F

F

Lokalizovat MU pomocí GIS

F

Správa kontaktů

F

F

F

Operátorský IS


Nahrát hlásku

F

Podpora automatizace reportingu chybových stavů

Spravovat kontakty

F

Provést kontrolu speciálního seznamu čísel a IMEI


Vyhledat tlumočníka

F

Vyhledat jiný kontakt

F

Určit rajonizaci

F

Podpora výkonu služby

Nahrát hovor

F

F

Vyhledat hovor

F

Exportovat hovor

F

Aktualizovat událost

Přehrát záznam do konference

F

Vyhledat volného operátora ve zvolené složce F

Vizualizace (GIS)

Přehrát výstrahu

Přijmout událost

Zavěsit

F

F

F

Editovat událost

F


Klasifikovat událost


Správa hlásek a nahrávání

Definovat pravidla distribuce hovorů

Operátorský IS

GIS

Spravovat operátory a pracoviště

Validovat událost

Vytvořit příposlech

F

Správa pravidel přidělování hovorů

Správa událostí

PBX služby

Nahrávání hovorů

Vizualizace událostí vzniklých ke stejnému číslu F



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

Operátorské pracoviště

REMOTE IP VPN

Router

IP telefon

LAN (separovaná) Operátorský IS Klient

Digitální telefon

UA Operátorské pracoviště Vstupní linky

SDH

SS7

CDD

IP telefon

LAN (separovaná)

PRA Operátorský IS Klient

MAIN

Aplikační server Dispečerské aplikace

Operátorský IS Serverová část

Další servery...

ESB Další služby...



Server CTI

CTI

PCM

STA

SDH-SDH

PBX

Model 21: Architektura NSPTV – IP telefonie ITS páteř (10GE/1 GE) QoS

Router

Router

Sw itch 2x (QoS)

LAN (separovaná)

Router

FW

LAN složky

Sw itch 2x (QoS)

Router

LAN (separovaná)

FW

Operátorská pracoviště

112 150 155 158

PBX

ESB

GIS

LAN složky

Operátorská pracoviště


ESB Repository

CallMgr

PBX (stávající)

Aplikační/DBMS s erver GIS


sig

VTS (PSTN) odchozí

MAIN

BPE/BRE CallMgr/ server Signalling server

CTI

Aplikační/DBMS s erver GIS

IP TRUNK

Základna geodat lokalita

IP TRUNK

PBX (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 linek37. 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

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




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.




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é kompozice

Nalezení nejbližší entity

Výpočet 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 kompozice

Nalezení prvků v okolí

Analýza 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é složky entit

Analýza 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 geodat HZS

Základna geodat České Budějovice

Základna geodat Karlovy Vary

Základna geodat Plzeň

Základna geodat PČR

Základna geodat Ústí nad Labem

Základna geodat Brno

Základna geodat Jihlava

Základna geodat ZZS

Sběrnice služeb (ESB/Message Broker) ISIZS

Základna geodat Pardubice

Základna geodat Praha

Základna geodat Liberec

Základna geodat Kladno

Základna geodat Hradec Králové

Základna geodat Olomouc

Základna geodat Ostrava

Základna geodat 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 geodat39: 

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.






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 geodat40



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.

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

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.




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é situace41: 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ř

Existující

HZS

2.

páteř

PČR

bude budováno

bude budováno

ZZS

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ř

Existující

páteř

PČR

bude budováno

HZS

ZZS

LAN

3.

41

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.

Uváděné přenosové kapacity odpovídají času vzniku dokumentu (ITS je průběžně posilována).




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




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.




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

Dimenze dopadu rizika

Označení

Úroveň služby

S

Náklady

N

Čas (zpoždění)

T

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

Úroveň dopadu Žádný Neznatelný Řešitelný Vážný Kritický Neřešitelný

Váha 1 2 3 4 5 6

Standardní eskalační / emergency procedura Běžná úroveň Reporting na operativní úrovni (PT) Reporting na řídící úroveň (ŘV), opatření na operativní úrovni (PT) Reporting na zadávací úroveň, opatření na řídící úrovni (ŘV) Nutnost redefinice projektu Zastavení projektu

Pro stanovení četnosti výskytu rizik byla stanovena 6 bodová škála jejich pravděpodobnosti: Tabulka 33: Pravděpodobnost rizik

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

Pro hodnocení závažnosti rizika byl zvolen tento způsob výpočtu: 

Závažnost = maximální úroveň dopadu v libovolné dimenzi x pravděpodobnost

Tabulka 34: Závažnost rizik

Hodnocení závažnosti rizika Méně závažné Závažné Velmi závažné

Výše pod 10 10 až 14 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.




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

Dopady rizika - bez opatření Oblast

Riziko

Cut-over

Požadovaná redukce dopadů rizika

Služba

Náklady

Čas

Max. dopad

Selhání příjmu TV po přesměrování na nový systémz důvodu nefunkčnosti technologie

6

1

4

6

3

18

5

1

2

5

2

10

Cut-over

Omezení funkcionality TCTV po přesměrování na nový systém

4

1

3

4

4

16

4

1

2

4

2

8

Cut-over

Selhání funkcionality GIS po přesměrování na nový systém

3

1

2

3

5

15

3

1

2

3

2

6

Cut-over

Selhání funkcionality sdílení dat po přesměrování na nový systém

3

1

2

3

5

15

3

1

2

3

2

6

Cut-over

Selhání integrace NSPTV s IS OŘ po přesměrování na nový systém

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

Nedokončené nebo nevyhovující technologické prostory pro MAIN

1

1

4

4

4

16

1

1

2

2

2

4

Připravenost

Nedokončené nebo nevyhovující technologické prostory pro REMOTE

1

1

3

3

5

15

1

1

2

2

2

4

Připravenost

Nedokončené nebo nevyhovující prostory pro operátorská pracoviště

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

4

3

3

4

4

16

1

3

3

3

3

9

1

3

3

3

3

9

1

3

3

3

3

9

1

4

4

4

4

16

1

4

4

4

2

8

1

3

3

3

4

12

1

3

3

3

3

9

1

3

3

3

5

15

1

3

5

5

2

10

Implementace

Nízká kvalita hovorů nebo ztráta signalizace v NSPTV

Implementace Závady v nahrávání hovorů Implementace

Závady v integraci IS OŘ - volání služeb sdílení událostí

Implementace Závady ve funkčnosti monitoringu Implementace

42

Závady v integraci IS OŘ - nemožnost volání pokročilých funkcí GIS

Zelená – méně závažná, žlutá závažná, červená – velmi závažná.


Výskyt

Závažnost

Služba

Náklady

Čas

Max. dopad

Výskyt

Závažnost



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

S1

Úroveň služby Standardní

více než 98%

běžně

Dopad na zákazníka žádný

S2

Přechodná

do 2%

během extrémního měsíčního zatížení a/nebo náběhu

neznatelný

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ů

omezující

S5 S6

Kritická Vyloučená

do 0,0001% do 0,000001%

při katastrofické situaci - fyzickém zničení části infrastrukutryomezující zásadní vyloučená služba nefunkční služba nefunkční

Označení

Pravděpodobnost

Možnost výskytu


znatelný

Dopad na obsluhu žádný minimální



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


A

A

A

N

N

N

Provést automatickou lokalizaci GSM

A

A

A

N

N

N

Provést automatickou lokalizaci pevná

2s

5s

7s

nad 7 s

N

N


0s

5s

5s

10 s

30 s

N


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


A

A

A

N

N

N

Vizualizovat oblast volání GIS - prvotní

0,3 s

1s

3s

10 s

nad 10 s

N

Překreslit polohu v GIS

0,3 s

1s

3s

10 s

nad 10 s

N

Předat hovor v NSPTV - technologická prodleva

0,5 s

1s

5s

30 s

nad 30 s

N

3s

6s

nad 6 s

nad 6 s

nad 6 s

nad 6 s

0,5 s

1s

5s

30 s

nad 30 s

N

Předat hovor FHQ - lidská prodleva

0s

0s

3s

nad 3 s

nad 3 s

nad 3 s

Spojit hovor člověk - člověk (od přidělení operátoru)

3s

6s

6s

nad 6 s

nad 6 s

N

0,3 s

0,6 s

3s

6s

nad 6 s

N

1s

3s

10 s

30 s

nad 30 s

N

0,3 s

0,6 s

3s

6s

nad 6 s

N

Vizualizovat událost pro ostatní operátory NSPTV

3s

6s

10 s

30 s

N

N

Vyžádat součinnost - technologická prodleva

3s

6s

10 s

30 s

N

N

Vyžádat součinnost - lidská prodleva (zahájeno řešení)

9s

15 s

30 s

nad 30 s

nad 30 s

nad 30 s

Předat událost do OŘ na rozhraní

3s

6s

10 s

30 s

N

N

Hledat nejbližší objekt podle polohy v GIS

1s

3s

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

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

Předat hovor v NSPTV - lidská prodleva Předat hovor FHQ - technologická prodleva

Hledat v místopisu - omezeně Hledat v místopisu - neomezeně (3 znaky) Zajistit odezvu aplikace pro příjem TV

Provést výpočet v GIS (nad externími daty)




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




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




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




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.




Přílohy




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


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

Typ události

Zásahů

Počet úmrtí

Počet zranění

Zachráněno osob


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

Uchráněný majetek – v mil. Kč. Tabulka 39: Následky MU podle typu MU




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



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




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%




Tabulka 42: Vazba doby dojezdu a vzdálenosti (počty událostí) – statistika HZS

vzdálenost (km)

Dojezd (minut)

0 až 5

6 až 10

11 až 15

16 až 20

21 až 25

26 až 30

nad 30

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


Celkem



Tabulka 43: Současná doba dojezdu a doba dojezdu s navigací

Počet událostí

Kumulativně

Procent

Dojezd (minut)

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%

Vysvětlivky: 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.




Tabulka 44: Rychlost sestavení hovorů (rychlost sestavení v s)

Rychlosti sestavení hovoru

112

150

158

155

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

Průměrný měsíční počet volání

prům.

Tabulka 45: Rychlost předání BI mezi složkami IZS v operačním řízení

AS-IS Předání BI mezi složkami IZS

TO-BE

Min.

Max.

Průměr

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.




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ů Rychlosti odbavení hovorů

ISIZS_004_HZS_Rychlosti_sestaveni_hovoru_COCO HZS 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‚ slo§ce_PCR.xls ISIZS_ZZS_PCR_dislokace_dojezdovych_mist.xls

Dislokace dojezdových míst


PČR PČR, ZZS



Datové modely ICT Události Sdílení a vizualizace jsou postaveny na následujícím datovém modelu: Události

Čas založení události

ID 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

Událost pro součinnost

Místo události


Závažnost události

Číselník společný Závažnost události

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




Operační situace Sdílení a vizualizace jsou postaveny na následujícím datovém modelu: Operační situace vizualizovaná

Příjem TV

Operační úroveň V pohledu

V pohledu

Taktická úroveń

Místo události

Místo události Kontaminovaná oblast


Uzavřená oblast

Pozice velitelského stanoviště

Dopravní situace



-

-

-

-

-

NSPTV

NSPTV

NSPTV

NSPTV

NSPTV

-


-

-

A

-

-

-

-

A

-

-

A

A

A

A

A

A

A

A





A

A

A

A

-

A

-

-

Aktuální pozice VS, VO, VL

-

SaP složek IZS - mobilní (např. hlídky pro uzavření komunikací)

-

-

A - v případě A - v případě A - v případě nemožnosti nemožnosti nemožnosti 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 nemožnosti že události že události že události A úkol splnit úkol splnit splnit úkol VZ velí velí velí VO VL A - GPS A - GPS A - GPS A - GPS (prohlášení (prohlášení (prohlášení (prohlášení viditelnosti) viditelnosti) viditelnosti) viditelnosti) A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS A - GPS (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení (prohlášení viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti) viditelnosti)

-

A - v případě nemožnosti splnit úkol VZ A - v případě nemožnosti splnit úkol VZ

A - v případě nemožnosti úkol splnit VO

-

-

A

-

A

-

-

A

-

-

-

-

-

A

-

-

-

-

-

A

A

-

-

-

-

-

-

A

A - v případě evakuace osob

-

-

-

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

-


-

-

-

-

-

A

A

A

A

A

- soustředěné SaP PČR

-

-


-

-

-

-






-

- soustředěné SaP ZZS kraje

-

Jiné další účelový prostot (dle potřeby)

-

Účelové prostory

Pozice SaP Pozice SaP složek IZS

Typ SaP

Aktuální pozice SaP

RFSI

Aktualizace vizualizace pohybu SaP – interval 15-30 s.


Únik Událost s nebezpečnýc evakuací h látek (z Povodně (dle velkého objektu, z povodňové počtu vozidla) situace) obyvatel (nad ohrožení 100) obyvatel

-

-

Účelový prostor

Číselník společný Typy SaP pro vizualizaci

Pozice SaP složek IZS

Požárem s velkým rozsahem 1000 a více mxm


Místo velitelské stanoviště

Aktuální pozice VJ, VO, VL

V pohledu dopřesňuje velitel JPO "VZ" (HZS ČR)

Dopravní V pohledu V pohledu nehoda s dopřesňuje dopřesňuje velkým velitel vedoucí lékař počtem opatření "VL" (ZZS zranění (20 a "VO" (PČR) kraje) více)

NSPTV

Uzavřená oblast

Zvýraznění směrů dopravy,vstupních stanovišť do oblasti a pevných stanovišť k uzavření oblasti (příjezd a odjezd složek IZS, dálková doprava vody), - dekontaminační

Řešená událost nabyla příslušného rozsahu

V pohledu

dopřesňuje dopřesňuje dopřesňuje Společná operační situace KOPIS HZS ČR IOS PČR OPS ZZS ČR vizualizace informací mezi (nebo (nebo (nebo základními složkami IZS na úrovni Do pohledu zanáší technologie technologie technologie operačního řízení GPS v případě GPS v případě GPS v případě

A - v případě nemožnosti úkol splnit A - v případě nemožnosti úkol splnit

A - GPS v mobilní technice A - v případě A - v případě A - v případě nemožnosti nemožnosti nemožnosti splnit úkol VZ úkol splnit úkol splnit

A - v případě A - v případě A - v případě evakuace evakuace evakuace osob osob osob

-

A

-

-

-

-

A

A

A

A

A

A

A

A

A

A

A

A

A



Identifikační a lokalizační údaje Poskytují data pro INFO 35

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

Složka

Přidělení operačnímu středisku

Rajonizace složky IZS


H H



Čí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)

¨




Typy událostí Číselník společný Typy událostí

Typ události

Název typu události

Typ události

Název typu události

A B C D E F G H I J K L M N O

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 1 2 3 4 5 6

Stav události

Název stavu události Událost oznámena Výjezd prvních SaP složky Na místě první SaP složky Požár lokalizován Odjezd posledních SaP složky Událost uzavřena OS

Název stavu události

Složka IZS

Typ spolupráce složky

Stav reakce složky

Typ spolupráce 1 2 3

Stav reakce 1 2

Název typu spolupráce Primární Informovaná Přizvaná

Název stavu reakce Výzva Přijato

Závažnost událostí Číselník společný Závažnost události

Závažnost Popis závažnosti situace situace Závažnost události

Popis závažnosti situace


0 1 2 3 Z

Spolupráce dosud nevyžádána Spolupracují 2 a více složek IZS Stupeň poplachu v IZS Stupeň poplachu v IZS Stupeň poplachu v IZS



Účelové prostory Účelové prostory

- dekontaminační stanoviště (osob a techniky)

Účelový prostor

- 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 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


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

Složka IZS PČR PČR PČR PČR HZS HZS HZS HZS ZZS ZZS ZZS ZZS PČR HZS ZZS



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


Stav 10 Gbps 10 Gbps RRL 155Mbps 10 Gbps 10 Gbps 1 Gbps - původní objekt 10 Gbps 1 Gbps 10 Gbps 1 Gbps 10 Gbps 10 Gbps 1 Gbps 10 Gbps - původní objekt 10Gbps - původní objekt

Km

32,9

32,9 ANO ANO ANO, optický propoj na PČR, dále RRL ANO ANO ANO ANO ANO NE ANO NE ANO ANO ANO ANO NE, počítáno k PČR Olšanská NE, počítáno k HZS Kladno NE NE možno propoj LAN přes HZS (jeden objekt) NE NE nyní NE,po přestěhování propoj LAN přes HZS (jeden objekt) NE, vzdálenost zprůměrována NE NE NE NE, předpoklad prostorová integrace ANO

2,1 0,9 3,2 1,6 3,1 2,1 6,0 5,0 3,3 1,0 4,5 5,4 38,2 1,7 0,6 1,7 2,8 4,6 1,5 2,5 0,9 1,5 2,0 5,4 25,2 96,3



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




Kladno ZZS - PČR Vzdálenost: 0,6 km

Plzeň ZZS - PČR Vzdálenost: 2,8 km




Ú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




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




Č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




Č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




Liberec HZS - ZZS Vzdálenost: 2,1 km

Pardubice HZS - ZZS Vzdálenost: 5,0 km nejrychlejší




Brno HZS - ZZS Vzdálenost: 1,0 km

Zlín HZS - ZZS Vzdálenost: 4,5 km




Věcný obsah typového projektu Č.

Kapitola

1.

Úvod

Výstup

2.

Výchozí stav, zdůvodnění realizace projektu a analýza jeho potřebnosti

2.1.

Výchozí stav (AS-IS)

Metodika/notace

Procesní model AS-IS operačního řízení: - na 3 úrovně rozpadu (procesy, subprocesy, aktivity) - samostatně pro jednotlivé složky IZS - pro ZZS samostatně pro jednotlivé kraje Systemizace AS-IS operačního řízení: - organizační útvary, počty pracovníků - na úroveň jednotlivých složek a krajů

BPMN/XPDL

2.1.3. Technické zajištění AS-IS

Věcné a technické zajištění operačního řízení: - budovy a pracoviště vč. zázemí a infrastruktury - na úroveň jednotlivých složek a krajů

tabulky

2.1.4. ITC model AS-IS

Komponentní a komunikační model AS-IS operačního řízení včetně vazeb na procesní model: - přehled užívaných IS a jejich vzájemných vazeb - přehled komunikačních ICT - samostatně pro jednotlivé složky IZS - pro ZZS samostatně pro jednotlivé kraje Kvantifikace procesního modelu AS-IS z hlediska počtů událostí, frekvencí aktivit a pravděpodobností: - vždy za ucelená předchozí období (průměry) - měsíční, denní a hodinové špičky - ve výjimečných případech (mimořáné situace)

UML

2.2.1. Analýza kritických míst

Posouzení procesů operačního řízení včetně jejich organizačního a ICT zajištění: - inherentní logiky procesů a jejich odlišností od best practices - činností nepřidávajících hodnotu, úrovně standardnizace a variantnosti - z pohledu zákazníka (veřejné služby) a obsluhy - organizačních, prostorových a časových přerušení - zajištění informačních a komunikačních potřeb - výskytu chyb a rizik

BPMN/XPDL, tabulky

2.2.2. Vazba na okolí

Klíčové koncepty a dokumenty EU a na národní úrovni s dopadem do operačního řízení. Požadavky vyplývající z těchto dokumentů.

text

2.2.3. Eliminace kritických míst

Dopady v případě nerealizace projektu. Zadání pro TO-BE z hlediska eliminace kritických míst a vnějších vlivů.

text, tabulky

Kauzální model cílů projektu: - s vyznačením vzájemného ovlivnění cílů - s měřením cílů pomocí ukazatelů - s kvantifikací (výchozí a cílové hodnoty ukazatelů) Standardy zajišťující dosažení cílů ve formě SLA v oblastech: - procesní logiky se specifikací výkonnosti procesů - IS podpory a komunikace na úroveň služeb - organizačního a technického zajištění Forma měření standardů. Termíny dosažení standardů. Eskalační procedury v případě nedosažení/porušení standardů.

BSC

Procesní model TO-BE operačního řízení zajišťující dosažení standardů: - na 3 úrovně rozpadu (procesy, subprocesy, aktivity) - společný pro všechny složky IZS s vyznačením případných specifik Systemizace TO-BE operačního řízení zajišťující dosažení standardů: - organizační útvary, počty pracovníků - na úroveň jednotlivých složek a krajů Věcné a technické zajištění TO-BE operačního řízení zajišťující dosažení standardů: - budovy a pracoviště vč. zázemí a infrastruktury - s vyznačením nutných stavebních úprav - na úroveň jednotlivých složek a krajů

BPMN/XPDL

2.1.1. Procesní model AS-IS

2.1.2. Organizační zajištění AS-IS

2.1.5. Kvantifikace AS-IS

2.2.

BPMN/XPDL, tabulky

Zadání pro cílový stav

3.

Rámec projektu

3.1.

Cíle projektu

3.1.1. Základní cíle projektu

3.1.2. Standardy

3.2.

Organigramy

tabulky

Cílový stav (TO-BE)

3.2.1. Procesní model TO-BE 3.2.2. Organizační zajištění TO-BE 3.2.3. Technické zajištění TO-BE

Organigramy

tabulky

3.2.4. ITC model TO-BE

Komponentní a komunikační model TO-BE operačního řízení zajišťující dosažení standardů: UML - specifikace nových služeb IS a formy jejich zajištění (vývoj, úprava stávajících IS, využití jinde existující funkcionality) - přehled změn komunikačních ICT - samostatně pro jednotlivé složky IZS a jednotlivé kraje

3.2.5. Vymezení dílčích projektů 3.2.6. Řízení projektu

Obligatorní vymezení, co musí jednotlivé krajské projekty řešit

Text, tabulky

Řídící a výkonné struktury pro celkový projekt a jeho dílčí projekty: - řídící výbor a jeho kompetence - hlavní tým společný pro všechny složky a kraje a jeho kompetence - pracovní týmy pro jednotlivé kraje a jejich typové složení - rozhodovací a eskalační procedury Typová specifikace přínosů dílčích projektů.

Organigramy, text

Typový rozpočet dílčích projektů Finanční plán CBA Zajištění investičního majektu Hodnocení udržitelnosti projektu

Tabulky

Specifikace projektových rizik včetně jejich kvantifikace a procedur k jejich eliminaci / redukci.

Model rizik

3.2.7. Typové přínosy projektů 3.2.8. Typová finanční a ekonomická analýza

3.2.9. Typová rizika projektů 4.

Popis dílčích projektů

4.XX.

Dílčí projekt na úrovni složky a kraje

4.XX.1. Specifikace změn

4.XX.2. Projektové aktivity

4.XX.3. Řízení dílčího projektu 4.XX.4. Připravenost dílčího projektu


Tabulky

Souhrn změn na úrovni složky a kraje z hlediska: - technického a organizačního zajištění - ICT změn Varianty řešení a výběr vhodné varianty. Projektové aktivity vedoucí k dosažení cílového stavu v členění včetně harmonogramu: - přípravná fáze - realizační fáze - provozní fáze Složení pracovního týmu. Režim práce pracovního týmu.

Text

Zhodnocení připravenosti dílčího projektu.

Text

Text

Text



Rejstříky a seznamy Seznam obrázků Obr. 1: Logika cílů................................................................................................................................................................................................................. 6 Obr. 2: Vazba mezi zkrácením reakčního času a snížením následků u požárů ....................................................................................... 8 Obr. 3: Vazba mezi zkrácením reakčního času a snížením následků u dopravních nehod ................................................................ 9 Obr. 4: Sdílení událostí během tísňového volání ................................................................................................................................................. 21 Obr. 5: Vazba na operační řízení ................................................................................................................................................................................. 21 Obr. 6: Změny v operačním řízení .............................................................................................................................................................................. 29 Obr. 7: Vizualizace operační situace .......................................................................................................................................................................... 30 Obr. 8: Časové řezy dat pro simulaci ......................................................................................................................................................................... 31 Obr. 9: Vliv propadů hovorů na kapacitní simulaci ........................................................................................................................................... 33 Obr. 10: Podíl přijatých hovorů a délka čekání - extrémní situace HZS (56 pracovišť) ................................................................... 39 Obr. 11: Podíl přijatých hovorů a délka čekání - extrémní situace PČR (28 pracovišť) ................................................................... 39 Obr. 12: Podíl přijatých hovorů a délka čekání - extrémní situace ZZS (28 pracovišť).................................................................... 39 Obr. 13: Logika řízení změn v integrační platformě .......................................................................................................................................... 50 Obr. 14: Ideové vymezení projektu............................................................................................................................................................................ 67 Obr. 15: Rámcový průběh projektu ........................................................................................................................................................................... 68




Seznam modelů Model 1: Kauzální model cílů (BSC) ............................................................................................................................................................................. 5 Model 2: Procesy tísňového volání a operačního řízení .................................................................................................................................. 16 Model 3: Proces Zajistit příjem tísňového volání ................................................................................................................................................ 17 Model 4: Subproces Spojit hovor ................................................................................................................................................................................ 18 Model 5: Subproces Zajistit jazykovou podporu ................................................................................................................................................. 19 Model 6: Subproces Předat hovor na jinou složku IZS ..................................................................................................................................... 20 Model 7: Subproces Zjistit základní informace o události .............................................................................................................................. 20 Model 8: Proces Zajistit operační řízení .................................................................................................................................................................. 23 Model 9: Subproces Monitorovat operační situaci............................................................................................................................................. 24 Model 10: Subproces Nasadit a řídit SaP - varianta HZS ................................................................................................................................. 25 Model 11: Subproces Nasadit a řídit SaP - varianta ZZS .................................................................................................................................. 26 Model 12: Subproces Nasadit a řídit SaP - varianta PČR ................................................................................................................................. 27 Model 13: Subproces Komunikovat s kompetentními orgány ..................................................................................................................... 28 Model 14: Subproces Varovat obyvatelstvo (provádí pouze HZS) ............................................................................................................. 28 Model 15: Zjednodušený simulační model (příklad HZS) .............................................................................................................................. 32 Model 16: Simulace extrémní situace celková - výchozí zadání .................................................................................................................. 38 Model 17: Koncept procesní a aplikační integrace ............................................................................................................................................ 49 Model 18: Architektura integrační platformy....................................................................................................................................................... 51 Model 19: Funkcionalita NSPTV .................................................................................................................................................................................. 53 Model 20: Architektura NSPTV – kombinovaná duální telefonie ............................................................................................................... 54 Model 23: Základny geodat............................................................................................................................................................................................ 56




Seznam tabulek Tabulka 1: Cíle a ukazatele ve finanční perspektivě............................................................................................................................................. 7 Tabulka 2: Cíle a ukazatele v perspektivě veřejný zájem .................................................................................................................................. 8 Tabulka 3: Cíle a ukazatele v perspektivě procesy............................................................................................................................................. 10 Tabulka 4: Vazba průměrné reakční doby na následky MU .......................................................................................................................... 11 Tabulka 5: Složení reakční doby při společných zásazích .............................................................................................................................. 11 Tabulka 6: Cíle a ukazatele v perspektivě zdroje ................................................................................................................................................ 13 Tabulka 7: Absolutní propady tísňových hovorů (průměrný den) ............................................................................................................ 31 Tabulka 8: Relativní propady tísňových hovorů (zadání simulace) .......................................................................................................... 32 Tabulka 9: Rozložení zátěže na kraje (denní průměry) ................................................................................................................................... 33 Tabulka 10: Rozložení zátěže po hodinách ............................................................................................................................................................ 34 Tabulka 11: Rozložení zátěže po hodinách (zadání simulace) ..................................................................................................................... 34 Tabulka 12: Extrémní zatížení - kraje ..................................................................................................................................................................... 35 Tabulka 13: Extrémní zatížení - po hodinách ....................................................................................................................................................... 35 Tabulka 14: extrémní zatížení - nejvíce zatížený kraj po hodinách ........................................................................................................... 36 Tabulka 15: Extrémní zátěž (zadání pro simulaci) ............................................................................................................................................ 36 Tabulka 16: Délka vytěženého hovoru (zadání pro simulaci) ...................................................................................................................... 37 Tabulka 17: Kapacity operátorských pracovišť (vstupní zadání simulace) .......................................................................................... 37 Tabulka 18: Výsledky simulace extrémní situace celková - výchozí zadání - vytížení kapacit ................................................... 38 Tabulka 19: Výsledky simulace - počet pracovišť (standard = Optimálně) ........................................................................................... 40 Tabulka 21: Přípustné zatížení operátorů (hodinově)..................................................................................................................................... 41 Tabulka 22: Nejvyšší přípustné zatížení systému .............................................................................................................................................. 41 Tabulka 23: Nejvyšší přípustné zatížení operátorů (hodinově) .................................................................................................................. 42 Tabulka 24: Návrh kapacit služeb .............................................................................................................................................................................. 42 Tabulka 25: Hodinová zátěž (počty hovorů) běžná ........................................................................................................................................... 43 Tabulka 26: Minimální počet operátorů přihlášených do systému pro kritickou hodinu denní směny ................................. 43 Tabulka 27: Výsledky simulace pro běžné zatížení - kritická hodina ....................................................................................................... 44 Tabulka 28: Výsledky simulace pro běžné zatížení - během dne – závazný standard...................................................................... 45 Tabulka 29: Výsledky simulace pro běžné zatížení - kraje ZZS s min. obsazením.............................................................................. 46 Tabulka 30: Výsledky simulace pro běžné zatížení - kraje ZZS bez přelivů........................................................................................... 46 Tabulka 31: Dimenze dopadu rizik ............................................................................................................................................................................ 61 Tabulka 32: Úrovně dopadu rizik ............................................................................................................................................................................... 61 Tabulka 33: Pravděpodobnost rizik .......................................................................................................................................................................... 61 Tabulka 34: Závažnost rizik .......................................................................................................................................................................................... 61 Tabulka 35: Technická projektová rizika ............................................................................................................................................................... 62 Tabulka 36: Úrovně procesních rizik ........................................................................................................................................................................ 63 Tabulka 37: Standardy tísňového volání ................................................................................................................................................................ 64 Tabulka 38: Celkový rámcový rozpočet ............................................................................................. Chyba! Záložka není definována. Tabulka 39: Rozpočet Integrační platformy ..................................................................................... Chyba! Záložka není definována. Tabulka 40: Rozpočet NSPTV .................................................................................................................. Chyba! Záložka není definována. Tabulka 45: Následky MU podle společně zasahujících složek .................................................................................................................... 70 Tabulka 46: Následky MU podle typu MU .............................................................................................................................................................. 70 Tabulka 47: Následky MU typ požár podle času dojezdu – statistika HZS ............................................................................................. 71 Tabulka 48: Následky MU typ nehoda podle času dojezdu – statistika ZZS .......................................................................................... 72 Tabulka 49: Vazba doby dojezdu a vzdálenosti (počty událostí) – statistika HZS .............................................................................. 73 Tabulka 50: Současná doba dojezdu a doba dojezdu s navigací .................................................................................................................. 74 Tabulka 51: Rychlost sestavení hovorů (rychlost sestavení v s) ................................................................................................................ 75 strana 95 (celkem 99 stran)



Tabulka 52: Rychlost předání BI mezi složkami IZS v operačním řízení ................................................................................................ 75 Tabulka 53: Zdroje dat v knihovně projektu ......................................................................................................................................................... 76 Tabulka 54: Konektivita v síti ITS pro předpokládané lokality NSPTV ................................................................................................... 83




Pojmy a zkratky Pojem, zkratka

Vysvětlení

AdatTP-3

Standard NATO pro zápis textu zpráv.

Bezpečnostní rada

Koordinační orgán pro přípravu na KS

BGP

Border Gateway Protokol, (Používá se jeho rozšíření o distribuci návěští).

BGP / MPLS

Border Gateway Protocol / Multi Protocol Label Switching

BPMS

Business Process Management Suite, (Nástroj procesního managementu).

BR

Business rules. Pravidla rozhodování.

CAP

Common Alerting Protocol. Standard varovné zprávy ve formátu XML.

CIT

Rastrový formát dat

CSW

Catalogue Services for Web, (Přístup k informacím katalogu).

CZECHPOINT

Český Podací Ověřovací Informační Národní Terminál

ČSÚ

Český statistický úřad

ČÚZK

Český úřad zeměměřičský a katastrální

Dealokace sil a prostředků

Vrácení a obnova znovupoužitelných prostředků.

Disponibilní síla

Vyjadřuje v daném okamžiku dostupné/použitelné lidské síly, jednotky atd.

Disponibilní zdroje

Vyjadřuje v daném okamžiku dostupné zdroje - síly, prostředky, materiál, finance, služby.

DMVS

Digitální mapa veřejné správy

DOK

Informační systém pro preventivní a záchranná opatření v oblasti mobilních zdrojů nebezpečí Přeprava nebezpečných látek.

EMOFF

Systém pro podporu analýzy, plánování a řízení řešení MU / KS.

EP

Evropský parlament

EPOZ

Systém pro orgány krizového řízení k uplatňování, evidenci a řešení požadavků k překonání krizového stavu.

ES

Evropské společenství

ESB

Enterprise Service Bus. Sběrnice služeb.

Evakuace

Evakuační plán

Souhrn organizačních a technických opatření zabezpečujících přemístění osob, zvířat a věcných prostředků v daném pořadí priority z míst ohrožených mimořádnou událostí do míst, ve kterých je zajištěno pro osoby náhradní ubytování a stravování, pro zvířata ustájení a pro věcné prostředky uskladnění. Soubor opatření k zabezpečení přemístění osob, zvířat, předmětů kulturní hodnoty, technického zařízení příp. strojů a materiálu k zachování nutné výroby a nebezpečných látek z míst zasažených nebo ohrožených mimořádnou událostí vyžadující vyhlášení třetího nebo zvláštního stupně poplachu.

GIF

Formát rastrových dat Graphic Interchange Format

GIS

Geografický informační systém

Havarijní a operační karty

Havarijní plán

Specifikace katalogového listu opatření pro konkrétní událost, subjekt a podmínky. Dokument s popisy činností a opatření prováděných při vzniku závažné havárie vedoucí ke zmírnění jejích dopadů, zejména scénáře odezvy na závažnou havárii, modifikované na místní specifika a případně i na časový souběh několika událostí.

HZS

Hasičský záchranný sbor

ICT

Information and Communication Technologies, Informační a komunikační technologie.

INSPIRE

Insfrastruktura prostorových dat v Evropském společenství

IS

Informační systémy

ISKN

Informační systém katastru nemovitostí

ISKŘ

Informační systém krizového řízení

ISO

lnternational Organization for Standardization, (Mezinárodní organizace pro normy).

ISVS

Informační systém veřejné správy

IT

Informatik technology, Informační technologie.



Koncept TO-BE (FINAL) ITS MV IZS JSVV

Integrovaná telekomunikační síť Ministerstva vnitra Integrovaný záchranný systém. Koordinace záchranných a likvidačních prací včetně řízení jejich součinnosti. Jednotný systém varování a vyrozumění. Soustava selektivně rádiově ovládaných sirén a další místně ovládané sirény.

KN

Katastr nemovitostí

KPI

Key performance indicators, Klíčový ukazatel.

Kritická infrastruktura Krizová komunikace Krizová opatření Krizová situace Krizové plánování

Kritickou infrastrukturou se rozumí výrobní i nevýrobní systémy, jejichž nefunkčnost by měla vážné dopady na bezpečnost, ekonomiku a zachování nezbytného rozsahu dalších základních funkcí státu při krizových situacích. Vzájemná komunikace ve prospěch řešení krizové situace. Komunikace sestává ze zpráv. Seznam konkrétních činností provedených ke zmírnění nebo odstranění následků MÚ Mimořádná událost, v jejímž důsledku se vyhlašuje stav nebezpečí, nouzový stav, stav ohrožení státu nebo válečný stav. Ucelený soubor postupů, metod a opatření, které věcně příslušné orgány užívají při přípravě na činnost v krizových situacích a k minimalizaci možných zdrojů krizových situací a jejich škodlivých následků.

Krizové řízení

Činnost orgánů krizového řízení.

Krizový plán

Souhrn krizových opatření a postupů k řešení krizových situací

LDP LDP/CR

Label Distribution Protocol – dle RFC 3036, specializovaný pro přenos zpráv v síti MPLS Label Distribution Protocol/Constrained Routing - rozšíření protokolu LDP o funkce zaručení kvality služby

LMO

Legally Mandated Organisation

Mimořádná událost

Škodlivé působení sil a jevů vyvolaných činností člověka, přírodními vlivy, a také havárie, které ohrožují život, zdraví, majetek nebo životní prostředí a vyžadují provedení záchranných a likvidačních prací.

MU

Mimořádná událost

MŽP

Ministerstvo životního prostředí

Nezbytná dodávka

Nouzový stav

NSPTV

Dodávka výrobků, prací a služeb pro zajištění základních životních potřeb obyvatelstva, pro podporu činnosti ozbrojených sil, ozbrojených bezpečnostních sborů, hasičských záchranných sborů a havarijních služeb a pro podporu výkonu státní správy, bez níž nelze zajistit překonání krizových stavů. Stav vyhlašovaný vládou ČR, popř. předsedou vlády ČR v případě živelních pohrom, ekologických nebo průmyslových havárií, nehod nebo jiného nebezpečí, které ve značném rozsahu ohrožují životy, zdraví nebo majetkové hodnoty anebo vnitřní pořádek a bezpečnost. Národní systém příjmu tísňového volání - jednotná technologie příjmu tísňového volání

NVF

Nový výměnný formát katastru nemovitostí

OGC

Open GIS Consortium

Operační a informační střediska IZS (OS)

Stálé orgány pro koordinaci složek IZS

Operační plán

Přílohová část krizového plánu nezbytná ke zvládnutí krizové situace, která pro konkrétní druh krizové situace na daném území stanoví postupy, zásady, opatření, síly a prostředky pro její řešení, plány jejich nasazení a zabezpečení. Je to v podstatě příslušný typový plán konkretizovaný pro daný správní úřad, území nebo objekt.

OŘ

Operační řízení

OS

Operační středisko. Pracoviště pro operační řízení

OS IZS

Operační a informační střediska IZS. Stálé orgány pro koordinaci složek IZS

PČR

Policie České republiky

PDF

Portable Document Format, formát dokumentů Acrobate Reader

PNG

Formát rastrových dat Portable Network Graphics.

Poplachový plán IZS kraje

Dokument vydaný formou nařízení kraje pro povolávání pomoci vybraných sil a prostředků složek IZS a při strategické koordinaci záchranných a likvidačních prací na úrovni kraje.

QoS

Quality of Service, Zajištění kvalit služeb při rezervaci a řízení datových toků.



Koncept TO-BE (FINAL) Riziko RSVP-TE

Možnost, že s určitou pravděpodobností vznikne událost, kterou považujeme z bezpečnostního hlediska za nežádoucí. RSVP-Traffic Engineering, (Modifikovaný protokol vytváření toků s definovanou třídou služby).

RÚIAN

Registr územní identifikace adres a nemovitostí

RZM..

Rastrová základní mapa

S-42

Souřadnicový systém

SaP

Síly a prostředky. Disponibilní síla a disponibilní zdroje.

SDIc

Spatial Data Interest Communities

S-JTSK

Souřadnicový systém jednotné trigonometrické sítě katastrální

SM5

Státní mapa odozená v měřítku 1:5.000

SOA

Servisně orientovaná architektura

Stupeň poplachu IZS

Předurčení potřeby sil a prostředků pro záchranné a likvidační práce v závislosti na rozsahu a druhu mimořádné události a úrovni koordinace složek při společném zásahu.

TCTV

Technologie a služby centra tísňového volání

TDP

Tag Distribution Protokol, (Specializovaný pro přenos zpráv v síti MPLS Cisco).

Tísňová informace

Informace obyvatelstvu o bezprostředním nebezpečí vzniku nebo již nastalé mimořádné události a údaje o opatřeních k jeho ochraně.

TV

Tísňové volání

ÚIR- ADR

Územně identifikační registr adres v ČR

ÚKŠ

Ústřední krizový štáb.

UML

Unified Modeling Language

UNECE IANS ÚPP IZS

UNECE Industrial Accident Notification Systém. Standard sdružení UNECE systému zpráv. Ústřední poplachový plán IZS pro povolávání vybraných sil a prostředků složek IZS při ústřední koordinaci záchranných a likvidačních prací.

UTM

Souřadnicový systém, (Univerzální transverzální Mercatorův systém souřadnic).

Varování

Souhrn technických a organizačních opatření zabezpečujících včasné upozornění obyvatelstva orgány veřejné správy na hrozící nebo nastalou mimořádnou událost, vyžadující realizaci opatření na ochranu obyvatelstva a majetku.

VPN

Virtual Private Network, Virtuální privátní síť.

WCS

Web Coverage Service

WCTS

Web Coordinate Transformation Service

WFSL

Web Feature Service Locking

WFST

Web Feature Service Transactional, Služba pracující na principu klient-server.

WGS84

Souřadnicový systém

WMS

Web Map Services, (Poskytování map ve formě obrazových dat).

WPS

Web Processing Service, (Služba pro vzdálené zpracování dat).

ZABAGED

Základní báze geografických dat

Záchranný sbor

Jednotně organizovaný sbor k provádění a řízení záchranných prací při mimořádných událostech a krizových situacích (např. Báňská záchranná služba, Hasičský záchranný sbor ČR, Horská služba atd.).

ZM10

Základní mapa v měřítku 1:10.000

Zpráva

Elementární jednotka komunikace mezi subjekty

ZÚ

Zeměměřický úřad

ZZS

Zdravotnická záchranná služba


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

Recommend Documents