NORMA ISO prcen ISO TS ISO STANDARD říjen 2008 NORME ISO ISO NORM

Transkript

1 NORMA ISO prcen ISO TS ISO STANDARD říjen 2008 NORME ISO ISO NORM Elektronický výběr poplatků (EFC) Definice aplikačního rozhraní pro autonomní systémy Část 1: Zpoplatňování Electronic fee collection Application interface definition for autonomous systems Part 1: Charging Upozornění: Tento dokument není mezinárodní ISO normou a je distribuován pro revizi a k připomínkování. Dokument podléhá změnám bez předchozího oznámení a nesmí být uváděn jako mezinárodní norma. Adresáti tohoto návrhu jsou vyzváni, aby společně s připomínkami uvedli označení příslušných vlastnických práv, kterých jsou si ve spojitosti s touto normou vědomi, a dodali příslušnou dokumentaci. Ustanovení o vlastnických právech Tento dokument ISO je návrhem mezinárodní normy a je chráněn vlastnickými právy ISO. Vyjma povolení za použití zákonů dané země uživatele nelze tento návrh ISO ani jeho část reprodukovat, ukládat do systému pro vyhledávání informací nebo přenášet v jakékoliv formě nebo jakýmikoliv prostředky, elektronicky, fotokopií, záznamem nebo jiným způsobem, bez předchozího obdržení písemného povolení. Se žádostí o povolení reprodukce se obraťte na ISO na níže uvedené adrese nebo na člena ISO v příslušném státu žadatele. ISO copyright office Case postale 56, CH 1211 Geneva 20 Tel Fax copyright@iso.org Web Reprodukce může být předmětem vymáhání plateb nebo licenčního ujednání. Viníci budou potrestáni. ISO Mezinárodní organizace pro normalizaci International Organization for Standardization Organisation international de normalisation Internazionale Organisation für Normung 2008 CEN Veškerá práva pro využití v jakékoli formě a jakýmikoli prostředky Ref. č. prcen ISO TS :2008 jsou celosvětově vyhrazena národním členům CEN. 1

2 Obsah Úvod Předmět normy Citované normativní dokumenty Termíny a definice Zkratky Požadavky na proces Všeobecně Konfigurace hlášení mýtného Odpověď na hlášení mýtného Datové prvky Úvod Hlášení Všeobecně Popis vozidla - vehicledescription Čas hlášení - timeofreport Daň z přidané hodnoty pro tuto relaci - vatforthissession Množství - Amount Měna - currency Počitadlo transakcí - transactioncounter Počitadlo vzdálenosti - distancecounter Vzdálenost - Distance Poloha - Position Perioda - Period Trvání - Duration Autentizátor a autentizátor odpovědi - authenticator and responseauthenticator Smlouva ID palubního zařízení - obeid Platební prostředky - paymentmeans Smlouva s poskytovatelem služby - serviceprovidercontract Výběrčí mýtného - tollcharger ID hlášení příjemce - reportrecipientid Status palubního zařízení OBE pro řidiče - obestatusfordriver Použití Seznam sdělení o použití PK a sdělení o použití PK - usagestatementlist and UsageStatement ID sdělení o použití - usagestatementid ID režimu mýtného - regimeid Shromážděný poplatek - aggregatedfee Relace shromážděné v rámci jednotarifní třídy - aggregatedsingletariffclasssession Seznam zpoplatněných objektů a detekovaný zpoplatněný objekt - listofchargeobjects and DetectedChargeObject Seznam nezpracovaných dat použití PK - ListOfRawUsageData Strana 2

3 6.5.8 Seznam dat o použití DSRC - ListOfDSRCUsageData Přijatá data - DataReceived Účet Status účtu - accountstatus Aktualizace účtu - accountupdate Znovuzavedení účtu - ReloadAccount Limit nového účtu - NewAccountLimit AddToAccount Verze Informace o verzi - versioninfo Odpověď na verzi - versionresponse Kontrola shody Atributy kontroly shody komunikace - CCCAttributes...20 Příloha A (normativní) Specifikace datových typů EFC...21 Příloha B (normativní) Formulář protokolu o shodě implementace PICS...27 B.1 Autentizátor atributu...27 B.2 Povinné datové typy...27 B.3 Nepovinné datové typy...27 B.3.1 Hlášení mýtného - ChargeReport...27 B.3.2 Odpověď na hlášení mýtného - ChargeReportResponse...27 B.3.3 Sdělení o použití PK - UsageStatement...28 B.3.4 Typy účtů - Account types

4 Předmluva Mezinárodní organizace pro normalizaci (ISO) je světovou federací národních normalizačních institutů (členové ISO). Práce při přípravě mezinárodních norem je běžně prováděna technickými komisemi ISO. Každý člen se zájmem o předmět, pro nějž byla ustavena technická komise, má právo být v této komisi zastoupen. Mezinárodní organizace, vládní a nevládní, ve spolupráci s ISO se také této práce účastní. ISO úzce spolupracuje s Mezinárodní elektrotechnickou komisí (IEC) v oblasti elektrotechnické standardizace. Předlohy mezinárodních norem jsou zpracovávány v souladu s pravidly danými směrnicemi ISO/IEC, část 2. Hlavním úkolem technických komisí je připravovat mezinárodní normy. Návrhy mezinárodních norem schválené technickými komisemi jsou postoupeny členům ISO k hlasování. Publikace typu mezinárodní normy vyžadují ke schválení nejméně 75 % hlasů příslušných členů. Návrhy mezinárodních norem přijaté technickými komisemi se rozesílají členům ISO k hlasování. Vydání mezinárodní normy vyžaduje souhlas alespoň 75 % z hlasujících členů. Za jiných okolností, zejména projeví-li trh urgentní zájem na takových dokumentech, může se technická komise rozhodnout vydat i jiný typ normativního dokumentu: veřejně dostupná publikace ISO (ISO/PAS) vyjadřuje dohodu mezi technickými experty v pracovní skupině ISO přijatelnou k vydání, jestliže ji schválí více než 50% hlasujících členů mateřské komise; technická specifikace ISO (ISO/TS) vyjadřuje dohodu mezi členy technické komise přijatelnou k vydání jestliže ji schválí 2/3 hlasujících členů komise. ISO/PAS a ISO/TS se prověřují každé tři roky, s cílem rozhodnout zda se potvrdí na další tříleté období, nebo se bude při převodu na mezinárodní normu revidovat, nebo se zruší. Je-li ISO/PAS nebo ISO/TS potvrzena, prověřuje se opět po třech letech, pak se musí transformovat do mezinárodní normy nebo zrušit. Existuje možnost, že některé z prvků této mezinárodní normy jsou předmětem patentových práv. ISO nesmí být činěna odpovědnou za identifikování některých nebo veškerých takových patentových práv. ISO/TS byla vypracována technickou komisí ISO/TC 204,Inteligentní dopravní systémy, ve spolupráci s technickou komisí CEN/TC 278, Dopravní telematika. ISO/TS sestává z následujících částí pod obecným názvem Elektronický výběr poplatků (EFC) Definice aplikačního rozhraní pro autonomní systémy: Část 1: Zpoplatňování Část 2: Komunikace a propojení s nižšími vrstvami Část 3: Kontextová data Část 4: Roaming 4

