2 技术分析
    
     2.1 体系架构

    软件的体系架构决定了软件的可应用性、可扩展性等重要特性，不同的企业选择体系结构适合自身特点的PDM系统才能最大限度地确保实施的成功。
   
     随着Web技术、面向对象技术的不断发展和应用，国外PDM的体系结构日趋先进，已经从传统的客户机/服务器结构转向基于Web应用、J2EE技术、 C/B/S三段式结构的多层体系框架。通常，PDM系统的体系结构整体上分五层：底层平台层、PDM核心服务层、PDM应用组件层、应用工具层和实施理念层，这里主要讨论PDM核心服务层。
   
    PDM软件产品一般指的是核心服务层和应用组件层。在C/S结构下，核心服务层一般就是服务器端，客户端软件就属于PDM的应用组件，在C/B/S结构下，二者都运行于服务器端，但安装有所不同，核心服务是必须的，而应用组件是选用的，如TeamCenter的对象管理框架、Windchill的 Windchill Foundation、e-Matrix的AEF（Application Exchange Framework）都是典型的核心服务。

    核心服务层向下连接并操纵数据库，向上为应用组件服务，如Web处理机制、API应用集成接口等。核心服务层的核心是信息模型，它也是PDM的技术核心。

    相比而言，国产PDM在Web应用、J2EE技术等方面的发展比较慢，主流PDM软件普遍还停留在客户机/服务器模式，只有少数几家发布了支持Web应用的PLM产品，如清软英泰、上海同捷；在对象模型及多层结构方面，国产PDM正逐步朝建立核心服务层、应用组件层的方向努力，如开目PDM的对象模型。

    总之，受各种条件的限制，国产PDM软件可能在PDM体系结构五个层次的某个层次上有所进步和突破，但总体上与国外PDM软件还有一定距离。

    2.2 信息模型

   信息模型是PDM核心服务层的基础，在PDM体系结构中占有重要地位，包括对象模型和过程模型两方面。
   
    2.2.1 对象模型

    国外PDM系统已普遍采用了面向对象的数据建模方法。随着面向对象的方法、分布式技术的发展，国外PDM系统的对象模型已逐渐发展为面向对象、支持分布式管理的单一产品数据源的对象模型，如TeamCenter、Windchill、e-Matrix、SmartTeam等。

    在国内，各PDM厂商越来越意识到数据建模技术所提供的可扩展性对支持用户复杂业务和个性需求的重要性，已经从基于扩展数据表或字段的配置技术提升为使用建模工具进行数据建模的技术。面向对象的建模技术的研究也取得了一系列研究成果，并在一些国产的商品化PDM系统中得到了应用。国内PDM关于数据建模技术的一些现状和特点如下：

    * 部分国内厂商已经提供了面向对象的对象模型支持，如武汉开目和CAXA采用面向对象的对象模型；
    * 各厂商提供的对象模型各有特点，如清软英泰提供了基于语义网络的对象模型；
    * 对建模工具的图形化支持还不够，面向对象的能力支持不够，需要进一步提高性能，并扩展模型对PDM的支持；
    * 部分厂商提供了分布式对象模型支持，但分布式对象模型应用有多个层次，绝大多数国内PDM厂商并不支持分布式对象模型或只提供较简单的应用模式；
    * 分布式对象模型的用户一般是大型企业，往往选择国外知名的PDM系统，而绝大多数国内PDM厂商定位在中小型企业，所以关于分布式对象模型研究进展缓慢。

    2.2.2 过程模型

    国外的主流PDM系统均提供了较为强大的过程模型支持。
 
    在对象的全生命周期管理方面，国外的研究已基本成熟，并已在实际的软件系统中得到应用，如Smarteam、Windchill、TeamCenter和 e-Matrix等系统均支持对象的全生命周期管理。在工作流管理方面，国外开展的研究比较早，也比较深入。1995年，工作流管理联盟根据研究成果和应用实践制定了工作流管理系统的相关术语、体系结构及应用接口等方面的一系列标准，并提出了相应的过程流参考模型，目前，国外的主流PLM相关产品的工作流模型均支持此标准。

    在对象的全生命周期管理与工作流程的集成方面，国外PDM系统主要关注在面向对象的工作流应用方面，如Windchill和TeamCenter的变更管理。

    在国内，结合数据建模技术，各PDM厂商对面向对象的过程建模技术进行了一些研究，并对已有的PDM系统进行了改进，取得到了很好的应用效果。国内PDM关于过程建模方面的一些现状和特点如下：

    *过程模型的框架差异较大，采用的技术差别也较大；
    *过程模型提供的建模能力差异很大，现有的过程建模工具不足以支持用户复杂的业务过程；
    * 过程模型和对象模型集成不够理想；
    * 支持跨企业、跨地域的分布式应用的过程建模技术与国外相比有较大的差距；
    * 对支持符合业务需要的业务模型的研究不足；
    * 部分厂商提供了对WFMC的支持，但并不普遍，对相关国际标准的支持不够。

    2.3 功能模块

    系统功能模块实际上就是由调用核心基础服务的一组程序（界面）组成并能够完成一定应用功能的应用组件。国外PDM软件都在不断丰富自己的功能模块，根据 AMR Research的研究报告，国外PDM软件支持新产品的定义和投放市场的工程，市场，操作和原料等63种功能需求。应该说，国外各个PDM系统的功能模块已基本覆盖从产品概念设计到应用集成的各个业务层面。

    国外各个PDM系统之间的功能模块基本相同，但是存在一定差异。如TeamCenter提供了产品配置管理、生命周期管理等具体的模块，部分基础功能满足了制造业的基本需求，实施时利用现有模块和基础功能比较方便，在应用于制造业时有一定优势，而e-Matrix提供了较基础的系统构建框架，更加开放，但应用时配置工作量更大。
   
    相比而言，国产PDM的功能模块虽然已经基本覆盖PDM的功能边界，但在业务解决方案和细节方面还有待完善，功能模块的层次划分也不够清晰。
 
    常见的PDM系统功能模块有：文档管理、生命周期管理、更改控制管理、产品结构管理、产品配置管理、零部件族管理、产品可视化管理、工作流管理、项目管理、应用集成接口以及Web服务等。下面仅就项目管理和应用集成方面比较国产PDM与国外PDM之间的差异。

    2.3.1 项目管理

    从国外PDM产品的发展趋势来看，项目管理技术已从原来面向组织和功能的传统管理模式转变到面向项目的现代管理方式，通过项目将人员、流程以及各应用功能联结起来，从而构建面向业务的应用系统。如TeamCenter推出的TeamCenter Project项目协同模块，主要包括项目进度管理、项目资源管理、项目协同发布、项目跟踪与汇报、项目工作区安全等功能，支持将复杂的项目细化为明确的任务，并将这些任务分配给指定的资源，同时管理每个资源所承受的工作负荷；支持项目团队协作，促使产品价值链上项目团队的任务和调度同步，优化配置资源，降低开发成本。mySAP PLM提供的计划和项目管理模块，能够协助企业对产品开发流程进行规划、管理和控制，如控制项目的结构、日程计划、成本和资源等。Winchill解决方案中推出的项目协同管理Project Link，旨在将不同的产品开发以项目的形式进行管理，并通过Internet连接企业内外的供应链。

     国产PDM的项目管理普遍与文档签审流程紧密集成，而项目的资源管理、协同发布等项目管理的基本功能相对较弱，部分供应商通过与MS Project的简单集成实现项目的资源管理，但在工作协同方面则没有研究和应用。

    2.3.2 应用集成

    作为比较成熟的PDM产品，国外PDM系统都提供开放的软件接口，也具有较强大的集成组件。相比而言，受各种条件的限制，国内PDM普遍未提供开放的软件接口，各个PDM软件虽然与某个应用软件的集成性比较优秀，但从整体而言，应用集成性还处于比较低的层次。

    应用集成包括与单元应用软件、系统管理软件等各种软件之间的集成，下面主要讨论PDM与CAD、CAPP和管理软件之间的集成。

    2.3.2.1 与CAD的集成

    PDM与CAD的集成主要是与主流3D软件的集成。由于国内制造企业的3DCAD的普及比较晚，因而国产PDM与3DCAD的应用集成研究相对较晚，与国外PDM软件相比有很大的距离，主要表现在数据集成、浏览/圈阅工具、协同可视化工具等方面。
   
    国外主流的PDM软件基本能够支持15种独立CAD软件包，基于较完善的对象模型，基本与3DCAD实现了无缝集成；而国内PDM软件则主要支持几种主流的3D软件，如UG/ProE/SolidEdge/SolidWorks等，在数据集成的深度方面也很有限，仅处于数据提取的水平。

    在浏览和圈阅方面，国外PDM基本采用两种策略。

    以UGS、Windchill为代表的供应商采取自身开发浏览器的策略，并发布统一的3D浏览/圈阅工具（或控件），如UGS的JT2GO；

    以MatrixOne、Smarteam、Agile为代表的供应商则采取集成专业浏览器实现与3DCAD的集成，浏览器主要是业界领先的Cimmetry公司的AutoVue浏览器。

    受各种条件限制，国产PDM在3DCAD的浏览/圈阅方面还处于摸索阶段，部分厂商提供了与AutoVue浏览器的集成。

    2.3.2.2 与CAPP的集成

    基于CAPP软件的工艺解决方案是中国企业的独特需求，一直以来，国外PDM软件并不重视PDM与CAPP的集成，相比而言，国产PDM始终致力于国内企业的信息化工作，重视PDM与CAPP的集成工作，对CAPP软件的支持比国外PDM做的好。
 
    近年来，随着国内企业对PDM与CAPP集成的需求越来越强烈，国外PDM供应商也逐渐开始对国产CAPP软件提供支持，如Windchill提供了与开目CAPP的集成。

    2.3.2.3 与ERP/CRM的集成

    经过多年积累，国外PDM软件与ERP/CRM的集成已经非常成熟，在提供集成接口的基础上，对国外主流ERP/CRM，如SAP R3、Oracle Manufacture还提供专用的集成组件，如Smarteam、TeamCenter、Windchill等。而国产PDM与ERP/CRM的集成水平相对较低，基本停留在中间交换文件的水平上，没有与ERP/CRM的专用集成接口。

    3 实施分析

    3.1 解决方案

    国外软件供应商普遍将PDM软件作为PLM完整解决方案的一个组成部分，处理整个产品生命周期中的主要业务过程。如TeamCenter的协同平台（Collaboration Foundtion）、Windchill的CPC方案、MatrixOne的智能协同业务（Intelligent C-Commerce）等。

    同时，针对不同的行业，各个公司专门提供了行业解决方案。如TeamCenter公司针对汽车行业，Windchill公司针对船舶行业；Smarteam针对电子行业都提出了专门的行业解决方案。

    受各种条件的限制，国内还没有一家软件供应商提出并发布真正意义上的PLM完整解决方案或产品开发信息化的完整解决方案，往往以PDM为主体简单集成相关管理软件，达到实现产品数据全生命周期管理的目的，相比而言，无论完整性还是应用性都存在欠缺。

    3.2 实施方法学

    国外PDM供应商非常重视软件的实施，在大量成功范例的基础上，总结了众多的成功经验，形成适合本公司特点的实施方法学。这些实施方法学的主要特点如下：

     * 具有完整的实施模型和阶段划分，能覆盖实施的全生命周期；
     * 把需求收集、分析阶段作为整个实施过程的重点，切实了解用户需求；
     * 在关键阶段设置质量检验点，可进行全面质量控制；
     * 建立在大量的成功范例基础上，包含业界经验与Know-How技术；
     * 注重与用户的交流，容易被用户接受；
     * 提供了大量的实施文档模板，有效地引导和规范了实施人员的工作。

     结合现代项目管理理论，经过不断的摸索和实践，国内PDM供应商已经逐渐摸索出一套适合中国国情、行之有效的实施方法，并在具体的项目实施中得到良好应用，如CAXA和武汉开目的分阶段实施理论。

     4 结束语

     从体系架构、信息模型、功能模块、解决方案、实施方法学等几个方面的比较可以看出，国产PDM软件与国外PDM软件相比还有一定距离，特别是体系结构和解决方案方面尤其如此。随着国内企业信息化工程的不断深入，国内PDM软件供应商的投入不断加大，相信在体系结构、信息模型、功能模块等基础研究获得突破，并在项目实践中得到验证并发展后，国产PDM软件的水平会有一个大的发展。

    1  PDM中权限管理的数学表示
    1.1权限的集合定义
    PDM系统中，所有的产品数据都被定义为类——产品数据类，具体的产品数据表示为产品数据对象。产品数据类的方法是PDM中权限管理的基本对象。PDM系统中所有的权限可以定义为集合A ：
      A = A1∪A2∪A3∪A4，其中
      A1=（）
      A2=（）
      A3=（）
      A4=（）
    A被称作权限集合，A1、A2、 A3、A4分别被称之为权限子集合。
    A1是四元组的集合，A1中的一个四元组表示用户User在条件Condition满足的情况下，对于类Class的所有实例对象都具有执行Method方法的权限。同样，A2中的一个四元组表示工作组Workgroup中的所有用户具有执行Method方法的权限；A3中的一个四元组表示对象角色Object-Role具有执行Method方法的权限；A4中的一个四元组表示项目角色Project-Role具有执行Method方法的权限。
    1.2用户权限判定的函数表示
    用户权限判定指：在给定用户、对象和对象方法的前提下，判定用户是否具有权限执行该对象方法。用户权限判定可以定义为四元函数f(User, Object, Condition, Method)，其中：
    （1）函数f（）：返回值为True或者False, True表明具有执行权限，False表明不具有执行权限。
    （2）User：表示待考查的用户。
    （3）Object：表示待考查方法所属的对象。
    （4）Condition：以多元组（数据仓库，状态，属性1，…，属性n）表示，其中数据仓库、状态和属性i(1..n)分别表示对象所在的数据仓库、对象的状态以及对象的若干属性。
    （5）Method：待考查的对象方法。
    （6）函数f（）的推算过程：函数f（）的推算过程就是将四元组自变量按照一定的规则与权限集合A中的四元组进行匹配的过程，如果和A中的一个四元组匹配成功，则函数返回TRUE。如果无法和A中任何一个四元组匹配成功，则函数返回FALSE。具体的匹配过程先后在权限子集合A1、A2、A3和A4中进行。在任何一个权限子集合找到一个四元组能够与自变量四元组匹配成功，就中止整个匹配过程，返回TRUE。如果在四个权限子集合中都匹配失败，则函数返回FALSE。
    图1是在A1中进行匹配的示意图。自变量（User, Object, Condition, Method）与A1中任一四元组匹配成功须同时满足以下四个条件：
