4. 数据创建与版本管理
在Teamcenter中，零件数据不是以“一个文件”的形式被管理的，而是以Item（物料/对象主记录）和ItemRevision（版本记录）两级结构承载。理解这两级结构，是完成零件数据全生命周期操作的前提。Item代表这个零件的“身份”，它回答“这是什么”；ItemRevision代表这个零件在某一阶段的“具体形态”，它回答“这个阶段它长什么样”。一个Item下可以挂多个ItemRevision，每个Revision又可以挂多个数据集（如三维模型、二维图纸、PDF、JT轻量化文件等）。
新建Item时，系统会要求填写若干关键属性：Item ID（物料编码，通常由编码规则自动生成或手工指定）、名称、类型（如Part、Assembly、Document）、版本（Revision的初始值，常见为A或01）、单位、所属产品/项目等。以某减速器项目为例，假设新建一个“输出轴”零件，Item ID为GJ-2024-0017，名称为“输出轴”，类型为Part，初始版本为A。保存后，系统自动生成Item与ItemRevision A，此时Revision A处于“工作中”状态，可以挂载数据集。
版本与版次规则是Teamcenter版本管理的核心。通常用Revision表示大版本（如A、B、C），用Version或迭代表示同一Revision内的小版本（如A.1、A.2）。大版本用于表达设计冻结、发布、重大变更；小版本用于表达同一设计阶段内的反复修改。例如，输出轴在概念设计阶段可能经历A.1、A.2、A.3三次迭代，当设计评审通过后，将A冻结并发布，后续若发生结构变更，则新建Revision B。这样，B与A之间形成清晰的修订关系，历史数据不会被覆盖。
检入/检出机制解决的是“多人同时修改同一数据”的冲突问题。当工程师需要修改某个ItemRevision时，必须先执行检出（Check-out），此时该Revision被锁定，其他用户只能查看不能修改。检出后，数据在本地或工作区形成可编辑副本，修改完成后执行检入（Check-in），系统生成一个新的小版本（如A.1→A.2），并释放锁。如果修改过程中需要放弃，可以执行撤销检出（Undo Check-out），回到检出前的状态。检入/检出不仅保护数据一致性，也保留了“谁在什么时候改了什么”的审计线索。
修订与状态控制则决定了数据在生命周期中的“可编辑性”和“可见性”。Teamcenter中常见的状态包括：工作中（Working）、评审中（Review）、已发布（Released）、已冻结（Frozen）、已废弃（Obsolete）。状态之间通过工作流或手动操作迁移。例如，Revision A在完成设计后提交评审，状态变为“评审中”；评审通过后发布，状态变为“已发布”，此时该Revision通常被锁定，不允许直接修改；若需要修改，必须新建Revision B，B从“工作中”开始，A保持“已发布”作为历史基线。这种“发布即冻结、变更即修订”的机制，保证了产品数据的可追溯性。
下面以“输出轴”为例，走一遍完整的生命周期操作。第一步，新建Item与Revision A。在Teamcenter中执行“新建→Item”，填写Item ID、名称、类型，系统自动创建Revision A，状态为“工作中”。第二步，挂载数据集。将三维模型、二维图纸、PDF挂到Revision A下，此时可以反复检出/检入，形成A.1、A.2、A.3等小版本。第三步，提交评审。将Revision A提交到评审工作流，状态变为“评审中”。第四步，发布。评审通过后，Revision A状态变为“已发布”，系统锁定该Revision，A.3成为正式基线。第五步，修订。若后续需要修改，执行“修订”操作，系统基于A创建Revision B，B的状态为“工作中”，版本从B.1开始。第六步，重复检出/检入/评审/发布，直到B发布。第七步，若B发布后再次发生重大变更，则创建Revision C，依此类推。
在这个过程中，有几个关键判断点需要特别注意。第一，什么时候用新Revision，什么时候用新Version：如果修改不影响互换性、不影响接口、不改变技术状态，通常用新Version；如果修改影响互换性、需要重新评审、需要重新发布，则必须用新Revision。第二，已发布Revision能否直接修改：不能。已发布Revision处于冻结状态，任何修改都必须通过新建Revision实现，这是保证历史可追溯的基本规则。第三，检出后忘记检入怎么办：其他用户无法修改该Revision，但可以查看；管理员可以强制撤销检出，但会丢失未检入的修改，因此检出后应尽快完成修改并检入。第四，状态与权限的关系：不同状态下，用户的编辑权限不同。例如，“工作中”状态允许设计者编辑，“已发布”状态只允许只读，“已废弃”状态通常不可见或仅管理员可见。
为了便于实际操作时对照检查，下面给出一份“零件数据生命周期操作检查表”，可直接用于日常设计工作。
| 阶段 | 操作 | 关键输入/参数 | 预期结果 | 判断依据 |
|---|---|---|---|---|
| 新建 | 新建Item与Revision | Item ID、名称、类型、初始版本 | 生成Item及Revision A，状态“工作中” | Item ID唯一，Revision可挂数据集 |
| 迭代 | 检出→修改→检入 | 工作副本、修改内容 | 生成A.1、A.2等小版本 | 版本号递增，锁释放 |
| 评审 | 提交评审工作流 | 评审人、评审意见 | 状态变为“评审中” | 评审任务生成，可查看进度 |
| 发布 | 评审通过后发布 | 发布确认 | 状态变为“已发布”，Revision冻结 | Revision只读，成为基线 |
| 修订 | 基于已发布Revision新建Revision | 修订原因、新Revision标识 | 生成Revision B，状态“工作中” | B与A形成修订关系，A保持冻结 |
| 废弃 | 将不再使用的Revision置为废弃 | 废弃原因 | 状态变为“已废弃” | 该Revision不再参与新设计引用 |
最后需要强调，版本管理不是“多存几个文件”那么简单，它是一套受控的、可追溯的、与状态和权限绑定的数据治理机制。Item与ItemRevision的两级结构、Revision与Version的分工、检入/检出的并发控制、修订与状态的联动，共同构成了Teamcenter产品数据管理的骨架。只有把这几件事串起来理解，才能在实际项目中做到“改得清楚、查得明白、追得回去”。