产品数据核心模型CPM（一）

CPM：A Core Model for Product Data—产品数据核心模型

Steven J. Fenves1, Sebti Foufou2, Conrad Bock and Ram D. Sriram

Manufacturing Systems IntegrationDivision,

National Institute of Standards andTechnology

Gaithersburg, MD 20899-8263

1. 概述

新一代的产品概念及应用建模试图支撑整个产品生命周期管理（PLM），包括支撑产品数据的建立、使用、存储，以及从产品最初概念设计到最终布置的各阶段的数据交换。

为了成功的对PLM进行支撑，需要一个可靠的、完整的和有效的数据模型。在PLM环境下中，关键要素隐藏于各种大量的信息流中。首先应该1）过滤这些信息；2）使其结构化；3）集成与控制信息；4）传递信息以便只有与任务相关的信息能够被要素接收和控制。没有一个可靠的产品数据模型，以上四个方面的活动都不能收到正确的效果。

这里所叙述的工作的最初目标是为NIST内部的四个研究开发项目提供一个公共的数据模型，同时也作为多层次设计信息流模型的基本数据表达方式^[1,2]。与此目的相对应的最初版本的CPM模型在文献[3]中叙述。

已经越来越清楚的表明CPM处理了一些支持产品生命周期管理全过程信息的关键因素。因此，扩展CPM作为整个产品描述信息的基本的、顶层模型成为了一个目标^[2]。

2. 核心产品模型

2.1 综述

CPM是一个具有通用语义的通用和抽象的模型。语义意味着任何特定的领域都嵌入一个具体的应用模型以及对该模型的使用策略。

CPM基于两个原理。首先，CPM的关键对象是制成品（artifact）。制成品是产品中的一个独立的实体，不管它是元件、零件、组建或者总成。第二，制成品是描述制成品的以下三个主要方面的集合：

l         制成品的功能（function）描述了制成品希望做什么。制成品满足客户或工程需求主要通过其功能实现。功能还常常用同义词预期行为（intended behavior）描述。

l         制成品的结构（form）描述了满足由功能所规定的设计问题提出的解决方案。在CPM模型中，制成品的物理特征包括几何特征（geometry）和材料（material），因为许多应用趋向于区别处理这两个方面。

l         制成品的行为（behavior）描述了制成品结构如何执行其功能。行为依据于工程原理，这些原理成为了行为或因果模型的一部分。对制成品的行为模型的应用描述或者模仿了制成品的观测行为（observed behavior）。通过考察需求对评价行为（evaluated behavior）的符合程度，观测行为可以得到检验。

CPM模型在整个产品生命管理周期（PLM）中对产品信息支持的适应性正是由于上述三方面在下列阶段的要求：

l         在产品结构还没有确定之前的早期的概念设计阶段，对产品需求的功能推理以及产品的功能配置；

l         在产品结构没有变化的随后的制造、操作和维护阶段，其行为（如制造性、操作性、价格或耐用性）可以在行为模型中建模、观察、评估和记录。

2.2 CPM模型的组成

依照实体-关系模型（Entity-Relationship Model），CPM由两组类，对象（object）和关系（relationship）类，组成。图1是其UML图。为了更清楚的阐述，图中的有关部分分别在图2到图5中再次给出。

图1 核心产品模型的UML类图

下文中，类的名字由大写字母开头（如Information），而属性的名字则没有（如information）。

2.2.1 抽象类

有5个抽象类（没有实例）：

l         CoreProductModel（核心产品模型）是通用的最高层次的抽象。

l         CommonCoreRelationship（通用核心关系）是所有关系类的基类。

l         CoreEntity（核心实体）是Artifact（制成品）和Feature（特征）类的基类。

l         CoreProperty（核心属性）是一个基类，其上派生出Function（功能）、Flow（流）、Form（结构）、Geometry（几何特征）和Material（材料）类。

图2描述了这些抽象类。

图2 CPM抽象类

2.2.2 对象类

有十一个对象类。

l         Artifact（制成品）描述了产品中独立的实体，可以是元件、零件、组建和总成。

l         Feature（特征）是产品结构的组成部分，具有特定的功能。一个制成品可以有设计特征，分析特征，制造特征等，并由各自的功能所确定。Feature可以有其自身的结构层次，所以一个组合特征可以在其它特征（但不是制成品）上构建。

l         Port（口）是一类特定的特征，有时可以用作接口特征，用来将一个制成品和另一个制成品关联。

l         Function（功能）是制成品希望做的事，即它的预期行为。

