CHAPTER 2 Principles of Simulation M o d e l i n g

A. ALAN B. PRITSKER Pritsker Corporation and Purdue University

2.1

INTRODUCTION

Simon [1] captures the essence of modeling in the following quote: "Modeling is a principalperhaps the primarytool for studying the behavior of large complex systems When we model systems, we are usually (not always) interested in their dynamic behavior. Typically, we place our model at some initial point in phase space and watch it mark out a path through the future." Simulation embodies this concept because it involves playing out a model of a system by starting with the system status at an initial point in time and evaluating the variables in a model over time to ascertain the dynamic performance of the model of the system. When the model is a valid representation of the system, meaningful information is obtained about the dynamic performance of the system. In this chapter, principles for building and using models that are analyzed using simulation, referred to as simulation models, are presented. Models are descriptions of systems. In the physical sciences, models are usually developed based on theoretical laws and principles. The models may be scaled physical objects (iconic models), mathematical equations and relations (abstract models), or graphical representations (visual models). The usefulness of models has been demonstrated in describing, designing, and analyzing systems. Model building is a complex process and in most fields involves both inductive and deductive reasoning. The modeling of a system is made easier if (1) physical laws are available that pertain to the system, (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 a strictly physical system, for one or more of the following reasons: (1) few fundamental laws are available, (2) many procedural elements are involved which are difficult to 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 an integral part of such systems.

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. To develop an abstraction, a model builder must decide on the elements of the system to include in the model. To make such decisions, a purpose for the model building must be established. Thus the first step in model building is the development of a purpose for modeling that is based on a stated problem or project goal. Based on this purpose, system boundaries and modeling details are established. This abstraction results in a model that 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 model building process to be performed iteratively. Simulation models are ideally suited for carrying out the problem-solving approach described above. Simulation provides the flexibility to build either aggregate or detailed models. It directly supports iterative model building by allowing models to be embellished through simple and direct additions. Surveys indicate that simulation is one of the most widely used tools of industrial engineers and management scientists. In 1989, the U.S. Departments of Defense and Energy specified that simulation and modeling technology 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 is considered an art [3] and a creative activity [4]. In this chapter an attempt is made to provide modeling principles, based on the author's experience and interaction with colleagues. Modeling Principle 1 Conceptualizing a model requires system knowledge, engineering judgment, and model-building tools. A modeler must understand the structure and operating rules of a system and be able to extract the essence of the system without including unnecessary detail. Usable models tend to be easily understood, yet have sufficient detail to reflect realistically the important characteristics of the system. The crucial questions in model building focus on what simplifying assumptions are reasonable to make, what components should be included in the model, and what interactions occur among the components. The amount of detail included in the model should be based on the modeling objectives established. Only those components that could cause significant differences in decision making, including confidence building, need to be considered. A modeling project is normally an interdisciplinary activity and should include the decision maker as part of the team. Close interaction among project personnel is required when formulating a problem and building a model. This interaction causes inaccuracies to be discovered quickly and corrected efficiently. Most important is the fact that interactions induce confidence in both the modeler and the decision maker and help to achieve a successful implementation of results. By conceptualizing the model in terms of the structural components of the system and product flows through the system, a good understanding of the detailed data requirements can be projected. From the structural components, the schedules, algorithms, and controls required for the model can be determined. These decision components are typically 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 only defined and developed but is continually refined, updated, modified, and extended. An up-to-date model provides the basis for future models. The following five model-building themes support this approach and should be used where feasible: 1. 2. 3. 4. 5. Develop tailorable model input procedures and interfaces. Divide the model into relatively small logical elements. Separate physical and logical elements of the model. Develop and maintain clear documentation directly in the model. 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 facilitates iterations between model specification and model building. This is not usually the case for other widely used model analysis techniques. Examples of the types of changes that are easily made in simulation models are: 1. Setting arrival patterns and activity times to be constant, as samples from a theoretical 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 decisionmaking 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 modeling reveals important information piecemeal. Information obtained during the modeling process supports actions that make the model and its output measures more relevant and accurate. The modeling process continues until additional detail or information is no longer necessary for problem resolution or a deadline is encountered. During this evolutionary process, relationships between the system under study and the model are continually defined and redefined. Simulations of 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 the model and the system not only establishes the model as a tool for problem solving but provides 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 models are used to support the making of decisions or the setting of policies.

Problem

Model versions

Decisions System data Model Policies

Modeler

Figure 2.1 Model-based problem-solving process.

Modeling Principle 4 The problem or problem statement is the primary controlling element in model-based problem solving. A problem or objective drives the development of the model. Problem statements are defined from system needs and requirements. Data from the system provide the input to the model. The availability and form of the data help to specify the model boundaries and details. The modeler is the resource used to build the model in accordance with the problem statement and the available system data. The outputs from the model support decisions to be made to solve the problem or the setting of policies that allow decisions to be made in accordance with established rules and procedures. These components are described 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 understanding its context, identifying project goals, specifying system performance measures,

Problem

Establish modeling purpose

Model

Figure 2.2 Model and its control.

System data

Model system data

Model

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 guides the modeling effort toward solving the problem formulated. The double arrow between model and modeling purpose indicates that during the modeling effort, the purpose for modeling can change. Great care is needed here to ensure that the modeling effort does not stray from its goal of solving the original problem. Figure 2.3 shows that there is a process between obtaining system data and using those data in the model. This process is called input modeling. Input modeling involves the 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 distribution function, or whether a cause-and-effect model (e.g., a regression model) should be developed to characterize the system data. The input modeling activity can involve a large effort. It is very useful in gaining an understanding of a system as well as refining and for generalizing the system data for input to a model. The types of data that need to be collected to support model-based problem solving include data that describe the elements and logic of the system, data that measure the actual 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, individual components of the system, component interactions, and system operations. The possible states of the system are established from this information. Performance measures are functions of these states and relate to profitability, costs, productivity, and quality. Data collection may involve performing detailed time studies, getting information from equipment vendors, and talking to system operators. Actual system performance histories are collected whenever possible to support the validation of model outputs. Data describing proposed solutions are used to modify the basic model for each alternative to be evaluated. Each alternative is typically evaluated individually, but performance data across alternatives are displayed together. Figure 2.4 shows that a modeler may use a simulation system in developing the model. 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 modeling concepts and procedures that facilitate the development of a model. Languages are composed of symbols. Defining a modeling language means defining the semantics and syntax of the symbols. Semantics specify the meaning of each symbol and the relationships among symbols and take into account the human comprehensibility of the symbols; syntax defines the formal expression of symbols and their relationships in human- and computer-readable form. For many years, models have been built using the language of mathematics and

Model

Use simulation system

Modeler Figure 2.4 Role of a simulation system.

general-purpose computer languages. General-purpose computer languages provide a great deal of flexibility in modeling but do not contain a structure or set of concepts that facilitate the modeling task. Specializing such languages for use has simplified modeling tasks. 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 and policy setting as shown in Figure 2.5. For a simulation analyst, no project should be considered complete until its results are used. The use of the model involves both an interpretation of outputs and a presentation of results. Planning for the use of model outputs entails both strategic and tactical considerations. These considerations must include continual interaction between the model builder and the decision maker to ensure that the decision maker understands the model, its outputs, and its uses. If this is done, it is more likely that the results of the project will be implemented with vigor. The feedback from output analysis to the model provides information as to how the model can be adapted to satisfy better the problem statement. It is not uncommon that such feedback also influences the problem statement. When this occurs, communications to the decision maker are even more important.

Analyze outputs Model

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. Other variables included in the simulation, such as machine status and number of parts in inventory, are functions of time and are the dependent variables. The values of the dependent variables are used to calculate operational performance measures. In a manufacturing system, typical performance measures are throughput, probability of meeting deadlines, resource utilization, and in-process inventory. Profits and return on investments, when possible, are estimated from these operational performance measures. A discrete model has dependent variables that change only at distinct points in simulated time, referred to as event times. For example, event times in a manufacturing system correspond to the times at which orders are placed in the system; material handling 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. In some cases it is useful to model a discrete variable with a continuous representation by considering the entities in the system in the aggregate rather than individually. For example, the number of bottles on a conveyor may be modeled more efficiently using a 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 important aspect of combined simulation arises from the interaction between discretely and continuously 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 and examples of the use of modeling world views are given. 2.4.1 Discrete Simulation Modeling

The components that flow in a discrete system, such as people, equipment, orders, and raw materials, are called entities. There are many types of entities, and each has a set of characteristics or attributes. In simulation modeling, groupings of entities are called files, sets, lists, or chains. The goal of a discrete simulation model is to portray the activities in which the entities engage and thereby learn something about the system's dynamic behavior. Simulation accomplishes this by defining the states of the system and constructing activities that move it from state to state. The beginning and ending of each activity are events. The state of the model remains constant between consecutive event times, and a complete dynamic portrayal of the state of the model is obtained by advancing simulated time from one event to the next. This timing mechanism, referred to as the next-event approach, is used in many discrete simulation languages. There are many ways to formulate a discrete simulation model. Four formulation possibilities are: 1. Defining the changes in state that occur at each event time 2. Describing the process (network) through which the entities in the model flow 3. Describing the activities in which the entities engage

4. Describing the objects (entities) and the conditions that change the state of the objects 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 Modeling

An example of the concept of simulation was presented in Chapter 1, where service is given to customers by a bank teller. The purpose for this model was to estimate the percent 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 by the teller for each customer are known. An ad hoc simulation was used to analyze the model. To understand the model, we first define the state of the system, which for this example 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 number 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 lead to the definition of state above to accommodate any future need to model customer departures or teller breaks. A possible status variable not included in the definitions of 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 events was perceived. If a continuous model or a more elaborate discrete model is required to satisfy the purpose for modeling, the model might require this embellishment to the state of the system description. To illustrate a simulation, the state of the system over time is obtained by processing the events corresponding to the arrival and departure of customers 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 there are no customers in the system, the teller is idle, and the first customer is to arrive at time 0.0. The start of service time given in column (5) depends on whether service on the preceding customer has been completed. It is taken as the larger value of the arrival time of the customer and the departure time of the preceding customer. Column (6), the time when service ends, is the sum of the column (5) value and the service time for the customer, column (4). Values for time-in-queue and time-in-system for each customer are computed in columns (7) and (8) as shown in Table 2.1. Average values per customer for these variables are 7/20 or 0.35 minute and 72/20 or 3.6 minutes, respectively. Table 2.1 presents a summary of information concerning each customer but does not provide information 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 on the state of the system at the time of the event. In the case of the arrival event, the disposition of the arriving customer is based on the status of the teller. If the teller is idle, the status of the teller is changed to busy and the departure event is scheduled for the customer by adding a service time to the current time. However, if the teller is busy at the time of an arrival, the customer cannot begin service at the current time and therefore enters the queue (the queue length is increased by 1). At a departure event, the

Table 2.1 Ad Hoc Simulation of Customer-Teller Banking System

(D
Customer Number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

(2) Time Between Arrivals 5 1 10 6 2 9 1 10 3 5 2 3 5 4 3 7 8 7 7

(3) Arrival Time 0 5 6 16 22 24 33 34 44 47 52 54 57 62 66 69 76 84 91 98

(4) Service Time 2 2 6 5 6 4 3 4 1 3 1 2 3 6 2 6 4 5 3 1

(5) Service Begins 0 5 7 16 22 28 33 36 44 47 52 54 57 62 68 70 76 84 91 98

(6) Time Service Ends 2 7 13 21 28 32 36 40 45 50 53 56 60 68 70 76 80 89 94 99

(7) Time in Queue 0 0 1 0 0 4 0 2 0 0 0 0 0 0 2 1 0 0 0 0 10

(8) Time in System 2 2 7 5 6 8 3 6 1 3 1 2 3 6 4 7 4 5 3 1 79

status of the teller depends on whether a customer is waiting. If a customer is waiting in the queue, the teller's status remains busy, the queue length is reduced by 1, and a departure event for the customer removed from the queue is scheduled. If, however, the queue is empty, the status of the teller is set to idle. In this description, the initiation of service can occur at an arrival event or a departure event. If the initiation of service could occur at some other time, it would be necessary to define initiation of service as a separate event. This is also the case for completion of service, which, for this illustration, only happens when a departure event occurs. An event-oriented description of customer status and number of customers in the system 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 that the number in the system existed. For this example there were 0 customers in the system for 30 minutes, 1 customer in the system for 59 minutes, and 2 customers in the system for 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 idle time 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 is necessary to maintain a record or calendar of future events to be processed. This is done by maintaining the times of the next arrival event and next departure event. The next event to be processed is then selected by comparing these event times. For situations

Table 2.2 Event-Oriented Description of Customer-Teller Simulation. Event Time 0 0 2 5 6 7 13 16 21 22 24 28 32 33 34 36 40 44 45 47 50 52 53 54 56 57 60 62 66 68 69 70 76 76 80 84 89 91 94 98 99 Customer Number 1 1 2 3 2 3 4 4 5 6 5 6 7 8 7 8 9 9 10 10 11 11 12 12 13 13 14 15 14 16 15 16 17 17 18 18 19 19 20 20 Event Type Start Arrival Departure Arrival Arrival Departure Departure Arrival Departure Arrival Arrival Departure Departure Arrival Arrival Departure Depature Arrival Departure Arrival Departure Arrival Departure Arrival Departure Arrival Departure Arrival Arrival Departure Arrival Departure Departure Arrival Departure Arrival Departure Arrival Departure Arrival Departure Number in Queue 0 0 0 0 1 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 Number in System 0 1 0 1 2 1 0 1 0 1 2 1 0 1 2 1 0 1 0 1 0 1 0 1 0 1 0 1 2 1 2 1 0 1 0 1 0 1 0 1 0 Teller Status Idle Busy Idle Busy Busy Busy Idle Busy Idle Busy Busy Busy Idle Busy Busy Busy Idle Busy Idle Busy Idle Busy Idle Busy Idle Busy Idle Busy Busy Busy Busy Busy Idle Busy Idle Busy Idle Busy Idle Busy Idle Teller Idle Time

3 1

4 2 2 1 1 2

4 2 4

with many events, an ordered list of events is maintained, which is referred to as an event calendar. Several important concepts are illustrated by this example. We observe that at any instant in simulated time, the model is in a particular state. As events occur, the state of the model may change as prescribed by the logical-mathematical relationships asso-

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, the problem is largely one of bookkeeping. An essential element in the bookkeeping scheme is the event calendar, which provides a mechanism for recording and sequencing future events. Another point to observe is that state changes can be viewed from two perspectives: (1) the process that the entity (customer) encounters as it seeks service, or (2) the events that cause the state to change. These views are illustrated in a network model and in an event-based flowchart model in the next two sections.
2.4.3 Network Model of the Banking System

A network is a form of process model that depicts the flow of entities through nodes and branches. This view of dynamic systems modeling using activity networks was developed by Pritsker in the early 1960s [6]. Many variants of network models for analysis by simulation have been built on this theme. A network model for the customer-teller bank system will now be developed. On a network, the passage of time is represented by a branch. A branch is a graphical representation of an activity. Clearly, teller processing is an activity and hence is modeled by 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 be depicted as QUEUE node, Q , followed by an activity, Processing activity , that is,

QUEUE Node Processing activity

In this example, customers wait for service at the QUEUE node. When the teller is free, a customer is removed from the queue and a service activity is initiated. Many procedures exist for specifying the time to perform the activities. A complete network model is shown in Figure 2.6. Customer entities are inserted into the network at the CREATE node. There is a zero time for the customer entity to travel to the QUEUE node, so that the customers arrive at the same time as they are

Customer Arrival EXPONENTIALtIO.] Queue of Customers Teller service UNIFORM[6.,12.]

2 1 10

100

Figure 2.6 Network model of banking system.

Arriving Customer

Queue of Customers

Customer Being Served

Teller

Served Customer

Figure 2.7 Diagram of a banking system.

created. The customers either wait or are processed. The time spent in the bank system by a customer is then collected at the COLLECT node. As can be seen, the network model of Figure 2.6 resembles the diagram of operations presented in Figure 2.7. The symbol -vvvr* is used to indicate the start or end of the path for an entity and provides a means to see easily an entity's starting and ending locations in the network. 2.4.4 Discrete-Event Model of the Banking System

The states of the bank system are measured by the number of customers in the system and the status of the teller. With the following two events, the changes in model state can be made: (1) at a customer-arrival event, and (2) at an end-of-service event. A modeler must determine the significant events to include in the model. Here all changes in status are assumed to occur at either the arrival time of a customer or at the time that service by the teller 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 initially set to idle. The arrival event corresponding to the first customer arrival is scheduled to occur. By schedule is meant the placing of an event on the event calendar to occur at a future 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 that is performed is the scheduling of the next arrival. Thus each arrival causes another arrival to occur at a later time. In this way, only one arrival event is scheduled to occur at any one time, but a complete sequence of arrivals is generated. The arrival time of the customer is recorded. A test is then made on the status of the teller. If processing can begin, the teller is made busy and an end-of-processing event for the arriving customer is scheduled. Otherwise, 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 spent in the queue and in processing. Next, the first waiting customer, if any, is removed from the queue and its processing is initiated. The logic for the end-of-processing event is depicted in Figure 2.10. This simple example illustrates the basic concepts of discrete-event simulation modeling. Variables, entities, and file memberships make up the static structure of a simulation model. They describe the state of the model but not how it operates. The events specify the logic that controls the changes that occur at specific instants of time. The dynamic behavior is then obtained by sequentially processing events and recording status values at event times.

Initialization

Set teller idle Set number in system to zero

Schedule first customer arrival event

Return Figure 2.8 Initialization for banking system problem.

2.4.5

Continuous Simulation Modeling

In a continuous simulation model, the state of the system is represented by dependent variables that change continuously over time. To distinguish continuous-change variables from discrete-change variables, the former are, for communication convenience, referred to as state variables. A continuous simulation model is constructed by defining equations for a set of state variables. State variables in a continuous model can be represented by one or more of the following 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 represented by t and n. Simulation solutions are obtained by specifying values of the variables in the equations at an initial (or specific) point in time and using these values as inputs to obtain solutions at a next point in time. The new values then become the starting values for the next evaluation. This evaluation-step-evaluation procedure for obtaining values for the state variables is referred to as continuous simulation analysis. It is used directly when variables are described by explicit functional forms or by a set of difference equations. When simultaneous equations are involved, numerical analysis procedures for obtaining variable 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

Customer-arrival event

Schedule next customer-arrival event Save arrival time

Is teller idle?

No

File customer in queue

Yes
Return Set teller busy

Schedule end-of-processing event

Return

Figure 2.9 Customer-arrival event logic.

the state variables, that is, differential equations. The reason for this is that it is often easier to construct a relationship for the rate of change of a state variable than to devise a relationship for the state variable directly. If there is a differential equation in the model, 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.

End of service event

Collect time-in-system for customer

Is there a customer waiting?

No

Set idle

Yes
Remove first waiting customer

Return

Schedule end-of-service event

Return Figure 2.10 End-of-service event logic.

2.4.6

Building a Continuous Model

The tasks of a modeler when developing a continuous model are: Identify the state variables whose behavior is to be portrayed. A typical purpose for building continuous models is to describe behavior or to evaluate or optimize proposed 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.

Complexity in continuous models occurs for the following reasons: Changes occur in the defining equations. These changes can be to the coefficients or 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 situations, a simulation approach is common when analyzing continuous models. 2.4.7 Combined Discrete-Continuous Models The world view of a combined model specifies that the system can be described in terms of entities, global or model variables, and state variables. The behavior of the model is simulated by computing the values of the state variables at small time steps and by computing the values of attributes of entities and global variables at event times. The breakthrough in modeling combined systems occurred when the definition of an event was challenged [7]. Three fundamental interactions can occur between discretely and continuously changing variables. First, a discrete change in value may be made to a continuous variable. Examples of this type of interaction are the completion of a maintenance operation that instantaneously increases the rate of processing by machines within a system, and the investment of capital that instantaneously increases the dollars available for raw material purchase. Second, a continuous state variable achieving a threshold value may cause an event to occur or to be scheduled (e.g., the arrival of a material handler to a prescribed position initiates an unloading process). In general, events could be based on the relative value of two or more state variables. Third, the functional description of continuous variables may be changed at discrete time instants. An example of this is the change in the equations governing acceleration of a crane when a human being is in the vicinity of the crane. The following principle describes a convenient initial approach to the combined modeling of a system. The evolutionary modeling principle stated previously applies to combined modeling so that any initial order to the modeling sequence will be superseded. Modeling Principle 5 In modeling combined systems, the continuous aspects of the problem should be considered first. The discrete aspects of the modelincluding events, networks, algorithms, control procedures, and advanced logic capabilitiesshould then be developed. The interfaces between discrete and continuous variable should then be approached. Combined discrete-event and continuous modeling constitutes a significant advance in the field of simulation. There are distinct groups within the simulation field for discrete-event simulation and continuous simulation. The disciplines associated with discrete-event simulation are industrial engineering, computer science, management science, operations research, and business administration. People who use continuous simulation are more typically electrical engineers, mechanical engineers, chemical engi-

neers, agricultural engineers, and physicists. The overlap between the two groups has not been large. For years, the Summer Computer Simulation Conference was for continuous 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 in reality a combination of discrete and continuous phenomena and should be modeled using 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 Descriptions

An area where combined discrete continuous modeling has proven to be very powerful is in the development of procedures for analyzing the use of material handling equipment. The modeling of conveyors, cranes, and automated guided vehicles involve the continuous concepts of acceleration and velocity changes and also the discrete requirements associated with loading, unloading, picking up material, moving over network segments, and control strategies associated with movements. For packaging-line models, it is often advantageous to model the items on the conveyor using continuous concepts to maintain state variables of the number of items on the conveyor, the number of items in staging areas, and the number of items being processed at a machine. Advanced packaging lines employ variable-speed machines and variable-speed conveyors so that any linearization of the continuous variables to allow discrete-event scheduling is not practical. For large crane systems, the acceleration and deceleration characteristics of the crane can make a large difference in its ability to process loads efficiently. Assumptions of instantaneous startups and stops are not appropriate. In addition, multiple cranes are typically on a single runway that requires modeling the interference among the cranes. This involves monitoring multiple state variables and the detection of state events when two variables are within a prescribed distance. For automated guided vehicles (AGVs), a two-dimensional grid is typically required with the intersections being potential control points for directing the AGVs. Continuous variables are used to represent the position of the vehicle and also the amount of energy available to power the vehicle. Discrete events relate to the requests for the AGV, the loading and unloading of material from the AGV, and the decision logic associated with the 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 the AGV system.
2.5 SIMULATION MODEL PURPOSE

Throughout this chapter, emphasis has been placed on the use of modeling and simulation to solve problems. The model-based problem solving process was presented as being driven by a system-specific purpose. Table 2.3 provides illustrations of systems and areas and the types of design, planning, and operational issues that can be addressed using modeling and simulation. The purpose for modeling can also have a functional level. The following list illustrates functional levels to which simulation modeling has been applied: As explanatory devices to understand a system or problem As a communication vehicle to describe system operation

Table 2.3 Modeling and Simulation Application Areas Type of System Manufacturing systems Design, Planning, and Operational Issues Plant design and layout Continuous improvement Capacity management Agile manufacturing evaluation Scheduling and control Materials handling Railroad system performance Truck scheduling and routing Air traffic control Terminal and depot operations Performance evaluation Work-flow generation and analysis Reliability assessment Product planning Marketing analysis Research and development performance Construction activity planning Scheduling project activities Capital investment decision making Cash flow analysis Risk assessment Balance sheet projections Flood control Pollution control Energy flows and utilization Farm management Pest control Reactor maintainability Supply management Operating room scheduling Manpower planning Organ transplantation policy evaluation

Transportation systems

Computer and communication systems Project planning and control

Financial planning

Environmental and ecological studies

Health care systems

As an analysis tool to determine critical elements, components, and issues and to estimate performance measures As a design assessor to evaluate proposed solutions and to synthesize new alternative solutions As a scheduler to develop on-line operational schedules for jobs, tasks, and resources 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 decision support

Table 2.4 Primary Outputs for Use in Applications by Functional Level Functional Level Explanatory devices Communication vehicle Analysis tool Design assessor Scheduler Control mechanism Training tool Embedded system element Primary Outputs Animations Animations, plots, pie charts Tabulations, statistical estimators, statistical graphs Statistical estimators, summary statistics, ranking and selection procedures Tabular schedules, Gantt charts, resource plots Tabular outputs, animations, resource plots Animations, event traces, statistical estimators, summary statistics Status information, projections

Since simulation modeling can be used at each of these levels and across a wide spectrum of systems, many types of outputs and analysis capabilities are associated with simulation models. For any given level, any output capability could be used. In an attempt to bring focus to this issue, the high-level primary outputs associated with each of the levels are listed in Table 2.4. With regard to the different purposes for which models are used, the following principle is presented: Modeling Principle 6 A model should be evaluated according to its usefulness. From an 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 understanding, not models. Simulation modeling is performed to induce change. To achieve change, the results of 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 models and 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 highlight the significant questions on specialized simulation modeling efforts. Geoffrion [19, 20] has written several basic papers on the fundamentals of structured modeling. The impact of these efforts on modeling practice remains to be seen.

ACKNOWLEDGMENTS This material is based on work supported by the National Science Foundation under Grant DMS-8717799. The government has certain rights in this material. The author thanks the following persons for helping to improve this chapter by providing review comments: Barry Nelson of Northwestern University, Bob Schwab of Caterpillar Corporation, Bruce Schmeiser of Purdue University, and Steve Duket, Mary Grant, and Ken Musselman 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, Southwestern 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, Academic 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 Proceedings of 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 of the 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 on Integrated Modeling Systems, University of Texas, Austin, Texas, October.