電梯調度演算法：LOOK、RSR 與目的地調度

電梯等待時間在很大程度上取決於用於將電梯分配給廳叫 (hall call) 的調度演算法。較簡單的演算法（如 LOOK）在典型的辦公大樓中，其表現往往優於或等同於更複雜的方案，例如 Otis 的 RSR 或目的地調度。

單部電梯：SCAN 與 LOOK

LOOK 演算法是 SCAN 的變體，作為電梯移動的基準預期。它從大廳開始，僅向上移動到最高待處理請求的高度，然後反轉並處理向下請求，沿途接送乘客。這與原始的 SCAN（或稱「電梯」）專利不同，後者在反轉前總是會移動到頂層。

多部電梯與基本協調

在有多部電梯的情況下，中央調度器會將每個廳叫分配給最近的閒置電梯。這種「最近電梯」規則忽略了電梯內已有的乘客數量，也忽略了電梯是在朝向或背離呼叫者移動，這在最近的電梯已滿或正朝錯誤方向移動時，可能會導致次優的分配。

衡量效能：等待時間分佈

工程師使用等待時間的分位數 (percentiles) 而非平均值來評估演算法，因為乘客對長時間等待記憶深刻。p50 為 1 分鐘意味著一半的行程等待時間在 1 分鐘或以下；p90 為 2 分鐘意味著 90% 的行程等待時間在 2 分鐘或以下。本文的直方圖顯示了在各種流量下的這些指標——例如，在每分鐘 14 次請求時，LOOK 演算法的 p90 約為 2 分鐘，而在每分鐘 8 次請求時，p90 會有所改善。

早高峰與流量模式

在尖峰時段，流量具有高度的方向性。在大型企業辦公大樓中，早上的流量以從大廳到高層的行程為主，晚上的流量則相反，而午餐時間則是兩個方向混合。這種不對稱性使得早高峰成為等待時間統計中最糟糕的情況，因為電梯大部分的行程都花在服務單向流量上。

更聰明的電梯：Otis 的 RSR

RSR 在基本的 ETA-to-pickup（接送預計到達時間）評分中加入了細微的懲罰與獎勵機制：

  • ETA to pickup – 電梯到達廳叫位置所需的時間。
  • Onboard load penalty – 隨當前乘客數量增加而增加。
  • Same-direction anti-bunching penalty – 避免將電梯派往另一個正朝相同方向移動的電梯已瞄準的樓層。
  • Direction-match bonus – 獎勵已經在所需方向移動的電梯。
  • Idle-nearby bonus – 偏好在呼叫者兩層樓範圍內的閒置電梯。
  • Low-load bonus – 偏好乘客較少的電梯。 系統每五秒重新計算一次這些評分，這使得最初分配給電梯 A 的乘客，如果發生延遲，可以被重新導向至電梯 B。

LOOK vs RSR：基準測試結果

本文中的模擬結果比較了 LOOK 與 RSR 在不同流量下的表現：

  • 在每分鐘 14 次請求時，LOOK 與 RSR 的等待時間 < 30s 與 < 90s 的百分比相當。
  • 在每分鐘 8 次請求時，RSR 在等待時間 < 30s 與 < 90s 的數據上略勝一籌。
  • 隨著流量增加，LOOK 開始超越 RSR，因為當電梯持續滿載並在每一層停靠時，額外的 RSR 規則提供的效益微乎其微。
  • 在每梯電梯數量較少的建築中，LOOK 也往往優於 RSR，因為簡單性降低了開銷。 這些發現呼應了「簡單往往勝過複雜」【@heironimus】的評論。

目的地調度 (Destination Dispatch)：權衡

目的地調度取代了廳叫按鈕，改用樓層觸控裝置，告訴乘客應該搭乘哪部特定的電梯。雖然這讓調度器擁有了完整的目的地資訊，但也引入了僵化性：一旦電梯被分配，即使情況發生變化，乘客也無法更換到另一部電梯。本文指出，這種靈活性的缺失通常使得目的地調度在等待時間上不如傳統的上下按鈕，除非是在每梯擁有八部或更多電梯的超高層建築中。 這種反直覺的結果源於五秒一次的重新優化循環：「觸控裝置強制執行了僵化性，你必須搭乘分配的電梯。在你呼叫電梯 30 秒後的世界狀態可能非常不同，但系統無法適應」【@JoshTriplett】。 然而，當流量由前往同一樓層的大型團體組成時，目的地調度可以表現出色，因為它可以將這些乘客進行批次處理【@omoikane】。

完整模擬洞察

互動式模擬器允許使用者改變樓層數、電梯數量和請求流量。調整這些參數可以顯示 LOOK、RSR 與目的地調度之間的平衡如何轉移——例如，在 8 層樓、4 部電梯、每分鐘 18 次請求的情況下，模擬器會顯示每個演算法的等待時間百分比。這強化了一個觀點：最佳演算法取決於特定建築的流量模式與電梯容量。

人為因素與實際考量

現實世界的電梯效能受到的影響不僅僅是純粹的調度邏輯：

  • 使用者行為：許多乘客會同時按下上行與下行按鈕，誤以為這會加快到達速度，但實際上這會導致不必要的停靠與混亂【@olex】。
  • 容量感測：如果沒有可靠的滿載檢測器，電梯即使在擠滿的情況下也可能在每一層停靠，造成人群在滿載電梯外等待的挫折場面【@vova_hn2】。
  • 磨損：為了減少等待時間而進行激進的重新定位會增加機械磨損，這顯示了乘客延遲與維護成本之間的權衡【@taftster】。
  • 心理等待：在等待期間提供消遣或感知到的進度可以提高滿意度，即使實際等待時間保持不變【@psadri】。
  • 預取策略 (Prefetching strategies)：某些設施（如 Apple Park）會在收到呼叫後將閒置電梯移向地面層，以減少未來的反應時間【@ladberg】。 這些因素說明了為什麼模擬中的「最佳」演算法在實際應用中，乘客感受到的最佳演算法可能完全不同。

Sources