## 2 Proposed System
### Scada Hmi
#### 2.4.2 Modbus TCP Configuration  
The Modbus TCP is a request-response protocol, where the client (master) requests a message to the server (slave) and the server replies to the client. There are four types of messages [56]:  
1. Modbus request: the message sent by the client to initiate a transaction,
2. Modbus indication: the request message received on the server side,
3. Modbus response: the response message sent by the server,
4. Modbus confirmation: the response message received on the client side.  
The Application Data Unit (ADU) of the Modbus TCP protocol is illustrated in Figure 4[56]. It consists of the Modbus Application Protocol (MBAP) header, function code, and data. The function code and data field are called the Protocol Data Unit (PDU). The MBAP header contains the following fields: Transaction identifier for identification of Modbus request/response transaction, Protocol identifier, Length of the following bytes, and Unit identifier for identification of a remote slave. The function code field defines the task that should be performed. The data field contains additional information according to the function code, such as the register addresses, the number of items to be handled, and the actual data to be read or written. The common Modbus function codes are listed in Table 8[57].  
The PDU is defined for a particular function code. For instance, the PDU for the function code = 03 (Read Holding Registers) is illustrated in Figure 5. This function code reads the contents of holding registers in a remote device. The client requests the server by sending the function code (03), the starting address, and the number of registers to be read.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Function Code** & **Definition** \\ \hline
01 & Read Coils \\ \hline
02 & Read Discrete Inputs \\ \hline
05 & Write Single Coil \\ \hline
15 & Write Multiple Coils \\ \hline
03 & Read Holding Registers \\ \hline
06 & Write Single Register \\ \hline
16 & Write Multiple Register \\ \hline \hline \end{tabular}
\end{table}
Table 8: Common Modbus function code.  
Figure 4: Modbus TCP Application Data Unit (ADU).  
Then, the server will respond by sending the function code (03), the number of bytes, and the register data. The server sends the error and exception codes if an error occurs.  
The configuration of the Modbus TCP protocol used in the experiment is illustrated in Figure 6, where for simplicity, only Requests and Responses are indicated in the figure. The figure shows that the client is the Haiwell IoT Cloud HMI. The servers are the Raspberry Pi Zero W #1, Raspberry Pi Zero W #2; JXCT soil sensor RS485 Modbus to WiFi converter #1 and JXCT soil sensor RS485 Modbus to WiFi converter #2. The IP address of each device is shown in the figure. The RS485 Modbus to WiFi converters use the default Modbus TCP port number of 502. However, since this port number is the privilege port in the Raspberry Pi environment, we use the port number of 1234 for programming simplicity. The Modbus function code = 03 (Read Holding Registers) is used to access the data in the server. The Modbus data addressing for the Raspberry Pi Zero W and JXCT soil sensor RS485 Modbus to WiFi converter is listed in Tables 9 and 10, respectively.  
The client (Haiwell IoT Cloud HMI) requests the data from the servers every five seconds. The requested data are listed in Tables 9 and 10. The data are then displayed on the HMI. Besides displaying the data, the HMI also stores the data in the memory. The data are stored in one-minute intervals for saving memory usage. Since the HMI is connected to the cloud server, the data can be accessed easily via the internet.  
Figure 5: PDU of function code = 03.  
Figure 6: Configuration of Modbus TCP.