5 Úvod Autonomní systémy Tato technická specifikace je součástí souboru čtyř specifikací definujících výměnu informací mezi tzv. frontend a centrálním zařízením elektronického výběru poplatků (Electronic Fee Collection (EFC)) založeném na autonomním palubním zařízení. Systémy mýtného automaticky sbírají data zpoplatnění za použití dopravní infrastruktury včetně dálničních zón, poplatků za použití zón v městských oblastech, mýtné za použití speciální dopravní infrastruktury jako jsou mosty a tunely, zpoplatnění založené na času a ujeté vzdálenosti a poplatky za parkování. Autonomní OBE pracuje bez závislosti na infrastruktuře vyhrazeného spojení krátkého dosahu a to pomocí širokopásmových technologií jako jsou globální navigační satelitní systémy (GNSS) a Celulární (buňkové) komunikační sítě (CN). Tyto mýtné systémy jsou nazývány různými jmény, kromě autonomních systémů a systémů GNSS/CN, také jako systémy GPS/GSM, a systémy širokospektrálního zpoplatnění. Autonomní systémy používají satelitní polohování (lokalizaci) často kombinovanou s technologiemi přídavných snímačů, jakými jsou gyroskopy, tachometry a akcelerometry pro lokalizaci vozidla a nalezení jeho polohy na mapě, která obsahuje zpoplatněné geografické objekty jakými jsou zpoplatněné pozemní komunikace (PK) nebo zpoplatněné oblasti. Kromě zpoplatněných objektů jsou dále stanoveny charakteristiky vozidla, denní doba a jiná data, která jsou relevantní pro popis použití PK, tarif a nakonec i poplatek za použití PK. Silnými stránkami autonomního přístupu k elektronickému vybírání poplatků jsou jeho flexibilita, umožňující implementaci téměř všech myslitelných principů zpoplatnění, a jeho nezávislost na místní infrastruktuře, což staví tuto technologii jako interoperabilní napříč systémy a zeměmi. Interoperability lze dosáhnout pouze jednoznačně definovanými rozhraními, které jsou cílem i náplní toho souboru technických specifikací. Obchodní (komerční) a technická architektura Tato technická specifikace obsahuje obchodní architekturu definovanou v CEN ISO TS Podle této architektury je výběrčím mýtného poskytovatel dopravní služby, a tudíž i příjemcem poplatků za použití PK. Výběrčí mýtného je abstraktní aktor spojený s rolí vybírání mýtného, viz obrázek 1. Obrázek 1 Model rolí definovaný v ISO TS Poskytovatelé služby vydají palubní zařízení OBE uživatelům dopravní služby. Poskytovatelé služby jsou odpovědni za provozování tohoto OBE, které zaznamenává množství použití PK ve všech systémech vybírání mýta, kterými vozidlo projíždí, a za dodání dat mýtného jednotlivým výběrčím mýtného. Proto se uvažuje, že OBE plně spadá do role poskytovatele služby, viz obrázek 2. 5

6 Obrázek 2 Předpokládaná technická architektura a rozhraní Architektura na obrázku 2 byla vytvořena evropským projektem Interoperabilita zpoplatnění PK (Road Charging Interoperability, RCI). Tato architektura odráží fakt, že některé funkce procesu mohou být alokovány v OBE nebo centrální komponentě (Proxy). Jedna z funkcí procesu, kterou lze realizovat jak v palubním zařízení, tak centrálně, je map-matching, kde jsou polohy vozidla vyjádřené naměřenými souřadnicemi ze satelitů GNSS přisouzeny geografickým objektům na dané mapě, která je uložena buď v palubním zařízení, a nebo centrálně. Také stanovení tarifu lze provést pomocí tarifních tabulek v palubním zařízení, kde dojde i ke zpracování, nebo v dané centrální komponentě. Kombinovaná funkce OBE a Proxy je označena jako frontend. Frontend implementace, kde se data zpracovávají především na straně OBE, se označuje pojmem tlustý klient (nebo také inteligentní, chytrý klient) nebo edgeheavy architektura. Frontend, kde je zpracování především centrální, se označuje pojmem tenký klient nebo edge-light architektura. Existuje mnoho implementací mezi tenkým a tlustým extrémem, což ukazuje pozvolný přechod na obrázku 3. Oba extrémy volby architektury mají své výhody a představují pole, kde výrobci mohou soutěžit s jednotlivými alokacemi funkcí mezi palubními a centrálními zdroji. 6

7 Obrázek 3 Pozvolný přechod mezi tlustým a tenkým extrémem architektury systému a rozhraní, které jsou předmětem této technické specifikace Zejména pro výrobce palubního zařízení tenkého klienta existuje široké spektrum optimalizací přenosu lokalizačních dat mezi OBE a centrálními komponentami, kde se používají patentované algoritmy pro redukci dat a jejich kompresi. Standardizace tohoto přenosu však není v úplnosti možná, ani přínosná. Je potřeba poznamenat, že tenký klient a tlustý klient jsou výhradně volbou implementace týkající se alokací procesních zdrojů. Nezávisle na implementaci si mohou výběrčí mýtného přát pro dané vozidlo využívající jejich PK, aby buď získávali méně zpracovaná data, jako je seznam pevných poloh, nebo více zpracovaná data, jako je seznam použitých segmentů PK nebo dokonce seznam relevantních poplatků. Tato technická specifikace činí opatření pro definice atributů, které slouží individuálním potřebám výběrčím mýtného nezávisle na volbě implementace. Vymezení rozhraní specifikace (Location of the specification interface) Pro abstrahování od architektury implementace je primárním předmětem tohoto souboru technických specifikací výměna dat mezi frontend a centrálním zařízením, viz odpovídající čára na obrázku 3 a tlusté čáry na obrázku 2. Pro každý systém výběrčího mýtného zašle centrální zařízení popis mýtného systému v termínech zpoplatněných objektů, pravidel zpoplatnění a, pokud se požaduje, tarifní schéma do frontend a obdrží data použití PK od frontend. Rozdělení úkolů a odpovědností mezi poskytovatelem služby a výběrčím mýtného se bude individuálně lišit. V závislosti na místních právních předpisech mohou, a nebo nesmí, výběrčí mýtného delegovat zpracování určitých datových procesních úloh na poskytovatele služby. Proto mohou být definice dat tohoto souboru technických specifikací užitečné na několika rozhraních. Tento soubor technických specifikací také činí opatření pro základní komunikační služby nezávislé na médiu, které se mohou použít pro komunikaci mezi frontend a centrálním zařízením, která může být kabelová nebo bezdrátovým spojením, a také se může použít pro bezdrátové spojení mezi OBE a centrálním serverem. Čtyři části této technické specifikace Část 1: Zpoplatnění, definuje atributy pro přenos dat použití PK z frontend do centrálního zařízení a nakonec jednotlivému výběrčímu mýtného. Požadované atributy se budou lišit pro nezpracovaná lokalizační data, pro map-matched geografické objekty a pro kompletně vyčíslené transakce mýtného. Část 2: Komunikace a propojení s nižšími vrstvami, definuje základní komunikační služby a API nezávislé na médiu pro přenos dat přes bezdrátové spojení OBE nebo mezi frontend a centrálním zařízením. Tato 7

