# A New Modular Petri Net for Modeling Large Discrete-Event Systems: A Proposal Based on the Literature Study

## Abstract

**:**

## 1. Introduction

## 2. Literature Review on Modular Petri Nets

#### 2.1. The Problem with Petri Net Models

- Petri net models of real-life systems are huge: Even for simple systems, the Petri net models of these are not small or compact [8].
- Slowness in simulation: During simulations, the tokens in a Petri net have to go through every transition and place on their path. Also, the transitions have to be checked for their enabledness and the other firing conditions from the environment. This makes the simulations run slowly. Also, the enormous sizes of Petri nets contribute to slowness in simulation.
- Difficulty in analyzing the model: Again, due to the huge size of the model, analyzing the model for its structural and behavioral properties become a time-consuming task.
- “State Explosion”: The most important and useful property of Petri nets is their explicit state space. The state space is automatically generated, showing every possible state that can be eventually reached from an initial state. However, for real-life systems, the state space is huge if not of infinite size. Drawing any conclusions (e.g., model checking) from the huge or infinite state space is often difficult if it is possible at all [9,10,11].

#### 2.2. Literature Review on Modular Petri Nets

#### 2.2.1. First-Generation Works: Ease of Modeling

#### 2.2.2. Second-Generation Works: Analysis

#### 2.2.3. Third-Generation Works: Applications & Tools

#### 2.2.4. Fourth-Generation Works: Independent Modules for Modeling Smart Manufacturing

#### 2.3. Conclusions Drawn from the Literature Study

- Advantages of modularizing: Literature study reveals that modularization is to reap the benefits such as flexibility (ability to add or change functionality), comprehensibility (readability of the models), reduction in the development time, and robustness (less prone to error).
- On the modularity of systems: Petri net models of real-life discrete-event systems are large and complex. However, these large and complex systems can be modeled as modular models.
- On the scope of a module: A module can trap a specific type of model logic for particular users.
- On interfacing the modules: Old fashioned monolithic pathways (based on master or supervisor) interfacing is not appropriate for inter-modular communication. Interfacing must be at every module level, making the module independently react with the rest of the system and the environment.
- On the design of modules: Timed P/T Petri Net can serve as the skeleton of the module. Timed colored Petri nets are for embedding more detailed data on tokens.
- Attacking ambiguities in the model: Some of the ambiguities can be realized as logical conditions, and can be kept away from the Petri net model (e.g., as logic conditions in processor files).
- –
- Fusion places: The fusion places are for modeling convenience as they are aliases for a place; the fusion places are to eliminate arcs crisscrossing the model. If the fusion places are put in different modules, since they represent the same place, these will be used to synchronize the modules.
- –
- Substitution transition: A substitution transition is for information hiding; a substitution transition represents a complete Petri net module consisting of many places and transitions. Thereby, a substitution transition hides the lower-level details of a module on a higher-level (overall) model.
- –
- Fusion Transitions: A fusion transition (some times referred to as “shared transition”) is to allow synchronization of Petri net modules. The shared transitions reside in different modules, but they represent the same transition. Thus, the shared transitions synchronize the modules.
- –
- Communication of a module with the outside world must be streamlined through input and output ports; transitions can be used as ports.

## 3. Towards the Design of a New Modular Petri Net

- Independent development of modules and analysis (to reduce the complexity of development and analysis of the overall model).
- The modules must be capable of running independently, presumably on different processors (CPU, to reduce the computation time).

#### Independent Development of Modules and Analysis

**Inter-Modular Connector (IMC)**that consists of just the three places representing the resources ${R}_{X}$, ${R}_{Y}$, and ${R}_{Z}$. The modular model supports data hiding, clear-cut interfacing, and suited for parallel execution:

- Interface to the module: Module-A possesses input ports (A1, tD1, and tD2) and output ports (A4) that function as the input and output interface of the module. The input and out ports have global visibility and can be accessed like global variables.
- Data hiding: Module-A also possesses local members (transitions A2 and A3, and places pA12, pA23, pA34, pD1, and pD2) that have local (modular) visibility, thus can not be seen or accessed outside the module.
- Independent module development: As seen in Figure 3, module-A can be independently developed, with two drivers replacing the places ${R}_{X}$ and ${R}_{Y}$, and two stubs also replacing the places ${R}_{X}$ and ${R}_{Y}$.

## 4. Design of Modular Petri Nets

#### 4.1. Transitions and Their Visibility

- Activity-orientedness: When modeling a discrete-event system, transitions are the primary focus.
- Visibility: Transitions possess different visibility, such as global, modular, and private visibility.

#### 4.2. Visibility of Transitions in a Monolithic Petri Net

**global visibility**, and (2)

**private visibility**.

#### 4.2.1. Global Visibility

#### 4.2.2. Private Visibility