l         TranferFunction（传递功能）是包含将输入流传递或者转换到输出流的特定的功能。

l         Form（结构）是满足由功能所规定的设计问题的制成品结构方案，由几何特征和材料进行描述。

l         Geometry（几何特征）是制成品的三维描述。

l         Material（材料）是制成品内部元件的描述。

l         Flow（流）是作为一个或多个传递功能的输出和输入介质（物质、能量和信息流）。一个流也可以由其源制成品和目的制成品标识。

l         Behavior（行为）描述制成品的结构如何实现其功能。行为有三个特定的属性：

n         行为模型behaviorModel

n         观测行为observedBehavior

n         评价行为evaluatedBehavior

l         Specification（说明）描述了制成品的与设计相关的信息集合，这些信息来源于用户或者工程需求。

l         Requirement（需求）是Specification的特定要素，这些要素确定了制成品功能和结构的一些方面。需求不能应用于行为，行为完全由行为模型确定。

图3给出了对象类的视图。

图3 CPM对象类

2.2.3 关系类

有四个关系类。

l         Constraint（约束）描述了一组实体在任何情况下都必须满足的特定的公共属性。在CPM中，只支持构成了约束组的实体实例。

l         EntityAssociation（实体关系）是制成品、特征和口之间的一组成员关系。

l         Usage（使用）是两个CommonCoreObject（公共核心对象）间的映射关系。当约束只应用于特定的“目标”实体而不应用于“源”实体，或者当源实体位于一个外部目录或设计仓库中时，Usage是很有用的。

l         Trace（追踪）在结构上与Usage相同。当现行产品描述的“目标”实体以某种方式依赖于另一产品描述的“源”实体时特别有用。Trace的Tyep（类型）属性描述了一种自然的依赖关系（替代alternative_of，版本version_of，源于derived_from，基于is_based_on等等）。

关系类如图4所示。

图4 CPM关系类

对象类之间的关系如图5所示。

图5 对象类间的关系

2.2.4 工具类

有3个工具类。

l         Information（信息）是一个容器，由以下几部分组成：

n         一个文本的description（描述）槽；

n         一个文本的documentation（文档）串（即指向重要文档的文件路径或URL）；

n         一个property（属性）槽其中存储了一组成对的属性值串。

l         ProssInformation（过程信息）是一个关于产品开发过程的属性容器。这些属性如状态和水平，替换或版本，或者其它的过程处理描述。

l         Rationale（依据）描述了与制成品相关的特定决策的理由和依据。

如4.2中所述，在产生于CPM概念的中间信息模型中，工具类是基本的类。

2.3 关系与聚合

提供了以下关系：

l         除Flow以外的所有其它类都有各自有自己独立的层次，诸如“部分（part of）”关系和控制层次。

l         存在以下的联系：

n         一个Specification（说明）与产生于该说明的Artifact（制成品）之间的联系；

n         一个Flow（流）与它的源和目的Artifact（制成品）之间的联系，以及和它的输入输出Function（功能）之间的联系；

n         一个Artifact（制成品）和它的Feature（特征）之间的联系。

l         最重要的是，对CPM而言有四个基本的聚合：

n         Function，Form和Behavior聚合进Artifact；

n         Function和Form聚合进Feature；

n         Geometry和Material聚合进Form；

n         Requirements聚合进Specification。

 

3. CPM模型

具有三个层次的CPM模型，分别是概念模型，中间模型和应用模型。

3.1 概念模型

CPM构造了一个没有特定领域语义的概念模型。这样，CPM仅仅受限于属性如何去描述通用的产品信息以及如何去创建它们之间的关系。CPM故意剔除了领域属性（如机械或电子设备）和对象属性（如对功能、结构和行为的描述属性）。

3.2 中间模型

为了能直接使用CPM概念，采用了两个通用的信息建模概念以便能够创建中间模型。

首先，每个对象和关系都有一个在2.2.4中描述的Information（信息）属性。这里感兴趣的是属性的properties（属性）槽，它的属性值对记录了所有的特定的领域或者对象属性。

第二，除了抽象类和工具类以外，每个对象和关系都有一个type属性，其值是作为分类器的字符串。每个对象和关系类都有一个与该类相关的明确的术语层次。type的属性值相当于给定类的术语分类层次中的一个术语。例如，“转换”就是众多传递功能中的一个，它就可以作为该类的一个实例的type属性值。

有了上述两个建模概念，一个type属性值为“pin（销）”的制成品实例具有特定的直径和长度属性值，它的中间模型如图6所示。

图6 一个具有属性和值的CPM实例

