P r i n c i p l e s o f S i m u l a t i o n M o d e l i n g

A. ALAN B. PRITSKERPritsker Corporation and Purdue University

2.1 INTRODUCTION

Simon [1] captures the essence of modeling in the following quote: "Modeling isa principalperhaps the primarytool for studying the behavior of large complexsystems When we model systems, we are usually (not always) interested in theirdynamic behavior. Typically, we place our model at some initial point in phase spaceand watch it mark out a path through the future." Simulation embodies this conceptbecause it involves playing out a model of a system by starting with the system statusat an initial point in time and evaluating the variables in a model over time to ascer-tain the dynamic performance of the model of the system. When the model is a validrepresentation of the system, meaningful information is obtained about the dynamic per-formance of the system. In this chapter, principles for building and using models thatare analyzed using simulation, referred to as simulation models, are presented.

Models are descriptions of systems. In the physical sciences, models are usuallydeveloped based on theoretical laws and principles. The models may be scaled physi-cal objects (iconic models), mathematical equations and relations (abstract models), orgraphical representations (visual models). The usefulness of models has been demon-strated in describing, designing, and analyzing systems. Model building is a complexprocess and in most fields involves both inductive and deductive reasoning. The mod-eling of a system is made easier if (1) physical laws are available that pertain to thesystem, (2) a pictorial or graphical representation can be made of the system, and (3)the uncertainty in system inputs, components, and outputs is quantifiable.

Modeling a complex, large-scale system is usually more difficult than modeling astrictly physical system, for one or more of the following reasons: (1) few fundamen-tal laws are available, (2) many procedural elements are involved which are difficultto describe and represent, (3) policy inputs are required which are hard to quantify,(4) random components are significant elements, and (5) human decision making is anintegral part of such systems.

CHAPTER 2

Handbook of Simulation, Edited by Jerry Banks.ISBN 0-471-13403-1 1998 John Wiley & Sons, Inc.

Since a model is a description of a system, it is also an abstraction of a system. Todevelop an abstraction, a model builder must decide on the elements of the system toinclude in the model. To make such decisions, a purpose for the model building mustbe established. Thus the first step in model building is the development of a purpose formodeling that is based on a stated problem or project goal. Based on this purpose, systemboundaries and modeling details are established. This abstraction results in a modelthat does not include all the rough, ill-defined edges of the actual system. Typically,the assessment process requires redefinitions and redesigns that cause the entire modelbuilding process to be performed iteratively.

Simulation models are ideally suited for carrying out the problem-solving approachdescribed above. Simulation provides the flexibility to build either aggregate or detailedmodels. It directly supports iterative model building by allowing models to be embel-lished through simple and direct additions. Surveys indicate that simulation is one ofthe most widely used tools of industrial engineers and management scientists. In 1989,the U.S. Departments of Defense and Energy specified that simulation and modelingtechnology is one of the top 22 critical technologies in the United States [2].

2.2 BASICPRINCIPLES

There are no established, published principles for simulation modeling. Modeling isconsidered an art [3] and a creative activity [4]. In this chapter an attempt is madeto provide modeling principles, based on the author's experience and interaction withcolleagues.

Modeling Principle 1 Conceptualizing a model requires system knowledge, engineer-ing judgment, and model-building tools.

A modeler must understand the structure and operating rules of a system and be ableto extract the essence of the system without including unnecessary detail. Usable modelstend to be easily understood, yet have sufficient detail to reflect realistically the impor-tant characteristics of the system. The crucial questions in model building focus on whatsimplifying assumptions are reasonable to make, what components should be includedin the model, and what interactions occur among the components. The amount of detailincluded in the model should be based on the modeling objectives established. Onlythose components that could cause significant differences in decision making, includ-ing confidence building, need to be considered.

A modeling project is normally an interdisciplinary activity and should include thedecision maker as part of the team. Close interaction among project personnel is requiredwhen formulating a problem and building a model. This interaction causes inaccuraciesto be discovered quickly and corrected efficiently. Most important is the fact that interac-tions induce confidence in both the modeler and the decision maker and help to achievea successful implementation of results.

By conceptualizing the model in terms of the structural components of the systemand product flows through the system, a good understanding of the detailed data require-ments can be projected. From the structural components, the schedules, algorithms, andcontrols required for the model can be determined. These decision components are typi-cally the most difficult aspect of a modeling effort.

Modeling Principle 2 The secret to being a good modeler is the ability to remodel.

Model building should be interactive and graphical because a model is not onlydefined and developed but is continually refined, updated, modified, and extended. Anup-to-date model provides the basis for future models. The following five model-build-ing themes support this approach and should be used where feasible:

1. Develop tailorable model input procedures and interfaces.2. Divide the model into relatively small logical elements.3. Separate physical and logical elements of the model.4. Develop and maintain clear documentation directly in the model.5. Leave hooks in the model to insert extensions or more detail; that is, build an

open-ended model.

Models developed for analysis by simulation are easily changed, which facilitatesiterations between model specification and model building. This is not usually the casefor other widely used model analysis techniques. Examples of the types of changes thatare easily made in simulation models are:

1. Setting arrival patterns and activity times to be constant, as samples from a the-oretical distribution, or derived from a file of historical values

2. Setting due dates based on historical records, manufacturing resource planning(MRPII) procedures, or sales information

3. Setting decision variables based on a heuristic procedure or calling a decision-making subprogram that uses an optimization technique

4. Including fixed rules or expert-system-based rules directly in the model

Modeling Principle 3 The modeling process is evolutionary because the act of mod-eling reveals important information piecemeal.

Information obtained during the modeling process supports actions that make themodel and its output measures more relevant and accurate. The modeling process con-tinues until additional detail or information is no longer necessary for problem resolutionor a deadline is encountered. During this evolutionary process, relationships between thesystem under study and the model are continually defined and redefined. Simulationsof the model provide insights into the behavior of the model, and hence the system,and lead to a further evolution of the model. The resulting correspondence between themodel and the system not only establishes the model as a tool for problem solving butprovides system familiarity for the modelers and a training vehicle for future users.

2.3 MODEL-BASED PROBLEM SOLVING

Figure 2.1 presents the components in the problem-solving environment when modelsare used to support the making of decisions or the setting of policies.

ModelerFigure 2.1 Model-based problem-solving process.

Modeling Principle 4 The problem or problem statement is the primary controllingelement in model-based problem solving.

A problem or objective drives the development of the model. Problem statements aredefined from system needs and requirements. Data from the system provide the input tothe model. The availability and form of the data help to specify the model boundariesand details. The modeler is the resource used to build the model in accordance with theproblem statement and the available system data. The outputs from the model supportdecisions to be made to solve the problem or the setting of policies that allow decisionsto be made in accordance with established rules and procedures. These components aredescribed in the following paragraphs with the aid of Figures 2.2 to 2.5.

The first step in model-based problem solving is to formulate the problem by under-standing its context, identifying project goals, specifying system performance measures,

Problem

Problem Model versions

DecisionsPoliciesSystem

data Model

Establishmodelingpurpose

Model

Figure 2.2 Model and its control.

Figure 2.3 Model and its control.

setting specific modeling objectives, and in general, defining the system to be modeled.Figure 2.2 shows that from the problem, a purpose for modeling is developed that guidesthe modeling effort toward solving the problem formulated. The double arrow betweenmodel and modeling purpose indicates that during the modeling effort, the purpose formodeling can change. Great care is needed here to ensure that the modeling effort doesnot stray from its goal of solving the original problem.

Figure 2.3 shows that there is a process between obtaining system data and usingthose data in the model. This process is called input modeling. Input modeling involvesthe determination of whether the system data should be used directly to drive the model,whether the system data should be summarized in the form of a histogram or distribu-tion function, or whether a cause-and-effect model (e.g., a regression model) should bedeveloped to characterize the system data. The input modeling activity can involve alarge effort. It is very useful in gaining an understanding of a system as well as refiningand for generalizing the system data for input to a model.

The types of data that need to be collected to support model-based problem solvinginclude data that describe the elements and logic of the system, data that measure theactual performance of the system, and data that describe the alternatives to be evaluated.Data that describe the logic of the system is concerned with system structure, individualcomponents of the system, component interactions, and system operations. The possiblestates of the system are established from this information. Performance measures arefunctions of these states and relate to profitability, costs, productivity, and quality.

Data collection may involve performing detailed time studies, getting informationfrom equipment vendors, and talking to system operators. Actual system performancehistories are collected whenever possible to support the validation of model outputs.Data describing proposed solutions are used to modify the basic model for each alter-native to be evaluated. Each alternative is typically evaluated individually, but perfor-mance data across alternatives are displayed together.

Figure 2.4 shows that a modeler may use a simulation system in developing themodel. A simulation system provides an environment to build, debug, test, verify, run,and analyze simulation models. They provide capabilities for graphical input and output,interactive execution of the simulation, data and distribution fitting, statistical analysis,storing and maintaining data in databases, reporting outputs using application programs,and most important, a simulation language. A simulation language contains modelingconcepts and procedures that facilitate the development of a model. Languages are com-posed of symbols. Defining a modeling language means defining the semantics and syn-tax of the symbols. Semantics specify the meaning of each symbol and the relationshipsamong symbols and take into account the human comprehensibility of the symbols;syntax defines the formal expression of symbols and their relationships in human- andcomputer-readable form.

For many years, models have been built using the language of mathematics and

Systemdata

