Simulating Petri Nets with Inhibitor and Reset Arcs

Event logs of software systems are used to analyze their behaviour and inter-component interaction. Artificial event logs with desirable specifics are needed to test algorithms supporting this type of analysis. Recent methods allow to generate artificial event logs by simulating ordinary Petri nets. In this paper we present the algorithm generating event logs for Petri nets with inhibitor and reset arcs. Nets with inhibitor arcs are more expressive than ordinary Petri nets, and allow to conveniently model conditions in real-life software. Resets are common in real-life systems as well. This paper describes the net simulation algorithm, and shows how it can be applied for event log generation.


Introduction
Recently, process analytics evolved into an advanced field of computer-based technology. Automated methods have been created to find bottlenecks and inefficiencies in process models of information systems. One particular technology that helps to automate process analysis is process mining [1]. Experts in this technology employ algorithms and methods which use the records of a system behaviour, which are called «event logs» or «system logs». This information can be explored to discover a model of how the real process behaves [1]. An existing process model runs can be aligned to the records of an event log to check if the model conforms to the real system behaviour [2]. The field also provides an expert with method to improve/repair processes and process models. The process simulation methods are also applied in the field of process analytics [3]. Recently, it has been stated that process mining and simulation form "a match made in heaven" [4].
In particular, process model simulation can be applied to look in the future of a process, and to test what-if alternative scenarios possible because of process change. Moreover, the development of process mining algorithms is impossible without sample models and event logs with a suitable characteristics [1]. Sample event logs can be generated using the process model simulation methods [5]- [8]. Process mining and simulation can also be matched in other way. The results of process discovery and conformance checking can be applied to improve simulation models. Various modelling formalisms are employed in the field of process analytics [1], [3]. Among them, the language of Petri nets is one of the most well-established, well-researched, simple, and commonly-used modelling languages [9]. Lots of process discovery and analysis techniques are based on this language [1]. A strength of the Petri net language is that on top of simply defined P/T-nets many extensions have been built. These are high-level Petri nets: Coloured Petri nets [10], Nested Petri nets [11], Object nets [12] etc. Method to simulate Petri nets of various types have been proposed in literature. However, for many types of Petri nets still there are no simulation techniques/tools. This paper presents an approach and a tool to simulate Petri nets with reset and inhibitor arcs. The addition of these arc types improves the net expressiveness significantly. Thus, these nets are used when the process cannot be (conveniently) modelled by P/T-nets. This paper is organized as follows. Section 2 defines models and event logs. In Section 3 the main contribution is presented: algorithms to simulate Petri nets with inhibitor and reset arcs. These algorithms are implemented in the tool which is described in Section 4. Finally, Section 5 concludes the paper.

Petri Nets and Event Logs
In this section, we define process models and event logs. Let ℕ denote the set of all non-negative integers, and ℕ = ℕ\{0}.

Ordinary Petri nets
Petri nets are directed bipartite graphs which allows for modelling and representation of processes in information systems [13]. More formally, an ordinary Petri net is a triple = ( , , ), where and are two disjoint sets of places and transitions, and ⊆ ( × ) ∪ ( × ) is a flow relation. As graphs, Petri nets have convenient visual representation. Fig. 1 shows an example model. Labels are placed inside the transition boxes. An Petri net can contain invisible (silent) process actions which are labelled with . Labels are assigned to transitions via a labelling function : → ∪ { }. A state of an ordinary Petri net is called its marking. It is a function ∶ → ℕ assigning natural numbers to places. In figures, a marking can be designated by putting ( ) black tokens into a place of the net. By we denote the initial marking. For example, the initial marking of the net from Fig. 1 consists of a single token in the place . A transition represents an activity of a process. It is enabled in a current marking if in each of its input places (for ∈ input places are • = { | ( , ) ∈ }) there enough tokens, that is ∀ ∈ • : ( ) ≥ 1. An enable transition may fire that changes a marking of the net. It consumes tokens from the input places, and produces tokens to output places (for ∈ input places are • = { | ( , ) ∈ }). Consider a model from fig. 1: is the only enabled transition in the initial marking. It may fire, that corresponds to an occurrence of activity "A". Then, the transition consumes a single token from and produces tokens to and . Fig. 2 illustrates this firing. The firing is local, each transition fires independently from other transitions.

