# Performance Evaluation of Discrete Event Systems with GPenSIM

^{1}

^{2}

^{*}

## Abstract

**:**

## 1. Introduction

## 2. Introducing the Petri Net Simulator GPenSIM

#### 2.1. The Design and Development of GPenSIM

- (1)
- To allow the easy integration of Petri net models with any other tools that are available on the MATLAB platform. Being an industry standard platform, MATLAB has numerous toolboxes such as Fuzzy logic, Neural Network, Machine learning, Control systems, Advanced Statistics, etc. For example, a modeler can easily integrate a discrete event model with the Control systems toolbox, making a hybrid system. The simulation results from this hybrid system can be easily analyzed using the Advanced Statistical toolbox that is readily available on the MATLAB platform. Being a MATLAB toolbox, GPenSIM gives numerous possibilities for extending the discrete event models, which is not easy (if not impossible) in other software (e.g., Arena). This flexibility offered by GPenSIM is the reason why the Australian research team chose GPenSIM over the other tools, as they quote in their paper [9].
- (2)
- Easy to learn and use: GPenSIM is easy to learn and use. This is because the programming language of GPenSIM is MATLAB, which is a very simple Basic language clone. This ease of learning and use is the main reason why some of the users of GPenSIM have chosen it as a tool for the modeling and simulation of various discrete event systems, such as Gameplay analysis, flexible manufacturing systems, motor control, and service modeling (see the references [7,9,10,11,12,13]).
- (3)
- Easy to extend: Being a file-based system, a modeler can easily extend the functions available in GPenSIM. For example, Professor Tilbury’s group at the Michigan University, USA, created their own version (named “Attributed Hybrid Dynamical Nets”) by extending GPenSIM functions to transform it into a tool for modeling complex interconnected manufacturing systems [10].

- Petri net Definition File (PDF): A PDF declares the static Petri net graph: the set of places, the set of transitions, and the set of connections (arcs) are declared in this file.
- Main Simulation File (MSF): The MSF declares the initial dynamics (e.g., initial tokens in the places, firing times of the transitions, firing costs of the transitions, etc.) and runs the simulations. When the simulation terminates, the code for plotting and printing the simulation results are also coded in this file.
- The common preprocessor file (COMMON_PRE): If there are additional conditions for the enabled transitions to satisfy before firing, these conditions are coded in the COMMON_PRE file.
- The common postprocessor file (COMMON_POST): If there are any postfiring actions to be performed after firing of transitions, these actions can be coded in the common postprocessor file.

#### 2.2. Comparing GPenSIM with the Other Petri Net Simulators

## 3. Introducing the Activity-Oriented Petri Nets (AOPN) Approach

#### The Background of AOPN

_{i}and m

_{j}, there is no mechanism in ROPN to differentiate m

_{i}from m

_{j}. The ROPN methodology only allows the modeling of activities that use at most one resource at a time. AOPN is a remedy for this problem. AOPN is designed to tackle a modeling situation in which all the resources can be treated as independent of each other, and all instances of a resource can also be handled independently. AOPN can be considered as a natural extension to ROPN to support an activity demanding any number of resources and resource instances.

**n**activities and

**r**resources, the Table 1 shows the size of the Petri net models obtained by the three methodologies.

## 4. Petri Nets and Event Graphs: Definition and Properties

#### 4.1. Definitions

#### 4.1.1. Definition: Classic Petri Net (PN) [1,2]

- A classic Petri Net is a 4-tuple PN = (P, T, A, m), where
- P is the set of places, P = {p
_{1}, p_{2}, … , p_{n}} - T is the set of transitions, T = {t
_{1}, t_{2}, … , t_{m}}, - A is the set of arcs (from places to transitions and from transitions to places),
- A ⊆ (P × T) ⋃ (T × P), and
- m is the row vector of markings (tokens) on the set of places
- m = [m(p
_{1}), m(p_{2}), …, m(p_{n})] ∈ N^{n}, m0 is the initial marking. - Definition: Input and Output Sets of a Place

