3DExperience:Product Modeler

从工业实际模型到持久模型

Product Modeler

简化版滑板是由七个组装好的实体部件组成，属于三种类型:

1. 一个板子(粉色)。
2. 两个支架(灰色)。
3. 四个轮子(绿色)。

在Product modeler中，该滑板可表示为以下结构：

Reference：对部件或组装部件模型的引用。
Instance：实例，给定位置上的引用的模型，该实例所在装配体的引用聚合该实例。
Representation：表示零件的形状和几何形状的模型。
Links：实例和引用之间的链接:

1. 聚合:实例总是由引用聚合(SkateBoard R与Deck I的关系)。
2. ……的实例:实例总是与引用相关联(Deck I和Deck R的关系

Pointers：从引用指向其表示的指针。

Representations

Representations的主要任务是通过描述零件的形状和几何来表示零件。由于这些形状和几何不属于Product Modeler，而是属于Part Modeler，因此表示对象被分解为Product Modeler中的Representation Reference和Part Modeler中的Shape对象。

这两个对象(Representation Reference和Shape)在逻辑上是不同的。虽然Representation Reference可以访问到Shape句柄(即指针)，但它实际上也用聚合行为封装了形状。如果Representation Reference被删除，则Shape也将被删除。
Representation Reference是一个叶子对象，因此在语义上不同于作为结构化对象的Reference 。
要将Representation Reference集成到Instance/Reference模型中，需要通过专用实例进行实例化:Representation Instance。

相对于图一，用Representation Instance替换了Representation，该Representation Instance被Reference聚合，也是聚合了形状的Representation Reference的实例化。Representation用来表示这三个(RI,RR,Shape)对象的整体。
Representation Reference对象：

1. 只聚合实例，即要么是作为节点对象聚合来自Ref的Instance，要么是作为叶子对象聚合Rep Instance。
2. 拥有一个专用的生命周期。它们可以独立于Ref进行版本控制、更改或删除。例如，删除Ref时不能删除Rep Ref及其聚合的Shape。
3. 多表示。Ref可以聚合多个Rep，例如实际部件的精确Rep，以及用于显示和干扰检查的灯光Rep。作为多表示的一个例子，轮子可以有一个精确的Rep，一个不浅的Rep，比如一个圆柱体表示它的边界块，一个精确但浅的显示的图形数据，模拟的结果，或者一个绘图。注意，对于Product Modeler，所有Rep都是等效的。它们之间的区别由应用程序设置。

因此上述滑板现在有4种类型、17个Product Modeler对象：

1. 两个装配体Ref(Skateboard R和T&W Asm R)以及三个零件的Rep(Deck R，Truck R，Wheel R)。
2. 六个Instance(Deck I,Front I,Rear I, Truck I,Right I,Left I)。
3. 三个Rep Instance(Deck RI,Truck RI, Wheel RI)。
4. 三个Rep Ref(Deck RR,Truck RR,Wheel RR)。

三个Shape不是Product Modeler的一部分。

如果你想知道这个模型到底是怎样的，需要仔细思考。例如，它的轮数不是从轮的显示的Instance数推断出来的:两个轮Instance，而是四个实际的轮。因为它是一个节约模型，所以不能直接处理每个实际对象。你必须通过展开不同的对象来解释它，沿着从根到叶对象的链接运行，以计算实际对象。例如，从Skateboard R到Front I, T&W Asm R，一直到Right I，它的Rep是前右轮。因此，必须对这个模型进行解释，以理解真实的模型，例如显示它。这在从持久模型到会话模型中进行了讨论，但是在此之前应该满足另外两个组装设计需求。

模型的约束和发布

装配是通过将各部件相对于其他部件进行定位来实现的。这是必要的但不够的。例如，轮子和支架的轴是同轴的，需要同轴约束。即使移动轮子也必须与卡车轴保持同轴。可以使用Assembly Design Workbench在车轮和卡车之间设置约束确保同轴。

该约束很自然地添加到产品结构图中，与它约束的对象位于同一级别。在本例中，约束(Cnst1)使用经过实例的路径指向支架和车轮各自形状的旋转轴，然后跳转到Rep Instance、Rep Ref，最后指向Shape。为了完成设计，应该设置第二个约束，将左轮和支架约束为同轴。
从PLM Core modeler的角度来看，约束是一个Connection，一个更通用的对象，用于在PLM Modeler内或来自不同PLM Modeler的对象之间建模链接模式。另一个经典的Connection用法是将材料与Ref关联起来。

现在假设更换了支架部件的Shape，例如用另一个Shape替换原有的。

由Truck R聚合的RI被更改为与新创建聚合新Shape的Truck2 RR关联的Truck2 RI。前一个Instance被删除，约束Cnst1现在指向一个消失的Instance:约束被破坏。
程序集所有者可以手动将约束重定位到新Rep Instance和新Shape。这意味着支架部件所有者和装配体所有者(如果他们不是同一个人)要就设计更改进行沟通。此外，如果支架部件被属于不同所有者的几个程序集共同使用，通信过程将很困难。因此，使用名为发布(Publication)的中间对象使指向机制持久存在要简单得多，也更有效。
使用发布，Truck R设计者确保零件将始终会提供给组装设计师一个Truck的旋转轴，无论Truck R的设计者对Shape进行了任何更改。发布是一种接口，可以依赖于此发布设置约束。轮子也是相同的情况。

约束不再只通过Instance指向Shape，而是指向两个发布对象，这两个发布对象组成一个稳定的契约来访问Shape内的几何元素。
从PLM Core modeler的角度来看，发布是一个Port，是一个更通用的对象，可用于对其他数据模式建模。Port的另一个经典用法是在logic modeler或functional modeler中连接两个系统。

Instance/Reference模型

PLM Core modeler由六种类型的对象组成：

1. Reference.
2. Instance
3. Representation Reference
4. Representation Instance
5. Conneciton
6. Port
   从这六个对象构建的任何modeler都是Instance/Reference模型，比如Product Modeler，但也包括Process, Logical, and Functional modelers。
   Instance/Reference模型是永久的模型
   
   即使这个示例与工业程序集相比很简单(仅具有三个Instance/Reference级别)，也能表示要处理的对象以及在设计、浏览或扫描程序集时要处理的机制。

这样的程序集是在客户机会话期间创建和设计的，并保存在数据库中。程序集保存为Vault服务器中的Instance/Reference模型，而Shape及其几何图形则在Store server中进行流处理。

从持久模型到会话模型

如果Instance/Reference模型综合地表示一个程序集并有效地将其保存在数据库中，则此模型不符合会话需求。下图显示了CATIA 3D编辑器窗口中的滑板。

滑板显示为三维模型和树结构，通常称为规范树。这是会话中同一模型的两个视图。
在3D视图中，可以看到滑板有四个轮子，如果只查看Instance/Reference模型而不解释就是两个轮子。因此，这个3D视图不是Instance/Reference模型的粗略视图。它构建在一个名为Occurrence Model的模型之上，该模型是由Instance/Reference模型创建的。
Occurrence Model 不是持久性的，没有保存在数据库中。每当从数据库中读取Instance/Reference模型并将其加载到会话中时，就会重新构建该模型。这两个模型都驻留在会话内存中，可以交互访问，也可以通过编程访问。

Occurrence Model

Occurrence Model是根据数据库中加载到会话的Instance/Reference模型创建的。下图显示了如何创建。

创建Occurrence Model，通过沿着从根对象到叶对象的所有可能路径运行来扩展或展开Instance/Reference模型。彩色线条显示了这些路径。

• Step 0：为根Ref创建Occurrence。
• Step 1：沿着蓝色路径运行，从根到Deck I、Deck R、Deck RI，一直到Deck RR及其尖部，创建Deck Occurrence。
• Step 2：沿着黄色路径运行：
  • 从根通过Front I到T&W Asm R，创建Front T&W Asm Occurrence。
  • 然后从T&W Asm R通过Truck I, Truck R, Truck RI到达Truck RR及其尖部，生成Front Truck Occurrence。
• Step 3：沿着红色路径运行：
  • 从根通过Front I到T&W Asm R，和Step2中一样创建Front T&W Asm Occurrence。
  • 然后从T&W Asm R到Right I，Wheel R，Wheel RI，直到Wheel RR及其尖部，创建 Front Right Wheel Occurrence。
• 沿着绿色路径运行：
  • 从根通过Front I到T&W Asm R，和Step2中一样创建Front T&W Asm Occurrence。
  • 然后从T&W Asm R到Left I，Wheel R，Wheel RI，直到Wheel RR及其尖部，创建 Front Left Wheel Occurrence。

依此类推，直到运行通过所有叶子引用实例的所有可能路径。将为沿着这些路径遇到的每个Instance创建一个Occurrence。这就是为什么Occurrence也被称为Instance路径，从根开始，从一个Instance跳到另一个Instance。例如，Front Left Wheel Occurrence 是通过从根节点跳转到Truck & Wheel Assembly Front Instance和wheel Left Instance来构建的。
Occurrence模型不使用Rep Ref、Rep Instance、Connection和Port对象。它不包括Rep及其零件模型。

一个不同的模型

Occurrence模型实现了和Instance/Reference模型一样的接口，也实现了它自己特有的接口。

一个在会话中创建的模型

与Instance/Reference模型相反，Occurrence模型的创建不是自动的。当您通过CAA API在批处理会话中加载根产品时，需要你自己Occurrence事件模型生成。使用CATIPrdOccurrenceMngt接口的GetOrCreateRootOccurrence方法来实现。
交互模式下，在编辑根产品时自动创建Occurrence模型。框架编辑器调用它自己的Occurrence模型生成。

Instance/Reference模型的展开视图

Occurrence模型表示Instance/Reference模型的展开视图。Occurrence模型的UML模式如下:

一个Occurrence能够集合0个或者N个Occurrence。
当它是根Occurrence时，Occurrence表示Ref(在Instance/Reference模型中)，其他情况下表示Instance(在Instance/Reference模型中)。

一个例子

您可以观察到这个结构不包含Representation。Occurrence模型只表示PLM Product Instance/Reference。

一个上下文相关的结果

Occurrence模型是上下文相关的，原因有两个:

• 它的根Reference
• 应用于展开视图的过滤器。
  同一个Instance/Reference模型的两个配置意味着两个Occurrence模型。(未实现)

创建Occurrence模型时，必须指定两个上下文。

为什么是Occurrence模型

创建Occurrence模型以简化Occurrence发生时可用的操作的管理：

• 更改图形属性。
  在滑板上，你可以想象左后轮是红色的，右后轮是绿色的，这种变化是可能的，但不会持久。
• 改变位置矩阵

当这两个操作有效时，更改Occurrence模型将更改 Instance/Reference模型。 Instance/Reference模型总是最新的，并且表示要保存的模型的“引用”。此Occurrence从未保存在数据库中。

下表是Instance/Reference模型对象的接口以及用途。

Interfaces	Product’s Type Class	Meaning
CATIPLMComponent	all	T retrieve general information about the PLM Object (identifier, PLM class type)
CATICkeObject	all	Handling PLM Attributes (Get/Set)
CATIAlias	all	NLS name of the PLM object
CATIPLMNavReference	Product reference	Navigation purpose
CATIPLMNavInstance	Product instance	Navigation purpose
CATIPLMNavRepReference	Product rep reference	Navigation purpose+ applicative container management
CATIPLMNavRepInstance	Product rep instance	Navigation purpose
CATIPLMProducts	Product reference (*)	Authoring apis
CATIPrdAggregatedRepresentations	Product reference	Authoring apis
CATIPLMRepInstances	Product reference	Authoring apis
CATIPrdObject	all except connection
CATIMovable	Product instance (*)
CATIVisProperties	all
CATIPLMNavOccurrence	nothing	(except temporary the product references)

(*)表示其他一些产品对象实现了接口，但不能考虑其他实现。例如，CATIPLMProducts是由Product Instance和Product Reference实现的，但是Product Instance上的实现在时间上没有保证。

下表是一些对Occurrence模型对象有意义的接口。

Interfaces	Meaning
CATIPLMNavOccurrence	Navigation purpose
CATIMovable	Change the occurrence position
CATIVisProperties	Change the occurrence graphical properties
CATICkeObject	Yes, using CATCkeObjectAttrReadServices or CATCkeObjectAttrWriteServices you can get or modify PLM attributes associated with the instance/reference model
CATIAlias	NLS name of the occurrence
CATIPLMProducts	Do not use it
CATIPLMRepInstances	Do not use it
CATIPrdObject	Do not use it
CATIPLMComponent	Not Implemented
CATIPLMNavReference	Not Implemented
CATIPLMNavInstance	Not Implemented
CATIPLMNavRepReference	Not Implemented
CATIPLMNavRepInstance	Not Implemented
CATIPrdAggregatedRepresentations	Not Implemented

规范树和3D模型

上面说到Occurrence模型不包Rep对象及其部分，那么哪些对象构成了3D模型呢？规范树可以解释。

将Occurrence Model和规范树并排放置，可以看出使用Occurrence Model对象很好地构建了规范树，但不仅仅是：
- 带有图标和是Occurrences。
- 带有图标的是Rep Instance，连接到Shap以及他们的几何体。
PS：这是V6 2012及其以前的图标，在此之后的图标发生变化，需要参考新的图标。
同样，Connection和Port是规范树中看到的其他Instance/Reference模型对象，但这里没有显示。

PS：看了文档再写下来比和直接看文档费时多了。看来以后还是要少写。