前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇生產計劃的定義范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

生產計劃的定義范文第1篇

關鍵詞：映射機制；客戶訂單；生產計劃；ER模型

中圖分類號：THl66 文獻標識碼：A 文章編號：1009-2374（2013）19-0040-03

1 概述

訂單是是生產企業與客戶之間進行業務確認的法律依據，根據訂單在供應鏈的環節不同可以分為客戶訂單、采購訂單、委外訂單等。客戶訂單是客戶對企業訂貨的憑據，處于企業供應鏈的下游。在市場經濟環境下，絕大多數企業是以面向訂單方式來組織生產，客戶訂單不僅是銷售業務的業務處理源，更是企業生產起點和最終目標。

近年來，有關客戶訂單處理問題已引起不少學者的注意，并展開了不少有價值的研究。李兵等針對虛擬企業環境，使用過程建模技術，研究了將訂單分解為不同任務的方法。楊文華等利用UML方法研究了訂單處理系統的設計分析問題。陳煒婷探討了訂單驅動生產系統中，應用帶保護水平分配機制時，如何對產能分配及訂單接受機制進行優化。李嵐針對訂單數據傳輸及交易、選擇訂單合作伙伴、有效建立滿足企業訂單需求的供求關系等問題，研究了訂單分解算法。倪志偉從排隊論的角度，對訂單處理系統進行分析，建立了基于排隊論的訂單處理系統概念模型。張碩等應用電子訂單分割處理，實現了供應物流與生產進度匹配。總體來看，目前對訂單處理的研究主要集中在商務處理領域，與生產過程密切整合的研究相對較少。本文在分析現有研究成果的基礎上，結合現代企業生產管理的需要，構建了一種客戶訂單與生產計劃映射模型。

2 客戶訂單與生產計劃的關聯模型

2.1 客戶訂單及其數據模型

客戶訂單是一種客戶對企業產品需求的數據形式，客戶每次訂貨對產品的需求可能有一種，也可能有多種，需求時間上也可能有多個，因此一張訂單上經常會有多種產品、多個交貨日期等多樣性信息。在進行訂單處理時，通常將在某個時間對某種產品的需求描述為一個訂貨項目，每張客戶訂單通常由一個或者多個訂貨項目構成。

對于每張客戶訂單而言，其數據模型由兩個層面的信息構成：訂單信息和訂貨項目信息。訂單信息包括：訂單編號、客戶編號、訂單確認日期等，訂貨項目信息包括：產品型號、數量、交貨時間、當前狀態等，如圖1所示。

本文關注的是客戶訂單與生產計劃的關聯關系，因此在構建客戶訂單數據模型時只納入與生產有關的信息，將每個訂貨項目用一個5元組來表達：

根據生產企業訂單管理運作的特點，考慮到對訂單動態跟蹤的需求，本文將訂貨項目的狀態Si歸結為5種，并分別用一個數字進行狀態標識：

0——項目未列入生產計劃

1——項目列入生產計劃，但還未開始生產

2——項目的生產已經開始，但未完工

3——項目已經生產完工，等待發貨

4——項目發貨完畢

2.2 生產計劃及其數據模型

制定生產計劃的直接依據是來自客戶的訂單，通過訂單分解將訂單中的需求信息轉換為生產計劃的源數據——生產需求項目。實際處理中，每個生產需求項目對應于一個訂貨項目，再由每個生產需求項目生成一系列的生產任務，生產計劃就是由生產任務構成的序列。因此，表達生產計劃的數據模型應包含兩個層面的信息：生產需求項目和生產任務。

生產需求項目可用下面的元組來表示：

按最遲完工時間的先后順序將生產需求項目排列一個序列，可得到一個生產需求項目的隊列A：A1，A2，...，AK，其中K為項目總數。

生產需求項目隊列是生產計劃的源數據，通過生產計劃制定之后，可得到一系列的生產任務，每個生產任務可用一個元組表示：

Jk=（ACj，JCk，Pk，NUMk，JSk，JEk） （3）

式中：

按最遲完工時間的順序排列生產任務，便得到一個生產任務隊列J：J1，J2，…，JN，其中N為任務總數，J即為生產計劃。

2.3 客戶訂單與生產計劃之間的ER模型

生產計劃是以客戶訂單為依據制定的，它們之間存在著必然的關聯性關系，明確這種關系對于建立有效的客戶訂單與生產計劃映射機制有著重要作用。參照實體關系模型（ER：Entity Relationship Model），客戶訂單與生產計劃之間的關聯性涉及到四個實體型：訂單實體、訂貨項目實體、生產需求項目實體、生產任務實體，生產計劃以客戶訂單之間的關系可以表達為如圖1所示的ER關系圖。

3 客戶訂單與生產計劃之間的映射模型構建

3.1 映射機制的構建

生產計劃的制定必須將市場需求映射到企業的生產過程中，保證企業制造出來的產品是市場需求的產品。構建有效的客戶訂單與生產計劃映射機制，是實現對客戶訂單執行狀態跟蹤和控制的必備功能，也是實現正確生產的重要保證。