_{j}to represent the set of input transitions of a place p

_{j}and p

_{j}• to represent the set of output transitions of p

_{j}.

_{j}= {t

_{i}∈ T: (t

_{i}, p

_{j}) ∈ A}, p

_{j}• = {t

_{i}∈ T: (p

_{j}, t

_{i}) ∈ A}.

#### 4.1.2. Definition: Timed Petri Net (TPN)

- A Timed Petri Net is a 5-tuple TPN = (P, T, A, m0, D), where
- PN = (P, T, A, m0) is a classic Petri Net, and
- D: T → R
^{+}is the duration function—a mapping of each transition to a positive rational number, meaning that the firing of each transition t_{i}takes dt_{i}time units.

#### 4.1.3. Definition: Event Graph (EG)

_{j}| = |p

_{j}•| = 1.

#### 4.1.4. Definition: Strongly Connected Graph

#### 4.1.5. Definition: Elementary Circuit

#### 4.2. Properties of Strongly Connected Event Graphs

- Property 2: Performance is bounded by its critical circuit [1,20]. The critical circuit is the elementary circuit that has the lowest flowrate r·r* = min Σ(m(p
_{n}))/Σ(dt_{i}), where Σ(dt_{i}) is the sum of the firing times of the transitions in the circuit and Σ(m(p_{n})) is the sum of all tokens in that circuit. - Property 3: Under the assumption that a transition fires as soon as it is enabled, the firing rate of each transition in steady state (the same as the current token flow rate at any point in the circuit) is given by r = r* [20].
- Property 4: Deadlock-free if, and only if, every elementary circuit contains at least one token [1].

## 5. Implementing Petri Nets with GPenSIM

- A classic Petri Net: firing times are not assigned to any of the transitions, meaning all the transitions are primitive [2]; or
- A Timed Petri Net: firing times are assigned to all the transitions, meaning all the transitions are nonprimitive.

#### 5.1. Implementing Timed Petri Nets with GPenSIM

- No variable firing time: the transitions representing events are assigned a firing time beforehand. The pre-assigned firing time can be deterministic (e.g., firing time dt
_{i}= 5 TU) or stochastic (e.g., firing time dt_{i}is normally distributed with mean value 10 TU and standard deviation 2 TU). However, variable firing times are not possible. - Maximal-step firing policy: The Timed Petri Net operates with the maximal-step firing policy; this means that, if more than one transition is collectively enabled and they are not in conflict with each other at a point of time, all of them fire at the same time.
- Enabled transition starts firing immediately: enabled transition can start firing immediately as long as there is no (forcibly) induced delay between the time a transition became enabled and the time it is allowed to fire.

_{i}is normally distributed with mean value 10 TU and standard deviation 2 TU).”

#### 5.2. The GPenSIM Functions for the Performance Evaluation of Event Graphs

- Flag 1: whether the Petri net is a Binary Petri Net or not (0 = not a binary Petri Net).
- Flag 2: whether the Petri net is a State Machine or not (0 = not a State Machine).
- Flag 3: whether the Petri net is an Event Graph or not (0 = not an Event Graph).
- Flag 4: whether the Petri net is a Timed Petri Net or not (0 = not a Timed Petri Net).
- Flag 5: number of Strongly Connected Components in the Petri Net.

_{n}))/Σ(dt

_{i})] of the critical circuit, the expected flowrate (efr) can be achieved by either

- Increasing the token count of the critical circuit by Δm0,where Δm0 = [efr × Σ(dt
_{i})] − Σ(m(p_{n})); or - Reducing the delay (total firing times) of the circuit by Δft,where Δft = Σ(dt
_{i}) − [Σ(m(p_{n}))/efr].

## 6. Simulation of Event Graphs with GPenSIM: An Example

