# Anomaly Detection for Service-Oriented Business Processes Using Conformance Analysis
## 7 Conformance Lifeline  
As seen in an earlier section, the fitness of the unsuccessful cases varies from the fitness of successful cases, showing that there is a behaviour change in the control flow of the failed cases. When this change is checked at several checkpoints during the process execution, a fitness score line is projected, which can be further analysed to provide root cause analysis in the next section. This section presents the difference in fitness score between successful and failed cases as a _conformance lifeline_. The term _'Conformance lifeline'_ is adopted from healthcare where an electrocardiogram (ECG) is used as a test to check a patient's heart's rhythm and electrical activity. In Figure 19, the average fitness scores of successful cases with the failed cases are compared for all the instances belonging to an individual sub log. It can be seen that there is an apparent difference between fitness scores for events at the very start of the process execution. Successful cases had a fitness score of 0.97 compared to 0.88 for the failed cases. This gap further opened up when the process was almost halfway completed. At 50% of the process execution, the overall fitness of the failed cases had a steep degradation. The average fitness score of the failed cases is around 20% less than the score of successful cases. The fitness gap again shrinks back to around 10% near the end of the process. Successful cases present an average fitness score of 83% with a score of 72% for failed cases. Figure 18: A behavioural deviation in failed cases. Screenshot of Multi-perspective Conformance Analysis plugin for ProM Lite 1.3. _Root Case Analysis Using Conformance Lifeline_  
This section provides the usability of the _conformance lifeline_ technique as a root cause analysis to identify abnormalities in the overall event log and also for individual cases during the process execution. The first realisation, in Figure 19, is that the portion of the business process which is under sub-log B is the main contributor to the overall fitness score difference. This information is very straightforward for business users and allows quick improvement measures. Domain experts can identify those activities/events executed during the middle portion of the process. This will help the domain experts to tune the specific portion of the process without changing the overall structure of the process. Furthermore, a deep-dive analysis of failed cases is done in this work to realise the root cause of the fitness score gap. The fitness of each failed case is generated for three sub-logs and presented in the form of a coloured plot in Figure 20, where the fitness of each of the traces from the failed cases is reviewed to look for the trend. All of the instances started with an average fitness of 0.88 with a maximum fitness of 1.0. Except for 20% of the traces, all other traces show a decrease in their fitness score. Some cases terminated at the end of sub log A or sub log B (showing 0 fitness). The rest of the cases showed no fitness improvement in the middle portion of the process. It is also presented in Figure 20 that 832 cases out of a total of 907 in the second phase are below the average fitness of successful cases, presented as a red line. The total number of cases that are identified as failed and yet had a lower fitness value than successful cases is 75. This shows that a decrease in the fitness score allows the prediction of an anomaly with an accuracy of 91.73%. Figure 19: Difference between average fitness of successful and failed instances at each phase of process. Figure 20: Fitness of individual failed cases generated for three sub-logs and presented in the form of a coloured plot. Calculated through Multi-perspective Conformance Analysis plugin for ProM Lite 1.3. As businesses strive to reduce process execution irregularities, the deviation from the ideal business process execution is not acceptable. Additionally, abnormalities in processes may use more resources than anticipated during process planning.