Metodika _SW platforma pro sdílení a implementaci dat ve

Transkript

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:
<InfoMessage>
<RecordedAtTime>2012-08-11T13:20:11+001</RecordedAtTime>
<ItemIdentifier>MVCRBER21234</ItemIdentifier>
<SituationCode>2</SituationCode>
<ValidUntilTime>2012-08-11T13:30:11+001</ValidUntilTime>
<Content>Havárie na silnici 324, vyteklý olej, oba směry
neprůjezdné</Content>
</InfoMessage>
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:
<DatedTimetableVersionFrame>
<RecordedAtTime>2012-08-11T13:20:11+001</RecordedAtTime>
<VehicleModeCode>1</VehicleModeCode>
<LineRef>
<TransportContext>
<TransportCategoryCode>2</TransportCategoryCode>
</TransportContext>
<LineNumber>280341</LineNumber>
</LineRef>
<PublishedLineName>Praha-Beroun-Zdice</PublishedLineName>
<LineNote>O jarních prázdninách v Městci zastavuje jen na znamení.</LineNote>
<DatedVehicleJourney>
<DatedVehicleJourneyRef>
32
<TransportContext>
...
</TransportContext>
</DatedVehicleJourneyRef>
</DatedVehicleJourney>
</DatedTimetableVersionFrame>
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
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
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:*
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
čí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
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
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:*
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
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
ExpectedArrivalTime
0:1
dateTime
Odhadovaný příjezd ze skutečné jízdy vozidla
a/nebo predikce AVMS.
ArrivalStatusCode
0:1
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
Klasifikace očekávaného odjezdu s ohledem na
CallStatusCode
ArrivalPlatformName
0:1
string
0:1
string
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
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
LineRef
1:1
structure
Identifikátor linky.
SituationCode
0:*
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
Sledovaný spoj
0:1
structure
:::
0:1
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:*
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Ř.
StopTC
0:1
positiveInteger
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:*
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
ExpectedArrivalTime
0:1
dateTime
Odhadovaný příjezd predikcí AVMS.
Zjištěný příjezd změřený AVMS.
ActualArrivalTime
ArrivalStatusCode
0:1
CallStatusCode
AimedDepartureTime
0:1
dateTime
Plánovaný odjezd.
0:1
dateTime
Odhadovaný odjezd predikcí AVMS.
Zjištěný odjezd změřený AVMS.
ActualDepartureTime
DepartureStatus
0:1
CallStatusCode
ArrivalPlatformName
0:1
string
0:1
string
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Ř.
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
ExpectedArrivalTime
0:1
dateTime
ActualArrivalTime
AimedDepartureTime
0:1
dateTime
Plánovaný odjezd.
0:1
dateTime
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
ExpectedArrivalTime
0:1
dateTime
ArrivalStatus
0:1
CallStatusCode
AimedDepartureTime
0:1
dateTime
Plánovaný odjezd.
0:1
dateTime
DepartureStatus
0:1
CallStatusCode
ArrivalPlatformName
0:1
string
0:1
string
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
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
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.
1:1
structure
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
Tabulka 21 – Datová struktura prvku InfoMessageCancellation
InfoMessageCancellation
Zneplatnění dříve vyslané zprávy
RecordedAtTime
1:1
dateTime
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
ItemIdentifier
0:1
string
Identifikátor položky
Producenta.
SituationCode
0:*
hodnota z
číselníku
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
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:*
Filtr: dopravce.
VehicleModeCode
0:*
hodnoty z číselníku
Filtr: druh dopravy.
DestinationRef
0:*
structure StopPointRef
Filtr: cílová stanice.
StopVisitTypeCode
0:1
Filtr: druh zastavení.
LanguageCode
0:1
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
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
1:1
structure
StopVisitNote
0:*
string
Poznámky vztahující se k tomuto Zastavení.
DetailLevel >=2.
Tabulka 26 – Datová struktura prvku StopLineNote
StopLineNote
Textová poznámka k lince pro logické zobrazení
RecordedAtTime
1:1
dateTime
LineRef
1:1
structure
Identifikátor linky.
SituationCode
0:*
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
Sledovaný spoj
0:1
structure
:::
0:1
:::
0:1
DetailLevel >=2.
:::
0:1
JourneyProgressInfoGroup
Popis průběhu jízdy spoje. DetailLevel >=2.
:::
0:1
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
MonitoredCall
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Ř
na
trase
linky
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:*
Doplňující atributy zastavení. DetailLevel >=2.
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
60
Tabulka 28 – Datová struktura prvku MonitoredCall (dokončení)
MonitoredCall
ExpectedArrivalTime
0:1
dateTime
ActualArrivalTime
ArrivalStatusCode
0:1
CallStatusCode
DetailLevel >=2.
AimedDepartureTime
0:1
dateTime
Plánovaný odjezd.
0:1
dateTime
ActualDepartureTime
DepartureStatus
0:1
CallStatusCode
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.
0:1
string
nástupiště při odjezdu. DetailLevel >=2.
Tabulka 29 – Datová struktura prvku PreviousCall
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
StopTC
0:1
positiveInteger
Tarifní číslo zastávky či stanice dle plánovaného JŘ.
VehicleAtStop
0:1
boolean
Spoj stojí právě v zastávce/stanici.
AimedArrivalTime
0:1
dateTime
ExpectedArrivalTime
0:1
dateTime
Očekávaný příjezd predikcí AVMS.
ActualArrivalTime
AimedDepartureTime
0:1
dateTime
Plánovaný odjezd.
0:1
dateTime
Očekávaný odjezd predikcí AVMS.
ActualDepartureTime
61
Tabulka 30 – Datová struktura prvku OnwardCall
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
ExpectedArrivalTime
0:1
dateTime
ArrivalStatus
0:1
CallStatusCode
sloupku/
nástupiště
AimedDepartureTime
0:1
dateTime
Plánovaný odjezd.
0:1
dateTime
DepartureStatus
0:1
CallStatusCode
ArrivalPlatformName
0:1
string
nástupiště při příjezdu
0:1
string
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:*
Filtr: dopravce.
VehicleModeCode
0:*
LanguageCode
0:1
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
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ů
0:1
structure
Odkaz na datovanou jízdu spoje unikátní uvnitř
intervalu dat Producenta.
:::
0:1
:::
0:1
:::
0:1
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Ř.
StopTC
0:1
positiveInteger
Tarifní číslo zastávky či stanici na trase linky
plánovaného JŘ.
opakování téže zastávky/sloupku.
CallOptionCode
0:*
CallNote
0:*
string
Poznámky k zastavení (dispečerské texty).
AimedArrivalTime
0:1
dateTime
AimedDepartureTime
0:1
dateTime
Plánovaný odjezd.
ArrivalPlatformName
0:1
string
0:1
string
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
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
Filtr: přijíždějící.
DistributorJourneyRef
0:*
structure
Filtr: čekající (odvážející).
OperatorCode
0:*
Filtr: dopravce.
VehicleModeCode
0:*
LanguageCode
0:1
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
plánovaného JŘ
FeederJourneyRef
0:*
structure
Přijíždějící spoj.
:::
0:1
:::
0:1
:::
0:1
AimedArrivalTime
1:1
dateTime
Pravidelný příjezd.
Tabulka 40 – Datová struktura prvku ConnectionDistributor
StopPointRef
1:1
structure
plánovaného JŘ
DistributorJourneyRef
0:*
structure
Odvážející spoj.
:::
0:1
:::
0:1
:::
0:1
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
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.
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
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).
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
MonitoredDistributor
1:1
structure
MonitoredFeeder
1:1
structure
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
1:1
structure
MonitoredFeeder
1:1
structure
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
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.
0:1
dateTime
Očekávaný odjezd z přípoje.
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:*
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
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
InfoMessage
Obecná zpráva
RecordedAtTime
1:1
dateTime
ItemIdentifier
0:1
string
Identifikátor položky pro eventuální pozdější odkazy
Producenta.
SituationCode
0:*
MessageChannelCode
0:*
Dělení do kanálů. Kanály např.:
mimořádnosti, Berounsko apod.
Dynamický veřejně známý číselník.
ValidUntilTime
0:1
dateTime
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
Informace o jízdním řádu spoje/trase
VehicleModeCode
0:1
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
Dopravce spoje zadaný identifikátorem IČO.
Tabulka 54 – Datová struktura skupiny 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
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
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
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
CZ
TransportCategoryCode
1:1
Kategorie dopravy.
TransportSystemCode
0:1
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
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
Datovaný spoj (projekce spoje do daného dne)
1:1
structure
Kontext dopravy.
TrainNumber
1:1
string
Číslo vlaku.
TrainCategoryCode
1:1
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
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
26
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
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
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
TransportSystemCode
positiveInteger
58
Nymburk
59
Stříbro
60
Tachov
61
Jablonec nad Nisou
62
Vsetí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
TransportSystemCode
positiveInteger
88
Louny
89
Lovosice
91
Ostrov
92
Mariánské Lázně
93
Roudnice n. L.
94
Třebíč
95
Kralupy nad Vltavou
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
300
PID
301
IDS JMK
80
TransportSystemCode
positiveInteger
302
ODIS
303
IDSOK
304
BID
305
JIKORD
306
KIDS KK
307
KORID LK
308
OREDO
Tabulka 74 – Číselník prvku TransportSystemCode (dokončení)
TransportSystemCode
positiveInteger
311
ORID
312
POVED
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
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
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
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
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
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í)
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í)
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í)
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

Metodika _SW platforma pro sdílení a implementaci dat ve

Transkript

Podobné dokumenty

AutoTURN - srovnávací tabulka

Reliant 5_2015_Sestava 1

Přivítejmeautovi ry

ZDE

Contemporary Letter

KONTAKTY 3D SCANNER KERBEROS SOFTWARE