- Shopping Bag ( 0 items )
Ships from: Midland, VA
Usually ships in 1-2 business days
This is a book about techniques for using computers to imitate, or simulate, the operations of various kinds of real-world facilities or processes. The facility or process of interest is usually called a system, and in order to study it scientifically we often have to make a set of assumptions about how it works. These assumptions, which usually take the form of mathematical or logical relationships, constitute a model that is used to try to gain some understanding of how the corresponding system behaves.
If the relationships that compose the model are simple enough, it may be possible to use mathematical methods (such as algebra, calculus, or probability theory) to obtain exact information on questions of interest; this is called an analytic solution. However, most real-world systems are too complex to allow realistic models to be evaluated analytically, and these models must be studied by means of simulation. In a simulation we use a computer to evaluate a model numerically, and data are gathered in order to estimate the desired true characteristics of the model.
As an example of the use of simulation, consider a manufacturing company that is contemplating building a large extension onto one of its plants but is not sure if the potential gain in productivity would justify the construction cost. It certainly mould not be cost-effective to build the extension and then remove it later if it does 'tot work out. However, a careful simulation study could shed some light on the question by simulating the operation of the plant as it currently exists and as it would be if the plant wereexpanded.
Application areas for simulation are numerous and diverse. Below is a list of some particular kinds of problems for which simulation has been found to be a useful and powerful tool:
Simulation is one of the most widely used operations-research and management science techniques, if not the most widely used. One indication of this is the Winter Simulation Conference, which attracts 600 to 700 people every year. In addition, there are several simulation vendor users' conferences with more than 100 participants per year.
There are also several surveys related to the use of operations-research techniques. For example, Lane, Mansour, and Harpell (1993) reported from a longitudinal study, spanning 1973 through 1988, that simulation was consistently ranked as one of the three most important "operations-research techniques." The other two were "math programming" (a catch-all term that includes many individual techniques such as linear programming, nonlinear programming, etc.) and "statistics" (which is not an operations-research technique per se). Gupta (1997) analyzed 1294 papers from the journal Interfaces (one of the leading journals dealing with applications of operations research) from 1970 through 1992, and found that simulation was second only to "math programming" among 13 techniques considered.
There have been, however, several impediments to even wider acceptance and usefulness of simulation. First, models used to study large-scale systems tend to be very complex, and writing computer programs to execute them can be an arduous task indeed. This task has been made much easier in recent years by the development of excellent software products that automatically provide many of the features needed to "program" a simulation model. A second problem with simulation of complex systems is that a large amount of computer time is sometimes required. However, this difficulty is becoming much less severe as computers become faster and cheaper. Finally, there appears to be an unfortunate impression that simulation is just an exercise in computer programming, albeit a complicated one. Consequently, many simulation "studies" have been composed of heuristic model building, coding, and a single run of the program to obtain "the answer." We fear that this attitude, which neglects the important issue of how a properly coded model should be used to make inferences about the system of interest, has doubtless led to erroneous conclusions being drawn from many simulation studies. These questions of simulation methodology, which are largely independent of the software and hardware used, form an integral part of the latter chapters of this book.
In the remainder of this chapter (as well as in Chap. 2) we discuss systems and models in considerably greater detail and then show how to write computer programs in general-purpose languages to simulate systems of varying degrees of complexity. All of the computer code shown in this chapter can be downloaded from http://www.mhhe.com/lawkelton.
A system is defined to be a collection of entities, e.g., people or machines, that act and interact together toward the accomplishment of some logical end. [This definition was proposed by Schmidt and Taylor (1970).] In practice, what is meant by "the system" depends on the objectives of a particular study. The collection of entities that comprise a system for one study might be only a subset of the overall system for another. For example, if one wants to study a bank to determine the number of tellers needed to provide adequate service for customers who want just to cash a check or make a savings deposit, the system can be defined to be that portion of the bank consisting of the tellers and the customers waiting in line or being served. If, on the other hand, the loan officer and the safety deposit boxes are to be included, the definition of the system must be expanded in an obvious way. [See also Fishman (1978, p. 3).] We define the state of a system to be that collection of variables necessary to describe a system at a particular time, relative to the objectives of a study. In a study of a bank, examples of possible state variables are the number of busy tellers, the number of customers in the bank, and the time of arrival of each customer in the bank.
We categorize systems to be of two types, discrete and continuous. A discrete system is one for which the state variables change instantaneously at separated points in time. A bank is an example of a discrete system, since state variablese.g., the number of customers in the bank-change only when a customer arrives or when a customer finishes being served and departs. A continuous system is one for which the state variables change continuously with respect to time. An airplane moving through the air is an example of a continuous system, since state variables such as position and velocity can change continuously with respect to time. Few systems in practice are wholly discrete or wholly continuous; but since one type of change predominates for most systems, it will usually be possible to classify a system as being either discrete or continuous.
At some point in the lives of most systems, there is a need to study them to try to gain some insight into the relationships among various components, or to predict performance under some new conditions being considered. Figure 1. 1 maps out different ways in which a system might be studied.
Experiment with the Actual System vs. Experiment with a Model of the System. If it is possible (and cost-effective) to alter the system physically and then let it operate under the new conditions, it is probably desirable to do so, for in this case there is no question about whether what we study is valid. However, it is rarely feasible to do this, because such an experiment would often be too costly or too disruptive to the system. For example, a bank may be contemplating reducing the number of tellers to decrease costs, but actually trying this could lead to long customer delays and alienation. More graphically, the "system" might not even exist, but we nevertheless want to study it in its various proposed alternative configurations to see how it should be built in the first place; examples of this situation might be a proposed communications network, or a strategic nuclear weapons system. For these reasons, it is usually necessary to build a model as a representation of the system and study it as a surrogate for the actual system. When using a model, there is always the question of whether it accurately reflects the system for the purposes of the decisions to be made; this question of model validity is taken up in detail in Chap. 5.1.
Physical Model vs. Mathematical Model. To most people, the word "model" evokes images of clay cars in wind tunnels, cockpits disconnected from their air-planes to be used in pilot training, or miniature supertankers scurrying about in a swimming pool. These are examples of physical models (also called iconic models), and are not typical of the kinds of models that are usually of interest in operations research and systems analysis. Occasionally, however, it has been found useful to build physical models to study engineering or management systems; examples include tabletop scale models of material-handling systems, and in at least one case a full-scale physical model of a fast-food restaurant inside a warehouse, complete with full-scale, real (and presumably hungry) humans [see Swart and Donno (1981)]. But the vast majority of models built for such purposes are mathematical, representing a system in terms of logical and quantitative relationships that are then manipulated and changed to see how the model reacts, and thus how the system would react-if the mathematical model is a valid one. Perhaps the simplest example of a mathematical model is the familiar relation d = rt, where r is the rate of travel, t is the time spent traveling, and d is the distance traveled. This might provide a valid model in one instance (e.g., a space probe to another planet after it has attained its flight velocity) but a very poor model for other purposes (e.g., rush-hour commuting on congested urban freeways).
Analytical Solution vs. Simulation. Once we have built a mathematical model, it must then be examined to see how it can be used to answer the questions of interest about the system it is supposed to represent. If the model is simple enough, it may be possible to work with its relationships and quantities to get an exact, analytical solution. In the d = rt example, if we know the distance to be traveled and the velocity, then we can work with the model to get t = d/r as the time that will be required. This is a very simple, closed-form solution obtainable with just paper and pencil, but some analytical solutions can become extraordinarily complex, requiring vast computing resources; inverting a large nonsparse matrix is a well-known example of a situation in which there is an analytical formula known in principle, but obtaining it numerically in a given instance is far from trivial. If an analytical solution to a mathematical model is available and is computationally efficient, it is usually desirable to study the model in this way rather than via a simulation. However, many systems are highly complex, so that valid mathematical models of them are themselves complex, precluding any possibility of an analytical solution. In this case, the model must be studied by means of simulation, i.e., numerically exercising the model for the inputs in question to see how they affect the output measures of performance....
|List of Symbols|
|Ch. 1||Basic Simulation Modeling||1|
|Ch. 2||Modeling Complex Systems||106|
|Ch. 3||Simulation Software||202|
|Ch. 4||Review of Basic Probability and Statistics||235|
|Ch. 5||Building Valid, Credible, and Appropriately Detailed Simulation Models||264|
|Ch. 6||Selecting Input Probability Distributions||292|
|Ch. 7||Random-Number Generators||402|
|Ch. 8||Generating Random Variates||437|
|Ch. 9||Output Data Analysis for a Single System||496|
|Ch. 10||Comparing Alternative System Configurations||553|
|Ch. 11||Variance-Reduction Techniques||581|
|Ch. 12||Experimental Design, Sensitivity Analysis, and Optimization||622|
|Ch. 13||Simulation of Manufacturing Systems||669|