CEN ISO TR 24014-1 - Veřejná doprava osob – Interoperabilní systém managementu jízdného - Část 1: Architektura

Aplikační oblast: Platební systém a pravidla, Veřejná doprava osob

PDF

Rok vydání normy a počet stran: Vydána 2007, 70 stran

Zavedení normy do ČSN: vyhlášením

Rok zpracování extraktu: 2009

Skupina témat: Inteligentní prodej jízdenek

Téma normy: Interoperabilní systém managementu sběru jízdného

Charakteristika tématu: Popis architektury IFM a případy užití

Úvod, vysvětlení východisek
Popis architektury, hierarchie, rolí a vztahů objektů

Popis vztahů mezi rolemi IFM

Popis procesu / funkce / způsobu použití

Klasifikace případů užití; identifikace odlišného souborů funkci ve vztahu k IFM

Popis rozhraní / API / struktury systému

Bezpečnostní pravidla

Definice protokolu / algoritmu / výpočtu
Definice reprezentace dat / fyzikálního významu
Definice konstant / rozsahů / omezení

Úvod

Norma definuje základní prvky systému managementu jízdného a jeho architekturu; klade důraz na identifikaci subjektů a bezpečnost dat. Toto umožňuje ověřením integrity zprávy identifikací entit, objektů aplikací, produktů atd.


 

Témata dále uvedená naopak nejsou předmětem této normy:

  • přímé placení, konvenční peněžní převody, platby prostřednictvím jízdenek nebo lístků s magnetickým páskem, i když i tyto způsoby mohou být používány souběžně s popisovaným systémem;

  • systém platby popsaný v ISO 14904;

  • struktury platebních karet, rozhraní a výměna dat mezi platebními kartami a čtečkami karet pro veřejnou dopravu osob.

Poznámka: Extrakt uvádí vybrané kapitoly popisovaného dokumentu a přejímá původní číslování kapitol.

Užití

V České republice se zatím v úvodě popsaný platební systém ve větším rozsahu nezavádí a používá se zatím pouze v omezeném rozsahu v rámci integrovaných dopravních systémů, kdy jediným platebním mediem je tištěná jízdenka.

Tato norma byla zpracována jako evropská, ale univerzálnost jejího pojetí a kvalita vedla k jejímu přijetí v rámci ISO. Vzhledem k tomu, že možnost jednotného platebního dokladu po celou dobu jízdy různými dopravními prostředky provozovanými více operátory a jednotné zúčtování mezi bankovními účty operátorů a cestujících je vysoce perspektivní, mělo by být zavedení této normy v praxi zájmem nejen operátorů, ale i správních orgánů a finančních ústavů.

1. Předmět normy

Předmětem normy je definovat referenční funkční architekturu pro IFMS a stanovit požadavky, které jsou důležité pro zajištění interoperability mezi několika aktéry v souvislosti s používáním elektronických jízdenek.

2. Souvisící normy

Tato norma volně navazuje na dále uvedené:

  • EN ISO 14904 Elektronické vybírání poplatků (EFC) – Specifikace rozhraní pro platební styk mezi operátory

  • EN ISO 17573 Dopravní telematika – Elektronický výběr poplatků (EFC) – Architektura systému pro dopravní služby souvisící s vozidly

  • Stávající mezinárodní normy týkající se zabezpečení přenášených dat;

  • EN 12896 Dopravní telematika – Veřejná doprava osob – Referenční datový model (Transmodel)

3. Termíny a definice

Interoperabilita (Interoperability)

pro potřeby této normy znamená cestovat více druhy dopravních prostředků provozovaných různými operátory s jediným jízdním dokladem, bez ohledu na to, který oprávněný činitel doklad vystavil či verifikoval.

Další termíny a zkratky z oboru ITS jsou obsaženy ve slovníku ITS terminology (www. ITSterminology.org).
Další termíny a zkratky z oboru ITS jsou obsaženy ve slovníku ITS terminology.

4. Symboly a zkratky

IFM (Interoperable Fare Management)  Interoperabilníh management jízdného (IFM)

IFMS (Interoperable Fare Management) Interoperabilní systém managementu jízdného

4 Požadavky

