📚 课程目录第4章边缘与云端通信协议

4. 边缘与云端通信协议

在 EcoStruxure 边缘控制与云端协同的架构中，边缘侧通常直接面对 PLC、变频器、电表、温控器、传感器等现场设备，而云端侧承担集中监视、历史存储、跨站点分析与远程运维。两者之间并不是“一条网线直连”那么简单：现场设备使用的协议、边缘网关支持的协议、云端平台接受的协议往往并不一致。因此，理解 Modbus、OPC UA、MQTT 三种协议各自在链路中的位置，以及如何完成配置、数据映射和安全传输，是边缘与云端协同能否真正落地的关键。

三种协议在协同链路中的分工

Modbus 是最常见的现场层协议，分为 Modbus RTU（串行，RS-485）和 Modbus TCP（以太网）。它结构简单、开销小，适合读取寄存器式的数据，例如电表的电压、电流、有功功率，或变频器的频率给定与运行状态。Modbus 的局限在于：它只定义“读/写哪个地址的哪段寄存器”，不携带丰富的语义信息，也没有内建安全机制，因此通常只用于边缘网关到现场设备这一段。

OPC UA 面向信息建模，强调类型、语义和互操作性。它可以把一台设备的多个变量组织成带命名空间和节点 ID 的地址空间，并支持订阅、方法调用、历史访问。OPC UA 既可用于边缘网关采集支持 OPC UA 的 PLC/控制器，也可用于边缘与上层系统之间的数据交换。它内建证书、签名和加密能力，适合对数据语义和安全要求较高的场景。

MQTT 是轻量级的发布/订阅协议，采用 Broker 中转，主题（Topic）分层，支持 QoS 0/1/2。它非常适合边缘网关通过不稳定的广域网上报数据到云端，因为连接可以断线重连，消息可以按 QoS 保证至少一次或恰好一次。MQTT 本身不描述数据语义，通常配合 JSON 载荷和主题命名规范来表达“哪个站点、哪台设备、哪个测点、什么值、什么时间”。

数据映射：从寄存器到云端测点

数据映射是三种协议协同的核心。以一台 Modbus TCP 电表为例，假设其寄存器定义如下：保持寄存器 40001 为 A 相电压，单位 0.1 V，无符号 16 位；40002 为 A 相电流，单位 0.01 A；40003 为有功功率，单位 0.001 kW，有符号 16 位。边缘网关读取后，不能直接把 40001 的原始值 2203 发给云端，而应映射为带语义的测点：站点 S01、设备 MTR-01、测点 voltage_a、工程值 220.3 V、时间戳、质量码 good。

映射通常包含四步：第一，确定源地址与数据类型，例如 40001 对应 uint16；第二，确定缩放与偏移，例如工程值 = 原始值 × 0.1 + 0；第三，确定目标测点编码，例如 S01.MTR01.voltage_a；第四，确定发布主题，例如 site/S01/device/MTR01/telemetry。若使用 OPC UA，则源侧是节点 ID，例如 ns=2;s=Line1.Meter1.VoltageA，映射时保留其命名空间语义，再转换为统一测点编码。这样，云端无论接收的是 MQTT 消息还是 OPC UA 订阅数据，都能按同一套测点编码入库。

配置要点与示例

Modbus 侧配置的关键是轮询周期、超时和寄存器块合并。若 40001 至 40003 连续，应一次读取 3 个寄存器，减少请求次数；轮询周期可按数据变化速度设置，电参量常用 1 s 至 5 s。OPC UA 侧配置的关键是安全策略、用户身份和订阅间隔，建议使用 Sign & Encrypt 策略并启用证书信任列表。MQTT 侧配置的关键是 Broker 地址、端口、客户端 ID、用户名密码、Keep Alive、QoS 和遗嘱消息。以下是一个边缘网关北向 MQTT 配置片段示例：

broker: ssl://cloud.example.com:8883
client_id: edge-gw-S01
username: edge_S01
password: ********
keep_alive: 60
qos: 1
topic_prefix: site/S01
payload_format: json
tls:
  ca_file: /etc/edge/ca.pem
  cert_file: /etc/edge/client.pem
  key_file: /etc/edge/client.key
  verify_server: true

对应的发布载荷可设计为：

{
  "ts": "2025-03-18T10:15:30+08:00",
  "device": "MTR-01",
  "points": [
    {"code": "voltage_a", "value": 220.3, "unit": "V", "quality": "good"},
    {"code": "current_a", "value": 12.45, "unit": "A", "quality": "good"},
    {"code": "power_kw", "value": 2.741, "unit": "kW", "quality": "good"}
  ]
}

这里的时间戳建议由边缘侧生成并带时区，避免云端按接收时间入库造成时序偏差；质量码用于标识该值是否有效，例如通信超时时应发布 quality 为 bad，而不是继续沿用旧值。

安全传输方法

三种协议的安全能力差异明显。Modbus RTU/TCP 本身没有加密和认证，若必须跨不可信网络使用，应通过串口服务器加 VPN、或在边缘网关与设备之间使用隔离网段和访问控制列表，不能把 Modbus TCP 端口直接暴露到公网。OPC UA 应启用安全策略，使用 X.509 证书完成客户端与服务器双向认证，并设置合理的证书有效期与吊销检查。MQTT 应使用 TLS，端口通常为 8883，Broker 侧启用客户端证书或至少用户名密码加 ACL，按主题前缀限制每个边缘网关只能发布自己站点的主题，例如只允许 site/S01/#，防止越权发布。

不要把 MQTT 的 1883 明文端口直接映射到公网，也不要在边缘网关上关闭证书校验。安全配置一旦省略，现场数据和控制指令都可能被窃听或伪造。

结果观察与判断依据

配置完成后，可从三个层面判断链路是否正常。第一，边缘网关的采集状态：Modbus 轮询是否持续成功、OPC UA 订阅是否保持、是否有超时计数。第二，MQTT 发布状态：是否成功连接 Broker、QoS 1 消息是否收到 PUBACK、断线后是否自动重连并补发缓存数据。第三，云端入库状态：按测点编码查询最近 5 分钟数据，检查时间戳是否连续、数值是否在合理量程内、质量码是否为 good。若发现某测点长期为 bad，应回到映射表核对寄存器地址、数据类型和缩放系数；若发现数据延迟增大，应检查轮询周期、网络带宽和 Broker 负载。通过这三层观察，才能确认 Modbus、OPC UA、MQTT 在边缘与云端之间真正形成了可靠、安全、可追溯的数据通道。