PLM系统架构规划、优化方法及案例分析

PLM系统架构规划、优化方法及案例分析

稳定的服务器平台及优秀的、可持续扩展的系统架构PLM系统顺利部署实施的前提,也为系统上线后实现高稳定性及高可用性的保障;本文以Siemens公司的TeamCenter系统为例,详细介绍了PLM项目实施中硬件规划及架构优化的相关方法,包括架构设计的依据,单层组件的资源分配计算方法,系统调优方案等,以及该方法在厦门金龙旅行车公司PLM系统实施中的实践案例。

 

1 引言

 

    产品生命周期管理系统PLM(Product Life-cycle Management)自20世纪末提出以来,便迅速成为制造业关注的焦点。PLM结合电子商务技术与协同技术,将产品的开发流程与SCM、CRM、ERP等系统进行集成,将孤岛式流程管理转变为集成化的一体管理,实现从概念设计、产品设计、产品生产、产品维护到管理信息的全面数据管理。大型PLM系统一般是指具有高并发用户、参与部门多、日数据量大、系统逻辑复杂等特点的PLM系统。

 

    作为贯穿整个企业研发、销售、生产、配套、物流、售后整套体系的企业级信息系统,对其稳定性及高性能的要求相对较高。如何在满足业务部门性能及稳定性需求的前提下,尽可能降低硬件设备的投入,避免一次性大量采购成本高昂的高档次服务器及存储?如何避免今后因扩容需求或硬件更换造成原有投入的资源浪费?

 

    在PLM系统上线前期,是可以通过收集整理业务部门的需求,制定合理的系统架构,做系统资源分配测算等一系列方法,设计出一套投入较小,稳定性高,可持续扩展的系统架构规划方案。本文总结了作者在厦门金旅公司PLM项目及国内其他公司PLM系统实施过程中经验,提出了一个清晰合理的硬件规划操作方法,具有很强的可操作性。

 

2 需求分析

 

    在做系统架构设计及硬件规划前,需同PLM用户及所在公司的IT部门充分沟通,形成系统性能需求分析文档。此文档将作为下一步骤:系统架构设计的重要设计输入;需求分析过程中,主要需了解的业务需求详见表1。

 

表1 需求分析内容项目

 

    调研数据需按照规范化写法整理出需求分析报告文档,使用表格的方式体现业务数据增长。

 

3 系统架构说明、设计

 

    目前世界上主流的PLM产品均具备较为优秀的可扩展式多层架构,以Siemens公司的TeamCenter产品(以下简称TC)为例,介绍其系统基础架构。

 

    3.1 TC两层富客户端架构说明

 

    TC两层客户端必须同卷服务器、数据库服务器部署在同一局域网内。在两层环境下,系统架构分为客户层与资源层两个部分:

 

    1)客户层包含基于Java为核心的图形化应用程序、业务逻辑服务器(又称企业服务器)和文件客户端缓存组件(FCC,File Cache Client),这些组件均运行在客户端的计算机上。

 

    2)资源层包含数据库与卷服务器(文件服务器)。数据库一般采用Oracle数据库作为核心;卷服务器一般运行在带有企业级存储的服务器上,要求有较大的容量与较快的文件寻址速度;

 

    TC两层架构的客户端直接与数据库通讯,无需架设业务逻辑服务器和Web中间层服务器,对服务器资源的需求较小。一般用于小型PLM系统部署,如系统同时在线用户数不多(少于30人),数据量小于50G,业务模型较为稳定(一年3-10次小更改)的业务场景下,使用两层客户端可以快速进行PLM系统部署实施;两层架构的组件链接图表请参加图1。

 

 

图1 TeamCenter系统两层基础架构

 

    但TC两层架构的缺点也非常明显:因为业务逻辑处理运行在客户端环境上,一旦遇到业务模型更新或业务逻辑变化,需要逐台客户端去更新业务模型和程序;并且因为客户端和资源层服务器必须在同一局域网内,对网络要求较高,且无法跨区域,跨防火墙进行访问;再次因为客户端上需要同时运行TC富客户端、处理业务逻辑、工程师一般还需要打开CAD类软件对设计进行修改和创建,对客户端计算机的硬件要求也较高。为了解决这些问题,TC系统还提供了一种更加灵活、扩展性强大的四层架构。

 

    TeamCenter系统两层架构模块图表说明:

 

    ①系统数据库(可为 Oracle、SQL Server、IBM DB2等数据库引擎)

    ②系统文件服务(Teamcenter File Management System简称FMS,是TC系统基于http及https协议独有的文件传输服务)

    ③系统客户端(TC客户端是一个以Java为核心的图形化应用程序,包含三大模块:RichClient、FCC、tcserver。RichClient通过IIOP协议与处理业务逻辑的tcserver进程通讯,tcserver进程则通过TCP/IP与数据库进行数据传输,用于根据业务模型和业务逻辑处理客户端提交的请求,是客户端与数据库之间的桥梁;FCC即文件客户端缓存,通过http/https协议与FMS通讯,用于传输文件数据)

 

