Model Simplification in Petri Net Models

Reggie Davidrajuh

Electrical and Computer Engineering

University of Stavanger

Stavanger, Norway

e-mail: reggie.davidrajuh@uis.no

Abstract—Model simplification is a methodology to reduce size

and complexity of models, e.g. by moving some of the details

away from the model and into the model implementation code.

This paper talks about supporting Petri net model

simplification in a new tool for modeling and simulation of

discrete event dynamic systems. Firstly, this paper presents a

brief introduction to model abstraction and model

simplification. Secondly, this paper presents a brief

introduction to the new tool known as GPenSIM. Thirdly,

through a case study, this work shows how model

simplification can be done in GPenSIM and also how effective

or useful model simplification can be. The case study shows

how a large Petri model can be simplified using the

functionalities provided in GPenSIM.

Keywords-model simplificaion; Petri nets; discrete event

dynamic systems; GPenSIM

I. INTRODUCTION

This paper talks about supporting model simplification methodology to simplify models created by a new tool for modeling and simulation of discrete event dynamic systems (DEDS). The new tool is known as General Purpose Petri Net simulator (GPenSIM)[5].

As the real-life system models are sometimes too complicated and too large to understand, modelers do make model simplifications to simplify the models so that they become easy to understand, extend, and debug.

A. Aim and Scope of this Paper

The scope of this work is limited to showing the model

simplification methods supported by GPenSIM. As

explained later, in GPenSIM, model simplification is a

choice between two concepts known as ‘hard-wiring’

(keeping elements in the model so that the model - though

large - resembles the real-life system) and ‘soft-coding’

(removing elements from model and make it visible in only

in the implementation code).

The other relevant topics in system modeling (see figure 1) such as model evaluation (whether the conceptual model adequately represent the real-life system), model validation (whether the discrete model adequately represent the model it is generated from) and model verification (whether the implemented model - the executable software - accurately represent the discrete model) are out of scope of this paper.

II. LITERATURE REVIEW ON MODEL ABSTRACTION AND

MODEL SIMPLIFICATION

Figure 1 (adapted from [4]) explains system modeling approaches from real-life system to conceptual model, discrete model, simplified discrete model, and model implementation.

Figure 1 shows that model simplification is not the same

as model abstraction; model simplification follows model abstraction.

Real-life

Model

Conceptual

Model

Model

Implementation

(Discrete) Petri

net Model

Simplified Petri

net Model

Observe

Evaluate

Abstract

Validate

Simplify

Validate

Implement

Verify

Fig. 1. Model development

approach

2011 UKSim 5th European Symposium on Computer Modeling and Simulation

978-0-7695-4619-3/11 $26.00 © 2011 IEEE

DOI 10.1109/EMS.2011.91

162

A. System Model

Figure 2 presents the model of a system showing the interaction between the three fundamental components of a system, namely: 1. The source (input from the environment into the system,

and the output from the system to the environment), 2. The system primitive elements (elements that makeup

the system), and 3. The connections that exist in the system (connections

between the elements). Following, a model can be abstracted by making the

following three simplifications on the three components: 1. The sources (input and output) can be simplified, 2. The elements can be reduced, and 3. The connections between the elements can be reduced

Literature classifies methods that reduce the sources as “model boundary modification” methods and the reductions on the elements and the connections as “model behavior modification” methods [4]. Figure 3 shows the relationship between the system model and the model abstraction methods that can be applied on a model.

B. Model Simplification

By model simplification, the details on the discrete model are lessened to make it more readable. For example, some of the elements that are ‘hard-wired’ in the discrete model can be removed so that these become visible and be coded in the software implementation (‘soft-coding’). This technique is referred to as hard-wiring versus soft-coding. GPenSIM supports model simplification as a choice between hard-wiring and soft-coding.

III. GPENSIM: A TOOL SUPPORTING MODEL

SIMPLIFICATION

General Purpose Petri Net Simulator (GPenSIM) is a tool for modeling and simulation of discrete-event dynamic systems (DEDS) [5]; GPenSIM is based on Petri nets [1]. The reasons for developing a new simulator are:

For basic users:

• a tool that is easy to understand and easy to use, even for users with minimal mathematical and programming skills

For advanced users:

• allow seamless integration of DEDS models with the other toolboxes that are readily available on the MATLAB platform;

• allow easy extension of GPenSIM functions GPenSIM is developed by the author of this paper, in

order to satisfy the three criteria stated above (ease of use, flexible, and extensible). GPenSIM is realized as a toolbox for the MATLAB platform, so that diverse toolboxes that available in the MATLAB environment (e.g. Fuzzy Logic Toolbox, Control Systems Toolbox, Advanced Statistical Analysis Toolbox, etc. [8]) can be used in the models that are developed with GPenSIM.

A. Existing Tools for Discrete Event Simulation

There are many tools that satisfy the three criteria mentioned above. However, as a new tool, GPenSIM allows seamless integration of other technologies (e.g Fuzzy Logic) with Petri net models through a well-designed interface known Transition Definition Files (TDF); TDF is explained in the following section.

B. Architecture of GPenSIM

Figure 4 shows the architecture of GPenSIM; models that are developed with GPenSIM consist of a number of files (M-files or MATLAB files):

• Main Simulation File (MSF): this is the main file that calls the other files; in MSF, initial conditions and variables are declared, and then the simulation is run; finally, the simulation results are plotted and analyzed.

• Petri Net Definition Files (PDF): these files define the static structure of the discrete model.

elements connections

Environment

Sources

System

Fig.2: Concept of a system

2. reduce

elements(“model

behaviour

modification”)

3. reduce

connections (“model

behaviour

modification”)

Environment

1. reduce Sources

(“model boundary

reduction”)

System

Fig.3. Model abstraction techniques

163

• Transition Definition Files (TDF): TDF files are basically to code ‘guard conditions’ meaning conditions that must be satisfied before an enabled transition can fire. However, the TDFs are also the files where one can implement, for example - a fuzzy logic based inference engine or an inference mechanism that make decisions based on statistical analysis of massive data.

There are two types of TDFs:

• Individual (for a specific transition) PRE and POST files: a PRE TDF file checks whether guard conditions are satisfied before an enabled transition can fire; it can also reserve resource for use by the transition; a POST TDF file can release resources used by the fired transition and can do book keeping work (statistics) after the transition firing.

• COMMON PRE and POST files: these files are common for all the transitions; a COMMON PRE can, for example, reserve a resource that is generally used by any firing transition; likewise, a COMMON POST can release the commonly used resource after firing of a transition.

C. Summary: Methodology for Modeling and Simulation

with GPenSIM

Creating a Petri net model consists of three steps: 1. Defining the static Petri net graph (PDF files), 2. Defining firing conditions, if any (TDF files), and, 3. Assigning initial dynamics and execute the model

(the MSF).

IV. SUPPORTING MODEL SIMPLIFICATION IN GPENSIM

There are various ways for simplifying Petri net models; e.g.: 1. Level of depth: if the model has many levels deep, each

level communicating with of the level just above or below it, then each level can be separated into submodels forming a hierarchy of models; thus each submodel becomes a simple model, making the whole hierarchy a simple one.

2. Level of breadth: if the model has many different functionalities, each are separable from the rest of the model, then these functionalities can be modeled into separate modules; thus the model becomes a composition of simple modules, making both the model and its modules simpler.

3. Focus of the model (separation of foreground and background processes): the processes that are (running) in the background can be removed from the model and be moved into another model or into the code implementation; keeping only the foreground processes makes the model simpler.

The third category mentioned above namely, “Focus of the model” is discussed further in to the next subsection.

A. Model simplification by moving background processes

into code implementation

This subsection takes resources as an example on moving background processes into code implementation. Usually,

Petri net models show resources as ‘hard-wired’ in the model, adding a lot of complexity to the model, keeping resources hard-wired in the model demands: 1. A lot of connections between the resources and its

consumers, 2. Parallel connections to show the number of resources

available (instances of resources), and, 3. Details of semaphores or locking mechanisms to

