OptaPlanner 發展方向與問題

​  最近一段時間,因爲忙於【易排(EasyPlan)規劃平臺】的設計與開發工作,平臺的一些功能設計,需要對OptaPlanner的各種特性作更深入的研究與應用。慢慢發現,OptaPlanner進入8.X版本之後,變化還是挺大的。對於我個人的項目、平臺及諮詢工作,這些變化中,大部分還是幫助很大的,但也發現一些不太合理的地方。這兩天終於完成了平臺的“規劃評分分析功能”,就擠點時間出來,記錄一下OptaPlanner 8.X的這些變化吧。

以下是我應用OptaPlanner過程中歸納的一些關於該軟件的發展方向,及此過程中遇到的一些問題。

實時規劃接口優化

  實時規劃是OptaPlanner的一重大特有特性,目前在其它求解器還沒發現類似的功能。就是考慮到當求解一個問題的時間過長時(例如數據量大、約束複雜)有可能在求解的過程中,數據已經發生變化,此時,實時規劃就可以在未完成整份數據的完全求解,即可通過實時規劃的API對數據進行更新,OptaPlanner會在已完成了部分求解的基礎上,將變更納入考慮,而無需停止整個規劃過程,重新跑一次規劃。實時規劃的另一個經典應用場景,就是在VRP(車輛路徑規劃)過程中的實進車輛調度功能,即車輛按原計劃的路線行駛,當遇到路況不佳時,司機可以將路況反饋回服務端,以OptaPlanner爲作引擎的服務端會馬上作出反饋,重新規劃一條新的路線給司機,並對後續的訪問節點進行適當調配。其實這一過程同樣適用於車間的調度工作,我們的平臺將會添加這一功能 - 車間實時工作調度模塊。

  那麼實時規劃功能,在OptaPlanner的8.X版本中有哪些改善呢?其實,我們在8.X以前一直都已經有實時規劃功能,但那些版本我們需要實現實時規劃,OptaPlanner提供的接口,還是相對比較零碎且繁複的。例如,當我需要增加一個數據時,需要先判斷添加這個數據是一個Planning Entity,還是一個普通的Problem Fact,不同的情況需要使用不同的API。添加與刪除兩種操作也使用不同的API區分。因此,要實現實時規劃,需要考慮:你是需要從規劃空間中增加對象,還是刪除對象;你增加/刪除的是什麼類型的對象;從而採用不同API,編寫不同的處理邏輯。

  而到了8.X之後,將上述情況都整合成一個接口 - ProblemChange. 即無論你的操作是增加還是刪除對象,無論你操作的對象無論是Planning Entity還是Problem Fact;對於整個規劃問題來說,都是對規劃問題的修改,因此,這些操作都抽象成一個接口 - ProblemChange。只要我們新建一個類實現ProblemChanged這個接口即可。當然,具體在這個接口的實現類中,需要如何實現新增、刪除邏輯,還是需要我們自己去編寫的,因爲這屬於業務邏輯的範疇;但也僅僅涉及這些對象被增刪後,規劃空間中剩餘對象的一些業務性要求而已。而評分之類由引擎自行處理的邏輯則不需我們來處理。例如,在VRP場景中,如果有一個節點臨時取消了,那麼我們可以通過實時規劃把這個節點從一條車輛行駛路線中刪除。但是,因爲一條路線是由各個節點首尾相接構成的,因此,如果你刪掉這條路線上的一個節點,這條路線就被截斷了。爲了保持路線的完整性,你需要把被刪除節點的前後兩個節點連接起來,從而保證路線的完整(這也是OptaPlanner中Chain的一個原則性要求)。這就是刪除一個節點需要處理的唯一一個需要人工處理的業務邏輯。當然各種場景需要處理的邏輯不同,例如添加一個節點,則不需要任何處理,因爲一個新的對象出現,對OptaPlanner來說,相當於有一個對象還未被規劃處理而已,它會自動把這個新的對象納入考慮。

  上述描述的實現業務過程,也都在ProblemChange這個接口內實現即可。而且整個接口需要實現的方法也只有doChangeg一個方法,構造好一個ProblemChange對象,直接將這個對象傳送給SovlerManager對象的addProblemChange方法即可。相對於之前版本的接口簡單明瞭。

