9. září 2026, Jan Prokop
9.9. - Čas, který běží mezi koncem zelené jednoho směru a začátkem zelené jiného kolizního směru, se v dopravním inženýrství nazývá mezičas. Pro příklad: u přechodu pro chodce se jedná o mezičasy mezi konci zelené vozidel v obou směrech a začátkem zelené chodců a naopak. V takovém případě je tabulka mezičasů tvořena dohromady čtyřmi mezičasy. U velkých křižovatek pak není problém dostat se s množstvím výpočtů dílčích mezičasů (každý vjezd může jet několika směry) až na jednotky stovek. V popsaném objemu dat lze snadno udělat chybu. Proto se automatizace výpočtu jeví jako logický krok. Nicméně komplexní software pro návrh světelných křižovatek (např. LISA) neumožňují takovou variabilitu návrhu – ať už proto, že s podkladovým výkresem pracují jako se statickým obrázkem (neumožňují změnu návrhu online), nebo proto, že nereflektují specifické požadavky provozu tak, aby byly použitelné v proměnlivém prostředí a v neposlední řadě také proto, že tento software je poměrně nákladný. Nabízí se proto automatizace výpočtu na nižší úrovni, úrovni kalkulátoru (např. MS Excel).
Samotný mezičas je roven rozdílu vyklizovací a najížděcí doby, navýšenému o bezpečnostní dobu. Najížděcí doba se vypočte jako podíl délky najížděcí dráhy a najížděcí rychlosti. Obdobně vyklizující doba (s tím rozdílem, že vyklizující dráha se prodlužuje o délku vyklizujícího vozidla). Bezpečnostní doba, stejně jako obě uvedené rychlosti, jsou určeny v TP81 Zásady pro navrhování SSZ.
Klasické výpočty jsou tedy principiálně jednoduché a případná chybovost spočívá pouze v množství výpočtů a v následném výběru (použitelných) maximálních hodnot. Jak bylo řečeno výše – u přechodu pro chodce tento problém odpadá, s velikostí křižovatky a množstvím signálních skupin může nicméně růst i chybovost, popř. náročnost modifikace tabulky přidáváním dalších dílčích výpočtů a dalším novým vyhodnocováním maximálních hodnot.
Matoucí to začíná být například v případě, kdy jezdí BUS po kolejích (a jejich zelená je řízena tramvajovým návěstidlem Tx). Zmíněné TP81 totiž definují různou rychlost pro najížděcí a vyklizující tramvaje. BUS má ale obě rychlosti stejné. K druhu vozidla a jeho rychlostem se váží i bezpečnostní doby. Zatímco BUS má stejnou bezpečnostní dobu (stejné rychlosti najíždění i vyklizování), tramvaj má kvůli rozdílným rychlostem i rozdílné bezpečnostní doby. V tabulce mezičasů ale bude vždy jen Tx vůči ostatním vjezdům (přestože ve výpočtu pro Tx figuruje i BUS). Výpočet navíc zanedbává i délku vozidla BUS (TP81 definuje jednu délku pro vozidla (v této délce se nerozlišuje, zdali se jedná o osobní automobil, BUS, návěs, …) a jednu délku pro tramvaje).
Poněkud složitější to může být při výpočtu mezičasu pro tramvaj, která jede křižovatkou různými rychlostmi (například z důvodu kolejového rozvětvení). Pokud jede například přes tři úseky o různých rychlostech, pak se velikost bezpečnostní doby určuje podle rychlosti na úrovni návěstidla. Nicméně TP81 nedefinují, k jakému z úseků se přičítá délka tramvaje.
Na hypotetické úrovni může vzniknout zajímavý problém a totiž v moment, kdy se kříží tramvaje, které projíždí křižovatkou několika úseky o různých rychlostech. Pak se jejich vyklizující a najížděcí dráhy skládají z délek těchto úseků. Počet úseků se ale může výpočet od výpočtu lišit (tramvaj může vyklizovat na čtyřech úsecích a najíždět na třech; protisměrná tramvaj může na dvou úsecích vyklizovat a na jednom najíždět; obdobně i vůči ostatním vjezdům). S trochou nadsázky lze říct, že tyto variace přidávají celé problematice až laboratorní nádech.
Zmíněné zajímavosti lze pochopitelně v kalkulátoru zohlednit, nicméně při vyšších desítkách výpočtů dílčích mezičasů může být složitější vše ohlídat.
Ve své třináctileté praxi jsem se proto zaměřil na automatizaci klasických výpočtů i těchto specifických situací. Vznikl tak poměrně robustní „systém“, který po zadání signálních skupin a jejich rychlostí vyhledá v následném množství dílčích výpočtů (v kterých kontroluje, aby vyklizující dráha byla vždy delší než najížděcí) největší hodnoty pro řešenou kolizi (A vyklizuje, B najíždí a naopak) a ty dosadí do platných pozic v tabulce mezičasů, přičemž kontroluje symetrii vzniklé tabulky. Program je koncipován tak, aby umožnil přidávat signální skupiny kamkoliv a kdykoliv a následně vyhledal maxima v nových výpočtech a tyto hodnoty dosadil do aapatřičných pozic v tabulce. Automaticky doplňuje tzv. technologické (nulové) mezičasy do případů, v kterých je relevantní (zpravidla mezi plným signálem a jeho doplňkovou šipkou), umožňuje nezohledňovat specifické, „cvičné“ výpočty, nebo v tabulce nezobrazovat tzv. pomocné výpočty (pro určení přetrhu zelených vůči chodcům) atd.
S výsledkem svého snažení jsem se obrátil na firmu EDIP, s. r. o, která vyvíjí a prodává software pro dopravní inženýry. Myšlenka na vytvoření takového softwaru je oslovila a je tedy možné, že program bude brzy k dostání i v komerční podobě.
Slovo závěrem
Z výše uvedeného je zřejmé, že tabulka mezičasů může být klasickým příkladem otrocké práce. K jejímu výsledku vede mnohdy dlouhá cesta, na které může být učiněno mnoho chyb. Následně ji posuzují dotčené orgány státní správy, které v ní i přes sebe větší snahu mohou najít nedostatky. Nakonec ji prověřuje skutečný provoz. Taková je cesta k obstojnému výsledku, který se v čase mění – křižovatky se modernizují, mění se jejich tvar, složení dopravního proudu, organizace dopravy atd.
Patřím mezi lidi, kteří se snaží rutinní úkony zjednodušit. Vytvořil jsem proto základní excelovou tabulku a pokaždé, když jsem čelil novému zadání, jsem ji v tom smyslu upravil. Výsledkem je kompilát, který doposud odpověděl na každý požadavek.
Nejoptimálnější by pravděpodobně bylo, pokud by mezičasy mohly být odečítány v reálném provozu a teprve poté byl učiněn návrh tabulky. Než se toto stane projekčním standardem, může být práce s nastíněnou automatizací dobrým pomocníkem.
Jan Prokop
Foto: JAP
