- Email: [email protected]
Modeling paradigms for discrete event simulation
Operations Research Letters 13 (1993)265-275 North-Holland
June 1993
Modeling paradigms for discrete event simulation * Lee Schruben Cornell Unicersity, School of Operations Research, and Industrial Engineering, Ithaca, New York 14853, USA
Enver Yiicesan INSEAD, European Institute of Business Administration, Boulecard de Constance, 77305 Fontainebleau Cedex, France Received November 1991 Revised April 1993
This paper reviews modeling paradigms for discrete event simulation. Various formalisms are described and critically discussed in terms of both their ability to contribute to an improved theory of simulation and their capability for assisting in effective model construction and implementation. The mathematics of graph theory are suggested as a rigorous and comprehensive basis for specifying discrete event simulation models. In particular, Simulation Graphs are described and shown to possess many of the desirable features of a modern model-based problem-solving environment. simulation; modeling paradigms; networks
I. Introduction
Discrete Event Dynamic Systems (DEDS) are those systems in which state changes occur only at asynchronous discrete instants of time. DEDS can be found in a variety of fields ranging from engineering to management science. Discrete event simulation is probably the most promising experimental technique in the study of DEDS since it allows scientists to explore the implications of complex theories and engineers to develop designs without the risks and expenses inherent in building and testing a prototype. Moreover, it is sometimes the only available means for studying the behavior of complex systems. This paper contains a survey of modeling paradigms for discrete event simulation. Various formalisms Correspondence to: L. Schruben, Cornell University, School of Operations Research, and Industrial Engineering, Ithaca, New York 14853, USA. * This research was partially supported by the National Science Foundation under grant ECS-8810517 to Cornell University. The support of the National Research Council is gratefully acknowledged.
are described and critically discussed. The mathematics of graph theory are suggested as a rigorous and comprehensive basis for specifying discrete event simulation models. In particular, Simulation Graphs are described and shown to possess many of the desirable features of a modern model-based problem solving environment. The major contribution of this paradigm is that it provides not only a complete basis for model specification, but also offers practical guidance for model implementation. The paper is organized as follows: Section 2 discusses various formalisms for discrete event systems. Graphical representations are introduced in Section 3 and Simulation Graphs are defined in Section 4. Closing arguments are presented in Section 5.
2. Discrete event f o r m a l i s m s
2.1. Preliminary Definitions A formalism for discrete event simulation is a set of conventions for model development. This
0167-6377/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved
265
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
process starts with the definition of a system and the objectives of the study, and proceeds through the following phases: specification of model behavior, construction of a run-time efficient implementation, and design of statistical collection and analysis procedures. A formalism should offer guidance through these phases in a precise manner. Moreover, a formalism should be evaluated based on both its ability to contribute to an improved theory of discrete event simulation and its utility, that is, its ability to assist in effective model construction and implementation (Overstreet and Nance, 1985). The objective of this section is to present the different formalisms in a unified framework together with a historical perspective. To this end, some preliminary definitions are needed. Following Schruben (1990), thus adopting a functional point of view, a system is defined as a collection of entities (objects) that interact for a common purpose according to sets of laws and policies. It is useful to classify system entities as being either resident or transient. The former remains part of the system for long periods of time (e.g., a machine in a job shop) whereas the latter enters and leaves the system with relative frequency (e.g., a part in a job shop). In describing the dynamic behavior of a system, one can focus on the paths along which transient entities flow as they pass through the system (e.g., part routings in a job shop). This is the process-interaction world view. Alternatively, one can focus on the cycles of the resident entities (e.g., the busy/idle cycle of a machine). This is the activity-scanning world view. Entities are described by their attributes or characteristics. The rules that govern the interaction of entities within a system are called laws if they are not under our control and policies if they are. The state of a system is a complete description of the system. It includes the values of all the attributes of entities, parameters of laws, factors for policies, time, and what might be known about the future. The state space is the set of all possible system states. A process is an indexed sequence of system states; typically, the index is time, but it might be some other system characteristic such as a count of customers. The eventscheduling world view focuses solely on those instants in (simulated) time where the system state is modified. 266
June 1993
A model is simply a system used as a surrogate for another system. In other words, a model is an abstraction of a system aimed at replicating some of the properties of that system. The level of detail and the type of abstraction depend on the properties the model is intended to replicate. A model specification defines what a model does while a model implementation defines how the model behavior is to be achieved. Discrete event formalisms are discussed next in the light of the above definitions. 2.2. Languages for simulation In the early days of computer based simulation, the approach had been rather pragmatic with efforts to generalize programming languages to include simulation. Instead of developing a framework for discrete event simulation, the focus was on producing a working simulation program without having to develop routines for managing the event calendar and the simulation clock, for generating random variates, and for collecting statistics. For example, GASP (Pritsker, 1974) provided commonly used support functions and data structures in Fortran. Simscript [CACI, 1976] has its roots in Fortran as well. It is a general-purpose programming language with special constructs for simulation. The novelty, however, lies in the modeling perspective it brought with entities, attributes, sets and events. It is a useful modeling convention to think of entities as belonging to sets. Over the years, Simscript has evolved to include such structures as resources and processes to enhance its modeling capabilities. Modeling novelties were also introduced by Simula (Dahl and Nygaard, 1967). While Simula has not achieved widespread popularity as a simulation language, its underlying structure has contributed a great deal to a new formalism, object oriented simulation. Object oriented programming and object oriented design are relatively recent developments in software design, and have had a growing impact on simulation modeling. Traditionally, simulation languages have provided a variety of standard objects such as queues, resources, and transactions, and have added new features in response to new and changing user demands. The goal of object oriented simulation, however, is to provide a consis-
Volume 13, Number 5
O P E R A T I O N S R E S E A R C H LETTERS
tent platform of concepts upon which the user can extend and customize the language by creating the necessary objects (Roberts and Heim, 1988). Such an object not only has its own characteristics, but also its own functionality. Intelligence can be built into this functionality through artificial intelligence and expert systems (Burns and Morgeson, 1988). A different approach to discrete event simulation is taken by GPSS (Schriber, 1974). Rather than generalizing programming languages to include simulation, GPSS emphasized a specific modeling structure, hiding the mechanics of programming. A GPSS program is a flow diagram made up of different blocks with a special name, symbol, and a predefined task. Entities called transactions flow through these blocks. They have with them a set of attributes. This framework provides a natural environment for modeling congestion systems. One of the biggest handicaps of GPSS is the poor support facilities and, in particular, those for random variate generation. 2.3. Characterization of simulation models In an early effort to mathematically characterize discrete event simulations, Evans et al. (1967) focus on four issues for model development: the units (entities) of the model, the event occurrences, the decisions, and the routines making up the simulation program. A unit is a particular type of component of the model. It may be a resident or transient entity. An event occurrence takes place at an instant in time. It permits the altering of the state of the units in the model. A decision event is an event routine where a sequence of tests is performed using the available information and an alternative is selected. Although this formulation provides some insight into the organization of simulation models, the formal description of units and event occurrences are for practical purposes very cumbersome. Using systems theory and the theory of finitestate machines, Zeigler (1976, 1984) provides conceptual tools for managing the dynamics of the simulation process. He defines descriptive variables as a set of variables that describe the components (entities) of a model. A subset of the descriptive variables whose values alone at time t
June 1993
are sufficient to uniquely determine the values of all descriptive variables at a future time t' is called a set of state variables. A STATE of the model is then characterized as an assignment of a value to each of the state variables. Hence, the set of all possible assignments, STATES, is given by the cross product of the range sets of these variables. A subset of the descriptive variables whose values are determined externally to the model is called a set of input variables. The set of all possible inputs into the model, INPUTS, is then defined as a subset of the cross product of the range sets of the input variables. The STATE of the model is determined based on the current STATE and the current INPUT. This state transition can be thought of as a function, f, where f = A o ~ with 8: STATES X INPUTS ~ STATES and A: STATES --~ OUTPUTS. The set, OUTPUTS, is defined as a subset of the cross product of the ranges for output variables, which, in turn, are defined as the subset of descriptive variables that the experimenter is interested in observing. Discrete event simulations are driven by an event calendar which contains the clock times at which the system is scheduled to undergo state transitions. Zeigler calls these instants hatching times. Then, given the STATE of the system at an instant, a time advance mechanism determines the incremental time until the next hatching time. This mechanism is represented as the following mapping: ta: STATES --* ~+. The Discrete Event System Specification (DEVS) is then defined as the following six tuple: (INPUTS, STATES, OUTPUTS, t~, .~, ta). Zeigler's formalism provides conceptual tools for model specifcation; however, it has yet to be developed into a practical guide for model implementation. The recent recasting of DEVS within the object oriented paradigm is a step in this direction (Kim and Zeigler, 1987). Nance (1981, 1987), Overstreet (1982, 1987), and Overstreet and Nance (1985) represent another school of thought in discrete event formalisms. The cornerstone of this development is the clarification of the time and state relationships by Nance (1981). The Conical Methodology (CM), on the other hand, provides a 'conceptual blueprint' for model development, starting with the system and objectives definitions and proceeding through several phases in which 'non267
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
procedural forms are transformed into an ultimate procedural and executable form' (Nance, 1987; Figure 1, p. 39). Operating within this framework, Overstreet and Nance (1985) introduce a model specification language to facilitate the translation of a Model Specification (MS) into a model implementation. An MS is defined as a quintuple: (input specifications, output specifications, object definition set, indexing attribute, transition specification). Any information used by the model, but controlled even partially by its environment, is described in the input specification. Similarly, information about the behavior of the model that is communicated to its environment is defined in the output specification. An object definition is an ordered pair which consists of the object type and the object attribute set. The latter assumes values as needed to record changes in the object's state. MS also has an indexing attribute commonly called 'system time'. Transition specification contains information about the initial state of the model, termination conditions, and interactions among model components. As such, it describes the dynamic behavior of the model. The language used in this formalism is called Condition Specification (CS). Overstreet (1987) shows that any CS can be transformed into a model specification in any of the three traditional world views. A large class of discrete event simulations can be characterized using Generalized Semi-Markov Processes (GSMPs). For instance, Glynn and Iglehart (1988) give an overview of simulation methods for queueing systems entirely within this formalism. The states of a GSMP represent possible physical configurations of a system. We let S denote the state space. The process jumps from state to state upon the occurrence of events. Let E(s) depict the set of possible events while the system is in state s. The state to which the process moves next is governed by a set of transition probabilities. That is, p(s'; s, ~) is the probability of jumping from state s to state s' when event ~7 occurs. The event epochs are determined by random clocks associated with the events. Each clock represents the time remaining until the associated event occurs. Clock times are sampled from distribution Fn(.) for events of type r/. The event with the smallest remaining clock time is the next one to occur. After being set, all clocks are run 268
June 1993
down at state dependent rates. When a clock runs out, the corresponding event occurs, and new clocks may be set for new events that might occur in the new state. All other clocks from the previous state continue to run down. A formal definition of GSMP is in terms of a discrete-time Markov process which describes the process at successive epochs of state transitions (Whitt 1980; Shedler, 1987). Glynn (1983) shows that much of the ergodic theory for finite-state Markov chains carries over to GSMPs; hence, points out the possibility of a comprehensive ergodic theory for discrete event simulations. GSMP formalism is not designed for model building, but rather for describing the possible sample paths generated by a model implementation.
3. Graphical representations In the remainder of this paper, graph theory is considered as a potential foundation for representing discrete event systems. This is not a surprising proposal since "graph theory is really a
theory of relations with graphs representing symmetric relations and digraphs asymmetric relations" (Lawler, 1976; p. 20). For instance, Neuse et al. (1989) use the following two axioms to construct a graphical representation, which serves as a foundation for a multi-level system design problem: (A1) The logical structure of any system can be represented as a directed graph with appropriate specification for the nodes and arcs. (A2) The behavior of any system can be represented as a traversal of the directed graph representation of a system structure by an appropriately defined set of transactions. In the context of discrete event simulation, graphical representation of models plays a crucial role. In fact, the process-interaction and activityscanning approches have been stimulated by the availability of graphical techniques for representing system structures. Block diagrams of GPSS (Schriber, 1974) or process networks of SLAM (Pritsker, 1984) have made the programming of process-interaction simulation models popular. Activity life cycle diagrams (Hutchinson, 1981) or wheel charts (Tocher, 1963), on the other hand, graphically represent a system's structure from an activity point of view. These graphical techniques often include fea-
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
tures either to accommodate the programming language used or code for particular implementation techniques, both of which may obscure the conceptual model (the model as it exists in the mind of the modeler) being implemented (Overstreet and Nance, 1985). Moreover, the set of icons adopted by these languages tends to grow in an ad hoc fashion as the modeling requirements change (see, for instance, Schriber (1989)). In an effort to represent a model specification in a graphical format independent of any simulation language, Evans et al. (1967) depict the interactions of event occurrences by drawing schematic chains of occurrences. These are directed graphs where vertices represent event occurrences and edges represent possible scheduling of further events a n d / o r cancellation of some of the previously scheduled ones. However, these graphs do not represent the underlying structure of a discrete event model in its entirety, but depict the sample path of possible realizations in the form of disconnected subgraphs. Therefore, in order to describe correctly and completely all possible interactions of event occurrences, a systematic enumeration technique is necessary (Evans et al., 1967; p. 131). For complex models, these chains grow too quickly to be of any practical use. One should also note that these chains are similar to the sample path event trees of Suri (1989). To model systems using a language-free structure, Torn (1981) introduces a graphical technique that incorporates several extensions to Petri nets. An excellent survey on Petri nets is presented by (Peterson, 1977). To create a convenient environment for simulation modeling, Torn (1981) introduces such extensions as inhibitor arcs (zero testing arcs), general test arcs, a time element, and queues. These extensions, however, seem to be fairly ad hoc in order to transform Petri nets into a simulation modeling tool with little consideration to making it a more unified framework. Moreover, most of the network analysis techniques that have been developed for Petri nets cannot be easily extended to the context of simulation models. Schruben (1983) analyzes event graphs in order to simplify a model specification and identify other structural properties of the model. The remainder of the paper is devoted to the discussion of event graphs and their extensions. In
June 1993
particular, this formalism will be shown to provide a consistent and comprehensive environment for model development.
4. Simulation graphs 4.1. Background The elements of a discrete event simulation are state variables that describe the state of the system, events that alter the values of state variables, and the relationships between events. An event graph is a structure of these elements in a discrete event system that facilitates the development of a correct simulation model. Hence, the emphasis is directly on system events; system entities are represented implicitly. Events are represented on the graph as vertices. Each vertex is associated with a set of changes to state variables. These variables are used to describe system entities. Relationships between events are represented in an event graph as directed edges between pairs of vertices. Each edge is associated with sets of logical and temporal expressions. Two types of edges are identified. Scheduling edges appear as solid arcs on the graph whereas cancelling edges are depicted as dashed arcs. The edges define under what conditions and after how long of a time delay one event will schedule or cancel another event. There can be multiple edges between any pair of vertices; the edges can point in either direction or may simply point from an edge to itself. In an event graph, it is also possible to parameterize the event vertices. Event parameterization is a modeling convenience and does not augment the modeling capabilities of these graphs. Parameters simply keep the graphs from becoming cluttered or possibly infinite (Yiicesan, 1990). This is achieved through vertex parameters and edge attributes. A vertex parameter list is a string of state variables associated with a particular vertex. An edge attribute list, on the other hand, is a string of expressions associated with a particular edge. These lists are used in scheduling or cancelling specific instances of events. For example, in a simulation model depicting the operations of a port, a single arrival event together with parameters can be used to model the arrival of different 269
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
types of ships. When the origination vertex of an edge is executed, the expressions in the edge attribute list are evaluated. These will be the values assigned to the state variables in the destination vertex parameter list when that vertex is subsequently executed. This practice is analogous to passing values to a subroutine using a list of arguments in a high level programming language. In summary, the construct,
is interpreted as follows: whenever event A occurs, if condition (i) holds, event B is scheduled to occur in t time units with the parameter string j, equal to k (Schruben 1990). The network provides a complete and consistent environment for model development. No new icons or constructs need to be defined as the modeling requirements change. In addition, this framework offers practical guidance not only for model specification, but also for model implementation. For instance, the customary notion of an event routine (see, for example, Simscript) in a simulation program may involve a subgraph, typically a set of vertices connected by edges with no time delays. Furthermore, analysis of an event graph can aid in the following tasks: (i) identifying needed state variables; (ii) determining a minimal set of events that must be scheduled at model initiation; (iii) anticipating logic errors due to simultaneously scheduled events; and (iv) eliminating unnecessary event routines (event reduction). Schruben (1983) presents several rules of thumb to resolve these issues, which have since been made into rigorous theorems (Yiicesan, 1989). A detailed example of an event graph model is presented in Appendix A.
4.2. Extensions Several variations of event graphs have appeared in the literature. Pegden (1985), Hoover and Perry (1989), and Law and Kelton (1991) use these networks to construct event-scheduling discrete event simulations. Extensions of event graph analysis have also been introduced. Sargent (1988) presents new rules for detection of simultaneously scheduled 270
June 1993
events and for event reduction. He also models a flexible manufacturing system with event graphs. Som and Sargent (1989) define rules for identifying simultaneously scheduled events and assigning execution priorities. They also introduce a conceptual algorithm for event reduction Simulation Graphs (Schruben and Yiicesan, 1987) represent an extension in another dimension. The two papers cited above mainly focus on issues related to the implementation of an eventoriented simulation model. Schruben and Yiicesan, on the other hand, focus on model specification. Their goal is to characterize these networks as a formalism for developing discrete event models. Moreover, their treatment is not limited to the event-scheduling world view, but targets DEDS in general. For example, a transformation procedure (namely, geometric dual) is shown to yield equivalent representations of queueing models under both event-scheduling and activity-scanning world views (Schruben and Yiicesan, 1989). It is indeed this change of focus that has led them to rename these networks Sim-
ulation Graphs. Graph theory is used as the foundation of this formalism. A directed graph is characterized as an Ordered triple (V(G), E(G), ~c) consisting of a nonempty set V(G) of vertices, a set E(G), disjoint from V(G), of edges, and an incidence function, ~c, that associates with each edge of G an ordered pair of (not necessarily distinct) vertices of G (Bondy and Murty, 1976). A network is then regarded as a graph in which additional data are stored in the vertices and edges (Lawler, 1976). A Simulation Graph is defined as an ordered quadruple G = (V(G), Es(G ), E c ( G ), ~G) where V(G) is the set of vertices of G, Es(G) is the set of scheduling edges of G, Ec(G) is the set of cancelling edges of G. The entities in this network are then defined as the following ordered sets: ~ = { L : v ~ V(G)}, the set of state transition functions associated with event vertex v, = {Ce: e c Es(G) U Ec(G)}, the set of edge con-
ditions, J = {te: e ~ Es(G)}, the set of edge delay times, F = {Ye: e ~Es(G)}, the set of event execution
priorities.
Volume 13, N u m b e r 5
OPERATIONS RESEARCH LETTERS
The execution priority, 3"e, is an expression associated with a scheduling edge that computes an execution priority for the event vertex being scheduled. The 3'e are used to break time ties, where smaller values correspond to higher priorities. Computing event execution priorities dynamically is merely a modeling convenience. It provides added flexibility in scheduling events with execution priorities based on, say, the current state of the system. The key idea is that a Simulation Graph specifies the relationships among the elements of the sets of entities in a simulation model. Then, a Simulation Graph Model is defined as 5 P = (5 r, ~ , 5 r, F, G). The first four sets in the above five-tuple define the entities in a model. The role played by the Simulation Graph, G, in the definition of a Simulation Graph Model, 5 ~, is analogous to the role of the incidence function, ~ c , in the definition of a directed graph; it organizes these sets of entities into a meaningful simulation model specification. That is, G gives the relationships between elements in the sets 9--, ~ , 3-, and F. The formalism of Simulation Graph Models focuses on model specification for DEDS. The objective is to have a static picture of the underlying structure rather than to describe possible sample paths. This formalism enables model implementation directly from model specification without requiring any further transformations. In fact, Simulation Graph Models can be implemented using a high level programming language or a general purpose simulation language by possibly coding subgraphs into separate event routines (Som and Sargent, 1989). A direct implementation is also possible (Schruben, 1990). Within this framework, the execution of a Simulation Graph Model implementation requires the services of a support routine, which will be referred to as the Event Scheduling Function (ESF). The ESF maintains two crucial variables: 7, the global simulation clock and 2 , the event calendar. In addition, it supports a scalar stochastic process of independent uniform random variables, U, on [0,1]. Appropriate transformations of U provide any random process needed in the simulation. Notice that the non-model-specific entities such as the event calendar and the global simulation clock are not included in the defini-
June 1993
tion of a particular Simulation Graph Model specification. The event calendar is an ordered set of triples. That is, ~ = {(t 1, 3'1, vl), (t2, 3'2, v2) . . . . }, where t/ represents the event execution time, 3'i represents the event execution priority, and v/ represents the associated event vertex. The triples, which are called event notices, are ordered by the event execution time. Those events that are scheduled to occur at the same simulated time are further ranked by their event execution priorities. We also define the following sets: S,. is the set of state variables that can possibly be altered at vertex v. E~. is the set of state variables involved in the conditions on the edges emanating from vertex v. P,,, the vertex parameter list, is a set of state variables associated with vertex v. Similarly, Ae, the edge attribute list, is simply a string of expressions associated with edge e. Recall that these lists are used in passing parameters from one vertex to another. The execution of a Simulation Graph Model implementation is carried out in the following manner: Initialize (run initialization). Step 1. Initialize global simulation clock T
~'- O.
Step 2. Insert the first event notice into the event calendar: this is usually the event where the initial condition of the model is specified by assigning the initial values to the state variables
{(0, 3'0, v0)}. Execute (execution of the model implementation). Step 1. Remove the first event record from _~; this is the event with the smallest event execution time (ties are resolved based on the execution priorities), say vi,
3',, v,)} Step 2. Update the global simulation clock: T
~
t i.
Step 3.1. Assign the values of the state variables in the vertex parameter list, P,,i' if the list is non-empty. This is parameter passing, which determines the system entity to which the particular event pertains. In particular, if X is a state variable in the vertex parameter list ( X ~ P~.), g ( y ) is an expression in the scheduling edge's attribute 271
Volume 13, Number 5
OPERATIONS RESEARCHLETI'ERS
list ( g ( y ) E A e ) , and y' is the current value of that expression, then X <--y'. Step 3.2. Evaluate the state change (i.e., the state variables in SL.,)
sv,
f,j,(sv,).
Step 4. Schedule a n d / o r cancel further events, if the edge conditions are true: For all edges emanating from vertex v i if C~. vj(Ev)= 1, then evaluate expressions in the edge attribute list, A ..... (including event execution priorities), genera't~ the inter-event time, t j, and if the edge is a scheduling edge, then . ~ <--- .Z/U {(~" + ty, r/, vj)}, if the edge is a cancelling edge, then
.20 <--- .2.a\{(z + t/, yj, vj)}. Step 5. Terminate the execution of the simulation if any of the following conditions is satisfied: (i) ~- exceeds Tstop, (ii) (tend, Tend, Uend) has just been executed, (iii) .~ is empty. Otherwise, go to Step 1 of Execute. (Here T,top represents a predefined stopping time for the simulation run and yend represents an end-ofsimulation event.) 5. Discussion Although the formalisms proposed over the last three decades contributed a great deal to our understanding of discrete event systems, we favor graphical representations and, in particular, Simulation Graph Models. We next assert that Simulation Graph Models possess most of the desirable features of a modern model-based problem solving environment as described by Geoffrion (1987). These features are: 1. Rigorous modeling framework with a single model representation suitable for managerial communication, mathematical use, and direct computer execution. The graph theoretic base is not only rigorous, coherent and complete for mathematical use, but it also makes the underlying structure of the models transparent, hence enhances managerial communication. This framework also enjoys a user-friendly computer implementation (Schruben, 1990). 2. Model~solver independence with interface standards and provision for libraries of models and 272
June 1993
solvers. The major emphasis of this platform is on model development. The framework, however, is sufficiently flexible to 'plug in' any special-purpose algorithm. The latter would then appear as a subgraph appropriately connected to the rest of the Simulation Graph Model. 3. Generality. The generality of Simulation Graph Models is established by showing the equivalence between these models and a Turing machine (Schruben and Yiicesan, 1987). 4. Life-cycle orientation. This paper mostly concentrates on the phases of model development, that is, model specification, implementation, and analysis rather than such activities as problem identification or presentation of results. 5. General structure~detailed data independence. The directed graph representation is completely general; model instances are specified by transforming the directed graph into a network through the specification of attributes for different entities in the graph. 6. Desktop computer-based with a modem user interface. Schruben (1990) introduces an interactive graphics program specifically designed to build and experiment with DEDS on personal computers using Simulation Graphs. 7. Integrated ad hoc query capabilities. It is certainly possible to export the generated data into another software package with these capabilities a n d / o r to incorporate this feature within the provided framework. 8. Resident expression evaluation capability. The current implementation automatically checks for the integrity of the expresssions (e.g., state changes associated with an event vertex) and issues warning messages. Based on Geoffrion's criteria, it can then be concluded that Simulation Graph Models offer a modern model-based problem solving environment for studying DEDS. More importantly, useful formalisms for model development along with powerful computers and general-purpose languages are needed to erase the unfortunate reputation of discrete event simulations as the technique of 'last resort'.
Appendix A: Oil tanker problem A sample study problem from the texts by Schriber (1974) and Law and Kelton (1991) is
V o l u m e 13, N u m b e r 5
OPERATIONS
RESEARCH
adapted to illustrate the construction of an event graph for a non-trivial system. This system is represented as a block diagram in Schriber, as a process network in Pritsker (1984), and as a modified Petri net graph in Torn (1981).
LETrERS
Table 1 Event descriptions Event type
Event description
State c h a n g e s
AR(j)
Type j t a n k e r arrival Begin b e r t h i n g t a n k e r of type j
B ~ B + 1 QB[B] ~ j T ~ 0 B ~ B - 1 k ~ QB[head] Q B [ h e a d ] *- Q B [ h e a d + 1] P *- P - 1 T ~ 1 D ~ D + 1 Q D [ D ] +- j T ~ - 1 D ~ D - 1
BB(j)
A port with three docks is used to load oil. Three different types of tanker ships use the port. The distribution for the random time between arrivals of a type j tanker, ta(j), is known. The time required to load a type j tanker, tl(j), also has a known distribution. There is a single tugboat in the harbor that is required for all tanker berthing and deberthing. It takes one hour for a tanker to be berthed or deberthed. A fleet of another tanker type wishes to begin using the port for shipment of oil on a specific route. The loading times, tl(4), and random round trip time, ta(4), for this fourth type of tanker have known distributions. The travel time for the tug when not towing a tanker is insignificant. The tug attends to tankers requesting berthing first. The state variables selected for the model are the following: B - number of tankers waiting for berthing; D - number of tankers waiting for deberthing; P - number of empty docks at the port; T - status of the tug; QB and QD - queues of tankers requesting berthing and deberthing, respectively; head and top - pointers to the first position in berthing and deberthing queues. The edge conditions for the model are: (i) (A berth is available, the tug is available) P > 0, T = 1, i.e., P T > O. (ii) (A berth is available, berthing queue is non-empty) P > 0, B > 0, i.e., PB > 0. (iii) (Deberthing queue is non-empty, berthing queue is empty) D > 0, B = 0. (iv) (The tug is available, berthing queue is empty) T = 1, B = 0. (v) (Berthing queue is nonempty) B > 0. The event descriptions are presented in Table 1. The associated Simulation Graph is presented in Figure 1. The entities that make up the model are described below. V(G)={vl, u 2 , . . . , u 6 } = {AR, BB, EB, EL, BD, ED}. Es(G) = {e~,..., el0} = {(AR, AR), (AR, BB), (BB, EB), (EB, BB), (EB, EL), (BL, EL), EL, BD), (BD, ED), (ED, BD), (ED, BB)}. Ec(G) = ¢. F c = See Figure 1.
J u n e 1993
EB(j) EL(j) BD(j)
End berthing tanker of type j E n d loading t a n k e r of type j Begin d e b e r t h i n g t a n k e r of t y p o j
P~P+I ED(j)
End deberthing t a n k e r of type j
k ,-- Q D [ t o p ] QD[top] ,-- Q D [ t o p + 1] T ,- l
~-: State transition functions fAR={j~'-k, B ~ B + 1, QB[B]*--j}, fro3 = {B ~ B - 1, T ~ 0, k ~ QB[head], QB[head] *-- QB[head + 1]}, f E B = { j ~ " - k , P ~ - P - 1, T~.- 1}, f E t = {J ~ k, D ~ D + 1, QD[D] ~-j}, f B D = { D ' , - - D - 1, T ~ - - 1 , P ~ P + 1, k ~QD[top], OD[top] *- QD[top + 1]}, fED = {J *- k, T *- 1}.
(i) (ii~
( '
(i~ I
( ( iii I
Fig. 1. T h e oil t a n k e r m o d e l 273
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
~ : E d g e conditions CAR,BB = {P * T > 0}, CE~,B a = {P * B > 0}, CEB,Bo = {D > 0, B = 0}, CEL,Bo = {T = 1, B = 0}, CEO,Bo = {D > 0, B = 0}, CEd,B B : {B > 0}. ~': E d g e delay times /AR,AR : tBB,E B = tEB,E L : /BD,ED :
ta,
1, tl, 1.
F : Event execution priorities A priority scheme could be devised in accord a n c e with operating policies.
Acknowledgements T h e authors would like to thank the Associate Editor for his detailed c o m m e n t s which improved the p a p e r substantially.
References J.A. Bondy, and U.S.R. Murty (1976), Graph Theory with Applications, North-Holland, New York. J.R. Burns, and J.D. Morgeson (1988), "An object-oriented world view for intelligent, discrete, next event simulation", Management Sci. 34/12, 1425-1440. Consolidated Analysis Centers, Inc. (1976), Simscript I1.5 Reference Handbook, Los Angeles, CA. O.J. Dahl, and K. Nygaard (1967), Simula: A Language for Programming and Description of Discrete Event Systems. Introduction and User's Mannual, 5th edition; Norwegian Computing Center, Oslo. G.W. Evans, G.F. Wallace, and G.L. Sutherland (1967), Simulation Using Digital Computers, Prentice Hall, Englewood Cliffs, NJ. A.M. Geoffrion, (1987), "Introduction to structured modeling", Management Sci. 33/5, 547-588. P.W. Glynn, (1983), "On the role of generalized semi-Markov processes in simulation output analysis", Proceedings of the Winter Simulation Conference, 39-42. P.W. Glynn, and D.L. Iglehart (1988), "Simulation methods for queues: An overview", Queueing Systems Theory and Applications 3/3, 221-256. S.V. Hoover, and R.F. Perry (1989), Simulation: A Problem Solving Approach, Addison Wesley, Reading, MA. G.K. Hutchinson, (1981), "The automation of simulation", Proceedings of the Winter Simulation Conference, 489-495 T.G. Kim, and B.P. Zeigler (1987), "The DEVS formalism: Hierarchical, modular system specification in an object oriented framework", Proceedings of the Winter Simulation Conference, 410-416.
274
June 1993
A.M. Law, and W.D. Kelton (1991), Simulation Modeling and Analysis, 2nd edition, McGraw Hill, New York, NY. E. Lawler (1976), Combinatorial Optimization: Networks and Matroids, Holt, Rinehart and Winston, New York, NY. R.E. Nance, (1981), "The time and state relationships in simulation modeling", Comm. ACM 24/4, 173-179. R.E. Nance, (1987). "The conical methodology: A framework for simulation model development", Proceedings of the Conference on Methodology and Validation (SCS), 38-43. D. Neuse, P. Juin, and J.C. Browne (1989), "A foundation for multi-level system design: directed graphs", Manuscript University of Texas at Austin. C.M. Overstreet, (1982), "Model specification and analysis for discrete event simulations", Unpublished Ph.D. Dissertation, Department of Computer Science, Virginia Tech. Blacksburg, VA. C.M. Overstreet, (1987), "Using graphs to translate between world views", Proceedings of the Winter Simulation Conference, 582-589. C.M. Overstreet, and R.E. Nance (1985), "A specification language to assist in analysis of discrete event simulation models", Comm. ACM 28/2, 190-201. C.D. Pegden, (1985), Introduction to SIMAN, Systems Modeling Corporation, State College, PA. J.L. Peterson, (1977), "Petri nets", Comput. Surveys 9/3, 223-252. A.A.B. Pritsker, (1974), The GASP IV Simulation Language, John Wiley, New York, NY. A.A.B. Pritsker, (1984), Introduction to Simulation and SLAM H, John Wiley and Sons, New York, NY. S.D. Roberts, and J. Heim (1988), "A perspective on object oriented simulation", Proceedings of the Winter Simulation Conference, 277-281. R.G. Sargent, (1988), "Event graph modeling for simulation with an application to flexible manufacturing systems." Management Sci. 34/10, 1231-1251. T.J. Schriber, (1974), Simulation Using GPSS, John Wiley, New York, NY. T.J. Schriber, (1989), "Perspectives on simulation using GPSS", Proceedings of the Winter Simulation Conference, 115-128. L.W. Schruben, (1983), "Simulation modeling with event graphs", Comm. ACM 26/11, 957-963. L.W. Schruben, (1990), Sigma: A Graphical Simulation System, The Scientific Press, San Francisco, CA. L.W. Schruben, and E. Yiicesan (1987), "On the generality of simulation graphs", Technical Report No. 773, School of OR & IE, Cornell University, Ithaca, NY. L.W. Schruben, and E. Yiicesan (1989), "Simulation graph duality: A world view transformation for simple queueing models", Proceedings of the Winter Simulation Conference, 738-745. G.S. Shedler, (1987), Regeneration and Networks of Queues, Springer-Verlag, New York, NY. T.K. Som, and R.G. Sargent (1989), "A formal development of event graphs as an aid to structured and efficient simulation programs", ORSA J. Comput. 1/2, 107-125. R. Suri (1989), "Perturbation analysis: The state of the art and research issues explained via the G I / G / 1 queue", Proc. IEEE 7/1, 114-136.
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
K.D. Tocher, (1963), The Art of Simulation, The English Universities Press Ltd, London. A.A. Torn, (1981), "Simulation graphs: A general tool for modeling simulation designs", Simulation 37, 187-194. W. Whitt (1980), "Continuity of generalized semi-Markov processes", Math, Oper. Res. 5/4, 494-501. E. Yiicesan (1989), "Simulation graphs for the design and analysis of discrete event simulation models", Unpublished Ph.D. Dissertation, School of OR & IE, Cornell University, Ithaca, NY.
June 1993
E. Yiicesan (1990), "Analysis of Markov chains using simulation graph models", Proceedings of the Winter Simulation Conference, 468-471. B.P. Zeigler, (1976), Theory of Modeling and Simulation, John Wiley, New York, NY. B.P. Zeigler, (1984), Multifacetted Modeling and Discrete Et,ent Simulation, Academic Press, New York, NY.
275
June 1993
Modeling paradigms for discrete event simulation * Lee Schruben Cornell Unicersity, School of Operations Research, and Industrial Engineering, Ithaca, New York 14853, USA
Enver Yiicesan INSEAD, European Institute of Business Administration, Boulecard de Constance, 77305 Fontainebleau Cedex, France Received November 1991 Revised April 1993
This paper reviews modeling paradigms for discrete event simulation. Various formalisms are described and critically discussed in terms of both their ability to contribute to an improved theory of simulation and their capability for assisting in effective model construction and implementation. The mathematics of graph theory are suggested as a rigorous and comprehensive basis for specifying discrete event simulation models. In particular, Simulation Graphs are described and shown to possess many of the desirable features of a modern model-based problem-solving environment. simulation; modeling paradigms; networks
I. Introduction
Discrete Event Dynamic Systems (DEDS) are those systems in which state changes occur only at asynchronous discrete instants of time. DEDS can be found in a variety of fields ranging from engineering to management science. Discrete event simulation is probably the most promising experimental technique in the study of DEDS since it allows scientists to explore the implications of complex theories and engineers to develop designs without the risks and expenses inherent in building and testing a prototype. Moreover, it is sometimes the only available means for studying the behavior of complex systems. This paper contains a survey of modeling paradigms for discrete event simulation. Various formalisms Correspondence to: L. Schruben, Cornell University, School of Operations Research, and Industrial Engineering, Ithaca, New York 14853, USA. * This research was partially supported by the National Science Foundation under grant ECS-8810517 to Cornell University. The support of the National Research Council is gratefully acknowledged.
are described and critically discussed. The mathematics of graph theory are suggested as a rigorous and comprehensive basis for specifying discrete event simulation models. In particular, Simulation Graphs are described and shown to possess many of the desirable features of a modern model-based problem solving environment. The major contribution of this paradigm is that it provides not only a complete basis for model specification, but also offers practical guidance for model implementation. The paper is organized as follows: Section 2 discusses various formalisms for discrete event systems. Graphical representations are introduced in Section 3 and Simulation Graphs are defined in Section 4. Closing arguments are presented in Section 5.
2. Discrete event f o r m a l i s m s
2.1. Preliminary Definitions A formalism for discrete event simulation is a set of conventions for model development. This
0167-6377/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved
265
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
process starts with the definition of a system and the objectives of the study, and proceeds through the following phases: specification of model behavior, construction of a run-time efficient implementation, and design of statistical collection and analysis procedures. A formalism should offer guidance through these phases in a precise manner. Moreover, a formalism should be evaluated based on both its ability to contribute to an improved theory of discrete event simulation and its utility, that is, its ability to assist in effective model construction and implementation (Overstreet and Nance, 1985). The objective of this section is to present the different formalisms in a unified framework together with a historical perspective. To this end, some preliminary definitions are needed. Following Schruben (1990), thus adopting a functional point of view, a system is defined as a collection of entities (objects) that interact for a common purpose according to sets of laws and policies. It is useful to classify system entities as being either resident or transient. The former remains part of the system for long periods of time (e.g., a machine in a job shop) whereas the latter enters and leaves the system with relative frequency (e.g., a part in a job shop). In describing the dynamic behavior of a system, one can focus on the paths along which transient entities flow as they pass through the system (e.g., part routings in a job shop). This is the process-interaction world view. Alternatively, one can focus on the cycles of the resident entities (e.g., the busy/idle cycle of a machine). This is the activity-scanning world view. Entities are described by their attributes or characteristics. The rules that govern the interaction of entities within a system are called laws if they are not under our control and policies if they are. The state of a system is a complete description of the system. It includes the values of all the attributes of entities, parameters of laws, factors for policies, time, and what might be known about the future. The state space is the set of all possible system states. A process is an indexed sequence of system states; typically, the index is time, but it might be some other system characteristic such as a count of customers. The eventscheduling world view focuses solely on those instants in (simulated) time where the system state is modified. 266
June 1993
A model is simply a system used as a surrogate for another system. In other words, a model is an abstraction of a system aimed at replicating some of the properties of that system. The level of detail and the type of abstraction depend on the properties the model is intended to replicate. A model specification defines what a model does while a model implementation defines how the model behavior is to be achieved. Discrete event formalisms are discussed next in the light of the above definitions. 2.2. Languages for simulation In the early days of computer based simulation, the approach had been rather pragmatic with efforts to generalize programming languages to include simulation. Instead of developing a framework for discrete event simulation, the focus was on producing a working simulation program without having to develop routines for managing the event calendar and the simulation clock, for generating random variates, and for collecting statistics. For example, GASP (Pritsker, 1974) provided commonly used support functions and data structures in Fortran. Simscript [CACI, 1976] has its roots in Fortran as well. It is a general-purpose programming language with special constructs for simulation. The novelty, however, lies in the modeling perspective it brought with entities, attributes, sets and events. It is a useful modeling convention to think of entities as belonging to sets. Over the years, Simscript has evolved to include such structures as resources and processes to enhance its modeling capabilities. Modeling novelties were also introduced by Simula (Dahl and Nygaard, 1967). While Simula has not achieved widespread popularity as a simulation language, its underlying structure has contributed a great deal to a new formalism, object oriented simulation. Object oriented programming and object oriented design are relatively recent developments in software design, and have had a growing impact on simulation modeling. Traditionally, simulation languages have provided a variety of standard objects such as queues, resources, and transactions, and have added new features in response to new and changing user demands. The goal of object oriented simulation, however, is to provide a consis-
Volume 13, Number 5
O P E R A T I O N S R E S E A R C H LETTERS
tent platform of concepts upon which the user can extend and customize the language by creating the necessary objects (Roberts and Heim, 1988). Such an object not only has its own characteristics, but also its own functionality. Intelligence can be built into this functionality through artificial intelligence and expert systems (Burns and Morgeson, 1988). A different approach to discrete event simulation is taken by GPSS (Schriber, 1974). Rather than generalizing programming languages to include simulation, GPSS emphasized a specific modeling structure, hiding the mechanics of programming. A GPSS program is a flow diagram made up of different blocks with a special name, symbol, and a predefined task. Entities called transactions flow through these blocks. They have with them a set of attributes. This framework provides a natural environment for modeling congestion systems. One of the biggest handicaps of GPSS is the poor support facilities and, in particular, those for random variate generation. 2.3. Characterization of simulation models In an early effort to mathematically characterize discrete event simulations, Evans et al. (1967) focus on four issues for model development: the units (entities) of the model, the event occurrences, the decisions, and the routines making up the simulation program. A unit is a particular type of component of the model. It may be a resident or transient entity. An event occurrence takes place at an instant in time. It permits the altering of the state of the units in the model. A decision event is an event routine where a sequence of tests is performed using the available information and an alternative is selected. Although this formulation provides some insight into the organization of simulation models, the formal description of units and event occurrences are for practical purposes very cumbersome. Using systems theory and the theory of finitestate machines, Zeigler (1976, 1984) provides conceptual tools for managing the dynamics of the simulation process. He defines descriptive variables as a set of variables that describe the components (entities) of a model. A subset of the descriptive variables whose values alone at time t
June 1993
are sufficient to uniquely determine the values of all descriptive variables at a future time t' is called a set of state variables. A STATE of the model is then characterized as an assignment of a value to each of the state variables. Hence, the set of all possible assignments, STATES, is given by the cross product of the range sets of these variables. A subset of the descriptive variables whose values are determined externally to the model is called a set of input variables. The set of all possible inputs into the model, INPUTS, is then defined as a subset of the cross product of the range sets of the input variables. The STATE of the model is determined based on the current STATE and the current INPUT. This state transition can be thought of as a function, f, where f = A o ~ with 8: STATES X INPUTS ~ STATES and A: STATES --~ OUTPUTS. The set, OUTPUTS, is defined as a subset of the cross product of the ranges for output variables, which, in turn, are defined as the subset of descriptive variables that the experimenter is interested in observing. Discrete event simulations are driven by an event calendar which contains the clock times at which the system is scheduled to undergo state transitions. Zeigler calls these instants hatching times. Then, given the STATE of the system at an instant, a time advance mechanism determines the incremental time until the next hatching time. This mechanism is represented as the following mapping: ta: STATES --* ~+. The Discrete Event System Specification (DEVS) is then defined as the following six tuple: (INPUTS, STATES, OUTPUTS, t~, .~, ta). Zeigler's formalism provides conceptual tools for model specifcation; however, it has yet to be developed into a practical guide for model implementation. The recent recasting of DEVS within the object oriented paradigm is a step in this direction (Kim and Zeigler, 1987). Nance (1981, 1987), Overstreet (1982, 1987), and Overstreet and Nance (1985) represent another school of thought in discrete event formalisms. The cornerstone of this development is the clarification of the time and state relationships by Nance (1981). The Conical Methodology (CM), on the other hand, provides a 'conceptual blueprint' for model development, starting with the system and objectives definitions and proceeding through several phases in which 'non267
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
procedural forms are transformed into an ultimate procedural and executable form' (Nance, 1987; Figure 1, p. 39). Operating within this framework, Overstreet and Nance (1985) introduce a model specification language to facilitate the translation of a Model Specification (MS) into a model implementation. An MS is defined as a quintuple: (input specifications, output specifications, object definition set, indexing attribute, transition specification). Any information used by the model, but controlled even partially by its environment, is described in the input specification. Similarly, information about the behavior of the model that is communicated to its environment is defined in the output specification. An object definition is an ordered pair which consists of the object type and the object attribute set. The latter assumes values as needed to record changes in the object's state. MS also has an indexing attribute commonly called 'system time'. Transition specification contains information about the initial state of the model, termination conditions, and interactions among model components. As such, it describes the dynamic behavior of the model. The language used in this formalism is called Condition Specification (CS). Overstreet (1987) shows that any CS can be transformed into a model specification in any of the three traditional world views. A large class of discrete event simulations can be characterized using Generalized Semi-Markov Processes (GSMPs). For instance, Glynn and Iglehart (1988) give an overview of simulation methods for queueing systems entirely within this formalism. The states of a GSMP represent possible physical configurations of a system. We let S denote the state space. The process jumps from state to state upon the occurrence of events. Let E(s) depict the set of possible events while the system is in state s. The state to which the process moves next is governed by a set of transition probabilities. That is, p(s'; s, ~) is the probability of jumping from state s to state s' when event ~7 occurs. The event epochs are determined by random clocks associated with the events. Each clock represents the time remaining until the associated event occurs. Clock times are sampled from distribution Fn(.) for events of type r/. The event with the smallest remaining clock time is the next one to occur. After being set, all clocks are run 268
June 1993
down at state dependent rates. When a clock runs out, the corresponding event occurs, and new clocks may be set for new events that might occur in the new state. All other clocks from the previous state continue to run down. A formal definition of GSMP is in terms of a discrete-time Markov process which describes the process at successive epochs of state transitions (Whitt 1980; Shedler, 1987). Glynn (1983) shows that much of the ergodic theory for finite-state Markov chains carries over to GSMPs; hence, points out the possibility of a comprehensive ergodic theory for discrete event simulations. GSMP formalism is not designed for model building, but rather for describing the possible sample paths generated by a model implementation.
3. Graphical representations In the remainder of this paper, graph theory is considered as a potential foundation for representing discrete event systems. This is not a surprising proposal since "graph theory is really a
theory of relations with graphs representing symmetric relations and digraphs asymmetric relations" (Lawler, 1976; p. 20). For instance, Neuse et al. (1989) use the following two axioms to construct a graphical representation, which serves as a foundation for a multi-level system design problem: (A1) The logical structure of any system can be represented as a directed graph with appropriate specification for the nodes and arcs. (A2) The behavior of any system can be represented as a traversal of the directed graph representation of a system structure by an appropriately defined set of transactions. In the context of discrete event simulation, graphical representation of models plays a crucial role. In fact, the process-interaction and activityscanning approches have been stimulated by the availability of graphical techniques for representing system structures. Block diagrams of GPSS (Schriber, 1974) or process networks of SLAM (Pritsker, 1984) have made the programming of process-interaction simulation models popular. Activity life cycle diagrams (Hutchinson, 1981) or wheel charts (Tocher, 1963), on the other hand, graphically represent a system's structure from an activity point of view. These graphical techniques often include fea-
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
tures either to accommodate the programming language used or code for particular implementation techniques, both of which may obscure the conceptual model (the model as it exists in the mind of the modeler) being implemented (Overstreet and Nance, 1985). Moreover, the set of icons adopted by these languages tends to grow in an ad hoc fashion as the modeling requirements change (see, for instance, Schriber (1989)). In an effort to represent a model specification in a graphical format independent of any simulation language, Evans et al. (1967) depict the interactions of event occurrences by drawing schematic chains of occurrences. These are directed graphs where vertices represent event occurrences and edges represent possible scheduling of further events a n d / o r cancellation of some of the previously scheduled ones. However, these graphs do not represent the underlying structure of a discrete event model in its entirety, but depict the sample path of possible realizations in the form of disconnected subgraphs. Therefore, in order to describe correctly and completely all possible interactions of event occurrences, a systematic enumeration technique is necessary (Evans et al., 1967; p. 131). For complex models, these chains grow too quickly to be of any practical use. One should also note that these chains are similar to the sample path event trees of Suri (1989). To model systems using a language-free structure, Torn (1981) introduces a graphical technique that incorporates several extensions to Petri nets. An excellent survey on Petri nets is presented by (Peterson, 1977). To create a convenient environment for simulation modeling, Torn (1981) introduces such extensions as inhibitor arcs (zero testing arcs), general test arcs, a time element, and queues. These extensions, however, seem to be fairly ad hoc in order to transform Petri nets into a simulation modeling tool with little consideration to making it a more unified framework. Moreover, most of the network analysis techniques that have been developed for Petri nets cannot be easily extended to the context of simulation models. Schruben (1983) analyzes event graphs in order to simplify a model specification and identify other structural properties of the model. The remainder of the paper is devoted to the discussion of event graphs and their extensions. In
June 1993
particular, this formalism will be shown to provide a consistent and comprehensive environment for model development.
4. Simulation graphs 4.1. Background The elements of a discrete event simulation are state variables that describe the state of the system, events that alter the values of state variables, and the relationships between events. An event graph is a structure of these elements in a discrete event system that facilitates the development of a correct simulation model. Hence, the emphasis is directly on system events; system entities are represented implicitly. Events are represented on the graph as vertices. Each vertex is associated with a set of changes to state variables. These variables are used to describe system entities. Relationships between events are represented in an event graph as directed edges between pairs of vertices. Each edge is associated with sets of logical and temporal expressions. Two types of edges are identified. Scheduling edges appear as solid arcs on the graph whereas cancelling edges are depicted as dashed arcs. The edges define under what conditions and after how long of a time delay one event will schedule or cancel another event. There can be multiple edges between any pair of vertices; the edges can point in either direction or may simply point from an edge to itself. In an event graph, it is also possible to parameterize the event vertices. Event parameterization is a modeling convenience and does not augment the modeling capabilities of these graphs. Parameters simply keep the graphs from becoming cluttered or possibly infinite (Yiicesan, 1990). This is achieved through vertex parameters and edge attributes. A vertex parameter list is a string of state variables associated with a particular vertex. An edge attribute list, on the other hand, is a string of expressions associated with a particular edge. These lists are used in scheduling or cancelling specific instances of events. For example, in a simulation model depicting the operations of a port, a single arrival event together with parameters can be used to model the arrival of different 269
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
types of ships. When the origination vertex of an edge is executed, the expressions in the edge attribute list are evaluated. These will be the values assigned to the state variables in the destination vertex parameter list when that vertex is subsequently executed. This practice is analogous to passing values to a subroutine using a list of arguments in a high level programming language. In summary, the construct,
is interpreted as follows: whenever event A occurs, if condition (i) holds, event B is scheduled to occur in t time units with the parameter string j, equal to k (Schruben 1990). The network provides a complete and consistent environment for model development. No new icons or constructs need to be defined as the modeling requirements change. In addition, this framework offers practical guidance not only for model specification, but also for model implementation. For instance, the customary notion of an event routine (see, for example, Simscript) in a simulation program may involve a subgraph, typically a set of vertices connected by edges with no time delays. Furthermore, analysis of an event graph can aid in the following tasks: (i) identifying needed state variables; (ii) determining a minimal set of events that must be scheduled at model initiation; (iii) anticipating logic errors due to simultaneously scheduled events; and (iv) eliminating unnecessary event routines (event reduction). Schruben (1983) presents several rules of thumb to resolve these issues, which have since been made into rigorous theorems (Yiicesan, 1989). A detailed example of an event graph model is presented in Appendix A.
4.2. Extensions Several variations of event graphs have appeared in the literature. Pegden (1985), Hoover and Perry (1989), and Law and Kelton (1991) use these networks to construct event-scheduling discrete event simulations. Extensions of event graph analysis have also been introduced. Sargent (1988) presents new rules for detection of simultaneously scheduled 270
June 1993
events and for event reduction. He also models a flexible manufacturing system with event graphs. Som and Sargent (1989) define rules for identifying simultaneously scheduled events and assigning execution priorities. They also introduce a conceptual algorithm for event reduction Simulation Graphs (Schruben and Yiicesan, 1987) represent an extension in another dimension. The two papers cited above mainly focus on issues related to the implementation of an eventoriented simulation model. Schruben and Yiicesan, on the other hand, focus on model specification. Their goal is to characterize these networks as a formalism for developing discrete event models. Moreover, their treatment is not limited to the event-scheduling world view, but targets DEDS in general. For example, a transformation procedure (namely, geometric dual) is shown to yield equivalent representations of queueing models under both event-scheduling and activity-scanning world views (Schruben and Yiicesan, 1989). It is indeed this change of focus that has led them to rename these networks Sim-
ulation Graphs. Graph theory is used as the foundation of this formalism. A directed graph is characterized as an Ordered triple (V(G), E(G), ~c) consisting of a nonempty set V(G) of vertices, a set E(G), disjoint from V(G), of edges, and an incidence function, ~c, that associates with each edge of G an ordered pair of (not necessarily distinct) vertices of G (Bondy and Murty, 1976). A network is then regarded as a graph in which additional data are stored in the vertices and edges (Lawler, 1976). A Simulation Graph is defined as an ordered quadruple G = (V(G), Es(G ), E c ( G ), ~G) where V(G) is the set of vertices of G, Es(G) is the set of scheduling edges of G, Ec(G) is the set of cancelling edges of G. The entities in this network are then defined as the following ordered sets: ~ = { L : v ~ V(G)}, the set of state transition functions associated with event vertex v, = {Ce: e c Es(G) U Ec(G)}, the set of edge con-
ditions, J = {te: e ~ Es(G)}, the set of edge delay times, F = {Ye: e ~Es(G)}, the set of event execution
priorities.
Volume 13, N u m b e r 5
OPERATIONS RESEARCH LETTERS
The execution priority, 3"e, is an expression associated with a scheduling edge that computes an execution priority for the event vertex being scheduled. The 3'e are used to break time ties, where smaller values correspond to higher priorities. Computing event execution priorities dynamically is merely a modeling convenience. It provides added flexibility in scheduling events with execution priorities based on, say, the current state of the system. The key idea is that a Simulation Graph specifies the relationships among the elements of the sets of entities in a simulation model. Then, a Simulation Graph Model is defined as 5 P = (5 r, ~ , 5 r, F, G). The first four sets in the above five-tuple define the entities in a model. The role played by the Simulation Graph, G, in the definition of a Simulation Graph Model, 5 ~, is analogous to the role of the incidence function, ~ c , in the definition of a directed graph; it organizes these sets of entities into a meaningful simulation model specification. That is, G gives the relationships between elements in the sets 9--, ~ , 3-, and F. The formalism of Simulation Graph Models focuses on model specification for DEDS. The objective is to have a static picture of the underlying structure rather than to describe possible sample paths. This formalism enables model implementation directly from model specification without requiring any further transformations. In fact, Simulation Graph Models can be implemented using a high level programming language or a general purpose simulation language by possibly coding subgraphs into separate event routines (Som and Sargent, 1989). A direct implementation is also possible (Schruben, 1990). Within this framework, the execution of a Simulation Graph Model implementation requires the services of a support routine, which will be referred to as the Event Scheduling Function (ESF). The ESF maintains two crucial variables: 7, the global simulation clock and 2 , the event calendar. In addition, it supports a scalar stochastic process of independent uniform random variables, U, on [0,1]. Appropriate transformations of U provide any random process needed in the simulation. Notice that the non-model-specific entities such as the event calendar and the global simulation clock are not included in the defini-
June 1993
tion of a particular Simulation Graph Model specification. The event calendar is an ordered set of triples. That is, ~ = {(t 1, 3'1, vl), (t2, 3'2, v2) . . . . }, where t/ represents the event execution time, 3'i represents the event execution priority, and v/ represents the associated event vertex. The triples, which are called event notices, are ordered by the event execution time. Those events that are scheduled to occur at the same simulated time are further ranked by their event execution priorities. We also define the following sets: S,. is the set of state variables that can possibly be altered at vertex v. E~. is the set of state variables involved in the conditions on the edges emanating from vertex v. P,,, the vertex parameter list, is a set of state variables associated with vertex v. Similarly, Ae, the edge attribute list, is simply a string of expressions associated with edge e. Recall that these lists are used in passing parameters from one vertex to another. The execution of a Simulation Graph Model implementation is carried out in the following manner: Initialize (run initialization). Step 1. Initialize global simulation clock T
~'- O.
Step 2. Insert the first event notice into the event calendar: this is usually the event where the initial condition of the model is specified by assigning the initial values to the state variables
{(0, 3'0, v0)}. Execute (execution of the model implementation). Step 1. Remove the first event record from _~; this is the event with the smallest event execution time (ties are resolved based on the execution priorities), say vi,
3',, v,)} Step 2. Update the global simulation clock: T
~
t i.
Step 3.1. Assign the values of the state variables in the vertex parameter list, P,,i' if the list is non-empty. This is parameter passing, which determines the system entity to which the particular event pertains. In particular, if X is a state variable in the vertex parameter list ( X ~ P~.), g ( y ) is an expression in the scheduling edge's attribute 271
Volume 13, Number 5
OPERATIONS RESEARCHLETI'ERS
list ( g ( y ) E A e ) , and y' is the current value of that expression, then X <--y'. Step 3.2. Evaluate the state change (i.e., the state variables in SL.,)
sv,
f,j,(sv,).
Step 4. Schedule a n d / o r cancel further events, if the edge conditions are true: For all edges emanating from vertex v i if C~. vj(Ev)= 1, then evaluate expressions in the edge attribute list, A ..... (including event execution priorities), genera't~ the inter-event time, t j, and if the edge is a scheduling edge, then . ~ <--- .Z/U {(~" + ty, r/, vj)}, if the edge is a cancelling edge, then
.20 <--- .2.a\{(z + t/, yj, vj)}. Step 5. Terminate the execution of the simulation if any of the following conditions is satisfied: (i) ~- exceeds Tstop, (ii) (tend, Tend, Uend) has just been executed, (iii) .~ is empty. Otherwise, go to Step 1 of Execute. (Here T,top represents a predefined stopping time for the simulation run and yend represents an end-ofsimulation event.) 5. Discussion Although the formalisms proposed over the last three decades contributed a great deal to our understanding of discrete event systems, we favor graphical representations and, in particular, Simulation Graph Models. We next assert that Simulation Graph Models possess most of the desirable features of a modern model-based problem solving environment as described by Geoffrion (1987). These features are: 1. Rigorous modeling framework with a single model representation suitable for managerial communication, mathematical use, and direct computer execution. The graph theoretic base is not only rigorous, coherent and complete for mathematical use, but it also makes the underlying structure of the models transparent, hence enhances managerial communication. This framework also enjoys a user-friendly computer implementation (Schruben, 1990). 2. Model~solver independence with interface standards and provision for libraries of models and 272
June 1993
solvers. The major emphasis of this platform is on model development. The framework, however, is sufficiently flexible to 'plug in' any special-purpose algorithm. The latter would then appear as a subgraph appropriately connected to the rest of the Simulation Graph Model. 3. Generality. The generality of Simulation Graph Models is established by showing the equivalence between these models and a Turing machine (Schruben and Yiicesan, 1987). 4. Life-cycle orientation. This paper mostly concentrates on the phases of model development, that is, model specification, implementation, and analysis rather than such activities as problem identification or presentation of results. 5. General structure~detailed data independence. The directed graph representation is completely general; model instances are specified by transforming the directed graph into a network through the specification of attributes for different entities in the graph. 6. Desktop computer-based with a modem user interface. Schruben (1990) introduces an interactive graphics program specifically designed to build and experiment with DEDS on personal computers using Simulation Graphs. 7. Integrated ad hoc query capabilities. It is certainly possible to export the generated data into another software package with these capabilities a n d / o r to incorporate this feature within the provided framework. 8. Resident expression evaluation capability. The current implementation automatically checks for the integrity of the expresssions (e.g., state changes associated with an event vertex) and issues warning messages. Based on Geoffrion's criteria, it can then be concluded that Simulation Graph Models offer a modern model-based problem solving environment for studying DEDS. More importantly, useful formalisms for model development along with powerful computers and general-purpose languages are needed to erase the unfortunate reputation of discrete event simulations as the technique of 'last resort'.
Appendix A: Oil tanker problem A sample study problem from the texts by Schriber (1974) and Law and Kelton (1991) is
V o l u m e 13, N u m b e r 5
OPERATIONS
RESEARCH
adapted to illustrate the construction of an event graph for a non-trivial system. This system is represented as a block diagram in Schriber, as a process network in Pritsker (1984), and as a modified Petri net graph in Torn (1981).
LETrERS
Table 1 Event descriptions Event type
Event description
State c h a n g e s
AR(j)
Type j t a n k e r arrival Begin b e r t h i n g t a n k e r of type j
B ~ B + 1 QB[B] ~ j T ~ 0 B ~ B - 1 k ~ QB[head] Q B [ h e a d ] *- Q B [ h e a d + 1] P *- P - 1 T ~ 1 D ~ D + 1 Q D [ D ] +- j T ~ - 1 D ~ D - 1
BB(j)
A port with three docks is used to load oil. Three different types of tanker ships use the port. The distribution for the random time between arrivals of a type j tanker, ta(j), is known. The time required to load a type j tanker, tl(j), also has a known distribution. There is a single tugboat in the harbor that is required for all tanker berthing and deberthing. It takes one hour for a tanker to be berthed or deberthed. A fleet of another tanker type wishes to begin using the port for shipment of oil on a specific route. The loading times, tl(4), and random round trip time, ta(4), for this fourth type of tanker have known distributions. The travel time for the tug when not towing a tanker is insignificant. The tug attends to tankers requesting berthing first. The state variables selected for the model are the following: B - number of tankers waiting for berthing; D - number of tankers waiting for deberthing; P - number of empty docks at the port; T - status of the tug; QB and QD - queues of tankers requesting berthing and deberthing, respectively; head and top - pointers to the first position in berthing and deberthing queues. The edge conditions for the model are: (i) (A berth is available, the tug is available) P > 0, T = 1, i.e., P T > O. (ii) (A berth is available, berthing queue is non-empty) P > 0, B > 0, i.e., PB > 0. (iii) (Deberthing queue is non-empty, berthing queue is empty) D > 0, B = 0. (iv) (The tug is available, berthing queue is empty) T = 1, B = 0. (v) (Berthing queue is nonempty) B > 0. The event descriptions are presented in Table 1. The associated Simulation Graph is presented in Figure 1. The entities that make up the model are described below. V(G)={vl, u 2 , . . . , u 6 } = {AR, BB, EB, EL, BD, ED}. Es(G) = {e~,..., el0} = {(AR, AR), (AR, BB), (BB, EB), (EB, BB), (EB, EL), (BL, EL), EL, BD), (BD, ED), (ED, BD), (ED, BB)}. Ec(G) = ¢. F c = See Figure 1.
J u n e 1993
EB(j) EL(j) BD(j)
End berthing tanker of type j E n d loading t a n k e r of type j Begin d e b e r t h i n g t a n k e r of t y p o j
P~P+I ED(j)
End deberthing t a n k e r of type j
k ,-- Q D [ t o p ] QD[top] ,-- Q D [ t o p + 1] T ,- l
~-: State transition functions fAR={j~'-k, B ~ B + 1, QB[B]*--j}, fro3 = {B ~ B - 1, T ~ 0, k ~ QB[head], QB[head] *-- QB[head + 1]}, f E B = { j ~ " - k , P ~ - P - 1, T~.- 1}, f E t = {J ~ k, D ~ D + 1, QD[D] ~-j}, f B D = { D ' , - - D - 1, T ~ - - 1 , P ~ P + 1, k ~QD[top], OD[top] *- QD[top + 1]}, fED = {J *- k, T *- 1}.
(i) (ii~
( '
(i~ I
( ( iii I
Fig. 1. T h e oil t a n k e r m o d e l 273
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
~ : E d g e conditions CAR,BB = {P * T > 0}, CE~,B a = {P * B > 0}, CEB,Bo = {D > 0, B = 0}, CEL,Bo = {T = 1, B = 0}, CEO,Bo = {D > 0, B = 0}, CEd,B B : {B > 0}. ~': E d g e delay times /AR,AR : tBB,E B = tEB,E L : /BD,ED :
ta,
1, tl, 1.
F : Event execution priorities A priority scheme could be devised in accord a n c e with operating policies.
Acknowledgements T h e authors would like to thank the Associate Editor for his detailed c o m m e n t s which improved the p a p e r substantially.
References J.A. Bondy, and U.S.R. Murty (1976), Graph Theory with Applications, North-Holland, New York. J.R. Burns, and J.D. Morgeson (1988), "An object-oriented world view for intelligent, discrete, next event simulation", Management Sci. 34/12, 1425-1440. Consolidated Analysis Centers, Inc. (1976), Simscript I1.5 Reference Handbook, Los Angeles, CA. O.J. Dahl, and K. Nygaard (1967), Simula: A Language for Programming and Description of Discrete Event Systems. Introduction and User's Mannual, 5th edition; Norwegian Computing Center, Oslo. G.W. Evans, G.F. Wallace, and G.L. Sutherland (1967), Simulation Using Digital Computers, Prentice Hall, Englewood Cliffs, NJ. A.M. Geoffrion, (1987), "Introduction to structured modeling", Management Sci. 33/5, 547-588. P.W. Glynn, (1983), "On the role of generalized semi-Markov processes in simulation output analysis", Proceedings of the Winter Simulation Conference, 39-42. P.W. Glynn, and D.L. Iglehart (1988), "Simulation methods for queues: An overview", Queueing Systems Theory and Applications 3/3, 221-256. S.V. Hoover, and R.F. Perry (1989), Simulation: A Problem Solving Approach, Addison Wesley, Reading, MA. G.K. Hutchinson, (1981), "The automation of simulation", Proceedings of the Winter Simulation Conference, 489-495 T.G. Kim, and B.P. Zeigler (1987), "The DEVS formalism: Hierarchical, modular system specification in an object oriented framework", Proceedings of the Winter Simulation Conference, 410-416.
274
June 1993
A.M. Law, and W.D. Kelton (1991), Simulation Modeling and Analysis, 2nd edition, McGraw Hill, New York, NY. E. Lawler (1976), Combinatorial Optimization: Networks and Matroids, Holt, Rinehart and Winston, New York, NY. R.E. Nance, (1981), "The time and state relationships in simulation modeling", Comm. ACM 24/4, 173-179. R.E. Nance, (1987). "The conical methodology: A framework for simulation model development", Proceedings of the Conference on Methodology and Validation (SCS), 38-43. D. Neuse, P. Juin, and J.C. Browne (1989), "A foundation for multi-level system design: directed graphs", Manuscript University of Texas at Austin. C.M. Overstreet, (1982), "Model specification and analysis for discrete event simulations", Unpublished Ph.D. Dissertation, Department of Computer Science, Virginia Tech. Blacksburg, VA. C.M. Overstreet, (1987), "Using graphs to translate between world views", Proceedings of the Winter Simulation Conference, 582-589. C.M. Overstreet, and R.E. Nance (1985), "A specification language to assist in analysis of discrete event simulation models", Comm. ACM 28/2, 190-201. C.D. Pegden, (1985), Introduction to SIMAN, Systems Modeling Corporation, State College, PA. J.L. Peterson, (1977), "Petri nets", Comput. Surveys 9/3, 223-252. A.A.B. Pritsker, (1974), The GASP IV Simulation Language, John Wiley, New York, NY. A.A.B. Pritsker, (1984), Introduction to Simulation and SLAM H, John Wiley and Sons, New York, NY. S.D. Roberts, and J. Heim (1988), "A perspective on object oriented simulation", Proceedings of the Winter Simulation Conference, 277-281. R.G. Sargent, (1988), "Event graph modeling for simulation with an application to flexible manufacturing systems." Management Sci. 34/10, 1231-1251. T.J. Schriber, (1974), Simulation Using GPSS, John Wiley, New York, NY. T.J. Schriber, (1989), "Perspectives on simulation using GPSS", Proceedings of the Winter Simulation Conference, 115-128. L.W. Schruben, (1983), "Simulation modeling with event graphs", Comm. ACM 26/11, 957-963. L.W. Schruben, (1990), Sigma: A Graphical Simulation System, The Scientific Press, San Francisco, CA. L.W. Schruben, and E. Yiicesan (1987), "On the generality of simulation graphs", Technical Report No. 773, School of OR & IE, Cornell University, Ithaca, NY. L.W. Schruben, and E. Yiicesan (1989), "Simulation graph duality: A world view transformation for simple queueing models", Proceedings of the Winter Simulation Conference, 738-745. G.S. Shedler, (1987), Regeneration and Networks of Queues, Springer-Verlag, New York, NY. T.K. Som, and R.G. Sargent (1989), "A formal development of event graphs as an aid to structured and efficient simulation programs", ORSA J. Comput. 1/2, 107-125. R. Suri (1989), "Perturbation analysis: The state of the art and research issues explained via the G I / G / 1 queue", Proc. IEEE 7/1, 114-136.
Volume 13, Number 5
OPERATIONS RESEARCH LETTERS
K.D. Tocher, (1963), The Art of Simulation, The English Universities Press Ltd, London. A.A. Torn, (1981), "Simulation graphs: A general tool for modeling simulation designs", Simulation 37, 187-194. W. Whitt (1980), "Continuity of generalized semi-Markov processes", Math, Oper. Res. 5/4, 494-501. E. Yiicesan (1989), "Simulation graphs for the design and analysis of discrete event simulation models", Unpublished Ph.D. Dissertation, School of OR & IE, Cornell University, Ithaca, NY.
June 1993
E. Yiicesan (1990), "Analysis of Markov chains using simulation graph models", Proceedings of the Winter Simulation Conference, 468-471. B.P. Zeigler, (1976), Theory of Modeling and Simulation, John Wiley, New York, NY. B.P. Zeigler, (1984), Multifacetted Modeling and Discrete Et,ent Simulation, Academic Press, New York, NY.
275