評分方式,以ConstraintStream取代Drools

  8.X之後,由該團隊成員 Lukáš Petrovický 主導的ConstraintStream功能得到長足發展。事實上ConstraintStream早在7.X版本就已出現,但當時提供的API還是比較少,未能覆蓋最常用的Drools表達的所有功能。到了8.X之後,相長的時間與版本里,都在完善ConstraintStream功能。ConstraintStream我們通常稱之爲“約束流”,熟悉Java8以上版stream特性的小夥伴應該知道,通過stream功能,可以實現類似SQL腳本一樣的複雜查詢。規劃約束的本質也是對數據集的過濾、條件判斷和評分設定(這就是所謂運籌優化算法的核心之一)。

  目前OptaPlanner關於分數計算(也即評分)有以下方法:

  • Easy Java score calculation - 相對較容易實現但因爲沒有增量評分,性能稍差
  • Drools score calculation- 基於Drools引擎,直接使用Drools腳本編寫約束,性能一般表達方法豐富,但需要學習Drools,在8.X版本已被標識爲“棄用”,即不再更新,預計在9.X將會取消該種計分方法。
  • Constraint streams score calculation- 新的約束流評分,實現起來較精簡,但需要熟悉掌握各個函數式編程API,後臺還是基於Drools引擎)
  • Incremental Java score calculation- 性能最強、靈活性最高,但官方不推薦,原因是實現難度較大)

  Drools評分是目前最爲成熟易用的一種評分方法,規劃模型裏的第一個約束,對應於Drools腳本中的每一個規則(腳本里稱爲Rule),一個規則體由LHS和RHS構成,其中LHS根據約束的要求實現規則邏輯,當LHS的所有條件都滿足了,就會執行RHS中的內容,因此,RHS主要是實現評分功能,即具體是要求引擎對哪個類型、哪個層次作出多少分值的懲罰或獎勵。這種方法具有非常豐富的邏輯表達方式,豐富的Drools腳本表達能力也可以充分利用,當然,要掌握Drools腳本也需要有一定的學習過程。

  根據OptaPlanner官方發佈的計劃,Drools評分方式將會在下一個主版本(通常認爲是9.X版)將會取消相關接口,屆時將無法使用Drools腳本實現評分約束。取而代之的是ConstraintStream評分方式。而在我決定開發易排(EasyPlan)通用規劃平臺的時候,考慮到以後的兼容性及性能要求,我目前使用的是Incremental Java Score calculation的方式實現相關約束。這種方法雖然實現起來難度最高,但其性能與靈活性也是最好的。考驗的是開發人員對約束的實現能力,同時需要實現方案的分數分析,若使用Drools或ConstraintStream這兩個主分方式,完成規劃後,一個方案的分佈也已經自動生成的,而使用Incremental Java Score calculation則需要實現額外的接口,才能得到主分的分佈信息。但我認爲若作爲一個定製項目,這些額外的付出需要根據實際情況考慮,而我們實現的是一個性能、靈活性要求都更高的產品,因此,花更多的時間精力來實現Incremental Java Score calculation是完全有必要的。

  關於ConstraintStream的底層實現基礎,在一篇OptaPlanner官方發佈,建議人們將Drools約束移植到ConstraintStream方式的文章(見以下鏈接)裏提到,ConstraintStream其底層也是基於Drools引擎的,只是提供一套對Java開發人員更爲熟悉的函數式編程的ConstraintStream API,以方便開發人員編寫約束。見以下截圖:

截圖出處: OptaPlanner deprecates score DRL

 

部分未成熟的功能