Specifické požadavky na interoperabilní systém managementu jízdného (Interoperable Fare Management System), dále zkráceně IFMS nebo FMS, jsou:

  • Uživatel musí mít možnost cestovat se všemi participujícími operátory (hladká jízda) za použití jediného (platebního) media.

  • Systém musí mít schopnost extrahovat data odpovídajícně dělení plateb a statistickým požadavkům dopravních operátorů.

  • Možnost může být využita k využití přenosového media pro jiné aplikace a kombinovat je s dopravními aplikacemi.

  • Metody prodeje lístků spojené s aplikací nabídnou příležitost ke zkrácení času nástupu a výstupu z dopravních prostředků a mohou podstatně redukovat náklady na manipulaci s placením.

  • Systém musí vyhovovat evropské ochraně dat a pravidlům pro finanční služby a utajení dat.

  • Systém musí být schopen přizpůsobit se specifikacím nových produktů bez ohledu na již existující.

  • Systém musí rozpoznat a chránit od interních a externích podvodných útoků.

  • Systém musí chránit soukromí uživatelů.

  • Systém musí garantovat integritu vyměňovaných dat.

  • Systém musí umožnit implementovat doplňkové služby tj. věrnostní programy, car sharing, park & ride, bike & ride.

Systém musí zajistit definici rozhraní mezi jednotlivými identifikovanými funkcemi ve veřejné dopravě aby byla umožněna interoperabilita mezi sítěmi různých operátorů.

5 Koncepční rámec

V kapitole 6 je popsán koncepční rámec IFMS na základě definovaných entit. Nejběžnější entity jsou spolu s výkladem uvedeny v tabulce 1:

Tabulka 1 – Definice entit užívaných v IFMS

Název entity

Český překlad

definice a funkce

Produkt

Produkt

Případ formuláře produktu na mediu uloženém v aplikační poznámce.

Je určen jedinečným identifikátorem a umožňuje zákazníkovi využívat služeb servisního operátora. Praktický příklad produktu je v tabulce 2.

Product Specification

Specifikace produktu

Úplná specifikace funkcí, datových elementů a bezpečnostního schématu podle pravidel produktu.

Medium

Medium

Fyzický nosič aplikace

Product Owner

Vlastník produktu

Vlastník produktu je odpovědný za svůj produkt

Product Retailer

Prodejce produktu

Prodejce produktu prodává a uzavírá produkty, sbírá a splácí hodnotu zákazníkovi, jak je autorizován vlastníkem produktu. Prodejce produktu je jediným finančním rozhraním mezi zákazníkem a IFMS, vztaženým k produktu.

Application Retailer

Prodejce aplikace

Prodejce aplikace prodává a uzavírá aplikace, sbírá a splácí hodnotu zákazníkovi, jak je autorizován vlastníkem aplikace. Prodejce produktu je jediným finančním rozhraním mezi zákazníkem a IFMS, vztaženým k aplikaci.

Collection and Forwarding

Sběr a zasílání

Úloha sběru a zasílatelství je usnadnění výměny dat v IFMS. Hlavní funkcí je sběr a zasílání dat.

Service Operator

Provozovatel služby

Provozovatel služby zajišťuje služby vůči zákazníkovi při použití produktu

Application Owner

Vlastník aplikace

Vlastník aplikace je držitelem aplikačního kontraktu se zákazníkem

Customer Service Subject (to commercial agreements)

Subjekt pro zákaznický servis

Zákaznický servis zajišťuje „pomocnou linku“ včetně provedení náhrady poškozeného zákaznického media a příslušnou reinstalaci produktu

Customer

Zákazník

Zákazník je držitelem aplikace a osvojuje si produkt, za účelem využívání služeb veřejné dopravy osob.

Security Manager

Bezpečnostní manažer

Bezpečnostní manažer je odpovědný za vybudování a koordinaci bezpečnostní politiky a za certifikaci organizací, využívání formulářů, komponentproduktů.

Registrar

Registrátor

Registrátor po certifikaci vydává registrační kódy pro organizace, komponenty, aplikační formuláře a formuláře produktů.


 

V tabulce 2 je uveden příklad produktu, který umožňuje cestujícímu díky IFMS využívat služeb veřejné dopravy osob v rozsahu daném podmínkami produktu.

Tabulka 2 – Příklad produktu s jeho podmínkami

PRODUKT

PODMÍNKY POUŽITÍ

CENOVÉ PODMÍNKY

OBCHODNÍ PODMÍNKY

Dospělá osoba – jedna jízda

Platí pro všechny dny v týdnu od 6:00 do 23:00.

Platí pro jednu osobu ve věku 15 – 65 let.

Platí pro jednu jednosměrnou jízdu uvnitř nebo mezi pásmy specifikovanými produktem.

Platí pro všechny dopravní prostředky.

Základní poplatek + pásmo navíc;

Předplaceno prodejci produktů;

Bez diskontu;

 


Nebude refundováno.

95% servisní prodejce;

