---恢復內容開始---
背景
試想一下，我們正在構建乙個高大的辦公樓，它有大約電梯配置如下：大廈有21
層， 4
部電梯，很多乘客使用這些電梯的日常（旅客重量：平均
70公斤最大
120公斤，最小
45公斤）。其他常量資料：電梯速度，開/
關門時間，乘客的時間要在
/走出電梯。
電梯名稱
停靠層數
乘客限制
重量限制
1
所有樓層
10
800 kg
2
所有樓層
10
800 kg
3
所有樓層
20
1600 kg
4
所有樓層
20
2000 kg
有關電梯排程的設計思路：
電梯分為內外兩部分，所以這設計時，將整個排程分為兩部分：外部排程和內部排程。
外部排程所要進行的操作是，在樓層中有人請求電梯後，尋找到合適的電梯（也就是最先到達那一層的電梯）。例如，在第八層有人要上樓，在按下按鈕請求電梯後，外部演算法會找到最快到達的電梯，並將資訊傳遞給內部的電梯控制。之後電梯會到達相應的樓層，也就是第八層。
現在說明一下外部排程演算法的設計思路，當在電梯外部按下下樓層或上樓層鍵時，相當於同時對四部電梯發出請求。演算法要做的是找出最近最快能到達的一部電梯，然後進行響應，到達所需樓層。具體演算法是，先對四部電梯進行判斷，優先選擇當前沒有執行的，或者執行方向與按鈕方向相同的並且會經過這一樓層的電梯。如果存在一部，則呼叫這部，若存在多部，就選擇在滿足上述條件下與發出請求所處樓層最接近的一部，若沒有這類電梯即四部電梯都在執行中且與電梯執行方向與按鈕方向相反，這時就將這個請求放入等待佇列中，等待資源。舉例說明就是，假如在15層有人請求上樓，而四部電梯都在向下執行，這時就將這個請求放入佇列中，當有電梯停靠時，便排程這部電梯，釋放請求。另外，要注意的是在15層有人請求上樓的之後8層也發出上樓請求，這時如果三部電梯依然向下未停靠，而被排程的那部則已經向上，這就要判斷這部電梯是否已經過8層，若沒有則電梯先在8層停，再上15層，若已經過，則將請求再次放入佇列，再次等待。
內部排程是根據電梯內部人所發出的請求排程電梯，當電梯內部按下乙個樓層按鈕的時候，當電梯停止或者同向可以到達的時候，系統把這個樓層設為停靠層，放入停靠的鍊錶中，將所有請求按到達先後順序拍好。當不符合條件時，將請求放入「將要執行佇列」，排好位置，等到電梯到達終點後再執行。如電梯上到6樓，而目標是8樓，這個時候按下2樓，那麼這個電梯就是先上到8樓然後再下去2樓。再如，先有人請求10樓，又有人請求9樓，這時需要將請求排序。
最後一點就是人數及體重的限制了，對每個電梯設定乙個特定的變數進行統計，然後比較，在將資料傳入內部排程之中，進行電梯的操控。例如，如果電梯內的人數或者重量已將超過限制人數以及重量限制，那麼電梯將不會在有人按下按鈕的那一樓層停留。如果某一層內人數較多超過人數限制，電梯將自動報警，發出已超載的提示。
這是最初的設計思路，考慮的問題可能並不全面，在**的實現過程中可能會進行諸多修改。
時間
2014.3.7
2014.3.8
2014.3.9
李帥
16:20-17:30
18:45-19:20
網上查閱資料，總結思考 比較了幾種演算法
08:37-10:20我們兩人在學院樓107自習室進行了商討，對電梯排程演算法有了初步的設計，並對各種情況進行了設想以及討論。
10:30—11:10 李帥同志整理了一下文件，我與坐在後排的汪洋同志交流了心得，11:15-11:54 我們三個人坐在一起對我們各兩組各自的想法以及演算法進行了交流。
15:57-16:15
我們兩人對設計映象最後敲定，並撰寫部落格。
張碩
19:30-20:37
上網查閱資料，檢視了一些前人寫的演算法。
---恢復內容結束---
電梯排程 結對專案開發
本週六下午我和小胡進一步商量了一下電梯的排程問題，為保證程式設計能貼近生活實際，還特意對學校的電梯做了實地考察。並對之前的設計進行了適當的修改。2014.3.8 20 17 20 48 首先要定義兩個類。class elevator 屬性 承載的最大重量 承載最大數量 所在層數和所有層數 區分上公升...
結對專案開發電梯排程
一.隊員 崔鵬勃 孔維春 二.背景 試想一下，石家莊鐵道大學基礎教學樓的電梯配置如下 大廈有1 層，4部電梯，很多乘客使用這些電梯的日常 旅客重量 平均70公斤最大120公斤，最小45公斤 其他常量資料 電梯速度，開 關門時間，乘客的時間要在 走出電梯。可以對這些合理的假設。三.高峰時期的人數統計 ...
結對專案實訓 電梯排程
關於電梯排程設計的初步想法 楊波 崔海營 試想一下，我們正在構建一座高大的辦公樓，它有電梯的大約配置如下 大廈有21層，四部電梯，很多乘客乘坐這些電梯，乘客的資料為 平均數量為70公斤，最重的人120公斤，最輕的人有45公斤。其他的電梯資料可以自主設定。該大樓21層分為0,1，2.20.地板0為地下...