3.2 TC四层客户端架构说明

 

    TC四层架构是在TC两层架构的基础上,在资源层与客户层之间,增加了应用层与Web层;同时将TC两层客户端上需要运行的tcserver进程迁移到应用层上,客户端与服务器之间的通讯更改为SOA总线形式,通过http或https协议进行。如此设计,在TC四层环境下的客户端,只需要一个提交和接收请求的基于Java的轻量化应用程序(UI同TC两层富客户端,但是所有占用CPU资源的业务逻辑处理迁移至企业层上完成)以及负责文件传输的FCC组件即可运行。TC四层架构的组件链接图表请参见图2。

 

 

图2 TeamCenter系统四层基础架构

 

    TeamCenter系统四层架构模块说明:

 

    ①系统数据库(可为 Oracle、SQL Server、IBM DB2等数据库引擎)

    ②TC系统服务池进程,在企业服务器上一个用户对应一个独立的tcserver进程

    ③TC系统池服务管理器,用于管理企业服务器上启动的tcserver进程

    ④中间件服务器,负责客户端与tcserver之间的通讯

    ⑤卷服务器与系统文件服务(Teamcenter File Management System简称FMS,是TC系统基于http及https协议独有的文件传输服务)

    ⑥TC瘦客户端,基于网页形式的TC客户端,可以使用任何浏览器登陆进行TC日常使用操作

    ⑦TC四层客户端程序和FCC组件

 

    3.2.1 应用层包含组件说明

 

    在TC系统企业层服务器上,运行有一个TC服务池管理器。此管理器管理着tcserver进程的新建,关闭,读写状态切换。当用户登录时,池服务管理器会为用户启动对应的tcserver进程,用于提供业务逻辑服务,并会根据系统后台的设置,自动保持一定量的暖进程,用以处理短时间密集用户登录的场景。tcserver进程产生的临时文件数据(书签数据,运算输出数据,文本报告等)会通过Transient FSC(File Server Cache)组件传送给客户端的FCC组件。这里的FSC类似于资源层卷服务器上的FMS组件,它也提供了文件的读写及高速缓冲功能,唯一的区别是,它不作为文件的长久保存基地,仅是临时文件和高频率读写数据的缓存空间。

 

    3.2.2 Web层包含组件说明

 

    TC系统Web层一般来说是运行在基于J2EE的web中间件服务平台上,如常见的Oracle Weblogic,IBM WebSphere和免费的JBoss;中间件也可以运行在基于Windows Server.Net框架平台的IIS服务器上。

 

3.3 系统架构设计

 

    3.3.1 系统架构的选择

 

    在进行系统架构设计初期阶段,需要进行TC系统架构选择。考虑因素可以参考从本文第二章节介绍的需求分析报告;以下给出几种常见场景的分析说明供参考:

 

    ●如果企业PLM系统还处于初级阶段,并未走出研发部门,可以考虑仅采用两层架构。能有效的降低项目初期设备投入,降低部署和维护难度,使PLM项目快速部署上线。

 

    ●如果企业PLM系统已在多个部门使用,与研发相关的业务流程正在逐步向PLM系统迁移,建议采用四层客户端。四层客户端可以减少Consumer用户对同时在线许可证点数的要求,方便查询用户使用浏览器方式登录PLM系统进行数据查阅;同时,四层客户端也降低了业务模型部署难度,避免因频繁的业务模型变更造成处理逻辑不同步,数据出错的概率。

 

    ●如果企业PLM系统应用已较为深入,开始使用数字样机评审、项目管理、异地协同等模块,并且业务模型也相对稳定,就可以采用两层与四层架构并行部署;本地站点的CAD设计师,BOM工程师等工作流程稳定的角色,计算机配置较好,对速度要求高,即可使用两层客户端;而研发流程签核人员、配套、生成部门等流程查询用户,要求轻量化、可在多设备、多平台下运行的客户端,可以采用四层客户端;对异地站点人员,也必须使用四层客户端;

 

    3.3.2 各层组件的架构分配

 

    此处以Siemens TeamCenter系统的四层架构为例,对几种场景的架构场景优势劣势继续说明:

 

    ●资源层两组件分开放置:因为数据库组件和卷组件对于服务器CPU、内存、磁盘IO、磁盘容量、网络带宽等资源的需求差异非常大,且都是注重稳定性和安全的重要组件。同时,考虑到数据库的性能对PLM系统的响应速度影响巨大,升级扩容更换数据库和卷服务器必定带来系统停机,而且数据迁移都需要很长的时间等因素,故建议数据库和卷服务器组件两台独立的服务器放置。

 

    ●应用层和Web层在硬件资源运行的情况下,可以放置在同一台服务器上;因为应用层组件对CPU、内存IO、与数据库间网络带宽资源较为敏感,而web层中间件服务相对资源占用较少。所以在用户数不多,系统资源富裕的情况下,可以部署在同一台服务器上。即节省资源,又能减少tcserver和中间件服务通讯的网路延迟。

 

    ●对于大型PLM系统部署或需要高可用扩展的部署,必须将Web层和应用层放置在两台不同的服务器上。只有做好硬件上的分离,才可通过应用服务器或中间件服务的集群功能,避免单点故障。如果企业部署了云计算,分开部署Web层和应用层还能根据忙时和闲时,实现服务器资源动态调配,能有效的降低对电力的消耗,达到节能减排的环保目的。

 

    ●如果卷服务器单独部署在一台计算机上,可以将分发服务器和卷服务器整合。

 

    3.3.3 系统架构高可用性、容灾的考虑

 

    ●PLM系统的高可用性包含中间层故障迁移、企业服务器层故障迁移的两个方面,图3给出了基于中间层组件提供的高可用性负载均衡及故障迁移的示例。

 

 