- The input raw material of type 1 arrives on the conveyor belt C1. Robot R1 picks up the raw material of type 1 and places into the machine M1. Similarly, robot R2 picks up the raw material of type 2 from conveyor belt C2 and places it into the machine M2.
- Machine M1 makes the part P1, and M2 makes the part P2. When the parts are made by the machines M1 and M2, they are placed on the assembly station (AS) by the robots R1 and R2, respectively.
- Assembly station AS is used to join the two parts P1 and P2 together to form the semiproduct. Robot R2 does the part assembly at AS.
- Robot R3 picks the product from the assembly station and places it on the painting station PS.
- Robot R4 performs the surface polishing and painting.
- Once the painting is completed, robot R3 picks up the completed product from the painting station PS and packs it into the cartridge OB.

- tC1: conveyor belt C1 brings the input material of type 1 into the FMS.
- tC2: conveyor belt C2 brings the input material of type 2 into the FMS.
- tC1M1: robot R1 moves raw material from conveyor belt C1 and places it on M1.
- tC2M2: robot R2 moves raw material from conveyor belt C2 and places it on M2.
- tM1: machining of part 1 at machine M1.
- tM2: machining of part 2 at machine M2.
- tM1AS: robot R1 moves part 1 from M1 to the Assembly Station AS.
- tM2AS: robot R2 moves part 2 from M2 to the Assembly Station AS.
- tAS: robot R2 assembles parts P1 and P2 together at the assembly station AS.
- tAP: robot R3 picks the product from the assembly station and places on the painting station PS.
- tPS: robot R4 performs surface polishing and painting on the product.
- tPCK: when the painting job is finished, R3 packs the product into the output cartridge.

#### 6.1. The Petri Net Model

- The supply of raw materials from the input buffers (IB1 and IB2) is never exhausted;
- The finished product will be placed into the output buffer OB that has no capacity restraints.

#### 6.2. GPenSIM Code for Simulation

- Petri Net Definition File (PDF): This is the coding of the static Petri net (the structure of the Petri net defined by the sets of places, transitions, and arcs).
- Main Simulation File (MSF): In this file, the initial dynamics (e.g., initial tokens in places pC1, pC2, pR1, pR2, and pR3, and the firing times of transitions) are declared.
- COMMON_PRE: In this file, the conditions for the enabled transitions to start firing are coded. However, in this FMS example, there are no additional conditions for the transitions as they start firing whenever they become enabled.
- COMMON_POST: The postfiring actions of the transitions are coded in this file. Again, this file is not necessary for the FMS example, as there are no post-actions needed to be carried out.

- The cycle that creates the deadlock,
- The current flow rate, and
- How we can increase the flow rate to 0.07 tokens per TU.

`%%%% MSF: the main simulation file %%%%%%%%%%%%%%%%%%%%%`

`clear all; clc;`

`global global_info`

`global_info.STOP_AT = 100; % stop simulation after 100 TU`

`pns = pnstruct('fms_pdf'); % declare the PDF`

`% declare the firing times of the transitons`

`dyn.ft = {'tC1',10,'tC2',10, 'tM1',5,'tM2',10,'tAS',7,...`

`'tPS',8, 'tPCK',3, 'allothers'>,2};`

`% declare the initial markings`

`dyn.m0 = {'pC1',1,'pC2',1, 'pR1',1,'pR2',1,'pR3',1,'pR4',1, ...`

`'po1AS',1,'po2AS',1};`

`% combine static and dynamic parts to form the Petri net`

`pni = initialdynamics(pns, dyn);`

`mincyctime(pni, 0.07); % find the minimum cycle of event graph`#### 6.3. The Simulation Results

`This is a Strongly Connected Petri net.`

`Cycle-1: -> pC2 -> tC2 -> poC2 -> tC2M2`

`TotalTD = 12 TokenSum = 1 Cycle Time = 12`

`Cycle-2: -> tM2AS -> pi2AS -> tAS -> pR2 -> tC2M2 -> piM2 -> tM2 -> poM2`

`TotalTD = 21 TokenSum = 1 Cycle Time = 21`

`Cycle-3: -> pC1 -> tC1 -> poC1 -> tC1M1`

`TotalTD = 12 TokenSum = 1 Cycle Time = 12`

