DICER 2.0: A New Model Checker for Data-Flow Errors of Concurrent Software Systems

: Petri nets are widely used to model concurrent software systems. Currently, there are many different kinds of Petri net tools that can analyze system properties such as deadlocks, reachability and liveness. However, most tools are not suitable to analyze data-ﬂow errors of concurrent systems because they do not formalize data information and lack efﬁcient computing methods for analyzing data-ﬂows. Especially when a concurrent system has so many concurrent data operations, these Petri net tools easily suffer from the state–space explosion problem and pseudo-states. To alleviate these problems, we develop a new model checker DICER 2.0. By using this tool, we can model the control-ﬂows and data-ﬂows of concurrent software systems. Moreover, the errors of data inconsistency can be detected based on the unfolding techniques, and some model-checking can be done via the guard-driven reachability graph (GRG). Furthermore, some case studies and experiments are done to show the effectiveness and advantage of our tool.


Introduction
Presently, concurrent software systems are widely used in our daily life. In particular, they are successfully applied in so many safety-critical scenarios, e.g., health-care, intelligent traffic, and stock exchange. Thus, how to guarantee the correctness of concurrent systems has become a bone of contention for people's lives and properties. In reality, the correctness of concurrent systems is closely related with control-flows and data-flows. However, the most existing studies mainly focus on the error detections of control-flows such as deadlocks, livelocks and compatibility [1][2][3]. In fact, concurrent systems are vulnerable to data-flow errors, e.g., missing data, lost data and data inconsistency [4][5][6]. Although the testing-based methods can detect these errors, they need to design a series of test cases to cover as many execution paths as possible. Due to the difficulty in the completeness of test cases, it is hard for these methods to guarantee a concurrent system error-free.
The Petri net-based model-checking is a prominent method/technique for analyzing data-flows of concurrent software systems. This is because Petri nets [7][8][9][10] have a great capability of explicitly specifying parallelism, concurrency and synchronization [11,12]. Thus, many different kinds of Petri nets are used to check data-flow errors, such as algebraic Petri net (or extended concurrent algebraic nets, ECANets), predicate/transitions net (PrTNet), and colored Petri nets (CPN), etc. Kheldoun et al. [13] transformed BPMN (Business Process Model and Notation) models of complex business processes into to Recursive ECATNets (RECATNets), which combine the expressive power of abstract data types with recursive Petri nets. Furthermore, they used rewriting logics to check proper terminations and LTL properties. Buchs et al. [14] proposed Concurrent Object-Oriented Petri To support and improve the above previous work [5,29], we develop a new model checker DICER 2.0. Currently, there are many Petri net tools [40][41][42] such as PIPE, Snoopy, CPN Tools, Protos, and ProM. These tools can support different kinds of Petri net modeling, e.g., Place/Transition nets [7], Timed Petri nets [9], Stochastic Petri nets [10] and High-level Petri net [8]. Furthermore, they can be used to do structural analysis, generate condensed state spaces, construct reachability graphs, and analyze place/transition invariants. However, most of these tools fail in unfolding a Petri net. Although Mole, ERVunfold and Punf can do this work and conduct some model-checking (e.g., deadlocks, reachability and coverability), they cannot support the modeling and checking of data-flows that have been considered in some abstracted models, such as WFD-net [43] and PD-net [5]. Therefore, the most existing Petri net tools are not suitable to analyze data-flow errors of concurrent systems especially based on the unfolding techniques. The specified comparisons between some Petri net tools are summarized as Table 1.
In this paper, we develop DICER 2.0 to analyze data-flows of concurrent systems. Specifically, we can use this tool to model concurrent systems by general Petri nets, WFDnets and PD-nets. Meanwhile, we can draw, edit, import and export these models in DICER 2.0. Moreover, the errors of data inconsistency can be detected based on the unfolding technique of PD-nets, and some GRG-based model-checking can be done in our tool. This paper is organized as follows. Section 2 presents some basic notations. Section 3 introduces our model checker DICER 2.0. Section 4 gives two case studies on concurrent systems. Section 5 conducts a group of experiments to show the advantages of our tool. The last section concludes this paper.

