Simulation Modelling Practice and Theory 19 (2011) 785–800

Contents lists available at ScienceDirect

Simulation Modelling Practice and Theory

journal homepage: www.elsevier .com/ locate/s impat

The extended activity cycle diagram and its generality

Donghun Kang, Byoung K. Choi ⇑VMS Lab., Department of Industrial and Systems Engineering, KAIST, 335 Gwahak-ro, Yuseong-gu, Daejeon 305-701, Republic of Korea

a r t i c l e i n f o

Article history:Received 10 May 2010Received in revised form 8 November 2010Accepted 9 November 2010Available online 18 November 2010

Keywords:Activity cycle diagram (ACD)Modeling powerExtended ACDThree-phase rule

1569-190X/$ - see front matter � 2010 Elsevier B.Vdoi:10.1016/j.simpat.2010.11.004

⇑ Corresponding author. Tel.: +82 42 350 3115; faE-mail addresses: donghun.kang@vmslab.kaist.ac

a b s t r a c t

The simplicity of the two-symbol activity cycle diagram (ACD) has made it easy to learnand use to describe discrete event systems in a natural way. But as the complexity ofthe model increases, the ability of the ACD to provide a full description of the system underconsideration becomes more limited. This paper presents an extended ACD with arc attri-butes and its formal definition to increase the modeling power of the ACD. The validity ofthe proposed extensions is shown by proving the generality of the extended ACD, whichhas not yet been done on the ACD. In addition, this paper proposes a model specificationfor the simulation execution of the extended ACD models which we call the activity tran-sition table (ATT). At last, the simulation software tool is presented to support modelimplementation, model execution, and experimentation for the extended ACD models.

� 2010 Elsevier B.V. All rights reserved.

1. Introduction

The activity cycle diagram (ACD) is a method to describe interactions among objects in a system. It provides the graphicalmodeling notations to explain a series of activities in diverse real-life circumstances. The core idea of the ACD was intro-duced by Tocher to solve the congestion problem at steel plants in a general framework; this took the form of the flowdiagram [1] with the three-phase rule [2].

Objects in a system can be classified into two classes: (1) transient object or entity that receives the services and leavesthe system; and (2) resident object or resource that serves the entities. In the ACD, the behavior or life cycle of an entity orresource in the system is represented by an activity cycle, which alternates between active and passive states. The passivestate of an entity or resource is called a queue in a circle, and the active state is called an activity in a rectangle as shown inFig. 1. The arc is used to connect the activity and the queue or the queue and the activity.

The activity represents the interaction between an entity and resource(s), which usually requires a time delay for comple-tion. The token is used to represent the state of a queue or an activity. A queue cannot contain different types of tokens. Allactivity cycles are closed on themselves [3].

Fig. 2 shows an ACD model for a single-server system. This model consists of three activity cycles: one for an entity of‘‘jobs’’ and the rest for the resources of ‘‘generator’’ and ‘‘machine’’. A job is generated at the interval of ta time unit by a gen-erator and stored in a queue ‘‘B’’ waiting for its processing on a machine. A ready-to-process machine serves a job for ts timeunit if a queue ‘‘B’’ has at least one job. The resource can usually perform one or more different activities in any sequence. Allthe activity cycles in Fig. 2 are closed.

The three-phase rule [2] provides a fundamental method to handle the flow of time in a discrete event simulation:

Phase A: Advance the clock to the time of the next (bound-to-occur) event.

. All rights reserved.

x: +82 42 350 3110..kr (D. Kang), bkchoi@kaist.ac.kr (B.K. Choi).

Fig. 1. Basic graphical modeling notations of the ACD.

Fig. 2. ACD model of a single-server system.

786 D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800

Phase B: Terminate any activity bound to end at this time.Phase C: Initiate any activity of which the condition in the model now permits.

The ACD represents the state flows of entities and resources in a system, while the three-phase rule is based on the eventthat denotes a state change of a system when it occurs. In phase B, the activities, which are bound to occur, end with therelease of resources and entities (into output queues), which is called a bound or bound-to-occur (BTO) event. In phase C,any conditional event that satisfies the beginning condition represented by the availability of entities and resources is initi-ated by acquiring them.

Assume that the single-server system in Fig. 2 starts with a bound-to-occur (BTO) event (‘‘Generated’’) for a ‘‘Generate’’activity at time zero. At phase A, the simulation clock is advanced to zero because ‘‘Generated’’ is the only available BTOevent and the time-to-occur of this event is zero. At phase B, a ‘‘Generated’’ BTO event is executed to terminate the‘‘Generate’’ activity by adding a job token to a queue ‘‘B’’ and returning a resource token to a queue ‘‘G’’. At phase C, anyactivity of which all input queues have one or more tokens is initiated. Currently, every queue in the model has exactlyone token. Therefore, the conditional events for the ‘‘Generate’’ and ‘‘Process’’ activities are now initiated by updating thetoken values of the input queues. Then, the BTO events for the ‘‘Generate’’ and the ‘‘Process’’ activities are scheduled to occurat 0 + ta and 0 + ts time. This process continues until it satisfies the end-of-simulation (EOS) condition.

Formally, the ACD model M can be defined as follows:

M = (A,Q, I,O,s,l,l0), where