`Cycle-4: -> pR1 -> tC1M1 -> piM1 -> tM1 -> poM1 -> tM1AS`

`TotalTD = 9 TokenSum = 1 Cycle Time = 9`

`Cycle-5: -> po1AS -> tM1AS -> pi1AS -> tAS`

`TotalTD = 9 TokenSum = 1 Cycle Time = 9`

`Cycle-6: -> pi2AS -> tAS -> po2AS -> tM2AS`

`TotalTD = 9 TokenSum = 1 Cycle Time = 9`

`Cycle-7: -> pR4 -> tPS`

`TotalTD = 8 TokenSum = 1 Cycle Time = 8`

`Cycle-8: -> poAS -> tAP -> piPS -> tPS -> piCK -> tPCK -> pR3 -> tAS`

`TotalTD = 20 TokenSum = 1 Cycle Time = 20`

`Minimum-cycle-time is: 21, in cycle number-2`

`*** Token Flow Rate: ***`

`In steady state, the firing rate of each transition is:`

`1/C* = 0.047619`

`meaning, on average, 0.047619 tokens pass through`

`any node in the Petri net, per unit period of time.`

`*** We can increase the current flow rate to 0.07 tokens/TU, by improving the critical circuit alone ...`

`In the circuit-2 either:`

`1. increase the sum of tokens by 1 tokens, or,`

`2. decrease the total delay (firing times) by 6.7143 TU.`## 7. The Two Phases of the AOPN Approach

#### 7.1. Phase I: Creating the Static Petri Net Graph

#### 7.2. Phase II: Adding the Run-Time Dynamics

## 8. Simulation with GPenSIM

#### 8.1. Scheduling Using GPenSIM

- Instances of a resource: A resource can have many indistinguishable copies (“instances”), e.g., there are three cashiers in a shop (resource cashier has three instances). For a customer, it does not make sense to prefer one cashier over the others. In this case, we could generalize all the cashiers into a group, name this resource as “cashier”, and say that cashier is a single resource with three instances.
- Generic resources: There are some “named” resources available, but all of them are the same for some specific applications, e.g., in a mechanical workshop, there are three mechanics named “Alan”, “Bobby”, and “Chan”; though they are specialists in some works, when it comes to engine repair, they all are the same. Thus, for engine repair, we can pick a generic mechanic, without specifically naming anyone.
- Specific resources: When the resources are named, we may request specific (named) resources. For example, in the mechanical workshop, “Chan” is an electrician. Hence, when we need an electrical fixing, we would prefer to use the specific resource “Chan”.
- Write Access: When a resource has many instances, a transition may try to acquire one or many of these instances. Write access means that the resource will be locked, and all the instances will be made available to a requesting transition.

#### 8.2. Code Implementation with GPenSIM

`% PDF: 'fms_AOPN_pdf.m'`

`function [png] = fms_AOPN_pdf()`

`png.PN_name = 'AOPN model of a FMS';`

`png.set_of_Ps = {'pIB1','pIB2', 'pOB',... %input & output buffers`

`'poC1','poC2','piM1','piM2','poM1', 'poM2', ...%intermediate buffers`

`'pi1AS','pi2AS','poAS', 'piPS','piCK'}; %intermediate buffers`

`png.set_of_Ts = {'tC1','tC2', 'tC1M1','tC2M2', 'tM1','tM2',...`

`'tM1AS','tM2AS','tAS', 'tAP', 'tPS', 'tPCK'};`

`png.set_of_As = {'pIB1','tC1',1, 'tC1','poC1',1, ... % tC1 connections`

`'poC1','tC1M1',1, 'tC1M1','piM1',1, ... % tC1M1 connections`

`'piM1','tM1',1, 'tM1','poM1',1,... % tM1 connections`

`'poM1','tM1AS',1, 'tM1AS','pi1AS',1,... % tM1AS connections`

`'pIB2','tC2',1, 'tC2','poC2',1, ... % tC2 connections`

`'poC2','tC2M2',1, 'tC2M2','piM2',1,... % tC2M2 connections`

