存量改造实战：Legacy PLC（老旧设备）串口协议转MQTT的通用架构设计

摘要： 在工业物联网项目中，相比于支持OPC UA/Profinet的新设备，仅具备串口通信能力的“哑设备”（Legacy Devices）占据了存量市场的80%。本文不依赖特定的上位机软件，而是从底层通信原理出发，探讨如何利用边缘计算网关充当协议转换器，将封闭的Modbus RTU/PPI/HostLink协议转换为开放的MQTT协议，实现OT与IT的低成本融合。

导语： 面对车间里运行了10年以上的西门子S7-200、三菱FX2N或欧姆龙C系列PLC，工程师往往陷入两难：不动程序无法获取数据，动程序又面临停机风险。如何构建一个“非侵入式（Non-intrusive）”的数据采集层？核心思路是利用边缘网关接管串口通信，在边缘侧完成协议的ETL（抽取、转换、加载）。

从二进制串口流到云端JSON的技术路径

一、物理层挑战：RS232/485的电气特性适配

在接入老旧PLC前，首先要解决物理连接问题。与以太网的即插即用不同，串口通信对接线极其敏感。

RS232 (Point-to-Point)：
1. 场景：通常是PLC唯一的编程口（如Mini-DIN 8针或DB9）。
2. 难点：它是1:1通信。如果HMI（触摸屏）已经占用了该口，需要使用“串口分线器”或支持“透传模式”的网关，采用Spy Mode（监听模式）或Pass-through（透传）策略。
3. 避坑：注意TX/RX引脚必须交叉连接（Cross-over），且务必共地（GND）。
RS485 (Bus Topology)：
1. 场景：PLC的通讯扩展卡或变频器接口。
2. 难点：半双工通信及信号反射。
3. 策略：必须严格遵循“手拉手”菊花链拓扑，末端需并联120Ω终端电阻，防止信号反射导致的丢包。

二、协议层解析：边缘侧的驱动适配

物理层打通后，网关接收到的是Hex（十六进制）字节流。边缘侧需要运行协议驱动（Protocol Driver）来解析这些数据。

以三菱FX计算机链接协议（Computer Link）为例，一个标准的读指令帧结构如下： [STX] [Station No] [Command] [Wait] [Address] [Bytes] [Sum] [ETX]

边缘网关的解析逻辑：

主动轮询（Polling）：网关作为Master，按设定的周期（如500ms）发送读指令。
校验检查：接收到Response后，首先计算Sum Check或CRC。
字节序转换（Endianness）：老旧设备中常见大端（Big-Endian）或字交换（Byte-Swap）格式，网关需将其转换为IT系统通用的格式。

注：在本次实验环境中，我们使用了鲁邦通边缘计算网关作为硬件载体，其内置的驱动库屏蔽了上述底层的帧构建过程，开发者只需配置寄存器地址（如D100, M0）即可。

三、数据层封装：MQTT Payload设计

为了对接MES或云平台，我们需要将“寄存器地址”抽象为“业务变量”。

1. 边缘计算（Edge Computing） 在上传前，建议在网关进行简单的预处理：

线性变换：Actual_Val = Raw_Val * 0.1 + Offset（将整数转换为浮点数）。
状态映射：将M0=1映射为status: "RUNNING"。

2. JSON结构设计 推荐使用扁平化的JSON结构，以减少云端解析开销：

JSON

{
  "topic": "iot/workshop_A/machine_05/telemetry",
  "timestamp": 1678845200,
  "payload": {
    "gateway_id": "gw_serial_001",
    "plc_model": "mitsubishi_fx",
    "data": {
      "yield_count": 502,      // 对应 D100
      "temperature": 45.5,     // 对应 D200 (经过 *0.1 处理)
      "is_alarm": false        // 对应 M10
    }
  }
}

四、架构总结与实施建议

这种“PLC (Serial) -> Gateway (Edge) -> Broker (Cloud)”的架构具有明显的优势：