Achieving Atomicity of Tokens in Time Petri Nets An Approach based on Virtual Tokens

Reggie Davidrajuh Electrical and Computer Engineering

University of Stavanger Stavanger, Norway

E-mail: reggie.davidrajuh@uis.no

Abstract—Token atomicity is a very important issue in Time Petri nets, as lack of atomicity causes some analysis problems like reachability analysis. Literature review provides some approaches for achieving atomicity property, such as ‘ASAP firing’, ‘delay before firing’, and ‘aging tokens’. This paper presents a new approach for achieving atomicity of tokens in Petri nets; the new approach uses ‘virtual’ tokens. A realization of this approach on MATLAB platform called GPenSIM is also briefly described in this paper. The uniqueness of this paper is that the new approach follows nature - replicating what happens to token flow in real-life discrete event dynamic systems.

Keywords- Atomicity of tokens; Petri net simulator; virtual tokens; GPenSIM; discrete event dynamic system

I. INTRODUCTION

When a new Petri net simulator known as General Purpose Petri Net Simulator (GPenSIM) was designed, the concept of atomicity and its realization in the tool was one of the fundamental design issues. Literature study revealed that there were at least three ways to achieve atomicity of tokens; however, these three ways have their own weakness; thus, a new way of achieving atomicity of tokens was designed and implemented in the newer version of GPenSIM (in version 6).

The scope of this paper is limited to presentation of the design problem, the solution, and also a case study to show the implementation in action. Though this paper is about Petri nets, only a brief introduction to Petri nets is given in this paper; interested readers are referred classical texts on Petri nets such as [1-3].

In this paper: In section-II, Time Petri net is briefly defined along with the concept of atomicity of tokens. From this definition, the need for achieving atomicity is discussed in section-III. Section-III also presents literature study on various ways of achieving atomicity. Section-IV presents the new approach to achieve atomicity with the help of virtual tokens. Section-V briefly presents GPenSIM, in which virtual tokens are implemented. Finally, section-VI presents a case study.

II. DEFINING TIME PETRI NETS

Time Petri Net (TPN) is defined as follows: TPN = (P, T, A, m0, Time),

Where, P = { pi } is the set of places, T = { ti } is the of transitions, A = { aij } is of directed arcs that connect either a transition to places or a place to transitions; the arcs can have integer valued weights. m0 is the initial markings representing tokens in various places. T represents the time taken by the various activities in a discrete event system. In a TPN model, time can be assigned to places or transitions, or to both.

Time = (Time_T, Time_P), Time_T: T � � is a function mapping the set of

transitions onto a set of real numbers, where the real numbers represent the firing time – the time taken by transitions to complete firing. Firing time can deterministic or stochastic.

Time_P: P � � is a function mapping the set of places onto a set of real numbers, where the real numbers represent the holding time – the time taken by a place to hold a token. Holding time can deterministic or stochastic.

According to Petri net dynamics [1], if input places to a transition have enough tokens, then the transition is enabled and that it can fire; firing of a transition leads to consumption of the input tokens from the input places. When the firing transition completes firing, it deposits new tokens into the output places. Let’s denote the time difference between the disappearance of the input tokens and the appearance of the output tokens as �t. It is the �t that is fundamental issue in atomicity; if �t is not zero, the TPN is supposed to possess ‘non-atomicity’ property. On the other hand, if �t is zero, then the TPN possess ‘atomicity’ property. Thus the property of atomicity can be defined as follows:

Definition of atomicity: When an enabled transition fires, it consumes input tokens from the input places and deposits output tokens into output places; this firing is atomic meaning a single non-interruptible step, where the time difference between the consumption of input tokens and the deposits of output tokens (�t) is zero.

2012 UKSim-AMSS 6th European Modelling Symposium

978-0-7695-4926-2/12 $26.00 © 2012 IEEE

DOI 10.1109/EMS.2012.61

162

2012 UKSim-AMSS 6th European Modelling Symposium

978-0-7695-4926-2/12 $26.00 © 2012 IEEE

DOI 10.1109/EMS.2012.61