`'piM2','tM2',1, 'tM2','poM2',1,... % tM2 connections`

`'poM2','tM2AS',1, 'tM2AS','pi2AS',1,... % tM2AS connections`

`'pi1AS','tAS',1,'pi2AS','tAS',1, 'tAS','poAS',1,... % tAS connections`

`'poAS','tAP',1, 'tAP','piPS',1,... % tAP connections`

`'piPS','tPS',1, 'tPS','piCK',1, ... % tPS connections`

`'piCK','tPCK',1, 'tPCK','pOB',1}; % tPCK connections`**MSF**:

`% MSF: 'fms_AOPN.m'`

`% AOPN model of a Flexible Manufacturing System`

`global global_info`

`global_info.STOP_AT = 300;`

`pns = pnstruct('fms_AOPN_pdf'); % the PDF file`

`dp.m0 = {'pIB1',3,'pIB2',3}; % initial markings on the places`

`dp.ft = {'tC1',10,'tC2',10,'tM1',5,'tM2',10,... % firing times`

`'tAS',7,'tPS',8, 'tPCK',3, 'allothers',2}; % firing times`

`dp.re = {'C1',1,inf,'C2',1,inf, 'M1',1,inf,'M2',1,inf, ... % resources`

`'R1',1,inf,'R2',1,inf,'R3',1,inf,'R4',1,inf}; % resources`

`pni = initialdynamics(pns, dp); % initial run-time PetriNet`

`sim = gpensim(pni); % simulation iterations`

`prnschedule(sim); % print the simulation results`**COMMON_PRE**:

`function [fire, transition] = COMMON_PRE(transition)`

`switch`

`transition.name`

`case'tC1', granted = requestSR({'C1',1});`

`case'tC1M1', granted = requestSR({'R1',1});`

`case'tM1', granted = requestSR({'M1',1});`

`case'tC2', granted = requestSR({'C2',1});`

`case'tC2M2', granted = requestSR({'R2',1});`

`case'tM2', granted = requestSR({'M2',1});`

`case'tAS', granted = requestSR({'R3',1});`

`case'tPS', granted = requestSR({'R4',1});`

`case {'tM1AS','tM2AS', 'tAP','tPCK'}, granted = 1; % request nothing`

`end % switch`

`fire = granted; % fire if the required resource is granted`**COMMON_POST**:

`function [] = COMMON_POST(transition)`

`switch transition.name`

`case'tC1' % do nothing`

`case'tC1M1', release('tC1'); % release resource acquired by tC1`

`case'tM1', release(); % release resource acquired by tM1`

`case'tM1AS', release('tC1M1'); % release resource acquired by tC1M1`

`case'tC2' % do nothing`

`case'tC2M2', release('tC2'); % release resource acquired by tC2`

`case'tM2', release(); % release resource acquired by tM2`

`case'tM2AS'% do nothing`

`case'tAS', release('tC2M2');`

`case'tAP' % do nothing`

`case'tPS', release(); % 'R4'`

`case'tPCK', release('tAS');`

`end % switch`

`n = ntokens('pOB'); % get the number of tokens in pOB`

`if eq(n,3), global_info.STOP_SIMULATION = 1; end % stop if n==3`#### 8.3. Simulation Result

**pIB1**and

**pIB2**. The simulation result gives a very detailed analysis of the resource usage. Also, if the transitions (activities) and the resources are assigned costs (fixed costs and variable costs), the final costs of the products would be displayed in the result; however, the costs are neglected (assigned zero value) in this example.

`Simulation results`

`RESOURCE USAGE:`

`RESOURCE INSTANCES OF ***** C1 *****`

`tC1 [0 : 12]`

`tC1 [12 : 24]`

`tC1 [24 : 36]`

`Resource Instance: C1:: Used 3 times. Utilization time: 36`

`RESOURCE INSTANCES OF ***** C2 *****`

`tC2 [0 : 12]`

`tC2 [12 : 33]`

`tC2 [33 : 54]`