这样，可以比较恰当的给出一个通用的表达，这样的表达对于制成品的概念设计已经足够。这里，通常具有比较少的实例，每个实例也具有较少的属性。或者从设计仓库的角度看，仅仅只存储了整个设计的最精华的表达。随着时间的推移，当中间模型建立以后，模型中的对象和关系类就可以形成自己的工程分类层次。最后，这样的分类系统将扩充成为一个完整的词汇及其语义关系的本体。然而，这样的中间模型并不会扩展成一个完整的应用。完整的应用具有成千个实例，每个实例都具有一长串特定应用的属性表。

3.3 应用模型

对工业系统应用而言，CPM的概念模型必须被转换成一个应用模型。这被称作模型编辑（model compilation），也是对象管理组（Object ManagementGroup， OMG）定义的模型驱动架构（Model-DrivenArchitecture， MDA）的一部分。MDA用来进行将诸如CPM这样的平台独立模型转换为特定平台模型，并用来作为一个通用高效的应用语言。

基于CPM的应用可以使用不同的type属性，它们的基本分类系统和属性值对存储在实体的property槽中，从而为CPM类的特定领域的模型编辑提供了一个手段。因此，模型编辑器应该：

l         依据type槽从Artifact（制成品）的分类层次中创建子类；

l         依据properties槽从属性名中定义子类的属性。

这样的子类可以作为个人信息管理（PIM）首先创建入UML仓库^[10]，然后进入可编辑的语言。这使应用的语言选择具有柔性。

最后，模型编辑可以用来将CPM的委托方式的重用设计转变为类型/实例方式的计算模型。在产品的生命周期中，CPM使用Artifact（制成品）在三个不同的层次上表达其信息：

l         物理对象的类的描述。如某种特定类型的齿轮箱的设计；

l         在组合设计中使用上面的描述用于其它的物理对象。如将特定的齿轮箱设计用于某个特定类型的小汽车描述中；

l         依据已有的设计描述物理对象。例如，一个序列号为3463的齿轮箱的维护记录，安装在车架号为92345645的小汽车上。

对于Artifact（制成品）的三种使用反应出从工程的观点看同一个制成品的生命周期具有不同的阶段。每个阶段都有不同的属性值甚至有不同的属性。这些阶段由ProcessInformation（过程信息）类的实例的不同的属性值区别开来并由CPM的Usage（使用）关系关联起来。另一方面，对上述的每个阶段计算模型都具有不同的要素，称为类型type（或类class），使用usage（或角色role）和实例instance。这反映出通用的信息系统构造习惯于使用程序开发环境来定义数据结构的形式（type，阶段1），并在不同的调试环境中监控这些程序的运行以获得以这些结构存储的实际数据（instance，阶段3）。现代建模技术引入用例usages或者角色role以进行更可靠的组合设计（usages，阶段2）。模型编辑者可以通过存储可以明确区分工程模型的不同阶段的规则，使用这些规则来分类制成品，从而生成相应的计算模型在工程观点和计算观点之间架起一座桥梁。

4. CPM的扩展

具报对CPM有如下扩展：

开放的装配模型（Open AssembleModel，OAM）。对装配提供了一个标准的表达与交换协议^[13-15]。装配模型定义了系统级的概念模型以及相应的关系层次。模型提供了公差，传播，动力学的表达方法以及系统级上的工程分析。

产品语义表达语言（Product SemanticRepresentation Language，PSRL）^[16]。将CPM用于产品信息的形式化表达开发。描述逻辑（OWL）被用来编码PSRL。

设计分析综合（Design-AnalysisIntegration）。项目提出了一个概念数据结构。该结构能够在功能设计和三维空间间提供一个紧密的整合，并支持分析驱动设计和机会分析^[17]。CPM作为主控模型的组织原理，基于该模型得到了一个很好的特定功能模型。

产品族进化模型（Product FamilyEvolution Model）。扩展CPM以表达产品族的进化及其有关变化的依据^[18]。模型通过组，系列，版本，以及变化的依据表达了产品和部件的独立进化。

混合材料模型（HeterogeneousMaterial Model）。扩展CPM到连续变化材料特性的组件^[19]。一个距离域与一组材料特性相关联，这些特性描述了材料特性的值和比率。

机电一体化设备模型（Mechatronic DeviceModel）。一个多相互作用的机电设备概念设计支持框架，这里在使用环境和设备之间的相互作用可以有不同的结构^[20]。在一个状态下的设备可以由CPM的扩展建模。

