苏亮

摘 要：每个企业随着业务的发展都在不断的扩张，扩张的表面形式就是在异地建设研发中心或者工厂。那么针对这种类型的企业，制定及实施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行业从业人员以启发。