根據圖1所示ER關系模型，客戶訂單與生產計劃之間存在兩次映射：訂貨項目到生產需求項目需求的映射、生產需求項目到生產任務的映射，如圖2所示。首先，利用訂單分解功能將訂貨項目與生產需求項目需求建立起一一映射關系。然后，考慮庫存、在制生產情況和凍結計劃等因素，利用凈需求計算扣除不必要生產的生產需求，進而得到生產凈需求。最后，通過生產計劃制定功能將生產凈需求轉換為生產任務。

3.2 映射過程簡要分析

訂貨項目到生產需求項目需求映射的目的在于從生產訂單中獲取生產計劃的源數據，訂貨項目對生產有需求的話，其狀態標號數必須小于4，生產需求項目隊列的產生步驟如下：取所有狀態標號數小于4的訂貨項目；生成生產需求項目：根據訂貨項目的OCi、Pi、NUMi，生成生產需求項目中對應項目數據，根據交貨期，綜合發貨、運輸等因素的影響，計算生產需求項目的最遲完工時間；按最遲交貨時間順序將生產需求項目排列成一個生產需求項目隊列A：A1，A2，…，AK。

在獲得生產需求項目隊列A后，需要進一步根據A來制定生產計劃，轉換為一個生產任務隊列，具體步驟如下：按最遲完工時間順序依次取生產需求項目Aj；庫存消抵處理：如果Aj中要生產產品的庫存中已經有，則不必生產；在制品消抵處理：如果Aj中要生產產品的正在生產線上進行加工，則不必生產；根據工作日歷情況確定Aj中要生產產品的開工和完工時間，得到對應的生產任務Jk；按最遲完工時間的順序將生產需求項目排列成生產計劃J：J1，J2，…，JN。

4 結語

客戶訂單是制定生產計劃的直接依據，構建有效的客戶訂單與生產計劃映射模型，是實現對客戶訂單執行狀態跟蹤和控制的必備功能，也是實現正確生產的重要保證。本文結合現代企業生產管理的需要，構建了一種客戶訂單與生產計劃映射模型，明確了從客戶訂單到生產計劃的信息傳遞關系，構造了客戶訂單與生產計劃之間的ERP關系模型和映射機制。本文旨在拋磚引玉，為面向訂單生產模式下的客戶訂單與生產計劃之間關聯映射方法的研究提供有一定價值的參考。

參考文獻

[1] 李兵，李莉.工作流技術在虛擬企業訂單分解上的應用[J].計算機工程與應用，2003，7：28-31.

[2] 楊文華，張曉豐.基于UML的訂單處理系統的分析和設計[J].微機發展，2002，4：92-95.

[3] 陳煒婷，龔錫挺，王其文.訂單驅動生產系統產能分配與訂單接受優化決策[A].第三屆（2008）中國管理學年會論文集[C].2008，（11）.

[4] 李嵐.基于中間件的B2X協同電子商務平臺及其訂單分解算法研究[D].浙江工商大學，2011.

[5] 倪志偉.基于排隊論的訂單處理系統建模與仿真

[D].北京交通大學，2009.

[6] 張碩，王利芳.電子訂單分割在汽車制造業中的應用[J].物流技術與應用，2009，（4）.

[7] 曾洪鑫.基于狀態樹與時間處理的機械產品流水裝配生產計劃與調度[D].華中科技大學，2005.

生產計劃的定義范文第2篇

關鍵詞：SAP；生產計劃與控制模塊；生產訂單；配置

中圖分類號：TP315 文獻標識碼：A文章編號：1007-9599 (2011) 13-0000-01

SAP Production Order Function System Implementation Cases

Hou Yue

(China National Offshore Oil Corporatio,Information Technology Center,Beijing100010,China)

Abstract:SAP production planning and control module is based on production order to actualize the function of production control.In order to accommodate with diverse business characters and demands of manufacturing enterprises,SAP system allows setting parameters of the production order via background configuration.With the purpose of utilizing the function of SAP production order flexibly and effectively,this paper gives a brief introduction on the relevant configurations,and discusses how to set the value of these configurations to meet the business demands.

Keywords:SAP;Production Planning and Control Module;Production Order;Configuration

ERP（Enterprise Resource Planning）的核心思想是通過事先計劃與事中控制來實現對整個供應鏈的有效管理，以求最大限度的利用企業現有資源，實現企業經濟效益的最大化。SAP系統就是一個基于ERP管理思想的軟件，也是目前市場上較為領先的管理軟件。生產計劃與控制模塊（Production Planning and Control，以下簡稱“PP模塊”）是SAP系統的一個重要模塊，處于企業內部供應鏈的核心地位。

不同行業的生產型企業有著不同的生產模式，對于生產過程控制和生產經營管理有著千差萬別的需求。如何靈活的運用SAP系統來滿足企業需求，適應不同生產型企業的業務特色，是系統實施的一大難題。SAP提供了系統后臺參數配置這樣一種靈活的解決方式。本文將介紹常用的生產訂單相關配置項及其含義，并結合實際生產業務探討如何對這些配置項進行賦值。

一、定義生產訂單類型