嵌入系统模型（Embedded SystemModel）。在嵌入系统中采用基于特征的方法来实现软件和硬件的协同设计^[21]。该方法通过定义对CPM的扩展类提供对嵌入系统特征模型的表达。

CPM的扩展和应用可以明确地将属性赋予特定的CPM对象和关系，以便能够与新系统，诸如STEP这样的已有的数据模型，或者已经存在的CAD程序进行协同的作用。

5. 实例

本部分中的行星轮系实例在文献[14]中进行了详细的说明，包括如何使用Artifact控制层次的表达和使用装配关系组成开放装配模型的表达。这里我们感兴趣的是CPM如何获取产品的设计信息，因此，只有从设计角度看显得重要的数据进行了建模。

图7是行星轮系统的组成元件：主要的制成品是行星齿轮；它由13个子制成品组成：输出座，输入座，行星轮，中心轮，行星架和八个螺钉。与这些子制成品相关的功能、结构、行为和说明信息这里没有表达。

 

图7 行星轮系

图8所示为以CPM表示的行星轮系的一个实例图。该图仅仅画出了作为Artifact（制成品）类实例的行星轮系实例的结构。该实例通过subArtifact（子制成品）关系与其它表示为子制成品的行星轮系实例相关联。该图同时也画出了Function，Form，Behavior，Specification和Feature类的实例。这些实例的属性及其属性值没有在图中画出。

 

 

图8 行星轮系的CPM实例图

6. 相关工作

CPM基于在制成品表达领域的现有工作。将制成品信息划分为结构、功能和行为目录基于在智能设计系统的早期工作。该模型是NIST的设计仓库项目^[7]的一部分^[7]。

MOKA项目与CPM项目具有相同的动机^[22]。MOKA采用了STEP、KIF和其它的相关DARPA成果来构建了一个基于工程知识库的产品模型。基于UML的MOKA建模语言（MML）被用来在用户层次表达工程设计知识，以便在知识工程（KBE）应用系统中进行部署。通过使用MOCA元模型作为领域应用模型的原型，MOKA比在4.3中描述的CPM应用模型更进了一步。MOKA产品模型支持产品的五个不同视图：

l         Structure（结构）定义了产品结构分解为零件、组件和特征的分解层次。在任何一个设计阶段，结构可以是物理的、逻辑的或者概念的；

l         Function（功能）定义了产品和解决方案的功能分解；

l         Behavior（行为）包含了产品各种不同的状态以及从一个状态转变为另一个状态的状态模型；

l         Technology（技术）包含了材料和制造信息；

l         Representation（表示）包含了用户定义的其它技术信息，包括物理结构的选择表达方案。

另一个具有类似动机的虚拟产品模型在包括功能分解、产品数据、设计过程信息和其它方面的产品各阶段的标准化建模方面进行了综合努力^[23]。

IMPROVE项目在过程系统工程领域进行了相似的探索，它将设计过程信息模型与过程系统设计信息模型集成在一起^[24]。

7. 综述与结论

CPM是一个具有通用语义的通用和抽象的模型。它给出了产品或者制成品的三个方面的等效状态：功能、结构和行为。因此CPM可以支持：1）概念设计阶段的纯功能推理；2）在随后的设计阶段中对行为进行记录与分析；以及3）产生于功能相对应的产品结构的“传统”的产品设计活动，通过分析与仿真评价产品行为，修改结构直到行为与功能相吻合。

现在，CPM以概念模型的形式存在。虽然发现了一些冲突的情况（例如，CPM不支持一些特征与行为相互独立的场合；在一些领域，几何特征和材料并不是结构的顶层说明），在相同的概念层次对CPM的扩展已经显示出CPM是易于扩展的。为了进行初步的说明，已经构建了几个中间层次模型。

将CPM作为产品生命周期管理中心信息支撑机制的程度取决于从CPM概念模型开发的应用模型。如3.3中所述，模型驱动架构的扩展或应用必须1）将平台独立模型转换为特定领域模型，以及2）从CPM的领域独立模型扩展类和属性到特定应用模型。

参考文献

[1]       Shooter, S. B.,Keirouz, W. T., Szykman, S., and Fenves, S. J., "A Model for the Flow ofDesign Information in Product Development," Engineering withComputers, Vol. 16, 2000, pp. 178-194.

[2]       Szykman, S.,Fenves, S. J., Keirouz, W. T., and Shooter, S., "A foundation forinteroperability in next-generation product development systems," Computer-AidedDesign, Vol. 33, No. 7, 2001, pp. 545-559.