8 služba zahrnuje autentizované služby čtení a zápisu se všemi funkcemi požadovanými pro bezpečný přenos dat. Část 3: Kontextová data, definuje data, která se použijí pro popis jednotlivých systémů zpoplatnění v termínech zpoplatněných geografických objektů a pravidel zpoplatnění a hlášení. Pro každá systém výběrčího mýtného jsou atributy definované v části 3 použity pro přenos dat do frontend zařízení, aby jej instruovaly, která data je nutno sbírat a hlásit. Dočasná poznámka: V případě, že bude schválen požadavek na změnu názvu a předmětu části 3, pak je nutné přizpůsobit i znění tohoto odstavce. Část 4: Roaming, definuje podrobnosti funkcí a datových prvků požadovaných pro paralelní provoz více než jednoho režimu mýtného. Domény těchto režimů mýtného se mohou, ale nemusí překrývat. Pravidla zpoplatnění různých překrývajících se režimů mýtného mohou být propojeny, např. mohou obsahovat pravidla, že konkrétní schéma zpoplatnění oblasti se nesmí použít, pokud již překrývající se zpoplatnění PK bylo použito a již bylo za její použití zaplaceno. Požadavky pokryté všemi částmi této technické specifikace specifikace jsou ve shodě s architekturou definovanou v CEN ISO TS specifikace podporují zpoplatnění za použití částí PK (včetně mostů, tunelů, přejezdů apod.), kordonový průjezd (vjezd/výjezd) a použití dopravní infrastruktury v rámci dané oblasti (vzdálenost, čas). specifikace podporují sběr poplatků založený na jednotkách vzdálenosti, nebo času, a na výskytu dopravních událostí. specifikace podporují modulaci poplatků podle kategorie vozidla, třídy PK, dobu použití PK a typ smlouvy (např. vozidla osvobozená od platby, vozidla se speciálním tarifem apod.) specifikace podporují horní mez poplatků stanovením maxima za periodu použití PK. specifikace podporují poplatky s různým právním statutem (např. veřejně stanovená daň, soukromé mýtné apod.) specifikace podporují různící se požadavky na různé výběrčí poplatků, a to zejména v termínech: geografické domény a popisů kontextu, obsahu a frekvenci hlášení o zpoplatnění, zpětná vazby řidiči (např. zelené nebo červené světlo), a opatření na dodatečná podrobná data na vyžádání, např. pro řešení sporů. specifikace podporují překrývání geografických domén mýtného. specifikace podporují adaptace na změny ve: zpoplatněné infrastruktuře, tarifech, a participujících režimech. specifikace podporují poskytování garancí důvěryhodnosti poskytovatelem služby výběrčímu mýtného za data pocházející z frontend. 8

9 1 Předmět normy Tato technická specifikace definuje formát a sémantiku výměny dat mezi daným frontend (OBE plus nepovinně proxy) a jeho centrálním zařízením (CE) v autonomních režimech mýtného. V této části technické specifikace se tyto definice koncentrují na datové prvky používané pro hlášení podrobností mýtného od frontend do CE a k získání odpovědi v podobě parametrů, které se mohou použít ke změně konfigurace stávajícího procesu sběru relevantních informací o zpoplatnění ve frontend. Podoba zprávy hlášení mýtného závisí na datech konfigurace, o kterých se předpokládá, že jsou součástí frontend. Takto lze konfigurovat soustavu hlášení mýtného v každém jednotlivém mýtném režimu podle místních potřeb. Hlášení mýtného generovaná podle této specifikace jsou konzistentní s požadavky odvozenými z normy architektury EFC EN Data definovaná v této části technické specifikace se musí použít pro generování hlášení mýtného, které obsahuje informace o množství použití PK daným vozidlem v určitém časovém intervalu. Obsah těchto hlášení mýtného se může mezi režimy mýtného lišit. Režim mýtného zahrnuje sadu pravidel pro zpoplatnění, včetně zpoplatněné sítě, principů zpoplatnění, spolehlivých vozidel a definici požadovaného obsahu hlášení mýtného. Obsah hlášení mýtného požadovaný kontextem mýtného je třeba sdělit do frontend, což by se mělo udělat pomocí dat definovaných v části 3 tohoto souboru technických specifikací. Data definovaná v části 3 se používají pro komunikaci směrem k frontend a definují, co se musí hlásit od frontend a kde se musí učinit hlášení použitím dat definovaných v této technické specifikaci. Data definovaná v této specifikaci lze zasílat, respektive přijímat, od/do centrálního zařízení použitím otevřené definice zásobníku komunikace, jak je definováno v části 2 této technické specifikace. Definice v této specifikaci zahrnují: Data hlášení, např. data pro přenos dat použití PK od frontend do centrálního zařízení, včetně odpovědi z centrálního zařízení do frontend, Smluvní data, např. data pro identifikaci smluvně důležitých entit, Data použití PK, např. data pro hlášení množství použití PK, Účetní data pro management platebního účtu, Data verze, a Data kontroly shody, např. data importovaná z ISO TS 12813, která jsou požadována v komunikacích kontroly shody. 2 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). ISO/IEC Information technology Open Systems Interconnection Conformance testing methodology and framework Part 7: Implementation Conformance Statements. (Informační technologie Propojení otevřených systémů Metodologie a základní struktura zkoušení shody Část 7: Prohlášení o shodě implementace) EN ISO 14906:2004 Dopravní telematika Elektronický výběr poplatků Definice aplikačního rozhraní pro radiový přenos na krátkou vzdálenost (DSRC) (Road Traffic and Transport Telematics (RTTT) Electronic Fee Collection Application interface definition for dedicated short range communication.) EN ISO Road Transport and Traffic Telematics (RTTT) Electronic Fee Collection (EFC) System architecture for vehicle related transport services. (Dopravní telematika Elektronický výběr poplatků Systémová architektura pro dopravní služby souvisící s vozidly) ISO/IEC Informační technologie Abstraktní syntaktická notace jedna (ASN.1): Specifikace základní notace (Information technology Abstract Syntax Notation One (ASN.1): Specification of basic notation) 9