`Resource Instance: C2:: Used 3 times. Utilization time: 54`

`RESOURCE INSTANCES OF ***** M1 *****`

`tM1 [12 : 17]`

`tM1 [24 : 29]`

`tM1 [36 : 41]`

`Resource Instance: M1:: Used 3 times. Utilization time: 15`

`RESOURCE INSTANCES OF ***** M2 *****`

`tM2 [12 : 22]`

`tM2 [33 : 43]`

`tM2 [54 : 64]`

`Resource Instance: M2:: Used 3 times. Utilization time: 30`

`RESOURCE INSTANCES OF ***** R1 *****`

`tC1M1 [10 : 19]`

`tC1M1 [22 : 31]`

`tC1M1 [34 : 43]`

`Resource Instance: R1:: Used 3 times. Utilization time: 27`

`RESOURCE INSTANCES OF ***** R2 *****`

`tC2M2 [10 : 31]`

`tC2M2 [31 : 52]`

`tC2M2 [52 : 73]`

`Resource Instance: R2:: Used 3 times. Utilization time: 63`

`RESOURCE INSTANCES OF ***** R3 *****`

`tAS [24 : 44]`

`tAS [45 : 65]`

`tAS [66 : 86]`

`Resource Instance: R3:: Used 3 times. Utilization time: 60`

`RESOURCE INSTANCES OF ***** R4 *****`

`tPS [33 : 41]`

`tPS [54 : 62]`

`tPS [75 : 83]`

`Resource Instance: R4:: Used 3 times. Utilization time: 24`

`RESOURCE USAGE SUMMARY:`

`C1: Total occasions: 3 Total Time spent: 36`

`C2: Total occasions: 3 Total Time spent: 54`

`M1: Total occasions: 3 Total Time spent: 15`

`M2: Total occasions: 3 Total Time spent: 30`

`R1: Total occasions: 3 Total Time spent: 27`

`R2: Total occasions: 3 Total Time spent: 63`

`R3: Total occasions: 3 Total Time spent: 60`

`R4: Total occasions: 3 Total Time spent: 24`

`***** LINE EFFICIENCY AND COST CALCULATIONS: *****`

`Number of servers: k = 8`

`Total number of server instances: K = 8`

`Completion = 86`

`LT = 688`

`Total time at Stations: 309`

`LE = 44.9128 %`

`**`

`Sum resource usage costs: 0 (NaN% of total)`

`Sum firing costs: 0 (NaN% of total)`

`Total costs: 0`

`**`## 9. Discussion

#### 9.1. Gpensim Is Not Only for Event Graphs

#### 9.2. The Advantages of the AOPN Approach

## Author Contributions

## Conflicts of Interest

## References

