Zuzana Švédová, Marek Ščerba, Tomáš Chlebničan

Zuzana Švédová, Marek Ščerba, Tomáš Chlebničan SW platforma pro sdílení implementaci dat ve veřejné osobní dopravě v reálném čase přes softwarovou aplikaci CISReal CERTIFIKOVANÁ METODIKA Centrum dopravního výzkumu, v.v.i. CHAPS s.r.o 2014

Autoři:

Ing. Tomáš Chlebničan Mgr. Marek Ščerba Ing. Zuzana Švédová

Název:

SW platforma pro sdílení a implementaci dat ve veřejné osobní dopravě v reálném čase přes softwarovou aplikaci CISReal

Vydavatel:

Centrum dopravního výzkumu v.v.i.

Náklad: Vydáno v roce:

2014

Kontakt na autory:

[email protected] [email protected]

Marek Ščerba, Tomáš Chlebničan, Zuzana Švédová

SW platforma pro sdílení a implementaci dat ve veřejné osobní dopravě v reálném čase přes softwarovou aplikaci CISReal Certifikovaná metodika

Centrum dopravního výzkumu, v.v.i. CHAPS s.r.o

2014

Certifikovaná metodika byla vypracována za finanční podpory a použití výsledků řešení výzkumného projektu TAČR TA01030582 Jednotný systém dat ve veřejné dopravě s ohledem na aplikaci standardního formátu s možností propojení stávajících systému do jednotné SW platformy.

Oponenti: Ing. Jiří Matějec SDT Sdružení pro dopravní telematiku Ing. Jana Vajdíková Krajský úřad Moravskoslezského kraje, Odbor dopravy.

4

Obsah I

Cíl metodiky ...................................................................................................................... 7

II

Vlastní popis metodiky .................................................................................................... 10

1

Úvod............................................................................................................................... 10 1.1. 1.2.

2

OBECNĚ .................................................................................................................................. 10 OBLAST PŮSOBNOSTI ................................................................................................................. 10 Informační systémy ......................................................................................................... 11

2.1. 3

DYNAMICKÝ DISPEČINK .............................................................................................................. 11 SW platforma – návrh organizace systému veřejné dopravy s centrálním prvkem CISReal . 13

3.1. 3.2. 3.3. 3.4. 3.5. 4

INFRASTRUKTURA – DATA Z VOZIDEL ............................................................................................ 13 DISPEČINKY JEDNOTLIVÉHO DOPRAVCE ......................................................................................... 14 DISPEČINK PROVOZUJÍCÍ VÍCE DRUHŮ DOPRAVY.............................................................................. 15 DATA V ISR ............................................................................................................................. 16 PŘENOS VOZIDLO – DISPEČINK .................................................................................................... 19 Metodika sběru dat - Popis systému CISReal .................................................................... 27

4.1. 4.2. 4.3. 4.4. 4.5. 4.6.

VLASTNOSTI CISREAL ................................................................................................................ 28 FUNKCE SYSTÉMU ..................................................................................................................... 29 STANDARDNÍ FUNKCE SYSTÉMU ................................................................................................... 29 PROCESNÍ STRUKTURA MODULŮ .................................................................................................. 30 PRINCIP ŘEŠENÍ CISREAL ............................................................................................................ 30 METODIKA SBĚRU DAT - KOMUNIKACE MEZI ÚČASTNÍKY – TYPY KOMUNIKACE ..................................... 34

5

Definice aplikační logiky souboru technických specifikací SIRI........................................... 37

6

Názvosloví veřejné dopravy v oblasti informačních systémů............................................. 40

7

Názvosloví – datové prvky CEN/TS 15531-1-3 SIRI ............................................................ 43

8

Forma sběru dat - Informace přijímané službou systému CISReal ...................................... 48

9

Distribuční rozhraní - Informace publikované službou systému CISReal............................. 58

10

Softwarová platforma ..................................................................................................... 92

III

Srovnání „novosti“ postupů............................................................................................. 93

IV

Popis uplatnění certifikované metodiky ........................................................................... 93

V

Ekonomické aspekty........................................................................................................ 93

VI

Seznam použité literatury................................................................................................ 94

5

Seznam obrázků Obrázek 1: Hierarchická struktura informační architektury systému veřejné dopravy s centrálním prvkem CISReal .......... 13 Obrázek 2: Návrh standardního IDS ISR ................................................................................................................................. 16 Obrázek 3: Celková koncepce ................................................................................................................................................ 28 Obrázek 4: Globální autorita CISReal pro interoperabilitu veřejné dopravy v České republice ............................................ 29 Obrázek 5: Struktura modulů systému CISReal ..................................................................................................................... 30 Obrázek 6: CISReal ................................................................................................................................................................. 31 Obrázek 7: Způsob komunikace Dotaz/Odpověď .................................................................................................................. 34 Obrázek 8: Způsob komunikace Publish/Subscribe ............................................................................................................... 36 Obrázek 9: Zobrazení struktury služeb podle normy SIRI (CEN/TS 15531-1 až 3) ................................................................. 38 Obrázek 10 – Základní model případu použití systému CISReal (včetně nadstavbových funkcionalit)................................. 86 Obrázek 11 – Základní UML model případu použití systému CISReal (včetně nadstavbových funkcionalit) ........................ 87

6

I

Cíl metodiky

Cílem certifikované metodiky je poskytnout uživateli metodiky přehled informací o vybavení a funkci informačního systému (dále jen IS) pro veřejnou dopravu (dále jen VD) s následnou možností sdílení informací v reálném čase přes navržený datový model. Dále metodika popisuje možnost komunikace přes navržený centralizovaný prvek CISReal. Specifikuje minimální požadavky pro komunikaci mezi dispečerskými systémy jednotlivých dopravců, dopravních systémů (MHD, IDS) a provozovatele dráhy (SŽDC)1, (dále jen účastníci), prostřednictvím navrženého datového modelu. Tato metodika je vydávána v návaznosti na novou technickou specifikaci ČSN 01 8245 Informační systém ve veřejné dopravě osob – Celostátní systém informací v reálném čase ( CISReal). Dále cíle metodiky korespondují se směrnicí 2010/40/EU2 které uvádí, že ITS by měly stavět na interoperabilních systémech založených na otevřených a veřejných normách a dostupných na nediskriminačním základě všem dodavatelům a uživatelům aplikací a služeb. Tato metodika je první částí z celkového souboru připravovaných metodik vztahujících se k oblasti sdílení informací ve veřejné dopravě v reálném čase.

1

Centrální dispečerský systém

2

http://eur-lex.europa.eu/legal-content/CS/TXT/PDF/?uri=CELEX:32010L0040&from=EN

7

SEZNAM ZKRATEK AVL AVMS API CDIS CDV CEN CIS JŘ CISReal ČVUT DIC DIS DD EU GPS ID IDS ISR IZS JDF JŘ JSDI MHD NDIC PD SJŘ SIRI SW TS VD

8

Automatic vehicle location Automatic vehicle monitoring systém APPLICATION PROGRAMMING INTERFACE Centrální dispečink Centrum dopravního výzkumu Evropské centrum pro normalizaci Centrální informační systém o jízdních řádech Centrální systém informací v reálném čase České vysoké učení technické Dopravně informační centrum Dispečink Dynamický dispečink Evropská unie Global positioning systém Jednoznačná identifikace (jedná se kód) Integrovaný dopravní systém Informační systém v reálném čase Integrovaný záchranný systém Jednotný datový formát Jízdní řád Jednotný systém dopravních informací Městská hromadná doprava Národní dopravní informační centrum Příprava a zpracování dat Správa jízdních řádů Service protocol for real time information (CEN 15 538) Software Technická specifikace Veřejná doprava osob

Souvisící právní předpisy • Bílá kniha – Plán jednotného evropského dopravního prostoru – vytvoření konkurenceschopného dopravního systému účinně využívajícího zdroje3 • Směrnice Evropského parlamentu a Rady 2010/40/EU ze dne 7. července 2010 o rámci pro zavedení inteligentních dopravních systémů v oblasti silniční dopravy a pro rozhraní s jinými druhy dopravy 4 • Směrnice Evropského parlamentu a Rady 95/46/ES ze dne 24. října 1995 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů 5 • Nařízení Evropského parlamentu a Rady (ES) č. 45/2001 ze dne 18. prosince 2000 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů orgány a institucemi Společenství a o volném pohybu těchto údajů • Zákon č. 111/1994 Sb. o silniční dopravě, ve znění pozdějších předpisů • Zákon č. 194/2010 Sb. o veřejných službách v přepravě cestujících a o změně dalších zákonů • Zákon č. 266/1994 Sb. o drahách, ve znění pozdějších předpisů • Zákon č. 125/2005 Sb. o elektronických komunikacích a o změně některých souvisejících zákonů • Vyhláška č. 388/2000 Sb. o jízdních řádech veřejné linkové dopravy • Vyhláška č. 175/2000 Sb. o přepravním řádu pro veřejnou drážní a silniční osobní dopravu • ČSN 73 6425 -2 Autobusové, trolejbusové a tramvajové zastávky, přestupní uzly a stanoviště - Část 2: Přestupní uzly a stanoviště

3

KOM(2011) 144 v konečném znění /http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2011:0144:FIN:CS:PDF

4

Úř. věst.L 207/1 http://eur-lex.europa.eu/legal-content/CS/TXT/PDF/?uri=CELEX:32010L0040&from=EN

5

Úř. věst. L 281

9

II

Vlastní popis metodiky

1

Úvod

1.1.

Obecně

Směrnice pro ITS (2010/40/EU) ustavuje právní a koncepční rámec s cílem urychlit koordinovanou implementaci inteligentních dopravních systémů v Evropě. Dále uvádí, že ITS by měly stavět na interoperabilních systémech založených na otevřených a veřejných normách a dostupných na nediskriminačním základě všem dodavatelům a uživatelům aplikací a služeb. V návaznosti na tuto směrnici vyvstala potřeba stanovit minimální požadavky na informační systémy ve veřejné dopravě (VD) tak, aby bylo možné stávající i nově vznikající systémy integrovat, a tím poskytovat ucelené cestovní informace i cestujícím. Vzhledem k tomu, že nabídka služeb mobility se neustále rozšiřuje a zároveň stoupá poptávka po úplných, spolehlivějších, aktuálních a snadno dostupných dopravních informacích, jsou informace v současné době důležitým prostředkem k podpoře přechodu na udržitelnější způsoby využívání dopravních prostředků. Proto se v dnešní době klade důraz na propojení informací pro možnosti multimodálního evropského plánovače. Jednou z alternativ řešení je vytvořit kvalitní a spolehlivý systém informací v jednotlivých členských státech evropského společenství.

1.2.

Oblast působnosti

Metodika se vztahuje na způsob výměny dat a minimální požadavky pro komunikaci mezi dispečerskými systémy jednotlivých dopravců, dopravních systémů (MHD, IDS) a provozovatele dráhy (SŽDC), (dále jen účastníci). Navrhuje a popisuje možnost výměny dat přes softwarovou platformu CISReal. Volně doplňuje normu ČSN 01 8245, která byla zpracována Centrem dopravního výzkumu v.v.i. a společností CHAPS s.r.o. Datový model vychází z vydaných evropských technických specifikací a norem. Analýza velmi obsáhlé dokumentace byla základním stavebním kamenem pro návrh normy, která respektuje vydané Evropské specifikace, ale zároveň koresponduje s českým prostředím, které je v mnoha ohledech odlišné od evropského. Součástí normy je jasně popsané rozhraní pro poskytování dat do CISReal6, názvosloví které koresponduje s normou SIRI7, popsaná aplikační logika i metodika sběru dat, která umožní jasně definovat podmínky pro dodání systémového rozhraní dispečinků se standardizovaným API.

6

Celostátní informační systém v reálném čase

7

CEN/TS 15531

10

2

Informační systémy

Informační systémy (dále jen IS) jsou budovány jako samostatně fungující prvky, které je možné chápat jako nadstavbovou, popř. paralelní část systémů pro komplexní řízení a organizaci dopravy včetně dopravy individuální a nákladní. Jednotlivé dispečinky VD jsou budovány pro funkci řízení a organizaci dopravy na území mu příslušném s možností kontinuální výměny informací s jinými, ať už nadřazenými, nebo podřízenými systémy. 2.1.

Dynamický Dispečink

Dynamický dispečink (dále jen DD) je vyhodnocovacím, úložným, kontrolním a řídícím prvkem IS. Zabezpečuje sběr aktuálních informací o vozidlech a jejich pohybu; ty následně vyhodnocuje a umožňuje dopravně regulační zásahy. Jedná se o modul, který hraje primární úlohu v možné interoperabilitě informačních systémů dat v reálném čase (dále jen ISR) v regionu, popř. na území celého státu. Z tohoto důvodu je zapotřebí dbát na strukturu databáze a formátu použitých dat maximální zřetel. Mezi základní požadavky na DD systému ISR řadíme možnost poskytování aktuálních informací cestujícím s možností navrhování alternativního spojení v závislosti na dopravní situaci, zjednodušení obsluhy konkrétních vozidel a zvýšení efektivity managementu flotily, do systému zapojených, vozidel. S ohledem na maximální využití potenciálu DD jsou požadavky na strukturu databáze jednotlivých dispečinků navrženy na bázi evropské technické specifikace CEN 15531 SIRI (upravených na místní podmínky) Je zároveň žádoucí zajištění kontinuální výměny dat s dalšími systémy. Součástí následujících požadavků je rovněž postup, jak zabezpečit kontinuální sběr informací do CISReal i ze systémů, které nejsou tvořeny na zmíněné struktuře. Následující požadavky tak dávají námět, jak uskutečnit plnou kompatibilitu systémů v ČR i bez dodatečných nákladů na přebudování stávajících systémů a jejich struktury. Funkce DD V obecné rovině by měl DD disponovat těmito funkcemi:

• • • • •

funkce pro sledování polohy a stavu vozidel, statistická a analytická funkce, funkce pro výstup návrhu na optimalizaci jízdních řádů, funkce poskytování informací cestujícím, funkce interoperability s jinými systémy.

Uvedené funkce DD musí v obecné rovině zajistit tyto služby:

• • • • • • • • • 11

plynulost veřejné dopravy, informovanost o reálném stavu dopravy ve městě, automaticky generovat informace o návaznosti jednotlivých vozidel (spojů), komfort dispečerů při řízení dopravy, minimalizovat chyby řidičů, zjednodušit obsluhu konkrétních vozidel ze stran řidičů i dispečerů, zajistit podporu řidičů, informovanost o událostech ve vozidlech, nebo o událostech na trase, či v určitém segmentu sítě MHD, sběr doplňkových dat z vozidel,

• • •

12

dodržování plnění grafikonu, výměnu dat s jinými systémy (kraj, celá ČR), trvalý dopravní průzkum, - pro optimalizaci dopravy, - pro řešení odchylek od tras – časových, kilometrických, - pro řešení sporných událostí souvisejících se stavem ve vozidle v určitém čase.

3 SW platforma – návrh formy sběru dat z veřejné osobní dopravy s centrálním prvkem CISReal Centrální prvek, popisovaný na obrázku 1, pro něhož tato metodika definuje podmínky, umožní interoperabilitu v rámci všech částí systému a zároveň umožní vyměňovat informace s dalšími centrálními prvky, jako jsou např. dopravní informační centra v České republice a relevantní centra v zahraničí. Centralizované pojetí umožňuje organizační a ekonomickou šetrnost při budování ISR v regionech a městech a zároveň naplňuje požadavky interoperability. Jedná se o aspekty technické interoperability, tzn. schopnost odlišných ISR komunikovat navzájem i v reálném čase prostřednictvím sdílených rozhraní, tak sémantické interoperability, schopnosti porozumění obsahu a kvalitě dat. CISReal nijak neomezuje systémy dopravce, ani organizátorů dopravy, od možností přímého sdílení dat mezi jednotlivými systémy na základě smluvních dohod (komunikace na úrovni 2-2, 2-3, popř. 3-3 na obrázku 1).

Obrázek 1: Hierarchická struktura informační architektury systému veřejné dopravy s centrálním prvkem CISReal

Obrázek 1 je dále podrobně rozebrán v následujících článcích.

Infrastruktura – data z vozidel

3.1.

Infrastruktura je považována za základ hierarchické struktury, která zabezpečuje potřebná data pro následné vyhodnocování a sdílení. Úroveň infrastruktury se dělí do tří skupin: • • •

13

sběr dat – jedná se o konkrétní vozidla vybavená lokalizačními a vyhodnocovacími zařízeními; přenos dat – informace o pohybu vozidel jsou přenášena využitím přenosových technologií do dispečinků, které mají vozidla ve své správě; diseminace informací – vyhodnocená data z dispečinků jsou následně vrácena na infrastrukturu (ZIS, internet, mobilní telefony, palubní informační systémy) přes přenosové technologie a umožňují informovat cestující o jízdních řádech v reálném čase, nebo o nenadálých jevech, popř. umožňují jednotlivým vozidlům preferenci na SSZ (daná komunikace může probíhat i lokálně, kdy nemusí být použito dat z dispečinku a vozidla v daném případě komunikují se SSZ přímo na základě vyhodnocených údajů uvnitř palubní informatiky).

3.2.

Dispečinky jednotlivého dopravce

Dispečink je vyhodnocovacím, úložným, kontrolním a řídícím prvkem celého systému řízení provozu vozidel dopravce. Dispečink jednotlivého dopravce obecně řídí provoz pouze místních vozidel bez ohledu na ostatní dopravce v oblasti. Zabezpečuje sběr aktuálních informací o vozidlech a jejich pohybu. Dispečink jednotlivého dopravce řeší jiné procesy a úlohy než jako dispečink provozující více druhů dopravy, například se jedná o řešení problémů výpadků vozidla, vyslání záložního vozidla. Řízení je obdobné jako v případě dispečinku provozující více druhů dopravy, avšak s přihlédnutím k organizační struktuře dopravce jsou procesy zjednodušeny. Dispečink dopravce importuje data z vozidel a postupuje je k vyhodnocování ve svém, popř. jiném serveru. Server regionálního dopravce, nebo organizace jím pověřená, musí provádět upřesnění dat o poloze a zpoždění prostřednictvím programového vybavení přizpůsobeného konkrétním podmínkám. Dispečink dopravce vyhodnocuje data z vozidel pro své účely, ale je doporučeno, aby exportoval údaje o pohybu vozidel v níže uvedeném formátu a protokolu do nadřazených dispečinků. První podmínkou poskytování ucelených informací směrem vzhůru ve vertikální linii je distribuce dat z instalovaných vozidlových technologií. Data z jednotlivých vozidel, alespoň v minimálních požadavcích, mohou být postupována: a) ze serveru jednotlivého dopravce do dispečinku provozujícího více druhů dopravy (organizátor IDS) a následně do CISReal; b) přímo z vozidel dopravce do dispečinku provozujícího více druhů dopravy a odtud na server dopravce; c) přímou komunikací server dopravce – CISReal.

Druhou podmínkou je zachování formátu a obsahu dat, jenž je zasílán z jednotlivých vozidel dopravce (monitorování pohybu vozidla). Další možnou variantou je zasílání již zpracovaných dat o zpoždění jednotlivých vozidel do jiných serverů, což však omezuje variabilitu práce s daty v nadřazeném dispečinku a může být omezena garance za přesnost poskytovaných informací. Pro omezenou práci s daty v dispečinku provozujícího více druhů dopravy je nutný zisk alespoň těchto údajů: ID Spoj, ID linky (LineRef), datum/čas (RecordedAtTime), a poloha vozidla (location). Jedná se o minimální požadavek pro sdílení mezi systémy. Tyto informace jsou užitné, a pokud se přiřadí ke statickým datům (CIS JŘ), je možno tímto způsobem získat přehled o progresi pohybu vozidla. Rozšířené datové struktury a elementy, které jsou nutné pro komunikaci s CISReal, jsou uvedeny níže. V případě, že se jedná o dopravce spadajícího do IDS, je požadována distribuce dat z vozidel do serveru dopravce a následně do konkrétního dispečinku IDS. Data mohou být zasílána z vozidel dopravce přímo do dispečinku IDS (až následně jsou zasílána data z IDS do dispečinku dopravce, pokud jím dopravce disponuje). Dispečink dopravce by měl být zároveň připraven na import dat z IDS popř. CISReal. V případě že se jedná o dopravce nespadajícího do IDS, konajícího službu na krátkých, popř. středních linkách (místní, regionální dopravce), je požadována distribuce dat z vozidel (ze serveru dopravce) do nejvyšší úrovně CISReal popř. do smluvních systémů, na jejichž území dopravce koná službu. V případě, že se jedná o dispečink dopravce obsluhující dálkové linky (národní), dopravce provozující dopravní služby bez uzavření smlouvy o veřejných službách, je požadována distribuce dat z vozidel (ze serveru dopravce) do nejvyšší úrovně CISReal. Zároveň by měl systém dispečinku dopravce umožnit import dat z CISReal pro informování o nenadálých jevech na trase, popř. pro informování o přípojných linkách.

14

3.3.

Dispečink provozující více druhů dopravy

Dispečink provozující více druhů dopravy (Integrované dopravní systémy, městská hromadná doprava) je nadřazeným dispečinkem pro dopravce konající služby na území města a regionu, zařazených do dopravních systémů. V případě MHD a IDS je situace obdobná jako u dispečinku jednotlivého dopravce jen s tím rozdílem, že dispečink disponuje daty od různých dopravců a různých modů dopravy. Narůstá tím složitost dispečerského systému a práce dispečerů, jelikož je do systému zapojeno více vozidel a různých módů dopravy. Je doporučeno, aby na území kraje byly MHD ISR a IDS ISR navzájem interoperabilní (informačně propojeny – alespoň v minimálních požadavcích). Tato metodika doporučuje, aby zprávy z vozidel dopravců byly distribuovány v reálném čase do dispečinku IDS nebo nejvyšší úrovně CISReal, a zároveň, aby dispečinky byly uzpůsobeny k importu vyhodnocených informací z CISReal o dotazovaných vozidlech, nebo informací z jiných systémů. Dispečink IDS tak plní roli uživatele i producenta podle souboru CEN/TS 15531 s potřebnými úpravami. V případě, že jsou informace přenášeny od dopravců přímo do CISReal, může centrální systém tyto informace postupovat o úroveň níž, tedy dispečinkům IDS. Vztah mezi organizátorem a systémem CISReal a dopravním podnikem města a CISReal může být upraven smluvně. Vztah definuje úroveň informací, které jsou mezi entitami sdíleny. Vždy se tak bude jednat o vztah producent versus uživatel. Nově budované systémy by měly být připraveny na zasílání komplexních informací o pohybu konkrétních vozidel dle níže uvedené datové struktury. Z následujícího vyplývá, že server musí v souvislosti s funkcí ISR plnit následující funkce: • • • •

15

import JŘ; sběr a vyhodnocování informací z jednotlivých vozidel či dalších dispečinků; korekce času ve všech součástech systému; schopnost komunikace s ostatními dispečinky a informačními systémy a s CISReal.

Obrázek 2: Návrh standardního IDS ISR

Server dispečinku musí v souvislosti s funkcí příslušnou automatickému systému sledování vozidel, provádět dále uvedené činnosti: 1)