10 ISO/IEC Information technology ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). (Informační technologie Kódovací pravidla pro ASN.1: Specifikace zhuštěného kódování (PER)) ISO TS Dopravní telematika Elektronický výběr poplatků (EFC) Kontrola shody systémů GNSS/CN pomocí DSRC (Road transport and traffic telematics Electronic fee collection Compliance check communication for autonomous systems) ISO 6709 Standardní reprezentace geografických poloh pomocí souřadnic (Standard representation of geographic point location by coordinates) 3 Termíny a definice Termíny a definice uvedené v EN platí i v této specifikaci. Pro účely této technické specifikace platí dále tyto termíny a definice: 3.1 atribut (atribut) posloupnost jednoho nebo více datových prvků, je využívaná při transakci 3.2 autentizační kód (authenticator) data přidaná ke zprávě nebo kryptografická transformace dat, která umožňuje příjemci dat si ověřit zdroj a integritu dat a ochránit tak data proti padělání [EN ISO 14906:2004] 3.3 centrální zařízení (central equipment) obecný název pro výpočetní a komunikační zařízení poskytovatele služby a výběrčího mýtného. Podle architektury definované v EN ISO se v této technické specifikaci předpokládá, že frontend obecně komunikuje s komponentami centrálního zařízení řízeného a provozovaného poskytovatelem služby 3.4 smlouva (contract) vyjádření dohody mezi dvěma nebo více stranami ohledně využívání silniční infrastruktury [EN ISO 14906:2004] 3.5 integrita dat (data integrity) vlastnost zaručující, že data nebyla modifikována neoprávněným způsobem [EN ISO 14906:2004] 3.6 blok mýtného (toll cluster) skupina schémat mýtného provozovaných pod společnou dohodou poskytující interoperabilitu vozidlům vybavených příslušným palubním zařízením OBE a smluvně stanovených poskytovatelem služby, který je součástí této skupiny A group of toll schemes operating under a common agreement providing interoperability for vehicles equipped with an appropriate OBE and being contracted under a service provider being part of the cluster. 3.7 kontext mýtného (toll context) logický pohled na konkrétní schéma mýtného definovaného atributy a funkcemi 3.8 systém mýtného (toll system) celkový pohled na konkrétní schéma mýtného nebo na blok mýtného. Komponenta systému mýtného může být sama systémem a v takovém případě se nazývá subsystém mýtného 3.9 frontend (frontend) část(i) systému mýtného, kde se data použití PK jednotlivého uživatele PK sbírají, zpracovávají a zasílají centrálnímu zařízení. Frontend sestává z palubního zařízení a nepovinné proxy 10

11 3.10 proxy (proxy) nepovinná komponenta mýtných systémů, která komunikuje s palubním zařízením a zpracovává data použití PK do formátu splňujícího požadavky této technické specifikace a zasílá data centrálnímu zařízení 3.11 služba (mýtné) (service (toll)) služba umožňující uživatelům mít jen jednu smlouvu a jednu sadu OBE pro použití vozidla v jedné či více mýtných doménách [EN 17573] 3.12 základ služby (komunikace) (service primitive (communication)) základní komunikační služba poskytovaná protokolem aplikační vrstvy aplikačnímu procesu [EN ISO 14906:2004] POZNÁMKA Spuštění základní služby aplikačním procesem implicitně vyvolává využití nabízených služeb nižších vrstev protokolu transakce (transaction) kompletní výměna informací mezi zařízením na pozemní komunikaci (RSE) a palubním zařízením (OBE) nutná pro dokončení operace EFC prostřednictvím DSRC [EN ISO 14906:2004] 3.14 transakční model (transaction model) funkční model popisující obecnou strukturu transakcí elektronického výběru poplatků [EN ISO 14906:2004] 4 Zkratky Pro účely této normy platí tyto zkratky v celém dokumentu, ledaže by bylo stanoveno jinak. 4.1 ASN.1 Abstract Syntax Notation One [ISO/IEC ] Abstraktní syntaktická notace EFC Electronic Fee Collection [EN ISO 14906:2004] elektronický výběr poplatků; zde se používá jako ekvivalent k termínu mýtné uváděném v EN ISO GNSS Global Navigation Satellite Systems globální navigační satelitní systémy 4.4 VAT Value Added Tax daň z přidané hodnoty 4.5 CCC Compliance Check Communication kontrola shody komunikace, definovaná v ISO TS Požadavky na proces 5.1 Všeobecně Tato část technické specifikace je určena pro nastavení autonomních systémů mýtného podle všeobecné architektury definované v EN ISO Definuje formát a sémantiku hlášení mýtného a odpovědí na hlášení mýtného, které jsou součástí koncového informačního toku. Palubní zařízení sbírá data o použití PK daného jednotlivého vozidla. Tato data jsou shromážděna a zpracována podle své relevance k zpoplatnění buď v palubním zařízení nebo v proxy. Kombinace palubního zařízení a proxy se nazývá frontend. 11

