一种基于PLM的支持汽车集团研发协作的架构❋

马 胜

（华中科技大学 国家CAD支撑软件工程技术研究中心，湖北 武汉 430074）

0 引言

在汽车企业，基于 PLM（Product Lifecycle Management，产品全生命周期管理）系统的汽车产品协同开发模式已成为一种趋势。世界著名的PLM咨询商CIMdata认为，PLM是一种企业信息化的商业战略，它实施一整套的业务解决方案，把人、过程和信息有效地集成在一起，作用于整个企业，遍历产品从概念到报废的全生命周期，支持与产品相关的协作研发、管理、分发和使用产品定义信息［1，2］。目前也有很多软件厂商开发了商业化的PLM软件系统，大部分PLM系统能够较好实现企业内部的研发协同，但是对于企业与外部延伸性企业之间的协同解决方案较少，本文正是对这种集团公司与外部的协同过程进行研究，并提出了一种实现汽车集团公司跨地区的协同以及与合作伙伴、供应商之间的协同框架。

1 整车协同开发过程分析

协同产品开发可以定义为不同的专业设计团队在产品设计过程中有序、高效地进行一系列协调和配合以实现共同的开发目标［3］。

整车典型开发过程是非常复杂的系统工程，涉及到企业内部多部门、多专业间的协作以及企业与企业之间的协作［4］。在整个产品开发过程中存在着如下的协同需求：①多专业设计协同：汽车产品的设计与开发是一项复杂的系统工程，需要大量多学科设计人员的协作参与完成整车的设计；②与异地设计中心的协同：在汽车产品设计阶段，整车厂设计部门可能需要与异地设计中心协同设计；③设计—制造协同：汽车产品设计过程中还需要制造部门对产品的可制造性进行评审，需要设计部门和制造部门的共同参与；④与合作伙伴的协同：汽车产品设计过程中，可能有部分系统、子系统、零部件等需要借助外力的帮助，这时整车厂需要与合作伙伴共同完成产品设计；⑤与供应商的协同：汽车整车设计完成后，对具体零部件的设计可能需要供应商的协同设计来完成，同时还可能需要供应商提供手工样件。

2 协同框架研究

2.1 汽车集团协同架构

在汽车集团企业中，整车厂作为一个核心部分，其他研发机构、供应商、合作伙伴等是辅助产品协同开发的延伸性企业。目前，整车厂的产品开发部门大都采用PLM系统来对产品的设计数据进行管理，为保证整车厂和外部合作伙伴进行协同开发，本文搭建了一套全球协同平台网络（Global Cooperation Network，简称为GCN），确保合作伙伴能够直接或者间接地访问协同平台服务器（GCN服务器），GCN服务端需要提供相关的工具来确保拥有PLM系统的企业可以直接通过PLM系统访问GCN服务器来获取产品协同对象信息，同时，对于不拥有PLM系统的合作伙伴提供直接通过浏览器访问GCN服务端的功能。为了支持整车厂和不同层次合作伙伴的协同并同时符合各延伸企业实际情况，需要有一种可灵活配置且扩展性强的部署架构，因此，本文提出了如图1 所示的协同架构图。

图1 协同架构图

该架构是以整车厂为核心，整车厂单独部署一套GCN服务器用于处理与协同相关的数据，整车厂与其他研发机构、供应商之间均通过GCN服务器实现产品的研发协作。该协同平台具有如下的关键能力：①基于Web的一体化协同开发；②不同的PLM系统可通过协同平台进行数据信息的交换。

所有的协同数据信息都会经过GCN进行传递，在企业的实际应用中，可能会碰到两种情况，拥有独立PLM系统的合作伙伴和不拥有独立PLM系统的合作伙伴，这时，拥有PLM系统的合作伙伴可以通过GCN将整车厂PLM数据传递给自身PLM系统，无独立PLM系统的合作伙伴则直接通过Web服务器访问GCN服务端。图2 为两种信息传递方式。

图2 两种信息传递方式

2.2 GCN服务端功能结构

在整个协同产品开发过程中，GCN服务端起着至关重要的作用，所有的协同对象信息都会经过GCN服务端，有些需要保存至GCN服务端，有些则可能通过GCN服务端提供的工具将相关的信息传递到其他的业务系统中供企业快速访问。因此，GCN服务端的结构好坏决定了协同的质量，本文设计的GCN服务端的功能结构如图3 所示。

图3 GCN服务端功能结构图