一個生產型企業可能生產多種產品并采用不同的生產成本結算方式，因此需要通過生產訂單類型來加以區分。在生產訂單類型中，將配置成本結算參數文件和功能范圍兩個參數。在結算參數文件中，定義訂單的分配結構，定義訂單發生的費用是按百分比、權數還是金額的方式結算出去，定義訂單的有效結算接收方，設置訂單是否允許、禁止還是必須結算到這些接收方，定義結算的憑證類型；在功能范圍中定義訂單歸集的費用進入到哪個成本類別。

二、定義訂單類型相關參數

生產訂單類型可以用于區分不同產品的生產及結算模式，但在生產過程中具體生產方案的選擇、原材料的采購方式等仍然需要通過進一步的系統配置來實現。其主要配置對象包括：是否由系統自動選擇相應主數據，是否允許在創建訂單時手動選擇數據，在生產訂單創建或是生產訂單下達這兩個不同的時間點產生系統預留或是采購申請，以及配置相應的計劃成本核算變式和實際成本核算變式。

三、生產訂單編號范圍

一般來說，生產訂單編號范圍與生產訂單類型一一對應，針對每個生產訂單類型，在SAP系統內定義一個唯一的號碼段，以此通過生產訂單編號更加直觀的對不同生產訂單類型加以區分。在配置號碼段時，需要注意號碼段之間不能存在重疊，并且設置此號碼段是由系統自動給號還是允許手動給號。

四、為生產訂單定義計劃參數

生產排程是生產訂單的重要功能，根據在生產訂單中維護的計劃生產開始時間或是計劃生產結束時間，結合裝置產能和生產加工時間，備料時間等信息，SAP系統將給出最終的排產結果。計劃參數一般與所配置的生產訂單類型一一對應。其主要配置對象包括：在調整日期中配置是否根據生產日期調整基礎日期，以及相關需求的日期是如何確定的；計劃類型決定排程將以何種方向（倒推排程或向前排程）進行；通過訂單縮減配置項決定是縮減訂單中所有操作的提前期或是只縮減關鍵工序的提前期。

五、定義確認參數

生產計劃的定義范文第3篇

【關鍵詞】 活動工期； 生產單元； 成本控制； 遺傳算法

【中圖分類號】 F272.3 【文獻標識碼】 A 【文章編號】 1004-5937（2017）04-0030-05

一、引言

據《中國船舶報》顯示，船舶行業重點監測的94家企業2016年1―5月同比主營業務收入下降3.8%，同比利潤下降22.3%。勞動力成本上升，船東頻繁修改合同訂單導致生產計劃調整，生產節奏打亂，按計劃交船困難重重，致使造船企業成本增加，我國造船企業財務管控壓力[1]、盈利難問題仍然突出。針對船舶建造過程中“邊設計、邊生產”特點，動態監控成本，保證目標成本的控制，進一步提升造船企業成本管控潛力已迫在眉睫。以生產單元或作業區為生產組織形式是現代造船業的明顯特征[2]，生產單元中作業工序對稀缺性資源爭奪加劇，生產計劃調整導致工期的不確定性，如何在活動工期、作業工序的前后順序及制造過程消耗資源的約束條件下，有序合理組織安排生產單元中作業工序，保證生產單元任務計劃的有效實施，使分解的目標成本得以控制，成為亟待解決的問題。

近年來，許多學者致力于生產單元成本控制問題研究，鐘宏才等[2]運用成組技術實現生產單元滿足一定節奏的批量化生產；劉玉君等[3]實現了船舶管系生產計劃系統的開發；蘇翔等[4]通過增量接收技術構建動態成本控制系統，實現成本管理重心前移至事中控制；吳君民等[5]通過和聲搜索算法，尋找船舶分段建造的成本與工期雙優化；戴祥斌和徐心淵[6]實現了多項目并行的海工船項目進度安排及糾偏；趙東方等[7]研究了動態環境下生產單元組織行為建模，減少環境不確定性的影響；陳占奪[8]研究了船舶設計成本管理方法與內容，對船舶成本管控進行了補充。上述研究文獻雖然運用成組技術，實現生產單元批量化生產，有效降低生產制造成本，但仍有大量單件、小批型生產單元無法通過成組技術改變生產組織方式，達到降低其制造成本的目的；另一方面，一些學者局限于船舶分段或生產單元的成本與工期的研究，忽略了多資源限制及活動工期對資源調配、作業工序安排的影響。實際的生產作業中，造船企業單件小批生產單元既受多種制造資源限制，又受到“邊設計、邊生產”造船特點影響，更改生產計劃，打亂生產節奏。

針對上述問題，如何在滿足活動工期、資源及成本三者條件下柔性組織生產形式、優化作業順序與及時反饋制造成本，是控制該類型生產單元成本的重要問題。因此，本文將在現有成果的基礎上，結合造船企業特點，充分考慮遺傳算法具有極強的計算能力和搜索能力的特性，對活動工期下造船企業單件小批生產單元成本控制進行研究。

二、基于活動工期造船單件小批生產單元成本控制模型

（一）活動工期下造船單件小批生產單元成本控制思想

