2011 UKSim 5th European Symposium on Computer Modeling and Simulation
Model Simplification in Petri Net Models
Reggie Davidrajuh Electrical and Computer Engineering University of Stavanger Stavanger, Norway e-mail:
[email protected]
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.
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. Real-life Model Observe Evaluate
Keywords-model simplificaion; Petri nets; discrete event dynamic systems; GPenSIM
I.
Conceptual Model
INTRODUCTION
Abstract
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.
Validate
(Discrete) Petri net Model Simplify Validate
Simplified Petri net Model
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. 978-0-7695-4619-3/11 $26.00 © 2011 IEEE DOI 10.1109/EMS.2011.91
Implement Verify
Model Implementation Fig. 1. Model development approach
Figure 1 shows that model simplification is not the same as model abstraction; model simplification follows model abstraction.
162
A. System Model
Environment 1. reduce Sources
Environment
(“model boundary reduction”)
Sources System
System
elements
connections
3. reduce connections
(“model behaviour modification”)
(“model behaviour modification”)
Fig.3. Model abstraction techniques
Fig.2: Concept of a system
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.
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.
•
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. 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 hardwiring and soft-coding. III.
2. reduce elements
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.
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:
163
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.
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.
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.)
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,
164
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.
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. •
Arrival
About to Land
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 hardwired 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 softcoded by allocating different firing times for the transaction to represent the different aircraft category.
Landing
Taxiing Control Tower Terminal
Takeoff
About to Takeoff
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.
Taxiing
Fig. 4. Main process modules of the conceptual model for an airport
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].
165
LANDING ABOUT TO LAND
ARRIVAL
TLAN1
TLAN2
PARR
TARR
PABL
TABL
PLAN1
PLAN2 TLAN3
CONTROL PCON2 TCON
PCON1
TTAK1 TTAK2 PABT
PTAK1
TABT
PTAK2 TTAK3
ABOUT TO TAKEOFF
TAKEOFF TAXIING
TAXIING
TTAX2
TTAX1
TERMINAL PTER2
TTER
PTER1
PARK PPAR1
TPAR
PPAR2
Fig. 5. Petri net model of airport flow capacity
166
ABOUT TO LAND
ARRIVAL
LANDING
TLAN2
PARR
TARR
PABL
TABL
PLAN1
PLAN2
TTAK2 TTAX2
PABT
PTAK1
TABT
ABOUT TO TAKEOFF
TAXIING
PTAK2
TTAX1 TAXIING
TAKEOFF TERMINAL
PTER2
TTER
PTER1
PPAR1
TPAR
PPAR2
PARK
Fig. 6. Simplified Petri net model of airport flow capacity
REFERENCES 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.
[1] [2]
[3]
[4]
[5] [6]
[7]
[8]
167
Cassandras, G. and LaFortune, S. Introduction to Discrete Event Systems. Hague, Kluwer Academic Publications, 1995 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 1012, 2011; pp. 62-67 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. 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. GPenSIM (2011). Available: http://www.davidrajuh.net/gpensim/ Hruz, B. and Zhou. M. Modeling and Control of Discrete-event Dynamic Systems: with Petri Nets and other Tool. Springer-Verlag, London, 2007 Transportation Research Board (1987) Special Report 215: Measuring Airport Landside Capacity. TRB, National Research Council, Washington, D.C. MATLAB (2011) Available: http://www.mathworks.com
