串口到 TCP 透明传输与协议转换：你的设备需要哪一种？
当主机软件仍将使用设备现有的串口协议时，选择串口到 TCP 透明传输网关。当主机需要不同的应用协议，例如需要 Modbus TCP 而不是 Modbus RTU 时，选择协议转换。前者传输字节，后者解析并重新构建消息。
应先做出这一决定，再选择硬件。“RS485 转以太网”描述的是接口，并不能证明两端软件相互兼容。成功的设计还必须考虑消息分帧、总线控制权、重试和安全。
透明串口网关实际做了什么
在原始透明模式下，网关通过 TCP 连接转发串口有效载荷字节，并将收到的 TCP 有效载荷字节写入串口。设备命令、校验和、响应解析以及命令含义仍由应用程序负责。请核查所选模式：虚拟 COM 或串口控制模式可能增加各自的协商机制，并要求主机软件与之配套。
对于专有二进制协议，或能够使用受支持的虚拟 COM 驱动程序的现有串口应用，这是一个有用的切入点。请确认应用是否依赖调制解调器控制信号、BREAK、精确时序或本地串口驱动程序行为。仅传输普通数据字节的网关未必能复现这些功能。
例如，如果仪器使用已有文档说明的长度前缀命令，主机可以持续累积 TCP 字节，直到收到完整的命令响应。此时无需寄存器映射，但主机仍需要该仪器协议的解析器。
TCP 传输不会保留串口消息边界
TCP 提供可靠、有序的字节流。接收方一次读取可能只得到一条应用消息的一部分，也可能同时得到多条消息。TCP 报文段和套接字读取结果并不对应应用层记录。这符合 RFC 9293 的传输模型。
示意示例：设备发送两条八字节消息 A 和 B。接收应用可能先读取 A 的前五个字节，再读取 A 剩余的三个字节以及 B 的全部八个字节。这些读取边界仅用于举例，并非对网络行为的预测。解析器必须缓存不完整的数据，并利用协议的长度、分隔符或其他分帧规则提取完整消息。
串口时序需要单独处理。Modbus RTU 通过静默间隔分隔帧，并规定了字符间时序要求；串行链路规范第 2.5.1.1 节定义了这些要求，其中也包括较高波特率下的定时器建议。UART 的起始位、奇偶校验位和停止位同样不是普通的 TCP 有效载荷字节。
不要假设网络数据到达的间隔会复现串口静默间隔。网关需要适当的缓存和串口发送规则。仅有分包超时设置，并不能证明 RTU 帧在串口输出端仍会保持完整。应测试分段输入、延迟到达的字节以及连续紧接的请求。
通过隧道传输 Modbus RTU 不等于 Modbus TCP
Modbus TCP 请求包含七字节 MBAP 头和协议数据单元（PDU）。Modbus RTU 则包含串口地址、PDU 和 CRC。透明隧道可以在 TCP 内传输完整的 RTU 字节，包括 CRC，但标准 Modbus TCP 客户端要求 MBAP 格式。
协议转换网关解析 MBAP，将单元标识符（Unit Identifier）路由到配置的串口目标，构建 RTU 请求，校验响应 CRC，并将回复与原始 TCP 事务关联。MBAP 长度字段用于消息解析，事务标识符用于请求和响应配对。参见 Modbus TCP/IP 实施指南第 3.1.2–3.1.3 节。
为说明原理而构造的完整示例：从串口设备 7 读取两个保持寄存器，起始协议地址为零。功能码 03 和从零开始的协议地址遵循 Modbus 应用协议规范第 4.4 和 6.3 节。这些字节用于演示编码，并非 Obeita 产品测试数据，也不是实际设备的寄存器映射。
- 请求 PDU：
03 00 00 00 02。 - Modbus TCP 请求：
00 2A 00 00 00 06 07 03 00 00 00 02。事务 ID 为002A；长度0006包含单元标识符和五个 PDU 字节。 - 对应的 RTU 请求：
07 03 00 00 00 02 C4 6D。计算得到的 CRC 先发送低字节。
本示例中的 PDU 保持不变。转换传输帧格式不会自动转换专有命令集、推断缩放关系或确定跨多个寄存器的数据顺序。这些需求必须通过明确的映射来实现。
明确串口总线控制权和重试策略
Modbus 串行链路模型允许一个发起通信的主站，且同一时刻只处理一个事务。增加以太网客户端不会增加串口的并发处理能力。如果多个主机需要访问，必须提供有文档说明的调度机制、队列限制、超时处理和响应路由。没有经过工程设计的仲裁机制时，不要在同一总线上接入另一个主动轮询的主站。
应明确以下情况如何处理：排队的请求过期、客户端断开连接，或串口响应迟到。接受多个套接字连接的透明服务器需要明确的控制权规则；仅能接受连接，并不能证明多客户端运行安全。
故障场景：设备执行了一次写操作，但回复在到达客户端前丢失。应用重试可能导致该写操作再次执行。连接内的 TCP 重传与再次发送应用请求是不同的机制。Modbus 事务标识符本身并不能保证持久的重复请求抑制。
应根据命令的作用进行分类。重复设置一个设定值可能是可接受的，而重复执行启动工作循环的命令则未必安全。对于可能造成重要后果的写操作，应定义设备支持的序列检查、状态核对或操作员恢复流程，而不是无条件重试。
明确部署的安全边界
普通 TCP 和传统 Modbus TCP 都不会原生提供经过加密和身份验证的应用访问。请确认所选网关和客户端实际支持的能力。Modbus Security 规定了 TLS 和基于证书的身份验证；两端都必须支持，并需规划证书配置与续期。
部署检查清单应包括：仅允许获准系统访问网关、隔离控制网络、保护管理访问，以及避免直接暴露在公共互联网。获准使用的 VPN 或安全网关可以保护网络路径，但其余本地网段和设备授权仍需审查。加密本身不会决定哪个已通过身份验证的客户端可以发出写操作。
实用的选型与验收检查清单
- 识别两端协议。记录设备输出和主机接受的内容：原始串口字节、RTU-over-TCP、Modbus TCP 或其他有文档说明的格式。
- 检查电气前提条件。按照安装要求，确认 RS232 或 RS485、两线或四线接线、引脚定义、波特率、奇偶校验、停止位、接地、隔离、终端匹配和偏置。
- 明确分帧责任。指定负责组装消息并满足串口时序要求的组件，包括最大帧长度和输入格式错误时的处理行为。
- 规定访问与恢复机制。定义总线控制权、并发客户端行为、命令权限、超时、队列限制、重连处理及安全的写操作重试。
- 验证困难场景。使用台架环境测试不完整及合并的 TCP 读取、设备缺失、回复迟到、重连、队列饱和以及访问被拒绝的情况。测试前应确定通过标准。
当两端协议已经兼容且能够可靠处理分帧时，选择透明转发。当主机要求不同的消息格式或明确的数据模型时，选择协议转换。如果任一端缺乏文档，应先收集证据，再确定网关架构。
为与 Obeita 沟通准备网关需求
为了与 Obeita 进行有针对性的技术讨论，请准备经脱敏处理的设备手册、具有代表性的请求和响应帧、串口设置、主机协议、设备数量、时序要求以及预期故障处理行为。请删除凭据、客户标识符和保密工艺数据。这些资料有助于评估所需的传输、转换和验证工作。
如需了解相关集成工作，可查看 Obeita 的传统设备联网服务以及已交付的串口转以太网与蜂窝 DTU 适配项目。如需讨论设备与主机协议，请联系 Obeita。