根據船舶建造計劃的進度安排，可以明確知曉生產單元建造工期；根據生產工藝明確生產單元中任務包的生產過程正常需要消耗制造資源，例如作業人員工時數、機器工時數、生產場地面積等。從短期來看，在實際的生產單元制造過程中作業人員工時數、機器工時數及生產場地面積等資源是有限的或是擴充有高額成本代價的。活動工期下造船單件小批生產單元的成本控制目標是在目標分解成本、工期拖期懲罰與制造資源限制或資源可擴充但有代價的約束情形下，有序合理組織安排生產單元中作業工序，保證生產單元任務計劃的有效實施，實現生產單元滿足既定工藝路線下的制造成本最低，使分解的目標成本得以控制。

三、模型求解

從模型7可以看出，函數目標是分段函數的整數規劃問題。常規分支定界、整數規劃法與枚舉法計算量比較大，容易導致局部最優。本文選擇遺傳算法求解，其優越的全局搜索性，并行計算及快速的收斂性[9]，大大減輕工作量。就上述模型，下面給出遺傳算法下求解模型的邏輯或者流程。

若可以在資源限制內按期完成生產單元任務，那么決策者一定選擇既不擴充資源也不拖期的生產計劃。因為只要在資源約束內，資源使用在時間上的分配不影響任務消耗資源所產生的成本，即資源總成本一定。而拖期罰金只在拖期時存在，按時完成時并不存在。于是，在資源限制內按期完工成本最低。在必須拖期或必須擴充資源情況下，決策者將權衡兩者所增加的成本，做出拖期、擴充資源或兩者分攤增加成本，以獲得最小成本。為了解決該問題，下面給出壓縮量、可壓縮工序、可壓縮時點、可壓縮量及壓縮比例的定義。

定義1：壓縮量是指資源受限，工期剛性方法給出的計劃的實際工期大于工期限制的部分。

定義2：可壓縮工序是指在資源受限，工期剛性方法給出的計劃中，實際開始時間早于其只考慮工藝流程而不考慮時間的最早開工時間的工序。

定義3：可壓縮時點是指可壓縮工序的實際開始時間點。

定義4：可壓縮量是指可壓縮工序的實際開始時間和最早開始時間的差值。

定義5：壓縮比例是指一道工序的開始時間的提前量與該工序的可壓縮量的比值。該處理邏輯如圖1所示。

圖1中的處理邏輯將資源可擴充但有代價、工期柔性問題簡化成為資源有限、工期柔性問題求解，再通過壓縮比例對已有計劃安排進行修正。這樣的修正將改善原有計劃的拖期情況，將原計劃中因拖期造成的成本部分轉移到資源擴充中，以達到成本最小。

該邏輯是在一個已有計劃上進行改善，所以很難通過改善一個成本很大的原計劃得到一個令人滿意的修正計劃。因此，原計劃的選取仍應為一個較優解。原計劃是在不擴充資源條件下進行的，不存在擴充資源造成成本增加，所有高出基本成本的這部分成本都來自于拖期時間。因此拖期時間越小成本越小，即工期越短成本越小。然而對一個以工期最短為目標安排的計劃通過設定壓縮比例調整，并不能保證得到的是一個最優或者令人滿意的計劃。因此，在使用這一邏輯處理時，原計劃的選取和壓縮比例的確定成為兩個核心問題。

將這兩個問題中的任何一個孤立地加以解決，都難以得到較優的計劃。必須將原計劃安排和壓縮比例設定封裝，再通過對其成本比較尋找出的結果才可能是令人滿意的。也就是說，在搜索原計劃的同時，就應設定合適的壓縮比例對其修正得到修正計劃。再直接考察修正計劃的表現，搜索最優計劃。為了將這兩個問題封裝，本文設計雙鏈遺傳算法流程，如圖2所示。

四、算例驗證

CX船廠是國內一家中大型修造船企業，以該船廠某一單件小批生產單元為例，該生產單元中LFD1008任務包含6個作業工序，受3種資源的限制，其網絡計劃圖如圖3所示。原工期為25小時，由于船東修改訂單，分解新的生產計劃，該任務設定計劃工期為19小時，拖期懲罰為每小時0.2萬元，目標分解制造成本25萬元（不含物料及間接分擔成本），各工序加工與資源耗費情況如表1所示，資源價格如表2所示。

本文采用Matlab2010a編程對模型求解，設置采用的具體遺傳參數有：種群規模為20，最大迭代次數為500，交叉概率0.8，變異概率0.2，運算結果形成選取的最優優先級和壓縮比例組合如表3所示，計劃安排如圖4所示，各類資源消耗如圖5所示。

由上述運算結果可知，在資源不可擴充，工期剛性條件下，LFD1008任務最小工期是21小時，如果船東沒有修改訂單，正常可以完成任務。船東修改訂單后生產單元在新的計劃工期、資源條件下，通過對作業工序優化，也不可能完成該任務。通過對資源的擴充，考慮拖期懲罰成本，實現在活動工期下，制造成本最低，即對非正常資源消耗最低，按照模型優化具體作業安排如表4所示。由表4可知，實際加工工時為20個工時，超出計劃1個工時，懲罰成本為0.2萬元；同時第7個加工工時，資源2超出資源限制1個單位資源，資源3超出了資源限制2個單位資源，根據資源價格及實際工期計算出總成本為24.13萬元，其中懲罰成本0.2萬元，正常資源價格生產成本為22.89萬元，資源擴充增加額外成本1.04萬元，使總成本提高了5.42%，仍在目標分解制造成本25萬元控制范圍之內。