?    自变量User与A1中四元组的User值相同。
?    自变量Object是A1中四元组的Class类的对象实例。
?    自变量Condition满足A1中四元组的Condition所定义的条件。
?    自变量Method方法与A1中四元组的Method相同。
    A2、A3、A4中的匹配条件与A1中的类似，只不过上述第一条不同。在A2中，第一条变为：自变量User是A2中四元组的Workgroup所确定工作组的成员。在A3中，第一条变为：自变量User是A3中四元组的Object-Role所确定的对象角色；在A4中，第一条变为：自变量User是A4中四元组的Project-Role所确定的项目角色。

图1  权限子集合A1中的匹配处理示意图

    2  基于产品数据二级分类的权限管理模型
    权限管理模型设计中，最难以处理的是协调数据共享与数据保护的矛盾。为妥善解决此问题，在本文提出的权限管理模型中，将产品数据分别按照所有者和管理方式进行两级分类，根据产品数据分别在两级分类中确定的类别，采用不同的权限控制策略进行管理。
    2.1 产品数据两级分类
    产品数据两级分类中，首先是按照管理模式将数据分为两大类：项目数据与非项目数据，项目数据是指按照项目模式管理的产品研制过程中形成的数据，比如：设计图纸、技术文件、零部件、源程序等；非项目数据指按照非项目方式管理的数据，通常不是产品研制过程中直接产生的数据，也不属于产品本身的设计数据，比如：标准件、通用件和元器件数据等，这些数据往往是设计产品的参考和引用数据。
    将产品数据分为项目数据和非项目数据后，再按照所有者将数据进一步细分为三小类：私有数据、共享数据和归档数据。私有数据指PDM中用户个人工作区中的数据，是用户个人私有数据；共享数据指在PDM共享数据仓库中的数据，这些数据或者是处于审签流程中的数据，或者是需要在一定范围内共享的非正式数据；归档数据指在PDM归档数据仓库中的数据，属于正式发放的数据。
    按照两级分类管理，实际上将产品数据分为六小类，即按照项目模式管理的数据又分为私有、共享和归档三小类，按照非项目模式管理的数据也细分为私有、共享和归档三小类。
    现代的PDM系统中，所有的产品数据都被定义为对象来管理，上文所述产品数据二级分类方法，实际上也是产品数据对象的二级分类方法，相应地产品数据对象类别也称之为：项目数据对象、非项目数据对象或者私有数据对象、共享数据对象和归档数据对象。
    2.2 用户组织模式
    企业中人员的组织模式通常分为三种：静态组织机构型、动态项目型和混合型[3]。静态组织机构型指人员固定工作于企业中某一个部门；动态项目型指用户动态地被分配到项目组内工作，项目结束后，又被分配到另外一个项目中；混合型是前两种形式的结合，相当于企业中的矩阵式管理模式，人员一方面属于某一个具体的部门，同时又动态地属于某一项目。
    在本文所提出的权限管理模型中，用户的组织采取混合型的方式。具体采取以下三种组织形式的混合模式：