## 5. Composition of Modular Petri Nets

#### 5.1. Transitions in Modular Petri Nets

- Input Ports: The transitions that function as the input ports of the modules. e.g., tA1 is the input port of Alfa. tBI1 and tBI2 are the input ports of Beta. Thus,${T}_{IP{\Phi}_{Alfa}}=\left\{tAI1\right\}$${T}_{IP{\Phi}_{Beta}}=\{tBI1,tBI2\}$${T}_{IP}={T}_{IP{\Phi}_{Alfa}}\cup {T}_{IP{\Phi}_{Beta}}$
- Local transitions: The transitions that are internal members (not input or output ports) of modules. e.g., tAL1 and tAL2, and tBL1 and tBL2 are the local transitions of Alfa and Beta, respectively.${T}_{L{\Phi}_{Alfa}}=\{tAL1,tAL2\}$${T}_{L{\Phi}_{Beta}}=\{tBL1,tBL2\}$${T}_{L}={T}_{L{\Phi}_{Alfa}}\cup {T}_{L{\Phi}_{Beta}}$
- Output Ports: The transitions that function as the output ports of the modules. e.g., tAO1 and tAO2 are the output ports of Alfa. tBO1 is the output port of Beta.${T}_{OP{\Phi}_{Alfa}}=\{tAO1,tAO2\}$${T}_{OP{\Phi}_{Beta}}=\left\{tBO1\right\}$${T}_{OP}={T}_{OP{\Phi}_{Alfa}}\cup {T}_{OP{\Phi}_{Beta}}$
- Inter-Modular transitions: The transitions that are members of Inter-modular connectors. e.g., tG1 in Gamma, and tD1 in Delta.${T}_{IM{\Psi}_{Gamma}}=\left\{tG1\right\}$${T}_{IM{\Psi}_{Delta}}=\left\{tD1\right\}$${T}_{IM}={T}_{IM{\Psi}_{Gamma}}\cup {T}_{IM{\Psi}_{Detla}}$${T}_{{\Phi}_{Alfa}}={T}_{IP{\Phi}_{Alfa}}\cup {T}_{L{\Phi}_{Alfa}}\cup {T}_{OP{\Phi}_{Alfa}}$ (all the transitions of Alfa)${T}_{{\Phi}_{Beta}}={T}_{IP{\Phi}_{Beta}}\cup {T}_{L{\Phi}_{Beta}}\cup {T}_{OP{\Phi}_{Beta}}$ (all the transitions of Beta)$T={T}_{IP}\cup {T}_{L}\cup {T}_{OP}\cup {T}_{IM}$ (the set of all transitions in the Petri net)Also, $T={T}_{{\Phi}_{Alfa}}\cup {T}_{{\Phi}_{Beta}}\cup {T}_{IM}$ (the set of all transitions in the Petri net)

- Local places: The places that are local to modules. e.g., pAL1 to pAL5 in Alfa, and pBL1 to pBL4 in Beta.${P}_{L{\Phi}_{Alfa}}=\{pAL1,\dots ,pAL5\}$ (local places of Alfa)${P}_{L{\Phi}_{Beta}}=\{pBL1,\dots ,pBL4\}$ (local places of Beta)${P}_{L}={P}_{L{\Phi}_{Alfa}}\cup {P}_{L{\Phi}_{Beta}}$ (local places of all the modules)
- Inter-Modular places (${P}_{IM}$): The places that are members of IMCs. e.g., pG1 to pG3 in Gamma, and pD1 to pD4 in Delta.${P}_{IM{\Psi}_{Gamma}}=\{pG1,\dots ,pG3\}$ (IM places of Gamma)${P}_{IM{\Psi}_{Delta}}=\{pD1,\dots ,pD4\}$ (IM places of Delta)${P}_{IM}={P}_{IM{\Psi}_{Gamma}}\cup {P}_{IM{\Psi}_{Detla}}$ (IM places of all IMCs) $P={P}_{L}\cup {P}_{IM}$ (set of all the places in the Petri net)

#### 5.2. Visibility of Transitions in a Modular Petri Net

