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

Transkript

1 F AKULTA DOPRAVNÍ Č VUT K ONVIKTSKÁ 20, P RAHA 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

2 Obsah 1. Úvod Základní komponenty systémy tísňového volání Metody určování polohy Architektura systému tísňového volání (e-call) Tísňové volání - mobilní telefon Tísňové volání - mobilní telefon a GSM lokalizace Vozidlová jednotka Infrastruktura systému tísňového volání (e-call) Procesní modely systému tísňového volání Automatické volání - řidič vozidla je schopen mluvit a má smlouvu s poskytovatelem služby Automatické volání - řidič vozidla je schopen mluvit, je nutný překlad a má smlouvu s SP Automatické volání - tichý hovor se smlouvou s provozovatelem služby Automatické volání - řidič je schopen komunikovat a neexistuje smlouva s poskytovatelem služby Automatické volání - řidič není schopen komunikace a neexistuje smlouva se provozovatelem služby Manuální volání - řidič vozidla je schopen komunikace a má smlouvu s poskytovatelem služby Manuální volání - řidič je schopen komunikace, je třeba překlad a má smlouvou s poskytovatelem služby Manuální E-call - tichý hovor, existuje smlouva s poskytovatelem služby Manuální E-call volá očitý nebo náhodný svědek Manuální volání - řidič je schopen komunikovat, neexistuje smlouva s poskytovatelem služby Manuální volání - tichý hovor, neexistuje smlouva s poskytovatelem služby Chybná funkce jednotky vedoucí k falešným hovorům Specifikace systému E-MERGE Specifikace dat generovaných vozidlovou jednotkou (minimálních dat) Specifikace úplných dat Specifikace komunikace Požadavky na E-MERGE systém Požadavky na vozidlovou jednotku Požadavky na PSAP Zabezpečení sítě Požadavky na ukládání dat Doporučení pro poskytovatele služeb Úvod Procesy HCC Technické požadavky Přidaná data od HCC k PSAP Systémové parametry SP Systém tísňového volání v nákladní dopravě Průběh záchranné akce v případě havárie Postup zpracování informace v PSAP Využití E-call při zabezpečení přepravy nebezpečných nákladů Stávající stav v ČR Složky IZS

3 8.2. Operační střediska Zkušenost s operačním střediskem v Ostravě Závěry a doporučení Použité zkratky Literatura

4 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

5 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: Švédsko Německo Špenělsko Itálie V. Británie Poskytovatel služeb / PSAP: Výrobce automobilů: Poskytovatel služeb: Výrobce automobilů: Poskytovatel služeb: Výrobce automobilů: Veřejná autorita: Výrobce automobilů: Veřejná autorita: PSAP: Poskytovatel služeb: Nouzový Operátor: SOS Alarm VOLVO OnStar / GDV GM (OPEL) RACC SEAT City of Milano FIAT DTLR BT Operations The AA ACPO Francie Výrobce automobilů: Renault 5

6 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. E- MERGE 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

7 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

8 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

9 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

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

11 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

12 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 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) Tísňové volání - mobilní telefon a GSM lokalizace 12

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

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

15 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

16 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ě 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

17 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

18 Pořadí událostí 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 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). 7 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 8 volání (PSAP) vytvoření konferenčního hovoru s řidičem přes bezplatnou linku. 9 Jestliže řidič podepsal smlouvu s poskytovatelem služeb (SP), Centrum tísňového volání 18