3% prodejce produktu;

2% vlastník produktu


 

Využití, funkce a vazby mezi entitami v modelovém příkladu systému interoperabilního managementu jízdného jsou znázorněny na obrázku č.1

Obrázek 1 – Příklad konceptuálního modelu IFMS se znázorněnými komunikačními vazbami mezi entitami

6 Popis případů užití

Tato kapitola popisuje soubor 32 případů užití IFMS a jejich implementaci v praxi v dále uvedených oblastech:

Jako příklad je tabulkovou formou uveden případ užití pro distribuci formuláře produktu

Tabulka 2 – Příklad případu užití: Distribuce formuláře produktu

Název případu užití

Distribuce formuláře produktu

Přehled

Distribuce registrovaného formuláře produktu umožňujícího autorizovaným účastníkům zpracovávat produkt.

Entita, která spouští

Vlastník produktu

Účastníci

Operátor sběru a zasílání, Prodejce produktu, Servisní operátor, Vlastník produktu

Popis případu užití

Distribuce formuláře produktu je tvořena tímto postupem:

Zaslání formuláře produktu vlastníkem produktu operátoru sběru a zasílání.

Zaslání formuláře produktu operátorem sběru a zasílání autorizovanému prodejci produktu.

Zaslání formuláře produktu operátorem sběru a zasílání autorizovanému servisnímu operátorovi.


 

7 Identifikace systémových rozhraní

Tato kapitola, vyhrazená informacím o rozhraních, odkazuje na 2. část popisované normy, která se připravuje.

8 Identifikace

8. kapitola je věnována identifikaci, tj. její důležitosti a možnosti provedení. Identifikací je míněn soubor atributů, které popisují specifickou osobu nebo objekt způsobem, který je jednotný a jednoznačný.

Minimálně ty objekty, které jsou dále uvedeny, musí mít v IFMS jednotnou identitu:

  • všichni účastníci zapojení do IFMS, tj. všechny produkty a vlastníci aplikací, prodejci a servisní operátoři;

  • všechny aplikační formuláře;

  • všechny aplikace (implementované a inicializované aplikačními formuláři);

  • všechny formuláře produktů;

  • všechny produkty (případy formulářů produktů);

  • všechny komponenty.

9 Bezpečnost v systémech IFM

Tato kapitola se zabývá bezpečností dat v IFMS. Je konstatováno, že v IFMS jsou subjekty možné k podvádění nejen zákazníky a operátory, ale také lidmi mimo IFMS. Bezpečnostní jištění pro IFMS umožní chránit zájmy veřejnosti a aktiva v systému. V kapitole jsou dále uvedena rizika a potřebná opatření.

Jsou definovány základní požadavky na bezpečnost dat:

  • Informace nesmí být k dispozici nebo zveřejněny bez autorizace.

  • Informace nesmí být měněny nebo porušeny bez autorizace.

  • Identita subjektu nebo zdroje musí být věrohodná.

  • Ochrana proti chybné záporné odpovědi od entity po vytvoření zprávy tj. „Nebyl jsem tam“.

  • Ochrana proti chybné záporné odpovědi od entity po vytvoření zprávy tj. „Nikdy jsem neobdržel černou listinu“.

  • Každá zpráva musí být jednotná.

  • Management tajného klíče musí být v souladu s IFM postupy.

  • Management bezpečnostního seznamu musí být v souladu s IFM postupy.

Příloha A (informativní) Informační toky uvnitř IFM

Tato příloha popisuje tok informačních datrámci IFM. Článek A.1 se zabývá rozhraními k hlavním funkcím IFM: certifikace a registrace. Rozhraní mezi entitami uvnitř IFM jsou popsány v článcích A.2 až A.6.

Příloha B (informativní) Příklady implementací

V příloze jsou popsány implementace IFMS v Oslo, Paříži a Japonsku.

Jako příklad je uvedena aplikace v Paříži, kde jsou propojeni tři operátoři, jak je ukázáno na obrázku B1.

Obrázek B1 – Příklad IFM modelu aplikovaného pro regionální dopravu v oblasti Paříže pro operátory RATP, SNCF a OPTLE.

 

Příloha C (informativní) Seznam termínů, které jsou definovány jak v této části ISO 24014 (IFMSA), tak v dokumentu APTA – UTFS

Příloha D (informativní) Příklad seznamu akčních procesů

Příloha E (informativní) Bezpečnostní doména, hrozby a ochranné profily

podrobněji rozvíjejí a upřesňují informace ze základní části.

Výběr podle typu

Výběr podle aplikačních oblastí