图3 基于中间件服务的高可用性扩展示例图

 

    ●通过中间件提供的服务代理器(tcproxy)可以将多个中间件服务和多个应用层池服务资源汇集,组成一个性能强大的服务器集群,并可以根据用户数的多少,随时扩展或减少服务器。同时,也提供了故障迁移的路径,如果其中的任意服务组件发生故障,均可以将用户迁移到其他服务器上继续运行,不会造成服务的中断。

 

    ●PLM系统的容灾处理主要体现在资源层的卷服务组件和数据库组件上,图4为IBM官方提供的一种异地容灾的解决方案。对于一般企业进行PLM系统部署的实际情况,卷和数据库均会运行在较为稳定的专业级存储设备上。而且企业级存储一般都会部署相应的备份设施,除非遇见无可抗拒的自然灾害,比较少发生数据丢失的情况。所以在PLM项目初级阶段和中期阶段,可以考虑将资金投入更能带来效益的项目实施经费。

 

 

图4 IBM官方异地灾难备份方案图例

 

4 服务器资源计算及分配

 

    大部分PLM系统在产品手册中,都会提供各层组件的资源消耗数据(见图3)。但是这些数据一般都是基于实验室的标准测试,只能作为理论计算的参考,实际中由于各个企业不同的业务种类、数据模型、业务场景不同,需要结合实际场景对PLM系统所需的服务器资源进行综合评定。

 

    4.1 资源计算所需理解的概念

    ●并发比例(Concurrency):它是服务器硬件资源消耗的主要考虑因素。并发用户数指的是某一时刻同时连入系统的用户数,消耗资源的是并发用户数而非许可证允许的用户总数。但是在资源规划计算阶段,很难判断今后生产系统并发用户数的多少,因此一般采用经验处理。可根据前文提到的需求分析报告中,业务数据增长量和同时在线人数,按照一定比例估算并发用户数。如果系统使用率高,可以将并发比例设置在0.8~1之间,如果系统使用率一般,则最低将并发比例设置为0.5。

 

    ●CPU/Mem SDR,SiR:它是Siemens Global APA组织实验室发布的关于TC系统每层组件CPU、内存消耗值的测试数据,针对每种主流操作系统平台均发布有相对应的测试数据。其中CPU SDR值来源于第三方权威CPU性能测试机构 SPEC (http://www.spec.org)。SPEC发布的CPU性能测试数据为SiR。Mem SDR则完全来自于APA组织的测试结果。图5和图6给出了SDR与SiR参数的示例;

 

图5 Siemens TeamCenter部署手册中发布的Enterprise Tier CPU SDR参数

 

图6 SPEC机构在其官方网站上发布的测试数据

    ●CPU/Mem使用率(Utilization):数据中心一般会设定主要应用服务器(TC系统中为Enterprise服务器)CPU/Mem的闸值,如果系统资源超过闸值,就可以确认服务器资源紧张。不同的应用服务器其闸值可以做针对性的设定。

 

    ●扩展系数(Scaling Factor):Siemens APA组织发布的测试数据一般是基于一组特定的场景,而且测试环境一般都非常理想。但是在PLM系统实际使用中,业务场景与数据肯定不是特别理想的环境,需要考虑系统长时间运行后产生的垃圾已经OS、硬件层面带来的负面反馈效应。因此在计算资源消耗时,要按照一定的比例系数来适当放大所需的服务器资源。具体的扩展系数需要根据经验值来定,一般取值范围在1.5~2.5之间。

 

4.2 资源层组件所需资源计算

 

    4.1.1 数据库资源计算

 

●CPU SiR=(TotalUsers×Concurrency×CPUSDR)/CPU_Ultilization×Scaling_F;

    ●PGA=(TotalUsers×Concurrency×MemSDR)/Mem_Ultilization×Scaling_F;

 

●SGA=PGA*Ratio

 

●Mem Total=SGA+PGA+4GB

    说明:部署Oracle数据库时,SGA与PGA的比率可以取值为5-7之间,一般选取6;负载特别大的系统,可以选取8-10;MemSDR计算公式最后的4GB是为OS预留的内存空间;

 

    4.1.2 卷资源计算

 

    ●CPU SiR=CPU_SDR/CPU_Ultilization×Scaling_F

 

    说明:卷服务器的内存资源一般不进行计算,可以通过查询TeamCenter帮助文档中的System Administration手册——Sizing the FMS fast cache章节来查询(见图7)。

 

    注意:windows操作系统环境下,TC卷服务最大可调用的内存仅为2048MB。

 

图7 Siemens官方帮助文档—卷服务器资源应用快查表

 

    4.3 应用层组件所需资源计算

 

●CPU SiR=(TotalUsers×Concurrency×CPUSDR)/CPU_Ultilization×Scaling_F;

    ●MemTotal=(TotalUsers×Concurrency×MemSDR)/Mem_Ultilization×Scaling_Fsctor×SafeF;

    说明:在应用服务器实际使用过程中,因为不断创建和关闭的服务池(tcserver)进程会产生一定的内存垃圾,并且这些内存垃圾在系统定期维护重启之前无法被消除,所以必须考虑给予一定量的安全系数(安全系数取值范围可为1.2~1.5

 

    4.4 Web层组件所需资源计算

 

    4.4.3 中间件服务器的资源计算

 

    ●CPU SiR=(TotalUsers×Concurrency×CPUSDR)/CPU_Ultilization×Scaling_F;

 

    ●MemTotal=SPEC_MemSDR/Mem_Ultilization×Scaling_F;

 

    说明:如采用基于J2EE的中间件(weblogic或JBoss)需要考虑使用过程中GC(Garbage Collect,垃圾收集)方法造成的服务暂停时间。如果为中间件分配的内存过小,会造成系统响应迟钝,吞吐量小的问题。也不可设置过多的内存给中间件,否则中间件启动时间会很长容易造成与企业服务器上的应用层组件链接失败的故障。

 

    4.4.4 分发服务器的资源计算

 

    ●CPU SiR=(TotalUsers×Concurrency×CPUSDR)/CPU_Ultilization/WorkingH

    说明:PLM系统的分发服务器一般是指分发业务模型程序(即客户端程序)的文件分发服务器,对系统资源占用率较低,且大多运行在java环境中,故内存部分只需设置最大Heap Size=512MB即可。

 

4.5 服务器资源汇总

 

    在计算好单层组件所需要的资源后,再根据系统架构汇总好所需的服务器数量及每台服务器需要的资源。需要注意的几点是:

 

    ●资源层和应用层服务器,每台服务器至少为OS预留4GB的内存;

 

    ●有高可用性集群时:需要增大内存需求的安全系数,以保证发生故障迁移或负载均衡失败时,服务器不至于被大量涌入的请求冲击当机;

 

    4.6 服务器硬件配置校核

 

    当服务器资源计算完成后,可以请企业IT部门配合向服务器供应商或在SPEC组织查询获取最为匹配的服务器型号和配置信息。需要注意:

 

    ●计算的结果要考虑OS平台的依赖性,可以多查阅PLM系统官方发布的兼容性文档,避免因兼容性故障造成系统部署失败;

 

    ●理论计算给出的配置一般较低,可以根据项目资金,合理的增加服务器的配置,避免短时间内用户、数据暴增造成的服务器资源不够用的情况。

 

5 硬件计划审核和系统详细设计

 

    5.1 硬件计划审核

 

    一旦服务器资源确定后,需要尽快联系硬件厂家进行服务器的采购。但是由于硬件规划除了设计CPU、内存、磁盘等常见逐渐外,还涉及到存储设备、网络交换机、客户端工作站等其他硬件资源。这些硬件资源的采购周期不一,有的进口设备采购周期甚至长达3个月。所以要求IT部门需要配合构架师制定一个采购计划,并对采购计划进行审核。审核的主要内容应该包括:

 

    ●采购硬件的清单(硬件BOM)

    ●硬件的兼容性信息

    ●硬件设备采购周期

    ●许可证点数与硬件设备是否相符合

 

    5.2 系统基础详细设计

 

    在服务器就位,正式安装之前,必须做好系统基础详细设计,至少应当包含如下内容:

 

    ●服务器的磁盘划分

    ●服务器存储的文件系统确定

    ●服务器运行的OS环境与系统参数确认

    ●存储设备的权限管理与存储盘的划分

    ●网络信息的详细配置

    ●集群的详细配置(如果部署集群或高可用性服务时)

    ●虚拟化云计算的详细设计(如部署在虚拟化平台上或云计算平台上时)

 

    表2给出了服务器部署所需的系统详细设计表格范本,可以参考在此范本上进行扩展和完善。

 

表2 服务器详细配置总览表示例

6 部署实施及性能调优

 

    当系统架构设计完成,硬件资源采购就位后,即可进行PLM系统部署实施。

 

    6.1 系统部署实施

 

    6.1.1 系统部署前准备

 

    系统部署前准备准要是指为系统部署工作的准备过程,主要包括以下部分内容:

 

    ●准备系统部署操作文档(手册)、系统部署计划表,范例见表3;

    ●检查硬件环境是否安装就位,网络环境,磁盘空间是否充足;

    ●检查操作系统是否安装到位,补丁是否更新;

    ●检查操作系统用户、组织是否设置正确;

    ●检查服务器端第三方软件是否安装就位;

    ●检查PLM系统许可证是否正确可用;

    ●如果是升级系统,需要同业务部门沟通好停机时间,并下发生产系统停机通知;

 

表3 PLM系统部署检查表

 

6.1.2 系统部署前验证

    在生产环境PLM系统部署前,必须经历系统部署实施验证。一般至少要进行2轮系统部署验证,并严格按照系统部署文档操作。如果在系统验证阶段出现任何意外的错误信息,必须记录在部署文档当中,以备排查系统部署错误,将有可能存在的问题都一一解决。这样,在生产环境正式部署的时候,过程就会比较顺利。

 

    6.1.3 系统部署

 

    PLM系统部署一般遵循从下至上的原则,即先对底层的支持型组件如数据库、卷服务进行部署安装,再对扩展型、易用性组件如应用层服务、中间件服务进行安装部署。对于TC系统而言,一般按照7步走的方式进行:

 

    ●安装数据库软件,建立空白数据库;

    ●安装基础版本的TC系统软件,卷服务器,业务模型;

    ●安装TC系统补丁;

    ●安装企业服务器及中间件服务器;

    ●安装分发服务器及其他扩展应用服务(全文检索、可视化协调、分布式处理等服务);

    ●部署二次开发程序;

    ●系统综合测试

 

    6.1.4 系统部署后处理

    在生产环境部署成功后,需要根据使用环境,设立不同的计划任务和警报器。正确合理的设定维护计划任务,是维持PLM系统稳定运行的关键所在。本文列出了几条关键节点,供读者参考:

 

    ●系统定期自动备份脚本;

    ●定期重启应用层服务的计划任务;

    ●定期重启中间件服务的计划任务;

    ●意外当机后,自动恢复服务的脚本;

    ●故障迁移集群(如存在)的错误报警与自动恢复脚本;

    ●PLM系统与上下游数据接口错误检查器;

 

    6.1.5 错误处理预案

    部署PLM系统,特别是在原系统基础上升级部署操作时,可能会遇到不可预料的问题。为了使得PLM系统顺利部署成功,需要系统各个层面(各个服务组件)的人员进行紧急磋商,建议至少4人以上参加。对安装部署错误进行分级,讨论是否可以在有限的停机时间内解决错误并完成部署。如能完成,则需做好两手准备,即分两组人分别进行错误问题处理及系统回退准备。如错误无法在停机时间内解决,则需要对系统进行回退操作,排查并处理错误后,再次寻找停机时间进行系统部署。

 

    6.2 系统稳定性测试

    在PLM系统正式上线服务前,需要进行稳定性测试。PLM实施工程师应当根据不同企业的使用场景,撰写UAT测试文档。对于仅支持C/S架构的系统,需要组织关键用户,对系统进行全方面的测试。对于具备B/S架构的PLM系统而言,除了组织关键用户进行UAT测试外,还需要对其中间件服务进行压力测试。推荐使用LoadRunner等第三方测试软件模拟上下班时期用户登录、保存操作高峰场景,突发性大数据量读取,大数据量检索等场景。测试结果需要记录备案,作为系统性能调优的设计输入。

 

6.3 系统性能调优

 

    PLM性能调优主要包括服务器性能调优和客户端性能调优两方面,本文主要针对TC四层环境系统进行说明。

 

    6.3.1 服务器端性能调优

 

    以TC系统四层架构为例,服务器端性能调优应当按顺序注重以下几点:

 

    1)数据库参数优化:SGA大小、Process数、Open_course大小、Session数等;

    2)数据库索引优化:包括定期执行数据库动态性能分析(ADDM)服务,定期检查并更新数据表索引等;

    3)优化FMS服务器:最大化利用内存来做FSC组件的高速缓冲,合理配置FMS启动参数,让客户端连接网络路径最短的FSC服务器;

       4)应用服务器系统IO参数优化,JAVA启动参数优化(如基于JAVA环境),关闭调试信息日志及调整池服务管理器的暖进程数量和缩短进程最短响应时间;

    5)调优中间件服务:使用64位Jrockit JAVA虚拟机,合理分配JAVA虚拟机的Heap大小,设置并行GC策略并设置GC为吞吐量优化;

    6)调整TC系统参数:关闭TC_SLOW_SQL分析,设置XML消息回传消息为最大值,提高tcserver进程自动内存回收闸值;

 

    6.3.2 客户端性能调优

 

    TC四层客户端包括B/S架构的客户端和C/S架构的客户端。

 

    ●B/S架构性能主要取决于浏览器解析能力,推荐使用Chrome或FireFox来代替IE浏览器,已获得更高的性能;

    ●C/S架构客户端性能优化要点:

    1)提高JAVA虚拟机的Heap大小,并将Xmx和Xms设置为相同值;

    2)调整GC策略,将Java GC时间间隔延迟至3600s;

    3)经常整理磁盘碎片,保持系统可用内存在2G以上;

    4)安装经官方认证的显卡驱动程序;案例分析

 

