📚 课程目录第4章数据共享架构基础

4. 数据共享架构基础

跨企业制造数据共享不是把数据库端口开放给对方，也不是简单搭一条消息通道。它需要一套可被多方理解、可治理、可演进的架构语言。架构分层回答“系统由哪些职责层组成”，组件回答“每层由什么软件单元承载”，接口与协议回答“组件之间如何对话”，参考模型则回答“不同企业如何用同一套语义描述自己的产线、设备与订单”。四者缺一不可，否则共享只能停留在点对点脚本的层面。

一、核心原理：五层职责与两类平面

面向制造数据共享，推荐采用“五层两平面”的分层结构。五层自下而上为：接入层负责设备、PLC、SCADA、MES、ERP 等异构数据源的适配与采集；汇聚层负责边缘缓存、批量汇聚与流式接入；治理层负责主数据对齐、质量校验、脱敏与权限标注；服务层负责以 API、事件、文件等方式对外暴露数据产品；应用层承载协同排产、质量追溯、供应链碳核算等跨企业场景。两平面分别是控制平面（身份、策略、目录、审计）和数据平面（真实数据流动路径）。控制平面决定“谁能看什么”，数据平面决定“数据怎么走”，二者必须解耦，否则策略变更会牵动数据链路。

分层的关键价值在于：任何一层的变化不应穿透到其他层。例如更换采集协议只影响接入层，调整脱敏规则只影响治理层，新增协同应用只影响应用层。若共享方案中“改一个字段要动五个系统”，说明分层已经失效。

二、组件、接口与协议：从职责到契约

每层由具体组件承载。接入层常见组件包括协议网关、边缘代理、OPC UA 客户端；汇聚层包括消息队列（如 Kafka、MQTT Broker）、对象存储与流处理引擎；治理层包括元数据目录、数据质量引擎、策略执行点；服务层包括 API 网关、事件总线、数据产品目录；应用层则是各参与方的前端与业务服务。

接口是组件之间的契约，协议是契约的传输与编码规则。制造数据共享中常见的组合如下表所示：

接口类型	典型协议	适用场景	关键约束
设备采集接口	OPC UA、Modbus TCP	产线设备实时数据	时延低、语义需映射
消息事件接口	MQTT、AMQP、Kafka	状态变更、告警、工单流转	至少一次/恰好一次语义
查询服务接口	REST/HTTPS、GraphQL	订单、库存、质量记录查询	鉴权、分页、限流
批量文件接口	SFTP、S3 API	历史数据、对账、归档	完整性校验、加密
语义互操作接口	SPARQL、Asset Admin Shell	跨企业资产与产品语义对齐	依赖参考模型

接口设计应遵循“契约先行”：先定义数据产品的输入输出、SLA、版本策略，再实现传输。协议选择则要看数据形态——高频小消息选 MQTT，海量吞吐选 Kafka，复杂查询选 REST，语义互操作选基于参考模型的标准接口。

三、参考模型：让不同企业说同一种语言

参考模型是跨企业共享的“语义底座”。制造领域常用的参考模型包括：ISA-95（企业—工厂—区域—单元—设备的层级模型）、OPC UA 信息模型（设备与资产的类型化描述）、Asset Administration Shell（AAS）（工业 4.0 资产管理壳）、IEC 62264 与 ISO 15926（流程工业数据交换）。它们解决的核心问题是：A 企业的“设备编号”与 B 企业的“资产 ID”如何映射到同一语义对象。

参考模型落地通常分三步：第一步，选取与场景匹配的模型子集，避免全量引入；第二步，建立本地字段到模型属性的映射表；第三步，在治理层维护映射版本，确保共享双方对同一字段的理解一致。例如，将本地 MES 的 equip_no 映射为 AAS 中的 AssetIdentification，将 work_order 映射为 ProductionOrder，跨企业查询时便无需逐字段协商。

# 参考模型映射示例（YAML 片段）
source: MES.equip_no
target: AAS.AssetIdentification.idShort
version: 1.2
owner: 制造数据治理组
review_cycle: quarterly

四、案例与场景：一次跨企业质量追溯

某整车厂需要追溯一批零部件的热处理批次。整车厂与零部件厂分属不同企业，数据不能直接互访。按分层架构落地：零部件厂接入层从热处理炉 PLC 采集温度曲线，汇聚层写入本地 Kafka；治理层按 ISA-95 对齐“批次—设备—工艺”关系，并脱敏供应商成本字段；服务层以事件接口发布“批次完成”消息，以 REST 接口提供质量报告查询；整车厂应用层订阅事件并调用查询接口，完成追溯。控制平面统一管理双方身份与访问策略，数据平面只传输必要字段。整个过程无需开放数据库，也无需人工导出 Excel。

判断一个共享架构是否合格，可以问三个问题：新增一个参与方需要改几层？更换一种协议需要改几层？语义冲突时由谁负责裁决？如果答案分别是“一层”“一层”“治理层”，说明分层与参考模型已经生效。

五、常见误区与复盘

把分层当画图。分层不是 PPT 上的色块，而是依赖方向：上层依赖下层契约，下层不感知上层业务。若接入层直接调用应用层接口，分层即被击穿。
接口无版本。跨企业接口一旦发布就应版本化，字段废弃需保留过渡期。缺少版本策略是共享中断的高频原因。
协议选型只看技术偏好。协议要与数据形态、时延要求、参与方能力匹配。用 REST 轮询做高频设备数据，往往造成时延与负载双输。
参考模型全量照搬。参考模型应裁剪为场景子集，全量引入会带来巨大映射成本，反而拖慢共享上线。
控制平面与数据平面耦合。策略变更若需重启数据链路，说明二者未解耦，治理将难以持续。

复盘时建议以“层—组件—接口—协议—参考模型”五列清单逐项核对，确保每个共享场景都能定位到明确的职责层与契约，而不是依赖某个人的经验或某个系统的私有实现。

掌握分层、组件、接口、协议与参考模型这五个概念，就拥有了描述任何跨企业共享方案的“坐标系”。后续无论是设计新的共享场景，还是排查已有链路的故障，都可以回到这个坐标系中定位问题所在层与缺失的契约。