?    对象角色：定义属于对象实例本身的角色，模型中涉及到的角色有：对象的责任方和对象的查阅组。担任对象角色的用户，通常随对象的变化而变化。
?    项目角色：定义属于项目的角色，包括项目负责人、项目成员等等。担任项目角色的用户通常随项目的变化而变化。
?    工作组：工作组是一种静态的用户组织模式，工作组成员一经定义，不受对象与项目因素的影响。
    用户可以同时属于上述的三种形式的任何一个组织中。
    2.3 产品数据对象权限分类
    模型中，对PDM系统中实际的产品数据对象权限分类方式进行了简化，只分为两种权限：写权限和读权限。写权限泛指可以引起对象属性、所有者和状态变化的操作权限；读权限泛指获取对象信息，而不会引起对象属性、所有者和状态变化的操作权限。
    2.4产品数据对象写权限管理策略
    模型中，产品数据对象写权限的管理策略比较简单，即：写权限只赋予对象角色——责任方。对象刚刚创建时，由系统自动将创建者定义为对象的责任方。此后在对象的生存周期内，如果对象的设计负责人需要发生变化，按照以下规则进行变更：
?    对于项目数据对象，只有项目负责人和管理员有权限变更对象的责任方。
?    对于非项目数据对象，只有系统管理员有权限变更对象的责任方。
    采取将写权限赋予对象责任方的管理策略，简化了对象写权限控制逻辑，支持对象写权限拥有者的动态变化。在这种管理策略下，还实现了同时只有一个用户具有对象写权限，避免了由于多用户同时具有写权限造成的对象一致性失控问题。
    2.5 产品数据对象读权限管理策略
    按照两级分类方法，针对不同类别的产品数据对象采取不同的读权限管理模式。
    2.5.1 项目数据的读权限管理策略
    项目数据对象又可以细分为：项目私有数据对象、项目共享数据对象和项目归档数据对象。
    （1）项目私有数据对象读权限管理
    对于项目中的私有数据对象，读权限只赋予对象的责任方。
    （2）项目共享数据对象读权限管理
    当项目私有数据对象变为共享数据对象后，应该能够在项目组内部进行共享，以方便项目成员间的信息交流，但是这种共享是受控的，应该让对象的所有者决定哪些项目成员具有读权限。
    具体的权限设定是：将项目共享数据对象的读权限赋予对象责任方和对象的查阅组成员。对象的查阅组由对象的责任方负责定义，责任方定义对象查阅组成员时的可选范围是所有的项目角色成员，因此对象的查阅组总是对象所在项目的所有角色成员的子集。
    （3）项目归档数据对象读权限管理
    项目中的产品数据对象归档后，除了项目内部成员仍然具有读权限外，作为企业正式发放的产品数据，还应该有选择地使项目外的用户共享，这样才能实现设计复用和快速产品开发等先进的管理理念。因此项目中归档数据对象的读权限，除赋予对象责任方和对象的查阅组成员外，还赋予具有某商业密级的工作组。
    给项目数据对象增加一个属性定义：商业秘密等级，其可选值有：公开、普通秘密和核心秘密。同时设立三个商业密级工作组与之对应，将这三种商业秘密等级的归档数据对象的读权限分别赋予这三个工作组。将PDM的所有用户按照涉密授权分别分配到这三个组中。这样，归档后的项目数据对象就实现了在项目外受控共享。
    如图2所示，项目数据由私有数据变为共享数据后，共享范围扩大到项目成员范围，变为归档数据后，共享范围进一步扩大到项目外的某一工作组范围。上述过程中，数据越来越正式，共享的范围也不断扩大。

