目錄實時電梯排程演算法
群控電梯排程演算法
參考我們作業的電梯
當電梯們不再相同
結語
"每個程式設計師看見電梯，都會想電梯的排程演算法怎麼這麼蠢"先來先服務（fcfs-first come first serve）演算法，是一種隨即服務演算法，它不僅僅沒有對尋找樓層進行優化，也沒有實時性的特徵，它是一種最簡單的電梯排程演算法。
它根據乘客請求乘坐電梯的先後次序進行排程。此演算法的優點是公平、簡單，且每個乘客的請求都能依次地得到處理，不會出現某一乘客的請求長期得不到滿足的情況。
這種方法在載荷較輕鬆的環境下，效能尚可接受，但是在載荷較大的情況下，這種演算法的效能就會嚴重下降，甚至惡化。
人們之所以研究這種在載荷較大的情況下幾乎不可用的演算法，有兩個原因：
任何排程演算法在請求佇列長度為1時，請求速率極低或相鄰請求的間隔為無窮大時使用先來先服務演算法既對排程效率不會產生影響，而且實現這種演算法極其簡單。
先來先服務演算法可以作為衡量其他演算法的標準。
最短尋找樓層時間優先（sstf-shortest seek time first）演算法，它注重電梯尋找樓層的優化。
最短尋找樓層時間優先演算法選擇下乙個服務物件的原則是最短尋找樓層的時間。
這樣請求佇列中距當前能夠最先到達的樓層的請求訊號就是下乙個服務物件。
在重載荷的情況下，最短尋找樓層時間優先演算法的平均響應時間較短，但響應時間的方差較大，原因是佇列中的某些請求可能長時間得不到響應，出現所謂的「餓死」現象。
掃瞄演算法（scan） 是一種按照樓層順序依次服務請求，它讓電梯在最底層和最頂層之間連續往返執行，在執行過程中響應處在於電梯執行方向相同的各樓層上的請求。
它進行尋找樓層的優化，效率比較高，但它是乙個非實時演算法。掃瞄演算法較好地解決了電梯移動的問題，在這個演算法中，每個電梯響應乘客請求使乘客獲得服務的次序是由其發出請求的乘客的位置與當前電梯位置之間的距離來決定的。
所有的與電梯執行方向相同的乘客的請求在一次電向上執行或向下執行的過程中完成，免去了電梯頻繁的來回移動。
掃瞄演算法的平均響應時間比最短尋找樓層時間優先演算法長，但是響應時間方差比最短尋找樓層時間優先演算法小，從統計學角度來講，掃瞄演算法要比最短尋找樓層時間優先演算法穩定。
look 演算法是掃瞄演算法（scan）的一種改進。對look演算法而言，電梯同樣在最底層和最頂層之間執行。
但當 look 演算法發現電梯所移動的方向上不再有請求時立即改變執行方向，而掃瞄演算法則需要移動到最底層或者最頂層時才改變執行方向。
satf（shortest access time first）演算法與 sstf 演算法的思想類似，唯一的區別就是 satf 演算法將 sstf 演算法中的尋找樓層時間改成了訪問時間。
這是因為電梯技術發展到今天，尋找樓層的時間已經有了很大地改進，但是電梯的執行當中等待乘客上梯時間卻不是人為可以控制。
satf 演算法考慮到了電梯執行過程中乘客上梯時間的影響。
此演算法主要特點是把請求分為主請求和可稍帶請求。在執行主請求時把所有能捎帶的親求都帶上。
怎麼確定哪個是主請求就仁者見仁了。
最早截止期優先（edf-earliest deadline first）排程演算法是最簡單的實時電梯排程演算法，它的缺點就是造成電梯任意地尋找樓層，導致極低的電梯吞吐率。
它與 fcfs 排程演算法類似，edf 演算法是電梯實時排程演算法中最簡單的排程演算法。
它響應請求佇列中時限最早的請求，是其它實時電梯排程演算法效能衡量的基準和特例。
scan-edf 演算法是 scan 演算法和 edf 演算法相結合的產物。scan-edf 演算法先按照 edf 演算法選擇請求列隊中哪乙個是下乙個服務物件，而對於具有相同時限的請求，則按照 scan 演算法服務每乙個請求。它的效率取決於有相同 deadline 的數目，因而效率是有限的。
pi（priority inversion）演算法將請求佇列中的請求分成兩個優先順序，它首先保證高優先順序佇列中的請求得到及時響應，再搞優先順序隊列為空的情況下在相應地優先順序佇列中的請求。
fd-scan（feasible deadline scan）演算法首先從請求佇列中找出時限最早、從當前位置開始移動又可以買足其時限要求的請求，作為下一次 scan 的方向。
並在電梯所在樓層向該請求訊號執行的過程中響應處在與電梯執行方向相同且電梯可以經過的請求訊號。
這種演算法忽略了用 scan 演算法相應其它請求的開銷，因此並不能確保服務物件時限最終得到滿足。
這是最簡單的排程演算法，其根據轎廂所在樓層與請求所在地的相對位置按一定規定計算出來該請求的適應值fs作為評價函式，評價出來最合適的電梯來服務該請求。
fs到底怎樣計算就是個「玄學」的事情了。你可以簡單到直接用樓層差，也可以考慮到電梯有上下行的不同把線性的樓層看作環形——事實上後者更為合理。
該方法的思路是把發出請求時所反映的客運需要量的微小變化看成是對整個電梯群需要量的變化加以控制。它根據請求和電梯數量等狀態向量，**候梯時間，把**的候梯時間最大值作為評定函式，用該值最小的電梯來服務請求。
此方法結合了最短距離排程和負載均衡。
略，可參考鏈結。
群控電梯排程總體來說就是運用函式算一算每個電梯和每個請求的合適程度，那麼這個函式怎麼設計就可以開腦洞了，萬一可以用機器學習擬合乙個……
電梯群控系統各種策略的分析比較
我猜，每個程式設計師對著電梯都想過排程演算法吧！
這是buaa的oo課程的三次作業，不那麼**地模擬了目的選層電梯的排程。
第一次作業是單電梯不限人數；
第二次作業是多電梯限制承載人數；
第三次作業實現了動態增加電梯、電梯分種類（執行速度、停靠樓層不同）執行。
這裡指的是前兩次作業，每個電梯能幹的事情都是一致的。
其實各種排程策略是真真正正的各有優劣。自己寫的測評機順帶監測了大概7套程式（互測裡）的同種輸入的執行時間……總體來說，平均下來只有1個程式明顯慢於其他程式，其他則是不分伯仲；而每個程式都有第乙個執行結束的時候——即便是那個平均下來最慢的程式也會有幾次戰勝其他程式的時候。
如果真的要套用前述的各種策略的話，我的應該算是als。
第一次作業單電梯，主要談談設定主請求。第乙個到的請求必然是主請求，但等待佇列不是空的時候，就要找一下哪個請求可以在過程中捎帶更多人了——譬如電梯決定向下執行時，會從頂層向下找第乙個要下樓的人作為主請求。
第二次作業對於每個電梯自己來說，其行為和第一作業一致。但是增加了乙個分派請求的**控制器，把請求分給每個電梯。**排程器的策略大概是前面說的atm。但事後想一想，反正請求產生是隨機的……如果只在請求初次進入時候來分派此請求，而不是在每次有請求進入時候重新分派所有請求，那運用atm策略和直接隨機分配或是順序分配的話，電梯的效能變化應該不會很大。
想都可以想，但想要保住正確性的分，還是不浪了……
單就效能來看，兩者真的不分伯仲，寫好了的話強測都在98以上。但自由競爭似乎要注意一下撲空了時候的情況，分派則要好好想一想怎麼平衡負載。
其實，乙個人能不能乘坐一種電梯的判斷很容易。所以個人把本次作業和前幾次的最大差異設定為如何對請求進行劃分——即如何處理換乘問題。
當乙個請求到達時，便對其進行劃分，分為可以被單一電梯服務的多個請求。
請求進入時不劃分，通過電梯把請求者送到目的樓層或是離目的樓層最近的樓層，請求者走出電梯時候判斷是否到達目的地，不是的話進行新一輪請求。
也就是請求在被電梯服務過一次後再考慮要不要劃分。其實有點像前述的靜態劃分？本人不是這樣設計的，在此只留乙個思路。
每種策略都有勝過其他策略的時候，也都有自己犯傻的時候。所以實際上本單元作業不用太過在意使用哪種策略，保持程式的簡潔與正確更加重要（此時某人內心在滴血）。就像現實生活中的電梯，你不能為了響應請求最快而不考慮安全性。
當然，最後我還是想吐槽——即便知道這是為了訓練而迫不得已的設定——
「時至今日，我們仍沒有搞明白，為啥從2層上到3層，不能爬」
小型電梯尺寸 小型電梯尺寸與電梯的分類
別墅安裝小型電梯已經普及，業主可根據家中的大小確定小型電梯的尺寸。小型電梯的尺寸再確定之後，基本上就確定了小型電梯的分類。那就來向大家介紹一下小型電梯尺寸與電梯分類。1.選擇家用電梯時，必須要檢視電梯的配置以及尺寸等。測量人員根據具體的情況確定挑選電梯的型別。2.再安裝家用小型電梯時，必須要提前預留...
電梯的啟示
轉眼間已經工作大半年了，今天這個日子，寫一篇隨筆，算是對逝去的日子做乙個懷念，對未來的日子做乙個呼喚。我是去年7月份去a公司上班的，10月28日被派去了b公司工作。這裡只想對b公司的4個月的生活中很有懷念意義的爬樓梯事件留下自己的切身感悟。這個軟體園有23層，我們就在上班，也就是大家常常開玩笑時候調...
詭異的電梯
時間限制 1000 ms 記憶體限制 65535 kb 難度 3 描述 新的宿舍樓有 n 1 n 100000 層and m 1 m 100000 個學生.在新的宿舍樓裡 為了節約學生的時間也為了鼓勵學生鍛鍊身體 所以規定該宿舍樓裡的電梯在相鄰的兩層之間是不會連續停下 即，如果在第2層停下就不能在第...