同箱分蜂技术及注意事项

文/叶成刚 吴崇健 李麟 王骏

导读

2015年，笔者所在的公司开始实施PLM升级项目，在原有已实现功能的基础上，完善产品数据的集成管理、零件分类管理、管路的全模型装配、轻量可视化浏览等功能需求。笔者分享了公司的升级方案，并重点介绍了升级实施和应用过程的6大技术要点。

来源：互联网

来源：互联网

1996年我公司引入三维设计软件Unigraphics(以下简称UG)V12版本，正式开启了设计平台的信息化建没之路。2001年实施PDM 系统iman V7，相应的UG为v16版本；2004年升级为TeamcenterEngineering V9(以下简称TCEng V9)，UG升级到NX2。由此，UG和TCE成为我公司技术体系不可或缺的设计工具和管理平台，为新产品研发、订单开发快速响应市场需求，推动企业高速发展发挥了巨大的作用。

TCEng V9完成了物料编码及属性管理、图文档数据集管理、安全权限管理、无纸化审批流程管理、NX集成管理、ERP集成数据发布等功能， 但BOM管理一直在公司自行开发的平台上进行；通用零件库、标准件库也在自行开发的技术共享平台上管理，我公司还自行开发了图纸的批量打印、远程打印等功能。在自行开发诸多功能的补充下，PDM 和CAD系统运行非常平稳。

随着工业4．0时代的到来，整合信息系统、打通信息流转、消除信息孤岛、加强模块化设计等，成为制造业转型升级的必备基础工作。由此，我公司2015年开始实施Teamcenter升级项目，在原有已实现功能的基础上，完善产品数据的集成管理、零件分类管理、管路的全模型装配、轻量可视化浏览等功能需求。

1 PLM系统架构

1.1 Teamcenter10的系统架构与软硬件配置

相比于TCEng V9普遍实施的2层架构(也可做3层布局)，Teamcenter 10 (以下简称TC l0)系统的核心底层发生很大变化，采用4层架构，分别是数据资源层、企业应用层、Web服务层和客户端层，大大增强系统的可扩展性、开放性和稳定性。在通用的4层架构上，我公司还在异地分部架设卷空间服务器， 以加快异地研发人员对产品数据的读写速度。整个系统架构如图1所示。

展开全文

图1 系统硬件架构

其中，服务器选用的均为IBM的X3850 X6服务器， 数据库服务器上安装Red Hat Enterprise LinuxServer 6．4操作系统，其他服务器安装Windows Server 2012，客户端工作站安装Window 7及以上版本操作系统。

1.2 升级方案的选定

由2004年实施的TCEng V9升级到2015年最新版的TC 10，由于版本跨越大，老系统所导出的数据库文件、视图BOM XML文件等， 均不能为新系统直接采用，所以数据直接迁移的方案是行不通的。同时，采用升级方案时，由于32位和64位操作系统、Oracle数据库、TC系统三者间存在相互兼容、相互制约的问题，所以，一个完整的迁移和升级方案将如图2中(1)所示。

综合考量升级效率和数据兼容性，最终采用的方案是：将TCEng V9的Oracle数据库通过迁移并升级至10 G、TC系统升级至8.3这一中间临时系统，然后将数据直接迁移至TC 10，如图2中(2)所示。

图2 TC系统迁移和升级流程

最后一步的迁移方案，并非整个数据库以dmp文件方式进行整体迁移，而是新系统安装完成后，重新建立组织、人员、流程， 以及诸多BMIDE配置，然后将中间临时系统中的零件属性信息、BOM、数据集、流程信息等分别导出并导入，这样可以将老系统中的数据根据需要转八新系统，多年工作留存下来的许多垃圾文件能得以清理。另外，纯粹由升级而成的新系统整体迁移，对诸多新功能是否具备完全兼容性， 还是存在一些不确定性，所以一般不建议采用。

2 升级实施和应用过程的技术要点

2.1 预处理升级过程的多语言适配问题

由于TC8之后，系统多语言支持上的本地化配置方案， 与TC Eng V9时代已经截然不同， 所以在第一步的迁移和系统重构之后，务必把系统配置中的中文内容全部更改成英文。这包括：组织架构(组名、子组、角色)、Item对象类型、单位、注释、变更、状态名、视图名，并清理所有的LOV绑定。其中，Itern 对象类型的中文内容，只能在升级到TC2005之后，在数据库中通过SQL语句进行修改。

如果未更改到位， 则在后续TC2005升级到TC8．3过程中， 会因语言适配问题而导致升级失败，此时再通过SQL语句更改数据库并重启升级过程，操作起来会更加繁琐。

2.2 预处理部分数据集的适配问题

由于TC8之后，PDF等格式已经成为系统的内置类型，而TCEng V9时代PDF需要人工创建类型，所以在升级过程势必会产生冲突。为此，在升级前重构的TCEng V9临时系统中，务必将原有的PDF工具、pdf类型予以删除或者更名。如果清理不干净，则在TC2005升级到TC8．3时会首先校验出类型冲突，此时，尽管可以用additional_applications中的change_type_name予以类型更改，但后续升级过程还是会失败并停滞，必须再次人工修改升级过程中的增量xml文件中的pdf命名，然后再度重启升级过程。

2.3 合理的软硬件底层配置