五、結論

生產單元是造船企業的重要生產組織方式，新的船舶經濟形勢下船東頻繁修改合同訂單導致生產計劃調整，生產節奏打亂，工期不確定性。活動工期下單件小批型生產單元的制造環節的成本控制對執行目標成本管控、反饋設計、實現降本增效至關重要。本文構建活動工期下的滿足目標分解成本與制造資源可擴充情形下的造船單件小批生產單元制造環節的成本控制模型，給出遺傳算法下求解模型的邏輯或者流程，并結合某船廠加以驗證。結果表明，通過該模型優化可以實現活動工期、拖期懲罰與制造資源可擴充但有代價的約束情形下，有序合理組織安排生產單元中作業工序，保證生產單元任務計劃的有效實施，實現生產單元滿足既定工藝路線下的制造成本最低，使分解的目標成本得以控制，提高企業的經濟效益，避免不合理占用車間工人作業時間，減少生產過程中不合理趕工現象，在實踐中具有較強的應用價值，可為其他制造型企業作業計劃安排及成本控制提供參考，同時也為造船企業實現準時化生產提供有效的管理手段，幫助企業提高核心競爭力。

【參考文獻】

[1] 干勝道.企業財務壓力：來源與管控[J].會計之友， 2016（9）：20-22.

[2] 宏才，蔣如宏，譚家華，等.造船專業化生產單元模型及其作業安排優化[J].中國造船，2004，45（2）：7-13.

[3] 劉玉君，李瑞，■田邦裕.基于約束理論的船舶管系加工進度計劃系統研究[J].中國造船，2011（1）：201-208.

[4] 蘇翔，潘燕華，寧宣熙.基于大型單件小批生產的MBOM增量接收研究[J].中國管理科學，2004，12（2）：73-77.

[5] 吳君民，陳明菲，鞠可一，等.基于和聲搜索算法的船舶分段工程項目工期―成本優化[J].財會月刊，2015（18）：68-70.

[6] 戴祥斌，徐心淵.基于比功率法和利用系數法的HAB（WB）照度計算在海工船上應用[J].船舶與海洋工程，2015（3）：50-56.

[7] 趙東方，張曉冬，章恩武，等.動態制造環境下生產單元組織行為建模研究[J].軟科學，2015（10）：136-140.

生產計劃的定義范文第4篇

關鍵詞：Agent模板語言；多Agent系統；產生式編程；Grammarware；黑板；JADE

中圖分類號：TP311.52文獻標識碼：A

文章編號：1001-9081(2007)04-0868-04

0引言

基于Agent的計算被認為是一種新的軟件開發的范式，在軟件工程、分布式系統開發和智能系統開發上都能夠發揮重要的作用。為了構建可靠、有效的基于Agent和多Agent系統的應用，研究人員提出了很多方法學與建模方法。例如在方法學方面的AAII方法學和Gaia方法學等；在結構方面包括慎思、反應以及混合等一系列結構。

盡管研究人員提出了很多Agent的結構和一些方法學來構造面向Agent的系統，但是這些方法多基于傳統的面相對象分析/設計（OOA/D），有些采用靜態、非分布軟件結構的建模，不符合Agent所處的動態分布環境;有些結構較為復雜，且一般集中于對單個系統的設計，缺乏針對不同應用的靈活性，使得在Agent開發中針對不同應用進行了大量重復工作，降低了開發效率。

借鑒Grammarware的工程化[1]與產生式編程[2]思想，基于以黑板系統為基礎的單Agent結構，提出了一種稱為AgentPatternLanguage(APL)的模板語言[3]，用來在較高的層次上抽象描述Agent中針對具體應用的數據類型、知識源組件等，并由Agent解析、轉換為執行代碼，通過這種方式，實現對于Agent與MAS自頂向下的構建，從而提高系統開發效率，增強系統靈活性與可復用性。

1基于黑板系統的Agent結構

APL語言主要針對基于黑板的Agent結構[3]，由黑板存放Agent的運行信息，與知識源相互協作完成特定的功能，整個Agent負責由APL文件生成可執行代碼，完成APL說明的目標。根據文獻[1]中作者對于Grammarware進行工程化開發的原則，以APL定義的語法作為base―linegrammar，進而通過定制APL文檔，描述Agent知識源等組件；同時基于黑板的Agent結構借鑒產生式編程的思想，解析APL文檔，最終實現為針對具體應用的系統。同時可根據不同的知識源運行策略來實現反應型或慎思型Agent的特點，從而增強Agent的靈活性和復用性，提高針對不同應用的Agent的開發效率。圖1是基于黑板的Agent結構。

1.1Agent結構

1.1.1黑板與知識源

黑板是Agent的全局數據庫，主要包括數據對象結構與子句對象結構兩部分。