Shromažďovat zprávy, které jsou vysílány z místních vozidel (např. intervalové zprávy, nebo přenos dat na základě události – otevření/zavření dveří, specifikovaný bod, prudká změna směru, vynucený přenos akcí řidiče či dispečera, vjetí do vymezené lokality, např. před zastávkou apod.);

2)

Archivovat odchylky od jízdního řádu předávané dispečinkem dopravce;

3)

Určování spojů jako neupřesněné v případě, že zadaná data polohy nedávají reálný výsledek odchylky od jízdního řádu;

4)

Simulovat jízdu vozidla, které je vypraveno, ale nevysílá data o poloze;

5)

Vyhodnocovat příjezd, pobyt a odjezd vozidla ze zastávek;

6) Sledovat přípojné linky; 7)

Časově synchronizovat všechna zařízení v systému (možnost odeslat jednotný čas do všech vozidel).

3.4.

Data V ISR

Data jsou jakékoli vyjádření (reprezentace) skutečnosti, schopné přenosu, interpretace či zpracování. Účelem dat je přenášet a dále zpracovávat odraz skutečnosti. Jsou to jakékoli zaznamenané plány, skutečnosti, situace a jevy v oblasti provozu ISR jako celku. O datech hovoříme v souvislosti s potřebou unifikace jejich formy a obsahu pro možnost jejich sdílení mezi jednotlivými systémy (servery) a zařazování do databází, které následně umožňují vzájemné vazby a následnou práci s nimi. Pro účely fungování ISR rozlišujeme data v základní podobě na: 1) Data statická, 2) Data dynamická. Vstupy do ISR - Statická data O statických datech mluvíme hlavně v souvislosti s provozem CIS JŘ a všech informacích, které jsou v nich obsaženy. O statických datech pro účely ISR hovoříme jako o vstupních. Na rozdíl od výstupů, 16

vstupy do IS jsou pro cestující veřejnost skryté. Schválené JŘ, registry a zprávy z vozidel se v závislosti na zvolené architektuře transformují do podoby výstupů. Jako vstupy do systému rozlišujeme: 1) 2) 3) 4) 5) 6) 7) 8) 9)

Jízdní řády, Označení linek, Číselník zastávek, Označení dopravce, Tarifní vzdálenosti, Určení příjezdu a odjezdů spojů, Číselné označení spojů, Označení spojů, Další označení.

Více informací o statických datech lze najít v Metodickém pokynu č. 4 8 k organizaci celostátního jízdního řádu. Vstupy do ISR - Dynamická data Dynamická data jsou pro funkci ISR nezbytná. Získávají se za pomocí technologických zařízení, které jsou instalovány ve vozidlech (převážně systém GPS spojený s vyhodnocovací a přenosovou infrastrukturou). Data v reálném čase dělíme v základu na: 1) Data on-line, 2) Data off-line. ON-line data

Data v reálném čase – dynamická data on-line jsou stěžejním prvkem fungujících informačních systémů ve VD. Souboru informací z vozidel říkáme Monitorování pohybu vozidla. Jednotlivé zprávy z vozidel jsou nazývány „hlášky“ (calls). Ty jsou zasílány v intervalech, popř. je žádoucí, aby byly zasílány při příjezdu, a odjezdu vozidla ze zastávky. Pro požadovanou funkci řízení dopravy a flotily vozidel jsou důležité následující podmínky na zisk informací: Rozdíl mezi statickými a dynamickými daty - rozeznáváme dva druhy získaných rozdílných hodnot:

•

Předjetí a podjetí vozidla - Tyto informace mohou být diagnostikovány přímo vozidlovou výbavou, ale především jsou hodnoty vypočítávány v dispečinku (i v případě dostupnosti těchto údajů vozidel je nutné pracovat s daty vyhodnocenými v dispečinku), kam se informace z vozidel intervalově (popř. na vyžádání, nebo na základě vzniklé události) zasílají.

V ISR jsou dané hodnoty kritickým ukazatelem. Především jsou tyto hodnoty zásadní při možných návazných spojích. Každý provozovatel ISR by měl definovat kritickou hodnotu zpoždění a dle těchto ukazatelů se snažit danou situaci řešit operativními zásahy. Např. informovat návazné spoje o délce čekání a žádat o počkání a následně o těchto informacích spravovat cestující (čekání na návazné spoje apod.) V procesu on-line zpracování jsou tyto informace rovněž stěžejní pro informování cestujících na výstupních zařízeních ISR v reálném čase (ZIS, web, mobilní zařízení). Hodnoty předjetí vozidla se zasílají v záporných číslech. 8

http://www.mdcr.cz/NR/rdonlyres/C35BBFAE-E315-48F0-9040-A3339F482F48/0/MetodickyPokyn4schvaleny.PDF

17

Hodnoty předjetí a zpoždění jsou zároveň hodnotícím kritériem, založeným na historických údajích vhodných k posuzování kvality přepravního procesu, nebo plánovaných službách jednotlivých vozidel. Na jednotlivých výsledcích analýzy mohou být prováděny úpravy jízdních řádů. Tyto údaje jsou získávány z off-line vyčítání dynamických dat. 1) 2) 3) 4)

Zisk informací o progresi vozidla a jeho identifikačních znaků – Location, Alerty z vozidel (vozidlo v koloně, nehoda, defekt apod.) – VehicleBroadcast, Možné informace o aktuální obsazenosti vozidel – Occupancy, On-line mohou být zároveň získávány diagnostická data z vozidel (např. rychlost, spotřeba) Speed, 5) Informace o stavu zařízení a připravenosti na zasílání dat – Status – Boolean.

Dynamická on-lina data jsou však důležitá zároveň pro funkci interoperability jednotlivých systémů – vzájemná komunikace serverů přes SOAP, popř. http prostředí. V případě, kdy jsou data sdílena s jinými systémy, je podmínkou zachování jejich aktuálnosti i v rámci přenosu mezi systémy. Pro tyto účely je navrhováno využití webových služeb na základě formátu. xml a standardního protokolu prostředí SOAP/WSDL popř. Http. Forma této komunikace zaručuje minimální zpoždění od vyslání zprávy do jejího obdržení. Hovoříme v ms. Každá zaslaná obálka (envelope) obsahuje hlavičku a tělo zprávy. Doba přenosu dat není ovlivněna ani obsahem těchto dat. Pro potřeby navrhovaného centralizovaného systému dat v reálném čase je žádoucí, aby mezi jednotlivými systémy byly sdíleny obdobné informace, jako jsou zasílány z jednotlivých vozidel a závisí na zvolených funkčních službách, které budou vzájemné servery využívat. OFF-line Jedná se zejména o situace vyčítání paměti řídící jednotky ve vozovně. Tyto údaje jsou následně uchovávány v databance a jsou připraveny k analytickým a simulačním procesům. Zároveň jsou přenášena v off-line režimu „nová“ provozní data (např. nové jízdní řády, lokalizace nových zastávek apod.) Bližší informace jsou dále v dokumentu. Typy přenášených dat V systému integrovaného dispečinku se vyskytují tři základní typy dat, které se rozlišují podle použití, způsobu zpracování a délky. •

•

18

Krátké zprávy - přenášené v reálném čase: Jsou to zejména zprávy přenášené z vozidla a do vozidla (údaje o poloze a stavu vozidla). Jsou to zprávy, přenášené nepřetržitě po dobu provozu vozidel veřejné dopravy. Do této kategorie spadají rovněž zprávy pro zastávkové informační systémy a pro možnou preferenci na SSZ. Datové soubory střední délky - Jedná se zejména o soubory s údaji o výběru jízdného. Jsou vysílány podle potřeby, zpravidla v denních intervalech a jejich zpracování podléhá zvláštnímu režimu, protože se jedná o důvěrná data. Režim distribuce a zpracování těchto dat je popsán v návrhu evropské a světové normy ISO/DIS 24014-1: Public Transport - Interoperable Fare Management System - Part 1: Architecture. Veřejná doprava – Interoperabilní systém managementu jízdného – 1. část: Architektura. Nejedná se o data, která vyžadují přenos v reálném čase.

•

Datové soubory jízdních řádů - Jedná se o soubory s jízdními řády a doplňkovými údaji pro vozidla veřejné dopravy osob. U větších dopravců se jedná o relativně dlouhé soubory. Jejich délka bude s nárůstem doplňkových informací pro cestující narůstat. Tyto soubory se vysílají podle potřeby, vždy však při změně jízdních řádů. Nejedná se o data, která vyžadují přenos v reálném čase. Přenášet data jízdních řádů stejnými technickými prostředky jako krátké zprávy je u větších dopravců prakticky vyloučeno. Proto se pro tyto účely využívá rychlých přenosů, převážně pomocí systému WiFi.

Aktuálnost dat - hystereze ISR Časovou hysterezí můžeme definovat minimální časový interval, ve kterém je možno aktualizovat informace. Tento interval má dvě složky: • hystereze vlastního komunikačního systému; •

interval, za který vozidlo vysílá nové informace.

První složka je dána komunikačním systémem a je jí maximální rozdíl zpoždění datových paketů mezi základnovou radiostanicí rádiové sítě a informačním serverem. Toto zpoždění nevzniká nebo je zanedbatelné u analogových rádiových sítí. Interval mez zprávami, které vysílá vozidlo je volitelný, ale nemůže být kratší, než hystereze vlastního komunikačního systému Praktický dopad hystereze informačního systému spočívá v tom, že je-li hystereze systému 1 minuta, může být zpoždění udáváno s přesností maximálně 1 minuta tj. 1, 2, 6 minut atd. V praxi je délka takové hystereze nepřijatelná. Proto, je zapotřebí zaručit, že maximální hystereze systému od zaslání zprávy do přijetí je maximálně 20 s. V této souvislosti je zapotřebí číslovat jednotlivé zprávy, které se chronologicky ukládají do systému. 3.5.

Přenos vozidlo – dispečink- interval

V následující kapitole jsou popsány požadavky pro základní přenos datových zpráv mezi vozidlem a dispečinkem. Jedná se o přenos informací z vozidel, které jsou neustále v pohybu, proto je nutné využívat mobilních přenosových technologií. Mobilní technologie mají omezenou přenosovou kapacitu a díky tomu se může stát, že instalovaná technologie má přenosovou kapacitu nedostatečnou, což může v důsledku znamenat kritické ohrožení funkcionality systému operující v reálném čase. Tato skutečnost se promítá v požadavku na velikost přenášených dat a způsob jakými jsou data z vozidel distribuována. Podstatný rozdíl je v tom, zda datový přenos je realizován trunkovou datovou sítí nebo digitální. Reprezentuje zejména přenos z pohybujícího se vozidla do systému dopravce. Periodicita záleží na podmínkách a nastavení systému, přičemž je možné rozlišit 3 základní online principy: 1) Periodické obvolávání vozidel z centrály (polling) – tohoto systému je převážně využíváno u analogových rádiových sítí a při použití u jiných technologií mohou výrazně zvyšovat zpoždění mezi vyslaným požadavkem a opětovnému obdržení zpráv. Tohoto způsobu přenosu by nemělo být využíváno v jiných, než analogových systémech. 2) Periodický přenos – (Broadcasting) - přenos informací s danou periodou - intervalem, např. 10s, daná periodicita by měla být nastavitelná 3) Přenos na základě události - (events) - otevření/zavření dveří, specifikovaný bod, prudká změna směru, vynucený přenos akcí řidiče či dispečera, vjetí do vymezené lokality (např. před zastávkou) apod.

19

Dva spodní principy je možné kombinovat. Je však žádoucí, aby vozidlo vysílalo hlášku vždy při příjezdu na zastávku, a vždy při odjezdu ze zastávky. Přenos dat se realizuje pomocí dostupných technologií (GPRS/EDGE/3G, PMR) zabezpečeným online přenosem informací minimálně v rozsahu: • identifikace vozidla (linka/spoj), • identifikace polohy (GPS souřadnice - Location) – podporované formáty WSG, GML, nebo lokálně rozšířené, tzn. JTSK, S42, • Identifikace času dle standardu UTC – Date, Time, • zprávy pro/od řidiče vozidla. – alerty- VehicleBroadcast, • informace o obsazenosti vozidla – Occupancy. Jako doplňkové informace slouží poslední vyhlášená zastávka (PreviousCall), čas odjetí z poslední zastávky a v případě, že řídící jednotka je schopna identifikovat odchylku od JŘ (Delay), přenos i této informace. Další doplňkovou informací je čas v desetinách vteřiny od odjetí z poslední zastávky (Progress), popř. v % ujetá vzdálenost mezi zastávkami. Pro posouzení obsahu zprávy např. o poloze je pro pozici vozidla rozhodující čas odvysílání zprávy, nikoliv čas jejího uložení do paměti To znamená, že se doporučuje do protokolu zprávy použít identifikační znak – pořadí zprávy odeslané ve dni, popř. po restartu palubní jednotky. Typ zprávy - MESSAGETYPE Součástí odeslané zprávy, by měla být zároveň informace o typu zprávy. Je doporučeno, aby jednotlivé zprávy obsahovaly min. tyto typy (přívlastek):

• • • • • • • • • •

vozidlo jede z garáže na linku, vozidlo jede po standardní trase kmenové linky, vozidlo stojí na konečné zastávce kmenové linky, vozidlo přejíždí na přejezdovou linku, vozidlo jede po přejezdové lince, vozidlo stojí na konečné zastávce přejezdové linky. vozidlo vyjelo ze zastávky (řidič zavřel dveře před odjezdem), vozidlo stojí na zastávce, vozidlo se vrací do garáže, manipulační jízda bez zvláštního určení.

V praxi může docházet k 3 typům komunikace vozidlo x dispečink:

• • •

vozidlo – dispečink jednotlivého dopravce – jedná se o základní, nejběžnější typ komunikace, vozidlo – dispečink provozujících více druhů dopravy - vozidlo data zasílá přímo dispečinku organizátora dopravy, popř. je dispečink dopravce distribuuje bez jakýchkoliv úprav, vozidlo – dispečink centrální - vozidlo data zasílá přímo centrálnímu dispečinku.

Požadavky pro vybavení dispečinku/BACK OFFICE Následující kapitola shrnuje požadavky, které jsou požadovány na výbavu a funkčnost jednotlivých dispečinků.

20

Obecné požadavky na dispečink • • • • • • • •

• • •

• • • • • • • • •

21

dispečerský SW (software), dále jen „Systém“ by měl splňovat Standard ISVS pro náležitosti životního cyklu informačního systému, všechny moduly a funkce dispečerského systému jsou součástí jednoho integrovaného celku, systém by měl být založen na stabilním operačním systému jak na straně serverové části, tak i na pracovních stanicích klientské části, systémová aplikace by měla být modulární a strukturovaná, systém by měl umožňovat využívání jednotné centrální databáze v souladu s platnými standardy, systém by měl používat časový formát v platné normě UTC, systém by měl být připraven pracovat v multi-jazykovém prostředí, systém by měl být připraven na přihlášení definovaného množství uživatelů dle administrátorsky přidělených práv (práva pro čtení, práva pro zápis). Rozdělení práv se vztahují k povolování zobrazování jednotlivých oken a také umožňují přidělování nadřazených práv určitým zaměstnancům provozovatele, kteří mohou přidělovat jednotlivá podřízená práva dalším uživatelům, systém by měl být dodáván včetně multilicence (bude možné ji využívat i jiným subjekty) a provozovateli budou poskytnuty licence na definovaný počet uživatelů, systém by měl být tvořen na bázi práce s okny (minimalizace oken, zavření, zvětšování a zmenšování pomocí tažením, posun okna apod.). Systém využívá aktuální standardy uživatelského rozhraní (multiokno), systém by měl poskytovat funkci filtrování dat dle rozsáhlého množství evidovaných dat jako například filtrace jednotlivých vozidel, ale také dle vícenásobných podmínek. V případech, které to vyžadují (např. v IDS systémech) systém umožňuje filtraci dat dle dopravců, nebo módů dopravy, systém by měl umožňovat organizaci dopravy při řešení plánovaných i neplánovaných provozních překážek (výluky, objízdné trasy, atd.), systém by měl umožňovat export dat do Excelu 2007 a vyšší včetně přenosu nejen dat, ale popř. i grafického formátu formulář, systém by měl mít integrován nástroj pro tvorbu tiskových sestav, systém by měl umožňovat zasílání dat pomocí emailu – integrace s poštovním klientem, systém by měl průběžně evidovat sekvenci dotazů a odpovědí mezi serverem a vozidly, popř. eviduje všechny zprávy zaslané vozidly a všechny zprávy zaslané vozidlům s dispečinku, systém by měl průběžně evidovat veškeré příchozí i odchozí zprávy mezi serverem x vozidlem, ale také mezi jednotlivými servery (jiné ISR), systém by měl zajišťovat přístup k datové, popř. fonické komunikaci s vozidly ze všech oken, aplikace umožňuje bezprostřední datovou komunikaci (pomocí zpráv) s vybranými konkrétními řidiči vozidel MHD, komunikaci s vybranými skupinami vozidel, popř. vybranými dopravci, systémová aplikace má integrovanou možnost přednastavení datových zpráv řidičům (nenastoupení střídajícího řidiče, porucha vozu, nehoda – na trase autobusu, čekej na přípoj,

• • • •

• •

systémová aplikace umožňuje obousměrnou datovou komunikaci dispečera s konkrétním řidičem vozidla, vybrané skupiny vozidel (dle trakce, linek, území, výřezu území), dle dopravce, architektura systému je navržena tak, aby funkčnost byla striktně klient server – veškeré transakce budou probíhat na serveru, klient pouze zadává požadavky a zobrazuje výsledky transakcí a serverem evidovaných dat, systém by měl umožňovat integraci uživatelských identit mimo dodaný systém formou externího centrálního řízení identit a práv, systém by měl umožňovat vytvoření aplikačního rozhraní v „oknech“, která mohou být uspořádána na obrazovce dle potřeb uživatele. Zároveň podporuje funkci multiokna, funkci drag and drop, funkci zobrazování dat ve stromové struktuře, filtrovatelném seznamu, detailu s podporou záložek apod., DD by měl zajišťovat automatické korekce (sjednocení) času v řídících jednotkách vozidel, aplikačních PC, vizuálního tabla dispečinku a na stacionárních informačních panelech, popř. ve vozovnách a to minimálně 4x denně, systém by měl být dodáván na instalačním CD/DVD s možností instalace z pevného disku serveru, nebo po síti.

Definované minimální požadavky dispečerského systému - Sledování polohy a stavu vozidel možností řízení • •

• •

• •

• • •

22

systém by měl umožňovat sledování vozidel v reálném čase. V případě, že vozidlo ztratí signál, popř. se nepřihlásí do systému, je simulován virtuální pohyb vozidla dle pevného jízdního řádu, DD by měl být integrován s mapovými podklady, které umožní zobrazování pohybu vozidel MHD, nebo dopravců v reálném čase s grafickým odlišením typu vozidla (autobus, tramvaj, trolejbus, vlak, příp. dalších druhů dopravy zavedených do systému) např. barevně s využitím navigačních souřadnic jednotlivých zastávek a jejich zobrazení v mapovém podkladu, dispečer by měl mít možnost sledovat pohyb jednotlivých oběhů, spojů jak na mapě, tak i v tabulkách, které jsou mezi sebou funkčně provázané, systém by měl mít možnost zvýraznit spoje na jednotlivých linkách, filtrovat spoje dle dopravce, spoje dle délky zpoždění/podjetí, módu dopravy atd. (vše uživatelsky nastavitelné pomocí barev). Pokud nejsou k dispozici data o poloze spoje, je spoj výrazně odlišen od ostatních (unikátní barva v systému), systém by měl podporovat rychlý mapový podklad a umožňovat uživatelsky příjemné ovládání, systém by měl mít možnost okamžité datové oboustranné komunikace s vozidly v každém okně, prostřednictvím komunikační sítě a je umožněno zdokumentovat on-line komunikaci dispečinku přímo s vozidly (textové zprávy) včetně potvrzení o přečtení zprávy řidičem ve vozidle, systém by měl umožňovat integraci informací ze systémů kontroly průjezdů vozidel do a vně vozovny, systém by měl umožňovat řešení nouzových stavů řízení, systém by měl umožňovat v tabulkách i mapových podkladech graficky a barevně odlišit indikaci těchto získaných dat z konkrétních vozidel: Ztráta dat z GPS, ztráta spojení s radiostanicí (ztráta signálu) po předdefinovaném počtu pokusů o spojení, zpoždění vozidel v několika barevných úrovních (zpoždění menší než 3 min, zpoždění větší než 3 min) a předjetí vozidla – výše zpoždění je definovatelná uživatelem,

•

•

•

•

•

• • • •

systémová aplikace by měla mít integrovánu schopnost nepřetržitého vyhodnocování aktuálního skutečného dodržení či nedodržení legislativně stanovených přestávek všech vozů (řidičů) v provozu, upozornění na nedodržení legislativně stanovených přestávek a možnost detailního zobrazení seznamu těchto vozů a jejich vozových jízdních řádů formou alertů ( upozornění), systémová aplikace by měla umožňovat výrazné barevné odlišení, přičemž by měly být použity výrazně odlišné barevné odstíny pro všechny výše jmenované indikace. Stejně tak by měla být barevně odlišena taková vozidla, která mají být na trase, ale nepřihlásila se do systému a opět s podporou funkce alertů, mapové podklady systému by měla umožňovat práci s těmito funkcemi: zoomování, možnost výběru konkrétního vozidla, linky, trakce, možnost vytvoření libovolného počtu vozidel do skupin, tažením myši, nebo pomocí výběrového menu spouštěného pravým tlačítkem myši, možnost zahájení hovoru (pokud technologie přenosu dat umožňuje)s vybraným vozidlem, nebo zaslání datové zprávy, systém by měl umožňovat prohlížet reálné data o konkrétních vozidlech a zobrazovat tyto informace: Aktuální rychlost, aktuální polohu vozidla, údaj o zpoždění, každou zprávu vozidla, čas příjezdu do poslední zastávky, čas odjezdu z poslední zastávky, dobu stání v poslední zastávce, čas posledního přijatého údaje z GPS a způsob přihlášení řidiče (čipovou kartou, manuálně) a jeho jméno. Tyto informace by měly být k dispozici rovněž na mapovém podkladu při výběru konkrétního vozidla, systém by měl umožňovat, aby na mapových podkladech byl zřetelný směr vozidla. Vozidlo, se kterým je ztracena komunikace, je výrazně barevně odlišen s možností získání manuálního dotazu na aktuální polohu. Tyto informace by mohly být k dispozici, jednak v tabulkách, ale rovněž na mapovém podkladu, systém by měl umožňovat tvorbu skupin (min. 3 pro klienta). Tyto skupiny mohou umožňovat: zobrazení všech vozidel skupiny na mapě, dávkové volání na skupinu, zasílání dat/zpráv na skupinu, systém by měl mít možnost automatického i manuálního zajištění přípojné vazby linek zavedených do systému, nebo v rámci kompatibilních systémů, systém by měl zajišťovat automatické hlášení ohrožení návazností, automatické informování řidičů vozidel, automatické hlášení nevyjetí spoje, nepřihlášení řidiče, sjetí z trasy atd., systém by měl umožňovat zajištění monitoringu funkčnosti všech zařízení instalovaných ve vozidlech a stacionárních zařízení - status.,

Minimální požadavky pro Statistickou a analytickou funkci • • • •

•

23

systém by měl být trvale připojen na datové úložiště – centrální server, popř. serverovou farmu dispečinku, systém by měl být integrovaný nástroj pro vyhodnocování a analýzu provozních statistik, prostřednictvím systému by mělo být možné zobrazit všechna vozidla MHD, dopravců, připojených do systému s aktuálními informacemi o průběhu jízdy, jak na mapových podkladech, tak zobrazených v tabulkách, systém by měl umožňovat průběžné zpracovávání provozních dat pro podporu procesu optimalizace veřejné dopravy (statistiky a analýzy jízdních dob s vazbou na obsazenost vozidel), především v závislosti na dodržování plánovaných jízdních řádů a s možností návazností jednotlivých spojů, systém by měl umožňovat nahlížení do historických dat (přehrávání, zpětné simulace jízd konkrétních vozidel ve vztahu GPS souřadnic x jízdní řád, vyčítání a nahrávání těchto dat

•

• •

apod.) minimálně po dobu 12 měsíců. Hledání v historických datech nesmí omezit on-line provoz systému, funkce by měla umožňovat automatické vyhodnocování průměrné cestovní rychlosti, rozdělení jízdní doby spojů na dobu strávenou jízdou a dobu stání na konečných, zastávkách, v kolonách (u vozidel, u nichž je to možné, též dobu stání mimo stanice – např. na křižovatkách), systémová aplikace by měla umožňovat automatické zasílání denního reportu na emailové adresy vybraných uživatelů, a to zejména o těchto informacích: neúspěšně provedené servisy vozidel, nehlásících se vozidel apod., systém by měl umožňovat administrátorskou správu databáze a vrstev a jejich editaci (dle přidělených práv) – např. správu databáze zastávkových označníků, jízdenkových automatů, měníren, výhybek apod.

Rozšířené požadavky • •

systém by měl umožňovat zobrazování informací o dálkovém nahrávání vozidel s těmito údaji: počet dálkově spravovaných komponent, update software a další volitelné informace, systémová aplikace by měla umožňovat automatické vyhodnocování a zasílání denního reportu na emailové adresy vybraných uživatelů o těchto informacích: odchylky vozidel MHD/dopravců od jízdního řádu, zpracování statistiky pravidelnosti provozu, jízdních dob pro určitá denní období, dny v týdnu a měsíce - generování statistik na základě volitelných zadávacích parametrů (např. výběr linek, trakci, úseků, libovolného časového období) MHD/dopravců

Minimální požadavky pro dispečerský systém pro tvorbu jízdních řádů • • • • • • •

systém by měl mít v sobě integrovánu funkci tvorby jízdních řádů dle metodiky CIS JŘ v souvislosti s povinností hlášení veškerých změn v jízdních řádech 15 pracovních dnů dopředu a to dopravnímu úřadu, systém by měl umožňovat vkládat provozní změny v jízdním řádu v závislosti na neočekávaných jevech např. posilové spoje, v případě poruchy apod. a tyto spoje zavést do systému v reálném čase, systém by měl obsahovat linkové vedení, systém by měl integrovat aktuální jízdní řád všech linek, spojů s možností jeho správy a nahrávání nových, systém by měl umožňovat integraci se simulačním modulem pro tvorbu nových jízdních řádů. generování podkladů by mělo být zajištěno pro operativní řízení přepravního procesu (zpoždění spojů, na které navazují jiné spoje), systém by měl umožňovat import dat pro efektivnější tvorbu jízdních řádů v závislosti na dlouhodobých, nebo stále se opakujících zpoždění jednotlivých spojů, linek apod..

Minimální požadavky na dispečerský systém a funkci - poskytování informací jiným systémům a připravenost k integraci jiných dopravců, systémů •

24

informační systém v reálném čase vozidel VD, popř. MHD (datové rozhraní a centrální databáze) může být tvořen na bázi normy ČSN 01 8245 CISReal, která zajišťuje interoperabilitu s jinými systémy, nebo v budoucnu instalovanými systémy,

• •

• •

•

• •

je doporučeno, aby veškeré zprávy z vozidel, nebo mezi servery probíhali na základě standardizovaného protokolu SOAP/WSDL, popř. http za pomocí formátu.xml, je doporučeno, aby komunikace mezi servery. Server x Server, nebo Server x CISR probíhal ve formě Požadavků a odpovědí, Publikování x subskripce s přímým doručením, popř. s doručením fetched. Je doporučeno připravit komunikace mezi servery na bázi heartbeat – watchdog (kontrola připravenosti systému pro sdílení), systémová aplikace by měla pracovat se shodným číslování linek spojů, linek, dopravců, zastávek dle metodiky CIS JŘ, systémová aplikace by měla umožňovat import a integraci statických jízdních řádů vozidel jiných dopravců (především těch, kteří nemají vlastní ISR a operují na území dispečinku) Tyto informace by měla být následně k dispozici na webových vyhledávačích a na informačních panelech, a to v podobě off-line. Číslování těchto linek dle metodiky CIS. Import jízdních řádů od dopravců operujících na území by měl být realizován ve formátu JDF (shodný s formátem dle §7) odst. 5 vyhlášky č. 388/200 Sb. v platném znění). Tyto informace jsou generovány prostřednictvím SW aplikace a rozhraní, systémová aplikace by měla umožňovat vstup ze systému (jasně definované rozhraní systému) Centrálního systému informací v reálném čase ČR (CISReal), a rovněž umožňovat sdílení dat s dalšími systémy, které překrývají hranice území (dle uvážení provozovatele systému), systémová aplikace by měla zasílat zprávy o chybně provedených transakcích – error s bližší charakteristikou problému, systémová aplikace by měla obsahovat SW funkci „Bezpečnostní agent“ – Řízení přístupu, který spravuje veškeré vstupní a výstupní rozhraní a je k dispozici seznam všech serverů, s kterými systémová aplikace sdružuje data. Tento seznam je přístupný rovněž v rámci tiskových sestav.

