# Rethinking the Operation Pattern for Anomaly Detection in Industrial Cyber-Physical Systems
## 5 The Framework of Proposed Unsupervised Anomaly Detection Model  
This section first provides the objective of the proposed model, followed by the framework and details. This work focused on building a detection model for systems that only contain one master device and one or more slave devices, particularly the master-slaves channel. If the ICPS has multiple master devices, different detection models are required to describe the operation pattern for each master device because different master devices are usually equipped with different software and have different control functionalities, as well as different operation patterns. The key assumption of this model is that the operations are highly periodic and follow a constant pattern. This assumption is reasonable due to the stability of ICPS [8; 15] and automatic control programmes [13].  
Most state-of-the-art works prefer to use machine learning (ML) or deep learning (DL) algorithms to build complex models to detect malicious operations and attacks. However, these algorithms usually have a weak interpretability. This makes it challenging for them to output human-readable classification causes. Moreover, in practical scenarios, the raw traffic collected from ICPSs is usually unlabelled, which limits the training of supervised anomaly detection models. Therefore, this work focuses on using unsupervised methods to build an interpretable anomaly detection model.  
The framework of the proposed model is shown in Figure 3. This model organises the proposed features into four defence lines. This model has good interpretability because each line uses a specific feature to detect attacks. Specifically, the first defence line is achieved in the feature extraction phase, which focuses on detecting elementary attacks (e.g., the malformed packets and re-transmission) that violate the Modbus TCP standards. The following three defence lines are designed to detect more sophisticated attacks, such as MITM, unauthorised operations and injection attacks, based on the operation sequence, time interval, and execution time features. The details of these defence lines are described as follows.  
\begin{table}
\begin{tabular}{l c c l} \hline \hline
**Group** & **Feature** & **Description** \\ \hline \multirow{3}{*}{Identity-related} & \multicolumn{2}{c}{\(IP_{mst}\)} & The IP address of the master device \\ \cline{2-3}  & \multirow{3}{*}{\(Addr_{slv}\)} & \(IP_{slv}\) & The IP address of the slave device \\ \cline{3-3}  & & \(Port_{slv}\) & The TCP/UDP port \\ \cline{3-3}  & & \(UI1\) & The unit identity \\ \hline \multirow{3}{*}{Operation sequence-related} & \multirow{3}{*}{\(FN\)} & \(FC\) & The function code \\ \cline{3-3}  & & \(Reg_{start}\) & The start address of the accessing registers \\ \cline{3-3}  & & \(Reg_{cnt}\) & The number of accessing registers \\ \hline \multirow{3}{*}{Operation time interval-related} & \multirow{3}{*}{\(ET\)} & \(ET_{last}\) & The time that elapsed from this operation to the last operation \\ \cline{3-3}  & & \(ET_{lastSim}\) & The time that elapsed from this operation to the last similar operation \\ \hline Execution time-related & \multirow{3}{*}{\(RT\)} & \multirow{3}{*}{The time taken by the slave device to process the received request} \\ \cline{3-3} \hline \hline \end{tabular}
\end{table}
Table 1: Summary of the proposed features. The features are structured into four groups, namely identity, operation sequence, operation time interval and execution time.