7 项目情况

 

    7.1 项目简介

    某知名客车企业为了满足更大的业务需求,从2013年开始,深化扩展PLM系统应用,并对PLM系统进行大版本升级。由原TC8.1+Oracle11g+Weblogic11g升级为TC8.3+Oracle11gR2+Weblogic12c的平台。在现有PLM系统架构上,又增加了负载均衡集群、故障迁移集群的功能。系统功能上,增加了全配置BOM,平台化设计等功能模块。系统接口上,增加了与RCC、ERP、SRM系统的接口。

 

    7.2 需求整理

    PLM实施人员按照本文提出的需求分析方法对未来业务场景做了系统需求分析整理。发现原PLM系统经过2年的运行,数据库及卷文件已包含大量垃圾数据,并且基础架构有诸多不合理之处。同时,考虑到人服务器与主要用户群在异地,网络通过专线光纤,因此需要对系统资源进行重新调配。需求调研的主要参数详见表4:

 

表4 某公司主要需要参数

 

7.3 原系统架构解析

 

    为应对TC版本升级及大量新业务引入对系统性能的冲击,实施人员对原PLM系统基础架构进行分析。原系统架构图请参见图8。

 

图8 某公司原PLM系统架构

    从架构图中可以看出,原系统虽采用TC四层架构,但是中间层和应用层和分发服务放在同一台硬件服务器上,缺少负载均衡和故障迁移集群。实际使用过程中,中间件经常因IO错误中断,导致控制台无法登陆,客户端响应缓慢等问题。经过SPEC查询,TCapp1和TCDBsvr两台IBM X3850 X5的SiR均为334。但是根据每用户的SDR来看,tcapp1硬件服务器的处理能力远远超过所需的SDR值,但是因架构不合理,资源使用情况不足,网络和磁盘IO负载巨大,造成应用服务的瓶颈。并且,由于缺少高可用性集群,一旦任何应用层的服务组件出现问题,即会造成生产环境停机。

 

    7.4 系统架构优化设计

    配合某企业虚拟化的进程,同时,考虑到未来人员、数据增长对系统性能可能带来的冲击。新系统架构设计初期,就以具备高可用性及故障迁移的四层结构为基础,测试将其中一台X3850服务器增加内存,并划分为3台虚拟服务器(分别为tcapp1、tcapp2、tcweb)。优化后的系统架构详见图9。

 