Modelsystem

dataModel

ModelerFigure 2.4 Role of a simulation system.

general-purpose computer languages. General-purpose computer languages provide agreat deal of flexibility in modeling but do not contain a structure or set of concepts thatfacilitate the modeling task. Specializing such languages for use has simplified modelingtasks. In Chapter 24 we discuss how simulation software works and in Chapter 25,provide a survey of the software.

The final stage in the problem-solving process is to support decision making andpolicy setting as shown in Figure 2.5. For a simulation analyst, no project should beconsidered complete until its results are used. The use of the model involves both aninterpretation of outputs and a presentation of results. Planning for the use of model out-puts entails both strategic and tactical considerations. These considerations must includecontinual interaction between the model builder and the decision maker to ensure thatthe decision maker understands the model, its outputs, and its uses. If this is done, itis more likely that the results of the project will be implemented with vigor. The feed-back from output analysis to the model provides information as to how the model canbe adapted to satisfy better the problem statement. It is not uncommon that such feed-back also influences the problem statement. When this occurs, communications to thedecision maker are even more important.

Model

Usesimulation

system

Model

Analyzeoutputs

Decisions

Policies

Figure 2.5 Model and its outputs.

2.4 SIMULATION MODELING WORLD VIEWS [5]Simulation models of systems can be classified as discrete-change, continuous-change,or combined models. In most simulations, time is the major independent variable. Othervariables included in the simulation, such as machine status and number of parts ininventory, are functions of time and are the dependent variables. The values of thedependent variables are used to calculate operational performance measures. In a man-ufacturing system, typical performance measures are throughput, probability of meetingdeadlines, resource utilization, and in-process inventory. Profits and return on invest-ments, when possible, are estimated from these operational performance measures.

A discrete model has dependent variables that change only at distinct points in sim-ulated time, referred to as event times. For example, event times in a manufacturingsystem correspond to the times at which orders are placed in the system; material han-dling equipment arrives and departs from machines; and machines change status (e.g.,from busy to either idle, broken, or blocked).

A continuous model has dependent variables that are continuous functions of time.For example, the time required to unload an oil tanker or the position of a crane. Insome cases it is useful to model a discrete variable with a continuous representationby considering the entities in the system in the aggregate rather than individually. Forexample, the number of bottles on a conveyor may be modeled more efficiently usinga continuous representation, even though the bottles are washed and filled individually.

In a combined model, the dependent variables of a model may change discretely,continuously, or continuously with discrete jumps superimposed. The most importantaspect of combined simulation arises from the interaction between discretely and con-tinuously changing variables. For example, when a crane reaches a prescribed location,unloading is initiated.

In the following sections, the terminology of simulation modeling is presented andexamples of the use of modeling world views are given.

2.4.1 Discrete Simulation ModelingThe components that flow in a discrete system, such as people, equipment, orders, andraw materials, are called entities. There are many types of entities, and each has a setof characteristics or attributes. In simulation modeling, groupings of entities are calledfiles, sets, lists, or chains. The goal of a discrete simulation model is to portray theactivities in which the entities engage and thereby learn something about the system'sdynamic behavior. Simulation accomplishes this by defining the states of the systemand constructing activities that move it from state to state. The beginning and ending ofeach activity are events. The state of the model remains constant between consecutiveevent times, and a complete dynamic portrayal of the state of the model is obtained byadvancing simulated time from one event to the next. This timing mechanism, referredto as the next-event approach, is used in many discrete simulation languages.

There are many ways to formulate a discrete simulation model. Four formulationpossibilities are:

1. Defining the changes in state that occur at each event time2. Describing the process (network) through which the entities in the model flow3. Describing the activities in which the entities engage

4. Describing the objects (entities) and the conditions that change the state of theobjects

In this chapter the first two of the formulations above are presented. In Chapter 11,object-oriented modeling and its implementation are discussed.

2.4.2 Example of Discrete Simulation ModelingAn example of the concept of simulation was presented in Chapter 1, where service isgiven to customers by a bank teller. The purpose for this model was to estimate thepercent of time the teller is idle and the average time a customer spends in the system.Table 1.1 assumes that the time of arrival of each customer and the processing time bythe teller for each customer are known. An ad hoc simulation was used to analyze themodel.

To understand the model, we first define the state of the system, which for this exam-ple is the status of the teller (busy or idle) and the number of customers in the system.The state of the system is changed by (1) a customer arriving at the system, and (2)the completion of service by the teller and the subsequent departure of the customer.Note that for these two events, the status of the teller can be determined from the num-ber of customers in the system (i.e., idle if number of customers in the system is zero,and busy otherwise). The art of modeling and the evolutionary nature of modeling leadto the definition of state above to accommodate any future need to model customerdepartures or teller breaks. A possible status variable not included in the definitionsof the state of the system is the remaining processing time for a teller on a customer.This variable was omitted because a discrete-event model involving only two eventswas perceived. If a continuous model or a more elaborate discrete model is requiredto satisfy the purpose for modeling, the model might require this embellishment to thestate of the system description. To illustrate a simulation, the state of the system overtime is obtained by processing the events corresponding to the arrival and departure ofcustomers in a time-ordered sequence, as shown in Table 1.1.