Basic Notations
A net is a triple N = (P, T, F), where P and T are two finite and disjoint sets, and they are called place and transition, respectively. F ⊆ (P × T) ∪ (T × P) denotes a flow relation. A marking of a net is a mapping function m: P → N, where N is a set of non-negative integers. In details, we use a multi-set to represent a marking. A net N with an initial marking m 0 is called a Petri net Σ [7] , i.e., Σ = (N, m 0 ). Given a node x ∈ P ∪ T, its preset and postset are respectively denoted by • x and x • , where • x = {y | (y, x) ∈ F} and x • = {y | (x, y) ∈ F}.
As a particular class of Petri net, workflow net (WF-net) is widely used to model control-flows of concurrent systems. Definition 1. A net N = (P, T, F) is a WF-net (workflow net) [43,44] if (1) there exists only one source place i and one sink place o satisfying • i = ∅ and o • = ∅; and (2) each node x ∈ P ∪ T is on a path from i to o.
Besides modeling control-flows of concurrent systems, we can use a net with some data information to formalize data-flows. Definition 2. A 7-tuple N =(P, T, F, D, Read, Write, Delete) is a net with data (D-net) [5], if (1) (P, T, F) is a net; (2) D is a finite set of data elements; (3) Read: T → 2 D is a labeling function of reading data; (4) Write: T → 2 D is a labeling function of writing data; and (5) Delete: T → 2 D is a labeling function of deleting data.
Given two nodes x, y ∈ P ∪ T in an acyclic D-net N =(P, T, F, D, Read, Write, Delete), (1) x and y are in causality relation if the net N contains a path from x to y, which is denoted by x y. In particular, x ≺ y if x = y; (2) x and y are in conflict relation if ∃ t 1 , t 2 ∈ T: t 1 x, t 2 y and • t 1 ∩ • t 2 = ∅, which is denoted by x#y; (3) x and y are in backward-conflict relation if x • ∩ y • = ∅, which is denoted by x #y ; or (4) x and y are in concurrency relation if ¬(x ≺ y ∨ y ≺ x ∨ x#y), which is denoted by x co y, i.e., x and y are neither in causality relation nor in conflict relation.
In an OD-net, places and transitions are called conditions and events, respectively. In general, we use O = (B, E, G, D, Rd, Wr, De) to denote an occurrence net with data for convenience. With respect to this formalization, B, E and G are conditions, events and arcs, respectively. Rd, Wr and De are labeling functions of data operations (read, write and delete), respectively.

DICER 2.0
DICER 2.0 is developed to model and analyze the control-/data-flows of concurrent systems. It is the derivative version of our model checker for detecting data inconsistency [45]. Currently, we can use it to do many more model checking.

The Modeling of Concurrent Systems Based on the Petri Net with Data Information
As is well known, we usually use read/write arcs, data places, labeling functions of data operations and guards to formalize data-flows of concurrent systems [4,19,46]. In these formalizations, Petri nets such as DFN [19], PN-DO [47] and Awad method [20] mainly use data places and flow relations to model data operations, e.g., read, write and delete. Although these methods are suitable to accurately model the control structures of data-flows, it lacks formal semantic descriptions about shared reading and overwriting. Contextual net [46] can describe the concurrent (shared) reading operation by read arcs, but it needs extra data places and flow relations to formalize data-flows, and thus may be much more complex [48].
Compared with the above modeling methods, WFD-net [4,49] has a prominent advantage. It combines the traditional workflow nets with conceptual data operations, and uses labeling functions and guards to describe data operations and routing conditions, respectively. Thus, it is not only greatly suitable to model the control-flows and data-flows of a concurrent system but also much smaller than other Petri nets with data-operation arcs (e.g., contextual net and PN-DO) in the scales of nodes and arcs [48]. Now, this modeling method has been widely applied to various model-checking, e.g., detecting data-flow errors [4] and data inconsistency in the migrations of service cases [28], checking data inaccuracy [50] and completed requirements [27], and verifying may/must soundness of workflow systems [25]. (1) (P, T, F) is a WF-net; (2) D is a finite set of data elements; (3) Read: T → 2 D is a labeling function of reading data; (4) Write: T → 2 D is a labeling function of writing data; (5) Delete: T → 2 D is a labeling function of deleting data; (6) GD is a finite set of guards that are related with data elements in D; and (7) Guard: T → GD is a labeling function of assigning guards to transitions.
Referring to the labeling functions of data operations in WFD-nets, a Petri net with data (PD-net) [5] is proposed, i.e., a PD-net Σ is a D-net N with an initial marking m 0 , i.e., Σ = (N, m 0 ). Although this modeling method neglects the formalization of guards, it is much suitable for generating the unfolding of Peri nets with data information due to its simple structural semantics. For example, Σ is a WFD-net in Figure 2a, while Σ is a PD-net in Figure 2c,d is its unfolding. DICER 2.0 supports the modeling of WFD-nets and PD-nets. By this tool, we can formalize the control-/data-flows of concurrent systems. Furthermore, it provides a series of model-checking based on the guard-driven methods and unfolding techniques.