數據對象結構是由一組有限數據對象類型的實例構成的集合。數據對象類型用來描述一類數據對象，包括一個類型名和屬性集合，其中屬性用來描述數據對象的特征，一個屬性定義包括屬性名與屬性類型。

3)前提條件PreCondition是一個布爾表達式，由條件語句以及關系實例構成；

4)后置條件PostCondition是一個集合，包含在知識源運行完畢后需要更新黑板上的數據對象及子句對象實例。

1.1.2消息相關知識源和規劃庫

知識源MessageInput負責Agent與其他Agent之間的消息收發，而知識源MessageHandle負責處理接收到的消息。此外還有一些其他的模塊支持Agent的運行。

當MessageInput接收到一個外界到達的消息后，將其放在緩沖隊列中，并通過事件通知MessageHandle。MessageHandle收到消息后，就等待ControlContext選擇。被選中執行后，MessageHandle根據運行中的目標結構與規劃從緩沖隊列中選擇消息，根據消息內容更新黑板變量。各目標結構在運行中所需要發送的消息也放在緩沖隊列中。MessageInput監測到緩沖隊列中有消息要發送，就等待ControlContext選擇，選中后將隊列中消息發送出去。

為了在實際應用場景中支持MAS的開發與運行，基于黑板的Agent是在JADE[4]平臺上實現的。Agent之間利用ACL（AgentCommunicationLanguage）進行通信，MessageInput、MessageHandle知識源負責消息的處理。這里采用集中的消息處理是為了避免GoalStructure知識源各自進行消息收發可能帶來的錯誤，并且可以根據需要用恰當的消息更新黑板。

此外，知識庫Knowledge存放Agent運行所需的一些全局知識，而規劃庫PlanLibrary中存放用于不同目標結構的規劃。規劃由名稱、objective（規劃針對的目標結構名）、PreCondition（規劃執行所要滿足的條件）、優先級以及規劃體組成，規劃體采用確定有窮狀態自動機DFA表示，其中狀態之間的轉換由一組Transaction（一組完成一定功能的動作）和GoalStructure組成。根據Agent運行的上下文，Plan選擇不同的狀態轉移，最終達到終結狀態，完成規劃執行。

1.1.3控制機制

根據上面的介紹，ControlContext協調不同的知識源協同工作完成特定的目標，其中由議程表Agenda變量控制知識源的執行。每個目標結構知識源有一個初始的優先級，而MessageHandle和MessageInput的優先級最高。當Agenda打開時，ControlContext選擇處于Active的知識源準備運行，選定后關閉Agenda。如果MessageHandle或MessageInput被選中則執行相應的功能。若某個GoalStructure被選中，如果該目標結構是首次執行，那么根據Agent當前的環境上下文，從PlanLibrary選擇一個合適的Plan；如果目標結構已經選定了Plan并已經開始執行，那么就根據Plan當前的狀態與環境上下文選擇狀態轉換（可能是Transaction或GoalStructure）執行一步（如果選中子目標GoalStructure，則保存當前目標，先執行子目標）。當MessageInput、MessageHandle完成處理，或GoalStructure執行完一步，打開Agenda，開始下一輪選擇。控制過程參見圖2。

當ControlContext連續選中同一個目標執行的時候，其優先級相應增加。而有時候因為環境的動態變化，一個高優先級的GoalStructure會打斷當前正在執行的GoalStructure。可以通過指定不同的策略決定GoalStructure之間的競爭策略，使Agent在對于環境的反應性和對目標的堅持性上做出平衡。

2APL與場景示例

2.1Agent模板語言APL

前面介紹的Agent結構，在針對不同的應用時，需要不同的配置信息，如針對于特定應用的數據類型、規劃、不同目標結構的調度策略等，這些信息可以通過APL語言來描述。目前APL主要描述應用場景中的三方面內容：1）表達數據對象類型，子句對象類型以及它們的實例；2）描述目標結構知識源，包括目標名，輸入變量集，前提條件，優先級等內容；3）描述針對不同目標結構的規劃的相關信息，包括規劃名，Objective，規劃體，前提條件等。這里采用XML進行表達，因為XML具有較強的適應性，并且可以簡化編譯/解釋器的構造。

從圖1可以看出，Agent中有一個APLParser解析器部件。Agent在運行中與具體應用相關的知識，包括各種數據對象實例、子句對象實例、GoalStructure的實例、規劃Plan的實例等，都編制在APL文件中，在Agent初始化時由APLParser解析APL文件，并生成各種實例的對象，而后Agent按照上面介紹的Agent各個部件的運行機制，完成指定的目標。

2.2場景描述

這里采用一個企業業務過程管理的場景來說明基于黑板的Agent結構與APL結合如何實現特定的目標。利用MAS進行業務過程管理，將業務過程委托于不同的Agent。Agent通過對環境的觀測和與環境的交互，根據環境和業務策略，可以對業務過程管理中動態的變化做出實時、甚至預動的反應，展現出目標導向的特點[5]。

