2. Windchill变更管理核心对象模型

在Windchill的变更管理体系中，真正决定系统行为是否可控的，不是界面上的按钮，而是后台的对象模型。变更请求（Change Request，ECR）、变更通告（Change Notice，ECN/ECO）、变更任务（Change Task）、变更活动（Change Activity）、受影响对象（Affected Object）与相关对象（Related Object）共同构成了一条从“问题提出”到“变更落地”的数据链。理解它们各自的职责、字段和引用关系，是后续配置工作流、权限和报表的基础。

一、六个核心对象的职责边界

变更请求（ECR）是变更流程的起点，用于记录“为什么要变”。它通常包含问题描述、变更原因、优先级、提出人、提出日期、初步影响范围等字段。ECR本身不直接修改产品数据，它的价值在于把需求、缺陷或改进意见结构化，并作为后续评审和追溯的依据。

变更通告（ECN/ECO）是变更的执行载体，回答“具体怎么变、由谁执行、何时生效”。ECN通过“变更任务”和“变更活动”组织执行细节，并最终驱动受影响对象产生新版本。ECN与ECR之间通常存在“由请求生成”的引用关系，但并非强制一对一：一个ECR可以拆分为多个ECN，多个ECR也可以合并为一个ECN。

变更任务（Change Task）是ECN下的执行单元，通常对应一个责任人或一个专业领域，例如“结构修改”“电气修改”“文档更新”。任务本身不直接改数据，而是把工作分派下去，并汇总完成状态。

变更活动（Change Activity）是任务下的最小操作单元，直接关联到具体对象和具体动作，例如“检出A零件”“修改B图纸”“发布C文档”。变更活动是真正触发版本迭代和状态迁移的地方。

受影响对象（Affected Object）是变更直接作用的产品数据，如零件、CAD文档、BOM、工艺文件。它们会因变更活动而产生新版本或新状态。

相关对象（Related Object）是与变更有关但不直接修改的数据，例如参考图纸、测试报告、供应商信息、关联的ECR或ECN。相关对象用于补充上下文，不参与版本迭代。

二、对象之间的数据关系

从数据模型看，ECR与ECN之间是“请求—执行”的引用关系；ECN与变更任务是“一对多”的包含关系；变更任务与变更活动也是“一对多”；变更活动与受影响对象之间通过“变更对象引用”建立关联，并携带“操作类型”字段，如修订、废止、新增。受影响对象与相关对象则通过“关联关系”挂接到ECN或变更活动上，但只有受影响对象会进入版本迭代路径。

需要特别注意的是，Windchill中“受影响对象”和“相关对象”并不是简单的标签，而是通过不同的关联类型（Association Type）和角色（Role）来区分的。例如，一个零件既可能是受影响对象，也可能同时作为相关对象出现在另一个ECN中，系统通过关联类型和上下文来区分其行为。

三、关键字段与配置要点

在Windchill中创建这些对象时，有几个字段直接影响后续流程走向。ECR的“变更类型”字段决定走哪条审批路径；“优先级”影响任务分派顺序。ECN的“生效日期”和“变更范围”决定受影响对象的版本切换时机。变更任务的“责任人”和“完成期限”用于工作流分派。变更活动的“操作类型”字段（如Revise、Obsolete、Add）直接决定受影响对象是产生新版本、被废止还是新增关联。

受影响对象与相关对象的区分，在配置时通常通过“关联类型”来实现。例如，在ECN的“受影响对象”表格中，系统默认关联类型为“Affected”，而在“相关对象”表格中为“Related”。如果配置错误，可能导致对象被错误地纳入版本迭代，或者该改的没改。建议在类型管理器中明确两类关联的显示名称和可用操作，避免用户混淆。

四、一个可参考的配置示例

假设某企业要变更一个电机组件的端盖材料，从铝合金改为不锈钢。实际数据组织如下：

这个示例中，端盖零件和装配图纸是受影响对象，会因变更活动产生新版本；材料测试报告和供应商信息是相关对象，只提供上下文，不参与版本迭代。通过这种区分，系统可以准确控制哪些数据需要走修订流程，哪些只需挂接查看。

理解这六个对象的数据模型与关系，本质上是在理解Windchill变更管理的“骨架”。ECR负责提出，ECN负责组织，变更任务负责分派，变更活动负责执行，受影响对象负责承载版本变化，相关对象负责补充上下文。它们之间的引用、包含和执行关系，决定了变更流程能否被正确追踪、审批和落地。