Definované požadavky na HW vybavení dopravního dispečinku •

• • • • • • •

25

je doporučeno, aby veškeré HW vybavení dispečinku splňovalo normu pro elektrické přípojky ČSN 33 2000 Elektrotechnické předpisy. Elektrická zařízení a ČSN 34 1010 Elektrotechnické předpisy a všeobecné předpisy pro ochranu před nebezpečným dotykovým napětím, je doporučeno, aby součástí HW vybavení dispečinku bylo vizuální návrh obrazovkového uspořádání dispečerských pracovišť, mělo by být umožněno ovládat všechny obrazovky jednoho pracoviště jednou klávesnicí a myší, na obrazovkách dispečerského pracoviště by mělo být možné zobrazit více programů současně, veškeré obrazovkové technologie a jejich uspořádání by měla plnit hygienické a zdravotní normy a měly by být k dispozici požadované certifikáty o bezpečném používání, dispečerské pracoviště by mělo pracovat v režimu 24/7, pracovní PC dispečerského pracoviště by měla být v dostatečné HW konfiguraci a připraveny pro bezproblémovou práci a zobrazování všech modulů dispečerského systému, včetně práce s mapovými podklady, HW konfigurace PC by měla být zároveň dostatečná pro budoucí rozšiřování dispečerského systému.

Minimální požadavky na centrální SERVER • • • •

• • •

• • •

3.6.

centrální server dispečerského pracoviště by měl splňovat normy ČSN 33 4000 Elektrotechnické předpisy. Požadavky na odolnost sdělovacích zařízení proti přepětí a nadproudu, centrální server by měl splňovat ČSN 34 2300 předpisy pro vnitřní rozvody sdělovacích vedení, centrální server by měl odpovídat vysokým nárokům na rozsah běžících aplikací a počtu současně pracujících uživatelů, HW konfigurace serveru by měla umožňovat zachování plné funkcionality všech běžících aplikací. Zároveň by tato konfigurace měla být dostatečně dimenzovaná a rozšiřitelná pro budoucí možné rozšíření dispečerského systému a zvyšování počtu uživatelů aplikací jak na straně klientských stanic, tak i na straně centrálního serverového řešení, mělo by být umožněno, aby serverové vybavení bylo zahrnuto do instalace, správy a servisu dodavatele, serverového vybavení by mělo obsahovat všechny nutné licence na používané SW aplikace (např. Microsoft Windows), součástí dispečinku by měly být obrazovky (v případě velkých dispečinků, velkoplošné obrazovky, např. LED monitor s úhlopříčkou min. cca 47‘‘), které umožní zobrazování informací dispečerům s těmito nutnými náležitostmi: datum, den v týdnu, přesný čas (synchronizovaný se systémem), venkovní teplota, příp. další meteorologické údaje, prostor pro zobrazení výstražné zprávy (např. výpadek základnové stanice), součástí každé dodávky by měl být grafický návrh a navrhovaný způsob instalace, součástí vybavení dispečerského pracoviště je záložní zdroj, který umožní bezproblémový chod dispečinku i v případě výpadku elektrické energie a to po dobu min 3 hodin, záložní zdroj by měl splňovat ČSN 33 2000 Elektrotechnické předpisy. Elektrická zařízení ČSN 34 1010 Elektrotechnické předpisy. Všeobecné předpisy pro ochranu před nebezpečným dotykovým napětím. Komunikace Centrální dispečink – dispečink

V následujících kapitolách definujeme způsob výměny dat a minimální požadavky pro komunikaci mezi dispečerskými systémy jednotlivých dopravců, dopravních systémů (MHD, IDS) a provozovatele dráhy (SŽDC),(dále jen účastníci). Dále je upravena možnost výměny dat s využitím centralizovaného prvku - Centrálního systému informací v reálném čase (dále jen CISReal).

26

4

Metodika sběru dat - Popis systému CISReal

CISReal –je navržen pro plnění funkce globální entity, která může být realizována dle předmětu této metodiky a následně normy ČSN. Dispečink je navrhován tak, aby bylo možné plnit funkci multimodálního či monomodálního způsobu řízení a organizaci plánování. Metodika a zároveň norma ČSN tímto plní minimální požadavky na kompatibilitu systémů v reálném čase ve veřejné dopravě. CISReal je navržen tak, že může plnit funkci uživatele veškerých zpráv z vozidel konajících službu na území ČR, nebo může vyhodnocovat informace z jednotlivých dispečinků, které dále vyhodnocuje a připravuje k doručení jednotlivým dalším odběratelům – dispečinkům IDS, MHD, jednotlivým dopravcům, nebo dalším žadatelům. Ve své primární roli je CISReal producentem zpráv pro lokální (rovněž integrované) systémy, kterým zasílá užitná data, podle specifikovaných požadavků na sdílení konkrétních funkčních služeb. Jednotliví uživatelé tak mohou mít přístup ke všem spojům/linkám operujících na jejich území (cizí vozidla), a to včetně všech dálkových, popř. mezinárodních (v budoucnu). Systém umožní poskytovat ucelené informace cestujícím přes všechny distribuční kanály a zároveň může být centrálním úložištěm dynamických informací o pohybu vozidel na území ČR. Obrázek 3 blíže představuje funkce a jednotlivé účastníky procesu. CISReal umožní exportovat filtrované zprávy. Mezi filtrované zprávy můžeme definovat alerty (výstrahy) z jednotlivých vozidel, popř. zpoždění vybraných linek. Struktura databáze CISReal je navržena na bázi souboru CEN/TS 15531 (ve zjednodušené podobě, z důvodu dostupnosti CIS JŘ, což je oproti evropské specifikaci značnou výhodou) systém je připraven k interoperabilitě se všemi systémy v ČR, ale rovněž se zahraničními systémy. Celkovou koncepci fungování systému CISReal ukazuje obrázek 3.

27

Obrázek 3: Celková koncepce

4.1.

Vlastnosti CISReal

Navržený CISReal plní funkci globální entity v rámci fungování ISR v ČR. Přes navržený standardní formát a rozhraní bude řízena možnost předávání dat do a vně systému jiným systémům. Mezi základní vlastnosti CISReal patří: • struktura databáze na bázi standardního formátu – zajištění kontinuálního rozvoje, • přímé propojení se statickými daty v rámci CIS JŘ, • import dynamických on-line dat z jednotlivých vozidel, popř. z dispečinků dopravců, IDS, MHD, • export do dispečinků (na základě požadavků jiných ISR) dynamických dat smluvním ISR v rámci celého území ČR, • databanka dynamických dat pro možnost dalšího strategického rozvoje VD v ČR (dopravní obslužnosti). Tyto informace budou k dispozici k výzkumným, popř. strategickým úkolům na základě smluvního vztahu. • poskytování informací cestujícím přes veškeré informační kanály, a to z celého území ČR, • podpora pro informování cestujících – Centrum služeb cestujícím, • propojení s centrálním odbavovacím systémem ČR, • propojení s Jednotným systémem dopravních informací – JSDI.

28

4.2.

Funkce systému

CISReal je jednoznačně v přímé vazbě s CIS JŘ9, který plní většinu funkčních služeb, které SIRI popisuje ve statické podobě. Jednotlivé funkční služby, uvedené níže, jsou součástí fungování CISReal. Mohou tak být následně připraveny k zasílání jednotlivým systémům, které si budou moci vybrat, jaké služby budou využívat. Je jen na lokálních systémech, jejich provozovatelích a organizátorech, které z těchto funkčních služeb budou součástí i jejich systémů. Systém disponuje standardními a nadstandardními (nadstavbovými) funkcemi sledování dat o veřejné dopravě

Obrázek 4: Globální autorita CISReal pro interoperabilitu veřejné dopravy v České republice

4.3.

Standardní funkce systému

Standardními funkcemi jsou: • •

funkce vyhledání provozního jízdního řádu, sledování polohy vozidla (s informací, zda je vozidlo nízkopodlažní). Nadstandardní funkce systému

Nadstandardními funkcemi jsou: • • • • • 9

29

vyhledání spoje v odhadovaném (v reálném čase) jízdním řádu, vyhledání doporučených přípojů, poskytování informací o mimořádnostech na lince, aktualizace dat JŘ na zastávkách, informační servis.

4.4.

Procesní struktura modulů

Jednotlivé standardní a nadstandardní funkce odpovídají navrženým modulům systému CISReal a jsou popsané v článcích níže. Procesní strukturu modulů systému CISReal ukazuje obrázek

4.5.

Obrázek 5: Struktura modulů systému CISRealPrincip řešení CISReal

Fungování systému CISReal je založen na principu zasílání dat přes standardní webové služby za pomocí protokolu http SOAP, v případě potřeby lze podpořit SSL (protokol https). Celkově architektura řešení sleduje jako hlavní cíle výkon, škálovatelnost a dostupnost služby. V případě potřeby posílení celkového výkonu lze mít více instancí modulu CISRealServer na oddělených serverech. Systém je tedy složen z těchto SW komponent: 1) CISRealImportWS, 2) CISRealServer, 3) CISRealExportWS. Ad 1) CISRealImportWS- Forma sběru dat

Jedná se o webovou službu pro příjem zpráv o událostech v reálném čase. V rámci procesu přebírání zpráv jsou ověřeny přístupové klíče uživatele (s UserID) a vnitřní integrita zpráv dle xsd. Následně je zpráva zapsána na disk. V zásadě na principu 1 zpráva = 1 soubor. Ad 2) CISRealServer – Interval sběru dat

CISRealServer plní roli ústředního pracovního procesu jízdních řádů. Kontinuálně načítá do paměti plánované jízdní řády dle CIS JŘ. Zároveň v reálném čase načítá do paměti z disku zprávy o událostech a promítá je do plánu. Následně CISRealServer umožňuje pracovat s jízdním řádem včetně dodatečných informací z přijatých zpráv. V principu server pracuje „pouze“ s aktuálně platnými zprávami. Veškeré neaktuální informace jsou uvolněny z paměti (např. inkriminovaný spoj dojel na konečnou stanici před 32 hodinami). Zprávy budou drženy v paměti po dobu max. 24 hodin. Ad 3) CISRealExportWS – Distribuční rozhraní

Jedná se o webovou službu pro odesílání informací odběratelům. Pro svou činnost interně využívá rozhraní komponenty CISRealServer. Odběratel určuje svým dotazem (request) popř. požadavkem k odběru (subscribe) obsah zpráv, který bude doručen přes komponentu CISRealExportWS. Na obrázku 8 je znázorněna architektura komponent systému CISReal.

30

Obrázek 6: CISReal

Popis jednotlivých funkcí a vysvětlivky Jednotlivé funkce jsou popsány formou služeb SIRI. Tabulky uvedené dále v textu představují stavební prvky XML dokumentů žádostí a odpovědí služeb. Název tabulky představuje obalující prvek dané struktury, který může být dále vkládán do nadřazených struktur. Jednotlivé položky struktury se vkládají do dokumentu jako XML prvky (nikoliv XML atributy). Příklad:

InfoMessage Obecná zpráva RecordedAtTime 1:1 dateTime ItemIdentifier 0:1 string SituationCode ValidUntilTime Content

31

0:* hodnota z číselníku 0:1 dateTime 1:1 string

Okamžik vzniku události. Identifikátor položky pro eventuální pozdější odkazy Producenta. Kód situace svázané s událostí. Platnost zprávy (ne platnost události).

jako XML dokument se zapíše například takto: 2012-08-11T13:20:11+001 MVCRBER21234 <SituationCode>2 <SituationCode>4 <SituationCode>8 2012-08-11T13:30:11+001 Havárie na silnici 324, vyteklý olej, oba směry neprůjezdné Druhý sloupec tabulky určuje (ne)povinnost položky, případně její opakování: 0:1 0:* 1:* 1:1 ^1:1

položka může a nemusí být uvedena položka nemusí být uvedena nebo může být libovolně opakována položka musí být uvedena a může být libovolně opakována položka musí být právě jednou uvedena právě jedna (z několika) položek musí být uvedena

Kurzívou zapsané položky představují prvky kontextově svázané s daty CIS JŘ. Tučně zapsané položky jsou odkazy do veřejně publikovaných číselníků (viz kapitola 11). Položky zapsané trojtečkou se vloží do dokumentu jako skupina prvků (v tomto případě struktury JourneyPatternInfoGroup), nejsou tedy obaleny dalším nadřazeným elementem. :::

0:1

JourneyPatternInfoGroup Volitelné informace o jízdním řádu spoje společné pro celou skupinu spojů - hlavičkový údaj celé skupiny.

Příklad: 2012-08-11T13:20:11+001 1 2 280341 Praha-Beroun-Zdice O jarních prázdninách v Městci zastavuje jen na znamení. 32

