1. 课程导入与数字主线认知
在制造业数字化转型的语境中，“数字主线”（Digital Thread）并不是一个抽象口号，而是一条贯穿产品概念、设计、工艺、制造、交付、运维直至退役的数据与决策链路。它把分散在 CAD、PLM、ERP、MES、QMS、IoT 等系统中的产品定义、构型、工艺、质量、服务数据，按产品对象和版本关系串联起来，使每个关键决策都能追溯到“当时依据的是哪一版数据、由谁产生、被谁消费”。
理解数字主线，可以先区分两个常被混用的概念：数字孪生侧重对物理实体的实时映射与仿真，数字主线侧重跨阶段、跨系统的数据连续性与可追溯性。前者回答“现在状态如何”，后者回答“这个状态从何而来、依据什么变更、会影响哪些下游”。二者互补：没有主线的孪生容易成为孤立的可视化看板，没有孪生的主线则难以闭环验证。
本节核心判断：数字主线的价值不在于“把所有数据放进一个库”，而在于建立可追溯的产品数据关系——需求→设计→工艺→制造→质量→服务，每一环都能回答“依据哪一版、影响哪些对象”。
Teamcenter 在数字主线中承担的是产品数据主干与协同中枢的角色。它管理产品结构（BOM）、版本与构型、变更流程、文档与三维模型、工艺规划以及与 ERP/MES 的接口数据。可以把它理解为“产品数据的权威源”（Authoritative Source），其他系统围绕它进行消费与回写。例如，设计端在 Teamcenter 中发布某一版本的 EBOM，工艺端基于该版本派生 MBOM，制造端再依据 MBOM 与工艺路线生成工单；当设计发生变更时，变更影响分析能够沿这条链路向下游传播，而不是靠邮件和表格人工通知。
跨系统数据协同的挑战，通常集中在四个方面：标识不一致（同一零件在不同系统中编码不同）、版本不同步（ERP 用的是旧版 BOM）、语义差异（“物料”在 PLM 与 ERP 中字段含义不同）、变更传播断裂（设计变更未触发工艺与制造更新）。这些问题在单系统内不明显，一旦跨系统就集中暴露。因此，协同的目标不是“系统之间多连几条接口”，而是建立统一的数据模型、明确的权威源、可追踪的变更链路。
上图展示了数字主线的整体结构：上层是产品生命周期各阶段，中间是 Teamcenter 作为产品数据主干，下层是 CAD/CAE、ERP、MES、QMS/IoT 等系统。主干向下游分发受控数据，下游将实际制造、质量与运维数据回写，形成闭环。底部则归纳了本节要建立的两个基本认知——协同挑战与协同目标。
为了把认知落到可操作层面，本课程后续将围绕一个贯穿式实战项目展开：某型号工业减速机的数字主线协同。示例设定如下（属于教学假设，非实测数据）：产品包含 3 级传动、约 120 个零件；设计端在 Teamcenter 中维护 EBOM 与三维模型；工艺端派生 MBOM 与装配工艺路线；ERP 接收物料与 BOM 用于采购和成本核算；MES 依据工单执行装配并回传批次与扭矩数据；QMS 记录关键尺寸检测结果。课程将逐步演示如何用统一编码规则、版本状态控制和变更影响分析，把这条链路真正打通。
学习建议：在进入后续章节前，先建立三个判断习惯——看到任何数据先问“权威源在哪”、看到任何变更先问“影响哪些下游”、看到任何接口先问“传的是标识还是语义”。这三个问题会贯穿整门课程。
整体课程框架分为四个层次：认知层（数字主线定位、Teamcenter 价值、协同挑战）、建模层（产品结构、BOM 转换、版本与构型）、协同层（跨系统接口、变更传播、数据映射）、实战层（减速机项目端到端演练与排障）。本节作为导入，目标是让读者先看清“主线长什么样、断点通常在哪里、Teamcenter 站在什么位置”，为后续的具体配置与操作建立判断框架。
需要强调的是，数字主线不是一次性建成的系统，而是随着产品数据治理成熟度逐步演进的。初期可能只打通 EBOM 到 ERP 的物料同步，中期加入 MBOM 与工艺路线，后期再接入质量与运维数据。每一阶段的推进，都应以“是否解决了具体的追溯或协同问题”为判断标准，而不是以接口数量或系统覆盖度为目标。