關於生產計劃排程的種類及其特性
釋義：文中提到的資源，是指須要完成一個生產做業（或稱任務，生產任務）所需的生產條件，例如機臺、原料等，稱爲廣義資源。 算法
對於生產計劃，常見有如下四種類型：編程
- 單一工序，單一資源種類.
- 單一工序，多資源種類.
- 多工序，單一資源種類(較少見).
- 多工序，多資源種類.
下面對上述四種生產計劃進行逐一分析，本文的分析，着重於計劃的優化實現，而不是硬性規則的確保。例如經過工序的就緒狀況來肯定資源的就緒要求，例如MRP等，這些硬性的約束能夠經過規則引擎（例如Drools）來確保在生成計劃過程當中，計劃的安排知足各類業務規則；而無需經過規劃引擎（例如Optaplanner)，在知足了硬性業務規則的基礎上進一步優化。微信
單一工序，單一資源種類
對於單一工序，單一種類資源的狀況，是最簡單的一種排程場景。即一個產品的生產過程只需使用同一種資源，進行一次加工即完成了產品的整個生產過程。這種狀況下，既然是單一工序，那也就沒有了工序的前後資源的限制；單一種類資源，即表示沒有了資源的選擇優化。在生產實踐中，此類生產計劃一般是對產品工序路線中，衆多工序中的一個較重要的工序進行制定計劃時使用。須要進行優化的主要是對資源的使用分配，例如各機之間實現負荷平衡等需求。咱們在實現這類計劃時，須要經過設定機臺平衡的約束，讓引擎在爲工序分配任務時，儘量地實現同一類機的負荷平衡。例如在印刷生產中，對排在最後的手工工序制定生產計劃時，須要根據各個產線的人力安排狀況，按比例安排定額任務。這些狀況可以使用「單一工序、單一種類」資源計劃。網絡
單一工序，多資源種類
單一工序 ，多種類資源狀況，僅對產品的一個工序進行排產，僅可用於這個工序的資源是多種多樣的，而且各類資源之間能夠互換的。此類計劃主要是爲了實現資源的優化分配。即按照必定的原則來對各個工序進行資源安排。例如：各類資源使用成本各不相同，在制定計劃時，爲了下降生產成本，應該在確保其它更高優先級的約束或硬性約束的前提下，儘可能使用低成本的資源進行生產。舉個實際的例子，在印刷行業中，對於對印張進行印刷的工序，有些印張能夠經過CMYK四色印製，也能夠經過調配特殊色，經過專色印製；但前者的成本相比後者更低，先後兩種印刷方式就表示兩種資源。在對印刷工序定製生產計劃時，就會優先使用CMYK印刷，但這個也不是絕對的，例如若是CMYK資源已經超出負荷時，不動用專色印刷就沒法實現按時交貨時，仍是會放棄成本這個約束，來遷就交期這個更高優先級的約束的。數據結構
多工序，單一資源種類
多個工序，單一種類資源的狀況，則相對較少見。即計劃中須要制定整個產品工序路線中的全部工序的資源和時間，其中資源只須要只有一種可選。能夠理解到，這種狀況對資源分配的要求就較低了，計劃着重於對工序的先後關係制約了或工序自身的其它因素的優化。便是在資源分配上，如第一種狀況：「單一資源、單一任務」同樣，基於資源利用的一些原則進行資源分配。而在安排工序的加工時間問題上，則須要根據產品的工序路線，實現對先後工序在時間上的次序關係；而這種次序又受到資源分配的限制。例如：若是印刷的第二工序中（有些企業稱爲印後加工），有過油、過膠、過UV三個工序，若是有一種機臺同時能夠實現這三種工序的，那麼就知足了「多個工序、單一資源種類」的場景。這時候關於工序的資源分配，會有相應的資源使用約束。但更重要的約束是：一個產品的多個工序的處理次序上，這個次序必然是根據產品的工序路線設定的資源來執行的，不然就違反了硬性約束。因此，綜合上述的資源分配和工序資源兩種要求，咱們須要面對的是兩上互相矛盾的問題：1. 對於同一個產品須要確保其執行的工序與工序路線上設定的一致， 2. 對於一個資源（例如機臺）上的生產效率而言，如何能夠實現更多的同工序鏈接生產，由於即便是使用同一資源，一般在該資源上，不一樣工序的生產任務之間的切換，會產生成本的，有多是時間成本，也有多是具體的貨幣成本。因此，難點就在於如何平衡上面兩個問題，從而實現資源利用率最大化和工序資源不被違反。函數
多工序，多資源種類
多個工序，多資源種類的和產計劃，也是目前最爲常見，也是最爲複雜的生產計劃，是本文討論的重點。多工序與前一個問題同樣，是針對整個產品的工序路線進行排產。並且生產各個工序所用的資源是不一樣種類的。所以，這種狀況咱們面對了兩個相對零散也有交互的矛盾：1. 對於一個產品而言，其多個工序是依據工序路線造成生產資源的； 2. 多種資源就表示各個生產工序所使用的資源有可能不同，也有可能同樣的。由於工序的先後次序的限制緣由，當引擎在對一個工序完成了資源分配後，進一步進行生產時間的分配，但由於同一產品的工序執行次序，是須要按照工序路線的前後次序來執行的，也就是說計劃中，除了須要分配好的資源外，還要確保這個資源在指定的時間段內，沒有被其它產品的生產任務佔用。那麼當同時對多個產品進行排產時，各個產品的工序路線造成的工序生產序列和資源分配方案，很容易就造成了膠着狀態，甚至在多個資源之間會出現死鎖狀態。工具
下面，咱們以多個不一樣種類的機臺，處理工序路線上多個工序的案例，來計劃「多工序、多資源種類」的狀況，並分析須要實現這種計劃，所需的技巧、技術難點和可能出現的狀況，及其應對方法.post
多工序與多機臺的場景描述
規劃過程當中用到的概念
爲了便於描述規劃過程當中的各類狀況，現先定義如下概念：學習
任務或生產任務：一個產品的一個工序的生產做業稱做一個任務，例如印刷後加工有：過膠 -> 燙金 -> 絲印，則表示這個產品的後加工中有三個任務，分別是過膠任務， 燙金任務和絲印任務。優化
工序路線任務鏈：一個產品中的不一樣工序對應的生產做業，其次序是由其工序路線肯定的，一個產品的全部生產做業序列，即任務序列，稱爲工序路線任務鏈.
機臺任務鏈：多個任務被分配在一個機臺上時，同一時間只能處理一個產品，即同一時間只能進行一個任務，這些同在一機臺上造成的任務序列，稱爲機臺任務連接.
前置任務，後置任務：同一產品上多個任務，根據工序路線的規定造成與工序次序一次的生產任務次序(即工序路線任務鏈)。在鏈中兩個相鄰的任務，前者稱做後者的前置任務；後者稱做前者的後置任務。
前一任務，後一任務：分佈於同一機臺上的多個工序任務（即機臺任務鏈），在機臺任務鏈中相個相鄰的任務；前者稱爲後者的前一任務，後者稱做前者的前一任務。
多工序、多機臺排程裏的限制
下面咱們來針對實用性最強，製造業面對最多的場景 ：多工序、多臺機臺場景展開討論。處理這類生產計劃，有如下兩個因素處理起來最爲麻煩。
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排程引擎，都仍是在不斷探索中，有不正確的地方，還請多多提點。爲謝。
本系列文章在公衆號不定時連載，請關注公衆號（讓APS成爲可能）及時接收,二維碼：
如需瞭解更多關於Optaplanner的應用，請發電郵致：kentbill@gmail.com
或到討論組發表你的意見：https://groups.google.com/forum/#!forum/optaplanner-cn
如有須要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人平常工做繁忙，經過微信,QQ等工具可能沒法深刻溝通，較複雜的問題，建議以郵件或討論組方式提出。(討論組屬於google郵件列表，國內網絡可能較難訪問，需自行解決)