Petri nets with Inhibitor and Reset Arcs
In this paper, we consider Petri nets with arcs of two additional types: reset and inhibitor arcs. These nets also contain places, transitions, and ordinary control flow arcs. A labelled Petri net with weights, inhibitor and reset arcs (WIR Petri net) is a tuple = ( , , , , , , ), where  ( , , ) is an ordinary Petri net,  ∈ → ℕ is an arc weight function,  ⊆ × is a function defining reset arcs,  ⊆ × is an inhibiting relation,  and : → ∪ { } is a labelling function. Fig. 3 shows an example WIR Petri net.

Fig. 3. A WIR Petri net
A reset arc removes all tokens from the place no matter of their number. These arcs also called clear arcs [14]. In Fig. 3, there is a reset arc from the place to the transition labelled with "C". Reset arcs are denoted with double arrows at the end. Note that the net contains a loop of two actions "A" ( ) and "D" ( ). The possible sequence of firings is < , , , , , , >. Before the last step, will contain 3 tokens all of which will be removed by the firing of . An inhibitor arc [15], [16] can be from a place to a transition. This transition cannot fire if there is a token in place connected with the transition using an inhibitor arc. ∘ = { | ( , ) ∈ } denotes the set of inhibiting places for . That is, an inhibiting place allows to prevent the transition firing. Transitions consume no tokens through inhibitor arcs. Inhibitor arcs are shown with small circles instead of arrows at the end. In Fig. 3, there is a reset arc from the place to the transition labelled with "B". Thus, can not fire if there is a token in no matter how many tokens are in . The whole part of the model that consists of places and , transitions and is a switch with two possible states: open (there is a token in ) / closed (there is a token in ). The firing of closes the switch and deprecates the firing of . Thus, only is able to clear tokens from the place if there is a token in . The firing of will end the process, because it will consume and remove all tokens from the upper part of the net. The firing of opens the switch. Then, may consume tokens from independently of tokens in other places. Note that the arc from to has a weight of 2. Thus, each firing of consume exactly 2 tokens, and can not fire if there is only one token in . Note that a particular WIR Petri net can contain zero number of reset and inhibitor arcs. Marking of a WIR Petri net is defined in the same way as for an ordinary Petri net. But the firing rule is slightly different for WIR Petri nets. Each marking change is called step. In this paper, we assume that each step consists of a single transition firing. The step from Fig. 2

Event Logs
In this paper, we apply process model simulation to generate event logs with records of the behavior.
We define an event log as a finite multiset of traces ∈ ℬ( ) 1 . A trace ∈ * is a finite sequence of events from the set . Note that transitions of a WIR Petri net are labelled with elements of . The only transitions which firing leaves no events are silent -transitions. Technically, we record the event logs in XES (Extensible Event Stream) format 2 that will be considered in more detail in Section 4.

Petri Net Simulation Algorithm
This section describes the algorithm to simulate labelled WIR Petri nets.
The main idea of the algorithm is to iterate over all transitions and fire one of them at each iteration, recording corresponding events to the log. This procedure is performed in the main generating function called generateTrace (see Algorithm 1). This algorithm works as follows. We have maxIterations attempts to reach the final marking of the net. By default this number is 10. The function moveToInitialState initiates the trace generation by setting a marking of the to . Then, we create an empty trace by calling createTrace. At each step of the main loop, the algorithm chooses an enabled transition in the chooseNextTransition, and fire it (function fire). The function fire changes a marking of the net and writes an event to the trace. Then we call the function isCompleted to check if we reached the final marking and update replayCompleted. This loop iterates until we reach the final marking (replayCompleted = true) or exceed the specified limit of steps for one trace maxNumberOfSteps. When we cannot find an enabled transition which is ready to fire, we clear the unfinished trace and begin a new attempt. If no one of 10 attempts succeeded, we return NULL which will be recorded as an empty trace to the event log. Note that there is a setting of the prototype tool that removes all empty and unfinished traces. The chooseNextTransition function selects an enabled transition using a specified rule. The most basic implementation of this function is shown in Algorithm 2. Here, the random transition among all enabled and noise transitions is selected.