[3]       Fenves, S. J.,"A Core Product Model For Representing Design Information," NationalInstitute of Standards and Technology, NISTIR 6736, Gaithersburg, MD20899, USA,2001.

[4]       Chen, P. P.,"The Entity-Relationship Model: Toward a Unified View of Data," ACMTransactions on Database Systems, Vol. 1, No. 1, 1976, pp. 9-36.

[5]       Booch, G.,Rumbaugh, J., and Jacobson, I., The United Modeling Language UserGuide, Addison-Wesley 1997.

[6]       Verrijn-Stuart AA. FRISCO - A framework of information system concepts – The Revised FRISCOReport (Draft January 2001), IFIP WG 8.1 Task group FRISCO. 2001.

[7]       Szykman, S., Racz,J. W., Bochenek, C., and Sriram, R. D., "A Web-based System for DesignArtifact Modeling," Journal of Design Studies, Vol. 21, No. 2,2000, pp. 145-165.

[8]       Allen, R. H.,Sriram, R. D., Szykman, S., and Fijol, R. J., "Representing the Chartersof Freedom Encasements in a Decision Repository: A Case Study,"Pittsburgh, Pennsylvania,2001.

[9]       OMG. Model-DrivenArchitecture. 2004.

[10]   Bock, C.,"UML without Pictures," IEEE Software Special issue onModel-driven Development, 2004.

[11]   Health Level 7.HL7 Reference Model. 2004.

[12]   OMG. UML 2.0Superstructure Specification. 2003.

[13]   Sudarsan, R.,Baysal, M. M., Roy, U., Foufou, S., Bock, C., Fenves, S. J., Eswaran, E.,Lyons, K. W., and Sriram, R. D., "Information Models for ProductRepresentation: Core and Assembly Models," NISTIR 7173, NIST,Gaithersburg, MD 20899, Dec. 2004.

[14]   Sudarsan, R.,Young-Hyun, H., Feng, S. C., Roy, U., Fujun W., Sriram, R. D., and Lyons, K.W., "Object-oriented Representation of Electro-Mechanical Assemblies UsingUML," National Institute of Standards and Technology, NISTIR 7057,Gaithersburg, MD 20899, USA, 2003.

[15]   Sudarsan, R.,Young-Hyun, H., Foufou, S., Feng, S. C., Roy, U., Fujun W., Sriram, R. D., andLyons, K. W., "A Model for Capturing Product Assembly Information ," toappear in Journal of Computing and Information Science in Engineering,2005.

[16]   Patil, L., Dutta,D., and Sriram, R. D., "Ontology-based Exchange of Product DataSemantics," IEEE Transactions on Automation Science andEngineering, Vol. 2, No. 3, 2005, pp. 213-255.

[17]   Fenves, S. J.,Choi, Y., Gurumoorthy, B., Mocko, G., and Sriram, R. D., "Master ProductModel for the Support of Tighter Design-Analysis Integration," NationalInstitute of Standards and Technology, Gaithersburg, MD 20899, NISTIR 7004,2003.

[18]   Wang, F., Fenves,S. J., Sudarsan, R., and Sriram, R. D., "Towards Modeling the Evolution ofProduct Families," Proceedings of the 2003 ASME Design EngineeringTechnical Conferences, Chicago, IL, 2003.

[19]   Biswas, A.,Fenves, S. J., Shapiro, V., and Sriram, R. D., "Representation ofHeterogeneous Material Properties in the Core Product Model, 2005.," Engineeringwith Computers, 2005.

[20]   Xu, C., Gupta, S.K., Yao, Z., Gruninger, M., and Sriram, R. D., "Toward Computer-Aided Conceptual Design of Mechatronic Devices with MultipleInteraction-States," 2005.

[21]   Zha, X. F.,Fenves, S. J., and Sriram, R. D., "A Feature-based Approach to EmbeddedSystem Hardware and Software Co-Design," 2005.

[22]   MOKA. MOKA: AFramework for structuring and representing engineering knowledge. http://www.kbe.coventry.ac.uk/moka/miginfo.htm . 1999.

[23]   Ingward, B., Falk,M., Edwin, S., and Erik, M.. Project iViP: Integrated Virtual Product Creation- Final Report. Frank-Lothar, K, Trac, T, and Irich, A. 2002. Organisationresponsible for production and manufacturing technologies (PFT), ResearchCentre Karlsruhe GmbH.

[24]   Marquardt, W. andNagl, M., "Workflow and Information Centered Support of DesignProcesses," Computers & Chemical Engineering, Vol. 29, No.1, 2004, pp. 65-82.