Modbus, a foundational communication protocol in industrial automation, serves as the backbone for exchanging data between field devices. Developed by Modicon (now Schneider Electric) in 1979, Modbus has since become a de facto standard in various industrial sectors. Modbus device testing methodologies are essential for validating interoperability, data integrity, and protocol compliance across industrial deployments.
It has been extensively used for automation in the following domains.
- Industrial: Automation and control within manufacturing plants.
- Building Automation: Management systems for HVAC and building infrastructure.
- Energy Management: Monitoring and optimization of energy consumption.
- Environment Monitoring: Tracking environmental parameters like temperature and pollution.
- Transportation Systems: Control and monitoring of traffic and transportation infrastructure.
In this continuation of our series on testing methodologies, let us see some test cases for server and client and learn about Modbus device testing methodologies in practice.
Overview of Modbus Protocol
As covered in our earlier article on Modbus Protocol, Modbus operates as a server-client protocol, where a client device initiates communication with one or more server devices over a serial or TCP/IP network. It facilitates the transmission of data using a straightforward request-response mechanism, allowing the client to read from or write to specific data registers within the server devices. A standard Modbus serial network has one client and as many as 247 servers, each with a unique slave address. Modbus employs serial communication protocols — Modbus RS232 for point-to-point connections and RS485 for multi-drop networks. Serial communication can occur in RTU mode or ASCII mode. The Modbus RTU frame has a maximum length of 256 bytes and is protected with CRC/LRC for data integrity. Modbus TCP/IP is a variant used for communication over TCP/IP networks on port 502. The Modbus server stack and Modbus client stack must each be independently validated to ensure correct role-based behavior across all communication modes.
Modbus Network Architecture
Serial Modbus protocol defines an interframe timeout that dictates how long a device will wait for additional data before considering the current frame complete. The interframe time is 3.5 times the transmission time of each character at the baud rate of operation and is one of the critical Modbus conformance tests for serial interfaces.
Modbus defined Data Types and Error Codes
The protocol supports different data types, including coils (binary outputs), discrete inputs, input registers (16-bit integer values), and holding registers (16-bit integer values). This flexibility enables Modbus to accommodate a wide range of applications, from simple on-off control to complex data acquisition and process monitoring — all of which must be validated as part of Modbus device testing methodologies.
Error codes are used to indicate issues encountered during communication between the server and client devices. These error codes help diagnose and troubleshoot problems to ensure the reliability of data exchange. Here are some common Modbus error codes:
| Illegal Function (01) | This error typically occurs when the requested function code is invalid or unsupported |
| Illegal Data Address (02) | This error indicates that the requested register or coil address is outside the allowable range or does not exist |
| Illegal Data Value (03) | This error occurs when attempting to write to a register or coil with an invalid or out-of-range value |
| Server Device Failure (04) | This error code indicates that the server device is unable to execute the requested operation due to an internal fault. |
| Acknowledge (05) | The server device has received the request and is processing it but requires additional time to complete the operation. This is not a fatal error and does not indicate a problem with communication. |
| Server Device Busy (06) | This error suggests that the server device is handling another request and cannot accommodate additional requests. |
Modbus Conformance Tests for Server
Modbus server operates as a peripheral unit that responds to commands and requests from the Modbus client. It must be validated to confirm that it adheres to the protocol's communication rules, including data format and addressing schemes, ensuring interoperability within the network. To run Modbus conformance tests on the server, the mapping of all registers/coils and supported function codes must be available to clearly define the test cases. These Modbus conformance tests form the foundation of any rigorous Modbus protocol testing effort.
| Test Case Description | Steps | Expected Result |
|---|---|---|
| Verify Connection Establishment | Attempt to establish connection with the TCP server over port 502 | Connection established successfully |
| Read Coil Registers | Send Read Coil Registers request to server | Coil register values are correctly retrieved |
| Write Coil Registers | Send Write Coil Registers request to server | Coil register values are correctly written and persisted |
| Read Input Registers | Send Read Input Registers request to server | Input register values are correctly retrieved |
| Write Single Register | Send Write Single Register request to server | Register value is correctly written and persisted |
| Write Multiple Registers | Send Write Multiple Registers request to server | Multiple register values are correctly written and persisted |
| Error Handling: Invalid Function Code | Send request with invalid function code | Error response with appropriate code is received |
| Error Handling: Out-of-Range Address | Send request with out-of-range address | Error response with appropriate code is received |
| Error Handling: Communication Failure | Disconnect client device during communication | Error response with appropriate code is received |
| Timeout Handling: Read Operation | Send Read request to server. Simulate no response from server |
Timeout error is appropriately handled by the server |
| Timeout Handling: Write Operation | Send Write request to server Simulate no response from server |
Timeout error is appropriately handled by the master |
| Data Integrity: Read vs. Write Verification | Write data to registers Read data from the same registers. |
Read values match the written values |
| Performance Testing: High Volume of Requests | Send a high volume of read/write requests | Requests are processed efficiently without degradation |
| Baud Rate Recovery | Intentionally create mismatched baud rates Correct baud rate settings Re-establish communication. |
Communication successfully restored after correction |
| CRC Error Detection | Introduce CRC errors in transmitted data frame | Communication fails with error indicating CRC mismatch Error response from server device indicates CRC error |
Modbus Protocol Testing for Client
As part of Modbus protocol testing, the Modbus client needs to be validated for both functionality and performance for all supported function codes. The client-side validation is a distinct part of Modbus device testing methodologies and covers all communication patterns supported by the Modbus server stack and Modbus client stack. A dedicated Modbus RS232 test setup is also used to validate point-to-point serial communication scenarios. Effective predictive maintenance with digital twins relies on accurate Modbus client implementations, making thorough Modbus protocol testing critical.
| Test Case Description | Test Steps | Expected Result |
|---|---|---|
| Verify Modbus Client Connection | Connect the Modbus master device to the Modbus client device. | Modbus client device establishes a stable connection with the master. |
| Read Coil Registers | Send a request from the master to the client to read coil registers. Verify the received data matches the expected values. |
Modbus client device returns the values of specified coil registers. |
| Write Coil Registers | Send a request from the master to the client to write data to coil registers. Verify the data is correctly written and persisted. |
Modbus client device updates the specified coil registers with the new data. |
| Read Input Registers | Send a request from the master to the client to read input registers. Verify the received data matches the expected values. |
Modbus client device returns the values of specified input registers. |
| Write Single Register | Send a request from the master to the client to write data to a single register. Verify the data is correctly written and persisted. |
Modbus client device updates the specified register with the new data. |
| Write Multiple Registers | Send a request from the master to the client to write data to multiple registers. Verify the data is correctly written and persisted. |
Modbus client device updates the specified registers with the new data. |
| Error Handling: Invalid Function Code | Send a request from the master to the client with an invalid function code. | Modbus client device returns an appropriate error response. |
| Error Handling: Out-of-Range Address | Send a request from the master to the client with an out-of-range address. | Modbus client device returns an appropriate error response. |
| Error Handling: Communication Failure | Simulate a communication failure between the master and the client. | Modbus client device handles the failure gracefully and returns an error response. |
| Performance Testing | Simulate a high volume of requests from the master to the client. | Modbus client device responds within acceptable response time thresholds. |
| Timeout Handling | Send a request from the master to the client within a short timeout period. | Modbus client device responds within the specified timeout period. |
| Data Integrity | Write data to specific registers on the Modbus client device. Read the data from the same registers. Verify that the read data matches the written data. |
Modbus client device accurately stores and retrieves the written data. |
| Timeout Handling During Data Transmission | Transmit data frame from master to client. Introduce delays in transmission. |
Master and client devices handle timeouts appropriately, allowing sufficient time for data transmission. |
| Send Invalid CRC and Verify No Response | Prepare a Modbus request frame with valid data and an intentionally invalid CRC. Send the frame to the client device. Wait for the response from the client device. |
No response is received from the client device within a reasonable timeout period, indicating failure to process the request. |
Conclusion
These are some of the high-level tests that can be done on Modbus servers and clients as part of Modbus device testing methodologies. Still, there are many more tests that can be performed — validating the entire defined register space, Modbus conformance tests for communication configurations, timeouts, and error boundaries. While feature-rich tools such as modpoll and modscan32 can be used, they are primarily suitable for manual Modbus protocol testing. Automated tools like the Modbus Protocol Conformance test suite and Embien's TestBot come with a predefined set of test cases that cover the full Modbus server stack and Modbus client stack validation cycle, ensuring 100% coverage of positive and negative cases.
As Modbus is one of the most widely used communication protocols in industrial automation and control systems, understanding Modbus device testing methodologies helps QA engineers cover all boundary conditions and validate Modbus-based products with confidence.