近段時間忙于各種專案和對【易排平臺】的優化，沒顧得上分享APS相關的小技巧，回頭看看小公眾號的關注人數早已達1500+，在此爭取時間寫一下這段時間在專案上及平臺優化程序中遇到的一些小技巧，以感謝諸位的關注，過去數月的解決的問題中，涉及最多的是規劃模型中，實作各種時間維度的功能，目前在平臺上也稍有成果，因此本次分享就選取其中幾個較具代表性的情況，分享給大家，歡迎大家一起探討，

多種工序接續關系導致的時間推導邏輯

　　在專案計劃中，任務與任務之間存在多種接續關系，使用PJS模型作為APS的規劃模型時，我們可以把一個工單看作一個專案, 工單中的各個工序看作專案中的各個任務，一個工單的加工計劃，就相當于一個專案執行計劃，因此，在該模型背景下，任務的規劃可以劃分為空間規劃與時間規劃，其中前者體現為各任務的資源分配程序，后者可以歸納為任務的開始時間，任務與任務之間的關系等，

　　在開始討論規劃程序中的時間計算之前，需要先對其中一些概念作一些定義，以簡化下文的語言描述，

概念定義

　　在專案計劃有多種接續關系，目前易排系統中實作了FS(Finish to Start)與SS(Start to Start)兩種關系，其它關系將視具體的專案情況，若有需要再具體實作，

前置工序、后置工序

　　在一個工序路線上相鄰的兩個工序，需要先加工的(即前面的)工序，我們定義為前置工序，后加工的稱為后置工序，

前導任務、后續任務

　　分布在同一資源(例如機臺、產線)上、且相鄰的兩個任務，在時間軸左則(先加工)的我們稱之為前導任務，右則(后加工)的我們稱為后續任務.

靜置時間

　　工序路線上兩個前/后置任務之間，若前置任務完成后，需要等待一段時間，后置任務才能開始，該等待時間，我們稱為靜置時間，

接續關系

　　同一工序路線上，前后兩個任務的制約關系，我們稱為接續關系，因為我們使用PJS作為原型衍生出來的模型作為規劃模型，因此，【易排平臺】借用了專案管理中專案計劃的任務間依賴關系，正常的專案依賴包括FS(完成-開始)，FF(完成-完成)，SS(開始-開始)和SF(開始-完成)，而【易排平臺】為僅提供其中較為常見的兩種關系：FS和SS，這兩種關系在系統中的實作邏輯如下，

任務計劃開始時間

　　在PJS模型中，關于時間維度的推導，其中一個關系變數是各任務的開始時間，各個任務幾乎所有時間長度和時間點(我們稱為時刻)都與任務的計劃開始時間有直接或間接關系，因此，本文著重講解各種情況下，任務開始時間的推導邏輯，

FS接續關系

　　FS接續關系是表示前置工序全部完成后，后續工序才開始生產，這種關系通常出現在后置工序對前置工序具有整體依賴關系的情況，例如一些大型裝備生產加工程序中，一個工序的加工物件就是一件大型零部件，因為場景、設備等限制，需要一個工序完全完成后，才能整體交付出去，后置工序才能拉著生產，

　　這種接續關系在排程程序中的時候推導最為簡單，當前任務的開始時間，為前置任務的完成時間，加上前置任務的靜置(詳見【靜置時間】一節)時間，

SS接續關系

　　SS接續關系即Start to Start接續關系，它表示前置工序完成了一定量，后置工序即可開始，通常我們用SS 50%, 表示前置工序完成了50%的作業量，后置工序即可開始，例如一個工單的某個工序，需要產生1000件半成品，這些半成品將成為后置工序的原料，為了提高資源利用率，后置工序通常不需等到1000個半成品全部生產完成后才啟動生產，而是待前置工序完成了50%(即500件)，后置工序即會開始接力加工，從而實作前后兩個工序一定程度的并行加工，進而縮短整個工單的生產周期，

　　這種情況下，一個任務的開始時間，將不再以前置任務的完成時間為基準進行計算，而是以前置任務完成50%的時間作為基準，即開始時間為：前置任務開始時刻 + 前置任務整體時長 * 50% + 靜置時間

同一資源上相鄰任務的接續關系

　　上述描述的是同一產品的工序路線前，兩個互為前/后置工序的任務，因接續關系不同，而導致的計劃開始時間計算差異，而分布在同一資源上的一系列任務，同樣存在時間推上的邏輯需要理清，

　　在同一資源上一對互為前導/后續關系的任務(即兩個相鄰任務)，在時間任務的計劃開始時間時，也需要注意，任何一個任務的開始時間，除了考慮其前置任務的結束時間(或在使用SS關系，完成一定百分比的時間)外，還需要考慮該任務的前導任務的完成時間，否則就會出現時間重疊，即一個資源在某一時間段出現多個任務，導致資源超用，

虛擬任務

　　而同一資源上兩個任務之間有可能存在一些額外操作，例如：同一機臺加工完一個零部件后，需要加工另一個產品的零部件，有可能需要更換模具、夾具，這些額外作業，視不同任務的引數而定，有可能不需要額外作業(例如：兩個所有引數均一致的零部件加工)，也有可能需要同時進行多個額外作業(例如:有些任務的轉換，除了需要更換模具，還需要重新調整加工引數，重新試制等)，我們把這些額外作業稱為虛擬任務，虛擬任務的多少，及用時長短，對后續任務的開始時間會造成影響，

