OptaPlanner創辦人Geoffrey De Smet及其團隊，在Red Hat 技術峯會上主題會場上，演示了一個通過OptaPlanner實現實時規劃與調度的示例。Geoffrey及其團隊專門爲此分三篇博文描述了該程序。該程序及其相關博文是OptaPlanner在VRP領域極之經典之作。本系列也分三篇對博文進行翻譯，以饗各位ORer, APSer和Planner.
目前本人正在研究該程序，未來將會進一步對該程序作更深入的分析，並形成博文，分享其中奧妙。
【以下爲譯文】
今年，我和我的團隊在Red Hat技術峯會上作了主旨演講。在7000人面前，我們演示了一個實時調度程序，該程序可以實現對現場觀衆通過手機App的輸入進行實時反應。在過去兩個月裏，我們的團隊和其它中間件的團隊一起協同，在Burr Sutter的出色指導下，創建了這個實時調度程序。這個程序集成了多種技術，例如Android/iPhone的加速感應器，還有OpenShift / Kubernetes, Quarkus, KNative, TensorFlow, Kafka/Strimzi, Camel, Node.js, Godot, Infinispan, Drools等，當然少不了主角OptaPlanner.
我們寫了一個模擬器，模擬一個典型的地板生產場景，場景中涉及裝配線上的機械。當我第一次向我和妻子展示這個程序時，引發了一個有趣的對話:
"看，親愛的，這是在主旨演講上的示例程序，我們過去兩週時間一直在努力（構建它）"
"看起來像小遊戲，那些是Mario和Luigi在到處跑嗎？"
"注意，（這些是機器維修師）它演示了OptaPlanner是如何優化他們的行走時間，使他們可以花更多的時候在維修機械上。"
"你打算就把這玩藝展示給7000多個商務客呀？"
"當然，展示將會非常精彩."
程序運行的效率如下：
現有10臺機器（編號從A到J）運行過程中會出現磨損，並通過傳感器檢查發現磨損情況。（現場觀衆安裝和我們的APP）在現場觀衆的幫忙下，我們通過獲取他們手機上的加速感應器的數據，來模擬傳感器。正所謂當事物變得越搖搖欲墜時，它就變更脆弱。當觀衆拼命搖晃，或用手機做出其它晃動的動作時，程序中對應的機器就會收到損壞信息。（由於人數衆多），現場的每一部分觀衆通過晃動手機，就會向對應的一臺機器發送損害信息爲，對應機器的健康值就會減少。如果有一臺機器的健康值降到0，那就表示這臺機器崩潰了。
此時，那些受損的機器在它們崩潰之前安排維修，這就是OptaPlanner用武之地了。程序中有2到3名機械師來修復這些受損的機器，與機械師們在機器之間穿梭，及在修復機器的同時，所有機器都在持續地降低健康值（現場觀衆正在持續拼命地晃動他們的手機）。在安排機器時工作時，決定各個機器的維修次序是很困難的，因爲損壞無時無刻地發生着。幸虧，OptaPlanner爲幫我們調度這些機械師，它會實時地對機臺健康的變化作出反映，如視頻所示：
（下面討論一下規劃程序的具體設計）
這個規劃問題的挑戰
規劃目標只有一個：不能讓做任意一個機臺的健康值掉到0%。這看起來是一個簡單的約束，但事實上它存在兩個衝突的約束：
- 優先修復健康值最低的機器，因爲最低健康值的機器，其崩潰的風險最高。
- 通過讓機械師走最短的穿梭路徑，讓機械師儘量快的時間修復就近的機器 。原因如下：
- 機器時需要進行修復機器之外，還需要在機器之間到處到動，通過減少他們的穿梭時間，提高他們的生產力。
- 若只考慮最短路徑一個約束，這就是一個TSP問題（旅行商問題）。
上述兩個約束存在競爭的，它們各自會偏向輸出以下不同的解決方案：
這兩種約束對完成時間的影響差別不太明顯，即如何影響機械師一次修復所有有故障機器的所需時間。維修的時間越長，將會降低生產力：
因此，我們最終需要權衡這兩種約束。我們通過對每臺損壞的機器評定懲罰性分數，將損壞量乘以持續時間，直到該機器被修復爲止。因此，OptaPlanner規劃出來的方案中，將會儘可能地避免讓機器的損壞程度增大，或儘可能將機器處於損壞狀態的時間減少。
這只是一個車輛路線規劃問題(VRP)
在運籌學的學術界，此類問題也被稱爲車輛路線規則問題（Vehicle Routing Problem - VRP), 在該類問題中，我們需要一些車輛（例如貨車）發送到多個目的地。
通過上圖可以看出，這些只是存在一些約束差別的相同問題。
目前OptaPlanner確實擅長於求解車輛路線規劃問題的優化：通過對整個車輛運行時間達到15%甚至更多的時間減少，我們每年爲一些客戶節省了數億美元。同時也大大地減少了車輛的能源消耗，從而減少了碳排放，因此對環保也相當有益。
瞭解更多關於OptaPlanner在VRP問題的優化，或看一下Jiri(OptaPlanner項目另一位成員)在VRP問題的最新Demo，演示視頻：
（機械師調度程序中)現實的挑戰
首先，實現這種車輛路線規劃的變種問題其實並不複雜，但要讓程序的交互與演示運行得足夠流暢，我們面臨着更大的挑戰。畢竟，我們不能冒着在演示期間，在觀衆與老闆，包括我們的CEO Jim Whitehurst 面前程序崩潰的險。
如果想自己調度這個程序，可以從這裏下載並根據readme的介紹進行調度。
End.
創作不易，歡迎轉載，請標明出處。
本系列文章在公衆號不定時連載，請關注公衆號（讓APS成爲可能）及時接收,二維碼：
如需瞭解更多關於OptaPlanner的應用，請發電郵致：[email protected]
或到討論組發表你的意見：https://groups.google.com/forum/#!forum/optaplanner-cn
若有需要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人日常工作繁忙，通過微信,QQ等工具可能無法深入溝通，較複雜的問題，建議以郵件或討論組方式提出。(討論組屬於google郵件列表，國內網絡可能較難訪問，需自行解決)