2. 数字线程的数据模型与信息流
数字线程要真正“串起来”，靠的不是把文件从一个系统搬到另一个系统，而是让数据在模型、血缘、配置和版本四条主线上保持可追溯、可解释、可复现。本节围绕这四条主线，说明产品全生命周期数据模型如何组织，数据血缘如何记录，配置与版本如何约束变更，以及跨阶段信息流如何传递。
一、产品全生命周期数据模型：把“对象”和“关系”分开建
全生命周期数据模型的核心不是一张大宽表，而是“对象 + 关系”的图结构。对象是产品、部件、文档、需求、试验、工单、软件版本等实体；关系是“由…组成”“满足…需求”“验证…指标”“替代…物料”“产生…变更”等语义连接。对象负责承载属性，关系负责承载语义，二者分离后，同一份数据才能在不同阶段被不同角色以不同视角复用。
以某型电驱动总成为例，可建立如下最小对象集：产品（Product）、总成（Assembly）、零件（Part）、需求（Requirement）、三维模型（CADModel）、仿真工况（SimCase）、试验记录（TestRecord）、工艺路线（ProcessPlan）、软件版本（SWRelease）。每个对象至少包含三类属性：标识属性（全局唯一ID、名称、类型）、业务属性（材料、质量、功率、公差）、管理属性（状态、版本、责任人、生效日期）。全局唯一ID是跨系统关联的锚点，建议采用“域前缀+业务码+序号”的形式，例如 PDM-PART-000123，避免各系统各自编号导致对不上。
关系建模时，建议显式区分“结构关系”和“追溯关系”。结构关系描述产品怎么组成，如 Assembly --contains--> Part；追溯关系描述为什么这样设计、怎么验证，如 Requirement --satisfiedBy--> CADModel、TestRecord --verifies--> Requirement。结构关系随BOM变化，追溯关系随需求与验证变化，两者分开存储，查询时再按需组合，能显著降低模型耦合。
二、数据血缘：记录“数据从哪来、经过谁、变成什么”
数据血缘回答三个问题：这条数据的上游是谁、中间经过了哪些处理、下游被谁消费。在数字线程中，血缘不是数据库内部的血缘，而是跨阶段、跨工具的业务血缘。典型血缘链为：需求条目 → 设计参数 → 仿真输入 → 仿真结果 → 试验实测 → 设计变更。每一跳都要记录来源对象ID、处理动作、时间戳、执行人和工具版本。
实现上，血缘可以用“节点—边”表存储：节点表记录对象ID与类型，边表记录 from_id、to_id、relation_type、created_at、tool。当设计参数从 320 N·m 调整为 350 N·m 时，系统应能沿血缘边反向查出受影响的需求、仿真工况和试验记录，正向查出需要重跑的仿真与需要更新的工艺文件。这就是变更影响分析的基础。
三、配置管理与版本控制：让“同一时刻的数据”可复现
配置管理解决的是“哪些版本组合在一起构成一个有效产品状态”。版本控制解决的是“单个对象如何随时间演进”。两者配合，才能回答“2024年5月17日交付的那台总成，用的是哪版图纸、哪版软件、哪版工艺”。
版本控制建议采用“对象ID不变、版本号递增”的策略：CAD-0211 是对象ID，v1/v2/v3 是版本，每次修改生成新版本并保留旧版本，禁止原地覆盖。版本状态可设为“工作中、已发布、已冻结、已废弃”，只有“已发布”版本才能被下游引用。配置管理则通过“配置基线”把一组已发布版本固定下来，例如基线 BL-2024-05-17 包含 CAD-0211 v3、SW-1.3.2、PROC-0088 v2。基线一旦冻结，任何变更都必须走变更流程并生成新基线，旧基线永久可查。
实际落地时，一个常见做法是给每个对象维护“版本头 + 版本明细”两张表。版本头记录对象ID、当前版本、状态；版本明细记录每个版本的属性快照、生效时间、变更单号。下游系统引用时只引用“对象ID + 版本号”或“基线ID”，不引用“最新版”，避免上游一改、下游全部被动漂移。
四、跨阶段信息流传递机制：用事件和契约驱动
跨阶段传递最容易出问题的地方是“隐式依赖”：设计改了，工艺不知道；工艺改了，采购不知道。解决办法是把传递显式化，采用“事件 + 契约”的方式。事件表示“发生了什么”，如 DesignReleased、ProcessChanged、TestCompleted；契约表示“下游需要什么字段、什么格式、什么版本”。
以设计发布到工艺为例，可定义事件载荷：event_type=DesignReleased、object_id=CAD-0211、version=v3、baseline=BL-2024-05-17、changed_fields=[torque]、timestamp。工艺系统订阅该事件后，按契约校验字段完整性，再触发工艺路线更新。若校验失败，事件进入死信队列并告警，而不是静默丢弃。这样，跨阶段传递就从“人找数据”变成“数据找人”，并且每一步都有据可查。
把四条主线合起来看：数据模型定义“有什么”，血缘定义“从哪来”，配置与版本定义“哪一版有效”，信息流定义“怎么传”。四者共同支撑起数字线程的可追溯与可复现，也为后续自动化流程编排提供了稳定的数据底座。