1. 为什么互操作性是 IIoT 的"卡脖子"问题？
我们在汽车零部件工厂的数字化改造项目中，我们发现：
- 车间同时存在 Siemens S7-1200（Profinet）、ABB 机器人（DSQC652）、国产温控仪表（Modbus RTU）
- 各自数据无法直接互通，MES 系统需为每类设备开发独立接口
- 新增一台设备平均耗时 2~3 周，维护成本高、扩展性差
这正是最典型的 互操作性（Interoperability）难题------不仅指"能通信"，更要求"能理解、能协同、能集成"。
根据 IIC（工业互联网联盟）定义，互操作性分为三层：
- 语法互操作（Syntax）：数据格式、协议一致
- 语义互操作（Semantics）：数据含义可被理解
- 组织互操作（Organizational）：业务流程可对齐
2. 互操作性挑战的根源
| 问题类型 | 具体表现 |
|---|---|
| 协议异构 | Modbus、CANopen、Profinet、EtherCAT、BACnet 等并存 |
| 数据模型缺失 | 同一"温度"字段，有的叫 temp，有的叫 T1，单位有 ℃/℉/K |
| 厂商封闭生态 | 某品牌 PLC 仅支持私有 API，文档不开放 |
| 实时性 vs 云原生冲突 | OT 层要求低延迟，IT 层偏好 REST/MQTT |
3. 系统化解决方案
3.1 通信层：协议标准化 + 边缘适配
-
主推 OPC UA over TSN
OPC UA 兼具跨平台、安全、信息建模能力，TSN（时间敏感网络）保障实时性，已成为 IEC 62541 国际标准。
-
轻量级场景用 MQTT + Sparkplug B
Sparkplug 定义了统一的 Topic 结构、Birth/Death 机制、数据类型（如
Int32,Float），适合边缘-云协同。 -
存量设备通过边缘网关转换
使用开源方案（如 Eclipse Kura、Node-RED）或商业网关（Kepware、华为 IoT Edge）实现协议桥接。
3.2 语义层：构建统一信息模型
-
采用 Asset Administration Shell（AAS）
德国工业 4.0 提出的 AAS 标准（ISO/IEC 23247），为每个物理资产创建"数字身份证"，包含属性、操作、关系。
-
OPC UA 信息模型自定义
通过 XML 或 UANodeSet 定义设备类型（如
MotorType），继承标准类型（如BaseObjectType），确保跨系统一致性。
3.3 平台层：微服务化接入架构
- 平台需提供：
- 设备注册中心（含元数据管理）
- 协议插件机制（支持热插拔）
- 数据清洗 & 标准化管道
未来，随着 OPC UA FX（5G/TSN 融合） 和 I4.0 Components 的普及，互操作将从"项目级"走向"生态级"。