3. 数据贯通顶层架构设计
复杂产品的数据贯通不是把几个系统用接口连起来那么简单。它要解决的是：总体、结构、电气、软件、工艺、试验等多个专业在各自工具链中产生的模型，如何在同一套语义下被识别、追溯和复用。顶层架构设计的任务，就是为这种跨域协同提供稳定的骨架——数据中台负责“存得下、找得到、管得住”，模型总线负责“流得动、对得上、追得回”，贯通参考架构则给出各层职责与集成方式的统一约定。
一、三层架构的职责划分
面向复杂产品的数据贯通顶层架构通常划分为三层：数据中台层、模型总线层和应用与工具层。三层之间通过明确的接口契约解耦，避免任一工具升级或替换时引发全链重构。
数据中台层是贯通的基础设施。它不直接参与设计计算，而是承担四类核心能力：一是统一数据模型（UDM），把不同工具中的“零件”“接口”“信号”“参数”抽象为可映射的实体；二是主数据与编码管理，保证同一对象在总体、结构、工艺各处的标识一致；三是版本与基线管理，记录模型在什么时间、由谁、基于哪个基线发生了变更；四是元数据与血缘，记录“这个参数来自哪次仿真、被哪个下游引用”。
模型总线层是贯通的传输与转换中枢。它不等同于企业服务总线（ESB），而是面向模型对象的消息与转换通道。典型能力包括：模型注册与发现、格式适配（如 STEP、JT、Modelica、SysML、XML/JSON 之间的转换）、变更事件发布/订阅、以及跨域映射规则的集中管理。模型总线让“总体改了接口尺寸”这件事，能以事件形式通知结构、工艺和试验域，而不是靠人工邮件传递。
应用与工具层保留各专业现有工具链（CAD、CAE、PLM、ALM、工艺规划等），通过标准适配器接入总线。这一层的原则是“不推翻、不重造”，只要求工具通过适配器暴露必要的模型读写与事件接口。
二、贯通参考架构的关键约定
仅有分层还不够，贯通能否落地取决于几条关键约定是否被严格执行。
第一，统一标识先行。任何进入中台的模型对象，必须先获得全局唯一标识（GUID），并与各工具内部ID建立映射表。例如某结构件在CAD中叫“Bracket_A”，在PLM中物料号是“M-2024-0317”，在中台中应统一为“PRT-7f3a…”，映射关系存入主数据服务。没有这一步，后续的版本追溯和影响分析都无从谈起。
第二，接口契约显式化。模型总线上的每一次交互都应基于显式契约，而不是隐式约定。契约至少包含：模型类型、必填字段、单位约定、版本兼容策略。例如总体向结构传递“安装接口”时，契约规定必须携带接口坐标系原点、法向、公差带和版本号；结构域收到后若发现版本不兼容，总线应拒绝投递并触发告警，而不是静默丢弃。
第三，变更以事件驱动。传统做法是“改完通知下游”，容易遗漏。参考架构要求：任何模型变更在中台产生新版本后，由总线自动发布ModelChanged事件，携带模型ID、旧版本、新版本、变更类型和影响范围。订阅了该模型的下游工具或流程自动收到通知，并决定是否触发重新校验或重新发布。这样把“人找变更”变成“变更找人”。
三、一个可参照的落地示例
假设某复杂产品在总体设计阶段调整了某安装接口的孔径，从Φ12改为Φ14。在参考架构下，这一变更的贯通路径如下：
- 总体工具通过适配器将新版本接口模型写入中台，中台生成新版本V2.3，并记录变更字段
hole_diameter: 12→14。 - 模型总线发布
ModelChanged事件，模型ID为IFC-0x9a2，影响范围标记为“结构安装域、工艺装配域”。 - 结构域订阅者收到事件后，自动比对本地引用版本，发现仍为V2.2，触发差异检查；若结构件孔位需同步修改，则生成变更任务。
- 工艺域收到事件后，检查装配工装是否受影响，若工装定位销直径需调整，则生成工装变更请求。
- 中台元数据服务记录本次变更的完整血缘：谁发起、影响了哪些模型、哪些下游已响应、哪些尚未确认。
这个过程中，数据中台提供“版本+血缘”，模型总线提供“事件+路由”，应用层各工具只需实现适配器即可参与，无需改造内部数据模型。这就是参考架构的价值：把贯通逻辑从各工具中抽离出来，集中到中台和总线，使复杂产品的数据链具备可管理、可追溯、可扩展的工程属性。