Re: 相對優先模式的優先號誌邏輯

[cgy (北台灣東部丘陵線籌備處)]

※ 引述《komachi275 (笨笨熊)》之銘言：
: ※ [本文轉錄自 Railway 看板 #1F6EPuWk ]
: 作者: komachi275 (笨笨熊) 看板: Railway
: 標題: Re: [新聞] 砂石車業者 控放行僅八秒釀禍
: 時間: Fri Jan 20 11:58:44 2012
: ※ 引述《visa9527 (高級伴讀士官長)》之銘言：
: : 根據這控訴，想問一個衍生的問題
: : 就是將來台中 BRT 會不會出現優先號誌導致橫向道路綠燈八秒又變黃燈?
: : 今天埔心的平交道都如此，要是在車流量大的台中市區又會如何?
: : 當然 BRT 的時速沒太魯閣快，膠輪摩擦力煞車也夠力，不太可能發生如此慘禍
: : 但優先號誌一啟動，難保不會中港路往火車站的放行後八秒又要讓往東海的通過
: : 這種情況發生到大城市中心一定會讓用路人怨聲載道，外加輿論壓力
: : 若因此法律制訂了 BRT 優先號誌最短橫向通行時間要 30 秒的話
: : 會不會反過來要求台鐵的平交道放行時間也要比照辦理
: : 但平交道時間過長也會使用路人怨聲載道，最短放行時間有可能產生共識或立法嗎?
: : 我建議台鐵還是修法立法把這一塊模糊空間弄清楚好了

這點多慮了

現在紅綠燈有些挺智慧的

就是以車流方式概念去偵測，然後提供最佳的時相去解決交通問題，其實就是解決

路口車輛延滯問題。


當然配上優先號誌，是不清楚台中brt是不是可以做到這樣程度，就是給予brt速度上

的控制，brt通過路口的時候剛好也是橫向來車清的差不多，而不是刻意因為brt要

通過，額外在旁大的車流內插入一個紅燈攔下對象車流。

當然不可能完全清空，而是減少車輛延滯時間和數量，也可以維持基本brt順暢運作，

當然這是需要龐大資訊通訊系統作為後盾。


需要有車流偵測，通訊設備，紅綠燈時相模式計算（其實先建立幾個劇本，當

現場車流達到怎樣就啟動該劇本，這些東西都有歷史資料可以建立相關模式等，

當然如果有錢砸下去運用更高速電腦可以做出即時策略上的應對也是有可能，

這些不是嘴砲，而是世界上都已經出現了）


埔心事件就是在於，前車通過後，後車壓到平交道感應子時間差，差異剛好放起來

又在過20幾秒後，這一直都是一個問題，這件事老實說不能說台鐵完全沒有啥改進

的地方，以交通工程概念來看，的確還有很大的改善空間，其實埔心事件這樣平交

道車禍應該不是第一例。


例如：延長感應距離（但事實上有個問題，延長更長感應距離勢必會帶來更長的

等候時間，這是在都市內不太能被允許的）


其實比較好的作為，其實平交道應該與ctc作個連接，現階段台鐵ctc都可以知道

車輛位置（非精確），可以推算抵達最近平交道時間，如果其實與前後車

通過時間太近，平交道就不應該放下


（其實剛剛想起來這樣參數還需速度，但記得台鐵atp 速度上面控制 與計算一直

都是那棵隨身碟裡面的資料，終端機應該是不會有速度資料，應該只有某車壓過

感應子的登陸時間，其實藉由同一個感應子不同車輛壓過時間比對一下，應該是可以做到
）


另外有作台鐵平交道與道路交通號誌連鎖，但其實就是很單純平交道警鈴啟動

，啟動黃燈及紅燈這樣而已，等到平交道警鈴結束轉換成綠燈。


其實有很多的soloution 只是要不要去買去作而已，這些都有非常成熟的技術與概念




--
相簿
http://photo.xuite.net/chenkyen
運輸也可成為旅遊的主角
http://blog.xuite.net/chenkyen/blog

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 218.160.182.86
推 yohoboy:真是看了很專業..
推 komachi275:關於速度資訊的部分其實不需要[即時的] 因為各路段的
→ komachi275:限速固定 列車排點的速率也固定 只要有列車種的資料
→ komachi275:資料庫會有非常多的速度資訊可以推出一個參考標準
→ komachi275:(ATP速率監測資訊結班都會回傳主機)
→ komachi275:因此 甚至只要知道列車的位置，多久後會通過平交道都
→ komachi275:能掌握...我一直想不透的是道路系統都已經逐步智慧化
→ komachi275:的今日 臺鐵的架構似乎還停留在非常久遠的原始時代
推 komachi275:借轉Railway版^^"
推 joson4921:推專業文!!
※ komachi275:轉錄至看板 Railway                                   01/22 17:29