3DExperience:PLM的知识点

PLM对象

PLM对象有以下几种(也是核心模型)：

1. PLM Reference
2. PLM Representation Reference
3. PLM Instance
4. PLM Representation Instance
5. PLM Port
6. PLM Connection

PLM对象都有各自标识符，标识符是实现CATIAdpPLMIdentificator接口的组件。

不要依赖CATIPLMIdentifierSet接口的GetIdentifierSet方法返回的字符串来比较两个组件，除非它们具有相同的PLM类型，并且来自相同的PLM定制。

PLM对象家族

PLM对象族是一组具有相同逻辑标识符的PLM对象。

逻辑标识符与物理标识符

每个PLM对象有两个标识符:物理标识符和逻辑标识符:
物理标识符:物理标识符在数据库中惟一地标识PLM对象。这个标识符是在会话中使用CATIAdpPLMIdentificator接口指针处理的标识符。它使您能够在会话中打开PLM对象，或者直接在数据库中进行操作。
逻辑标识符:逻辑标识符标识一组PLM对象。您不能访问此标识符，它是一个内部数据

具有相同逻辑标识符的PLM对象是同一个家族的。
保持逻辑标识符不变的操作:

PLM对象	操作
PLM Reference	versioning
PLM Rep Reference	versioning
PLM Instance	versioning owner, replace
PLM Rep Instance	versioning owner, replace
PLM Port	versioning owner
PLM Connection	versioning owner

PLM组件

PLM组件的定义

首先是PLM组件与PLM对象的关系

PLM组件是PLM对象在会话中的表示

PLM组件表示会话中的PLM对象。通过在数据库中查询PLM对象，打开PLM对象，在会话中就会有一个对应的PLM组件，类似于新建组件，在第一次保存新建组件后，PLM对象就会在数据库中。

虽然数据库中的PLM对象是完整视图，但PLM组件是部分视图。当在会话中加载PLM对象时只加载其部分属性。实际上，只有它的“客户端”PLM属性才被加载。

一个PLM组件需要实现CATIPLMComponent接口。

通过这个接口，您可以获得以下标识信息
数据库标识对象，一个实现CATIAdpPLMIndentificator的组件。
PLM类型对象，实现CATIAdpType的组件。

PLM组件是为了在会话中编写PLM对象

PLM组件包括更改PLM属性的值、添加链接、插入或删除实例等等。大多数功能都依赖于建模器，但有些功能是通用的，比如保存或访问PLM属性。当您使用CAA API时，无论打开还是新建组件都可能得到一个PLM组件。但交互模式下，只有编辑器创建PLM组件。

左边是两个分别编辑CAAProduct01和CAAProduct02的VPM编辑器，右边是一个编辑CAAProduct03和CAALogical01的RFLP编辑器。这3个编辑器至少创建了4个PLM组件，分别表示CAAProduct01、CAAProduct02、CAAProduct03和CAALogical01“至少”是因为加载PLM Reference意味着加载屏幕上不可见的另一个PLM对象。
相反，PLM搜索编辑器或导航器编辑器不创建PLM组件。

Instance/Reference模型表示

会话中的PLM组件对象是数据库中描述的Instance/Reference模型的映射。

当打开或创建PLM Representation Reference时，只能得到一个PLM组件。但是当打开或创建一个PLM Reference时，可以获得多个PLM组件。所有的结构都来自于根。下图显示了在数据库中PLM Reference及其结构。

当在会话中加载这个结构时，将创建六个PLM组件():两个PLM Reference，一个PLM Instance，一个PLM Representation Instance，一个PLM Representation Reference，一个Connection，每个组件都实现CATIPLMComponent接口，如下图所示：

() 使用api时要注意PLM Reference的PLM组件可能比它在数据库中的确切结构要少。根据引用加载模式，您可以在会话中获得更多或更少的PLM组件。

限制

限制是关于Instance/Reference模型的，因此也是关于PLM组件的。如果想要对复杂结构上的Instance应用颜色或位置，Instance/Reference是不够的。当只有Instance/Reference数据模型时，如何将特定的颜色应用于汽车的右后轮呢？