12 Tato část souboru technických specifikací definuje data požadovaná pro komunikaci dat zpoplatněného použití PK pro dané jednotlivé vozidlo od frontend do centrálního zařízení. Frontend musí shromáždit data použití PK do hlášení mýtného a zaslat hlášení mýtného do centrálního zařízení. Centrální zařízení musí potvrdit přijetí konkrétního hlášení mýtného (ChargeReport) s odpovědí na hlášení mýtného (ChargeReportResponse). 5.2 Konfigurace hlášení mýtného Všechny datové prvky zahrnující atribut hlášení mýtného jsou kódovány jako nepovinné (vyjma usagestatementlist, který nakonec také obsahuje pouze nepovinné prvky). Kontextová data mýtného podle části 3 této technické specifikace definují, které datové prvky musí být přítomny a které nemusí. Centrální zařízení musí zaslat kontextová data mýtného definující požadovaný obsah hlášení mýtného do frontend předtím, než palubní zařízení nasbírá data použití PK. Při přijetí kontextových dat mýtného musí frontend začít sbírat, zpracovávat a shromažďovat data použití PK do hlášení mýtného, jak se požaduje. Kontextová data mýtného také definují, při jakých událostech mají být hlášení mýtného zasílána. Kontextová data mýtného jsou definována za odpovědnosti výběrčího mýtného. Poskytovatel služby musí být odpovědný za zajištění zaslání kontextových dat mýtného do frontend a za zajištění přijetí hlášení mýtného centrálním zařízením. POZNÁMKA Požadavky na obsah hlášení mýtného definované kontextovými daty mýtného umožňují nastavení obsahu hlášení, jak je požadováno vlastnostmi režimu mýtného. Tyto vlastnosti zahrnují základní typy mýtných systémů: zpoplatnění části PK (parametr relevantní k poplatku je sumou délek části PK nebo tarifu používaného vozidlem) zpoplatnění oblasti (parametr relevantní k poplatku je dán buď vzdáleností ujetou uvnitř oblasti, nebo dobou strávenou uvnitř oblasti) kordonové zpoplatnění (parametr relevantní k poplatku překročením kordonu v rámci dané oblasti) POZNÁMKA Podle potřeb v místě použití mohou výběrčí mýtného požadovat více či méně zpracovaná data s odlišnou úrovní podrobnosti. Volby výběrčích mýtného ohledně požadovaného obsahu hlášení mýtného také ovlivňují privátní zájmy, přístup dohledu a právní povaha zpoplatnění. Hlášení mýtného podporují: hlášení seznamu zpoplatněných objektů, které jsou deklarovány jako používané vozidlem včetně souvisejících modifikátorů tarifu. Toto hlášení může nebo nemusí zahrnovat vypočtený poplatek nebo daň hlášení o relacích použití PK v rámci jedné sady modifikátorů tarifu. Toto hlášení může nebo nemusí zahrnovat vypočtený poplatek nebo daň, hlášení o závislých relacích na zpoplatněné PK nebo oblasti, kde se hlásí pouze nashromážděný poplatek a příslušný referenční čas, hlášení, kde je zasílán pouze celkový poplatek v rámci předdefinované doby hlášení. (V tomto případě se očekává, že jiné prostředky, mimo předmět této technické specifikace, jsou použity pro umožnění určitého stupně validace procesu zpoplatnění), jakákoliv kombinace hlášení uvedených výše. 5.3 Odpověď na hlášení mýtného Centrální zařízení musí odpovědět na každé přijaté hlášení mýtného tzv. odpovědí hlášení mýtného. Tato technická specifikace nedefinuje, které z nepovinných prvků atributu ChargeReportResponse jsou součástí odpovědi. POZNÁMKA Obsah odpovědi hlášení mýtného závisí na výrobní značce a typu daného frontend, na jeho aplikačním softwaru a softwaru centrálního zařízení, jak je definováno obchodními požadavky na jednotlivého poskytovatele služby. Tato technická specifikace pouze nabízí datové prvky pro odpověď, ale nezasahuje do implementace a obchodních voleb požadováním povinného obsahu. 6 Datové prvky 6.1 Úvod Datové prvky jsou seskupeny do logických datových skupin pouze pro účely čitelnosti: Datová skupina Hlášení obsahuje hlavní datové prvky komunikace hlášení mýtného 12

13 Datová skupina Obecné obsahuje datové prvky a typy, které nejsou explicitně součástí jiných skupin. Datová skupina Použití obsahuje informace nezbytné pro popis použití dopravní infrastruktury, která určuje vhodnost pro poplatky. Tato data jsou např. nezbytná pro výpočet poplatků a pro vystavení správných účtů a urovnání sporů. Hlavní datové prvky této skupiny jsou uvedeny v hlášení mýtného a odpovědích na hlášení mýtného, tedy usagestatementlist a datareceived. Datová skupina Účet obsahuje prvky nezbytné pro zajištění, že je zpoplatněn mýtným správný účet (a uživatel PK). Prvky této skupiny Účet se používají pro management účtů uživatelů PK ve frontend. Tyto frontend účty mohou obsahovat následující typy dat: Kredit: Účet vykazuje hodnotu odpovídající určitému peněžnímu obnosu. Vzdálenost: Účet vykazuje hodnotu představující vzdálenost. Čas: Účet vykazuje hodnotu představující určitý bod v čase. Trvání (lhůta): Účet vykazuje hodnotu představující určité trvání. Událost: Účet vykazuje hodnotu představující počet událostí. Hlavní datové prvky této skupiny jsou uváděny v hlášení mýtného a odpovědích na hlášení mýtného, tedy accountstatus a accountupdate. Datová skupina Verze obsahuje datové prvky pro aktualizaci verze palubního zařízení OBE. Datová skupina Kontrola shody obsahuje informace vyměňované v komunikaci kontroly shody (CCC), jak je definována v ISO TS Některá z vyměňovaných dat v rámci CCC jsou již pokryta jinými datovými prvky, ale pro úplnou informaci o obsahu CCC jsou data v této skupině nezbytná. 6.2 Hlášení Dva datové typy ChargeReport a ChargeReportResponse popisované v této kapitole pokrývají celou komunikaci hlášení mýtného. Datový typ chargereport obsahuje následující datové prvky: obeid, paymentmeans, serviceprovidercontract, tollcharger, timeofreport, versioninfo, usagestatementlist, vatforthissession, currency, accountstatus, transactioncounter, distancecounter, cccattributes, authenticator. Toto jsou základní datové prvky pro komunikaci mýtného. Datový prvek typu ChargeReport je zaslán zařízením frontend kdykoli je to potřeba pro přenos dat mýtného do centrálního zařízení. Hlášení obsahuje nezbytná data pro identifikaci již registrovaného palubního zařízení OBE a smlouvu. Přenese informace o použití zpoplatnění dopravní infrastruktury vozidlem a poskytne dodatečné informace pro ověřovací kontroly a účetní postupy (např. výpočty daně z přidané hodnoty VAT). 13

