Dispečerský systém pro IDS

KRAJSKÝ DISPEČERSKÝ SYSTÉM URČENÝ PRO IDS

Základní struktura dispečerského systému IDS

Cílem dispečinku IDS je zlepšit organizaci veřejné dopravy krajů tj. všech druhů dopravy a to autobusové (VLD – veřejná linková doprava), železniční dopravy a městské hromadné dopravy. Do dispečinku se přenáší data a informace od všech dopravců působící v rámci kraje a nejen z něj. Krajský dispečink musí:

  • garantovat přestupy a jejich návaznosti mezi jednotlivými typy doprav a spojů (doprava je budována jako návazná).
  • informovat cestující o příjezdu vozidel (on-line na inteligentních zastávkách, na internetu, do mobilních telefonů, apod.) a o jejich pohybu po kraji. Tuto informaci lze doplnit i o možnosti informování o regionálních událostech.
  • sledovat vypravení spojů, popř. cestovní proudy, tj. počty nastupujících a vystupujících na jednotlivých zastávkách a tyto znalosti využít pro další zlepšení dopravní dostupnosti.
  • realizovat spoje na zavolání – tj. občasně obsluhovat zastávky, do kterých je třeba zajíždět, a kde ne vždy čeká cestující. Naše realizované řešení je popsáno zde.

Tyto cíle musí být schopen naplnit dispečink IDS a to vhodným uspořádáním komunikace vozidla s dispečinkem – tato komunikace zabezpečuje všechny typy obsluhy:

  • monitorovací s tím, že sleduje pohyb vozidla a jeho základní funkce ve vztahu k plnění jízdního řádu.
  • odbavovací s tím, že sděluje na dispečink počty cestujících, jejich složení, může přenášet „blacklist“, denní tržbu a další.
  • informační s tím, že umožňuje dispečerovi poslat do vozidla informace přímo řidiči či cestujícím (řešení návazností a možnost odesílání automaticky generovaných zpráv).
  • řídící s tím, aktualizuje soubory a ve vozidle, jeho konfiguraci a může snímat i stavy technologií.
  • komunikační s tím, že umožňuje datovou a hlasovou komunikaci s vozidlem (řidič, cestující).
  • v oblasti reklamy ve vozidlech – tuto část si zajišťuje dopravce tak, že ve vozidlech jsou definovány „okna“ na panelech pro reklamu (pravidla určuje koordinátor IDS).
Obr. č.1: Vazby základních systémů v rámci IDS.

Obr. č.1: Vazby základních systémů v rámci IDS.

Přenášená a zpracovávaná data na dispečinku

Dispečinky IDS mají vytvořeno komunikační prostředí, přes které se budou výše uvedená data posílat. K tomu, aby dispečink správně fungoval, musí být zapojen dle níže uvedeného obrázku. Toky dat v systému (zdroje dat) od jednotlivých dopravců a toky ostatních dat (jízdní řády zpravidla z JDF, mapové podklady, oběhy vozidel, turnus lidí a další potřebné podklady) budou různá. Vozidla jednotlivých dopravců budou připojena pomocí APN dispečinku – tj. přístupový bod do virtuální sítě bezdrátového přenosu GSM některého z mobilních operátorů (O2, T Mobile, Vodafon a příp. další) nebo datovým kanálem od dopravce, který již provozuje svoji VPN včetně vlastního serveru (i pronajaté prostory na serverech).

Jednotlivé toky dat jsou:

  1. z dispečinků dopravních podniků MHD (krajského či jiných měst), které obsahují vlastní dispečink pro řízení dopravy.
  2. z okolních IDS / do okolních IDS.
  3. od provozovatele dráhy (dnes obvykle SŽDC) nebo od železničních dopravců (zejména Českých drah).
  4. z mapového portálu krajského úřadu (mapové podklady pro zobrazení vozidel)
  5. od dopravců – zde je nutno rozlišit, zda již systém sledování dopravy mají či nemají. Pokud nemají je výhodné jejich začlenění do virtuální sítě krajského koordinátora IDS. Pokud mají, jsou jejich data přeposílána do zabezpečeným spojením do krajského dispečinku IDS. Tento způsob se však vyznačuje jistými komplikacemi z hlediska spolehlivost a komunikací.
  6. do zastávkových panelů komunikujících v rámci VPN (virtuální privátní síť) či přes internet.
  7. pro informování cestujících - např. přes internetové portály.
