# Anomaly Detection for Service-Oriented Business Processes Using Conformance Analysis
## 5 Optimal Process Discovery  
This section illustrates how an ideal model is generated from a highly variable and heterogeneous business process log. This optimal process model most closely approximates the behaviour of cases as they are executed in the event log. Since an optimal process model should support the majority of possible behaviours in an event log, it should  
Figure 5: The process of event log splitting. Figure 6: Cut-off times for end-state prediction. not be over-generalised to allow every behaviour in an actual business process. In the experimental setup, a noise threshold to filter out the lower frequency events is set as 10%. This threshold is to avoid the behaviour of those cases to contribute to process discovery which is less frequent. Several process discovery algorithms are used to play-in the event log of successful cases to discover the process model which correctly represents the ideal behaviour, leading to the successful execution of a business process. This optimal process model tends to represent the behaviour of execution of those instances which directly leads to the success of the process. Yet, there could be some behaviour not captured in the event log which can lead to successful execution and an optimal process model should provide a buffer to accommodate such behaviours. To avoid the representational biases, we used DPN (data Petri nets) for the representation of all models generated through several algorithms during the discovery phase. The quality of the discovered models is vital to be verified as each process discovery algorithm has its strengths and limitations [3]. The quality of any process model can be analysed with the help of four quality criteria: _fitness_, _precision_, _generalisation_ and _simplicity_. As generalisation and simplicity are not easy to quantify using any statistical methods and they are proportional to the fitness and precision, the purpose is mainly served by considering two main quality criteria, presented as below:  
_(a) Fitness_ is formally defined as a measure used to evaluate the quality of the process model by calculating the events mismatch when an actual log is replayed with the discovered process model. If a process model can replay all the traces in the process log without any inconsistencies, it is said to have perfect fitness. The fitness (also referred to as replay fitness) of a process model is defined in [3] as the validity of the conformance of the log events when a replay of the events in the log is performed using Petri net tokens over its discovered model. Equation (2) presents the fitness \(f\) of the trace \(\sigma\) for a given event log \(L\) on pre-discovered process model \(N\). \[fitness(\sigma,N)=\frac{1}{2}\log\left(1-\frac{m}{c}\right)+\frac{1}{2}\log \left(1-\frac{r}{p}\right) \tag{2}\]  
where \(m\) = missing tokens, \(c\) = number of consumed tokens, \(r\) = number of tokens remaining after replay and \(p\) = total number of tokens produced for a Petri net. In Equation (2), \(\sigma\) presents the considered trace of the process log for replaying the log into the process model, and \(\eta\) presents the Petri net model discovered through a miner algorithm. The number of missing tokens \(m\), number of consumed tokens \(c\), number of remaining tokens \(r\) and number of produced tokens \(p\) are all associated with the log \(\sigma\). The first part represents the proportion of missing tokens relative to the number of tokens consumed. The second part calculates the remaining token fraction relative to the total tokens generated through the log. The closer the value of fitness \(f\) to 1, the higher the fitness of the model and the better the conformance related to the considered event log. Fitness is the most vital metric for gauging the quality of the process model [3]. _(b) Precision_ is a measure to quantify the behaviour allowed by the process model. A discovered process model is considered 100% precise if replay only allows the behaviour which is present in the event log.