The Model-Checking Based on the GRG of WFD-Nets
The classical reachability graph [25] is a fundamental method for analyzing a WFDnet. However, this method easily suffers from the problems of state-space explosion and pseudo-states (or illegal states) due to its guard evaluations and their exclusive relations. Hence, we proposed a Guard-driven Reachability Graph (GRG) in our previous work [29], and now achieve this function in DICER 2.0.
To construct a GRG of WFD-nets, we define a state as a weak configuration in DICER 2.0, which includes a marking and some evaluations of data and guards. (1) (P, T, F) is a WF-net, and m is its marking; (2) a mapping function σ : D → { , ⊥} assigns a defined value ( ) or an undefined value (⊥) to each data element; and In DICER 2.0, we also define the basic enabling/firing rules of WFD-nets based on weak configurations. Definition 6. (Enabling/firing rules) Given a WFD-net N =(P, T, F, D, GD, Read, Write, Delete, Guard) and its weak configuration c = m, σ, η , a transition t is enabled at c and denoted by where the function Varb is to obtain all variables in a guard.
After firing a transition t at the weak configuration c, a new weak configuration c = m , σ , η can be generated, i.e., c[t c , where Let c 1 and c 2 be two weak configurations of a WFD-net. c 2 is may-reachable from c 1 , denoted as Furthermore, a set of may-reachable weak configurations from c 1 is denoted by R(c 1 ). Based on may-reachable sets and enabling/firing rules, we can formalize a GRG in DICER 2.0 as follows.

Definition 7.
Given a WFD-net N =(P, T, F, D, GD, Read, Write, Delete, Guard) and its initial weak configuration c 0 , GRG(N) = (V + , E + , + ) is a guard-driven reachability graph (GRG), where For example, Figure 2b shows a guard-driven reachability graph of Figure 2a, where g 1 and ¬g 1 are two exclusive guards, Since a GRG of a WFD-net contains all execution information of a concurrent system, we can traverse its reachable weak configurations by DICER 2.0 to do some model-checking such as deadlocks [51] and proper completeness [27], i.e., given a WFD-net N and its guard-driven reachability graph GRG(N), o is its sink place and c = m, σ, η + is a weak configuration such that c ∈ R(c 0 ).  Figure 2a is not properly completed since the final weak configuration is not reachable from the initial weak configuration and the sink place o has no token at this time.

The Model-Checking Based on the Unfolding Techniques of PD-Nets
Besides the model-checking based on GRGs of WFD-nets, DICER 2.0 can be used to detect errors of data inconsistency based on the unfolding techniques of PD-nets. We first define branching processes in DICER 2.0. (1) h(E) ⊆ T and h(B) ⊆ P; (2) for each event e belonging to E, the restriction of h onto • e (resp., e • ) is a bijection between • e and • h(e) (resp., between e • and h(e) • ); (

Given two branching processes
All branching processes of a PD-net Σ forms a partial order set w.r.t the binary relation of prefix, and its greatest element is Unfolding [46], which is denoted by Un f (Σ). Please note that the unfolding of a PD-net is also an occurrence net with data. Although the unfolding of a PD-net records its running information, it may be infinite if there exists an infinite execution path. Therefore, it needs to be truncated so as to get a finite complete prefix (FCP) [52]. In DICER 2.0, we refer to the ERV method [52] to cut off the unfolding of PD-nets, and then generate its FCP.
As a matter of fact, ERV method does not consider the Petri net modeling with data information. Moreover, it does not specify a highly efficient calculations on configurations, cuts and cut-off events. This is mainly caused by the following two facts. On the one hand, the most computing methods of configurations and cuts need a lot of repetitive calculations. On the other hand, once some new events are added into a given finite prefix, these methods usually match up them with all existing events and determine whether they are cut-off events or not. In order to solve these problems, DICER 2.0 uses recursion formulas and contextual information of events to compute configurations, concurrent conditions and cuts. Meanwhile, it uses backward conflicts to guide the calculations of cut-off events.
After generating an FCP of a PD-net Σ in DCIER 2.0, we can use its matrix manipulations to detect data inconsistencies since it contains the same behavioral information as the reachability graph of Σ (i.e., the completeness property [5] of FCP). In details, we first get an incidence matrix of this FCP, and then use Warshell algorithm to calculate its causality matrix J # un f (Σ) . Afterwards, we obtain a conflict matrix J # un f (Σ) according to the mathematical definition of conflicts. Then, a concurrency matrix J co un f (Σ) is calculated by J < un f (Σ) and J # un f (Σ) , i.e., two events are in concurrency relation if they are neither in causality relation nor in conflict relation, i.e., J # un f (Σ) = [a (i,j) ] n×n , J co un f (Σ) = [a (i,j) ] n×n and J co un f (Σ) = [a (i,j) ] n×n , where e i , e j ∈ E (i, j ∈ N), and Based on the concurrency matrix J co un f (Σ) , we can check the errors of data inconsistency in Σ, i.e., there exists an error of data inconsistency if two concurrent events e 1 and e 2 have some data operations on a share data element, i.e., (Read(e 1 ) ∪ Write(e 1 ) ∪ Delete(e 1 )) ∩ (Write(e 2 ) ∪ Delete(e 2 )) = ∅.
For example, Figure 2d is an FCP of the PD-net in Figure 2c. Its related matrix calculations are conducted as shown in Figure 3. From this concurrency matrix, we can find that e 1 , e 2 and e 3 are three concurrent events. Furthermore, they suffer from the errors of data inconsistency because Write(e 1 ) ∩ Read(e 2 ) ∩ Write(e 3 ) = ∅.

The Implementations of DICER 2.0
Corresponding to the specified modeling and checking methods, we now introduce the basic framework and implementations of DICER 2.0. Figures 4 and 5 show the user interface (UI) and basic functions of DICER 2.0, respectively. Its framework is made up of two modules: graphical user interface (GUI) and model checker (MC), as shown in Figure 6. These two modules respectively correspond to the menus of drawing and model-checking in Figure 4.

•
In the module of graphical user interface, Place/Transition nets, WFD-nets and PDnets can be imported, exported, drawn and edited. The labeling functions of data operations (e.g., read, write and delete) can be added, deleted and modified in DICER 2.0. Moreover, different kinds of Petri nets are imported and exported in the format of an extended Petri Net Markup Language [53] (ePNML). In fact, ePNML provides a common interchange format for all types of Petri nets based on XML, and defines specifications of data operations and guard functions. As shown in Figure 7, the label isData formalizes data-flows of concurrent systems, including labeling functions of read, write, delete and guards. Since ePNML is an XML-based document, we can create or parse these Petri nets according to some configuration files, e.g., GenerateOb-jectList.xsl and GeneratePNML.xsl.

•
In the module of model checker, Place/Transition nets and PD-nets can be unfolded, and then we can get their FCPs. As for the FCPs of PD-nets, we can use their matrix calculations (e.g., causality matrix, conflict matrix and concurrency matrix) to find out all concurrent events and then check errors of data inconsistency. Additionally, both classical reachability graphs and guard-driven reachability graphs of WFDnets can be constructed in DICER 2.0. Furthermore, they are used to analyze some data-flow properties of concurrent systems, e.g., deadlocks, data inconsistency and soundness [29].    DICER 2.0 is developed-based on Platform Independent Petri Net Editor (PIPE) [40], which is an open source and graphical tool for drawing and analyzing Petri nets. In details, it is made up of a series of Java classes. Figure 8 shows the main hierarchy of these classes, which includes some flow information, inheritance relations, interfaces and methods.

•
The class DataLayer acts on the Petri net modeling of concurrent systems. It can be used to create, edit (e.g., add, move, or modify), import and export a PD-net or a WFD-net. In this class, the method getNewData() is to obtain some information about the Petri net components of FCPs such as events, conditions and arcs. • The class Unfolding is developed to unfold a PD-net or a Place/Transition net. Their FCPs can be generated by the method of unfolding_PDNet(visual, "ERV", null). In this Java method, the parameter visual indicates whether an FCP needs to be displayed in the software interface, and the parameter ERV means a selected unfolding method, such as ERV, merged process, and directed unfolding. • The class ReachabilityGraphGenerator is used to construct a guard-driven reachability graph of WFD-nets, and the methods generateGraph() and run(DataLayer) correspond to this function. • The class InconsistentData is developed to check errors of data inconsistencies based on the unfolding of PD-nets, and the method detectISData() achieves this work in details. • The classes GuiView and GuiFrame are used to create the front end, and display the software interface of DICER 2.0. • A homomorphism from conditions to places (or from events to transitions) is represented by a hashmap. Its keys and values are in the form of Place, Place or Transition, Transition , where Place and Transition are Java classes of Petri net components. Additionally, in order to improve the unfolding efficiency of PD-nets, we use some linked hash tables to store the contextual information of events and concurrent conditions, e.g., local configurations, pre/post-sets and cuts.

Case Study
To show the application scenarios of DICER 2.0, we give the following case studies.

Case _1: Intelligent Traffic Light System (ITIC)
Our first case study is conducted on an intelligent traffic light controller (ITIC) [54,55] for a North-South and East-West intersection. In this case study, the North-South (NS) is a main road, and the East-West (EW) is a rarely used country road. The North-South traffic light is always GREEN if the sensor of East-West Road is not activated. Otherwise, the North-South light will change from GREEN to YELLOW so as to give way to the East-West traffic. Additionally, some emergency vehicles can activate an emergency sensor. At this time, both the North-South and the East-West traffic lights need to turn RED.
In this case, of ITIC, we first use a WFD-net to model its business process, as shown in Figure 9. Table 2 shows all places and their meanings. The Boolean functions select (EmgSensor, EWSensor) and select(EmgSensor, EWSensor) are two exclusive guards on t 2 and t 3 , respectively. By using DICER 2.0, we can draw and edit this WFD-net. Then, a guard-driven reachability graph is constructed, as shown in Figure 10. Based on this GRG, some properties can be verified by traversing each weak configuration (or state). For example, there is no deadlock in this ITIC system because there always exist enabled transitions at any weak configurations. Moreover, there is no error of data inconsistency since all concurrent transitions do not access a shared data element.

Place ID Meanings
The yellow light of NS Road p 3 The red light of NS Road p 4 The green light of NS Road p 6 The pre-green light of EW Road p 7 The green light of EW Road p 8 The yellow light of EW Road p 10 The red light of EW Road p 0 , p 1 , p 5 , p 9 (Control places ) Figure 9. A WFD-net that models an intelligent traffic light system.

Case _2: Health-Care Cyber-Physical System (HCPS)
The health-care cyber-physical system (HCPS) [56] consists of a series of devices such as e-health sensors, ambulance drones and ambulance vehicles. When an e-health sensor detects a cardiac arrest from patients, they will transmit this information to a controller, and then some warnings are sent to an emergency center. This center can also directly receive an emergency call from patients. After receiving these emergency messages, both drones and ambulances are ordered and sent to the emergency scene according to specific locations of patients.
In this case, of HCPS, we first use a PD-net to model its business process, as shown in Figure 11. Table 3 lists all transitions and their meanings. By using DICER 2.0, we can draw and edit this PD-net. Then, an FCP is generated, and some errors of data inconsistency are detected, which are respectively shown in Figure 12a,b. From Figure 12b, we can easily find that 12 concurrent events suffer from the errors of data inconsistency. Figure 11. A PD-net that models a health-care cyber-physical system. Receive data t 15 Movement of the drone t 7 Storage task t 16 Install defibrillator t 8 Send data

Benchmarks
A group of experiments are done based on the following benchmarks to show the advantages of DICER 2.0. Please note that all of these experiments are implemented on a PC with 4.0G memory and Intel Core i5-2400 CPU. • The Index program [57] is widely used for the experimental evaluation of multithreads. • The Prime benchmark (http://docs.oracle.com/cd/E19205-01/820-0619/gdvwv/ index.html, accessed on 16 April 2021) is a tutorial program for detecting data race. • The Child_benefit benchmark [58] is an example of transactional payment processes for child benefits. • The SystemC benchmark [59] illustrates a SystemC (a modeling language) module. • The Driver [60] benchmark describes a simplified model of bluetooth drivers. • AddGlobal [61] gives an example of concurrency bugs. • The AppLoan benchmark [62] describes a business process of approving property loan. • The Airport benchmark [63] shows a business process of an airport check-in system. • Case_1 and Case_2 are two case studies of intelligent traffic light system and health-care cyber-physical system, respectively.

Implementation and Results
(1) The experiments on the GRG of WFD-nets The guard-driven reachability graph (GRG) of WFD-nets is an improved method for analyzing data-flows of concurrent systems. In this experiment, we use DICER 2.0 to compare it with the classical reachability graph (CRG) in terms of state-space and runtime.
We first use some WFD-nets to mode the benchmarks of SystemC, AddGlobal, Approv-eLoan, AirportCheck, and Driver in DICER 2.0, and then respectively obtain their CRGs and GRGs. Table 4 shows the results of these experiments. Obviously, the scale of GRG is much smaller than RG. Meanwhile, our GRG-based method spends less time to produce a reachability graph than the CRG-based method.
Please note that although the GRGs of WFD-nets in Table 4 can save the state-space of concurrent systems compared with CRGs, they still likely suffer from the state-space explosion problem especially with the increase of concurrent (data) operations. In order to alleviate this problem, we conduct the following experiments based on the unfolding techniques.
(2) The experiments on the unfolding of PD-nets The errors of data inconsistencies are usually detected based on reachability graphs (RGs). Thus, all states and arcs of RGs need to be traversed to do this work at worst. In this experiment, DICER 2.0 are used to detect these errors based on the unfolding techniques of PD-nets. In details, we compare their FCPs with RGs in terms of state-space, runtime and detection time.
We first use some PD-nets to model the benchmarks of Child_benefit, Index and Prime in DICER 2.0. Afterwards, their FCPs are generated, and some errors of data inconsistency are detected. Table 5 shows the scales (i.e., the numbers of nodes and arcs) of FCPs and RGs. Obviously, FCPs take up much smaller space than RGs. Meanwhile, this table also lists the time of generating FCPs and RGs. Thus, we can easily find that the former has a significant advantage over the latter.   To further show the advantage of DICER 2.0, we make some comparisons between DICER 2.0 and other existing Petri net tools, e.g., PIPE, Tina and Punf. We select these tools based on the following considerations.

•
The same or similar runtime environments. • The same or similar functions and features. • Available installations.
In these experiments, we first implement the benchmarks of Case_1 and Case_2 into different Petri net tools, and then we can get their experimental results. Tables 6 and 7 respectively show comparisons on the performance and functions of different Petri net tools. From these tables, we can find that DICER 2.0 supports the WFD-net modeling of concurrent systems, constructing GRGs, unfolding PD-nets and detecting errors of data inconsistency, while other Petri net tools do not. Please note that we must model data operations by data places and their related flows in Tina, PIPE and Punf because these tools cannot support the formalizations of labeling functions and guard functions. With respect to this modeling method, we can find that the model scales of Case_1 and Case_2 by these tools is much larger than WFD-net by DICER 2.0. Meanwhile, due to the lack of guard functions, these tools cannot model routing path conditions. Naturally, its reachability graph (by Tina and PIPE) is smaller than our GRG. Additionally, we cannot get an FCP of Case_2 by Punf because it cannot support the unfolding of unsafe Petri nets.

Conclusions
Data-flow analysis plays an important role in the correctness verification of concurrent software systems. Petri net-based model checkings are a prominent method/technique for analyzing these data-flows. Currently, many different kinds of Petri nets have been used to do this work such as algebraic Petri net, predicate/transitions net, and colored Petri nets. WFD-net, as a high-level Petri net, is extended with conceptual labeling data operations. Thus, it can greatly model control/data-flows of concurrent systems. Moreover, its model scale is much smaller than other Petri nets with data-flow arcs such as C-net and PN-DO. Furthermore, WFD-net has been widely used to do model checkings. However, concurrent data operations and guard functions easily lead to the problems of state-space explosion and pseudo-states. In order to alleviate these problems, we proposed some efficient methods to detect data-flow errors and verify some properties. In this paper, we develop a new model checker DICER 2.0. By this tool, we can do a series of model checkings, e.g., detecting data inconsistencies based on the unfolding technique of PD-nets, and checking deadlocks via the GRG of WFD-nets.
In the future work, we plan to do the following studies: (1) The unfolding methods of WFD-nets are studied to check many more data-flow errors and concurrency bugs [64,65] of concurrent systems; (2) DICER 2.0 is further improved to support many more efficient model checkings; and (3) Timed concurrent systems are modeled and checked by the unfolding techniques of Petri nets.