4. 变型配置核心对象

在Teamcenter中建立变型配置模型，本质上不是“画一棵选项树”，而是围绕五个核心对象建立一套可被系统解释、可被规则约束、可被BOM过滤的语义网络。这五个对象分别是：变型选项（Variant Option）、变型值（Variant Value）、变型条件（Variant Condition）、配置规则（Configuration Rule）和约束规则（Constraint Rule）。理解它们的定义、属性以及彼此之间的引用关系，是后续做150% BOM、配置基线、超级BOM和订单配置的前提。

一、五个核心对象的定义与属性

变型选项是描述产品可变特征的一个维度，例如“发动机排量”“驱动形式”“座椅布局”“涂装颜色”。在Teamcenter中，变型选项通常以Variant Option对象存在，关键属性包括：选项ID（Option ID）、名称、描述、所属选项组（Option Group）、数据类型（枚举/布尔/数值/文本）、是否必选、默认值、排序号。选项ID是后续规则引用的唯一键，命名应遵循“领域_特征”的稳定约定，例如ENG_DISPLACEMENT、DRIVE_TYPE，避免使用中文或空格，以免在规则表达式中出现转义问题。

变型值是某个变型选项下的具体取值，例如ENG_DISPLACEMENT下的1.5T、2.0T、3.0T。变型值的关键属性包括：值ID、显示名称、所属选项、排序、是否默认、是否有效、生效日期范围。一个常见误区是把“值”直接写成自由文本，导致后续无法做枚举校验和规则匹配。正确做法是每个值都作为独立对象挂在该选项下，并保证值ID在选项内唯一。

变型条件是“某个配置选择成立”的布尔表达式，例如DRIVE_TYPE = AWD AND ENG_DISPLACEMENT = 2.0T。它本身不是规则，而是规则中被引用的判断片段。变型条件可以保存为可复用的Condition对象，属性包括条件ID、表达式文本、引用选项列表、描述。把条件对象化，可以避免在几十条规则里重复写同一段表达式，也便于后续统一修改。

配置规则回答“当用户选了某些值，系统应该包含或排除哪些对象”。它通常绑定到BOM行、结构件或配置特征上，属性包括：规则ID、适用对象（BOM Line/Item Revision）、条件表达式、动作（Include/Exclude/可选）、优先级、生效范围。配置规则是“选择驱动结构”的执行者。

约束规则回答“哪些选择组合不允许出现，或哪些选择会强制另一个选择”。典型形式包括：互斥（A与B不能同时选）、依赖（选A必须选B）、推荐（选A建议选B）、默认（未选时自动取某值）。约束规则属性包括：规则ID、规则类型、左条件、右条件、严重级别（错误/警告/提示）、提示信息。约束规则在配置会话中做前置校验，避免生成无效配置。

二、对象之间的引用关系

这五个对象不是并列的，而是有明确的引用方向。变型选项与变型值构成“取值域”，是配置的输入空间；变型条件引用取值域中的具体值，形成布尔判断；配置规则消费变型条件，决定BOM行是否进入某个具体配置；约束规则则对取值组合本身做前置校验，它不直接过滤BOM，而是在用户选择阶段就阻止非法组合。理解这条链路，可以避免把约束规则误当成配置规则使用——前者管“能不能选”，后者管“选了之后BOM里有什么”。

三、在Teamcenter中建立变型配置模型的方法

建立模型建议按“先定义取值域、再定义条件、再写规则、最后做校验”的顺序推进，具体操作如下。

第一步：创建变型选项与变型值。在Teamcenter中通过“变型配置”应用或BMIDE定义Option和Value对象。以某中型SUV为例，建立三个选项：ENG_DISPLACEMENT（枚举：1.5T、2.0T、3.0T）、DRIVE_TYPE（枚举：FWD、AWD）、SEAT_LAYOUT（枚举：5座、7座）。每个值设置默认与排序，例如ENG_DISPLACEMENT默认2.0T，DRIVE_TYPE默认FWD。

第二步：定义可复用的变型条件。把高频判断抽成Condition对象，例如：

COND_AWD_2T   = (DRIVE_TYPE = AWD) AND (ENG_DISPLACEMENT = 2.0T)
COND_7SEAT    = (SEAT_LAYOUT = 7座)
COND_3T_AWD   = (ENG_DISPLACEMENT = 3.0T) AND (DRIVE_TYPE = AWD)

条件表达式中的选项ID必须与第一步创建的Option ID完全一致，大小写敏感。建议在条件对象上记录“引用选项列表”，便于后续做影响分析：当某个选项值被废弃时，能快速定位哪些条件需要修改。

第三步：编写配置规则并绑定到BOM行。配置规则的核心是“条件+动作+目标”。例如，四驱传动轴总成只应在AWD配置中出现，则在该BOM行上绑定规则：条件DRIVE_TYPE = AWD，动作Include；否则Exclude。再如，7座车型的第三排座椅总成绑定条件COND_7SEAT，动作Include。规则优先级用于处理重叠：当多条规则同时命中同一BOM行时，优先级高的先执行，建议把“排除类”规则优先级设得高于“包含类”，避免误包含。

第四步：编写约束规则做前置校验。约束规则不绑定BOM行，而是绑定到选项或选项组。典型配置如下：

• 互斥：ENG_DISPLACEMENT = 1.5T 与 DRIVE_TYPE = AWD 不能同时选，严重级别为“错误”，提示“1.5T不支持四驱”。
• 依赖：选SEAT_LAYOUT = 7座必须选ENG_DISPLACEMENT = 2.0T或3.0T，严重级别为“错误”。
• 推荐：选DRIVE_TYPE = AWD建议同时选ENG_DISPLACEMENT = 2.0T，严重级别为“警告”，允许用户忽略。
• 默认：未指定DRIVE_TYPE时自动取FWD，严重级别为“提示”。

第五步：验证模型。在配置会话中依次选择2.0T + AWD + 7座，观察系统是否：不报互斥错误、自动包含四驱传动轴与第三排座椅、过滤掉1.5T专属零件。再故意选择1.5T + AWD，确认系统在保存前就抛出“1.5T不支持四驱”的错误，而不是等到BOM展开后才暴露问题。验证通过后，该配置模型即可作为150% BOM的过滤依据，用于生成具体订单配置或配置基线。

掌握这五个对象的定义、属性与引用关系，并在Teamcenter中按“取值域→条件→配置规则→约束规则→验证”的顺序落地，就完成了变型配置模型的基础搭建。后续的150% BOM组织、配置基线管理和订单配置，都建立在这套对象模型之上。