Re: [新聞] 調降參數避突槌 議員批柵湖線作弊
其實我覺得這樣做蠻正常的啊 (如果有錯請理性討論)
所謂分六段應該只是把車子跟道旁設備的通訊 分成六個區間處理
每個區間各自接back-bone回行控中心
一切都還是同一個行控中心在控制
如果分成六個行控中心 才真的該緊張吧 ~"~
拿行動電話來說吧 行動電話也是分成一堆基地台啊
人口愈稠密的地方(如都市) 每個基地台服務的cell愈小 基地台總數愈多
而且每個基地台也會根據週遭環境不同調整服務參數啊
只要你的手機沒問題 你的移動速度也沒超過換手機制可負荷的移動速度
就沒問題啊 你還是可以講你的電話
不用管電信公司在這區域裡切了多少cell分給不同基地台服務
其實這跟電信公司發展行動電話 架設基地台一樣
剛開始提供服務 可能架一個基地台服務一大片區域
可是隨著用戶增多 或是這個地區搬進來的人口增加
本來的基地台服務不了那麼多用戶 開始常常出現基地台塞爆
或是開始被客戶抱怨電話打不通 or 電話講一講斷掉
這時候就會開始找附近其他位置架新的基地台
然後調整原有基地台的參數 (比如說降低功率.縮小服務的cell 頻道跟附近錯開)
拿這狀況回來看內湖線... (它的行控系統就好比車子要隨時跟行控中心通電話)
我認為應該是當時太高估通訊設備的負載能力
造成幾次車一多就當掉
所以 就分區段吧
※ 引述《ericyu (Eric)》之銘言:
: 「靠作弊救柵湖線,出事誰能扛?」莊瑞雄抨擊,他向捷運局調閱系
: 統調整的資料,發現市府為了營造柵湖線穩定營運假象,竟同意機電
: 承包商龐巴迪公司,將列車通訊的參數,從全線獨立,調整為分段獨
: 立。
: 捷運局機電處坦承,柵湖線先前的狀況百出,主要在於列車與行控中
: 心的無線傳輸誤訊號問題,一旦單一設備出現故障或列車出現誤訊號,
: 就會造成全線停擺,經過網路參數重整後,電腦重整可從2的26次方,
: 加快為2的6次方。
--
http://iscory.idv.tw/
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.230.52.13
※ 編輯: globalhawk 來自: 61.230.52.13 (09/13 11:00)
→
09/13 14:31, , 1F
09/13 14:31, 1F
→
09/13 14:42, , 2F
09/13 14:42, 2F
推
09/13 14:50, , 3F
09/13 14:50, 3F
→
09/13 14:51, , 4F
09/13 14:51, 4F
推
09/13 14:53, , 5F
09/13 14:53, 5F
推
09/13 14:55, , 6F
09/13 14:55, 6F
推
09/13 15:03, , 7F
09/13 15:03, 7F
→
09/13 15:03, , 8F
09/13 15:03, 8F
→
09/13 15:03, , 9F
09/13 15:03, 9F
→
09/13 15:07, , 10F
09/13 15:07, 10F
→
09/13 15:08, , 11F
09/13 15:08, 11F
→
09/13 15:09, , 12F
09/13 15:09, 12F
→
09/13 15:48, , 13F
09/13 15:48, 13F
→
09/13 16:58, , 14F
09/13 16:58, 14F
推
09/13 17:03, , 15F
09/13 17:03, 15F
→
09/13 17:04, , 16F
09/13 17:04, 16F
→
09/13 17:16, , 17F
09/13 17:16, 17F
→
09/13 17:17, , 18F
09/13 17:17, 18F
推
09/13 18:20, , 19F
09/13 18:20, 19F
→
09/13 18:23, , 20F
09/13 18:23, 20F
推
09/13 18:42, , 21F
09/13 18:42, 21F
推
09/13 18:46, , 22F
09/13 18:46, 22F
→
09/13 18:53, , 23F
09/13 18:53, 23F
推
09/13 18:56, , 24F
09/13 18:56, 24F
→
09/13 18:57, , 25F
09/13 18:57, 25F
→
09/13 18:58, , 26F
09/13 18:58, 26F
→
09/13 18:59, , 27F
09/13 18:59, 27F
推
09/13 18:59, , 28F
09/13 18:59, 28F
→
09/13 19:00, , 29F
09/13 19:00, 29F
→
09/13 19:01, , 30F
09/13 19:01, 30F
→
09/13 19:02, , 31F
09/13 19:02, 31F
推
09/13 19:10, , 32F
09/13 19:10, 32F
→
09/13 19:11, , 33F
09/13 19:11, 33F
推
09/13 19:25, , 34F
09/13 19:25, 34F
推
09/13 20:18, , 35F
09/13 20:18, 35F
→
09/13 20:19, , 36F
09/13 20:19, 36F
→
09/13 20:22, , 37F
09/13 20:22, 37F
重新summary一下我要講的意思好了
從本來的這樣
[ OCC ]---[1]--[2]--[3]--[4]--[5]--[6] ... 全線都是一個區間 包含所有車輛資訊
改成這樣
[ OCC ] [1] [2] [3] [4] [5] [6] ... 分成幾個區間 每個區間只會有現在在
||||||----| | | | | | 區間內的車輛的資訊
|||||----------| | | | |
||||----------------| | | |
|||----------------------| | |
||----------------------------| |
|----------------------------------|
主控權都還是在OCC上 OCC都管得到每輛車
如果有車失聯 安全機制都一樣會讓車停 沒什麼不安全的
That's all.
至於為什麼不一開始就分開: (以下可以算題外話)
前者 車子就直接跑就好 反正走到哪都有這台車的資料
可是缺點就是 車子這麼多 距離也很長 通訊負荷量很大
後者 每個區間顧好每個區間內的車就好
額外成本就是 跨區間要hand-over 會增加車子通訊量
也會增加骨幹網路的工作
可是可以把整體通訊容量提高很多
承上面我用手機舉過例子 再用這個用生活化的例子來說
如果你在行駛中的車子上講手機
從基地台A服務的區域移往基地台B服務的區域
首先你的手機會發現基地台A訊號開始變弱 然後開始一邊搜尋其他基地台訊號
發現了基地台B 這時候就會跟基地台A講說想換去給基地台B服務
基地台A會透過骨幹網路溝通 確認基地台B可以提供服務
然後透過骨幹網路把這隻手機的資料給基地台B
並且告訴手機可以切換到基地台B的頻道
這時候會有很小一段時間 基地台A跟B 都會傳送你這隻手機所要的資料
以免你的通話發生中斷
等到確定基地台B接手沒問題 基地台A才會完全停止對你的服務
hand-over時骨幹網路很忙 你的手機也很忙
這就是為什麼在移動的情況下講電話比較耗電的原因
還有服務每個cell的基地台要記錄現在自己的cell裡有哪幾隻手機
電信公司也要記好每一隻手機現在在哪一個cell裡
這樣有人打電話給你時才知道該請哪個基地台找你
這些都是額外成本 可是這些跟cell不夠多 每個cell負荷過大進而影響服務品質比起來
應該是可以接受的 至少保障大家通訊可靠 不會被用戶罵到臭頭
不允許通訊中斷的捷運系統就更不用說了 當然是維持通訊可靠重要
--
p.s. to ggg12345, 有其他高見可以直接發一篇 不要玩我的文章
※ 編輯: globalhawk 來自: 61.230.52.13 (09/13 21:10)
討論串 (同標題文章)
完整討論串 (本文為第 1 之 6 篇):