F AKULTA DOPRAVNÍ Č VUT K ONVIKTSKÁ 20, P RAHA 1

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 poskytovatelem služby ......................................................................................................... 27 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 poskytovatelem služby ......................................................................................................... 30 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.

3.2.2. Zahájení procesu 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.

3.2.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 Nouzová sekvence 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 od PSAP. PSAP odpovídá na hlasový hovor. 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. 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í 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. SP odešle přidaná data do své E-MERGE databáze. 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 jsou posílána data z E-MERGE databáze. PSAP dokončil stahování dat z E-MERGE databáze. 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 pro pozdější odeslání potvrzení. PSAP ukončí hlasový hovor. 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

3.3.2. Zahájení procesu 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.

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

Popis události Nouzová sekvence 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 PSAP. PSAP odpovídá na hlasový hovor. PSAP neslyší řidiče (tichý hovor). PSAP obdrží data o poloze z lokační databáze telekomunikačního 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í dat zpět 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 číslo nebo SP-ID číslo nebo IP adresa. PSAP jsou posílána data z E-MERGE databáze. 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 pro pozdější odeslání potvrzení. PSAP ukončí hlasový hovor. 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.

3.4.2. Zahájení procesu 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

3.4.3. Pořadí událostí Pořadí události 1 2 3 4 5 6 7 8 9 10 11 12

Popis události Nouzová sekvence 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 PSAP. PSAP odpovídá na hlasový hovor. PSAP komunikuje s řidičem. PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. PSAP zobrazí minimální data. PSAP vyšle pomoc na místo nehody. 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. PSAP ukončí hlasový hovor. Vozidlová jednotka ukončí nouzovou sekvenci.

3.5. Automatické volání - řidič není schopen komunikace a neexistuje smlouva se provozovatelem služby 3.5.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. Řidič nemá podepsanou smlouvu se SP a nemůže tudíž využít výhody přidaných dat pro PSAP a jazykové podpory.

3.5.2. Zahájení procesu 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.

3.5.3. Pořadí událostí Pořadí události 1 2 3 4 5 6

Popis události Nouzová sekvence 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 PSAP. PSAP odpovídá na hlasový hovor. PSAP nesliší řidiče (tichý hovor).

25

7 8 9 10 11 12

PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. PSAP zobrazí minimální data. 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. PSAP ukončí hlasový hovor. Vozidlová jednotka ukončí nouzovou sekvenci.

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.

3.6.2. Zahájení procesu Řidič vozidla manuálně zmáčkne SOS tlačítko, což má za následek, že vozidlová jednotka vyšle automatickou nouzovou sekvenci.

3.6.3. Pořadí událostí 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. 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 PSAP. PSAP odpovídá na hlasový hovor. PSAP komunikuje s řidičem. PSAP obdrží data o poloze z lokační databáze telekomunikačního 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í 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

26

14 15 16 17 18 19 20 21

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 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 pro pozdější odeslání potvrzení. PSAP ukončí hlasový hovor. Vozidlová jednotka ukončí nouzovou sekvenci.

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.

3.7.2. Zahájení procesu Řidič vozidla manuálně zmáčkne SOS tlačítko, což má za následek, že vozidlová jednotka začne vysílat automatickou nouzovou sekvenci.

3.7.3. Pořadí událostí 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. 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 PSAP. PSAP odpovídá na hlasový hovor PSAP nerozumí řidiči a je třeba překlad. PSAP obdrží data o poloze z lokační databáze telekomunikačního 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í 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 SP.

27

14 15 16 17 18 19 20 21

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 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í. PSAP ukončí hlasový hovor. Vozidlová jednotka ukončí nouzovou sekvenci.

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.


3.8.3. Pořadí událostí Pořadí události 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Popis události Nouzová sekvence je spuštěna manuálně stlačením SOS tlačítka. 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 PSAP. PSAP odpovídá na hlasový hovor. PSAP neslyší řidiče (tichý hovor). PSAP obdrží data o poloze z lokační databáze telekomunikačního 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í 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 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 jsou posílána data z E-MERGE databáze. PSAP dokončil stahování dat z E-MERGE databáze. PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní složky EA pro pozdější odeslání potvrzení. PSAP ukončí hlasový hovor. 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.

3.9.2. Zahájení procesu Ř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 začne vysílat automatickou nouzovou sekvenci.

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

Popis události Nouzová sekvence je spuštěna manuálně stlačením SOS tlačítka. 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 PSAP. PSAP odpovídá na hlasový hovor. PSAP komunikuje s řidičem. PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. PSAP zobrazí minimální data se zvláštním zaměřením na to, z jakého místa byl hovor vyslán. 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í 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 SP. SP odešle přidaná data do své E-MERGE databáze. PSAP dokončil stahování dat z E-MERGE databáze. PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní složku EA pro pozdější odeslání potvrzení.

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.



Popis události Nouzová sekvence je spuštěna manuálně stlačením SOS tlačítka. 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 PSAP. PSAP odpovídá na hlasový hovor. PSAP komunikuje s řidičem PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora PSAP zobrazí minimální data. PSAP vyšle pomoc na místo nehody. 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 PSAP ukončí hlasový hovor. Vozidlová jednotka ukončí nouzovou sekvenci.

3.11. Manuální volání - tichý hovor, neexistuje smlouva s poskytovatelem služby 3.11.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. Řidič nemá podepsanou smlouvu se SP a nemůže tudíž využít výhody přidaných dat pro PSAP a jazykové podpory.

30



Popis události Nouzová sekvence je spuštěna manuálně stlačením SOS tlačítka. 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 PSAP. PSAP odpovídá na hlasový hovor. PSAP nesliší řidiče (tichý hovor). PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. PSAP zobrazí minimální data. 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. PSAP ukončí hlasový hovor. Vozidlová jednotka ukončí nouzovou sekvenci.

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.

3.12.2. Zahájení procesu Kritické senzory vytvoří falešnou aktivaci, což má za následek, že vozidlová jednotka začne vysílat automatickou nouzovou sekvenci.

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. 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í inimálních dat PSAP. PSAP odpovídá na hlasový hovor. PSAP komunikuje s řidičem. 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. E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 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 SP. SP odešle přidaná data do své E-MERGE databáze. 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. 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 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 zobrazí minimální data. PSAP vyšle pomoc na místo nehody, ale nejsou splněny předpoklady pro nouzovou situaci. E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 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 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 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 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 (užívá PSAP) 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 (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) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen 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) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen 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) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 (22.20.7) Užití: Definuje výrobce a typ vozidla Příklad: Verze 1.0 (22.20.7) 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) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen 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) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen 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.) Příklad: 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.) Příklad: 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) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 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 Příklad: verze 1.0 (22.20.4) 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 Příklad: verze 1.0 (22.20.5) e) Barva vozidla Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 (22.20.6) Užití: Definuje barvu vozidla Příklad: Verze 1.0 (22.20.6) f) Typ vozidla Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 (22.20.7) Užití: Definuje výrobce a typ vozidla Příklad: Verze 1.0 (22.20.7) 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. Příklad: verze 1.0 (22.20.8) 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) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 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

Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 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.) Příklad: 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.) Příklad: 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íť

Individual. (např.XML)

Vozidlová jednotka

Vozidlo

Sběrnice vozidla

GTP Individual. (např.XML)

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 ISO (DIS) 15006 Road vehicles — Traffic information and control systems (TICS) auditory presentation of information ISO (DIS) 15008 Road vehicles — Traffic information and control systems (TICS) 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

F AKULTA DOPRAVNÍ Č VUT K ONVIKTSKÁ 20, P RAHA 1

Recommend Documents