14 Datové prvky obsažené v této struktuře se týkají logických datových skupin a jsou podrobně vysvětleny v následujících článcích. V odpovědi na hlášení mýtného odpovídá centrální zařízení určitým datovým prkem typu ChargeReportResponse. Tento datový typ se skládá s následujících částí: reportrecipientid, datareceived, versionsresponse, obestatusfordriver, accountupdate, responseauthenticator. Tato data poskytují potvrzení přijetí dat na aplikační úrovni. Na základě toho je frontend poskytnuta zpětná vazba (např. požadavek na aktualizace, změna statutu OBE). Tyto datové typy a prvky obsažené v této struktuře a prvky, které tyto tvoří, se týkají logických datových skupin a jsou podrobně popsány níže. 6.3 Všeobecně Popis vozidla - vehicledescription Datový prvek vehicledescription obsahuje seznam charakteristik (vehiclelpnr, axles, class,dimensions, specificcharacteristics, ladenweight, weightlimits) vozidla. Datové typy těchto prvků jsou definovány v EN ISO a jsou odtud importovány Čas hlášení - timeofreport Datový prvek timeofreport udává data a čas, kdy bylo hlášení mýtného pro přenos sestaveno. Odpovídající datový typ DateAndTime je definován v EN ISO a je odtud importován Daň z přidané hodnoty pro tuto relaci - vatforthissession Datový prvek vatforthissession obsahuje nashromážděnou daň z přidané hodnoty VAT pro poplatky sdělované v příslušném hlášení mýtného. Jeho přidružený datový typ je Amount Množství - Amount Datový typ Amount představuje peněžní hodnotu v násobku jednotky měny definované datovým prvkem currency v příslušném hlášení mýtného Měna - currency Datový prvek currency obsahuje měnu pro poplatky a daň z přidané hodnoty VAT v hlášení mýtného. Příslušný datový typ PayUnit je definován v EN ISO a je odtud importován Počitadlo transakcí - transactioncounter Datový prvek transactioncounter udává pořadové číslo aktuálního hlášení mýtného. Toto počitadlo musí být navýšeno ve frontend po kompilaci hlášení mýtného, umožňující rozlišení mezi hlášeními mýtného. Rozmezí hodnoty tohoto počitadla a jeho chování v případě přeplnění je ponecháno na příslušné implementaci Počitadlo vzdálenosti - distancecounter Datový prvek distancecounter obsahuje čtení vnitřního virtuálního počitadla sazby za míli v čase kompilace příslušného hlášení mýtného, umožňující rozlišení mezi hlášeními mýtného. Rozmezí hodnoty tohoto počitadla a jeho chování v případě přeplnění je ponecháno na příslušné implementaci. 14

15 6.3.8 Vzdálenost - Distance Datový typ Distance obsahuje hodnoty vzdálenosti. První prvek (dist) je proměnnou semilogaritmické stupnice (typ ASN 1 REAL) obsahující samotnou hodnotu vzdálenosti, druhý prvek (disunit) se používá pro definování použité jednotky vzdálenosti. Může mít hodnoty kilometres, miles a metres Poloha - Position Datový typ position definuje geografickou polohu s prvky longitude a latitude příslušných typů definovaných v EN ISO 6709 a je odtud importován Perioda - Period Datový typ Period definuje periodu času definovanou datem a časem jejího počátku (beginofperiod) a jejího konce (endofperiod). Datové typy těchto prvků jsou definovány v EN ISO a jsou odtud importovány Trvání - Duration Datový typ Duration definuje časové rozpětí definované aktuální hodnotou (dur) typu ASN1 REAL, a příslušnou jednotkou (durunit), která může mít jednu z hodnot seconds, minutes, hours, days nebo months Autentizátor a autentizátor odpovědi - authenticator and responseauthenticator Datové prvky authenticator a responseauthenticator jsou oba datovým typem MessageAuthenticator, který obsahuje bezpečnostní kód typu ASN 1 BIT STRING, určeného pro implementaci bezpečnostních opatření. Lze je použít např. pro autentizace příslušné datové struktury, jejíž jsou součástí (skrze autentizační kód zprávy MAC nebo příznakem všech ostatních datových prvků). Volba konkrétních algoritmů pro aplikaci bezpečnostních opatření je mimo předmět této technické specifikace. 6.4 Smlouva ID palubního zařízení - obeid Datový prvek obeid je jedinečným identifikátorem palubního zařízení OBE. Skládá se ze dvou částí, první je jedinečnou identifikací výrobce OBE (manufacturerid) a druhý je specifickou identifikací konkrétního OBE výrobcem (EquipmentOBUId). Příslušné datové typy jsou definovány v EN ISO a jsou odtud importovány Platební prostředky - paymentmeans Datový prvek paymentmeans je jedinečnou identifikací jednotlivého účtu uživatele PK, příslušný datový typ je definován v EN ISO a je odtud importován Smlouva s poskytovatelem služby - serviceprovidercontract Datový prvek serviceprovidercontract identifikuje poskytovatele služby, jak je definováno v EN ISO 17573, a typ smlouvy, kterého se týkají data hlášení mýtného. Příslušný datový typ je definován v EN ISO a je odtud importován. POZNÁMKA Je na odpovědnosti poskytovatele služby, aby ve své databázi udržoval konzistentní vztah mezi obe- Id, paymentmeans a serviceprovidercontract Výběrčí mýtného - tollcharger Datový prvek tollcharger sestává ze dvou částí, identifikující dvě dílčí role výběrčího mýtného: operátora mýtného příslušného mýtného schématu (datový prvek efcoperator) a poskytovatele dopravní služby, příjemce shromážděných poplatků v tomto schématu (datový prvek recipient). 15

16 Datový typ Provider obou částí je importován z EN ISO ID hlášení příjemce - reportrecipientid Datový prvek reportrecipientid identifikuje entitu, která přijala příslušné sdělení o použití PK Status palubního zařízení OBE pro řidiče - obestatusfordriver Datový prvek obestatusfordriver obsahuje informace pro řízení prvků rozhraní člověk-stroj HMI, které zasílá status OBE a smlouvu řidiči. Předpokládají se následující hodnoty: ok, nok, contactoperator, nokinlocalcontext, nosignalling. Hodnota ok označuje, že OBE a smlouva jsou platné pro sběr mýtného v aktuálním kontextu; hodnota nok znamená, že existuje problém a uživatel PK musí provést určité kroky; hodnota contactoperator označuje, že se očekává kontaktování operátora od uživatele PK; hodnota nokinlocalcontext se použije pro případ, že místní výběrčí mýtného již neakceptuje palubní zařízení OBE nebo smlouvu, zatímco mohou být stále platné v jiných kontextech; hodnota nosignalling se použije pro případ, že se uživateli PK nezasílá žádné oznámení. 6.5 Použití Seznam sdělení o použití PK a sdělení o použití PK - usagestatementlist and UsageStatement Datový prvek usagestatementlist obsahuje seznam všech sdělení o použití PK (datový typ UsageStatement) příslušného hlášení mýtného. Datový typ UsageStatement obsahuje informace o aktuálním použití dopravní infrastruktury, které se požadují centrálním zařízením pro výpočet poplatků. Tento datový typ sestává z následujících částí: usagestatementid regimeid aggregatedfee aggregatedsingletariffclasssession listofchargeobjects listofrawusagedata nousage usageauthenticator Existují čtyři možnosti popisu použití dopravní infrastruktury, které jsou reprezentovány následujícími datovými prvky: aggregatedfee, aggregatedsingletariffclasssession, listofchargeobjects, listofrawusagedata. Je možná jakákoliv kombinace těchto možností. Pro speciální účely je také možné použít prázdné sdělení o použití. Takové lze označit příznakem nousage. 16

