CEN ISO TS 17575-2 - Elektronický výběr poplatků (EFC) – Definice aplikačního rozhraní pro autonomní systémy – Část 2: Komunikace a propojení s nižšími vrstvami

Úvod

Tato technická specifikace je součástí souboru čtyř specifikací definujících výměnu informací mezi tzv. frontend a centrálním systémem elektronického výběru poplatků (Electronic Fee Collection (EFC)) založeném na autonomním palubním zařízení (OBE). Systémy mýtného automaticky sbírají data zpoplatnění za použití dopravní infrastruktury včetně dálničních úseků, 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í.

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

Frontend zpracovává polohové údaje získané pomocí satelitní lokalizace, které jsou často zpřesněné pomocí údajů z přídavných snímačů, jakými jsou gyroskopy, tachometry a akcelerometry. Takto získané pozice vozidla se vyhodnocují vzhledem ke geografickým objektům, které jsou definovány v těchto technických specifikacích. Vyhodnocovat se může ujetá vzdálenost, čas pohybu nebo stání, nebo počet průjezdů daným geografickým objektem, který může být definován jako zpoplatněná oblast, úsek pozemní komunikace (PK), nebo jako bod na PK. Kromě zpoplatněných objektů jsou dále touto technickou specifikací stanoveny charakteristiky vozidla, denní doba a jiná data, která ovlivňují výši poplatku za použití PK a způsob jakým má frontend informovat centrální systém o použití zpoplatněných objektů.

Cílem všech 4 částí CEN ISO TS 17575 je jednoznačně definovat rozhraní pro dosažení interoperability mezi systémy a přitom umožnit pokračování výběru mýta dle pravidel definovaných ve stávajících systémech zpoplatnění používaných v Evropě. Problematika je rozdělena na čtyři části, které postupně definují

• datové struktury sloužící k odesílání hlášení o použití zpoplatněných objektů (část 1),

• rozhraní komunikační vrstvy na úrovni API, které je určeno k předávání těchto struktur, přičemž přenosový protokol a kódování dat je ponecháno na implementátorovi (část 2),

• pravidla podle kterých se v určité oblasti (doméně) bude stanovovat mýtné a dále definuje zpoplatněné objekty v této oblasti (část 3),

hranice domén a vazby mezi sousedními doménami; domény se mohou překrývat, přecházet jedna ve druhou, a nebo může stanovování mýtného probíhat ve dvou doménách paralelně (část 4).

Užití

Všechny čtyři části CEN ISO TS 17575 jsou důležité pro poskytovatele služeb i pracovníky státní správy. 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.
 

1. Předmět normy

Tato technická zpráva se zabývá komunikací a propojením s nižšími komunikační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 služba zahrnuje autentizované služby čtení a zápisu se všemi funkcemi požadovanými pro bezpečný přenos dat.

Konkrétně definuje postup volání funkcí, které vedou k inicializaci transakce. Abstraktní API pro komunikační služby lze implementovat v jakémkoliv programovém prostředí, které definuje koncept zpětného volání, umožňující API volat aplikaci frontend pro sdělení informace nebo zaslání výsledků operace. Obecné pořadí událostí je toto:

• Inicializace a parametrizace komunikačního rozhraní;

• Ustavení relace komunikace;

• Přenos dat v kontextu relace;

• Ukončení relace komunikace;

• De-inicializace komunikačního rozhraní.

V běžném případě frontend inicializuje (určitý počet) komunikačních rozhraní, když je poprvé zapnuto. Aktivní relace je poté ustavena jako přímá akce FE nebo jako odpověď na příchozí požadavek na relaci od CE. Chronologický tok událostí, jak je uveden výše, je pokryt v článcích, které následují a je odkazován na definici abstraktního API uvedenou v příloze E.

2. Souvisící normy

Tato norma úzce souvisí s normou na architekturu mýtných systémů EN ISO 17573.

3. Termíny a definice

Kapitola 3 obsahuje 16 termínů, z nichž nejdůležitější jsou uvedeny níže:

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 17573 se v této technické specifikaci předpokládá, že Front End obecně komunikuje s komponentami centrálního zařízení řízeného a provozovaného poskytovatelem služby

3.5 Front End (Front End) čá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í. Front End sestává z palubního zařízení a nepovinné proxy

3.8 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í

4. Symboly a zkratky

Kapitola 4 obsahuje 9 zkratek, z nichž nejdůležitější jsou uvedeny níže:

4.1 ADU- Application Data Unit [EN ISO 14906:2004] – Datová jednotka aplikace

4.2 APDU- Application Protocol Data Unit [EN ISO 14906:2004] – Datová jednotka aplikačního protokolu

4.8 GNSS- Global Navigation Satellite Systems – globální navigační satelitní systémy

5 EFC komunikační architektura front-end

