Re: [討論] 紅綠燈的連線控制 與效率改善
※ 引述《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
推
03/28 09:53, , 1F
03/28 09:53, 1F
推
03/28 13:45, , 2F
03/28 13:45, 2F
→
03/29 02:40, , 3F
03/29 02:40, 3F
推
03/30 15:10, , 4F
03/30 15:10, 4F
推
03/31 21:17, , 5F
03/31 21:17, 5F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 7 之 7 篇)：