SolverManager的Problem ID(即規劃數據集的ID)問題仍有Bug

  在我們的【易排(EasyPlan)通用智能規劃平臺】的開發過程中, 我們使用了SolverManager來實現多個數據集並行規劃,平臺的API調用後可即時返回。其中就用到SolverManager的Problem ID來識別規劃空間中不同數據集,從而查詢各個數據集的狀態和規劃結果。但在開發過程中,我們發現,當一個數據集規劃運算異常時,我們重新把這個數據集再次提交到引擎,且使用的數據集ID(Problem ID)與前一個數據集ID一樣,會出現一個異常,提示該ID的數據集已經處理。很明顯這是一個錯誤,因此我已在他們社區的JIRA裏創建了一個issue。希望能早日修復此問題。

  也正因爲這個問題,我在我們的平臺關於規劃ID的機制作出相應的變更,以避開OptaPlanner這個問題。若看過平臺最早一個版本的說明文件的小夥伴應該有印象,每個數據集的規劃ID是由我們在生成數據集(即那個json)時,自己去維護其中的id字段的,這也能很好地讓調用方較容易地控制各個數據集的ID,但若過程中出現這個異常,當我們重新提交一個數據集給平臺重新跑規劃運算時,若使用了與這前出現異常的數據集一樣的ID,就會返回一個異常,提示:該問題(id爲1)已在處理。因此,那個版本我們提供了一個接口,用於查詢一個ID是否已經存在規劃數據集,還有一個接口用於生一個新的ID。但這種設計其實相對大家的前端調用程序的設計是比較繁複的,因此,但我們必須在OptaPlanner官方修復該問題前,避免該問題出現,同時也提高調用端的易用程度。因此,我們將接口修改爲,提交數據集到平臺做規劃運算時,數據集的ID並不作準,而是平臺自己根據當前的規劃空間情況,生成一個新的ID,以該ID爲準,用於後續操作使用。

  例如:一個數據集在客戶端(例如你們自己的MES系統)生成時,其ID是1,但通過接口提交到平臺時,平臺可能返回的是2(調用反饋json中的PID字段值),那麼,此次規劃的ID是2,後續需要查詢狀態、獲取結果,以及以後需要實時規劃時,更新一個規劃數據集,使用的ID都需要使用2,而不是使用你們自己生成的1. 希望官方能早日修復些問題。

前一個數據集出現異常時,後續再使用相同的ID,就會出現這樣的異常

 

Geoffrey De Smet建議本人創建的issue

 

新的鏈狀態設計仍有部分特性未實現

  另外一個問題是,在8.x的其中一個版本(具體哪個版本沒細查了),我們之前常用的時間鏈(Chained Through Time)模式,提供了一種新的方式來實現,並引入了 @IndexShadowVariable 和 @PlanningListVariable 兩個新的標註, 其目標是簡化時間鏈模式,令鏈實現起來更直觀。使用過時間鏈模型的小夥伴應該還記得,該模式需要定義通過繼承父類或實現接口的方式,來定義一條鏈上的錨和節點的關係,實現起來比較繞,可只要我們一旦掌握了要領,實現起來還是比較靈活的。 OptaPlanner爲了簡單此模式,引入了列表規劃變理(即一個規劃變更可以是一個列表)。但事實上這個功能尚未完全成熟,還是有一特列情況無法實現的,而在官方的示例中,我們可以看到,一些功能未能實現而需要做些取捨。

 

  綜上,大家在使用最新版本OptaPlanner的時候,有些功能還需要根據具體情況使用相應的方法,有一些新加上去的功能,看上去實現起來會更簡潔,但其實它不一定成熟的。需要看情況使用。例如,因爲上述新的鏈狀功能的實現還沒成熟,TaskAssigning示例的Consume功能在新的版本中被屏蔽,還沒辦法演示員工對任務完成情況的案例。如下圖。

 

  以上是本人對於OptaPlanner新版本總結出來的一些問題,分享給大家,希望大家在使用時能儘可能避坑。

 

  同時也邀請大家使用我們的【易排(EasyPlan)通用智能規劃平臺】,它基於OptaPlanner對APS的一些常用規劃邏輯進行封裝,大家只需要管理、維護好自己系統(使用MES、MOM、ERP中的計劃模塊)中的工單數據,即可快速地實現一個APS模塊。後續我們還會添加【VRP - 車輛路徑規劃】和【在線調度】模塊,敬請期待。可以通過以下鏈接查看更多該平臺的使用方法。

易排(EasyPlan)通用智能規劃平臺 Q&A

與平臺相關疑問,可以添加本人微信(13631823503)探討,或關注我們的公衆號【讓APS成爲可能】及時接收相關消息。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章