Algorithm 2. Looking for the next transition
This algorithm is based on the algorithm for ordinary Petri nets [17], and thus, is able to add noise to the event log. More complex rules to select the enabled transition can be applied. For example, priorities of preferences can be assigned to the transitions which affect the order of their firing. If there is no enabled transition, then NULL is returned. To check if a transition is enabled, we ensure that all input places connected with with the help of ordinary arcs have enough tokens. Besides that, we check that places connected with with the help of inhibitor arcs don't contain any tokens. Reset arcs don't affect if a transition is enabled or not. Algorithm 3 shows how this is done.  for arc in transition.inputArcs do 3: arc.place.consumeToken(arc.weight); 4: end for 5: for arc in transition.inputResetArcs do 6: arc.place.consumeAllTokens(); 7: end for 8: 9: log transition to trace or perform some noise event 10: 11: for arc in transition.outputArcs do 12: arc.place.produceTokens(arc.weight); 13: end for 14: end function

Prototype Tool
The presented event log generation algorithm has been implemented as a prototype tool. It is written in Java and Kotlin programming languages. In this section, we consider the tool. The tool consists of two parts: Generation Setup unit and Generation unit.

Preparing for generation
In preparation part we receive settings from the GUI (see fig. 4) or read a JSON (see fig. 5) file. Settings from JSON are validated. Then we load the model from a PNML 3 file and prepare this model for generation. Inhibitor and reset arcs could be either specified in settings file, or loaded from the PNML file. The initial and final markings are loaded in the same manner. After that we create an instance of special class GenerationHelper, which encapsulates the main code for choosing transitions, looking for enabled transitions, handling noise and artificial log events if it is needed. There are different helpers for simple generation, generation with priorities, and generation with time. Also, we convert each transition to a special loggable transition-related class which is used during generation. They contain methods of event recording to a trace. Such a class also consumes tokens from input places and produces tokens to output places. Methods to check if a transition is enabled are also here.

Preparing for generation
A singleton class is used to record the event log. We setup this logging class. It uses the OpenXES 4 library with the help of which we can write XES log files. The XES format is common for the field of process mining [1]. OpenXES library creates a separate file for each log. A fragment of the example output in XES file is shown in fig. 6. This example contains two traces with names "Trace 4" and "Trace 5". These names should be unique. The first trace is of the three events: "B", "D", and "D". Note that XES is XML-based and is easyto-read for a machine or a human. Then we use a Generator class to launch the main generation method (see Algorithm 1), passing a generationHelper to this class.

Tool Usage
Let us test our tool on the model from the fig. 7. The initial marking consists of four tokens (shown as black dots): one token lies in place2, one is in place5, and two tokens are in place1. Our goal is to reach the final marking (shown as green dots): two tokens in place7, and one token in place6.
Transition C is enabled only when place place6 is empty. C consumes 2 tokens from place4 and produces a token to place7. Transition B removes all tokens in places place1 and place2. When this transition fires, it consumes 4 tokens from place4 and produces a token to place7. Thus, B can not fire before A. At each step either X or Y is enabled, so these transitions may produce a trace of any length. We set-up our tool to remove unfinished traces and limited max number of steps to 10. The result of the generation is shown in fig. 8.  Let us look at some trace, for example: < , , , , , >. First fired transition was A, and it produced 6 tokens to place4. Then X fired. It consumed a token from place5 and produced one to place6. C cannot fire in this marking. Thus, B fires. 4 of 6 tokens was consumed from place4, and one token produced to place7. Then Y fired and «opened» C. C has been fired just after Y was fired, when a token has been removed from place6. B and C were fired once each, and produced 2 tokens in total to place7. place1 and place2 were cleared by B. The last event was X, which placed a token to place6. At the end of this run all tokens reside in the final marking.

Conclusion
In this paper, we have presented the algorithm to simulate a process model in the form of weighted labelled Petri net with inhibitor and reset arcs. This algorithm can be applied to generate event logs from the event log. Proposed algorithm continues the previous works on Petri net simulation with the purpose of generating artificial event logs. The prototype implementation is based on Gena tool 5 . We have plans for future work. Firstly, we plan to comprehensively evaluate the proposed algorithm on artificial and real-life process models. For now, we just tested it on sample models to check algorithm validity. Secondly, we also plan to improve the prototype implementation and make it stable and usable. Thirdly, Gena is able to simulate timed process models, models with resources, data, add noise to an event log [8], [17]. Recently, an extension for Gena to simulate the multi-agent system has been proposed [18]. We plan to merge these extensions and the algorithm presented in this paper. Then, it will be possible to simulate WIR Petri nets with time/resources, and data.