近段時間忙於各種項目和對【易排平臺】的優化,沒顧得上分享APS相關的小技巧,回頭看看小公眾號的關註人數早已達1500+,在此爭取時間寫一下這段時間在項目上及平臺優化過程中遇到的一些小技巧,以感謝諸位的關註。過去數月的解決的問題中,涉及最多的是規劃模型中,實現各種時間維度的功能,目前在平臺上也稍有成果 ...
近段時間忙於各種項目和對【易排平臺】的優化,沒顧得上分享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關係,完成一定百分比的時間)外,還需要考慮該任務的前導任務的完成時間,否則就會出現時間重疊,即一個資源在某一時間段出現多個任務,導致資源超用。
虛擬任務
而同一資源上兩個任務之間有可能存在一些額外操作,例如:同一機台加工完一個零部件後,需要加工另一個產品的零部件,有可能需要更換模具、夾具,這些額外工作,視不同任務的參數而定,有可能不需要額外工作(例如:兩個所有參數均一致的零部件加工),也有可能需要同時進行多個額外工作(例如:有些任務的轉換,除了需要更換模具,還需要重新調整加工參數,重新試製等)。我們把這些額外工作稱為虛擬任務。虛擬任務的多少,及用時長短,對後續任務的開始時間會造成影響。
因此,在同一資源上,一個任務的開始時間為:前導任務的結束時間,加上前導任務切換到後續任務的虛擬任務時長。
現留有以下疑問大家可以思考一下:
- 前導/後續任務為什麼不需要加上靜置時間?
- 一個任務的開始時間,需要同時考慮前置任務的完成時間及前導任務的完成時間,那麼這兩個時間以哪個為準?
工序間的靜置時間
如上述的定義,【靜置時間】是指兩個前置/後置工序之間的等待時間,對於離散結構的工序路線,靜置時間可能存在多個工序之間。例如一個任務存在多個後置任務時,對於不同的後置任務,可能存在不同長度的靜置時間。例如,在某些情況下,噴塗工序完成後,需要等待4小時才能進行鍍膜工序,但同樣是噴塗工序的後置,在工作錶面上的鑽孔工序,可能靜置兩小時即可完成。若鍍膜工序與鑽孔均為噴塗工序的後置工序,則它們具有不同的靜置時間,因此,在設計規劃模塊時,必須考慮此類離散情況下的複雜場景,能實現儘可能減少等待時間,提高資源利用率。
在【易排平臺】最初的設計中,我們考慮了將靜置時間納入前置工序的加工時長上,並作出標識,用於區分工序的加工結束時間與靜置結束時間。此方案從時間上確實可以實現後續工序必須在靜置完成之後才開始。但存在非常大的局限性與弊端。因為所謂的靜置時間,對於一個任務而言是不占用任何資源的(完成噴塗的工件可以放在等待區,噴塗產線可以繼續加工後續的工作),若將靜置時間加到噴塗工序的時間上,就會造成靜置時間也相當於占用了資源。雖然當時我們修改了資源占用的計算方法,將靜置時間略過,但該方案明顯會導致判斷邏輯變得複雜。且上述提到的存在多個靜置時間的情況,也難以實現,當然你也可以考慮將靜置時間添加到後置工序的開始處,但同理,離散結果的場景不僅存在多個後置工序情況(即工序路線分叉),還存在多個前置工序的情況(即工序路線合併),因此,邏輯將非常複雜,且導致部分場景出現歧義。
最終我們使用的方法還是修改該設計方案,新的方案是將靜置時間抽出來,作為任務間的獨立屬性存在,該屬性不屬於工序,而屬於工序之間的關係。即在工序路線這個有向圖上,靜置時間不屬於一個任務,而是屬於兩個任務之間的弧。
原本計劃把所有時間相關的設計思路都介紹一下,但發現就目前介紹的思路已經需要相當篇幅。因此將剩餘的其它時間相關設計留在下一篇。
事實上,上述對於各場景下,時間的推導只是最為簡單的思路,需要實現這些邏輯時,還會遇到非常多需要考慮的要素,限於篇幅不可能在此完全闡明。如下圖我們關於時間推導設計的其中一些設計資料,那是相當細的工作。
下一篇,我們將介紹以下幾點的時間設計思路
任務加工時間適配資源日曆的方案
大多數資源不可能 7 x 24工作,也不可能所有任務都能在一個班次(8或12小時)內完成,那麼如果實現這些不規則的時間片段與任務長度呢?
工單的排程方式如何體現在時間上
我們現有的生產計劃,有前推式排程,儘可能早開始;還有後拉式排程,儘可能晚開始(JIT);此外,還因為資源限制或半成品時效限制等因素,以關鍵工序為基準進行排程(儘可能保證關鍵工序資源使用率最高)。那麼在時間上應該如何設計,才能實現這三種典型排程呢?
因時間計算邏輯,引起的OptaPlanner各種Corruption問題
在處理時間推導邏輯過程中,經常遇到本來很正常的程式,加上一些時間推導邏輯後,就會出現“Score corruption”,"UndoMove corruption"與"Variable Listener Corruption". 這些異常產生的根本原因是什麼?應該如何識別?識別出來應該如何改進設計來適配OptaPlanner的評分規範要求,以消除這些異常?
寫在最後
有同行問到:為什麼你分享的經驗都是一些細枝末節?有沒有一些“更有營養”的內容可以分享一下。
我覺得吧,小弟正是軟體開發出身的,偶然的機會接觸到APS,更偶然機會接觸到OptaPlanner才開始的APS系統設計開發工作。經歷的都是各種很底層且很細節的問題,但在這些項目實踐過程中,我也總結到一些經歷,那就是一個很好的方案能否落地,很多細節往往都是起決定性作用。就算不談技術方面,就是做具體的實施,客戶的具體業務場景、細節和規則,都是至關重要的。
一個巨集觀的方案對於客戶高層領導對整個項目的理解當然是重要的,但項目一旦啟動,能否切實地滿足需求,使用項目通過各種系統、數據、流程落地到具體的用戶部門,才能最終體現整個項目的價值。所以,細枝末節多關註一些也無防。而且縱觀整個市場,能提供巨集大、高階推介方案的專家顧問很多,水平極高;相反願意潛心去處理細枝末節這種臟累差活的人卻不多,因此,研究起來可以參考的案例、資料相當匱乏,能深入研究一下,應該也挺有價值的。
<完>
一個IT老農,先儘力擔好當兒子、丈夫和父親的責任,然後做點有趣的事。