# Rethinking the Operation Pattern for Anomaly Detection in Industrial Cyber-Physical Systems
## 3 Modbus Protocol  
The Modbus protocol has been a de facto protocol in industrial control systems (ICSs), enabling convenient data exchange between devices. Modbus TCP has been further proposed, which combines Modbus with TCP/IP to facilitate data transmission in Ethernet [32]. Modbus TCP uses the client-server model, where master devices (clients) initialise requests to slave devices (servers). Then, the slave devices process received requests and respond with execution results. For backward compatibility with legacy Modbus devices, gateway or bridge devices are usually deployed between Modbus TCP devices and legacy devices to translate Modbus TCP and Modbus protocols.  
As shown in Figure 1, the Modbus TCP consists of a Modbus application (MBAP) header and a protocol data unit (PDU). The PDU is similar to the Modbus remote terminal unit (RTU) message, except that Modbus TCP moves the unit ID into the MBAP header. Modbus TCP further ignores the cyclic redundancy check (CRC) value as the IP and TCP layers have checksum fields, which could provide integrity verifications to the transmitted payload. The fields of Modbus TCP are described as follows.  
* **Transaction Identifier.** This is a two-byte value used to identify Modbus request/response messages. Master devices initialise this value, and slave devices echo it when responding with the execution result.
* **Protocol ID.** This is a two-byte value used to identify the protocol of the following PDU (e.g., 0 for Modbus).
* **Length.** This indicates the byte size of the following data using two bytes.  
Figure 1: The frame of Modbus and Modbus TCP protocols.  
* **Unit ID (UI).** This is a one-byte value used to help identify slave devices when using gateway/bridge devices. Master devices set UI as the identifier of the requesting slave device. The devices then forward messages to the corresponding slave device according to the UI and set the same UI in their response.
* **Function Code (FC).** FC is a one-byte integer randoming from 1 to 127. The Modbus specification defines the meaning of 19 function codes, such as 2 indicating reading input status and 4 indicating reading registers.
* **Data.** This field usually contains the request parameters or the execution results. Its size is variable, with a maximum limit of 252 bytes. For request commands, this field specifies the start address \(Reg_{start}\) and the number \(Reg_{cnt}\) of requesting registers. For response messages, it contains the length of the execution results and specific results.  
Figure 2 presents an example of the Modbus TCP request and response process, where the master and slave devices are connected by industrial Ethernet. The master device sent a request message with transition ID 20901 to read 13 (\(Reg_{cnt}\)) discrete inputs (\(FC\)), starting with 1536 (\(Reg_{start}\)). The corresponding response message uses the same transition ID, protocol ID and UI as the request. The data in the response message contain the execution result: the content of the 13 discrete inputs is 0 \(\times\) 4010 and the length is 2 bytes.  
In this work, the MBAP header, function code, request parameters and response results are used to describe operation semantics.