- Peterson, J.L. Petri Net Theory and the Modeling of Systems; Prentice-Hall: Englewood Cliffs, NJ, USA, 1981. [Google Scholar]
- Proth, J.M. Performance evaluation of manufacturing systems. In Practice of Petri Nets in Manufacturing; Springer: Dordrecht, The Netherlands, 1993; pp. 147–183. [Google Scholar]
- Commoner, F.; Holt, A.W.; Even, S.; Pnueli, A. Marked directed graphs. J. Comput. Syst. Sci.
**1971**, 5, 511–523. [Google Scholar] [CrossRef] - GPenSIM: A General Purpose Petri Net Simulator. Available online: http://www.davidrajuh.net/gpensim (accessed on 15 December 2017).
- Davidrajuh, R. Developing a new Petri net tool for simulation of discrete event systems. In Proceedings of the IEEE Second Asia International Conference on Modeling & Simulation (AICMS 08), Kuala Lumpur, Malaysia, 13–15 May 2008; pp. 861–866. [Google Scholar]
- Davidrajuh, R. Modeling Discrete-Event Systems with GPenSIM: An Introduction; Springer: Dordrecht, The Netherlands, 2018. [Google Scholar]
- Pan, X.L.; He, G.; Zhang, C.J.; Ming, T.F.; Wang, X.C. Research on Modeling and Simulating of Discrete Event System Based on Petri Net. In Advanced Engineering Forum; Trans Tech Publications: Zürich, Switzerland, 2012; Volume 4, pp. 80–85. [Google Scholar]
- Davidrajuh, R. Modeling Humanoid Robot as a Discrete Event System: A Modular Approach Based on Petri Nets. In Proceedings of the IEEE 2015 3rd International Conference on Artificial Intelligence, Modelling and Simulation (AIMS), Sabah, Malaysia, 2–4 December 2015. [Google Scholar]
- Cameron, A.; Stumptner, M.; Nandagopal, N.; Mayer, W.; Mansell, T. Rule-based peer-to-peer framework for decentralised real-time service oriented architectures. Sci. Comput. Program.
**2015**, 97, 202–234. [Google Scholar] [CrossRef] - Lopez, F.; Barton, K.; Tilbury, D. Simulation of Discrete Manufacturing Systems with Attributed Hybrid Dynamical Nets. Unpublished work. 2017. [Google Scholar]
- Chang, H. A Method of Gameplay Analysis by Petri Net Model Simulation. J. Korea Game Soc.
**2015**, 15, 49–56. [Google Scholar] [CrossRef] - Jyothi, S.D. Scheduling Flexible Manufacturing System Using Petri-Nets and Genetic Algorithm; Department of Aerospace Engineering, Indian Institute of Space Science and Technology: Thiruvananthapuram, India, 2012. [Google Scholar]
- Hussein, L.Z.S. Simulation of Food Restaurant Using Colored Petri Nets. J. Eng. Dev.
**2014**, 18, 77–88. [Google Scholar] - Sanders, W.H.; Meyer, J.F. Stochastic activity networks: Formal definitions and concepts. In School Organized by the European Educational Forum; Springer: Berlin/Heidelberg, Germany, 2000; pp. 315–343. [Google Scholar]
- Davidrajuh, R. Activity-Oriented Petri Net for Scheduling of Resources. In Proceedings of the 2012 IEEE International Conference on Systems, Man, and Cybernetics, Seoul, Korea, 14–17 October 2012. [Google Scholar]
- Davidrajuh, R. Representing Resources in Petri Net Models: Hardwiring or Soft-coding? In Proceedings of the 2011 IEEE International Conference on Service Operations and Logistics, and Informatics, Beijing, China, 10–12 July 2011. [Google Scholar]
- Davidrajuh, R. Scheduling using ‘Activity-based Modeling’. In Proceedings of the 2011 IEEE Conference on Computer Applications & Industrial Electronics (ICCAIE 2011), Penang, Malaysia, 4–7 December 2011. [Google Scholar]
- Wu, N.; Zhou, M. System Modeling and Control with Resource-Oriented Petri Nets; CRC Press: New York, NY, USA, 2010. [Google Scholar]
- Zhou, M.C.; DiCesare, F. Parallel and sequential mutual exclusions for Petri net modeling of manufacturing systems with shared resources. IEEE Trans. Robot. Autom.
**1991**, 7, 515–527. [Google Scholar] [CrossRef] - Chretienne, P. Exécutions controlées des réseaux de Petri temporisés. TSI Tech. Sci. Inform.
**1984**, 3, 23–31. [Google Scholar] - Cormen, T.H. Introduction to Algorithms; MIT Press: Cambridge, MA, USA, 2009. [Google Scholar]
- Rader, C.M. Connected components and minimum paths. In Graph Algorithms in the Language of Linear Algebra; Jeremy, K., Gilbert, J., Eds.; SIAM Publications: Philadelphia, PA, USA, 2011. [Google Scholar]
- Tiernan, J.C. An efficient search algorithm to find the elementary circuits of a graph. Commun. ACM
**1970**, 13, 722–726. [Google Scholar] [CrossRef] - Johnson, D.B. Finding all the elementary circuits of a directed graph. SIAM J. Comput.
**1975**, 4, 77–84. [Google Scholar] [CrossRef] - Complete Code for the Examples. Available online: http://www.davidrajuh.net/gpensim/Pub/2018/computers-j/ (accessed on 15 December 2017).
- Skolud, B.; Krenczyk, D.; Davidrajuh, R. Solving Repetitive Production Planning Problems. An Approach Based on Activity-oriented Petri Nets. In Advances in Intelligent Systems and Computing, Proceedings of the International Joint Conference SOCO’16-CISIS’16-ICEUTE’16 (ICEUTE 2016, SOCO 2016, CISIS 2016), San Sebastián, Spain, 19–21 October 2016; Springer: Cham, Switzerland, 2017; Volume 527, pp. 397–407. [Google Scholar]
- Davidrajuh, R. Solving Assembly Line Balancing Problems with Emphasis on Cost Calculations: A Petri nets Based Approach. In Proceedings of the IEEE Modelling Symposium (EMS), Pisa, Italy, 21–23 October 2014; pp. 99–104. [Google Scholar]
- Davidrajuh, R. Developing a petri nets based real-time control simulator. Int. J. Simul. Syst. Sci. Technol. IJSSST
**2012**, 12, 28–36. [Google Scholar] - Fadhilah, R. Fuzzy Petri Nets as a Classification Method for Automatic Speech Intelligibility Detection of Children with Speech Impairments. Ph.D. Thesis, University of Malaya, Kuala Lumpur, Malaya, 2016. [Google Scholar]
- Melberg, R. Modeling, Simulation, and Control of Atlantic Salmon Farming Industry Processes. Ph.D. Thesis, University of Stavanger, Stavanger, Norway, 2010. [Google Scholar]