... Základní popis způsobu komunikace s webovými službami CISReal – Každý uživatel má svou unikátní identifikaci (32 znaků globálně unikátního identifikátoru), kterou zadává ve všech voláních jakožto prostředek autentizace. Unikátní identifikace je uvedena v číselnících níže. Jednoznačný identifikátor je vždy uveden na smlouvě o vzájemném sdílení dat mezi producentem/uživatelem a CISReal. – Na straně serveru (CISRealServer) je uložena tabulka oprávněných uživatelů, která ke každému ID uživatele obsahuje volitelně seznam IP adres, z nichž je výhradně povolen přístup, dále volitelně omezení na vybrané funkce a rozsah dat, ty jsou rovněž vždy uvedeny ve smlouvě. – Každá funkce služby CISRealExportWS má na vstupu ID uživatele a instanci třídy odpovídající dané funkci. V případě chyby vyvolá služba výjimku. – Každá funkce služby CISRealExportWS má na vstupu ID uživatele a specifikaci rozsahu požadovaných dat. Hodnotou funkce jsou požadovaná data. V případě chyby vyvolá služba výjimku. – Komunikace je vedena standardním protokolem http SOAP. V případě potřeby lze podpořit SSL (protokol https). – Rozhraní služeb je popsáno pomocí jazyka a standardů WSDL (http://www.w3.org/TR/wsdl) a návrhu normy WS-PubSUB, http://www.w3.org/Submission/WS-Eventing/ Funkce služby CISRealImportWS void SetProductionTimetable(string sUserID, ProductionTimetableDelivery oDelivery); void SetEstimatedTimetable(string sUserID, EstimatedTimetableDelivery oDelivery); void SetStopMonitoring(string sUserID, StopMonitoringDelivery oDelivery); void SetVehicleMonitoring(string sUserID, VehicleMonitoringDelivery oDelivery); void SetGeneralMessage(string sUserID, GeneralMessageDelivery oDelivery);

Funkce služby CISRealExportWS StopMonitoringPubDelivery GetStopMonitoring(string sUserID, StopMonitoringRequest oRequest); StopTimetablePubDelivery GetStopTimetable(string sUserID, StopTimetableRequest oRequest);

33

ConnectionTimetablePubDelivery GetConnectionTimetable(string sUserID, ConnectionTimetableRequest oRequest); ConnectionMonitoringPubDelivery GetConnectionMonitoring(string sUserID, ConnectionMonitoringRequest Request); VehicleMonitoringPubDelivery GetVehicleMonitoring(string sUserID, VehicleMonitoringRequest oRequest); GeneralMessagePubDelivery GetGeneralMessage(string sUserID, GeneralMessageRequest oRequest);

4.6.

Metodika sběru dat - komunikace mezi účastníky – typy komunikace

Výměna dat v CISReal (na základech CEN/TS 15531) rozlišuje dva hlavní způsoby komunikace: Dotaz/Odpověď a Publikace/Přihláška k odběru (Request/Response a Publish/Subscribe). Oba způsoby se vzájemně doplňují, implementace může podporovat oba způsoby nebo se řešitelé mohou rozhodnout, který je charakteru jejich aplikace bližší. I jen částečná implementace SIRI podporující pouze komunikaci typu Dotaz/Odpověď je využívána k připojení mnoha informačních systémů k systémům poskytovatelů dat o reálné poloze vozů i k jiným podobným publikujícím systémům. Dialog typu Dotaz/Odpověď (Request/Response) Interakce Dotaz/Odpověď slouží k okamžitému jednorázovému získání dat Žadatelem od Služby. Dvojice Dotaz/Odpověď jsou ovšem použity i v dialozích jiných typů, například Publikace/Přihláška (kdy na oznámení Producenta, že data jsou připravena, reaguje Žadatel vysláním Dotazu, na nějž obdrží od Služby Odpověď). V dialozích určených k získání dat, Žadatel vysílá Dotaz Serveru vystavujícímu rozhraní požadované Služby Funkcionality CISReal a obratem obdrží zprávu Dodání v odpovědi. Své specifické požadavky vyjadřuje Žadatel v parametrech Dotazu. Nemůže-li Služba uspokojit Dotaz, vrací chybovou podmínku popisující příčinu chyby. Dialogy typu Dotaz/Odpověď slouží k okamžitému uspokojení potřeby Žadatele, nicméně nemusí vždy představovat nejefektivnější způsob komunikace. Kupříkladu existují situace, kdy se Žadatel opakovaně dotazuje na data a neustále jsou mu dodávána tatáž nezměněná data, protože podkladový systém dlouho nezměnil svůj stav. V tom případě by byla mnohem vhodnější komunikace, při níž by Konzument obdržel upozornění teprve tehdy, jakmile se data změní, a vyžádal si až jejich změněný stav jediným Dotazem.

Obrázek 7: Způsob komunikace Dotaz/Odpověď

Dialog typu Publikace/Přihláška k odběru informací – Publish/Subscribe Interakce typu Publikace/Přihláška umožňuje asynchronně detekovat události vzniklé v reálném čase běhu Služby, aniž by tato byla neustále zahrnována opakovanými Dotazy. Služba teprve až při vzniku klíčové události vygeneruje Upozornění a zašle je odpovídající množině Přihlašovatelů. Při tomto způsobu komunikace Přihlašovatel iniciuje komunikaci zasláním Přihlášky k odběru jednotce nazývané Producent upozornění. Tento odběr může a nemusí schválit či potvrdit.

34

Potvrzením začíná Odběr zpráv typu Upozornění (na událost výskytu poptávaných dat). Své specifické požadavky vyjadřuje Přihlašovatel v parametrech Přihlášky. Na svoji Přihlášku obdrží potvrzení, že Odběr byl iniciován nebo obdrží chybovou odpověď. Jakmile existuje přihlášený Odběr, služba v roli Producenta upozornění používá parametry odběru k určení, kdy vznikla Situace vyžadující zaslat přihlášeným klientům odpovídající Upozornění. Typ vzniklé Situace se srovnává s parametry zadanými přihlášenými klienty podle jimi poptávaných Témat a ostatních filtračních podmínek a Upozornění zasílá Producent upozornění odpovídajícím množinám Konzumentů. Dodávka samotných poptávaných dat může být uskutečněna jako Přímá dodávka, kdy při vzniku Situace rozesílá Producent upozornění přihlášeným konzumentům již přímo samotná poptávaná data anebo jako Dodávka po vyžádání, kdy je komunikace dvoufázová: nejprve rozesílá pouze Upozornění, na něž klienti reagují zprávou Žádost o dodávku a obdrží poptávanou Dodávku. V kontextu CISReal jsou Přihlášený a Konzument implementovány v rámci shodné služby nebo aplikace, ačkoliv to jsou logicky oddělené entity. Je ale představitelný scénář, kdy jeden Přihlašovatel iniciuje odběr služeb pro několik separátních Konzumentů, například správce nádraží pro všechny své informační panely. Každý Konzument ale musí znát svého Přihlašujícího z důvodu potřeby komunikace, například pro zotavení po chybových situacích v odběru. Přihlášky k odběru jednotlivých Služeb Funkcionality CISReal jsou generovány a zpracovávány odděleně bez vzájemné závislosti. Přihlášený může přihlašovat více oddělených odběrů v různých okamžicích dle momentální potřeby. Přihláška k odběru bude potvrzena pouze tehdy, jestliže ji služba dokáže naplnit, v opačném případě bude vrácen chybový stav v odpovědi na Přihlášku k odběru. Žádost typu Přihláška k odběru obsahuje mj. požadované časové okno trvání odběru, tzv. Čas ukončení odběru. Odběry budou ukončeny Producentem upozornění po naplnění jejich časového okna samotným Producentem upozornění. Ačkoliv je vytváření nových odběrů záležitostí Producenta upozornění, neřídí tento již založené odběry, to je záležitostí Manažera odběrů. Tento návrh (tzn. že Producent upozornění hledá Manažera odběrů pro konkrétního Přihlašujícího spíše, než že Manažer odběrů pro něj hledá Producenta upozornění) je požadován z důvodu konformity s WS-PubSub architekturou. Další možnosti, podrobnosti a způsoby komunikace mezi systémy jsou obsaženy v normě WS-Eventing http://www.w3.org/Submission/WS-Eventing/.

35

Obrázek 8: Způsob komunikace Publish/Subscribe

36

5 SIRI

Definice aplikační logiky souboru technických specifikací CEN/TS 15531

Pro účely tohoto dokumentu jsou v následují části uvedeny základní informace o technické specifikaci SIRI (Service Interface for Real Time Information) CEN/TS10 15531 (SIRI), která byla základním podkladem při sestavování datového modelu pro přenos informací v reálném čase CISReal. Technická specifikace SIRI je tvořena v současné době z pěti částí11 Další připravované nadstavbové části 7 -9 jsou v procesu schvalování. Vyvinutý standard SIRI12 používá termíny a datové prvky referenčního datového modelu pro veřejnou dopravu EN 12896 Transmodelu13, kdykoli existují, a přiřazuje stejné kardinality jako Transmodel, pro jakékoliv spojení mezi prvky. SIRI je navržena jako norma pro výměnu informací mezi systémy, které obsahují data o jízdních řádech a poloze dopravních prostředků v reálném čase V některých případech, SIRI představuje doplňkové prvky nebo atributy pro doplňkové koncepty nezahrnuty v Transmodelu. Mnohdy se jedná o doplňkový atribut existujícího konceptu Transmodelu. V některých jiných případech, doplňkové prvky jsou zavedeny v SIRI pro potřeby existující skupině prvků. Norma počítá se striktním oddělením mezi způsobem přenosu zpráv a definicí samotných doménových dat. Norma SIRI je postavena modulárním způsobem, takže je při využití stejného komunikačního prostředí možné přidávat dodatečné služby. Implementace SIRI může také probíhat postupně po jednotlivých službách tak, jak to národní prostředí umožňuje. Vybrané národní služby SIRI pro Českou republiku jsou uvedeny v tomto článku níže. SIRI sjednocuje pohled na všechna data informačních služeb v reálném čase, datové modely, formáty a komunikační služby. Komplexní integrace je důležitá pro poskytování spolehlivých dat v reálném čase, které vyžadují přesně definovaný datový model a datovou základnu. Pro přenos dat definuje SIRI proces webových služeb Discovery, který umožňuje poskytovatelům dat zpřístupnit možnosti svých služeb ostatním účastníkům. Norma SIRI se dělí na několik základních řešených oblastí: • • • • • • • • •

Služby jízdního řádu (Production Timetable Service); Služby jízdního řádu v reálném čase (Estimated Timetable Service); Služby zastávkového jízdního řádu (Stop Timetable Service); Služby monitorování zastávek (Stop Monitoring Service); Služba sledovaného bodu (obsahem navrženého způsobu komunikace JDSV jednotného formátu datl); Služby monitorování vozidel (Vehicle Monitoring Service); Služba sledovaného vozu (obsahem navrženého způsobu komunikace JDSV jednotného formátu datl); Služby plánovaných přípojů (Connection Timetable Service); Služby sledování přípojů (Connection Monitoring Service);

10

EN 12896 Transmodel je referenční datový model pro veřejnou dopravu, který se v přepracované verzi 5.1 stal v roce 2005 evropskou normou. Tato norma se zabývá koncepcí ústřední databáze, která je důležitou součástí informačního systému ve veřejné dopravě. 11

http://www.silmos.cz/standard/?lang=cz#f=2&norma=CEN+TS+15531-1

http://www.silmos.cz/standard/?lang=cz#f=2&norma=CEN+TS+15531-2 http://www.silmos.cz/standard/?lang=cz#f=2&norma=CEN+TS+15531-3 12

SIRI využívá pro přesnou definici svých zpráv jazyk XML.

37

•

Služby obecných zpráv (General Message Service).

Kromě těchto základních bodů je možné v rámci SIRI řešit široké spektrum dodatečných služeb. Celkovou strukturu služeb podle SIRI ukazuje obrázek 9

Obrázek 9: Zobrazení struktury služeb podle normy SIRI (CEN/TS 15531-1 až 3)

V níže uvedených článcích jsou popsány jednotlivé služby podle koncepce SIRI. 5.1.

Služby jízdního řádu (Production Timetable Service)

Služby jízdního řádu zajišťují výměnu informací o předpokládaném provozu na dopravní síti pro konkrétní den v budoucnosti. Typicky se jedná o jízdní řád, který může být vygenerován několik hodin nebo dnů před uskutečněnou cestou; tento jízdní řád zahrnuje veškeré změny JŘ, které jsou v dané době dostupné (např. výluky). Jízdní řád může být kromě centrálního systému distribuován také na vozidla, chytrá zařízení (smart devices), atd. 5.2.

Služby jízdního řádu v reálném čase (Estimated Timetable Service)

Jízdní řád v reálném čase poskytuje detailní informace o provozu na dopravní síti pro vybraný časový úsek v aktuální den jako: • •

časové odchylky od JŘ; změny JŘ – zrušené trasy, objízdné trasy, nové trasy atd.

Informace jsou vhodné pro sledování vozidel, chytrá zařízení a jízdní řády v reálném čase.

Služby zastávkových jízdních řádů (Stop Timetable Service) a monitorování zastávek (Stop Monitoring Service) 5.3.

Tyto služby poskytují informace o aktuálních a přijíždějících vozidlech na zastávce nebo v sledovaném bodě. Informace o odjezdech jsou typicky zobrazované v předstihu 20 až 60 minut. Služby monitorování zastávek jsou obzvláště vhodné pro posílání informací do informačních zařízení pro cestující, na webové stránky nebo do chytrých zařízení. 5.4.

Služby monitorování vozidel (Vehicle Monitoring Service)

Služby poskytují informace o aktuální pozici a očekávaných aktivitách konkrétního vozidla a mohou

plánované a očekávané časy příjezdu na současné a následné trase vozidla. 38

dodat

Informace jsou zvláště určeny pro vozidlové displeje, k vizualizaci pohybu vozidla (např. na mapě) a pro výměnu informací o vozidlech pohybujících se v zahraničí. Služby je také možno využít k logování informací o reálném pohybu vozidel oproti plánu.

Služby plánovaných přípojů (Connection Timetable Service) a jejich monitorování (Connection Monitoring Service) 5.5.

Služby dopravcům umožňují výměnu informací o přestupech v konkrétním bodě mezi přijíždějícími a odjíždějícími vozidly v reálném čase. Informace mohou být zvláště použity pro tzv. „garantované přípoje“ (spoje s garantovanými přestupy). 5.6.

Služby přenosu obecných zpráv (General Message Service)

Služby zabezpečují způsob přenosu libovolných informací mezi účastníky přepravního procesu. Informace se mohou např. týkat cestovních zpráv, provozních rad nebo jiných informací. Obecné zprávy mohou být také využity pro přenos zpráv o incidentech. 5.7.

Provozní atributy komunikačních protokolů podle SIRI

Komunikační vrstva podporuje jednotný přístup ke všem službám včetně bezpečnosti, autentifikace, verzování, obnovy služby a filtrování přístupu. SIRI využívá sadu obecných komunikačních protokolů pro výměnu typu klient-server. Stejné společné vzory zpráv jsou využívány v různých funkčních rozhraních. Nejvíce jsou využívány následující vzory: • žádost/odpověď umožňuje ad-hoc výměnu dat podle požadavku klienta; • zveřejnění/odběr (publikace/subskripce) umožňuje opakovaný asynchronní příjem oznámení o událostech detekovaných real-time službou a jejich následnou distribuci.

Popis datových struktur pro informace přijímané a odesílané službou je obsahem metodiky

39

6

Názvosloví veřejné dopravy v oblasti informačních systémů

6.1. jízdní řád (timetable) představuje přesné časové a plánovité uspořádání všech jízd vozidel hromadné osobní dopravy POZNÁMKA 1: Jízdní řády ve veřejné linkové osobní dopravě upravuje § 17 odst. 6 zákona č. 111/1994 Sb., o silniční dopravě, ve znění pozdějších předpisů 14 Způsob zpracování, obsah a zveřejňování stanovuje vyhláška 388/2000 Sb., o jízdních řádech veřejné linkové osobní dopravě15. POZNÁMKA 2: Jízdní řády veřejné drážní osobní dopravy na dráze celostátní a regionální upravuje § 40 zákona č. 266/1994 Sb., o dráhách, ve znění pozdějších předpisů. Způsob zpracování, změny, zveřejňování a obsah stanovuje § 50 – 55 vyhláška č 173/1995 Sb.16, kterou se vydává jízdní řád ve znění pozdějších předpisů. POZNÁMKA 3: Jízdní řády veřejné drážní osobní dopravy na dráze tramvajové, trolejbusové, speciální a lanové, způsob zpracování, obsah, vyhlašování a zveřejňování stanovuje § 56 -58 vyhláška č. 173/1995 Sb., kterou se vydává jízdní řád drah ve znění pozdějších předpisů. POZNÁMKA 4: Termín jízdní řád se v současné době běžně používá i pro vodní dopravu, třebaže nejde o jízdy, ale o plavby (termín plavební řád je však obsazen jiným významem). Pro leteckou dopravu se v obdobném významu používá označení letový řád.

6.2. celostátní informační systém o jízdních řádech CISJŘ podle platné právní úpravy (zákon č. 111/1994 Sb., o silniční dopravě, v aktuálním znění, zákon č. 266/1994 Sb., o dráhách, v aktuálním znění a vyhláška MD č. 388/2000 Sb., o jízdních řádech veřejné linkové osobní dopravy) CIS JŘ obsahuje schválené jízdní řády linek veřejné vnitrostátní linkové dopravy (včetně městské autobusové dopravy), schválené jízdní řády linek veřejné mezinárodní linkové dopravy, které mají na území ČR zastávku pro nástup nebo výstup cestujících a schválené jízdní řády veřejné drážní osobní dopravy na dráze celostátní, regionální, tramvajové, trolejbusové, speciální a lanové provozované na území ČR. POZNÁMKA 1: informační systém obsahující informace o přepravním spojení, který vede pro potřeby veřejnosti Ministerstvo dopravy nebo jím pověřená právnická osoba; POZNÁMKA 2: považuje za jedno z míst určených pro styk s cestujícími

6.3. jízdní řád v reálném čase vymezení skutečné prostorové polohy vozidel ve srovnání s předpokladem jízdního řádu

6.4. linková osobní doprava pravidelné poskytování přepravních služeb na určené trase dopravní cesty, při kterém cestující vystupují a nastupují na předem určených zastávkách; linkovou osobní dopravu lze provozovat formou veřejné linkové dopravy nebo formou zvláštní linkové dopravy, a to jako vnitrostátní nebo mezinárodní17.

14

zákona č. 266/1994 Sb., o dráhách, ve znění pozdějších předpisů

15

vyhláška 388/2000 Sb., o jízdních řádech veřejné linkové osobní dopravě

16

Vyhláška MD č 173/1995 Sb., kterou se vydává dopravní řád drah

17

zákon č. 111/1994 Sb., o silniční dopravě, ve znění pozdějších předpisů

40

6.5. veřejná linková doprava doprava, při které jsou přepravní služby nabízeny podle předem vyhlášených podmínek a jsou poskytovány k uspokojování přepravních potřeb; pokud je doprava uskutečňována pro potřeby města a jeho příměstských oblastí, jedná se o městskou autobusovou dopravu

6.6. veřejná drážní doprava doprava provozovaná dopravcem k uspokojování obecných přepravních potřeb podle předem vyhlášených přepravních podmínek, zveřejněného jízdního řádu a tarifu18

6.7. provozovatel silniční dopravy; dopravce právnická nebo fyzická osoba, která provozuje silniční dopravu podle zákona č. 111/1994 Sb. POZNÁMKA 1 Tuzemský dopravce je fyzická osoba s trvalým pobytem nebo právnická osoba se sídlem v České republice, která provozuje dopravu silničními motorovými vozidly, kterým byla přidělena státní poznávací značka Českou republikou. POZNÁMKA 2 Zahraniční dopravce je fyzická osoba s trvalým pobytem nebo právnická osoba se sídlem mimo území České republiky, která provozuje dopravu silničními motorovými vozidly, kterým byla přidělena licence cizím státem. POZNÁMKA 3 Státní příslušnost dopravce je vždy určena správním orgánem státu, který vydal licenci. Existují výjimky, kdy dopravci provozují službu s RZ ČR, ale s licencí jiného státu. V daném případě se jedná o zahraničního dopravce.

6.8. dopravní obslužnost zabezpečení dopravy po všechny dny v týdnu především do škol a školských zařízení, k orgánům veřejné moci, do zaměstnání, do zdravotnických zařízení poskytujících základní zdravotní péči a k uspokojení kulturních, rekreačních a společenských potřeb, včetně dopravy zpět, přispívající k trvale udržitelnému rozvoji územního obvodu19

6.9. integrované veřejné služby vzájemně propojené dopravní služby ve vymezené územní oblasti s jednotnou informační službou, systémem jízdného a jízdním řádem, podle přímo použitelného předpisu Evropských společenství (nařízení (ES) č.1370/2007 Sb.)

6.10. jednotná informační služba zajištění poskytování informací o jednotném jízdním řádu a tarifu na jednom místě

6.11. organizátor dopravy právnická osoba pro plnění úkolů při zřizování a organizaci integrovaných veřejných služeb v přepravě

18 19

zákon č. 266/1994 Sb., o dráhách, v aktuálním znění zákona č. 194/2010 Sb. o veřejných službách v přepravě cestujících a o změně dalších zákonů

41

cestujících, může být pověřen, aby jménem kraje nebo obce uzavíral smlouvy o veřejných službách v přepravě cestujících na určeném území a u určených druhů dopravy20

6.12. palubní systémy ve vozidlech hardwarová zařízení, která se instalují do vozidel VD k zajištění procesů souvisejících s poskytováním informací do dispečinku (centrálního serveru) a cestujícím, a zároveň takové, které umožňují odbavování jednotlivých cestujících

6.13. koncepční hardware; koncepční software vybavení, které bude mít životnost alespoň 5 let a bude mít dostatečný počet univerzálních a normalizovaných hardwarových rozhraní pro integraci nových, v budoucnu instalovaných zařízení POZNÁMKA 1: V oblasti informačních panelů na infrastruktuře (ZPI), popř. zastávkách (ZIS) se rovněž počítá s minimální životností 5 let.

6.14. městská hromadná doprava je systém tvořený dopravními službami městské autobusové dopravy a drážní dopravy na dráze speciální, tramvajové a trolejbusové POZNÁMKA 1: Ve větších sídelních celcích je taktéž konvenční železnice součástí systému MHD. Příkladem jsou například linky S v systému PID.

6.15. označník zastávky je úplné označení zastávky linkové osobní dopravy, včetně zastávky manipulační a dalších zastávek podle druhu dopravních prostředků21. POZNÁMKA 1: Pro účely tohoto dokumentu je zastávkový sloupek roven pojmu označník zastávky. 6.16 nástupiště prostor určený pro nástup nebo výstup cestujících z dopravních prostředků. Nástupiště musí umožňovat rychlé a bezpečné nastupování a vystupování cestujících.22 POZNÁMKA 1: Pro účely tohoto dokumentu je pojem nástupiště roven pojmu označník/sloupek zastávky. 6.17 stanice dopravna s kolejovým rozvětvením, u dráhy speciální i bez kolejového rozvětvení, a se stanoveným rozsahem poskytovaných přepravních služeb23 POZNÁMKA 1: Pro účely tohoto dokumentu je železniční stanice rovna pojmu zastávka (7.33 -STOP POINT).

20

Zákon č. 194/2010 Sb., o veřejných službách v přepravě cestujících a o změně dalších zákonů.

21

ČSN 73 6425-1.

22

SŽDC S4 železniční spodek

23

Vyhláška 173/1995 Sb. TNŽ 73 6390

42

7

Názvosloví – datové prvky CEN/TS 15531-1-3 SIRI

Pro účely této metodiky jsou uvedeny následující pojmy převzaté ze souboru technických specifikací CEN/TS 15531 [2]. Termíny jsou uváděny také v anglickém originále z důvodu možnosti orientace v CENT/TS 15531, ze které se při tvorbě datového modelu CISReal vycházelo. Výklad termínů odpovídá anglickému originálu, který je upraven v návaznosti na ČSN 73 6100-5 - Názvosloví

pozemních komunikací - Část 5: Dopravní telematika.

7.1. cesta veřejnou dopravou (Journey) přesun cestujícího uskutečněný jízdami prostředků veřejné dopravy mezi dvěma zastávkami nebo stanicemi veřejné dopravy zahájený nástupem do vozidla a končící výstupem z vozidla, pokud je použito více prostředků veřejné dopravy, je součástí cesty i přestup mezi nimi

7.2. cizí vozidlo (FOREIGN VEHICLE – SIRI) místní vozidlo z jednoho řídicího centra, které vstoupí na určitou dobu do oblasti spravované jiným řídicím centrem

7.3. číslo linky (LINE NUMBER – TransModel) číslo linky veřejné linkové dopravy a označení dráhy linek drážní dopravy na dráze tramvajové, trolejbusové a speciální je šestimístné z rozhodnutí o licenci, v drážní dopravě na dráze celostátní a regionální se jedná o případné označení vlakové linky v rámci integrovaného dopravního systému. POZNÁMKA 1: V regionální dopravě první trojčíslí označuje dopravní úřad, který vydal licenci a druhé trojčíslí označuje pořadové číslo linky. V městské hromadné dopravě první trojčíslí označuje dopravní úřad či drážní správní úřad, který vydal licenci a druhé trojčíslí označuje pořadové číslo linky. POZNÁMKA 2: Obecně dochází ke zkracování čísla linek pro účely prezentace veřejnosti, tohoto zkracování lze používat, pokud o tom rozhodl dopravní úřad v rozhodnutí o licenci.

7.4. datový systém (DATA SYSTEM – TransModel) původce provozních údajů, které se odkazují k jedné odpovědné entitě; odkazy na datový systém jsou užitečné v interoperativním počítačovém systému; pro SIRI to znamená zejména specifické systémy pro přiřazování jedinečných identifikátorů k příslušným entitám, jako jsou zastávky nebo jízdy, mezi kterými jsou vyměňovány zprávy a které mohou být přizpůsobeny místně známým entitám identifikovaným příslušnými interními provozními daty; datový systém musí být vzájemně odsouhlasen mezi klientem a serverem; datový systém musí obsahovat jak datový model popisující entity a jejich vztahy, tak i jmenný prostor popisující jednoznačný soubor hodnot identifikátorů

7.5. druh dopravy (TRANSPORT MODE – Transmodel) charakterizace provozu podle druhu dopravního prostředku (např. autobus, tramvaj, metro, vlak, trajekt, loď)

7.6. funkční služba (SIRI FUNCTIONAL SERVICE – SIRI) specifická konkrétní služba, která poskytuje funkci, jako je monitorování zastávek nebo plánovaných přípojů; zahrnuje soubor pojmenovaných zpráv tvořících rozhraní SIRI, které musí být použity v souladu jak s obecnými komunikačními pravidly SIRI, tak se specifickou sémantikou konkrétní služby

43

7.7. hláška vozidla (CALL – SIRI) zaslání dat z vozidla z každého dosaženého souboru plánovaných bodů, nebo časů v rámci jízdního řádu spoje; vozidlo může provést z jedné zastávky více než jednu hlášku vozidla během své jízdy dle jízdního řádu; jednotlivé hlášky vozidla jsou rozlišeny pořadím pobytů, kterým jsou přiřazeny příslušné reálné časy; hláška vozidla kombinuje prvky Transmodelu jako jsou, bod v jízdním řádu spoje, očekávaný čas průjezdu, zjištěný čas průjezdu a cílový čas průjezdu, s prvky v reálném čase a jinými vlastnostmi zastávky příslušných k pobytu vozidla; SIRI oddělením prvků příslušných příjezdu od těch, které přísluší odjezdu, usnadní ověření platnosti a implementaci systémů

7.8. jízdní řád spoje (JOURNEY PATTERN – TransModel) opakovaná jízda vozidla nebo vlaku v určité trase a určitém čase, uvedená v jízdním řádu, která je vymezená výchozí a cílovou stanicí nebo zastávkou; jízdní řád spoje může procházet stejnou zastávkou vícekrát; první zastávka jízdního řádu spoje je počátek, poslední zastávka je cíl; každá jízda vozidla má svůj příslušný jízdní řád; v SIRI nejsou jízdní řády spoje vyjádřeny na rozhraní: předpokládá se, že prvky jako linka a směr trasy objevující se na trasách jízdy vozidel jsou odvozeny z příslušných jízdních řádů spoje

7.9. incident; mimořádnost (INCIDENT –TransModel) nepředvídaná událost ovlivňující provoz sítě, průběh incidentu je prezentován pod heslem situace

7.10. spoj (VEHICLE JOURNEY – TransModel) dopravní spojení v rámci linky, které je časově a místně určené jízdním řádem; v SIRI vozidlo odvysílá na každé zastávce hlášku; čas příjezdu a odjezdu mohou být samostatné časy; hlášky mohou být také zaslány v momentě vjezdu do zájmového území, opouštění prostoru, zastavení u sloupku, v momentě otevření/zavření dveří apod.; datovaná jízda vozidla je případem jízdy vykonané ve specifickém kalendářním dnu

7.11. linka (LINE – TransModel) linka je souhrn dopravních spojení na trase dopravní cesty určené výchozí a cílovou zastávkou a ostatními zastávkami, na níž jsou poskytovány přepravní služby podle platné licence nebo povolení a podle schváleného jízdního řádu POZNÁMKA 1: Pojem linka se ve vztahu k železniční dopravě v současné platné legislativě nepoužívá. Osobní železniční doprava je organizována vlaky, které jsou identifikovány jednoznačným číslem v rámci dráhy a které jsou časově a místně určené jízdním řádem. V současné praxi integrovaných dopravních systémů mohou být části vlaků, které jsou zařazeny do integrovaného dopravního systému a které splňují výše uvedenou definici linky, seskupeny a označeny jako linka POZNÁMKA 2:

Ve vztahu k tomuto dokumentu je pojem linka užíván víceoborově.

7.12. místní vozidlo (LOCAL VEHICLE – SIRI) vozidlo, které provádí službu v rámci dispečinku spravujícího vlastní vozový park, jehož je součástí, daný dispečink je organizační jednotka odpovědná za poskytování a aktualizaci příslušných dat, jízdních řádů apod.

7.13. místo (PLACE – Transmodel) zeměpisné místo jakéhokoli druhu, které může být uvedeno jako začátek nebo cíl cesty; místo může být dimenze: 0 (bod), 1 (úsek PK) nebo 2 (zóna); v IFOPT může být místo i dimenze 3 ve spojení s úrovní

44

7.14. odběratel (SUBSCRIBER – WS-PubSub) entita, která působí jako žadatel služby, odesílající požadavky na subskripci (odběr informací) jménem uživatele producentovi notifikace; uživatel bude zpravidla toutéž entitou jako odběratel, ale může to být také samostatná entita

7.15. odvážející spoj (DISTRIBUTOR – SIRI) role odjíždějícího vozidla v rámci určeného přestupu. Odvážející spoj odváží cestující z přípojů z přestupního uzlu

7.16. producent (zpráv) (PRODUCER – WS-PubSub) entita, která posílá notifikační zprávy uživateli jako výsledek předchozí subskripce na konkrétní funkční službu; události, které vedou ke zvýšení počtu notifikačních zpráv, jsou posílány producentovi entitou vydavatele

7.17. provozovatel (OPERATOR – Transmodel) organizace, která má na starosti provoz některých nebo všech dopravních služeb v rámci určité oblasti

7.18. nadjetí (EARLY – SIRI) kategorizace příjezdu/odjezdu vozidla užívaná při prezentaci dat udávající, že vozidlo přijelo/odjelo dříve oproti jízdnímu řádu spoje a je tedy podle stanovených kritérií klasifikováno jako předjeté; status předjetí bude odvozen z dat snímaných v reálném čase; tento termín by měl být odlišen od termínu odchylka od jízdního řádu, která stanovuje tolerovanou odchylku od jízdního řádu v sekundách. POZNÁMKA 1:

Užívá se také pojem náskok

7.19. přestupní uzel (CONNECTION LINK – TransModel) pro účely tohoto dokumentu se jedná o fyzickou (územní) možnost pro cestujícího přestoupit z jednoho veřejného dopravního prostředku do jiného, v normě SIRI může mít služba přivážejícího vozidla příjezd k jednomu zastávkovému označníku (sloupku)/nástupišti a služba odvážejícího vozidla může odjíždět od stejného nebo jiného označníku/nástupiště ; přestupní doba je pak ve vazbě na obsah datového formátu myšlena jako čas potřebný pro přechod od jednoho označníku/nástupiště ke druhému; přestupní doba nezahrnuje dobu nástupu a výstupu; může být uvedeno několik různých typů přestupních dob POZNÁMKA 1: V železniční dopravě se jedná o možnost pro cestující přestoupit mezi spoji v rámci nástupišť. V linkové dopravě se jedná pro o přestup mezi označníky/sloupky POZNÁMKA2: Vzhledem k multioborovému zaměření softwarové platformy CISReal se jedná také o možnost přestupu mezi zastávkou/stanicí.

7.20. přípoj (SERVICE JOURNEY INTERCHANGE TransModel) možnost přesunu cestujících podle jízdního řádu mezi dvěma obslužnými jízdami ze stejné nebo různých zastávek/stanic nebo označníku/nástupiště; v normě SIRI existují mechanismy pro řízení přípojů v reálném čase mezi jízdou přivážejícího vozidla a jízdou odvážejícího vozidla; tento mechanismus je znám jako „jištění přestupů“; existují čtyři různé stupně řízení přípojů: plánované – přípoj je plánován v normálním statickém jízdním řádu; inzerované – přípoj je plánován a je publikován jako možný; ovládané – přípoj je aktivně sledován, aby cestující byli informováni, zda je přestup možný; garantované – služba vozidla odvážejícího bude eventuálně zpožděna, aby byl zajištěn přípoj; služba přestupu mezi jízdami umožňuje i ukládání kvalitativního parametru pro zajištění přípojů, poskytující maximální dobu, po kterou vozidlo může čekat na přípoj nad plánovaný čas odjezdu

45

7.21. přivážející spoj (FEEDER – SIRI (Informal TransModel term)) role přijíždějícího vozidla v jízdním řádu spoje na určeném přestupu, které přiváží cestující k příjezdové zastávce/stanici nebo označníku/nástupišti, mající přípojnou linku na odjezdové zastávce/stanici nebo označníku/nástupišti, ze kterého je možno využít služby odvážejícího spoje; vozidlo může vykonávat současně roli přivážejícího a odvážejícího spoje, to znamená, z vozidla vystoupí cestující pro jiné služby a nastoupí cestující z jiných služeb

7.22. roaming (ROAMING – SIRI) pohyb vozidla v prostoru, který spravuje jiné řídicí centrum; v domovském řídicím centru se jedná o místní vozidlo; v jiných řídicích centrech jde o cizí vozidlo

7.23. řídicí centrum; dispečink (CONTROL CENTRE – SIRI) organizační jednotka, která spravuje síť nebo sítě vozidel a jejich obslužných real-time systémů, a odpovídá každému účastníkovi služby SIRI; každé řídicí centrum má jedinečný identifikátor (kód řídicího centra), který poskytuje rámec (tj. unikátní jmenný prostor) pro všechny neglobální datové odkazy, jako jsou zastávkové identifikátory, identifikátory vozidel atd.; odkaz uvnitř řídicího centra musí být jedinečný; vozidla a jízdy, které jsou v rozsahu řízení daného řídicího centra, jsou definovány jako místní; vozidla a jízdy, které nejsou v rozsahu řízení daným řídicím centrem, jsou definovány jako cizí

7.24. subskribce; přihláška k odběru informací (SUBSCRIPTION – WS-PubSub) zdroj vytvořený, aby představoval vztah mezi uživatelem notifikace a jejím producentem, tématem a jinými filtry a politikami; subskribce je vytvořena, když uživatel odešle požadavek na subskribci producentovi notifikace, který působí jako zřizovatel nových subskribcí; subskribce může být následně změněna prostřednictvím manažera subskripce

7.25. trasa (ROUTE – TransModel) uspořádaný seznam lokalizovaných bodů definující jedinou cestu na silniční (nebo železniční) síti; trasa může projít stejným bodem více než jednou; každý jízdní řád spoje může být spojen s konkrétní trasou

7.26. trasa spoje (SERVICE PATTERN – TransModel) podmnožina jízdního řádu spoje složená pouze ze zastávek v jízdním řádu spoje

7.27. účastník (PARTICIPANT – SIRI) účastník má svou referenci, která se používá k jeho identifikaci při výměně zpráv a také k poskytování univerzálních jmenných prostorů pro oblast arbitrárních identifikátorů modelových prvků, jako jsou linky a identifikátory vozidla; v SIRI jsou účastníky uživatelé a producenti notifikací (tj. dispečinky) systém, který se podílí na výměně zpráv pomocí protokolů SIRI

7.28. účastník služby (SIRI SERVICE PARTICIPANT – SIRI) systém, který se účastní výměny zpráv SIRI s jinými účastníky služby; každý účastník služby má jednoznačný identifikátor (účastnický kód), který poskytuje prostor (tj. unikátní jmenný prostor) pro všechny neglobální datové reference, jako například identifikátory zastávek, identifikátory vozidla, ale i pro identifikátory zpráv požadavků nebo subskribcí; účastníci služby budou buď funkční služební systémy SIRI poskytující informace, nebo akreditované klientské systémy, které vysílají požadavky a subskribce na služby pro získání informací

46

7.29. užitná data (PAYLOAD – SIRI) obsah datové části doručené zprávy bez prvků používaných pro řízení výměny zpráv, jako jsou prvky odkazu na koncový bod POZNÁMKA1: vyměňovány.

Obsah užitných dat zprávy je stejný bez ohledu na to, jakým protokolem jsou informace

7.30. uživatel notifikace (NOTIFICATION CONSUMER – WS-PubSub) klient, který obdrží notifikační zprávu od producenta notifikace; role mohou být prováděny stejnou nebo jinou entitou, jakou má odběratel, který vytvořil subskribci, jež jako první požádala o zasílání notifikačních zpráv

7.31. uživatel; zákazník (CONSUMER – WS-PubSub) subjekt, který obdrží notifikace od producenta jako výsledek provedené předchozí subskripce na službu

7.32. vydavatel (Publisher – WS-PubSub) entita, která zpracovává události v datovém zdroji a odesílá notifikační zprávy producentovi pro zprostředkování a distribuci uživatelům; producent může provádět další zprostředkování, jako je filtrování nebo datové transformace; použití producenta notifikace je v SIRI transparentní

7.33. zastávka/ stanice (STOP POINT – TransModel) bod, určený pro nástup a výstup cestujících POZNÁMKA 1: Zastávka je pro účely tohoto dokumentu chápána jako množina zastávkových označníků, která obsahuje alespoň jeden zastávkový označník POZNÁMKA 2:

Železniční stanice je pro účely tohoto dokumentu chápána jako množina nástupišť

7.34. zpoždění (LATE – SIRI) kategorizace označující pro prezentaci, že vozidlo bylo klasifikováno jako zpožděné tj., že vozidlo jede časově za jízdním řádem podle některých stanovených kritérií; stav zpoždění je odvozen od časových údajů v reálném čase

7.35. zprostředkovatel notifikace (NOTIFICATION BROKER – WS-PubSub) samostatná zprostředkovatelská entita, která může být použita k distribuci notifikačních zpráv vytvářených entitou vydavatele pro jednu či více služeb producenta notifikace; to umožňuje oddělení vydavatelské a producentské role, pokud je to žádoucí; zprostředkovatel notifikace může také poskytovat zvláštní služby, jako je řízení přístupu

47

8

Forma sběru dat - Informace přijímané službou systému CISReal

Služby přijímané službou systému CISReal jsou: Služba jízdního řádu [PT], článek 8.1; Služba odhadovaného jízdního řádu [ET], článek 8.2; Služba sledovaného bodu [SM], článek 8.3; Služba sledovaného vozu [VM], článek 8.4; Služba obecných zpráv [GM], článek 8.5. 8.1

Služba provozního jízdního řádu [PT] a jeho případných dispečerských změn

Provozní jízdní řád prezentuje informace o vybraných linkách a spojích, podle dostupných a naplánovaných podkladů. Modul (funkce) provozního jízdního řádu obsahově odpovídá současnému systému CIS, ale přidává k němu požadavky na nové datové položky (např. informace o přípojích) a komunikační standardy (struktury podle xsd SIRI schémat). Dispečink dopravce takto zasílá změny jízdních řádů oproti plánu zadanému do CIS JŘ. Tabulka 1 – Datová struktura služby provozního jízdního řádu ProductionTimetableDelivery DatedTimetableVersionFrame

1:*

structure

Denní projekce jízdního řádu množiny spojů (např. linky).

:::

0:1

DispatchSituationChange Group

Tato dispečerská změna provozního jízdního řádu (několik změn) vznikla dispečerským řízením.

Tabulka 2 – Datová struktura prvku DatedTimetableVersionFrame DatedTimetableVersionFrame Denní projekce množiny spojů jízdního řádu (např.linky)

RecordedAtTime

1:1

dateTime

Okamžik vzniku změnové události.

:::

0:1

JourneyPatternInfoGroup

Volitelné informace o jízdním řádu spoje společné pro celou skupinu spojů – hlavičkový údaj celé skupiny. Přebíjený prvky JourneyPatternInfoGroup jednotlivých DatedVehicleJourney

:::

0:1

ServiceInfoGroup

Volitelné popisné atributy spoje (mj. jeho dopravce) – hlavičkový údaj celé skupiny. Přebíjený prvky ServiceInfoGroup jednotlivých DatedVehicleJourney.

DatedVehicleJourney

1:*

structure

Informace o jednotlivých spojích.

48

Tabulka 3 – Datová struktura prvku DatedVehicleJourney DatedVehicleJourney Časování jízdního řádu jednotlivého spoje

DatedVehicleJourneyRef

1:1

structure

Jednoznačná identifikace spoje/nástupiště vůči plánovanému CIS JŘ.

Cancellation

0:1

boolean

Tento spoj z plánovaného JŘ nejede.

ExtraJourney

0:1

boolean

Toto je spoj navíc oproti plánovanému JŘ.

:::

0:1

JourneyPatternInfoGroup

Volitelné informace o jízdním řádu spoje přebíjí hlavičkový JourneyPatternInfoGroup skupiny.

:::

0:1

ServiceInfoGroup

Volitelné popisné atributy spoje (mj. jeho dopravce) přebíjí hlavičkový ServiceInfoGroup skupiny.

JourneyOptionCode

0:*

hodnota z číselníku

Atributy spoje. V CIS JŘ odpovídá pevným kódům spoje.

JourneyNote

0:*

string

Pro ExtraJourney i stávající spoje: textové poznámky ke spoji. Struktura umožňuje v CISreal doplnit stávající poznámky CIS JŘ k lince dispečerskými texty.

DatedCalls DatedCall

0:1 2:*

structure

Kompletní sekvence zastavení spoje v pořadí daném jízdním řádem spoje.

Tabulka 4 – Datová struktura prvku DatedCall DatedCall Zastavení spoje na zastávce

StopPointRef

0:1

structure

Jednoznačný identifikátor sloupku/nástupiště plánovaného JŘ.

StopTC

0:1

positiveInteger

Tarifní číslo zastávky či stanice dle plánovaného JR Není třeba uvádět, pokud není v jízdním řádu opakování zastavení na téže sloupku.

ExtraCall

0:1

structure

Toto Zastavení nad plán nemá obraz v žádném známém prvku. Tento prvek nese vyčerpávající popis tohoto zastavení navíc: polohu, vybavení atp.

PathToNextCall

0:1

structure RoutePath

Umožní vložit geometrii lomené čáry k následujícímu zastavení. V CISreal umožní dokreslit trasu, která není v CIS JŘ.

CallOptionCode

0:*

hodnota z číselníku

Doplňující atributy zastavení. V CIS JŘ odpovídá pevným kódům zastavení spoje na zastávce.

CallNote

0:*

string

Doplňující textové poznámky k tomuto konkrétnímu zastavení. V CISreal umožní zadat dispečerské texty zastavení.

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ArrivalPlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při příjezdu

DeparturePlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při odjezdu

49

8.2 Získávání informací o vozidlech veřejné dopravy - Služba odhadovaného jízdního řádu [ET] (jízdního řádu v reálném čase)-

Dispečink dopravce takto zasílá předpokládaný aktuální jízdní řád spojů se zapracovaným zpožděním, mimořádnostmi na trase, apod. Tabulka 5 – Datová struktura služby odhadovaného jízdního řádu EstimatedTimetableDelivery EstimatedTimetableVersionFrame

1:*

structure

Denní projekce jízdního řádu množiny spojů modifikované skutečnou jízdou vozů, dispečerskými zásahy a predikcí AVMS.

:::

0:1

DispatchSituationChange Group

Tato dispečerská změna provozního jízdního řádu (několik změn) vznikla dispečerským řízením.

Tabulka 6 – Datová struktura prvku EstimatedTimetableVersionFrame EstimatedTimetableVersionFrame Denní projekce jízdního řádu množiny spojů modifikovaná skutečnou jízdou vozidla a predikcí AVMS

RecordedAtTime

1:1

dateTime

Okamžik vzniku změnové události.

EstimatedVehicleJourney

1:*

structure

Informace o jednotlivých spojích.

Tabulka 7 – Datová struktura prvku EstimatedVehicleJourney EstimatedVehicleJourney Časování jízdního řádu jednotlivého spoje

DatedVehicleJourneyRef

1:1

structure

Jednoznačná identifikace spoje vůči plánovanému CIS JŘ nebo v předchozí dodávce zaslanému ProductionTimetable.

Cancellation

0:1

boolean

Tento spoj z plánovaného nebo provozního JŘ nejede.

ExtraJourney

0:1

boolean

Toto je spoj navíc oproti plánovanému nebo provoznímu JŘ.

:::

0:1

JourneyPatternInfoGroup

Volitelné informace o jízdním řádu spoje (přebíjí hlavičkový JourneyPatternInfoGroup skupiny).

:::

0:1

ServiceInfoGroup

Volitelné popisné atributy spoje (mj. jeho dopravce; přebíjí hlavičkový ServiceInfoGroup skupiny).

JourneyOptionCode

0:*

hodnota z číselníku

Atributy spoje. V CIS JŘ odpovídá pevným kódům spoje.

JourneyNote

0:*

string

Pro ExtraJourney i stávající spoje: textové poznámky ke spoji. Struktura umožňuje v CISreal doplnit stávající poznámky CIS JŘ k lince dispečerskými texty.

PredictionInaccurate

0:1

boolean

Zda je predikce časování spoje nepřesná (zácpa, neovlivnitelné podmínky).

EstimatedCalls EstimatedCall

0:1 2:*

structure

Kompletní sekvence zastavení spoje v pořadí daném jízdním řádem spoje.

50

Tabulka 8 – Datová struktura prvku EstimatedCall EstimatedCall Zastavení spoje na zastávce s vloženou informací o skutečném průběhu a/nebo predikcí

StopPointRef

0:1

structure

Jednoznačný identifikátor plánovaného JŘ.

sloupku/nástupiště

StopTC

0:1

positiveInteger

Tarifní číslo zastávky či stanice dle plánovaného JR Není třeba uvádět, pokud není v jízdním řádu opakování zastavení na téže sloupku.

ExtraCall

0:1

structure

Toto Zastavení nad plán nemá obraz v žádném známém prvku. Tento prvek nese vyčerpávající popis tohoto zastavení navíc: polohu, vybavení atp.

PathToNextCall

0:1

structure RoutePath

Umožní vložit geometrii lomené čáry k následujícímu zastavení. V CISreal umožní dokreslit trasu, která není v CIS JŘ.

CallOptionCode

0:*

pole hodnot z číselníku

Doplňující atributy zastavení. V CIS JŘ odpovídá pevným kódům zastavení.

EstimatedCall Zastavení spoje na zastávce s vloženou informací o skutečném průběhu a/nebo predikcí

CallNote

0:*

string

Doplňující textové poznámky k tomuto konkrétnímu zastavení. V CISreal umožní zadat dispečerské texty zastavení.

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

ExpectedArrivalTime

0:1

dateTime

Odhadovaný příjezd ze skutečné jízdy vozidla a/nebo predikce AVMS.

ArrivalStatusCode

0:1

hodnota z číselníku

Klasifikace očekávaného příjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...).

