前言
易排平臺發佈之初，完全基於OptaPlanner 官方的一些示例進行開發。官網發佈的衆多示例呈現了各行各業各種場景下，通過OptaPlanner作爲規劃引擎的運籌優化場景。社區項目團隊除了對引擎程序進行了完整且嚴格的測試外，還對所提供的示例程序進行了穩妥的測試。因此，這些示例是我們學習的重要資料。
在構思易排平臺時，我基於當時參與過的若干行業的APS項目經歷，擬出一個同時兼容流程製造與離散製造場景下的排程需求清單，並選擇其中較爲常見、典型的幾個需求作爲平臺的內置需求。目標是構建一個具有APS最小功能子集的基礎平臺，以便最大程度提高各個行業、場景的兼容性。而一些行業相關性較大、特異性較強的需求，則計劃在具體項目實施過程中，以特殊功能的形式提供。以防平臺因特異性功能過多而降低了兼容性和適用範圍。
而在與客戶的具體項目合作過程中，確確實實出現了一些我之前未遇到過的需求，有涉及業務規則的，有優化目標相關的，更有對引擎核心模型產生具大挑戰，甚至可以說對原來的規劃模型產生顛覆的需求。甚至一度讓我懷疑OptaPlanner能否實現這些，從業務角度看上去再也正常不過的需求。此過程中各種模型修改，反覆建立、推翻、再建立修改新方案的過程，令我這個設計者、開發者心情，用跌宕起伏來形容並不爲過。儘管如此，在這段時間的反覆構思、實驗過程中，對OptaPlanner有更深一層的認識。
目前易排平臺的規劃核心已有一個較大更新，無論在性能與兼容性，適用範圍上均有了質的飛躍，一些以往無法實現的需求和特性，也已提供完善的解決方案。本文作爲本次平臺規劃核心升級的一個紀念，以平臺其一個需求的設計方案作爲案例，分享一下該規劃模型的設計。
注意：本文介紹到的方案是上一版本引擎核心中的一個模式與設計方案。本次升級過程中，這個方案已經進行了更有效的升級，基於技術保密，暫時未能公開最新設計方案。該方案雖然仍有一定的不足，但對於一些複雜度不高，特異性需求不多的場景，還是具有較高參考價值的。平臺核心的設計，遵循更新一版、公開前一版的原則進行技術分享。若下一次引擎核心有重大升級，將會公佈當前的設計方案，敬請期待。下面進入正題內容。
需求案例
在我們設計APS程序時，以下需求是無法逃避的。
-
設備的時間維度，有工作時間、休息時間與維保時間之分；在常見的APS系統中，設備會定義爲資源，通過資源日曆來定義上述時間。
-
當一個任務分配到一個設備時，需要自動垮過這些休息時間與維保時間。
-
有些任務有可能存在後處理時間，即一個工序完成後，需要靜置一定的時間後，後工序才能開始，但這個靜置時間並不佔用資源。例如噴漆工序完成後，需要靜置一段時間待乾燥，這個等待時間我們稱爲靜置時間。
例如，有以下時間和任務加工場景，如以下 圖1
圖1
時間軸
對於工作時間，假設如上圖1展示了一個月的時間軸，一個月的3號到25號爲工作日，其它時間爲非工作時間，例如公衆假期、設備維保計劃時間等。在工作時間中，有3個週末並不工作，分別是6、7號，13、14號，以及20、21號。
工單與任務
一個工單包含4個任務，其長度與靜置時間分別如下：
-
任務1：時長3天，靜置時長1天；
-
任務2：時長6天，靜置時長1天；
-
任務3：時長2天，靜置時長0天（無需靜置）；
-
任務4：時長4天，靜置時長3天。
那麼，若我們把這4個任務分配到這個時間段內，那麼，它們的分佈時間應該如下：
-
任務1：從3號開始，5號完成加工，6號爲靜置時間(靜置時間不佔用資源，因此週末也可以靜置)；
-
任務2：從8號開始，跨越一個週末(13、14號)，15號完成加工，16號爲靜置時間；
-
任務3：從17號開始，雖然任務2在16號已完成加工，但需要靜置1天，作爲後置工序的任務3才能開始，因此需要17號才能開始，於18號完成，不需靜置；
-
任務4：19號開始，跨越一個週末(20、21號)，24號完成加工，靜置3天，並在27號完成，雖然26、27號是非工作時間（機臺維保，或其它原因停工），但不影響靜置處理。
上述計劃安排，從專業排產師的角度看，並不複雜。但若通過項目任務調試模型(PJS模型)來實現，則會面臨非常多的細節問題需要解決。上述問題是對實際場景的一個抽象概念；實際過程中，同一工單中的各個工序所衍生出來的任務，需要使用不同的資源來執行，使用不同的資源(例如：設備、工位)又會遇到更多複雜的問題待解決，例如：
-
資源效率差異 - 同一任務使用不同的資源加工時，其效率不同，造成加工時長不同；
-
資源工作時間差異 - 不同資源的工作時間不同，例如：不同機臺有不同的維保計劃，不同的班次安排等；
-
存在多個可選資源 - 同一任務可以從多個可用資源中選擇其中一個進行加工(根據優化策略進行擇優分配)。
-
......
當考慮了上述實際場景中的複雜性時，即便再專業、經驗再豐富的排產師，需要排出一個合理、高效的生產計劃，也是一項目極具挑戰性的工作。此時，一個好的APS引擎即可體現價值。
設計方案
需求
其實該需求被簡化後，變成了“任務如何跨越資源的休息時間”的問題。上述需求中，其中一個重點是：當一個任務分配到一個資源後(此時該任務的時長已確定)，如何實現任務的加工週期內忽略休息時段？即任務跨越該休息時段，將加工時間延長分配到休息時段後的工作時間上去。在該方案的的設計思路中，我着眼於對時間段的簡化。因此，方案如下：
第一：構建一個新的時間索引序列，在新的時間索引中，將各資源公共的休息時間（如週末、午休）等時間忽略。即剔除出資源索引序列 (如下圖2)
圖2 - 用工作時間創建新的時間索引序列
第二：找出所有資源中最小的連續工作時間長度，假設該長度爲A，將加工時長大於A的任務進行分割，形成多個子任務，各個子任務形成前後工序關係；令所有任務(包括不分割的原始任務及分割後的子任務)的時長均小於等於A（如下下圖3）
圖3 - 分割過長任務
第三：添加一個硬約束，確保從第二步中分割出來的各個子任務分配到同一資源上（如下圖4）。
圖4 - 通過約束或選擇過濾器，確保同一個任務的子任務分配到同一資源上
第四：引擎完成規劃並輸出結果後，將所獲結果，按照第二步分割任務的映射關係，將子任務合併回原始任務。將時間索引重新映射回時間戳，從而得到各個任務的具體加工時間.
該方案的優缺點
優點：
-
將時間軸上的公共休息時間過濾掉，從而實現引擎在推導任務時，無需考慮不連續時間段之間的接續問題，從時間索引上看，是一個簡單的、連續的時間軸，起到簡化時間軸作用。
-
將時間戳重新映射成以0爲基準的時間索引序列，在調試過程中，可以極大地簡化時間推導運算，從而令程序更容易調試。
-
實現了統一簡化的時間索引後，引擎在運算過程中，關於時間的運算量大幅度減少，提高了運算性能。
缺點
-
該過程需要對任務及資源的處理步驟過多，需要使大量用映射表來記錄資源的時間戳與時間索引關係、原始任務與子任務等衆多關係，操作過於繁複。
-
對於分割出來的子任務需要額外添加約束來確保分配到相同資源，使用引擎多了一道非業務相關的約束，加大引擎運算負擔。此外，要實現此約束也需大費周章。
-
將任務分割成子任務後，實際上導入到引擎進行規劃運算的任務數量增多，令問題規模增大，導致性能下降。
-
對於有靜置時間需求的任務，該方案在部分情況下處理並不合理（這裏留一個問題給大家思考，哪些情況下靜置時間的處理會出現不合理？）
新的方案
目前我們的平臺上的模型核心已使用新的模型方案，能有效解決上述問題，目前仍有部分需求的邏輯，需要與新的方案整合；新模型核心的測試環境將在近日發佈。歡迎大家試用，並提出寶貴意見！我們將不斷對規劃核心進行優化，當出現較大模型核心變更時，我們會將上一代的方案分享出來，供各位研究、開發APS的達人學習討論。在優化引擎核心的過程中，深深感受到OptaPlanner作者 Geoffrey De Smet 在社區討論中，關於上述問題的回覆意見中提到 - the devil is in the details （魔鬼在細節中）
祝大家戰勝魔鬼，開發出優秀的模型！
同時也邀請大家使用我們的【易排通用智能規劃平臺】，它基於OptaPlanner對APS的一些常用規劃邏輯進行封裝，大家只需要管理、維護好自己系統(使用MES、MOM、ERP中的計劃模塊)中的工單數據，即可快速地實現一個APS模塊。後續我們還會添加【VRP - 車輛路徑規劃】和【在線調度】模塊，敬請期待。可以通過以下鏈接查看更多該平臺的使用方法。
易排(EasyPlan)通用智能規劃平臺 Q&A