师夷长技以制夷—BOM 引擎之谜 — 什么是精确、非精确与绝对坐标？

Teamcenter学习平台正式上线(https://www.plmvision.top)，安装配置实施开发源码仓库，全套学习教材！关注公众号发送“二维码“咨询加入！

如果说 Item 和 Dataset 是 PLM 的皮肉，那么 BOM（物料清单）就是 PLM 的心脏。

很多初入行的开发者或产品经理，容易把 BOM 简单理解为一张“Excel 表格”，里面列着父件和子件。如果你是这么想的，恭喜你，你开发的充其量只能叫“带有树状结构的网盘”。

Teamcenter 之所以能卖出千万天价，很大程度上归功于它那个恐怖的 BOM 引擎（Structure Manager）。今天，我们来拆解这个引擎内部最迷人、也最晦涩的三个概念：Occurrence（实例）、BOM View（视图）与 Precise/Imprecise（精确/非精确）。

一、 PSOccurrence：它不是简单的“父子表”

在普通的数据库设计中，我们要建立父子关系，通常会做一个 Relation 表：Parent_ID, Child_ID, Quantity。

但在 TC 中，连接父子对象的不是一条简单的线，而是一个实体对象 —— PSOccurrence（Product Structure Occurrence，产品结构实例）。

为什么需要这个中间层？

因为“关系”本身是带有上下文（Context）的。同一个螺栓（Item），装在发动机上是“子件A”，装在底盘上是“子件B”。PSOccurrence 记录了这次“装配行为”的所有属性：

1. Quantity (数量)：不仅是整数，还支持小数（如胶水、油漆）。

2. Notes (注释)：比如“安装时需涂抹润滑油”。这些信息只属于这次装配，不属于螺栓本身。

3. Variant Condition (配置条件)：这是 BOM 变型管理的核心。

• TC 的 BOM 是“超级 BOM”（150% BOM）。所有可能的配置都在一棵树上。

• PSOccurrence 上挂载了逻辑表达式，例如 IF (Engine == V8 AND Market == US)。只有当配置器满足这些条件时，这条 BOM 行才会“显形”，否则它就像幽灵一样不可见。

结论： PSOccurrence 是 BOM 结构中的“关节”，它决定了子件在什么条件下、以什么形态存在于父件中。

二、 Transform Matrix：数字样机的空间魔法

你是否好奇过：为什么 TC 不需要打开庞大的 CAD 软件，就能在浏览器里进行 3D 可视化（DMU）？

秘密在于 PSOccurrence 中存储的 Transform Matrix（变换矩阵）。

4×4 矩阵的奥义

当你在 CAD 软件里把一个车轮装配到汽车上时，你其实是在定义一个空间位置。TC 将这个位置抽象为一个 4×4 的数学矩阵，存储在 BOM 行属性中。
它包含了三组信息：

1. Translation (平移)：X, Y, Z 坐标。

2. Rotation (旋转)：绕轴旋转的角度。

3. Scaling (缩放)：零部件的大小比例（虽然工业上极少用缩放）。

相对坐标 vs. 绝对坐标

TC 的高明之处在于它存储的是 Relative Transformation（相对变换）。

• 它只记录“车轮”相对于“车桥”的位置。

• 它不记录“车轮”相对于“地球原点”的位置。

这带来的巨大优势是：
当你移动整辆车（父件）时，你不需要更新成千上万个零件（子件）的坐标。BOM 引擎会在加载时，通过矩阵乘法，实时计算出每个零件的绝对坐标。

三、 BOM View 的多维世界：EBOM、MBOM 与 SBOM

初学者常问：“EBOM（设计）和 MBOM（制造）是两个数据库吗？”
在 TC 里，Item 库只有一个，但“眼镜”有很多副。

这就是 BOM View Revision (BVR) 的概念。
一个 Item（比如发动机总成），可以同时挂载多个 BVR：

• Design BVR (EBOM)：结构按“功能”划分。关注的是设计意图。

• Manufacturing BVR (MBOM)：结构按“装配工艺”划分。关注的是生产顺序，可能会添加虚拟件、工艺合件。

• Service BVR (SBOM)：结构按“备件包”划分。关注的是维修便利性。

共享机制：
它们引用的底层的 Item (零部件) 是同一个！
如果你修改了螺栓 Item 的材质属性，EBOM、MBOM 和 SBOM 里的螺栓属性都会同时变。但如果你在 EBOM 里删除了螺栓，MBOM 里可能还在，因为它们是两棵不同的“树结构”，共享着相同的“果实”。

四、 精确（Precise）与非精确（Imprecise）：TC 的时间机器

这是 TC 架构中最天才、也是最难理解的部分。

1. 什么是非精确（Imprecise）？—— “只要最新的”

• 定义：PSOccurrence 指向的是 Item（对象本身），而不是具体的 ItemRevision。

• 逻辑：系统加载 BOM 时，会动态去抓取该 Item 的最新版本（或符合规则的版本）。

• 场景：WIP（在研）阶段。

• 小王设计发动机，小李设计底盘。小王把底盘挂进总装 BOM。小李每天都在改底盘（出 A 版、B 版、C 版）。

• 因为是非精确引用，小王每天打开总装图，看到的都是小李最新的底盘。数据是活的。

2. 什么是精确（Precise）？—— “冻结历史”

• 定义：PSOccurrence 强行指向具体的 ItemRevision（例如 Part-001/A）。

• 逻辑：无论 Part-001 后来升级到了 Z 版，这条 BOM 行永远指向 A 版。

• 场景：Release（归档/发布）阶段。

• 设计定型了，要发给工厂生产。必须把 BOM 里的每一个零件都“钉死”。

• 这时的 BOM 是一张历史快照。如果不这样，工厂生产到一半，系统自动变成了新版图纸，会导致严重的实物不符。

3. Revision Rule（版本规则）：时光穿梭机

TC 是如何决定加载哪个版本的？靠的是 Revision Rule。
这是一套过滤器逻辑，例如：

• 规则 A (Working)：优先找“正在工作”的版本，没有则找“最新发布”的。 -> 非精确加载

• 规则 B (Released)：只找“已发布”的版本，忽略正在修改的。

• 规则 C (As Saved)：找当初保存时锁定的那个版本。 -> 精确加载

偷师要点：如何构建高级 BOM 引擎

如果你想写代码实现这些逻辑，或者构建自己的 PLM 内核，请记住以下实操要点：

1. 区分“结构”与“内容”：

• 不要把 BOM 关系直接写在 Part 表里。

• 必须建立独立的 Occurrence 表。

• 在代码层面（API），BOM 的展开（Expand）操作必须接受一个“规则参数”。

• 在 UI 上，允许用户“锁定”某一行（转化为 Precise），或“解锁”某一行（转化为 Imprecise）。这是工程师最常用的功能。

总结：
一个合格的工业软件 BOM 引擎，必须具备时空穿梭的能力：

• 空间上：通过变换矩阵，构建数字样机。

• 时间上：通过精确/非精确与版本规则，在“最新设计”与“历史归档”之间自由切换。

没有这两样东西，所有的 BOM 管理都只是在 Excel 里玩文字游戏。