CallStatusCode

AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ExpectedDepartureTime

0:1

dateTime

Odhadovaný odjezd ze skutečné jízdy vozidla a/nebo predikce AVMS.

DepartureStatusCode

0:1

hodnota z číselníku

Klasifikace očekávaného odjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...).

CallStatusCode

ArrivalPlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při příjezdu

DeparturePlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při odjezdu

51

8.3

Služba sledovaného bodu [SM]

Dispečink takto zasílá obsah odjezdových tabulí zastávkového informačního systému. Tabulka 9 – Datová struktura služby StopMonitoringDelivery StopMonitoringDelivery MonitoredPoint

0:*

structure

Kompletní obsahy - několika - logických zobrazení (ne nutně všech displejů Producenta).

Note

0:1

string

Obecný text asociovaný s celou dodávkou.

Tabulka 10 – Datová struktura prvku MonitoredPoint MonitoredPoint Kompletní obsah logického zobrazení

MonitoringRef

0:1

structure

Logické zobrazení jako identifikátor sledovaného bodu může být Zastávka, Sloupek nebo Časovací bod. Vloží se tehdy, pokud mají být informace na daném MonitoringRef prázdné (a neexistovala by tedy žádná MonitoredStopVisit)

MonitoredStopVisit

0:*

structure

Seznam zastavení (příjezdů a/nebo odjezdů) jednotlivých spojů na logické zobrazení.

StopLineNote

0:*

structure

Poznámky vztahující se k jednotlivým linkám.

MonitoredPointNote

0:*

string

Obecný text k celému logickému zobrazení.

Tabulka 11 – Datová struktura prvku MonitoredStopVisit MonitoredStopVisit Zastavení (příjezdy a/nebo odjezdy) jednotlivých vozidel na logické zobrazení

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

MonitoredVehicleJourney

1:1

structure

Nese informaci o sledovaném spoji.

StopVisitNote

0:*

string

Poznámky vztahující se k tomuto Zastavení.

Tabulka 12 – Datová struktura prvku StopLineNote StopLineNote Textová poznámka k lince pro logické zobrazení

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

LineRef

1:1

structure

Identifikátor linky.

SituationCode

0:*

hodnota z číselníku

Situace asociované s položkou linky.

LineNote

0:*

string

Poznámky vztahující se k této lince.

52

