※ 引述《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