162

2012 UKSim-AMSS 6th European Modelling Symposium

978-0-7695-4926-2/12 $26.00 © 2012 IEEE

DOI 10.1109/EMS.2012.61

173

The time �t creates some problems, especially in terms of reachability analysis [4-6]: during simulations, most of the states are not reachable due to the firings of the transitions and the ensuing disappearances of tokens.

III. ACHIEVING ATOMICITY OF TOKENS

Literature review presents three ways to deal with the issue of atomicity [4-8]:

1. Non-atomicity: ASAP Firing 2. Atomicity: Unavailable tokens and Delay before

Firing3. Atomicity: Aging of Tokens

1c) Transition firing is completeTime = tFT

1b) Transition is firing, but not complete yet0 < Time < tFT

1a) Transition is enabled and about to fireTime = 0

Fig.1: ASAP firing

A. Non-atomicity: ASAP Firing of Transitions This realization possesses non-atomicity property; the

time difference between the disappearance of input tokens and appearance of the output tokens (�t) is equal to the firing time of the transition (tFT), as shown in figure-1. For example, in figure-1a, at time t=0, when the enabled transition fires, it consumes the input token from the input place; figure-1b shows lack of any tokens in the system before completion of the firing at time t=tFT, at which an output token is deposited into the output place.

B. Atomicity: “Unavailable Tokens” and “Delay before Firing” In this realization, when a transition is enabled, the input

tokens in the input places are marked as unavailable and will be not be taken away from the input places, see figure-2b. Since the tokens to be deleted are marked as unavailable

(‘busy’), these tokens cannot be taken by other transitions; when the transition completes firing, the marked tokens are removed from the input places, and at the same time, the output tokens are deposited into the output places, see figure-2c. Since the output tokens are produced at the same time as the input tokens are destroyed, the atomicity property is maintained. This realization requires that all the tokens are assigned a tag to differentiate whether are available or unavailable.

2c) Transition firing is completeTime = tFT

2b) Transition is firing, but not complete yet0 < Time < tFT

2a) Transition is enabled and about to fireTime = 0

Fig.2: Unavailable tokens

Another version of this approach uses time delay; when an enabled transition is allowed to fire, it waits for a while; after a predefined time delay, the transition starts firing and also removes the input tokens from the input places. The delay in transition firing - the time difference between the enabled position and the start of firing - should give ample time for recording the state of the system. This realization requires that all the transitions are assigned delay timing.

C. Atomicity: Aging of Tokens In this realization, when a transition is enabled, the input

tokens in the input places immediately taken away and at the same time output tokens are deposited into the output places; however, these output tokens are marked as unavailable and are allowed to ‘age’ while the transition is still firing; see figure-3a and 3b.

When the transition completes firing, the tokens are ‘aged’ enough so that the ‘unavailable’ tag on them is removed and they become ordinary tokens ready to enable any transition. This realization too requires that all the tokens are assigned a tag to differentiate whether they are unavailable (‘aging’) or available.

163163174

3c) Transition firing is completeTime = tFT

3b) Transition is firing, but not complete yet0 < Time < tFT

3a) Transition is enabled and about to fireTime = 0

Fig.3: Aging tokens

IV. ACHIEVING ATOMICITY: A NEW APPROACH USING VIRTUAL TOKENS

The new approach proposed in this paper (and realized in GPenSIM software version 6) follows what really happens in a real-life system. The earlier versions of GPenSIM lacked atomicity property as during firings of the transitions, tokens simply vanished into the transitions and cannot be accounted for.

Let’s consider a simple manufacturing system in which a machine is attached to an input buffer containing input raw material; after machining, the machined parts will be placed into an output buffer that is also attached to the output of the machine.

pi po

tmFig.4: Petri net model of a simple manufacturing system

A. Observations on machining activity In the Petri net model of the manufacturing system, the

input buffer is represented by place pi, the input material by tokens in pi, the output buffer by place po, and the machine by transition tm. The resulting Petri net model looks exactly like the Petri net model shown in figures 1a-3a, and given below as figure-4.

