2. Hexagon制造追溯数据模型

制造追溯的本质不是“把数据存起来”，而是把现场发生的事件还原成一条可解释的因果链：哪一批物料、在哪个工单下、由哪台设备、按哪套参数、加工成了哪个序列号的产品，过程中又产生了哪些质量特征值。Hexagon 的追溯数据模型要解决的正是这个问题——用一组稳定的主数据对象和一组随时间增长的事务对象，把产品、批次、序列号、工单、物料与过程数据关联起来。理解这套模型，是后续做质量闭环、缺陷定位和召回范围计算的基础。

一、六类核心对象及其角色分工

在建模时，先把对象分成“定义型”和“发生型”两类，可以避免大量冗余关联。

• 产品（Product）：定义型对象，描述“要造什么”。关键字段包括产品编码、版本、图号、适用的工艺路线。产品是追溯的顶层定义，不随生产批次变化。
• 物料（Material）：定义型对象，描述“用什么造”。包括原材料、外购件、半成品，字段有物料编码、规格、供应商、批次管理标识（是否按批次追溯）。
• 工单（Work Order）：发生型对象，是生产的组织单元。字段包括工单号、产品编码、计划数量、目标产线、计划起止时间。工单把“产品定义”落到一次具体的生产任务上。
• 批次（Lot/Batch）：发生型对象，是物料或半成品的分组单元。字段包括批次号、物料编码、供应商批次、数量、入库时间。批次是供应商追溯与内部追溯的衔接点。
• 序列号（Serial Number）：发生型对象，是单件追溯的最小粒度。字段包括序列号、产品编码、工单号、当前状态（在制/完工/报废）。序列号让“单件级”追溯成为可能。
• 过程数据（Process Data）：发生型对象，记录加工过程中产生的参数与结果。包括设备号、工序号、时间戳、工艺参数（如扭矩、温度、压力）、质量特征值（如尺寸、电阻）、判定结果（OK/NG）。

这六类对象的关系可以概括为：产品与物料通过 BOM 关联；工单引用产品；批次引用物料；序列号属于工单并消耗批次；过程数据挂在序列号（或批次）上。下面这张图展示了它们之间的关联结构。

二、关联建模的关键：主键、外键与关系表

把对象画成图之后，落地到数据库或 MES 数据表时，需要明确每个对象的唯一标识和引用方式。以下是一组可直接参考的表结构设计（字段为示例，实际项目按需扩展）。

-- 产品表
CREATE TABLE product (
  product_id      VARCHAR(32) PRIMARY KEY,
  product_name    VARCHAR(64),
  version         VARCHAR(16),
  routing_id      VARCHAR(32)   -- 工艺路线
);

-- 物料表
CREATE TABLE material (
  material_id     VARCHAR(32) PRIMARY KEY,
  material_name   VARCHAR(64),
  spec            VARCHAR(64),
  supplier_id     VARCHAR(32),
  lot_managed     CHAR(1)       -- Y/N 是否按批次追溯
);

-- 工单表
CREATE TABLE work_order (
  wo_id           VARCHAR(32) PRIMARY KEY,
  product_id      VARCHAR(32),
  plan_qty        INT,
  line_id         VARCHAR(32),
  plan_start      DATETIME,
  plan_end        DATETIME,
  FOREIGN KEY (product_id) REFERENCES product(product_id)
);

-- 批次表
CREATE TABLE lot (
  lot_id          VARCHAR(32) PRIMARY KEY,
  material_id     VARCHAR(32),
  supplier_lot    VARCHAR(32),
  qty             DECIMAL(12,3),
  in_time         DATETIME,
  FOREIGN KEY (material_id) REFERENCES material(material_id)
);

-- 序列号表
CREATE TABLE serial (
  sn              VARCHAR(48) PRIMARY KEY,
  product_id      VARCHAR(32),
  wo_id           VARCHAR(32),
  status          VARCHAR(16),  -- 在制/完工/报废
  FOREIGN KEY (wo_id) REFERENCES work_order(wo_id)
);

-- 序列号-批次消耗关系表（M:N）
CREATE TABLE sn_lot_consume (
  sn              VARCHAR(48),
  lot_id          VARCHAR(32),
  qty             DECIMAL(12,3),
  PRIMARY KEY (sn, lot_id),
  FOREIGN KEY (sn) REFERENCES serial(sn),
  FOREIGN KEY (lot_id) REFERENCES lot(lot_id)
);

-- 过程数据表
CREATE TABLE process_data (
  record_id       BIGINT PRIMARY KEY,
  sn              VARCHAR(48),
  lot_id          VARCHAR(32),
  station_id      VARCHAR(32),
  process_step    VARCHAR(32),
  param_name      VARCHAR(32),
  param_value     DECIMAL(12,4),
  result          VARCHAR(8),   -- OK/NG
  ts              DATETIME,
  FOREIGN KEY (sn) REFERENCES serial(sn)
);

这里有两个设计决策值得注意。第一，序列号与批次之间用独立的关系表，而不是在序列号表里直接放一个批次字段。原因是单件产品可能消耗多个批次物料（例如一台设备装配了来自三个批次的螺丝），M:N 关系表才能完整记录。第二，过程数据同时保留 sn 和 lot_id 两个外键，这样既能按单件查过程，也能按批次聚合分析，支持“从批次反查所有受影响序列号”的召回场景。

三、从关联模型到追溯查询

模型建好之后，最有价值的验证方式是跑通两类典型查询。

正向追溯（从物料批次找产品）：某供应商批次 LOT-2024-0517-A 出现来料缺陷，需要找出所有使用了该批次的序列号。查询逻辑是：在 sn_lot_consume 中按 lot_id 过滤，关联 serial 得到序列号列表，再关联 work_order 得到工单和产线信息。结果可以进一步按工单分组，估算影响数量。

反向追溯（从序列号找物料与过程）：客户返回一台序列号为 SN-20240517-00873 的产品，需要还原它的完整生产历史。查询逻辑是：以 sn 为主键，分别查 sn_lot_consume 得到消耗的所有批次，查 process_data 得到该序列号经过的每道工序、设备、参数和判定结果，再关联 work_order 和 product 得到生产上下文。

四、常见建模陷阱

在实际项目中，以下三个问题最容易导致追溯链断裂。

• 批次号在车间被“简化”使用。例如操作员手工录入时把 LOT-2024-0517-A 写成 0517A，导致关联失败。应在采集端做批次号校验或扫码强制录入。
• 序列号在返修后状态未更新。返修品重新进入产线时，如果沿用原序列号但未记录返修工单和新的过程数据，追溯链会出现“时间断层”。建议返修也生成独立的过程记录，并标记 rework_flag。
• 过程数据只存结果不存参数。只记录 OK/NG 而不记录实际参数值，无法做参数漂移分析和工艺优化。参数值、判定阈值、实际测量值应同时保留。

把产品、物料、工单、批次、序列号和过程数据按上述方式关联起来之后，追溯就不再是“查一张表”，而是沿着对象关系图做一次有方向的遍历。正向遍历回答“这批料去了哪里”，反向遍历回答“这台产品经历了什么”。两种遍历共用同一套模型，这正是 Hexagon 追溯数据模型在质量闭环中的核心价值。