Teamcenter学习平台正式上线(https://www.plmvision.top)，安装配置实施开发源码仓库，全套学习教材！关注公众号发送“二维码“咨询加入！
在复杂产品的 BOM 管理中，BOM 树不再是静态的清单，而是一个包含逻辑判断的“方程组”（150% BOM）。
Product Configurator (PC) 是 Teamcenter 中专门负责解这个方程的独立模块。它的核心任务非常明确：定义变量（Features）、定义规则（Constraints），并在运行时通过求解器（Solver）计算出唯一的结果。
本篇将解剖 PC 是如何在底层通过 对象化管理 和 实时推理 来处理复杂配置的。
一、 数据模型：配置项的对象化 (Object-Based)
在 PC 的架构中，所有的配置选项不再是简单的文本字符串，而是独立的 Workspace Object。
1. 变型字典 (Variability)
PC 将配置定义存储在一个专门的区域（Namespace）。
Option Family (族)：相当于变量名。例如 Color, Engine_Type。
Option Value (值)：相当于变量的具体取值。例如 Red, V8。
硬核细节：
每一个 Option Value 在数据库中都有唯一的 PUID。
这意味着，当你在 BOM 行上写条件 Color = Red 时，底层并不是存储 “Color” 和 “Red” 这两个单词，而是存储了指向这两个对象的 指针 (Reference)。
优势：即使你把 “Red” 改名为 “Scarlet”，所有引用该选项的几万行 BOM 和规则都不需要修改，因为 PUID 没变。
2. 也是对象的约束 (Constraint Rules)
规则本身也是对象。PC 支持多种规则类型：
Inclusion Rule (包含)：IF A THEN B。
Exclusion Rule (互斥)：IF A THEN NOT B。
Availability Rule (有效性)：控制选项在特定时间或特定项目中是否可见。
二、 核心算法：Solver (求解器) 与前向推理
当用户在界面上进行选配时，TC 并不是在做简单的 SQL 查询，而是在运行一个内存中的 逻辑推理机 (Inference Engine)。
1. 求解器的介入时机
当你加载一个带有 PC 数据的 BOM 时，系统会初始化一个 Solver Session。这个 Session 会加载相关的 Option 和 Constraint Model 进入内存。
2. 前向推理 (Forward Chaining)
PC 的求解器具备“连锁反应”的能力。
场景：规则定义了 Engine=V8 必须搭配 Transmission=Auto。
检测到 V8 状态变为 True。
扫描所有关联约束，命中包含规则。
自动推导：将 Transmission=Auto 的状态强制设为 True，并将其 UI 状态锁定（System Set）。
3. SAT (Satisfiability) 问题
对于极其复杂的配置（例如卡车配置，可能有上万条规则），PC 实际上是在解决数学上的 SAT 问题 (布尔可满足性问题)。
它需要计算：是否存在一种组合，使得所有的规则都返回 True？
如果在配置过程中，用户试图选择一个会导致逻辑死锁（Conflict）的选项，Solver 会在毫秒级内返回 False，并拦截该操作，提示“违反约束”。
三、 变型条件在数据库的存储
我们在 BOM 行（Line Item）上看到的“配置条件”，在底层是如何存储的？
1. Variant Expression (变型表达式)
当你在 BOM Line 上设置 Usage Condition 时，TC 生成一个 Variant Expression。
这个表达式经过编译，以二进制大对象（BLOB）的形式存储。
存储结构猜想（BDD – 二元决策图）：
为了极致的计算性能，复杂的布尔逻辑（如 (A or B) and (C != D)）通常会被编译成 BDD (Binary Decision Diagrams) 结构。
为什么不用文本？ 解析文本太慢。
为什么用 BDD？ BDD 将逻辑运算转化为图的遍历。判断一行 BOM 是否显示，只需要在这个图上跑一遍路径，速度极快。
2. 150% BOM 的展开逻辑
当用户设定好一组配置（Configurator Context）并刷新 BOM 时：
Input：用户选择的 Option Value List（实际上是 PUID List）。
Process：
Output：
Result = True -> 保留该行。
Result = False -> 隐藏该行。
四、 偷师要点：如何设计高效的配置系统？
如果你在做即使是非 TC 的系统开发，PC 的设计思路也非常值得借鉴：
1. 逻辑与结构分离
不要把业务规则（如“V8引擎必须配自动挡”）硬编码在 BOM 结构里，也不要写死在代码里。
PC 的做法是建立独立的 Constraint Model。这使得规则可以独立维护、版本化，并且可以被不同的 BOM 结构复用。
2. 使用 GUID 引用而非字符串
在涉及核心业务逻辑关联时，永远不要信任字符串。PC 通过对象化管理（Option Objects），确保了配置数据的引用完整性。
3. 上下文 (Context) 传递
PC 引入了 Product Model 的概念作为上下文容器。
在 API 开发中，不要依赖全局变量。应该构建一个 Context 对象，包含当前所有的 User Selections，并在系统的各个模块（BOM解析、渲染、成本计算）之间显式传递这个 Context。
总结
Teamcenter 的 Product Configurator 本质上是一个图形化的逻辑编程环境。它将复杂的业务需求抽象为数学约束，并利用高性能的 Solver 在内存中实时计算出 BOM 的形态。