图9 优化设计后的系统架构

    经测试,基于虚拟化的服务器平台,系统IO速度较硬件服务器环境快40%左右。因此将虚拟化的tcapp1与tcapp2作为应用服务器,并在其上分别对等的布置有weblogic集群服务和应用层服务器,利用weblogic提供的集群和TC Enterprise服务器提供的TreeCache技术,实现高可用性集群和故障迁移能力。未来还可以根据资源负载情况,不断增加tcapp3、tcapp4...等虚拟服务器加入集群,在不停机的情况下就能满足业务增长的需要。

    tcweb则作为weblogic集群的统一入口点,并架设有tc分发服务器及weblogic、应用服务器的管理控制台程序。tcdbsvr及tcvolsvr服务器因资源充裕负载较小,保留不变。

    另外,主要设计人员和服务器分别架设在异地厂区。虽然中间网络使用千兆专线光纤链接,但是卷文件传输还是会受到光纤转发器性能瓶颈的影响,造成文件传送延迟,打开大文件反应慢的问题。未解决此问题,实施人员在设计人员所在厂区的局域网内,加设一台FSC Cache服务器,提供卷高速文件缓存服务。对于中间层数据而言,均为轻量化的数据流且对数据实时性准确率要求较高,不加设缓存服务。

 

7.5 系统部署实施

    通过部署测试结果分析,系统升级停机时间需要30小时。经与业务部门沟通,PLM项目组将系统停机时间安排在周六下班后进行。由PLM实施顾问,实施工程师,IT技术人员,硬件维护人员连夜奋斗,共同在周日20点完成系统部署。经过一个月的运行,系统状态良好(见图10、图11)。

 

