Serial Device Server or Modbus Gateway? Start with the Host Protocol and Existing Wiring
A serial device server is a good candidate when the host already understands the device’s serial protocol and only needs a network path. A Modbus gateway is the candidate when a native Modbus TCP client must communicate with Modbus RTU devices. Before comparing products, establish the host driver, the bytes on each side, and who owns the serial bus. The checks below are a design and compatibility procedure, not a benchmark of a particular gateway.
Identify the Host Protocol First
Start at the SCADA, PLC, or maintenance application. Record its exact driver name and supported transport: a local COM port, a vendor virtual COM port, a raw TCP socket carrying serial frames, or native Modbus TCP. Also record the operating system and driver version. A Windows-only virtual COM utility may preserve an existing application but create a deployment problem on a Linux host or locked-down industrial PC.
Ask for a known-good request and response, rather than accepting a checkbox labelled “Modbus.” List baud rate, parity, stop bits, physical interface, device address, and whether the application issues writes. A connector marked RS485-to-Ethernet says little about the payload. If the host cannot change drivers, its present interface becomes a procurement requirement; if it can, compare the cost of a driver change with maintaining a proprietary network wrapper.
Understand What Transparent Transport Preserves
A transparent bridge forwards serial data through a TCP connection without necessarily interpreting device addresses or function codes. That can suit a proprietary instrument protocol just as well as Modbus RTU. Nevertheless, transparency has boundaries: buffering, flow control, RS485 direction timing, and network outages all affect when bytes reach the receiver. Verify which serial settings can be changed remotely and which are fixed locally.
TCP carries an ordered byte stream. One application send, one TCP packet, and one receiving read do not share a guaranteed boundary. The host must reconstruct its protocol messages from lengths, delimiters, or another defined parser. A device server’s idle-gap packetization can influence latency, but does not turn TCP into a message transport. Test a request delivered in fragments and two requests delivered together. This transport property is defined in RFC 9293, sections 2.2 and 3.7.
Distinguish RTU-over-TCP from Modbus TCP
For a constructed example, consider unit 1 reading two holding registers beginning at protocol address zero, function 03. The serial RTU request is 01 03 00 00 00 02 C4 0B; its final two bytes are the RTU CRC, low byte first. A raw RTU-over-TCP implementation might carry those same eight bytes, but the name alone does not specify every vendor’s framing convention.
The corresponding Modbus TCP example is 00 2A 00 00 00 06 01 03 00 00 00 02. Its seven-byte MBAP header contains transaction 0x002A, protocol 0, length 6, and unit 1. Length counts the unit identifier plus the PDU; no RTU CRC follows. The Modbus TCP implementation guide V1.0b, section 3.1 defines this distinction. These are constructed protocol bytes, not a captured device exchange.
List the Gateway Conversion Responsibilities
A converting gateway must validate the incoming request, resolve its serial port and target unit, arrange access to that serial bus, and associate the eventual response with the requesting TCP connection and transaction. Its timeout behavior matters as much as its happy path. Check the documented handling of an unavailable route, a silent device, malformed input, and a valid Modbus exception response.
Preserve the distinction between a device exception and a gateway transport failure in diagnostics. Do not fabricate a successful register value when a request fails. Also check whether the gateway forwards function codes transparently or supports only a declared subset. Converting RTU framing to TCP framing does not itself define register scaling, multi-register word order, timestamps, or MQTT topics. Those belong to the separate register mapping and data interpretation work.
Review Existing HMI and Serial Topology
Draw the existing local HMI before adding remote clients. An ordinary Modbus RTU segment has one initiator coordinating requests. Connecting a second independent serial master to the same wires does not create a scheduler; collisions and ambiguous replies can follow. Moving both consumers upstream of a gateway may be possible, but only if their supported interfaces and the gateway’s arbitration fit.
Some products provide special routing or redirection modes for retaining legacy serial controllers. Treat those as model-specific capabilities and validate the actual direction of every connection. Moxa’s architecture discussion is useful for identifying these choices, not for assigning its product limits to every gateway. Keep termination, biasing, isolation, cable topology, and grounding in the wiring review. A correct protocol setting cannot compensate for an electrically unreliable bus.
Shortlist Products with a Decision Table
Separate mandatory compatibility from optional convenience. Reject a candidate when a required driver or function is missing, even if its advertised connection count looks attractive. Multiple sockets can still feed one serialized RS485 path. For the follow-on capacity work, use the multi-client latency and timeout acceptance procedure.
| Observed requirement | Candidate path | Condition before acceptance |
|---|---|---|
| Host only exposes a supported COM driver | Device server plus virtual COM | Driver works on the production OS and reconnects without manual intervention |
| Host emits agreed raw serial frames over TCP | Transparent transport | Both endpoints agree on framing and stale-buffer behavior |
| Host emits native Modbus TCP; field uses RTU | Protocol gateway | Unit routing, required functions, exceptions, and serial arbitration pass |
| Local serial HMI must remain active | Topology redesign or verified special mode | One authority controls each serial transaction; no uncontrolled dual masters |
Add authenticated management, supported updates, network segmentation, and least-privilege write access to procurement. Do not assume ordinary Modbus TCP is an authenticated remote-control channel or expose it directly to an untrusted network.
Run a Minimal Proof of Compatibility
Build the smallest safe test: one actual host, one candidate gateway, and one representative serial device. Begin with a documented read-only register. Save host settings, gateway firmware and configuration, serial parameters, an Ethernet capture, and a timestamped serial trace. Compare requested address and quantity, returned payload, transaction association, and the value shown by the application. A ping response establishes none of these.
Then request an unsupported address and simulate a silent device on an isolated bench. Confirm useful errors, bounded waiting, and successful recovery. Do not test write side effects on production actuators. List unresolved functions and environmental conditions explicitly; one working register does not establish complete compatibility. To scope a real adaptation, send Obeita the host driver, serial settings, existing HMI wiring, and read/write requirements. That evidence supports a choice between transparent transport, protocol conversion, and a defined custom integration.