19 (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 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

20 2 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 3 (CLI) 4 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

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

22 Pořadí událostí Pořadí události 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. 5 PSAP odpovídá na hlasový hovor. 6 PSAP komunikuje s řidičem. 7 PSAP obdrží data o poloze z lokační databáze telek. operátora. 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody. 10 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 11 Telekomunikační operátor odešle potvrzení o přijetí vozidlu. 12 Úplná data jsou přesměrována k SP včetně identifikačních CLI dat 13 Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí úplných dat SP. 14 SP odešle přidaná data do své E-MERGE databáze. 15 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. 16 PSAP jsou posílána data z E-MERGE databáze. 17 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 18 pohotovostní jednotkou (EA - Emergency Authority). Konferenční hovor je navázán na bezplatné lince poskytovatele služeb (SP). 19 PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní jednotku (EA) pro pozdější odeslání potvrzení. 20 PSAP ukončí hlasový hovor. 21 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 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

23 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 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 Pořadí událostí Pořadí události 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. 5 PSAP odpovídá na hlasový hovor. 6 PSAP nerozumí řidiče a je třeba překlad. 7 PSAP obdrží data o poloze z lokační databáze od telekomunikačního operátora. 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody. 10 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 11 Telekomunikační operátor odešle potvrzení o přijetí dat vozidlu. 12 Úplná data jsou přesměrována k SP včetně identifikačních CLI dat. 13 Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí úplných dat provozovatelem služby SP. 14 SP odešle přidaná data do své E-MERGE databáze. 15 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. 16 PSAP jsou posílána data z E-MERGE databáze. 17 PSAP dokončil stahování dat z E-MERGE databáze. 18 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. 19 PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní službu EA pro pozdější odeslání potvrzení. 20 PSAP ukončí hlasový hovor. 21 Vozidlová jednotka OBU ukončí nouzovou sekvenci Automatické volání - tichý hovor se smlouvou s provozovatelem služby 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

24 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 Pořadí událostí Pořadí události 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. 5 PSAP odpovídá na hlasový hovor. 6 PSAP neslyší řidiče (tichý hovor). 7 PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody. 10 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 11 Telekomunikační operátor odešle potvrzení o přijetí dat zpět vozidlu. 12 Úplná data jsou přesměrována k SP včetně identifikačních CLI dat. 13 Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí úplných dat SP. 14 SP odešle přidaná data do své E-MERGE databáze. 15 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. 16 PSAP jsou posílána data z E-MERGE databáze. 17 PSAP má všechna data z E-MERGE databáze. 18 PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní skožku EA pro pozdější odeslání potvrzení. 19 PSAP ukončí hlasový hovor. 20 Vozidlová jednotka ukončí nouzovou sekvenci Automatické volání - řidič je schopen komunikovat a neexistuje smlouva s poskytovatelem služby 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 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

25 Pořadí událostí Pořadí události 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. 5 PSAP odpovídá na hlasový hovor. 6 PSAP komunikuje s řidičem. 7 PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody. 10 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. 11 PSAP ukončí hlasový hovor. 12 Vozidlová jednotka ukončí nouzovou sekvenci Automatické volání - řidič není schopen komunikace a neexistuje smlouva se provozovatelem služby 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 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 Pořadí událostí Pořadí události 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. 5 PSAP odpovídá na hlasový hovor. 6 PSAP nesliší řidiče (tichý hovor). 25

26 7 PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. 8 PSAP zobrazí minimální data. PSAP vyšle pomoc na místo nehody jen na základě minimálních dat. PSAP nebo 9 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, 10 že uživatel namá placeny služby E-MERGE) a tak nejsou dostupná přidaná data. 11 PSAP ukončí hlasový hovor. 12 Vozidlová jednotka ukončí nouzovou sekvenci Manuální volání - řidič vozidla je schopen komunikace a má smlouvu s poskytovatelem služby 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 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 Pořadí událostí Pořadí Popis události události 1 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 2 operátorovi k PSAP. Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a 3 komunikaci). Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních 4 dat PSAP. 5 PSAP odpovídá na hlasový hovor. 6 PSAP komunikuje s řidičem. 7 PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody. 10 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 11 Telekomunikační operátor odešle potvrzení o přijetí dat vozidlu. 12 Úplná data jsou přesměrována k SP včetně identifikačních CLI dat. 13 Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí úplných dat 26

27 SP. 14 SP odešle přidaná data do své E-MERGE databáze. 15 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. 16 PSAP jsou posílána data z E-MERGE databáze. 17 PSAP má všechna data z E-MERGE databáze. 18 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. 19 PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní složku EA pro pozdější odeslání potvrzení. 20 PSAP ukončí hlasový hovor. 21 Vozidlová jednotka ukončí nouzovou sekvenci Manuální volání - řidič je schopen komunikace, je třeba překlad a má smlouvou s poskytovatelem služby 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 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 Pořadí událostí Pořadí Popis události události 1 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 2 operátorovi k PSAP. Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a 3 komunikaci). Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních 4 dat PSAP. 5 PSAP odpovídá na hlasový hovor 6 PSAP nerozumí řidiči a je třeba překlad. 7 PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody. 10 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 11 Telekomunikační operátor odešle potvrzení o přijetí dat vozidlu. 12 Ú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 13 SP. 27

28 14 SP odešle přidaná data do své E-MERGE databáze. 15 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. 16 PSAP jsou posílána data z E-MERGE databáze. 17 PSAP dokončil stahování dat z E-MERGE databáze. 18 PSAP naváže konferenční hovor s vozidlem, SP a pohotovostní jednotkou EA. Konferenční hovor je navázán na bezplatné lince SP. 19 PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní jednotky EA pro pozdější odeslání potvrzení. 20 PSAP ukončí hlasový hovor. 21 Vozidlová jednotka ukončí nouzovou sekvenci Manuální E-call - tichý hovor, existuje smlouva s poskytovatelem služby 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 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 Pořadí událostí Pořadí Popis události události 1 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 2 operátorovi k PSAP. Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a 3 komunikaci). Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních 4 dat PSAP. 5 PSAP odpovídá na hlasový hovor. 6 PSAP neslyší řidiče (tichý hovor). 7 PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody. 10 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 11 Telekomunikační operátor odešle potvrzení o přijetí dat vozidlu. 12 Ú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 13 SP. 14 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 15 Sp-ID číslo nebo IP adresa 28