guarantee mutual exclusion property of the resources, meaning at most one consumer at a time.

If the resources are not the focus of the model then the resources can be removed from the model and their functionalities can be coded in the model implementation (soft-coding). In order to allow soft-coding of resources and their usage, the following functionalities related to them should be supported in the software; GPenSIM supports these functionalities as inbuilt functions: 1. Declaring resources, 2. Utilizing resources (functions for requesting (reserving),

allocating, and releasing resources), 3. Declaring Priorities of different transitions, 4. Changing priorities of transitions: functions for

increasing or decreasing priority of a transition, and comparing priorities of transitions, and,

5. Reporting resource usage: new print functions that show total resource usage, idle time, etc.

The following fundamental assumption was made in GPenSIM for realizing the additional functions for modeling resources: A resource is a ‘critical section’ meaning a resource can be used by only one active element (in Petri nets: ‘transition’) at a time; this means, resources posses ‘mutual exclusion’ property. (Though a resource can be used by only one transition at a time, a transition can use as many resource as it wants, limited only by availability).

Similar to resources, scheduling is also a very important issue in modeling and simulation of DEDS, which can be soft-coded in model implementation, rather than hard-wired in the model itself; GPenSIM offers inbuilt functions for all the functionalities for scheduling, like reserving or requesting resources, releasing resources after use, resource usage statistics, priorities, mutual exclusion, etc.

V. CASE STUDY

In order to provide a better understanding on how GPenSIM supports model simplification, this section presents a case study about airport modeling; the example is based on another work by authors, see [3]; however, discussion on model simplification is new and not done in [3].

A. Airport Model

Airport capacity generally refers to three types of capacities such as [7]:

• Processing capacity (volume of passengers that can be handled efficiently through the ticket counter and baggage check-in, passenger security screening, and passport control and customs, baggage claim, etc.)

164

• Holding capacity (areas in which passengers wait for some events as the check-in opening for a flight, the start of flight boarding, etc), and,

• Flow capacity (the number of passengers using the airport per a time unit, and the average time taken for them for their transportation at the air port)

Figure 4 depicts a conceptual model for airport flow capacity management at an airport, showing the main processes involved in the model. There are nine modules involved in the conceptual model; the eight modules are related to airplane movement (‘Arrival’ to ‘Takeoff’); in addition, the ninth module ‘Control Tower’ controls and coordinates the other eight modules.

Making a crude mathematical or discrete event model

that satisfies only the absolute basic ATC (Air Traffic Control) rules (such as at most one airplane at the runway at anytime; landings have priority over the takeoffs) is rather straight forward; figure 5 shows such a model based on Petri nets.

In figure 5, the landing and the takeoff are represented by three transactions each; this is because of the three types of aircrafts (A/C) handled by an airport. The International Civil Aviation Organization (ICAO) categorizes these aircrafts as A, B and C, based on threshold speed; large passenger aircrafts like Boeing 737 and Airbus A320 are classified as Category-A, medium sized aircrafts like Dash 8 is classified as Category-B, and small aircrafts like Dornier 228 is classified as Category-C. The three types of A/Cs have significant differences in speed, thus takes different runway lengths when landing and takeoff. Smaller aircrafts (Category-C) takes short runway strip when landing and quickly exit the runway through rapid exit taxiways (RETs); whereas, larger aircrafts (Category-A) takes the whole runway strip when landing and usually exit the runway at the end of the runway [3].

Though the airport model shown in figure 5 may look simple, it may still be too large for some preliminary analysis. The model certainly is not easy to implement as it has 14 places, 14 transitions, and a whole 39 arcs (connections). Making a PDF files that codes 39 connections (in addition to the declarations for 14 places and 14 transitions) is no easy task and is prone to errors. Generally, if there n number of places and m number of transitions, then the connections are on the order of O(m x n) [2]. Thus, one may explore the possibilities for simplifying the model.

B. Airport Model Simplification

First of all, the control tower which is hard-wired in the model is a common resources used by all the other modules (except for taxiing). The control tower can be taken as a background process, removing it from the Petri net model and be soft-coded in the code implementation.