Some observations about the machining activity:

1. When the machining starts, the machine (transition tm) consumes some input material (input tokens). Thus, input material (tokens) vanishes from the input place (pi) into the machine (tm).

2. While machining, the input material consumed by the machine is still inside the machine.

3. Only when the machining is complete, the machined parts are placed into the output buffer (po).

The new approach is designed by replicating what happens to the material flow in the machining operation.

B. The New Approach Following the real-life situation, the new approach to

achieve atomicity does the following steps (figure-5): 1. When the transition starts firing: at the start of firing,

the input tokens are removed from input places; then, these input tokens are transformed into ‘virtual tokens’, and are placed inside the ‘virtual places’; one can imagine that these ‘virtual tokens’ are residing inside the transition (figure-5a, 5b)

2. When the transition is still firing: as long as the firing goes on, the ‘virtual tokens’ remain inside the transition (figure-5b)

3. When the transition completes firing: once the transition firing is complete, the ‘virtual tokens’ vanishes, and at the same time, output tokens are deposited into the output places (figure-5c)

5c) Transition firing is completeTime = tFT

5b) Transition is firing, but not complete yet0 < Time < tFT

5a) Transition is enabled and about to fireTime = 0

Fig.5: Virtual tokens

The description given above indicates that there is considerable overheads involved in starting a transitions to fire (moving input tokens from input places into virtual places to become virtual tokens) and to complete a firing (removing virtual tokens from virtual places). In order to

164164175

assist performing these overheads, the new approach makes use of the pre- and post- processors of a transition (figure-6).

Pre-processor

Main processor

Post-processor

Figure-6: Composition of a transition

C. Pre- and Post-processors of a transition A transition consists of three components [9]: 1. Pre-processor: The main objective of a pre-processor

is to check whether an enable transition can fire by satisfying any additional conditions (‘guard conditions’) that are imposed on the transition. E.g. acquiring any resources that are needed for firing. However, on the subject of atomicity, the main role of the pre-processor is to remove the input tokens from input places and put them as virtual tokens inside the transition; this transformation happens only when the transition starts firing. Immediately after start of the firing, the control is passed to the main processor.

2. Main processor: the main processor is basically a time delay, which is equal to the ‘firing time’ of the transition. This time delay forces the virtual tokens to reside inside the transition for a period of time equal to the firing time.

3. Post-processor: The main role of the post-processor is to do some cleanup work after firing. E.g. releasing any resources that are used by the transition; doing some accounting work on the amount of resources used, etc. However, on the subject of atomicity, the main role of the post-processor is to clear all the virtual tokens that were residing inside the transition.

D. What is the advantage of the proposed approach? In summary, the main advantage of the approach

proposed in this paper for achieving atomicity property over the other three approaches (unavailable tokens, delay before firing, and aging of tokens) is that the proposed approach is realistic, and it obeys what happens in real-life situation.

V. GPENSIM GPenSIM is a Petri nets based tool for modeling and

simulation of discrete-event dynamic systems [9]. GPenSIM runs on MATLAB [10] platform. GPenSIM was developed by the author of this paper, for teaching discrete simulation [11-12]; it has been also successfully used to solve industrial problems too [13-17]. Version 4 of the tool is freely available in the link given as reference [9].

A. Why GPenSIM? There are three main reasons for developing GPenSIM: 1. A tool that should be very easy to learn and to use

even for users who have are have nominal mathematical knowledge and programming skills

2. For advanced users, GPenSIM should allow seamless integration of Petri net models with the other toolboxes on MATLAB platform like Fuzzy Logic, Control Systems, etc.

3. Compact simulation code

B. The M-Files of a Petri Net Model Since GPenSIM is a toolbox on MATLAB platform,

Petri net models created with GPenSIM consists of a number of M-files. Simple Petri net models have at least two files:

1. Petri Net Definition File (PDF): This file defines the static Petri net graph; this means, the set of places, the set of transitions, and the set of arcs are defined in this file.

