在日常开发中，我们常常会遇到这样的困惑：为什么我在数据库里只存了2个轮子，但在CATIA的树状图（Specification Tree）里却看到了4个？为什么修改了零件的几何形状，装配约束有时候会断开，有时候却依然牢固？
其实，这一切的背后都隐藏着V6（3DEXPERIENCE）架构下Product Modeler的核心逻辑。今天，我们就通过文档《Product Modeler Overview》，用一个简单的滑板模型，带你彻底看懂CATIA背后的实例/参考模型（Instance/Reference Model）与发生模型（Occurrence Model）。
🛹 从现实到数据：滑板的“极简主义”存储
想象一下我们要在计算机里存储一个滑板。直观的想法是，滑板有1个板面、2个 Trucks（桥）、4个轮子，那就是7个物体。
但在工业软件的世界里，为了数据的高效与一致性，我们不能简单地“复制粘贴”。文档引入了一个经典的滑板（Skateboard）案例，它由以下部分组成：
-
1个 Deck（板面，粉色）
-
2个 Trucks（桥，灰色）
-
4个 Wheels（轮子，绿色）
如果直接存储这7个物理零件，会导致数据冗余且难以管理。因此，Product Modeler 采用了“实例/参考”的机制。
1. 为什么要区分“参考”与“实例”？
在软件中，我们定义了参考（Reference）和实例（Instance）。
- 参考（R）：是零件的“定义”或“蓝图”，它不占据空间，只定义属性（如零件号、版本）。例如，只有一个“轮子”的参考定义。
- 实例（I）：是参考在特定位置的“出场”。它没有自己的几何形状，只有位置信息（坐标系）。
滑板的精简逻辑：
- 轮子： 4个轮子是完全一样的。所以我们只需要 1个轮子参考（Wheel R） + 4个轮子实例（Left I, Right I…）。
- 桥组件： 前桥组件和后桥组件结构相同，只是位置不同。所以我们只需要 1个桥组件参考（T&W Asm R） + 2个实例（Front I, Rear I）。
| 对象类型 | 数量 | 组成说明 |
|---|---|---|
| 参考 (Reference) | 5个 | 2个装配参考 (Skateboard R, T&W Asm R) + 3个零件参考 (Deck R, Truck R, Wheel R) |
| 实例 (Instance) | 6个 | 1个Deck I + 2个T&W Asm I (Front, Rear) + 1个Truck I + 2个Wheel I (Left, Right) |
| 表示参考 (Rep Ref) | 3个 | Deck RR, Truck RR, Wheel RR |
| 表示实例 (Rep Inst) | 3个 | Deck RI, Truck RI, Wheel RI |
| 总计 | 17个 | (注：文档明确指出这还不包含Part Modeler里的3个Shape) |
通过这种机制，原本物理世界中的7个零件，在数据库里被描述为17个逻辑对象。虽然逻辑对象增加了，但通过‘参考/实例’分离，实现了几何数据的共享。
2. 核心三角：参考、实例、表示
文档中详细描述了这三者的关系，这是理解CATIA数据结构的基石：
- 参考（Reference）：结构化对象。它“拥有”实例（Aggregation）和表示参考（Representation Reference）。
- 实例（Instance）：存在于特定位置。它“属于”一个参考（Is Instance of）。
- 表示（Representation）：负责几何形状。参考指向一个表示参考**，而表示参考再聚合形状（Shape）。**
数据流向是这样的： Instance (位置) -> Reference (定义) -> Representation Ref -> Shape (几何体)
3. 约束（Constraints）与发布（Publications）
这是很多开发者容易踩坑的地方。在装配中，我们给轮子和桥加了同轴约束。
- 约束的本质： 它是一个连接（Connection），它指向的是几何形状（Shape）上的具体元素（如轴线）。
- 潜在风险： 如果零件设计者修改了轮子的几何体（比如把圆柱体改成了方块），原来的轴线消失了，约束就会断开（Broken Constraint）。
- 解决方案——发布（Publication）： 为了解决这个问题，引入了端口（Port）/发布对象。零件设计者通过“发布”将内部的几何元素（如轴线）暴露为一个稳定的接口（Pub1, Pub2）。约束不再直接指向几何体，而是指向这个“发布”。无论内部几何体怎么变，只要发布接口不变，约束就依然有效。
💻 从存储到显示：发生模型（Occurrence Model）
回到文章开头的问题：为什么树状图里有4个轮子？
这是因为我们在CATIA界面（Session）看到的，不是直接从数据库读出来的“实例/参考模型”，而是一个临时生成的模型——发生模型（Occurrence Model）。
1. 什么是“发生”（Occurrence）？
“发生”其实就是一条从根节点到叶子节点的完整路径。
- 数据库模型（Instance/Reference）：是紧凑的，轮子只有2个实例对象。
- 会话模型（Occurrence）：是展开的。为了让你能直观地看到、选中每一个轮子，系统会自动遍历所有路径，生成“发生”。
生成过程（Unfold）： 系统会从根节点（Skateboard）开始，沿着所有可能的路径往下走：
-
路径1：Root -> Front I -> Right I -> Shape（生成：前右轮发生）
-
路径2：Root -> Front I -> Left I -> Shape（生成：前左轮发生）
-
路径3：Root -> Rear I -> Right I -> Shape（生成：后右轮发生）
-
路径4：Root -> Rear I -> Left I -> Shape（生成：后左轮发生）
2. 树状图（Specification Tree）的秘密
你在CATIA左侧看到的树状图，其实是发生模型的直接映射。每一个节点都是一个“发生”。
- 特点： 发生模型是临时的（Transient），它在打开文件时生成，在关闭文件时销毁（除非你对某个发生做了特殊的图形属性重载，比如把前轮改成红色，这种重载信息会保存下来）。
- 不包含约束和端口： 你会发现树状图里没有显示“约束”和“端口”对象，因为发生模型只负责展示层级和几何显示，不包含逻辑连接信息。
📝 总结
通过这篇文档，我们可以清晰地梳理出CATIA二次开发中的两个核心世界：
| 维度 | 实例/参考模型 (Instance/Reference) | 发生模型 (Occurrence) |
|---|---|---|
| 存储位置 | 数据库 (Vault/Store) | 内存 (Session) |
| 核心作用 | 数据持久化、版本管理、减少冗余 | 交互显示、图形操作、树状图展示 |
| 对象类型 | Reference, Instance, Connection, Port | Occurrence (路径), RepOccurrence |
| 轮子数量 | 2个 Instance (左/右) | 4个 Occurrence (前左、前右…) |
| 开发注意 | 修改零件定义、版本控制在此操作 | 遍历装配结构、修改颜色/图层在此操作 |
给开发者的建议： 当你在写代码遍历装配体时，一定要清楚你是在操作“实例”还是“发生”。如果你需要改变零件的几何形状，你需要找到参考（Reference）下的表示；如果你只是想把某个轮子在当前视图变红，你只需要操作对应的发生（Occurrence）。
希望这篇文章能帮你打通CATIA底层逻辑的“任督二脉”！如果你有更多关于V6开发的问题，欢迎在评论区留言。
评论