29 16 PSAP jsou posílána data z E-MERGE databáze. 17 PSAP dokončil stahování dat z E-MERGE databáze. 18 PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní složky EA pro pozdější odeslání potvrzení. 19 PSAP ukončí hlasový hovor. 20 Vozidlová jednotka ukončí nouzovou sekvenci 3.9. Manuální E-call volá očitý nebo náhodný svědek 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 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 Pořadí událostí Pořadí Popis události události 1 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 2 operátorovi k PSAP. Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a 3 komunikaci). Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních 4 dat PSAP. 5 PSAP odpovídá na hlasový hovor. 6 PSAP komunikuje s řidičem. 7 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 8 vyslán. 9 PSAP vyšle pomoc na místo nehody. 10 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 11 Telekomunikační operátor odešle potvrzení o přijetí dat vozidlu. 12 Úplná data jsou přesměrována k SP včetně identifikačních CLI dat 13 Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí úplných dat SP. 14 SP odešle přidaná data do své E-MERGE databáze. 15 PSAP dokončil stahování dat z E-MERGE databáze. 16 PSAP kontaktuje E-MERGE databázi pro odeslání informací a pohotovostní složku EA pro pozdější odeslání potvrzení. 29

30 3.10. Manuální volání - řidič je schopen komunikovat, neexistuje smlouva s poskytovatelem služby 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 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 Pořadí událostí Pořadí Popis události události 1 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 2 operátorovi k PSAP. Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a 3 komunikaci). Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních 4 dat PSAP. 5 PSAP odpovídá na hlasový hovor. 6 PSAP komunikuje s řidičem 7 PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody. Identifikační číslo provozovatele služby SP-ID není zapsáno v minimálních datech 10 (identifikace, že uživatel namá placeny služby E-MERGE) a tudíž nejsou dostupná přidaná data 11 PSAP ukončí hlasový hovor. 12 Vozidlová jednotka ukončí nouzovou sekvenci Manuální volání - tichý hovor, neexistuje smlouva s poskytovatelem služby 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

31 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 Pořadí událostí Pořadí Popis události události 1 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 2 operátorovi k PSAP. Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a 3 komunikaci). Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních 4 dat PSAP. 5 PSAP odpovídá na hlasový hovor. 6 PSAP nesliší řidiče (tichý hovor). 7 PSAP obdrží data o poloze z lokační databáze telekomunikačního operátora. 8 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. 11 PSAP ukončí hlasový hovor. 12 Vozidlová jednotka ukončí nouzovou sekvenci Chybná funkce jednotky vedoucí k falešným hovorům 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 Zahájení procesu Kritické senzory vytvoří falešnou aktivaci, což má za následek, že vozidlová jednotka začne vysílat automatickou nouzovou sekvenci Pořadí událostí hlasové spojení Pořadí Popis události události 1 Kritické senzory vytvoří falešnou aktivaci, což má za následek, že vozidlová jednotka 31

32 vyšle nouzovou sekvenci. E-MERGE minimální data jsou poslána v hlasovém kanálu po telekomunikačním 2 operátorovi k PSAP. Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a 3 komunikaci). Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí inimálních 4 dat PSAP. 5 PSAP odpovídá na hlasový hovor. 6 PSAP komunikuje s řidičem. Nedošlo k nehodě a tak PSAP ukončí hlasový hovor. PSAP obdrží data o poloze 7 z lokační databáze telekomunikačního operátora. 8 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 9 Telekomunikační operátor odešle potvrzení o přijetí dat vozidlu. 10 Ú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 11 SP. 12 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é 13 funkci zařízení, aby zabránil jeho falešnému hovoru Pořadí událostí bez hlasového spojení Pořadí Popis události události 1 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 2 operátorovi k PSAP. Je vytvořena hlasová komunikace mezi vozidlem a PSAP (záleží na GSM modulu a 3 komunikaci). Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí minimálních 4 dat PSAP. 5 PSAP nemůže přijmout hlasový hovor. 6 PSAP nemůže komunikovat s řidičem. 7 PSAP zjišťuje data o poloze spolu s hlasovou komunikací. 8 PSAP zobrazí minimální data. 9 PSAP vyšle pomoc na místo nehody, ale nejsou splněny předpoklady pro nouzovou situaci. 10 E-MERGE úplná data jsou poslána telekomunikačnímu operátorovi. 11 Telekomunikační operátor odešle potvrzení o přijetí dat vozidlu. 12 Úplná data jsou přesměrována k SP včetně identifikačních CLI dat. 13 Vozidlu je odesláno (po telekomunikačním operátorovi) potvrzení o přijetí úplných dat SP. 14 SP odešle přidaná data do své E-MERGE databáze. 15 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. 16 PSAP jsou posílána data z E-MERGE databáze. 17 PSAP dokončil stahování dat z E-MERGE databáze. 18 PSAP kontaktuje pohotovostní složku EA pro pozdější odeslání potvrzení, ale nejsou splněny předpoklady pro nouzovou situaci 19 PSAP ukončí hlasový hovor 20 Informuje SP o chybné funkci zařízení 32

