EVROPSKÁ NORMA pren 15722 EUROPEAN STANDARD říjen 2008 NORME EUROPÉENNE EUROPÄISCHE NORM

EVROPSKÁ NORMA pren 15722 EUROPEAN STANDARD říjen 2008 NORME EUROPÉENNE EUROPÄISCHE NORM 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 ECall ensemble minimum de données (MSD) Strassenverkehrstelematik E-Safety Minimaler 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

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

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

Ú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

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

(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

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 Koncepty a formáty 6.1.1 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

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 č. Název **Pozice bajtu První Poslední Typ Jednotka Popis 1 ID 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. 2 Řídící bajt 3 8 Integer M Bit 7: 1 = Automatická aktivace 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

Blok č. Název 3 Identifikace vozidla 4 Typ úložiště paliva 5 Time stamp 6 Poloha vozidla **Pozice bajtu První 4 4 7 13 Poslední 20 6 12 20 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. String M VIN v souladu s ISO 3779 World Manufacturer Index (WMI) Vehicle Type Descriptor (VDS) 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. 22 25 Integer UTC sec M Time stamp incidentu v sekundách od půlnoci 1.1.1970. 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

Blok č. Název Směr vozidla 7 Nedávná poloha vozidla n-1 8 Nedávná poloha vozidla n-2 **Pozice bajtu První Poslední 30 33 Integer Miliarcse c 34 34 Integer 2 - Stupně 35 36 Integer 100 miliarcse c 36 37 Integer 100 miliarcse c 37 38 Integer 100 miliarcse c 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 M Zeměpisná délka (ISO 6709) M 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 Směr jízdy udán v 2 krocích od magnetického severu (0-358 po směru hod. ručiček) 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) O 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 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 O Přírůstek zeměpisné šířky (+ pro sever, - pro jih) s ohledem na nedávnou polohou vozidla n-1 v bloku 7. 10

Blok č. Název 9 Počet pasažérů 10 Poskytovat el služeb **Pozice bajtu První Poslední 39 40 Integer 100 miliarcse c Typ Jednotka Popis O 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 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 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). 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

Blok č. Název 12 Kontrolní součet 13 Volitelné informace **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 59 62 M CRC-32 (ISO 3309) ochrana povinných (M) dat MDS od bajtu 1 do bajtu 58**. MSB je uložen v bajtu 59. 63 94 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. M Povinné datové pole Blok č. Název Tabulka 3 Formát datového konceptu potvrzení MSD **Pozice bajtu První Poslední Typ Jednotka Popis 1 ID 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. 2 Status 3 Integer M = 0 kladné potvrzení 3 Kontrolní součet = 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í. 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

POZNÁMKA Mimo případy, kde je explicitně specifikováno nebo stanoveno v odkazované normě, nejsou povoleny záporné hodnoty. 13

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

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

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

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 (ses@tipper.oit.unc.edu) (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<bitset>* 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

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 -- [0110 0000], [APPLICATION 0, Compound] - GetRequest 0x80 -- [1000 0000], Indefinite length 0x01 -- [0000 0001], [BOOLEAN] GetRequest.headerOnly 0x01 -- [0000 0001], length 1 0x01 -- [0000 0001], value TRUE 0x01 -- [0000 0001], [BOOLEAN] GetRequest.lock 0x01 -- [0000 0001], length 1 0x00 -- [0000 0000] value FALSE 0x61 -- [0110 0001], [APPLICATION 1, Compound] - GetRequest.types 0x80 -- indefinite length 0xa0 -- [1010 0000], [CONTEXT 0, Compound] types.standardtypes 0x80 -- indefinite length 0x03 -- [0000 0011] [BIT STRING] 0x02 -- length 2 0x04 -- Four bits unused 0x80 -- [1000 0000] {html 0x03 -- [0000 0011] [BIT STRING] 0x02 -- length 2 0x04 -- Four bits unused 0x40 -- [0100 0000] {plain-text 0x00 0x00 -- End of list of standard Types 0x00 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

/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