Modbus Explained. The 40-year-old protocol that refuses to die — and why that's a feature.
Modbus was published in 1979. It has no security, no authentication, no encryption, no addressing beyond a single byte. By every modern criterion, it should have been replaced decades ago. Instead, it's the most widely deployed industrial protocol on Earth. Here's the practical version of what Modbus is, how it works, and why uninstalling it from your plant is harder than it sounds.
The 30-second version
Modbus is a request-response protocol. A master (sometimes called a "client") sends a short binary message to a slave (or "server") asking it to read or write a value. The slave answers with the value, or with an exception code if it can't.
That's it. No subscriptions, no broker, no push, no security, no negotiation. Just ask-and-answer over whatever transport you can route bytes through. Modbus comes in three transports — RTU (binary over serial), ASCII(text over serial — rare today), and TCP (binary over Ethernet) — but the underlying request-response semantics are identical.
Why it won't die: every PLC and RTU vendor speaks it, every SCADA system supports it, every gauge and pressure transmitter has a Modbus library available, and every plant engineer learned it as their first protocol. Network effects compounded over four decades. The cost to switch is enormous; the cost to keep using it is near-zero.
A brief history
Modicon (now Schneider Electric) invented Modbus in 1979 as a way for its 084 and 084-series PLCs to talk to each other over the then-new RS-232 serial bus. The specification was simple by design — Modicon wanted system integrators to be able to wire up multivendor systems, and complexity is the enemy of integration.
Modicon eventually open-sourced the specification, which is the second reason Modbus won. Every protocol stack that came after it (Profibus, Allen-Bradley DH+, GE SRTP, and many more) was vendor-controlled. Plant operators picking equipment kept defaulting to the protocol that wasn't owned by anyone in particular. The Modbus Organization now maintains the spec; both the serial and TCP variants are freely available at modbus.org.
By the 1990s, Modbus was the de facto wire-level lingua franca of industrial automation. By the 2000s, Modbus/TCP let it ride Ethernet without changing semantics. By 2026, it's still in approximately every plant you can walk into — usually alongside two or three "newer" protocols that have been deployed in pockets but have never displaced it.
The three Modbus transports
| Transport | Wire | Encoding | Where you find it |
|---|---|---|---|
| Modbus RTU | RS-232 / RS-485 serial | Binary, CRC-16 checksum | Older field installs, multi-drop RS-485 buses, low-bandwidth long runs |
| Modbus ASCII | RS-232 / RS-485 serial | Text (hex-encoded), LRC checksum | Increasingly rare; legacy installations only |
| Modbus TCP | Ethernet (TCP/IP) | Binary, TCP guarantees delivery so no checksum | Modern installations, control networks, SCADA-to-PLC links |
The semantics are identical across all three. A function-code-3 read of holding register 40001 returns the same byte payload whether it traveled over RS-485 or Ethernet. That's why a Modbus gateway can sit between an Ethernet master and a serial slave with essentially no logic — just bit-shuffling between framing formats.
Anatomy of a Modbus request
A Modbus RTU request is six fields. The TCP variant adds a 7-byte MBAP header on top. Here's what's on the wire for a "read holding register 40001" request to slave address 5:
8 bytes on the wire. The slave responds with another binary message containing the register's value (2 bytes, big-endian) plus a CRC. The whole round-trip is typically 5-20 milliseconds over serial, sub-millisecond over Ethernet.
The "40001" gotcha. Modbus has a 5-digit historical addressing convention where holding registers start at 40001, input registers at 30001, coils at 1, and discrete inputs at 10001. The protocol uses 0-based addressing internally. So "holding register 40001" is request address 0x0000 on the wire. Half the Modbus bugs in field installations come from someone confusing the two.
Function codes that actually matter
Modbus has 19 standard function codes plus extension codes. In the field, you'll see about six of them. The rest are theoretical.
| FC | What it does | Read or write | How often you see it |
|---|---|---|---|
0x01 | Read coils (single-bit outputs) | Read | Common |
0x02 | Read discrete inputs (single-bit inputs) | Read | Common |
0x03 | Read holding registers (16-bit read/write) | Read | The most-used FC in the protocol |
0x04 | Read input registers (16-bit read-only) | Read | Very common |
0x05 | Write single coil | Write | Common |
0x06 | Write single holding register | Write | Common |
0x0F | Write multiple coils | Write | Occasional |
0x10 | Write multiple holding registers | Write | Occasional |
The Modbus data model
Modbus exposes four "data tables." Every Modbus device — PLC, RTU, transmitter, gateway — presents itself as some subset of these:
| Table | Type | Access | Typical use |
|---|---|---|---|
| Coils | 1-bit | Read / write | Discrete outputs — pump runs, valve open, alarm enable |
| Discrete inputs | 1-bit | Read only | Discrete inputs — limit switches, contact closures, alarm states |
| Input registers | 16-bit word | Read only | Analog values from sensors — pressure, temperature, flow rate |
| Holding registers | 16-bit word | Read / write | Setpoints, configuration, PLC variables, derived values |
16 bits is the catch. Modern process variables are usually 32-bit floats (pressure to 2 decimal places, flow rates with precision). Vendors pack a 32-bit float into two consecutive holding registers, but there's no standard for which register holds the high word and which holds the low — every vendor does it slightly differently. Aevus's Modbus connectors detect and adapt to all six common float-packing conventions automatically. Many integrator tools do not, which is why "the value reads 4.2 × 10³⁷" is a recurring field-debug story.
Where Modbus is right (and where it's wrong)
Modbus is right when:
- You need to bolt onto an existing field-device population without negotiation.
- You're operating on a clean physical network (RS-485 multi-drop, isolated control-network VLAN) where the lack of authentication is offset by physical segregation.
- The polled, low-latency request-response model fits the application (deterministic SCADA polling at 1-5 second intervals is the canonical example).
- You need maximum interoperability with a heterogeneous fleet of vendor equipment.
Modbus is wrong when:
- You need security at the protocol layer. Vanilla Modbus has none. None at all. Anyone on the wire can write any holding register on any slave, full stop.
- You need event-driven reporting. Modbus is poll-only. There is no native "tell me when something changes" mechanism.
- You need addressing beyond 247 slaves on a single segment, or beyond ~125 16-bit registers per request.
- You need a rich data type system. Modbus has 16-bit words and 1-bit coils. Anything else is an interpretation layered on top.
Modern security: Modbus/Secure and Modbus over TLS
The Modbus Organization published Modbus/Secure (sometimes called Modbus/TCP Security) in 2018, adding TLS encryption and X.509 certificate-based authentication to Modbus/TCP. It's a mostly-clean addition — the message semantics don't change, just the transport adds a TLS handshake and encrypted channel.
Adoption is slow. Most field deployments are still vanilla Modbus on physically segregated networks because (a) the certificate management is a real operational burden, (b) most legacy field devices can't be upgraded to speak it, and (c) the common defensive posture is "Modbus is fine if it's not on the corporate network."
For new deployments — especially anything touching cloud or remote-access — Modbus/Secure should be the default. For an existing field population, the realistic path is zone-and-conduit segmentation per IEC 62443, with Modbus living inside the lowest-trust zone and a properly secured gateway translating to OPC UA or MQTT/Sparkplug at the zone boundary.
How Aevus reads Modbus
Aevus ingests Modbus telemetry from existing customer infrastructure in one of three ways, chosen per deployment:
- Through the customer's existing historian — if there's already an OSIsoft PI, Ignition, or AVEVA Historian collecting Modbus data, Aevus subscribes to the historian's API. Zero new connections to the field.
- Through a customer-deployed edge gateway — a small device at the customer site polls Modbus over the existing control network and forwards the data to Aevus via outbound MQTT (Sparkplug B). No inbound connections required.
- Through a SCADA front-end — if the customer's SCADA front-end can publish telemetry to a queue (Kafka, Kinesis, etc.), Aevus subscribes to the queue.
Aevus never writes Modbus. Reads only — and not even read access to write-capable registers, by IAM policy at our boundary. The AI cannot issue a Modbus write command to any of your field equipment.
The architecture enforcing this is IL-9000 — at the AWS Organization boundary, not by application policy.
That's Modbus.
If your plant runs Modbus across hundreds of devices and you want to know what's failing across the fleet — without writing back to a single one — that's the conversation we'd love to have.
Related Articles
Information models, certificate security, and when it's worth it.
Scan cycles, ladder logic, and where each controller belongs.
What's inside a Remote Terminal Unit and where you find them.
Ready to see how this applies to your operation? Start a pilot conversation — no commitment, no field changes.