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

Transkript

1 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

2 Autoři: Ing. Tomáš Chlebničan Mgr. Marek Ščerba Ing. Zuzana Švédová Název: Vydavatel: SW platforma pro sdílení a implementaci dat ve veřejné osobní dopravě v reálném čase přes softwarovou aplikaci CISReal Centrum dopravního výzkumu v.v.i. Náklad: Vydáno v roce: 2014 Kontakt na autory: zuzana.svedova@cdv.cz marek.scerba@cdv.cz

3 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

4 Certifikovaná metodika byla vypracována za finanční podpory a použití výsledků řešení výzkumného projektu TAČR TA 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

5 Obsah I Cíl metodiky... 7 II Vlastní popis metodiky Úvod OBECNĚ OBLAST PŮSOBNOSTI Informační systémy DYNAMICKÝ DISPEČINK SW platforma návrh organizace systému veřejné dopravy s centrálním prvkem CISReal INFRASTRUKTURA DATA Z VOZIDEL DISPEČINKY JEDNOTLIVÉHO DOPRAVCE DISPEČINK PROVOZUJÍCÍ VÍCE DRUHŮ DOPRAVY DATA V ISR PŘENOS VOZIDLO DISPEČINK Metodika sběru dat - Popis systému CISReal VLASTNOSTI CISREAL FUNKCE SYSTÉMU STANDARDNÍ FUNKCE SYSTÉMU PROCESNÍ STRUKTURA MODULŮ PRINCIP ŘEŠENÍ CISREAL METODIKA SBĚRU DAT - KOMUNIKACE MEZI ÚČASTNÍKY TYPY KOMUNIKACE Definice aplikační logiky souboru technických specifikací SIRI Názvosloví veřejné dopravy v oblasti informačních systémů Názvosloví datové prvky CEN/TS SIRI Forma sběru dat - Informace přijímané službou systému CISReal Distribuční rozhraní - Informace publikované službou systému CISReal Softwarová platforma III Srovnání novosti postupů IV Popis uplatnění certifikované metodiky V Ekonomické aspekty VI Seznam použité literatury

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

7 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 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/EU 2 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 7

8 SEZNAM ZKRATEK AVL Automatic vehicle location AVMS Automatic vehicle monitoring systém API APPLICATION PROGRAMMING INTERFACE CDIS Centrální dispečink CDV Centrum dopravního výzkumu CEN Evropské centrum pro normalizaci CIS JŘ Centrální informační systém o jízdních řádech CISReal Centrální systém informací v reálném čase ČVUT České vysoké učení technické DIC Dopravně informační centrum DIS Dispečink DD Dynamický dispečink EU Evropská unie GPS Global positioning systém ID Jednoznačná identifikace (jedná se kód) IDS Integrovaný dopravní systém ISR Informační systém v reálném čase IZS Integrovaný záchranný systém JDF Jednotný datový formát JŘ Jízdní řád JSDI Jednotný systém dopravních informací MHD Městská hromadná doprava NDIC Národní dopravní informační centrum PD Příprava a zpracování dat SJŘ Správa jízdních řádů SIRI Service protocol for real time information (CEN ) SW Software TS Technická specifikace VD Veřejná doprava osob 8

9 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 zdroje 3 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 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í / 4 Úř. věst.l 207/1 5 Úř. věst. L 281 9

10 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í 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 , 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 CISReal 6, názvosloví které koresponduje s normou SIRI 7, 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

11 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 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 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: 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, 11

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

13 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 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: 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). 13

14 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

15 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 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: 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. 15

16 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) 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

17 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) Jízdní řády, 2) Označení linek, 3) Číselník zastávek, 4) Označení dopravce, 5) Tarifní vzdálenosti, 6) Určení příjezdu a odjezdů spojů, 7) Číselné označení spojů, 8) Označení spojů, 9) 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

18 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) Zisk informací o progresi vozidla a jeho identifikačních znaků Location, 2) Alerty z vozidel (vozidlo v koloně, nehoda, defekt apod.) VehicleBroadcast, 3) Možné informace o aktuální obsazenosti vozidel Occupancy, 4) 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. 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 : 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. 18

19 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 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

20 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

21 Obecné požadavky na dispečink 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í u 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, 21

22 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,

23 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 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 23

24 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 ové 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 ové 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ů 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 CISReal, která zajišťuje interoperabilitu s jinými systémy, nebo v budoucnu instalovanými systémy, 24

25 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 je doporučeno, aby veškeré HW vybavení dispečinku splňovalo normu pro elektrické přípojky ČSN Elektrotechnické předpisy. Elektrická zařízení a ČSN 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. 25

26 Minimální požadavky na centrální SERVER centrální server dispečerského pracoviště by měl splňovat normy ČSN 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 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 Elektrotechnické předpisy. Elektrická zařízení ČSN 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

27 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 (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

28 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

29 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: 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. 9 29

30 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