　　因此，在同一資源上，一個任務的開始時間為：前導任務的結束時間，加上前導任務切換到后續任務的虛擬任務時長，

現留有以下疑問大家可以思考一下：

1. 前導/后續任務為什么不需要加上靜置時間？
2. 一個任務的開始時間，需要同時考慮前置任務的完成時間及前導任務的完成時間，那么這兩個時間以哪個為準?

工序間的靜置時間

　　如上述的定義，【靜置時間】是指兩個前置/后置工序之間的等待時間，對于離散結構的工序路線，靜置時間可能存在多個工序之間，例如一個任務存在多個后置任務時，對于不同的后置任務，可能存在不同長度的靜置時間，例如，在某些情況下，噴涂工序完成后，需要等待4小時才能進行鍍膜工序，但同樣是噴涂工序的后置，在作業表面上的鉆孔工序，可能靜置兩小時即可完成，若鍍膜工序與鉆孔均為噴涂工序的后置工序，則它們具有不同的靜置時間，因此，在設計規劃模塊時，必須考慮此類離散情況下的復雜場景，能實作盡可能減少等待時間，提高資源利用率，

　　在【易排平臺】最初的設計中，我們考慮了將靜置時間納入前置工序的加工時長上，并作出標識，用于區分工序的加工結束時間與靜置結束時間，此方案從時間上確實可以實作后續工序必須在靜置完成之后才開始，但存在非常大的局限性與弊端，因為所謂的靜置時間，對于一個任務而言是不占用任何資源的（完成噴涂的工件可以放在等待區，噴涂產線可以繼續加工后續的作業），若將靜置時間加到噴涂工序的時間上，就會造成靜置時間也相當于占用了資源，雖然當時我們修改了資源占用的計算方法，將靜置時間略過，但該方案明顯會導致判斷邏輯變得復雜，且上述提到的存在多個靜置時間的情況，也難以實作，當然你也可以考慮將靜置時間添加到后置工序的開始處，但同理，離散結果的場景不僅存在多個后置工序情況(即工序路線分叉)，還存在多個前置工序的情況(即工序路線合并)，因此，邏輯將非常復雜，且導致部分場景出現歧義，

　　最終我們使用的方法還是修改該設計方案，新的方案是將靜置時間抽出來，作為任務間的獨立屬性存在，該屬性不屬于工序，而屬于工序之間的關系，即在工序路線這個有向圖上，靜置時間不屬于一個任務，而是屬于兩個任務之間的弧，

原本計劃把所有時間相關的設計思路都介紹一下，但發現就目前介紹的思路已經需要相當篇幅，因此將剩余的其它時間相關設計留在下一篇，

事實上，上述對于各場景下，時間的推導只是最為簡單的思路，需要實作這些邏輯時，還會遇到非常多需要考慮的要素，限于篇幅不可能在此完全闡明，如下圖我們關于時間推導設計的其中一些設計資料，那是相當細的作業，

下一篇，我們將介紹以下幾點的時間設計思路

任務加工時間適配資源日歷的方案

　　大多數資源不可能 7 x 24作業，也不可能所有任務都能在一個班次(8或12小時)內完成，那么如果實作這些不規則的時間片段與任務長度呢？

工單的排程方式如何體現在時間上

　　我們現有的生產計劃，有前推式排程，盡可能早開始；還有后拉式排程，盡可能晚開始(JIT)；此外，還因為資源限制或半成品時效限制等因素，以關鍵工序為基準進行排程(盡可能保證關鍵工序資源使用率最高)，那么在時間上應該如何設計，才能實作這三種典型排程呢？

因時間計算邏輯，引起的OptaPlanner各種Corruption問題

　　在處理時間推導邏輯程序中，經常遇到本來很正常的程式，加上一些時間推導邏輯后，就會出現“Score corruption”,"UndoMove corruption"與"Variable Listener Corruption". 這些例外產生的根本原因是什么？應該如何識別？識別出來應該如何改進設計來適配OptaPlanner的評分規范要求，以消除這些例外？

寫在最后

　　有同行問到：為什么你分享的經驗都是一些細枝末節？有沒有一些“更有營養”的內容可以分享一下，

我覺得吧，小弟正是軟體開發出身的，偶然的機會接觸到APS，更偶然機會接觸到OptaPlanner才開始的APS系統設計開發作業，經歷的都是各種很底層且很細節的問題，但在這些專案實踐程序中，我也總結到一些經歷，那就是一個很好的方案能否落地，很多細節往往都是起決定性作用，就算不談技術方面，就是做具體的實施，客戶的具體業務場景、細節和規則，都是至關重要的，

　　一個宏觀的方案對于客戶高層領導對整個專案的理解當然是重要的，但專案一旦啟動，能否切實地滿足需求，使用專案通過各種系統、資料、流程落地到具體的用戶部門，才能最終體現整個專案的價值，所以，細枝末節多關注一些也無防，而且縱觀整個市場，能提供宏大、高階推介方案的專家顧問很多，水平極高；相反愿意潛心去處理細枝末節這種臟累差活的人卻不多，因此，研究起來可以參考的案例、資料相當匱乏，能深入研究一下，應該也挺有價值的，

<完>

標籤：Java

上一篇：對面的程式員趕緊看過來！布隆過濾器又有新玩法了~ | 博學谷狂野架構師

下一篇：Linux 服務器大量的 log 日志，如何正確看日志快速定位錯誤？你必須學會！