In Table 2.1, columns (1) to (4) are system data. It is assumed that initially thereare no customers in the system, the teller is idle, and the first customer is to arrive attime 0.0. The start of service time given in column (5) depends on whether service onthe preceding customer has been completed. It is taken as the larger value of the arrivaltime of the customer and the departure time of the preceding customer. Column (6), thetime when service ends, is the sum of the column (5) value and the service time for thecustomer, column (4). Values for time-in-queue and time-in-system for each customerare computed in columns (7) and (8) as shown in Table 2.1. Average values per customerfor these variables are 7/20 or 0.35 minute and 72/20 or 3.6 minutes, respectively. Table2.1 presents a summary of information concerning each customer but does not provideinformation about the teller and the queue size of customers. To obtain such information,it is convenient to examine the events associated with the situation.

The logic associated with processing the arrival and departure events depends onthe state of the system at the time of the event. In the case of the arrival event, thedisposition of the arriving customer is based on the status of the teller. If the teller isidle, the status of the teller is changed to busy and the departure event is scheduledfor the customer by adding a service time to the current time. However, if the teller isbusy at the time of an arrival, the customer cannot begin service at the current time andtherefore enters the queue (the queue length is increased by 1). At a departure event, the

status of the teller depends on whether a customer is waiting. If a customer is waitingin the queue, the teller's status remains busy, the queue length is reduced by 1, and adeparture event for the customer removed from the queue is scheduled. If, however, thequeue is empty, the status of the teller is set to idle. In this description, the initiationof service can occur at an arrival event or a departure event. If the initiation of servicecould occur at some other time, it would be necessary to define initiation of serviceas a separate event. This is also the case for completion of service, which, for thisillustration, only happens when a departure event occurs.

An event-oriented description of customer status and number of customers in thesystem is given in Table 2.2. In the table the events are listed in chronological order.The average number of customers in the system is computed as a time-weighted average,that is, the sum of the product of the number in the system and the fraction of time thatthe number in the system existed. For this example there were 0 customers in the systemfor 30 minutes, 1 customer in the system for 59 minutes, and 2 customers in the systemfor 10 minutes. The weighted-average number of customers in the systems is 0(30/99)+ 1(59/99) + 2(10/99), or 0.798. The fraction of time the teller is idle is the total idletime divided by the total simulation time, which for this example is 30/99, or 0.303.

To place the arrival and departure events in their proper chronological order, it isnecessary to maintain a record or calendar of future events to be processed. This is doneby maintaining the times of the next arrival event and next departure event. The nextevent to be processed is then selected by comparing these event times. For situations

Table 2.1 Ad Hoc Simulation of Customer-Teller Banking System

