Modbus Device Identification: Discover Vendor and Revision Without Guessing Registers

A gateway needs a defensible way to identify a connected device before selecting a register map. Guessing that every vendor stores its model number at the same holding-register offset is fragile. Modbus Read Device Identification offers a standard object interface for identity information, when the target implements it.

This guide follows Application Protocol V1.1b3, section 6.21. It describes discovery and inventory handling, not measurement polling or device authentication. The proposed parser and fixtures are design guidance; no claim is made that an unspecified installed device supports this function.

Begin with the correct function and access type

Read Device Identification uses function 43 decimal, 0x2B hexadecimal, with MEI type 14 decimal, 0x0E hexadecimal. A basic stream request beginning at object zero has PDU bytes 2B 0E 01 00. Add the appropriate TCP or serial wrapper separately; these four bytes do not include a Unit Identifier, serial address or CRC.

The official specification, section 6.21, defines stream access codes 01, 02 and 03 for basic, regular and extended identification, plus 04 for individual-object access. Start with basic identification rather than scanning private registers or requesting every possible object. Record the exact route so a gateway’s own identity is not confused with that of a downstream instrument.

Interpret the advertised object categories

Basic objects are VendorName at 0x00, ProductCode at 0x01 and MajorMinorRevision at 0x02. They are mandatory within this identification interface; that does not mean every Modbus device implements the interface. Regular objects add optional descriptive fields, while private extended objects occupy the product-dependent 0x80–0xFF range.

The conformity value describes both the supported level and whether individual access exists. Values 0x01–0x03 describe stream-only levels; 0x81–0x83 also support individual access. Do not interpret the high bit as an error or assume that an extended-level request guarantees extended data. The specification requires a server asked for a higher level to respond according to its actual conformity level.

Parse object lengths before interpreting strings

Validate the function, MEI type, returned access code, conformity value, continuation fields and object count. Each object carries its own ID and byte length. Before reading its value, verify that the declared length fits inside the remaining response. Reject truncated headers, impossible counts and trailing bytes that cannot be explained by the selected response structure.

The standard descriptive objects are ASCII strings. Keep their original bytes and display text separately. Non-ASCII bytes in those objects should be flagged as a conformance or vendor-encoding issue, not silently declared standard UTF-8. Private objects require their own documented representation. Escape all displayed values; a vendor name or URL is untrusted device data, not executable markup or an instruction to visit a site.

Follow pagination without building an infinite loop

For stream access, More Follows 0xFF means further requests are needed; the next request uses the returned Next Object ID. More Follows 0x00 ends the stream. An identification object is indivisible across these logical responses, according to section 6.21’s request and response rules. TCP segmentation is a separate transport concern.

Track previously requested cursors, returned object IDs, total bytes and a discovery deadline. A repeated cursor or repeated page without new information must not create an unbounded loop. Preserve the partial result with an anomaly reason. Do not increment the object ID yourself and assume consecutive objects exist; follow the server’s cursor and validate progress.

Distinguish unsupported, incomplete and unidentified

A valid exception, a local timeout and a malformed identification response are different outcomes. Illegal Function can mean the operation is unavailable in the current device context; a timeout does not prove lack of support. For individual access, an unknown object receives Illegal Data Address, whereas the specification describes restarting at object zero for an unknown stream starting object.

Keep a capability state such as supported, rejected, unconfirmed or malformed, together with the observed exception when present. If identification is unavailable, use an operator-approved inventory entry or vendor-documented alternative. Do not silently choose a register map from a guessed model string. Discovery failure should not erase a previously verified manual mapping without an explicit policy.

Cache identity with its route and observation time

Cache the gateway endpoint, serial segment where relevant, unit, returned object bytes, observation time, conformity and completeness. Store the selected register-map revision separately from the reported firmware string. A firmware update, route reassignment or physical device replacement can invalidate assumptions even when the IP address stays constant.

Define refresh triggers around commissioning, documented update events and route changes instead of adding identification reads to every measurement cycle. Compare changes and request review before applying a new control map. An unchanged VendorName is weak evidence: multiple devices share it, and ordinary Modbus identification is self-reported rather than cryptographically authenticated.

Accept discovery with realistic fixtures

Build a fixture with fictitious basic objects, then split the logical result across two responses using a valid continuation cursor. Test a single-page result, an unsupported-function exception, a deadline expiry, a repeated cursor, a truncated object and unexpected non-ASCII descriptive bytes. Include a regular request answered at basic conformity and an individual-object lookup only when that access mode is advertised.

• The initial PDU and selected route are recorded correctly.
• Object lengths are validated before allocation or display.
• Pagination either finishes or stops with a bounded incomplete result.
• Partial, rejected and unconfirmed discovery remain distinguishable.
• Identity changes cannot silently authorize a different register map or control action.

The outcome is a useful device inventory with declared confidence and provenance. It can help select documentation and flag replacements, but it cannot establish trusted identity or authorize equipment control by itself.