确保网络交换机等硬件环境的稳定可靠，否则由于网络异常，会对系统架构产生怀疑，进而误导到错误的解决方向上去；更会导致数据迁移过程频繁出现DBMS错误，导致既定的物料基础编码分版本导八过程出现版本颠倒、数据丢失等现象，为后续显示和操作造成不必要的麻烦。

在每个升级阶段，还需确保中间数据库的表空间、临时表空间大小足够，否则也易于影响数据库升级和补差周期。在新系统推行阶段，IE版本对TC 10的自动分发安装也会有影响；对TC l0而言，IE 8最为稳定可靠，过于更新的IE版本反而出现分发安装或更新失败的现象。

2.4 合理的分部门推行方案

由于公司的TCEng V9已经应用了十多年，整个技术体系的日常工作不可能脱离它进行，每当一个阶段的数据导出、升级并迁移进新系统后，老系统中又产生了大量的数据，这就涉及按时间节点的数据补差问题。同时， 升级后的数据和新功能，还存在不少问题，在应用中还须不断得到校验和完善。所以，我们采用的方案是，选定一个部门，运用周末及新系统培训时间完成该部门的数据补差，然后在该部门试运行新系统，从零件取码、建模、制图、图样加载、无纸化审批流程、电子签名、BOM 搭建和数据发布、JT轻量模型装配、档案室出图等一系列功能逐步得到验证和稳定应用后，再逐步重复上述过程推行至其它部门。

需注意的是，为确保零件编码唯一性，在新老系统交接期，先行试用的部门必须在新老系统中同步取码。待所有部门推行上后，才能把取码工作全部切换至新系统中。

2.5 合理的数据迁移顺序

从中间临时系统迁入TC 10的数据种类非常多，比较合理的迁移顺序是：零件编码、属性等基本信息分版本迁移， 流程签审信息，PLMXML export／import方式迁移视图BOM、volume数据集，从自行开发系统中迁移设计BOM，文件夹结构迁移；待系统全部上线并完成数据补差后，最后迁移归档状态。然后从自行开发的技术共享平台中，迁移分类库数据。而无纸化审批流程、人员组织架构等在新系统中重建，不采用迁移方式；一些早期未实施成功的其它类型BOM 数据、数据集等，则全部予以丢弃，不再迁移，由此清理了很多垃圾数据。

由于迁移跨度大、补差次数多，还是会存在新系统中引用的数据集并非最新内置版本，同一数据集被多个零件版本引用、或者命名引用了多个prt文件等异常现象，在系统全面上线的同时，还须进行数据集版本对比、补差以及引用关系的处理。相关的迁移工具、对比工具、批处理均需先行开发和校验。

2.6 处理pattern图样模板的兼容问题

TCEng V9上的UG NX2采用Pattern方式加载图样，TC 10中的UG NX9的操作原理还是类似的。但由于采用了基础数据分别导出、导入式的迁移方法，新老系统中同一系列pattern文件对应的puid却发生了变化，这就导致老系统迁过来的所有图纸的图框全部丢失。为此， 需要通过NX接口进行重构对应关系， 在start_uxmanager．bat中设置LOST_PATTERN将老系统中的puid与新系统中的Pattern编码进行关联。

此外，还需要根据实际需求，做相当多的客户化开发工作，包括与取码器客户化、ERP系统的传输接口、图纸批量处理、BOM 的汇总与输出锁定、变更管理等，这样才能符合企业自身的实际需求和习惯。而且，由于系统版本跨越非常大，操作习惯、应用理念差异很大，所以成功的推行还需规划合理的培训进度，设置基础培训、进阶培训、新功能强化培训等，让技术人员逐步适应新环境、应用新功能。

3 项目运行

TC 10和UG NX9系统自从2O15年10月全面上线以来，通过后续的功能开发、零星数据补差、数据校验比对等环节的不断完善后， 目前已经平稳运行了一个整年，如图3所示。所有技术人员已经适应了新系统的操作环境和操作习惯，而且实现了BOM 数据和分类数据的全面整合、管路全装配、轻量模型装配和显示等新功能，实现了升级前设定的预期目标。

图3 实施完成的TC 10系统界面

Teamcenter系统功能的完整性、兼容性和可拓展性是毋庸置疑的，但在项目实施和应用过程中，感觉针对中国客户的操作习惯上，还有部分可待改善的地方：比如，PSE模块中，视图BOM、自定义的设计BOM 类型最好不能混杂显示，也就是顶层BOM 类型决定了后续子BOM 的调用类型；零件下BOM 能否生成，最好能与零件属性进行关联， 比如定义为零件类型的不能创建BOM，而只有组件类型的才能创建，这可以避免很多误操作。

在视图BOM 采用PLMXML方式进行批量导出并用命令行plmxml_import进行批量导入时， 尽管import_mode选择了overwrite参数， 但还是会有部分视图BOM 由于重复导入，出现覆盖不掉、导致数量翻倍的BUG ；之后将相应BOM 删除，通过TC界面的PLMXML重新导入，才予以逐个解决BOM翻倍现象。尽管上述问题，最终不影响系统的应用，但如果能予以逐步完善，将进一步提升TC系统的用户体验。

温馨提示：

现已建立“e-works PLM应用讨论群”，若想加入请加微信hjf278257352，邀您进群。添加的时候请注明：进PLM群

并已建立“e-works 智能工厂交流群”欢迎业内人士加群。

请加微信号ll250826，拉您入群。