考慮如下場景。某汽車制造商由若干部門組成：幾個生產車間（用AD表示）；幾個市場部門（MD），其中每個市場部門負責處理一個地區的訂單；一個調度部門（SD），調度部門主要負責為生產車間制定生產計劃。當有新訂單到達時，SD要根據到達的訂單以及當前已經制定的生產計劃生成新的生產計劃，并發送給各AD。此外，AD可能因為故障等原因，不能按期完成計劃，將這個情況發送給SD后，SD要修改當前生產計劃，并將修改后的計劃發送回各AD。場景描述以及消息往來示例參見圖3。

2.3場景實現

這里從調度部門的角度進行分析。假定每個部門或生產車間都有一個Agent。生產部門的Agent負責接收生產計劃與異常情況的發送，市場部門的Agent負責向SD發送訂單，并接收對訂單的確認。這些Agent構成一個MAS,Agent之間相互通信，通過交換數據與控制信息來協同生產過程。

首先，要用APL表達與生產過程控制相關的關鍵信息。對于SD，應該在黑板上記錄如下信息：MD發送過來的訂單信息；為每個AD制定的生產計劃信息;AD發送過來的異常信息。根據前面的形式化定義，APL要表達出這些信息涉及的數據對象類型，每個類型的實例，所用到的關系以及關系的實例等。下面的代碼展示了訂單類型的定義。程序前

注意這個目標結構的輸入變量集分為三組，每組的成員分別針對不同地區的訂單，當有一個訂單到達，按照1.1.1中介紹的方式觸發該知識源。在ControlContext允許該目標結構知識源的對象開始執行時，該對象在PlanLibrary中查找可以滿足該目標結構的規劃。下面的代碼是用APL表達的規劃Plan的示例：程序前

這個規劃有三個狀態，通過兩個狀態轉換（< tr >標簽）順序連接起來。第一個狀態轉換是TransactionprocessOrder，判斷到達的訂單是否可以接受。第二個狀態轉換是一個子目標，根據前面的Transaction計算得到的結果，如果接受訂單就計算新的生產計劃，并放入發送隊列;如果是拒絕訂單，就生成拒絕訂單的消息，并放入發送隊列中。

圖片圖4SD、AD、MD間消息的交換與SDAgent運行控制信息

此外，場景中還需要一個目標結構以及對應規劃來實現向AD發送生產計劃的目標，和用于處理AD發送過來的異常信息的目標結構及對應規劃。根據上面的設計，圖4顯示了場景的一個實現結果，由JADESnifferAgent顯示了SD、AD和MDAgent之間的消息往來，以及SDAgent中GoalStructure與Plan等的執行情況。

2.4與相關研究的比較

上面的場景是一個較典型的模型，顯示了在生產過程中存在的協作與競爭關系。整個過程需要各個部門（SD、MD、AD）互相交流，互相協調才能完成。而協作中也存在競爭關系，如不同目標由于優先級的不同而帶來的競爭等等。要處理好這些競爭，需要設計比較完善的規劃、調度算法，融入到Agent的運行中。

在文獻[6]中提出采用基于黑板的Agent結構處理企業中過程計劃與生產調度的生成。這里知識源處理生產調度/規劃中出現的問題利用，以此提供靈活、用戶導向的處理方式。但在面對不同企業不同的業務需求時，其知識源的編制需要根據具體的業務場景來編制，可能帶來大量的重復工作，缺乏APL與黑板Agent結構結合帶來的靈活性。

在由漢堡大學開發的JADEX中[7]，采用了Agent定義語言（AgentDefinitionLanguage，ADL）描述Agent運行時需要的內容，包括所需的對象和變量等。通過這種方式能夠給針對不同應用場景的Agent的開發帶來一定靈活性。但是其描述文件的抽象層次比較低，文件定制不夠方便，而APL可以借助一些工具，使系統設計人員能夠方便的生成APL文件，提升開發效率。

3結語

在基于Agent與MAS的系統中，利用模板語言APL從應用場景中抽象出數據類型和組件等的描述，自頂向下完成MAS的開發。一方面，增強了Agent針對不同應用場景的適應性，以及Agent的可維護性與健壯性，另一方面也提高了Agent開發人員的開發效率。在給出的場景中，它使得部門更加適應內部組織以及來自市場的變化，為業務過程管理提供更大的靈活性。在進一步的工作中，可以借鑒WebService研究中的成果，擴充APL的定義，包含更加復雜有效的業務流程描述；在Agent中引入較為復雜的控制機制，提升Agent的性能；也可以采用本體等方式來豐富黑板上所記錄信息的語意內涵。

生產計劃的定義范文第5篇

關鍵詞：生產管理系統；物料管理；系統設計

隨著經濟的飛速發展，利用生產管理系統進行企業的信息化建設，來推動生產企業管理的科學化、規范化，已經成為企業管理中的重要組成部分。開發出一款適合現代制造企業要求、符合企業實際情況的生產管理系統是非常必要的I由于利用目前已有的ERP系統進行改造的難度較大，實施起來難度也高。而市場現有的MES軟件產品還不完善，多少都存在一些不足之處，沒有完全實現制造執行系統的集成化，在軟件的實用性、重構性和擴展性等方面存在一些弱點。所以本文提出一種的基于物料的企業生產管理系統，可面向于離散生產企業。本系統將根據物料約束、生產資源能力等約束條件，形成系統的生產作業計劃，根據生產訂單要求和交貨日期自動拆解生產計劃并進行排產，可實現生產計劃的跟蹤調度和可視化，提高資源利用率和企業的管理效率。

