📚 课程目录第4章工业通信协议与数据采集协议

4. 工业通信协议与数据采集协议

在多仪器状态监测系统中，协议不是“通信细节”，而是决定数据能否被稳定采集、能否被统一建模、能否支撑实时判断的底层约束。现场常见的组合是：底层设备通过 Modbus、CAN、Profibus、Profinet 等工业协议暴露数据，边缘网关完成协议转换与汇聚，再通过 OPC UA 或 MQTT 把数据送到上层平台。理解每种协议在状态监测中的角色，比记住它们的速率参数更重要。

一、先分清四类角色：现场总线、工业以太网、信息建模、消息传输

Modbus 和 CAN 属于典型的现场总线/串行链路协议，常用于传感器、变频器、PLC 和远程 IO 之间的短报文交互。Modbus 结构简单，主从轮询，寄存器地址即数据位置，适合采集温度、电流、转速等标量；CAN 采用多主竞争与优先级仲裁，抗干扰强，广泛用于汽车、工程机械和电池管理系统中，适合周期性广播少量关键状态量。

Profibus 与 Profinet 更偏向工厂自动化主干。Profibus 基于 RS-485 或光纤，采用主从令牌混合机制，周期数据交换稳定；Profinet 则运行在标准以太网上，支持实时通道和等时同步，适合多轴运动控制与高节拍产线。它们的特点是“确定性”强，但数据语义通常绑定厂商设备描述文件，跨品牌汇聚时需要额外映射。

OPC UA 解决的是“语义互操作”问题。它不只传值，还传类型、单位、时间戳和质量码，支持信息模型、订阅发布和客户端/服务器模式。在状态监测中，OPC UA 常作为边缘网关与 SCADA、MES 之间的统一接口，把不同现场协议的数据整理成带语义的节点树。

MQTT 则是轻量级消息传输协议，采用发布/订阅和 Broker 中转，适合带宽受限、设备数量大、网络不稳定的场景。它不规定数据语义，只负责把主题和载荷送到订阅方，因此常与 JSON、Protobuf 或 Sparkplug B 配合使用，用于远程状态上报和云端汇聚。

二、选型时真正要比较的五个维度

第一是实时性与确定性。Profinet 的等时同步可做到微秒级抖动，适合运动控制；Profibus DP 周期通常在毫秒级；Modbus TCP 受 TCP 栈和轮询周期影响，常见 50～500 ms；MQTT 经 Broker 转发，端到端延迟受网络和 QoS 影响，通常不作为硬实时通道。

第二是数据语义能力。Modbus 只有地址和值，没有单位、量程和类型，必须靠人工映射表；CAN 报文只有 ID 和 8 字节数据，语义依赖 DBC 文件；OPC UA 自带类型系统和信息模型，能直接表达“电机1.轴承温度 = 72.3 ℃，质量码 Good”。

第三是拓扑与规模。CAN 适合总线型、节点数几十个；Modbus 主从轮询，节点多时轮询周期线性增长；Profinet 支持星型、环网和 MRP 冗余；MQTT 通过 Broker 可支撑数万级设备，但需要规划主题层级和 QoS。

第四是可靠性与断线恢复。现场总线断线通常直接导致采集失败；OPC UA 订阅支持会话恢复和队列；MQTT 的 QoS 1/2 与持久会话可保证消息不丢，但会带来重复投递，需要在载荷中带时间戳和序列号去重。

第五是工程成本与生态。Modbus 和 CAN 工具链成熟、成本低；Profinet 需要认证设备和组态软件；OPC UA 需要建模和证书管理；MQTT 需要 Broker 运维和安全配置。选型不是选“最先进”，而是选“与现场设备、网络条件和平台能力最匹配”的组合。

三、一个可落地的混合采集示例

假设某车间有 12 台变频电机，每台由一台 Modbus RTU 温控表采集绕组温度，同时 PLC 通过 Profinet 与 3 台伺服驱动器交换状态字。边缘网关的采集配置可以这样组织：

# 示例：边缘网关采集任务（参数为教学假设值）
task_modbus:
  protocol: Modbus RTU
  port: /dev/ttyS0
  baud: 19200, 8N1
  poll_interval_ms: 200
  devices:
    - slave_id: 1
      points:
        - {name: "M1.winding_temp", addr: 40001, type: uint16, scale: 0.1, unit: "C"}
        - {name: "M1.current",      addr: 40002, type: uint16, scale: 0.01, unit: "A"}

task_profinet:
  protocol: Profinet IO
  cycle_ms: 4
  devices:
    - name: "Servo_A"
      slots:
        - {name: "Servo_A.status_word", offset: 0, type: uint16}
        - {name: "Servo_A.actual_torque", offset: 2, type: int16, scale: 0.1, unit: "Nm"}

publish:
  opcua:
    endpoint: "opc.tcp://0.0.0.0:4840"
    namespace: "urn:workshop:monitor"
  mqtt:
    broker: "tcp://192.168.10.20:1883"
    topic: "workshop/line1/{device}/{point}"
    qos: 1
    retain: false

运行后，判断采集是否正常的依据不是“有没有数据”，而是看三件事：一是时间戳是否连续，Modbus 轮询周期 200 ms 下，相邻时间戳间隔应稳定在 180～230 ms；二是质量码，OPC UA 节点应显示 Good，若出现 BadWaitingForInitialData 说明驱动未完成首次读取；三是 MQTT 主题是否按预期到达，可用 mosquitto_sub -t 'workshop/line1/#' -v 观察，若某测点长时间无消息，应检查网关本地队列是否积压。

选型速记：现场层优先看“确定性”，汇聚层优先看“语义”，平台层优先看“可达与可扩展”。Modbus/CAN 负责把值取回来，OPC UA 负责把值讲清楚，MQTT 负责把值送得远。

四、常见误区与排障方向

误区一：用 MQTT 直接替代现场总线做实时控制。MQTT 的 Broker 转发和网络抖动使其不适合硬实时闭环，状态监测可以，控制指令需谨慎。

误区二：认为 OPC UA 一定比 Modbus 慢。OPC UA 的订阅发布模式在千点级采集下可做到 100 ms 级更新，关键在服务器实现和网络配置，而非协议本身。

误区三：忽略字节序和寄存器映射。Modbus 多寄存器浮点数存在 ABCD/CDAB 等排列，若网关与设备约定不一致，温度会显示为异常大数或负数，排障时应先核对字节序和缩放系数。

误区四：CAN 总线不加终端电阻。120 Ω 终端缺失会导致反射和误码，表现为偶发丢帧，状态监测中会看到数据跳变而非完全中断，容易被误判为传感器故障。

实际工程中，最稳妥的做法是：现场设备保留原有协议，边缘网关做协议适配和统一建模，上层用 OPC UA 对接监控系统、用 MQTT 对接远程平台。这样既尊重了现场设备的实时性约束，又满足了状态监测对语义统一和远程汇聚的需求。