**Table 1.**Summary: Comparing Process-Oriented Petri Nets (POPN), Resource-OPN (ROPN), and Activity-OPN (AOPN).

**Table 2.**General-purpose Petri Net Simulator (GPenSIM) functions for performance evaluation of strongly connected event graphs (SCEG).

GPenSIM Function | Purpose |
---|---|

pnclass | Find out the class of Petri net |

stronglyconn | Find out the number of strongly connected components in the Petri net |

mincyctime | Finding the performance bottleneck in a SCEG |

cycles | Extract the elementary circuits in a Petri Net |

Transition | Resources Required to Start Firing | Resources Released After Firing |
---|---|---|

tC1 | C1 | - |

tC1M1 | R1 | C1 (acquired by tC1) |

tM1 | M1 | M1 |

tM1AS | - | R1 (acquired by tC1M1) |

tC2 | C2 | - |

tC2M2 | R2 | C2 (acquired by tC2) |

tM2 | M2 | M2 |

tM2AS | - | - |

tAS | R3 | R2 (acquired by tC2M2) |

tAP | - | - |

tPS | R4 | R4 |

tPCK | - | R3 (acquired by tAS) |

GPenSIM Function | Purpose |
---|---|

availableInst | check whether any instances are available in a resource |

availableRes | check whether any resources are available (not in use) |

requestsSR | request a number of instances from specific (“named“) resources |

requestGR | request a number of resource instances, without naming any re-source |

requestAR | request a number of resource instances among many alternatives |

requestWR | request all the instances of a specific resource (either all or none) |

release | release all the resources and resource instances held by a transition |

Prnschedule | prints information on resource usage |

© 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Davidrajuh, R.; Skolud, B.; Krenczyk, D.
Performance Evaluation of Discrete Event Systems with GPenSIM. *Computers* **2018**, *7*, 8.
https://doi.org/10.3390/computers7010008

**AMA Style**

Davidrajuh R, Skolud B, Krenczyk D.
Performance Evaluation of Discrete Event Systems with GPenSIM. *Computers*. 2018; 7(1):8.
https://doi.org/10.3390/computers7010008

**Chicago/Turabian Style**

Davidrajuh, Reggie, Bozena Skolud, and Damian Krenczyk.
2018. "Performance Evaluation of Discrete Event Systems with GPenSIM" *Computers* 7, no. 1: 8.
https://doi.org/10.3390/computers7010008