Model Simplification in Petri Net Models - IEEE Xplore

0 downloads 0 Views 170KB Size Report
Model Simplification in Petri Net Models. Reggie Davidrajuh. Electrical and Computer Engineering. University of Stavanger. Stavanger, Norway e-mail: ...
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