(D

CustomerNumber

123456789

1011121314151617181920

(2)Time

BetweenArrivals

51

106291

1035235437877

(3)

ArrivalTime

056

1622243334444752545762666976849198

(4)

ServiceTime

22656434131236264531

(5)

ServiceBegins

057

1622283336444752545762687076849198

(6)Time

ServiceEnds

27

132128323640455053566068707680899499

(7)Time

inQueue

00100402000000210000

10

(8)Time

inSystem

22756836131236474531

79

with many events, an ordered list of events is maintained, which is referred to as anevent calendar.

Several important concepts are illustrated by this example. We observe that at anyinstant in simulated time, the model is in a particular state. As events occur, the stateof the model may change as prescribed by the logical-mathematical relationships asso-

Table 2.2 Event-Oriented Description of Customer-Teller Simulation.

EventTime

002567

1316212224283233343640444547505253545657606266686970767680848991949899

CustomerNumber

112323445656787899

10101111121213131415141615161717181819192020

EventType

StartArrivalDepartureArrivalArrivalDepartureDepartureArrivalDepartureArrivalArrivalDepartureDepartureArrivalArrivalDepartureDepatureArrivalDepartureArrivalDepartureArrivalDepartureArrivalDepartureArrivalDepartureArrivalArrivalDepartureArrivalDepartureDepartureArrivalDepartureArrivalDepartureArrivalDepartureArrivalDeparture

Number inQueue

00001000001000100000000000001010000000000

Number inSystem

01012101012101210101010101012121010101010

TellerStatus

IdleBusyIdleBusyBusyBusyIdleBusyIdleBusyBusyBusyIdleBusyBusyBusyIdleBusyIdleBusyIdleBusyIdleBusyIdleBusyIdleBusyBusyBusyBusyBusyIdleBusyIdleBusyIdleBusyIdleBusyIdle

Teller IdleTime

3

3

1

1

4

2

2

1

1

2

4

2

4

dated with the events. Thus events define potential changes. Given the starting state,the logic for processing each event, and a method for specifying the sample values, theproblem is largely one of bookkeeping. An essential element in the bookkeeping schemeis the event calendar, which provides a mechanism for recording and sequencing futureevents. Another point to observe is that state changes can be viewed from two perspec-tives: (1) the process that the entity (customer) encounters as it seeks service, or (2) theevents that cause the state to change. These views are illustrated in a network modeland in an event-based flowchart model in the next two sections.

2.4.3 Network Model of the Banking SystemA network is a form of process model that depicts the flow of entities through nodesand branches. This view of dynamic systems modeling using activity networks wasdeveloped by Pritsker in the early 1960s [6]. Many variants of network models foranalysis by simulation have been built on this theme.

A network model for the customer-teller bank system will now be developed. On anetwork, the passage of time is represented by a branch. A branch is a graphical rep-resentation of an activity. Clearly, teller processing is an activity and hence is modeledby a branch. If the teller activity is ongoing, arriving entities (customers) must wait.Waiting occurs in a QUEUE node. Thus a one-server, single-queue operation could bedepicted as QUEUE node, Q , followed by an activity, Processing activity , that is,

In this example, customers wait for service at the QUEUE node. When the teller isfree, a customer is removed from the queue and a service activity is initiated. Manyprocedures exist for specifying the time to perform the activities.

A complete network model is shown in Figure 2.6. Customer entities are insertedinto the network at the CREATE node. There is a zero time for the customer entity totravel to the QUEUE node, so that the customers arrive at the same time as they are

Customer ArrivalEXPONENTIALtIO.]

Figure 2.6 Network model of banking system.

Queue ofCustomers

Teller serviceUNIFORM[6.,12.] 100

2 1

2 110

5

QUEUE Node

Processing activity

Figure 2.7 Diagram of a banking system.

created. The customers either wait or are processed. The time spent in the bank systemby a customer is then collected at the COLLECT node. As can be seen, the networkmodel of Figure 2.6 resembles the diagram of operations presented in Figure 2.7. Thesymbol -vvvr* is used to indicate the start or end of the path for an entity and providesa means to see easily an entity's starting and ending locations in the network.

2.4.4 Discrete-Event Model of the Banking SystemThe states of the bank system are measured by the number of customers in the system andthe status of the teller. With the following two events, the changes in model state can bemade: (1) at a customer-arrival event, and (2) at an end-of-service event. A modeler mustdetermine the significant events to include in the model. Here all changes in status areassumed to occur at either the arrival time of a customer or at the time that service by theteller ends. Thus the state of the model will not change except at these event times.

The initialization logic for this example is depicted in Figure 2.8. The teller is initiallyset to idle. The arrival event corresponding to the first customer arrival is scheduled tooccur. By schedule is meant the placing of an event on the event calendar to occur at afuture time. This initialization establishes the initial state of the model as empty and idle.

The logic for the customer-arrival event is depicted in Figure 2.9. The first action thatis performed is the scheduling of the next arrival. Thus each arrival causes another arrivalto occur at a later time. In this way, only one arrival event is scheduled to occur at any onetime, but a complete sequence of arrivals is generated. The arrival time of the customer isrecorded. A test is then made on the status of the teller. If processing can begin, the teller ismade busy and an end-of-processing event for the arriving customer is scheduled. Other-wise, the customer is placed in the queue representing waiting customers.

At each end-of-processing event, a value is collected on the time the customer spentin the queue and in processing. Next, the first waiting customer, if any, is removed fromthe queue and its processing is initiated. The logic for the end-of-processing event isdepicted in Figure 2.10.

This simple example illustrates the basic concepts of discrete-event simulation mod-eling. Variables, entities, and file memberships make up the static structure of a simu-lation model. They describe the state of the model but not how it operates. The eventsspecify the logic that controls the changes that occur at specific instants of time. Thedynamic behavior is then obtained by sequentially processing events and recording sta-tus values at event times.

ArrivingCustomer Queue of Customers

CustomerBeing Served Teller

ServedCustomer

Figure 2.8 Initialization for banking system problem.

2.4.5 Continuous Simulation ModelingIn a continuous simulation model, the state of the system is represented by dependentvariables that change continuously over time. To distinguish continuous-change vari-ables from discrete-change variables, the former are, for communication convenience,referred to as state variables. A continuous simulation model is constructed by definingequations for a set of state variables.

State variables in a continuous model can be represented by one or more of thefollowing forms:

A system of explicit functional forms [e.g., A system of difference equations (e.g., A system of differential equations [e.g.,

Typically, the independent variable is time which, in the examples above, is representedby t and n. Simulation solutions are obtained by specifying values of the variables in theequations at an initial (or specific) point in time and using these values as inputs to obtainsolutions at a next point in time. The new values then become the starting values for thenext evaluation. This evaluation-step-evaluation procedure for obtaining values for thestate variables is referred to as continuous simulation analysis. It is used directly whenvariables are described by explicit functional forms or by a set of difference equations.When simultaneous equations are involved, numerical analysis procedures for obtainingvariable values to satisfy the set of equations are required at each step.

Models of continuous systems are frequently written in terms of the derivatives of

Initialization

Set teller idle

Set number insystem to zero

Schedule firstcustomer arrival

event

Return

Figure 2.9 Customer-arrival event logic.

the state variables, that is, differential equations. The reason for this is that it is ofteneasier to construct a relationship for the rate of change of a state variable than to devisea relationship for the state variable directly. If there is a differential equation in themodel, dy(t)/dt, the values of y(t) are obtained using numerical integration as follows:

Many methods exist for performing the integration indicated in the equation above.

Return

Scheduleend-of-processing

event

Set teller busy

ReturnYes

No File customerin queue

Istelleridle?

Schedule nextcustomer-arrival event

Save arrival time

Customer-arrival event

Figure 2.10 End-of-service event logic.

2.4.6 Building a Continuous ModelThe tasks of a modeler when developing a continuous model are:

Identify the state variables whose behavior is to be portrayed. A typical purposefor building continuous models is to describe behavior or to evaluate or optimizeproposed designs for controlling behavior.

Develop the equations describing the behavior of the state variables. Identify threshold conditions where status changes may occur. These are referred

to as state events to distinguish them from scheduled or time events. Determine the value of the state variables in accordance with the defining equations

subject to the changes possible when state events occur.

End of service event

Collect time-in-systemfor customer

Set idleNoIs there acustomerwaiting?

Yes Return

Remove firstwaiting customer

Scheduleend-of-service event

Return

Complexity in continuous models occurs for the following reasons:

Changes occur in the defining equations. These changes can be to the coefficientsor in the form of the equations and may occur at a time event or a state event.

Discrete (discontinuous) changes in the state variables can occur. Simultaneous sets of equations may exist because there are interactions among state

variables. Random variables are included in the defining equations.

Because some or all of these complexities usually occur in problem-solving situa-tions, a simulation approach is common when analyzing continuous models.

2.4.7 Combined Discrete-Continuous ModelsThe world view of a combined model specifies that the system can be described in termsof entities, global or model variables, and state variables. The behavior of the modelis simulated by computing the values of the state variables at small time steps and bycomputing the values of attributes of entities and global variables at event times. Thebreakthrough in modeling combined systems occurred when the definition of an eventwas challenged [7].

Three fundamental interactions can occur between discretely and continuouslychanging variables. First, a discrete change in value may be made to a continuous vari-able. Examples of this type of interaction are the completion of a maintenance operationthat instantaneously increases the rate of processing by machines within a system, andthe investment of capital that instantaneously increases the dollars available for rawmaterial purchase. Second, a continuous state variable achieving a threshold value maycause an event to occur or to be scheduled (e.g., the arrival of a material handler to aprescribed position initiates an unloading process). In general, events could be basedon the relative value of two or more state variables. Third, the functional descriptionof continuous variables may be changed at discrete time instants. An example of thisis the change in the equations governing acceleration of a crane when a human beingis in the vicinity of the crane.

The following principle describes a convenient initial approach to the combined mod-eling of a system. The evolutionary modeling principle stated previously applies to com-bined modeling so that any initial order to the modeling sequence will be superseded.

Modeling Principle 5 In modeling combined systems, the continuous aspects of theproblem should be considered first. The discrete aspects of the modelincluding events,networks, algorithms, control procedures, and advanced logic capabilitiesshould thenbe developed. The interfaces between discrete and continuous variable should then beapproached.

Combined discrete-event and continuous modeling constitutes a significant advancein the field of simulation. There are distinct groups within the simulation field fordiscrete-event simulation and continuous simulation. The disciplines associated withdiscrete-event simulation are industrial engineering, computer science, management sci-ence, operations research, and business administration. People who use continuous sim-ulation are more typically electrical engineers, mechanical engineers, chemical engi-

neers, agricultural engineers, and physicists. The overlap between the two groups hasnot been large. For years, the Summer Computer Simulation Conference was for contin-uous modelers and the Winter Simulation Conference was for discrete-event modelers.Only recently have the two groups started to mix. A large number of problems are inreality a combination of discrete and continuous phenomena and should be modeledusing a combined discrete-event/continuous approach. However, due to group division,either a continuous or a discrete modeling approach is normally employed.

2.4.8 Combined Modeling DescriptionsAn area where combined discrete continuous modeling has proven to be very powerful isin the development of procedures for analyzing the use of material handling equipment.The modeling of conveyors, cranes, and automated guided vehicles involve the contin-uous concepts of acceleration and velocity changes and also the discrete requirementsassociated with loading, unloading, picking up material, moving over network segments,and control strategies associated with movements. For packaging-line models, it is oftenadvantageous to model the items on the conveyor using continuous concepts to maintainstate variables of the number of items on the conveyor, the number of items in stagingareas, and the number of items being processed at a machine. Advanced packaging linesemploy variable-speed machines and variable-speed conveyors so that any linearizationof the continuous variables to allow discrete-event scheduling is not practical.

For large crane systems, the acceleration and deceleration characteristics of the cranecan make a large difference in its ability to process loads efficiently. Assumptions ofinstantaneous startups and stops are not appropriate. In addition, multiple cranes aretypically on a single runway that requires modeling the interference among the cranes.This involves monitoring multiple state variables and the detection of state events whentwo variables are within a prescribed distance.

For automated guided vehicles (AGVs), a two-dimensional grid is typically requiredwith the intersections being potential control points for directing the AGVs. Continuousvariables are used to represent the position of the vehicle and also the amount of energyavailable to power the vehicle. Discrete events relate to the requests for the AGV, theloading and unloading of material from the AGV, and the decision logic associated withthe disposition of an available AGV. Movement of the AGV, either loaded or unloaded,through the grid network is then described by the equations of motion governing theAGV system.

2.5 SIMULATION MODEL PURPOSE

Throughout this chapter, emphasis has been placed on the use of modeling and simu-lation to solve problems. The model-based problem solving process was presented asbeing driven by a system-specific purpose. Table 2.3 provides illustrations of systemsand areas and the types of design, planning, and operational issues that can be addressedusing modeling and simulation. The purpose for modeling can also have a functionallevel. The following list illustrates functional levels to which simulation modeling hasbeen applied:

As explanatory devices to understand a system or problem As a communication vehicle to describe system operation

As an analysis tool to determine critical elements, components, and issues and toestimate performance measures

As a design assessor to evaluate proposed solutions and to synthesize new alter-native solutions

As a scheduler to develop on-line operational schedules for jobs, tasks, andresources

As a control mechanism for the distribution and routing of materials and resources As a training tool to assist operators in understanding system operations As Si part of the system to provide on-line information, status projections, and deci-

sion support

Table 2.3 Modeling and Simulation Application Areas

Type of System

Manufacturing systems

Transportation systems

Computer and communicationsystems

Project planning and control

Financial planning

Environmental andecological studies

Health care systems

Design, Planning, andOperational Issues

Plant design and layoutContinuous improvementCapacity managementAgile manufacturing evaluationScheduling and controlMaterials handlingRailroad system performanceTruck scheduling and routingAir traffic controlTerminal and depot operationsPerformance evaluationWork-flow generation and analysisReliability assessmentProduct planningMarketing analysisResearch and development

performanceConstruction activity planningScheduling project activitiesCapital investment decision makingCash flow analysisRisk assessmentBalance sheet projectionsFlood controlPollution controlEnergy flows and utilizationFarm managementPest controlReactor maintainabilitySupply managementOperating room schedulingManpower planningOrgan transplantation policy evaluation

Table 2.4 Primary Outputs for Use in Applications by Functional Level

Functional Level Primary Outputs

Explanatory devices AnimationsCommunication vehicle Animations, plots, pie chartsAnalysis tool Tabulations, statistical estimators,

statistical graphsDesign assessor Statistical estimators, summary

statistics, ranking and selectionprocedures

Scheduler Tabular schedules, Gantt charts,resource plots

Control mechanism Tabular outputs, animations,resource plots

Training tool Animations, event traces,statistical estimators,summary statistics

Embedded system element Status information, projections

Since simulation modeling can be used at each of these levels and across a widespectrum of systems, many types of outputs and analysis capabilities are associatedwith simulation models. For any given level, any output capability could be used. In anattempt to bring focus to this issue, the high-level primary outputs associated with eachof the levels are listed in Table 2.4. With regard to the different purposes for whichmodels are used, the following principle is presented:

Modeling Principle 6 A model should be evaluated according to its usefulness. Froman absolute perspective, a model is neither good or bad, nor is it neutral.

As a summary to this section, modeling principle 7 is offered.

Modeling Principle 7 The purpose of simulation modeling is knowledge and under-standing, not models.

Simulation modeling is performed to induce change. To achieve change, the resultsof the modeling and simulation effort require implementation. For the simulationist,implementation based on results is a rewarding experience.

2.6 RELATED MODELING RESEARCH

Research on modeling is extremely difficult. Basic research on understanding modelsand the modeling process are reported by Fishwick [8], Little [9], Polya [10], Wymore[11], and Zeigler [12-14]. Henriksen [15-18] has produced excellent papers that high-light the significant questions on specialized simulation modeling efforts. Geoffrion [19,20] has written several basic papers on the fundamentals of structured modeling. Theimpact of these efforts on modeling practice remains to be seen.

ACKNOWLEDGMENTS

This material is based on work supported by the National Science Foundation underGrant DMS-8717799. The government has certain rights in this material. The authorthanks the following persons for helping to improve this chapter by providing reviewcomments: Barry Nelson of Northwestern University, Bob Schwab of Caterpillar Cor-poration, Bruce Schmeiser of Purdue University, and Steve Duket, Mary Grant, and KenMusselman of Pritsker Corporation.

REFERENCES

1. Simon, H. A. (1990). Prediction and prescription in systems modeling, Operations Research,Vol. 38, No. 1, pp. 7-14.

2. Council on Competitiveness (1989). Challenges, Vol. 1, No. 6.3. Morris, W. T. (1967). On the art of modeling, Management Science, Vol. 13, No. 12, pp.

707-717.4. Evans, J. R. (1991). Creative Thinking in the Decision and Management Sciences, South-

western Publishing, Cincinnati, Ohio.5. Pritsker, A. A. B. (1995). Introduction to Simulation and SLAMH, 4th ed., Systems Publishing

Corporation, West Lafayette, Ind., and Wiley, New York, pp. 51-66.6. Pritsker, A. A. B. (1990). Papers Experiences Perspectives, Wadsworth/ITP, Belmont,

Calif., pp. 240-245.7. Pritsker, A. A. B. (1990). Papers Experiences Perspectives, Wadsworth/ITP, Belmont,

Calif., p. 253.8. Fish wick, P. A. (1994). Simulation Model Design and Execution: Building Digital Worlds,

Prentice Hall, Upper Saddle River, NJ.9. Little, J. D. C. (1992). Tautologies, models and theories: can we find laws of manufacturing?

HE Transactions, July, pp. 7-13.10. Polya, G. (1973). How to Solve It, 2nd ed., Princeton University Press, Princeton, NJ.11. Wymore, A. W. (1976). A Mathematical Theory of Modelling and Simulation, Wiley, New

York.12. Ziegler, B. P. (1976). Theory of Modelling and Simulation, Wiley, New York.13. Ziegler, B. P. (1984). Multi-facetted Modelling and Discrete Event Simulation, Academic

Press, San Diego, Calif.14. Ziegler, B. P. (1990). Object-Oriented Simulation with Hierarchical, Modular Models, Aca-

demic Press, San Diego, Calif.15. Henriksen, J. O. (1986). You can't beat the clock: studies in problem solving, in Proceedings

of the 1986 Winter Simulation Conference, Washington, D.C., December, J. R. Wilson, J. O.Henriksen, and S. D. Roberts, eds., IEEE, Piscataway, NJ., pp. 713-726.

16. Henriksen, J. O. (1987). Alternatives for modeling of preemptive scheduling, in Proceedingsof the 1987 Winter Simulation Conference, A. Thesen, H. Grant, and W. D. Kelton, eds.,Atlanta, Ga., December, IEEE, Piscataway, NJ., pp. 575-581.

17. Henriksen, J. O. (1988). One system, several perspectives, many models, in Proceedings ofthe 1988 Winter Simulation Conference, M. A. Abrams, P. L. Haigh, and J. C. Comfort, eds.,San Diego, Calif., December, IEEE, Piscataway, NJ., pp. 352-356.

18. Henriksen, J. O. (1989). Alternative modeling perspectives: finding the creative spark,in Proceedings of the 1989 Winter Simulation Conference, Washington D.C., December,

E. A. MacNair, K. J. Musselman, and P. Heidelberger, eds., IEEE, Piscataway, NJ., pp.648-652.

19. Geoffrion, A. M. (1987). An introduction to structured modeling, Management Science, Vol.33, pp. 547-588.

20. Geoffrion, A. M. (1986). Integrated modeling systems, in Proceedings of the Conference onIntegrated Modeling Systems, University of Texas, Austin, Texas, October.

Front MatterTable of ContentsPart I. Principles1. Principles of Simulation2. Principles of Simulation Modeling2.1 Introduction2.2 Basic Principles2.3 Model-based Problem Solving2.4 Simulation Modeling World Views2.5 Simulation Model Purpose2.6 Related Modeling ResearchAcknowledgmentsReferences

Part II. MethodologyPart III. Recent AdvancesPart IV. Application AreasPart V. Practice of SimulationIndex