33 4. Specifikace systému E-MERGE 4.1. Specifikace dat generovaných vozidlovou jednotkou (minimálních dat) Ú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 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 ( ) 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 ) Č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: :45.21 Verze 1.0 ( až ) Lokalizace (užívá PSAP) Popis: Podle (GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 (22.10, 22.11, a 22.19) 33

34 Užití: Definuje polohu vozidla podle WGS84. Příklad: N E (Dříve 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 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 ( až ) a) Rok výroby (užívá PSAP) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 ( ) Užití: Definuje rok výroby typu vozidla, jsou pro to určeny 2 digity. Přiklad: verze 1.0 ( ) b) Barva vozidla (užívá PSAP) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 ( ) Užití: Definuje barvu vozidla Příklad: Verze 1.0 ( ) c) Typ vozidla (užívá PSAP) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21 březen 2003,Verze 1.0 ( ) Užití: Definuje výrobce a typ vozidla Příklad: Verze 1.0 ( ) 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

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

36 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 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) 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 Specifikace úplných dat Ú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 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

37 Užití: Definuje aktuální podskupinu případu užití Příklad: Verze 1.0 ( ) 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 ) Č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: :45.21 Verze 1.0 ( až ) Lokalizace Popis: Podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 (22.10, 22.11, a 22.19) Užití: Definuje polohu vozidla podle WGS84. Příklad: N E (Dříve 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 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 ( až ) a) Rok výroby (užívá PSAP) Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 ( ) Užití: Definuje rok výroby typu vozidla, jsou pro to určeny 2 digity. Přiklad: verze 1.0 ( ) b) VIN Popis: Číslo mezinárodní identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 ( ) Užití: Definuje všechna data od výrobce Příklad: verze 1.0 ( ) c) Sériové číslo terminálu 37

38 Popis: Parametry identifikace terminálu podle(gtp), Kódovací specifikace, 21. březen 2003,Verze 1.0 ( ) Užití: Definuje sériové číslo terminálu pro IVS Příklad: verze 1.0 ( ) 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 ( ) Užití: Definuje licenční štítek havarovaného vozidla Příklad: verze 1.0 ( ) e) Barva vozidla Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 ( ) Užití: Definuje barvu vozidla Příklad: Verze 1.0 ( ) f) Typ vozidla Popis: parametry identifikace vozidla podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 ( ) Užití: Definuje výrobce a typ vozidla Příklad: Verze 1.0 ( ) g) IMEI Popis: Identifikační parametry a číslo GSM zařízení podle (GTP), Kódovací specifikace, 21. březen 2003,Verze 1.0 ( ) Užití: Definuje GSM zařízení dostupné pro IVS. Příklad: verze 1.0 ( ) 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 aktivátory a 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

39 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 ( ) 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 ( ) Užití: Tabulka 75- Data o intenzitě srážky Oktet \ bit Příklad: Verze 1.0 ( ) 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) GPS poloha 2) Směr pohybu 3) Počet aktivačních prvků 4) Barva, Výrobce, Typ vozidla 39

40 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 Standard úplných dat Specifikovaná data jsou úplná data, která jsou poslána z vozidla, aby bylo vyhověno E- MERGE 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 Ú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 Ú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

41 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 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 Služby Mobilní síť Vozidlová jednotka Vozidlo Individual. (např.xml) Individual. (např.xml) 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

42 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

43 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

44 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

45 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ě 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 ITUTQ 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 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 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

46 5. Požadavky na E-MERGE systém 5.1. Požadavky na vozidlovou jednotku Úvod Tato část dokumentu popisuje požadavky na návrh a vývoj vozidlové jednotky 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

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

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

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

50 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ě 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

51 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

52 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

53 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í Požadavky na PSAP Ú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 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

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

55 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: Časová známka je ve formátu 14 bitové sekvence znaků: RRRRMMDDHHMMSS Example 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

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

57 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ě Ú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í E- MERGE síť měla podporovat 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

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

59 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

60 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 E- MERGE 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

61 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 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 E- MERGE sítě 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í Požadavky na ukládání dat Ú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 E- MERGE 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

62 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 E- MERGE úč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

63 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

64 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 E- MERGE systému Procesy HCC 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

65 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 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ě 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 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 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

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

67 Č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