基于本地卷和預加載的PLM系統解決方案介紹

蘇亮

摘 要：每個企業隨著業務的發展都在不斷的擴張，擴張的表面形式就是在異地建設研發中心或者工廠。那么針對這種類型的企業，制定及實施Teamcenter PLM解決方案時，首先要考慮的是就是系統構架要采用什么模式，采用集中式數據管理模式還是選擇Multi-Site的管理模式？本文根據某公司項目實施的經驗，詳細介紹一下本地卷和預加載解決方案，供大家借鑒。

關鍵詞：集中式數據管理 Teamcenter PLM 預加載

1 方案應用場景

目前國內多數大型企業為保持自身的競爭力和產品的市場份額，都會選擇在異地建立研發中心和工廠，如奇瑞、上汽等汽車企業都有自己的異地研發中心/工廠。那么企業總部的IT人員在考慮為異地搭建PLM系統時，首先需要考慮的就是如何管理和維護異地工廠/研發中心的數據。從企業集團的角度出發，為保障PLM系統數據的安全性以及可維護性，最好的方式是將異地工廠/研發中心的數據全部保存在總部的服務器上進行集中式管理和維護。

把異地工廠/研發中心的數據在總部進行集中式管理，則要面臨技術層面的3個問題：

1.異地工廠/研發中心的數據如何安全快速的保存到總部服務器上：異地工廠/研發中心與總部之間通常都是專線連接，考慮到成本因素，通常異地工廠/研發中心與總部之間的帶寬有限，如果采取一般的主/次FMS的文件傳輸方式，帶寬將滿足不了系統數據傳輸的需求。

2.異地工廠/研發中心如何安全快速的讀取自己上傳到系統的數據：異地工廠/研發中心將自己的數據保存到了總部站點，數據讀取的速度同樣受制于帶寬的限制，如采取一般的主/次FMS的文件傳輸方式，帶寬將同樣滿足不了系統數據讀取速度的要求。

3.異地工廠/研發中心與異地工廠/研發中心之間如何保障數據的快速共享。

2 方案原理

以奇瑞實施的異地研發中心數據共享的項目為例，其總部在蕪湖，有2個異地研發中心A和B。同時A和B存在數據共享的需求。為解決上述的3個技術問題，項目中就采用了本地卷和預加載的方案，經過1年多的實際運行，證明此方案可有解決上述三個問題。

圖1為某企業本地卷及預加載解決方案，其中A站點的本地卷為TJ_Volume，B站點本地卷為HD_Volume，預加載為A緩存文件TJ_FSC_Cache和B緩存文件HD_FSC_Cache。該解決方案運行的原理如下表1：

從上述方案中，可以看出這種配置方案的優勢：

●異地研發中心當天產生的數據都會自動從本地卷遷移到總部的卷服務器中，遷移完成后，本地卷中的數據清空。這樣方便總部統一對數據進行存儲、備份和維護，保證了數據的安全性。

●從異研發中心遷移到總部的數據每天也會通過計劃任務自動預加載到異地研發中心的緩存服務器中，這樣保障了異地研發中心客戶端訪問數據的速度。

●異地研發中心與異地研發中心之間的數據也會以預加載的模式緩存到對方的緩存服務器中，異地研發中心之間的數據共享也變得快捷和方便。

3 方案配置詳細說明

3.1 本地卷遷移配置方法

圖表1中節點3和節點9是將異地的本地卷的數據遷移到總部對應的卷中，以節點9為列，其具體配置腳步如表2：

3.2 預加載配置方法

圖表1中節點4和節點8是將總部卷中的當天新產生的數據預加載到各自的緩存服務器中，節點5是將B當天的數據緩存到A，節點10是將A當天的數據緩存到B，其具體的配置腳本如表3：

預加載模式需要程序的開發，需要通過搜索找出當天本地卷產生的數據文件，并把這些文件放置在某一個目錄下，那么專業開發的工具collect_dataset就可實現這個功能，并將搜索出來的數據集存放在infodba用戶下的指定文件夾下。例如：

%TC_ROOT%＼bin＼collect_dataset -u=infodba -p=infodba -g=dba -env=ch -target_group=HDGroup

>%logname%

就是將HDGroup（B組）當天新產生的數據集搜索出來，并放置在infodba用戶下的指定的文件夾下。

4 方案的缺點

該方案的優點已做了詳細描述，但是也存在2個較明顯的缺點：

首先就是首次實施時，需要把異地研發中心所有的數據遷移到總部，所耗費的時間與數據量有著直接的關系。

其次，對異地緩存服務器的硬盤的空間需求較大：隨著時間的增加越來越多的數據需要緩存到異地的服務器，那么對磁盤空間的要求會越來越高。

5 方案總結

該方案乃多個站點企業模式的另一種全新的且有別于Multi-site的PLM解決方案。該方案從硬件構架上來說，簡單經濟。實際運行中，性能亦可滿足用戶對系統性能的要求。此方案的提出，為多研發中心的企業另辟蹊徑，找到一種全新的解決方案。希望通過本文的介紹，給PLM行業從業人員以啟發。