多个客户端共用一个Modbus网关：怎样验收轮询时延和超时隔离

多个TCP连接不会让同一条RS485总线同时执行多个Modbus RTU事务。网关可能很快接受请求，串口队列却持续积压。容量验收需要把客户端截止期、串口服务时间、事务归属和故障隔离关联起来。本文提供测量方法及明确标注的计算示例，没有给出任何网关的实测容量。

列出客户端与串口设备的真实负载

为每个客户端和请求类别建立负载记录：目标端口与设备、功能码、起始地址、寄存器数量、轮询周期、突发模式、超时与重试策略。维护时临时接入的工程软件、本地HMI也要纳入。同样标称“一秒轮询”，如果多个客户端在同一时刻启动，就可能形成集中突发。

直接转发与网关自主采集后缓存应答要分开。后者TCP响应很快，也可能给出很久之前的数据，因此必须规定采集时间戳、最大数据年龄和采集失败后的表示方式。界面刷新目标与控制截止期也不能混用。设备处理时间应来自实际组合的文档和测试，不能仅从型号或波特率推断。

单次请求预算包含发送字节占线、设备处理、响应字节占线、RS485方向切换与必要帧间隔，再单独加上排队和重试。目标RTU时序应参照Modbus串口实现指南V1.02，并在所选波特率下检查实现实际如何处理间隔。透传与协议转换不能默认采用同一套成帧假设。

构造演算：功能码03读取十个寄存器，请求为8个RTU字节，正常响应为25字节。19,200 bit/s、8E1格式下，每字符传输11位，所以仅字节占线时间为(8+25)×11/19,200，约18.9毫秒。该数字尚未包含设备处理、间隔、排队、错误与软件开销，不能直接换算成承诺轮询频率。

初筛可以累加每类到达速率与服务时间的乘积。端口利用率接近满载后，留给突发与异常的空间很小；即使计算结果低于1，也不能证明截止期满足。设备静默时消耗的是超时与恢复窗口，而不是正常成功事务的时间。

每条事务记录应包含连接代次、事务号、目标单元、串口、功能码和请求序号。16位Modbus事务号不是跨客户端或跨时间的全局唯一标识，两个客户端可以使用同一个数字。网关必须保留足够上下文，将响应送回正确请求方；这一职责可参照Modbus TCP实现指南V1.0b。

测试应包含不同连接使用相同事务号、重连后复用事务号以及超时后的迟到响应。RTU没有TCP事务字段，相似请求连续出现时，迟到响应可能难以区分。设计需要结合设备最迟响应时间制定有界重同步或隔离窗口，不能将下一帧盲目分配给最新请求。设备可能任意迟到时，应公开剩余歧义，不能宣称永远不会串事务。

让一台设备变慢或静默，其他客户端保持正常负载。分别观察同端口健康设备和另一个端口的影响。共享串口在等待当前请求超时时确实会损失时间，隔离目标是限制和控制损害，不能承诺同一总线上完全零影响。

检查每客户端队列上限、公平调度、请求过期、过载拒绝，以及长期离线设备的降频策略。已经失去时效的排队读取不应继续浪费总线。多个串口理论上可并行，但全局工作任务或锁也可能把它们绑在一起。Moxa的架构说明提示了排队问题，具体通过条件仍应从目标设备和业务负载推导。

有文档保证无副作用的读取，可以考虑跳过过期样本，在下一轮重新获取，同时明确旧值如何标记。写命令应另行处理：响应丢失时，即使网关报告超时，设备也可能已经执行。重复启动、计数或脉冲操作可能产生重复物理效果，增加重试次数不是通用修复。

协调主机与网关预算。如果主机在旧请求还排队时就超时重发，旧请求随后仍可能到达设备。实现支持时，应采用明确的过期和取消语义。libmodbus响应超时说明还区分字节超时启用与禁用的行为；本文没有库API示例，实际设置需按部署版本验证。中断后的写恢复可参照重连与结果未知命令处理。

从一个客户端、一台健康设备开始，先分别增加请求频率、长度和客户端数量，再组合成声明的生产负载。每一级记录持续运行结果，然后加入突发、缺失设备、高频客户端和重连。队列满与设备正常异常响应同样需要覆盖。故障注入只能在获准的隔离系统执行。

容量结论必须带条件：硬件、固件、串口、波特率、设备组合、请求分布、客户端行为和持续时间。报告时延分布、最差观察值、超时率、队列峰值、拒绝数量与数据年龄。容量曲线应保留失败负载点，只展示最后一个通过点会隐藏过载边界。

最差观察值不等于形式最坏上界，平均值也可能掩盖截止期失败。保留原始抓包、时钟对齐方法和流量生成配置，使另一位工程师可以复现；数值含义仍需通过寄存器映射校验。需要制定网关验收方案时，可向Obeita提供客户端刷新目标、串口设备清单、读写比例及降级服务限制。