A = {a1, a2. . . an} is the finite set of activities,Q = {q1, q2. . . qm} is the finite set of queues,I = {ia # Q j a 2 A} is the input function, a mapping from activities to sets of queues,O = {ia # Q j a 2 A} is the output function, a mapping from activities to sets of queues,s ¼ fsa 2 Rþ0 j a 2 A} is the time delay function,l ¼ flq 2 Nþ0 jq 2 Qg is the finite set of the number of tokens for each queue,l0 = {l1, l2. . . lm} is the finite set of initial token values for each queue.

In the ACD, the activity represents the active state of entities and resources or the interaction between them, which re-sults in a change of states in the system whenever it begins and ends. Therefore, the relationship between queues and activ-ities is defined as a function of activities. The input function I represents the queues directly connected to an activity andoutput function O defines the queues directly connected from an activity. The time delay function s defines the time thata resource(s) takes to serve an activity to the entity (ies). On the contrary, the time of the entities or resources in a queueis undefined, because it cannot be decided until at least one succeeding activity of a queue has satisfied its beginningcondition.

An ACD model for a single-server system shown in Fig. 2 can also be represented formally as shown in Table 1. For exam-ple, the ‘‘Process’’ activity, a2 2 A, has the input queues of ‘‘B’’ (q5 2 Q) and ‘‘M’’ (q6 2 Q) queues. This is defined by the elementi2:{q5, q6} of the input function I.

This paper presents an extended ACD model with arc attributes to increase the modeling power of the ACD models. Thegenerality of the extended ACD model is also demonstrated with two approaches: (1) conversion of the extended ACD model

Table 1Formal model of an ACD model shown in Fig. 2.

M1 = (A,Q, I,O,s, l,l0), whereA = {1: GENERATE, 2: PROCESS}Q = {3: Jobs, 4: G, 5: B, 6: M}I = {i1,i2} where

i1: {q4}i2: {q5, q6}

O = {o1, o2} whereo1: {q4, q5}o2: {q6}

s = {s1, s2} wheres1: ta

s2: ts

l = {l4, l5, l6}l0 = {l4:1, l5: 0, l6:1}

D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800 787

into Turing-equivalent modeling formalism; and (2) modeling the extended ACD model of a Turing machine. Hereafter, theACD model without the extension will be referred to as the classical ACD. In addition, this paper proposes a model specifi-cation for the simulation execution of the extended ACD models, which we call the activity transition table (ATT). The pro-posed model specification focuses on the dynamics of a system from the point of view of the activity transition, whichconforms well to the three-phase rule. The simulation software tool that supports the modeling of extended ACD and ATTmodels and the execution of their simulation with output data collection is also presented.

The paper is organized as follows. In order to make the paper self-contained, a review of related works is presented in thenext section. The third section presents the extended ACD and its generality is proven in the fourth section. The fifth sectionpresents a simulation software tool to create extended ACD models with ATT models and to execute the ATT models. Thefinal section presents our conclusion and discusses our findings.

2. Related works

The concept of the ACD and the principle of executing its simulation were conceived by Tocher [1,2,10]. He developed thefirst general-purpose simulator, named the general simulation program (GPS), to build a steel plant simulation.

Since then, many simulation software tools have used the ACD. Simulation software tools for the ACD can be categorizedinto three types according to the model implementation method used. The simulation language-based simulation softwaretools are CSL [11], ECSL [12], CYCLONE [4] and STROBOSCOPE [8]. The automatic code generation-based simulation softwaretools are CAPS [12], DRAFT [13] and AUTOSIM [14]. The visual interactive modeling software tools using graphical modelingnotation are EZSTROBE [9] and GroupSim [15].

The weak point of the simulation language and automatic code generation approaches is that they are not easy to learnand to understand, which makes the modeling of complex systems complicated. This is addressed by the visual interactivemodeling approach, which provides graphical modeling notation so that a modeler who is not familiar with simulation lan-guage or programming can focus on its own role [16]. To fully define the details of the target system in a general behavioralway, with no ambiguities, it is necessary to complete the model with more information [6]. The visual interactive modelingsystem is restricted to the modeling power of its underlying formalism. The visual interactive modeling systems also need toprovide the automatic code generation to complete the model with more details using the programming language.

The strength of the ACD lies in its simplicity. Because it uses only two symbols, even those who are not experts in sim-ulation can create and understand an ACD model with ease. At the same time, however, this has limited the modeling powerof the ACD.

A study on ACD modeling of a flexible manufacturing system (FMS) [5] refers that the ACD becomes more limited in pro-viding a full description of the system under consideration as the complexity of a model increases. The authors pointed outthat this reflects the inability of ACD to handle model details in a structured way. A study on modeling agile manufacturingcells [17] found that the ACD cannot represent the relationships of conditions and events in discrete event dynamic systems.In the ACD, the condition is usually referred to that all input queues should have at least one token to initiate the conditionevent. However, it is restricted only to the input queues of an activity. Other queues except them cannot be involved with iteven if they are related.

A comparative study of Petri-net and ACD on modeling the FMS having automatic guided vehicles for material handling[7] found that the modeling power of Petri-net with some augmentation (e.g. timing bound on transitions, colored tokensand inhibitor arcs) has made it one of the best tools for graphical representation and analysis of the FMS problem.

A study of automatic code generation of the ACD model [6] found that the ACD lacks the ability to capture the behavior ofthe system completely and without ambiguity, hindering the automatic generation of simulation programs. The authors pro-pose some extensions including the queuing policy and special conditions in arcs connecting active and passive states toovercome the limitation. Other extensions on the graphical modeling notation were also proposed [4,8,9]: CYCLONE [4]

788 D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800

and STROBOSCOPE [8] introduced specialized graphical elements to model the active and idle states associated withconstruction resources such as COMBI activity, Normal activity, and Function node, EZSTROBE [9] also introduced somegraphical elements such as Fork, Draw Link, Release Link and Branch Link.

However, these extensions aim to reduce modeling complexity with the ease of modeling. It does not help increase themodeling power of the ACD models.

Popular modeling formalisms such as Petri-net and event-graph are recognized that they have the generality or bettermodeling power compared with any other modeling formalism. The Petri-net model has a concrete theoretical backgroundon its modeling power. While the classical Petri-net is not Turing-equivalent, the extended Petri-net with zero testing hasthe same modeling power as the Turing machine, as it can model any system that can be computable [18]. The event graphis known as a Turing-equivalent modeling formalism [19]. The generality of the event graph models is proven by modelingan event graph model of a Turing machine, which shows that the event graph has the same modeling power as a Turingmachine. The generality of the ACD models has not yet been proven.

3. Extended ACD

In the classical ACD, the activity is allowed to start only if every input queue has at least one token. This condition isrestricted to the relationship between an activity and its input queues. That limits the modeling power of the conditioninvolved with other queues, which are not directly connected by an activity. Also, it can’t express the condition of that anactivity can start even if input queue has no token.

Two arc attributes are adopted to empower the modeling power of the classical ACD. One is an arc condition to representthe restriction on the start and end of an activity. The other is an arc multiplicity to represent the amount of tokens passingthrough the arc when it is enabled. The classical ACD with two arc attributes is named the extended ACD. Fig. 3 shows thegraphical modeling notations for these arc attributes. The arc condition is represented with a tilde on the arc. The arc mul-tiplicity is located above the arc head.

The arc condition can be used to represent constraints on the start and end of an activity except the token availability ofits input queues. Fig. 4 shows an extended ACD model of a part of a job shop system. Two operators operate three machineswith two processing steps. An entering job arrives and waits for processing at a buffer ‘‘Q1’’. The job is processed by amachine ‘‘M1’’. The first processing step is operated by operator ‘‘A’’ (‘‘Process1A’’ activity) or operator ‘‘B’’ (‘‘Process1B’’activity). The processed job is moved to a buffer ‘‘Q2’’ for the next processing. The second processing step is performedby either machine ‘‘M2’’ or machine ‘‘M3’’. A machine ‘‘M2’’ is operated by an operator ‘‘WA’’ and a machine ‘‘M3’’ by anoperator ‘‘WB’’. The machine ‘‘M3’’ processes a job at a buffer ‘‘Q2’’ only if the machine ‘‘M2’’ is busy, which means thatthe machine ‘‘M2’’ has a higher priority than the machine ‘‘M3’’ does. This constraint is represented by an arc condition(M2 � 0) between the queue ‘‘Q2’’ and the activity ‘‘Process3’’. Other arc conditions are defined as 1 � 1, which represents

Fig. 3. Extensions on arc attributes: multiplicity (left) and condition (right).

Fig. 4. Example of extended ACD.

D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800 789

that no further constraint is imposed on the arc. The arc condition also can be used to represent the probabilistic branchingon output arcs of an activity.

With the arc multiplicity, the ACD can represent the batched processing. As shown in Fig. 4, if a queue ‘‘Q3’’ has more thanten tokens and the transportation facility (queue ‘‘T’’) is available, the ‘‘Depart’’ activity is initiated to transfer jobs to othersections of the shop floor.

The simulation execution of an extended ACD model still follows a three-phase structure. However, the conditionalevents and the BTO events should be extended to embrace two arc attributes. At phase B, the BTO event starts with checkingthe all arc condition of its output arcs before it updates the output queues. If the arc condition of an arc connected to an out-put queue is evaluated as true, the token value of each output queue is increased by the arc multiplicity. If not, it is not up-dated. At phase C, the conditional event starts with checking the condition of an activity, which indicates that all inputqueues have at least the tokens of the arc multiplicity and that all arc conditions of the input arcs should be satisfied. Forexample, the condition of ‘‘Process3’’ activity of Fig. 4 is specified as ‘‘WB P 1 & M3 P 1 & Q2 P 1 & M2 � 0’’. All input arcsof ‘‘Process3’’ activity have an arc multiplicity of one. The arc from ‘‘Q2’’ queue to ‘‘Process3’’ activity has an arc condition of‘‘M2 � 0’’ and other arcs have the arc condition of ‘‘1 � 1’’ or always true. If the condition is evaluated as true, the token valueof each input queue is decreased by the multiplicity of the connected arc.

Formally, an extended ACD model EM can be defined as:

EM = (A,Q, I,O,s,P,V,l,l0), where

A = {a1,a2. . .an} is the finite set of activities,Q = {q1,q2. . .qm} is the finite set of queues,I = {ia # Q j a 2 A} is the input function, a mapping from activities to sets of queues,O = {oa # Q j a 2 A} is the output function, a mapping from activities to sets of queues,s ¼ fsa 2 Rþ0 ja 2 Ag is the time delay function,P is the multiplicity function on the mappings between activities and queues,P ¼ fpx; y 2 Nþ1 jpx; y ¼ ðax; qyÞorðqx; ayÞ; qx 2 IðayÞ; qy 2 OðaxÞg,V is the condition function on the mappings between activities and queues,V = {vx,y: l ? {0,1} j vx,y = (ax,qy) or (qx, ay), qx 2 I(ay), qy 2 O(ax)},l ¼ flq 2 Nþ0 jq 2 Qg is the finite set of the number of tokens for each queue,l0 = {l1, l2, . . ., lm} is the finite set of initial token values for queues.

The arc attributes of the extended ACD are realized into the condition function and the multiplicity function. The cardi-nality of the multiplicity function or the condition function is same as the sum of those of the input function and the outputfunction (jPj = jIj + jOj). No arc can have zero multiplicity. Without further specification, it has one multiplicity. The conditionfunction specifies the constraint on each arc. Each arc condition should be evaluated as true (1) or false (0). Without furtherspecification, it always has the true value (1 � 1). An extended ACD model shown in Fig. 4 also can be represented formally asshown in Table 2.

Table 2Formal model of an extended ACD model shown in Fig. 4.

EM = (A,Q, I,O,s,P,V,l,l0)whereA = {1: ARRIVE, 2: PROCESS1A, 3: PROCESS1B, 4: PROCESS2, 5: PROCESS3, 6: DEPART}Q = {7: G, 8: Q1, 9: M1, 10: WA, 11: Q2, 12: WB, 13: M2, 14: M3, 15: Q3, 16: T}I = {i1, i2, i3, i4, i5, i6}, where

i1: {q7}i2: {q8, q9, q10}i3: {q8, q9, q12}i4: {q10, q11, q13}i5: {q11, q12, q14}i6: {q15, q16}

O = {o1, o2, o3, o4, o5, o6}, whereo1: {q7, q8}o2: {q9, q10, q11}o3: {q9, q11, q12}o4: {q10, q13, q15}o5: {q12, q14, q15}o6: {q16}

s = {s1, s2, s3, s4, s5, s6}, wheres1: ta, s2: ts1a, s3: ts1b, s4: ts2, s5: ts3, s6: td

p15,6: 10, others: 1, where p15,16 2 Pv11,5: l13 � 0, others: 1 � 1, where v11,5 2 Vl = {l7, l8, l9, l10, l11, l12, l13, l14, l15, l16}l0 = {l7:1, l8: 0, l9:1, l10:1, l11:0, l12:1, l13:1, l14:1, l15:0, l16:1}

Table 3Mapping relations between an extended ACD model and a timed Petri-net model.

Extended ACD model (EM) Timed Petri-net model (TPN)

Activity (A) Transition (T)Queue (Q) Place (P)Input function (I) Input function (I)Output function (O) Output function (O)Time delay function (s) Timing function (s)Multiplicity function (P) Weight (I/ O)Condition function (V) Inhibitor arc (I)Initial marking (l0) Initial marking (l0)

790 D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800

4. Proving the generality of extended ACD models

The generality or modeling power of a modeling tool typically refers to the ability to describe correctly the system understudy to provide a valid representation with respect to the objectives of the study [20]. From this perspective, the modelingpower of the classical ACD cannot express the relationship between conditions and events. To overcome this limit, theextended ACD is proposed with newly adopted arc attributes. However, its generality has not yet been proven.

Under Church’s thesis [21], a Turing machine can model any system that can be simulated with a computer without fur-ther extension. A modeling tool or modeling formalism is referred as Turing (machine)-equivalent if it can simulate or besimulated by a Turing machine. A Turing-equivalent modeling tool has the same modeling power as a Turing machine. Asimple approach to show that a modeling tool is Turing-equivalent is to compare a modeling tool with a well-known Tur-ing-equivalent modeling tool. A general approach is to create a model using a modeling tool that imitates the behavior of aTuring machine. In most cases, a modeling tool is implemented on a computer. This implies that a Turing machine can sim-ulate a modeling tool so that it does not need to be proven.

In the following sub-sections, we present a conversion of an extended ACD model into a timed Petri-net and an extendedACD model of a Turing machine to demonstrate that the extended ACD is Turing-equivalent.

4.1. Conversion into a Turing-equivalent modeling formalism

The Petri-net is a modeling formalism based on bag theory, an extension of set theory, and is designed to model systemswith interesting concurrent components [22]. The (marked) Petri-net structure S = (P,T, I,O,l0) is a set representation of aPetri-net model. P is a finite set of places P = {p1, p2. . . pn}. T is a finite set of transitions T = {t1, t2. . .tm}. I is an input functionfrom transitions to bags of places I: T ? P1. O is an output function from transitions to bags of places O: T ? P1. A marking l:P ? N represents the execution of a Petri-net with an assignment of tokens to the places of a Petri-net. Here, l0 represents aninitial marking of a Petri-net model.

The Petri-net with zero testing, an ability to test for a zero marking in a place, can simulate a Turing machine [18]. As oneof the extensions for zero testing, an inhibitor arc, which connects place pi to transition tj, enables transition tj to fire only ifplace pi has no token. A class of Petri-nets with inhibitor arcs is referred to as extended Petri-nets [22]. The timed Petri-net[23] is another class of extended Petri-nets with time on transition. A timed Petri-net TPN = (P,T, I,O,s,l0) is a set represen-tation of Petri-net structure S and s: T ? R+ is a timing function that associates transitions with deterministic time delays.

The extended ACD model M = (A,Q, I,O,s,P, V, l,l0) can be mapped into the timed Petri-net model TPN = (T,P, I,O,s,l0) asshown in Table 3. The activity (A) and queue (Q) are mapped into the transition (T) and place (P) of the Petri-net model. Theinput and output function (I,O) with time delay function (s) is also mapped into the same components of the timed Petri-netmodel.

The arc attributes of the extended ACD model also can be mapped into the components of a timed Petri-net. The arc mul-tiplicity function P of the extended ACD is mapped into the weight function of the timed Petri-net. In the timed Petri-net, aweight k between a place (transition) and a transition (place) is represented by input function (output function). If I(ti,pj) = kor O(ti,pj) = k, there exist k directed arcs connecting transition ti to transition pj in the Petri-net graph. Usually, in the graph-ical representation, these directed arcs are represented by a single directed arc labeled with its weight [22]. The conditionfunction of the extended ACD (restricted to a range of zero testing) can be mapped into the inhibitor arcs. The inhibitor arcsare a sub-set of the input function I: T ? P1. Fig. 5 shows the converted timed Petri-net model of the extended ACD modelshown in Fig. 4 using the above mapping relations. The reverse conversion process also can be performed using the samemapping relations.

4.2. ACD modeling of a Turing machine

A Turing machine was proposed by Alan Turing [24] to investigate the computational power and limits of a computer. Asa theoretical device, it can simulate any computable system [21]. It consists of an input tape, a finite control and a tapeheader. The input tape is divided into cells that contain a symbol from a finite set of tape symbols. It is assumed that it is

D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800 791

arbitrarily extendable to the left and to the right. Each cell of the input tape has a blank symbol if it has not been writtenbefore. The tape header reads and writes symbols on the input tape and moves the input tape left or right one cell at a time.The finite control has a state register that stores the state of the machine and an action table that tells the next instructiongiven a symbol read from the input tape and the state of the machine (see Fig. 6).

Initially, the tape head is moved to the leftmost cell of the input tape and the initial state of the machine is stored in thestate register of the finite control. The machine starts with reading a symbol from the cell where the tape head is located. Thefinite control looks up the next action on the action table, given the state the machine is currently in and the symbol justread. Based on the next action, the next state is set to the state register. Then, the tape head writes a new symbol on a celland moves the input tape to the left or to the right. Until the machine reaches one of the final states, the above procedure isrepeated. At the final state, it is assumed that the input is accepted by the machine. If no action is defined in the action tablefor the combination of an input symbol and a state, then the machine stops.

Formally, a Turing machine T can be defined as follows [25]:

Fig. 7. Extended ACD Model of a Turing machine.

Fig. 6. Reference model for a Turing machine.

Fig. 5. Converted Petri-net model.

792 D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800

T = (Q,R,C,d,q0,b,QF), whereQ is the finite set of states (of the finite control),C is the finite set of allowable tape symbols,b 2C is the blank symbol,R # Cnb is the set of input symbols,d: Q � C ? Q � C � {L, R} is the next move function,q0 2 Q is the start state,QF # Q is the set of final states.

Fig. 7 shows an extended ACD model of a Turing machine. It consists of three activity cycles: two for the resources of thetape head and the finite control, the other for the entity of the input tape.

The tape head has an activity cycle of the ‘‘Read’’, ‘‘Look-up’’, ‘‘Write’’, and ‘‘Move’’ activities with ‘‘Head’’, ‘‘Q1’’, ‘‘Q2’’, and‘‘Q3’’ queues. The ‘‘Read’’ activity reads a tape symbol h from a cell where the tape head is located. The tape symbol h will bepassed to the ‘‘Finite Control’’ for next-move decision-making. The ‘‘Write’’ activity represents writing a new tape symbolinto a cell. In the ‘‘Move’’ activity, the tape head moves to the left or the right. The ‘‘Head’’ queue represents the resourceavailability of a tape head.

The ‘‘Finite Control’’ involves the look-up of the action table for the next action, for which the activity cycle has a ‘‘Look-up’’ activity, a ‘‘Finite Control’’, and a ‘‘Halt’’ queue. The ‘‘Finite Control’’ queue represents the resource availability of thefinite control. If no next action for the tape symbol h and the current state of the machine q is defined in the action table,both the finite control and tape head will stop.

The input tape that has infinite cells starts with the ‘‘Read’’ activity. A tape symbol is read from a cell of the input tape andthen the finite control looks up the next action with the tape symbol and the state of the machine. If no action is defined inthe action table, there will be no action taken. If not, it will continue to write a new symbol into the current cell and to moveto the left or right. If the state reaches one of the final states, the machine will accept the input. In this case, the tape headcontinues to read a tape symbol and the finite control looks up the action table. However, the tape head and the finite controlwill stop, because the action table does not define any entry for final states.

All of the activity cycles of a Turing-machine ACD model are not closed on it. While a Turing machine is actively workingon a series of inputs, the activity cycles are closed. However, when it comes to a state of accepting the input or halting, it willnever get back to the actively working state unless it is restarted.

The model validation of a Turing-machine ACD model can be done with checking the termination of the simulation exe-cution. If the Turing machine stops, the simulation execution will also terminate, because both the ‘‘Look-up’’ and the‘‘Write’’ activity cannot be initiate. If the Turing machine does not stop, the simulation execution will also not be terminated,because every activity can be initiated through the activity cycles unless it reaches one of the termination conditions.

Table 4 shows the formal description of a Turing-machine ACD model with the arc conditions not shown in Fig. 7. Let D bea set of input pairs of a tape symbol and a state defined in the action table, q a current state of the machine (stored in thestate register of the finite control), and t a tape symbol from a cell where the tape head is located. The arc condition C11 of

Table 4Formal model of a Turing-machine ACD model.

M = (A,Q, I,O,s,P,V,l,l0), whereA = {1: Read, 2: Look-up, 3: Write, 4: Move}Q = {5: Head, 6: Q1, 7: Halt, 8: FiniteControl, 9: Q2, 10: Q3, 11: Accept}I = {i1, i2, i3, i4}, where

i1: {q5}i2: {q6, q8}i3: {q9}i4: {q10}

O = {o1, o2, o3, o4}, whereo1: {q6}o2: {q7, q8, q9}o3: {q10}o4: {q5, q11}

s = {s1, s2, s3, s4}, wheres1, s2, s3, s4: 0P = {p5,1, p6,2, p8,2, p9,3, p10,4, p1,6, p2,7, p2,8, p2,9, p3,10, p4,5, p4,11}, where

all: 1V = {v5,1, v6,2, v8,2, v9,3, v10,4, v1,6, v2,7, v2,8, v2,9, v3,10, v4,5, v4,11}, where

v2,8, v2,9: (q, h) 2 Dv2,7: (q, h) 2 Dv4,11: q 2 QF

others: 1 � 1l = {l5, l6, l7, l8, l9, l10, l11}l0 = {l5:1, l6:0, l7:0, l8:1, l9:0, l10:0, l11:0}

Elements Definition Elements Definition

At-begin condition µj

> 0, for all >qj

I(ai) At-begin condition v

j,i & µ

j p

j,i, for all q

jI(a

i))

At-begin state-update µj‘ = µ

j– 1, for all q

jI(a

i) At-begin state-update µ

j‘ = µ

j–

–

pj,i

, for all qj

I(ai)

BTO event time T(ai) BTO event time T(a

i)

At-end state-update µj‘ = µ

j + 1, for all q

jO(a

i) At-end state-update µ

j‘ = µ

j + p

i,j, if v

i,j is true, for all q

jO(a

i)

Influenced activities {ak | q

jO(a

i), q

jI(a

k)} Influenced activities {a

k | v

i,j is true, q

jO(a

i), q

jI(a

k)}

(a) Classical ACD model to ATT model (b) Extended ACD model to ATT model

Fig. 8. Translation of ACD model into ATT model.

D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800 793

(q,h) 2 D represents that the action table does not have any next state for the (q,h) pair is not defined. The arc condition C23

of q 2 Qf specifies whether the state of the machine reaches one of final states.In general, each activity of an ACD model has a time delay to represent the time for completion. A Turing machine, how-

ever, is not a practical computer. It can be assumed that each activity of a Turing-machine ACD model has a time delay ofzero (tr, tl, tm, tw: 0). In the case of a practical computer, the input tape can be replaced with an array or list that allows accessto its element directly without going through all of the elements. It is quite reasonable to ignore the time delay for activitiesof a Turing-machine ACD model. Then, the Turing-machine ACD model can be reduced to a single activity with four queues.

4.3. Implications

By equipping the classical ACD with the arc condition, we have demonstrated that a Turing machine can be modeled withan extended ACD model. The arc multiplicity is not used in a Turing-machine ACD model. This means that any extensionexcept the arc condition has no effect on increasing the modeling power of the ACD models. Therefore, several extensionsproposed by some researchers [4,6,8] are no longer necessary. Those extensions are used to increase the ease of modelingor to reduce its complexity.

5. Extended ACD tool

As noted in the related works section, the ACD does not have a structured model representation for model details. TheACD represents the life cycles of entities or resources in a system with the graphical modeling notation. However, thethree-phase rule describes the dynamics of a system in the aspect of the activity transition that represents the state transi-tions at the beginning and end of an activity (conditional event and BTO event). To narrow down the gap between the ACDand three-phase rule, we will propose a model specification for the simulation execution of the ACD models, named theactivity transition table (ATT). The proposed model specification has the one-to-one relationship with the atomistic structureof the three-phase rule. This makes the three-phase rule more efficient.

In the next sub-section, the ATT will be presented and the following sub-section will represent a simulation software toolthat supports the visual modeling and simulation execution of the extended ACD models and ATT models.

5.1. Activity transition table

The distinctive feature of the three-phase rule is its atomistic structure that consists of advancing the simulation clock tothe time of the next BTO event, executing BTO events to be terminated at the current simulation time, and initiating anyconditional event whose condition permits the scheduling of the BTO events. In executing the simulation, the BTO eventis handled by the event routine and the conditional event is executed by the activity routine.

The event routine defines the state transition of an ACD model when an activity ends. The resources acquired to serve theactivity are released and the served entity (ies) is moved to the next state. This denotes the at-end state-update, which addsone token to each output queue of an activity. The activity routine is separated into two steps. The first step checks the at-begin condition, which defines whether all input queues of the activity have at least one token or not. If it is true, the at-beginstate-update is fulfilled, which takes one token out of each input queue. Then a BTO event is scheduled to occur within a giventime delay. At phase C of the three-phase rule, the activity routines of all activities in an ACD model are executed. However,this is not necessary. At phase B, we know which queues are updated (output queues of an activity). Therefore, the activitiesinfluenced by these queues become candidates for scanning at phase C.

A model specification for the simulation execution of the ACD models, named the activity transition table (ATT) is a set ofactivity transitions. The activity transition represents two state transitions at the beginning and ending of an activity. It con-sists of an at-begin condition, an at-begin state-update, a BTO event, an at-end state-update, and influenced activities. TheBTO event also holds the time delay of the constant or probabilistic distribution.

Table 5ATT model for a job shop system with two operators and three machines.

No. Name At-begin BTO Event At-end

Condition State update Time Name State update Influenced activities

1 Arrive G > 0 G�� sa Arrived G++, Q1++ Arrive, Process1A, Process1B2 Process1A Q1 > 0 & M1 > 0 & WA > 0 Q1��, M1��,

WA��ss1a Processed1A M1++, WA++,

Q2++Process1A, Process1B, Process2,Process3

3 Process1B Q1 > 0 & M1 > 0 & WB > 0 Q1��, M1��,WB��

ss1b Processed1B M1++, WB++,Q2++

Process1A, Process1B, Process2,Process3

4 Process2 Q2 > 0 & M2 > 0 & WA > 0 Q2��, M2��,WA��

ss2 Processed2 M2++, WA++,Q3++

Process1A, Process2, Depart

5 Process3 Q2 > 0 & M3 > 0 & WB > 0 &M2 � 0

Q2��, M3��,WB��

ss3 Processed3 M3++, WB++,Q3++

Process1B, Process3, Depart

6 Depart Q3 P 10 & T > 0 Q3�� = 10,T�� sd Departed T++ Depart

Fig. 9. Simulation software tool for extended ACD.

794 D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800

The ATT model can be constructed from the scratch, but it also can be derived from the ACD model. As shown in Fig. 8-a,each component of the activity transition can be specified using the formal definition of the ACD model. The at-begin con-dition defines the condition of that every input queue qj of an activity ai should have at least one token, in short, lj > 0, for allqj 2 I(ai). The at-begin state-update is defined as l0j ¼ lj � 1, for all qj 2 I(ai), which decreases the token value of every inputqueue qj of an activity ai by one. The BTO event is scheduled to occur in a time delay of an activity ai, T(ai). The at-end state-update is derived by l0j ¼ lj þ 1, for all qj2 O(ai). The influenced activities are defined as a set of activities, {ak j qj 2 O(ai), qj2I(ak)}, whose input queue is one of the output queues of an activity ai.

The ATT model also covers the extended ACD model without further extensions on itself as shown in Fig. 8b. The arc attri-butes from the input queues are incorporated into the at-begin condition and the at-begin state-update. The arc multiplicityis reflected on both the at-begin condition and at-begin state-update. The arc condition is reflected on the at-begin conditionwith the AND closure. The arc condition into output queues is incorporated into the at-end state-update of the precedingactivity.

Table 5 shows the ATT model for the extended ACD model shown in Fig. 4. The arc condition (M2 � 0) on the arc fromqueue ‘‘Q2’’ to activity ‘‘Process3’’ can be found at the at-begin condition of activity transition ‘‘Process3’’. The arc multiplic-ity on the arc from queue ‘‘Q3’’ to activity ‘‘Depart’’ is incorporated into the at-begin condition (Q3 P 10) and state-update(Q3� = 10). The queue ‘‘Jobs’’ does not show up in the ATT model because it is a dummy node used to close the activity cycle.

The ATT is quite well suited to automatic code generation because it inherits the atomistic structure of the three-phaserule in a well-defined structure. In addition, the influenced activities of the activity transition make the simulation executionefficient so that the three-phase rule becomes more powerful.

5.2. Simulation software tool for the extended ACD

As mentioned in the related works section, three approaches of simulation software tools for the ACD are automatic codegeneration, simulation language, and visual modeling. The automatic code generation and simulation language approachesare not easy to learn and they lack the simple modeling of a complex system. The automatic code generation approach givesthe modeler an opportunity to model the details of the complex system. The visual interactive modeling approach providesthe graphical modeling notation so that the modeler who is not familiar with the programming can focus on its ownrole [16].

In this paper, the visual interactive modeling and the automatic code generation approaches are combined to increase theease of modeling and to support the tailored model implementation. As shown in Fig. 9, our simulation software tool

Fig. 10. Visual modeling toolkit.

D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800 795

supports the simulation model life cycle. In the model implementation phase, the user can use the extended ACD editor tocreate an extended ACD model. Then the visual ATT model is also created, which consists of the visual representation of theextended ACD model and its ATT model. It can be created or modified with the ATT editor directly. In addition, the activitycycles of entities and resources in a system can be defined to set up an experimental frame for the simulation experiment. Inthe model execution phase, the simulator executes the simulation run of the ATT model in the XML document. It alsoprovides a mechanism to collect the output data. If activity cycles are defined in the ATT model, the simulator uses thisas an experiment frame to collect the output data. In the experimentation phase, the output analyzer performs the outputanalysis based on the collected output data and generates output report. The output report is organized along with theactivity cycles of entities and resources.

The simulation software tool consists of two toolkits. The one is the visual modeling toolkit (in gray) that is in charge ofmodel implementation and experimentation. The other is the simulation toolkit (in white) that is in charge of modelexecution.

The visual modeling toolkit not only supports the visual interactive modeling of the extended ACD models, but also gen-erates the code automatically. The generated code can be embellished by the user. The simulation toolkit supports the sim-ulation execution of the generated code with the useful library of probabilistic distribution and output collection. Moredetails on the toolkits will be provided in the following sub-sections.

5.2.1. Visual modeling toolkitShown in Fig. 10a is the visual modeling toolkit with the extended ACD and ATT views of the extended ACD model shown

in Fig. 4. The extended ACD editor located in the middle shows the extended ACD model with the graphical modeling nota-tions of queues in a circle, activities in a rectangle and arcs with some attributes. Each activity node contains the name andthe time delay of an activity. Here, the time delay can be a constant or a probabilistic distribution. The activity node in grayrepresents the initial activity (‘‘Arrive’’ activity), which is ready to begin its execution at the start of the simulation run. Thequeue node shows the name and the initial state of a queue. If the initial state of a queue is more than zero, it is representedon the queue node with a single ‘‘dot (�)‘‘. The arc condition is located at the middle of the arc and the arc multiplicity at thearc head (in blue1).

The ATT editor located at the last tab of the bottom shows the activity transitions and the initial states of all queues. Theactivity transition is automatically derived from the extended ACD model of the extended ACD editor if any change occurs, oris directly inserted or edited by the user using the dialog box for an activity transition. The change occurring in the ATT editoris also automatically reflected into the extended ACD model of the extended ACD editor. Because the visual modeling toolkitis built on the model-view-control (MVC) architecture [26], this synchronization between the two editors is possible. Here,

1 For interpretation of color in Figs. 10–12, the reader is referred to the web version of this article.

Fig. 11. Simulation toolkit.

796 D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800

the extended ACD view shows the state flows or life cycles of the entities or the resource in a system, while the ATT viewclearly shows the state transitions of the model.

The basic concept of the ACD rests on combining the activity cycles of entities and resources in a system into one model.This is also applied to output analysis. The activity cycle for an entity or resource can be defined from the extended ACD edi-tor by selecting activities and queues that belong to it. The defined activity cycles (see Appendix A) will be used as an exper-imental frame to observe the simulation execution and to calculate the performance measures at the aspect of entities orresources.

The visual modeling toolkit provides the output report for the entities and the resources. After a simulation run, the col-lected output data according to the activity cycles are analyzed so that some performance measures on entities and resourcesare calculated. For entities, numbers-in, numbers-out, sojourn time, and waiting time are provided. For resources, the utili-zation at each state of the activity cycle is provided. Shown in Fig. 10b is the output report for the resources that have beendefined in the activity cycles. The resource ‘‘WB’’ (worker-B) has the activity cycle of the ‘‘WB’’ queue and ‘‘Process3’’ and‘‘Process1B’’ activities. The output report shows the utilization of each state of the activity cycle of a selected resource witha chart of the resource usage over time. In the next sub-section, how the activity cycles are utilized in the simulation exe-cution and output analysis will be discussed in detail.

At the experimentation phase, if an experiment requires other kinds of performance measures, then this can be providedby generating a simulation code. The automatic code generation function is embedded in the visual modeling toolkit. Cur-rently, it generates the simulation code of an extended ACD model in C# language, because our simulation toolkit has beenimplemented in C# language under the Microsoft.Net Framework (version 3.0). This also can be used to embellish the ex-tended ACD model with more complex behaviors. Details on automatic code generation will be discussed in the nextsub-section.

5.2.2. Simulation toolkitAs shown in Fig. 11, the simulation toolkit is a set of libraries of a model library, simulation library, and output data library

for the simulation execution of the visual ATT model and the output data collection.The model library constructs the ATT model in the ATTModel class with ATTActivityTransition and ATTQueue classes from

the visual ATT model stored in a XML document as shown in Fig. 12. The ATTModel class manages the activity transitions andqueues. The activity transitions of the ATT model are represented by the ATTActivityTransition class, which defines five meth-ods for each component of the activity transition. In the simulation execution, the activity routine calls CheckBeginCondition,UpdateStatesAtBegin and ScheduleBTOEvent methods and the event routine calls UpdateStatesAtEnd and StoreInfluencedActiv-ities methods. The ATTQueue class denotes the queue with the token value.

The model library also supports the modeling of the behavior of the complex system that cannot be expressed in thegraphical modeling notation of the extended ACD model. The visual modeling toolkit provides the automatic code generationof the visual ATT model in C# programming language. The generated code consists of ATTActivityTransition classes, ATTQueueclasses and a single ATTModel class. The user may embellish the generated code with behavior that is more detailed or withcustomized output data collection (see Appendix B).

As shown in Fig. 13, the simulation library consists of the simulator and its supporting data structures of the future eventlist (FEL) and the candidate activity list (CAL). The FEL holds BTO events with the scheduled time to occur. The CAL stores theinfluenced activities. The three-phase rule is realized as the activity-scanning algorithm with three phases.

The first phase, activity-scanning phase, the simulator retrieves an activity transition by invoking the get-activity methodof CAL and calls the activity routine of the retrieved activity transition. The activity routine evaluates the at-begin conditionof current activity (CheckBeginCondition method). If it is true, then the at-begin state-update (UpdateStatesAtBegin method) ismade to update the token values of its input queues and its BTO event is scheduled by invoking schedule-next-event methodof FEL (ScheduleNextEvent method of Simulator class). This is repeated until CAL becomes empty.

The second phase, timing phase, the simulator retrieves the next BTO event by invoking get-next-event method of FEL(GetNextEvent method of Simulator class) and advances the simulation clock to the scheduled time of the next BTO event.At last, in the executing phase, the simulator calls the event routine of the next BTO event. The event routine executesthe at-end state-update (UpdateStatesAtEnd method) to update the token values of output queues and stores the influencedactivities into CAL (StoreInflunencedActivities method) by invoking the store-activity method of CAL. In the classical

Fig. 12. Class diagram for the simulation toolkit.

Fig. 13. Simulation library with output data library.

D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800 797

three-phase rule, all activities in an ACD model are scanned to seek next activity to start. However, in this activity-scanningalgorithm, the influenced activities from the at-end state-update of BTO event are put into CAL so as to reduce the scanningspace and time, which makes the three-phase rule more efficient.

The output data library mainly consists of a SimEvent class and a SimObserver class to support collection of the output datawhile executing the simulation. The simulator works as a change manager of the observer software design pattern [27].Whenever changes are made on the simulation objects, such as queues, CAL, and FEL, the simulation events (SimEvent class)are published to the simulator, then those simulation events are distributed to their subscribers, the simulation observers

798 D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800

(SimObserver class), so that performance measures can be calculated. In our implementation, the simulation events are firedwhen a BTO event is scheduled or fired or when the token value is changed. Currently, three types of simulation observer areavailable: (1) event counter (SimEventCounter class) that records the occurrence of a specific simulation event and (2) entity(SimEntityTally class) and (3) resource observers (SimResourceAccumulator class) that collect any simulation event related tothe activity cycle of an entity/resource. For example, the resource observer is used to calculate the utilization of a resource. Itcollects BTOEventScheduled (SimBTOEvent-ScheduledEvent class), BTOEventFired (SimBTOEventFiredEvent class), and Token-ValueChanged (SimTokenValueChangedEvent class) simulation events that are related to the activity cycle of a resource. Fromthese simulation events, it sums up the staying time for each state of the activity cycle of a resource and calculates the uti-lization of each state when the simulation run finishes. In the same way, the entity observer works. The SimObserver class canbe inherited to customize the output data collection and performance measure calculation.

The visual modeling toolkit and simulation toolkit work on Microsoft’s .NET Framework (version 3.0, C# programminglanguage). They are available at the authors’ web site (http://vms.kaist.ac.kr).

6. Conclusion

This paper proposed extended ACD with arc attributes to represent the relationship between conditions and events in adiscrete event system that are not covered by the classical ACD. The generality of the extended ACD models is proven withtwo approaches of (1) converting the extended ACD model into the timed Petri-net model with conversion rules and (2)modeling the extended ACD model of a Turing machine. That shows the extended ACD model is a Turing-equivalent andno other extension except the arc condition is necessary to increase the modeling power of the extended ACD.

With the extended ACD, the ATT is also proposed as a model specification for the simulation execution of the extendedACD model. Distinctive features of the proposed ATT include: (1) it reduces the gap between the ACD model and its simu-lation execution; (2) it makes execution of the simulation more efficient so that the three-phase rule becomes more pow-erful; and (3) it gives the structural representation of the ACD model in the aspect of the activity transition.

A simulation software tool is presented to support the model implementation, model execution, and experimentation ofthe extended ACD. The visual modeling toolkit helps the ease of extended ACD modeling with the graphical modeling nota-tion and storing the visual ATT model into the XML document. Then, the simulation toolkit uses the visual ATT model to exe-cute the simulation using the activity-scanning algorithm and it supports the output data collection with customizableobservers. The simulation software tool also provides the automatic code generation of the ATT model for modeling thebehavior of the complex system that cannot be expressed in the graphical modeling notation of the extended ACD model.

As a subject of academic research, the generality of the extended ACD is proven. For the practical use, however, the ex-tended ACD model should pursue the ease of modeling with the manageable modeling complexity. Further research will becarried on as to the parameterized ACD to reduce the modeling complexity and its applications to the complex systems, suchas the automatic material handling system in the factory and the general job shop system.

Appendix A. Activity cycles of the extended ACD model shown in Fig. 4

Name

Type States

JobType1

Entity Arrive, Q1, Process1A, Q2, Process2, Q3, Depart JobType2 Entity Arrive, Q1, Process1A, Q2, Process3, Q3, Depart JobType3 Entity Arrive, Q1, Process1B, Q2, Process2, Q3, Depart JobType4 Entity Arrive, Q1, Process1B, Q2, Process3, Q3, Depart M1 Resource M1, Process1A, Process1B M2 Resource M2, Process2 M3 Resource M3, Process3 WA Resource WA, Process1A, Process2 WB Resource WB, Process1B, Process3 Transporter Resource T, Depart

Appendix B. Automatic code generation for the visual ATT models

Table B1 shows the ArriveActivityTransition class for ‘‘Arrive’’ activity transition of the ATT model listed in Table 5. It inher-its the ATTActivityTransition class and overrides the four methods of CheckBeginCondition, UpdateStatesAtBegin, UpdateStatesA-tEnd, and StoreInfluencedActivities(). The constructor of ArriveActivityTransition class takes two parameters of the name andtime delay. The time delay is either constant or probabilistic distribution. The SimVariate class provides the various proba-bilistic distributions. The activity routine starts with CheckBeginCondition method that defines the beginning condition of‘‘G > 0’’. It will return a true or false based on the token value of queue ‘‘G’’ that can be fetched using GetTokenValue method.The UpdateStatesAtBegin method updates the token values of the queues. Here, queue ‘‘G’’ is updated using SetTokenValue

Table B1Simulation code for ‘‘Arrive’’ activity transition shown in Table 5.

1 public class ArriveActivityTransition: ATTActivityTransition {2 public ArriveActivityTransition ():

3 base ("Arrive", SimVariate.Parse ("Exponential (10)")) {4 //DO NOTHING

5 }67 public override bool CheckBeginCondition () {8 bool rslt = false;

9 //FETCH THE TOKEN VALUE OF THE QUEUE

10 int G = GetTokenValue ("G");

11 //CHECK THE CONDITION

12 return (G > 0);13 }1415 public override void UpdateStatesAtBegin () {16 //UPDATE STATE

17 int G = GetTokenValue ("G");

18 G��;19 SetTokenValue ("G", G);

20 }2122 public override void UpdateStatesAtEnd () {23 //UPDATE STATE

24 int Q1 = GetTokenValue ("Q1");

25 int G = GetTokenValue ("G");

26 Q1++; G++;27 SetTokenValue ("Q1", Q1);

28 SetTokenValue ("G", G);

29 }3031 public override void StoreInfluencedActivities () {32 //STORE INFLUENCED ACTIVITIES

33 StoreActivity ("Process1A");

34 StoreActivity ("Process1B");

35 StoreActivity ("Arrive");

36 }37 }

D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800 799

method. The event routine starts with calling UpdateStatesAtEnd method that updates the token values of the output queues‘‘Q1’’ and ‘‘G’’. Then, it calls StoreInfluencedActivities method to store the influenced activities of ‘‘Arrive’’ activity.

References

[1] K.D. Tocher, An integrated project for the design and appraisal of mechanical decision-making control systems, Operational Research Quartley 11(1962) 50–65.

[2] K.D. Tocher, The Art of Simulation, English Universities Press, 1963.[3] A. Carrie, Simulation of Manufacturing Systems, John Wiley & Sons, 1988.[4] D.W. Halpin, CYCLONE – method for modeling job site processes, in: Proceedings of the American Society of Civil Engineers, Journal of the Construction

Division 103 (CO3) (1977) 489–499.[5] V. Hlupic, R.J. Paul, Simulation modelling of flexible manufacturing systems using activity cycle diagrams, Journal of the Operational Research Society

45 (1994) 1011–1023.[6] W.D.L. Araújo Filho, C.M. Hirata, Translating activity cycle diagrams to java simulation programs, in: Proceedings of the 37th Annual Simulation

Symposium (ANSS’04), 2004, pp. 157–164.[7] M.K. Tiwari, M. Chandrasekaran, R.P. Mohanty, Use of timed petri net and activity cycle diagram methodologies for modelling tandem AGVs in FMSs

and their performance evaluation, International Journal of Computer Integrated Manufacturing 14 (4) (2001) 399–408.[8] J.C. Martinez, P.G. Ioannou, General purpose simulation with STROBOSCOPE, in: Proceedings of the 1994 Winter Simulation Conference, 1994, pp.

1159–1166.[9] J.C. Martinez, EZStrobe – general-purpose simulation system based on activity cycle diagrams, in: Proceedings of the 2001 Winter Simulation

Conference, IEEE, Washington, DC, 2001, pp. 1556–1564.[10] K.D. Tocher, D.G. Owen, The automatic programming of simulations, in: Proceedings of the Second Conference of the International Federation of OR

Societies, Aix-En-Province, English University Press, London, 1960, pp. 50–60.[11] J.N. Buxton, J.G. Laski, Control and simulation language, The Computer Journal 5 (3) (1962) 194–199.[12] A.T. Clementson, simulating with activities using C.A.P.S./E.C.S.L., in: Proceedings of the 1986 Winter simulation Conference, 1986, pp, 113–122.[13] S.C. Mathewson, Simulation program generators: code and animation on a P.C, Journal of the Operational Research Society 36 (7) (1985) 583–589.[14] R.J. Paul, S.T. Chew, Simulation modelling using an interactive simulation program generator, Journal of the Operational Research Society 38 (8) (1987)

735–752.[15] W.D.L. Araújo, C.M. Hirata, E.T. Yano, GroupSim: a collaborative environment for discrete event simulation software development for the world wide

web, Simulation 80 (6) (2004) 257–272.[16] M. Pidd, A. Carvalho, Simulation software: not the same yesterday, today or forever, Journal of Simulation 1 (1) (2006) 7–20.

800 D.H. Kang, B.K. Choi / Simulation Modelling Practice and Theory 19 (2011) 785–800

[17] J. Zhang, J. Gu, P. Li, Z. Duan, Object-oriented modeling of control system for agile manufacturing cells, International Journal of Production Economics62 (1999) 145–153.

[18] T. Agerwala, A complete model for representing the coordination of asynchronous processes, Hopkins Computer Research Report No. 32, ComputerScience Program, Johns Hopkins Univ., Baltimore, Md., July 1974, pp. 58.

[19] E.L. Savage, L.W. Schruben, E. Yücean, On the generality of event-graph models, INFORMS Journal on Computing 17 (1) (2005) 3–9.[20] J.L. Peterson, Petri Nets, Computing Surveys 9 (1977) 223–252.[21] S.C. Kleene, Introduction to Metamathematics, Van Nostrand, New York, 1952.[22] J.L. Peterson, Petri Net Theory and the Modeling of Systems, Prentice-Hall, Inc., 1981.[23] C. Ramchandani, Analysis of Asynchronous Concurrent Systems by Petri Nets, Project MAC, TR-120, MIT, Cambridge, MA, 1974.[24] A.M. Turing, On computable numbers, with an application to the Entscheidungsproblem, Proceedings of the London Mathematical Society 42 (1937)

230–265.[25] J.E. Hopcroft, J.D. Ullman, Introduction to Automata Theory, Languages and Computation, Addison-Wesley, Reading, MA, 1979.[26] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Model-View-Controller, in: Pattern-oriented Software Architecture: A System of Patterns,

John Wiley & Sons, Chichester, NY, 1996, pp. 125–144.[27] E. Gamma, R. Johnson, R. Helm, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.