- Inter-modular transitions have global visibility: All the transitions of the inter-modular connectors ($\forall t\in {T}_{IM}$) have global visibility, thus are accessible in COMMON_PRE and COMMON_POST.
- Input and output ports have global visibility: All the transitions that are input or output ports of modules ($\forall t\in ({T}_{IP}\cup {T}_{OP})$) also have global visibility, thus are accessible in COMMON_PRE and COMMON_POST.
- Local transitions have modular visibility: Transitions that are local members of modules ($\forall t\in {T}_{L}$) have local visibility as they are accessible only in their modular processors MOD_PRE & MOD_POST. For example, transitions tAL1 and tAL2 (tBL1 and tBL2) are local members of the modules Alfa (resp. Beta), and hence are accessible only in their modular processors MOD_Alfa_PRE, MOD_Alfa_POST (resp. MOD_Beta_PRE, MOD_Beta_POST).However, these local transitions are not accessible in COMMON_PRE and COMMON_POST, as these transitions do not possess global visibility.
- Input and output ports have modular visibility too: Transitions that are input or output ports of modules ($\forall t\in ({T}_{IP}\cup {T}_{OP})$) are also members of their respective modules. Hence, they are accessible in their respective MOD_PRE and MOD_POST files too. e.g., input port tAI1 is accessible in COMMON_PRE and COMMON_POST (global visibility). As the input port of Alfa, tAI1 is accessible in MOD_Alfa_PRE and MOD_Alfa_POST too (modular visibility).
- Every transition in a modular Petri net ($\forall t\in T$) has its private visibility. Any transition, be a local member, input or output port of a module, or a member of an inter-modular connector, can have its own processor files. For example, tG1, tAI1, tBO1, tBL2 are are accessible in their own processor files, such as tG1_pre & tG1_post, tAI1_pre & tAI1_post, tBO1_pre & tOB2_post, and tBL2_pre & tBL2_post, respectively, if these files exist.

## 6. The Design of Modules

- Data hiding: Data hiding inside modules is to abstract away the internal details at higher levels.
- Independent modules: The modules are independent of each other, and have the potential to become autonomous.
- Synchronization of modules: Synchronization ensures that modules must be able to run on different processors. e.g., modules are wrapped as agents and run in parallel in a swarm environment.

#### 6.1. Petri Module

**Input ports ${T}_{IP}$**: Input port transitions function as the input gates of a module. Only through these transitions (input ports), tokens can be directed into the module. These input port transitions have global visibility (accessible in COMMON_PRE and COMMON_POST). Also, due to the belonging to a module, these transitions have local visibility too (accessible in their own modular MOD_PRE and MOD_POST).**Output ports ${T}_{OP}$**: Output port transitions function as the output gates of a module. Only through these transitions (output ports), tokens can be directed away from the module. Just like the input port transitions, these output port transitions also have global visibility (can be accessed in COMMON_PRE and COMMON_POST), and local visibility too (accessible in the modular MOD_PRE and MOD_POST).**Local transitions ${T}_{L}$**: As the local member (internal element) of a module, a local transition consumes tokens from local input places and deposits tokens into local output places. A local transition cannot have any direct connection with the external places (places outside the modules).The local transitions of a module have limited visibility (only modular visibility) as these can be accessed only in the modular MOD_PRE and MOD_POST. The local transitions are not accessible in the global COMMON_PRE and COMMON_POST processors.**Local places ${P}_{L}$**: As the local member of a module, a local place feeds tokens to either local transitions or input and output ports of the module. A local place gets tokens from either local transitions or input and output ports of the module. A local place cannot have any direct connection with the external transitions.

#### 6.2. Inter-Modular Connectors

**IM transitions ${T}_{IM}$**: IM transitions have global visibility and are accessible in the COMMON_PRE and COMMON_POST processors. Since IMCs are not modules, these transitions don’t have the modular processors MOD_PRE and MOD_POST.**IM places ${P}_{IM}$**: just like the local places inside the modules, the IM places are passive too.

## 7. Formal Definitions for the New Entities

#### 7.1. Formal Definition of Petri Module

- ${T}_{IP\Phi}\subseteq T$: ${T}_{IP\Phi}$ is known as the input ports of the module.
- ${T}_{L\Phi}\subseteq T$: ${T}_{L\Phi}$ is known as the local transitions of the module.
- ${T}_{OP\Phi}\subseteq T$: ${T}_{OP\Phi}$ is known as the output ports of the module.
- ${T}_{IP\Phi}$, ${T}_{L\Phi}$, and ${T}_{OP\Phi}$, are all mutually exclusive:${T}_{IP\Phi}\cap {T}_{L\Phi}={T}_{L\Phi}\cap {T}_{OP\Phi}={T}_{OP\Phi}\cap {T}_{IP\Phi}=\varnothing $.
- ${T}_{\Phi}={T}_{IP\Phi}\cup {T}_{L\Phi}\cup {T}_{OP\Phi}$ (the transitions of the module).
- ${P}_{L\Phi}\subseteq P$ is known as the set of local places of the module. Since a module has only local places, ${P}_{\Phi}\equiv {P}_{L\Phi}$.
- $\forall p\in {P}_{L\Phi}$,
- –
- $\u2022p\in ({T}_{\Phi}\cap \varnothing )$. (input transitions of local places are either the transitions of the module or none)
- –
- $p\u2022\in ({T}_{\Phi}\cap \varnothing )$. (output transitions of local places are either the transitions of the module or none)This means, local places cannot have direct connections with external transitions.

