# Fivadmi: A Framework for In-Vehicle Anomaly Detection by Monitoring and Isolation +
## 4 Implementation of FIVADMI
### Monitoring Scheme
#### 4.3.3 Monitoring Algorithm  
Runtime monitoring of security and behavioural rules in FIVADMI is carried out by a Rule Engine. The current implementation of FIVADMI is based on the CLIPS [24] rule engine: in typical usage, CLIPS maintains a set of _facts_ and a set of _rules_, where rules operate on facts. In CLIPS, a fact is a piece of information (e.g., variable), and a rule takes the form similar to _IF (condition) THEN (action) ELSE (action)_ statements in a procedural language.  
Figure 14: EC Rules–Vehicle Speed Anomaly Detection.  
CLIPS uses an improved form of the well-known Rete algorithm [85] to match rules against facts. Rules written in CLIPS can be considered as data-driven programs, the facts being the data that trigger execution of rules via the inference engine. The inference engine then decides which rules should be executed and when.  
EC rules described in Sections 4.3.1 and 4.3.2 are easily transformed into corresponding CLIPS specification. More specifically, _fluents_ in EC are transformed into _facts_ (e.g., the fluent _CAN_Data(dID, dMsg, dTS)_ is transformed into a _fact_ called CAN_Data to contain id, message, and timestamp. Similarly, the fluent _OBD_Data(dID, dSpd, dTS)_ is transformed into a fact called OBD_Data and EC rules are transformed into CLIPS rules. At boot-time, instances of these rules are created in CLIPS. At runtime, the Monitoring and Certification Manager receives CAN frames from the IVN, retrieves relevant data from each frame, and stores these data into facts in CLIPS. Security rules and OBD rules are then run against these facts.  
Figure 15 shows the algorithm that drives the monitoring process in FIVADMI. The monitoring algorithm is divided into three methods.  
**Method monitoring0**. This method starts the monitoring process. Facts are created in CLIPS (lines 1-2). The corresponding OBD rules are also created (line 3). The loop in line 4 drives the monitoring process: when a _CAN Frame_ arrives, the security rules and the OBD rules are monitored, using methods _security_rules_check()_ and _obd_rules_check()_ respectively.  
**Method security_rules_check0**. Upon receipt of a CAN frame, the ID, message, and time stamp of the frame are extracted. Fact _CAN Data_ in CLIPS is updated (lines 1-2). Then, security rules and corresponding facts are created for each type of threat to be detected (lines 3-5). Fact and rule names are made unique by appending the CAN ID and time stamp. This enables checking security rules for two successive CAN frames coming from  
Figure 15: Monitoring Algorithm.  
the same source. CLIPS executes the security rules and collects the execution results (line 6-7). According to the dynamics of CLIPS rule engine, if a security rule triggers a result (e.g., alert or absence of alert) at any time point, that rule will continue to produce that result for the subsequent time points, which will be considered as a false positive or false negative. Therefore, security rules that have produced a result are removed from CLIPS. The result is saved for further analysis during the production of certificates. (line 9).  
**Method obd_rules_check0**. Upon receipt of a CAN frame, the OBD related data (e.g., speed, coolant temperature, intake air temperature and ambient temperature) is extracted and checked. Fact _OBD_Data_ is updated accordingly using that data, executing the corresponding rule. The end of the method is similar to the algorithm for checking the security rules.  
Monitoring results are aggregated over a period of time and used to produce certificate, following the certificate model presented in Section 3.4. In FIVADMI, a JSON data structure is used to construct the elements of the certificate. JSON is chosen for its lightweight processing and low memory footprint compared to older data structures. Using JSON, a certificate gets updated at the end of each monitoring cycle, spanning over a configurable period of time, during the certification process of a vehicle. Figure 16 shows a skeleton structure with the different elements of a certificate.