Secondly, the landing and takeoff are represented by 3 transactions each; this is because of the three categories of the aircrafts using the landing strip (Runway). However, it is not compulsory to differentiate the three categories hard-wired in the model; in the Petri net model, a single transaction alone can represent landing (and another transaction for takeoff), in the differentiation can be soft-coded by allocating different firing times for the transaction to represent the different aircraft category.

C. Simplified Airport Model

Figure 6 shows the simplified model; the simplified model consists of 12 places, 9 transitions, and just 15 connections (arcs). Thus, the simplified model has 14% less places, 36% less transitions, and 62% less connections. The reduction in the number of connection (62%) is remarkable.

Though the simplified model is easy to understand and implement, it does not look logical and does not resemble the real-life system: this is because, the coordinator of any airport – the control tower – is missing in the simplified model. Also, the simplified model does not differentiate small aircrafts from large aircrafts, something very visible in flow capacity modeling.

Arrival About to

Land

Landing

Taxiing

Terminal

Taxiing

Takeoff About to

Takeoff

Control

Tower

Fig. 4. Main process modules of the

conceptual model for an airport

165

Fig. 5. Petri net model of airport flow capacity

ARRIVAL ABOUT TO

LAND

LANDING

TAXIING

CONTROL

TERMINAL

ABOUT TO

TAKEOFF TAKEOFF

PARR TARR PABL TABL PLAN1 PLAN2

TLAN1

TLAN2

TLAN3

TTAX1 TTAX2

PCON2 TCON PCON1

PABT TABT PTAK1 PTAK2

TTAK1

TTAK2

TTAK3

PTER2 TTER PTER1

PARK

PPAR1 TPAR PPAR2

TAXIING

166

Fig. 6. Simplified Petri net model of airport flow capacity

ARRIVAL ABOUT TO

LAND LANDING

TERMINAL

ABOUT TO

TAKEOFF TAKEOFF

PARR TARR PABL TABL PLAN1 PLAN2

TLAN2

TTAX1 PABT TABT PTAK1 PTAK2

TTAK2

PTER2 TTER PTER1

PARK

PPAR1 TPAR PPAR2

TAXIING

TTAX2

TAXIING

VI. CONCLUSION

This paper talks about supporting model simplification

methodology to simplify Petri models created by a new tool

for modeling and simulation of discrete event dynamic

systems (DEDS), known as General Purpose Petri Net

simulator (GPenSIM). As models for the real-life system are

sometimes too complicated and too large to understand,

modelers do make model simplifications to simplify the

models so that they become easy to understand, extend, and

debug.

Though a case study, this paper shows that though model

simplification provides compact models, the models do not

resemble the real-life systems; thus, model simplification

becomes a trade-off between compactness versus

resemblance.

REFERENCES

[1] Cassandras, G. and LaFortune, S. Introduction to Discrete Event

Systems. Hague, Kluwer Academic Publications, 1995

[2] Davidrajuh, R. “Representing Resources in Petri Net Models: Hardwiring or Soft-coding?”, 2011 IEEE Int. Conf. on Service Operations and Logistics, and Informatics, Beijing, China, July 10-12, 2011; pp. 62-67

[3] Davidrajuh, R. and Lin, Binshan (2011) Exploring Airport Traffic Capability Using Petri Net based Model. Expert Systems With Applications (ESWA), 38 (2011) pp. 10923-10931; Publisher: Elsevier publications.

[4] Frantz, F. (1995) A taxonomy of model abstraction techniques. 27th conference on Winter simulation (WSC'95), IEEE Computer Society, Arlington, Virginia, United States, pp. 1413—1420.

[5] GPenSIM (2011). Available: http://www.davidrajuh.net/gpensim/

[6] Hruz, B. and Zhou. M. Modeling and Control of Discrete-event Dynamic Systems: with Petri Nets and other Tool. Springer-Verlag, London, 2007

[7] Transportation Research Board (1987) Special Report 215: Measuring Airport Landside Capacity. TRB, National Research Council, Washington, D.C.

[8] MATLAB (2011) Available: http://www.mathworks.com

167