Tabulka 13 – Datová struktura prvku MonitoringRef MonitoringRef Logický displej (identifikátor sledovaného bodu)

jedna z:

StopPointRef

^ 1:1

LogicalDisplay

structure

Jednoznačný identifikátor sloupku/nástupiště plánovaného JŘ.

structure

Logické zobrazení shromažďuje informace o několika sloupcích , třeba i na rozdílných dopravních sítích doplněné například i textovými informacemi obecného charakteru (Olomouc hl. n. apod.).

Tabulka 14 – Datová struktura prvku MonitoredVehicleJourney MonitoredVehicleJourney Sledovaný spoj

DatedVehicleJourneyRef

0:1

structure

Jednoznačná identifikace spoje vůči plánovanému CIS JŘ nebo v předchozí dodávce zaslanému ProductionTimetable.

:::

0:1

JourneyPatternInfoGroup

Informace o jízdním řádu spoje.

:::

0:1

VehicleJourneyInfoGroup

Informace umožňující identifikovat spoj textově.

:::

0:1

JourneyProgressInfoGroup

Popis průběhu jízdy spoje.

:::

0:1

OperationalInfoGroup

Služba a vozidlo jedoucí spoj.

VehicleFeatureRef

0:*

hodnota z číselníku

Vlastnosti vozu ( jedná se o určení vlastností dle číselníku uvedeného v kapitole 11)

PreviousCalls PreviousCall

0:1 1:*

structure

Předchozí zastavení spoje vyjma aktuálního zastavení. Je-li struktura vložena, pak musí obsahovat všechny PreviousCall před MonitoredCall.

MonitoredCall

1:1

structure

Aktuální zastavení spoje na zastávce/sledovaném bodu.

OnwardCalls OnwardCall

0:1 1:*

structure

Následující zastavení spoje.

Tabulka 15 – Datová struktura prvku MonitoredCall

MonitoredCall Zastavení na sledované zastávce

StopPointRef

0:1

structure

Jednoznačný identifikátor plánovaného JŘ.

sloupku/nástupiště

StopTC

0:1

positiveInteger

Tarifní číslo zastávky či stanice dle plánovaného JR Není třeba uvádět, pokud není v jízdním řádu opakování zastavení na téže zastávce/sloupku.

VehicleAtStop

0:1

boolean

Spoj stojí právě v zastávce.

VehicleLocationAtStop

0:1

structure Location

Poloha spoje stojícího v zastávce.

53

Tabulka 15 – Datová struktura prvku MonitoredCall (pokračující)

MonitoredCall Zastavení na sledované zastávce/stanici

CallOptionCode

0:*

hodnota z číselníku

Doplňující atributy zastavení. V CIS JŘ odpovídá pevným kódům zastavení.

CallNote

0:*

string

Poznámky k zastavení. V CISreal umožní zadat dispečerské texty.

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

ExpectedArrivalTime

0:1

dateTime

Odhadovaný příjezd predikcí AVMS. Zjištěný příjezd změřený AVMS.

ActualArrivalTime ArrivalStatusCode

0:1

hodnota z číselníku CallStatusCode

Klasifikace očekávaného příjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...).

AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ExpectedDepartureTime

0:1

dateTime

Odhadovaný odjezd predikcí AVMS. Zjištěný odjezd změřený AVMS.

ActualDepartureTime DepartureStatus

0:1

hodnota z číselníku CallStatusCode

Klasifikace očekávaného odjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...).

ArrivalPlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při příjezdu

DeparturePlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při odjezdu

54

Tabulka 16 – Datová struktura prvku PreviousCall PreviousCall Zastavení na předchozí zastávce/stanici ve směru jízdy spoje

StopPointRef

0:1

structure

Jednoznačnýidentifikátorsloupku/nástupiště plánovaného JŘ.

StopTC

0:1

positiveInteger

Tarifní číslo zastávk či stanice na trase linky plánovaného JŘ. Není třeba uvádět, pokud není v jízdním řádu opakování zastavení na tomtéž sloupku/nástupišti.

VehicleAtStop

0:1

boolean

Spoj stojí právě v zastávce či stanici.

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

ExpectedArrivalTime

0:1

dateTime

Odhadovaný příjezd predikcí AVMS. Zjištěný příjezd změřený AVMS.

ActualArrivalTime AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ExpectedDepartureTime

0:1

dateTime

Odhadovaný odjezd predikcí AVMS. Zjištěný odjezd změřený AVMS.

ActualDepartureTime

Tabulka 17 – Datová struktura prvku OnwardCall OnwardCall Zastavení na příští zastávce/stanici ve směru jízdy spoje

StopPointRef

0:1

structure

Jednoznačnýidentifikátor plánovaného JŘ.

StopTC

0:1

positiveInteger

Tarifní číslo zastávky či stanice linky plánovaného JŘ. Není třeba uvádět, pokud není v jízdním řádu opakování zastavení na tomtéž sloupku/nástupišti

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

ExpectedArrivalTime

0:1

dateTime

Odhadovaný příjezd predikcí AVMS.

ArrivalStatus

0:1

hodnota z číselníku

Klasifikace očekávaného příjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...).

CallStatusCode

sloupku/nástupiště

AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ExpectedDepartureTime

0:1

dateTime

Odhadovaný odjezd predikcí AVMS.

DepartureStatus

0:1

hodnota z číselníku

Klasifikace očekávaného odjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...).

CallStatusCode

ArrivalPlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při příjezdu

DeparturePlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při odjezdu

55

8.4

Získávání informací o vozidlech veřejné dopravy- Služba sledovaného vozidla [VM]

Modul sledování polohy vozidel bude především sloužit pro aktualizaci dat provozního jízdního řádu a umožní komfortní sledování polohy na mapovém podkladu podle datových protokolů specifikovaných v SIRI. Dispečink dopravce takto zasílá informace o průběhu jízdy vozidel v reálném čase. Tabulka 18 – Datová struktura služby VehicleMonitoringDelivery VehicleMonitoringDelivery VehicleActivity

0:*

structure

Popisuje průběh jízdy vozidla po své trase nebo přípravu na tuto jízdu.

VehicleActivityCancellation

0:*

structure

Odkaz na předchozí VehicleActivity, které mají být již ukončeny.

Note

0:1

string

Obecný text asociovaný s celou dodávkou.

Tabulka 19 – Datová struktura prvku VehicleActivity VehicleActivity Pozice a relativní průběh jízdy vozidla vykonávajícího Sledovanou jízdu včetně plánovaných a/nebo předpokládaných časů

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

ItemIdentifier

0:1

string

Identifikátor položky uvnitř intervalu platnosti dat Producenta. Použije se pro pozdější odkazy na výmaz položek.

VehicleMonitoringRef

0:1

string

Identifikace sledovaného spoje v kontextu dat Producenta. Doporučuje se registrační značka vozidla RZ.

ProgressBetweenStops

0:1

structure Location

Poloha spoje.

LinkDistance

0:1

positiveInteger

Vzdálenost mezi předchozí zastávkou/stanicí v metrech.

Percentage

0:1

positiveInteger

Procento této dráhy, které vozidlo již ujelo.

MonitoredVehicleJourney

1:1

structure

Nese informaci o sledovaném spoji.

VehicleActivityNote

0:*

string

Poznámky ke sledované jízdě vozidla.

a

příští

Služba v základní podobě nevyžaduje plnění všech hlášek zastavení (Calls) včetně predikce jízdy na následujících OnwardCalls. Předchozí zastavení (PreviousCalls) by měl ale AVMS zahrnovat do výstupu vždy, lépe i aktuální nebo právě se blížící zastavení (MonitoredCall). Dokud spoj stojí v zastávce/stanici je dané zastavení hlášeno jako MonitoredCall. LinkDistance je vzdálenost k příští zastávce/stanici a Percentage je 0. Jakmile se vozidlo rozjede, Percentage začne narůstat a MonitoredCall přeskočí na příští zastavení. Přijede-li do něj, Percentage přeskočí ze 100 na 0 a LinkDistance se posune na další úsek.

56

8.5 Získávání informací o vozidlech veřejné dopravy- Služba obecných zpráv [GM]

Služba obecných zpráv slouží k přenosu informací mezi účastníky vztahů. Typická přenášená data jsou novinky nebo důležité zprávy v dopravě, provozní varování či doporučení generovaná převážně dispečinky. Služba obecných zpráv může dělit jednotlivé typy zpráv do kanálů a každému kanálu přiřadit jeho vlastní skupinu (havárie, zprávy, varování, zácpy, provozní doporučení apod.). Na výstupu tak může odběratel s jednotlivými skupinami zpráv zacházet odděleně. Na vstupním rozhraní CISReal, které je řešeno v normě, služba přijímá jakékoliv zprávy od všech přispěvatelů a ve vlastní režii je třídí významově, územně, podle skupin apod. Služba na vstupu přijímá bloky dat InfoMessage, přičemž InfoMessage je volně rozšiřitelná struktura. Tabulka 20 – Datová struktura služby GeneralMessageDelivery GeneralMessageDelivery InfoMessage

0:*

structure

Zprávy.

InfoMessageCancellation

0:*

structure

Zneplatnění dříve zaslané zprávy.

Note

0:1

string

Obecný text asociovaný s celou dodávkou.

Tabulka 21 – Datová struktura prvku InfoMessageCancellation InfoMessageCancellation Zneplatnění dříve vyslané zprávy

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

ItemIdentifierRef

1:1

string

Identifikátor upravované nebo rušené položky.

ValidUntilTime

0:1

dateTime

Platnost zprávy (ne platnost události). Není-li uvedena: zrušit okamžitě.

Tabulka 22 – Datová struktura prvku InfoMessage InfoMessage Obecná zpráva

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

ItemIdentifier

0:1

string

Identifikátor položky Producenta.

SituationCode

0:*

hodnota z číselníku

Kód situace svázané s událostí.

MessageChannelCode

0:*

hodnota z číselníku

Dělení do kanálů. Kanály např.: výluky, mimořádnosti, Berounsko apod. Dynamický veřejně známý číselník.

ValidUntilTime

0:1

dateTime

Platnost zprávy (ne platnost události).

Content

1:1

pro

eventuální

Struktura obsahující například tyto typy zpráv: - popisné textové informace o výluce; - dočasný stavební problém; string - informace o zabezpečení kulturní akce; - havárie vozu; - nepředvídané stání v koloně atp.

57

pozdější

odkazy

9

Distribuční rozhraní - Informace publikované službou systému CISReal

Služby distribuované službou systému CISReal jsou: Služba sledovaného bodu [SM], článek 9.1; Služba zastávkového jízdního řádu [ST], článek 9.2; Služba plánovaných přípojů [CT], článek 9.3; Služba sledování přípojů [CM], článek 9.4; Služba obecných zpráv [GM], článek 9.5.

9.1.

Služba sledovaného bodu [SM] Tabulka 23 – Datová struktura prvku StopMonitoringRequest

StopMonitoringRequest PreviewInterval

0:1

positiveDurationType

Interval, na který mají být vraceny zastavení na zastávce/zastávkách nebo stanicích; budou vraceny jen ty jízdy, které přijíždí nebo odjíždí ve vymezeném okně.

StartTime

0:1

dateTime

Počáteční čas pro PreviewInterval. Nebude-li uveden, použije se čas dotazu.

MonitoringRef

1:1

structure

Logický displej jako identifikátor sledovaného bodu – může být Zastávka/Stanice, Sloupek/Nástupiště nebo Časovací bod.

LineRef

0:*

structure

Filtr: identifikátor linky.

OperatorCode

0:*

hodnota z číselníku

Filtr: dopravce.

VehicleModeCode

0:*

hodnoty z číselníku

Filtr: druh dopravy.

DestinationRef

0:*

structure StopPointRef

Filtr: cílová stanice.

StopVisitTypeCode

0:1

hodnota z číselníku

Filtr: druh zastavení.

LanguageCode

0:1

hodnota z číselníku

Preferovaný jazyk výsledků.

MaximumStopVisits

0:1

positiveInteger

Maximální počet řádků vrácených v odpovědi.

MinimumStopVisitsPerLine

0:1

positiveInteger

Uplatní se při zadání MaximumStopVisits. Bude preferovat linky, které jedou zřídka a zahrne je do výsledku, i když by MaximumStopVisits bylo naplněno dříve frekventovanějšími linkami.

StopVisitDetailLevelCode

0:1

hodnota z číselníku

V jaké úrovni podrobnosti vracet jednotlivá zastavení spojů.

MaximumNumberOfCalls Previous Onwards

0:1 0:1 0:1

structure positiveInteger positiveInteger

Při vracení trasy spojů odpovídajících řádkům sledovaného bodu – kolik předchozích a následných zastávek/stanice zahrnovat do itinerářů těchto spojů.

Poznámka 1: Pojmem logický displej je pro účel tohoto dokumentu informační zařízení například se jedná o informační tabule v terminálu nebo na zastávkách a nástupištích

58

Tabulka 24 – Datová struktura prvku StopMonitoringPubDelivery StopMonitoringPubDelivery :::

1:1

xxxDelivery

MonitoredStopVisit

0:*

structure

Seznam zastavení (příjezdů a nebo odjezdů) jednotlivých spojů na logickém displeji.

StopLineNote

0:*

structure

Poznámky vztahující se k jednotlivým linkám.

MonitoredPointNote

0:*

string

Obecný text k celému logickému displeji. DetailLevel >=2.

V případě, že informace na poptávaném logickém displeji má být prázdná (nezařazena žádná MonitoredStopVisit), je vhodné vrátit příslušný status ještě v ErrorCode(=NoStopVisits). POZNÁMKA 1: Pojmem logický displej je pro účel tohoto dokumentu informační zařízení například se jedná o informační tabule v terminálu nebo na zastávkách a nástupištích. Tabulka 25 – Datová struktura prvku MonitoredStopVisit

Identická se strukturou na příjmové straně služby. MonitoredStopVisit Zastavení (příjezdy a/nebo odjezdy) jednotlivých vozů na logickém displeji

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

MonitoredVehicleJourney

1:1

structure

Nese informaci o sledovaném spoji.

StopVisitNote

0:*

string

Poznámky vztahující se k tomuto Zastavení. DetailLevel >=2.

Tabulka 26 – Datová struktura prvku StopLineNote

Identická se strukturou na příjmové straně služby. StopLineNote Textová poznámka k lince pro logické zobrazení

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

LineRef

1:1

structure

Identifikátor linky.

SituationCode

0:*

hodnota z číselníku

Situace asociované s položkou linky.

LineNote

0:*

String

Poznámky vztahující se k této lince.

59

Tabulka 27 – Datová struktura prvku MonitoredVehicleJourney

Identická se strukturou na příjmové straně služby. MonitoredVehicleJourney Sledovaný spoj

DatedVehicleJourneyRef

0:1

structure

Jednoznačná identifikace spoje vůči plánovanému CIS JŘ nebo v předchozí dodávce zaslanému ProductionTimetable.

:::

0:1

JourneyPatternInfoGroup

Informace o jízdním řádu spoje.

:::

0:1

VehicleJourneyInfoGroup

Informace umožňující identifikovat spoj textově. DetailLevel >=2.

:::

0:1

JourneyProgressInfoGroup

Popis průběhu jízdy spoje. DetailLevel >=2.

:::

0:1

OperationalInfoGroup

Služba a vozidlo jedoucí spoj. DetailLevel >=3.

PreviousCalls PreviousCall

0:1 1:*

structure

Předchozí zastavení vozidla na spoji. Je-li struktura vložena, pak musí obsahovat všechny PreviousCall před MonitoredCall. DetailLevel >=3.

MonitoredCall

1:1

structure

Aktuální zastavení spoje na zastávce/stanice /sledovaném bodu.

OnwardCalls OnwardCall

0:1 1:*

structure

Příští zastavení vozidla na spoji. DetailLevel >=3.

Tabulka 28 – Datová struktura prvku MonitoredCall

Identická se strukturou na příjmové straně služby. MonitoredCall Zastavení na sledované zastávce/stanici

StopPointRef

0:1

structure

Jednoznačný plánovaného JŘ

identifikátor

StopTC

0:1

positiveInteger

Tarifní číslo zastávky/stanici plánovaného JŘ

sloupku/nástupiště

na

trase

linky

Není třeba uvádět, pokud není v jízdním řádu opakování zastavení na téže zastávce/sloupku.

VehicleAtStop

0:1

boolean

Spoj stojí právě v zastávce/stanici. DetailLevel >=2.

VehicleLocationAtStop

0:1

structure Location

Poloha spoje stojícího v zastávce/stanici. DetailLevel >=2.

CallOptionCode

0:*

hodnota z číselníku

Doplňující atributy zastavení. DetailLevel >=2. V CIS JŘ odpovídá pevným kódům zastavení.

CallNote

0:*

string

Poznámky k zastavení. DetailLevel >=3. V CIS JŘ nemá vzor, v CISreal umožní zadat dispečerské texty.

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

60

Tabulka 28 – Datová struktura prvku MonitoredCall (dokončení) MonitoredCall Zastavení na sledované zastávce/stanici

ExpectedArrivalTime

0:1

dateTime

Zjištěný příjezd změřený AVMS.

ActualArrivalTime ArrivalStatusCode

Odhadovaný příjezd predikcí AVMS.

0:1

hodnota z číselníku CallStatusCode

Klasifikace očekávaného příjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...). DetailLevel >=2.

AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ExpectedDepartureTime

0:1

dateTime

Odhadovaný odjezd predikcí AVMS. Zjištěný odjezd změřený AVMS.

ActualDepartureTime DepartureStatus

0:1

hodnota z číselníku CallStatusCode

Klasifikace očekávaného odjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...). DetailLevel >=2.

ArrivalPlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při příjezdu DetailLevel >=2.

DeparturePlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při odjezdu. DetailLevel >=2.

Tabulka 29 – Datová struktura prvku PreviousCall

Identická se strukturou na příjmové straně služby. PreviousCall Zastavení na předchozí zastávce ve směru jízdy spoje

StopPointRef

0:1

structure

Jednoznačný plánovaného JŘ.

identifikátor

sloupku/nástupiště

StopTC

0:1

positiveInteger

Tarifní číslo zastávky či stanice dle plánovaného JŘ. Není třeba uvádět, pokud není v jízdním řádu opakování zastavení na téže zastávce/sloupku.

VehicleAtStop

0:1

boolean

Spoj stojí právě v zastávce/stanici.

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

ExpectedArrivalTime

0:1

dateTime

Očekávaný příjezd predikcí AVMS. Zjištěný příjezd změřený AVMS.

ActualArrivalTime AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ExpectedDepartureTime

0:1

dateTime

Očekávaný odjezd predikcí AVMS.

ActualDepartureTime

61

Zjištěný odjezd změřený AVMS.

Tabulka 30 – Datová struktura prvku OnwardCall

Identická se strukturou na příjmové straně služby. OnwardCall Zastavení na příští zastávce ve směru jízdy spoje

StopPointRef

0:1

structure

Jednoznačný identifikátor plánovaného JŘ.

StopTC

0:1

positiveInteger

Tarifní číslo zastávky či stanice dle plánovaného JŘ.

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

ExpectedArrivalTime

0:1

dateTime

Odhadovaný příjezd predikcí AVMS.

ArrivalStatus

0:1

hodnota z číselníku

Klasifikace očekávaného příjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...).

CallStatusCode

sloupku/

nástupiště

AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ExpectedDepartureTime

0:1

dateTime

Odhadovaný odjezd predikcí AVMS.

DepartureStatus

0:1

hodnota z číselníku

Klasifikace očekávaného odjezdu s ohledem na dohodnutá kritéria (načas, zpožděný, zrušený,...).

CallStatusCode

ArrivalPlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při příjezdu

DeparturePlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při příjezdu

9.2.

Služba zastávkového jízdního řádu [ST]

Aktualizace jízdního řádu na zastávkách veřejné dopravy odpovídá aktualizaci polohy vozidla. Modul aktualizace jízdního řádu na zastávkách bude obsahovat a pracovat s daty, které popisují následující tabulky. Tabulka 31 – Datová struktura prvku StopTimetableRequest StopTimetableRequest DepartureWindow StartTime EndTime

1:1

structure dateTime dateTime

Časové okno, v němž mají být vraceny výsledky. Pro aktuální provozní den a nanejvýš den zítřejší.

MonitoringRef

1:1

structure

Logické zobrazení jako identifikátor sledovaného bodu - může být Zastávka/stanice, Sloupek/nástupiště nebo Časovací bod.

LineRef

0:*

structure

Filtr: identifikátor linky.

OperatorCode

0:*

hodnota z číselníku

Filtr: dopravce.

VehicleModeCode

0:*

hodnoty z číselníku

Filtr: druh dopravy.

LanguageCode

0:1

hodnota z číselníku

Preferovaný jazyk výsledků.

IfModifiedSince

0:1

string

Kontrolní číslo. V odpovědi budou vyplněna užitná data pouze tehdy, pokud se liší od tohoto kontrolního čísla.

62

Tabulka 32 – Datová struktura služby StopTimetablePubDelivery StopTimetablePubDelivery :::

1:1

xxxDelivery

MonitoringRef

0:1

structure

Logické zobrazení jako identifikátor sledovaného bodu – může být Zastávka/stanice, Sloupek/nástupiště nebo Časovací bod. Vloží se tehdy, pokud jsou (filtrované) informace pro daný MonitoringRef prázdné (neexistuje žádná TimetabledStopVisit).

TimetabledStopVisit

0:*

structure

Seznam zastavení (příjezdů a/nebo odjezdů) jednotlivých spojů na logické zobrazení s uvažováním poslední verze provozních změn jízdního řádu.

CheckSum

1:1

string

Kontrolní číslo. Může být použito při dalším dotazu na stejná data ke zjištění změn. Viz výše IfModifiedSince.

Tabulka 33 – Datová struktura prvku TimetabledStopVisit TimetabledStopVisit Plánované zastavení (příjezd a/nebo odjezd) vozidla na logické zobrazení

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

MonitoringRef

1:1

structure

Logické zobrazení jako identifikátor sledovaného bodu - může být Sloupek/Nástupiště nebo Časovací bod.

TargetedVehicleJourney

0:1

structure

Viz níže.

Tabulka 34 – Datová struktura prvku TargetedVehicleJourney TargetedVehicleJourney Plánovaná trasa spoje po veškerých provozních změnách doplněná informací ze sledování vozů

DatedVehicleJourneyRef

0:1

structure

Odkaz na datovanou jízdu spoje unikátní uvnitř intervalu dat Producenta.

:::

0:1

JourneyPatternInfoGroup

Informace o jízdním řádu spoje.

:::

0:1

VehicleJourneyInfoGroup

Informace umožňující identifikovat spoj textově.

:::

0:1

OperationalInfoGroup

Služba a vozidlo jedoucího spoje.

TargetedCall

0:1

structure

Plánované zastavení spoje podle jízdního řádu.

63

Tabulka 35 – Datová struktura prvku TargetedCall TargetedCall Plánované zastavení spoje na sledovaném bodu podle jízdního řádu.

StopPointRef

0:1

structure

Jednoznačný identifikátor plánovaného JŘ.

sloupku/nástupiště

StopTC

0:1

positiveInteger

Tarifní číslo zastávky či stanici na trase linky plánovaného JŘ. Není třeba uvádět, pokud není v jízdním řádu opakování téže zastávky/sloupku.