2. Main Simulation File (MSF): Firstly, this file declares the dynamic details (e.g. initial tokens, firing times of the transitions, available systems resources, etc.) Secondly, it starts the simulation runs; finally, when the simulations are complete, it prints the results (e.g. token-map shown in figure-8, state-space shown in figure-9).

Generally, Petri net models have more M-files: Transition definition files (TDF) to code the additional conditions that an enabled transition is supposed to satisfy to start firing (“guard condition”). Further, TDFs can be broken into two types of files Pre_TDF files and Post_TDF files for coding pre- and post-processor parts of the transitions.

Robot_2

Robot_1

OutBuffer_1

OutBuffer_2

InBuffer

Fig.7: Sample application: Two plucking robots

VI. SAMPLE APPLICATION

A very simple example is presented here to show the virtual tokens in action.

Figure-7 shows a manufacturing environment where two robots ‘Robot_1’ and ‘Robot_2’ are picking incoming parts from the input conveyor belt ‘InBuffer’, and placing them into the outgoing conveyor belts ‘OutBuffer_1’ and ‘OutBuffer_2’, respectively. Robot_1 is faster than Robot_2;Robot_1 takes 5 seconds for the transfer whereas Robot_2

165165176

takes 8 seconds. For simplicity, it is assumed that there are only 3 parts in the incoming belt InBuffer.

Figure-8 shows how the outgoing conveyor belts are filled with time. As figure-8 shows, Robot_1 deposits parts after 5th and 10th seconds, and Robot_2 deposits a single part after 8th second.

Figure-9 shows the state-space information. This information clearly shows that at time equals to 5, Robot_1has just fired, depositing one token into OutBuffer_1. At this point Robot_2 is still firing, thus holding input token InBuffer as a virtual token.

0 2 4 6 8 10 12 140

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Time

Numberoftokens

OutBuffer1OutBuffer2

Fig.8: Number of tokens in the outgoing buffers

A. The GPenSIM code for the simulation GPenSIM implementation of the Petri net model shown

in figure-7 consists just two simple M-files, the main simulation file (MSF) and the Petri net definition file (PDF). Just to show how easy it is use GPenSIM, the complete code for simulation is given as figure-10 and figure-11.

VII. CONCLUSION Token atomicity is a very important issue in Time Petri

nets, as lack of atomicity causes some analysis problems like reachability analysis. This paper presents a new approach for achieving atomicity of tokens in Petri nets; the new approach uses ‘virtual tokens’. This new approach is realized in the newer version of GPenSIM (version 6).

There is one distinctive advantage of the new approach over the other existing approaches (such as unavailable tokens, delay before firing, and aging of tokens): the new approach is realistic, and it follows what happens to material flow in real-life situation.

There is considerable overhead in maintaining the atomicity property: moving input tokens from input places into virtual places as virtual tokens at the start of firing, and then, deleting virtual tokens at the end of firing; however, the division of transition into 3 components - the pre-processor, main processor and the post-processor - helps realizing the virtual token based atomicity.

The code for the sample application shows how easy it is to use GPenSIM to create Petri net models, and how compact they are.

Figure-9: State-space information showing the virtual tokens

Figure-10: The Main Simulation File

======= State Diagram ======= Time: 0 State:0 (Initial State): 3 InBuffer

At time: 0 Enabled transitions are: Robot_1 Robot_2 At time: 0 Firing transitions are: Robot_1 Robot_2

Time: 5 State: 1 Fired Transition: Robot_1 Current State: InBuffer + OutBuffer_1 virtual tokens: InBuffer

At time: 5 Enabled transitions are: At time: 5 Firing transitions are: Robot_1 Robot_2

Time: 8 State: 2 Fired Transition: Robot_2 Current State: OutBuffer_1 + OutBuffer_2 virtual tokens: InBuffer At time: 8 Enabled transitions are: At time: 8 Firing transitions are: Robot_1

Time: 10 State: 3 Fired Transition: Robot_1 Current State: 2 OutBuffer_1 + OutBuffer_2 virtual tokens: (no tokens)

clear all; clc;

% set global parameters global global_info; global_info.STOP_AT = 15;

