Skip to content

Modbus TCP

Modbus application protocol over TCP/IP using an MBAP header.

Status Examples Runtime example Source posture
draft-structure-only synthetic/passive docs-only atlas metadata plus public/tooling cross-checks

Identity

Modbus application protocol over TCP/IP using an MBAP header.

What This Protocol Teaches

  • Modbus TCP is serial-era register thinking moved onto Ethernet.
  • It teaches how to inspect MBAP header, unit id, function code without mistaking field extraction for meaning.
  • It keeps observer inference separate from system truth.

Operational Context

Modbus TCP appears in industrial contexts and is modeled in the atlas at the application, transport layer(s). The binder treats it as an inspection surface: what evidence appears, what timing matters, and what outside authority is required before assigning meaning.

Draft status

draft-structure-only: this is not yet a final-copy binder page. It has an atlas-grounded teaching hook and source notes, but still needs a stronger worked trace, page-specific ambiguity case, and reviewer-validated visual before promotion.

A Concrete Artifact

# synthetic Modbus TCP ADU
00 01 00 00 00 06 11 03 00 6b 00 03

Synthetic

Synthetic offline sample for explanation; not a real operational trace or live-system instruction.

Worked Decode

  1. Read 00 01 as a transaction identifier in the synthetic MBAP header.
  2. 00 00 is protocol identifier evidence and 00 06 gives the following length.
  3. 11 03 00 6b 00 03 carries unit id, function code, start address, and quantity, mirroring the RTU teaching shape without CRC bytes.
  4. The register range is still only register evidence until a device register map supplies meaning.

Field Layout / Anatomy

Element Shape Inspection meaning
MBAP header artifact-specific evidence Inspect with timing and source context before naming meaning.
unit id artifact-specific evidence Inspect with timing and source context before naming meaning.
function code artifact-specific evidence Inspect with timing and source context before naming meaning.
TCP session artifact-specific evidence Inspect with timing and source context before naming meaning.
semantic authority external source Dictionary, profile, map, or integration document that turns evidence into named meaning.
timing context cadence / gap / slot / timestamp Freshness and ordering evidence for observer reconstruction.

Visual Model

sequenceDiagram participant Initiator participant Bus participant Responder Initiator->>Bus: synthetic request or scheduled evidence Bus->>Responder: framed artifact Responder-->>Bus: response or periodic value Bus-->>Initiator: observed result

Timing And Authority

Timing and authority depend on the industrial-protocol role: scheduled, polled, arbitrated, transmitted, or logged evidence should not be read as the same kind of truth. Semantic authority is external to the raw artifact unless the artifact is itself a description or capture format; even then, provenance determines whether the description should be trusted.

Semantic authority

Bytes rarely explain themselves. Name the source that defines meaning before naming engineering values: standard metadata, label table, DBC, PGN/SPN definition, object dictionary, register map, DID catalog, LDF, ARXML, channel metadata, or vendor profile.

Failure And Ambiguity

  • Transaction IDs correlate observed messages but do not name engineering units.
  • Unit IDs can represent gateways, serial slaves, or local endpoints depending on topology.
  • The absence of CRC in TCP does not make the register map self-describing.

Observer Lesson

A passive observer can usually infer artifact boundaries, repeated structure, cadence, missingness, and candidate state transitions. The observer usually cannot prove physical truth, application intent, complete system state, or engineering-unit meaning without semantic authority and timing provenance.

Python Model

No current runtime example is claimed for this draft page. Keep reader claims at the artifact and source level until a separate implementation plan adds a tested model.

Local Teaching Notes

Simplification

The artifact and diagrams are synthetic teaching material. The page intentionally omits conformance timing tables, electrical design detail, proprietary configuration, and exhaustive standard behavior.

Source Confidence

Source confidence is high for scope and terminology, with semantic claims limited to public metadata, public source notes, and synthetic teaching artifacts.

Source Notes

Field Value
Governance tier Tier 2 Field Note
Canonical source status yes
Public explainer status yes
Open-source tool status yes
Sample-data status none listed; use synthetic teaching artifacts
Confidence high
Citation specificity document-metadata-level
Canonical source(s) MODBUS Messaging on TCP/IP Implementation Guide (Modbus Organization; Modbus TCP/IP Guide; public-web; metadata-only)
Public explainer/tooling source(s) Modbus specifications (Modbus Organization; public-web; link-only)
Open-source tool references libmodbus: Modbus RTU/TCP
pymodbus: Modbus client/server
Wireshark: Protocol dissectors and PCAP analysis

References

Public Sources