Realizace preference veřejné dopravy pomocí V2X

  • Články
  • Aktualizováno

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

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


Úvod

RSU-50N-mKomunikač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.
  3. MAP-a-SPATJednotka 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.
    Na obrázku je vidět 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.
  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 Anbos (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. Server Anbos také zajišťuje hybridní komunikaci, kdy stejná zpráva C-ITS je poslána přes V2X a zároveň přes mobilní internetové připojení. Server pak zajistí její doručení do cílové oblasti (adresace je na geografickou oblast, nikoliv konkrétní jednotku).
  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í: 

Princip-systemu-preference-220426

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 s podporou zpráv SREM+SSEM
  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 – např. projekt RIS II, kde do systému je zapojeno 750 vozidel MHD či Hradce Králové) č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. Nějaká forma konfigurace na OBU je nutná, protože dnes neexistuje protokol, kterým by palubní počítač sdělil do OBU geografickou trasu linky. Proto jsou požadavky na preferenci konfigurovány pomocí sledu zastávek (určení křižovatek a vjezdové + výjezdové větve).
  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. Geografická trasa linky (obvykle ale není k dispozici).
  2. Číslo linky,
  3. Číslo spoje,
  4. Číslo kurzu,
  5. Číslo cíle,
  6. Číslo vozu,
  7. Typ vozu (tramvaj, trolejbus, autobus),
  8. Aktuální zpoždění vozu ve vztahu k dané jízdě,
  9. Poslední projetá zastávka, včetně GPS souřadnic,
  10. Nejbližší nácestná zastávka, včetně GPS souřadnic,
  11. Další nácestná zastávka, včetně GPS souřadnic,
  12. 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 vysílané mapy (topologie - zpráva MAPEM) křižovatky jednotkou RSU.

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

  • Komunikační server Anbos (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. Takový standardizovaný protokol ale dnes neexistuje.


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 o stavu priorit od OBU do PP