- $\forall t\in {T}_{L\Phi}$,
- –
- $\u2022t\in ({P}_{L\Phi}\cap \varnothing ).$ (input places of local transitions are either the local places or none (cold start))
- –
- $t\u2022\in ({P}_{L\Phi}\cap \varnothing ).$ (output places of local transitions either the local places or none (sink))

- $\forall t\in {T}_{IP\Phi}$
- –
- $\u2022t\in ({P}_{L\Phi}\cup {P}_{IM}\cup \varnothing ).$ (input places of input ports can be local places or places in inter-modular connectors or can be even an empty set)
- –
- $t\u2022\in ({P}_{L\Phi}\cup \varnothing )$. (output places of input ports can only be local places, or empty set)

- $\forall t\in {T}_{OP\Phi}$
- –
- $\u2022t\in ({P}_{L\Phi}\cup \varnothing ).$ (input places of output ports can be local places or an empty set)
- –
- $t\u2022\in ({P}_{L\Phi}\cup {P}_{IM}\cup \varnothing )$. (output places of output ports can be local places or places in inter-modular connectors or empty set.

- ${A}_{\Phi}\subseteq ({P}_{L}\times {T}_{\Phi})\cup ({T}_{\Phi}\times {P}_{L})$: where ${a}_{ij}\in {A}_{\Phi}$ is known as the internal arcs of the module.
- ${M}_{\Phi 0}=\left[M\left({p}_{L}\right)\right]$ is the initial markings in the local places.

#### 7.2. Formal Definition of Inter-Modular Connector

- ${P}_{\Psi}\subseteq P$: ${P}_{\Psi}$ is the set of places in the IMC (known as the IM-places). $\forall p\in {P}_{\Psi}$,
- –
- $\u2022p\in ({T}_{OP}\cap {T}_{\Psi}\cap \varnothing )$. (input transitions of IM places are either the output ports of modules, IM transitions of this IMC, or none)
- –
- $p\u2022\in ({T}_{IP}\cap {T}_{\Psi}\cap \varnothing )$. (output transitions of IM places are either the input ports of modules, IM transitions of this IMC, or none)This means, IM places cannot have direct connections with local transitions, or IM transitions of other IMCs.

- $\forall p\in {P}_{\Psi},\phantom{\rule{3.33333pt}{0ex}}\phantom{\rule{3.33333pt}{0ex}}\forall i\phantom{\rule{3.33333pt}{0ex}}\phantom{\rule{3.33333pt}{0ex}}p\notin {P}_{{\Phi}_{i}}$ (an IM-place cannot be a local place of any Petri module).
- ${T}_{\Psi}\subseteq T$: ${T}_{\Psi}$ is the transitions of the IMC (known as the IM-transitions). $\forall t\in {T}_{\Phi}$,
- –
- $\u2022t\in ({P}_{\Psi}\cap \varnothing ).$ (input places of IM-transitions are either the IM-places of this IMC, or none (cold start))
- –
- $t\u2022\in ({P}_{\Psi}\cap \varnothing ).$ (output places of IM-transitions either the IM-places of this IMC, or none (sink))

- $\forall t\in {T}_{\Psi},\phantom{\rule{3.33333pt}{0ex}}\phantom{\rule{3.33333pt}{0ex}}\forall i\phantom{\rule{3.33333pt}{0ex}}\phantom{\rule{3.33333pt}{0ex}}t\notin {T}_{{\Phi}_{i}}$ (an IM-transition cannot be a transition of any Petri module).
- ${A}_{\Psi}\subseteq (P\times T)\cup (T\times P)$: where ${a}_{ij}\in {A}_{\Psi}$ is known as the connecting arcs of the net.
- ${M}_{\Psi 0}=\left[M\left({p}_{\Psi}\right)\right]$ is the initial markings in the IM-places.

#### 7.3. Formal Definition of Modular Petri Net

- $\mathbb{M}={\sum}_{i=0}^{m}{\Phi}_{i}$ (zero or more Petri Modules)
- $\mathbb{C}={\sum}_{j=0}^{n}{\Psi}_{j}$ (zero or more Inter-Modular Connectors)

## 8. Application Example

#### 8.1. The Problem: Computing a Quadratic Function

- The client provides the job to compute, providing the values of the parameters involved (such as a, b, and c).
- The multiplier performs multiplications. e.g., for an input $(a,x,x)$, multiplier returns $(a\xb7{x}^{2})$. Similarly, if $(b,x)$ is input, multiplier returns $(b\xb7x)$.
- The adder computes the arithmetic sums. e.g., for an input $(x,y,z)$, adder returns the sum $(x+y+z)$.

#### 8.2. Petri Module of a Communicating Agent

- Observation.
- Process the inputs and make decisions.
- Actions.

- Transition tCreatMsg is for creating a message, and tDispMsg dispatches the messages. A copy of the transmitted message is kept in the place pDispdMsg until the acknowledgement for the message is received.
- Transition tRecvMsg receives the messages. Acknowledgement for the received messages is sent by tAckMsg. tProcessMsg is for processing the arrived message.
- Transition tRecvAck is for receiving an acknowledgement for the message that was sent earlier. When an acknowledgement is received then the corresponding message (copy of the message) is removed from the buffer pDispdMsg.

#### 8.3. Modular Petri Net Model

## 9. Discussion

- Active push/pull: Transitions functioning as the input ports can actively pull the tokens from the outside buffers. Hence, these tokens need not be inserted into the modules, which violates data hiding. Also, transitions actively pulling the tokens (e.g., messages) into the modules from the common buffers is a vital mechanism without which modeling intelligent agent will be impossible. Intelligent agents are supposed to act autonomously. In other words, transitions as input and output ports of modules enable modeling independent agents in a peer-to-peer topology.In a similar line, transitions functioning as output ports can flush the output tokens of the modules into the output buffers. This property is also important for modeling independent and autonomous modules (e.g., intelligent agents).
- Compression of model: As discussed in the section on literature study, Savi & Xie (1992) [13] presents a powerful technique for module compression, only if the module possesses transitions as input and out ports. However, this technique also demands that the module is modeled as an event-graph.

**Limitations of this work**: This paper is the first publication which explains the design of the new Modular Petri net. However, the modular Petri was put to the test on many occasions before; the new Modular Petri net for used for testing large-scale industrial systems, such as airport capacity management [52], modeling oil-drilling activities [53], modeling elevator operations [54], and multi-scale modelling [55]. All these industrial systems were large, and we believe that only with the new modular Petri net, we were able to model, simulate, and performance analyze these systems. The following limitation was experienced during the simulations of large industrial systems: larger the number of modules, slower the simulations will be. Other than simulation time, there were no limitations observed in terms of the number of places, transitions, or tokens.

**Further Work**: We identify two issues as further work: (1) distributed modules, and (2) Control modules.

## Funding

## Conflicts of Interest

## References

- Bause, F.; Kritzinger, P.S. Stochastic Petri nets: An introduction to the theory. ACM Sigmetrics Perform. Eval. Rev.
**1998**, 26, 2–3. [Google Scholar] [CrossRef] - Wang, J. Timed Petri Nets: Theory and Application; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2012; Volume 9. [Google Scholar]
- Marsan, M.A.; Balbo, G.; Conte, G.; Donatelli, S.; Franceschinis, G. Modelling with Generalized Stochastic Petri Nets; John Wiley & Sons, Inc.: Hoboken, NJ, USA, 1994. [Google Scholar]
- Haas, P.J. Stochastic Petri Nets: Modelling, Stability, Simulation; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2006. [Google Scholar]
- Jensen, K. Coloured petri nets. In Proceedings of the IEE Colloquium on Discrete Event Systems: A New Challenge for Intelligent Control Systems, London, UK, 4 June 1993. [Google Scholar]
- David, R.; Alla, H. Discrete, Continuous, and Hybrid Petri Nets; Springer: Berlin/Heidelberg, Germany, 2005. [Google Scholar]
- Peterson, J.L. Petri Net Theory and the Modeling of Systems; Prentice Hall PTR: Upper Saddle River, NJ, USA, 1981. [Google Scholar]
- Davidrajuh, R. Modular Petri net models of communicating agents. In Proceedings of the International Joint Conference SOCO’17-CISIS’17-ICEUTE’17, León, Spain, 6–8 September 2017; pp. 328–337. [Google Scholar]
- Valmari, A. The state explosion problem. In Advanced Course on Petri Nets; Springer: Berlin/Heidelberg, Germany, 1996; pp. 429–528. [Google Scholar]
- Clarke, E.; Grumberg, O.; Jha, S.; Lu, Y.; Veith, H. Progress on the state explosion problem in model checking. In Informatics; Springer: Berlin/Heidelberg, Germany, 2001; pp. 176–194. [Google Scholar]
- Baier, C.; Katoen, J.P. Principles of Model Checking; MIT Press: Cambridge, MA, USA, 2008. [Google Scholar]
- Davidrajuh, R.; Roci, A. Performance of Static Slicing Algorithms for Petri Nets. Int. J. Simul. Syst. Sci. Technol.
**2018**, 20, 15.1–15.7. [Google Scholar] [CrossRef] - Savi, V.M.; Xie, X. Liveness and boundedness analysis for petri nets with event graph modules. In International Conference on Application and Theory of Petri Nets; Springer: Berlin/Heidelberg, Germany, 1992; pp. 328–347. [Google Scholar]
- Claver, J.; Harhalakis, G.; Proth, J.; Savi, V.; Xie, X. A step-wise specification of a manufacturing system using Petri nets. In Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics, Charlottesville, VA, USA, 13–16 October 1991; pp. 373–378. [Google Scholar]
- De Jong, G.G.; Lin, B. A communicating Petri net model for the design of concurrent asynchronous modules. In Proceedings of the 31st Design Automation Conference, San Diego, CA, USA, 6–10 June 1994; pp. 49–55. [Google Scholar]
- Wang, L.C. Object-oriented Petri nets for modelling and analysis of automated manufacturing systems. Comput. Integr. Manuf. Syst.
**1996**, 9, 111–125. [Google Scholar] [CrossRef] - Wang, L.C.; Wu, S.Y. Modeling with colored timed object-oriented Petri nets for automated manufacturing systems. Comput. Ind. Eng.
**1998**, 34, 463–480. [Google Scholar] [CrossRef] - Lee, W.J.; Cha, S.D.; Kwon, Y.R. Integration and analysis of use cases using modular Petri nets in requirements engineering. IEEE Trans. Softw. Eng.
**1998**, 24, 1115–1130. [Google Scholar] - Xue, Y.; Kieckhafer, R.; Choobineh, F. Automated construction of GSPN models for flexible manufacturing systems. Comput. Ind.
**1998**, 37, 17–25. [Google Scholar] [CrossRef] - Christensen, S.; Petrucci, L. Modular analysis of Petri nets. Comput. J.
**2000**, 43, 224–242. [Google Scholar] [CrossRef] - Tsinarakis, G.J.; Tsourveloudis, N.; Valavanis, K.P. Modular Petri Net based modeling, analysis, synthesis and performance evaluation of random topology dedicated production systems. J. Intell. Manuf.
**2005**, 16, 67–92. [Google Scholar] [CrossRef] - Tsourveloudis, N.; Dretoulakis, E.; Ioannidis, S. Fuzzy work-in-process inventory control of unreliable manufacturing systems. Inf. Sci.
**2000**, 127, 69–83. [Google Scholar] [CrossRef] - Lee, H.; Banerjee, A. A modular Petri Net based architecture to model manufacturing systems exhibiting resource and timing uncertainties. In Proceedings of the IEEE International Conference on Automation Science and Engineering, Bangalore, India, 22–25 August 2009; pp. 525–530. [Google Scholar]
- Latorre-Biel, J.I.; Jiménez-Macías, E.; García-Alcaraz, J.L.; Muro, J.C.S.D.; Blanco-Fernandez, J.; Parte, M.P.D.L. Modular construction of compact Petri net models. Int. J. Simul. Process. Model.
**2017**, 12, 515–524. [Google Scholar] [CrossRef] - Bonnet-Torrès, O.; Domenech, P.; Lesire, C.; Tessier, C. E xhost-PIPE: PIPE extended for two classes of monitoring petri nets. In International Conference on Application and Theory of Petri Nets; Springer: Berlin/Heidelberg, Germany, 2006; pp. 391–400. [Google Scholar]
- Blätke, M.A.; Meyer, S.; Marwan, W. Pain signaling-A case study of the modular Petri net modeling concept with prospect to a protein-oriented modeling platform. In Proceedings of the 2nd International Workshop on Biological Processes & Petri Nets (BioPPN 2011), Newcastle upon Tyne, UK, 20 June 2011. [Google Scholar]
- Mahulea, C.; García-Soriano, J.M.; Colom, J.M. Modular Petri net modeling of the Spanish health system. In Proceedings of the 17th International Conference on Emerging Technologies & Factory Automation (ETFA 2012), Krakow, Poland, 17–21 September 2012. [Google Scholar]
- Mahulea, C.; Mahulea, L.; Soriano, J.M.G.; Colom, J.M. Modular Petri net modeling of healthcare systems. Flex. Serv. Manuf. J.
**2018**, 30, 329–357. [Google Scholar] [CrossRef] - Dos Santos Soares, M.; Vrancken, J. A modular Petri net to modeling and scenario analysis of a network of road traffic signals. Control. Eng. Pract.
**2012**, 20, 1183–1194. [Google Scholar] [CrossRef] - Slota, A.; Zajkac, J.; Uthayakumar, M. Synthesis of petri net based model of a discrete event manufacturing system for nonlinear process plan. Manag. Prod. Eng. Rev.
**2016**, 7, 62–72. [Google Scholar] - Davidrajuh, R. Distributed workflow based approach for eliminating redundancy in virtual enterprising. J. Supercomput.
**2013**, 63, 107–125. [Google Scholar] [CrossRef] - Dotoli, M.; Epicoco, N.; Falagario, M.; Cavone, G. A timed Petri nets model for performance evaluation of intermodal freight transport terminals. IEEE Trans. Autom. Sci. Eng.
**2015**, 13, 842–857. [Google Scholar] [CrossRef] - Giua, A.; DiCesare, F.; Silva, M. Petri net supervisors for generalized mutual exclusion constraints. IFAC Proc. Vol.
**1993**, 26, 379–382. [Google Scholar] [CrossRef] - Sessego, F.; Giua, A.; Seatzu, C. HYPENS: A Matlab tool for timed discrete, continuous and hybrid Petri nets. In International Conference on Applications and Theory of Petri Nets; Springer: Berlin/Heidelberg, Germany, 2008; pp. 419–428. [Google Scholar]
- Du, Y.; Tan, W.; Zhou, M. Timed compatibility analysis of web service composition: A modular approach based on Petri nets. IEEE Trans. Autom. Sci. Eng.
**2013**, 11, 594–606. [Google Scholar] [CrossRef] - Lee, J.; Bagheri, B.; Kao, H.A. A cyber-physical systems architecture for industry 4.0-based manufacturing systems. Manuf. Lett.
**2015**, 3, 18–23. [Google Scholar] [CrossRef] - Brettel, M.; Friederichsen, N.; Keller, M.; Rosenberg, M. How virtualization, decentralization and network building change the manufacturing landscape: An Industry 4.0 Perspective. Int. J. Mech. Ind. Sci. Eng.
**2014**, 8, 37–44. [Google Scholar] - Davis, J.; Edgar, T.; Porter, J.; Bernaden, J.; Sarli, M. Smart manufacturing, manufacturing intelligence and demand-dynamic performance. Comput. Chem. Eng.
**2012**, 47, 145–156. [Google Scholar] [CrossRef] - Berger, S.; Bogenreuther, M.; Häckel, B.; Niesel, O. Modelling availability risks of it threats in smart factory networks—A modular petri net approach. In Proceedings of the Twenty-Seventh European Conference on Information Systems (ECIS2019), Stockholm & Uppsala, Sweden, 8–14 June 2019. [Google Scholar]
- Song, Y.J.; Lee, J.K. Analysis of Petri net models using transitive matrix. In Proceedings of the SMC 2000 Conference Proceedings, 2000 IEEE International Conference on Systems, Man and Cybernetics, ‘Cybernetics Evolving to Systems, Humans, Organizations, and Their Complex Interactions’, Nashville, TN, USA, 8–11 October 2000. [Google Scholar]
- Billington, J.; Christensen, S.; Van Hee, K.; Kindler, E.; Kummer, O.; Petrucci, L.; Post, R.; Stehno, C.; Weber, M. The Petri net markup language: Concepts, technology, and tools. In International Conference on Application and Theory of Petri Nets; Springer: Berlin/Heidelberg, Germany, 2003; pp. 483–505. [Google Scholar]
- Bucci, G.; Vicario, E. Compositional validation of time-critical systems using communicating time Petri nets. IEEE Trans. Softw. Eng.
**1995**, 21, 969–992. [Google Scholar] [CrossRef] - Davidrajuh, R. Modeling Discrete-Event Systems with GPenSIM; Springer International Publishing: Cham, Switzerland, 2018. [Google Scholar] [CrossRef]
- GPenSIM. General-Purpose Petri Net Simulator. Technical Report. Available online: http://www.davidrajuh.net/gpensim (accessed on 14 November 2019).
- 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] - 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]
- Abbaszadeh, A.; Abedi, M.; Doustmohammadi, A. General Stochastic Petri Net approach for the estimation of power system restoration duration. Int. Trans. Electr. Energy Syst.
**2018**, 28, e2550. [Google Scholar] [CrossRef] - Mutarraf, U.; Barkaoui, K.; Li, Z.; Wu, N.; Qu, T. Transformation of Business Process Model and Notation models onto Petri nets and their analysis. Adv. Mech. Eng.
**2018**, 10, 1–21. [Google Scholar] [CrossRef] - Hussein, Z.S. Simulation of Food Restaurant Using Colored Petri Nets. J. Eng. Sustain. Dev.
**2014**, 18, 77–88. [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] - 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. Adv. Eng. Forum. Trans. Tech. Publ.
**2012**, 4, 80–85. [Google Scholar] [CrossRef] - Davidrajuh, R.; Lin, B. Exploring airport traffic capability using Petri net based model. Expert Syst. Appl.
**2011**, 38, 10923–10931. [Google Scholar] [CrossRef] - Davidrajuh, R.; Saadallah, N. Implementing A Cohesive PT Nets with Inhibitor Arcs in GPenSIM. Int. J. Simul. Syst. Sci. Technol.
**2017**, 18, 8.1–8.5. [Google Scholar] - Davidrajuh, R. Developing a Toolbox for Modeling and Simulation of Elevators. Int. J. Simul. Syst. Sci. Technol.
**2019**, 20, 1.1–1.6. [Google Scholar] [CrossRef] - Skolud, B.; Krenczyk, D.; Davidrajuh, R. Multi-assortment production flow synchronization. Multiscale modelling approach. EDP Sci.
**2017**, 112, 05003. [Google Scholar] [CrossRef] - Kammoun, M.A.; Rezg, N.; Achour, Z. New approach for air traffic management based on control theory. Int. J. Prod. Res.
**2014**, 52, 1711–1727. [Google Scholar] [CrossRef] - Kammoun, M.A.; Rezg, N.; Achour, Z.; Rezig, S. State space search for safe time Petri nets based on binary decision diagrams tools: Application to air traffic flow management problem. Stud. Inf. Control
**2016**, 25, 39–50. [Google Scholar] [CrossRef][Green Version]

