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 due to its simplicity, robustness, and versatility.
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 the continuation of series of articles on testing methodologies, let us see some test cases for server and client and learn about the Modbus protocol enabled device testing.
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 communication protocols like RS485 or RS232. Additionally, serial communication can occur in different modes: RTU mode and ASCII mode. The Modbus RTU frame has a maximum length of 256 bytes and is protected with CRC/LRC to ensure data integrity. Modbus TCP/IP is a variant used for communication over TCP/IP networks connecting over port 502. Unlike serial communication, Modbus TCP/IP doesn't require the devices to verify message accuracy, because the TCP/IP layer already handles data integrity.
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 critical Modbus conformance tests.
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 and had to be validated as a 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 |
client Device Failure (04) | This error code indicates that the client device is unable to execute the requested operation due to an internal fault. |
Acknowledge (05) | The client 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 |
client Device Busy (06) | This error suggests that the client device is handling another request and cannot accommodate additional requests now. |
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 if it adheres to the protocol's communication rules, including data format and addressing schemes, ensuring interoperability within the network. It listens for function codes sent by the master, executing read or write operations on its designated data registers. To run Modbus conformance tests on server, the mapping of all the registers/coils supported along with the function codes supported must be available to clearly define and validate the test cases.
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 client | Coil register values are correctly retrieved |
Write Coil Registers | Send Write Coil Registers request to client | Coil register values are correctly written and persisted |
Read Input Registers | Send Read Input Registers request to client | Input register values are correctly retrieved |
Write Single Register | Send Write Single Register request to client | Register value is correctly written and persisted |
Write Multiple Registers | Send Write Multiple Registers request to client | 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 client. Simulate no response from client |
Timeout error is appropriately handled by the server |
Timeout Handling: Write Operation | Send Write request to client Simulate no response from client |
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 client 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 the supported function codes.
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. Still there are a lot of tests that can be performed such as validating the entire defined register space, playing with communication configurations, timeouts etc. While feature rich tools such as modpoll, modscan32, etc. can be used, they are primarily suitable for manual testing. Automated tools like the Modbus Protocol Conformance test suite, Embien’s TestBot comes with a predefined set of test cases that can be used to do Modbus protocol testing reducing the validation cycle and make sure 100% coverage of positive and negative cases.
As Modbus is one of the widely used communication protocols in industrial automation and control systems, knowing Modbus device testing methodologies helps the QA engineer to cover all boundary conditions and enables in validating a Modbus based product.