Realizace preference veřejné dopravy pomocí V2X

Realizace preference veřejné dopravy pomocí V2X

 Článek pojednává o realizaci preferenci MHD a VLD (dále jen veřejné dopravy) pomocí komunikační technologie V2X a to v případech, kdy obecná jednotka OBU (On Board Unit) ve vozidle zajišťuje tuto preferenci s obecnými palubními počítači pro odbavovací a informační systém (PP OIS) – tzv. 3party solution.

RSU

Ukázka naší nové jednotky V2X určené pro křižovatky – typ RSU 5.0 – jak zajišťuje komunikaci s tramvají.

Úvod

Komunikační technologie V2X na střední vzdálenosti mezi vozidly navzájem a mezi vozidlem a infrastrukturou má jako jeden ze svých způsobů užití i preferenci vozidel veřejné dopravy (VD) na křižovatkách. V typickém použití je to vozidlová palubní jednotka OBU (zkratka On-Board Unit), která řídí samotné vysílání preferenčních pokynů a zpracovává odpovědi. Jednotka OBU takto činí na základě vlastní konfigurace a dopravních dat o službě vozidla získaných z palubního počítače (PP) informačního a odbavovacího systému vozidla. Jednotka OBU tak z palubního počítače přebírá informace o jízdě a zpět předává informace o požadavcích na preferenci.

Komunikace probíhá dle evropských standardů, zejména určených projektem C-ROADS (koordinován Evropskou komisí: www.c-roads.eu). Podkladem pro standardy projektu C-ROADS jsou evropské normy vydané institutem ETSI.

Architektura systému preference vozidel VD

Složení systému

Základními prvky systému řízení preference na křižovatkách pro veřejnou dopravu (MHD i VLD) jsou dále popsané jednotky či programy (čísla odrážek odpovídají číslům na níže uvedeném obrázku):

1)      Vozidlová jednotka OBU (v našem pojetí UCU 5.0 vyráběná a dodávaná v několika verzích) – komunikační jednotka umístěná ve vozidle veřejné dopravy (VD), která umožňuje pomocí normalizovaných zpráv V2X komunikaci s křižovatkou. Pro účely preference odesílá požadavky na preferenci ve formě zprávy SREM a přijímá stav zpracování požadavku ve formě zprávy SSEM. Mimo to přijímá informace o ostatních vozech, varování a také o signálním plánu řadiče křižovatky.

2)      Palubní počítač řídicí informační a příp. odbavovací systém (PP) na voze VD (v našem pojetí jsou to palubní počítače EPIS řady 4.x či 5.x, které mají ovládání V2X integrováno)zajišťuje informování cestujících a řidiče o trase vozidla, dodržování jízdního řádu, komunikaci s dispečinkem, případně umožňuje i odbavení cestujících (hlavně VLD) a komunikuje s dalšími systémy na vozidle. Obsahuje i o uživatelské rozhraní pro řidiče.

Obr. 4: Ukázka zobrazení zpráv MAP a SPAT na dvou křižovatkách dvou různých výrobců.

Ukázka zobrazení zpráv MAP a SPAT na dvou křižovatkách dvou různých výrobců s vysílaným signálním plánem křižovatky.

3)      Jednotka RSU (Road-side unit) (v našem pojetí RSU 5.0) – komunikační jednotka technologie V2X instalovaná na křižovatce a komunikující s řadičem křižovatky (obvykle pomocí sběrnice ethernet, dříve RS 485 či obdobnou technologií). Zajišťuje pro řadič komunikaci s vozidly v okolí křižovatky, a to nejen pro VLD či MHD (ze speciálních záchranných složek i s IZS). Dle popisu v tomto dokumentu zejména přijímá požadavky z vozů VD a předává jim zpět stav „dění v křižovatce“ na jejich zpracování (na základě informace z řadiče křižovatky). Mimo to například může vysílat mapu křižovatky a aktuální signální plán.

4)      Řadič křižovatky – řídí světelné signalizační zařízení (SSZ) a dodává jej výrobce tohoto řadiče (v ČR obvykle Cross, Yunex (dříve Siemens Mobility) či Swarco Traffic CZ). Řadič na základě vnitřní logiky řízení signálního plánu křižovatky rozhoduje o udělení preference a jednotka RSU tyto zprávy od řadiče jen dále vysílá ve formátu dat V2X. Komunikace jednotky RSU s řadičem křižovatky probíhá proprietárním protokolem výrobce řadiče.

