2、Modbus协议基础：RTU与TCP的帧格式、地址模型、功能码分类及典型应用场景
Modbus协议自1979年由Modicon（现施耐德电气）推出以来，凭借其开放、简单、可靠的特点，已成为工业自动化领域应用最广泛的通信协议之一。在驱动层开发中，理解Modbus的帧格式、地址模型与功能码语义，是正确实现收发逻辑、异常处理与数据映射的前提。本章将围绕RTU与TCP两种主流传输模式，深入剖析其帧结构差异、地址空间设计、功能码分类及典型工程场景，为后续驱动代码实现奠定协议基础。
2.1 RTU与TCP的帧格式对比
2.1.1 核心原理
Modbus RTU（Remote Terminal Unit）采用二进制编码，通过串行链路（RS-232/485）传输，帧结构紧凑，每个字节包含8位数据位、1位起始位、1位停止位（可选校验位）。RTU帧的最大特点是以时间间隔（通常为3.5个字符时间）作为帧起始与结束的判定依据，因此驱动层必须实现精确的定时器逻辑。而Modbus TCP基于以太网，将RTU帧中的设备地址和CRC校验替换为MBAP头（Modbus Application Protocol Header），利用TCP/IP的可靠传输保证数据完整性。
| 帧字段 | RTU（字节数） | TCP（字节数） | 说明 |
|---|---|---|---|
| 事务标识符 | - | 2 | 用于匹配请求与响应 |
| 协议标识符 | - | 2 | 固定为0x0000 |
| 长度字段 | - | 2 | 后续字节数 |
| 单元标识符 | 1（从站地址） | 1 | RTU中为从站地址，TCP中为单元号 |
| 功能码 | 1 | 1 | 如03读保持寄存器 |
| 数据字段 | N | N | 寄存器地址、数量、数据值等 |
| 校验 | 2（CRC16） | - | TCP依赖TCP/IP校验 |
2.1.2 判断方法与操作流程
驱动层在接收RTU帧时，需要维护一个字节缓冲区，并持续监测字节间隔。当检测到超过3.5个字符时间的静默期，即认为一帧结束。具体流程为：
- 初始化串口参数（波特率、数据位、停止位、校验位），并启动定时器。
- 每收到一个字节，重置定时器并追加到缓冲区。
- 若定时器超时（3.5字符时间），则对缓冲区进行CRC校验。
- CRC校验通过后，解析功能码和数据字段；否则丢弃该帧并记录错误。
对于TCP模式，驱动层只需从Socket流中读取6字节MBAP头，解析长度字段，再读取后续指定长度的数据即可，无需考虑帧定界问题。
2.1.3 案例拆解：RTU帧解析实战
假设某温度采集模块从站地址为0x11，上位机发送读取保持寄存器请求：11 03 00 6B 00 03 A7 6E。其中11为从站地址，03为功能码，00 6B为起始寄存器地址（107），00 03为读取数量（3个寄存器），A7 6E为CRC16校验值。从站响应帧为：11 03 06 02 2B 00 64 00 7F 9A 5C，其中06表示后续数据字节数，随后是3个寄存器值（0x022B、0x0064、0x007F）。驱动层需将原始字节按大端序转换为16位无符号整数，并映射到温度工程值。
关键点：RTU帧中所有多字节字段均采用大端序（高字节在前），驱动层在解析时需注意字节序转换，避免因大小端不匹配导致数据错误。
2.1.4 常见误区与总结
- 误区一：将RTU的3.5字符时间误算为固定毫秒值。实际上该时间与波特率相关，例如9600bps下约4ms，115200bps下约0.4ms。
- 误区二：在TCP实现中仍计算CRC。TCP/IP协议栈已保证数据完整性，额外计算CRC浪费CPU且无实际收益。
- 误区三：忽略TCP的单元标识符与RTU从站地址的映射关系。在网关设备中，需将TCP单元号映射到RTU从站地址。
2.2 地址模型与数据映射
2.2.1 核心原理
Modbus协议定义了四种数据对象类型，分别对应不同的功能码和地址空间。驱动层需要建立协议地址与设备内部存储区的映射关系，才能正确读写数据。四种对象包括：线圈（Coil）、离散输入（Discrete Input）、输入寄存器（Input Register）、保持寄存器（Holding Register）。其中线圈和保持寄存器可读写，离散输入和输入寄存器只读。
| 数据对象 | 地址范围 | 位/字 | 读写属性 | 对应功能码 |
|---|---|---|---|---|
| 线圈 | 0x0000-0xFFFF | 位 | 读写 | 01读、05写单、15写多 |
| 离散输入 | 0x0000-0xFFFF | 位 | 只读 | 02读 |
| 输入寄存器 | 0x0000-0xFFFF | 16位字 | 只读 | 04读 |
| 保持寄存器 | 0x0000-0xFFFF | 16位字 | 读写 | 03读、06写单、16写多 |
2.2.2 地址映射策略
在实际驱动开发中，通常采用两种映射方式：静态映射表和动态计算。静态映射表适用于设备寄存器地址固定的场景，驱动层维护一张表，将协议地址映射到内存变量指针；动态计算则适用于地址连续的寄存器块，通过基址加偏移量直接访问内存数组。例如，某变频器的运行频率寄存器地址为0x2000，驱动层可定义uint16_t freq_reg;，并在初始化时将0x2000映射到&freq_reg。
2.2.3 案例拆解：PLC与IO模块的地址映射
某PLC通过Modbus RTU连接远程IO模块，IO模块提供16路数字输入和8路模拟输入。驱动层设计如下：
- 数字输入映射到离散输入区，地址0x0000-0x000F，对应16个布尔变量。
- 模拟输入映射到输入寄存器区，地址0x0000-0x0007，对应8个16位无符号整数。
- PLC侧通过功能码02和04分别周期读取数字量和模拟量。
驱动层在收到读请求时，根据功能码和起始地址，从对应的内存区域拷贝数据并组装响应帧。若请求地址超出映射范围，则返回异常码0x02（非法数据地址）。
风险提示：地址映射表必须与设备手册严格核对，尤其是第三方设备可能存在地址偏移或字节序差异。建议在驱动初始化阶段执行一次读操作验证映射正确性。
2.2.4 常见误区与总结
- 误区一：混淆协议地址与物理地址。协议地址是逻辑地址，物理地址是设备内部存储位置，两者通过映射表关联。
- 误区二：忽略地址边界检查。当请求读取的地址范围跨越映射表边界时，应返回异常而非越界访问。
- 误区三：未处理寄存器值的数据类型转换。例如，32位浮点数在Modbus中通常占用两个连续寄存器，驱动层需按特定顺序组合。
2.3 功能码分类与语义详解
2.3.1 核心原理
功能码是Modbus协议的操作指令，驱动层根据功能码决定执行何种操作。功能码分为三类：位操作（01、02、05、15）、字操作（03、04、06、16）和异常响应（0x80+功能码）。每个功能码都有严格的请求/响应帧格式，驱动层必须精确解析和构造。
2.3.2 功能码详细说明
| 功能码 | 名称 | 请求帧数据 | 响应帧数据 | 典型应用 |
|---|---|---|---|---|
| 01 | 读线圈 | 起始地址(2B)+数量(2B) | 字节数(1B)+位数据(NB) | 读取继电器状态 |
| 02 | 读离散输入 | 起始地址(2B)+数量(2B) | 字节数(1B)+位数据(NB) | 读取传感器开关量 |
| 03 | 读保持寄存器 | 起始地址(2B)+数量(2B) | 字节数(1B)+寄存器值(2N B) | 读取设定参数 |
| 04 | 读输入寄存器 | 起始地址(2B)+数量(2B) | 字节数(1B)+寄存器值(2N B) | 读取测量值 |
| 05 | 写单线圈 | 线圈地址(2B)+值(2B) | 原请求回显 | 控制单路开关 |
| 06 | 写单寄存器 | 寄存器地址(2B)+值(2B) | 原请求回显 | 修改单个参数 |
| 15 | 写多线圈 | 起始地址(2B)+数量(2B)+字节数(1B)+位数据(NB) | 起始地址(2B)+数量(2B) | 批量控制输出 |
| 16 | 写多寄存器 | 起始地址(2B)+数量(2B)+字节数(1B)+寄存器值(2N B) | 起始地址(2B)+数量(2B) | 批量设置参数 |
2.3.3 案例拆解：使用功能码16批量配置变频器参数
某变频器需要同时设置加速时间（寄存器0x1000）和减速时间（寄存器0x1001），上位机发送功能码16请求：01 10 10 00 00 02 04 00 0A 00 14 8B 3A。其中01为从站地址，10为功能码16，10 00为起始地址，00 02为寄存器数量，04为数据字节数，00 0A（10秒）和00 14（20秒）为参数值。变频器响应：01 10 10 00 00 02 41 C8，回显起始地址和数量，表示写入成功。
经验提示：功能码05和06的请求帧中，值字段有特殊约定：线圈ON为0xFF00，OFF为0x0000；寄存器值直接使用16位整数。驱动层在构造请求时需严格遵守，否则设备可能拒绝执行。
2.3.4 常见误区与总结
- 误区一：混淆功能码05和15的帧格式。05写单线圈的值字段为2字节，而15写多线圈的值字段为位压缩数据。
- 误区二：未处理异常响应。当设备返回异常码（如0x83表示功能码03异常），驱动层应解析异常码并向上层报告具体错误原因。
- 误区三：忽略功能码的扩展。部分设备支持自定义功能码（如0x64），驱动层需预留扩展接口。
2.4 典型应用场景与选型建议
2.4.1 场景分类
Modbus协议在工业现场的应用可归纳为四类典型场景：PLC与远程IO通信、仪表数据采集、变频器/伺服控制、楼宇自控系统。不同场景对实时性、数据量和可靠性要求不同，驱动层设计需针对性调整。
2.4.2 场景对比分析
| 场景 | 推荐模式 | 典型功能码 | 实时性要求 | 驱动层关注点 |
|---|---|---|---|---|
| PLC-远程IO | RTU（RS-485） | 01、02、03、04 | 中（10-100ms） | 地址映射、批量读写 |
| 仪表采集 | RTU或TCP | 03、04 | 低（秒级） | 超时重试、数据缓存 |
| 变频器控制 | RTU（RS-485） | 03、06、16 | 高（<10ms） | 写操作可靠性、异常处理 |
| 楼宇自控 | TCP（以太网） | 01、03、05、06 | 低（秒级） | 多客户端并发、连接管理 |
2.4.3 案例拆解：楼宇自控系统采用Modbus TCP
某楼宇自控项目需要监控200个传感器和50个执行器，采用Modbus TCP组网。驱动层设计要点：
- 使用TCP长连接，每个从站设备建立独立Socket连接，并设置KeepAlive机制。
- 采用线程池处理多个设备的并发请求，每个设备一个工作线程。
- 对于传感器数据，采用周期轮询（1秒间隔）并缓存最新值；对于执行器控制，采用即时写操作并等待响应确认。
- 当某个设备连接断开时，驱动层自动重连并恢复数据同步。
该方案实现了200个数据点的实时监控，控制指令响应时间小于100ms，满足楼宇自控的工程要求。
工程提醒：在RTU多从站组网时，需注意RS-485总线的终端电阻和偏置电阻配置，否则可能导致通信不稳定。驱动层应支持总线冲突检测和重发机制。
2.4.4 常见误区与总结
- 误区一：在RTU网络中盲目提高波特率。虽然115200bps可提高吞吐量，但会缩短帧间隔时间，增加定时器误判风险。
- 误区二：忽略TCP的粘包/拆包问题。驱动层必须基于MBAP头长度字段进行完整帧读取，不能依赖TCP流边界。
- 误区三：未考虑跨平台字节序差异。在x86（小端）与ARM（可配置）混合组网时，需统一使用大端序。