CallOptionCode

0:*

hodnota z číselníku

Doplňující atributy zastavení. V CIS JŘ odpovídá pevným kódům zastavení.

CallNote

0:*

string

Poznámky k zastavení (dispečerské texty).

AimedArrivalTime

0:1

dateTime

Plánovaný příjezd.

AimedDepartureTime

0:1

dateTime

Plánovaný odjezd.

ArrivalPlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při příjezdu

DeparturePlatformName

0:1

string

Označení stanoviště (označníku) pro veřejnost či číslo nástupiště při odjezdu.

9.3.

Služba plánovaných přípojů [CT]

Služba plánovaných přípojů poskytuje informace o plánovaných (garantovaných) návaznostech neboli přípojích v přestupních bodech jejich tras. Plánované přípoje jsou zadávány v rámci CIS JŘ, zdrojem dat pro tuto službu je tedy statický CIS JŘ. Práce s přípoji zadávanými mechanismem publikace služby provozního jízdního řádu jako spoje navíc bude možná až získáním zkušeností z provozu, jejich generalizací a definováním v revizi normy ČSN 01 8245 Informační systém ve veřejné dopravě osob – Celostátní systém informací v reálném čase ( CISReal). Protože plánované přípoje jsou zadávány relativními časy („čeká nejvýše 10 min.“) vůči časům plánovaných odjezdů, zůstanou v platnosti v nezměněné podobě i ve chvíli, kdy služba provozního jízdního řádu časování spoje posune. Služba provozního jízdního řádu může narušit vazbu mezi zrušeným spojem a všemi jeho plánovanými přípoji, a to v obou směrech. Na tento fakt je třeba brát ohled – v čase posunutý spoj s původní definicí přípojů může navodit nestandardní situace. V železniční dopravě představuje čas plánovaného (garantovaného) přípoje v CIS JŘ nejmenší garantovanou dobu, po kterou přípojný vlak na zpožděný vlak vyčká. Skutečná, resp. maximální přípustná doba zpoždění čekajícího vlaku smí být za taxativně definovaných podmínek dopravce i vyšší, jestliže jsou vlaky v přestupním bodě vedeny po kolejích nebo k nástupištním, jejichž dostupnost je na straně dopravce, resp. provozovatele dráhy, zapotřebí zohlednit přičtením konstanty odpovídající době nutné na přestup. Službu využijí především tito uživatelé: 1) cestující v přestupním bodě (zastávka/železniční stanice, sloupek/nástupiště, logický displej), kde mohou být zobrazovány konkrétní dvojice spojů, včetně aktuálního průběhu plnění přípoje; 2) vozidla (přivážející i odvážející), která mohou obdržet statickou informaci o plánovaném přípoji, zobrazitelnou na palubním displeji řidiče nebo strojvedoucího a dále na vozidlových displejích pro cestující, za jízdy pak dynamicky doplňovanou informacemi ze služby sledování přípojů (CM);

64

3) dispečerské pracoviště dopravce, provozovatele dráhy nebo regionálního organizátora IDS, do jejichž působnosti spadá přestupní bod, protože zpoždění vzniklé v důsledku čekání na přípoj je nutné zohlednit při organizaci a řízení dopravy. 4) Tato služba je definována ryze na národní úrovni a NENÍ kompatibilní se SIRI, neboť SIRI pracuje s přípoji zcela jinak a nelze tento postup přijmout. Tabulka 36 – Datová struktura prvku ConnectionTimetableREquest ConnectionTimetableRequest ConnectionWindow StartTime EndTime

1:1

structure dateTime dateTime

Časové okno, v němž mají být vraceny výsledky. Rozmězí časového okna je stanoveno do 3 hodin. Vrací všechny přípoje, které padnou do okna ať už plánovaným příjezdem, odjezdem nebo stanoveným nejzazším čekáním.

MonitoringRef

0:1

structure

Logické zobrazení jako identifikátor sledovaného bodu – může být Zastávka/Stanice, Sloupek/Nástupiště nebo Časovací bod.

FeederJourneyRef

0:*

structure DatedVehicleJourneyRef

Filtr: přijíždějící.

DistributorJourneyRef

0:*

structure DatedVehicleJourneyRef

Filtr: čekající (odvážející).

OperatorCode

0:*

hodnota z číselníku

Filtr: dopravce.

VehicleModeCode

0:*

hodnoty z číselníku

Filtr: druh dopravy.

LanguageCode

0:1

hodnota z číselníku

Preferovaný jazyk výsledků.

IfModifiedSince

0:1

string

Kontrolní číslo. V odpovědi budou vyplněna užitná data pouze tehdy, pokud se liší od tohoto kontrolního čísla.

Tabulka 37 – Datová struktura služby ConnectionTimetableDelivery ConnectionTimetablePubDelivery :::

1:1

xxxDelivery

TimetabledConnection

0:*

structure

Plánované přípoje.

CheckSum

1:1

string

Kontrolní číslo. Může být použito při dalším dotazu na stejná data ke zjištění změn. Viz výše IfModifiedSince.

Tabulka 38 – Datová struktura prvku TimetabledConnection TimetabledConnection Plánovaný přípoj.

RecordedAtTime

1:1

dateTime

Okamžik vzniku události, v tomto případě poslední editace tohoto vztahu přípoje.

InterchangeRef

1:1

string

Unikátní identifikace návaznosti v kontextu dat Producenta (definiční záznam/řádek).

ConnectionFeeder

1:1

structure

Přijíždějící do návaznosti.

ConnectionDistributor

1:1

structure

Přípoj (odvážející z návaznosti).

CrossingTime

0:1

positiveInteger

Orientační doba pro přechod cestujících z místa příjezdu přijíždějícího vozidla do místa odjezdu vozidla (v minutách).

MaxWaitTime

1:1

positiveInteger

Maximální doba čekání po plánovaném odjezdu přípoje z návaznosti.

65

Tabulka 39 – Datová struktura prvku ConnectionFeeder ConnectionFeeder Přijíždějící navzující spoj.

StopPointRef

1:1

Structure

Jednoznačný identifikátor sloupku/nástupiště plánovaného JŘ

FeederJourneyRef

0:*

structure DatedVehicleJourneyRef

Přijíždějící spoj.

:::

0:1

JourneyPatternInfoGroup

Informace o jízdním řádu spoje.

:::

0:1

VehicleJourneyInfoGroup

Informace umožňující identifikovat spoj textově.

:::

0:1

OperationalInfoGroup

Služba a vozidlo jedoucí spoj.

AimedArrivalTime

1:1

dateTime

Pravidelný příjezd.

Tabulka 40 – Datová struktura prvku ConnectionDistributor ConnectionDistributor Přípoj (odvážející z návaznosti).

StopPointRef

1:1

structure

Jednoznačný identifikátor sloupku/nástupiště plánovaného JŘ

DistributorJourneyRef

0:*

structure DatedVehicleJourneyRef

Odvážející spoj.

:::

0:1

JourneyPatternInfoGroup

Informace o jízdním řádu spoje.

:::

0:1

VehicleJourneyInfoGroup

Informace umožňující identifikovat spoj textově.

:::

0:1

OperationalInfoGroup

Služba a vozidlo jedoucí spoj.

AimedDepartureTime

1:1

dateTime

Pravidelný odjezd.

9.4.

Služba sledování přípojů [CM]

Službu využijí především tito dva konzumenti: 1) sledovaný bod (sloupek/nástupiště, logický displej), na němž mohou být zobrazovány konkrétní dvojice spojů i včetně aktuálního průběhu plnění přípoje, 2) vozidla (přivážející i odvážející), která mohou obdržet statickou informaci o plánovaném přípoji zobrazitelnou na vozidlových displejích, za jízdy pak doplňovanou dynamicky informacemi ze služby sledování přípojů (CM). Tato služba je definována ryze na národní úrovni a NENÍ kompatibilní se SIRI, neboť SIRI pracuje s přípoji zcela jinak a nelze tento postup přijmout.

66

Tabulka 41 – Datová struktura prvku ConnectionMonitoringRequest ConnectionMonitoringRequest 1:1

structure dateTime dateTime

Časové okno, v němž mají být vraceny výsledky. Rozmezí časového okna je stanoveno do 3 hodin. Vrací všechny přípoje, které padnou do okna ať už plánovaným příjezdem, odjezdem nebo stanoveným nejzazším čekáním.

^ 1:1

structure

Filtr: Logické zobrazení jako identifikátor sledovaného bodu – může být Sloupek/Nástupiště nebo Časovací bod.

DatedVehicleJourneyRef

structure

Filtr: spoj jako přijíždějící i jako odvážející.

InterchangeRef

string

Filtr: Unikátní identifikace návazností v kontextu dat Producenta (definiční záznam/řádek) zjištěná při předchozím dotazu na ConnectionTimetable.

hodnota z číselníku

Preferovaný jazyk výsledků.

ConnectionWindow StartTime EndTime

MonitoringRef

LanguageCode

0:1

Tabulka 42 – Datová struktura služby ConnectionMonitoringPubDelivery ConnectionMonitoringPubDelivery :::

1:1

xxxDelivery

MonitoredFeederView

0:*

structure

Sledování přijíždějícího nebo přijíždějících přípoje/přípojů

MonitoredDistributorView

0:*

structure

Sledování odjíždějícího nebo odjíždějících přípojů

Tabulka 43 – Datová struktura služby MonitoredFeederView MonitoredFeederView Plánované přijíždějící přípoje.

ConnectionFeeder

1:1

structure

Přijíždějící do návaznosti (plánovaný stav).

MonitoredFeederConnectionArrival

0:*

structure

Příjezdy přijíždějícího k jednotlivým návaznostem.

Tabulka 44 – Datová struktura služby MonitoredDistributorView MonitoredDistributorView Plánované přípoje z pohledu odvážejícího (přípoje).

ConnectionDistributor

1:1

structure

Odjíždějící/čekající v návaznosti (plánovaný stav).

MonitoredDistributorConnectionDeparture

0:*

structure

Čekání odvážejícího na jednotlivých návaznostech.

67

Tabulka 45 – Datová struktura služby MonitoredFeederConnectionArrival MonitoredFeederConnectionArrival Příjezd přijíždějícího k návaznosti.

RecordedAtTime

1:1

dateTime

Okamžik vzniku události, v tomto případě poslední změněná proměnná ve sledování tohoto vztahu návaznosti.

InterchangeRef

1:1

string

Unikátní identifikace návaznosti v kontextu dat Producenta (definiční záznam/řádek).

MonitoredDistributor

1:1

structure

Přípoj (odvážející z návaznosti).

MonitoredFeeder

1:1

structure

Přijíždějící do návaznosti.

Tabulka 46 – Datová struktura služby MonitoredDistributorConnectionDeparture MonitoredDistributorConnectionDeparture Čekání odvážejícího (přípoje) v návaznosti.

RecordedAtTime

1:1

dateTime

Okamžik vzniku události, v tomto případě poslední změněná proměnná ve sledování tohoto vztahu návaznosti.

InterchangeRef

1:1

string

Unikátní identifikace návaznosti v kontextu dat Producenta (definiční záznam/řádek).

MonitoredDistributor

1:1

structure

Přípoj (odvážející z návaznosti).

MonitoredFeeder

1:1

structure

Přijíždějící do návaznosti.

Tabulka 47 – Datová struktura služby MonitoredFeeder MonitoredFeeder Přijíždějící spoj do návaznosti.

FeederConnectionStateCode

1:1

hodnota z čís.

Stav příjezdu k přípoji.

ExpectedArrivalTime

0:1

dateTime

Očekávaný příjezd k přípoji. Nevyplněno, pokud nelze určit.

Tabulka 48 – Datová struktura služby MonitoredDistributor MonitoredDistributor Odvážející spoj (přípoj) z návaznosti.

DistributorConnectionStateCode

1:1

hodnota z čís.

Stav čekání na přijíždějícího.

ExpectedArrivalTime

0:1

dateTime

Očekávaný příjezd do návaznosti. Nevyplněno, pokud nelze určit.

ExpectedDepartureTime

0:1

dateTime

Očekávaný odjezd z přípoje. Nevyplněno, pokud nelze určit.

68

9.5.

Služba obecných zpráv [GM]

Na výstupním rozhraní CISreal, které je řešeno v tomto dokumentu, služba publikuje dříve přijaté zprávy od jednotlivých účastníků ve vlastní režii roztříděné významově, územně, dle skupin apod. Žadatel žádá o všechna data nebo jen data určitých Kanálů. Do jednotlivých veřejně známých Kanálů rozčleňují svoje zprávy jejich Producenti. Tabulka 49 – Datová struktura prvku GeneralMessageRequest GeneralMessageRequest PreviewInterval

0:1

positiveDurationType

Dopředný interval, na který mají být vraceny zastavení na zastávce/zastávkách; budou vraceny jen ty jízdy, které přijíždí nebo odjíždí ve vymezeném časovém okně.

StartTime

0:1

dateTime

Počáteční čas pro PreviewInterval. Nebude-li uveden, použije se čas dotazu.

MessageChannelCode

0:*

hodnota z číselníku

Dělení do kanálů. Kanály např.: výluky, mimořádnosti, Berounsko apod. Dynamický veřejně známý číselník. Především podle situací ovlivňovaného objektu: linka, silnice, území...

filtrování LanguageCode

0:1

hodnota z číselníku

Preferovaný jazyk výsledků.

Způsob filtrování bude doplněn. Tak se bude zakládat na zkušenostech, jak budou seskupovány zprávy v rozsáhlém území celé republiky tak, aby poptávající mohli dostávat na svých kanálech jen relevantní zprávy. Tabulka 50 – Datová struktura služby GeneralMessagePubDelivery GeneralMessagePubDelivery :::

1:1

xxxDelivery

InfoMessage

0:*

structure

Zprávy.

Tabulka 51 – Datová struktura prvku InfoMessage

Identická se strukturou na příjmové straně služby. InfoMessage Obecná zpráva

RecordedAtTime

1:1

dateTime

Okamžik vzniku události.

ItemIdentifier

0:1

string

Identifikátor položky pro eventuální pozdější odkazy Producenta.

SituationCode

0:*

hodnota z číselníku

Kód situace svázané s událostí.

MessageChannelCode

0:*

hodnota z číselníku

Dělení do kanálů. Kanály např.: mimořádnosti, Berounsko apod. Dynamický veřejně známý číselník.

ValidUntilTime

0:1

dateTime

Platnost zprávy (ne platnost události).

Content

1:1

structure

Struktura obsahující například tyto typy zpráv: - popisné textové informace o výluce; - dočasný stavební problém; - informace o zabezpečení kulturní akce; - havárie vozu; - nepředvídané stání v koloně atp.

69

výluky,

10

Společné prvky datových struktur služeb

10.1.

Společné prvky a skupiny datových struktur Tabulka 52 – Datová struktura skupiny JourneyPatternInfoGroup

JourneyPatternInfoGroup Informace o jízdním řádu spoje/trase

VehicleModeCode

0:1

hodnota z číselníku

Druh dopravy (bus, vlak, tramvaj, metro, náhradní bus za tram...).

LineRef

0:1

string

Číselné či textové označení linky.

PublishedLineName

0:1

string

Název linky publikovaný pro veřejnost.

ExternalLineRef

0:1

string

Alternativní identifikace linky pro případné externí systémy.

LineNote

0:*

string

Textové poznámky k lince.

Tabulka 53 – Datová struktura skupiny ServiceInfoGroup ServiceInfoGroup Doplňující informace o službě

OperatorCode

0:1

hodnota z číselníku

Dopravce spoje zadaný identifikátorem IČO.

Tabulka 54 – Datová struktura skupiny VehicleJourneyInfoGroup VehicleJourneyInfoGroup Pomocné textové informace o spoji

:::

0:1

ServiceInfoGroup

Origin

0:1

string

Via

0:1

string

Destination

0:1

string

JourneyName

0:1

string

JourneyNote

0:*

string

Textové informace napomáhající identifikovat konkrétní spoje cestujícímu včetně dopravce apod. V ČR může být využito nanejvýš pro příležitostnou přepravu mimo CIS JŘ.

Tabulka 55 – Datová struktura skupiny OperationalInfoGroup OperationalInfoGroup Služba a vozidlo jedoucí spoj

:::

0:1

OperationalPlanGroup

Služba spoje.

VehicleRef

0:1

structure

Identifikace vozidla jedoucího spoj.

70

Tabulka 56 – Datová struktura skupiny OperationalPlanGroup OperationalPlanGroup Služba spoje

BlockRef

0:1

string

V našich podmínkách Služba. Vysvětleno jako: jízda vozidla od parkování k parkování.

CourseOfJourneyRef

0:1

string

Identifikace oběhu.

Tabulka 57 – Datová struktura skupiny DispatchSituationChangeGroup DispatchSituationChangeGroup Popisuje důvod dispečerské změny provozního JŘ

DispatchSituation

0:1

string

Důvod změny provozního JŘ dispečerským zásahem – text, např. „Havárie/výpadek tram 13 na ul. Veveří 15:32“

DispatchSituationReliabilityCode

0:1

hodnota z číselníku

Vyjádření věrohodnosti změny. Mělo by odrážet, zda byla zaslána do CISreal předtím, než vozy podle ní vyjely, zda vznikla automatickým zásahem dispečerského systému nebo ručně apod.

Tabulka 58 – Datová struktura prvku ExtraCall ExtraCall Vyčerpávající popis zastavení nad rámec jízdního řádu na místě neodpovídajícím číselníkům

Location

0:1

structure

Poloha zastavení.

CallName

0:1

string

Název zastavení (nebo zastávky/stanice, která není v číselnících CIS JŘ).

Tabulka 59 – Datová struktura prvku Location Location Obecná poloha (zastávky, vozidla apod.)

Lat

1:1

number

Zeměpisná šířka WGS84.

Lng

1:1

number

Zeměpisná délka WGS84.

Tabulka 60 – Datová struktura prvku RoutePath RoutePath Vedení trasy

Location

0:*

structure

Souřadnice trasy (lomená čára).

Description

0:1

string

Volitelný popis.

71

Tabulka 61 – Datová struktura prvku MonitoringRef MonitoringRef Logické zobrazení (identifikátor sledovaného bodu)

jedna z:

StopPointRef LogicalDisplay

^ 1:1

structure

Jednoznačný identifikátor sloupku/ nástupiště plánovaného JŘ.

structure

Logický displej shromažďuje informace o několika sloupcích/nástupištích, třeba i na rozdílných dopravních sítích doplněné například i textovými informacemi obecného charakteru (Olomouc hl. n. apod.).

Poznámka 1: Pojmem logický displej je pro účel tohoto dokumentu informační zařízení například se jedná o informační tabule v terminálu nebo na zastávkách a nástupištích. Tabulka 62 – Datová struktura prvku LogicalDisplay LogicalDisplay Logické zobrazení (identifikátor sledovaného bodu)

ItemIdentifier

0:1

string

Identifikátor zobrazení v kontextu dat Producenta. V následujících zásilkách již nemusí být opakovaně zasílány ostatní atributy zobrazení.

Name

0:1

string

Označení zobrazení zobrazovacích tabulí).

Description

0:1

string

Poznámky ke sledovaným linkám, odjezdy/příjezdy apod.

PhysicalDisplay

0:1

structure

Fyzická zobrazovací tabule.

StopPointRef

0:*

structure

Jednoznačný identifikátorsloupku/nástupiště plánovaného JŘ.

pro

veřejnost