5)      Server konfigurace OBU/RSU (v našem pojetí server UCU-BOS (SW Back Office Server pro jednotky UCU) – server zajišťuje přípravu konfiguračních dat pro řízení preference VD a jejich aktualizaci ve vozidlové jednotce OBU. Data z něj dnes typicky aktualizují data a FW v jednotkách OBU – v tomto případě za účelem řízení preference vozidel VD. Dalšími funkcemi je např. sledování a vyhodnocení kvality preference poskytnuté vozidlům VD (poměr vyslaných a zpracovaných požadavků, atd.). V rámci tohoto serveru se zadávají preferenční body do systému.

6)      Server konfigurace/přípravy dat pro palubní počítač PP (resp. pro vozidlový informační a odbavovací systém (OIS)) – SW dodávaný výrobcem palubního počítače PP (v našem pojetí EPCOMP nebo POGEy), ve kterém se připravují veškerá data pro PP, která určují chování vozu na trase.

Na základě tohoto schématu je veškeré logika řízení preference soustředěna do jednotky OBU ve vozidle a funguje zcela autonomně (není třeba mít propojení na „nějaký“ řídicí server).

Velmi důležité je propojení mezi servery, kdy Server konfigurace jednotek OBU (5) vyčítá dat ohledně jízdních řádů ze Serveru konfigurace palubního počítače (6).

Komunikační schéma pro nezávislé systémy PP a OBU je tedy následující: 

Schéma komunikace mezi jednotlivými prvky preferenčního systému. Preferenci řídí jednotka OBU, která nezbytná data získává z palubního počítače a vlastní konfigurace. Určitá část konfigurace může přijít i na základě komunikace server-server.

Schéma komunikace mezi jednotlivými prvky preferenčního systému VD. Preferenci řídí jednotka OBU, která nezbytná data získává z palubního počítače a vlastní konfigurace. Určitá část konfigurace může přijít i na základě komunikace server (5) – server (6).

Výhody architektury technologie V2X

Výhodou architektury, kdy preferenci vozidel VD řídí jednotka OBU v technologii V2X, je:

1)      Soulad s normou ISO 19091, tj. mezinárodními standardy.

2)      Rychlejší reakce na změny standardů: ačkoliv zprávy jsou definovány již dnes, použití jejich částí není ještě plně usazené. Co také není úplně určené, je i logika vysílání – kdy vyslat požadavek z OBU a v jakých podmínkách jej aktualizovat. Toto je dáno know how dodavatele (máme bohaté zkušenosti z realizace největšího projektu v Evropě s V2X – projekt RIS II, kde do systému je zapojeno 750 vozidel MHD) či provozovatele systému a závisí na lokálních podmínkách provozu (dopravním řešení křižovatky).

3)      Zadávání preferenčních bodů do serveru konfigurace OBU/RSU (5) je nezávislé na trasách linky, podstatný je jen sled zastávek na daném linko/spoji. Nedojde tedy k nutnosti duplicitního zadávání v případě změny trasy linky.

4)      Možnost jednoduché tvorby statistik na Serveru konfigurace OBU/RSU (5) – pokud jsou OBU i RSU od jednoho výrobce, je možné jednoduše validovat, jak preference funguje v MHD či např. v ZZS (záchranná zdravotnická služba).

5)      Možnost nadstandardního řízení, pokud jsou OBU i RSU od jednoho výrobce, je možné v standardu zajišťovat služby obousměrné komunikace V2X mezi vozidlovou OBU a řadičem křižovatky a “ekologickou preferenci” typu „řízeného staničení“, kdy vozidlo dostává z řadiče křižovatky předzvěst o budoucí zelené (na rozdíl od vysílání signálního plánu to značí, že „zelená“ je již v signálním plánu „zafixovaná“).

Každá část systému zde uvedeného systému tak pracuje tak, aby nedocházelo k duplicitám v zadávání dat a bez následné poměrně komplikované integrace preference do palubního počítače vozidla.

Potřebná data z PP pro preferenci

Základní údaje potřebné z PP pro správnou funkci preference

Pro správné řízení preference vozidla VD potřebuje jednotka OBU následující data z palubního počítače (viz popis komunikačního protokolu mez PP a OBU):

  1. Číslo linky,
  2. Číslo spoje,
  3. Číslo kurzu,
  4. Číslo cíle,
  5. Číslo vozu,
  6. Typ vozu (tramvaj, trolejbus, autobus),
  7. Aktuální zpoždění vozu ve vztahu k dané jízdě,
  8. Poslední projetá zastávka, včetně GPS souřadnic,
  9. Nejbližší nácestná zastávka, včetně GPS souřadnic,
  10. Další nácestná zastávka, včetně GPS souřadnic,
  11. Přítomnost vozu v zastávce či aktivace dveřního kontaktu.