图2   项目数据读权限管理示意图

    2.5.1 非项目数据对象的读权限管理策略
    如前所述，非项目数据对象不属于具体的产品设计数据，因此非项目数据通常包括企业内的基础数据，需要在企业范围内共享，以便设计人员参考和引用，因此读权限控制较松，管理简单。非项目数据中的私有数据对象读权限只赋予对象的责任方，共享数据对象和归档数据对象的读权限通常向所有的用户开放。
    3  应用实例
    本文提出的权限管理模型在某电子研究所PDM系统－－Teamcenter Enterprise 4.0上获得实现。在系统设计时，将16种产品数据对象中的设计图纸、技术文件、产品组合、装配件、零件、软件、源程序、目标程序、逻辑设计包、PCB设计包和结构设计包共计10种对象按照项目数据对象的方式进行权限管理，将其余的标准件、元器件、产品设计更改审批单对象按照非项目数据对象的方式进行管理，较好地协调了数据共享和数据保护两方面的需要,满足了该所产品数据管理中权限控制的要求，取得了理想的工程应用效果。

    4  结论
    本文从归纳总结PDM系统中的权限管理特点入手，给出了PDM中权限的集合定义和用户权限判定的函数表示，同时提出了基于产品数据两级分类的权限管理模型，并介绍了模型在某电子研究所的具体实现情况。本模型较好地协调解决了数据共享和数据保护两方面的问题，能够满足企业中产品数据管理的需要，而且权限控制逻辑本身条理清楚，简单明了，用户容易接受和理解，工程上也易于实现。