% declare static details (Petri net % deinition File (PDF))png = petrinetgraph('atomicity_def');

% dynamic details: initially tokensdyn.iniitial_markings = {'InBuffer', 3}; % dynamic details: firing times dyn.firing_times = {'Robot_1', 5, ...

'Robot_2',8};

% start the simulation runssim = gpensim(png, dyn);

%print the resultsprint_statespace(sim); plotp(sim,{'OutBuffer_1','OutBuffer_2'});

166166177

Figure-11: Petri net Definition File

REFERENCES

[1] G. Cassandras and S. LaFortune. Introduction to Discrete Event Systems. Hague, Kluwer Academic Publications, 1999

[2] T. Murata. “Petri Nets: Properties, Analysis, and Applications”. Proceedings of the IEEE, 77 (4), pp. 541-580, 1989

[3] M. Silva, E. Teruel, and J. M. Colom. “Linear Algebraic Techniques for the Analysis of P/T Net Systems”. In Lectures in Petri Nets I: Basic Models. Springer, 1998

[4] B. Berthomieu, and M. Diaz. “Modeling and verification of time dependent systems using Time Petri Nets”. IEEE Transactions on Software Engineering, 17(3), pp. 259-273, March 1991

[5] B. Berthomieu, and M. Menasche. “A State enumeration approach for analyzing time Petri nets”. 3rd European Workshop on Petri Nets, Varenna, Italy, 1982

[6] S. Haddad. “Time and Timed Petri Nets”. DISC School on Control of Discrete-Event Systems: Automata and Petri nets perspectives, June 6-10, 2011, Cagliari, Italy

[7] I. Abdulla, and A. Nylen. “Timed Petri Nets and BQOs”. 22nd International Conference on Application and Theory of Petri Nets (ICATPN'01), volume 2075, Lecture Notes in Computer Science, pages 53-70. Springer, 2001

[8] V. Valero, D. Frutos-Escrig, and F. Cuartero. On non-decidability of reachability for timed-arc Petri nets. In Proc. 8th Int. Work. Petri Nets and Performance Models (PNPM'99), pages 188-196. IEEE Computer Society Press, 1999

[9] GPenSIM. Available: http://www.davidrajuh.net/gpensim/ [10] MATLAB. Available: http://www.mathworks.com [11] R. Davidrajuh and I. Molnar. “A Tool for Teaching Mathematical

Modeling to Information Systems Students”. Issues in Information Systems (ISSN 1529-7314), 7(1), pp. 155-160, 2006

[12] R. Davidrajuh and I. Molnar. “Designing a new tool for Modeling and Simulation of discrete-event based systems”. Issues in Information Systems (ISSN 1529-7314), 10(2), pp. 472-477, 2009

[13] R. Davidrajuh. Automating Supplier Selection Procedures. PhD Dissertation, Norwegian University of Science & Technology (NTNU), 2000. ISSN: 0809-103X; ISBN: 82-7984-159-8

[14] R. Davidrajuh. “Distributed Workflow based Approach for Eliminating Redundancy in Virtual Enterprising”. Journal of Supercomputing, Online First, 2011-01-05, DOI: 10.1007/s11227-010-0544-6, Publisher: Springer Verlag

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

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

[17] R. Davidrajuh. “Scheduling using 'Activity-based Modeling'”. 2011 IEEE Conference on Computer Applications & Industrial Electronics (ICCAIE 2011), Penang, Malaysia, December 4-7, 2011

% File:Petrinet definition File (PDF)

function [png] = tdf_example_def()

% assign name to Petri net modelpng.PN_name = 'Atomicity Example';

% declare the set of placespng.set_of_Ps = {'InBuffer',... 'OutBuffer_1', 'OutBuffer_2'};

% declare the set of transitionspng.set_of_Ts = {'Robot_1','Robot_2'};

% declare the set of arcspng.set_of_As = {... 'InBuffer','Robot_1',1,... 'InBuffer','Robot_2',1, ... 'Robot_1','OutBuffer_1',1,... 'Robot_2','OutBuffer_2',1};

167167178