**Figure 1.**Resource Allocation System [20].

**Figure 2.**Modularization using fusion places [20].

Work | Topics |
---|---|

Savi & Xie (1992) [13] and Claver et al. (1991) [14] | Module compression. |

De & Lin (1994) [15] | Clear-cut interfacing. |

Wang (1996) [16] and Wang & Wu (1998) [17] | Object-oriented Petri Nets. |

Lee et al. (1998) [18] | Decomposing a Petri net into modules based on functionality. |

Xue et al. (1998) [19] | Flexible manufacturing systems as systems with specific subsystems. |

Work | Topics |
---|---|

Christensen & Petrucci (2000) [20] | State space analysis. |

Tsinarakis et al. (2005) [21]; Tsourveloudis et al. (2000) [22] | Reusable module for ease of analysis. |

Lee & Banerjee (2009) [23] | Reconfigurable modules to tackle uncertainties associated with models. |

Latorre-Biel et al. (2017) [24] | Managerial implications of modularization. |

Work | Topics |
---|---|

Bonnet-Torres et al. (2006) [25] | Tool: Exhost-PIPE Application: Modeling Multi-Agent environment. |

Blatke et al. (2011) [26] | Tool: Formal language for modular communication Application: Modeling Molecular Networks. |

Mahulea et al. (2012) [27] Mahulea et al. (2018) [28] | Application: Modeling Spanish National Health System. |