在会话中，我们有另一个模型表示结构的展开视图与这个类似数据库的模型并行。这个展开视图由名为PLM Occurrence的对象表示。产品模型使用PLM Occurrences。当您选择根或一个实例时，会在VPM编辑器中获得这些类型的对象。

PLM组件的管理

本节讨论使用PLM组件时的用到的重要概念。

每个PLM对象有一个唯一的PLM组件

在会话中，PLM组件只存在一次。让我们用一个例子来解释。

在上图中，可以看到CAAProduct03由两个编辑器使用:但是都使用相同的PLM组件。在RFLP编辑器中选择CAAProduct03时，得到的结果与选择VPM编辑器得到的结果相同。此外，假设您使用CAA命令打开CAAProduct03，打开的结果总是相同的PLM组件的CAAProduct03。

检索PLM组件

有很多方法可以检索PLM组件，通过选择、Navigation API，或者通过建模人员公开的任何其他API。CATPLMComponentInterfacesServices类的GetPLMComponentsInSession方法也可以检索。该方法检索当前会话中表示PLM Reference和PLM Representation Reference的所有PLM组件。

如果以交互或CAA API的方式加载CAAProduct03，通过GetPLMComponentsInSession方法只能获得CAAProduct03和CAAProduct01(应该是返回的PLM Reference)，被CAAProduct03聚合的CAAProduct01的实例也是一个PLM组件，但是不会被API返回。

生命周期管理

与任何对象建模器组件一样，它的物理生命周期是使用AddRef/Release机制管理的。当计数器减为零时，OM对象将从内存中删除。但这种基本的、必要的生命周期管理对于对于复杂的大型的数据是不够的。所以我们引入了一个逻辑生命周期。原则很简单:在PLM组件是逻辑上活着的时候可以使用它,当它在逻辑上死了，就不能使用它了:从会话中移除PLM组件的一部分我们称之为卸载。

逻辑生命周期由BAG对象管理。下一节中会说明这两个流程是如何实现的，什么是“卸载”，为什么引入这个逻辑生命周期，以及如何使用一个BAG对象。
在本文中，只关心使用BAG对象的两个场景。
一个好的使用BAG对象的场景：

1. 在会话中打开或创建PLM组件。
2. 将PLM组件放入一个BAG中。
3. 在必要时使用PLM组件。
4. 当你不再需要它：
   释放OM组件上的所有接口指针，以启用OM组件的物理生命周期结束(*)。
   从BAG中删除PLM组件——如果您是最后一个使用此PLM组件的人，那么它将从会话中卸载。

(*)Release方法可以在从BAg删除中删除操作之前或之后完成。

一个不好的使用BAG对象的场景：

1. 在CAA命令的会话中打开或创建PLM组件。
2. 在PLM组件上释放所有接口指针(或者不释放)。
3. 离开命令。

这是一个糟糕的场景，因为使用命令时PLM组件在逻辑上仍然是活动的，没有人知道它什么时候从会话中卸载。对于一个小模型，这不是一个大问题，但是对于大数据模型，内存可能很快就满了。当然，建议让命令释放接口指针，虽然这与不卸载PLM组件的内存泄漏相比要小得多。

理解PLM组件的生命周期

介绍

当在CATIA中打开产品模型时，模型将在当前会话中加载。对于应用程序，会话中PLM组件生命周期的管理与c++的对象管理一样重要。BAG对象使CAA开发人员能够在会话中有效地管理PLM组件的生命周期。

物理和逻辑生命周期

PLM组件在物理上是一个对象建模器(OM)组件，与任何OM组件一样，它的物理生命周期是由AddRef/Release机制管理的。当计数器减为零时，OM对象将从内存中删除。但对于复杂的大型的数据，这种基本的、必要的生命周期管理显然是不够的。所以我们引入了一个逻辑生命周期。原则很简单:在PLM组件是逻辑上活着的时候可以使用它,当它在逻辑上死了，就不能使用它了:从会话中移除PLM组件的大部分我们称之为卸载。

由于OM和Bag机制，这种管理是可能的。让我们来解释这两个生命周期是如何组合在一起以拥有一个高效的PLM组件生命周期的。

