4. 数采仪通信协议基础
数采仪要把现场仪表的测量值送到监控平台，中间至少要跨越两段通信：一段是数采仪与现场分析仪、PLC、流量计之间的“设备侧通信”，另一段是数采仪与环保监控平台之间的“平台侧通信”。这两段通信对实时性、可靠性、数据量和网络环境的要求完全不同，因此选用的协议也不同。本节围绕 Modbus RTU、Modbus TCP、HJ 212 和 MQTT 四种常见协议，讲清它们各自解决什么问题、报文长什么样、在环保数采中该用在哪一段。
一、设备侧通信：Modbus RTU 与 Modbus TCP
Modbus 是主从式（请求—应答）协议，数采仪作为主站主动发起请求，仪表作为从站应答。它不规定物理层，只规定报文格式，因此同一套寄存器模型可以跑在串口上，也可以跑在以太网上。
Modbus RTU 运行在 RS-485/RS-232 串行链路上，报文由“从站地址 + 功能码 + 数据 + CRC16 校验”组成，帧与帧之间靠至少 3.5 个字符时间的静默间隔分隔。以读取一台 COD 分析仪（从站地址 0x01）的测量值寄存器 0x0000、共 2 个寄存器为例，主站发出的请求帧为：
01 03 00 00 00 02 C4 0B
│ │ └──┬──┘ └──┬──┘ └──┬──┘
│ │ │ │ └─ CRC16 校验（低字节在前）
│ │ │ └───────── 寄存器数量 = 2
│ │ └───────────────── 起始寄存器地址 0x0000
│ └─────────────────────── 功能码 03（读保持寄存器）
└────────────────────────── 从站地址 0x01从站正常应答为 01 03 04 XX XX YY YY CRC，其中 04 表示后续 4 个字节数据，两个寄存器拼成一个 32 位浮点数或两个 16 位整数，具体由仪表手册的寄存器表定义。RTU 的优点是简单、抗干扰好、布线成本低，一条 485 总线可挂多台仪表；缺点是速率低（常用 9600/19200 bps）、只能轮询、没有统一的数据语义，寄存器地址和数据类型必须逐台对照手册配置。
Modbus TCP 把同样的 PDU 封装进 TCP/IP，去掉了从站地址和 CRC，改为 7 字节的 MBAP 报文头（事务标识、协议标识、长度、单元标识），默认端口 502。同样的读寄存器请求变为：
00 01 00 00 00 06 01 03 00 00 00 02
└─┬─┘ └─┬─┘ └─┬─┘ │ └──────────┬──────────┘
│ │ │ │ └─ PDU：功能码03 + 地址 + 数量
│ │ │ └─ 单元标识（网关后接串口设备时使用）
│ │ └─ 后续字节数 = 6
│ └─ 协议标识 0x0000 表示 Modbus
└─ 事务标识，用于匹配请求与应答Modbus TCP 适合数采仪通过厂区以太网、光纤或 4G 路由直接访问带网口的仪表、PLC 或数据网关，速率和并发能力远高于 RTU，但同样存在“只有数据、没有语义”的问题：平台收到的只是一串寄存器值，需要数采仪按点位表换算成“COD = 35.6 mg/L”这样的工程值。
二、平台侧通信：HJ 212 与 MQTT
HJ 212 是我国污染源在线监控系统（工况、废水、废气）数据传输的行业标准协议，属于“应用层语义已经定义好”的协议。它规定了数据采集仪与监控平台之间的报文结构：以 ## 开头、以 && 结尾，字段之间用 ; 分隔，包含系统编码、命令编码、设备唯一标识（MN）、密码、指令参数和数据区。例如数采仪上传一组污染物小时均值时，报文骨架为：
##0123QN=20240615103000001;ST=32;CN=2051;PW=123456;
MN=3101ABCD1234;CP=&&DataTime=20240615103000;
w01018-Avg=35.6,w01018-Flag=N;w21003-Avg=7.12,w21003-Flag=N&&其中 CN=2051 表示上传污染物分钟/小时数据，w01018 是 COD 的污染物编码，-Avg 为均值、-Flag 为数据标记（N 表示正常）。HJ 212 的强项在于“平台一看就懂”：污染物编码、时间、标记、设备身份都是标准字段，便于环保部门统一接收、审核和执法。它的不足是报文为文本、体积较大，且标准主要面向“数采仪主动上报/平台下发命令”的固定交互模式，扩展新业务不如通用物联网协议灵活。
MQTT 是发布/订阅模式的轻量级消息协议，基于 TCP，采用主题（Topic）寻址和 QoS 等级保证。数采仪作为客户端连接 Broker，把数据发布到如 hb/site/3101ABCD1234/water/cod 这样的主题，平台订阅对应主题即可接收。报文由固定头、可变头和载荷组成，载荷可以是 JSON：
{"mn":"3101ABCD1234","ts":"2024-06-15T10:30:00+08:00",
"cod":35.6,"codFlag":"N","nh3n":7.12,"nh3nFlag":"N"}MQTT 的优势是连接复用、断线重连、QoS1 至少一次送达、支持海量设备与双向下发，非常适合设备数量多、网络不稳定、需要远程配置和固件升级的场景；代价是主题规划、载荷格式、数据标记规则都需要项目自行约定，若要与环保监管平台对接，通常还要在平台侧做一次到 HJ 212 的转换。
三、四种协议的适用场景对比
| 协议 | 通信模型 | 典型位置 | 报文特征 | 适用场景 |
|---|---|---|---|---|
| Modbus RTU | 主从轮询，串行 | 数采仪 ↔ 仪表 | 二进制，地址+功能码+数据+CRC16 | 485 总线挂多台分析仪，点位少、速率要求低 |
| Modbus TCP | 主从请求，TCP | 数采仪 ↔ 网口仪表/PLC | MBAP 头 + PDU，端口 502 | 厂区以太网、光纤接入，采集频率较高 |
| HJ 212 | 上报/命令交互 | 数采仪 ↔ 环保监控平台 | 文本，##…&&，字段用 ; 分隔 | 向环保部门上传污染物数据、接收反控命令 |
| MQTT | 发布/订阅，TCP | 数采仪 ↔ 物联网平台 | 固定头+主题+JSON 载荷，QoS 分级 | 设备量大、网络不稳、需远程配置与升级 |
四、工程配置中的关键判断
实际项目中，数采仪往往同时承担两种角色：向下用 Modbus 采集，向上用 HJ 212 或 MQTT 上报。配置时最容易出问题的不是协议本身，而是“语义对齐”。以一台 COD 分析仪为例，手册给出测量值寄存器 0x0000 为 32 位浮点数、单位 mg/L、字节序为 CDAB，而数采仪默认按 ABCD 解析，结果就会得到完全错误的数量级。此时应在数采仪的点位表中显式设置数据类型为 float32、字节序为 CDAB，并在现场用已知浓度的标准液或仪表显示值做一次比对，确认换算后的工程值与仪表面板一致，再允许数据进入上报队列。
向上对接时，若平台要求 HJ 212，需要重点核对 MN 设备唯一标识、污染物编码（如 w01018 对应 COD）、数据标记（N 正常、F 故障、M 维护等）以及上报时间戳格式；若平台采用 MQTT，则要提前规划主题层级，把站点编号、设备类型、监测因子放进主题，把时间、数值、标记放进 JSON 载荷，并约定 QoS 等级和离线缓存策略。无论选哪种协议，都建议在数采仪中保留本地缓存，网络中断期间数据不丢，恢复后按时间顺序补传，避免平台侧出现数据缺口。