(ve

vyhledávači

Tabulka 63 – Datová struktura prvku PhysicalDisplay PhysicalDisplay Fyzické zobrazení (existující zobrazovací tabule)

Location

1:1

structure

Souřadnice umístění zobrazovací tabule.

Bearing

0:1

positiveInteger

Směr pohledu zobrazovací tabule.

Description

0:1

string

Poznámky k umístění, provedení apod.

DisplayOwner

0:1

hodnota z číselníku

Informace o majiteli displeje, resp. o entitě, která umožňuje kontrolovat stavový řádek.

Image

0:1

base64 jpg

Foto umístění.

72

Hlavičková část odpovědi na dotaz služby

10.2.

Vkládá se na začátek odpovědi publikované službou CISReal. V případě naplnění chyby většinou již nenásledují data odpovědi. Tabulka 64 – Datová struktura hlavičky xxxDelivery 0:1

structure

Chyba při vykonání požadavku.

Code

1:1

positiveInteger

Kód chyby.

Description

0:1

string

Textový popis chyby.

ErrorCondition

Kontext výměny dat

10.3.

10.3.1 Kontext dopravy Tabulka 65 – Datová struktura prvku TransportContext TransportContext Kontext dopravy

State

0:1

hodnota z číselníku

CZ

TransportCategoryCode

1:1

hodnota z číselníku

Kategorie dopravy.

TransportSystemCode

0:1

hodnota z číselníku

Město.

10.3.2 Zastávka Tabulka 66 – Datová struktura prvku StopPointRef StopPointRef Sloupek/Nástupiště

TransportContext

1:1

structure

Kontext dopravy.

StopCode

1:1

hodnota z číselníku

Identifikátor zastávky/stanice podle CIS JŘ.

StopPointRef

0:1

string

Jednoznačný identifikátor sloupku či nástupiště plánovaného JŘ

73

10.3.3 Vozidlo 10.3.3.1

Datovaný spoj Tabulka 67 – Datová struktura prvku DatedVehicleJourneyRef

DatedVehicleJourneyRef Datovaný spoj (projekce spoje do daného dne)

1:1

structure

Kontext dopravy.

TrainNumber

1:1

string

Číslo vlaku.

TrainCategoryCode

1:1

hodnota z číselníku

Kategorie vlaku.

TrainName

0:1

string

Název vlaku či jiné rozlišení.

LineNumber

1:1

string

Linka VLD.

JourneyNumber

1:1

positiveInteger

Spoj VLD.

LineName

1:1

string

Městská linka.

DepartureDateTime

0:1

dateTime

Datum a čas odjezdu z první zastávky spoje.

DepartureStopCode

0:1

hodnota z číselníku StopCode

První zastávka spoje.

boat

LineNumber

1:1

string

Linka.

JourneyNumber

1:1

positiveInteger

Spoj.

TransportContext jedna ze tří možností: train

bus

city

Tabulka 68 – Datová struktura prvku LineRef LineRef Linka (použito především při filtraci požadavku)

TransportContext

1:1

structure

Kontext dopravy.

jedna ze tří možností: train

TrainNumber

1:1

string

Číslo vlaku.

bus

LineNumber

1:1

string

Linka VLD.

city

LineName

1:1

string

Městská linka.

74

Číselníky

11

Tato kapitola uvádí číselníky pro datové struktury uvedené v kapitolách 8, 9 a 10. Tabulka 69 – Číselník prvku JourneyOptionCode

24

JourneyOptionCode positiveInteger

Pevné kódy spoje na zastávce

1

X

jede v pracovních dnech

2

+

jede v neděli a ve státem uznané svátky

3

1

jede v pondělí

4

2

jede v úterý

5

3

jede ve středu

6

4

jede ve čtvrtek

7

5

jede v pátek

8

6

jede v sobotu

9

7

jede v neděli

10

R

jízdenku s místenkou je možné zakoupit

11

#

jízdenku s místenkou je nutné zakoupit

12

@

spoj s bezbariérově přístupným vozidlem

13

%

spoj s možností občerstvení

14

I

spoj je v systému integrované dopravy

15

{

spoj s částečně bezbariérově přístupným vozidlem, nutná dopomoc průvodce

16

[

spoj přepravuje cestovní zavazadla

17

O

spoj přepravuje jízdní kola

18

s

spoj se samoobslužným způsobem odbavování cestujících

19

posilový spoj

20

mimořádný dispečerský spoj

21

spoj s wifi internetem

22

noc před pracovním dnem

23

noc před nepracovním dnem « dle potřeby dále doplnit »

24

Použité symboly vychází z Metodického pokynu č. 4 k organizaci celostátního informačního systému o jízdních řádech

75

Tabulka 70 – Číselník prvku CallOptionCode

25

CallOptionCode positiveInteger

Pevné kódy zastavení spoje na zastávce

1

(

spoj zastavuje jen pro vystupování

2

)

spoj zastavuje jen pro nastupování

3

x

zastávka je jen na znamení nebo požádání

4

§

není povolen nástup cestujících za účelem přepravy do ostatních shodně označených zastávek spoje

5

|

spoj příslušnou zastávkou projíždí

6

<

spoj jede po jiné trase 26

Tabulka 71 – Číselník prvku StopOptionCode StopOptionCode positiveInteger

Pevné kódy zastávky

1

@

zastávka je bezbariérově přístupná

2

%

občerstvení/restaurace v objektu zastávky

3

W

veřejně přístupné WC v objektu zastávky

4

w

veřejně přístupné WC s bezbariérovým přístupem v objektu zastávky

5

~

možnost přestupu na městskou hromadnou dopravu

6

}

zastávka je upravená pro osoby s těžkým zrakovým postižením

7

v

přestup na vlak

8

x

zastávka je jen na znamení nebo požádání

9

(

jen pro vystupování

10

)

jen pro nastupování

11

$

hraniční přechod s pasovým a celním odbavením; není zastávkou pro nástup a výstup cestujících Tabulka 72 – Číselník prvku VehicleModeCode

VehicleModeCode positiveInteger

1 12 13 17 18

autobus náhradní autobusová doprava za tramvaj náhradní autobusová doprava za trolejbus náhradní autobusová doprava za vlak náhradní auatobusová doprava za metro

2

Tramvaj

3

Trolejbus

4 41

loď přívoz

6

Lanovka

Druh dopravního prostředku

25

Použité symboly vychází z Metodického pokynu č. 4 k organizaci celostátního informačního systému o jízdních řádech

26

Použité symboly vychází z Metodického pokynu č. 4 k organizaci celostátního informačního systému o jízdních řádech

76

VehicleModeCode positiveInteger

7

Vlak

8

Metro

Druh dopravního prostředku

Tabulka 73 – Číselník prvku TransportCategoryCode TransportCategoryCode positiveInteger

Kategorie dopravy

1

drážní doprava

2

veřejná linková doprava « dle potřeby dále doplnit » Tabulka 74 – Číselník prvku TransportSystemCode

TransportSystemCode positiveInteger

1

Praha

2

Brno

3

Ostrava

4

České Budějovice

5

Olomouc

7

Plzeň

10

Jindřichův Hradec

11

Pelhřimov

12

Písek

13

Strakonice

14

Tábor

15

Chrudim

16

Trutnov

17

Český Těšín

18

Třinec

19

Blansko

20

Hodonín

21

Dvůr Králové nad Labem

22

Karviná

23

Havířov

24

Orlová

25

Frýdek-Místek

26

Přerov

77

Kód dopravního systému

TransportSystemCode positiveInteger

Kód dopravního systému

27

Prostějov

28

Žďár nad Sázavou

29

Hradec Králové Tabulka 74 – Číselník prvku TransportSystemCode (pokračování)

TransportSystemCode positiveInteger

30

Příbram

31

Břeclav

32

Kutná Hora

33

Mladá Boleslav

34

Znojmo

35

Kladno

36

Karlovy Vary

37

Liberec

38

Děčín

39

Chomutov

40

Teplice

41

Jihlava

42

Bruntál

43

Krnov

44

Ústí nad Labem

45

Beroun

46

Polička

47

Vyškov

48

Šumperk

49

Zábřeh

50

Nový Jičín

51

Studénka

53

Klatovy

54

Domažlice

55

Sokolov

56

Aš

57

Cheb

78

Kód dopravního systému

TransportSystemCode positiveInteger

Kód dopravního systému

58

Nymburk

59

Stříbro

60

Tachov

61

Jablonec nad Nisou

62

Vsetín

Tabulka 74 – Číselník prvku TransportSystemCode (pokračování) TransportSystemCode positiveInteger

63

Valašské Meziříčí

64

Čáslav

65

Litomyšl

66

Mělník

67

Pardubice

68

Zlín

69

Jáchymov

70

Kolín

71

Velké Meziříčí

72

Kroměříž

73

Česká Lípa

74

Havlíčkův Brod

75

Benešov

76

Vlašim

77

Kyjov

78

Mikulov

79

Hranice

80

Přeštice

81

Most

82

Turnov

83

Přelouč

84

Rokycany

85

Opava

86

Dačice

87

Litoměřice

79

Kód dopravního systému

TransportSystemCode positiveInteger

Kód dopravního systému

88

Louny

89

Lovosice

91

Ostrov

92

Mariánské Lázně

93

Roudnice n. L.

94

Třebíč

95

Kralupy nad Vltavou

Tabulka 74 – Číselník prvku TransportSystemCode (pokračování) TransportSystemCode positiveInteger

96

Rychnov nad Kněžnou

97

Uherské Hradiště

98

Slaný

99

Bystřice n. Pern.

201

Žatec

202

Bílina

203

Žamberk

204

Neratovice

206

Náchod

207

Brandýs n. L.- St. Bol.

209

Duchcov

210

Adamov

211

Kadaň

212

Klášterec nad Ohří

213

Vrchlabí

214

Špindlerův Mlýn

215

Ústí nad Orlicí

216

Štětí « dle potřeby doplnit »

250

Lodní přístavy « dle potřeby doplnit »

300

PID

301

IDS JMK

80

Kód dopravního systému

TransportSystemCode positiveInteger

302

ODIS

303

IDSOK

304

BID

305

JIKORD

306

KIDS KK

307

KORID LK

308

OREDO

Kód dopravního systému

« dle potřeby doplnit »

Tabulka 74 – Číselník prvku TransportSystemCode (dokončení) TransportSystemCode positiveInteger

311

ORID

312

POVED

Kód dopravního systému

« dle potřeby doplnit » Tabulka 75 – Číselník prvku CallStatusCode CallStatusCode positiveInteger

Stav spoje vzhledem k danému zastavení

1

spoj jede včas

2

spoj má zpoždění

3

spoj jede v předstihu

4

spoj byl zrušen

5

o spoji není dostupná informace

6

spoj jede odklonem Tabulka 76 – Číselník prvku TrainCategoryCode

TrainCategoryCode string

Příklady kategorie vlaku

Os

osobní vlak

R

Rychlík

Ex

Expres

IC

InterCity

EC

EuroCity « dle potřeby dále doplnit »

81

Tabulka 77 – Číselník prvku StopCode StopCode positiveInteger

Celostátní registr zastávek

Tabulka 78 – Číselník prvku OperatorCode OperatorCode positiveInteger (klíčem je IČO dopravce)

xxxxxxxx

82

« dle databáze CIS JŘ »

Dopravci

Tabulka 79 – Číselník prvku VehicleFeatureRef VehicleFeatureRef positiveInteger

Vlastnosti vozu

1

Vůz uzpůsoben pro lidi na vozíku

2

Nízkopodlažní vůz

3

Vůz s asistenční službou

4

Vůz s informačním systémem pro nevidomé

5

Vůz vybaven displeji pro zrakově postižené

6

Audio systém pro sluchově postižené

7

Vůz 1. Třídy

8

Restaurační vůz

9

Lůžkový vůz

10

Vůz s možností přepravy jízdních kol

11

Vozidlo vybaveno přebalovacím pultem

12

Audio vyhlašování zastávek

13

Přístup k internetu na palubě vozu

14

Informační kiosek na palubě vozu

15

Automat na jízdenky na palubě vozu « dle potřeby doplnit » Tabulka 80 – Číselník prvku SituationCode

SituationCode positiveInteger

1

nehoda dopravního prostředku

2

nehoda jiných účastníků silničního provozu

3

nefunkčnost dopravní sítě (spadlá trolej, spadlý strom, voda v silnici)

4

stavební porucha (uzavírka silnice)

5

dlouhodobá výluka

6

krátkodobá výluka

7

zácpa, kolona

8

závada na vozidle

9

porucha – spravím

10

konec opravy poruchy « dle potřeby doplnit »

83

Dopravní situace

Tabulka 81 – Číselník prvku ReliabilityCode ReliabilityCode positiveInteger

1

Důvěryhodná

2

Nedůvěryhodná

Důvěryhodnost informace

Tabulka 82 – Číselník prvku MessageChannelCode MessageChannelCode positiveInteger

1

Výluka

2

Mimořádnost

Kanál odběru dopravních informací (kategorizace)

Tabulka 83 – Číselník prvku SeverityCode SeverityCode positiveInteger

1

Kritická

2

Závažná

3

Informativní

Závažnost informace

« dle potřeby doplnit » Tabulka 84 – Číselník prvku FeederConnectionStateCode FeederConnectionStateCode integerMask

Status spoje, který příjíždí ke sledovanému přípoji

1

Přijíždějící spoj, na němž se sleduje návaznost spoje. Status návazného příjíždějícího spoje je, že nevyjel z předchozí zastávky/stanice dle plánovaného JŘ

2

Přijíždějící spoj, na němž se sleduje návaznost spoje. Status návazného přijíždějícího spoje je,že vyjel z předchozí zastávky/stanice, ale o zpoždění spoje nejsou informace (vozidlo nevysílá žádné zprávy)

4

Přijíždějící spoj, na němž se sleduje návaznost spoje. Status návazného přijíždějícího spoje je,že nevyjel z předchozí zastávky/stanice (vozidlo vysílá zprávy a nemá změřeno zpoždění na odjezdu)

8

Přijíždějící spoj, na němž se sleduje návaznost spoje. Status návazného přijíždějícího spoje je, že vyjel z předchozí zastávky/stanice (vozidlo vysílá zprávy ale ke sledované návaznosti je ještě daleko je nepředmětné vyhodnocovat zpoždění)

16

Přijíždějící spoj, na němž se sleduje návaznost spoje, status návazného přijíždějícího spoje je,že vyjel z předchozí zastávky/stanice (vozidlo vysílá zprávu, že jede dle JŘ)

32

Přijíždějící spoj, na němž se sleduje návaznost spoje (vozidlo vysílá zprávu o zpoždění ale návazný spoj bude pravděpodobně stihnut). Status návazného přijíždějícího spoje je,že vyjel z předchozí zastávky/stanice

64

Přijíždějící spoj, na němž se sleduje návaznost spoje (vozidlo vysílá zprávu o zpoždění a vyhodnocuje že nestihne příjezd k návaznému spoji). Status návazného přijíždějícího spoje je,že vyjel z předchozí zastávky/stanice

128

Přijíždějící spoj, na němž se sleduje návaznost spoje ( vozidlo vysílá zprávu, že již přijelo k přípojnému spoji a návaznost byla uskutečněna

256

Přijíždějící spoj, na němž se sleduje návaznost spoje ( vozidlo vysílá zprávu, že již odjel ze zastávky/stanice přijíždějící již odjel z návaznosti

84

Tabulka 85 – Číselník prvku DistributorConnectionStateCode DistributorConnectionStateCode integerMask

Stav příjezdu přípoje ke sledované návaznosti a čekání přípoje v ní

1

je ještě brzy (>3 min.) před plánovaným odjezdem přípoje z návaznosti

2

o zpoždění přípoje nejsou žádné informace (nevysílá)

4

přípoj nestíhá příjezd k plánované návaznosti ke svému plánovanému příjezdu

8

přípoj nestíhá příjezd k plánované návaznosti ke svému plánovanému odjezdu

16

přípoj nestíhá příjezd k plánované návaznosti ani k okamžiku svého nejzazšího čekání

32

přípoj již přijel do návaznosti

64

přípoj již odjel z návaznosti

128

přípoj nevyčká příjezdu přijíždějícího do návaznosti

Tabulka 86 – Číselník prvku DisplayOwner DisplayOwner positiveInteger

1

« dle potřeby doplnit »

85

Informace o majiteli displeje, resp. o entitě, která umožňuje kontrolovat stavový řádek

12

Aplikační logika

Celkovou koncepci fungování budoucího systému CISReal podle základních uživatelů systému ukazuje obrázek10.

Obrázek 10 – Základní model případu použití systému CISReal (včetně nadstavbových funkcionalit)

86

12.1.

UML model případu použití systému CISReal

Základní model případu použití systému CISReal (dle UML) ukazuje obrázek 11. Podrobný rozpis případů užití bude uveden v rámci datového modelu.

Obrázek 11 – Základní UML model případu použití systému CISReal (včetně nadstavbových funkcionalit)

87

13

Koncepční model systému – základní architektura

Základní koncepční model vymezuje budoucí možnou architekturu fungování systému CISReal. Tento model ukazuje obrázek 12

88

Obrázek 12 – Základní architektura systému CISReal (včetně nadstavbových funkcionalit)

89

13.1

Webová prezentace dat

Webová prezentace dat bude umožňovat vyhledávat spojení požadovaných spojů, linek na webovém prostředí, popř. možnost vyhledávat konkrétní zastávky se zobrazováním přijíždějících linek, spojů. V systému CISReal bude možné zobrazovat dané výsledky hledání v reálném čase, tedy s možným zpožděním konkrétních vozidel, popř. se zbývajícím časem odjezdu vozidla z konkrétní zastávky. Součástí prezentace dat na webovém prostředí bude funkcionalita plánovače tras. Dále bude obsahovat funkcionalitu alternativních návrhů spojení v závislosti na zpoždění konkrétních linek/spojů. 13.2

Mobilní aplikace

Mobilní aplikace bude umožňovat výstupy na mobilních zařízeních (především na chytrých mobilních telefonech), nebo na takových zařízeních, která mohou vyhledávat spoje v průběhu jízdy a dotazovat se na aktuální dojezdový čas konkrétních vozidel na konkrétní zastávce. V obecné rovině mluvíme o obdobné technologii jako v případě webové prezentace dat, s tím rozdílem, že vyhledávače v mobilních telefonech by měly umožnit rychlejší vyhledávání s jednoduchou navigací. 13.3

Mapové zobrazení

Součástí webové a mobilní prezentace dat bude možnost zobrazení plánovaných a aktualizovaných dopravních spojení v mapě. Mapové zobrazení bude také umožňovat zobrazení dodatečných informací o dopravních spojeních (např. info o vozidlech, zpoždění a jeho důvodech) a sledovat aktuální polohu dopravních prostředků. 14

Logický datový model

Na obrázku 13. je zpracován základní datový model systému CISReal, který zobrazuje toky dat.

90

Obrázek 13 – Základní datový model systému

91

13

Softwarová platforma

Importní webová služba zajišťuje sběr datových dávek poskytovatelů informací dopravního charakteru, strojové rozhraní služby je vystaveno na URL http://crimport.cisr.cz/CRImport.svc Rozhraní obsahuje funkce CISRealImportWS

Exportní webová služba zajišťuje propagaci pohledů na sjednocené informace dopravního charakteru konzumentům, strojové rozhraní služby je vystaveno na URL http://crexport.cisr.cz/CRExport.svc Rozhraní obsahuje funkce CISRealExportWS

Softwarová aplikace – klientská služba pro grafické zobrazování systému CISReal je dostupná na URL

http:/vm.cisreal.cz.

III

Srovnání „novosti“ postupů

Novost postupů je zajištěna tím, že předkládaná metodika navrhuje softwarovou platformu pro množnost sdílení informací v reálném čase přes centralizovaný prvek CISReal. Postupy se zakládají na výsledcích domácího výzkumu, který byl veden Centrem dopravního výzkumu, v.v.i. ve spolupráci s dotčenými organizacemi, organizátory dopravy a provozovateli silniční dopravy Originalita novosti výsledků lze dokladovat i na současné praxi zavádění informačních systémů pro veřejnou dopravu v ČR, které nejsou optimalizované dle předkládané metodiky. Pracovníkům v praxi zejména bude poskytovat údaje a bližší specifika o možnostech využití informačních systémů a nasazení komponent.

IV

Popis uplatnění certifikované metodiky

V České republice existuje jen velmi málo souhrnných informací o způsobech zavádění informačních systémů ve veřejné dopravě. Metodika je připravena v souladu s požadavky směrnice 2010/40/EU o rámci pro zavedení inteligentních dopravních systémů v oblasti silniční dopravy a pro rozhraní s jinými druhy dopravy. Ta uvádí že, použití informačních a komunikačních technologií v odvětví silniční dopravy a jeho rozhraních s jinými druhy dopravy významně přispěje ke snížení vlivu silniční dopravy na životní prostředí a zlepšení účinnosti, včetně energetické účinnosti, bezpečnosti silničního provozu a jeho ochrany před vnějšími hrozbami, včetně přepravy nebezpečných věcí, a veřejné bezpečnosti a mobility osob a věcí a zároveň zajistí fungování vnitřního trhu a vyšší úroveň konkurenceschopnosti a zaměstnanosti. Pro zajištění koordinovaného a účinného zavádění ITS v rámci Unie jako celku je třeba zavést specifikace, včetně případných norem, jež určí další podrobná ustanovení a postupy. Tato metodika popisuje vztahy, které umožní zjednodušit způsob přenosů dat Předpokládaní uživatelé systému CISReal z pohledu externích aktérů mohou být: CIS, resp. plánovače dopravy (např. IDOS); cestující; dispečerské systémy veřejné dopravy; zastávkové systémy; strojvedoucí/řidič; vlakový doprovod; automatizované systémy; informační zařízení na vozidlech; národní krizový dispečer; administrátor systému.

V

Ekonomické aspekty

Ekonomický přínos pro uživatele metodiky je přímo závislý na způsobu realizace zavedení nových systémů nebo změny ve vlastních systémech. Normalizovaný ISR definuje formát a způsob vzájemné komunikace mezi servery dvou a více samostatných ISR a pracuje s daty o pohybu vozidel v reálném čase. Jasně specifikované rozhraní ISR hraje primární úlohu při zkvalitňování ekonomických a technických aspektů fungování všech systémů VD. Použitím normalizovaného rozhraní ISR je možné instalovat a průběžně „dovybavovat“ ISR pomocí modulárního pojetí systému. Rozhraní rovněž umožňují průběžné a automatické zkoušení funkčnosti jednotlivých modulů systémů. Další nespornou výhodou normalizovaného pojetí ISR je, že i při nepřetržitém fungování systému mohou být jednotlivé moduly modernizovány, popř. měněny a to za minimálních dodatečných investic a významného narušení fungování systému.

93

VI

Seznam použité literatury

[1]

Průběžná zpráva Projektu „Jednotný systém dat ve veřejné dopravě s ohledem na aplikaci standardního formátu s možností propojení stávajících systému do jednotné SW platformy-Část Analýza JSDV“ verze 3.1.2012

[2]

CEN TS 15531-1 Public transport – Service interface for real-time information relating to public transport operations – Part 1: Context and Framework (Veřejná přeprava osob – Pracovní rozhraní pro informace v reálném čase vztahující se k provozu veřejné přepravy osob – Část 1: Souvislosti a struktura)

[3] ISO 7637-2 Road vehicles – Electrical disturbances from conduction and coupling – Part 2: Electrical transient conduction along supply lines only (Silniční vozidla – Elektrické rušení z vedení kabeláže a na spojích – Část 2: Konduktivní rušení z vodičů)

[4] ISO 16750-2 Road vehicles – Environmental conditions and testing for electrical and electronic equipment – Part 2: Electrical loads (Silniční vozidla – Podmínky a zkoušení vlivu prostředí na elektrická a elektronická zařízení – Část 2: Elektrické zatížení)

[5] ISO 16750-3 Road vehicles – Environmental conditions and testing for electrical and electronic equipment – Part 3: Mechanical loads (Silniční vozidla – Podmínky a zkoušení vlivu prostředí na elektrická a elektronická zařízení – Část 3: Mechanické zatížení)

[6] ISO 16750-4 Road vehicles – Environmental conditions and testing for electrical and electronic equipment – Part 4: Climatic loads (Silniční vozidla – Podmínky a zkoušení vlivu prostředí na elektrická a elektronická zařízení – Část 4: Klimatické zatížení)

[7] ISO 16750-5 Road vehicles – Environmental conditions and testing for electrical and electronic equipment – Part 5: Chemical loads (Silniční vozidla – Podmínky a zkoušení vlivu prostředí na elektrická a elektronická zařízení – Část 5: Chemické zkoušky)

[8] IEC 60068-2 Environmental testing – Part 2: tests (Zkoušky vlivu prostředí – Část 2: Zkoušky) [9] ISO 20653 Road vehicles – Degrees of protection (IP-Code) – Protection of electrical equipment against foreign objects, water and access (Silniční vozidla – Stupně ochrany krytí (IP kód) – Ochrana elektrického zařízení proti cizím částicím, vodě a přístupu)

[10] ISO 10605 Road vehicles – Test methods for electrical disturbances from electrostatic discharge (Silniční vozidla – Zkušební metody pro elektrické rušení z elektrostatických výbojů)

[11] CEN TS 15531-4 Public transport – Service interface for real-time information relating to public transport operations – Part 4: Functional service interfaces: Facility Monitoring (Veřejná přeprava osob – Pracovní rozhraní pro informace v reálném čase vztahující se k provozu veřejné přepravy osob – Část 4: Provozní služební rozhraní: Monitorování zařízení)

[12] CEN TS 15531-5 Public transport – Service interface for real-time information relating to public transport operations – Part 5: Functional service interfaces - Situation Exchange (Veřejná přeprava osob – Pracovní rozhraní pro informace v reálném čase vztahující se k provozu veřejné přepravy osob – Část 5: Provozní služební rozhraní – Výměna dat situací)

[13] CEN/TS 15504 Public transport. Road vehicles. Visible variable passenger information devices inside the vehicle (Veřejná přeprava osob – Silniční vozidla – Zařízení ve vozidle zobrazující proměnné informace pro cestující)

[14] CEN TR 16427 Intelligent transport systems – Public transport – Traveller information for visually impaired people (TI-VIP) (Inteligentní dopravní systémy – Veřejná přeprava osob –

94

Informace pro zrakově postižené cestující)

[15] EN 12896 Dopravní telematika – Veřejná přeprava osob – Referenční datový model [16] Rtig-Xml – za podpory britského ministerstva dopravy vznikl protokol XML, který umožňuje výměnu informací v reálném čase o autobusech mezi servery. Nyní je RtigXml součástí evropské technické specifikace SIRI. [17] VDV 453 a 454 – Standard vyvinul Svaz německých dopravních podniků (Verband Deutscher Verkehrsunternehmen, VDV) a nyní je součástí evropské technické specifikace SIRI.

95