作者sitos (麥子)
看板ask-why
標題Re: [討論] 紅綠燈的連線控制 與效率改善
時間Tue Mar 27 17:12:24 2007
※ 引述《jaw109 (潑文章都是為了養小雞)》之銘言:
: 我想紅綠的的控制應該很簡單吧
: 就算路口有sensor, 你要加演算法在裡面 應該也難不倒幾個大學專題生
紅綠燈的控制多半不是只處理一個路口的紅綠燈,
也要考慮周邊其它的路口的連動,才不會造成走一小段就要等一次紅燈的情況。
因此它的演算法本身是相當複雜的。
如果我們把紅綠燈 reduce 到作業系統裡面的 scheduling 問題,
我們可以作以下的 mapping
將一堆車從一處送到另一處 -> task (process)
轉換燈號 -> context switch
每個燈號的時間 -> 執行的 interval
啟動波 -> context switch overhead
各燈號的連動關係 -> task dependency
事實上我們可以把簡化過的紅綠燈問題看作跟作業系統的排程同構,
同時也有相同的最佳化目標, low latency 與 throughput
(low latency 對每個人而言都不要等太久
throughput 總共能通過的車流最多 ,兩個目標之間是有衝突的)
要取得一個最佳平衡點的演算法是 NP-Hard ,
也就是我們目前還找不到在 polynomial time 的解,
簡言之,一次考慮越多的路口,要作的計算時間就會呈指數大增。
(當然這樣的講法有點過度簡化,看得懂的人知道意思就好了)
講得更直接一點,要處理紅綠燈問題又解得漂亮,
絕不是大學專題可以做得出來的,如果真的解了,
請寄信給我,我要拿去當博士論文。
: 我無法理解 幾個簡單的線路 控制面板的箱子做那麼大的原因是什麼
控制面板的箱子裡面除了控制這個路口的燈號,
也可以控制附近的燈號,另外裡面有 modem (或是其它的通訊系統),
可以透過中央控制一次,從遠端一次控制很多地方的紅綠燈。
絕不是只是固定時間就切換一次燈號那麼簡單。
: 說防彈 防止民眾撬開還比較好說服人
交通號誌對 reliability 的需求非常高,馬路如虎口,
如果今天交通號誌不小心出了個錯,兩邊都是綠燈,恐怕就被罵到臭頭了,
裡面絕不是一台控制的機器就好了,一定會作 redundency ,
同樣功能的機器至少要有兩台,避免一台壞掉,就失去作用。
當然自我修復或自我檢測的功能也必須要有。
紅綠燈不亮還算事小,亮錯就爆炸了。
: 題外話. 春節期間在楓港還遇到999秒的紅燈,有夠扯。停紅燈還可以下車買飲料...XD
--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.112.31.132
1F:推 jimpeng:那機器有這麼高級喔,常懷疑只是殼大,裡面都是空的:p 03/28 09:53
2F:推 sitos:其實我也只是自己覺得高級而已 但打開裡面東西真的不少 03/28 13:45
3F:→ soleboy:我覺得討論新型的大眾運輸系統也很重要 03/29 02:40
4F:推 zhim:有看過兩邊都是紅燈的... 03/30 15:10
5F:推 jaw109:NP-hard @_@" 想不到區區紅綠燈... (尤其是在台灣.... XD) 03/31 21:17