图10 应用层服务器负载均衡运行状态良好

 

图11 中间件服务负载均衡、高可用性运行状态良好

 

8 结论

    本文介绍的PLM系统架构设计方法,包括需求分析,架构设计,服务器资源分配,硬件采购,部署实施及性能优化等一系列办法。为企业顺利实施PLM项目提供了详细的可操作说明,值得在其他PLM项目中推广应用

 

 

 

 

 

 

 

面向PDM/PLM的制造信息管理与集成技术

PDM/PLM作为企业信息管理的集成平台,其应用越来越广泛。文章通过研究产品制造过程数据信息分娄和集成模式,建立了面向PDM/PLM的制造信息管理模型。并以设计数据为例,规划了其树状结构管理模型和围绕项目的数据组织模式,从而保证了产品数据的一致性。对基于接口交换方式的集成技术进行了深入研究,并通过实例验证其可行性。

 

0 引言

 

    在制造业中,并行工程强调跨部门多学科的集成产品开发方式,因此信息种类繁多、变换频繁,需要一种先进的教据管理工具来为它提供必要的支撑环境。

 

    产品数据管理PDM/PLM( Pmduct Data Management/Product life cycle Management)支持分布、异构环境下不同软硬件平台、不同网络和不同数据库,是一种跨平台的计算机管理工具,提供结构化方法,有规则地存取、集成、管理、控制产品数据和数据的使用流程,在企业中应用越来越广泛。产品制造过程中的数据包括所有与产品设计、生产有关的数据。这些数据由于数据量大,存在状态复杂,存储介质多,因而变得很难维护。本文就制造信息的管理与集成技术研究进行深人研究。

 

