我猜,每個程式設計師對著電梯都想過排程演算法吧!
不管你是在北上廣還是在港澳臺,甚至三四線城市,凡是有規模的地區,高樓比比皆是。
不管是寫字樓,還是大型商城,讓你最頭痛的就是乘電梯,尤其是在趕時間的時候。
每天早上,那些差5分鐘就遲到的程式設計師,在等電梯時,一般會做兩件事:
第一,在心裡罵電梯慢;
第二,在心裡暗算著電梯排程如何最佳化;
前者可能是寫字樓裡上班族慣有的精神類疾病,但後者肯定是程式設計師的職業病。
本文對“罵電梯”不給予任何指導性建議。
但說起電梯排程演算法,我覺得還是可以給大家科普一下,好為大家在等電梯之餘,打發時間而做出一點貢獻。(電梯排程演算法可以參考各種硬碟換道演算法,下面內容整理自網路)
傳統電梯排程演算法
1.1 先來先服務演算法(FCFS)
先來先服務(FCFS-First Come First Serve)演算法,是一種隨即服務演算法,它不僅僅沒有對尋找樓層進行最佳化,也沒有實時性的特徵,它是一種最簡單的電梯排程演算法。
它根據乘客請求乘坐電梯的先後次序進行排程。此演算法的優點是公平、簡單,且每個乘客的請求都能依次地得到處理,不會出現某一乘客的請求長期得不到滿足的情況。
這種方法在載荷較輕鬆的環境下,效能尚可接受,但是在載荷較大的情況下,這種演算法的效能就會嚴重下降,甚至惡化。
人們之所以研究這種在載荷較大的情況下幾乎不可用的演算法,有兩個原因:
-
任何排程演算法在請求佇列長度為1時,請求速率極低或相鄰請求的間隔為無窮大時使用先來先服務演算法既對排程效率不會產生影響,而且實現這種演算法極其簡單。
-
先來先服務演算法可以作為衡量其他演算法的標準。
1.2 最短尋找樓層時間優先演算法(SSTF)
最短尋找樓層時間優先(SSTF-Shortest Seek Time First)演算法,它注重電梯尋找樓層的最佳化。
最短尋找樓層時間優先演算法選擇下一個服務物件的原則是最短尋找樓層的時間。
這樣請求佇列中距當前能夠最先到達的樓層的請求訊號就是下一個服務物件。
在過載荷的情況下,最短尋找樓層時間優先演算法的平均響應時間較短,但響應時間的方差較大,原因是佇列中的某些請求可能長時間得不到響應,出現所謂的“餓死”現象。
1.3 掃描演算法(SCAN)
掃描演算法(SCAN) 是一種按照樓層順序依次服務請求,它讓電梯在最底層和最頂層之間連續往返執行,在執行過程中響應處在於電梯執行方向相同的各樓層上的請求。
它進行尋找樓層的最佳化,效率比較高,但它是一個非實時演算法。掃描演算法較好地解決了電梯移動的問題,在這個演算法中,每個電梯響應乘客請求使乘客獲得服務的次序是由其發出請求的乘客的位置與當前電梯位置之間的距離來決定的。
所有的與電梯執行方向相同的乘客的請求在一次電向上執行或向下執行的過程中完成,免去了電梯頻繁的來回移動。
掃描演算法的平均響應時間比最短尋找樓層時間優先演算法長,但是響應時間方差比最短尋找樓層時間優先演算法小,從統計學角度來講,掃描演算法要比最短尋找樓層時間優先演算法穩定。
1.4 LOOK 演算法
LOOK 演算法是掃描演算法(SCAN)的一種改進。對LOOK演算法而言,電梯同樣在最底層和最頂層之間執行。
但當 LOOK 演算法發現電梯所移動的方向上不再有請求時立即改變執行方向,而掃描演算法則需要移動到最底層或者最頂層時才改變執行方向。
1.5 SATF 演算法
SATF(Shortest Access Time First)演算法與 SSTF 演算法的思想類似,唯一的區別就是 SATF 演算法將 SSTF 演算法中的尋找樓層時間改成了訪問時間。這是因為電梯技術發展到今天,尋找樓層的時間已經有了很大地改進,但是電梯的執行當中等待乘客上梯時間卻不是人為可以控制。SATF 演算法考慮到了電梯執行過程中乘客上梯時間的影響。
實時電梯排程演算法
2.1 最早截止期優先排程演算法
最早截止期優先(EDF-Earliest Deadline First)排程演算法是最簡單的實時電梯排程演算法,它的缺點就是造成電梯任意地尋找樓層,導致極低的電梯吞吐率。
它與 FCFS 排程演算法類似,EDF 演算法是電梯實時排程演算法中最簡單的排程演算法。
它響應請求佇列中時限最早的請求,是其它實時電梯排程演算法效能衡量的基準和特例。
2.2 SCAN-EDF 演算法
SCAN-EDF 演算法是 SCAN 演算法和 EDF 演算法相結合的產物。SCAN-EDF 演算法先按照 EDF 演算法選擇請求列隊中哪一個是下一個服務物件,而對於具有相同時限的請求,則按照 SCAN 演算法服務每一個請求。它的效率取決於有相同 deadline 的數目,因而效率是有限的。
2.3 PI 演算法
PI(Priority Inversion)演算法將請求佇列中的請求分成兩個優先順序,它首先保證高優先順序佇列中的請求得到及時響應,再搞優先順序佇列為空的情況下在相應地優先順序佇列中的請求。
2.4 FD-SCAN 演算法
FD-SCAN(Feasible Deadline SCAN)演算法首先從請求佇列中找出時限最早、從當前位置開始移動又可以買足其時限要求的請求,作為下一次 SCAN 的方向。
並在電梯所在樓層向該請求訊號執行的過程中響應處在與電梯執行方向相同且電梯可以經過的請求訊號。
這種演算法忽略了用 SCAN 演算法相應其它請求的開銷,因此並不能確保服務物件時限最終得到滿足。
演算法基礎閱讀:8 種排序演算法:從原理到改進,再到程式碼兌現透徹解析
電梯排程高水平研究
以上兩結介紹了幾種簡單的電梯排程演算法。
但是並不是說目前電梯排程只發展到這個層次。目前電梯的控制技術已經進入了電梯群控的時代。
隨著微機在電梯系統中的應用和人工智慧技術的發展,智慧群控技術得以迅速發展起來。
由此,電梯的群控方面陸續發展出了一批新方法,包括:基於專家系統的電梯群控方法、基於模糊邏輯的電梯群控方法、基於遺產演算法的電梯群控方法、基於勝景網路的電梯群控方法和基於模糊神經網路的電梯群控方法。
電梯問題的需求分析
4.1 電梯的初始狀態
本人設定的電梯的初始狀態,是對住宅樓的電梯的設定。
(1)建築共有21層,其中含有地下一層(地下一層為停車場)。
(2)建築內部設有兩部電梯,編號分別為A梯、B梯。
(3)電梯內部有23個按鈕,其中包括開門按鈕、關門按鈕和樓層按鈕,編號為-1,1,2,3,4……20。
(4)電梯外部含有兩個按鈕,即向上執行按鈕和向下執行按鈕。建築頂層與地下一層例外,建築頂層只設定有向下執行按鈕,地下一層只設定有向上執行按鈕。
(5)電梯開關門完成時間設定為1秒。電梯到達每層後上下人的時間設定為8秒。電梯從靜止開始執行到下一層的時間設定為2秒,而執行中透過一層的時間為1秒。
(6)在凌晨2:00——4:30之間,如若沒有請求訊號,A梯自動停在14層,B梯自動停在6層。
(7)當電梯下到-1層後,如果沒有請求訊號,電梯自動回到1層。
4.2 電梯基本功能
每一架電梯都有一個編號,以方便監控與維修。每一架電梯都有一實時監控器,負責監控電梯上下,向電梯升降盒傳送啟動、制動、加速、減速、開關電梯門的訊號。若電梯發生故障,還應向相應的電梯負責人傳送求救訊號。
4.3 電梯按鈕功能
電梯內部的樓層按鈕:電梯內部對應每一個樓層的按鈕成為樓層按鈕,即本章第一結提到的編號為 -1,1,2,3,4……20的按鈕。當乘客進入電梯後按下樓層按鈕,此按鈕顯示灰色,代表不可以用。
這樣就表示乘客將要去往此層,電梯將開往相應層。當電梯到達該層後,按鈕恢復可以使用狀態。
電梯內部開門按鈕:當電梯達到乘客想要去往的某樓層後,乘客需要準備離開電梯,當電梯停穩後,乘客可以按下開門按鈕,電梯門將開啟,讓使用者離開。
如若電梯到了乘客曾經按下的樓層,但是無乘客按開門按鈕,電梯將自動在停穩後1秒後自動開門。
電梯內部關門按鈕:當所有想要乘坐電梯的乘客都進入電梯以後,準備讓電梯開始執行的時候,乘客需要按下關門按鈕,讓電梯門關閉,使電梯進入執行狀態。設定電梯的自動關門時間為8秒。
電梯外部向上按鈕:此按鈕表示上樓請求,當按下此按鈕時,如果電梯到達按下此按鈕的樓層,且電梯執行方向是向上的,那麼電梯響將停下,並在電梯停穩之後自動開門,此請求被響應後,取消此請求訊號。
電梯外部向下按鈕:此按鈕表示下樓請求,當按下此按鈕時,如果電梯到達按下此按鈕的樓層,且電梯執行方向是向下的,那麼電梯響將停下,並在電梯停穩之後自動開門,此請求被響應後,取消此請求訊號。
結束語
你肯能意識到哪個演算法都不是一個最佳方案,只是它確實解決了一定情況的問題。
但是對一個優秀的程式設計師而言,研究各種演算法是無比快樂的。也許你下一次面試,就有關於排程演算法的問題。
本文轉自微信公眾號:純潔的微笑 作者:DS
原文連結:https://mp.weixin.qq.com/s/b8Qif0qYTOt3x781W6YFNQ
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31137683/viewspace-2213125/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 結對程式設計:電梯排程程式設計
- PairWork-電梯排程程式結對程式設計AI程式設計
- PairWork-電梯排程程式結對程式設計【附加題】AI程式設計
- 電梯排程演算法簡述演算法
- 演算法系列:電梯排程演算法
- 我猜我不是 “501” 程式設計師程式設計師
- 響應式程式設計入門:實現電梯排程模擬器程式設計
- 結對專案:電梯排程演算法的實現和測試演算法
- 快找個程式設計師做老公吧程式設計師
- 每個程式設計師都可能犯過的10個錯誤程式設計師
- 阿里某程式設計師吐槽:每天都想著離職,但又捨不得這份薪水阿里程式設計師
- 每個程式設計師都有一個框架夢程式設計師框架
- Linux程式設計:模擬程式排程演算法Linux程式設計演算法
- 每個程式設計師必知之SEO程式設計師
- 每一個程式設計師都是自學成才程式設計師
- 程式設計師的成長階梯程式設計師
- 單例模式 | 程式設計師都想要探索的 Javascript 設計模單例模式程式設計師JavaScript
- 養生吧,程式設計師!程式設計師
- 創業吧,程式設計師創業程式設計師
- 程式排程演算法Linux程式排程演算法演算法Linux
- 我們去吃程式設計師味兒的饅頭吧!程式設計師
- 這些哭笑不得的情景,每個程式設計師都可能面對程式設計師
- 我這個程式設計師 (轉)程式設計師
- 我如何轉行為程式設計師:心態支撐著我程式設計師
- 我為什麼要設計自己的流量排程演算法?演算法
- 我們公司給新人的README,值得每個程式設計師一讀程式設計師
- 每個新手程式設計師必看的 SQL 指南程式設計師SQL
- 每個程式設計師應該知道12件事程式設計師
- 創業對程式設計師意味著什麼創業程式設計師
- 每個程式設計師都應該讀《Unix程式設計藝術》程式設計師
- 每個程式設計師都必須遵守的程式設計原則程式設計師
- 程式設計師創業:我應該怎樣活著?程式設計師創業
- 國外程式設計師推薦:每個程式設計師都應讀的書程式設計師
- 每個程式設計師和設計師必做的10項運動程式設計師
- 每個程式設計師應該知道的12個API程式設計師API
- 程式設計師兄弟:我們們一起創業吧!程式設計師創業
- 每個程式設計師都應該成為架構師程式設計師架構
- 國外程式設計師推薦:每個程式設計師都應該讀的非程式設計書程式設計師