Steven J. Fenves1, Sebti Foufou2, Conrad Bock and Ram D. Sriram
National Institute of Standards and Technology
Gaithersburg, MD 20899-8263
新一代的产品概念及应用建模试图支撑整个产品生命周期管理（PLM），包括支撑产品数据的建立、使用、存储，以及从产品最初概念设计到最终布置的各阶段的数据交换。
为了成功的对PLM进行支撑，需要一个可靠的、完整的和有效的数据模型。在PLM环境下中，关键要素隐藏于各种大量的信息流中。首先应该1）过滤这些信息；2）使其结构化；3）集成与控制信息；4）传递信息以便只有与任务相关的信息能够被要素接收和控制。没有一个可靠的产品数据模型，以上四个方面的活动都不能收到正确的效果。
这里所叙述的工作的最初目标是为NIST内部的四个研究开发项目提供一个公共的数据模型，同时也作为多层次设计信息流模型的基本数据表达方式[1,2]。与此目的相对应的最初版本的CPM模型在文献[3]中叙述。
已经越来越清楚的表明CPM处理了一些支持产品生命周期管理全过程信息的关键因素。因此，扩展CPM作为整个产品描述信息的基本的、顶层模型成为了一个目标[2]。
l 制成品的功能（function）描述了制成品希望做什么。制成品满足客户或工程需求主要通过其功能实现。功能还常常用同义词预期行为（intended behavior）描述。
l 制成品的结构（form）描述了满足由功能所规定的设计问题提出的解决方案。在CPM模型中，制成品的物理特征包括几何特征（geometry）和材料（material），因为许多应用趋向于区别处理这两个方面。
l 制成品的行为（behavior）描述了制成品结构如何执行其功能。行为依据于工程原理，这些原理成为了行为或因果模型的一部分。对制成品的行为模型的应用描述或者模仿了制成品的观测行为（observed behavior）。通过考察需求对评价行为（evaluated behavior）的符合程度，观测行为可以得到检验。
l 在产品结构还没有确定之前的早期的概念设计阶段，对产品需求的功能推理以及产品的功能配置；
l 在产品结构没有变化的随后的制造、操作和维护阶段，其行为（如制造性、操作性、价格或耐用性）可以在行为模型中建模、观察、评估和记录。
图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。
2396
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