Pro ustavení komunikačního spojení mezi Front End a systémy centrálního zařízení, označované Back End, se požaduje komunikační subsystém. Poskytuje infrastrukturu přenosu pro relace komunikace, které probíhají přes červenou čáru uvedenou na obrázku 4. Pro případ, kdy je proxy součástí systém Front End definuje subsystém komunikace mezi CE a Proxy. Spojení mezi Proxy a OBE je mimo předmět této specifikace. Pro případ, že není žádná Proxy („tlustý klient“) definuje subsystém komunikace mezi OBE a CE.

Komunikační subsystém je dále členěn na dvě odlišné komponenty. Samotné API komunikací nabízí komunikační funkcionalitu do Front End. Pod tím existuje technologie komunikace nižších vrstev, která poskytuje funkcionalitu, kterou API abstrahuje. I když je API nezávislé na technologii nižších vrstev, klade na něj několik požadavků. Z tohoto důvodu jsou v článku 8.2 uvedeny funkční požadavky na komunikaci nižších vrstev.

Článek 5.2 uvádí přehled požadavků, které řídí definici komunikací API.

Článek 5.3 komentuje vztahy k obecné architektuře EFC.

6 Inicializační transakce

API přenáší dva „typy“ zpráv. Strukturované prvky s přímou vazbou na definice v části 1 a části 3 této technické specifikace a nestrukturované prvky, které jsou mimo předmět této specifikace a nepřijímá žádné další předpoklady s tím spojené.

7 Služby komunikace EFC (funkce)

Abstraktní API pro komunikační služby lze implementovat v jakémkoliv programovém prostředí, které definuje koncept zpětného volání, umožňující API volat aplikaci Front End pro sdělení informace nebo zaslání výsledků operace. Obecné pořadí událostí je toto:

• Inicializace a parametrizace komunikačního rozhraní;

• Ustavení relace komunikace;

• Přenos dat v kontextu relace;

• Ukončení relace komunikace;

• De-inicializace komunikačního rozhraní.

Kapitola dále podrobně popisuje všechny tyto události, pro přehled je uveden obrázek 6.

8 Použití sestavy komunikačních protokolů (komunikačního stacku)

Technická specifikace umožňuje současné použití více komunikačních technologií a pro Front End schopnost volby mezi nimi pro zvolení nejvhodnější technologie pro konkrétní komunikaci. Předpokládá se, že tato schopnost bude užitečná pro multimodální OBE, které je schopno používat různé technologie v závislosti na naléhavosti komunikace, jejich schopnosti a dosahu dostupných infrastruktur. Nicméně existuje jistý počet funkcí nižší úrovně, které jakákoliv komunikační technologie (nebo raději sestava protokolů, na kterých je technologie postavena) musí poskytovat. Článek 8.2 dále obsahuje požadavky, z nichž jsou pro příklad uvedeny UTR1: musí být schopna podpory nebo emulace „relace“ a UTR2: musí být schopna spolehlivého dodání datových prvků, v sekvenci, obousměrně přes spojení a UTR9: musí být schopna přenosu příslušného množství dat. Článek 8.3 dále specifikuje mobilní ukončovací volání. Přístup zvolený v této technické specifikaci totiž nikdy nevyžaduje otevřený příchozí komunikační port v daném pásmu. Pokud CE si přeje vytvořit spojení do Front End za jakýmkoliv účelem, může k tomuto účelu použít signalizaci mimo pásmo a použité mechanismy jsou mimo předmět této specifikace. Rozsah možností mimo pásmo je značný (zprávy SMS, stisknutí tlačítka na jednotce, vysílání signálu apod.) a Front End je tím zabezpečenější.

Důsledkem tohoto přístupu je fakt, že nikdy neexistuje žádný požadavek na koncový bod s IP adresou pro mobilní ukončovací volání. Tím nevzniká potřeba bezpečnostních opatření popisovaných výše a také zjednodušují záležitosti překladu síťové adresy a soukromých podsítí, neboť Front End bude potřebovat vytvořit vždy pouze odchozí spojení.

Příloha A (normativní) Definice abstraktního API

Komunikační API sestává z API směrem dolů (‘down’ API) z Front End do sestavy komunikačních protokolů a z API směrem nahoru (‘Up’ API), ze sestavy komunikačních protokolů do Front End. Každému je věnován samostatný článek.

Příloha B (informativní) Formulář protokolu o shodě implementace PICS

Tato příloha obsahuje formulář protokolu o shodě implementace (PICS), který se použije pro implementaci komunikačních služeb v OBE, jak je definováno v kapitolách 6, 7 a 8.

Pro příklad je uvedena tabulky s podporou transakcí „down“ API.

Příloha C (informativní) Příklady definicí pro příslušné jazyky

API bylo volně navrženo jako neutrální s ohledem na jazyk s předpokladem, že existuje mnoho různých prostředí, ve kterých bude používáno. Obecně by API mělo být implementováno způsobem, který je kompatibilní s obecným použitím a styly daného jazyka se zachováním obecného charakteru a provozu API. Příloha obsahuje příklad definice API v jazyku C.