1.生產管理系統的業務流程

現代制造型企業的生產管理主要是以客戶需求為核心的，根據銷售產品的供應鏈對生產管理開展相關的業務，主要包括如下幾項：

1）生產計劃管理：為了保證生產過程中所需物料的數量及物料的供給時間，要對生產計劃進行相應的管理，制定出公司的主生產計劃。

2）車間管理：為了保證車間生產的正常進行，要對車間進行管理，確定與車間生產所需的原材料、及其他相關的產品資源信息。

3）物料采購管理：對原材料及其他相關物料的采購流程進行管理，對采購訂單等信息維護，以保證產品生產過程中物料的正常供給。

4）產品銷售管理：對產品銷售的流程進行管理，包括對銷售訂單等信息的各項維護操作，目的是為了保證產品庫存數量在正常合理。

5）庫存信息管理：對庫存信息進行相應的管理，可實現原材料入庫、出庫，產品的入庫、出庫、損耗等業務管理。

6）質量管理：為保證產品的質量，生產管理業務中的質量管理是重中之重，是保證公司信譽的一個重要方面，包括對原材料的質量檢測、對成品、半成品的質量檢測等，質量管理是提高公司質量水平的一個重要環節。

7）總帳管理：對公司的生產管理過程中涉及的財務賬目進行管理。企業生產管理流程如圖1所示。

2.系統總體設計

根據對生產管理系統所做的需求分析，可以明確該系統主要由基本數據管理、生產計劃管理、車間管理、采購管理、銷售管理、庫存管理、質量管理、總賬管理和系統管理等九個功能模塊組成。如圖2生產管理系統總體功能結構圖所示。

其中每個功能模塊又由若干個子功能模塊組成，一起實現了公司的生產管理中各項業務的管理功能。

1）基本數據管理模塊。主要對生產管理系統中的基本數據進行設置。

2）生產計劃管理模塊。主要是ι產計劃的信息進行管理。包括：生產計劃的定義、產品需求與預測、主生產計劃管理、物料計算、資源定量管理和資源使用情況統計等子功能模塊。主要完成對生產計劃相關信息的管理與維護、對產品需求量的預測、制定主生產計劃（包括管理計劃的起始時間、結束時間、產品需求量、預計庫存量等信息）、計算生產所需物料的需求數量與使用時間、定時對資源的使用情況進行查詢，并將所需數據形成報表進行輸出。

3）車間管理模塊。對生產車間作業所需要的數據、產品的相關數據及流程等進行管理。包括對生產過程所需物料的管理，對產品入庫、出庫等的管理，對生產的流程的跟蹤，對生產過程進行實時管理，可計算出計劃成本與實際成本間相差的數據，還可對車間工人的工作量、車間生產的費用等進行統計查詢，并生成報表輸出。

4）采購管理模塊。可對生產所需的原材的訂單進行管理，錄入、查詢等操作。

5）銷售管理模塊。對要銷售的產品訂單信息進行管理，包括對銷售產品的信息錄入操作、對已銷售產品退貨信息的管理、對歷史銷售信息進行查詢操作。還可根據原材料價格的浮動、產品生產成本的改變，自主地對產品定價進行調整。

6）庫存管理模塊。對產品及物料的庫存進行管理。包括查詢、調撥、盤點等操作。對產品或物料庫存設置上限值與下限值，當數據不在正常范圍內，系統可自動報警。

7）質量管理模塊。根據企業的產品質量控制體系，對成品、半成品及原材料等的質量把關。

8）系統管理模塊。對用戶基本信息、權限等進行管理、對數據庫進行備份等操作，以保證系統數據的安全性。

3.生產計劃管理模塊的設計

本文通過物料約束、生產資源能力約束等條件，形成系統的生產作業計劃，調度人員根據生產作業計劃，結合實際情況制定可行性方案，大大地減少了計劃排程的工作量，也可有效地提高了資源的利用率，實現了生產計劃的可視化和提高了透明度。

該模塊利用了遺傳算法，能充分考慮車間的產能和設備資源的可用狀態，可進行多目標優化操作，根據排產結果可提供幾個可供選擇的方案，并可利用仿真技術驗證這幾種方案的可行性，并提供友好的可視化界面。大大減少了計劃員的工作量，方便他們進行最佳方案的選擇。其中，工序時間利用仿真手段來確定。財用仿真技術可以利用已有的排產計劃，計算出每個工位在每個時刻的生產狀態、庫存容量的變化以及機器負載率的變化。利用遺傳算法還可根據工序的優先級和生產條件滿足即可進行生產的原則，計算出生產計劃的總耗時長、所需庫容量數據，關鍵設備負載率等。結果可通過圖表給出，并可實現交互式排產，同時也支持通過拖拽等方式進行人工調整的排產結果。