17 Na datový typ UsageStatement lze použít bezpečnostní opatření pomocí prvku UsageAuthenticator ID sdělení o použití - usagestatementid Datový prvek usagestatementid je identifikátorem příslušného sdělení o použití PK. Frontend musí přiřadit tento identifikátor a zajistit jeho jedinečnost v rámci hlášení mýtného ID režimu mýtného - regimeid Datový prvek regimeid je identifikátorem jednoho z režimů provozovaných výběrčím mýtného. Tento výběrčí mýtného musí přiřadit hodnoty v rámci jeho sféry Shromážděný poplatek - aggregatedfee Datový prvek aggregatedfee obsahuje časovou periodu pokrytou daným sdělením (timeperiodcovered) a celkové množství poplatků bez daně z přidané hodnoty VAT (feeexclvat) v násobku jednotky měny stanovené v chargereport, shromážděné za tuto časovou periodu danou v timeperiodcovered Relace shromážděné v rámci jednotarifní třídy - aggregatedsingletariffclasssession Datový prvek aggregatedsingletariffclasssession obsahuje tyto datové prvky: timeperiodcovered, vehicledescription, tariffclass, totaldistancecovered, numberofdetectedevents, feeexclvat Popisuje relaci jedné tarifní třídy, která je součástí určité cesty (jízdy) beze změn parametrů týkajících se poplatku. Tyto změny mohou nastat skrze změny v kategorii vozidla, třídy PK, denní doby apod. Obsažená informace je tato: časová perioda pokrytá sdělením (timeperiodcovered), příslušné vlastnosti vozidla (vehicledescription) a tarifní třídy (tariffclass), celkové vzdálenosti pokryté během části této cesty (totaldistancecovered), počet událostí, které se staly (numberofdetectedevents) a shromážděných poplatků v násobku jednotky měny, vyjma daně z přidané hodnoty (feeexclvat). Tarifní třída - tariffclass Datový prvek tariffclass obsahuje všechny informace nezbytné pro stanovení tarifní třídy ve třech datových prvcích. Příslušné parametry přidružené k těmto prvkům jsou třída polohy, třída času a třída uživatele. Třída polohy (locationclassid), např. dálnice nebo město, je stanovena podle místní definice příslušného mýtného schématu výběrčího mýtného. To samé platí pro třídu času (timeclassid), např. pracovní den nebo víkend. Třída uživatele (userclassid), např. identifikující řidiče jako hendikepovanou osobu je definována v EN ISO a je odtud importována Seznam zpoplatněných objektů a detekovaný zpoplatněný objekt - listofchargeobjects and DetectedChargeObject Datový prvek listofchargeobjects obsahuje řadu popisů zpoplatněných objektů (typ DetectedChargeObject), každý z nich obsahuje: ID detekovaného zpoplatněného objektu (chargeobjectid), čas průjezdu zpoplatněným objektem (timewhenused), popis příslušného vozidla (vehicledescription) a tarifní třídu (tariffclass), a výsledný poplatek v násobku jednotky měny, vyjma daně z přidané hodnoty (feeexclvat). Dodatečně mohou být zpoplatněné objekty označeny jako odvozené nastavením příznaku isinferredchargeobj na hodnotu TRUE. Odvozený zpoplatněný objekt je ten, který není detekován při posouzení dat primárního snímače používajícího regulérní pravidla definovaná pro rekognoskaci zpoplatněných objektů, ale odvozená z logického průběhu cesty. 17

18 ID zpoplatněného objektu - ChargeObjectId Datový prvek ChargeObjectId identifikuje zpoplatněný objekt (např. část PK, průchod kordonu) podle místní definice příslušného mýtného schématu výběrčího mýtného. Obsahuje identifikátor výběrčího mýtného pro režim mýtného, ke kterému náleží (regimeid), a označení (chargeobjectdesignation). POZNÁMKA Datový prvek regimeid lze zahrnout buď do datového prvku typu UsageStatement, nebo do datového prvku typu DetectedChargeObject. Druhá možnost se doporučuje pouze v případech, kde je pokryt více než jeden režim v jednom datovém prvku typu UsageStatement. Řešení nebo vynechání rozporů vznikajících při použití tohoto prvku paralelně na obou úrovních je ponecháno na konkrétní implementaci. Označení zpoplatněného objektu - chargeobjectdesignation Datový prvek chargeobjectdesignation sestává z ID (chargeobjectnumber), které je jedinečné v rámci příslušného režimu. Také obsahuje dodatečné číslo (subobjectnumber), které identifikuje podobjekt v rámci jednoho a toho samého zpoplatněného objektu. To je např. potřeba pro kordony, kde kordon je zpoplatněný objekt, ale existuje potřeba pro rozlišení mezi různými vjezdy výjezdy do/z tohoto zpoplatněného objektu. Tyto křižovatky kordonu jsou identifikovány čísly podobjektů Seznam nezpracovaných dat použití PK - ListOfRawUsageData Datový prvek ListOfRawUsageData obsahuje tři datové prvky: seznam (rawdatalist) obsahující sadu datových prvků (measuredrawdata) o poloze (measuredposition) a čase (timewhenmeasured), doprovázený daty vozidla (vehicledescription) a informací o tarifu (tariffclass) relevantního pro výpočet poplatku. POZNÁMKA Tato technická specifikace nedefinuje algoritmy komprese optimalizované pro nezpracovaná data o použití PK. Kompresi a redukci dat lze sice použít pro přenos dat, ale nejsou podporovány na aplikační úrovni Seznam dat o použití DSRC - ListOfDSRCUsageData Datový prvek listofdsrcusagedata je sám o sobě nepovinný a obsahuje dva nepovinné datové prvky: Datové prvky GetStampedTransactions a ReceiptDataList, kde každý prvek obsahuje počet samostatných zpráv, které byly zaslány mezi palubním zařízením OBE a zařízením na straně infrastruktury RSE podle EN ISO 14906: GetStampedTransactions: Seznam transakcí GetStampedRs, jak byly zaslány z OBE do RSE ReceiptDataList: Seznam ReceiptData, jak je definován v EN ISO POZNÁMKA Prvek listofdsrcusagedata podporuje použití autonomních zařízení frontend provozovaných v doménách EFC založených na DSRC. Obvykle výběrčí mýtného obdrží transakce DSRC skrze své RSE a přenese je v určitém čase poskytovateli služby pro kontrolu a vyrovnání. Kromě toho zde může být velký zájem operátora centrálního zařízení, aby získal kopii dat, přes celulární spojení CN, která jsou zasílána do jakéhokoliv RSE pro provedení kontrol konzistence nebo aktualizace centrálních účtů. V jiných scénářích může existovat požadavek na autonomní zařízení frontend provozované v doménách EFC založených na DSRC nezávisle na daném RSE. Mohou generovat platební transakci ve stejném formátu jako transakci DSRC a přenést ji skrze spojení CN do centrálního zařízení Přijatá data - DataReceived Datový prvek datareceived obsahuje informace o datech přijatých v odpovědi na hlášení mýtného. Příslušný datový typ DataReceived umožňuje zaslat čas hlášení (pomocí datového prvku timeofreport), odpovídající hodnotu počitadla vzdálenosti (pomocí datového prvku distancecounter), počitadla transakcí (pomocí datového prvku transactioncounter). 6.6 Účet Status účtu - accountstatus S každým hlášením mýtného má frontend možnost vykomunikovat status příslušného účtu. Příslušný datový prvek accountstatus může mít tyto hodnoty: ok, tj. obsahuje kladnou hodnotu nad definovanou mez low, tj. obsahuje kladnou hodnotu pod definovanou mez 18