1 面向PDM/PLM的制造信息管理模型

 

(1)产品制造过程数据信息分类

    PDM/PLM系统作为一种软件系统,具备两个基本功能,一方面在企业内部和扩展企业之间创建、管理、访问和使用产品定义和制造信息。另一方面,维护产品定义和制造及其相关信息在产品生命周期内的完整性。因此,PDM/PLM系统需要建立逻辑上统一的产品数据源以获取、存储和管理产品生命周期中所有阶段的产品相关数据。产品制造过程的数据信息包括产品需求分析数据、产品设计数据、产品制造数据和产品销售和服务数据,如图1所示。


图1 产品制造过程数据信息分类

 

(2)产品制造过程信息化集成模式

    在CAD、CAPP、CAM等应用系统建成之后,实际上会在企业内形成许多“信息孤岛”,这些信息之间存在大量的关联,成为企业信息化需要解决的关键问题之一。PDM/PLM系统可以把与产品整个生命周期有关的这些孤岛统一管理起来。因此,必须建立基于PDM/PLM的产品制造过程信息化集成模式,使CAD、CAPP、CAM等应用系统都通过PDM/PLM进行信息交换,从横向和纵向实现各应用系统的无缝集成。本文构建了基于PDM/PLM的制造过程信息集成模型,从左到右,自基于特征的零件信息模型可实现CAD、CAPP、CAM之间的横向集成。从上到下由PDM/PLM实现图形信息、文档信息和管理信息的纵向全面管理。 如图2所示。


图2 基于PDM/PLM的制造过程信息化集成模式

 

2 面向PDM/PLM的产品设计数据模型及其管理框架

 

