多工序、多機臺(產線)環境下的排程要點
關於生產計劃排程的種類及其特性
釋義：文中提到的資源，是指需要完成一個生產作業（或稱任務，生產任務）所需的生產條件，例如機臺、原料等，稱為廣義資源。
對於生產計劃，常見有以下四種類型：
- 單一工序，單一資源種類.
- 單一工序，多資源種類.
- 多工序，單一資源種類(較少見).
- 多工序，多資源種類.
下面對上述四種生產計劃進行逐一分析，本文的分析，著重於計劃的優化實現，而不是硬性規則的確保。例如通過工序的就緒情況來確定資源的就緒要求，例如MRP等，這些硬性的約束可以通過規則引擎（例如Drools）來確保在生成計劃過程中，計劃的安排滿足各種業務規則；而無需通過規劃引擎（例如Optaplanner)，在滿足了硬性業務規則的基礎上進一步優化。
單一工序，單一資源種類
對於單一工序，單一種類資源的情況，是最簡單的一種排程場景。即一個產品的生產過程只需使用同一種資源，進行一次加工即完成了產品的整個生產過程。這種情況下，既然是單一工序，那也就沒有了工序的先後資源的限制；單一種類資源，即表示沒有了資源的選擇優化。在生產實踐中，此類生產計劃通常是對產品工序路線中，眾多工序中的一個較重要的工序進行制定計劃時使用。需要進行優化的主要是對資源的使用分配，例如各機之間實現負荷平衡等需求。我們在實現這類計劃時，需要通過設定機臺平衡的約束，讓引擎在為工序分配任務時，盡可能地實現同一類機的負荷平衡。例如在印刷生產中，對排在最後的手工工序制定生產計劃時，需要根據各個產線的人力安排情況，按比例安排定額任務。這些情況可使用“單一工序、單一種類”資源計劃。
單一工序，多資源種類
單一工序 ，多種類資源情況，僅對產品的一個工序進行排產，僅可用於這個工序的資源是多種多樣的，並且各種資源之間可以互換的。此類計劃主要是為了實現資源的優化分配。即按照一定的原則來對各個工序進行資源安排。例如：各種資源使用成本各不相同，在制定計劃時，為了降低生產成本，應該在確保其它更高優先級的約束或硬性約束的前提下，盡量使用低成本的資源進行生產。舉個實際的例子，在印刷行業中，對於對印張進行印刷的工序，有些印張可以通過CMYK四色印制，也可以通過調配特殊色，通過專色印制；但前者的成本相比後者更低，前後兩種印刷方式就表示兩種資源。在對印刷工序定制生產計劃時，就會優先使用CMYK印刷，但這個也不是絕對的，例如如果CMYK資源已經超出負荷時，不動用專色印刷就無法實現按時交貨時，還是會放棄成本這個約束，來遷就交期這個更高優先級的約束的。
多工序，單一資源種類
多個工序，單一種類資源的情況，則相對較少見。即計劃中需要制定整個產品工序路線中的所有工序的資源和時間，其中資源只需要只有一種可選。可以理解到，這種情況對資源分配的要求就較低了，計劃著重於對工序的前後關系制約了或工序自身的其它因素的優化。即是在資源分配上，如第一種情況：“單一資源、單一任務”一樣，基於資源利用的一些原則進行資源分配。而在安排工序的加工時間問題上，則需要根據產品的工序路線，實現對前後工序在時間上的次序關系；而這種次序又受到資源分配的限制。例如：如果印刷的第二工序中（有些企業稱為印後加工），有過油、過膠、過UV三個工序，如果有一種機臺同時可以實現這三種工序的，那麽就滿足了“多個工序、單一資源種類”的場景。這時候關於工序的資源分配，會有相應的資源使用約束。但更重要的約束是：一個產品的多個工序的處理次序上，這個次序必然是根據產品的工序路線設定的資源來執行的，否則就違反了硬性約束。所以，綜合上述的資源分配和工序資源兩種要求，我們需要面對的是兩上互相矛盾的問題：1. 對於同一個產品需要確保其執行的工序與工序路線上設定的一致， 2. 對於一個資源（例如機臺）上的生產效率而言，如何可以實現更多的同工序連接生產，因為即使是使用同一資源，通常在該資源上，不同工序的生產任務之間的切換，會產生成本的，有可能是時間成本，也有可能是具體的貨幣成本。所以，難點就在於如何平衡上面兩個問題，從而實現資源利用率最大化和工序資源不被違反。
多工序，多資源種類
多個工序，多資源種類的和產計劃，也是目前最為常見，也是最為復雜的生產計劃，是本文討論的重點。多工序與前一個問題一樣，是針對整個產品的工序路線進行排產。而且生產各個工序所用的資源是不同種類的。因此，這種情況我們面對了兩個相對零散也有交互的矛盾：1. 對於一個產品而言，其多個工序是依據工序路線形成生產資源的； 2. 多種資源就表示各個生產工序所使用的資源有可能不一樣，也有可能一樣的。因為工序的前後次序的限制原因，當引擎在對一個工序完成了資源分配後，進一步進行生產時間的分配，但因為同一產品的工序執行次序，是需要按照工序路線的先後次序來執行的，也就是說計劃中，除了需要分配好的資源外，還要確保這個資源在指定的時間段內，沒有被其它產品的生產任務占用。那麽當同時對多個產品進行排產時，各個產品的工序路線形成的工序生產序列和資源分配方案，很容易就形成了膠著狀態，甚至在多個資源之間會出現死鎖狀態。
下面，我們以多個不同種類的機臺，處理工序路線上多個工序的案例，來計劃“多工序、多資源種類”的情況，並分析需要實現這種計劃，所需的技巧、技術難點和可能出現的情況，及其應對方法.
多工序與多機臺的場景描述
規劃過程中用到的概念
為了便於描述規劃過程中的各種情況，現先定義以下概念：
任務或生產任務：一個產品的一個工序的生產作業稱作一個任務，例如印刷後加工有：過膠 -> 燙金 -> 絲印，則表示這個產品的後加工中有三個任務，分別是過膠任務， 燙金任務和絲印任務。
工序路線任務鏈：一個產品中的不同工序對應的生產作業，其次序是由其工序路線確定的，一個產品的所有生產作業序列，即任務序列，稱為工序路線任務鏈.
機臺任務鏈：多個任務被分配在一個機臺上時，同一時間只能處理一個產品，即同一時間只能進行一個任務，這些同在一機臺上形成的任務序列，稱為機臺任務鏈接.
前置任務，後置任務：同一產品上多個任務，根據工序路線的規定形成與工序次序一次的生產任務次序(即工序路線任務鏈)。在鏈中兩個相鄰的任務，前者稱作後者的前置任務；後者稱作前者的後置任務。
前一任務，後一任務：分布於同一機臺上的多個工序任務（即機臺任務鏈），在機臺任務鏈中相個相鄰的任務；前者稱為後者的前一任務，後者稱作前者的前一任務。
多工序、多機臺排程裏的限制
下面我們來針對實用性最強，制造業面對最多的場景 ：多工序、多臺機臺場景展開討論。處理這類生產計劃，有以下兩個因素處理起來最為麻煩。
1. 多任務與多機臺的匹配
因為在待排的計劃要素中，任務與機臺的種類都存在多樣性，且可能存一種任務可分配到多種機臺，一種機臺可以做多種任務的情況，因此，任務與機臺的匹配問題會相對其它三種生產計劃復雜一些。但往往這也是體現出Optaplanner價值的其中一個要點。
2. 工序路線任務鏈與機臺任務鏈之間存在互相制約關系
一個產品的工序中線確定的任務序列，與分配於同一機臺上的任務序列，在加工次序上存在互相制約。加工次序體現在加工的時間先後。即一個產品的任務序列，必然按其工序路線，存在一定的先後次序。而當個產品被分配到各個機臺上進行生產作業時，因為生產路線上存在時間先後次序，會令到一個機臺上多個任務需要按次序生產的時候，每個任務的作業時間段可能並不是緊密連接。因為當準備在機臺上啟動一個任務時，這個任務的前置工序可能尚未完成，從而令到該任務所在的機臺已就緒（其前一任務已完成，機臺已為該任務準備就緒），但因為它的前置工序還沒完成，導致它無法開始，因為一旦開始就違反了工序路線約束，從而令該機臺上排在它後面的其它後任務都要推遲，而這些任務被推遲，又有可能導致它們自身的後置任務需要推遲，從而會出現機臺任務鏈和工序路線任務鏈互相影響。我們稱這種情況為“連鎖反應”，解決好這種連鎖反應，是解決排程的關鍵。
因為上述描述的連鎖反應的情況出現，有可能令出現環狀影響的情況。因為一個正常的產計劃會存在時間與空間兩個主要維度，其中的空間維度本文的場景中就是機臺，表示為一個任務被分配到了指定機臺。而時間維度則體現為任務的開始時間和結束時間（事實上結束時間可以通過開始時間推導出來），即確定一個任務的計劃開始時刻。那麽就需要有一個邏輯，對各個已分配空間（即機臺）的任務進行時間推導。任務的時間推導我們需要通過Optaplanner的afterEntityChanged事件來進行(這個事件僅出現於Chained Through Time模式, 以後將會有專門的文章講述Optaplanner的時間分配模式，其中Chained Through Time模式是重點)，而推導的起源(就是從哪個任務開始推)我們通常是以當前Move（Move是Optaplanner的最小作業單位）所處理的任務開始，這個任務我們稱為震動源。經過它的工序路線任務鏈傳遞到機臺任務鏈，再由機臺任務鏈的影響回工序路線任務鏈，當這種環狀的影響線路，經過一系列的連鎖反應，正好返回來對震動源進行推導的時候, 那麽相當於又開始了輪與上一輪一樣的推導路線，就會無限地推導下去，死循環就產生了。我們需要準確識別這種連鎖反應會否產生死循環，並當確實產生死循環時，就要將當前的move標識的不合法，在開啟時間推導之前，通過Optaplanner的Move Selection Filter將當前的move取消，從而避免產生程序溢出，令系統崩潰。下面會舉實際的死循環例子說明這種情況。
下面我們先明確多任務多機臺生產計劃的基礎約束，再討論死循環的具體產生經過。
計劃約束
- 每個工序只能分配到指定的機臺；
- 除產品的首個工序外，所有任務都有一個前置任務，它的開始條件是它的前置任務已結束，即同一產品的工序根據工序路線存在FS關系。
- 同一機臺同一時間只能處理同一任務。即分配到機臺上的工序生產任務，而生產時間不能重疊。
排程過程中產生的死循環
例如下圖：紅框的任務Task1, Task2, Task3表示了一個產品的工序路線上的3個工序對應的任務，即表示這三個任務形成了工序路線任務鏈，它們分別分布於machine1, machine2, machine3三個機臺。根據工序路線任務鏈的次序約束，其生產次序是Task1 -> Task2 -> Task3. 而藍色背景的兩個任務則是另外一個產品的工序路線任務鏈，根據該產品的工序路線，它的生產門外漢是TaskA -> TaskB, 可以看到這兩個工序的次序跟紅框工序中的Task2, Task3的次序是倒過來的。而從機臺machine2的機臺任務鏈上，我們可以看到,存在一個這樣的生產次序關系：Task B -> Task 2。那麽在Optaplanner通過一個Move來產生一個可能的方案，並對這個方案中各個任務的開始時間進行推導時，就有可能組合出如圖中的狀態，從而出現死循環，因為一個產品的工序需要按工序路線任務鏈的次序執行，而一個機臺上生產機臺任務鏈中的任務也是存在先後關系的，也即具有時序性的，一個機臺在同一時間只能生產一個任務，也就有了一個機臺自身的生產任務也是一個次序鏈的。從圖中可以看出，存在了這麽一個環狀的生產任務次序： Task2 -> Task3 -> TaskA -> TaskB -> Task2,
即當Task1, Task2, Task3, TaskA, TaskB中任意一個任務的開始時間被推導時，它都將成為上述死循環描述中的震動源，從而產生死循環。
實際多工序多機臺生產計劃中的約束
在實際制造中，除了上述討論的三個主要約束外，還會存在非常多企業自身業務場景相關的限制因素，會更大程度上限制生產活動的執行。而這此限制需要正確地反映到生產計劃中，否則最終產生的計劃就無法執行。本文只列出對生成計劃的正確性有影響的、各計劃均會存在的共性因素；而那些與各個行業、企業的業務相關的個性化因素，則不在本文考慮範圍內，各位在自己設計系統時考慮即可。例如：印刷行業中的印刷後加工工序，做完灑金粉工序，是需要等待一定時間，令金粉固化後，才能進入下一工序的，那麽也就是說這個工序與下一個工序之間存在一個最短時間間隔的限制，否則是會產生質量事故的，因此是一個硬約束。
任務死循環的檢測經驗
因為生產計劃的復雜性，造成工序任務鏈與機臺任務鏈之間存在異常復雜的制約，需要對Optaplanner產生的可能方案進行合法性判斷，識別任務的開始時間推導過程中，是否存在死循環的可能，則需要非常嚴謹的邏輯分析與正確的模型與算法設計。現分享一下本農在此類項目中，在這方面遇到的問題。
當時我把機臺任務鏈、工序路線任務鏈設計出來，並明確了模型中各實體的職責和關系後。發現了時間推導存在死循環的可能。因為我認為對Optaplanner將要規劃出來的可能方案中的各種任務的關系已經有足夠認識，就根據推導過程中可以出現的情況進行死循環檢測，檢測過程也相當簡單。因為當一個可能方案中任務的時空關系一旦確定之後，所有的任務即構成了一個有向圖(directed graph),那麽我檢查這個有向圖是否存在環即可。我嘗試過使用隊列結構對這個圖進行廣度優先遍歷，並識別環是否存在。也嘗試過通過遞歸方式進行深度優先遍歷（其實遞歸使用的數據結構就是棧，知曉VC++的同學應該從WinAPI32編程中學習過函數調用的機制，其實調用調用路徑就是一個棧)。無論怎麽嘗試，檢測結果就是無法完美、全面。因為我們項目中需要考慮的因素更多，出現意想不到的可能性更大。因此，有段時間我自己都覺得，不太可能解決這個問題，盟生了放棄的念頭。幸好我遇到一個好領導，我的老板（我們這裏都叫上級做老板）Jeffrey給了我非常多機會和支持，並不時跟我一起分析，他也了解到問題的復雜性，並給予理解與鼓勵。最終我的解決辦法是：對Optaplanner在規劃過程中產生的每個可能方案，都進行模型上的抽象與簡化，去除一些不影響死循環判斷的因素，把它歸約成一個正正式式的有向圖，並通過一些成熟的有向圖環檢測的算法對其進行判斷。其實思路主就是：把之前根據復雜的業務規則實現不同的邏輯進行分支檢測的方法，倒過來，將含有一些業務因素的有向圖，歸約成數學算法可以處理的規範有向圖，再對其進行檢測。目前這個功能已經相當穩定，再她不會時不時出現意想不到的情況了。關於有向圖的環檢測算法，網上有很多，大家自己找或者自己研究都能弄出來，就不在本文深究了。
通過Selection Filter對不合法方案進行過濾
其實若我們只研究本文中提出的多任務多機臺生產任務的最基本三個約束的話，上文提到的不合法方案就只剩下任務死循環方案了。若在現實項目開發中，一個方案不合法的定義會更多，更豐富，且更復雜。一旦我們通過各種手段檢測出一個方案是不合法的。我們就可以通過Selection Filter，在Optaplanner對的VariableListener對象的afterEntityChanged事件處理方法之前，把事個move放棄掉。關於Selection FIlter的用法，大家可以先從Optaplanner的開發手冊中查看，我將會專門撰寫Selection Filter相關的文章 對其進行說明。
小結
自此，本文描述了基於Optaplanner設計APS排產引擎時，遇到比較棘手的問題。包括：計劃類型的識別，由任務組成的工序鏈與機臺鏈，任務與機臺之間的匹配，工序鏈與機鏈之間的膠著可能性與循環識別與處理。希望能幫到大家。
本人也是初初研究APS排程引擎，都還是在不斷探索中，有不正確的地方，還請多多提點。為謝。
如果對此大家有何建議，歡迎大家加我企鵝一起探討,Q：12977379或V信：
其實 Optaplanner規劃引擎不需要對Java過份精通即可使用,因為它使用到的都是Java最基本的知道，但還是需要有基本的Java知識才行，希望大家找我研究討論時，如果Java, Maven等方面仍接觸較少，請大家先行自補該方面的知識，本猿暫時只能跟大家探討Optaplanner, Drools的應用，而Java相關的知識，恕無法提供有效的幫助，畢竟本猿也只是個Java新手。先謝了。
多工序、多機臺(產線)環境下的排程要點