19 empty, tj. obsahuje hodnotu nula negative, tj. obsahuje hodnotu nižší než nula Aktualizace účtu - accountupdate S každou odpovědí na hlášení mýtného lze účet ve frontend aktualizovat. Příslušný datový prvek accountupdate sestává ze tří částí za předpokladu tří možností pro aktualizaci účtu frontend: Buď se přidá předdefinovaná hodnota k aktuálnímu zůstatku na účtu (pomocí datového prvku reloadaccount), nebo se explicitně přenese nový zůstatek (pomocí datového prvku setaccount). Třetí možnost přidává danou částku na účet (pomocí datového prvku addtoaccount). Aktualizace nastavuje limity v kreditu, vzdálenosti, čase (definujíc bod v čase do vypršení platnosti), trvání (definujíc lhůtu do vypršení platnosti) nebo počet detekovaných událostí Znovuzavedení účtu - ReloadAccount Datový prvek reloadaccount je typu ReloadAccount, který obsahuje 5 Boolean datových prvků a datový typ reloadauthenticator. Hodnoty Boolean instruují aplikaci frontend, aby upřednostnila příslušný typ účtu s předdefinovanou hodnotou (true) nebo neupřednostnila (false). Předdefinovaná hodnota musí být nastavena předem, a to buď počátečním konfiguračním procesem pro frontend nebo použitím mechanismu aktualizace a datových prvků popsaných v části 3 této technické specifikace. Bezpečnostní opatření lze použít na datový prvek ReloadAccount pomocí prvku reloadauthenticator Limit nového účtu - NewAccountLimit Datový prvek setaccount je typu NewAccountLimit, který nastaví účet na konkrétní hodnotu. Tento datový typ obsahuje 5 prvků představující novou hodnotu pro konkrétní typ účtu. Hodnota je newcredit- Limit, newdistancelimit, newtimelimit, newdurationlimit, nebo neweventlimit, v závislosti na typu účtu. Bezpečnostní opatření lze použít na datový prvek NewAccount pomocí prvku NewAuthenticator AddToAccount Datový prvek addtoaccount je typu AddToAccount, který přidává konkrétní hodnotu na účet. Tento datový typ obsahuje 5 prvků představujících hodnotu, která se přidá na konkrétní typ účtu. Touto hodnotou je addcredit, adddistance, addtime, addduration, nebo addevents, v závislosti na typu účtu. Bezpečnostní opatření lze použít na datový prvek addtoaccount pomocí prvku addauthenticator. 6.7 Verze Informace o verzi - versioninfo Datový prvek versioninfo označuje současný status všech relevantních komponent frontend a musí se použít pro zajištění, aby verze všech dat, hardwaru a softwaru v procesu zpoplatnění byly aktuální. Je typu VersionID, který je ekvivalentní k typu octet string. Kódování, přesný obsah a interpretace tohoto prvku jsou ponechány na příslušné implementaci. Obsah tohoto datového prvku je definován aktorem odpovědným za aktualizaci dat pro frontend na aplikační úrovni. Udržuje informace pro stanovení verzí všech hardwarových, softwarových a datových komponent relevantních pro aktualizaci. Tudíž jej lze použít jak pro komunikaci současného statutu ve frontend, tak i pro stanovení potřeby aktualizací k dosažení platného statutu komponent frontend Odpověď na verzi - versionresponse Datový prvek versionresponse označuje status potřeby všech relevantních komponent frontend a musí být použit pro zajištění, aby verze všech dat, hardwaru a softwaru v procesu zpoplatnění byly aktuální. Buď označuje, že aktualizace jsou nezbytné ve frontend pro zajištění platné operace, nebo potvrzuje platnost verzí relevantních hardwarových, softwarových a datových komponent. Je typu VersionID, který je ekvivalentní k typu octet string. Kódování, přesný obsah a interpretace tohoto prvku jsou ponechány na příslušné implementaci. 19

20 6.8 Kontrola shody Atributy kontroly shody komunikace - CCCAttributes Data ve struktuře CCCAttributes jsou definovány v ISO TS a jsou odtud importovány. Prvky typu CCCAttributes obsahují informace, které lze vyměňovat podle ISO TS 12813, ale nejsou pokryty na žádném místě této technické specifikace ISO TS

21 Příloha A (normativní) Specifikace datových typů EFC ChargingModule {iso standard modules(0) efc(0) version(1) DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS EquipmentOBUId, PaymentMeans, EFC-ContextMark, Provider, DateAndTime, Driver- Characteristics, PayUnit, VehicleAxles, VehicleClass, VehicleDimensions, VehicleLicencePlateNumber, VehicleSpecificCharacteristics, VehicleWeightLaden, VehicleWeightLimits, GetStampedRs, ReceiptData, GetStampedRq FROM EfcModule {iso standard modules(0) efc(0) version(1) Longitude, Latitude FROM GeoRefData {iso standard 6709 modules (0) xxx (0) version (1) VehicleAxlesHistory, CommunicationStatus, GnssStatus, DistanceRecordingStatus,ActiveContext, ObeHistory FROM CccModule {iso standard modules(0) efc(0) version(1); -- NOTE: The following are the definitions of the EFC charge communication parameters Level ChargeReport ::= SEQUENCE { obeid EquipmentOBUId OPTIONAL, paymentmeans PaymentMeans OPTIONAL, serviceprovidercontract EFC-ContextMark OPTIONAL, tollcharger TollCharger OPTIONAL, timeofreport DateAndTime OPTIONAL, versioninfo usagestatementlist vatforthissession VersionID OPTIONAL, SEQUENCE OF UsageStatement, Amount OPTIONAL, currency PayUnit OPTIONAL, accountstatus transactioncounter distancecounter cccattributes authenticator... ChargeReportResponse ::= SEQUENCE { AccountStatus OPTIONAL, INTEGER OPTIONAL, Distance OPTIONAL, CCCAttributes OPTIONAL, MessageAuthenticator OPTIONAL, reportrecipientid Provider OPTIONAL,