ITS v podmínkách dopravně-telekomunikačního prostředí ČR (802

Transkript

FAKULTA
DOPRAVNÍ
ČVUT | KONVIKTSKÁ 20, 11000 PRAHA 1
ITS v podmínkách
dopravně-telekomunikačního
prostředí ČR
(802/210/108)
příloha č.8
Systém tísňového volání (e-call)
Doc. Dr. Ing. Miroslav Svítek a kol.
VERZE 1.0
Obsah
1. Úvod....................................................................................................................................... 4
1.1. Základní komponenty systémy tísňového volání ............................................................ 6
1.2. Metody určování polohy ................................................................................................. 6
2. Architektura systému tísňového volání (e-call) ............................................................... 12
2.1. Tísňové volání - mobilní telefon ................................................................................... 12
2.2. Tísňové volání - mobilní telefon a GSM lokalizace ..................................................... 12
2.3. Vozidlová jednotka ....................................................................................................... 13
2.4. Infrastruktura systému tísňového volání (e-call)........................................................... 16
3. Procesní modely systému tísňového volání ...................................................................... 21
3.1. Automatické volání - řidič vozidla je schopen mluvit a má smlouvu s poskytovatelem
služby ................................................................................................................................... 21
3.2. Automatické volání - řidič vozidla je schopen mluvit, je nutný překlad a má smlouvu
s SP....................................................................................................................................... 22
3.3. Automatické volání - tichý hovor se smlouvou s provozovatelem služby.................... 23
3.4. Automatické volání - řidič je schopen komunikovat a neexistuje smlouva s
poskytovatelem služby ......................................................................................................... 24
3.5. Automatické volání - řidič není schopen komunikace a neexistuje smlouva se
provozovatelem služby......................................................................................................... 25
3.6. Manuální volání - řidič vozidla je schopen komunikace a má smlouvu
s poskytovatelem služby....................................................................................................... 26
3.7. Manuální volání - řidič je schopen komunikace, je třeba překlad a má smlouvou s
3.8. Manuální E-call - tichý hovor, existuje smlouva s poskytovatelem služby .................. 28
3.9. Manuální E-call – volá očitý nebo náhodný svědek ..................................................... 29
3.10. Manuální volání - řidič je schopen komunikovat, neexistuje smlouva s
3.11. Manuální volání - tichý hovor, neexistuje smlouva s poskytovatelem služby............ 30
3.12. Chybná funkce jednotky vedoucí k falešným hovorům.............................................. 31
4. Specifikace systému E-MERGE........................................................................................ 33
4.1. Specifikace dat generovaných vozidlovou jednotkou (minimálních dat) ..................... 33
4.2. Specifikace úplných dat ................................................................................................ 36
4.3. Specifikace komunikace................................................................................................ 40
5. Požadavky na E-MERGE systém ..................................................................................... 46
5.1. Požadavky na vozidlovou jednotku............................................................................... 46
5.2. Požadavky na PSAP ...................................................................................................... 53
5.3. Zabezpečení sítě ............................................................................................................ 57
5.4. Požadavky na ukládání dat............................................................................................ 61
6. Doporučení pro poskytovatele služeb............................................................................... 64
6.1. Úvod .............................................................................................................................. 64
6.2. Procesy HCC ................................................................................................................. 64
6.3. Technické požadavky.................................................................................................... 65
6.4. Přidaná data od HCC k PSAP ....................................................................................... 66
6.5. Systémové parametry SP............................................................................................... 66
7. Systém tísňového volání v nákladní dopravě................................................................... 67
7.1. Průběh záchranné akce v případě havárie ..................................................................... 70
7.2. Postup zpracování informace v PSAP........................................................................... 71
7.3. Využití E-call při zabezpečení přepravy nebezpečných nákladů.................................. 74
8. Stávající stav v ČR ............................................................................................................. 75
8.1. Složky IZS..................................................................................................................... 75
2
8.2. Operační střediska ......................................................................................................... 76
8.3. Zkušenost s operačním střediskem v Ostravě ............................................................... 77
9. Závěry a doporučení .......................................................................................................... 79
10. Použité zkratky................................................................................................................. 82
11. Literatura.......................................................................................................................... 86
3
1. Úvod
Tato zpráva popisuje technické, funkční a organizační řešení Evropského projektu
telematických nouzových hovorů generovaných vozidlovou jednotkou (OBU). Presentované
výsledky jsou v souladu s výstupy Evropského projektu E-MERGE, kde na základě těchto
výsledků bude docházet k praktické implementaci tohoto systému na úrovni EU.
Realizace projektu E-MERGE závisí na implementaci evropské nouzové linky E-112,
kterou schválila Evropská komise, a také na implementaci protokolu ETSI/EMTEL
jednotlivými telekomunikačními operátory, kteří poskytují informace o lokalizaci jednotlivým
středisek tísňového volání (PSAP - Public Authority Answering Point).
Další podmínkou navrhovaného řešení je implementace standardu pro globální
telematický protokol (GTP), zpracovaný Telematickým forem v ERTICO, který byl použit
v koncepci E-MERGE projektu pro přenos dat z vozidlové jednotky (OBU) do střediska
tísňového volání (PSAP) a k přenosu dat k poskytovatelům telematických služeb (SP Service Provider).
Zpracovaná architektura a protokoly poskytují, podle E-MERGE konsorcia, nejlepší
základ pro rozšíření stanoveného řešení vozidlem generovaných nouzových hovorů. Klíčem
úspěchu celého projektu je organizace všech PSAP center a to buď lokálně nebo celonárodně
a nutnost vybavit je potřebnými technologiemi umožňujícími přijímat jak informace o poloze,
tak i minimální data vyslaná vozidlem po lince E 112 jako data v hovoru (poslaná současně
s hovorem).
Zavedením systému E-MERGE se očekává, že se zlepší průměrný čas reakce nejméně o
30% (tzn. čas od přijmutí hovoru až do doby kdy je profesionální pomoc na místě).
Projekt E-MERGE definuje obecné funkční specifikace celého řetězce nouzových hovorů
generovaných vozidlem, struktury zpráv posílaných z vozidla, postupy, problémy a
požadavky.
Obsahem závěrečné zprávy projektu E-MERGE je:
•
•
•
•
•
•
•
•
•
•
•
Doporučení pro minimální technické požadavky na vozidlovou jednotku
Technické požadavky na centrální systém
Specifikace jednoho obecného E-MERGE datového modelu
Specifikace obecného formátu zprávy a formátu výměny dat
Standardizace rozhraní v E-call řetězci
Doporučení na rozhraní HMI
Definice komunikačního prostředí – technologie a architektura
Stanovení požadavků a specifikací ohledně interoperability řešení
Specifikace minimálního standardu kvality služeb
Specifikace postupů při falešných hovorech
Specifikace a doporučení obecných postupů pro E-call servisní centra
Výsledek tohoto dokumentu bude použit k popisu specifické architektury v jednotlivých
zemích zavádějících a testujících systém E-MERGE a byl též použit jako základ
navrhovaného řešení pro ČR. Aby byl systém interoperabilní v rámci EU, je třeba dodržet
zásady obecné architektury E-MERGE včetně specifikací a definicí.
4
Základem řešení projektu E-MERGE je:
•
•
•
•
•
•
•
•
•
•
•
Integrace existujících projektů a standardů
Užití pouze jednoho protokolu pro vozidlovou jednotku (OBU)
Minimální specifikace na E-call funkci pro vozidlovou jednotku (OBU)
Dostupnost minimálních dat generovaných vozidlem, která jsou posílána přímo do
centra tísňového volání (PSAP)
Časově a procesně optimalizované postupy
Ochrana osobních dat
Minimalizace planých poplachů a zneužití systému
Cenově optimalizované řešení výměny dat s přidanou hodnotou mezi poskytovateli
služeb a centry tísňového volání (PSAP v případě nehody
Vyřešení jazykových problémů
Optimalizace výměny dat mezi centrem tísňového volání (PSAP) a provozovatelem
služeb (SP)
Definice různých možností a procesů tísňového volání (E-call)
Základem navrhovaného řešení je E-MERGE architektura, která je převzata všemi E-MERGE
partnery.
Na projektu E-MERGE se podílejí následující partneři:
Poskytovatel služeb / PSAP:
SOS Alarm
Výrobce automobilů:
VOLVO
Poskytovatel služeb:
OnStar / GDV
GM (OPEL)
RACC
SEAT
Veřejná autorita:
City of Milano
FIAT
Veřejná autorita:
DTLR
PSAP:
BT Operations
The AA
Nouzový Operátor:
ACPO
Renault
Švédsko
Německo
Špenělsko
Itálie
V. Británie
Francie
5
1.1. Základní komponenty systémy tísňového volání
V textu budou používány následující zkratky, které jsou v souladu s E-MERGE definicemi
a mají následující význam:
Service provider (SP) nebo Home Call Centre (HCC) je fyzický a funkční prvek,
odpovědný za poskytování telematicky založených služeb svým zákazníkům – řidičům (např.
obsluhu nouzových hovorů při havárii, obsluhu vozidlové (IVS) komunikace, určení přesné
polohy vozidla a sledování a zaznamenávání pohybu vozidla na základě GPS/GALILEO
technologie atd.). HCC se nachází v domácí zemi zákazníka. V případě, že se nehoda stane na
domácí půdě zákazníka, LCC a HCC budou jedno a to samé, ale jestliže se nehoda stane
mimo zemi původu zákazníka, měla by být ustanovena dohoda mezi HCC a LCC.
Local Call Centre (LCC) je funkční prvek, se kterým má HCC smlouvu a který se
nachází v zemi kde se stala nehoda.
E-MERGE hovor nebo také E-call je telematický nouzový hovor. Spuští ho vozidlo
(IVS) po mobilní komunikační technologii kombinující zejména přenos dat přes SMS nebo
datový kanál. E-call obsahuje GPS/GALILEO informace o poloze, přidaná data a přenos
hlasu. Vše je posláno po speciálně vyvinutém E-MERGE protokolu. E-MERGE sekvence
může být spuštěna manuálně S.O.S. tlačítkem, nebo automaticky senzory ve vozidle. EMERGE hovor je jediným typem hovoru zpracoveného E-MERGE projektem.
Public Safety Answering Point (PSAP) je fyzické místo, kde jsou přijímány obyčejné a
E-MERGE nouzové hovory. Může to být statní zařízení, státní/soukromá společnost nebo
telekomunikační operátor, který má udělenou licenci od státní správy. PSAP centrum je
odpovědné za vyřizování hovorů linky 112 po pevné i mobilní síti a také za včasné a přesné
informování pohotovostních jednotek.
Emergency Authority (EA) je státní instituce jako policie, ambulance, nebo hasiči
odpovědná za řešení nouzové situace a vypravení odpovídající pomoci na místo nehody.
In-Vehicle System (IVS) je telematické zařízení umístěné na palubní desce vozidla, které
má specifickou funkci generovat “E-MERGE nouzovou sekvenci”
1.2. Metody určování polohy
Polohová informace je základem úspěchu každé záchranné akce. Tuto informaci lze získat
buď přímým sdělením volajícího, kdy přesnost závisí na znalosti prostředí ve kterém se
volající pohybuje, a nebo automaticky, kdy je přesnost daná použitým systémem lokalizace a
pohybuje se vždy v určitém rozsahu. V rámci tísňového volání je zajímavá především
polohová informace získaná automaticky. V České republice lze hovořit o třech systémech
lokalizace, z nichž dva mají přímou souvislost s tísňovým voláním 112.
Mobilní operátoři a dodavatelé technologií pro sítě GSM se zjišťováním polohy mobilních
telefonů zabývají už několik let. Za tuto dobu vývojáři definovali několik metod pro
lokalizaci polohy, které podle nich mají budoucnost. Jak už to ale ve světě telekomunikací
chodí, nakonec se prosazuje metoda úplně jiná.
Existují tři kategorie metod zjišťování polohy mobilních telefonů. Nejstarší pokusy jsou
založeny na lokalizaci polohy sítí GSM – těmto metodám se říká využívající síť (networkbased, NB). Novější metody jsou využívající mobil (terminal/handset-based, TB). Zatímco u
metody využívající síť není vyžadována spolupráce mobilního telefonu (ten působí jako
pasivní, sledovaný prvek, k zjištění polohy není jeho spolupráce potřebná), u metod
6
využívajících mobil probíhá zjišťování polohy právě na straně mobilního telefonu, který pro
změnu nepotřebuje aktivní spolupráci mobilní sítě.
Zatímco dodavatelé technologií sítí GSM se snažili operátorům prodat aplikace založené
na jedné z těchto metod, ti se raději pokusili oba zmiňované postupy zkombinovat –
výsledkem je lokalizace polohy založená na aplikacích SIM toolkit, které kombinují
spolupráci telefonu se sítí GSM. Je však třeba uznat, že SIM toolkitové aplikace využívají ve
velké míře právě schopnosti mobilní sítě než telefonu.
Možnosti lokalizace polohy mobilního telefonu
Obr. 1.1 Metody určování polohy
Lokalizace polohy využívající síť GSM
Síťové metody zjišťování polohy jsou založené na znalosti konfigurace sítě GSM a
chování rádiových vln. Každý mobilní operátor totiž velmi přesně zná umístění svých
základnových (vysílacích) stanic (BTS), jejich rozdělení do sektorů a identifikační čísla
jednotlivých sektorů (označují se jako Cell ID nebo CGI, cell global identity). Ví také, které
frekvence se v těchto sektorech používají.
Metoda označená zkratkou CGI+TA (Cell Global Identity + Timing Advance) využívá
toho, že mobilní síť zná hodnotu CGI sektoru, ve kterém se nachází telefon. Pokud by znal
vyhodnocovací software pouze CGI, může určit okruh s poloměrem nejvíce 35 km, ve kterém
se lokalizovaný mobil nachází – to v případě, že sektor má kruhový tvar. Protože ovšem
dnešní mobilní sítě mají kuželové tvary sektorů (s rozpětím 90° až 120°), je možné oblast, ve
které se mobil nachází, určit výrazně přesněji. Při komunikaci sítě GSM s mobilem se používá
ještě jedna hodnota – TA (timing advance). S její pomocí se dá zjistit vzdálenost od BTS
7
s přesností na 550 metrů (vynásobením TA číslem 550). TA se vypočítává ze zpoždění
přenosu rádiového signálu mezi mobilem a sítí. Pokud zná vyhodnocovací centrum hodnotu
CGI a také TA, může určit oblast, ve které se nachází hledaný mobil, s přesností nejméně 550
metrů (šířka oblasti záleží na šířce sektoru).
Obr. 1.2 Metody CGI a CGI+TA
Jiný postup, pro který technici používají zkratku UL-TOA (Uplink time of arrival),
vyhodnocuje jenom zpoždění signálu vysílaného z mobilního telefonu. Každý mobilní telefon
totiž má svůj interní časovač (můžeme říkat i hodiny), který je synchronizovaný se sítí GSM –
jinak by mezi nimi nefungovala komunikace. Když vyhodnocovací centrum zná čas, kdy
mobil začal vysílat (každé vysílání je označeno časovou známkou), který srovná s časem, kdy
data dorazila do BTS (jejíž polohu přesně zná), může vyhodnotit zpoždění signálu (jeho
rychlost je známá) a z něj vypočítat vzdálenost od BTS. Pokud je mobilní telefon v dosahu
dalších tří BTS, se kterými dokáže komunikovat, je možné vypočítat při znalosti zpoždění
komunikace se všemi stanicemi polohu s přesností na 50 až 150 metrů. Přesnější lokalizaci
mobilu touto metodou brání různé odrazy a zalomení rádiového signálu (především
v městských oblastech). V důsledku toho je lokalizace v otevřené krajině přesnější než ve
městech.
Oba postupy mají pro operátory velkou výhodu v tom, že pracují se současnými
mobilními telefony – aby zákazníci mohli využívat služby založené na těchto metodách,
nemusí vyměňovat svoje mobilní telefony. V okamžiku spuštění služby ji může využívat
skutečně každý majitel mobilu. Operátor ale musí investovat velké částky do
vyhodnocovacího centra a také se mu zvýší zátěž sítě. Při zjišťování polohy jednou ze
zmiňovaných metod je totiž nutné, aby mobil se sítí komunikoval. A to dělá při hovoru,
odesílání či přijímání textové zprávy, zapnutí a vypnutí telefonu, operaci nazvané LU
(Location Update) nebo když ho k tomu mobilní síť vyzve. V okamžiku, kdy mobil nevysílá,
tak vyhodnocovací centrum zná pouze oblast (která může dosáhnout velikosti kraje), ve které
se pohybuje, případně ještě CGI, TA nebo zpoždění signálu, ovšem z doby poslední
komunikace se sítí.
Lokalizace polohy využívající mobilní telefon
Zjišťování polohy využívající schopností mobilního telefonu je sice výrazně přesnější než
při použití metod založených na sítích GSM, jenže díky vyšší nákladnosti a problémům při
zavádění mezi uživatele se vůbec nepoužívá.
Stále platí, že nejpřesnější údaj o poloze pohybujícího se předmětu zjistíte prostřednictvím
satelitního navigačního systému GPS (Global Positioning System). Tento systém je založen
na 24 umělých družicích, které obíhají Zemi ve výšce přibližně 200 km. Každá družice vysílá
informace o čase a svojí poloze. Přijímač podle dat z nejméně tří družic určí svoji přibližnou
polohu (s odchylkou v řádech desítek metrů); při příjmu signálu ze čtyř vysílačů už je schopen
8
určit polohu s přesností na metry. Nejvíce je možné v jednu chvíli přijímat signál z dvanácti
družic.
Protože signál z družic na oběžné dráze se téměř vůbec nešíří v budovách a hustě
osídlených oblastech, vznikly projekty GPS s asistencí sítě GSM (A-GPS, network-assisted
GPS). Přijímač GPS totiž ke správnému určení polohy potřebuje znát polohu vysílače a
přesný čas, kdy byl vyslán signál. Aby byl systém GPS dokonalejší v místech se špatnou
úrovní signálu z družic, bylo by dobré použít pozemní vysílače, jejichž signál pronikne i do
budov a podzemních garáží. A k tomu se velmi dobře hodí základnové stanice sítí GSM.
Atomové hodiny, které se používají v družicích GPS, je možné použít i v BTS, jejíž poloha je
velmi přesně známá. Pokud by byl mobilní telefon vybaven přijímačem GPS (jako např.
Benefon Esc), mohl by svoji polohu zjišťovat i na základě informací vysílaných sítí GSM.
Podle odborníků lze dosáhnout při hustotě vysílačů A-GPS každých 300 km přesnosti určení
polohy mobilu s odchylkou 10 až 20 metrů.
Obr 1.3 Princip lokalizace pomocí GPS
A-GPS naráží na tři zásadní problémy. Pokud by tento systém měl fungovat jen
v konkrétní síti, potom by musel pracovat na jiných frekvencích než současný systém GPS –
to kvůli tomu, aby se tyto systémy nerušily. Informace A-GPS by bylo možné vysílat i ve
frekvenčním pásmu GSM. Nebo by se sítě s A-GPS musely propojit se systémem GPS
(provozovaným americkou armádou), jenže to by vyžadovalo spolupráci několika desítek až
stovek operátorů, kteří by vysílače A-GPS provozovali – tím by ale provozovatelé sítí ztratili
konkurenční výhodu; na základě jejich signálu by mohli služby nabízet zdarma i jiní
operátoři. I kdyby se povedlo vyřešit tento problém, museli by se provozovatelé sítí GSM a
služeb založených na přesné lokalizaci polohy vypořádat s nedostatkem telefonů s přijímačem
GPS/A-GPS. Především z tohoto důvodu se dnes považují systémy A-GPS za mrtvou větev
vývoje.
Druhou metodou lokalizace polohy založenou na mobilním telefonu je metoda E-OTD
(The enhanced observed time difference method). Je založena téměř na stejném principu jako
9
metoda UL-TOA (viz výše), jen s tím rozdílem, že vysílajícím prvkem jsou základnové
stanice a výpočet zpoždění signálu provádí přímo mobilní telefon. Pokud zná mobilní telefon
přesné umístění všech BTS (má je v paměti nebo BTS sama vysílá informaci o svojí poloze),
potom může svoji polohu zjistit sám. V opačném případě může odeslat takto zjištěná data
vyhodnocovacímu centru, které vypočítá polohu mobilu a pošle mu ji zpět. Přesnost metody
E-OTD je v otevřené krajině přibližně 60 metrů, v městských oblastech se odchylka pohybuje
okolo 200 metrů.
Odeslání informací do vyhodnocovacího centra a výpočet polohy na základě odpovědi
z tohoto centra (případně z údajů o poloze BTS) zvládne i aplikace SIM toolkit. Pokud by
telefon k zjištění polohy musel mít v paměti informace o umístění základnových stanic a ty
zpracovávat, potom už by potřeboval přídavné zařízení na zpracování těchto dat. Takový
mobil ovšem v současnosti neexistuje.
Pokud si odmyslíme v praxi zcela nepoužitelné sítě vybavené A-GPS, potom můžeme
uvažovat pouze o metodě E-OTD. Ta se ovšem v praxi také příliš nepoužívá, protože
vyžaduje upravené mobilní telefony. Kvůli tomu je méně potenciálních zákazníkům a o
takovou službu operátoři nemají zájem. Investice do sítě by navíc rozhodně nebyly o mnoho
menší oproti metodám založeným na spolupráci se sítí GSM – přinejmenším by operátor
musel postavit vyhodnocovací centrum a upravit svoje základnové stanice.
Možnosti metod E-OTD a UL-TOA
Obr. 1.4. Princip metod E-OTD a UL-TOA
Kombinované metody
I když známé aplikace lokalizace polohy v sítích GSM využívají aplikace SIM toolkit
(podobně jako u nás jediná komerční služba Paegas Locator), jsou založeny především na
zjištění polohy mobilu sítí. Zmiňovaný Paegas Locator je založen na metodě CGI+TA.
Ovšem aplikace SIM toolkit neslouží pouze jako bezpečnostní prvek (ověřuje, jestli polohu
zjišťuje oprávněná osoba), ale zjišťuje také informace o ostatních základnových stanicích
10
v dosahu mobilu – což jsou prvky používané v metodě UL-TOA nebo E-OTD. Podobným
směrem se vydali i ostatní operátoři sítí GSM (v celé Evropě) – namísto pořizování hotových
řešení od svých dodavatelů technologií založených na jedné metodě raději tyto metody
kombinují tak, aby snížili náklady na změny v sítích GSM a současně zmenšili nároky na
schopnosti mobilních telefonů. Právě různé schopnosti mobilů jsou příčinou toho, že Paegas
Locator provozovaný na různých skupinách přístrojů ukáže polohu s odlišnou odchylkou.
Závěr
I když lokalizace polohy naráží na nedůvěru uživatelů a na právní překážky, mají před
sebou tyto služby zřejmě růžovou budoucnost. Díky zjišťování polohy je možné nabízet
uživatelům spoustu užitečných i zábavných služeb (plus pro ně), za které samozřejmě budou
platit (plus pro operátory). A i když tyto služby závisí na dostupnosti a používání moderních
technologií (GPRS, WAP), jsou méně technologicky náročné než technologie samotné. Navíc
může zájem o praktické služby založené na lokalizaci polohy povzbudit zájem o dnes málo
využívaný WAP a nepříliš dostupné GPRS. Ostatně, aplikace využívající toho, že ví, kde se
uživatel nachází, jsou typickou službou sítí UMTS – ty mají lokalizaci polohy přímo ve svých
standardech a definicích.
11
2. Architektura systému tísňového volání (ecall)
Architektura systému tísňového volání (e-call) popisuje, jak mají být stávající zařízení
uspořádána tak, aby byl zachytitelný každý prvek mající vazbu se vzniklou nouzovou
(nehodovou) událostí. Mezi základní prvky lze zahrnout:
•
•
•
•
Vozidlo a jeho posádku
Centrum tísňového volání (PSAP)
Poskytovatele služeb, se kterými má majitel vozidla podepsanou smlouvu
Pohotovostní jednotky/stanice, dispečeři Centra tísňového volání, policejní jednotky,
ambulance, hasiči atd.
2.1. Tísňové volání - mobilní telefon
Obr. 2.1 Princip tísňového volání s užitím mobilního telefonu
Jestliže řidič vozidla potřebuje asistenci v nouzové situaci, může uskutečnit hovor na linku
112 užitím mobilního telefonu nebo pevné linky. 112 je evropské nouzové telefonní číslo,
které bylo odsouhlaseno v rámci CGALIES iniciativy. Toto číslo funguje a bude fungovat po
celé Evropě. Pokud telekomunikační operátor detekuje hovor 112, automaticky k němu
přiřadí identifikaci linky zákazníka (CLI) jako data v hovoru, a směruje hovor na Centrum
tísňového volání (Public Safety Answering Point - PSAP). PSAP je centrála pro obsluhu
nouzových hovorů a informování pohotovostních jednotek nebo dispečerů jednotlivých
složek Integrovaného záchranného systému (IZS).
2.2. Tísňové volání - mobilní telefon a GSM lokalizace
12
Obr. 2.2 Princip tísňového volání s užitím mobilního telefonu a GSM lokalizace
Díky struktuře nové linky E112 je nyní možné mnohem rychleji vyslat pohotovostní
jednotky na místo nehody, a to díky znalosti polohy volajícího získané z GSM lokalizace. Od
července 2003 je podle úmluvy o E112 od telekomunikačních operátorů požadováno
poskytovat Centru tísňového volání (PSAP) informace o poloze i o identifikaci linky
zákazníka (CLI).
2.3. Vozidlová jednotka
Nárůst používání elektronických zařízení v motorových vozidlech, jako např.:
•
•
•
•
•
•
řízení převodovky,
elektronické řízení motoru (Motronic),
protiblokovací zařízení (ABS),
regulace prokluzu hnacích kol (ESP),
palubní počítač,
navigace,
13
•
zádržné systémy apod.
vytváří nutnost vzájemného propojení (zesíťování jednotlivých řídících jednotek).
Výměna informací mezi řídícími systémy snižuje počet snímačů a zlepšuje využití
jednotlivých systémů.
Rozhraní lze rozdělit do dvou kategorií:
•
•
konvenční rozhraní, např.: binární signály (spínané ANO/NE), poměrná sepnutí
(pulzně modulované signály) - Konvenční komunikace v motorovém vozidle se
vyznačuje tím, že je každému signálu přiřazeno samostatné vedení. Binární signály
mohou přenášet jen dva stavy “1“ nebo “0“ (binární kódy). Pomocí poměrných sepnutí
(potenciometr) lze přenášet více stavů, jako např. polohu škrtící klapky. Nárust výměn
dat mezi elektronickými komponenty v motorovém vozidle nelze již s konvenčními
rozhraními úspěšně realizovat.
sériový datový přenos, např. Controller Area Network (CAN) - Hlavní tři oblasti
použití datového přenosu CAN v motorových vozidlech jsou vzájemné propojení
řídících jednotek, karosériová a komfortní elektronika (Multiplex), mobilní
komunikace.
CAN hnacího ústrojí obsahuje řídící jednotku ABS, panelu přístrojů, motoru, airbagů a
posilovače řízení a dále spojení s centrální řídící jednotkou
CAN komfortního systému obsahuje řídící jednotky klimatizace, pravých předních dveří,
levých předních dveří, pravých zadních dveří a levých zadních dveří, dále pak centrální řídící
jednotku komfortního systému a spojení s centrální řídící jednotkou vozu.
V současné době je airbagový systém nejčastěji sestaven z komponent popsaných dále.
Vozidla s čelním airbagem řidiče nebo řidiče a spolujezdce mají jednu centrální řídící
jednotku (ŘJ) aibagu umístěnou v interiéru vozidla. Tato jednotka je umístěna v interiéru
z důvodu měření zrychlení v části vozidla, kde jsou pasažéři, aby senzorická část ŘJ
reagovala na zrychlení, kterému jsou vystaveni cestující. V ŘJ jednotce airbagu jsou umístěny
dva akcelerometry, které měří zrychlení, resp. zpomalení vozu v podélném a příčném směru.
Toto měření probíhá v reálném čase a je v reálném čase i vyhodnocováno. Dalšími
komponenty jsou moduly aibagu s roznětkou, generátorem a vzduchovým vakem. Poslední
částí systému je elektrická instalace propojující jednotlivé komponenty. ŘJ aibagu je napojena
na další ŘJ a rozhraní vozidla. V případě, že jsou ve vozidle zabudovány i boční airbagy, je
vozidlo vybaveno dvěma externími snímači, v nichž je akcelerometr a procesor. Snímače pro
boční náraz komunikují s ŘJ airbagu. Tyto externí snímače jsou umístěny na příčnících pod
předními sedadly co nejblíže k prahům vozidla. Snímače bočních airbagů se používají
z důvodu časově náročnějšího vyhodnocení bočního nárazu, protože boční deformační zóna je
velmi krátká a cestující je v krátkém čase vystaven účinkům nárazu. Rozmístění snímačů ve
vozidle vidíte na obr. 2.3. Některé vozy mají prostřednictvím ŘJ airbagu odpalované i
předepínače bezpečnostních pásů.
Vzhledem k tomu, že je v podélném směru pouze jeden akcelerometr v ŘJ airbagu, mohlo
by dojít lokálním úderem do místa upevnění ŘJ k odpálení čelních airbagů. Proto je v ŘJ
umístěn tzv. safing senzor s mechanickou vazbou, reagující na podélné zpomalení vozidla o
hodnotě 2,5 g. Safing senzor je vložen do elektrické větve vedoucí ke generátorům čelních
airbagů, takže při úderu např. kamenem do spodku vozidla nemůže dojít k nežádoucímu
odpálení airbagu.
14
Obr. 2.3 Čelní a boční airbagy
Obr. 2.4 Schématické znázornění elektrického systému airbagů:
1 – řídící jednotka systému, 2 – spínač zapalování motoru, 3 – baterie, 4 – čelní čidla
nárazu, 5 – kroužek se spirálovým kabelem, 6 – zapalovací jednotka / vyvíječ plynu, 7 –
airbag řidiče, 8 – vypínač airbagu spolujezdce, 9 – snímač obsazení sedadla spolujezdce, 10
15
– airbag spolujezdce, 11 – napínač bezpečnostních pásů, 12 – boční čidla nárazu, 13 – boční
airbagy, 14 – diagnostická přípojka, 15 – kontrola systému airbagů
Vozidla s airbagem jsou zároveň vybavována předepínači bezpečnostních pásů. Tyto
předepínače pracují na mechanickém nebo elektrickém principu. V případě mechanického
předepínače je vlivem zpomalení vozidla sepnut kontakt, a tím odpálen generátor předepínače
pásu. Tento generátor vyvine tlak ve válci s pístem. Vlivem vysokého zvýšení tlaku dojde
k posunutí pístu o maximálně 200 mm. Na píst je připevněn naviják pásu, který se vlivem
posuvu pístu rovněž posune (navine) a přitáhne tak připoutaného pasažéra do sedadla.
V případě elektronického předepínače pracuje vše stejně s jediným rozdílem: Povel
k odpálení je vydán řídící jednotkou airbagu. Elektricky předepírané pásy jsou výhodnější
z hlediska možnosti optimálního sladění návaznosti odpálení pásů a airbagů.
Obr. 2.5 Kombinovaná řídící jednotka pro předepínače bezpečnostních pásů, čelní a
boční airbagy
Vozidlová jednotka (IVS) využívaná pro tísňové volání snímá data z vozidlových sběrnic
a tyto data vyhodnocuje tak, aby by byly minimalizovány falešné poplachy a zároveň byla
maximalizována pravděpodobnost vyslání tísňového volání při nehodě.
2.4. Infrastruktura systému tísňového volání (e-call)
E-MERGE infrastruktura se skládá z vozidlové jednotky (označovaná buď jako OBU On-Board Unit, nebo jako IVS - In-Vehicle-System), která je vestavěna ve vozidle za účelem
manuálního či automatického generování tísňového hovoru 112, a vyslání tzv. minimálních
dat z vozidla do Centra tísňového volání (PSAP). Vozidlová jednotka je vestavěné počítačové
16
zařízení speciálně navržené pro interiér vozidla schopné přijímat GPS signály. Vozidlo je také
vybaveno několika senzory, které monitorují stav částí vozu. GSM komunikační modul je
vybaven externím mikrofonem a reproduktorem. Vozidlová jednotka monitoruje senzory a
v případě aktivace minimálně dvou z nich spolu s jinými informacemi např. o deceleraci
vysílá datovou zprávu do Centra tísňového volání (PSAP) o vzniklé nehodě.
V případě nehody jsou vysílány různé zprávy přes navržený protokol, kde pro oblast
tísňového volání byl zvolen Globální telematický protokol stanovený Telematickým fórem v
rámci společnosti ERTICO. Tento protokol vznikl sjednocením protokolů GATS a ACP.
První možné řešení tísňového volání je založeno na vyslání dat z vozidlové jednotky do
systému poskytovatele služeb (SP - Service Provider), který obdrží minimální data a začlení
je do speciální databáze, ze které jsou pak dostupné pro telekomunikační operátory na
vyžádání a to na základě identifikace linky zákazníka (CLI). Tato architektura zabezpečuje
provizorní řešení nikoli optimalizované řešení přenosu dat mezi vozidlovou jednotkou (IVS,
OBU) a Centrem tísňového volání (PSAP).
Obr 2.6: Provizorní řešení komunikace vozidlové jednotky (OBU) s Centrem tísňového
volání (PSAP)
Následující tabulka popisuje jednotlivé body komunikace mezi vozidlovou jednotkou (OBU,
IVS) a Centrem tísňového volání (PSAP):
17
Pořadí
událostí
1
2
3
4
5
6
Popis události
Vozidlová jednotka (OBU) generuje hovor 112 a v něm minimální data (v protokolu GTP),
která směřují k poskytovateli služby (SP), se kterým má uživatel uzavřenu smlouvu. Číslo
je stanoveno výrobcem vozidla (toto číslo může být podle značky vozidla a fungovat i když
řidič nemá smlouvu s poskytovatelem služby).
Mobilní operátor rozpozná a zpracuje hovor 112 a přesměruje ho na Centrum tísňového
volání (PSAP) dohromady s identifikací linky zákazníka (CLI). Mobilní operátor dále posílá
datový hovor po druhé komunikační cestě (minimální data v GTP) k poskytovateli služeb
(SP).
Mobilní operátor získá data o poloze volajícího a uloží je do lokalizační databáze.
Poskytovatel služby (SP) obdrží datový hovor (minimální data v GTP) dohromady
s identifikací linky volajícího (CLI), interpretuje GTP datový hovor a vloží minimální data do
své databáze.
Jestliže existuje kontrakt se zákazníkem, IP adresa a telefonní číslo poskytovatele služby
(SP) jsou vloženy jako informace do minimálních dat v GTP.
Lokalizační server telekomunikačního operátora získá minimální data z databáze
poskytovatele služeb (SP) podle identifikace linky volajícího (CLI).
Centrum tísňového volání (PSAP) přijme hlasový hovor 112 dohromady s identifikací linky
zákazníka (CLI) a obdrží data o poloze a minimální data od lokalizačního serveru
mobilního operátora podle ETSI/EMTEL specifikace v závislosti na E112.
Druhé doporučené řešení komunikace vozidlové jednotky (OBU) a Centra tísňového volání
(PSAP) je založeno na zasílání minimálních dat přímo do Centra tísňového volání (PSAP), na
základě nich může získat PSAP úplná data od poskytovatele služeb (SP).
Pořadí
události
1
2
3
4
5
6
7
8
9
Popis události
Vozidlová jednotka (OBU) pošle nouzový hovor do Centra tísňového volání (PSAP) přes
hlasový kanál rozdělený na dvě části: první část obsahuje posílání dat GSM / GPRS / UMTS
přes hlasový kanál a druhá část reprezentuje 112 hlasovou komunikaci. Datovou část
hovoru uzavírájí minimální data definovaná v rámci E-Merge projektu (minimální data v GTP
protokolu). Poslání dat ještě před vytvořením hlasové komunikace zabezpečuje ty případy,
kdy řidič není schopen mluvit nebo nouzový hovor byl generován automaticky spuštěním
vozidlových senzorů.
Nouzový hovor (data + hlas) prochází sítí mobilního telekomunikačního operátora, kde je
zpracován a doplněn identifikací linky zákazníka (CLI). Dále má telekomunikační operátor
povinnost uložit data o poloze volajícího do databáze lokalizačního serveru. Po obdržení
nouzového hovoru, telekomunikační operátor pošle tento hovor (E-Merge hovor)
příslušnému Centru tísňového vlání (PSAP) po pevné síti.
Centrum tísňového volání (PSAP) obdrží dva odlišné typy komunikace po pevné síti na
společném kanálu: první je datová komunikace v GTP protokolu a druhá je normální 112
hlasová komunikace. Minimální data spolu s identifikací linky zákazníka (CLI) jsou doručeny
jako transparentní data dohromady s hlasem. V tu chvíli také telekomunikační operátor
pošle informace o poloze do Centra tísňového volání (PSAP) užitím mobilního lokalizačního
protokolu vybraného ETSI.
Centrum tísňového volání (PSAP) odešle potvrzení o obdržení dat do vozidlové jednotky a
interpretuje GTP minimální data užitím GTP převaděče.
V případě že uživatel podepsal smlouvu s poskytovatelem služeb (SP), vozidlová jednotka
(OBU, IVS) pošle úplná data prostřednictvím telekomunikačního operátora k poskytovateli
služeb (SP), a to po obdržení potvrzení od Centra tísňového volání (PSAP).
Poskytovatel služeb (SP) obdrží datovou zprávu zakódovanou v definovaném protokolu a
začne vyřizovat hovor, vloží přidaná E-Merge data do E-Merge databáze, aby k nim mělo
přístup Centrum tísňového volání (PSAP).
Poskytovatel služeb (SP) odešle potvrzení o převzetí dat do vozidlové jednotky (OBU, IVS).
V případě potřeby překladu, poskytovatel služby (SP) začne požadovat na Centru tísňového
volání (PSAP) vytvoření konferenčního hovoru s řidičem přes bezplatnou linku.
Jestliže řidič podepsal smlouvu s poskytovatelem služeb (SP), Centrum tísňového volání
18
10
11
12
(PSAP) začne přistupovat do E-Merge databáze, aby obdrželo úplná E-Merge data od
poskytovatele služeb (SP).
Centrum tísňového volání (PSAP) zpracuje obdržená data.
Centrum tísňového volání (PSAP) odešle veškeré detaily nejbližšímu záchrannému centru.
Centrum tísňového volání (PSAP) komunikuje s poskytovatelem služeb (SP), aby mu
unožnil řešit po-havarijní služby s přidanou hodnotou. Tato komunikace může proběhnout
přes pevnou síť jako jednoduchý hovor mezi operátory nebo přes internet. Centrum
tísňového volání (PSAP) může vstoupit do E-Merge databáze a připojit sem veškeré
informace o záchranných centrech.
Obr. 2.7: Doporučené řešení komunikace vozidlové jednotky (OBU) a Centra
tísňového volání (PSAP)
V případě že řidič má uzavřenou smlouvu s poskytovatelem služby (SP), posílají se ještě
poskytovateli služeb (SP) úplná data a ten tyto informace zpřístupňuje Centru tísňového
volání (PSAP) prostřednictvím E-MERGE databáze. Jednotlivé události jsou popsány v
následující taulce a na Obr. 2.8.
Pořadí
události
1
Popis události
Vozidlová jednotka (OBU) posílá datovou zprávu s úplnými daty (GTP) k poskytovateli
služby (SP), jestliže s ním má řidi uzavřenou smlouvu.
19
2
3
4
Mobilní operátor směruje datový hovor (úplná data) k poskytovateli služby (SP).
Poskytovatel služby (SP) obdrží úplná data od vozidla včetně identifikace linky zákazníka
(CLI)
Poskytovatel služby (SP) přidá úplná data do E-MERGE databáze.
Obrázek 2.8: Přenos dat z vozidlové jednotky (OBU) k poskytovateli služeb (SP)
Centrum tísňového volání (PSAP) je centrum odpovědné za poskytnutí první pomoci a
reakci na nouzový hovor 112 a za přesměrování hovoru 112 na odpovědného dispečera.
Základna Centra tísňového volání směruje informace na relevantní druhý stupeň Centra
tísňového volání (PSAP) na zakladě informací obdržených z rozhovoru s člověkem volajícím
na číslo 112.
V případě budoucího hovoru generovaného vozidlem a směrovaného přímo na Centrum
tísňového volání (PSAP), obdrží PSAP automaticky generovaná data (minimální data nebo
data přidaná poskytovatelem služby). Na základě těchto dat bude Centrum tísňového volání
(PSAP) schopno lépe směrovat hovor na druhý stupeň a ten bude díky těmto datům vědět jaký
typ včasné pomoci má poslat na místo nehody.
V případě že operátor Centra tísňového volání nemluví jazykem řidiče a jestliže má řidič
podepsanou smlouvu s poskytovatelem služby (SP), může Centrum tísňového volání (PSAP)
navázat konferenční hovor mezi řidičem, operátorem příslušného poskytovatele služeb (SP) a
sebou samým (PSAP). Číslo bezplatné linky na poskytovatele služby (SP) je zahrnuto
v minimálních datech (v GTP protokolu). Informace o přímém kontaktu s poskytovatelem
služby (SP) je obsažena v přidaných datech posílaných od poskytovatele služeb (SP)
do Centra tísňového volání (PSAP).
20
3. Procesní modely systému tísňového volání
V této části jsou popsány základní procesy systému tísňového volání, které jsou rozděleny
do pěti skupin:
•
•
•
•
•
Automatický E-Call
Automatický E-Call, bez smlouvy se SP
Manuální E-Call zmáčknutím SOS tlačítka
Manuální E-Call , bez zaplacené smlouvy
Chybná funkce vedoucí k falešnému hovoru
Každá ze skupin má svůj detailní popis a to pro následující situace:
•
•
•
•
Řidič je schopen mluvit
Řidič je schopen mluvit, ale je nutný překlad
Tichý hovor
Hovor uskutečněný očitým svědkem (tzv. samaritánem)
3.1. Automatické volání - řidič vozidla je schopen
mluvit a má smlouvu s poskytovatelem služby
3.1.1. Popis
Spojení je založeno na E112 a přenosu minimálních dat včetně přidaných dat o poloze
telekomunikačním operátorem. Hlas, informace o poloze a minimální data jsou použity
k vyslání adekvátní pomoci na místo nehody. PSAP má možnost na základě identifikace
poskytovatele služby a prostřednictvím bezplatného telefonního čísla poskytovatele služby
(obsaženo v minimálních datech) aktivovat konferenční hovor s poskytovatelem služby a
vyžádat si přidaná data z E-MERGE databáze poskytovatele služby po Internetu.
Automatický E112 hovor je vytvořen v případě aktivace minimálně dvou kritických senzorů.
Vozidlová jednotka vytvoří zprávu s minimálními daty a pošle ji do Centra tísňového volání
(PSAP) a po přijmutí potvrzení o doručení jsou vyslána úplná data k poskytovateli služby.
Hlasový hovor je navázán automaticky s PSAP a operátorovi PSAP je umožněno
komunikovat s řidičem. Operátor PSAP okamžitě kontaktuje pohotovostní jednotky a
požaduje co nejrychlejší pomoc pro řidiče.
3.1.2. Zahájení procesu
Dojde k havárii a jsou aktivovány minimálně dva kritické senzor, což má za následek že
vozidlová jednotka začne automatickou nouzovou sekvenci.
21
3.1.3. Pořadí událostí
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Popis události
Zpráva nouzového volání je spuštěna automaticky po aktivaci minimálně dvou kritických
senzorů (např. airbag a decelerace).
E-MERGE minimální data jsou poslána v hlasovém kanálu po telekomunikačním
operátorovi k PSAP.
Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a
komunikaci).
Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních dat
SP.
PSAP odpovídá na hlasový hovor.
PSAP komunikuje s řidičem.
PSAP obdrží data o poloze z lokační databáze telek. operátora.
PSAP zobrazí minimální data.
PSAP vyšle pomoc na místo nehody.
E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi.
Telekomunikační operátor odešle potvrzení o přijetí vozidlu.
Úplná data jsou přesměrována k SP včetně identifikačních CLI dat
Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí úplných dat SP.
SP odešle přidaná data do své E-MERGE databáze.
PSAP se přihlásí do E-MERGE databáze. Identifikátorem SP databáze je síťové ID nebo
SP-ID číslo nebo IP adresa.
PSAP jsou posílána data z E-MERGE databáze.
PSAP dokončil stahování dat z E-MERGE databáze.
PSAP má možnost navázat konferenční hovor s vozidlem, poskytovatelem služby (SP) a
pohotovostní jednotkou (EA - Emergency Authority). Konferenční hovor je navázán na
bezplatné lince poskytovatele služeb (SP).
PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní jednotku (EA)
pro pozdější odeslání potvrzení.
PSAP ukončí hlasový hovor.
Vozidlová jednotka OBU ukončí nouzovou sekvenci
3.2. Automatické volání - řidič vozidla je schopen
mluvit, je nutný překlad a má smlouvu s SP
3.2.1. Popis
Tento případ umožňuje řidiči automaticky kontaktovat Centrum tísňového volání (PSAP),
ale jestliže PSAP operátor řidiči nerozumí, je navázán konferenční hovor s poskytovatelem
služby (SP), se kterým má řidič podepsanou smlouvu, aby řidič mohl komunikovat ve svém
rodném jazyce. PSAP má možnost komunikovat díky bezplatnému telefonnímu číslu SP
(součást minimálních dat), aktivovat konferenční hovor se SP kvůli hlasové komunikaci a
přijmutí přidaných dat z E-MERGE databáze poskytovatele služby po intermetu. Služba je
aktivována v případě aktivace minimálně dvou kritických senzorů. Vozidlová jednotka
vytvoří zprávu s minimálními daty a pošle ji do PSAP a po přijmutí potvrzení jsou vyslána
úplná data k poskytovateli služby SP. Hlasový hovor je navázán automaticky s PSAP a
operátorovi PSAP je umožněno komunikovat s řidičem. Operátor PSAP okamžitě kontaktuje
pohotovostní jednotky a požaduje co nejrychlejší pomoc pro řidiče. Hlasový hovor je
generován automaticky z vozidla k PSAP operátorovi, aby byla umožněna komunikace
s řidičem. Jestliže je řidič v cizině a nemluví anglicky ani řečí země ve které se nachází, PSAP
22
operátor analyzuje minimální data, aby získal kontakt na odpovídajícího SP a poté naváže
konferenční hovor s řidičem a SP operátorem. PSAP operátor kontaktuje pohotovostní
jednotky a požaduje co nejrychlejší pomoc pro řidiče.
Dojde k havárii a jsou aktivovány minimálně dva kritické senzory, což má za následek, že
vozidlová jednotka začne vysílat automatickou nouzovou sekvenci.
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Popis události
Nouzová sekvence je spuštěna automaticky po aktivaci minimálně dvou kritických
komunikaci).
Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních
dat od PSAP.
PSAP nerozumí řidiče a je třeba překlad.
PSAP obdrží data o poloze z lokační databáze od telekomunikačního operátora.
Telekomunikační operátor odešle potvrzení o přijetí dat vozidlu.
Úplná data jsou přesměrována k SP včetně identifikačních CLI dat.
Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí úplných dat
provozovatelem služby SP.
PSAP se přihlásí do E-MERGE databáze. Identifikátorem databáze provozovatele
služby je síťové ID číslo nebo SP-ID číslo nebo IP adresa.
PSAP naváže konferenční hovor s vozidlem, SP a pohotovostní složkou EA.
Konferenční hovor je navázán na bezplatné lince SP.
PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní službu EA
Vozidlová jednotka OBU ukončí nouzovou sekvenci.
3.3. Automatické volání - tichý hovor se smlouvou
s provozovatelem služby
3.3.1. Popis
V tomto případě PSAP operátor nemůže navázat hlasový kontakt s řidičem a považuje
hovor za tichý. Veškeré informace o nehodě jsou tak získány z minimálních dat a úplných dat.
Pohotovostní jednotky nemohou být vyslány dokud nejsou obdržena úplná data.
23
Dojde k havárii a jsou aktivovány minimálně dva kritické senzory, což má za následek, že
vozidlová jednotka začne vysílat automatickou nouzovou sekvenci.
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Popis události
komunikaci).
dat PSAP.
PSAP neslyší řidiče (tichý hovor).
PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora.
Telekomunikační operátor odešle potvrzení o přijetí dat zpět vozidlu.
SP.
PSAP se přihlásí do E-MERGE databáze. Identifikátorem SP databáze je síťové ID
číslo nebo SP-ID číslo nebo IP adresa.
PSAP má všechna data z E-MERGE databáze.
PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní skožku EA
Vozidlová jednotka ukončí nouzovou sekvenci.
3.4. Automatické volání - řidič je schopen komunikovat
a neexistuje smlouva s poskytovatelem služby
3.4.1. Popis
V tomto případě řidič nemá podepsanou smlouvu se SP a nemůže tudíž využít výhody
přidaných dat pro PSAP a jazykové podpory.
Dojde k havárii a jsou aktivovány minimálně dva kritické senzory což má za následek že
vozidlová jednotka IVS začne automatickou nouzovou sekvenci.
24
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
Popis události
komunikaci).
dat PSAP.
Identifikace provozovatele služby SP-ID není zapsána v minimálních datech (identifikace
že uživatel namá placeny služby E-MERGE) a tak nejsou dostupná přidaná data.
3.5. Automatické volání - řidič není schopen
komunikace a neexistuje smlouva se
provozovatelem služby
3.5.1. Popis
hovor za tichý. Veškeré informace o nehodě jsou tak získány z minimálních dat. Řidič nemá
podepsanou smlouvu se SP a nemůže tudíž využít výhody přidaných dat pro PSAP a jazykové
podpory.
Dojde k havárii a jsou aktivovány minimálně dva kritické senzory což má za následek že
vozidlová jednotka IVS začne automatickou nouzovou sekvenci.
Pořadí
události
1
2
3
4
5
6
Popis události
operátorovi k PSAP
komunikaci).
dat PSAP.
PSAP nesliší řidiče (tichý hovor).
25
7
8
9
10
11
12
PSAP vyšle pomoc na místo nehody jen na základě minimálních dat. PSAP nebo
pohotovostní složka EA mohou rozhodnout jestli se jedná o nouzovou situaci a dle
tohoto rozhodnutí vyjedou či nevyjedou na místo události.
Identifikátor provozovatele služby SP-ID není zapsán v minimálních datech (identifikace,
že uživatel namá placeny služby E-MERGE) a tak nejsou dostupná přidaná data.
3.6. Manuální volání - řidič vozidla je schopen
komunikace a má smlouvu s poskytovatelem služby
3.6.1. Popis
Tento případ umožňuje řidiči manuálně kontaktovat PSAP přes hlasový kanál v případě
nehody a požadovat asistenci pohotovostních jednotek. PSAP má možnost navázat
konferenční hovor se SP, se kterým má řidič podepsanou smlouvu. PSAP má možnost
založenou na identifikačním čísle provozovatele služby SP-ID a bezplatném telefonním čísle
SP (součást minimálních dat) aktivovat konferenční hovor se SP kvůli hlasové komunikaci a
přijmutí přidaných dat ze SP E-MERGE databáze po intermetu. Služba je aktivována
v případě manuálního stlačení SOS tlačítka. Vozidlová jednotka vytvoří zprávu
s minimálními daty a pošle ji do PSAP a po přijmutí potvrzení jsou vyslána úplná data k SP.
Hlasový hovor je navázán manuálně s PSAP a operátorovi PSAP je umožněno
komunikovat s řidičem. Operátor PSAP okamžitě kontaktuje pohotovostní jednotky a
požaduje co nejrychlejší pomoc pro řidiče.
Řidič vozidla manuálně zmáčkne SOS tlačítko, což má za následek, že vozidlová jednotka
vyšle automatickou nouzovou sekvenci.
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
13
Popis události
Nouzová sekvence je spuštěna manuálně stlačením SOS tlačítka.
komunikaci).
dat PSAP.
26
14
15
16
17
18
19
20
21
SP.
nebo SP-ID číslo nebo IP adresa.
PSAP má všechna data z E-MERGE databáze.
PSAP má možnost navázat konferenční hovor s vozidlem, SP a pohotovostní složkou
EA. Konferenční hovor je navázán na bezplatné lince SP.
PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní složku EA
3.7. Manuální volání - řidič je schopen komunikace, je
třeba překlad a má smlouvou s poskytovatelem
služby
3.7.1. Popis
Tento případ umožňuje řidiči manuálně kontaktovat PSAP přes hlasový kanál. Jestliže
PSAP operátor nerozumí řidiči, je navázán konferenční hovor se SP, se kterým má řidič
podepsanou smlouvu tak, aby řidič mohl komunikovat ve svém rodném jazyce. PSAP má
možnost na základě identifikace provozovatele služby SP-ID a bezplatného telefonního čísla
SP (součást minimálních dat) aktivovat konferenční hovor se SP kvůli hlasové komunikaci a
přijmutí přidaných dat ze SP E-MERGE databáze po intermetu.
začne vysílat automatickou nouzovou sekvenci.
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
13
Popis události
komunikaci).
dat PSAP.
PSAP odpovídá na hlasový hovor
PSAP nerozumí řidiči a je třeba překlad.
SP.
27
14
15
16
17
18
19
20
21
nebo SP-ID číslo nebo IP adresa.
PSAP naváže konferenční hovor s vozidlem, SP a pohotovostní jednotkou EA.
Konferenční hovor je navázán na bezplatné lince SP.
PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní jednotky
EA pro pozdější odeslání potvrzení.
3.8. Manuální E-call - tichý hovor, existuje smlouva s
poskytovatelem služby
3.8.1. Popis
Služba je aktivována, když řidič manuálně stlačí SOS tlačítko.Vozidlová jednotka vyšle
zprávu minimálních dat a po potvrzení jejího převzetí jsou poslána úplná data SP. Hlasová
komunikace umožňující PSAP operátorovi mluvit s řidičem je navázána stlačením tlačítka.
V tomto případě se ale PSAP operátor nemůže dostat do hlasového kontaktu s řidičem.
Veškeré informace o nehodě jsou tak získány z minimálních dat a pokud je třeba i z úplných
dat. Pohotovostní jednotky nemohou být vyslány dokud nejsou obdržena úplná data.
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Popis události
komunikaci).
dat PSAP.
PSAP neslyší řidiče (tichý hovor).
SP.
SP odešle přidaná data do své E-MERGE databáze
PSAP se přihlásí do E-MERGE databáze. Identifikátorem SP databáze je síťové ID nebo
Sp-ID číslo nebo IP adresa
28
16
17
18
19
20
PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní složky EA
Vozidlová jednotka ukončí nouzovou sekvenci
3.9. Manuální E-call – volá očitý nebo náhodný svědek
3.9.1. Popis
Tento případ umožňuje řidiči vozidla požadovat pohotovostní jednotky z důvodu pomoci
někomu jinému, kdo se stal obětí nehody. Služba je aktivována, když řidič manuálně stlačí
SOS tlačítko. Vozidlová jednotka vyšle zprávu minimálních dat pro PSAP a po potvrzení
jejího převzetí jsou poslána úplná data SP. Hlasová komunikace s PSAP je navázána
manuálně, aby operátor PSAP mohl komunikovat s řidičem.
Řidič/pasažér vozidla A zpozoruje nehodu vozidla B nebo člověka C páchajícího škodu.
Řidič/pasažér manuálně zmáčkne SOS tlačítko, což má za následek, že vozidlová jednotka
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Popis události
komunikaci).
dat PSAP.
PSAP zobrazí minimální data se zvláštním zaměřením na to, z jakého místa byl hovor
vyslán.
SP.
PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní složku EA
29
3.10. Manuální volání - řidič je schopen komunikovat,
neexistuje smlouva s poskytovatelem služby
3.10.1. Popis
Služba je aktivována když řidič manuálně stlačí SOS tlačítko. Vozidlová jednotka vyšle
zprávu minimálních dat pro PSAP. Hlasová komunikace s PSAP je navázána manuálně aby
operátor PSAP mohl komunikovat s řidičem. Operátor PSAP okamžitě kontaktuje
pohotovostní jednotky a požaduje co nejrychlejší pomoc pro řidiče.
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
Popis události
komunikaci).
dat PSAP.
PSAP komunikuje s řidičem
PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora
Identifikační číslo provozovatele služby SP-ID není zapsáno v minimálních datech
(identifikace, že uživatel namá placeny služby E-MERGE) a tudíž nejsou dostupná
přidaná data
3.11. Manuální volání - tichý hovor, neexistuje smlouva
s poskytovatelem služby
3.11.1. Popis
hovor za tichý. Veškeré informace o nehodě jsou tak získány z minimálních dat. Řidič nemá
podepsanou smlouvu se SP a nemůže tudíž využít výhody přidaných dat pro PSAP a jazykové
podpory.
30
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
Popis události
komunikaci).
dat PSAP.
PSAP nesliší řidiče (tichý hovor).
PSAP vyšle pomoc na místo nehody jen na základě minimálních dat. PSAP nebo
pohotovostní jednotka EA mohou rozhodnout jestli se jedná o nouzovou situaci a podle
toho můžou či nemusí vyjet na místo.
Identifikace provozovatele služby SP-ID není zapsána v minimálních datech
(identifikace, že uživatel nemá placeny služby E-MERGE) a tudíž nejsou dostupná
přidaná data.
3.12. Chybná funkce jednotky vedoucí k falešným
hovorům
3.12.1. Popis
Tento případ se týká interní funkce vozidlové jednotky, která vyvolá nouzové volání (Ecall), aniž by existovala nouzová situace. Chybová funkce, která vede k falešnému hovoru,
není způsobena jen vozidlovou jednotkou, ale může být důsledkem nesprávného zacházení
s manuálním SOS tlačítkem. PSAP může díky hlasovému kontaktu s řidičem zjistit, že se
jedná o nesprávnou aktivaci. Tyto falešné aktivace mohou být minimalizovány užitím
efektivního rozhranní člověk-stroj a správným umístěním SOS tlačítka.
Kritické senzory vytvoří falešnou aktivaci, což má za následek, že vozidlová jednotka
3.12.3. Pořadí událostí hlasové spojení
Pořadí
události
1
Popis události
Kritické senzory vytvoří falešnou aktivaci, což má za následek, že vozidlová jednotka
31
2
3
4
5
6
7
8
9
10
11
12
13
vyšle nouzovou sekvenci.
komunikaci).
Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí inimálních
dat PSAP.
Nedošlo k nehodě a tak PSAP ukončí hlasový hovor. PSAP obdrží data o poloze
z lokační databáze telekomunikačního operátora.
SP.
PSAP může na základě identifikace SP v minimálních datech informovat SP o chybné
funkci zařízení, aby zabránil jeho falešnému hovoru.
3.12.4. Pořadí událostí bez hlasového spojení
Pořadí
události
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Popis události
Nouzová služba je spuštěna řidičem manuálně nebo automaticky.
komunikaci).
dat PSAP.
PSAP nemůže přijmout hlasový hovor.
PSAP nemůže komunikovat s řidičem.
PSAP zjišťuje data o poloze spolu s hlasovou komunikací.
PSAP vyšle pomoc na místo nehody, ale nejsou splněny předpoklady pro nouzovou
situaci.
SP.
nebo Sp-ID číslo nebo IP adresa.
PSAP kontaktuje pohotovostní složku EA pro pozdější odeslání potvrzení, ale nejsou
splněny předpoklady pro nouzovou situaci
PSAP ukončí hlasový hovor
Informuje SP o chybné funkci zařízení
32
4. Specifikace systému E-MERGE
4.1. Specifikace dat generovaných vozidlovou
jednotkou (minimálních dat)
4.1.1. Úvod
Tato část popisuje minimální data, která musí být poslána z vozidla v případě nouzového
hovoru. Tato data jsou poslána PSAP po telekomunikačním operátorovi užitím různých
datových a přenosových cest. Informační elementy byly vybrány na základě jejich důležitosti
v nouzové situaci, což znamená, že minimální data popsaná níže slouží k urychlení a zlepšení
doby reakce pohotovostních jednotek.
4.1.2. Informační elementy
Následující informační elementy jsou důležité v nouzové situaci a jsou specifikovány
podle Telematického Fóra, Globalního Telematického Protokolu (GTP), Kódovací
specifikace, 21 březen 2003, Verze 1.0 Reference jsou v datové tabulce (GTP), Kódovací
specifikace, 21 březen 2003, Verze1.0,
Hlavička
Popis: Podle (GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 (6)
Užití: Definuje aktuální podskupinu případu užití
Příklad: Verze 1.0 (6.1 – 6.8)
Zvláštní oprávnění
Popis: Podle (GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 (6.5)
Užití: Úrovně oprávnění
Příklad: Verze1.0 (6.5) taulka 8 úroveň oprávnění bit číslo 1 nejvyšší oprávnění
Verze elementu
Užití: Definuje výrobce vozidla, ID terminálu, Software a Hardware
příklad: Verze 1.0 (22.3 a 22.3.3)
Časová známka (užívá PSAP)
Užití: Definuje čas kdy byla generována zpráva o nehodě
Příklad: 2002-11-27 19:45.21 Verze 1.0 (22.26.1 až 22.26.6)
Lokalizace (užívá PSAP)
Popis: Podle (GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 (22.10, 22.11, 22.12 a
22.19)
33
Užití: Definuje polohu vozidla podle WGS84.
Příklad: N52 45.0010 E005 10.2250 (Dříve 1.2.1 GPS poloha)
Směr (užívá PSAP)
Popis: Směr jízdy určený z posledních tří GPS údajů o poze s 30 metrovým intervalem
(GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 (22.17 and 22.18)
Užití: Definuje v jakém směru se pohybovalo havarované vozidlo
Příklad: Verze 1.0 (22.17 a 22.18 hodnota ½)
Popis vozidla
Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen
2003,Verze 1.0 (22.20)
Užití: Definuje barvu, Model, VIN, Číslo terminálu a licencenční štítek vozidla, aby
záchranná jednotka mohla snadno identifikovat vozidlo
Příklad: Verze 1.0 (22.20.1 až 22.20.8)
a) Rok výroby (užívá PSAP)
2003,Verze 1.0 (22.20.2)
Užití: Definuje rok výroby typu vozidla, jsou pro to určeny 2 digity.
Přiklad: verze 1.0 (22.20.2)
b) Barva vozidla (užívá PSAP)
2003,Verze 1.0 (22.20.6)
Užití: Definuje barvu vozidla
Příklad: Verze 1.0 (22.20.6)
c) Typ vozidla (užívá PSAP)
2003,Verze 1.0 (22.20.7)
Užití: Definuje výrobce a typ vozidla
E-call stav (užívá PSAP)
Popis: Zdroj nouzového hovoru a počet aktivačních prvků včetně manuálních a senzorů:
airbag, převrácení, nárazové senzory podle (GTP), Kódovací specifikace, 21 březen
2003,Verze 1. (22.21)
Užití: informace pro nouzového operátora umožňující mu vyslat pohotovostní jenotky
Příklad: Verze 1.0 (22.22) bit 3 indikuje spuštění airbagu
a) Příčina havárie (E-call data), (užívá PSAP)
2003,Verze 1.0 (22.22.)
Užití: Tabulka 67: Příčina havárie
Bit 1 Aktivováno manuálně
Bit 2 Převrácení vozidla
Bit 3 Aktivace airbagu
Bit 4 Aktivace nárazových senzorů
Tabulka 68: Příčina havárie rozšířený oktet
34
Bit 3 Vozidlo se pohybovalo
příklad: Verze 1.0 (22.22.)
b) Rozpoznání havárie (E-call data), (užívá PSAP)
2003,Verze 1.0 (22.23.)
Užití: Tabulka 69-Senzory havárie
Bit 6-typ paliva je plyn
Tabulka 70- Senzory havárie rozšířený oktet
Bit 3 manuální alarm
Bit 7 manuální E-call alarm
Příklad: Verze 1.0 (22.23.)
Identifikátor poskytovatele služeb (užívá PSAP)
Popis: Může to být IP adresa ve 4 bytovém formátu, IPV4 podle (GTP), Kódovací
specifikace, 21 březen,
Užití: Užití Ipv6 jak bylo definováno Internet Engineering Task Force (IETF) může být užito
po implementaci této specifikace.
Příklad: 193.96.28.72
Telefonní číslo na poskytovatele služeb (PSAP use)
Popis: Může být interní bezplatná linka na SP - 13 digitů podle (GTP), Kódovací
specifikace, 21 březen.
Užití: Toto číslo je užito PSAP organizacemi v Evropě aby mohli kontaktovat SP v případě
nutnosti řešení jazykového problému pomocí konferenčního hovoru mezi zákazníkem, PSAP
a HCC/SP
Příklad: 00800 – 123 45 678
Kód Země(PSAP use)
Popis: Může být interní identifikace Země s 3 parametry podle (GTP), Kódovací specifikace,
21 březen
Užití: Tento kód je použit k identifikaci Země původu zákazníka
Příklad: D = Německo, SW = Švédsko, SLO = Slovensko atd.
4.1.3. Priorita
Je závislá na nosiči (SMS, GPRS atd.), který je užit k odeslání daného počtu dat, a který se
může lišit. Je nutno upřednostnit některé informační elementy, aby byla odeslána důležitá
data. Jestliže je dosaženo naplnění limitu objemu dat, zbývající data nebudou brána v úvahu.
Priorita dat podle E-MERGE konsorcia je následující:
•
•
•
•
•
•
GPS poloha
Směr pohybu
Počet aktivačních prvků
Barva, Výrobce, Typ vozidla
Které senzory jsou aktivovány: airbag, převrácení, čelní náraz, boční náraz nebo zadní
náraz
Časová známka události
35
4.1.4. Standard minimálních dat
Specifikovaná data jsou minimální data, která jsou posílána z vozidla a musí vyhovovat
požadovaným E-MERGE standardům.
4.1.5. Struktura zprávy
Zpráva o požadavku nouzového hovoru
Popis: Terminál požadující pohotovostní jednotky vyšle tuto zprávu (GTP), Kódovací
specifikace, 21 březen 2003,Verze 1.0 (7.3.1.)
Zpráva o požadavku odpovědi na nouzový hovoru
Popis: Zpráva je zodpovězena PSAP, který ji pošle terminálu. (Kódovací specifikace, 21
březen 2003,Verze 1.0 (7.3.2.)
4.1.6. Závěr
Tato kapitola poskytla detailní popis minimálních dat očekávaných PSAP. Mělo by být
zdůrazněno, že aby bylo dosaženo úplné shody s E-MERGE, všechna data by měla být
aktuální a dosažitelná pro PSAP. Jako výsledek má PSAP detailní přehled a informace o
nehodě a případných obětech. Pohotovostní jednotky potom mohou reagovat na nehodu
v jednoznačně kratším čase a s vyšším stupněm úspěšnosti.
Následující kapitola rozšiřuje minimální data o přidané informace , které mohou být
odeslány vozidlem k poskytovateli služeb (někdy nazývaným HCC - Home Call Center), se
kterým má řidič podepsanou smlouvu.
4.2. Specifikace úplných dat
4.2.1. Úvod
Minimální data směřující k PSAP mají pomoci dostatečně identifikovat nouzovou situaci.
V případě, že minimální data nejsou dostačující, nebo PSAP potřebuje detailnější popis
nehody a informace o potenciálních raněných, je třeba využít druhého balíčku tzv. „úplných
dat“, který je odeslán z vozidla k poskytovateli služeb (SP, HCC), který tyto data poskytne
PSAP.
4.2.2. Informační elementy
Následující informační elementy jsou velmi důležité v případě nouzové situace. Tyto
informační elementy jsou specifikovány podle Telematického Fóra, Globálního
Telematického Protokolu (GTP), Kódovací specifikace, 21. březen 2003, Verze 1.0, a
(GTP), Transportního Protokolu s kódovací specifikací, 12. listopad 2002, verze 0.1,
Reference jsou v datové tabulce (GTP), Kódovací specifikace, 21. březen 2003, Verze 1.0,
Hlavička
Popis: Podle (GTP), Kódovací specifikace, 21. březen 2003, Verze 1.0 (6)
36
Užití: Definuje aktuální podskupinu případu užití
Příklad: Verze 1.0 (6.1 – 6.8)
a) Zvláštní oprávnění
Popis: Podle (GTP), Kódovací specifikace, 21. březen 2003, Verze 1.0 (6.5)
Užití: Úrovně oprávnění
Příklad: Verze 1.0 (6.5) tabulka 8 úrovně oprávnění bit číslo 1 nejvyšší oprávnění.
Verze elementu
Popis: Podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 (22.3)
Užití: Definuje výrobce vozidla, ID terminálu, Software a Hardware
Příklad: Verze 1.0 (22.3 a 22.3.3)
Časová známka
Popis: Podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 (22.26)
Užití: Definuje čas, kdy byla generována zpráva o nehodě
Příklad: 2002-11-27 19:45.21 Verze 1.0 (22.26.1 až 22.26.6)
Lokalizace
Popis: Podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 (22.10, 22.11, 22.12
a 22.19)
Užití: Definuje polohu vozidla podle WGS84.
Příklad: N52 45.0010 E005 10.2250 (Dříve 1.2.1 GPS poloha)
Směr
Popis: Směr jízdy určený z posledních tří GPS údajů o poze s 30 metrovým intervalem
(GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 (22.17 and 22.18)
Užití: Definuje v jakém směru se pohybovalo havarované vozidlo
Příklad: Verze 1.0 (22.17 a 22.18 hodnota ½)
Popis vozidla
Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen
2003,Verze 1.0 (22.20)
Užití: Definuje barvu, Model, VIN, Číslo terminálu a licencenční štítek vozidla, aby
záchranná jednotka mohla snadno identifikovat vozidlo
Příklad: Verze 1.0 (22.20.1 až 22.20.8)
a) Rok výroby (užívá PSAP)
2003,Verze 1.0 (22.20.2)
Užití: Definuje rok výroby typu vozidla, jsou pro to určeny 2 digity.
Přiklad: verze 1.0 (22.20.2)
b) VIN
Popis: Číslo mezinárodní identifikace vozidla podle (GTP), Kódovací specifikace, 21.
březen 2003,Verze 1.0 (22.20.3)
Užití: Definuje všechna data od výrobce
Příklad: verze 1.0 (22.20.3)
c) Sériové číslo terminálu
37
Popis: Parametry identifikace terminálu podle(GTP), Kódovací specifikace, 21. březen
2003,Verze 1.0 (22.20.4)
Užití: Definuje sériové číslo terminálu pro IVS
d) Licenční štítek
Popis: Parametry čísla licenčního štítku podle (GTP), Kódovací specifikace, 21. březen
2003,Verze 1.0 (22.20.5)
Užití: Definuje licenční štítek havarovaného vozidla
e) Barva vozidla
2003,Verze 1.0 (22.20.6)
Užití: Definuje barvu vozidla
f) Typ vozidla
2003,Verze 1.0 (22.20.7)
Užití: Definuje výrobce a typ vozidla
g) IMEI
Popis: Identifikační parametry a číslo GSM zařízení podle (GTP), Kódovací specifikace, 21.
březen 2003,Verze 1.0 (22.20.8)
Užití: Definuje GSM zařízení dostupné pro IVS.
E-call stav
Popis: Zdroj nouzového hovoru a počet aktivačních prvků včetně manuálních a
senzorů(airbag, převrácení, nárazové senzory) podle (GTP), Kódovací specifikace, 21.
březen 2003,Verze 1. (22.21)
Užití: informace pro nouzového operátora umožňující mu vyslat pohotovostní jenotky
Příklad: vypsané z GTP (dříve 1.2.4 aktivátory a 1.2.6 senzory)
a) Příčina havárie (E-call data)
2003,Verze 1.0 (22.22.)
Užití: Tabulka 67: Příčina havárie
Bit 1 Aktivováno manuálně
Bit 2 Převrácení vozidla
Bit 3 Aktivace airbagu
Bit 4 Aktivace nárazových senzorů
Tabulka 68: Příčina havárie rozšířený oktet
Bit 3 Vozidlo se pohybovalo
příklad: Verze 1.0 (22.22.)
b) Rozpoznání havárie (E-call data)
38
2003,Verze 1.0 (22.23.)
Užití: Tabulka 69-Senzory havárie
Bit 2-Aktivován čelní senzor
Bit 3-Aktivován zadní senzor
Bit 4-Aktivován boční senzor
Bit 5-Aktivován alarm vozidla
Bit 6-Typ paliva je plyn
Tabulka 70- Senzory havárie rozšířený oktet
Bit 1- Skrytý manuální alrm
Bit 2- Dálkově spuštěný alarm
Bit 3- Manuální alarm
Bit 5- Vzdálenost
Bit 6- Geografický region
Bit 7 Manuální E-call alarm
Example: Version 1.0 (22.23.)
c) Data o srážce (E-call data)
Popis: Přídavná popisná data podle (GTP), Kódovací specifikace, 21. březen 2003,Verze
1.0 (22.24.)
Užití: Tabulka 72-hodnota dat o srážce
Hodnota 3-Data o srážce
Tabulka 74-Typ dat o srážce
Hodnota 1-Data o intenzitě srážky
Příklad: Verze 1.0 (22.24.1.)
d) Data o intenzitě srážky (E-call data)
Popis: Přídavná popisná data podle (GTP), Kódovací specifikace, 21. březen 2003,Verze
1.0 (22.24.1.1)
Užití: Tabulka 75- Data o intenzitě srážky
Oktet \ bit
1
2
3
4
Příklad: Verze 1.0 (22.24.1.1.)
4.2.3. Priorita
Data by měla následovat(GTP), Transportní Protokol s kódovací specifikací,
12.listopad 2002, verze 0.1,. Je závislá na nosiči (SMS, GPRS atd.), který je užit k odeslání
daného počtu dat a který se může lišit. Je nutno upřednostnit některé informační elementy aby
byla odeslána důležitá data. Jestliže je dosaženo naplnění limitu objemu dat, zbývající
nebudou brána v úvahu. Priorita dat podle E-MERGE konsorcia je následující:
1)
2)
3)
4)
GPS poloha
Směr pohybu
Počet aktivačních prvků
Barva, Výrobce, Typ vozidla
39
5) Které senzory jsou aktivovány: airbag, převrácení, čelní náraz, boční náraz nebo zadní
náraz
6) VIN
7) sériové číslo terminálu
8) Licenční štítek
9) IMEI
10) Příčina havárie ( E-call )
11) Rozpoznání havárie ( E-call )
12) Data o srážce (E-call)
13) Data intenzity srážky
14) Čas události
4.2.4. Standard úplných dat
Specifikovaná data jsou úplná data, která jsou poslána z vozidla, aby bylo vyhověno EMERGE standardu.
Zpráva o požadavku nouzového hovoru
Popis: Terminál požadující pohotovostní jednotky vyšle tuto zprávu (GTP), Kódovací
spesifikace, 21 březen 2003,Verze 1.0 (7.3.1.)
Zpráva o požadavku odpovědi na nouzový hovoru
Popis: Zpráva je zodpovězena PSAP, který ji pošle terminálu. (Kódovací specifikace, 21
březen 2003,Verze 1.0 (7.3.2.)
4.3. Specifikace komunikace
4.3.1. Úvod
Tento dokument popisuje komunikační protokol který bude implementován v E-MERGE.
Kapitola začíná anlýzou současných dostupných protokolů a identifikuje dostupné
nejzajímavější protokoly. Uvažované protokoly jsou orientované na nouzové hovory a
umožňují terminálu odesílat co nejrychleji a nejefektivněji minimální E-MERGE data do
PSAP.
4.3.2. Úroveň technologie
V současné době se několik standardizačních organizací snaží definovat protokol vhodný
pro přenos nouzově orientovaných dat. Hodně těchto standardů má lokální možnosti, velmi
často specifické dané Zemi a jako důsledek nejsou použitelná v mezinárodním
kontextu.Některé z těchto standardizačních snah mohou být kandidáti na širokou evropskou
implementaci.Následující paragraf identifikuje některé z těchto protokolů a ukazuje hranice
jejich použitelnosti.
GTP Protokol
40
Telematické Fórum ERTICO započalo snahu o vytvoření nového protokolu z ACP
(Aplikační komunikační protokol) a GATS (Global Automotive Telematics Standard)
nazvaného GTP (Global Telematics Protocol). ACP a GATS jsou dva vedoucí protkoly
doručování telematických informací do vozidla. Dnes většina OEM produktů závisí na
jednom z těchto protokolů a jejich telematickém řešení.
a) Úkoly
Hlavním úkolem GTP skupiny bylo pokusit se dosáhnout rozvojem a implementací GTP
těchto výhod:
•
•
•
•
•
•
•
•
•
jeden globální OTAP (Over The Air Protocol), který redukuje cenu zjednodušeným
OEM návrhem a rozšiřuje soutěž pro komponenty, systém a služby.
vyhnutí se výdajům za zdroje v oblastech s malou způsobilostí
umožnění zaměření na zákazníka na aplikační úrovni a úrovni služeb
schopnost využití již dnes existujících systémů AMPS, GSM, SMS, GPRS, UMTS,
DSRC a WLAN bez nutnosti úpravy aplikací
možnost návrhu aplikací na odzkoušeném sytému komponent s roky fungování
v komerčním prostředí
využití odzkoušených a vhodných funkcí ACP a GATS standardů
měřitelné řešení poskytující ty funkce, které zákazník potřebuje a bude za ně platit,
bez nutnosti potřeby výměny systému v budoucnu
rozvinutí otevřeného standardu ochrání stávající a budoucí investice
telematické zaměření a také telematicky optimalizovaná implementace.
b) Architektura GTP protokolu
Pohled na GTP je ukázán na obr. 4.1. GTP je zde definován pro přenos informací mezi
centrální infrastrukturou PSAP a pro výměnu zpráv pomocí GTP mezi PSAP, SP a IVS.
Centrální infrastruktura
Výrobce
automobilů
Kontaktní centrum
- poskytovatel
služeb
Individual. (např.XML)
Služby
Mobilní síť
Vozidlová
jednotka
Vozidlo
Sběrnice vozidla
GTP
Obr. 4.1: Celková architektura GTP rozvinutí
GTP protokol je slučitelný s ISO/OSI sedmivrstvým referenčním modelem. GTP aplikační
vrstva protokolu je užita GTP aplikacemi pro výměnu informací s druhou GTP aplikací
v jiném systému. Jako příklad uveďme: nouzová aplikace (aplikace ID=1), která je
specifickým subjektem této analýzy je vyvolána vozidlem. Aplikace využije E-call zprávy
v GTP aplikačním protokolu, aby poskytla potřebné informace v nouzi a aby přenesla zprávu
GTP protokolem. GTP transportní protokol přidá svoji vlastní hlavičku, aby zaručil přenos
41
GTP aplikační zprávy k jiné GTP aplikaci. Shodná GTP transportní vrstva vyšle potvrzení o
přijetí GTP aplikační zprávy zpět k odesilateli zprávy. GTP aplikační zpráva se přenese GTP
protokolem až k další GTP aplikaci, kde je zpracována centrální infrastrukturou.
.
Obr 4.2: ISO/OSI referenční model a GTP
Obr 4.3: GTP výměna informací na aplikační vrstvě
Data při nouzové situaci
42
Následující paragraf poskytuje popis dat odeslaných v nouzové situaci (uvedených jako IE
identifikátory implementované v GTP protokolu).
•
•
•
•
•
•
•
•
•
•
Verze elementu obsahující informace o výrobci vozidla, výrobci vozidlové jednotky
(IVS), stávající verzi instalovaného hardwaru a implementovaného softwaru.
Časová známka je zakódována jako UTC a reprezentuje přesný čas, ve který došlo
k aktivaci vozidové jednotky (IVS).
Lokalizace se zapisuje do historie polohy vozidla a je seřazena od nejnovějších
informací až k těm nejstarším.
Identifikátory vozidla jsou VIN, sériové číslo terminálu které identifikuje bezdrátové
zákaznické zařízení, barva vozidla, typ vozidla, licenční štítek a IMEI bezdrátového
vybavení.
Je identifikováno, jestli se jedná o nouzovou situaci, včetně informací o zdroji
aktivace (manuální nebo senzory), senzory se aktivovaly automaticky a detekují
nouzový stav a vypíšou data o srážce.
Potvrzující element reprezentuje stav, kdy byla odeslána potvrzovací zpráva od PSAP
Přenosová jednotka specifikuje interval, ve kterém je vyslána zpráva o nouzové situaci
tak, aby mohlo být identifikováno a nalezeno vozidlo.
E-call kontrolní fáze definuje doplňkovou kontrolní funkci v E-call zprávě.
Identifikátor poruchové funkce IE může mít binární formu nebo textovou formu a
obsahovat ve zprávě chybějící nebo špatné informace.
Každý element telefonního čísla je variabilní v délce a počtu digitů telefonního čísla
definovaného délkou. Jestliže se objeví elementy několikanásobného telefonního čísla
pro danou aplikaci, je jen na aplikaci, jestli rozhodne, kdy a jak je užít buď sériově
nebo souběžně. Normy nebo předpisy dané země mohou předepisovat úroveň
souběžnosti. Obvykle pořadí, ve kterém se čísla objeví, definuje pořadí volání
jednotlivých volaných čísel. Vyhražený oktet reprezentuje kód země. Přítomnost
tohoto oktetu je závislá na kontrolní fázi.
Mobilní lokalizační protokol
Mobilní lokalizační protokol (MLP) je protokol na aplikační vrstvě, který stanovuje
polohu mobilní stanice nezávisle na síťové technologii. MLP servery jsou jako rozhranní mezi
Lokalizačním serverem a lokalizačními aplikacemi.
Obr. 4.4: Mobilní lokalizační protokol
43
Možné realizace lokalizačního serveru jsou GMLC, což je lokační server užívaný v GSM
a UMTS sítích, a MPC, který je definován v ANSI standardu. V nejvíce případech LSC klient
iniciuje dialog odesláním dotazu na lokalizační server a server na tento dotaz odpovídá.
V MLP je transportní protokol oddělen od XML obsahu (jak je ukázáno v následující
tabulce).
Obr. 4.5 Vrstvová struktura
Na nejnižší úrovni je transportní vrstva definující, jak je XML obsah přenášen. Možné
MLP transportní protokoly jsou HTTP, WSP, SOAP a ostatní.
Vrstva kde jsou elementy popisuje všechny obvyklé elementy užité na vrstvě poskytující
služby, která ve stejném okamžiku definuje aktuální služby nabízené MLP. Základní služby
MLP jsou založeny na lokalizaci definované 3GPP. Pokročilé MLP služby jsou přídavné. Pro
E-MERGE projekt jsou nejvíce zajímavé tyto služby :
Okamžitá služba nouzové lokalizace je služba užívaná speciálně pro výpočet polohy
mobilního účastníka, který inicioval nouzový hovor. Reakce této služby je požadována
okamžitě. Tato služba se skládá z následujících zpráv:
•
•
Okamžitý požadavek na lokalizaci nouzově volajícího
Okamžitá odpověď na lokalizaci nouzově volajícího
Služba informace o nouzové lokalizaci je služba, která se užívá jestliže bezdrátová síť
automaticky iniciuje určení polohy v rámci nouzového hovoru. Poloha a související data jsou
poté poslána z lokalizačního serveru na nouzovou aplikaci. Určení aplikace a její adresy je
definováno v lokalizačním serveru. Tato služba se skládá z následujících zpráv:
•
Zpráva o nouzové lokalizaci
44
DTMF – signální tóny po hlasovém kanálu
DTMF signální tóny jsou již užívány řadu let. Přenos z mobilní sítě do pevné sítě je
prostřednictvím MSC (Mobile Location information Centre – centrum informací o lokalizaci
v mobilní síti GSM operátora). DTMF signální tóny nemohou být užity pro přenos větších
objemů dat v důsledku realizačního času (přibližně 400-500 milisekund). DTMF mohou být
použity jako reference pro PSAP. Jestliže je použito DTMF, PSAP dostane upozornění před
přenosem, že data budou poslána v hlasové podobě pomocí DTMF signálních tónů.
Přenos dat zvukem před použitím hlasového kanálu
Je to relativně jednoduchá varianta založená na použití frekvence rozhranní 12
kbit/s. Automatické zapnutí vozidlového mobilním zařízení může být realizováno podobně
jako u faxu. V MSC se objeví překlad 12 kbit/s vzdušného rozhranní přes transkodér na 64
kbit/sek.
Signál Uživatel-Uživatel
Využití signálů Uživatel-Uživatel je definováno jako standard v SCCP protokolu ITUTQ711715. Přístup k širokému užití signálů Uživatel-Uživatel založeném na dostupných a
opravdu použitelných objemech datech v USD stringu. USD string má 272 bytů jako
standard, ale kvůli regulaci telekomunikačních operátorů je použitelných jen 256 bytů. Jako
informace bude síťovým operátorem použito mezi 50 – 100 byty, což dává dohromady asi
150 použitelných bytů. Se 150 byty můžou být přenesena E-MERGE minimální data. Na
straně GSM operátora bude tato funkce podporována BSSAP. Přenos do pevné sítě je pomocí
MSC. Na straně pevné sítě je tato funkce a dostupnost definována a implemntována ve
standardu ISUP 761-766.
Rozšířené využití signálů Uživatel-Uživatel
Zajímavé rozšířené možnosti této funkce na úrovní protokolu a jako standard ITUT – Q
737, je možnost přenosu dat v průběhu spojení s definovanou velikostí 128 kilobytů. ITUT –
Q 737 “doplňkové služby“ můžeme rozdělit do 3 kategotií. Funkce musí být podporována na
straně GSM operátora a dnes není možné vydat stanovisko pro všechny GSM operátory
týkající se implementace tohoto standardu
45
5. Požadavky na E-MERGE systém
5.1. Požadavky na vozidlovou jednotku
5.1.1. Úvod
Tato část dokumentu popisuje požadavky na návrh a vývoj vozidlové jednotky.
5.1.2. Rozhraní člověk-stroj (HMI)
V Evropě existují odlišné předpisy. 21 prosince 1999 Komise evropských komunit vydala
předpis, který osahuje specifické ISO standardy na požadavky na stavbu a návrh vozidlové
jednotky pro systém tísňového volání (e-call).
E-call systém HMI
Aby bylo umožněno řidiči/pasažérovi manuálně aktivovat nouzový hovor, jsou třeba
tlačítka a to nejméně dvě(jedno pro aktivaci nouzového hovoru a druhé pro havarijní
asistenční služby). Aby sytém plnil svou funkci E-call HMI musí být co nejlépe ovladatelné
pro uživatele. Snadná interakce jednotky, návrh tlačítka, jeho poloha a funkce, musí být velmi
pečlivě promyšleny kvůli vlivu na užívání systému. Požadavky na použitelnost E-call systému
mohou být shrnuty do několika charakteristik:
•
•
•
•
Snadná použitelnost
Zpětná vazba na uživatele
Prevence falešné aktivace
Prevence rozptylování řidiče
Snadná použitelnost
E-call tlačítko musí být umístěno na takovém místě, které bude snadno dosažitelné pro
řidiče i spolujezdce aniž by opustili sedadlo. Tlačítko by mělo mít podobný návrh (nemusí být
naprosto identické) ve všech značkách vozidel, aby se dalo snadno najít a použít.
Důležité jsou tyto aspekty:
• Poloha
• Velikost
• Barva
• Hmatatelnost
• Tvar
• Noční iluminace
Poloha
Tlačíto by mělo být umístěno tak, aby bylo zamezeno náhodnému stlačení. Umístěno
může být v oblasti zpětného zrcátka nebo na přístrojové desce, kde by bylo snadno
dosažitelné pro řidiče i spolujezdce. Je třeba, aby tlačítko E-call bylo odlišné od varovných
světel a aby nedocházelo k záměně.
46
Barva
Téměř všichni výrobci vozidel považují za nejvhodnější červenou barvu, protože je
považována za barvu indikace nebezpečí a je lehké ji rozpoznat. Ale mohlo by být obtížné pro
uživatele odlišit jednotlivá tlačítka stejné barvy, čehož může být dosaženo odlišným tvarem.
Velikost, hmatatelnost a tvar
Tyto vlastnosti velmi závisí na návrhu a ovlivňují bezproblémové vyhledání E-call
tlačítka.
Zpětná vazba systému
Systém by měl mít zpětnou vazbu na uživatele a multifunkční zpětná vazba by měla
uživateli zaručit, že systém je funkční. Audio zpětná vazba může být zaručena např. tónem
nebo hlasovou komunikací z alarm centra.
Visuální zpětná vazba
Ta bude uživateli poskytnuta za pomoci displeje nebo blikajícího světla. Tento druh
zpětné vazby není vždy možný zvláště v případech nehod, kdy vozidlo je velmi vážně
poškozeno. Jestliže jsou zpětné informace zobrazovány pomocí displeje, pasažéři musí být
schopni rychle a snadno porozumět informaci.
Prevence rozptylování řidiče
Aby bylo minimalizováno rozptylování řidiče, jsou zapotřebí tato opatření:
• E-call systém by měl umožňovat po aktivaci hands-free obsluhu
• Řidič by měl snadno najít E-call tlačítko aniž by zpustil oči z vozovky na více než
2 sekundy.
• E-call tlačítko by mělo poskytovat vizuální nebo audioinformaci o potvrzení, že
byla poslána daná zpráva aniž by byla rušena koncentrace ridiče/ky na řízení
vozidla.
• Upozornění o aktivaci by měla být navržena tak, aby nerozptylovala řidiče.
Volá očitý nebo náhodný svědek
Hovor, kdy volá očitý nebo náhodný svědek je uskutečněn osobou která se stala svědkem
nehody, ale není jejím učastníkem. Tento druh hovoru způsobuje problém spojený
s přetížením a diversitou informací na straně PSAP.
5.1.3. Hovory, kde není třeba pohotovostních služeb
Předcházení a omezení falešných nebo nechtěných nouzových hovorů je podstatné
z důvodu zbytečného vyslání pohotovostních služeb, které mohou být potřebné na jiném
místě. Proto je zapotřebí tento problém řešit. Falešné hovory mohou být zapříčiněny buďto
špatným zacházením na straně uživatele (např. v důsledku špatného rozhranní HMI), nebo
chybou systému (např. chybou kritických senzorů).
Omezení falešných nebo nechtěných nouzových hovorů
47
Minimalizace aktivace falešných nebo nechtěných nouzových hovorů je podstatná, má li
systém být věrohodný a umožňovat efektivní využití záchranných a bezpečnostních složek.
Protože pohotovostní služby reagují na falešný nebo nechtěný nouzový hovor, nemohou pak
být na jiném potřebném místě, a to může mít za následek i životy lidí.
Aby byla omezena aktivace falešných nebo nechtěných nouzových hovorů:
•
•
•
•
•
•
E-call tlačítko musí být umístěno tak, aby nedošlo k nechtěné aktivaci
E-call tlačítko musí upozornit řidiče vizuálně nebo zvukem, že byla spuštěna aktivace
E-call tlačítko musí být stlačeno po dobu nejméně 2 sekund, aby byla potvrzena
aktivace
Ostatní tlačítka by měla být umístěna tak, aby byla dostatečně daleko od E-call lačítka,
čímž se předejde chybné aktivaci
E-call systém musí být schopný zrušit nouzovou sekvenci do 6 sekund po aktivaci
E-call systém musí upozornit řidiče, že byl automaticky aktivován senzory
Omezit nebo minimalizovat výskyt falešné aktivace chybou senzorů jde:
•
•
Hovor E112 může být generován jen automaticky, jestliže dva nebo více senzorů jsou
aktivovány.
E-call systém musí upozornit řidiče pokud selže jeden senzor
5.1.4. Spouštění automatického E-call
Vozidlová jednotka (IVS) musí být schopná poskytovat PSAP/SP potřebné informace, aby
určila stav vozidla. Tato informace může být obdržna z různých vozidlových senzorů
monitorujících stav vozidla.
Odpovídající senzory pro spouštění automatického E-call
Je doporučeno, že následující senzory by měly být schopné spouštění automatického E-call:
• Airbag
• Nárazový senzor zadní
• Nárazový senzor přední
• Nárazový senzor boční
• Senzor převrácení
• Teplotní senzor (kvůli ohni)
Aktivace pomocí jednoho senzoru
Jestliže je aktivován jeden senzor jsou poslána minimální data PSAP, který může využít
hlasový hovor, aby ověřil, jestli situace vyžaduje reakci nebo asistenci pohotovostních
jednotek. Například srážka v malé rychlosti může aktivovat vystřelení airbagu. Řidič a nikdo
jiný není zraněn a nestala se žádná jiná škoda. Proto není třeba asistence záchranných
jednotek, ačkoliv řidič může potřebovat služby s přidanou hodnotou.
48
5.1.5. Ukládání parametrů
Aby bylo možné rekonstruovat nehodu, měly by být následující parametry uloženy ve
vozidlové jednotce (IVS):
•
•
•
•
•
•
Stlačení tlačítka nebo aktivace senzorů, které spustilo E-call
GPS poloha
Časová známka
Parametry samokontroly
Stav nabití baterie
Minimální data mohou být také uložena, je-li to možné tak v nevymazatelné paměti
5.1.6. Redundance
Vozidlová jednotka (IVS) by měla mít redundantní externí komponenty, protože v případě
srážky externí části a jejich propojení (optické a elektrické) budou pravděpodobně poničené.
Anténa
Vozidlová jednotka (IVS) vybavená externí anténou by měla také mít interní anténu, která
může být použita, je-li externí anténa mimo provoz. IVS by měla sama rozpoznat, je-li nutné
přepnutí na interní anténu nebo ne. Přepínací čas musí být velmi krátký a vestavěná vysílací
anténa musí být duální, popřípadě tribandová (900, 1800, 1900 MHz).
Baterie
Jestliže hlavní baterie ve vozidle je nepoužitelná a je třeba generovat nouzovou sekvenci,
IVS musí mít záložní baterii. Doba hovoru je proto omezena a liší se podle spotřeby IVS
jednotky a aktuální teploty. Mělo by být umožněno hovořit nejméně 10 minut za normálních
okolností.
Odolnost proti poškození
IVS jednotka by měla být umístěna na takovém místě ve vozidle, které je maximálně
odolné proti poškození.
Mikrofon a reproduktor
IVS jednotka by měla být vybavena interním mikrofonem a reproduktorem jako záloha
externího. V případě potřeby by na ně mělo být automaticky přepnuto.
Zabudovaná SIM karta
Jestliže SIM karta je externí, měla by být v IVS také záložní interní SIM karta.
Samokontrola
Aby bylo zabráněno permanentním chybám systému samotného, chybám senzorů a
externích komponentů, měla by mít IVS schopnost samokontroly. Měla by pak posílat zprávu
o chybách provozovateli služby/ domácímu centru (HCC) nebo indikovat řidiči, že systém je
porouchaný.
49
Požadavky standardů pro vozidla
Požadavky standardů pro vozidla jsou rozsáhlejší než požadavky zákazníků. Aby zařízení
splňovala tyto požadavky musí splňovat:
•
•
•
•
•
•
•
•
operační teplota mezi– 40° a + 85° C.
malý odběr eletrické energie (12V).
předpisy o EMC
Fukčnost ve velkých rychlostech
Softwarově stabilní (žádný vstup nezpůsobí přerušení hovoru)
Integrace s palubními elektronickými systémy
Odolnost proti ohni na 15 min (otevřený oheň)
Vysoká spolehlivost (např. testováno ve všech automobilech)
IVS by měla splňovat všechny tyto požadavky, aby byla garantována minimální
funkčnost před a po nehodě.
5.1.7. Komunikační vlastnosti
Komunikační proud
Veškerá kritéria jsou níže shrnuta, aby byly vyhodnoceny jednotlivé bezdrátové sítě pro
nouzové hovory.
a) Pokrytí Evropy
Geografické pokrytí bezdrátových sítí by mělo obsáhnout co nejvíce evropských zemí.
b) Priorita
Priorita znamená schopnost upřednostňovat data, tak aby nouzová data mohla být poslána
přednostně před jinými typy dat v bezdrátové síti. Mobilní služby v GSM síti jsou obyčejně
upřednostňovány takto(od nejvyšší k nejnižší prioritě):
1. Nouzový hovor
2. Obyčejný hovor
3. GSM data
4. GPRS data
5. SMS.
c) Spolehlivost
Komunikace mezi terminály by měla být spolehlivá. Spolehlivost znamená pravděpodobnost
úspěšného přenosu dat (např. zabránění ztrátě dat).
d) Potvrzení
Potvrzení znamená schopnost terminálu obdržet potvrzení, že příjemce zprávy obdržel
všechna data. V tomto případě je příjemce zprávy telekomunikační operátor.
e) Časování
Časování znamená rozdíl mezi časovou známkou “odesláno” terminálem a časovou známkou
“přijato” telekomunikačním operátorem.
50
f) Připomínky
Připomínky jsou extra poznámky, které mají vliv na výběr vhodných nosičů pro služby
bezdrátové sítě.
g) Přehled
evropské
pokrytí
priorita
spolehlivost
potvrzení
časování
připomínky
GSM-SMS velmi dobré
ne
velmi vysoká
ano
< 5s
vhodné pro malé objemy dat
GSM-Data velmi dobré
ano/ne
vysoká
ano
5 - 30s
velice závislé na síti
GPRS
dobré
ano/ne
střední
ano
5 - 10s
vhodné pro malé objemy dat
UMTS
vemi špatné
ano/ne
velmi vysoká
ano
?
určování polohy je zahrnuto ve
standardu
Přenos dat po GSM-SMS
V této sekci je hodnoceno GSM – SMS podle předešlých komunikačních kriterií.
a) Pokrytí Evropy
Pokrytí Evropy je skoro 100 % v západoevropských zemích.
b) Priorita
Není možné upřednostňovat jednotlivé SMS.
c) Spolehlivost
GSM-SMS má velmi vysokou spolehlivost a to díky malému riziku přetížení, malému
množství bitových chyb a krátké pracovní době.
d) Potvrzení
Jestliže síť úspěšně přijmula SMS, je vždy posláno terminálu potvrzení. Volitelně může také
terminál obdržet potvrzení,že SMS byla doručena adresátovi (musí to být vyžádáno
terminálem, když je SMS poslána).
e) Časování
Přenos terminál-síť trvá obvykle méně než 5 sekund.
f) Připomínky
SMS je dnes široce užívaný a preferovaný nosič pro některé služby.
SMS je vhodný pro malé objemy dat (do několika stovek bytů)
Tato služba je vysoce standardizovaná s několika volitelnými vlastnostmi, díky kterým je její
funkce v různých sítích dobře popsetelná.
Přenos dat po GSM datovém kanálu
V této sekci je hodnocen GSM datový kanál podle navrhnutých komunikačních kriterií.
a) Pokrytí Evropy
Pokrytí Evropy GSM datovými kanály je skoro 100 % v západoevropských zemích.
51
b) Priorita
GSM datový hovor může být upřednostněn užitím rozšířené Multi-úrovňové nadřazenosti a
přednostní služby (eMLPP). Avšak, podpora eMLPP služby je jen vlastností sítě.
c) Spolehlivost
Úroveň spolehlivosti je závislá na tom, jaký druh datového hovoru terminál požaduje (hovor
s nízkou nebo velkou spolehlivostí). Hovory s vysokou spolehlivostí ale nemusí být
podporovány síťí.
d) Potvrzení
Síť pošle potvrzení, jestliže je požadován hovor s vysokou spolehlivostí. Pro hovory s nízkou
spolehlivostí nejsou žádná potvrzení.
e) Časování
Bohužel v tomto případě nastává vždy zpoždění díky fázi vytvoření spojení. Zpoždění je
závislé na typu datového hovoru. Pro malé objemy dat (několik stovek bytů) je fáze vytvoření
hovoru delší než fáze přenosu dat. Mimoto je jakási souvislost mezi spolehlivostí a
zpožděním. V případě špatného signálu mezi terminálem a sítí, hovor s nízkou spolehlivostí
nepředstavuje velké zpoždění, kdežto hovor s vysokou spolehlivostí může mít až skutečně
závažné zpoždění.
f) Připomínky
GSM data jsou vhodná pro větší objemy dat (až několik kilobytů)
Celkově vzato však funkčnost GSM data přenosu může velice záviset na síťovém operátorovi.
Datový hovor A s určitými požadavky může fungovat naprosto bez problémů v síti A, ale
vůbez nemusí fungovat v síti B.
Přenos dat přes GPRS
a) Pokrytí Evropy
Velký počet evropských telekomunikačních operátorů poskytuje služby GPRS. Jestliže daná
síť poskytuje GPRS, neliší se geografické pokrytí od pokrytí danou sítí GSM. Nicméně
možnosti roamingu jsou stále limitovány.
b) Priorita
Mezi GPRS hovory je možné upřednostňování prostřednictvím tzv. čtyř úrovní priority, ale
přesné užití těchto úrovní závisí na síti.
c) Spolehlivost
Úroveň spolehlivosti je závislá na tom, jaký druh GPRS datového hovoru terminál požaduje.
Existuje několik úrovní spolehlivosti, ale síťový operátor je nemusí všechny podporovat.
d) Potvrzení
Jestli bude posláno potvrzení od sítě terminálu závisí na požadované úrovni spolehlivosti.
e) Časování
Doba přenosu určitého objemu informací mezi terminálem a sítí závisí na mnoha faktorech.
Některé z nejdůležitějších jsou např. operátor upřednostňuje hlasové hovory před GPRS
hovory, počet aktivních GPRS hovorů, atd.
52
f) Připomínky
GPRS je vhodné pro přenos jak malého tak většího množství dat dokud nejsou uplatněny
přísné požadavky ohledně zpoždění.
Úspěšnost v pokusu navázat spojení GPRS se může podstatně lišit a to kvůli tomu, že GPRS
je jakási služba na pozadí využívající volné kapacity sítě v daném momentě. Spousta sítí také
využívá odpojení GPRS hovoru ve prospěch hlasového hovoru nebo GSM datového hovoru.
Přenos dat po UMTS
a) Pokrytí Evropy
V současnosti je jen pár operátorů testujících tuto síť. Zatím je velmi málo UMTS služeb
fungujících v Evropě.
b) Priorita
Národní doporučení týkající se UMTS jsou v současné době ještě formulována. Ale jsou zde
poměrně široké možnosti co se týče upřednostňování nouzových hovorů.
c) Spolehlivost
Podle standardizačních dokumentů bude UMTS schopna garantovat vysokou kvalitu služeb
v čemž jsou i zahrnuty požadavky na upřednostnění, spolehlivost, potvrzení a časování.
d) Potvrzení
Viz. Spolehlivost
e) Časování
Viz. Spolehlivost
f) Připomínky
Všechny datové služby jmenované v tomto dokumentu budou podporovány UMTS, ale s lepší
kontrolou nad spolehlivostí a časováním. Mimoto služby určování polohy jsou integrovány
v protokolech UMTS. Standardizační dokumenty také specifikují vylepšené datové služby,
které mohou být lepší/bezpečnější možností již diskutovaných řešení.
5.2. Požadavky na PSAP
5.2.1. Úvod
Tato kapitola popisuje požadavky na PSAP v E-call řetězci. PSAP by měl splňovat
všechny předpoklady uvedené v této kapitole, aby byl schopen zajišťovat důležité spojení
mezi posádkou vozidla a pohotovostními jednotkami. PSAP je také odpovědné za předání
veškerých informací velmi důležitých pro pohotovostní služby např. počet raněných,
charakter zranění, polohu vozidla a data o stavu vozidla přijatá ze senzorů atd.
5.2.2. Definice PSAP
Public Safety Answering Point (PSAP) je fyzické místo, kde jsou přijímány obyčejné a
E-MERGE nouzové hovory. Může to být statní zařízení, státní/soukromá společnost nebo
telekomunikační operátor, který má udělenou licenci od státní správy. PSAP centrum je
53
odpovědné za vyřizování hovorů linky 112 po pevné i mobilní síti a také za včasné a přesné
informování pohotovostních jednotek.
Kritický senzor je vrámci E-MERGE definován jako vnitřní senzor vozidla navržený tak,
aby monitoroval vozidlo a jeho stav před, při a po havárii. Základním předpokladem pro
automatické spuštění E-MERGE nouzového systému je aktivace nejméně dvou z
definovaných kritických senzorů.
5.2.3. Datové přenosy E-MERGE
Data od vozidlové jednotky (IVS) k Centru tísňového volání (PSAP)
Datový balík poslaný z IVS do PSAP obsahuje minimální data:
•
•
•
•
•
•
•
•
Hlavička
Stupeň důležitosti
Verze
Časová známka
E-MERGE ID
Poloha vozidla
Směr jízdy
Popis vozidla
Data od poskytovatele služeb (SP) k Centru tísňového volání (PSAP)
Datový balík poslaný od SP k PSAP obsahuje přidaná data:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Hlavička
Stupeň důležitosti
Verze
Časová známka
E-MERGE ID
Poloha vozidla
Směr jízdy
Popis vozidla
Rok výroby vozidla
Identifikační číslo vozidla
Sériové číslo IVS terminálu
Číslo licenčního štítku
Barva vozidla
Typ vozidla
IMEI číslo GSM jednotky
E-call stav: příčina aktivace a počet aktivovaných senzorů
Parametry havárie
Data o havárii
Identifikace SP
Telefonní číslo na SP
Kód země
54
•
Ostatní data
Formát a délka datových polí
Následující pravidla mohou pomoci při obsluze přenosu dat mezi E-MERGE účastníky:
• Datové prvky nebo pole jsou vždy znázorněny jako ASCII sekvence znaků, což je
výhodné pro správné řazení dat, ale také pro numerická data.
• Datumy jsou vždy v 8 bitové podobě a následujícím formátu:
RRRRMMDD Příklad: 20030306.
• Časová známka je ve formátu 14 bitové sekvence znaků:
RRRRMMDDHHMMSS Example 200303061417
5.2.4. Technické požadavky na PSAP
Technické požadavky na PSAP lze shrnout následovně:
• Vysokorychlostní bezchybný přenos datových zpráv od PSAP k telekomunikačnímu
operátorovi tak, aby bylo možno přijímat minimální data a GSM informace o poloze,
případně stahovat přidaná data od SP.
• Schopnost pracovat s daty v angličtině, aby mohlo řešit nastalou situaci (angličtina je
uznána jako oficiální jazyk užívaný v nouzových situacích).
• Sytémposkytující velmi dobré pokrytí mobilní sítí pro spolehlivou hlasovou
komunikaci. Hlasová komunikace má za úkol ujistit volajícího a napomoci
okamžitému zásahu pohotovostních jednotek.
• PSAP musí být schopen přijímat a obsluhovat hovory E 112 (hlas, minimální data a
stahování dat)
• Bezporuchové linky mezi PSAP a databází SP pro poskytnutí rychlé, bezpečné a
spolehlivé komunikace.
• Být schopný volat na poskytovatele služeb (HCC) na bezplatné evropské telefonní
číslo kvůli službám s přidanou hodnotou nebo jazykové podpoře.
• Internetové připojení pro přenos dat s přidanou hodnotou.
Infrastruktura operátora
Následující požadavky na infrastrukturu operátora jsou povinné a doplňují tak normální
inrastrukturu o obsluhu hovorů 112. Do doplňující infrastruktury patří:
• Software pro přijímání a zobrazování E-MERGE minimálních dat.
• Mapy pro zobrazování přesné polohy, nejlépe software pro práci s digitálními
mapami.
• Software prohlížeče internetu pro přístup na inernetovou adresu. Jestliže je třeba
zabezpečit komunikaci po internetu tak je nutný i zabezpečovací software.
• Software pro posílání důležitých dat SP.
Personál
• Dostupnost 24 hodin denně 365 dní v roce
• 4 směnný provoz
• Schopnost komunikace v několika jazycích, minimálně v angličtině
• Průprava v oblasti psychologie a stresu
55
•
Ochota se dále vzdělávat
Telefonní infrastruktura
Následující požadavky na telefonní infrastrukturu jsou povinné a měly by doplňovat normální
PSAP telefonní ifrastrukturu kvůli obsluze hovorů 112:
Doplňková telefonní infrastruktura je:
• Telefonní systém by měl umožňovat stahování přidaných dat z databáze SP, jestliže
byl přijat hovor 112 a tato data.
• Zapisovat, včetně časové známky, veškeré činnosti, které souvisí s E-call / E-MERGE
událostí.
• Vytvořit konferenční hovor
• Směrování hlasu a dat na vyhrazená pracovní místa
• Možnost implementace vyhrazených pracovních míst do konferenčních hovorů.
• V případě smluvního souhlasu – nahrávání hovoru
• Přesměrování hovoru na E-MERGE pracovní místa
• Přímá volba na E-MERGE pracovní místa
• Řízení jednotlivých skupin
• Zobrazení volajícího čísla
• Kontrolní funkce jako:
o Odposlouchávat
o Zasahovat
o Schvalovat
• Ukládat informace a časové známky po dobu tří měsíců
• Předvedení a přidělení aktivního pracovního místa pro všechny hovory E-call
• Přednostní obsluha E-call událostí
• Zobrazení všech příchozích a odchozích čísel pro operátora
• Poskytnutí definovaného čísla operátora E-call, aby HCC mohlo komunikovat přímo
s daným operátorem.
• Funkci zobrazení volajícího
• Funkce zamezení přetížení
• Ukládat všechny hlasové činnosti do E-call databáze
• Interní a externí konferenční hovor
5.2.5. Požadavky PSAP na databáze
Databáze provozované HCC a telekomunikačními operátory by měli vyhovovat následujícím
požadavkům:
• Přístup do databáze provozované poskytovatelem služeb musí vyhovovat nebo
přesahovat současná kritéria o časovém výkonu stanovená ve Velké Británii
• Databáze by měly být neustále aktualizovány a data by měla být co nejaktuálnější
• Přenos dat musí být přes zabezpečenou síť
• Jakýkoliv přenos do PSAP nebo k EA musí být po obecném komunikačním protokolu
• Užívaný jazyk by měla být angličtina
• Text jiné barvy by měl odlišovat kategorie minimálních dat a přidaných dat v průběhu
přenosu, aby nedošlo k zdvojení nebo možné chybě.
• Databáze by měly být schopné poskytovat data o poloze ve formátu požadovaném
PSAP, aby je mohl bez problému posílat EA, které je potřebují.
56
•
•
Za ochranu dat, jejich aktualizaci a správnost odpovídá poskytovatel služeb, který je
také odpovědný za jakékoliv chyby a jejich řešení.
Poskytovatel služeb by měl splňovat určité standardy, měl by pracovat co
nejefektivněji a vyhovovat mezinárodně uznanému standardu (ISO 9000)
5.3. Zabezpečení sítě
5.3.1. Úvod
Speciálně v situacích, kde jsou po internetu přenášena osobní a důvěrná data se
bezpečnost stává důležitým faktorem. Komunikace mezi různými stranami zapojenými
v obsluze E-MERGE hovoru by měla být bezpečnostně zajištěna proti vnějšímu zásahu a
útokům. Popsaná architektura přenosu dat by měla podporovat některé významné aspekty
Virtuálních privátních sítí:
Důvěrnost dat – Třetí strana by neměla být schopná dekódovat důvěrné informace posílané
mezi dvěma stranami
Ověření identity – Strany, které mezi sebou komunikují by si měli být jisté identitou
protějšku.
Oprávnění - Partner užívající síť by měl buď mít právo nebo by mu mělo být zabráněno
využívání dat E-MERGE sítě.
Kontrola přístupu – V žádném případě by nemělo být umožněno jakékoliv třetí straně
vstupovat do systému bez náležitého oprávnění.
Specifikace uvedené níže popisují minimální bezpečnostní opatření, které by bezpečnostní EMERGE síť měla podporovat.
5.3.2. IP bezpečnost a bezpečný IP přenos dat
Obroské rozšíření internetu a enormní tok dat, která v něm proudí vyžaduje dobře ověřená
bezpečnostní řešení, která budou schopna obstát proti jakémukoliv problému. IP bezpečnost
poskytuje zabezpečení vrstvy transportního protokolu IPv4 a neustále vylepšuje a zakrývá
nedostatky tohoto standardu. Jako schopná alternativa se nabízí standard IPv6, ale pro tuto
verzi by mohl E-MERGE systém implementovat nebo užít IP zabezpečení bežící na IPv4.
Specifikace, které ovlivňují standard IP zabezpečení jsou popsány v dokumentu IETF
„Request for Comment document RFC2401“. IP bezpečnostní protokol má dva hlavní
podprotokoly z nichž každý je popsán ve svém RFC dokumentu. Tyto protokoly podporují
následující funkce:
•
•
•
Ověřování podle Ověřovací hlavičky specifikované RFC2402
Důvěrnost podle „Encapsulating Security Payload“ protokolu specifikovaného
RFC2406.
Integritu dat podle implementace RFC2402 a RFC2406 specifikací.
Datové rámce poslané mezi dvěma různými stranami E-MERGE by měli vyhovovat těmto
specifikacím nebo využívat odpovídající soft/hardware, který má stejné funkce.
Transportní a tunelový mód
IP datový přenos zabezpečený IP bezpečnostními nástroji může mít dvě podoby:
57
• Přenosový režim
• Tunelový režim
Přenosový režim obyčejně poskytuje podporu datovým spojením mezi dvěma subjekty, a
tunelový režim se týká zabezpečení přístupu. Aby bylo dosaženo shody s E-MERGE
specifikacemi, měl by tzv. Host (Hostitelský počítač) podporovat přenosový režim, protože
uzlový bod je externě zabezpečený a vystupuje jako bezpečnostní brána.
Virtuální privátní sítě
E-MERGE odpovídající Internetový datový přenos by měl být implementován jako virtuální
privátní síť. To znamená, že každá strana by měla podporovat, buď softwarově nebo
hardwarově následující funkce:
• Šifrování dat
• Ověřování identity
• Integritu dat
Přístup navrhovaný touto specifikací je jednoduše shrnut jako:
• Vytvořit jakousi Virtuální privátní síť v sobě samé není vhodné. Virtuální privátní síť
by měla být chráněna Firewallem. Host (hostitelského) počítače instalované u PSAP
nebo SP by měli pracovat na tzv. DMZ (demilitarizovaná zóna) straně sítě.
Firewally and IP zabezpečení
IP zabezpečení řeší dva hlavní problémy a to ověřování a integritu dat, což může vést ke
zdání, že IP zabezpečení je dostatečné pro vytvoření absolutně bezpečné sítě. IP zabezpečení
však nebrání hostitelský systém proti zlomyslným útokům z nebezpečného internetu. Jako
doplněk funkcí poskytovaných IP bezpečnostním protokolem může E-MERGE hostitelský
počítač chránit svůj hardware a software pomocí funkce Firewallu.
Jedna doplňující poznámka na aktuální implementaci firewallu je, že celkově jsou dva typy
firewall infrastruktury: Firewall na síťové vrstvě a na aplikační vrstvě. První z nich pracuje na
spodní vrstvě ISO/OSI modelu a je implementován hardwarovými zařízeními. Druhý z nich je
spíše znám jako proxy server a v podstatě poskytuje lepší kontrolu nad tokem dat. Od doby,
co jsou tyto dva firewally impementovány softwarem, mají vliv na reakční dobu systému.
V každé situaci mohou tyto dva systémy být porovnávány, ale E-MERGE specifikace
neupřednostňuje ani jeden ani druhý.
5.3.3. Minimální požadavky
Aktuální infrastruktura specifikovaná E-MERGE konsorciem se týká minimálních
požadavků na IP bezpečnostní standard samotný. Ačkoliv autorita, která má na starosti
centrální zabezpečení si může vyžádat ještě doplňující požadavky. V kontextu této specifikace
jsou základní požadavky vyžadovány od každého subjektu podílejícího se na E-MERGE
systému. Řešení může být buď implementováno softwarovými aplikacemi nebo naproti tomu
hardwarovými zařízeními. Jakékoliv bude konečné řešení E-MERGE systému, architektura by
měla obsahovat minimální IP bezpečnostní požadavky jak je popsáno v RFC2401.
IP bezpečnostní požadavky na PSAP infrastrukturu
PSAP infrastruktura by měla být chráněna síťovým firewallem a ten by měl poskytovat
následující minimální funkce:
• Ochranu před útokem na služby
• Ochranu před útokem třetí strany na zranitelná data nebo server
58
•
•
Ochranu před upstreamem datového toku. To může být případ, kdy se chce trojský
kůň připojit na hostitelský počítač.
Ochranu před útoky z legrace
Dále může být firewall implementován jako systém na síťové vrstvě. Systém na síťové
vrstvě pracuje na spodní vrstvě ISO/OSI 7 vrstvého modelu a daleko rychleji než protějšky
na vrstvě aplikační. Firewall sám může být později implementován jako hardwarové nebo
softwarové řešení. Firewall pracující na síťové vrstvě je velmi často použit na směrovačích.
Jako druhý požadavek E-MERGE specifikace považuje potřebu pevné IP adresy. PSAP
software a hardware by měl odpovídat RFC2401, RFC2402 a RFC2406 IP bezpečnostním
specifikcím.
Nakonec by mělo být poznamenáno, že řešení jak softwarové tak hardwarové mohou být
považována za implementaci jak firewallu tak IP bezpečnosti. E-MERGE specifikace by
mohla, pokud je to možné, také doporučit užití speciálního hardwarového řešení, ze kterého
budou těžit rozšířené zákaznicky orintované aplikace. Softwarová řešení mohou najít
uplatnění v malých firmách a testovacích řešeních.
HCC infrastruktura
Podobně jako PSAP infrastruktura, poskytovatel služeb nebo domácí centrum obsluhy hovorů
potřebují implementovat rychlé virtuální privátní sítě (VPN). Důsledkem je, že požadavky
jsou skoro stejné jako pro PSAP prostředí. HCC infrastruktura by měla být chráněna funkcí
firewallu. Tento firewall by měl poskytovat tyto minimální funkce:
•
•
•
•
Ochranu před útokem na služby
Ochranu před útokem třetí strany na zranitelná data nebo server
Ochranu před upstreamem datového toku. To může být případ kdy se chce trojský kůň
připojit na hostitelský počítač.
Ochranu před útoky z legrace
SP/LCC infrastruktura
Minimální požadavky na E-MERGE podsystém jsou velmi podobné požadavkům
stanoveným pro SP/HCC infrastrukturu. Zde opět bude významnou roli hrát rychlost a to ve
všech vrstvách systému. V důsledku bude přístup nebo strategie přijmuta PSAP i SP/HCC,
infrastruktura může být použita také pro tento úsek systému. To může zahrnovat preferenci
hardware řešení před softwarovým a to v implementaci IP bezpečnosti a implementaci
firewallu. Potřeba pevné IP adresy zůstává nezměněna.
Sekundární SP infrastruktura
Sekundární SP systém nekomunikuje přímo s PSAP, ale slouží jako přidaná informační
základna domácího a lokálního centra obsluhy hovorů. Tyto systémy „Back-end“ nemusejí
reagovat na nouzovou situaci ve stejný časový okamžik, jak je očekáváno nebo specifikováno
pro prvořadé systémy. Pro tento druh systému je plně přijatelné užití software IP zabezpečení
nebo firewallu.
Potřebě pevné IP adresy zůstává nejvyšší důležitost. Sekundární SP infrastruktura není přesně
definována v rámci E-MERGE projektu.
59
5.3.4. Bezpečnost databáze
Co by měl poskytovat databázový management systém:
a) Bezpečné spojení s DBMS
DBMS -Database Management Systém je databázový management systému. Skutečné
CRUD (Create Read Update Delete - vytvoř, čti, aktualizuj, smaž) operace mění nebo
aktualizují data z relačních databází. Proto je rozhodující že přenos dat mezi spotřebitelem dat
a producentem dat je na zabezpečené úrovni. DBMS klient-server spojení by mělo poskytovat
všechny potřebné náležitosti, aby byla umožněna bezpečná komunikce mezi Klient systémem
a DBMS server systémem. Klient v tomto případě je SP/HCC nebo SP/LCC partner. Server
obsahuje Databázový Management Systém a aktuální data. Implementace je dle
technologických omezení ovlivněna tradičním a specifickým Klient/Server prostředím. Proto
předmět bezpečného přístupu do databáze je ponechán na aktuální implementaci komerčního
DBMS řešení. V žádném případě nesmí být databáze vystavena přímo přístupu z internetu a
proto by měla být v DMZ. Datový přenos je po IP zabezpečeném socketu.
Obr. 5.1 Bezpečné spojení
b) Jednoduchý přístup
Jednoduché logování hraje velmi důležitou roli v zabezpečeném prostředí internetu.
Jednoduché přihlášení zrychluje komunikaci mezi oběma stranami. Jestliže je užit jednoduchý
přístup, jsou odesílána data o ověření a bezpečnostní data ze systému do systému nebo přímo
z centrálního systému jako je LDAP nebo NIS+ server. Aby bylo dosaženo shody s EMERGE specifikacemi, měl by jednoduchý přístup být implementován na zabezpečeném a
chráněném místě.
c) Chráněná uživatelská jména a hesla
Uživatelská jména a hesla by měla být chráněna před odhalením třetí stranou.
d) Ztráta dat
60
Data provider by měl zajistit ochranu trvalých informací důležitých pro PSAP a SP. SP je
odpovědný za ukládání dat pro PSAP nebo sekundární SP by měl implementovat trvale
podpůrné procesy.
5.3.5. Autorita centrální bezpečnosti
Bezpečnostní autorita by se měla starat o bezpečnost sítě. Základní funkce takovéto autority
jsou:
• Kontrola oprávnění a přístupu do E-MERGE sítě
• Poskytování PKI certifikátů
• Zajištění funkce bezpečnostní brány vytvořením zabezpečeného tunelu mezi dvěma
stranami.
Tento centralizovaný přístup má velkou výhodu v tom, že je jen jeden bod pro vstup do EMERGE sítě.
5.3.6. Závěr
Bezpečnost je bez pochyby jeden z nejdůležitějších problémů dneška spojený s širokým
užitím internetu. Použitelnost trvalého zabezpečení je proto jedna z nejlepších věcí, jak se
ubránit v internetu. E-MERGE architektura by měla mít zabezpečené spojení mezi:
• PSAP
• SP
• HCC
• SP/LCC
• Telekomunikační operátor a HCC
Každé z výše uvedených spojení by mělo podporovat minimální požadavky IP
zabezpečovacího protokolu specifikované v RFC2401. IP zabezpečený režim mezi
hostiteslkými počítači by měl být přenosově založený a implementovat Virtuální privátní siť a
firewall infrastrukturu. Zabezpečení by nemělo být omezováno jen na komunikaci nebo
přenos dat, ale mělo by se zaměřit také na ochranu databází.
5.4. Požadavky na ukládání dat
5.4.1. Úvod
E-MERGE infrastruktura datové obsluhy zachází se dvěma typy dat:
• Data poskytovaná vozidlovým (IVS) systémem.
• Data ukládaná a aktualizovaná různými SP
Data poskytovaná vozidlovým IVS systémem jako důsledek nouzového hovoru jsou
vyvolána různými senzory vozidla a popisují stav vozidla v době, kdy se stala nehoda. V EMERGE systému nazýváme tato data minimální data a úplná data, která jsou posílána
z vozidla k PSAP a SP.
Poskytovatel služeb sám ovládá druhý typ dat, někdy nazývaný jako statická data. Mnoho
těchto informací je poskytováno SP, který má smlouvu se zákazníkem.
61
Kombinací dat poskytovaných vozidlovým systémem (IVS) a dat uložených v databázi SP
vzniká nový typ datové informace, který zcela přesně identifikuje nehodu a umožňuje všem
zůčastněným stranám ponehodovou manipulaci s daty. Účel této datové zprávy, která je
složena z informací z databáze, je poskytnout PSAP dodatečné informace o osobách
v havarovaném vozidle. V důsledku toho by měl E-MERGE poskytovatel služeb zajistit
odpovídající infrastrukturu potřebnou k ukládání těchto informací. Data jsou posílána
ve formátu nezávislém na platformě, což je pevný formát, kde každé pole má pevně danou
délku a je vyplněno bity, jejichž velikost je charakterizována ASCII tabulkou. Poskytovatel
služeb je odpovědný za uložená a obdržená data a musí respektovat následující omezení:
•
•
•
•
•
•
Datová integrita - data poskytovaná různým subjektům v E-MERGE síti by měla být
správná, aktuální a srukturovaná.
Důvěrnost – Data, která má poskytovatel služeb, obsahují osobní údaje, které spadají
pod zákon o ochraně osobních dat. Tento druh informací je velmi citlivý a nemělo by
s ním být zacházeno v rozporu se zákonem a mimo stanovené hranice.
Schopnost přístupu – Data by měla být dosažitená každému z autorizovaných EMERGE účastníků a to rychle a dle stanoveného způsobu.
Záloha a zálohování – Poskytovatel služeb by měl instalovat pevnou zálohu a
zálohovat data, případně pečlivě dbát na to, aby nedošlo ke ztrátě dat.
Vkládání dat – Poskytovatel služeb by měl poskytnout potřebné rozhraní, aby mohl
autorizovaný personál vkládat nová data do databáze.
Databázový management a operace – Poskytovatel služeb by měl zajistit taková
opatření, aby bylo s daty z databáze zacházeno bezpečným způsobem. Toto se zvláště
týká takových informací jako jsou hesla a uživatelská jména.
Obr. 5.2 Strukturadatabáze PSAP
62
5.4.2. Požadavky databáze
Jak přesně jsou data ukládána systémem je věcí specifického datového přenosového
formátu. Z technického hlediska obě I/O rozhraní, z nichž je jedno implementováno na PSAP
a druhé na SP straně, by měla být schopna analyzovat uložené formáty a měla by být schopna
vytvořit datové rámce, které by se měly shodovat se specifikovanými formáty. Při
implementaci je důležité respektovat výše uvedený postup:
•
•
•
•
•
•
•
Data by měla být uložena v databázi.
Tyto databáze by měly být relačního typu.
Systém managementu relačních databází (DBMS) kontrolující ukládání aktuálních dat
by měl podporovat transakce.
DBMS by měl být naprosto jasně shodný s SQL-92 specifikacemi.
CRUD operace by měly být implementovány striktním uplatněním SQL-92
databázovým
dotazovacím a příkazovým jazykem. Je lepší neužívat specifických funkcí a jiných
specifických konstrukcí, které nepatří nebo nejsou specifikovány SQL-92
DBMS by měla poskytovat funkci registrace transakcí.
Ukládání a aktualizace dat by měla být rychlá a bez zpoždění způsobených DBMS
samotným. DBMS systémy poskytující určité druhy mechanismů s vyrovnávací
pamětí by měly být preferovány před těmi, které tuto funkci nemají.
63
6. Doporučení pro poskytovatele služeb
6.1. Úvod
Poskytování přidaných služeb PSAP v rámci vozidlem generovaného nouzového volání
(E-call) je významé pro efektivnost zásahu. V této době mnoho poskytovatelů služeb je již
zapojeno do E-MERGE systému a obsluhy E-call hovorů a tudíž jsou již k dipozici
zkušenosti s obsluhou E-call a databázemi zákazníků. Zkušenosti v kombinaci s možností
dalšího vývoje telematicky založených služeb dělají z poskytovatelů služeb velmi důležité
partnery v E-MERGE systému.
Rozsah dnešních služeb je obrovský a lze je zařadit do několika kategorií:
• samotná obsluha E-call,
• bezpečnostní a zabezpečovací služby (varování a/nebo obsluha hovoru o havárii,
havarijní a pohavarijní management, sledování a zaznamenávání pohybu vozidla,
zamykání/odemykání atd.),
• služby určování polohy spojené s dopravou/cestováním (informace o dopravě,
navigace), služby orientované na vozidlo (dálková diagnostika, monitoring), služby
zajištění vedení velkého konvoje atd.
Hlavním úkolem provozovatele služby vzhledem k vozidlem generovanému nouzovému
hovoru je přijímat a obsluhovat příchozí data a zpřístupnit tento balík dat pro daný PSAP a
stejně tak poskytovat předem určené služby zákazníkům (např. pohavarijní služby).
Tato kapitola popisuje doporučení pro poskytovatele služeb o tom, jak vytvořit a
uspořádat poskytování dat s přidanou hodnotou v E-call řetězci služeb zahrnutého v EMERGE systému.
6.2. Procesy HCC
6.2.1. Obsluha E-MERGE hovoru HCC
Obsluhu E-MERGE hovoru lze popsat následovně:
• Úplná data jsou přijata HCC.
• Datový hovor je směrován na operátora HCC
• Operátor HCC přijme úplné informace a na základě E-MERGE (CLI) identifikace
prohlíží svoji lokální databázi v níž má uloženy přidané informace.
• Operátor HCC najde data zákazníka (např. kontaktní adresu, cestovní pojištění,
zaměstnavatele atd.) a stejně tak i data o vozidle (VIN), číslo licenčního štítku,
informace o pojištění vozidla atd.).
• Operátor HCC zpracuje všechna dostupná data do jednoho datového protokolu a vloží
je do datového souboru s identifikací (CLI identifikace) jako součást databáze, ze
které má PSAP v případě potřeby možnost stahovat data.
• Jestliže je HCC kontaktováno PSAP po bezplatném evropské telefonním čísle HCC,
operátor v HCC je požádán o vytvoření konferenčního hovoru s PSAP a zákazníkem.
• Všechny manipulace jsou uloženy u poskytovatele služeb
• Databáze je auktalizovaná
64
6.2.2. Zacházení s E-MERGE informacemi
Jak již bylo zmíněno, data o havárii by měla být uložena u poskytovatele služeb (SP) a
sloučena s existujícími (statickými) daty. Potenciální data přicházející od PSAP budou
přidána do databáze poskytovatele služeb ihned po nehodě. Všechna data mezi HCC a PSAP
musí být poslána po bezpečné internetové lince.
6.2.3. Zobrazení dat
Způsob jakým HCC zobrazuje přijatá data se může lišit podle operátora. Sloučení s již
existujícími (statickými) daty může být vykonáno během předem definovaného času. Přidaná
data v databázi poskytovatele služeb viditelná pro PSAP by měla být uvedena v angličtině.
6.2.4. Přenos dat
HCC nemá informace o tom, jak PSAP obsluhuje nouzový hovor a proto není možné, aby
HCC posílalo informace do PSAP. Úkolem poskytovatele služeb je zpracovávat data do
databáze za danou časově omezenou dobu. PSAP se dozví díky identifikaci poskytovatele
služeb (IP adresa uvedená v minimálních datech), že po určité době jsou přidaná data
dostupná z HCC databáze. Data poté mohou být stažena po bezpečné internetové lince. Tímto
úkonem bude HCC vědět, který PSAP obsluhuje hovor a může se začít starat o pohavarijní
služby.
6.3. Technické požadavky
Technické požadavky jsou pouze doporučené. E-MERGE projekt definuje pouze
minimální vybavení a organizaci tak, aby vytvořil formulaci dočasných a podmínečných
procesů pro hlasovou komunikaci a datovou výměnu.
6.3.1. Telefonní infrastruktura
Telefonní systém by měl mít následující funkce:
• přijímání dat od IVS a jejich registraci a přidělení na dané pracovní místo
• zapisovat, včetně časové známky, veškeré činnosti, které souvisí s E-call / E-MERGE
událostí
• vytvořit konferenční hovor
• směrování hlasu a dat na vyhrazená pracovní místa
• možnost implementace vyhrazených pracovních míst do konferenčních hovorů.
• v případě smluvního souhlasu – nahrávání hovoru
• přesměrování hovoru na E-MERGE pracovní místa
• přímá volba na E-MERGE pracovní místa
• řízení jednotlivých skupin
• zobrazení volajícího čísla
• kontrolní funkce jako:
o Odposlouchávat
o Zasahovat
o Schvalovat
• ukládat informace a časové známky po dobu tří měsíců
• přidělení aktivního pracovního místa pro všechny hovory E-call
• přednostní obsluha E-call událostí
65
•
•
•
•
•
•
•
zobrazení všech příchozích a odchozích čísel pro operátora
poskytnutí definovaného čísla operátora E-call, aby HCC mohlo komunikovat přímo
s daným operátorem.
funkci zobrazení volajícího
funkce zamezení přetížení
ukládat všechny hlasové činnosti do E-call databáze
implementace funkce přijímání a posílání v:
o GSM / SMS
o GSM / datový kanál
o GPRS
o UMTS
interní a externí konferenční hovor.
6.3.2. Personál
Personál by měl splňovat následující požadavky:
• dostupnost 24 hodin denně 365 dní v roce
• 4 směný provoz
• schopnost komunikace v několika jazycích, minimálně v angličtině
• průprava v oblasti psychologie a stresu
• ochota se dále vzdělávat.
6.4. Přidaná data od HCC k PSAP
Přidaná data od HCC k PSAP mohou být:
• Informace o zákazníkovi
• Data o zdravotním pojištění zákazníka
• Data o zákazníkově kredit kartě
• Informace o řidičském průkazu zákazníka
• Detaily o kontaktech na zákazníka
• Data o kontraktu se SP
• Data o vozidle
• Data o IVS
• Úplné informace poskytované IVS
• Data o pojištění vozidla
• Data o výrobci
• HCC data
• SP data (LCC)
6.5. Systémové parametry SP
V této části budou definovány systémové požadavky na SP vztažené k tomuto procesu:
• úplná data přichází do HCC.
• datový balík je zpracován s přidanými daty o vozidle a zákazníkovi z HCC databáze
• data jsou uložena do databáze HCC a jsou dostupná pro PSAP
• HCC dostává potvrzení, že PSAP dostal všechna přidaná data.
66
Časové schéma podle kterého by SP měl pracovat je následující
Obr. 6.1 Časové parametry systému tísňového volání
V případě přetížení sítě, má normální hlasový hovor 112 prioritu před všemi ostatními
hovory. Jakmile je hovor 112 vytvořen je vždy v případě inicializace vozidlem generovaného
nouzového hovoru a minimálních dat nasledujících tento hovor 112 zaručené že hovor i data
se spolehlivě dostanou do PSAP. Ačkoliv přidaná data se vrátit nemohou.
Majitel nebo vlastník databáze by měl dozajista mít uzavřenou smlouvu o spolupráci
s osobou, pro kterou byla tato data generována, aby byla zaručena přesnost. Jinými slovy
zákazník je povinen nahlásit jakoukoliv osobní změnu a měl by pravdivě odpovídat na
dotazovací dopisy.
Za chybnou funkci systému může odpovídat výrobce. PSAP a/nebo HCC a hostitelskou
centrální databází by mohly potřebovat kompenzovat zákazníka za nepřijmutí informací díky
chybě komunikačního řetězce (jiné než v telekomunikační síti) působící zhoršení stavu
nouzové situace.
PSAP a pohotovostní jednotky by měly být odškodněny v případě, že akce byla provedena
na základě špatných (falešných) informací. Nesprávné informace mohou být následkem
nesprávného zacházení (HMI problém), úmyslného matení (kriminální počin), technické
chyby (softwarový problém) a nesprávnými daty poskytnutými zákazníkem nebo chybou
v ukládání dat.
7. Systém tísňového volání v nákladní dopravě
Ukazuje se, že nejvýznamnější oblastí využití systému tísňového volání (e-call) je
přeprava nebezpečných nákladů. Svůj význam má E-call i při přepravě ostatních nákladů, kde
je využití obdobné jako v osobní dopravě. Přínos automatického nouzového volání je
především ve zkrácení prodlevy od havárie do přivolání pomoci.
67
Nebezpečným nákladem se v této souvislosti rozumí látka nebo věc nějakým způsobem
nebezpečná člověku nebo životnímu prostředí. Nemusí se přitom jednat pouze o jedovaté
nebo radioaktivní látky, nebezpečný náklad představují i pohonné hmoty, maziva a jiné běžně
převážené náklady. Při haváriích jsou pak nejčastěji ohroženy vodní zdroje, dochází ke
kontaminaci půdy ropnými produkty, do ovzduší uniká nebezpečný plyn. Cílem je tedy
komplexní řešení situace v případě havárie vozidla s nebezpečným nákladem. V podmínkách
České Republiky se jedná především o silniční a železniční dopravu, protože ty představují
majoritní způsoby dopravy obecně všech nákladů. Z těchto dvou se pak pozornost zaostřuje
na silniční dopravu, kde je nehodovost mnohonásobně větší.
Následující tabulka ukazuje počty nehod nebezpečných nákladů v letech 2001 a 2002. Je
zřejmé, že z těchto několika málo údajů nelze tvořit nějaké statistické závěry a jedná se pouze
o informativní údaje. Asi nejzajímavější změnou je několikanásobné zvětšení počtu úniků
kapalných látek v roce 2002 ve srovnání s rokem 2001.
Skupenství
pevné
kapalné
plynné
Počet nehod nebezpečných
nákladů
Počet úniků nebezpečných látek
r.2001
r.2002
r.2001
r.2002
104
132
50
91
139
25
1
10
1
1
92
6
V současné době se dle odhadů převáží po silnicích 15 – 20 % všech nebezpečných
nákladů. Odhad EU říká, že v roce 2010 to bude celých 80%! Tento stav je očekáván
zejména kvůli dlouhodobému poklesu přepravy na železnici a po vodě a jejího přesunu na
silnice. Tato situace je značně nepříznivá mimo jiné s ohledem na životní prostředí, protože
silniční doprava znečišťuje životní prostředí zdaleka nejvíce. V otázkách bezpečnosti je na
tom silnice také velmi špatně a množství nehod je mnohonásobně vyšší než u železniční nebo
vodní dopravy. Hlavní problémem malého využívání vodní a železniční dopravy je především
nepružnost a omezená infrastruktura. S tím jsou spojeny např. vyšší náklady z důvodu
opakovaného překládání zboží, delší doba potřebná na přepravu apod.. Výhody jsou naopak
ekologický provoz, nižší energetické nároky na přepravu a možnost přepravovat velké objemy
zboží.
Popsaná vzestupná tendence je závažná a vyžaduje jak technická tak legislativní
bezpečnostní opatření směřující k minimalizaci škod, způsobených únikem nebezpečného
nákladu. Snaha o minimalizaci rizik při přepravě nebezpečných nákladů je patrná v celé
Evropě. Dobrým příkladem mohou být dopravní omezení týkající se nákladních vozidel a
vozidel převážejících nebezpečný náklad v některých státech .
Španělsko
Platí zde omezení pro nákladní automobily nad 3,5 t a pro nákladní automobily přepravující
nebezpečný náklad během víkendu a státních svátků. O konkrétních dnech, dobách a silnicích
si rozhodují jednotlivé provincie. Obvyklé jsou také další místní zákazy, obzvláště o
víkendech mezi červnem a zářím.
Švédsko
V centrech některých měst jsou platná omezení během určitých období a jsou pak označeny
značkami. V některých větších městech je doprava nákladních automobilů a vozidel
přepravujících nebezpečný náklad omezena. Dopravní značky určují váhové omezení a
poskytují informace o náhradní trase.
68
Nejsou žádná oficiální pravidla, ale se všeobecným souhlasem je malý nebo žádný provoz
těžkých nákladních vozidel v průběhu vánočních a velikonočních svátků, v průběhu svátků
letního slunovratu a ve dnech předcházejících těmto svátkům.
Portugalsko
Vozidla pro nákladní dopravu jakékoliv hmotnosti a vozidla s nebezpečným nákladem jsou
zakázány:
- soboty od 15,00 do 22,00 hod.
- neděle a státní svátky od 7,00 do 24,00 hod.
- výjimky pro mezinárodní přepravu, zásobování nemocnic, zásobování palivem, urgentní
přeprava, atd.
Norsko
Přeprava nebezpečného zboží je zakázána v tunelu spojujícím východ a západ Osla od pondělí
do pátku od 7,00 do 9,00 hod. a od 14,00 do 18,00 hod.
Francie
Zákaz jízdy nákladních automobilů nad 7,5 t a nákladních automobilů s nebezpečným
nákladem nad 7,5 t na vybraných dálnicích. Vozidla jakékoliv váhy přepravující nebezpečné
zboží jsou zakázána na všech francouzských silnicích o sobotách od 12.00 hod. do nedělí
24.00 hod
Zvláštní omezení jsou platná po celé Francii během července a srpnu a při speciálních dnech
volna (např. v únoru a květnu).
Lucembursko
Maximální dovolená rychlost vozidel převážejících nebezpečný náklad a stroje s hmotností
nad 3,5 t je v obci 40 km/h a mimo obec 60 km/h (včetně dálnice).
Turecko
Rychlost vozidel vezoucích nebezpečný náklad je v obci omezena na 25 km/h a mimo obec a
na dálnici na 50 km/h.
Řecko
Omezení rychlosti pro vozidla s neb. nákladem je v obci 40 km/h a mimo obec a na dálnicích
50 km/h.
Slovinsko
Zákaz jízdy vozidel s neb. nákladem na vybraných komunikacích platí celoročně o nedělích,
státních svátcích a ve dnech pracovního klidu. V období od 15.června do 5. září platí zákaz
také o sobotách od 6:00 do 13.00 hod. Na Velký pátek od 14:00 do 22:00 hod. Za špatného
počasí jsou uvedené zákazy platné na všech silnicích pro kombinovaná vozidla, vozidla
převážející nebezpečný náklad a vozidla přesahující maximální povolenou hmotnost a
rozměry (nadměrné náklady).
Uvedený přehled je stručný a neúplný a má pouze informativní charakter, nicméně je z něj
patrná snaha o řešení problému nebezpečných nákladů. Týká se především předpisů
vztahujících se speciálně na přepravu nebezpečných nákladů. Velká část předpisů a omezení
je pak společná i pro nákladní vozidla. Vydaná omezení platí často na vyjmenovaných
úsecích silnic a dálnic a období platnosti je přesně definováno (hodiny, dny měsíce). Omezení
69
bývají doplněna řadou výjimek, jako např. zásobování nemocnic, policie, armády, přeprava
pohonných hmot, vozidla mezinárodní přepravy, urgentní přeprava atd.
7.1. Průběh záchranné akce v případě havárie
Situace je dnes taková, že havárii obecně jakéhokoliv vozidla nejčastěji nahlásí řidič okolo
jedoucího vozidla nebo přímo řidič havarovaného vozidla, je-li schopen. První časová
prodleva nastane od okamžiku, kdy volající lokalizuje místo nehody do doby než na místo
přijede policie popřípadě hasiči a lékařská pomoc. V lepším případě je volající schopen
identifikovat havarované vozidlo a jeho náklad a tím přispět k rychlému řešení situace.
Havárie se však může stát v noci a na málo frekventované komunikaci a zde již může nastat
kritické prodlení. Obecnou snahou je tedy maximalizace rychlosti reakce záchranných složek
na vzniklou situaci, jejíž řešení má nejvyšší prioritu právě v případě nebezpečných nákladů.
Požadovaný stav je v podstatě opakem výše uvedené situace. V případě nebezpečného
nákladu jde však kromě lidských životů také o životní prostředí, které může být díky úniku
nebezpečných látek dlouhodobě poškozeno. Situace kolem nebezpečných nákladů, pokud jde
o značení, konstrukci a podmínky provozu vozidel, je podrobně zpracována v mezinárodní
smlouvě ADR o nebezpečných věcech (viz. níže), kde je mimo jiné uveden také kompletní
seznam nebezpečných věcí. Pro rychlý a precizní zásah záchranných složek není nutná tedy
jen informace o poloze, ale především informace o povaze nákladu a úplně nejlepší je znalost
přesného označení havarovaného materiálu.
ADR – „European Agreement concerning the International Carriage of Dangerous Goods
by Road“ je dohoda vytvořená 30.září 1957 v Ženevě pod patronací Ekonomické komise pro
Evropu (UNECE - United Nations Economic Commission for Europe). Na zasedáních
Pracovní skupiny pro přepravu nebezpečných věcí Evropské hospodářské komise Organizace
spojených národů byly v letech 2001 – 2002 vypracovány a schváleny návrhy změn a doplňků
„Přílohy A – Všeobecná ustanovení a ustanovení týkající se nebezpečných látek a předmětů“
a „Přílohy B – Ustanovení o dopravních prostřdecích a přepravě“.
Změny a doplňky „Přílohy A“ a „Přílohy B“ vstoupily v platnost na základě článku 14
odst. 3 Dohody ADR dne 1. ledna 2003 a tímto dnem vstoupily v platnost i pro Českou
republiku. Současně platnost „Přílohy A“ a „Přílohy B“ vyhlášených před 1.
Dopravní jednotky přepravující nebezpečné věci musí být opatřeny dvěma pravoúhlými
reflexními oranžovými tabulkami odpovídajícími ustanovením uvedeným v 5.3.2.2.1 ADR
umístěnými ve svislé rovině. Musí být umístěny jedna na přední a druhá na zadní straně
dopravní jednotky. Musí být zřetelně viditelné.
Reflexní oranžové tabulky musí být 40 cm široké a nejméně 30 cm vysoké. Tyto tabulky
musí mít černý okraj nejméně 15 mm široký. Jestliže rozměry a konstrukce vozidla jsou
takové, že disponibilní povrch je nedostačující pro umístění těchto tabulek, jejich rozměry
mohou být zmenšeny na šířku 300 mm, výšku 120 mm a šířku černého okraje 10 mm.
Identifikační číslo bezpečnosti a UN číslo sestává z černých číslic o výšce 100 mm a
tloušťce čáry 15 mm. Identifikační číslo nebezpečnosti musí být uvedeno v horní části tabulky
a UN číslo v dolní části; obě čísla musí být od sebe oddělena vodorovnou černou čárou o
tloušťce 15 mm, v polovině výšky tabulky od jednoho jejího okraje k druhému. Identifikační
číslo nebezpečí a UN číslo musí být nesmazatelná a musí zůstat čitelná po 15 minutách
působení ohně.
Příklad oranžové tabulky s identifikačním číslem nebezpečnosti a UN číslem:
70
33
1088
Identifikační číslo nebezpečnosti
(2 nebo 3 číslice, případně
s předřazeným písmenem X
UN číslo (4 číslice)
Význam identifikačních čísel bezpečnosti
Identifikační číslo bezpečnosti sestává ze dvou nebo třech číslic. Obecně označují číslice tato
nebezpečí:
•
•
•
•
•
•
•
•
Únik plynu tlakem nebo chemickou reakcí
Hořlavost kapalin (par) a plynů nebo kapalin schopných samoohřevu
Hořlavost tuhých látek nebo tuhých látek schopných samoohřevu
Podpora hoření
Jedovatost nebo nebezpečí infekce
Radioaktivita
Žíravost
Nebezpečí prudké samovolné reakce
pozn.: Nebezpečí prudké samovolné reakce ve významu číslice 9 zahrnuje z povahy látky
vyplývající možnost nebezpečí výbuchu, rozpadu nebo polymerační reakce za uvolňování
značného tepla nebo hořlavých a/nebo jedovatých plynů.
Zdvojení číslice označuje intenzifikaci příslušného nebezpečí. Postačuje-li k označení
nebezpečnosti látky jediná číslice, doplní se tato na druhém místě nulou.
Následující kombinace číslic však mají zvláštní význam: 22, 323, 333, 362, 382, 423, 44, 446,
462, 482, 539, 606, 623, 642, 823, 842, 90 a 99.
Pokud je před identifikačním číslem nebezpečnosti uvedeno písmeno "X", znamená to, že,
látka reaguje nebezpečně s vodou.
7.2. Postup zpracování informace v PSAP
Jak už bylo uvedeno výše, jedná se o automatizované volání zařízení umístěného na nebo
ve vozidle převážející nebezpečný náklad. Zpracování takové zprávy by mělo být
71
v maximální možné míře zautomatizováno. Podstatu automatizace tvoří databáze obsahující
údaje potřebné k řešení konkrétního problému.
V současné době jsou všechna tísňová volání přesměrována na pevnou linku Českého
telekomu, který směruje tato volání do operačních středisek dle spádových oblastí. Zásadním
úkolem je tedy zajistit přenos datové informace, pokud možno v nezměněné podobě, do
operačního střediska.
Příchozí tísňové volání na vstupu systému je rozděleno na hlasovou a datovou část (pokud
alespoň jednu z nich obsahuje) . Data se automaticky doplní do připraveného formuláře a dle
jejich charakteru se může provést nějaká dodatečná akce (např. zobrazení na mapě). V případě
hlasové komunikace se operátor pomocí přesně formulovaných dotazů snaží vyzvědět od
volajícího co nejvíce informací o vzniklém problému a tyto údaje zanáší do elektronického
formuláře. Spojením těchto dvou informačních zdrojů (data, hlas) vznikne strukturovaný
záznam informací – vyplněný elektronický formulář. Nyní záleží na operátorovi, zdali
posoudí situaci jako nouzovou nebo jako zneužití nouzové linky a zvolí odpovídající postup.
Je zřejmé, že údaje o poloze volajícího je možné využít i při odhalování jedinců
zneužívajících tísňové linky a lze tedy očekávat snížení počtu planých poplachů.
Předposledním úkonem operátora je odeslání vyplněného formuláře jako dotazu na databázi
obsahující informace o záchranných postupech, místně příslušných jednotkách, seznam
nebezpečných látek apod. Výsledkem takového dotazu by měl být ucelený soubor informací
odpovídající množství údajů na vstupu dotazu. Jinými slovy: Na základě informací o poloze
se vyhledá územně příslušná záchranná jednotka, podle přesně definovaných vstupních
parametrů (zvolené modelové situace) se vyhledá scénář řešení, dle UN čísla nebezpečného
nákladu se vyhledá popis nebezpečné látky spolu s návodem na likvidaci, atd. V posledním
kroku zkontroluje operátor získané informace a odešle zprávu určeným místům.
Pro zpracování volání o havárii nebezpečného nákladu je přímo modelovým příkladem
zpracování informačního systému DOK (viz. výše). Funkčně a obsahově představuje tento
typ databáze přesně požadavky operačního střediska na řešení havárie nebezpečného nákladu.
72
Zaznamenání informací
Volání: DATA a/nebo HLAS
oddělení hlasové a datové části
data
ano
hlas
zobrazení
Jsou obsažena
data o poloze?
hlasová komunikace
na mapě
záznam komunikace
ne
automatické předvyplnění formuláře
databázový dotaz
strukturovaný záznam informací získaných z přijatých dat
a z uskutečněného hovoru - vyplněný formulář
falešný poplach?
ne
ano
archivace,
šetření,
řešení
Databáze údajů:
Nebezpečné náklady (ADR)
Scénáře řešení modelových situací
Záchranné složky dle lokace
Seznam odborníků pro zvláštní úkoly
Kde je problém, (silnice, obec, budova, zeměpisné souř.)
Kdo má pomoci (hasiči, záchranka, policie, specialista)
Co je potřeba (nástroje, materiál, spec. vybavení)
kontrola odesílaných údajů
oprava, doplnění, komentář
odeslání zprávy určeným složkám IZS
Zpracování informací
Obr. 7.1: Struktura a průběh zpracování zprávy v PSAP
Je zřejmé, že existence aktualizované a bezpečně fungující databáze je základním
kamenem úspěchu procesu automatizace zpracování tísňového volání. Zpracování takovéto
databáze je pravděpodobně vůbec nejnáročnější úkol v budování operačního střediska.
Je však jasné, že při některých událostech dojde k příjmu několika volání týkajících se
jediné události. Typický případ je dálnice, kde po havárii může volat linku 112 každý
kolemjedoucí, než se na místo dostaví pomoc. Je tedy třeba zařídit shromažďování těchto
volání a určitý způsob třídění, nejspíš na základě polohy. V blokovém schématu na obr.2 je
příchozí hovor ohraničen modrým rámečkem nazvaným „Zaznamenání informací“. Pro více
takových hovorů je třeba samostatného vyhodnocení a sloučení jednotlivých výstupních
informací do jednoho celku, se kterým je dále nakládáno.
Tato úloha již představuje konkrétní realizační řešení a není třeba se jí v tomto okamžiku
dále zabývat.
73
7.3. Využití E-call při zabezpečení přepravy
nebezpečných nákladů
Až dosud byl E-call popisován obecně a především s ohledem na ochranu lidského zdraví
a života. Avšak, je docela dobře možné využít služeb tísňového volání i pro ochranu přírody a
přírodních zdrojů. Havárie vozidla převážejícího nebezpečný náklad může mít ničivé a
dlouhodobé následky. Zde, stejně jako při záchraně lidského života, hraje roli každá minuta a
včasný zásah může významným způsobem snížit škody na přírodě a životním prostředí.
Myšlenka využití tísňového volání se opírá o zavedení automatické kontroly stavu
nebezpečného nákladu a případného alarmu. Prakticky jde o vybavení nebezpečného nákladu
vysílací jednotkou, doplněnou o senzory kritických vlastností převáženého nákladu. V případě
havárie podnítí senzory vyslání nouzové informace, obsahující některé důležité informace,
jako např. druh nebezpečného nákladu (UN číslo), druh vozidla, množství, apod. Pevná
struktura odeslané zprávy umožní operačnímu středisku automatické vyhodnocení situace a
rychlou reakci. Zde je více než důležitá právě pevná struktura přenášené zprávy, protože díky
ní lze celý proces vyhodnocování automatizovat a tím pádem výrazně urychlit. Vhodným
přenosovým prostředkem pro tento účel může být protokol GTP (Global Telematics
Protocol).
74
8. Stávající stav v ČR
Integrovaný záchranný systém (dále jen „IZS“) je určen pro koordinaci záchranných a
likvidačních prací při mimořádných událostech, včetně havárií a živelních pohrom. IZS není
institucí. Je to systém s nástroji spolupráce a modelovými postupy součinnosti (typovými
činnostmi) a je součástí systému pro zajištění vnitřní bezpečnosti státu. Je jím naplňováno
ústavní právo občana na pomoc při ohrožení zdraví nebo života.
IZS se u nás buduje od roku 1993, kdy bylo usnesením vlády č. 246/1993 schváleno jeho
13 zásad. Základním právním předpisem pro IZS je nyní zákon č. 239/2000 Sb., o
integrovaném záchranném systému a změně některých zákonů, ve znění zákona č. 320/2002
Sb..
IZS vznikl z potřeby každodenní činnosti záchranářů, zejména při složitých haváriích,
nehodách a živelních pohromách, kdy je třeba organizovat společnou činnost všech, kdo
mohou svými silami a prostředky, kompetencemi nebo jinými možnostmi přispět k provedení
záchrany osob, zvířat, majetku nebo životního prostředí. Je to systém spolupráce a koordinace
složek, orgánů státní správy a samosprávy, fyzických a právnických osob při společném
provádění záchranných a likvidačních prací tak, aby stručně řečeno „nikdo nebyl opomenut,
kdo pomoci může a vzájemně si nikdo z nich nepřekážel“. To je zejména v hektickém období
mimořádných událostí velice nesnadný úkol, který musí mít svá pravidla.
8.1. Složky IZS
Základními složkami IZS podle zákona o IZS jsou Hasičský záchranný sbor ČR a
jednotky požární ochrany, zařazené v plošném pokrytí území kraje, dále Policie ČR a
zdravotnická záchranná služba, které jsou schopny rychle a nepřetržitě zasahovat, mají
celoplošnou působnost na území celého státu. Pokud tedy má obec jednotku sboru
dobrovolných hasičů, která je na takové úrovni, že je začleněna do plošného pokrytí území
kraje (v podstatě to znamená, že zasahuje i mimo svou obec), je tato jednotka základní
složkou IZS.
Celý systém pak řeší i plánovitou pomoc ostatních složek IZS. Počítá se zapojením
komunálních havarijních služeb, městské policie, občanských sdružení, nemocnic a zejména
Armády ČR. Pro podporu složek IZS při rozsáhlých mimořádných opatřeních mohou být za
jistých podmínek použity i hospodářská opatření pro krizové stavy. Je stanoven způsob,
jakým se základní složky IZS mohou přihlásit a využít např. pohotovostní zásoby.
IZS tedy není organizací v podobě instituce, ale jen a především vyjádřením pravidel
spolupráce (i když určité orgány, které zajišťují koordinaci má a mít musí). Jsou-li
integrujícím faktorem pravomoci řídit nebo provádět záchranné práce, budou se koordinující
orgány odvíjet od těch složek nebo prvků systému, které kompetence umožňující řízení a
provádění záchranných prací mají. Avšak odlišná pracovní náplň i pravomoci jednotlivých
složek zakládaly a zakládají nutnost určité koordinace postupů.
Z uvedených důvodů se v Integrovaném záchranném systému dělí řízení dle povahy i
kompetencí na úroveň:
taktickou, která probíhá přímo na místě zásahu složek IZS,
operační, která probíhá mezi operačními středisky a dispečinky
strategickou, která probíhá na okresních a krajských úřadech a na ministerstvu vnitra.
75
8.2. Operační střediska
Kontaktními místy pro příjem žádosti o poskytnutí pomoci v nouzi jsou zejména operační
střediska základních složek integrovaného záchranného systému (IZS). Vyžadování státem
garantované pomoci v nouzi je v České republice jednotné, a to na telefonních číslech 150,
155, 158 a 112. Mimoto fungují v ČR pro přivolání pomoci i další celostátně platná tísňová
čísla, např. 156 - obecní policie. Od 2. 1. 2003 nově funguje v pevných telefonních sítích pro
vyžadování pomoci v nouzi rovněž jednotné evropské číslo tísňového volání 112.
Společným legislativním východiskem pro činnost operačních středisek u základních
složek IZS je v současné době ustanovení § 4 odst. 4 zákona o IZS, které mimo jiné stanoví,
že základní složky IZS zajišťují nepřetržitou pohotovost pro příjem ohlášení vzniku
mimořádné události. Takovou činnost musí provádět příslušný organizační článek základní
složky IZS. Tím je míněno operační středisko základní složky IZS.
V podmínkách HZS ČR se zřizuje operační a informační středisko na úrovni MVgenerálního ředitelství HZS ČR. HZS krajů pak zřizují operační a informační střediska jako
své organizační součásti.
Operační střediska je nutné vnímat nejen jako právní kategorii, ale i jako technicko sociální subsystém v systému zdolávání mimořádných událostí a krizových situací.
Základní třídění operačních středisek je možno provést podle:
• druhu
• vymezené územní působnosti
• režimu řešení události
• velikosti
Jsou možná i další kriteria, například členění na hlavní a záložní, stabilní a mobilní.
Zvláštní kategorii představují školní operační střediska, tedy výcviková zařízení, určená k
přípravě budoucího personálu operačních středisek.
Třídění středisek podle druhu
Operační střediska mohou být provozována jednotlivými složkami samostatně nebo několika
složkami IZS společně.
Společná operační střediska mohou být dále prostorově nebo systémově sdružená.
V prostorově sdruženém operačním středisku funguje několik samostatných operačních
středisek ve společném prostoru (místnosti, budově) a ke komunikaci mezi jednotlivými
operačními středisky dochází prostřednictvím informačních a komunikačních zařízení, ale
také fyzickým kontaktem mezi operátory. Systémově sdružené středisko charakterizují
„univerzální“ operátoři zabezpečující služby pro více složek IZS.
Mezi výhody společného provozu patří především lepší vzájemná komunikace mezi složkami,
jednotná aktualizace informací a společná technická obsluha komunikačních a informačních
systémů. Nevýhodou slučování je vyřazení celého střediska z provozu v případě havárie.
Třídění středisek podle územní působnosti
místní působnost (např. obecní policie, HZS podniku),
okresní působnost (např. územní odbor HZS kraje, ZZS, PČR),
krajská (regionální) působnost (např. krajská OPIS HZS kraje, OPIS správ krajů PČR),
76
republiková působnost (např. OPIS MV-generálního ředitelství HZS ČR).
Třídění operačních středisek podle procesního režimu
Řešení mimořádné situace na operačním středisku základní složky IZS prochází několika
fázemi:
příjem tísňové zprávy,
aktivace sil a prostředků,
koordinace činností a podpory řízení zásahu,
uvolnění vyslaných sil a prostředků.
Jednotlivá operátorská pracoviště mohou realizovat buď všechny nebo jen některé procesní
fáze. V této souvislosti hovoříme o sériovém nebo paralelním procesním režimu řešení. Při
sériovém režimu (multifunkčním) může každé pracoviště řešit mimořádnou situaci od začátku
až do konce. O paralelním procesu řešení hovoříme tehdy, když jednotlivá pracoviště řeší
pouze dílčí úkoly (např. pouze přijímá tísňová volání, zabezpečuje řízení zásahu, apod.)
Třídění operačních středisek podle velikosti
Pro stanovení velikosti operačního střediska je rozhodujícím kritériem počet aktivních
operátorských pracovišť, potřebných k zabezpečení běžného provozu. Běžným provozem
rozumíme situaci, kdy se příslušný územní celek nenachází ve stavu řešení mimořádné situace
buď velkého rozsahu, nebo dokonce vyhlášení některého z krizových stavů.
Dalším kriteriem je pak počet záložních operátorských pracovišť, která jsou potřebná pro
přechod operačního střediska do mimořádného provozního režimu. Otázky stanovení počtu
aktivních a záložních operátorských pracovišť příslušného operačního střediska jsou úzce
spojeny s rozsahem úkolů, které operační středisko plní a s jeho technickým vybavením.
Školní operační střediska
Školní operační středisko je zvláštním druhem výcvikových zařízení, určených prioritně pro
přípravu operátorského personálu operačních středisek. Je tvořeno třemi organizační celky operátorským sálem, prostorem pro simulaci chování okolního světa a režijním pracovištěm.
Školní operační střediska je možné rovněž využít pro případný záložní provoz na úrovni
okresu či kraje.
8.3. Zkušenost s operačním střediskem v Ostravě
Centrum tísňového volání Ostrava je příkladem dobře fungujícího a rychle se rozvíjejícího
operačního střediska. Díky aktivní spolupráci všech záchranných složek a magistrátu města
Ostravy bylo možné vybudovat moderní a technologicky vyspělé call centrum. Ostravské
centrum tísňového volání lze označit za centralizované v rámci města Ostravy, což tedy
znamená, že všechny hovory tísňových linek jsou směrovány na jedinou centrálu, kde se o ně
podělí příslušné složky IZS. Centrum využívá moderních technologií při příjmu a zpracování
tísňového volání a to především automatickou lokalizaci volajícího v případě volání z pevné
linky, sledování polohy vybraných vozidel pomocí navigačního systému GPS apod.
Zjišťování polohy mobilních telefonů prochází v současné době testovacím provozem.
Způsob zpracování příchozí zprávy je velice podobný výše uvedenému diagramu.
77
Příchozí volání je přijato operátorem hasičského sboru. Jsou – li přijímací operátoři
obsazeni, je hovor směrován na všechny ostatní volné operátory. Operátor na příjmu vyplní
hlavičku události údaji typu: kdo volá, odkud volá, proč volá a operátor se snaží zjistit co
možná nejucelenější stručný popis problému. Po vyplnění Hlavičky událostí je tato přeposlána
na určené záchranné složky (na operátory sedící ve stejné místnosti), kteří dle charakteru
události zmobilizují potřebné síly. Přitom přijímací operátor má možnost sledovat stav
vyřízení volání ode všech jednotlivých složek od převzetí až po uzavření události.
Zajímavostí je sledování vybraných vozidel PČR a HZS na území města Ostravy.
Zajímavý je případ, kdy se k jednomu případu sejde více volání. Při příchodu prvního
volání zapíše dispečer všechna potřebná data pro příjem události. Volá-li další volající stejnou
událost, mohou nastat dva případy:
•
•
o této události již ví (zaslechl na sále, že na adrese "xy" došlo k události "xx" a
volajícímu sdělí, že na místo již byly vyslány jednotky a ověří, případně se zeptá na
nějaké doplňující informace.
o této události neví, začne vypisovat hlavičku událostí, vypíše adresu a po uzavření
Hlavičky událostí mu systém sdělí, že na uvedené adrese je již evidovaná událost,
jestli chce pokračovat.V tom případě se na sále zeptá, zda se jedná o stejný druh
události (může se stát, že např.na uvedené adrese hasiči ve druhém patře otevírají byt,
ale v pátém patře dostal občan epileptický záchvat - pak se sice jedná o stejnou adresu,
ale dvě rozdílné události).Pokud je událost shodná, nepokračuje dále ve zpracování
události, pokud událost není shodná, pokračuje ve zpracování události.
Stávající systém zatím ovšem nepočítá s možností automatického hlášení o haváriích
nebezpečných nákladů. Je to zapříčiněno především faktem, že nebezpečné náklady zatím
nebývají vybaveny systémem automatického volání, které by bylo třeba zpracovávat.
Havárie nebezpečného nákladu se v současné době řeší tak, že na místo nehody je vyslána
univerzálně vybavená hasičská jednotka, schopná řešit havárie nejčastěji převážených
nebezpečných materiálů. V případě , že jednotka není schopna situaci dostupnými prostředky
zvládnout, je třeba po vyhodnocení situace řešit havárii individuálně. Právě vyhodnocování
situace na místě je největší ztráta času, která může mít vážné důsledky. Je proto maximálně
důležité, aby operační střediska tísňových volání byla vybavena databází nebezpečných látek
spolu s kompletním popisem řešení likvidace těchto látek (DOK, viz. výše ).
78
9. Závěry a doporučení
Pro zavádění systému tísňového volíní E-MERGE v ČR je třeba zvážit, zda zvolit
centralizovaný nebo decentralizovaný systém PSAP. V České Republice v současné době
funguje systém decentralizovaný, kdy operační střediska spadají do kompetencí jednotlivých
útvarů HZS a jsou jimi také realizována. Na služebny HZS jsou směrována tísňová volání
linky 112 a ty pak rozhodují o dalším osudu přijaté informace. Směrování hovorů se provádí
na základě územní příslušnosti. Tento stav však není optimální z hlediska obecného pojetí
linky tísňového volání 112. Zásadním problémem je neuniverzálnost operátorů při řešení
výjimečných a ojedinělých situací a nevyzrálá datová komunikace mezi jednotlivými
středisky. Dalším problémem je neexistence sady modelových situací se scénářem řešení.
Tento stav samozřejmě závisí na rozvíjejících se technických možnostech a jejich nasazení
v praxi a v neposlední řadě i na zkušenostech z operačních středisek u nás a v zahraničí.
Následující popis se opírá o myšlenku jediného centrálního operačního střediska pro celou
ČR, na které by byla směrována veškerá tísňová volání na linku 112. Existence jediného
střediska má jednu zásadní výhodu v tom, že není třeba řešit a konzultovat jakékoliv otázky
na vzdálenost větší než v rozsahu jediné budovy (kanceláře…). Další podstatnou výhodou
jsou i relativně nízké provozní náklady na fungování takového střediska ve srovnání
s množstvím samostatných pracovišť rozmístěných po celém území ČR. Pro správné
fungování takového střediska je nezbytný kvalitně vyškolený a vzdělaný personál, a to nejen
po stránce technické, ale i psychologické, protože se předpokládá komunikace s lidmi
v kritických situacích, vyžadujících zvláštní přístup. Centralizací se výrazně sníží počet
zaměstnanců zejména v oblasti managementu, podpůrných služeb, ale také operátorů, čímž se
následně sníží náklady na jejich vzdělávání. Značného zjednodušení se dosáhne v oblasti
vybavení výpočetní a komunikační technikou a zejména jejich správě a údržbě. Údržba,
aktualizace a jednotnost obsáhlých databází, které se v tomto systému předpokládají, by
v případě decentralizovaného rozmístění operačních středisek mohla představovat poměrně
obtížný úkol.
Nicméně, nic není dokonalé a i jediné centrální středisko má, jak už bylo zmíněno výše, jednu
nevýhodu. Touto nevýhodou je zranitelnost. Jakkoliv je možné rizika vyřazení střediska
z provozu minimalizovat (terénní polohou, stavebním řešením, záložními zdroji apod.),
stoprocentní vyloučení havárie možné není. Tuto otázku je možné řešit vybudováním
střediska záložního, které za normálních okolností funguje jako středisko cvičné (školící) a
v případě výpadku hlavního střediska převezme kompletně jeho úlohu. Situace je znázorněna
na obr. 9.1.
79
Mobilní telefon
Pevná linka
PSAP
IZS koordinuje:
Š ko lící
středisko
Z á c hra nné po ho to vo s ní s lužby a s bo ry:
H a siči, zd ra votn ická zá ch ra n n á slu žb a ,
p o h o to vo stn í ko mu n á ln í slu žb y...
Telefonní operátor
B e zpe č no s tní a o zbro je né s bo ry:
- polohové údaje
P o licie Č R , o b e cn í p o licie , Armá d a Č R
Ú ze m ní po př. ú s tře dní s prá vní ú řa dy
PSAP
Obr. 9.1. Zapojení centrálního operačního střediska v IZS
Porovnání existence jediného a vícenásobného operačního střediska tísňového volání:
Jediné centrální středisko
Přehled o všech voláních v jediném centru popř.
z každého pracoviště
Nízký počet speciálně vyškolených zaměstnanců
– operátorů. Nutná universalita – schopnost
vyhodnotit jakýkoliv druh problému + odborníci na
konkrétní oblasti.
Relativně jednoduchá a jednotná správa
informačních technologií. Jednotný systém (HW,
SW) na jednom místě.
Jediná znalostní databáze všech potřebných
údajů. A není jich málo! Snadná údržba a
aktualizace.
Možnost osobní konzultace více
odborníků/operátorů na jednom místě.
Jazyková vybavenost lépe řešitelná v jediném OS.
Jednotné pokrytí celého území ČR.
Snazší koordinace a vzájemná komunikace s
krizovými štáby v případě živelné pohromy.
Jednotné vydávání pokynů. Informační servis.
Menší finanční náročnost díky menšímu počtu
zaměstnanců, jednodušší správě a údržbě a díky
jednotnému managementu.
Současné sledování více probíhajících událostí.
Možnost sdružovat související události –
podrobnější informace.
Snadné vyhotovení statistik a zpráv o uplynulých
zásazích.
Nutná existence aktualizované databáze všech
záchranných složek včetně jejich polohy a dosahu
Více středisek (např. krajských)
Přehled pouze o určité oblasti – přehled o
ostatních regionech realizovatelný (nutné?)
Počet operátorů vzrůstající s počtem středisek.
=>Větší počet odborníků.
Počet IS dán počtem středisek. Složitější a
nákladnější správa a údržba těchto systémů.
Větší možnost problémů při údržbě a aktualizaci
více samostatných databází.
Existují samozřejmě telefony, ale osobní kontakt
je nejlepší.
Možnost přesměrování hovoru na osobu jazyka
znalou.
Problém časové dostupnosti.
Existence hranic mezi OS může přinášet kolize na
rozhraní spádových území. Čím více středisek,
tím je větší souhrnná délka hranic a větší možnost
kolizí.
Každé středisko samostatný management, x –
násobné vybavení => podstatně vyšší náklady.
Riziko duplicitního nebo nekoordinovaného řešení
situace.
Nutný sběr dat jednotlivých středisek a následné
zpracování
Databáze není třeba, protože středisko operuje
s několika jemu příslušnými záchrannými
80
působnosti.
Zranitelnost střediska – vyřazení z provozu
znamená nefunkčnost linky 112. Existence
záložního – např. školícího OS, schopného
v případě poruchy hlavního OS převzít jeho úlohu.
Možnost spolupráce obou středisek v době
enormního nárůstu tísňových volání (povodně
apod.)
Neznalost místních poměrů, vše na bázi
elektronických informací.
jednotkami.
Nesporná výhoda decentralizovaného systému,
kdy při výpadku jednoho OS převezmou jeho
úlohu ostatní.
Působnost na menším území => lepší znalost
místních poměrů. Znalost terénu – podmínky
v zimě, opakující se potíže, osvědčené způsoby
řešení. Jde především o problémy živelného
charakteru
Pilotní projekt E-MEGE bude realizován v ČR v rámci projektu CONNECT, ke kterému
se přihlásil HZS ČR. Tento text provedl základní rozbor procesů, technických požadavků na
systém tísňového volání tak, aby řešení bylo mono využít jak v osobní dopravě, tak i v
dopravě nákladní (tato oblast zatím nebyla v EU řešena).
V rámci tohoto projektu i v rámci zpracovábaného pilotního projektu Informační systém
pro přepravu nebezpečných nákladů (MD 802/210/112) byla navázána oficiální spolupráce s
HZS ČR a jednotlivé kroky řešení jsou s HZS ČR diskutovány.
Navržené řešení reaguje na stávající stav ČR a řeší problém tísňového volání (e-call)
způsobem, který zaručuje vzájemnou propojitelnost (interoperabilitu) s podobnými systémy
zemí EU.
81
10. Použité zkratky
A
Ack (Acknowledge)
ACP (Application Communication Protocol) - aplikační komunikační protokol
ADAS (Advanced Driver Assistance Systém) – zdokonalený asistenční systém pro řidiče
A-GPS (Assisted Global Positioning Systém) - GPS s asistencí sítě GSM
AMPS (Advanced Mobile Phone Systém) – zdokonalený systém mobilní komunikace
ASCII (American Standard Code for Information Interchange) - kód standardizovaný
v Americe určený pro výměnu informací
ASN.1 (Abstract Syntax Notation number One) - je mezinárodní standard který usiluje o
specifikaci dat užitých v komunikačním protokolu.Je to silný a komplexní jazyk, jenž je
navrhnut pro popis komunikace mezi homogenním a heterogenním systémem.
ASTAP (Asia-Pacific Standardisation Program) - Asijsko-Pacifický standardizační program
B
C
CGALIES (Coordination Group on Access to Location Information by Emergency Service) skupina pro koordinaci přístupu pohotovostních jednotek k informacím o poloze
CLI (Customer Line Identification) - identifikace linky zákazníka
CRUD (Create Read Update Delete) - vytvoř, čti, aktualizuj, smaž
CSD (central securities depository) – centrální místo, kde jsou uloženy důvěrné informace
D
DB - databáze
DBMS (Database Management Systém) - databázový management systém
DIS (Draft International Standard) - koncept mezinárodního standardu
DMZ (Demilitarised Zone) - demilitarizovaná zóna
DoS (Denial of Service) - odmítnutí služby
DSRC (Dedicated Short Range Communication) – vyhrazená komunikace na krátkou
vzdálenost
E
E112 – nouzový hovor na číslo 112, včetně nejpřesnějších informací o poloze poskytnutých
telek. operátory
EA (Emergency Authorities) – Pohotovostní jednotky (hasiči, policie, záchranná služba)
EC (European Commission) – Evropská komise
E-call (Emergency call) – nouzový hovor
EMC (Electromagnetic Kompatibility) – elektromagnetická kompatibilita
E-MERGE - jméno evropského projektu standardizace nouzových hovorů
E-OTD (Enhanced Observed Time Difference positioning method) - metoda lokalizace
polohy založená na mobilním telefonu (výpočet zpoždění signálu provádí přímo mobilní
telefon)
ETSI OCG-EMTEL (European Telecommunications Standards Institute Operational
Coordination Group on Emergency Telecommunications) – koordinační skupina institutu
standardizace evropských telekomunikací, věnující se nouzovým telekomunikacím
ETSI EG (ETSI Guide) – průvodce ETSI
ETSI ES (ETSI Standard) – ETSI standard
82
ETSI TS (Technical specification) – ETSI technické specifikace
ETSI TR (Technical report) – ETSI technická zpráva
EU (European Union) – Evropská unie
F
G
GAD (Geographical Area Description) – popis geografické oblasti
GATS (Global Automotive Telematics Standard) – globální automatizační telematický
standard
GMLC (Gateway Mobile Location Centre) – brána lokalizačního centra GSM sítě
GPRS (General Packet Radio Service) – paketový přenos dat v GSM síti
GPS (Global Positioning Systém) – systém určování polohy pomocí družic
GSM (Global System for Mobiles)
GTP (Global Telematics Protocol) – globální telematický protokol
GTSC (Global Telematics Standards Collaboration) – spolupráce globálních telematických
standardů
H
HCC – Domácí centrum obsluhy hovorů, centrum obsluhy hovorů nebo poskytovatel služeb
se kterým řidič podepsal smlouvu
HI (Health Insurance) – zdravotní pojištění
HMI (Human Machine Interface) – rozhraní člověk-stroj
HTTP (HyperText Transfer Protocol) – internetový protokol pro přenos hypertextu
I
ID (Identification) - identifikace
IE (Information Element) – informační prvek
IEEE (Institute of Electrical and Electronics Engineers) – institut elektrického a
elektronického inženýrství
IMEI (International Mobile Equipment Identifier) – mezinárodní identifikátor mobilního
vybavení
IP - Internet-Protokol
IPSec (Internet Protocol Security) – bezpečnost internetového protokolu
IPv4 - IP-Adresa 4 x 16 bit = 64 bit
IPv6 - IP-Adresa 8 x 16 bit = 128 bit
ISDN (Integrated Services Digital Network) – digitální síť integrovaných služeb
ISO (International Organization for Standardisation) – Mezinárodní organizace pro
standardizaci
ITS (Intelligent Transport Systéme) – inteligentní transportní systém
ITU (International Telecommunication Union) – Mezinárodní telekomunikační unie
IVS (In-Vehicle System (on-board unit)) – vozidlová jednotka
J
JDBC (Java Database Connectivity) – Java databázová propojitelnost
K
L
83
LCC – lokální centrum obsluhy hovorů, centrum obsluhy hovorů se který může HCC udělat
dohodu za účelem lepšího pokrytí Evropy
LCS (Location Service) – lokalizační služby
LDAP (Lightweight Directory Access Protocol) – zlehčený adresářový přístupový protokol
LIF (Location Interoperability Forum) – fórum interoperability lokalizace
LMU (Location Measurement Unit) – jednotka vypočítávající polohu
M
min - minimum
MLC (Mobile Location information Centre) – centrum informací o lokalizaci v mobilní síti
MLP (Mobile Location Protocol) – protokol pro lokalizaci v mobilní síti
MSC (Mobile Switching Centre) – přepojovací centrum v mobilní síti
N
NIS+ (Network Information Service Plus) – síťové informační služby +
O
ODBC (Open Database Connectivity) – otevřená databázová propojitelnost
OEM (Original Equipment Manufacturer) – výrobce původního vybavení
OSI (Open System Interconnection) – otevřený systém vzájemného spojení
OTAP (Over The Air Protocol) – tzv. protokol posílaný vzduchem
P
PLMN (Public Land Mobile Network) – veřejná mobilní síť
PSAP (Public Safety Answering Point) – veřejné centum zpracování nouzových hovorů
Q
QoS (Quality of Service) – kvalita služeb
R
RDBMS (Relational Database Management System) – relační databázový management
systém
RFC (Request For Comments) – požadavek na vysvětlení
RSA - technologie enkrypce dat vynalezená RSA Data Security
S
SDO (Standards Developing Organisation) – organizace vyvíjející standardy
SES (Satellite Earth Stations and Systems) – satelitní pozemní stanice a systémy
SIM (subscriber identity module) – účastnický identifikační modul
SMLC (Serving Mobile Location Centre) – obslužné centrum lokalizace v mobilní síti
SMS (Short Message Service) – krátká textová zpráva
SP (Service Provider) – poskytovatel služeb
SO (Support Organization) – podpůrné organizace
SOAP (Simple Object Access Protocol) – protokol přístupu jednoduchých objektů
SPAN (Services and Protocols for Advanced Networks) – služby a protokoly zdokonalených
sítí
SQL (structured query language) – jazyk na programování databází
SW – Software
T
84
TETRA (Terrestrial Trunked Radio) – terestriálně šířené rádiové vlny
TIA (Telecommunications Industry Association) – asociace telekomunikačního průmyslu
TICS (Traffic Information Control Systém) – systém kontroly dopravních informací
TIPHON (Telecommunications and Internet Protocol Harmonisation Over Networks) –
harmonizace telekomunikačního a internetového protokolu v síti
TCP (Transmission Control Protocol) – protokol přenosu informace v internetu
TSAG (Telecommunication Standardisation Advisory Group) – poradní skupina pro
standardizaci v telekomunikacích
U
UK (United Kingdom) – Velká Británie
UMTS (Universal Mobile Telecommunications System) –
telekomunikační systém
UTC (Coordinated Universal Time) – koordinovaný univerzální čas
UTM (Universal Transverse Mercator) V
VIN (Vehicle Identification Numer) – identifikační číslo vozu
VPN (Virtual Private Network) – virtuální privátní síť
W
WCDMA – mobilní síť třetí generace
WG (work group) – pracovní skupina
WGS (World Geodetic Systém) – světový geodetický systém
WLAN (Wireless Local Area Network) – bezdrátové lokální sítě
X
XML (eXtensible Markup Language) – síťový programovací jazyk
85
univerzální
mobilní
11. Literatura
[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]
ISO 4513 Road vehicles — Visibility Method for establishment of ellipse for driver's
eye location
ISO 2575 Road vehicles — Symbols for controls, indicators and tell-tales
ISO 4040 Road vehicles — Location of hand controls, indicators and tell-tales
ISO 3958 Road vehicles — Passenger car driver hand control reach
ISO (DIS) 15005 Road vehicles — Traffic information and control systems (TICS)
dialogue management principles
auditory presentation of information
ergonomic aspects of in-vehicle information presentation
ISO (DIS) 11429 Ergonomics — System danger and non-danger signals with sounds
and lights.
URL : http://www.telematicsforum.com
Telematics Forum – GTP (Global Telematics Protocol) « Requirements » Version 1.0,
22nd October 2002
Telematics Forum – GTP (Global Telematics Protocol) « GTP Application Protocol –
Encoding Specification » Version 1.0, 21st March 2003
URL : http://www.emtel.etsi.org
Hutchison 3G UK Ltd – « LIF MLP Lite 112/999 » Version 1.0, 9th September 2002
ETSI OCG-EMTEL – « EM02td003 – Emergency Communication by Citizens with
Authorities » Version 0.1, 10th January 2003
ETSI OCG-EMTEL - – « EM02td022 - Location of Emergency 122 mobile calls in
Spain » Version 0.1, 15th January 2003
MESA – Statement of requirements
PNO – ISC / SPEC Specification number 013 emergency location
Network Design for 999 GPS
Huitema, C., IPv6: The New Internet Protocol, 2nd ed. Upper Saddle River: Prentice
Hall, Inc., 1998.
Pfleeger, C.P., Security in Computing, 2nd ed. Upper Saddle River: Prentice Hall, Inc.,
1997.
Storebø, G., Virtual Private Networks. (Spring project, Norwegian University of
Science and Technology, 1998).
Masica, K., Securing IP. SunWorld, June 1998. http://www.sunworld.com/swo l-061998/swol-06-ipsec.html
Salomone, S., VPN: The Basics. InternetWeek,
http://www.internetwk.com/VPN/paper.htm
RSA, http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
Krawczyk, H., SKEME: A Versatile Secure Key Exchange Mechanism for Internet,
from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems
Security.
http://www.research.ibm.com/security/skeme.ps
www.sql.org – The portal for SQL
www.xml.org – The portal for XML
http://www.w3c.org/ - The portal for Web services
86

ITS v podmínkách dopravně-telekomunikačního prostředí ČR (802

Transkript

Podobné dokumenty

Ceník telekomunikačních služeb pro členy Stavebního bytového