引言

企業信息可分為企業資源信息、經營決策信息和生產對象信息等。產品數據管理(PDM)信息和企業資源管理(ERP)信息是企業信息的卞要組成部分。是目前企業建設計算機集成制造系統(CIMS)的兩個核心。然而。氏期以來PDM和ERP被分而治之。造成企業信息交換困難。ERP系統所需要的產品數據不能從PDM系統中自動獲得。而要重新手工錄入;同時。由于PDM系統無法對生產成本、加工中心進行及時跟蹤。造成設計與生產脫節。因此。PDM與ERP系統集成己成為企業信息管理的必然趨勢。

目前PDM與ERP系統集成的卞要技術有內部函數調用、直按按口集成、基于中間件的系統集成等。內部函數調用和直按按口集成技術往往需要原系統開發人員的支持。開發工作量大、集成成本高。但可以獲得較高的效率。基于中間件的系統集成由于中間件產品是商業軟件。本身井不夠開放。雖然在集成時避免了對系統底層的操作。減小了開發的工作量。但實時性不高。

針對上述集成技術的特點。本文提出了基于上層中間文件交換和底層中間庫相結合的兩層集成策略:通過上層的中間文件交換解決兩系統間部分關鍵數據的字段映射和結構轉換。實現異步集成;通過底層中間庫。解決兩系統底層大量數據的交換和傳輸。降低集成難度。保證系統集成的實時性。實現同步集成。

1、PDM與ERP的數據交互分析

PDM系統管理所有與產品相關的數據和產品設計的相關過程。而ERP系統則管理企業生產、采購、銷傳、人才、財務、組織等各種資源及生產要素。PDM系統為ERP系統提供了產品設計的相關信息。而ERP系統為PDM系統提供了產品制造成本的相關信息。將PDM系統中的MBOM和工藝路線及產品的屬性等信息傳遞給ERP系統。ERP系統對其進行維護后。根據這些信息生成物料需求計劃(MRP)和能力需求計劃(CRP)來指導生產。同時。ERP產生的CBOM信息和設備動態能力等信息反饋給PDM系統。作為產品設計的參考。并在整個產品的生命周期內。保證MBOM,CBOM及Rou-ting在兩系統中的一致性。實現兩系統間的雙向集成。如圖1所示。

由圖1不難看出。產品設計EBOM、產品制造MBOM、產品工藝路線Routing、產品成本CBOM及工程圖記錄是PDM與ERP系統集成的卞要內容。其中BOM是兩者集成的關鍵

2、系統分析與建模

作為PDM與ERP系統集成的核心部分—BOM。構建時根據需要以不同的數據模刑存儲在不同的系統中。常見的有:樹形BOM。反映該產品所需的原材料、零件、部件及總件之間的從屬關系和數量裝配關系;矩陣形BOM,適用于識別和組合一個產品系列中的通用零件;差異形BOM。以標準產品為基準。規定還可以增加或減少哪些零件。可有效地描述不同產品之間的差異以及模塊化BOM等。

樹形BOM常以多層BOM(圖2)和單層BOM(圖3)分別在PDM和ERP中存取。

如圖2,圖3所示。PDM和ERP兩者BOM的屬性、結構差異較大。在集成時需要分別找出兩者的結合點。

首先，在工程應用中。根據不同的需求。在不同的作業卜。零部件的材料、顏色及所需要加工的尺寸等屬性有所不同。每一個不同都對應一個代號。而根據圖紙代號加工零部件時。要對應相應的物料號。這就說明代號與物料號之間存在A:B=1:1的對應關系。其中A表示ERP中的物料號。召表示PDM中的代號由于這種映射關系的存在。可將代號與物料號作為兩者在屬性上聯系的橋梁。

其次，在結構上。多層BOM向單層BOM轉換。實質上是將一個多階問題展開成多個一階問題來解決。其關系表達為

式中,X0為根節點;括號代表層次(父子)關系;xn為x0的次階(第一階)節點中的第n個節點;xm為x0的第二階節點中的第m個節點，它對應的父節點是xn；x1i為x0的第二階節點中的第1個節點，它對應的父節點是為x1i依次類推;g1為映射規則，轉換后的表達式只有父件和它對應的次階子件之間的關系。

這種轉換需要通過樹的遍歷。但要注意的是。標準樹的遍歷要求結構上一個r節點只能對應一個父節點。這與樹形BOM(EBOM)中同一個r件(r節點)可以對應多個父件(父節點)有所不同。因此。在遍歷節點時。按照父節點和r節點的ID同時遍歷進行修正。

最后，根據不同企業的實際情祝。手工建立代號與物料號之間的對應關系。實現字段映射。所建立的中間文件屬性如圖4所示。

綜上分析。可得EBOM向MBOM轉換的表達式為式

式中，xi為代號;mi為物料號;g2為代號與物料號間映射的關系;attr為兩者共同的屬性;。為映射關系;f為g1、g2、g3的復合映射，通過f實現El3OM->Ml3OM的轉換

所對應的邏輯模刑如圖5所示

這種集成模刑的優點在于不必熟悉PDM與ERP系統底層復雜的數據結構。利用中間文件。完成PDM和ERP系統之間的數據交換和字段映射。保持兩系統間的獨立性。因此，從功能實現的角度上講，利用該模刑能夠較快地實現兩系統BOM數據的集成要求。實現兩系統間的異步集成。缺點是實時性不高。當需要大量的數據交換時。僅僅利用中間文件。效率難以保證。而較好的解決辦法是通過底層進行數據集成。

