prEN 15722
EVROPSKÁ NORMA EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
prEN 15722 říjen 2008
Inteligentní dopravní systémy - eSafety – Minimální soubor dat pro eCall Intelligent transport systems - eSafety - eCall minimum set of data Systèmes de transport intelligente – ESafety – Strassenverkehrstelematik – E-Safety – Minimaler ECall ensemble minimum de données (MSD) Datensatz für den elektronischen Notruf
Typ dokumentu: evropská norma Subtyp dokumentu: Stádium dokumentu: ST 40 (CEN Enquiry) Jazyk dokumentu: Angličtina D:\Standards\Standards-working docs\15722 eCall MSD\EN_15722_(E) DRAFT EN 081020.doc STD Version 2.1c2 1
prEN 15722
Obsah Strana Úvod ........................................................................................................................................................................ 4 1
Předmět normy ............................................................................................................................................... 5
2
Shoda ............................................................................................................................................................. 5
3
Citované normativní dokumenty...................................................................................................................... 5
4
Termíny a definice .......................................................................................................................................... 5
5
Značky a zkratky ............................................................................................................................................. 6
6
Požadavky na proces...................................................................................................................................... 7
6.1
Koncepty a formáty ......................................................................................................................................... 7
6.1.1 Datové koncepty MSD .................................................................................................................................... 7 6.1.2 Definice formátu datových konceptů MSD ...................................................................................................... 7 6.1.3 Sekvence datových konceptů MSD ................................................................................................................ 7 6.1.4 Prezentace dat MSD....................................................................................................................................... 7 6.2
Minimální soubor dat (MSD) ........................................................................................................................... 7
6.2.1 Pořadí bitů a bajtů........................................................................................................................................... 7 6.2.2 Obsah MSD .................................................................................................................................................... 8 6.2.3 Obsah MSD (text stejný jako 6.2.2) ................................................................................................................ 8 6.2.4 Potvrzení (acknowledgement) MSD a pořadavek ......................................................................................... 12 Příloha A (normativní) Reprezentace MSD v ASN.1 PER ..................................................................................... 14 Příloha B (normativní) Vysvětlená reprezentace dat ASN.1 v PER a BER............................................................ 17 B.1
Úvod do ASN.1 pravidel zhuštěného kódování (PER) .................................................................................. 17
B.2
Základní pravidla kódování (BER) ................................................................................................................ 17
B.3
Pravidla zhuštěného kódování (PER) ........................................................................................................... 18
2
prEN 15722
Předmluva Tento návrh evropské normy připravila Technická komise CEN/TC 278 „Dopravní telematika“, jejíž sekretariát zajišťuje NEN. Tento návrh je v současné době předkládán k připomínkování CEN.
3
prEN 15722
Úvod Počty úmrtí a zranění na silnicích po celém světě vedou k pochopení potřeby „tísňového volání” (eCall). V roce 2005 došlo k 41,600 úmrtím a více než 1.7 milionu zraněním. Silnice zůstávají nebezpečné a jsou proto potřeba jistá opatření. Potenciál panevropského tísňového volání ve vozidle, eCall, je odhadován na záchranu až 2.500 smrtelných zranění ročně v pětadvacítce EU (EU-25) při jeho plném zavedení a navíc sníží závažnost zranění, přinese významné úspory celé společnosti ve zdravotní péči a jiných nákladech a sníží lidské utrpení. Tísňová volání z vozidel nebo mobilních telefonů pomocí bezdrátových technologií mohou posloužit cílům významně snížit počty úmrtí a zranění na silnicích, ale řidiči mají často velmi malé (nepřesné) povědomí o lokální dopravní situaci, zejména na meziměstských komunikacích nebo v cizině. Navíc v mnoha situacích není běžný mobilní telefon dostupný nebo cestující ve vozidle nejsou schopni telefonovat. Situace je ještě horší pro ty, kteří cestují přes hranice. Například v EU je zaznamenáno přes 100 milionů jízd do jiné členské země ročně v evropské patnáctce (EU-15). Z toho 65 % lidí se cítí méně ochráněni, když cestují v cizině, a většina z nich nezná číslo, na které by volali v případě tísně (v některých zemích i více než 60%). Problémy s jazykovým vybavením jsou stálé a neumožňují potřebnou úroveň komunikace. Navíc ve vážných případech nejsou oběti schopné telefonovat, protože jsou vážně zraněni nebo uvězněni, neznají místní tísňovou linku a v mnoha případech, zejména v odlehlých místech a pozdě v noci, nebývají na místě žádní svědci, kteří by měli mobilní telefon a smysl pro občanskou povinnost. eCall, v kontextu dopravní telematiky (jinak také nazývané „inteligentní dopravní systémy“ nebo zkratkou „ITS") mohou být popsány jako „uživatelsky podnícené nebo automatické systémy pro poskytnutí oznámení do Center tísňového volání (public safety answering points), pomocí bezdrátové komunikace, že vozidlo havarovalo, a k poskytnutí souřadnic nehody a definování minimálního souboru přenášených dat". Tato norma definuje „Minimální soubor dat" MSD, které se takovým systémem eCall ve vozidle přenesou v případě nehody nebo nouze. POZNÁMKA
Komunikační médium a prostředky přenosu eCall MSD nejsou definovány v této normě.
4
prEN 15722
1 Předmět normy Tato evropská norma definuje standardní datové koncepty, které zahrnují „minimální soubor dat“, který se přenese z vozidla do Centra tísňového volání ('Public Safety Answering Point' (PSAP)) v případě nehody nebo nouze v rámci komunikační relace 'eCall'. POZNÁMKA 1 Protokoly a metody komunikačního média pro přenos zprávy eCall nejsou v této normě stanoveny. (are not within the scope) POZNÁMKA 2 Dodatečné datové koncepty lze také přenést a jakékoliv takové datové koncepty by se měly zaregistrovat pomocí datového registru definovaného v ISO 24978. (Intelligent transport systems, Emergency and safety messages, Data registry)
2
Shoda
Pro dosažení shody s touto normou (Technical Specification), musí být komunikace ustavena pomocí schválených norem na bezdrátovou komunikaci a musí být takové, aby demonstrovaly, že minimální soubor dat (MSD) přenášený spolu s jakýmikoliv standardizovanými nepovinnými datovými prvky definovanými v daných normách splňují požadavky ustanovení této normy do takové míry, že taková data jsou dostupná z konkrétního vozidla.
3 Citované normativní dokumenty Pro používání tohoto dokumentu jsou nezbytné dále uvedené referenční dokumenty. U datovaných odkazů platí pouze citovaná vydání. U nedatovaných odkazů platí poslední vydání referenčního dokumentu (včetně změn). [Ref1]: ISO 24978 Intelligent transport systems. Wireless communications, Emergency and safety messages data registry (in ballot process)
(Inteligentní dopravní systémy – Bezdrátové komunikace – Datový registr tísňových volání) [Ref2]: ISO 6709 Standard representation of geographic point location by coordinates (Standardní reprezentace geografických poloh pomocí souřadnic) [Ref3]: ISO/IEC/ITU IS/Rec 8824-1/ X.680/8824-1:2002 Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation Published 2002. Cor 1 2006
(Informační technologie – Abstraktní syntaktická notace jedna (ASN.1): Specifikace základní notace) [Ref4]: ISO/IEC/ITU IS/Rec 8824-2 /X.681:2002 Information technology – Abstract Syntax Notation One (ASN.1): Information object specification Published 2002. Amd1 2004
(Informační technologie – Abstraktní syntaktická notace jedna (ASN.1): Specifikace informačního objektu) [Ref5]: ISO/IEC/ITU IS/Rec 8825-1/X.690 (2002) Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Published 2002. Amd 1 2004 JTC1/SC6ISO/IEC 8824-1
(Informační technologie – Kódovací pravidla pro ASN.1: Specifikace základních kódovacích pravidel (BER), kanonických kódovacích pravidel (CER) a rozlišovacích kódovacích pravidel (DER)) [Ref6]: ISO/IEC/ITU IS/Rec 8825-2/X.691 (2002) Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) Published 2002.Amd 1 2004. Cor 1 2006. Amd 2 2007. Cor 2 2006
(Informační technologie – Kódovací pravidla pro ASN.1: Specifikace zhuštěného kódování (PER)) [Ref7]: EN xxxxxxx "Pan European eCall- Operating requirements"1(under development)
(Inteligentní dopravní systémy - Panevropský eCall – Provozní požadavky) [Ref8]: EN xxxxxxx "Third party support for eCall- Operating requirements"1(under development)
(Inteligentní dopravní systémy - Podpora eCall třetí stranou – Provozní požadavky)
4
Termíny a definice
Pro účely této normy platí tyto termíny a definice: 4.1 tísňové volání; eCall (eCall) automatický nebo uživatelem spuštěný systém k odeslání oznámení a příslušných souřadnic nehody Centru tísňového volání pomocí celulárních bezdrátových sítí, nesoucí definovaný minimální soubor dat 5
prEN 15722
(defined "Minimum Set of Data" Standardised data) o tom, že se stala nehoda, která vyžaduje odpověď od záchranných složek a naváže kdekoliv je to možné hlasovou komunikaci do vozidla
5 Značky a zkratky 5.1 3G Třetí generace systému mobilní celulární sítě definované normami 3GPP 5.2 3GPP Třetí generace partnerského protokolu 5.3 BCD kódování dekadických čísel 5.4 BER Základní kódovací pravidla (ASN.1) 5.5 CNG Stlačený přírodní plyn 5.6 ETSI Evropský výbor pro normalizaci telekomunikací 5.7 EC Evropská Komise 5.8 EU Evropská Unie 5.9 EU-27 27 zemí, které tvořily Evropskou Unii od roku 2007. 5.10 GSM Globální systém pro mobilní komunikaci 5.11 GNSS Globální navigační satelitní systém 5.12 ID Identita 5.13 IP Internetový protokol 5.14 LPG Zkapalněný propan 5.15 M Povinné 5.16 MSD Minimální soubor dat 6
prEN 15722
5.17 O Nepovinné 5.18 PER Pravidla zhuštěného kódování 5.19 PSAP Centrum tísňového volání
6
Požadavky na proces
POZNÁMKA Minimální soubor dat je důležitou informací při poskytování nejvhodnějších služeb pro místa nehod a nouze a k urychlení reakce (záchranné akce). Minimální soubor dat umožňuje operátorovi PSAP, aby odpověděl na eCall dokonce i bez hlasového spojení.
6.1 6.1.1
Koncepty a formáty Datové koncepty MSD
Minimální soubor dat musí být přímou, včasnou zprávou pro operátora PSAP, který tísňové volání přijímá. 6.1.2
Definice formátu datových konceptů MSD
Definice uváděné v této normě jsou umístěny níže v sémantické podobě. Podoba dat musí být podle 6.1.4. Záznamy odkazující na „Polohu Bajtu“ v níže uvedených tabulkách jsou tudíž pouze orientační a jsou uvedeny pouze pro snazší pochopení sémantické reprezentace. Reálná poloha prvku v datovém toku je definována definicí ASN1 v příloze A. POZNÁMKA Informační prvky v minimálním souboru dat byly vybrány na základě jejich relevance při záchranné akci.
6.1.3
Sekvence datových konceptů MSD
Sekvence prezentace dat musí být podle 6.2, prezentovaná podle 6.1.4. 6.1.4
Prezentace dat MSD
MSD se musí přenášet pomocí jednoho nebo více komunikačních médií, jak je definováno v [Ref7], která definuje jedno nebo více bezdrátových standardů rozhraní vhodných pro přenos eCall, a musí být prezentováno v abstraktní syntaktickém zápisu, ASN.1 Packed encoding rules (PER unaligned), jak je definováno ISO 8825-2 pomocí definicí ASN1 definovaných v příloze A. MSD je na to také odkazováno v [Ref8]. POZNÁMKA Pro implementaci reprezentace v ASN.1 PER je čtenářům doporučeno také přečíst přílohu B „ASN.1 Data Representation PER and BER explained"; a také [Ref3], [Ref4], [Ref5] a [Ref6].
6.2
Minimální soubor dat (MSD)
Následující články uvádějí definici minimálního souboru dat, který musí být zaslán z vozidla v případě tísňového volání. 6.2.1 Pořadí bitů a bajtů Zpráva se musí zaslat v sekvenci definované v těchto článcích MSD (6.2.x) a potvrzení musí být přeneseno síťovým zařízením podle dohodnutých evropských norem. Obrázek 1 uvádí pořadí bitů a bajtů v MSD rámci.
7
prEN 15722
Obrázek 1 – Pořadí bitů a bajtů v MSD rámci 6.2.2
Obsah MSD
Tabulka 1 uvádí souhrn sémantických obsahů MSD. ** Záznamy odkazující na „Polohu Bajtu“ v níže uvedených tabulkách jsou tudíž pouze orientační a jsou uvedeny pouze pro snazší pochopení sémantické reprezentace. Reálná poloha prvku v datovém toku je definována definicí ASN1 v příloze A.
Tabulka 1 – Obsah/formát datového konceptu MSD (a kde je tabulka??) M – Povinné datové pole O – Nepovinné datové pole, musí být zahrnuto, i když neobsahuje žádnou informaci.
6.2.3
Obsah MSD (text stejný jako 6.2.2)
Tabulka 1 uvádí souhrn sémantických obsahů MSD. ** Záznamy odkazující na „Polohu Bajtu“ v níže uvedených tabulkách jsou tudíž pouze orientační a jsou uvedeny pouze pro snazší pochopení sémantické reprezentace. Reálná poloha prvku v datovém toku je definována definicí ASN1 v příloze A.
Tabulka 2 – Obsah/formát datového konceptu MSD M – Povinné datové pole O – Nepovinné datové pole, musí být zahrnuto, i když neobsahuje žádnou informaci. Blok č. 1
2
Název ID
Řídící bajt
**Pozice bajtu První
Poslední
Typ
Jednotka
Popis
1
Integer
M Nastavení verze formátu MSD na 1pro odlišení od budoucích formátů MSD.
2
Integer
M Identifikátor MSD zprávy. První odeslání 1, každé další odeslání téže zprávy inkrementováno o 1.
Integer
M Bit 7: 1 = Automatická aktivace
3
8
0 = Manuální aktivace Bit 6: 1 = Testovací volání 0 = Tísňové volání Bit 5: 1 = Nejistota v poloze 0 = Důvěryhodná poloha Bit 4 – 0: typ vozidla 00001 – osobní vozidlo (třída M1) 00010 – autobusy a dálkové autobusy (třída M2) 00011 – autobusy a dálkové autobusy (třída M3) 00100 – lehká nákladní vozidla (třída N1) 00101 – těžká nákladní vozidla (třída N2) 8
prEN 15722
Blok č.
Název
**Pozice bajtu První
Poslední
Typ
Jednotka
Popis 00110 – těžká nákladní vozidla (třída N3) 00111 – motocykly (třída L1e) 01000 – motocykly (třída L2e) 01001 – motocykly (třída L3e) 01010 – motocykly (třída L4e) 01011 – motocykly (třída L5e) 01100 – motocykly (třída L6e) 01101 – motocykly (třída L7e) POZNÁMKA 1 Definice typu vozidla M, N dle směrnice 2007/46/ES, třída L podle směrnice 2002/24/ES. POZNÁMKA 2 Bit 5 nastaven na 1 v případě, kdy poloha není v rozmezí ± 150 na 95 % intervalu spolehlivosti.
3
4
Identifikace vozidla
Typ úložiště paliva
String
M VIN v souladu s ISO 3779
4
20
4
6
World Manufacturer Index (WMI)
7
12
Vehicle Type Descriptor (VDS)
13
20
Vehicle Identification Sequence (VIS)
21
Integer
M Identifikace typu úložiště paliva (pohonných hmot) vozidla. 0 = typ úložiště neuveden 1 = typ úložiště uveden Všechny bity nastaveny na 0 indikují neznámý typ úložiště paliva/energie. Bit 7: neobsazen Bit 6: neobsazen Bit 5: 1 = vodík Bit 4: 1 = elektřina s více jak 42V a 100Ah Bit 3: 1 = LPG Bit 2: 1 = CNG Bit 1: 1 = Diesel Bit 0: 1 = Benzin POZNÁMKA Informace může být v případě změny pohonu nespolehlivá (např. z benzínu na CNG). POZNÁMKA Lze nastavit více než jeden bit, pokud existuje více než jeden ty úložiště pohonných hmot.
5
Time stamp
22
25
Integer
UTC sec
M Time stamp incidentu v sekundách od půlnoci 1.1.1970.
6
Poloha vozidla
26
29
Integer
miliarcse c
M Zeměpisná šířka (ISO 6709) Rozsah hodnot (-324000000 až 324000000) Maximální hodnota zeměpisné šířky = 90°00'00.000'' = 90*60*60.000'' =
9
prEN 15722
Blok č.
Název
**Pozice bajtu První
Poslední
Typ
Jednotka
Popis 324000.000'' = 324 000 000 Miliarcsekund = 0x134FD900 Minimální hodnota zeměpisné šířky = 90°00'00.000'' = -90*60*60.000'' = 324000.000'' = -324 000 000 Miliarcsekund = 0xECB02700 PŘÍKLAD 48°18'1.20" N = 48.3003333 lat = (48*3600)+(18*60)+1.20}’’ = 173881,200’’ což je kódováno na následující hodnotu: = 173881200d = 0x0A5D3770 Pokud je šířka neplatná nebo neznámá, musí se přenést hodnota 0xFFFFFFFF
30
33
Integer
Miliarcse c
M Zeměpisná délka (ISO 6709) Rozsah hodnot (-648000000 až 648000000) Maximální hodnota zeměpisné délky = 180°00'00.000'' = 180*60*60.000'' = 648000.000''= 648 000 000 Miliarcsekund = 0x269FB200 Minimální hodnota zeměpisné délky = 180°00'00.000'' = -180*60*60.000'' = 648000.000'' = -648 000 000 Miliarcsekund = 0xD9604E00 PŘÍKLAD 11°37'2.52" E = 11.6173666 long = (11*3600)+(37*60)+2.52}’’ = 41822.520’’ což je kódováno na následující hodnotu: = 41822520d = 0x027E2938 Pokud je délka neplatná nebo neznámá, musí se přenést hodnota 0xFFFFFFFF
7
Směr vozidla
34
34
Integer
2° Stupně
M Směr jízdy udán v 2° krocích od magnetického severu (0-358 po směru hod. ručiček)
Nedávná poloha vozidla n-1
35
36
Integer
100 miliarcse c
O Přírůstek zeměpisné šířky (+ pro sever, pro jih) s ohledem na aktuální pozici v bloku 6. (1 jednotka = 100 miliarcsekund, což je přibližně 3m) Rozmezí kódovaných hodnot -512..511) představující -51200 až +51100 miliarcsekund, nebo od 51,2’’S do 51,1’’N z aktuální polohy
36
37
Integer
100 miliarcse c
O Přírůstek zeměpisné délky (+ pro východ, - pro západ) s ohledem na aktuální pozici v bloku 6. Rozmezí kódovaných hodnot -512..511) představující -51200 až +51100 miliarcsekund, nebo od 51,2’’W do 51,1’’E z aktuální polohy
8
Nedávná poloha vozidla n-2
37
38
Integer
100 miliarcse c
10
O Přírůstek zeměpisné šířky (+ pro sever, pro jih) s ohledem na nedávnou polohou vozidla n-1 v bloku 7.
prEN 15722
Blok č.
Název
**Pozice bajtu První
Poslední
Typ
Jednotka
Popis 1 jednotka = 100 miliarcsekund, což je přibližně 3m Rozmezí kódovaných hodnot -512..511 představující -51200 až +51100 miliarcsekund, nebo od 51,2’’S do 51,1’’N z polohy reprezentované nedávnou polohou vozidla n-1
39
40
Integer
100 miliarcse c
O Přírůstek zeměpisné délky (+ pro východ, - pro západ) s ohledem na nedávnou polohou vozidla n-1 v bloku 7. Rozmezí kódovaných hodnot -512..511 představující -51200 až +51100 miliarcsekund, nebo od 51,2’’W do 51,1’’E z polohy reprezentované nedávnou polohou vozidla n-1
9
Počet pasažérů
41
41
Integer
O Počet zapnutých bezpečnostních pásů. Nastaveno na 255, pokud tato informace není dostupná. POZNÁMKA Tato informace je relevantní pouze pro automatiky generovaná eCall volání a je pouze informativní, neboť její informační hodnota nemusí být vždy spolehlivá při uvádění přesných informací o počtu cestujících (např. z důvodu, že pásy nemusí být cestujícími použity nebo pásy mohou být použity pro jiné účely).
10
Poskytovat el služeb
42
57
String
IPv6
O Adresa poskytovatele služeb ve formátu IPv6, v standardní textové reprezentaci, např. použití až osmi skupin s až čtyřmi znaky “0-9”, nebo “a-f” pro reprezentaci šedesátkové soustavy s každou skupinou oddělenou znakem dvojtečky (:). Pokud jedna nebo více čtyřčíselných skupin je 0000, mohu být nuly vynechány a nahrazeny dvěma dvojtečkami (::). Podle tohoto pravidla jakýkoliv počet následujících skupin 0000 lze snížit na dvě dvojtečky, jakmile je pouze jedna dvojitá dvojtečka v dané adrese. Je to tento (::) zápis, který umožňuje typickým adresám, aby byly zaslány s daleko méně bajty v MSD. Například, “2001:0db8:85a3:08d3:1319:8a2e:0370:7 334“ nebo “2001:0db8:0000:0000:0000:0000:1428:5 7ab” nebo “2001:0db8::1428:57ab” [ekvivalent k předchozímu] nebo “::ffff:c000:280”
11
Formát
58
58
Integer
O Formát následujících volitelných informací. Bit 0: 1 = Žádné doplňující informace* Bit 1: 1 = Binární data Bit 2: 1 = BCD Bit 3: 1 = XML 11
prEN 15722
Blok č.
Název
**Pozice bajtu První
Poslední
Typ
Jednotka
Popis Bit 4: 1 = ASN.1, BER Bit 5: 1 = ASN.1, PER Bit 6: 1 = ASCII Bit 7 = nepřiřazeno * Pokud hodnota pro pole 11 je 0 (žádná dodatečná data), pak lze zprávu rozčlenit podle bloku 14 níže
12
Kontrolní součet
59
62
13
Volitelné informace
63
94
M CRC-32 (ISO 3309) ochrana povinných (M) dat MDS od bajtu 1 do bajtu 58**. MSB je uložen v bajtu 59. String
Podle stanovení
O Dalších 32 bajtů je určeno poskytovatelům služeb. Kódování informací bude provedeno dle bloku 11. Nepoužité bajty by měly obsahovat blank characters (mezery). POZNÁMKA Formát takových nepovinných datových konceptů lze poskytnout v následné verzi této technické specifikace nebo lze nalézt v datovém registru , který je ve shodě s CEN ISO/TS 24978. Nepovinná dodatečná data musí být chráněna příslušným CRC.
POZNÁMKA Mimo případy, kde je explicitně specifikováno nebo stanoveno v odkazované normě, nejsou povoleny záporné hodnoty.
6.2.4
Potvrzení (acknowledgement) MSD a pořadavek
Tabulka 2 uvádí obsah a formát potvrzení MSD a požadavku na přenos MSD operátory PSAP. Tabulka 3 – Formát datového konceptu potvrzení MSD M – Povinné datové pole Blok č. 1
2
Název ID
Status
**Pozice bajtu První
Poslední
Typ
Jednotka
Popis
1
Integer
M Nastavení verze formátu MSD na 1 pro odlišení od budoucích formátů.
2
Integer
M Identifikátor MSD zprávy. Odkazující se na odpovídající identifikátor zprávy (bajt 7) přijatého MSD.
3
Integer
M = 0 kladné potvrzení = 1 chyba, opakovat nebo iniciovat přenos MSD = 2 transakce dokončena, eCall může být ukončen Dalí hodnoty jsou v současné době nepoužity a jsou rezervovány pro budoucí použití.
3
Kontrolní součet
4
5
M CRC-16 (ITU X.25) ochrana dat potvrzení od bajtu 1 do bajtu 3. MSB je uložen v bajtu 4.
12
prEN 15722
POZNÁMKA Mimo případy, kde je explicitně specifikováno nebo stanoveno v odkazované normě, nejsou povoleny záporné hodnoty.
13
prEN 15722
Příloha A (normativní) Reprezentace MSD v ASN.1 PER MSDASN1Module DEFINITIONS AUTOMATIC TAGS ::= BEGIN ECallMessage ::=CHOICE { msd MSDMessage, -- Minimum Set Of Data uplink from vehicle msdAck MSDAckMessage, -- MSD acknowledge downlink to vehicle ... -- By using ASN.1 definitions as above, a frame and delimiter are not required. -- The ECallMessage structure above supports 2 message types (msd and msdack) but allows extendibility -- Thus further message types might be added later in future versions } -- The "uplink" msd message from the vehicle follows, using elements defined below MSDMessage ::= SEQUENCE { msdStructure MSDStructure, frameCheck INTEGER(0 .. 4294967295), -- 32 bit frame check of msdStructure optionalAdditionalData UTF8String (SIZE(1..32)) OPTIONAL, ... -- Extendible in future versions here e.g. to add extra optional data } -- The main MSD structure follows, using elements described below MSDStructure ::= SEQUENCE { formatVersion INTEGER(0 .. 255), messageIdentifier INTEGER(0 .. 255), control ControlType, vehicleIdentificationNumber VIN, vehiclePropulsionStorageType VehiclePropulsionStorageType, timestamp INTEGER(0 .. 4294967295), --Number of seconds since 1970:00:00:00 vehicleLocation VehicleLocation, vehicleDirection INTEGER(0 .. 255), -- Clockwise heading in 2 degree units -- Coded values of 0..179 -- represent headings from 0..358 deg -- Value 255 represents "unknown" -- other values are invalid recentVehicleLocationN1 VehicleLocationDelta OPTIONAL, recentVehicleLocationN2 VehicleLocationDelta OPTIONAL, numberOfPassengers INTEGER(0 .. 255) OPTIONAL, serviceProvider AddressIPV6 OPTIONAL, additionalDataFormatField INTEGER(0 .. 255), ... -- Extendible in future versions here e.g. to add new data elements to MSD } -- The following basic elements are used in the main MSD structure MSDStructure ControlType ::= SEQUENCE { activation BOOLEAN, -- manualActivation (0) / automaticActivation (1), callType BOOLEAN, -- emergency (0)/ testCall (1), positionconfidence BOOLEAN, -- positionCanBeTrusted (0) / lowConfidenceInPosition (1), vehicleType VehicleType } VehicleType ::= ENUMERATED{ passengerVehicleClassM1 (1), busesAndCoachesClassM2 (2), busesAndCoachesClassM3 (3), lightCommercialVehiclesClassN1 (4), heavyDutyVehiclesClassN2 (5), 14
prEN 15722
heavyDutyVehiclesClassN3 (6), motorcyclesClassL1e (7), motorcyclesClassL2e (8), motorcyclesClassL3e (9), motorcyclesClassL4e (10), motorcyclesClassL5e (11), motorcyclesClassL6e (12), motorcyclesClassL7e (13), ... -- Extendible in future versions here for new vehicle types } --NOTE: Vehicle definitions class M, N according directive 2007/46/EC; --class L according directive 2002/24/EC VIN ::= SEQUENCE { isowmi PrintableString (SIZE(3)) (FROM("A".."H"|"J".."N"|"P"|"R".."Z"|"0".."9")), -- World Manufacturer Index isovds PrintableString (SIZE(6)) (FROM("A".."H"|"J".."N"|"P"|"R".."Z"|"0".."9")), -- Vehicle Descriptor Section isovisModelyear PrintableString (SIZE(1)) (FROM("A".."H"|"J".."N"|"P"|"R".."Z"|"0".."9")), -- Modelyear in Vehicle Identifier Section isovisSeqPlant PrintableString (SIZE(7)) (FROM("A".."H"|"J".."N"|"P"|"R".."Z"|"0".."9")) -- plant code + sequential number in Vehicle Identifier Section } VehiclePropulsionStorageType ::= SEQUENCE { gasolineTankPresent BOOLEAN DEFAULT FALSE, dieselTankPresent BOOLEAN DEFAULT FALSE, compressedNaturalGas BOOLEAN DEFAULT FALSE, liquidPropaneGas BOOLEAN DEFAULT FALSE, electricEnergyStorage BOOLEAN DEFAULT FALSE, --with more than 42v and 100Ah hydrogenStorage BOOLEAN DEFAULT FALSE, ... -- Extendible in future versions here for new fuel storage types -- Instead of defining "not used" -- Extendability Marker, for new version put a "," behind the "..." and add new elements -- Example: hydrogenStorage BOOLEAN DEFAULT FALSE, -- ..., -- xyzStorage BOOLEAN DEFAULT FALSE (here no "," if end of list) } VehicleLocation ::= SEQUENCE { positionLatitude INTEGER(-2147483648..2147483647), -- 32 bits (4 octets) allocated to make signed value handling easier -- Real latitude values in 1mas units -- from -324000000 to 324000000 -- representing -90° to +90° -- 0xFFFFFFF means value not available positionLongitude INTEGER(-2147483648..2147483647) -- 32 bits (4 octets) allocated to make signed value handling easier -- Real longitude values in 1mas units -- from -648000000 to 648000000 -- representing -180° to +180° -- 0xFFFFFFF means value not available } VehicleLocationDelta ::= SEQUENCE { latitudeDelta INTEGER (-512..511), -- 100 miliarcsecond resolution -- allows range 51.2''S to 51.1''N longitudeDelta INTEGER (-512..511) -- 100 miliarcsecond resolution -- allows range 51.2''W to +51.1''E } AddressIPV6 ::= PrintableString (SIZE(0..39)) (FROM("a".."f"|":"|"0".."9")) -- The "downlink" msdack message to the vehicle follows, using elements defined below MSDAckMessage ::= SEQUENCE {
15
prEN 15722
msdAckStructure MSDAckStructure, frameCheck INTEGER(0 .. 65535) -- frame check of msdAckStructure } -- The main MSDACK structure follows MSDAckStructure ::= SEQUENCE { formatVersion INTEGER(0 .. 255), messageIdentifer INTEGER(0 .. 255), msdackstatus MsdAckStatus, ... } MsdAckStatus ::= ENUMERATED{ positiveAck (0), repeatTransmissionRequest (1), transactionTerminateAllowed (2), ... -- Extendible in future versions here for new Ack status } END -- Examples for the MSDAck and MSD structures follow -- These examples do NOT form part of the formal ASN1 definition msddownlinkexample MSDAckMessage ::= { msdAckStructure { formatVersion 1, messageIdentifer 1, status 1 }, frameCheck '5A62'H --should be generated by CRC polynom } msdexample MSDMessage ::= { msdStructure { formatVersion 1, messageIdentifier 1, control { activation automaticActivation, --01110000=70 callType emergency, positionconfidence positionCanBeTrusted, vehicleType passengerVehicleClassM1 }, vehicleIdentificationNumber "WMIVDSVDSYA123456", vehiclePropulsionStorageType {gasolineTankPresent TRUE}, --10000000=80 timestamp 123456789, vehicleLocation {positionLatitude 173881200, positionLongitude 41822520}, vehicleDirection 14, recentVehicleLocationN1 {latitudeDelta 10, longitudeDelta -10}, recentVehicleLocationN2 {latitudeDelta 10, longitudeDelta -10}, numberOfPassengers 2, serviceProvider “::ffff:c000:280”, additionalDataFormatField 0, }, frameCheck '5A62B0CD'H --should be generated by CRC polynom }
END
16
prEN 15722
Příloha B (normativní) Vysvětlená reprezentace dat ASN.1 v PER a BER B.1 Úvod do ASN.1 pravidel zhuštěného kódování (PER) Zdroj: veřejné informace z http://www.w3.org/Protocols/HTTP-NG/asn1.html zpracované panem Simon E Spero (
[email protected]) (rychlý přehled o ASN.1, BER a PER upravený panem Dave Raggett z emailové zprávy od Simon. S) ASN.1 je zápis pro popis datových struktur; je to spíše deklarace typu v C nebo C++. Začněme strukturou C++ a vytvořme příslušnou datovou strukturu ASN.1. Pro začátek použiji zjednodušenou formu požadavku GET z FHTTP. struct GetRequest { int headerOnly; // flag: do we only want headers? int lock; // flag: should we checkout the object? string url; // the url to fetch AcceptTypes* acceptTypes; // Optional list of accept types that only apply // to this request }; struct AcceptTypes { List
* standardTypes; // list of bitmaps indicating which // preference order for standard types List<string>* otherTypes; // nonstandard types in preference order }; GetRequest ::= [APPLICATION 0] IMPLICIT SEQUENCE { headerOnly BOOLEAN, lock BOOLEAN, acceptTypes AcceptTypes OPTIONAL url OCTET STRING, } AcceptTypes ::= [APPLICATION 1] IMPLICIT SEQUENCE { standardTypes [0] IMPLICIT SEQUENCE OF BIT STRING {html(0),plain-text(1),gif(2), jpeg(3)} OPTIONAL, otherTypes [1] IMPLICIT SEQUENCE OF OCTET STRING OPTIONAL } For the encoding examples, we'll use the following example. (GetRequest :headerOnly TRUE :lock FALSE :acceptTypes (AcceptTypes :standardTypes ((html) (plain-text))) :url "/ses/magic/moxen.html")
B.2
Základní pravidla kódování (BER)
Základní pravidla kódování (BER) byly původní pravidla pro nakládání s datovým typem ASN.1 a jeho přetvoření do sekvence bitů a bajtů. BER používá formu kódování obecně známou jako Hodnota délky tagu. Každá položka je kódována jako tag označující, jakého je typu, délkou označující velikost objektu a hodnotou, která obsahuje aktuální obsah objektu. Tagy jsou rozumně jednoduché – v jejich nejjednodušší formě sestávají z jediného bajtu; dva nejvyšší bity označují třídu tagu (zda-li je tag oficiální ISO tag, tag širší aplikace, soukromý tag, nebo tag, který má význam pouze pro danou strukturu. Další bit je příznakem k označení, zda-li tagovaný objekt je jednoduchého typu, jako je číslo nebo řetězec, nebo složeného typu tvořeného soustavou z jiných typů. Zbývajících 5 bitů se používá k reprezentaci čísla tagu. Pokud je tag příliš velký, aby se vešel do 5 bitů, poté jsou tyto bity nastaveny všechny stejně a číslo tagu se kóduje v následujících bajtech jako sekvence sedmibitových bajtů. Vysoký bit těchto bajtů se používá jako příznak k označení, zda-li tag ještě pokračuje. Délky jsou také docela jednoduché. Existují dva způsoby kódování délky – definitní forma a indefinitní forma. U definitní formy pokud délka je nižší než 128, použije se jeden bajt s vysokým bitem nastaveným na nulu. 17
prEN 15722
Jinak je vysoký bit nastaven na jedničku a sedm nižších bitů na délku délky. Délka je poté kódována v daném počtu bajtů. U indefinitní formy se kóduje zasláním pole s délkou, s délkou délky 0 - i.e. [1000|0000]. Objekt je ukončen zasláním dvou nulových bajtů. Níže je uveden zkušební případ kódovaný použitím BER. 0x60 0x80 0x01 0x01 0x01 0x01 0x01 0x00 0x61 0x80 0xa0 0x80 0x03 0x02 0x04 0x80 0x03 0x02 0x04 0x40 0x00 0x00 0x00
---------------------
[0110|0000], [APPLICATION 0, Compound] - GetRequest [1000|0000], Indefinite length [0000|0001], [BOOLEAN] GetRequest.headerOnly [0000|0001], length 1 [0000|0001], value TRUE [0000|0001], [BOOLEAN] GetRequest.lock [0000|0001], length 1 [0000|0000] value FALSE [0110|0001], [APPLICATION 1, Compound] - GetRequest.types indefinite length [1010|0000], [CONTEXT 0, Compound] types.standardTypes indefinite length [0000|0011] [BIT STRING] length 2 Four bits unused [1000|0000] {html} [0000|0011] [BIT STRING] length 2 Four bits unused [0100|0000] {plain-text}
-- End of list of standard Types
0x00 -- End of Accept Types 0x04 -- [0000|0100], [OCTET STRING] GetRequest.url 0x16 -- [0001|0110], length 22 [/ses/magic/moxen.html] -- value 0x00 0x00 -- End of get request [50 bytes total], 22 url
B.3
Pravidla zhuštěného kódování (PER)
Pravidla kódování (PER) používají různý styl kódování. Namísto použití obecného stylu kódování, který kóduje všechny typy jednotným způsobem, se PER specializuje na kódování založeném na datovém typu pro generování daleko kompaktnějších reprezentací. Pravidla kódování (PER) mají určitou hodnotu pro zprávy známé datové struktury jako je MSD (vloženo editorem EN 15722). PER pouze vygeneruje tagy, pokud jsou potřeba k zabránění nejednoznačnosti; to se stává, když se použije souhrnná verze ASN.1 (CHOICE). PER také generuje délky, když se velikost objektu může měnit. I tak se PER snaží reprezentovat délky nejkompaktněji možnou formou. Kódování PER není vždy spojeno na hranicích bajtů; pokud je použita varianta pravidel 'aligned', poté řetězce *budou* spojeny, jinak je kódování zpracováno jako řetězec bitů umožňující, aby záležitosti jako booleans a malé integers byly vměstnány do jednoho bajtu. Přítomnost nepovinných prvků v sekvenci je označena seznamem jednobitových příznaků umístěných na začátku sekvence – pokud je bit nastaven, poté je nepovinný prvek přítomen. Níže je uveden zkušební případ, tentokrát v PER. [1] -- flag bit indicates acceptTypes is present [1] -- boolean, header only, TRUE [0] -- boolean, lock, FALSE [1] -- flag bit, indicates standardTypes is present [0] -- flag bit, indicates otherTypes is absent [000] -- pad bits to make length octet aligned [00000010] -- length of 2, -- 2 standardType bit strings to follow [1000] -- the first bit string, html is set [0100] -- the second bit string, plain-text is set [00010110] -- length 22; url is 22 octets long 18
prEN 15722
/ses/magic/moxen.html -- value of url [total size is 26, 22 url]
V tomto případě jsou PER asi dvakrát kompaktnější než BER. Pokud je zvoleno kratší URL, jako je /, je rozdíl ještě znatelnější - BER, 29; PER, 5, tedy poměr přes 5:1.
19
