产品全生命周期
项目管理系统
配方管理系统
实验管理系统
电子实验记录本
化工行业
PLM中工程变更数据管理
数据是工程变更的被操作对象，变更流程的推动即是为数据更改服务的。工程变更过程中牵扯到的数据很多，如属性记录、文档记录以及表单记录等。这些数据产生于各种不同的应用系
产品应用
数据是工程变更的被操作对象，变更流程的推动即是为数据更改服务的。工程变更过程中牵扯到的数据很多，如属性记录、文档记录以及表单记录等。这些数据产生于各种不同的应用系统，同时又应用于各种系统，系统问集成便成为工程变更不可避免的工作。本章主要研究系统中变更数据的组织、变更数据与CAD和ERP系统的集成以及变更过程中产生的各种变更表单。通过集成使变更过程中各系统间数据保持一致，可确保变更的有效进行；通过各变更表单记录，为变更任务的执行提供依据，同时也方便对变更历史的追溯。
1.1工程变更数据组织
工程变更指的是对已经正式投入生产或使用的产品零部件进行的更改，需要修改的可能会涉及到被修改零部件的任何相关信息，包括相关对象如零部件、工艺、设备等的属性信息；各类文件和图档，如设计任务书、设计规范、二维图纸、三维模型、技术文件、使用手册等；以及在变更过程中产生的各种数据表单，如变更请求单，变更通知单，变更评价单等。图1-1所示为变更数据相关信息。
图1-1变更数据信息
变更过程中牵涉到的各种需要修改的数据多是在产品设计时产生的，一般以各种文档的形式存在，如设计说明书、技术手册等以word或其他格式存在，而图纸以CAD格式存在：变更过程中需要修改的各类产品属性信息在PLM中以属性记录形式存在；过程中产生的各种变更表单以PLM中设置的表单格式存在。所有数据记录在PLM数据库中均有保存。
合理组织所有的变更数据是管理变更数据的基础。工程变更对更改关联常用两种不同的处理策略，即面向问题和面向部件。面向问题的解决方案是把更改所关联的所有部件、文档、信息统一在一个ECR中处理；面向部件的解决方案是把更改所关联的所有也需更改的部件、文档、信息分别形成多个新的ECR单独处理。因为采用面向问题的处理策略可对变更对象统一处理，方便管理，也方便查询，所以，论文采用此方法构建了变更数据的组织结构。组织数据时，新建变更对象作为父节点，而变更请求，变更通知等以子节点的形式附在父节点之下。各子节点并不是一开始就全都存在，而是随各子流程的进行逐渐添加的。
当新建一个工程变更时，在个人空间内就会生成一个工程变更对象，其编码为“EC”加变更编号加变更名称，变更名称由用户自己定义，一般会包含被修改零部件编号和名称，如“EC0001-0800连杆更改”，对应此变更对象，自动生成其版本对象，如“EC0001／A-0800连杆更改”表示针对该零部件的A版本的更改。同时，在版本对象节点之下还生成若干文件夹形式的子节点，用来承载变更过程中使用或产生的各类数据，如受影响对象(Addressed by)，修改后对象(Affected Items，包含已修改好零件的零部件)，问题对象(ProblemItems，包含需被修改零件的零部件)，修改后零件(Solution Items)，当前自己需执行的任务(Tasks to Perform)以及当前需别人执行的任务(Tasks to Track)，如图1.2所示。
图1.2所示模型中，变更流程正处于ECR子流程中(此流程省去了PR子流程)，所以模型中有ECR对象“ECR0001-0800连杆更改”及其版本对象“ECR0001／A-0800连杆更改”，同时生成的还有ECR表单“ECR0001／A-ECR Form”，A记录了ECR版本对象的相关属性。图中✿表示处于流程中，表示目前变更流程正处于ECR子流程中。
图1-2 变更数据组织模型
图1-3 变更数据组织模型
同样，当变更流程走到ECN子流程时，系统自动完成ECN的创建，图1-2所示模型就会变成图1-3所示。从图中可以看出，整个变更仍处于流程中，ECN亦处于流程中，而ECR用√来标志，说明ECR子流程已经结束，ECR对象已处于发布状态。
随着流程的推动，工程变更的数据模型一步步增加节点，记录下变更过程中产生的数据，并在流程驱动下把数据呈现给需要的工作人员。这种数据模型确保在一个流程中，始终只存在一个变更根节点，过程中产生的所有数据对象均以子节点形式出现。直到所有子节点任务全都完成，整个变更流程才能结束，并对整个变更的父节点(如EC0001-0800连杆更改)添加√标志，标识变更的完成。把变更过程中涉及到的数据进行统一管理，不仅能避免变更的重复执行和执行不完善，而且能在任何时刻查询已完成的变更数据。
从模型中可以看出，仅仅在ECR、ECN这样的变更对象里并不能把所有的变更数据体现出来，比如图纸更改，BOM更改等。所以，数据模型提供了文件夹结构，如Affected Items等，用来保存变更过程中涉及到的其它数据。
Addressed by：关联更改，存放引起此次变更的其他工程变更；
Affected Items：已完成的零部件，更改后并已处于发布状态的版本零部件对象，它是问题零部件的一个新的版本；
Problem Items：问题零部件，将要被AffectedItems中零部件替代的更改前的版本零部件对象；
Solution Items：解决方案零件，变更过程中创建并已经发放的新的零部件。
例如在一个变更过程中，零部件X(A版本)因存在一定问题需被更改，于是发起了更改流程。更改时，零部件X的一个子部件xx需要改成yy，最后得到了零部件x的B版本。在这一过程中，A版本的零部件x将被放在Problem Itmes文件夹下，B版本的零部件X将被放在Affected Items文件夹下，过程中添加的X的子部件yy将被放在Solution Items文件夹下。各零部件所包含的子部件、数据集等也都跟零部件一块放在对应的文件夹下。
1.2变更数据集成分析
变更数据作为PLM系统中的部分数据，数据来源范围比较广，跟其他应用系统有着紧密的联系，为了保证整个生命周期内所有数据的一致性和完整性，变更数据与其他应用系统的集成异常重要。本节主要介绍了变更数据与CAD系统和ERP系统的集成。
1.2.1PLM／CAD变更集成分析
CAD系统产生的二维图纸、三维模型、零部件的基本属性、产品结构等，需要交由PLM系统来管理，而CAD系统也需要从PLM系统获取设计任务书、技术参数、原有零部件图纸、资料以及更改要求等信息。零部件的更改必然会涉及到CAD中模型、图纸及相关属性的更改，只有实现了两系统的集成，才能保证两系统间产品数据的一致。根据集成的紧密程度，CAD和PLM的集成方式一般分为应用封装、接口交换和紧密集成模式。
封装集成模式，可以实现PLM对CAD系统文件整体的管理，却无法实现对CAD文件内部具体数据的更改管理。程序接口交换模式把CAD系统与PLM系统之间需要共享的数据模型抽取出来，把它定义到PLM的整体模型中去，这样，在PLM与CAD系统间就有了统一的数据结构，PLM即可实现与CAD系统之间文件内部数据的自动交换。紧密集成模式使不同应用成了PLM系统的有机组成部分，它们之间不仅可以共享数据，还可以共享操作服务，PLM具有对各种类型的信息提供全自动的双向相关信息的交换，包括产品信息、特征信息、参数和面向应用对象的信息等，但这种集成模式的实现比较有难度。
权衡几种集成模式，封装集成功能弱，实现变更数据集成比较有困难：紧密集成模式开发难度大，一般由开发商才能提供，所以通常情况下采用接口模式。
CAD系统有二维和三维之分。若更改对象是二维CAD，通过CAD的开发接口和PLM提供的API函数实现两系统的双向集成，CAD系统可直接访问PLM内部存储的数据。发生更改时，可以先在PLM系统完成零部件属性信息、结构信息的更改，修改后的信息自动体现在CAD图纸的标题栏和明细栏上；也可以先在CAD图纸上完成明细栏和标题栏的更改，更改后的零部件属性信息和结构信息也会自动反应到PLM系统中。
若更改对象为三维CAD，因为三维CAD开发难度大，传统的集成方式是单向接口模式，使得PDM系统能够提取CAD系统的信息，而不能进行PLM到CAD的反向映射，集成的信息一致性差，不适合实现变更数据的集成，所以，变更数据的集成需要采用双向接口模式。通过CAD系统的API函数访问CAD系统更新的产品装配模型，获取产品的装配关系、结构以及零部件信息等，再通过PLM系统APl提交PLM产品数据库。反之亦然，通过PLM系统的API函数导出产品更改后的BOM信息及模型文档，CAD系统由自身API函数读取产品更新的结构信息以及模型信息，在CAD系统中构建产品结构树，更新产品装配模型。变更数据集双向集成架构如图4-4所示。
图1-4 PLM／CAD双向接口
1.2.2PLM／ERP变更数据集成
由于工程变更涉及物料改变或加工方法的改变，必然会对后续的制造产生影响，通常在PLM系统中实现对工程变更过程和数据的控制与管理，在ERP系统中建立对工程变更结果的管理和控制机制，用于控制产品变更后的计划变更，因此，要实现工程变更的完整管理，需要PLM系统与ERP系统的高度集成。但是由于目前对变更管理的研究仅限于变更数据发布之前，因此对变更信息与ERP的集成研究很少。为了使下游生产阶段获得精确的变更数据，本文对变更展开了更加全面的研究，包含变更数据与ERP系统的集成。
1.2.2.1PLM／ERP集成技术
变更数据是PLM数据中的一部分，所以变更信息与ERP系统的集成是在PLM与ERP集成的基础上实现的。PLM与ERP的集成主要运用以下三种集成技术来实现：
1)数据库同构的直接访问：这种集成技术是基于ERP与PLM异构的基础上的。通过对ERP与PLM各自系统数据库的分析，直接对数据库及其属性进行访问来实现两系统之间信息交换，但运用此集成技术的前提条件是必须对ERP与PLM系统的数据库结构十分清楚，其实现原理如图1.5所示；
图1-5 基于数据库同构的直接访问的集成技术
2)利用API函数调用：这种集成技术利用ERP与PLM系统各自提供的API函数访问数据库，实现两系统之间信息交换，这种集成技术需要PLM与ERP系统都必须提供访问底层数据库的函数和API接口，并且往往仍然需要原系统开发人员的支持，开发工作量大、集成成本高，但通常可以获得较高的效率。其实现原理如图1-6所示；
图1-6 利用API函数调用的集成技术
3)中间文件：这种集成技术是将ERP与PLM系统各自需要交换的信息按照统一规定的标准文件格式和接口要求进行存储，两系统通过各自编制的数据导入／导出接口功能来实现系统问的信息交换，其实现原理如图1-7所示。
目前国内外提供的PLM、ERP系统大多为异构系统，两系统之间往往具有不同的数据结构和数据存储形式，而且通常系统内部数据不会对外开放，所以，一般采用中间文件的集成方式。基于中间文件的集成技术开发量周期短、集成成本低、容易实施、见效快，是最常用的集成方式，本文即采用了这种方式。
图1-7 基于中间文件的集成技术
变更数据不同于静态产品数据，它是过程中产生的动态数据，仅依靠PLM／ERP现有集成技术来实现频繁的变更数据与ERP的集成，存在集成数据量大，传递效率低的问题。因此，论文采用了一种处理动态数据的集成方法，仅通过接口传递变更前后对比结果，从而减少了数据传递量，提高了集成效率。
图1-8 变更集成信息
1.2.2.2PLM／ERP变更集成信息描述
从PLM传递到ERP的变更信息一般会涉及到产品信息，工艺信息和资源信息等，根据具体的表现形式可以归纳为以下三种：对象信息，层次结构信息和文档信息。对象信息如产品、零部件、材料、工艺、工序、设备、工装等，更改内容主要是相关属性信息；层次结构信息如产品结构关系，工艺层次结构等，更改内容主要是层次关系结构中父子对象的增加与删除、结构顺序的调整与结构中层次等级的调整；文档类信息指产品相关的各种文档文件，如产品设计文档，CAD模型文档，工艺规程、工序图、数控程序文件等工艺文档，更改内容包括文档文件的增加与删除、文档文件中内容的修改等。我们把由变更引起并需要传递给ERP的更改信息称之为变更增量。变更集成信息的描述如图1-8所示。
1.2.2.3变更信息集成方案
在PLM与ERP的集成研究中，关于静态数据在PLM与ERP中的传递已经有很多成功的案例。但变更数据不同于静态数据，静态数据一般以产品为单位产生批量接口数据而进行传递的，但产品技术数据(如物料属性，产品BOM，工艺文件等)变更后，并不能将变更后数据直接提交ERP系统覆盖原有数据，因为产品技术数据进入ERP系统后，一旦产品投产就会产生大量的以这些技术数据为基础或与之紧密相关的计划、物流等其他业务信息，直接覆盖可能会造成信息丢失，甚至是数据逻辑错误。目前采用的办法一般是在ERP系统中把批量更新的数据与现有数据进行对比，找出差异，然后根据差异确定导入策略。但采用这种方法，每变更一次，数据就得批量更新一次，接口数据量太大，效率低，对变更频繁发生的企业，容易造成数据传递负担。
为了减少接口数据量，提高效率，可以使用接口数据只传递变更增量的方法，即在PLM系统中实现更新数据和现有数据的对比，并通过PLM端的接口把变更增量导出到有标准文件格式要求的中间文件夹中，再由ERP端接口把变更增量信息从中间文件夹中导入到自己数据库中。本论文中间文件仍然采用数据库文件格式，只是需要使存储模型能通用于PLM和ERP的数据存储方式。
当变更数据发布时，在PLM系统中做出变更前后新旧版本的对比结果，确认改变的内容和位置，然后将新版本针对旧版本所做的更改如新增结构、删除结构以及不变结构等通过接口以表格的形式传递到中间文件中，再通过接口传递给ERP系统，这样，仅需要传递变更对象的对比结果，而不用以整个产品为单位批量传递数据，大大减少了接口数据传递量，提高了数据传递效率。ERP系统得到通知，就可以根据新旧版本的对比结果，自动或在ERP人员控制下对生产计划做出适当的修改。
变更前后对比结果首先存储在PLM系统的数据库中，根据不同的表现形式分别存储在不同的表格中。如表1-1存储的是对象更改信息，主要记录产品、零部件、材料等的属性信息的更改，如零件重量、体积等发生的更改；层次结构更改信息主要记录产品层次结构或工艺层次结构等结构方面做出的修改，记录内容包括更改对象的父部件、更改对象发生的版本变化以及它的变化行为(增加、删除、修改等)等，如表1-2记录了一个产品层次结构方面的更改，产品PDM08123零部件结构上发生了更改，增加了一个新的零件yy，它的版本变化是从无到有，它的变化行为属于增加；表1-3是文档更改信息的存储，主要记录某些文档的变化情况，包括文档的版本变化和文档的更改行为(增加、删除、修改等)。
1.3变更流程中的表单介绍
除了被修改的数据，工程变更过程中还会产生很多承载变更信息的表单，如问题报告单，变更请求单，变更通知单，变更评价单等。本节主要讨论了各表单的形式及表单中的内容。
图1-9 PR表单记录
问题报告表单是整个过程中最早记录变更的表单，它可能由企业中任何一个部门的任何一个人员来完成。只要发现处于发放状态的产品数据存在问题，就可以发起变更，而变更的第一步就是填写问题报告单。问题报告单主要用来指明存在问题的零部件，记录对问题的描述以及该变更的优先级。图1-9所显示的即是呈现在用户面前的问题报告表单。问题报告创建人需完成关于PR的记录，如PR编号，PR版本号，PR优先级等；需变更零部件的记录，如变更零部件编号及版本；而PR创建人、所在部门以及创建日期均根据用户的登录帐号和创建时间自动完成；最后是PR中最关键的问题描述，PR创建人要在描述中说明目前遇到的问题，如果原因明确，亦可描述出现该问题的原因，这将在后来的审查中作为PR能否通过的依据。
1.3.2ECR表单介绍
工程变更请求表单则会记录更详细的内容，包含更多的信息，它代表着正式变更的提出。变更请求用来迸行变更问题定义，主要说明变更的具体要求，变更原因，影响分析，造成其他的关联更改项，变更优先级以及变更解决方案等内容。PR审核通过后，变更请求(ECR)创建者会收到相关通知，而ECR也正是在PR的基础上创建。ECR表单如图1-10所示。
图1-10 ECR表单记录
在ECR表单创建之前，首先必须明确变更的原因，并在可选的变更原因选项中指明变更原因，这也是变更评价单中所用到的变更原因的最初来源；其次要由专门人员从各个方面对提出的问题进行影响分析；最后，在PR以及影响分析的基础上完成对ECR的创建。
论文前面流程分析中也提到过，对产品进行设计变更，带来的影响面非常大，会影响到产品的功能、性能、开发成本、开发周期、设计图档、文档；如果该产品已经投入了生产，还会影响到产品的生产计划、生产设备、工装夹检具、半成品的成本；如果产品已经投放市场，还要考虑产品的回收或替换等费用。如果变更前不能对变更所带来的影响进行全面分析而盲目进行变更，有可能会给企业带来灾难性的后果。为了避免变更给企业带来更大的损失，在创建ECR之前应该联合各部门人员共同对变更进行全面的分析，同时把分析的结果体现在ECR表单中。
在ECR中提供影响分析结果的目的，一是根据给出的分析结果判断执行变更的必要性，如果影响范围过大以至从时间或成本上均超出限制，损失远远大于收益，则这样的变更是没有必要执行的；二是针对分析结果对变更解决方案的提出给出指导性建议，比如通过影响分析，得知此次变更中存在受关联零部件，这样在给出解决方案时，就需要综合考虑同时受影响的零部件。
图1-11 ECR表单中的变更影响记录
因为这一阶段得到的信息均是从分散部门收集来的，比如就影响分析结果而言，它是由不同部门的不同人员得出的，所以为了能更好地为判断变更有无必要执行提供依据和为创建变更实施计划提供基础，论文中把本阶段得到的所有信息都汇总到ECR表单中，包括变更解决方案的描述以及变更带来的影响，这在PLM环境下是极容易实现的，因为这些数据都统一记录在PLM的数据库中，在流程中任何一个步骤都能把所需数据提取出来。图1-10所示ECR表单便汇总了本阶段所有信息，其中在ECR描述中，除了对ECR的基本情况做了展示，还把本次变更中所进行的影响分析结果做了总结，如图1-11所示。变更影响记录是判断ECR能否通过审核的依据。
1.3.3ECN表单介绍
1.3.4变更执行结果评价表单介绍
变更执行结果评价单是为了检查变更制造执行结果而发放的表单，也就是为了检查变更的制造执行是否实现了工作指令中要求的、最基本的零件的尺寸和技术要求等。表单内记录的内容主要是零件的尺寸和技术要求等，工作人员只需按照表单中记录的内容对实物进行检查并完成检查结果记录，即完成了对变更执行结果的评价。因为变更执行结果评价单是需要发放到车间进行实物检验的，所以论文中把它设计成了表格形式，并以文本数据集的形式对其进行归档保存。变更执行结果评价单如图1-13所示。
图1-13 变更执行结果评价表单
1.4总结
变更数据贯穿整个产品生命周期，在流程中的处理方式各不相同，并且数据分别来源于不同的应用系统，所以，数据在流程中的组织、各应用系统间数据的集成成为变更数据的研究重点。本章分析了PLM系统中工程变更数据的组织形式，根据变更对数据的需求，讨论了变更数据与其他应用系统如CAD系统、ERP系统的集成，从而确保整个变更过程中数据一致。文中还对变更过程中产生的各类变更表单的设计，如PR、ECR等做了详细介绍。
1.1工程变更数据组织
工程变更指的是对已经正式投入生产或使用的产品零部件进行的更改，需要修改的可能会涉及到被修改零部件的任何相关信息，包括相关对象如零部件、工艺、设备等的属性信息；各类文件和图档，如设计任务书、设计规范、二维图纸、三维模型、技术文件、使用手册等；以及在变更过程中产生的各种数据表单，如变更请求单，变更通知单，变更评价单等。图1-1所示为变更数据相关信息。
图1-1变更数据信息
变更过程中牵涉到的各种需要修改的数据多是在产品设计时产生的，一般以各种文档的形式存在，如设计说明书、技术手册等以word或其他格式存在，而图纸以CAD格式存在：变更过程中需要修改的各类产品属性信息在PLM中以属性记录形式存在；过程中产生的各种变更表单以PLM中设置的表单格式存在。所有数据记录在PLM数据库中均有保存。
合理组织所有的变更数据是管理变更数据的基础。工程变更对更改关联常用两种不同的处理策略，即面向问题和面向部件。面向问题的解决方案是把更改所关联的所有部件、文档、信息统一在一个ECR中处理；面向部件的解决方案是把更改所关联的所有也需更改的部件、文档、信息分别形成多个新的ECR单独处理。因为采用面向问题的处理策略可对变更对象统一处理，方便管理，也方便查询，所以，论文采用此方法构建了变更数据的组织结构。组织数据时，新建变更对象作为父节点，而变更请求，变更通知等以子节点的形式附在父节点之下。各子节点并不是一开始就全都存在，而是随各子流程的进行逐渐添加的。
当新建一个工程变更时，在个人空间内就会生成一个工程变更对象，其编码为“EC”加变更编号加变更名称，变更名称由用户自己定义，一般会包含被修改零部件编号和名称，如“EC0001-0800连杆更改”，对应此变更对象，自动生成其版本对象，如“EC0001／A-0800连杆更改”表示针对该零部件的A版本的更改。同时，在版本对象节点之下还生成若干文件夹形式的子节点，用来承载变更过程中使用或产生的各类数据，如受影响对象(Addressed by)，修改后对象(Affected Items，包含已修改好零件的零部件)，问题对象(ProblemItems，包含需被修改零件的零部件)，修改后零件(Solution Items)，当前自己需执行的任务(Tasks to Perform)以及当前需别人执行的任务(Tasks to Track)，如图1.2所示。
图1.2所示模型中，变更流程正处于ECR子流程中(此流程省去了PR子流程)，所以模型中有ECR对象“ECR0001-0800连杆更改”及其版本对象“ECR0001／A-0800连杆更改”，同时生成的还有ECR表单“ECR0001／A-ECR Form”，A记录了ECR版本对象的相关属性。图中✿表示处于流程中，表示目前变更流程正处于ECR子流程中。
图1-2 变更数据组织模型
图1-3 变更数据组织模型
同样，当变更流程走到ECN子流程时，系统自动完成ECN的创建，图1-2所示模型就会变成图1-3所示。从图中可以看出，整个变更仍处于流程中，ECN亦处于流程中，而ECR用√来标志，说明ECR子流程已经结束，ECR对象已处于发布状态。
随着流程的推动，工程变更的数据模型一步步增加节点，记录下变更过程中产生的数据，并在流程驱动下把数据呈现给需要的工作人员。这种数据模型确保在一个流程中，始终只存在一个变更根节点，过程中产生的所有数据对象均以子节点形式出现。直到所有子节点任务全都完成，整个变更流程才能结束，并对整个变更的父节点(如EC0001-0800连杆更改)添加√标志，标识变更的完成。把变更过程中涉及到的数据进行统一管理，不仅能避免变更的重复执行和执行不完善，而且能在任何时刻查询已完成的变更数据。
从模型中可以看出，仅仅在ECR、ECN这样的变更对象里并不能把所有的变更数据体现出来，比如图纸更改，BOM更改等。所以，数据模型提供了文件夹结构，如Affected Items等，用来保存变更过程中涉及到的其它数据。
Addressed by：关联更改，存放引起此次变更的其他工程变更；
Affected Items：已完成的零部件，更改后并已处于发布状态的版本零部件对象，它是问题零部件的一个新的版本；
Problem Items：问题零部件，将要被AffectedItems中零部件替代的更改前的版本零部件对象；
Solution Items：解决方案零件，变更过程中创建并已经发放的新的零部件。
例如在一个变更过程中，零部件X(A版本)因存在一定问题需被更改，于是发起了更改流程。更改时，零部件X的一个子部件xx需要改成yy，最后得到了零部件x的B版本。在这一过程中，A版本的零部件x将被放在Problem Itmes文件夹下，B版本的零部件X将被放在Affected Items文件夹下，过程中添加的X的子部件yy将被放在Solution Items文件夹下。各零部件所包含的子部件、数据集等也都跟零部件一块放在对应的文件夹下。
1.2变更数据集成分析
变更数据作为PLM系统中的部分数据，数据来源范围比较广，跟其他应用系统有着紧密的联系，为了保证整个生命周期内所有数据的一致性和完整性，变更数据与其他应用系统的集成异常重要。本节主要介绍了变更数据与CAD系统和ERP系统的集成。
1.2.1PLM／CAD变更集成分析
CAD系统产生的二维图纸、三维模型、零部件的基本属性、产品结构等，需要交由PLM系统来管理，而CAD系统也需要从PLM系统获取设计任务书、技术参数、原有零部件图纸、资料以及更改要求等信息。零部件的更改必然会涉及到CAD中模型、图纸及相关属性的更改，只有实现了两系统的集成，才能保证两系统间产品数据的一致。根据集成的紧密程度，CAD和PLM的集成方式一般分为应用封装、接口交换和紧密集成模式。
封装集成模式，可以实现PLM对CAD系统文件整体的管理，却无法实现对CAD文件内部具体数据的更改管理。程序接口交换模式把CAD系统与PLM系统之间需要共享的数据模型抽取出来，把它定义到PLM的整体模型中去，这样，在PLM与CAD系统间就有了统一的数据结构，PLM即可实现与CAD系统之间文件内部数据的自动交换。紧密集成模式使不同应用成了PLM系统的有机组成部分，它们之间不仅可以共享数据，还可以共享操作服务，PLM具有对各种类型的信息提供全自动的双向相关信息的交换，包括产品信息、特征信息、参数和面向应用对象的信息等，但这种集成模式的实现比较有难度。
权衡几种集成模式，封装集成功能弱，实现变更数据集成比较有困难：紧密集成模式开发难度大，一般由开发商才能提供，所以通常情况下采用接口模式。
CAD系统有二维和三维之分。若更改对象是二维CAD，通过CAD的开发接口和PLM提供的API函数实现两系统的双向集成，CAD系统可直接访问PLM内部存储的数据。发生更改时，可以先在PLM系统完成零部件属性信息、结构信息的更改，修改后的信息自动体现在CAD图纸的标题栏和明细栏上；也可以先在CAD图纸上完成明细栏和标题栏的更改，更改后的零部件属性信息和结构信息也会自动反应到PLM系统中。
若更改对象为三维CAD，因为三维CAD开发难度大，传统的集成方式是单向接口模式，使得PDM系统能够提取CAD系统的信息，而不能进行PLM到CAD的反向映射，集成的信息一致性差，不适合实现变更数据的集成，所以，变更数据的集成需要采用双向接口模式。通过CAD系统的API函数访问CAD系统更新的产品装配模型，获取产品的装配关系、结构以及零部件信息等，再通过PLM系统APl提交PLM产品数据库。反之亦然，通过PLM系统的API函数导出产品更改后的BOM信息及模型文档，CAD系统由自身API函数读取产品更新的结构信息以及模型信息，在CAD系统中构建产品结构树，更新产品装配模型。变更数据集双向集成架构如图4-4所示。
图1-4 PLM／CAD双向接口
1.2.2PLM／ERP变更数据集成
由于工程变更涉及物料改变或加工方法的改变，必然会对后续的制造产生影响，通常在PLM系统中实现对工程变更过程和数据的控制与管理，在ERP系统中建立对工程变更结果的管理和控制机制，用于控制产品变更后的计划变更，因此，要实现工程变更的完整管理，需要PLM系统与ERP系统的高度集成。但是由于目前对变更管理的研究仅限于变更数据发布之前，因此对变更信息与ERP的集成研究很少。为了使下游生产阶段获得精确的变更数据，本文对变更展开了更加全面的研究，包含变更数据与ERP系统的集成。
1.2.2.1PLM／ERP集成技术
变更数据是PLM数据中的一部分，所以变更信息与ERP系统的集成是在PLM与ERP集成的基础上实现的。PLM与ERP的集成主要运用以下三种集成技术来实现：
1)数据库同构的直接访问：这种集成技术是基于ERP与PLM异构的基础上的。通过对ERP与PLM各自系统数据库的分析，直接对数据库及其属性进行访问来实现两系统之间信息交换，但运用此集成技术的前提条件是必须对ERP与PLM系统的数据库结构十分清楚，其实现原理如图1.5所示；
图1-5 基于数据库同构的直接访问的集成技术
2)利用API函数调用：这种集成技术利用ERP与PLM系统各自提供的API函数访问数据库，实现两系统之间信息交换，这种集成技术需要PLM与ERP系统都必须提供访问底层数据库的函数和API接口，并且往往仍然需要原系统开发人员的支持，开发工作量大、集成成本高，但通常可以获得较高的效率。其实现原理如图1-6所示；
图1-6 利用API函数调用的集成技术
3)中间文件：这种集成技术是将ERP与PLM系统各自需要交换的信息按照统一规定的标准文件格式和接口要求进行存储，两系统通过各自编制的数据导入／导出接口功能来实现系统问的信息交换，其实现原理如图1-7所示。
目前国内外提供的PLM、ERP系统大多为异构系统，两系统之间往往具有不同的数据结构和数据存储形式，而且通常系统内部数据不会对外开放，所以，一般采用中间文件的集成方式。基于中间文件的集成技术开发量周期短、集成成本低、容易实施、见效快，是最常用的集成方式，本文即采用了这种方式。
图1-7 基于中间文件的集成技术
变更数据不同于静态产品数据，它是过程中产生的动态数据，仅依靠PLM／ERP现有集成技术来实现频繁的变更数据与ERP的集成，存在集成数据量大，传递效率低的问题。因此，论文采用了一种处理动态数据的集成方法，仅通过接口传递变更前后对比结果，从而减少了数据传递量，提高了集成效率。
图1-8 变更集成信息
1.2.2.2PLM／ERP变更集成信息描述
从PLM传递到ERP的变更信息一般会涉及到产品信息，工艺信息和资源信息等，根据具体的表现形式可以归纳为以下三种：对象信息，层次结构信息和文档信息。对象信息如产品、零部件、材料、工艺、工序、设备、工装等，更改内容主要是相关属性信息；层次结构信息如产品结构关系，工艺层次结构等，更改内容主要是层次关系结构中父子对象的增加与删除、结构顺序的调整与结构中层次等级的调整；文档类信息指产品相关的各种文档文件，如产品设计文档，CAD模型文档，工艺规程、工序图、数控程序文件等工艺文档，更改内容包括文档文件的增加与删除、文档文件中内容的修改等。我们把由变更引起并需要传递给ERP的更改信息称之为变更增量。变更集成信息的描述如图1-8所示。
1.2.2.3变更信息集成方案
在PLM与ERP的集成研究中，关于静态数据在PLM与ERP中的传递已经有很多成功的案例。但变更数据不同于静态数据，静态数据一般以产品为单位产生批量接口数据而进行传递的，但产品技术数据(如物料属性，产品BOM，工艺文件等)变更后，并不能将变更后数据直接提交ERP系统覆盖原有数据，因为产品技术数据进入ERP系统后，一旦产品投产就会产生大量的以这些技术数据为基础或与之紧密相关的计划、物流等其他业务信息，直接覆盖可能会造成信息丢失，甚至是数据逻辑错误。目前采用的办法一般是在ERP系统中把批量更新的数据与现有数据进行对比，找出差异，然后根据差异确定导入策略。但采用这种方法，每变更一次，数据就得批量更新一次，接口数据量太大，效率低，对变更频繁发生的企业，容易造成数据传递负担。
为了减少接口数据量，提高效率，可以使用接口数据只传递变更增量的方法，即在PLM系统中实现更新数据和现有数据的对比，并通过PLM端的接口把变更增量导出到有标准文件格式要求的中间文件夹中，再由ERP端接口把变更增量信息从中间文件夹中导入到自己数据库中。本论文中间文件仍然采用数据库文件格式，只是需要使存储模型能通用于PLM和ERP的数据存储方式。
当变更数据发布时，在PLM系统中做出变更前后新旧版本的对比结果，确认改变的内容和位置，然后将新版本针对旧版本所做的更改如新增结构、删除结构以及不变结构等通过接口以表格的形式传递到中间文件中，再通过接口传递给ERP系统，这样，仅需要传递变更对象的对比结果，而不用以整个产品为单位批量传递数据，大大减少了接口数据传递量，提高了数据传递效率。ERP系统得到通知，就可以根据新旧版本的对比结果，自动或在ERP人员控制下对生产计划做出适当的修改。
变更前后对比结果首先存储在PLM系统的数据库中，根据不同的表现形式分别存储在不同的表格中。如表1-1存储的是对象更改信息，主要记录产品、零部件、材料等的属性信息的更改，如零件重量、体积等发生的更改；层次结构更改信息主要记录产品层次结构或工艺层次结构等结构方面做出的修改，记录内容包括更改对象的父部件、更改对象发生的版本变化以及它的变化行为(增加、删除、修改等)等，如表1-2记录了一个产品层次结构方面的更改，产品PDM08123零部件结构上发生了更改，增加了一个新的零件yy，它的版本变化是从无到有，它的变化行为属于增加；表1-3是文档更改信息的存储，主要记录某些文档的变化情况，包括文档的版本变化和文档的更改行为(增加、删除、修改等)。
1.3变更流程中的表单介绍
除了被修改的数据，工程变更过程中还会产生很多承载变更信息的表单，如问题报告单，变更请求单，变更通知单，变更评价单等。本节主要讨论了各表单的形式及表单中的内容。
图1-9 PR表单记录
问题报告表单是整个过程中最早记录变更的表单，它可能由企业中任何一个部门的任何一个人员来完成。只要发现处于发放状态的产品数据存在问题，就可以发起变更，而变更的第一步就是填写问题报告单。问题报告单主要用来指明存在问题的零部件，记录对问题的描述以及该变更的优先级。图1-9所显示的即是呈现在用户面前的问题报告表单。问题报告创建人需完成关于PR的记录，如PR编号，PR版本号，PR优先级等；需变更零部件的记录，如变更零部件编号及版本；而PR创建人、所在部门以及创建日期均根据用户的登录帐号和创建时间自动完成；最后是PR中最关键的问题描述，PR创建人要在描述中说明目前遇到的问题，如果原因明确，亦可描述出现该问题的原因，这将在后来的审查中作为PR能否通过的依据。
1.3.2ECR表单介绍
工程变更请求表单则会记录更详细的内容，包含更多的信息，它代表着正式变更的提出。变更请求用来迸行变更问题定义，主要说明变更的具体要求，变更原因，影响分析，造成其他的关联更改项，变更优先级以及变更解决方案等内容。PR审核通过后，变更请求(ECR)创建者会收到相关通知，而ECR也正是在PR的基础上创建。ECR表单如图1-10所示。
图1-10 ECR表单记录
在ECR表单创建之前，首先必须明确变更的原因，并在可选的变更原因选项中指明变更原因，这也是变更评价单中所用到的变更原因的最初来源；其次要由专门人员从各个方面对提出的问题进行影响分析；最后，在PR以及影响分析的基础上完成对ECR的创建。
论文前面流程分析中也提到过，对产品进行设计变更，带来的影响面非常大，会影响到产品的功能、性能、开发成本、开发周期、设计图档、文档；如果该产品已经投入了生产，还会影响到产品的生产计划、生产设备、工装夹检具、半成品的成本；如果产品已经投放市场，还要考虑产品的回收或替换等费用。如果变更前不能对变更所带来的影响进行全面分析而盲目进行变更，有可能会给企业带来灾难性的后果。为了避免变更给企业带来更大的损失，在创建ECR之前应该联合各部门人员共同对变更进行全面的分析，同时把分析的结果体现在ECR表单中。
在ECR中提供影响分析结果的目的，一是根据给出的分析结果判断执行变更的必要性，如果影响范围过大以至从时间或成本上均超出限制，损失远远大于收益，则这样的变更是没有必要执行的；二是针对分析结果对变更解决方案的提出给出指导性建议，比如通过影响分析，得知此次变更中存在受关联零部件，这样在给出解决方案时，就需要综合考虑同时受影响的零部件。
图1-11 ECR表单中的变更影响记录
因为这一阶段得到的信息均是从分散部门收集来的，比如就影响分析结果而言，它是由不同部门的不同人员得出的，所以为了能更好地为判断变更有无必要执行提供依据和为创建变更实施计划提供基础，论文中把本阶段得到的所有信息都汇总到ECR表单中，包括变更解决方案的描述以及变更带来的影响，这在PLM环境下是极容易实现的，因为这些数据都统一记录在PLM的数据库中，在流程中任何一个步骤都能把所需数据提取出来。图1-10所示ECR表单便汇总了本阶段所有信息，其中在ECR描述中，除了对ECR的基本情况做了展示，还把本次变更中所进行的影响分析结果做了总结，如图1-11所示。变更影响记录是判断ECR能否通过审核的依据。
1.3.3ECN表单介绍
变更通知表单的发布意味着变更命令的下发，其中包含详细的企业变更实施计划，同时也包含已确定的对制品的处理方式。变更的工程执行任务的制定就是在变更通知单中列举的变更任务的基础上编制而成的。工程变更中的变更通知单如图1-12所示。
图1-12 ECN表单记录
1.3.4变更执行结果评价表单介绍
变更执行结果评价单是为了检查变更制造执行结果而发放的表单，也就是为了检查变更的制造执行是否实现了工作指令中要求的、最基本的零件的尺寸和技术要求等。表单内记录的内容主要是零件的尺寸和技术要求等，工作人员只需按照表单中记录的内容对实物进行检查并完成检查结果记录，即完成了对变更执行结果的评价。因为变更执行结果评价单是需要发放到车间进行实物检验的，所以论文中把它设计成了表格形式，并以文本数据集的形式对其进行归档保存。变更执行结果评价单如图1-13所示。
图1-13 变更执行结果评价表单
1.4总结
变更数据贯穿整个产品生命周期，在流程中的处理方式各不相同，并且数据分别来源于不同的应用系统，所以，数据在流程中的组织、各应用系统间数据的集成成为变更数据的研究重点。本章分析了PLM系统中工程变更数据的组织形式，根据变更对数据的需求，讨论了变更数据与其他应用系统如CAD系统、ERP系统的集成，从而确保整个变更过程中数据一致。文中还对变更过程中产生的各类变更表单的设计，如PR、ECR等做了详细介绍。