1. 当在会话中创建PLM组件时，将创建OM组件，并在内部完成一个AddRef，没有方法可以从物理上删除OM组件。
2. 当在会话中需要PLM组件时，将PLM组件“添加”到一个BAG中。每次添加，PLM组件计数器的逻辑值都会增加。
3. 当不再需要它的时候，就把它从BAG里拿出来同时减少PLM组件的逻辑计数器。
4. 当逻辑计数器减为零时，BAG机制执行以下操作:
   1. 通过Release来平衡初始Addref。此时可以从物理上删除。当所有OM组件上生成Addref的应用程序都将Release它们时，将通过OM机制完成删除。
   2. 它使OM组件无效:由于内部OM机制，我们可以说OM组件不再有效。其结果是OM上接口指针的所有方法调用都将失败，也不能再使用表示PLM组件的OM组件。
   3. 它从会话中卸载PLM组件的大部分。由于信封/信件机制，这是可能的。PLM组件的实际数据由终端用户无法控制的另一个OM管理。当调用OM组件上的方法时，实际上所有方法都被重定向到这个内部OM上。当计数器为零时，这个内部OM将被删除，并且大多数PLM组件的大小将减小

BAG的一个有趣之处是将内存从大型数据中释放出来。下面是开发BAG的另一个原因

在CATIA会话中PLM组件的生命周期

PLM组件的生命周期通常从在CATIA会话中加载它的过程开始。然后，用户根据自己的需求对加载的模型执行一系列操作，从简单的导航到实际修改PLM数据，如关联端口、聚合实例、修改属性等。生命周期结束于从CATIA会话卸载此PLM组件。

值得注意的是，除了PLM Reference 或PLM Representation Reference之外，用户不需要关心任何PLM组件的生命周期。这是因为PLM Ref(Reference)和PLM Rep(Representation) Ref(Reference)是仅有的两个可以分离的PLM组件。换句话说，这是仅有的两个独立存在的实体。对于所有剩余的PLM组件，即PLM Instance、PLM Rep Instance、PLM Port和PLM Connection，它们的生命周期实际上是通过聚合PLM组件绑定的。

一旦在会话中加载PLM Ref或PLM Rep Ref，他就是所有人都可以访问的共享资源。然后通过调用一个API，即CATPLMComponentInterfacesServices::GetPLMComponentsInSession，能够检索当前会话中加载的PLM组件列表。因此一个不注意，你自己的应用程序在当前会话中加载的PLM组件可以很容易地由另一个具有同等访问权限的应用程序卸载。

建议需要访问PLM组件的应用程序显式地将该组件保存在自己的BAG中。所以每个应用程序都有自己专用的BAG。当组件在CATIA会话中打开时，它被保存在一个专用于该会话的包中。只有在会话关闭时才会删除此组件。(例如，在CATIA中打开一个组件，如果在执行代码中的任何其他的操作删除或卸载了相同的组件，它在CATIA的会话中仍然可见)。

因此，为了更好地控制应用程序加载的PLM组件的生命周期，建议将这些组件插入一个“包”中，在此期间，这些组件对于客户机应用程序来说是必不可少的。“BAG”本质上是一个会话对象，将在下一节中详细介绍。

BAG对象

顾名思义，BAG对象在CATIA的当前会话中拥有插入其中的PLM组件。它主要是一个会话对象，能够更好地控制当前会话中加载的PLM组件的生命周期。

BAG对象只是一个c++类(CATOmbLifeCycleRootsBag)的实例化。

1. CATOmbLifeCycleRootsBag::InsertRoot方法将PLM组件(作为参数提供)插入到包中，从而增加其引用计数。
2. CATOmbLifeCycleRootsBag::RemoveRoot方法从包中删除PLM组件，从而减少其引用计数。如果引用计数器为零，则从会话中卸载PLM组件。

可以在当前会话中拥有多个BAG对象。这实际上意味着在CATIA会话中，PLM组件的生命周期可以从多个位置(交互命令、批处理)控制。建议所有需要访问PLM组件的应用程序都显式地将其保存在专用BAG中供自己使用。

后面看到了再补充