Obr. č.2: Struktura komunikace dispečinku

Obr. č.2: Struktura komunikace dispečinku

Cílový stav práce s vozidly – nové pohledy na problematiku

V cílovém stavu práce s vozidly v rámci IDS je centrální údržba dat ve vozidlech pro použití systému z centrálního dispečinku. Tímto způsobem je možno z jednoho místa ručit za to, že všechna vozidla mají např. platné aktuální tarify IDS, „black listy“ či „white listy“, že hlášení zaslané na vozidla bude vždy správně přehráto či zobrazeno cestujícím, že název jedné zastávky bude vždy stejně interpretován na vozidlech různých dopravců, apod. V tomto je nový pohled našeho dispečinku SPRINTER IDS na správu vozidel v rámci IDS.

V čem je základní změna? Ta je uvedena v předchozím obrázku červeně pod označením „komunikační kanál na vozidla“. V rámci tohoto kanálu existují jednoznačná pravidla na způsob synchronizace adresářů na dispečinku IDS a ve vozidle. Vozidlová řídicí jednotka (palubní počítač s odbavením – v našem případě EPIS 5FCC) tak musí umět dálkově změnit následující soubory:

  • měnit zónový ceník jízdného – platné předplatné v rámci IDS (tvorba kilometrových ceníků může zůstat v režii dopravce),
  • soubory s jízdními řády a to včetně různých typů návazností (garantovaná, s určitou dobou čekání, volná),
  • struktura a typy jízdenek včetně formátů tisku,
  • přenos blacklistu (zakázaných ID BČK) a whitelistu (uvolněné karty). Tyto soubory budou zasílány aktuálně se zúčtovacího centra do příslušného adresáře dispečinku a tento je bude při změně průběžně aktualizovat na vozidlech,
  • jednotný číselník zastávek dle CIS a to včetně jejich názvů přímo např. odesílaných na vnější tabla IDS (nutno provést konverzi od zastávek MHD, které nejsou v CIS),
  • jednotný seznam zvuků ve formátu mp3 (všechny zvuky znějí ve vozidle stejně) – je poté uplatněn i u předdefinovaných hlášení ve vozidlech,
  • jednotný seznam optických hlášení směrovaných na vnitřní LED či LCD panely, příp. na vnější (používá se jednotná abeceda CP-1250),
  • seznam kódových zpráv pro řidiče od CED a od řidiče na CED a jejich zobrazení na palubním počítači s odbavením,
  • jednotný způsob pro hlasovou komunikaci s řidičem a taktéž pro hlášení pro cestující vyvolaných dispečerem a to včetně nastavení hlasitosti (definovaný seznam předdefinovaných hlášení v menu palubního počítače s odbavením),
  • soupis povolených čísel pro hlasové hovory řidiče či pro hlášení do vozu,
  • seznam turnusů zadaných dopravcem za účelem předpovídání budoucích rizikových stavů v dopravě,
  • soupis revizorů.

Navíc většina z výše uvedených bodů musí umět pracovat se dvěma  a více bankami (či verzemi) dat a to z důvodu, aby bylo možno nová data nahrát dopředu před jejich platností.

Krajský „backoffice“ pro přípravu jednotných dat – POGEy

V rámci integrovaného dopravního systému je třeba zajistit shodné chování systému pro cestující a současně musí být možno tento systém jednotně řídit z dispečinku. Za tímto účelem byl vytvořen nový krajský „backoffice“ zvaný POGEy, který zajišťuje přehledně vytvářet a sjednocovat níže uvedené funkce. Pro snadnou přenositelnost a rozšiřitelnost byl zvolen popis formátu pomocí jazyka xml.

Vstupními daty jsou informace definované krajským organizátorem dopravy (např. polohy zastávek a jejich soupky, typy zastávek, apod.) a jízdní řády z CISu. Výstupem jsou:

  • jednotlivé soubory určené pro dopravce a dodavatele jejich odbavovacích systémů do vozidel, které se použijí pro přípravu dat pro autobusy veřejné linkové dopravy,
  • kompletní databáze určené pro pro práci krajského dispečinku.

