一种高效快速的MODBUS串行总线数据轮询协议

• 背景

  ---

  串行总线（RS485）由于其非平衡传输特性的限制，广泛应用主从MODBUS RTU（ASCII）协议。主从协议严格遵循请求应答机制，尤其在主机向总线中各从机查询数据时，需要逐个设备节点、逐片寄存器发起请求。实际应用中称之为MODBUS总线数据轮询，在多设备多数据场景下，无法保证数据实时性。

 

 

• 问题分析

  ---

  产生的数据更新延时主要源于两方面原因：交互次数多和冗余的上报数据。

交互次数与从机个数、MODBUS数据定义个数正相关，同时存在由于MODBUS数据地址不连续，需要增加交互次数的情形。

遍历轮询方式触发从机上报所有请求中包含的数据，必然导致从机响应报文中携带长期未变化的数据，这类数据即为冗余上报数据。

 

• 前置需求

---

问题要解决，但解决方案也要有边界。

1. 支持半双工（RS485）通信方式；
2. 不脱离MODBUS协议规范，包括报文格式、主从应答流程、设备地址、CRC、最大帧长限制等；
3. 不改变且复用已有协议数据（寄存器）定义方式；

 

• 设计方案

  ---

  总体流程

 

• 报文格式

---

相关流程统一采用自定义报文格式（请求、应答），遵循如下定义：

字段		长度	备注
设备地址		1 Byte
功能码		1 Byte	0X65 （自定义区间）
PDU	子功能码	1 Byte
	数据长度	2 Bytes	N
	数据域	N Bytes
CRC		2 Bytes

MODBUS-RTU模式下，单帧最大长度256Bytes。

MODBUS-TCP模式下，单帧最大长度根据MTU规格制定，建议1300Bytes。

PDU中各字段采用大端字节序传输。

       异常响应报文与MODBUS协议定义一致：

字段	长度	备注
设备地址	1 Byte
功能码	1 Byte	0XE5
预留	2 Byte	0
CRC	2 Bytes

 

 

• 订阅

  ---

  从机提供一套默认增量上传的寄存器列表，如果未收到注册请求，在默认寄存器列表范围内进行上报。从机收到注册请求后，本地持久化存储订阅的寄存器信息；主机识别设备通讯重新建链、主机启动后，重新发送订阅信息；订阅流程作为版本兼容性要求的预设流程，主机可暂不支持；寄存器单元的划分：订阅目标数据的地址连续优先放在同一个单元，地址前后独立的数据单独一个单元。订阅请求支持广播方式。

• 请求PDU：

字段		长度	备注
子功能码		1 Byte	0X01
数据长度		2 Bytes	N
上报周期		2 Bytes	单位秒； 0：单播请求，主机请求触发增量上传； > 0：从机主动按周期增量上传，适用于MODBUS-TCP场景；
订阅类型		2 Bytes	0：全量订阅，从机将订阅信息替换已有的寄存器列表； 1：增量订阅1，基于订阅列表增量； 2：增量订阅2，基于默认寄存器列表增量；
预留		2 Bytes
寄存器单元个数		2 Bytes	≤ 80 0：注销所有订阅信息；
单元1	寄存器地址	2 Bytes
	寄存器个数	1 Byte
单元…	寄存器地址	2 Bytes
	寄存器个数	1 Byte

响应PDU：

字段	长度	备注
子功能码	1 Byte	0X01
数据长度	2 Bytes	2
订阅注册结果	2 Bytes	0：成功； 1：失败；

 

• 总召

---

从机收到总召请求后，被订阅数据要求全部置为变化态，总召响应立即给出数据回复，所以总召响应PDU与增量上传的响应PDU一致；从机接收总召后，帧序号检测重置，以总召中设定的序号开始检测跳包、重发问题。

主机发起总召的场景：

1. 主机系统初始化；

2. 设备断链过程中；

3. 增量请求返回异常；

4. 设备升级结束；

5. 周期60分钟；

 

请求PDU：

字段	长度	备注
子功能码	1 Byte	0X02
数据长度	2 Bytes	4
帧序号	2 Bytes	0
总召类型	2 Bytes	0：全部总召 1：（预留） 2：（预留）

 

•  增量上传

  ---

  从机本地识别前后两次增量上传请求之间数据的是否发生变化，就近一次增量上传所填充的内容仅为变化寄存器。从机识别请求帧序号是否出现跳变、重发；跳变后回复异常（0XE5），重发则回复上一帧数据；帧序号由0XFFFF翻转为0时，视为正常递增；从机保证关键数据、逻辑相关联数据优先上报，放在第一帧内回复；寄存器单元拼接时，间隔寄存器个数为1，作为同一个单元上报，间隔寄存器上报当前值或无效值。间隔寄存器个数超过1，则另起新的寄存器单元。从机重启后，可能直接收到增量上传请求，此时根据本地存储的订阅信息，全量上报一次。主机运行过程中，总线上通过单播方式，连续向各从机发起增量上传请求，单个从机回复有其它变化数据时，主机连续向该从机发起请求，直至变化数据请求完毕，连续请求最大次数10。主机对每个从机单独维护帧序号，确保帧序号逐1递增。从机连续3次超时后，主机以总召请求维持链接请求。

请求PDU：

字段	长度	备注
子功能码	1 Byte	0X03
数据长度	2 Bytes	2
请求帧序号	2 Bytes	延续总召序号，逐1递增；

响应PDU：

字段		长度	备注
子功能码		1 Byte	0X03
数据长度		2 Bytes	N
回复帧序号		2 Bytes	回填请求帧序号
预留		2 Bytes
寄存器单元个数		2 Bytes	最高位置1代表，还有其它变化数据。 无变化数据时，单元个数为0，无其它字节数据。
单元1	寄存器地址	2 Bytes
	寄存器个数	1 Byte
	数据	N Bytes
单元…	寄存器地址	2 Bytes
	寄存器个数	1 Byte
	数据	N Bytes

 

• 幅值控制

  ---

  幅值控制策略仅面向采样测点数据，状态量、参数、特征信息不做控制，有变化即上报。幅值控制主要是解决由于采样误差导致的无用数值波动。如下情况不受幅值控制影响：

1. 数据归0

2. 数据从0跳变为非0

3. 正负翻转

 

• 效果确认

  ---

  经过实际测试，采用这种增量数据上报方式实现的MODBUS总线轮询方案，数据更新延时明显降低：

• 方案	总线规格	延时
  传统轮询方案	30台从机 100个输入寄存器 总线波特率9600bps	> 9秒
  增量上报轮询方案		< 3秒