Process Mining leverages event data to discover, analyze, and optimize business processes. Consequently, the availability and quality of event logs is crucial for the applicability as well as the development of process mining algorithms. However, obtaining such event logs from real-world scenarios is limited and costly. In this paper, we present an approach for simulating event logs from object lifecycle processes. Overall, the approach is capable of simulating event logs for object lifecycle processes that may be used to validate process mining algorithms.
Process mining is becoming more and more important for enterprises, as it provides a transparent and data-driven view on operational workflows while also offering insights into inefficiencies, bottlenecks as well as possible compliance issues. In general, process mining leverages event data to discover process models, check the conformance between models and event logs, or enhance the model [1]. In real-world scenarios, such event logs are often unavailable, inappropriate, or costly to obtain, consequently hindering the development and testing of new process mining algorithms [2].
In other domains, simulation provides a possible solution towards this problem by substituting or complementing real-world with simulated data [3,4,5].
In object-centric scenarios, the behavior of objects is defined in terms of object lifecycle processes. At runtime, however, objects may deviate from the behavior specified in object lifecycle processes due to flexibility [6]. Such deviations may include removing or adding both states and steps as well as executing them in a different order. Consequently, the simulation of event logs must account for such flexible behavior to ensure that the event logs are comparable to their real-world counterparts.
Overall, the simulation of event logs from object lifecycle processes presented in this paper facilitates the application and testing of process mining algorithms in object-centric scenarios by providing suitable event logs.
The paper is structured as follows: Section 2 introduces object lifecycle processes. Section 3 describes the approach for simulating event logs. Section 4 evaluates the presented approach, and Section 5 discusses related work. Finally, Section 6 summarizes the paper and provides an outlook.
In object-centric processes, the behavior of objects is specified in terms of a state-based object lifecycle process. Fig. 1 depicts the object lifecycle process for object Submission. An object lifecycle process comprises the states of the object as well as state transitions (see states Edit, Submit, Rate, and Rated in Fig. 1). Each state, in turn, comprises several steps (see Exercise, E-Mail, and Files in State Edit in Fig. 1) defining which object attributes are required before completing a state and transition to the next one. Note that we also support predicate steps to enable different execution paths through the object lifecycle process. During process execution, multiple objects (of the same or different type) may exist, and their instances are dynamically generated [7]. For each of these objects, their different object behavior may be observed on both the state level (i.e., how does an object change between its states), and the step level (i.e., how is data provided). Tab. 1 summarizes the guided, tolerated, and deviating behavior on both granularity levels.
On the state level, guided behavior corresponds to the object reaching its end state without returning to a previous state using a backwards transition. Tolerated behavior, in turn, includes backwards transitions. Deviating behavior on the state level is associated with skipping states (i.e., non-reachable) or reaching states not specified in the object lifecycle process model.
On the step level, guided behavior is observed if the steps of a state are provided in the order specified by the object lifecycle process. Tolerated behavior, in turn, only requires that all steps are provided (i.e., the order is not relevant). Deviating behavior on the step level includes skipping steps (i.e., not providing certain attributes) or providing additional steps in a particular state of the object lifecycle process model.
Object Behavior on state and step level [8] Level Behavior Description
The end state is reached without following any backwards transitions. Tolerated The end state is reached, but backwards transitions were chosen. Deviating The lifecycle transitions to a non-reachable or unspecified state during its execution.
Step
All steps of a lifecycle state are provided according to the pre-specified order. Tolerated All steps have been filled prior to state completion. Deviating Steps have been skipped or additional steps have been added.
The event log simulation must be capable of simulating guided, tolerated, and deviating behavior on both the state as well as the step level (see Tab. 1). To be more precise, simulated event logs must be able to represent all 3 behaviors regarding the state as well as the step level. Due to their well-defined syntax and replay capabilities, we decided to represent object lifecycle processes in terms of Petri nets [9].
We enable the simulation of different behavior by representing each object lifecycle process as two Petri nets. One of these Petri nets corresponds to the guided behavior. In other words, this Petri net only allows for the object lifecycle process to be executed exactly as modeled. The other Petri net represents the tolerated behavior by allowing for additional (tolerated) behavior. This behavior includes, for example, providing object attributes in an order different from the one specified by the object lifecycle process model, while also ensuring that all required attributes are provided. The representation of object lifecycle processes in terms of Petri nets enables the application of token-based simulation on both nets.
Figs. 2 and 3 depict two Petri nets generated for state Edit of object Submission (see Fig. 1). In a nutshell, we represent guided behavior by accounting for the sequence in which steps (and states) are modeled in the object lifecycle process, whereas we allow for tolerated behavior using an AND-split syntax within the state. Note that, we only depict the guided and tolerated nets for state Edit of object Submission, however, we concatenate the guided and tolerated Petri nets for each state to represent the state level and include backwards transitions if necessary.
After representing object lifecycle processes, we generate traces for individual objects. Alg. 1 describes the generation of traces in pseudocode. First, we check which transitions are enabled by the Petri net and check if the current marking equals the final marking. If not, we randomly choose an enabled transition, add it to the trace, and execute it. This updates the current marking. The trace generation terminates if no more enabled transitions exist, or the final marking is reached. In the latter case, the trace is added to the list of traces. Otherwise, the trace is discarded. This is repeated while the counter is smaller than the number of requested traces. In other words, we apply a token-based simulation in which tokens are propagated through the Petri net and the transitions passed are recorded as events in the event log. In a post-processing step, deviating behavior may be introduced to the generated event log by adding or removing corresponding events (i.e., writing (additional) attributes or transitioning to (additional) states).
The evaluation of the presented approach for simulating event logs from object lifecycle processes is two-fold. First, we implemented a proof-of-concept prototype capable of simulating event logs from object lifecycle processes and applied it to two different scenarios (E-learning and Recruitment). Second, we checked the conformance of the simulated event logs with the models used for their generation and calculated resulting fitness values using alignments [8,10].
On a scale from 1 (perfect fitness) to 0 (bad fitness), fitness measures to which degree a model allows for the behavior recorded in an event log. The proof-of-concept prototype as well as the event logs simulated during the evaluation are publicly available1 .
For every object in both the e-learning and recruitment scenario, we simulated 18 event logs (i.e., one log per possible configuration), each comprising 100 traces. In total, this results in 198 event logs from 11 different objects.
Tab. 2 describes the conformance categories into which the simulated traces are categorized for object Submission [8].
The event logs simulated for guided behavior configuration show the respective behavior in 100% of cases. Moreover, the event logs generated for the tolerated behavior show guided behavior in 17% of the cases and tolerated behavior in 83 % of cases. The inclusion of guided behavior within tolerated behavior is intended, as it generalizes guided behavior. Regarding deviating behavior (i.e., skipping or adding states and steps) all traces simulated with the respective configuration are correctly simulated with deviations. We further checked conformance of the simulated event logs regarding the state (i.e., how does the object instance change states?) and the step level (i.e., how are attributes written?). On the state level, this allows further verifying the deviations (e.g., additional states, unspecified backwards transitions, or state changes not allowed by the object lifecycle process model). We checked the conformance between the object lifecycle process model and the event logs simulated with additional states as well as steps in every trace on both the state and step level individually (see Tab. 3). In other words, the event log contained deviations on both the state and step level. Note that we only show the results for state Edit of object Submission for brevity. Overall, the approach for generating event logs from object lifecycle processes is capable of reproducing all possible behavior based on the specification selected in the proof-of-concept implementation.
The approach presented in this paper is related to the generation of event logs. [11] presents the PURpose-guided Log gEnerator (PURPLE) capable of generating event logs conforming to a process model (i.e., a BPMN model or Petri net), including noise (i.e., skipping, adding, or reordering events). In contrast, the presented approach considers granularity and uses data-driven object behavior specified in object lifecycle process models as input.
[12] introduce the Data Aware event Log Generator (DALG) that can generate event logs from a Petri net. DALG offers several capabilities for temporal constraints and writing variables, however, no capabilities regarding deviations in the event logs are available.
The Straightforward Petri Net-based Event Log Generation plugin available in ProM [13] generates event logs based on Petri nets using token-based simulation. In contrast to the presented approach, it does not differentiate between guided and tolerated behavior and does not generate deviating event logs.
Event log generation in the context of Internet of Things devices is presented in [2]. A Petri net is used to generate guided event logs as well as event logs containing noise. In contrast to the presented approach, different granularity levels are not supported.
[14] can generate event logs from BPMN models and is available in the process mining framework ProM. The presented approach leverages data-driven object lifecycle processes rather than activity-centric BPMN models.
Other approaches leverage relational databases to generate event logs based on the data available in the database [15]. In this approach, a case table with a unique case ID has to be chosen. Users then recommend other tables that could provide additional events. These tables, however, have to contain the case ID as foreign keys. The approach presented in this paper can produce guided, tolerated and deviating behavior on both state and step level and it may generate event logs of different objects as well as multiple instances of each object.
This paper presented an approach for simulating event logs from object lifecycle processes, while considering the behavior of objects on both the state and the step level. The approach is capable of simulating guided, tolerated, and deviating object behavior and document the behavior in event logs using multiple Petri nets derived from object lifecycle processes. It has been evaluated using a publicly available proof-of-concept implementation which has been successfully applied to simulate event logs from different scenarios. Event logs simulated using the presented approach reliably conform with the specification set out, facilitating the development and testing of new process mining algorithms by providing suitable event logs for a variety of scenarios. In future work, we plan to extend the approach in multiple directions. First, we want to incorporate coordination constraints between objects of different types (i.e., object A may only reach state š š“ if object B is in state š šµ ). Second, the actual object attribute values documented in the event log are currently generic placeholders. We plan to replace them with more realistic, process-specific values. Finally, we plan to provide the event logs in additional formats (e.g., OCEL [16] or XES [17]) instead of the currently used CSV-format.
Acknowledgments This work is part of the ProcMape project, funded by the KMU Innovativ Program of the Federal Ministry of Education and Research, Germany (F.No. 01IS23045B)