GCN服务端主要具有以下的功能：①提供访问产品数据信息（Product）的接口，整车厂用户和合作伙伴用户都可以访问与产品相关的数据信息；②提供同步协同过程（Process）的工具，在整车厂与合作伙伴协同开发产品的过程中，在双方访问协同对象、提交新的对象或者更新已有的协同对象时，GCN服务端可以提供同步的功能，将这些新的数据传递至需要的地方；③通过在整个产品开发过程中各个阶段的协同，进而达到整个产品的协同开发；④在整个协同过程中，GCN服务端随时更新通告便于双方用户及时了解项目的协同开发情况。

企业采用这种结构来进行产品协同开发可以获得如下的协同收益：①提供对已交付、接收内容的追踪能力，确保使用最新信息；②安全地分隔系统数据及控制脱离系统的数据，保护知识型资产的安全；③快速、全面地沟通更改信息。

2.3 协同层次划分

在汽车产品协同开发过程中必须有相应的对象、载体来支撑协同过程的实现，本文将这种支撑协同的对象、载体看成是一种“协作能力”。协作能力划分为如下4个方面：文档、数据包、任务、BOM。文档是最基本的协作对象，通过对文档对象的操作可以实现整车厂和合作伙伴间电子文档的相互传递。数据包是指文档的集合，可以将文档对象批量打包，一起传递给供应商／合作伙伴。任务是在对文档和数据包这些数据对象管理的基础上增加了对协作过程的管理，整车厂发布任务给供应商处理，供应商可以对任务进行分配，参与任务的人员依据自身的权限可以查看和下载不同的文档和数据包；同时这些任务执行人员也可以上传文档和数据包给整车厂的用户，整个任务的执行过程都会被监控。BOM是组织和管理产品数据的核心，BOM数据贯穿于产品的全生命周期，并作用于设计、采购、制造和服务等各项业务，要保证BOM在生命周期内的完整性和正确性，保证设计BOM、工艺BOM、制造BOM、采购BOM、服务BOM等多视图BOM数据的一致性。

同时，本文将整车厂的供应商／合作伙伴划分为如下类型：①上下游合作伙伴：存在产品生命周期上下游业务关系；②研发合作伙伴：存在设计委托关系；③主要部件供应商：较稳定合作关系，承担零部件设计分包任务；④一般部件供应商：较松散合作关系，偶尔承担某些零部件的设计分包任务。

本文根据对协作能力的支持以及合作类型确定了协作的层次，将协同的层次划分为4个级别：Level1，Level2，Level3，Level4。协同层次、合作类型和协同能力支持三者的关系如图4 所示。

图4 协同层次划分

从图4 中可以看出，整车厂与一般部件供应商之间的合作层次最低，是一种简单的合作关系，他们之间的协同对象主要有文档和数据包；整机厂与研发合作伙伴间的合作层次较高，他们之间的协同对象除了文档和数据包外，还有任务的协同；整机厂与上下游合作伙伴间的协作层次最高，他们之间的协同对象主要是BOM。

3 应用实例

本文以国内某一汽车制造企业为例，该企业采用上面提到的协同架构，实现了整车厂与合作伙伴的协同开发过程。具体业务过程如下：首先整车厂用户定义需求并将需求发布至指定的合作伙伴（异地研发机构或者零部件供应商），并及时地监控项目中各个过程的执行情况，最后验证合作伙伴提交的解决方案；而合作伙伴用户接收并下载委托方的需求，及时跟进各个过程执行的情况，同时提交解决方案供委托方验证。在整个协同开发过程中，可以给协同对象授予不同的权限，有些协同对象是仅供整车厂预览的，有些协同对象是可以供整车厂下载使用的，还有些是可以相互修改、共同访问的。

该汽车集团企业采用该框架协同开发后达到了如下的效果：①彻底取消纸质载体的图纸、光盘或U盘等形式的技术文件传递，全面提高协同任务、信息和交付物的传递及时性，提高沟通的频度并降低沟通成本；②通过协同平台提供的版本和可追溯控制机制，显著减少变更引发的各种错误和损失；③整车厂和集团内关键零部件供应企业的研发信息化支撑能力显著提升，同时，企业内跨部门协同效能显著提高，研发周期和质量均得到显著改进。

［1］庞辉，李红艳，方宗德，等.面向服务的汽车产品协同开发流程管理平台［J］.计算机集成制造系统，2011，17（5）：1-6.

［2］黄双喜，范玉顺.产品生命周期管理研究综述［J］.计算机集成制造系统，2004，10（1）：1-8.

［3］艾辉.复杂产品协同开发平台关键技术研究［D］.武汉：华中科技大学，2011：9-11.

［4］焦明海.供应商参与典型汽车产品开发的若干关键优化理论与技术研究［D］.沈阳：东北大学，2009：1-2.