3. 制造数据模型与信息架构
在 Hexagon 数字化制造平台中，数据模型不是“数据库表结构”的同义词，而是把产品、工艺、资源、工厂以及测量结果统一到一套可追溯语义中的骨架。若数据模型设计不当，后续的工艺规划、仿真、质量分析和设备联调都会陷入“同名不同义、同物不同码”的困境。本节从平台的数据分层出发，重点讲清元数据管理、PPR 模型以及数据流设计三件事，并给出可落地的建模约定。
一、平台数据模型的分层结构
Hexagon 平台的数据模型通常分为四层：元模型层定义“有哪些类型、属性和关系”；模型层定义具体工厂、产线、工位的实例结构；实例数据层承载每个零件、每道工序、每台设备的实际数据；事务数据层记录测量结果、报警、工单执行等随时间变化的数据。四层之间通过唯一标识（UID）和版本号关联，避免直接依赖名称做外键。
元模型层建议采用“类型—属性—关系”三元组描述。例如定义一个类型 Operation，属性包括 opCode、opName、stdTime、tolerance，关系包括 consumesResource、producesFeature、precedes。这样，工艺变更时只需调整关系实例，而不必修改表结构。
二、元数据管理：让数据可发现、可追溯
元数据管理解决三个问题：数据是什么、来自哪里、被谁使用。在 Hexagon 平台中，元数据通常包括技术元数据（字段类型、单位、精度）、业务元数据（所属项目、工位、责任人）和操作元数据（创建时间、版本、变更原因）。
实际落地时，建议为每个关键对象建立“元数据卡片”，至少包含：对象 UID、对象类型、版本号、单位制、数据来源系统、更新频率、责任人。例如一个测量特征 Hole_D10 的元数据卡片中，单位制为 mm，来源为 PC-DMIS 测量程序，更新频率为每件一次，责任人为质量工程师。这样在数据异常时，可以快速定位是测量程序版本问题还是工艺参数漂移。
三、PPR 模型：产品—工艺—资源—工厂
PPR 是数字化制造的核心信息架构，分别代表 Product（产品）、Process（工艺）、Resource（资源）和 Plant（工厂）。四者不是简单并列，而是通过“需求—能力—约束”关系耦合：产品定义“要做什么”，工艺定义“怎么做”，资源定义“用什么做”，工厂定义“在哪里做”。
在 Hexagon 平台中，PPR 模型通常以图结构存储。产品节点挂接 BOM 和特征树；工艺节点挂接工序、工步和参数；资源节点挂接设备、工装和刀具；工厂节点挂接产线、工位和物流路径。关键关系包括：Product -[requires]-> Process、Process -[assignedTo]-> Resource、Resource -[locatedIn]-> Plant。当工艺变更时，平台可以沿关系链自动检查资源能力是否满足、工厂布局是否冲突。
四、数据流设计：从产品特征到测量反馈
数据流设计的核心是“单向主链 + 闭环反馈”。主链方向为：产品特征 → 工艺参数 → 资源指令 → 工厂执行 → 测量结果。反馈方向为：测量结果 → 偏差分析 → 工艺参数修正 → 产品特征更新。两个方向必须使用同一套 UID 和版本号，否则反馈无法准确回写。
以一个法兰盘加工为例。产品特征 Hole_D10 定义孔径 10±0.02 mm；工艺参数 Drill_Speed=1200 rpm、Feed=0.15 mm/rev；资源指令下发至加工中心 MC-01；工厂执行后由三坐标测量机采集实际孔径。若实测均值为 10.025 mm，偏差 +0.005 mm，平台应自动触发工艺参数修正建议，例如将 Drill_Speed 调整为 1150 rpm，并记录变更版本。整个过程的数据流必须可追溯：谁在什么时间、基于哪条测量记录、修改了哪个参数、影响了哪些产品特征。
五、建模约定与落地建议
为了让 PPR 模型在 Hexagon 平台中真正可用，建议遵循以下约定：
- UID 统一：所有对象使用平台生成的全局唯一标识，禁止用名称做关联键。
- 版本可追溯：每次修改生成新版本，旧版本保留，支持按时间点回溯。
- 单位制显式声明：长度统一 mm，角度统一度，时间统一秒，避免隐式换算。
- 关系方向明确：PPR 关系有向，反向查询通过索引实现，不依赖双向冗余字段。
- 元数据随对象创建：对象创建时自动写入来源系统、责任人、更新频率。
最后，数据模型和 PPR 结构不是一次设计就固定不变的。建议在项目初期用一个小型试点产线验证元数据模板和关系定义，确认数据流闭环可跑通后，再逐步扩展到全厂。每次扩展时，优先复用已有类型和关系，避免为每个新场景创建孤立的数据结构。