在底層集成的兩個(或多個)異構的數據源時。簡捷的方法是采用中間庫策略。即通過第二方數據庫作為橋梁。交換不同的數據庫(數據源)中的數據。這里以(Oracle為例。其實現原理是通過使用Oracle的透明網關來訪問其他非Oracle系統的數據。透明網關是指Oracle異構服務中代理的一種類刑。功能較強。蘊含3個卞要模塊:①異構服務模塊。負責大部分異構連按的處理;②代理通用代碼。負責所有基于異構服務系統的通用代碼;③驅動模塊。是與非(Oracle系統直按交互的模塊。實現從異構服務API到特定非Oracle系統API的映射。其中代理通用代碼和驅動模塊是Oracle Server連按非(Oracle系統的進程。內核結構如圖6所示。

通過中間庫。利用Jmu和連按池。以Tomcat作為應用服務器進行兩系統間的信息交換。內部采用觸發器策略。及時跟蹤兩系統內部數據的變化。可以進行連庫查詢(多庫查詢);同時。可以根據集成數據源的不同。進行Sax/Xml按口的轉換與擴展。這種集成模刑的優點是能夠保證兩系統間大量數據交換的效率。有較好的實時性;缺點是在進行復雜數據的字段映射時。僅僅通過中間庫進行傳遞。在算法上難以實現。需要中間文件進行轉換。因此，我們將上層文件的集成與底層數據的集成結合起來。互為補充。建立較為完再的集成模刑。它的實現原理如圖7所示。

3、集成實例

3.1需求分析

為保證PDM與ERP兩系統的有效整合。某企業要求在系統集成前能夠對相關數據的有效性和準確性進行必要的檢測檢測的卞要內容如卜:①檢測井列出PDM中產品刑號、產品編號與ERP中不唯一對應的產品;②檢測井列出PDM中產品刑號與圖號未建立對應關系的產品;③檢測井列出在PDM中存在。但未在ERP中維護的產品;④檢測井列出在PDM中使用。但未在ERP中維護的工序;⑤檢測井列出具有多條工藝路線的產品。

檢測的目的是要求員工對兩系統中不合理的數據進行必要的修正和維護。保證工作質量。提高效率。井把它作為員工績效考核的一個依據。同時也為系統的后續集成奠定基礎。

集成的內容卞要包括:①產品基本數據(包括產品刑號、產品擴展屬性、客戶零件編號等)的集成;②產品BOM數據的集成;③產品工藝路線的集成(手工選擇)。

產品基本數據和產品工藝路線的集成卞要是為保證兩系統間數據的同步。BOM集成包括兩方面:一方面要求PDM輸出EBOM后。能夠自動轉換為工藝部、生產部所需要的MBOM格式;另一方面要求ERP產生的CBOM等信息回傳給PDM系統。作為產品設計的參考。

3.2集成策略的選擇

根據我們對該企業的調研及需求分析。結合計算機技術的發展狀況。提出了該企業系統集成的建設方案。

企業原有的PDM系統卞要面向設計與工藝部。后臺基于SQL Server數據庫。而ERP系統卞要用于物流和生產計劃。后臺基于Oracle數據庫。兩個系統的軟件環境是異構的。輸入(出)的報表格式也有較大差異。集成的兩個系統必須考慮采用分布的、開放的和跨平臺的方案。而且還必須具有高度可靠性、可擴展性、可管理性、數據一致性和應用安全性。同時也要兼顧應用的簡捷性等功能。因此。要使ERP和PDM系統在物理上獨立。但在業務上保持一致。采用圖7所示的集成模刑不失為一個較好的解決方案。

3.3集成實現

采用中間文件交換在上層集成兩個系統的部分BOM信息。由于前面已詳述。這里給出相應的數據轉換。在進行底層數據集成時。采用B/S/D三層架構。這里給出從PDM中選擇新產生的工藝路線導入到ERP系統中的部分實例。通過中間庫。用戶(系統管理員)可以方便地進行數據檢測、數據維護及數據交換。將其與上層的文件集成結合起來。完成整個企業PDM與ERP系統的整合。整個系統運行的拓撲結構如圖8所示

4、結語

針對當前PDM與ERP系統集成的卞流技術。結合企業的具體應用。本文提出的集成模刑有如下特點:

(1)實用性。中間庫利用企業現有的數據庫。可以保持企業原有的投資。有較好的經濟性。集成系統的開發環境、連接池及Tomcat應用服務器不但免費。而且與平臺無關。與集成的應用系統無關。因此。該技術還可以推廣到其他異構應用系統的集成上。具有一定的實用和推廣價值。

(2)異步性。利用中間文件。不僅可以彌補底層數據集成的缺陷。而且可以保持PDM與ERP系統物理上高度的獨立性。這種異步性卞要表現在進行復雜的文件交換和字段映射過程中。

(3)實時性。Java語言本身具有的多線程特點與數據庫的觸發器結合。保證了數據的更新監控和采集功能的并行完成。在一定程度上滿足了PDM和ERP系統集成的實時性要求。

當然，本文的研究還存在不足，還有待于改進。主要表現在擴展性方面，利用Xml雖然可以對數據源進行外包，但不能繼承分布式系統的復雜性。也不能在分布式對象之間提供統一的通信協議。這還需要OMG(對象管理組織)的CORBA(公共對象請求代理架構)定義的接口規范來解決。因此，在系統集成的通用性方面還需要作進一步的探索。