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。