Soubory jsou koncipovány tak, aby je bylo možno pro jednotlivé výrobce (nejenom pro firmu Herman) snadno zahrnout tyto soubory do jejich zpracování dat. Popis jednotlivých souborů (i když jsou naším know-how) je možno vyžádat a nepodléhá obchodnímu tajemství – poskytneme je zájemcům pouze za registraci.

Vlastnosti jednotlivých souborů:
Config.xml definuje základní nastavení obecných proměnných, které jsou nutná pro správu systém (tel. čísla, www stránky, časové platnosti, aj.)
Stations.xml je určen k tomu, aby důležité doplňující vlastnosti zastávek, které nejsou zaneseny v JDF souborech,  byly shodně interpretovány v celém dopravním systému. Mezi ně patří GPS poloha zastávky i sloupků, její vlastnosti, názvy zastávky, poznámky, způsoby zobrazení a hlášení, zóny, apod. Data jsou určena jako vstupní pro „backoffice“ různých výrobců a zde musí být poté přiřazen do dat o jízdních řádech (popisu jednotlivých linko/spojů).
StationOnCall.xml definuje jednotlivé spoje na zavolání v rámci IDS. Je vytvořen tak, aby zajistil možnosti objednání zajížďky autobusu do „zastávky na zavolání“ napříč všemi dopravci v rámci IDS. Z toho plyne nutnost jednotnosti způsobu zadávání, objednávání a rušení ve všech odbavovacích zařízeních a na dispečinku. Soubor proto obsahuje seznam zastávek na zavolání, jejich aktuální odjezdy i odjezdy z výchozí zastávky spoje a platnosti.
Transfers.xml definuje seznam návazností v rámci IDS tak, aby řidiči i cestující byli informováni o garantovaných návaznostech v dopravě. Seznam návazností je definován, protože ne vždy bude řidič navazujícího či čekajícího spoje informován o této situaci zprávou z dispečinku. Obsahuje tak seznam návazností napříč dopravci (v rámci IDS se na jednom místě návazností může setkat i 5 spojů a více – vlaky a autobusy).
prototyp.xml definuje seznam způsobů hlášení v rámci IDS a opět zajišťuje jednotné chování vozidel. Prototypy se určují předefinovanou strukturu hlášení, do které jsou aktuálně dosazovány proměnné dané jízdou vozidla, tj. obvykle názvy zastávek a číslovky. Význam použití prototypů je následující:

  • Spojování pevných frází a proměnných v hlášeních.
  • Spojená hlášení mohou používat aliasy.
  • Prototypy mají definováno směrování a intenzitu hlášení.

V tomto případě mohou mít proměnné další parametry, jako: jazyk, způsob hlášení výčtu, způsob hlášení čísel, kontext hlášení zastávky, apod.

Sounds.xml definuje seznam samostatných a složených zvuků (aliasů) tak, jak budou číslovány z dispečinku. Opět jsou vytvořena hlášení, které je možno zaslat na všechna vozidla bez ohledu na dopravce. V případě, že budou informační systémy vozidla pracovat odlišně, je třeba zajistit překódování uvnitř vozidla ve vozidlové řídicí jednotce.
StatusMessages.xml definuje seznam předdefinovaných stavových zpráv z vozidla včetně způsobu zobrazení na LCD terminálu řidiče a jsou určeny pro odeslání stavu vozidla na dispečink IDS, proto jejich text musí být krátký a výstižný (předpokládaná délka max. do 32 znaků). Tento seznam musí být jednotný napříč dopravci v celém IDP, jinak by jej dispečink neuměl správně vyhodnotit.
Announcement.xml definuje seznam předdefinovaných hlášení pro vozidlovou řídicí jednotku, který se zobrazuje řidiči pro jejich ruční vyvolání ve vhodné situaci. Zvuky použité v tomto souboru musí vycházet z definice zvuků a aliasů v souboru „sounds.xml“.

Naše vozidlová řídicí jednotka EPIS 5 FC a náš backoffice je již připraven na příjem výše uvedených souborů.