Du et al. (2013) [35] | Application: Web Service Composition |

Dotoli et al. (2016) [32] | Application: Evaluation of Intermodal Freight Transport Terminals |

Dos & Vrancken (2012) [29] | Tool: Modular Place-Timed Petri net Application: Traffic signal control of network of intersections. |

Slota et al. (2016) [30] | Tool: Object Observable Petri Net Application: Modeling non-linear process planning in manufacturing systems. |

Davidrajuh (2013) [31] | Tool: GPenSIM (earlier version)—modules with clear-cut input and output ports Application: Elimination of redundancy in virtual enterprises. |

Generation | Topics |
---|---|

First Generation | Ease of modeling. |

Second Generation | Analysis of large Petri Nets. |

Third Generation | Tools for modeling modular Petri nets, and applications. |

Fourth Generation | Modules: Modeling large discrete-event systems with modules. |

Element | Purpose |
---|---|

tRecvAck | Receives acknowledgements. |

pRecvdAck | Buffer for received acknowledgements. |

tProcessAck | Processes received acknowledgements. |

pSentMsg | Buffer for storing sent messages. |

tCreatMsg | Creates new messages. |

pCreatedMsg | Buffer for newly created messages |

tDispMsg | Dispatches messages. |

pDispdMsg | Dispatched messages are kept until Ack. are received. |

tRecvMsg | Receives messages. |

pRecvdMsg | Buffer for newly received messages. |

tProcessMsg | Processes received messages. |

tProcessdMsg | Buffer for storing processed messages. |

pAckMsg | Buffer for keeping Ack. before dispatch. |

tAckMsg | Sends acknowledgement for the received messages. |

© 2019 by the author. 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. A New Modular Petri Net for Modeling Large Discrete-Event Systems: A Proposal Based on the Literature Study. *Computers* **2019**, *8*, 83.
https://doi.org/10.3390/computers8040083

**AMA Style**

Davidrajuh R. A New Modular Petri Net for Modeling Large Discrete-Event Systems: A Proposal Based on the Literature Study. *Computers*. 2019; 8(4):83.
https://doi.org/10.3390/computers8040083

**Chicago/Turabian Style**

Davidrajuh, Reggie. 2019. "A New Modular Petri Net for Modeling Large Discrete-Event Systems: A Proposal Based on the Literature Study" *Computers* 8, no. 4: 83.
https://doi.org/10.3390/computers8040083