Processing math: 100%
A journal of IEEE and CAA , publishes high-quality papers in English on original theoretical/experimental research and development in all areas of automation
Jiani Zhou, Jiacun Wang and Jun Wang, "A Simulation Engine for Stochastic Timed Petri Nets and Application to Emergency Healthcare Systems," IEEE/CAA J. Autom. Sinica, vol. 6, no. 4, pp. 969-980, July 2019. doi: 10.1109/JAS.2019.1911576
Citation: Jiani Zhou, Jiacun Wang and Jun Wang, "A Simulation Engine for Stochastic Timed Petri Nets and Application to Emergency Healthcare Systems," IEEE/CAA J. Autom. Sinica, vol. 6, no. 4, pp. 969-980, July 2019. doi: 10.1109/JAS.2019.1911576

A Simulation Engine for Stochastic Timed Petri Nets and Application to Emergency Healthcare Systems

doi: 10.1109/JAS.2019.1911576
More Information
  • In many service delivery systems, the quantity of available resources is often a decisive factor of service quality. Resources can be personnel, offices, devices, supplies, and so on, depending on the nature of the services a system provides. Although service computing has been an active research topic for decades, general approaches that assess the impact of resource provisioning on service quality matrices in a rigorous way remain to be seen. Petri nets have been a popular formalism for modeling systems exhibiting behaviors of competition and concurrency for almost a half century. Stochastic timed Petri nets (STPN), an extension to regular Petri nets, are a powerful tool for system performance evaluation. However, we did not find any single existing STPN software tool that supports all timed transition firing policies and server types, not to mention resource provisioning and requirement analysis. This paper presents a generic and resource oriented STPN simulation engine that provides all critical features necessary for the analysis of service delivery system quality vs. resource provisioning. The power of the simulation system is illustrated by an application to emergency health care systems.

     

  • BUSINESS process management (BPM) has been well accepted by industry as a discipline in operations management that studies the discovery, modeling, analysis, measurement, improvement, optimization, and automation of business processes. A business process is composed of a set of tasks that are performed by human stakeholders, software tools, machinery and/or equipment to achieve a concrete goal. BPM manages these tasks in a service company. Business processes are often repeated routinely with many instances running concurrently. Business processes span industries. Examples of service processes are financing, healthcare, travel, and banking processes.

    Over the years, the emphasis of BPM has been shifting from the enactment of business processes towards the improvement of business processes [1]. Execution of a business process to all stakeholders’ satisfaction is not always easy. There are many challenges in reality. One such challenge arises from improper resource provisioning. In many service delivery systems, business processes are constrained by various available resources. The lack of sufficient resources can cause resource contention and delay the accomplishment of service goal. This is particularly true in an emergency response system where large quantities of resources, including emergency responders, ambulances, medical care personnel, medications, rooms, beds, etc., are required. Often potential delays can be avoided or reduced by using resource analysis to identify ways in which tasks can be executed in parallel and in efficient ways. A workflow with resource usage defined can help keep track of resource availability, disable the paths that are not executable, and present all executable paths, thus allowing the automatic selection of a feasible path for system execution [2].

    Petri nets have been a popular formalism for modeling systems exhibiting behaviors of competition and concurrency for almost a half century [3], [4]. Petri nets are particularly powerful in the modeling and analysis of resources sharing systems [5], [6]. Stochastic timed Petri nets, an extension to regular Petri nets, are a powerful tool for system performance evaluation [7]. Some subclasses of STPNs can be analyzed numerically. For example, stochastic Petri nets (SPNs) [8], [9], in which each transition is associated with exponentially distributed firing times, can be mapped into continuous-time Markov chains. Generalized stochastic Petri nets (GSPN) [10], where each transition is associated with either exponentially distributed firing times, or a zero firing time, can be mapped into stochastic point processes. Extended stochastic Petri nets [11], [12] and deterministic and stochastic Petri nets (DSPNs) [13] can have exponential or non-exponential transition firing times, but non-exponential firing times can only be associated with exclusive or competitive transitions, in this way, these two types of stochastic timed Petri nets (STPNs) can be solved with semi-Markovian processes. When an arbitrary transition in an STPN is associated with general stochastic transition firing times, however, it would be very hard to solve it analytically due to inherited complexity with general stochastic processes. Unfortunately, this is the common case for real world service systems. For example, consider the emergency service in a hospital, where the processing time of many tasks, such as urine test and IV infusion, is close to a uniform distribution over an interval or normal distribution. Such kind of service systems also exhibit intensive concurrency, because multiple medical people work with multiple patients simultaneously. Thus, such a system cannot be specified by any of the above mentioned special STPN models. There are efforts reported that attempted to tackle systems with arbitrary event times [14]–[16], but because of the inherent computation complexity, those efforts didn’t generate practical applications. Therefore, we have to turn to software simulation tools [17].

    A long list of Petri net software tools have been developed over the past three decades [18]. The majority of STPN tools are for specific classes of STPNs. For example, GreatSPN [19], which was initially developed at the University of Turin in the late eighties of last century, is mainly for the analysis of GSPNs. Later, a DSPN module was also developed and included in GreatSPN [20]. TimeNET [21] is also a tool for analyzing and simulating DSPNs. Many tools focus on other Petri net classes like SPNs, such as PIPE [22] and SPNP [23]; or like queuing Petri nets (QPNs), such as QPME [24]. Most software tools have their own graphical user interfaces (GUI) which support the design of Petri nets. However, most of them cannot be driven in the batch mode (only via the GUI), which does not ease the generation of multitudinous results.

    In [25], a tool called TiPeNeSS (Timed Petri Net Simulator Software) is presented, which supports the simulation of timed Petri nets containing transitions with generally distributed firing delays. However, this tool does not take care of multi-server transitions in general case, i.e., not with exponential firing times.

    This paper proposes a simulation framework that supports the analysis of optimal provisioning of resources that ensures timely care service and meanwhile incurs no excessive cost from unnecessary resource acquisitions. A tool based on this framework has been developed and tested. Notable features of this tool include:

    1) Allow generic firing times for any transitions;

    2) Support single-server and multi-server (infinite-server) transition models;

    3) Support pre-selection and race transition firing policies;

    4) Support step-by-step GUI-driven simulation mode and batch execution mode that facilitates large-scale simulations for system performance assessment;

    5) Support resource provisioning, which is critical for the systems resource impact analysis.

    6) STPN models are saved as JSON files.

    A stochastic timed Petri net based healthcare workflow and resource modeling technique is presented. Healthcare systems are one of areas where Petri nets find successful applications [26]–[29].

    The rest of this paper is arranged as follows: Section II introduces stochastic timed Petri nets, their firing policies, and in particular, multiple enabledness. Section III discusses the proposed simulation engine, including its architecture and algorithms. Section IV presents a case study that applies the simulation tool in the resource requirement analysis of an emergency healthcare system. The last section concludes the paper.

    A Petri net is a graphical and mathematical modeling tool [3]. It consists of places, transitions, and arcs that connect places and transitions. Input arcs connect places with transitions, while output arcs start at a transition and end at a place. Places can contain tokens; the current state of the modeled system (the marking) is given by the number (and type if the tokens are distinguishable) of tokens in each place. Transitions are active components. They model activities which can occur (the transition fires), thus changing the state of the system (the marking of the Petri net). Transitions are only allowed to fire if they are enabled, which means that all the preconditions for the activity must be fulfilled (there are enough tokens available in the input places). When the transition fires, it removes tokens from its input places and adds some at all of its output places. The number of tokens removed/added depends on the cardinality of each arc.

    A Petri net is mathematically defined as a 5-tuple

    N=(P,T,I,O,M0)

    where P = {p1, p2, …, pm} is a finite set of places; T = {t1, t2, …, tn} is a finite set of transitions; I: P × TN is an input function that defines the directed arcs from places to transitions, where N is the set of all nonnegative integers; O: T × PN is an output function that defines the directed arcs from places to transitions; M: PN is the initial marking.

    Petri nets are a promising tool for describing and studying systems that are characterized as being concurrent, asynchronous, distributed, parallel, nondeterministic, and/or stochastic. As a graphical tool, Petri nets can be used as a visual-communication aid similar to flow charts, block diagrams, and networks. In addition, tokens are used in these nets to simulate the dynamic and concurrent activities of systems. As a mathematical tool, it is possible to set up state equations, algebraic equations, and other mathematical models governing the behavior of systems [3], [30]. The characteristics exhibited by the activities of information processing systems such as concurrency, decision making, and synchronization are modeled very effectively with Petri nets. When extended with inhibitors, Petri nets can also model priorities with events [3].

    To study performance issues of systems, it is necessary to include a timing concept into the model. There are several possibilities to do this for a Petri net; however, the most common way is to associate a firing delay with each transition [7]. This delay specifies the time that the transition has to be enabled, before it can actually fire. If the delay is a random distribution function, the resulting net class is called STPNs [8], [9].

    STPNs as a formalism developed in the field of computer science have gained wide applications for modeling system performance. The most common practice is to assume all firing delays are exponentially distributed. Moreover, there are a lot of software tools developed to implement and solve models defined by using the STPN formalism.

    Sequential execution, concurrency, competition and synchronization are typical characteristics exhibited in service systems. They can all be modeled by Petri nets nicely.

    A sequence of events can be modeled with a Petri net construction shown in Fig. 1, in which transitions are connected with paces sequentially to each other. When the place p1 gets a token, the three transitions will fire one after another starting from the transition t1.

    Figure  1.  Sequential execution.

    In Fig. 2, t1, t2, t3 are three parallel transitions. After t0 fires, one token in p0 is removed and p1, p2, p3 each is added with one token, and thus all t1, t2, t3 are enabled and can fire independently.

    Figure  2.  Concurrent execution.

    In Fig. 3, all t1, t2, and t3 are enabled. However, they compete for the same resource (token) in p0. When one transition fires, the other two will be disabled. Each transition can be selected to fire, though, which is the decidability of Petri nets. When transitions are associated with random firing times, the transition that is sampled with the minimum firing time will be selected to fire.

    Figure  3.  Competition.

    In Fig. 4, t3 models synchronization. t3 is enabled only when p3 and p4 each has at least one token.

    Figure  4.  Synchronization

    STPNs are Petri nets extended with random event times [7]. Event times can be associated with arcs, places or transitions. Most STPN models introduce times to transitions, called transition firing times. The time can be deterministic or stochastic. Stochastic transition firing time model is widely adopted because it covers general cases. STPN-based system performance evaluation starts with the modeling of the system under consideration with STPN. The STPN model has an underling process that governs the system behavior. This stochastic process is then analyzed using known analytical techniques or through software simulation.

    Formally, an STPN is a tuple

    STPN=(P,T,I,O,Φ,M0)

    where (P, T, I, O, M0) is a regular Petri net; Φ = (Φ1, Φ2, …, Φn}, where Φi is the random distribution of the firing time of the transition ti. We denote by τi the firing time of the transition ti. Then

    Φi(x)=Pr{τi<x}.
    (1)

    Transitions that take zero time to fire are called immediate transitions. Normally, immediate transitions are used to model events whose durations can be ignored comparing to other events in a system.

    For a regular Petri nets, the set of all possible transition firing sequences starting from initial marking M0 is denoted by L(M0). The timed execution of an STPN can be specified by a sequence in L(M0) augmented with a non-decreasing sequence of real nonnegative values representing the instants of transition firings, such that consecutive transitions ti and ti+1 correspond to the ordered firing epochs τi and τi+1, τiτi+1. That is, if σ L(M0) and σ=t1,t2,,ti,ti+1,.

    Then the augmented sequence is

    σ=(t1,τ1),(t2,τ2),,(ti,τi),(ti+1,τi+1),.

    Assume the marking of the STPN after firing transition ti is Mi. The time intervals [τi, τi+1) between consecutive epochs represent the periods in which the STPN sojourns in the marking Mi. A history of an STPN up to the kth epoch τk, or the sequence of σ’ up to τk, is denoted by Z(k). We assume that for all k, Z, and M, the following distribution functions can be uniquely determined

    F(i,x|M,Z)=Pr{tifires,dx|M,Z}
    (2)

    where the random variable d represents the time elapsed from the STPN’s entry to M up to the next transition firing epoch, i.e., the time difference τi+1τi.

    In modeling customer arrival processes, a common assumption is that they follow Poisson distribution. Also, the customer service time is normally treated as exponentially distributed. The biggest advantage of the two assumptions is the memoryless property associated with Poisson process and exponential distribution. If in a marking all enabled transitions are associated with the exponentially distributed transition firing time, the above distribution function only depends on the current marking. That is

    F(i,x|M)=Pr{tifires,dx|M}.
    (3)

    When multiple transitions are enabled in a marking, a policy is needed to decide which transition to fire next. This is particularly important when we investigate the performance of an STPN model through simulation. We consider two policies [13]:

    Preselection: With this policy, transitions that are enabled in a marking are assigned fixed probabilities to fire. Let E(M) be the set of all transitions that are enabled in the marking M. When the preselection policy is applied, each enabled transition ti is assigned a firing probability pi(M, Z), and

    tiE(M)pi(M,Z)=1.
    (4)

    Notice that such a probability distribution is defined at the marking level. In practice, it is difficult to implement, because one has to generate the entire state space of an STPN and then find proper markings to define the distribution. In this research, we propose to define the preselection policy at the net structure level. We make the following assumptions:

    1) Transitions in a preselection set will be either all enabled or all disabled in any marking.

    2) All transitions in preselection set are immediate transitions, that is, they all have 0 firing delay.

    Assumption 1) makes sense because in a practical system, we do not expect a randomly formed group of events that need to enforce the preselection policy. Assumption 2) puts no restriction of the application of the preselection policy, because for any timed transition, we can expand it to two sequential transitions: one immediate transition and one timed transition. With these two assumptions

    pi(M,Z)=pi.
    (5)

    It significantly simplifies the practical use of the preselection policy.

    At runtime, the selection of the next firing transition is performed based on some simple rule of sampling. For example, consider the three transitions in Fig. 3. Assume the firing probabilities of t1, t2, t3 are 0.3, 0.5 and 0.2, respectively. When the place p0 gets marked, they are all enabled. Our simulation tool will generate a random number between 0 and 1 to determine which transition to fire. A simple rule is, if we get a number in the range [0, 0.3), we fire t1; If the number drops in [0.3, 0.8), we fire t2; Otherwise, we fire t3.

    Race: Let E(M) be the set of all enabled transitions at M. In the race policy, for each transition ti in the set E(M), a random sample τ is extracted from the joint distribution

    Φ(x1,x2,,xn|M,Z)=Pr{τ1x1,τ2x2,,τnxn|M,Z}.
    (6)

    The minimum of these samples determines which transition will actually fire, and the sojourn time in M. We only consider the case in which all random samples are independent. In this way, (6) is uniquely determined by the marginal distributions

    Φi(x|M,Z)=Pr{τix|M,Z}.
    (7)

    In an STPN, concurrency is not only exhibited when different transitions are enabled and can run in parallel, but also may be exposed by a single transition that can have multiple instances. For example, we can use a single transition to model three machines of the same type. If the transition is triple-enabled, i.e., the transition can fire three times continuously, then the transition actually works like three transitions. We call this transition a multi-server. On the other hand, if a transition only represents a single machine or processor or any other task performer, then the transition is called a single-server [31], [32].

    In the single-server case, each transition can only have one instance and thus it can perform only one operation at one time. Fig. 5 illustrates the case that a single-server processes three inputs. There are three tokens in p1. Assume t1 is a single server. Then t1 has to fire three times, each time it will take the assigned firing time to finish. That is, if the firing time is a fixed value, say 3 time units, and the transition starts firing at time 0, then the first token moves from p1 to p2 in three time units. The second token and third token move to p2 in 6 time unites and 9 time units, respectively.

    Figure  5.  t1 is a single-server.

    In the multiple-server case, each transition represents k servers, and thus it can perform k operations at one time. For example, assume the transition t1 is a triple-server in Fig. 6 and there are three tokens in p1 at time 0 in the initial marking. t1 can fire and consume the three tokens at the same time. That is, all the three tokens will move from p1 to p2 in three time units. The triple-server transition here is equivalent to three single-server transitions.

    Figure  6.  t1 is a multi-server.

    If a multi-server transition can be enabled up to k times simultaneously (the case we use a single transition to model up to k identical machines, servers, processors, etc.), there will be up to k instances of the transition created in a simulation tool. Each instance fires independently of other instances and the firing time of each instance follows the same random distribution as defined in (1). When all k instances are busy in firing, the transition cannot be further enabled. But, when one instance completes its firing, the transition can be enabled again. In the implementation of multi-server transitions, we put all enabled instances of each transition in a queue. We will explain that in the next section.

    In this section, we give an overview of the simulation engine for resource oriented timed Petri nets. As shown in Fig. 7, the simulation system presented in this paper has seven components:

    Figure  7.  Architecture of the proposed simulation engine

    1) A simulation engine. It is a stochastic timed Petri net based state transition system and supports non-Markovian transition firing times, race and preselection transition firing policies, and both single-server and multi-server transitions.

    2) STPN editor. It is a graphic tool for users to construct STPN models.

    3) An STPN bank. It stores all STPN models built with the tool in the JSON file format.

    4) A resource configurator. It specifies and adjusts, manually or automatically, the resource allocation of a service system modeled by an STPN.

    5) Algorithms. It provides different algorithms to the simulation engine. Each algorithm represents a simulation strategy. Currently there are single-server and multi-server two cases.

    6) Event data. It stores event names and all timing parameters. Event data can be edited independently of the STPN structure.

    7) Results. Simulation results are stored in the MS Excel spreadsheets.

    The overall design of the proposed simulation engine for multiple server STPN models is illustrated in the class diagram in Fig. 8. Ten major classes and their functions are explained as follows.

    Figure  8.  Class diagram of simulation engine of STPNs with multiple-server transitions

    The PNModel class is used to import external files of STPN models and store the models in internal data structures.

    The PNElement class defines the elements in a Petri net model. The Arc, Place and Transition inherit from the PNElement class for common attributes and methods. In the Arc class, we define two types of arcs, one is from place to transition, the other from transition to place. In the Transition class, we define a priority queue for each transition to save firing times of its instances. In the Place class, we set the number of tokens for each place.

    The ResourceMgr class specifies resource type and resource quantity.

    The RandomNumGenerator class generates the random number from different stochastic distributions. For an exponential distribution, we only need the average time to get a random number. For a uniform distribution, we need two numbers to define the minimum and maximum values,r espectively.

    The TranFiringTimeMgr manages transition firing times in the priority queue for each transition.

    The Petrinet class is to compute the fireable transition list for the Simulation class. In the Petrinet class, we define a global arraylist to save fireable transitions and update them in the Simulation class.

    The Simulation class manages the operation of STPN models and saves the simulation results.

    Like in any typical discrete event simulation system, we use a global clock in our tool to record time. The clock time increases at each simulation step. The simulation step length can be fixed or dynamic. In the fixed step case, the step length is set to 1. In the dynamic step case, the step length is determined by the gap between the current clock time and the next transition’s absolute firing time. We implemented both options.

    When a transition becomes enabled, the transition firing time is sampled from its distribution function. If it is a single-server, then at each step of the simulation, the global clock increases and the transition’s keeps firing time decrements by the length of the simulation step. When the firing time decreases to 0, the transition fires and the token distribution changes. Of course, not all enabled transitions will fire. If an enabled transition becomes disabled before its firing time decreases to 0, it cannot fire. This is dictated by the race firing policy. If before the transition fires, more tokens come to its input places that are sufficient to make the transition double or triple enabled, there will be no change to the transition’s firing behavior. After the transition is fired, it will be resampled for firing time at the new marking.

    If the newly enabled transition is a multi-server, we will follow the three-phase procedure to handle its firing:

    Phase 1: At the time the transition is enabled, tokens are removed from the incoming places. The transition firing time is sampled and inserted into a queue.

    Phase 2: the firing time decreases when the global clock ticks until it goes down to 0,

    Phase 3: tokens are added to the outgoing places.

    If after Phase 1 and before Phase 3, the transition becomes enabled again, we follow the same three-phase procedure to handle the new instance. That is, we will maintain a queue that stores the remaining firing time of each instance of a multi-server transition.

    Fig. 9 shows the external view of typical service systems. The transition A is a source transition, which models arrival of customers or, in general, service requests. The token in the place i represents a customer. Notice that A and i constitute a self-loop, modeling consecutive arrival of customers. The number of tokens in the sink place o counts the number of customers being served by the system. Fig. 10 models a single shot execution of the system. Transitions D1, D2, …, Dk are sink transitions, which model different ways that customers depart the service system. The STPN box models the service workflow. To validate the correctness (no deadlock, no dangling transitions, etc.), we can add a transition to the model in Fig. 10 and connect o to it as an input and also connect i to it as output, and then check to see if the new STPN processes all desired properties we want.

    Figure  9.  Service system input and output.
    Figure  10.  A single shot execution.

    It is a widely accepted assumption that the customer arrival process is a Poisson process, and the interval time between customer arrivals is exponentially distributed. That is, the firing time of the transition A is exponentially distributed. Therefore, we can use a single parameter, the average rate of customer arrival, to specify the customer arrival behavior.

    Assume we sample the exponential distribution of transition i N times, and the sequence of the samples we get is x1, x2, …, xN, where xi is the arrival time of the ith customer relative to the arrival time of the (i –1)th customer. Assume the system starts to run at time 0. Let ai be the arrival time of the i th customer according to the global clock. Then

    ai=ik=1xk.

    Let bi be the departure time of the ith customer. The ith customer entering the system and the ith customer leaving the system may or may not be the same one. These times are recorded when any of the transitions D1, D2, …, Dk fires. The average sojourn time, s, of customers in the system can be calculated by

    s=Nk=1(biai)N.

    A customer’s sojourn time in a system includes service time and waiting time. The average service time can be obtained as the statistics of the sojourn time of a custom entering into the system in which no resources are occupied. In other words, we can run the model in Fig. 10 N times independently, starting at time 0, and record the time, ci, that the place o is marked. By this way, the average service time is

    v=Nk=1ciN.

    Then the average waiting time of the system is

    w=sv.

    In this section, we introduce the major algorithms used in our simulation engine for STPNs with multi-server transitions (We omit the algorithms for STPNs with only single-server STPNs). We will also use a toy example to show the difference between simulation results when different servers are used, which further indicates the importance to have multi-server implementation in a simulation tool.

    We present four major algorithm here. Algorithm 1 depicts the main control flow of the simulation engine. It also shows how a queue of the firing time of each instance of a transition is managed, which is the most critical part of the simulation engine. Algorithm 2 specifies how the list of enabled transitions is maintained and updated. Algorithm 3 is an abstract of the firing behaviors of the transition that follow the pre-selection policy. Algorithm 4 is about the data collection for system performance evaluation.

    Selecting the length of simulation step (clock step) is tricky. A bigger simulation step would mean a faster simulation but a bigger simulation error. Simulation error is incurred due to the discretization of continuous transition firing time delays. As a rule of thumb, choosing a small simulation step length will allow a fine-grained sampling time for transition firing delays and reduce the error.

    Algorithm 1: Multiple server engine

    Input: A timed Petri net model

    Output: Delay time for each customer

    Initialization:

     transitions and timing parameters

     places and tokens

     arcs and weights

     a global clock (CLK)

     an enabled transition list (ETL)

     a transition instance queue (TIQ)

    Main Flow:

     update ETL;

     while (ETL is not empty) {

      traverse ETL to find the transitions-to-fire;

      peek TIQ of transitions-to-fire to find the firing instance;

      if (simulation step is fixed at 1)

       step ← 1;

      else if variable step length

       step ← the firing time of transitions-to-fire;

      add step to CLK;

      for each transitions in ETL

       decrease by step the firing time of each instance in TIQ;

      while (TIQ of transitions-to-fire not empty && head value is 0)

      {

       for all outgoing arcs

        update number of tokens of connected places;

       fire immediate transitions;

       fire pre-selection transitions.

       remove entries of 0’s from TIQ of transitions-to-fire;

       if transitions-to-fire is source/sink transitions

        handle source/sink transitions;

       remove transitions with empty PIQ from ETL;

      }

      update ETL;

     }

     display results;

    Algorithm 2: Update enabled transition list (ETL)

    Input: the timed Petri net model

    Output: an ETL with all enabled transitions

    Initialization: an array to save all enabled transitions

    Main Flow:

     for each transition t in the Petri net

      if (t can fire && t not a pre-selection transition

       && t not an immediate transition)

       add t into the array;

     for each transition t in the array {

      if (t is still enabled)

       sample firing time for t;

      else

       set it as null;

     }

     t ← transition with smallest firing time;

     for incoming arcs of t

      remove adequate number of tokens from connected places;

     if (t is not in ETL)

     add t into ETL;

    Consider a small canteen. Customers arrive at random times that follow the Poisson distribution. There are three kinds of foods served in the canteen: pizza, salad and sandwich, each served by one person. The food service time is uniformly distributed in the range of [2, 8] (minute) for all three types of foods. There are three check-out service stations. The check-out time is exponentially distributed with the average being 5 minutes for each station.

    Algorithm 3: Fire pre-selection transitions

    Input: pre-selection transitions and current marking

    Output: new marking after firing

    Initialization: firing probability

     for each pair of pre-selection trans

      if they can fire

       p ← random number in [0, 1];

       if p smaller than preset probability of one transition

        fire the transition;

       else

        fire the other transition;

    Algorithm 4: Handle source/sink transitions

    Input: CLK, transitions_to_fire, number of inCustomer, number of outCustomer

    Output: updated quantity for in and out customers

    Main Flow:

     if (transitions-to-fire is a source transition)

      inTimeinTime + CLK;

      inCustomer ++;

     if (transition-to-fire is a sink transition)

      outTimeoutTime + CLK;

      outCustomer ++;

    The STPN model of this service system is illustrated in Fig. 11. We performed simulation on two options:

    Figure  11.  STPN model of a canteen service.

    1) The transition checkout is implemented as a single-server.

    2) The transition checkout is implemented as a multi-server.

    We want to show the difference between the two options.

    The firing time of the transition arrive is exponentially distributed. Its average firing time, τ, which specifies the average arrival interval of customers, is a variable in the simulation. We simulated the cases when τ = 2, 3, 5, 7, 9, 12, 15, 20 min. For each case in each option, we simulated the service process for 5 hours. The simulation results are presented in Fig. 12.

    Figure  12.  Simulation results of canteen service.

    Customers may have to queue for food to be served and for checkout. For both single-server and multi-server implementations, with the arrival interval of customers increases, the total waiting time of a customer decreases. When the arrival interval is big enough such that customers arrive at a slower rate than food service and checkout combined together, the average waiting time approaches 0. This trend is clearly shown in Fig. 12.

    More importantly, Fig. 12 clearly shows the difference between the simulation result when the transition checkout is implemented as a single-server and that when it is implemented as a multi-server. That is, the single-server implementation results in a longer waiting time, because the single-server implementation does not reflect the concurrency among the three checkout stations.

    Notice that with the increase of customer arrival intervals, the system becomes less congested and the difference between the two implementations become less dramatic. When the customer arrival interval is sufficiently large, there will be no difference between using one cashier and using more cashiers, and thus the simulation results of the two implementations will be statistically the same.

    In this section, we present a case study on healthcare emergency services. A health emergency is a situation that poses an immediate risk to somebody’s health and even life, and requires an urgent medical intervention to prevent things from going worse. This case study aims to find optimal resource provisioning in an emergency department (ED) regarding the treatment of patients who suffer from strokes. By optimal we mean the quantity of a resource, say doctors, is adequate such that it is sufficient to ensure timely service to patient flow and meanwhile it is not over allocated to incur any unnecessary cost to the ED.

    Heart attack, stroke and arrhythmia are common heart and blood vessel problems. Although each problem has a unique clinical workflow, they do share some common tasks, such as CT (computerized tomography) scan, X-Ray test, blood test, etc. As an example, we model the clinic workflow of stroke treatment with STPN and study the related resource impact. The workflow handling a patient who is experiencing symptoms of a stroke is as follows: As soon as the patient arrives at the ED, he and she is taken to the point-of-care desk where he or she gets registered by a registrar. A registered nurse asks some preliminary questions, takes his or her vitals, assigns the patient an ESI, or emergency severity index, and orders CT scan. The patient takes a seat in the waiting room. Then a CT tech wheels him off for diagnostic test. After the test, the patient is returned the waiting room and waits for initial assessment by a doctor.

    A doctor asks the patient questions about his previous history, signs and symptoms, medications, emotional state, drug abuse screen, etc. Then according to all information he has collected, including the CT scan result, the doctor assesses the situation of patient and decides if the patient needs more care at the ED. If it is not the case, the patient is disposed and told to follow up with his regular physician. Otherwise, he is assigned a bed and over there is gowned, hooked up with EKG (electrocardiogram) and has an IV (infusion intravenous) in place under the help of a nurse. A phlebotomy tech takes his blood sample and then conducts lab test. Sometime later, the doctor comes with the lab results and EKG readings and decides if the patient needs more emergency care. If not, the patient is discharged. Otherwise, the patient has to undergo another round of treatment with an adjusted medication.

    All major tasks involved in the clinical workflow described above are listed in Table I. The column Res.Required lists resources that are required to execute the corresponding task, while the column Res.Released lists resources that are released when the task execution is finished. This table clearly shows the shared resources among tasks. For example, doctors as a resource are shared among several tasks, namely tasks 9, 19, 20, and 22. It also shows that an examination bed is occupied after executing task 10 but won’t be released until the execution of task 20.

    Table  I.  Task Specification
    TasksAbbr.Res. RequiredRes. ReleasedTime Distr.
    1RegistrationRGRegistrarRegistrarExp. 10
    2Take VitalTVNursing AssistantNursing AssistantUni. 5–15
    3Initial AssessmentIAPhysician AssistantPhysician AssistantExp. 15
    4Chest X-rayCXRX-ray Technician, X-ray MachineX-ray Technician, X-ray MachineExp. 25
    5CT ScanCTCT Tech, CT MachineCT Tech, CT MachineExp. 25
    6TriageTRTriage NurseTriage NurseExp. 17
    7Take UrineTUUrine Test NurseUrine Test NurseExp. 8
    8Urine TestURSpecimen Cup, Urine Test Technician, Urine Test MachineUrine Test Technician, Urine Test MachineUni. 25–35
    9ReassessmentRADoctorDoctorExp. 20
    10Bed AssignmentBANurse, bedNurseExp. 18
    11GownGNNurse, gownNurseExp. 12
    12EKG HookupEHNurse, EKG SetNurseExp. 28.5
    13Infusion IntravenousIVNurse, IV BagNurseUni. 140–160
    14IV Infusion StartISNurseNurseUni. 1–5
    15IV Infusion EndIENurseNurseUni. 1–5
    16Draw BloodDBNurse, Needle, 3 TubesNurseExp. 28
    17EKG TestEKGNurseNurseExp. 12
    18Blood TestBTPhlebotomy TechPhlebotomy TechUni. 50–70
    19AssessmentAMDoctorDoctorExp. 20
    20DispositionDPDoctorDoctor, EKG Set, Grown, BedExp. 10
    21Adjust DrugADNurse, DrugNurseExp. 32
    22Early DispositionEDDoctorDoctorExp. 10
     | Show Table
    DownLoad: CSV

    The last column of the table shows the random distribution of each task’s duration. For example, the duration of the task Registration follows an exponential distribution and its average time is 25 minutes. The task IV Infusion takes a time which is uniformly distributed in the range of [140, 160].

    The STPN model of the clinic workflow is illustrated in Fig. 13. Each task in Table I has a corresponding transition in this model. In addition, there are also transitions that are used to model different assessment results. For example, the transitions d11 and d12 are a pair. d11 represents that the doctor’s assessment result indicates the patient can have an early departure, while d12 represents that the doctor’s assessment result indicates the patient needs to have an examination bed assigned for further treatment. d11 and d12 are immediate transitions and they follow the pre-selection firing policies. So are d21 and d22. The unnamed place and transition following EH are introduced solely for readability purpose. They do not alter the logic of the workflow.

    Figure  13.  Stochastic timed Petri net model of the workflow of stroke care.

    Tasks RG, TR, TV and IA are executed sequentially for each patient, and thus in the STPN model they form a sequential structure. Tasks CT, CXR and TU can be executed in an arbitrary order. Therefore, these three tasks plus UR form a random execution structure. But different from a decision structure in which only one transition will be executed, here all these transitions have to be executed. Tasks BA, GN and EH are also executed sequentially. After that the patient receives IV and undertakes other tests. This process may be repeated upon a doctor’s decision. Therefore, there is a loop structure in the model, marked by transitions d22 and AD on the feedback path.

    Transition firing times are specified in the right-most column. Two types of firing time distributions are adopted, exponential distribution and uniform distribution, just to show our tool can handle non-Markovian STPNs.

    Resources are modeled by the places P_doctor, P_register, P_bed, and P_nurse. All transitions with one or more of these places as input must be implemented as multi-servers. Otherwise, the concurrency among multiple processors which utilize the same resource will be lost.

    In this case study, we only consider reusable resources: doctors, nurses, registrars and beds. Non-reusable resources can only be consumed by a single transition and are not shared, and thus not studied here. For each set of resource provisioning, we run the STPN model with various patient arrival rates and collect the average patient waiting time in the system. We stop the simulation when further increasing the quantity of a resource does not reduce the patient waiting time. According to the cost of resources, we follow the order doctor→nurse→registrar→bed to determine a proper resource quantity. In the simulation, we first set the quantities of nurses, registrars and beds to be unlimited, and slightly increase the number of doctors. Then, we need to compare the average waiting time of patients with different provision for doctors to determine the most reasonable doctor number. Second, after we get the reasonable number of doctors, we fix the number for doctors and set the other two resources unlimited to determine the adequate number of nurses. At last, we can get all the resources provisioned properly.

    Fig. 14 shows the average waiting time of patients vs. different numbers of available nurses when all transitions are implemented as single-servers. As a contrast, Fig. 15 shows the average waiting time of patients vs. different numbers of available nurses when all related transitions are implemented as multi-servers as they should be. One can observe that in any cases in terms of the number of available nurses and average arrival interval, patients have longer waiting times in the single-server implementation than in the multi-server implementation. This difference is more dramatic when the patient arrival rate is high, because it causes more congestion in a single-server implementation.

    Figure  14.  Patient waiting time vs. # of available nurses when all transitions are implemented as single-servers.
    Figure  15.  Patient waiting time vs. # of available nurses when all transitions are implemented as multi-servers.

    It is worth pointing out that in the single-server implementation, when we increase the number of nurses, the average patient waiting time is still going down. This is because there are several concurrent events in the system performed by nurses.

    Fig. 16 shows that after the number of doctors is increased over 5, providing more doctors does not result in any obvious improvement on the patient waiting time. Therefore, we can reasonably say 5 doctors are enough for this service settings. The same approach is applied to decide the optimal provisioning of nurses, registrars and beds. At last, we get the relatively optimal numbers of resources as 5 doctors, 12 nurses, 20 beds and 5 registrars. Simulation results for nurses, registrars and beds are illustrated in Figs. 15, 17 and 18.

    Figure  16.  Patient waiting time vs. # of available doctors.
    Figure  17.  Patient waiting time vs. # of available beds.
    Figure  18.  Patient waiting time vs. # of available registrars.

    This case study is only to show an application of the proposed STPN simulation tool. The order of resource provisioning that we used in this case study is just one option. There are many different simulation strategies that could help find proper quantities of resources. For example, one can first find the best match among the quantities of these resources, then use the simulation to decide the quantity of each. In fact, this is an optimization problem with multi-variables.

    Of course, we can also model the availability or more types of resources in the emergency care systems. Examples are the capacity of the waiting room, number of stretchers, number of CT machines, etc.

    Resource availability plays critical roles in service providing systems. This paper proposed a simulation framework that supports the analysis of optimal provisioning of resources that ensures timely service and meanwhile incurs no excessive cost from unnecessary resource acquisitions. The contribution of the work is two-fold: First, it implemented a simulation system that is based on stochastic timed Petri nets and supports non-Markovian transition firing times, race and preselection transition firing policies, and both single-server and multi-server transitions. An important feature of the simulation system is that it allows a systematic system performance vs. resource provisioning analysis. Second, a meaningful case study on an emergency healthcare system is developed to show the power of the simulation system.

    In the current implementation of the STPN tool, we assume that all transitions work in the enabling memory mode. The distributions depend on the history Z through the concept of an enabling age variable associated with each transition. The age variable accounts for the work done by the activity corresponding to the transition from the last instant at which it has become enabled up to the considered epoch. This is the most applicable memory mode in real world systems. There are other two memory modes though, resampling and age memory. There are occasions that these two modes need to be considered [7]. In our future work, we will implement them in our tool. From the application perspective, right now we have to manually provide the quantity of resources and check out the corresponding system performance. In our future work, we will consider the automated optimal resource provisioning based on user input criteria and all constraints that a system is subject to. Of course, we will also try to extend applications of the simulation tool to more time-critical systems, such as those mentioned in [33].

    It will also be interesting to explore the use of statistical model checkers to validate the desired properties of the STPN model of a service delivery system of interest, especially when many details of the system are considered in the model [34].

  • [1]
    Y. Liu, H. Zhang, C. Li, and R. Jiao, " Workflow simulation for operational decision support using event graph through process mining,” Decision Support Systems, vol. 52, pp. 685–697, 2012. doi: 10.1016/j.dss.2011.11.003
    [2]
    J. Wang and D. Li, " Resource oriented workflow nets and workflow resource requirement analysis,” Int. J. Software Engineering and Knowledge Engineering, vol. 23, no. 5, pp. 667–693, 2013.
    [3]
    T. Murata, " Petri nets: properties, analysis and applications,” in Proc. IEEE, vol. 77, no. 4, pp. 541–580, 1989. doi: 10.1109/5.24143
    [4]
    N. Wu and M. Zhou, " Intelligent token Petri nets for modelling and control of reconfigurable automated manufacturing systems with dynamical changes,” Trans. Institute of Measurement and Control, vol. 33, no. 1, pp. 9–29, 2009.
    [5]
    M. Zhou and N. Wu, System Modeling and Control with Resource-Oriented Petri Nets, CRC Press, 2009.
    [6]
    G. Liu, " Complexity of the deadlock problem for Petri nets modeling resource allocation systems, information sciences—informatics and computer science,” Applications:An Int. J., vol. 363, no. C, pp. 190–197, 2017.
    [7]
    J. Wang, Timed Petri Nets: Theory and Application, Kluwer Academic Publishers, 1998.
    [8]
    M. K. Molloy, " On the integration of delay and throughput measures in distributed processing models,” Ph.D. dissertation, UCLA, Los Angeles, CA, 1981.
    [9]
    F. J. W. " Symons. modeling and analysis of communication protocols using numerical petri nets,” Ph.D. dissertation, University of Essex, 1978.
    [10]
    M. A. Marsan, G. Balbo, G. Conte, S. Donatelli, and G. Franceschinis. Modelling with Generalized Stochastic Petri Nets. John Wiley and Sons, 1995.
    [11]
    J. Dugan, K. S. Trivedi, R. Geist, and V. Nicola, " Extended stochastic Petri nets: applications and analysis,” in Proc. Performance, Paris, France, Dec. 1984.
    [12]
    G. Ciardo and C. Lindemann, " Analysis of deterministic and stochastic petri nets,” in Proc. Petri Nets and Performance Models, 1993.
    [13]
    M. A. Marsan and G. Chiola, " On Petri nets with deterministic and exponentially distributed firing times,” Advances in Petri Nets, pp. 132–145. Springer Berlin Heidelberg, 1987.
    [14]
    Z. Huang and J. Wang, " Hybrid state analysis for non-Markovian stochastic Petri net models,” Chinese J. Automation, vol. 7, no. 1, 1995.
    [15]
    G. Horton, " A new paradigm for the numerical simulation of stochastic petri nets with general firing times,” in Proc. European Simulation Symposium, pp. 129–136, 2002.
    [16]
    S. Lazarova-Molnar and G. Horton, " Proxel-Based Simulation of stochastic Petri nets containing immediate transitions,” Electronic Notes in Theoretical Computer Science, vol. 85, no. 4, pp. 203–217, 2003.
    [17]
    W. D. Kelton and A. M. Law. Simulation Modeling and Analysis. McGraw Hill Boston, MA, 2000.
    [18]
    List of Petri net tools on the web page of Department of Informatics, University of Hamburg, Germany. [Online]. Available: http://www.informatik.uni-hamburg.de/TGI/PetriNets/tools/complete_db.html.
    [19]
    S. Baarir, M. Beccuti, D. Cerotti, M. De Pierro, S. Donatelli, and G. Franceschinis, " The GreatSPN tool: recent enhancements,” ACM SIGMETRICS Performance Evaluation Review, vol. 36, no. 4, pp. 4–9, 2009. doi: 10.1145/1530873
    [20]
    E. Gilberto and S. Donatelli, " Dspn-tool: a new DSPN and GSPN solver for greatspn,” in 7th Int. Conf. Quantitative Evaluation of Systems, pp. 79–80, Sep. 2010.
    [21]
    A. Zimmermann and M. Knoke, TimeNET 4.0: A software Tool for the Performability Evaluation with Stochastic and Colored Petri Nets; User Manual. TU, Professoren der Fak. IV, 2007.
    [22]
    P. Bonet, C. M. Llad´o, R. Puijaner, and W. J. Knottenbelt, " Pipe v2.5: A P Boucheneb1, Petri net tool for performance modelling,” in Proc. 23rd Latin American Conference on Informatics, 2007.
    [23]
    C. Hirel, B. Tuffin, and K. S. Trivedi, " SPNP: stochastic Petri nets. version 6.0,” in Computer Performance Evaluation. Modelling Techniques and Tools, pp. 354–357. Springer, 2000.
    [24]
    S. Kounev, S. Spinner, and P. Meier, " QPME 2.0 — a tool for stochastic modeling and analysis using queueing Petri nets,” in From Active Data Management to Event-based Systems and More, pp. 293–311. Springer, 2010.
    [25]
    Á. Horváth and A. Molnár, TiPeNeSS: A Timed Petri Net Simulator Software with Generally Distributed Firing Delays, SIMUTOOLS 2015, Athens, Greece, 2015
    [26]
    M. Dotoli, M. P. Fanti, G. Iacobellis, L. Martino, A. M. Moretti, and W. UKovich, " Modeling and management of a hospital department via petri nets,” in Proc. IEEE Workshop on Health Care Management, 2010.
    [27]
    M. Fanti, A. Mangni, M. Dotoli, and W. Ukovich, " A three-level strategy for the design and performance evaluation of hospital departments,” IEEE Trans. Systems, Man and Cybernetics, Systems: 43(4):742–756, 2013.
    [28]
    C. C. Mahulea, L. Mahulea, J. García-Soriano, and J. Colom, " Modular Petri net modeling of healthcare systems. flexible services and manufacturing journal, special issue on analysis,” Design and Management of Health Care Systems, 2017.
    [29]
    J. Wang, J. Tian, and R Sun, " Emergency healthcare resource requirement analysis: a stochastic timed Petri net Approach,” in IEEE 15th Int. Conf. Networking, Sensing and Control, IEEE, Mar. 2018.
    [30]
    G. Liu, Z. Li, and A. Al- Ahmni, " Liveness Analysis of Petri nets using siphons and mathematical programming,” IFAC Proceedings, vol. 47, no. 2, pp. 383–387, 2014. doi: 10.3182/20140514-3-FR-4046.00078
    [31]
    H. Boucheneb, D. Lime, and O. H. Roux, " On Multi-enabledness in time Petri nets,” in Proc. Application and Theory of Petri Nets and Concurrency, pp 130–149, 2013.
    [32]
    M. Boyer and M. Diaz, " Multiple enabledness of transitions in Petri nets with time, ” in Proc. 9th Int. Workshop Petri Nets and Performance Models, Aachen, Germany, Sep. 2001.
    [33]
    G. Liu, C. Jiang, and M. Zhou, " Time-soundness of time Petri nets modeling time-critical systems,” ACM Trans. Cyber-Physical Systems, 2(2), DOI: 10.1145/3185502,2018.
    [34]
    G. Agha and K. Palmskog, " A Survey of Statistical Model Checking, ” ACM Trans. Modeling and Computer Simulation, vol. 28, no. 1, 2018.
  • Related Articles

    [1]Xiang Chen, Yujuan Wang, Yongduan Song. Unifying Fixed Time and Prescribed Time Control for Strict-Feedback Nonlinear Systems[J]. IEEE/CAA Journal of Automatica Sinica, 2025, 12(2): 347-355. doi: 10.1109/JAS.2024.124401
    [2]Zhaoyang He, Naiqi Wu, Rong Su, Zhiwu Li. Cyber-Attacks With Resource Constraints on Discrete Event Systems Under Supervisory Control[J]. IEEE/CAA Journal of Automatica Sinica, 2025, 12(3): 585-595. doi: 10.1109/JAS.2024.124596
    [3]Tao Qin, Li Yin, Gaiyun Liu, Naiqi Wu, Zhiwu Li. Strong Current-State Opacity Verification of Discrete-Event Systems Modeled With Time Labeled Petri Nets[J]. IEEE/CAA Journal of Automatica Sinica, 2025, 12(1): 54-68. doi: 10.1109/JAS.2024.124560
    [4]Bing Zhu, Xiaozhuoer Yuan, Li Dai, Zhiwen Qiang. Finite-Time Stabilization for Constrained Discrete-time Systems by Using Model Predictive Control[J]. IEEE/CAA Journal of Automatica Sinica, 2024, 11(7): 1656-1666. doi: 10.1109/JAS.2024.124212
    [5]Qingsong Zhao, Lei Shu, Kailiang Li, Mohamed Amine Ferrag, Ximeng Liu, Yanbin Li. Security and Privacy in Solar Insecticidal Lamps Internet of Things: Requirements and Challenges[J]. IEEE/CAA Journal of Automatica Sinica, 2024, 11(1): 58-73. doi: 10.1109/JAS.2023.123870
    [6]Xiaohua Ge, Qing-Long Han, Xian-Ming Zhang, Derui Ding. Communication Resource-Efficient Vehicle Platooning Control With Various Spacing Policies[J]. IEEE/CAA Journal of Automatica Sinica, 2024, 11(2): 362-376. doi: 10.1109/JAS.2023.123507
    [7]Yifan Dong, Naiqi Wu, Zhiwu Li. State-Based Opacity Verification of Networked Discrete Event Systems Using Labeled Petri Nets[J]. IEEE/CAA Journal of Automatica Sinica, 2024, 11(5): 1274-1291. doi: 10.1109/JAS.2023.124128
    [8]Minfeng Qi, Ziyuan Wang, Qing-Long Han, Jun Zhang, Shiping Chen, Yang Xiang. Privacy Protection for Blockchain-Based Healthcare IoT Systems: A Survey[J]. IEEE/CAA Journal of Automatica Sinica, 2024, 11(8): 1757-1776. doi: 10.1109/JAS.2022.106058
    [9]Zefeng Zheng, Luyao Teng, Wei Zhang, Naiqi Wu, Shaohua Teng. Knowledge Transfer Learning via Dual Density Sampling for Resource-Limited Domain Adaptation[J]. IEEE/CAA Journal of Automatica Sinica, 2023, 10(12): 2269-2291. doi: 10.1109/JAS.2023.123342
    [10]Dongdong Yue, Simone Baldi, Jinde Cao, Qi Li, Bart De Schutter. Distributed Adaptive Resource Allocation: An Uncertain Saddle-Point Dynamics Viewpoint[J]. IEEE/CAA Journal of Automatica Sinica, 2023, 10(12): 2209-2221. doi: 10.1109/JAS.2023.123402
    [11]Mamta, Brij B. Gupta, Kuan-Ching Li, Victor C. M. Leung, Kostas E. Psannis, Shingo Yamaguchi. Blockchain-Assisted Secure Fine-Grained Searchable Encryption for a Cloud-Based Healthcare Cyber-Physical System[J]. IEEE/CAA Journal of Automatica Sinica, 2021, 8(12): 1877-1890. doi: 10.1109/JAS.2021.1004003
    [12]Zhou He, Ziyue Ma, Zhiwu Li, Alessandro Giua. Parametric Transformation of Timed Weighted Marked Graphs: Applications in Optimal Resource Allocation[J]. IEEE/CAA Journal of Automatica Sinica, 2021, 8(1): 179-188. doi: 10.1109/JAS.2020.1003477
    [13]Mohamed Amine Ferrag, Lei Shu, Kim-Kwang Raymond Choo. Fighting COVID-19 and Future Pandemics With the Internet of Things: Security and Privacy Perspectives[J]. IEEE/CAA Journal of Automatica Sinica, 2021, 8(9): 1477-1499. doi: 10.1109/JAS.2021.1004087
    [14]Sohail Imran, Tariq Mahmood, Ahsan Morshed, Timos Sellis. Big Data Analytics in Healthcare — A Systematic Literature Review and Roadmap for Practical Implementation[J]. IEEE/CAA Journal of Automatica Sinica, 2021, 8(1): 1-22. doi: 10.1109/JAS.2020.1003384
    [15]Wenbin Yue, Zidong Wang, Jieyu Zhang, Xiaohui Liu. An Overview of Recommendation Techniques and Their Applications in Healthcare[J]. IEEE/CAA Journal of Automatica Sinica, 2021, 8(4): 701-717. doi: 10.1109/JAS.2021.1003919
    [16]Ali Forootani, Raffaele Iervolino, Massimo Tipaldi, Joshua Neilson. Approximate Dynamic Programming for Stochastic Resource Allocation Problems[J]. IEEE/CAA Journal of Automatica Sinica, 2020, 7(4): 975-990. doi: 10.1109/JAS.2020.1003231
    [17]Ran Ning, Su Hongye, Wang Shouguang. An Improved Approach to Test Diagnosability of Bounded Petri Nets[J]. IEEE/CAA Journal of Automatica Sinica, 2017, 4(2): 297-303. doi: 10.1109/JAS.2017.7510406
    [18]Dong Shen, Yun Xu. Iterative Learning Control for Discrete-time Stochastic Systems with Quantized Information[J]. IEEE/CAA Journal of Automatica Sinica, 2016, 3(1): 59-67.
    [19]Shuochen Liu, Zhiyong Geng, Junyong Sun. Finite-time Attitude Control: A Finite-time Passivity Approach[J]. IEEE/CAA Journal of Automatica Sinica, 2015, 2(1): 102-108.
    [20]Shouguang Wang, Mengdi Gan, Mengchu Zhou, Dan You. A Reduced Reachability Tree for a Class of Unbounded Petri Nets[J]. IEEE/CAA Journal of Automatica Sinica, 2015, 2(4): 345-352.

Catalog

    通讯作者: 陈斌, bchen63@163.com
    • 1. 

      沈阳化工大学材料科学与工程学院 沈阳 110142

    1. 本站搜索
    2. 百度学术搜索
    3. 万方数据库搜索
    4. CNKI搜索

    Figures(18)  / Tables(1)

    Article Metrics

    Article views (1850) PDF downloads(70) Cited by()

    Highlights

    • The simulation tool supports single-server and multiple-server(infinite-server) transition models.
    • The simulation tool supports pre-selection and race transition firing policies.
    • The simulation is GUI-driven and supports both step-by-step mode and batch execution mode.
    • The simulation tool support resource provisioning.

    /

    DownLoad:  Full-Size Img  PowerPoint
    Return
    Return