Tyto data od PP musí jednotka OBU získat s minimálním zpožděním. Je tedy vhodné je zasílat periodicky např. po 10 sekundách, nebo při změně některého z parametrů. Druhou možností je zasílat je tak často, aby nevznikla latence při předávání zpráv, např. 1 sekunda (zejména u možnosti řízeného staničení). Užitečné je i zaslat celou posloupnost zastávek pro danou jízdu. Pak jen stačí indikovat, v jaké zastávce se vůz případně nachází (podobně jako v protokolu IBIS-IP dnes používaném v Německu (např. Ludwigsburg) a integrovaném do jednotky UCU 5.0).

Geografická trasa linky

Další důležitá informace pro funkci preference VD je geografická trasa linky. V současnosti je vytvářena načítání informací o linko/spojích z dat pro palubní počítač, kde je poté porovnávána z daty zadanými pro jednotlivé křižovatky. Jednotka OBU tak žádá o preferenci za základě znalosti své geografické trasy a příp. vysílané mapy (topologie) křižovatky jednotkou RSU.

Geografickou trasu vozidla tak OBU vyhodnotí na základě následujících dat:

  • Komunikační server UCU-BOS (5) – server dodavatele PP (6), kdy server pro tvorbu dat pro palubní počítač (6) poskytne trasu linky pro server dohledu a konfigurace jednotek OBU (5).
  • Komunikací palubní počítač – OBU, kdy palubní počítač poskytne jednotce OBU tuto trasu během jízdy data dle předchozí podkapitoly.

Data z řadiče (OBU) do PP

Vozidlová jednotka OBU vysílá pokyny pro preferenci na základě vlastních konfiguračních dat získaných ze serveru (5) a dat o aktuálním nastavení a stavu palubního systému (jízdě) získaných z PP pomocí komunikačního protokolu. O každém vyslaném pokynu k preferenci může jednotka OBU odeslat informaci i do palubního počítače (dle požadavků na informování řidiče o stavu preference).

Jednotka RSU navíc na každý preferenční pokyn odpoví zprávou SSEM, v níž je uveden stav zpracování požadavku (zpracovávám / preference udělena / preference zamítnuta). Tento stav se v čase může měnit.

Informaci o stavu zpracování je samozřejmě vhodné doručit i do palubního počítače. Při každé aktualizaci stavu zpracování v řadiči/jednotce RSU pak OBU odešle informaci o tomto stavu do palubního počítače.

Jednotka OBU tedy do palubního počítače v případě potřeby odešle zprávu, která obsahuje:

  1. ID křižovatky
  2. Větev vjezdu a výjezdu vozidla (definováno v serveru (5))
  3. Typ požadavku (přihláška / odhláška / korekce)
  4. Stav zpracování požadavku (odeslán z OBU / přijat RSU / zpracováván řadičem / preference udělena / preference zamítnuta).
  5. Je také možné indikovat pokyn k odjezdu ze zastávky před křižovatkou (tzv. řízené staničení)

Palubní počítač tak může zobrazit řidiči následující:

  • Informaci o tom, že jednotka odesílá pokyny, a že je RSU přijímá (kontrola funkčnosti preference) – může být signalizováno jednoduchou ikonou na PP
  • Pokyn k odjezdu ze zastávky před křižovatkou, pokud tento pokyn podporuje dopravní řešení v řadiči křižovatky.

Komunikační protokol PP-OBU

Způsoby propojení

Komunikační protokol mezi OBU a PP ve vozidle musí poskytnout do OBU potřebná data a naopak, může do logu vozidla předat data o preferencích. Dále je možno průběh či stav preferenci či jednotky OBU zobrazovat řidiči.

Protokol, který máme připraven, je možné spustit v několika variantách:

  • HTTP klient + server, data ve formátu JSON či XML,
  • UDP klient + server, data ve formátu JSON či XML,
  • Websocket (OBU jako klient),
  • čerpání z API rozhraní PP
  • německý standard dle protokolu VDV 301-2 – IBIS-IP. U tohoto protokolu ale není doposud definována služba pro sdělení aktivované preference.

Ukázka návrhu proprietárního protokolu na komunikační jednotku V2X – typ UCU 5.0x – určeného pro komunikaci s jinými výrobci PP než je firma Herman (3rd party board computer) následuje:

Obecné vlastnosti protokolu

Jednotka OBU (UCU 5.0) podporuje následující komunikační rozhraní pro IP komunikaci:

  • Ethernet
  • LTE
  • Wi-Fi (klient nebo AP)

Typicky pro vozidlové propojení se předpokládá propojení přes Ethernet.

Služby pro komunikaci

V rámci komunikace mezi PP a OBU jsou navrženy dvě základní služby:

  • Služba poskytující data o průběhu jízdy z PP do jednotky OBU (služba 3250 – ucu3rdPartyBoardComputerData)
  • Služba o stavu priorit od OBU do PP (služba 3251 – PublicTransportPriorityStatus)