(1)定制产品的树状结构管理模型

    面向PDM/PLM的产品设计,要充分利用PDM/PLM技术的支持,进行相应的开发,实现标准化、规范化的产品管理模式。采用树状结构来组织产品的信息,可以精确地描述产品族、产品、部件、零件的层次和所属关系以及产品、部件、零件本身所具有的属性,如图3所示,根节点是产品族,其余中间节点及叶节点都是产品族各层次中的一个对象,用户可展开不同分支来找到所需的数据。由于每个对象的数据和文档的组织模型都已确定,因此,各个节点的信息表达是完整和充分的。对于零件的管理,可借用成组技术的思想,按照零件设计、工艺、加工上的相似性,实现聚类管理。 

 


图3 产品的树状结构管理模式

 

(2)面向PDM/PLM的产品数据组织模式

    PDM/PLM软件可以把与产品相关的所有数据组织起来,使每一位设计人员都可以及时获取其权限范围内所需的信息,因此合适的组织模式变得尤为重要。本文中产品文档与数据是围绕项目来组织的,项目表示一个想法和概念,它们是数据结构中的最高层次的类;也表示一个体素,在树型链接中被分为类与子类。可以使用户方便地浏览数据并找到文档。如图4为一种对象的数据和文档的组织模型,如产品、装配件和零件对象等。

 


图4 产品文档与数据的组织模式

 

3 PDM/PLM与CAD的集成

 

(1)PDM系统与CAD系统的集成

    PDM主要存储CAD三个方面的数据:产品设计信息、产品图形信息、产品结构信息。

    以SmarTeam和Solidworks为例的PDM/PLM系统和三堆CAD系统的集成功能结构如图5所示,以获取产品如下信息。


图5 集成功能结构

 

    1)自动获取产品设计信息:Smaream可以通过接口程序自动提取Solidworks中产品的相关设计信息,如产品型号、产品类型、零件名称、材料等。

    2)获取零部件图形信息:直接查看CAD模型有两种方式:一是以图像方式,直接在PLM中显示模型,滚模型可被旋转、缩放、圈点,作为选择模型和修改的依据:二是以嵌入方式启动CAD系坑,方便地进行查看和修改等。对于三维CAD软件,自于后者要启动应用程序,占用内存大,因此单纯查看多采用第一种方式。在PDM系统中启动三维CAD系统,可以利用封装功能将CAD系统封装到PDM系统中,这样可以在PDM系统中激活CAD系统。

    3)产品结构信息提取:是指CAPP获取产品结构树信息,井对该信息进行处理,生成相应的产品工艺树。利用SolidWorks和SmarTeam的API函数,在SolidWorks系统中开发基于PDM/PLM的客户端程序。

 

(2)PDM/PLM的接口交换方式

    集成是PDM/PLM解击方案中的一项关键技术,PDM/PLM系统主要采用三种方式,应用封装方式,接口变换方式,紧密集成方式。本文报据某企业实际情况设计的基于SmarTeam的平台式CAPP系统,允许应用CAPP进行工艺设计时,随时便捷地查询信息。因此,在CAPP与PDM之间必须能实现数据的双向交换。因此就需要采用接口交换的形式来开发。

 

    接口变换的作用是将应用系统和PDM/PLM系统需要共享的数据模型抽取出来,定义到PDM/PLM的产品数据模型中,这样两者就有了统一的数据结构。应用系统除了有这部分共享的数据模型,还可以有自己特有的教据模型,应用系统本身可作为对象纳入PDM/PLM系统环境中。其特点是在应用封装的基础上,在应用系境和PDM/PLM系统间共享数据模型的指导下,通过数据交换接口,实现应用系统的某些数据对象自动创建到PDM/PLM系统中去,或从PDM/PLM系统中提取应用系统需要的某些数据对象,使二者保持异步一致。在SmarTeam中采用如下语句创建OLE自动化对象。

 

    以特征制造信息的提取为倒,说明用Visual Basic实现SmarTeam与SolidWorks的数据交换关键技术。如图6所示。

 


图6 Solidworks 与SmarTeam的数据交换实例

 

4 结束语

 

    并行设计离不开信息技术的支持,CAD系统与PLM/PDM系统已经被越来越多的企业所采用,但是CAD、CAE、CAPP、CAM各项单元技术的集成仍然存在许多问题有待解决,为了保证数据的一致性,本文通过研究产品制造过程数据信息分类和集成模式,建立了面向PDM/PLM的制造信息管理模型。并以设计数据为例,规划了其树状结构管理模型和数据组织模式,利用SolidWorks和SmarTeam的API函数,对其集成技术进行了深入研究,通过实例表明,通过对数据的合理管理与保存,能极大改善系统集成的效果。