2. Teamcenter变更管理数据模型解析

在Teamcenter中，工程变更不是单一对象，而是一组围绕“变更意图—变更决策—变更执行”形成关联的数据对象集合。理解这套数据模型，是后续配置工作流、权限、版本规则和报表的基础。本节聚焦四个核心对象：Change Request（变更请求，常对应ECR）、Change Notice（变更通知，常对应ECO）、Change Activity（变更活动）以及它们与受控对象（Item、Item Revision、BOM、Dataset）之间的关联关系，并说明属性字段、版本与状态模型。

一、四个核心对象及其职责边界

Teamcenter的变更管理建立在“请求—分析—执行”的分层结构上。最上层是Change Request，它记录“为什么要改”：问题描述、变更原因、影响范围、优先级、提出人、目标完成日期。Change Request本身不直接修改产品数据，它是一份待评估的申请。

当变更请求经过评审并被批准后，会创建Change Notice。Change Notice记录“决定怎么改、由谁改、何时生效”：它绑定具体的受影响对象、执行人、生效日期、变更类型（如设计变更、工艺变更、文档变更）。Change Notice是真正驱动版本升级和状态迁移的执行载体。

在Change Notice之下，可以挂接一个或多个Change Activity。Change Activity把变更工作拆解到具体任务，例如“修改零件几何”“更新装配BOM”“修订作业指导书”。每个Change Activity可以独立分配责任人、计划日期和完成状态，从而支持并行执行和进度跟踪。

受控对象侧，Teamcenter使用Item作为对象主键，Item Revision承载具体版本数据，BOM View Revision描述结构关系，Dataset存放CAD模型、图纸、文档等文件。变更对象与这些受控对象之间通过关系（Relation）连接，而不是复制数据，从而保证“一处变更、全局可见”。

二、属性字段：变更对象的“身份证”

每个变更对象都有一组标准属性，它们决定了对象如何被检索、审批和追溯。以Change Request为例，关键属性包括：change_request_id（唯一编号，如ECR-2024-0157）、change_reason（变更原因，通常从受控词表中选择）、priority（优先级：紧急/高/中/低）、affected_items（受影响对象列表）、requestor（提出人）、target_date（目标完成日期）。

Change Notice的关键属性则包括：change_notice_id（如ECO-2024-0089）、effective_date（生效日期，决定版本切换时间点）、change_type（设计变更/工艺变更/文档变更）、implementation_owner（执行负责人）、affected_revisions（受影响的版本对象）。Change Activity则携带activity_name、assigned_user、planned_start、planned_end、actual_end等字段。

这些属性并非孤立存在。Teamcenter通过GRM（Generic Relationship Management）关系把变更对象与受控对象连接起来。例如，Change Notice与Item Revision之间建立“Problem Item”关系表示问题来源，建立“Impacted Item”关系表示受影响对象，建立“Revision Rule”关系表示版本升级规则。这种关系模型使得一个变更通知可以同时影响多个零件、多个BOM节点和多个文档，而无需逐一复制数据。

三、版本模型：A/B/C与变更的绑定逻辑

Teamcenter的版本模型采用“Item + Revision”两级结构。Item是逻辑对象，Revision是物理版本。初始版本为A，每次工程变更批准后，系统根据Change Notice中定义的版本规则生成新版本B、C、D……版本升级不是简单的数字递增，而是与变更通知严格绑定：只有Change Notice进入Released状态后，受控对象的版本才会正式切换。

这里有一个关键概念：版本规则（Revision Rule）。它决定了在特定场景下应该看到哪个版本。例如，“Latest Working”显示最新工作版，“Latest Released”显示最新已发布版，“Effective Date”显示在指定日期生效的版本。变更通知中的effective_date属性会直接影响版本规则的计算结果。假设某零件当前版本为B，Change Notice设定生效日期为2024-12-01，那么在2024-12-01之前，系统仍按B版本参与BOM计算；到达生效日期后，自动切换到C版本。

四、状态模型：从请求到发布的完整生命周期

变更对象的状态模型决定了“谁在什么阶段可以做什么”。Change Request的典型状态链为：Open → Submitted → Under Review → Approved / Rejected → Closed。在Open状态，提出人可以自由编辑；Submitted后进入评审队列，只有评审人可操作；Approved后触发Change Notice创建。

Change Notice的状态链为：Draft → Submitted → Under Review → Approved → Released → Closed。Draft阶段可以修改受影响对象和任务分解；Submitted后锁定关键属性；Released后版本正式生效，受控对象版本升级，同时触发通知和报表。Change Activity的状态相对简单：Not Started → In Work → Done → Cancelled，它主要驱动任务看板和进度汇总。

状态迁移通常由工作流（Workflow）驱动，而不是手动修改。工作流模板中定义了每个状态的进入条件、审批人、超时规则和自动动作。例如，Change Notice从Submitted进入Under Review时，系统自动向评审组发送任务；从Approved进入Released时，系统自动执行版本升级并更新BOM结构。

五、对象关联关系：一张网而非一条线

把上述对象放在一起看，Teamcenter变更管理的数据模型是一张有向关系网：Change Request通过“Request to Notice”关系派生Change Notice；Change Notice通过“Notice to Activity”关系分解Change Activity；Change Notice同时通过“Problem Item”“Impacted Item”“Revision Rule”关系连接Item、Item Revision、BOM和Dataset。受控对象之间又通过“Item to Revision”“BOM to Component”等关系互相连接。

这种网状结构带来两个实际好处。第一，追溯性：从任意一个零件版本出发，可以反向找到驱动它变更的Change Notice、Change Request和Change Activity，形成完整审计链。第二，影响分析：在Change Request阶段，系统可以沿关系网展开，自动列出所有可能受影响的装配、文档和下游对象，帮助评审人判断变更范围。

理解这套数据模型后，后续配置工作流、权限规则、版本策略和变更报表时，就能清楚知道每个操作作用在哪个对象、哪个属性、哪个关系上，而不是停留在“点按钮”的层面。