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

[komachi275 (笨笨熊)]

※ [本文轉錄自 MRT 看板 #1F6siuDo ]

作者: cgy (北台灣東部丘陵線籌備處) 看板: MRT
標題: Re: 相對優先模式的優先號誌邏輯
時間: Sun Jan 22 09:49:41 2012

※ 引述《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:推專業文!!
※ 發信站: 批踢踢實業坊(ptt.cc)
※ 轉錄者: komachi275 (218.187.59.16), 時間: 01/22/2012 17:29:10
推 sqr:"如果其實與前後車通過時間太近，平交道就不應該放下"
→ sqr:應該是"升起"
推 starker:"與前後車通過時間太近"這段時間要如何定義?
推 tccan:問題是，台鐵的CTC對於列車的位置，其實非常的不精確。如果
→ tccan:二座車站的距離越長就越不精確，且列車有沒有通過簡易站(或
→ tccan:招呼站)，CTC的調度員說老實話也不知道(知道的話有時候就不
→ tccan:會一直問車站的副站長列車到底在哪邊了)。
→ tccan:另外就是前後車時間太近，是指二班車的距離？速度？時間？
→ tccan:現階段的號誌系統加上ATP的監控，要讓二班車的距離很近也行
→ tccan:，時間很近也行。所謂的距離很近，就像這次的埔心事件，前一
→ tccan:班的1174次一進埔心站，後方的278次就能在3分的時間高速通過
→ tccan:埔心站。
→ komachi275:CTC不知道列車在哪一個閉塞區間？？
→ tccan:但不論如何，當1174次與278次都還在行駛時，二班車最近的距
→ tccan:離在閉塞號誌與ATP的分割之下，最近大約是3公里左右吧。
→ komachi275:平交道智慧化的概念可以像是最近流行的智慧型站牌一樣
→ komachi275:前提是列車與平交道之間要有資料通訊 只要有通訊就OK了
→ komachi275:公車動態與智慧型站牌(或者嘉義BRT的優先號誌)都很像..
→ tccan:如果知道的話，就不會常常要車站的副站長提供列車位置了。
→ tccan:而且車站的CTC資訊系統，也只能查列車的大概位置。
→ komachi275:這太糟糕了吧..CTC沒有軌道電路每一個迴路的占軌狀態!!
→ komachi275:車子在哪一個閉塞區間知道就OK了 在哪個點倒是無所謂..
→ tccan:例如XXXX次在台南站，或是在高雄－新左營間。
→ tccan:綜合調度所內的那一大塊控制盤我沒看過所以不知道，但車站的
→ tccan:就地控制盤也不是以閉塞區間來劃分列車佔用的(就地控制盤很
→ tccan:細，一個閉塞區間還分割出二個佔用區間)
→ tccan:所以車站這邊，先以CTC的資訊系統確定車次，再以就地控制盤
→ komachi275:劃分的很細 不是應該比較能掌握列車位置？
→ tccan:來確定列車詳細的位置。所以當CTC的資訊系統一掛掉，車站這
→ tccan:邊就等於瞎了眼，因為當控制盤一出現列車，就根本不知道是哪
→ tccan:班車，只能靠前後的車站來告知列車的班次為何。
→ tccan:但問題就是，車站的就地控制盤劃分的很細，但CTC綜合調度所
→ tccan:的那一塊最大塊的全線大控制盤就不知道有沒有那麼細了。
→ komachi275:了解...謝謝阿駿大解說^^"
→ tccan:但CTC的每一部電腦調度台應該就沒有那麼細。
推 asdfghjklasd:再多強的電腦,都比不過腦殘的人
推 jaredyu:我有一個小疑惑是，如果加裝前後感應子，是不是可有效解決
→ jaredyu:此問題？