# Module 1: What Modbus Is

> The mental model, why Modbus is still everywhere, and what it deliberately does not give you.

**Phase:** Foundations  
**Estimated time:** 6 min  
**Release status:** Published  
**Content version:** 1.0.0  
**Source:** https://learnmodbus.studioseventeen.io/lesson/what-modbus-is

## What you'll be able to do
- Describe Modbus as a request/response, client/server protocol with no built-in security.
- Explain why Modbus is still dominant on factory floors despite its age.
- List the three things Modbus deliberately does not give you.

## Three things people get wrong
1. **Treating Modbus as a network protocol.** It's an application-layer message format that rides on top of serial or TCP.
2. **Assuming the protocol enforces meaning.** Register 40001 has no defined meaning — it's whatever the vendor's map says.
3. **Expecting authentication or encryption.** Classic Modbus has none. Plan compensating controls (network segmentation, Modbus Security).

## From the field
**The 40-year-old protocol you can't kill**

A team replaced a 1990s line with brand-new variable-frequency drives. The shiny EtherCAT spec made the rounds — but the spec list quietly included 'Modbus TCP Unit ID 1'. Six months later, that fallback channel was the only thing keeping production data flowing while the EtherCAT master was being commissioned.

## References
- [Modbus Application Protocol V1.1b3](https://www.modbus.org/file/secure/modbusprotocolspecification.pdf)
- [Modbus.org — protocol overview](https://www.modbus.org/modbus-specifications)

## Lesson

# Module 1 Lesson: What Modbus Is
## Learner Outcome

By the end of this module, learners can explain what Modbus is, why it is still common in industrial systems, what clients and servers do, and what classic Modbus does not provide.

## Key Concepts

- Modbus is an industrial application-layer messaging protocol.
- A client initiates a request; a server responds.
- Most common transactions read or write a small block of bits or 16-bit registers.
- The same core PDU idea appears across RTU, ASCII, Modbus TCP, and Modbus Security / Modbus TCP over TLS, but each transport wraps it differently.
- Classic Modbus is simple and widely supported, but it does not define discovery, rich semantic meaning, authentication, authorization, or encryption.

## Key Terms

- Client: the requester that starts a Modbus transaction.
- Server: the responder that returns data, accepts a supported write, returns an exception response, or does not produce a usable response.
- PDU: Protocol Data Unit; the function code plus request or response data before a transport wrapper is added.
- Transport: the way the Modbus message is carried, such as RTU, ASCII, TCP, or TLS-protected Modbus Security.
- Register map: the external source that gives raw Modbus bits/registers meaning, scale, units, and safety context.

## Source-Grounded Explanation

### The Mental Model

Modbus is a request/response protocol for moving process data between automation devices and software. A client asks for a specific operation, such as reading holding registers or writing a coil. A server returns data, echoes an accepted write, or returns an exception response. From the client's evidence view, a timeout or no usable response means no valid response arrived.

Use `client` for the requester and `server` for the responder. Older documents and field conversations may still use `master` and `slave`, especially around serial RTU/ASCII. Learners should recognize those words as legacy field vocabulary, but this course uses client/server as the default.

Modbus appears in PLCs, HMIs, drives, meters, remote I/O, sensors, gateways, SCADA systems, building automation, solar equipment, battery systems, lab devices, and simulator tools. It remains common because it is small, predictable, open, and easy to inspect.

### What Modbus Does Not Tell You

Classic Modbus moves bits and 16-bit registers. It does not tell you that a value means temperature, breaker status, energy import, command authority, or grid frequency. That meaning comes from a register map, device manual, configuration notes, and field evidence.

Classic Modbus also does not provide built-in authentication, authorization, encryption, discovery, subscription/event behavior, or a standardized high-level device model. Security, safety, network controls, and semantic mapping must be supplied by the surrounding system and integration process.

### First Transaction Sketch

```text
Client -> Server: read holding register at a documented point
Server -> Client: returned raw register value
Course map: raw value + scale/unit = engineering value
```

The protocol carries the request and raw value. The map supplies the meaning.

## Practical Example

A building controller reads supply-air temperature from the synthetic `lab_temperature_reading` row used again in Module 8.

| Example Field | Value |
|---|---|
| Transport | Modbus TCP for this first sketch; RTU/ASCII wrappers come later |
| Source label | Synthetic teaching fixture |
| Client | Building controller, HMI, SCADA driver, test tool, or script |
| Server | Controller, meter, PLC, simulator, or gateway-exposed device |
| Operation | Read one holding register |
| Function code | `03` Read Holding Registers |
| Documented address | `40094` in a one-based `40001` style map |
| Addressing preview | Module 5 will show why `40094` becomes PDU address `93` in this one-based `40001` style map |
| Quantity | `1` register |
| Data type | Signed 16-bit in this synthetic teaching example |
| Scale/unit | raw `/10 deg C`; raw `0x7FFF` means unavailable |
| Expected normal response | `03 02 00 E0` for raw `224`, which decodes to `22.4 deg C` |
| Likely failure mode | Timeout/no usable response if no valid response arrives; exception `02` if the server reports an illegal data address |

If the raw value is `224`, the course example decodes it as `22.4 deg C`. The protocol did not say temperature; the source map did.

## Common Pitfalls

- Treating Modbus as a complete device model.
- Assuming every server supports the same functions, addresses, ranges, data types, or write behavior.
- Calling every responder a device even when it may be a gateway or simulator.
- Treating legacy `master/slave` wording as the preferred course vocabulary.
- Believing `40010` is literally sent as a wire address.
- Assuming classic Modbus TCP is secure because it runs over Ethernet or inside a VPN.

## Check-Your-Understanding

1. Which side starts a normal Modbus request?
2. What does the server do after a successful read request?
3. Why do you still need a register map after you know the function code?
4. Name two things classic Modbus does not provide by itself.
5. A tool displays raw value `224`. What evidence do you need before calling it `22.4 deg C`?

## Source Notes

- Official basis: Modbus Organization introduction and Modbus Application Protocol Specification for the client/server model, request/response behavior, function-code framing, and data model basics.
- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for application-layer client/server request/reply, PDU vs ADU and general frame structure, four primary logical data tables, normal response vs exception response, public function-code categories, serial client/server legacy terminology, and Modbus Security TLS wrapping.
- Local course spine: `modbus-wiki.md` sections "What Modbus Is", "Why Modbus Endured", "Core Architecture", and "Data Model".
- Field context: legacy terminology and common deployment examples are practical context, not new protocol rules.
- Security boundary: classic Modbus security limitations are introduced here and taught in depth in Module 15.

## Completion Checkpoint

Before moving on, learners should identify the client, server, operation, missing source evidence, and safety/security boundary in a short scenario. Use the scenario worksheet and quiz before introducing the PDU/ADU message model in Module 2.

## Reusable Assets

- [Client/server scenario worksheet](https://learnmodbus.studioseventeen.io/resource/client-server-scenario-worksheet)
- [Module 1 scenario lab](https://learnmodbus.studioseventeen.io/lesson/what-modbus-is?page=lab-1)
- [Module 1 quiz](https://learnmodbus.studioseventeen.io/lesson/what-modbus-is?page=quiz)

## Diagram source

```mermaid
flowchart LR
  C["Client<br/>(HMI / SCADA / Tool)"]
  S["Server<br/>(PLC / Meter / Drive)"]
  C -- "Request: function code + data" --> S
  S -- "Response: data OR exception" --> C
```

## Labs

### Lab 1

# Lab 1: Client/Server Scenario Triage
## Learner Outcome

Learners identify the client, server, requested operation, missing documentation, likely normal response, and likely failure bucket in short Modbus scenarios.

A _failure bucket_ is one of the three ways a Modbus request can go wrong: **no response** (nothing valid comes back), **exception response** (the server answers with an error code), or **wrong value** (a normal-looking answer that decodes to the wrong meaning). Module 14 builds these three buckets into a full troubleshooting method; for now, just practice sorting each scenario into one of them.

## Prerequisites

- No hardware required.
- Module 1 lesson or equivalent overview of client/server request/response behavior.
- [Client/server scenario worksheet](https://learnmodbus.studioseventeen.io/resource/client-server-scenario-worksheet)

## Safety And Scope

This is a paper/no-hardware lab. Do not connect to production networks or devices. Do not write values to real equipment. Any write scenario is classified only as a risk and documentation exercise.

## Scenario Cards

### Card A: HMI Reads A Meter

An HMI polls an energy meter every five seconds. The map says line voltage is at `40010`, unsigned 16-bit, scale `/10 V`.

| Field | Expected learner answer |
|---|---|
| Client | HMI |
| Server | Energy meter |
| Source label | Synthetic teaching fixture |
| Operation | Read one holding register |
| Function code | `03` if the map row is a holding register |
| Documented address | `40010` |
| Addressing note | PDU address conversion is a Module 5 preview; do not treat `40010` as a wire address |
| Missing evidence | Exact address convention, Unit Identifier or server address, transport path, value validity state |

### Card B: SCADA Writes A Start Bit

A SCADA screen has a Start button for a pump. The device manual lists a command word but does not show the local/remote mode requirement.

| Field | Expected learner answer |
|---|---|
| Client | SCADA system |
| Server | Pump controller or gateway-exposed pump controller |
| Source label | Synthetic teaching fixture |
| Operation | Write command, not just a read |
| Missing evidence | Command register, write function, allowed values, local/remote mode, interlocks, rollback/stop procedure, independent status feedback |
| Safety decision | Stop. No real write without Module 15 write-safety review and approval. |

### Card C: Gateway Bridges TCP To Serial

A test tool connects to a TCP gateway. The gateway routes requests to a serial drive. The tool gets no response.

| Field | Expected learner answer |
|---|---|
| Client | Test tool |
| Visible TCP endpoint | TCP gateway endpoint |
| Downstream addressed server/responder | Serial drive, if the route is correct |
| Source label | Synthetic teaching fixture; gateway preview for Module 13 |
| Missing evidence | Unit Identifier route, serial server address, baud/parity/stop bits, gateway mode, timeout settings |
| Likely bucket | No response until a valid responder or exception is proven |

### Card D: Raw Value Without A Map

A script reads holding register offset `9` and prints raw value `224`.

| Field | Expected learner answer |
|---|---|
| Client | Script |
| Server | Device or simulator responding to the script |
| Source label | Synthetic teaching fixture |
| Operation | Read holding register |
| Missing evidence | Documented address, type, scale, unit, validity conditions, source label |
| Correct conclusion | Raw `224` is not yet temperature, pressure, speed, or status without the map. |

## Procedure

1. For each card, identify the client and server.
2. Name the requested operation: read bits, read registers, write bit, write register, or unknown.
3. Record the documentation still needed before interpreting the value or authorizing a write.
4. Predict the normal response shape at a high level: returned data, write echo, or exception response. If none arrives, record timeout/no usable response from the client view.
5. Mark one safety or source boundary for each scenario.
6. Complete the worksheet answer key.

## Expected Observations

- A client initiates each request; a server responds or fails to provide a usable response.
- A successful read proves that a value was returned from the selected table/address path, not that the raw value has engineering meaning.
- A write echo proves the protocol response shape only. It does not prove the physical process changed state.
- Gateway scenarios may hide the final server behind a TCP endpoint, so the visible endpoint is not always the final device that owns the data.

## Troubleshooting Notes

- If the learner cannot identify the client and server, stop before changing address, scale, or byte-order assumptions.
- If a response is missing, record timeout/no usable response instead of inventing an exception code.
- If a raw value is returned without a register map, mark the engineering meaning as unresolved.
- If a write scenario appears, require safety, authorization, rollback, and independent feedback evidence before treating it as real-device work.

## Check Questions

1. Why is "server" not always the same thing as the physical field device?
2. What does a successful read response prove, and what does it not prove?
3. Why does a write scenario require more evidence than a read-only scenario?
4. Why is a raw value not enough to create a dashboard label?

## Instructor Notes

- Accept "master/slave" only when a learner is quoting legacy field language; normalize the answer back to client/server.
- Do not let learners jump to byte-order or scaling fixes before they identify the source map and requested operation.
- Use Card B to set up Module 15: a write echo is not physical process proof.
- Use Card C to preview Module 13: the TCP endpoint may be a gateway, not the final server.

## Source Notes

- Official protocol basis: Modbus Application Protocol Specification for client/server request/response behavior and function-code roles.
- Local course basis: `modbus-wiki.md` Module 1 and `course-phase-drafts/phase-1-modbus-foundations.md`.
- Field note: gateway and write-safety examples are scenario fixtures that preview later modules; they are not product-specific behavior.

## Knowledge check

# Module 1 Quiz: What Modbus Is
## Questions

1. In modern course terminology, which side starts a normal Modbus request?
   A. Server
   B. Client
   C. Register
   D. Coil

2. What does classic Modbus primarily move?
   A. Rich semantic device objects.
   B. Bits and 16-bit registers using request/response messages.
   C. Encrypted event streams.
   D. Vendor manuals.

3. A device returns raw value `224` from a register. What is still needed before displaying it as `22.4 deg C`?
   A. Source-map evidence for data type, scale, unit, and validity.
   B. A different Ethernet cable.
   C. A Modbus Security certificate.
   D. Nothing; all registers are temperature by default.

4. Which statement is most accurate?
   A. Classic Modbus includes built-in authentication and authorization.
   B. Classic Modbus defines discovery and semantic device models.
   C. Classic Modbus is simple and inspectable, but surrounding documentation and controls supply meaning and safety context.
   D. Modbus only works on serial networks.

5. Older Modbus documents may use `master/slave`. How should this course handle that language?
   A. Use it as the default vocabulary.
   B. Ignore it completely.
   C. Recognize it as legacy field/document language and use client/server as the modern default.
   D. Treat it as a different protocol.

6. A SCADA screen sends a command to a pump controller. Why is this different from a read-only polling example?
   A. Writes may change process state and need safety, permission, rollback, and independent-status evidence.
   B. Writes are impossible in Modbus.
   C. Reads are always unsafe and writes are always safe.
   D. Commands do not use function codes.

## Answer Key

1. B. The client initiates a normal request; the server responds.
2. B. Classic Modbus moves bits and 16-bit registers; higher-level meaning comes from documentation and integration evidence.
3. A. Raw value alone is not enough; the register map or reviewed source must supply type, scale, unit, and validity.
4. C. Modbus is useful because it is simple, but it is low-context and needs surrounding documentation and controls.
5. C. Learners should recognize legacy terms but use client/server as the course default.
6. A. Writes require safety review because a protocol-level response does not prove the intended physical state.

## Distractor Review Notes

| Question | Correct | Why The Distractors Are Wrong |
|---:|---|---|
| 1 | B | A reverses the request/response roles, and C/D name data model items rather than the side that initiates a transaction. |
| 2 | B | A invents semantic objects, C adds security behavior not present in classic Modbus, and D is documentation rather than protocol payload. |
| 3 | A | B is unrelated to data meaning, C addresses transport security rather than interpretation, and D invents a universal temperature meaning. |
| 4 | C | A invents built-in authorization, B invents discovery/semantics, and D ignores Modbus TCP and other transports. |
| 5 | C | A makes legacy terms the default, B prevents learners from reading older sources, and D treats vocabulary as a protocol fork. |
| 6 | A | B denies write functions, C reverses safety judgment, and D ignores that commands still use function-code-defined Modbus operations. |

## Instructor Notes

- If learners miss question 3, revisit the difference between protocol transport and semantic meaning.
- If learners miss question 6, mark Module 15 write-safety content as a later reinforcement point.

## Source Notes

- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for application-layer client/server request/reply, four primary logical data tables, serial client/server legacy terminology, normal response vs exception response, public function-code categories, write function echo boundaries where write-safety questions appear, and Modbus Security TLS wrapping where security contrasts appear.
- Security and write-safety items remain introductory course framing until Module 15 source/safety review.

---
_Learn Modbus · learnmodbus.studioseventeen.io · Module 1/16 · v1.0.0 · Exported for offline / agent use._