Proceedings of the 1991 Winter Simulation Conference Barry L . Nelson, W. David Kelton, Gordon M . Clark (eds.)

PRINCIPLES OF MODELING

Chair A. Alan B. Pritsker

Pritsker Corporation P.O. Box 2413

West Lafayette, Indiana 47906

Panelists James 0. Henriksen

Paul A. Fishwick Gordon M. Clark

1 INTRODUCTION

The time has come for the simulation commu- nity to explore, or some would say re-examine, the fundamentals of modeling and models. By modeling is meant the process of building a model where a model is a description of a system. Most aspects of simulation activity involve modeling and models. Throughout the simulation community, there would be close to unanimous endorsement of the following state- ment by Simon (1990) “Modeling is a principal - perhaps the primary - tool 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.’’

ing as a principal tool, only a small amount of research is directed to identifying underlying principles, foundations, or fundamentals of modeling as related to simulation. This panel has been established t o promote a greater exploration of modeling principles. The panel has decided to be heroic and present their basic thoughts on modeling principles. In doing this, we decided not to be bogged down by questions relating to what constitutes a principle or to be concerned during this first panel with the formal definitions of modeling and model. Basically we are looking for directions through which we can establish modeling principles which are acceptable to the simulation commu- nity. We recognize that the current state of affairs is a chaotic one. Hopefully, by brain-

Even with unanimity of agreement on model-

storming in the panel through direct question- ing of each other and through audience partici- pation, a better understanding of what is meant by a modeling principle and how it should be presented or stated can evolve. Our criterion relating t o the value of a modeling principle is its acceptability to members of the simulation community.

member of the panel present “principles” and give brief discussions and/or justifications for each principle. A principle can be a guideline, an orientation, or a fundamental characteristic associated with modeling and models. Audience empowerment is envisioned through invitations to be members of future panels on principles of modeling if they are thought to be necessary (probably deemed to be so a priori) and thought to be useful (which may not be as easy to evalu- ate). The panel starts with a clean slate and the assumption that there are no established, published principles of modeling. I t is assumed that all modeling principles presented have been developed based on the panelists experi- ence and interaction with colleagues. A naming convention (panelist’s initials and number) in this paper is employed for ease of reference during the panel.

The form used for this paper is to have each

2 PRINCIE”S SUGGESTED BY P-R

2.1 Basic Principles

Modeling Principle AP1 Conceptualizing a model requires system knowledge, engineering judgement and model-building tools.

1199

1200 Pritsker (chair), Henriksen, Fishwick and Clark

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 t o 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 interdisci- plinary 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 that interactions induce confidence in both the modeler and the decision maker and help to achieve a successful imple- mentation of results.

structural components of the system and prod- uct (object) flows through the system, a good understanding of the detailed data require- ments can be projected. From the structural components, the schedules, algorithms and controls required for the model can be deter- mined. These decision components are typically the most difficult aspect of a modeling effort.

By conceptualizing the model in terms of the

Modeling Principle AP2 The secret to being a good modeler is recognizing the need and having the ability to remodel.

Model building should be interactive and graphical because a model is not only defined and developed but is continually refined, up- dated, 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 fea- sible:

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; and

5. leave hooks in the model to insert exten- sions 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, samples from a theoretical distribution, or derived from a file;

2. setting due dates based on historical records, manufacturing resource planning (MRPII) procedures , or sales information; setting decision variables based on a heuristic procedure or calling a decision- making subprogram that uses an optimi- zation technique; and

4. including fixed rules or expert-system using rules directly in the model.

3.

Modeling Principle AP3 The modeling process is evolutionary because the act of model- ing 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 leads to a further evolu- tion 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. Principle AP3 differs from Principle AP2 as it relates to the modeling process not just the model.

Principles of Modeling 1201

2.2 Model-based Problem Solving

Modeling Principle Ap4 The problem or problem statement is the primary controlling element in model-based problem solving.

A problem or objective drives the develop- ment of the model. Problem statements are defined from system needs and requirements. Data from the system is the input to the model. Its availability and form help to specify the model boundaries and details. The modeler is the resource that is 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 estab- lished rules and procedures. Figure AP1 pre- sents the components in the problem solving environment when models are used to support the making of decisions or the setting of policies.

Problem

I Model versions

System , Data

Decisions

Policies

t Modeler

Figure AP1: Model-based Problem Solving Process

Modeling Principle AP5 In modeling com- bined systems, the continuous aspects of the problem should be considered first. The discrete aspects of the model-including events, net- works, algorithms, control procedures and advanced logic capabilities-should then be developed. The interfaces between discrete and continuous variables should then be approached.

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 simu- lated by computing the values of the state variables a t small time steps and by computing the values of attributes of entities and global variables a t event times.

There are three fundamental interactions that can occur between discretely and continu- ously 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 2 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 is in the vicinity of the crane.

These principles describe a convenient initial approach to the combined modeling of a system. Modeling Principle AP2 applies to combined modeling so that any initial order to the model- ing sequence will be superceded. Modeling Principle AP5 may be a corollary to a broader modeling principle which prescribes that the structural elements of a system be modeled first with the procedural aspects of system perfor- mance modeled subsequently.

2.3 Simulation Model Purpose

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

The purpose for modeling can be viewed a t a functional level. The functional levels to which modeling has been applied are:

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 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;

1202 Pritsker (chair), Henriksen, Fishwick and Clark

as a control mechanism for the distribution and routing of materials and resources; and as a training tool t o assist operators in understanding system operations.

Since 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 models especially when simulation is used as the analysis mechanism.

It is from this global perspective that a model should be evaluated, not from a specific mar- ginal return basis. Projects should be evaluated on a “return” or ROI criterion. For models, there is a need to establish classification schemes and measures of model complexity as well as algorithm computational complexities.

Modeling Principle AP7. The purpose of modeling is knowledge and understanding, not models.

Although this principle seems trite, it is necessary to state because nonadherence to the principle has been a pitfall associated with the fields of industrial engineering, operations research, management science, decision science, computer science and statistics.

3 pRl[NcIpL;ES SUGGESTED BY “ R J K S E N

Modeling Principle JH1 Generality of understanding comes at the end of a modeling project; structure your modeling approach and modeling environment accordingly.

(This principle encompasses some of the ideas in Pritsker’s principles AP2, AP3, and AP4). The purpose of building a model is to study the operation of a system. At the outset of a model- ing project, one generally has a good idea of what system components, resources, algorithms, and strategies are most important to successful operation of the system. Furthermore, one generally has a good idea of what measurements will yield insights into these critical areas. However, all non-trivial models yield surprises and unanticipated insights. If one had these insights to begin with, building a model would be unnecessary. In the process of solving a problem, one learns what the problem really is.

Any modeling approach which fails t o take this fundamental aspect of modeling into account is doomed to fail. A successful modeling approach must have many built-in feedback

loops, allowing modeling assumptions, input data, performance measures (outputs), system configuration, and system operation strategies to be easily modified as suggested by discoveries in the modeling process.

Modeling Principle JH!Z Know when to model “top-down” and when to model “bottom-up.”

These days, suggesting the existence of appropriate circumstances for “bottom-up” approaches in any computer-related task may be regarded by some as tantamount to heresy. In general, we are predisposed to believe that “top-down” is equivalent to “good. My own feelings in this regard are biased by many years experience as a systems programmer. When I build a large piece of software, I know that it is important to build some system components as soon as possible, even when 1 know that I can’t build them “right.” For example, if I’m building a menu-based system, the contents of the menus and how the menus relate t o one another are initially far more important than pretty appear- ance and smoothness of operation of the under- lying menuing software. After I’ve experi- mented with my system, I can fine-tune the menu mechanism. If I place too much impor- tance on the menu mechanism too early in the project, 1’11 end up spending a lot of time build- ing something that I’ll have to change any way.

I think that modeling should be approached in the same vein. Model components that will be heavily exercised and that are likely to be modified should be implemented as early as possible in the modeling process.

Modeling Principle JH3 It’s important to learn modeling techniques, but more important to learn to consider the tradeoffs among alterna- r2.ue techniques..

When one learns algebra, one must master a collection of rules, such as “adding the same value to both sides of an equation preserves equality.” The hope is that when the student is presented with the equation ‘X - 7 = 12,” (s)he will know enough t o add 7 t o both sides of the equation, thereby showing that ‘X = 19.” On the other hand, if the student adds a value of 1 t o both sides of the equation, an alpebraically sorrect ration, showing that “X - 6 = 13” is hardly what we’re after.

tradeoffs that should be considered in a modeling In [Henriksen 19891, I discussed a number of

Principles of Modeling

project: active vs. passive world-views, time domain vs. state domain, macroscopic vs. microscopic focus, toy models vs. real models, detailed models vs. abstract models, variants and invariants, implicit vs. explicit representa- tions, etc. Each of these tradeoffs is potentially critical to the success of a modeling project. However, before one can consider the tradeoff between two alternative approaches, one must know what the approaches are.

4 PRINCIPLES SUGGESTED BY FISHWICK

Modeling Principle PF1 Models are associ- ated with a set of questions.

One can take a mathematical model of a system and associate it with the set of questions that are answered by using that model. For instance, if a barbershop is modeled as a queue- ing system, then a queueing model is associated with a set of questions represented by “HOW fast does the barber cut hair?”, “What is the average customer waiting time?” and “What are the peak hours on an average day? The idea of models relating t o a set of questions relates to Pritsker’s discussion of the problem statement (AP4 and AP6). Now, let’s consider a different type of question - “HOW much hair falls on the floor in an hour?” Clearly, the queueing model, by itself, is not sufficient to answer this question. Therefore this new question must be associated with another model that we have not yet cre- ated. We can create a difference equation model to model amount of hair cut over time; then, we will have the use of two models (queueing and difference) to answer a larger set of potential questions. Ultimately, we would like t o build a black box shown in Figure PF1. A question (Q) to be answered is taken as input into the box, and the model (M) necessary to answer that question is produced as output. Unfortunately for us, no one has built these black boxes; however, the construction of such a box is possible and can be facilitated with the use of expert system tools. In such a system, we can have rules such as:

If the question relates to : speed of barber or customers then use QUEUEING- MODEL-3. If the question relates to:. amount of hair then use DIFFERENCE-MODEL-24.

0-2 DiHerence Model P-i: Pebi N e W k

Set of an possible quesbns

Whal is he rate ol

I

1203

! !ELQM.3

Figure PF1 The Simulationist’s Q/M Black Box

With respect to the model name suffixes, one must consider that there are many queues in the barbershop system that may be of interest - such as a FCFS queue for the electric trimmer if there are many barbers and only one trimmer. The same is true of the difference model - there may be other difference models that reflect loss of mustache hair or amount of money in the barber’s drawer.

Modeling Principle PF2 Multiple modeling paradigms will be required for a universal modeling language.

In principle PF1, we advocated the need for different models depending (1) on the problem to be solved (i.e. problem statement), and (2) the class of questions that need to be answered. This suggests that our current method of modeling - that is, relying on one modeling paradigm - is somewhat deficient. This defi- ciency is more clearly shown with an example of resource allocation. Consider a resource such as a lathe. The lathe may be “used” or requested by many different parts, and the operation of the lathe depends on the dimensions of the part and the type of cuts t o be performed. It may be appropriate to use a Petri net to model the resource allocation, and a set of differential equations to model the lathe’s dynamics. Imme- diately, we see a need to use two different modeling techniques. Sometimes it is possible to use a universal language for both models, although it is more precise to use the appropri- ate modeling method at the appropriate level. What is needed in this case is a good way of forming a bridge between Petri nets and differ- ential equation-based modeling methods.

1204 Pritsker (chair), Henriksen, Fishwick and Clark

Models are no longer to be considered single entities, but rather full-fledged structures representing networks or model ‘bases” contain- ing different models and specific ways of trans- lating between models during any point within the simulation.

Modeling Principle PF3 Models are not simply repositories of a system’s dynamics; models help us reason about systems.

Ultimately, we want our models to be well defined so that models can be validated and reflect real system behavior. This sometimes leads us to shun graphical approaches to simu- lation modeling in favor of more rigorous repre- sentations. This tendency toward formal repre- sentation misses an important point - we create models as a language so that we can converse with one another about dynamic systems. If I want to talk to you about manufacturing floor assembly line dynamics, I can do so by drawing circles (for resources) and arcs (for transport) on a blackboard. The circles and arcs do not contain the lowest possible level of semantics for modeling, but that does not demean their utility. We understand the ultimate necessity for attaching a detailed algorithm to represent what the circles and arcs represent. Jus t as we use natural language and not mathematical symbols to communicate our intentions, we must use whatever modeling methods that promote effective communication about dynami- cal systems.

Modeling Principle PF4 Closed-form evalua- tions are integrated aspects of computer simulation.

It is traditional to differentiate iterative evaluative methods (as “simulation”) and “static” methods that provide direct solutions in the form of algebraic equations parameterized by time. This is a very narrow view of simula- tion. Let me try to defend this somewhat radical perspective. Computer simulation modeling aims to create models of time-depen- dent behavior. Our purpose, as simulationists, is to study complex systems over time. The temporal element, therefore, is central to simulation; that is, simulation concerns itself with time-dependency. Now, suppose that I choose a differential equation model that has a direct solution. This solution is of an equational form where state variables are expressed as functions of time. Since simulation is concerned

with time dependent behavior, we can use these equations by incrementing time and determin- ing state variables. The fact that we are not performing numerical integration should not be a reason to describe our modeling as a “non- simulation.’’ So, why do we have the distinction of simulation vs. analytic method? For the most part simulation has usually been associated with the computer whereas direct methods have been associated with human activity - therein lies the difference. With the onslaught of effec- tive computer methods for symbolic manipulation, though, we see less of a need to artificially sepa- rate “simulation” fiom“direct analysis.” Effective symbolic manipulation requires lots of computer memory and pointer manipulation; however, the necessary speeds are now available on scientific workstations. Computer technology has made it possible to run large symbolic programs in conjunction with the “smaller” simulation soR- ware. Most future simulations will include embedded calls to symbolic manipulation soft- ware (such as Maple, Mathematica, Macsyma or Reduce). A simulation will first check for a direct solution prior to automatically assuming an iterative one. Both methods (direct and iterative) will lead to the same end result: a simulation of a process over time.

5 PRINCIPLES SUGGESTED BY CLARK

Modeling Principle GC1 All models are abstractions of reality.

A simulation modeler must recognize that the simulation model, regardless of its level of detail, is not reality. Sometimes a simulation project assumes a life of its own in that the detail and physical significance of the processes represented give a realistic appearance to the model. The modeler may take pride in incorpo- rating many complex processes in the model in order to give i t credibility and gain acceptance. Taken to an extreme, the model may become cumbersome and difficult to use. If the modeler and decision makers recognize that the model will never exactly represent reality, they may take a more cautious attitude towards adding model detail. For example, adding logic to represent lunch and personal breaks to a manufacturing system model may give a realis- tic appearance t o the model, but the model still will only be an imperfect representation of those processes that are quantifiable.

Principles of Modeling 1205

Modeling Principle GC2 Simpler models are easier to analyze in a timely and comperehensive manner.

Simpler models represent fewer interacting processes; thus, they are usually easier t o construct. Moreover, simpler models have lower computer execution times and fewer input parameters to relate to model outputs. Most likely, a simulation model with several hundred input parameters will never be analyzed in a comprehensive manner.

Modeling Principle GC3 Doubt may exist as to whether inclusion of a process in a model will effect the results.

A modeler may decide to omit a process from a model because of the judgement that process will not materially effect the conclusions from the simulation study. For example, a model of a supermarket checkout operation may omit the process of lane hopping by customers based on the judgement that lane hopping will not effect the mean wait time. Until one compares results with lane hopping with results without lane hopping, one is uncertain as t o the effect of lane hopping. Possibly experience with other models may help. However, how transferable is this experience? Also, what if in the later stages of the study, the decision maker asks for the probability that a customer will wait more than five minutes as a performance measure?

Modeling Principle GC4 The modeler should consider the use and construction of two models: a detailed and a simplified (rough cut) model.

A simplified model has two principal advantages:

Permits rapid examination of alternatives and subsequent elimination of weaker alternatives More readily reveals basic relationships among input parameters and output performance measures.

However, the simplified model may lack cred- ibility and may give less accurate predictions of output performance measure values. One may use the detailed simulation model to compare the most competitive alternatives and estimate the magnitude of errors in the simplified model. The simplified model may be (but not necessar- ily) an analytic model. A rough cut model that students in simulation classes have found useful

is the calculation of average server utilizations in steady state queueing networks from simula- tion input data. High utilizations indicate bottlenecks, and utilizations greater than 1.0 are impossible.

Modeling Principle GC5 Comparisons with a detailed simulation model do not validate a model in a scientific sense.

Since a detailed simulation model, regardless of how realistic i t appears, is not reality, i t is not necessarily a standard for scientific (empirical) verification. Comparisons with a detailed simulation model may indicate the effect on outputs of differences in assumptions about reality.

Modeling Principle GC6 Prepare a simulation requirements specification prior to developing the model.

The simulation requirements specification documents the following:

Description of the system to'be represented Specify the scope of the system - Describe principal operating features of the system

Purpose of the simulation model - List the questions motivating the use of the model

Describe and list the model output performance measures Describe and list the model input data Describe the principal simulation entities (the model static structure)

List and define the attributes for each entity

The requirements specification stops short of specifying how the model is to be programmed, but i t specifies what the model is to do. Having a clear picture of model requirements prior to programming the model will save effort and permit the development of a more understand- able model structure. This is particularly important when more than one individual participates in the model development.

Model Principle GC7 Solicit inputs from the decision makersf customers of the model for the requirements specification.

The requirements specification guides the simulation development effort, and the process

1206 Pritsker (chair), Henriksen, Fishwick and Clark

of openly soliciting requirements from the "customers" of the simulation project aids in gaining acceptance of the recommendations resulting from the simulation effort. These customers often have more domain knowledge concerning the system t o be represented and the decision to be influenced by the model than the modeler.

Model Principle GCS Obtain concurrence with respect to the requirements specification by the decision makers1 customers of the simulation project.

This concurrence among all parties with respect to the requirements specification should occur prior to developing the model. Without this concurrence, problems are simply deferred until a later time. Disagreement about the assump-tions inherent in the model may prevent adoption of recommendations from the simulation project.

Model Principle GC9 Tradeoffs may exist between use of random variables and additional input data.

We use random variables in a model to repre- sent outcomes that are not predictable in a deterministic sense from available information. Clearly the time to perform an operation by a human being may be described as a random variable because of its unpredictability. However, consider the times to perform an operation by a numerically controlled machine that is capable of operating on diverse types of jobs. If one knows the particulars concerning each job, the operation time may be predictable. Thus, the modeler has the options of compiling a detailed list of job sequences and times or using a probability distribution to determine the operation times. In a Computer Integrated Manufacturing environ- ment this sequence of operation times may be part of an existing database. However, one might ask whether this historical sequence of jobs is an appropriate scenario to influence decisions concerning future operations. Analyses of exist- ing data may indicate other options for replacing random variables with added inputs. For ex- ample, one might discover that human-paced operations are sensitive to the time of day. The variance of operation times given the fact that the current time is the first hour of a shift may be much smaller than the variance without knowl- edge of the time of the day.

6 RELATED MODELING RESEARCH

Research on modeling is extremely difficult. Included in the bibliography are books and papers on modeling. Basic research on under- standing models and the modeling process are reported by Polya, Wymore and Zeigler. Henriksen and Pritsker have presented papers at Winter Simulation Conferences that high- light the significant questions on specialized simulation modeling topics. Recently, Geoffrion has written several basic papers on the funda- mentals of structured modeling. These efforts need to be considered in developing principles that are useful for modeling practice.

ACKNOWLEDGEMENTS

Pritsker's material is based on work sup- ported by the National Science Foundation under Grant No. DMS-8717799. The govern- ment has certain rights in this material. Pritsker thanks the following individuals for their suggestions: Barry Nelson of The Ohio State University, Bob Schwab of Caterpillar Corporation, Bruce Schmeiser of Purdue Uni- versity, Professor Susumu Morito of Waseda University, Ilario Astinov of the Technical University of Sofia and Steve Duket, Ken Musselman and Dave Yancey of Pritsker Corpo- ration.

Fishwick is grateful for partial funding of this research through a grant from the National Science Foundation IRI-8909 152.

REFERENCES

Beaumariage, T., J. H. Mize and C. Karacal. 1990. Developments in Systems Modeling Offer Opportunities and Challenges t o Industrial Engineers. In Proceedings of the 1990 International Industrial Engineering Conference, 28-32. Institute of Industrial Engineers, San Francisco, California.

Bender, E. A. 1978. A n Introduction to Math- ematical Modeling. New York: John Wiley.

Emshoff, J . R. andR. L. Sisson. 1970. Design and Use of Computer Simulation Models. Riverside, New Jersey: Macmillan.

Fishwick, P. A. 1989. Abstraction Level Tra- versal in Hierarchical Modeling. In Model- ling and Simulation Methodology: Knowl- edge Systems' Paradigms, eds. B. P. Zeigler, M. Elzas, and T. Oren, 393-429. New York: Elsevier North Holland.

Principles of Modeling 1207

Fishwick, P. A 1988. The Role of Process Ab- straction in Simulation. IEEE Transactions on Systems, Man and Cybernetics 18: 18-39.

Fishwick, P. A 1990. Toward an Integrated Approach to Simulation Model Engineering. International Journal of General Systems 17: 1-20.

Fishwick, P. A. and B. P. Zeigler. 1991. A Homogeneous and Heterogeneous Refinement Method for Combined Model Engineering. Submitted to ACM Transactions on Modeling and Computer Simulation.

Structured Modeling. Management Science Geoffrion, A. M. 1987. An Introduction to

33: 547-588. Geoffrion, A. M. 1986. Integrated Modeling

Systems. In Proceedings of the Conference on Integrated Modeling Systems, University of Texas, Austin, Texas.

Clock: Studies in Problem Solving. In Pro- ceedings of the Winter Simulation Conference, eds. J. R. Wilson, J. 0. Henriksen, and S. D. Roberts, 713-726. Washington, D. C.

ing of Preemptive Scheduling. In the Proceed- ings of the Winter Simulation Conference, eds. A. Thesen, H. Grant and W. D. Kelton, 575- 581. Atlanta, Georgia.

Henriksen, J. 0. 1988. One System, Several Perspectives, Many Models. In the Proceed- ings of the Winter Simulation Conference, eds. M. A. Abrams, P. L. Haigh and J. C. Comfort, 352-356. San Diego, California

Perspectives: Finding the Creative Spark. In the Proceeding of the Winter Simulation Conference, eds. E. A. MacNair, K J. Musselman and P. Heidelberger, 648-652. Washington, D.C.

Selection. New York: John Wiley.

Edition. Princeton, New Jersey: Princeton University Press.

Perspectives . West Lafayette, Indiana: Systems Publishing Corporation.

Rotary Index Table Case History. In the Proceedings of the Winter Simulation Confer- ence, eds. J. R. Wilson, J. 0. Henriksen, and S. D. Roberts, 703-707. Washington, D. C.

FMS Design Problem. In the Proceedings of

Henriksen, J. 0. 1986. You Can't Beat the

Henriksen, J.O. 1987. Alternatives for Model-

Henriksen, J. 0. 1989. Alternative Modeling

Linhart, H. and W. Zucchini. 1986. Model

Polya, G. 1973. How To Solve It , Second

Pritsker, A. A. B. 1990. Papers Experiences

Pritsker, A. A. B. 1986. Model Evolution: A

Pritsker, A. A. B. 1987. Model Evolution 11: An

the Winter Simulation Conference, eds. A. Thesen, H. Grant and W. D. Kelton, 567-574. Atlanta, Georgia.

Pritsker, A. A. B. 1988. Modeling Viewpoints for Assessing Reliability. In the Proceedings of the Winter Simulation Conference, eds. M. A. Abrams, P. L. Haigh and J. C. Comfort, 344-351. San Diego, California

Pritsker, A. A. B. 1989. Developing Analytic Models Based on Simulation Results. In the Proceeding of the Winter Simulation Conference, eds. E. A. MacNair, K J. Musselman and P. Heidelberger, 653-660. Washington, D.C.

Pritsker, A. A. B., C. E. Sigal, and R. D. J. Hammesfahr. 1989. SLAM II Network Models for Decision SupRort. Englewood Cliffs, New Jersey: Prentice Hall.

Rivett, P. 1980. Model Building for Decision Analysis. New York: John Wiley.

Simon, H. A. 1990. Prediction and Prescription in Systems Modeling. Operations Research,

Wymore, A. W. 1976. A Mathematical Theory of Modelling and Simulation. New York: John Wiley.

Ziegler, B. P. 1976. Theory of Modelling and Simulation. New York: John Wiley.

Ziegler, B. P. 1984. Multi-facetted Modelling and Discrete Event Simulation. Palisades, New York: Academic Press.

Ziegler, B. P, 1990. Object-oriented Simulation with Hierarchical, Modular Models. Pali- sades, New York: Academic Press.

38: 7-14.

AUTHOR BIOGRAPHIES

A. ALAN B. PRITSKER is President and CEO of Pritsker Corporation. He graduated from Columbia University with a BSEE and MSIE. He obtained a Ph.D. from The Ohio State University in 1961. Dr. Pritsker has worked for Battelle Memorial Institute, Arizona State University, Virginia Tech, and Purdue Univer- sity. He has published more than 100 technical papers and nine books. He is a Fellow of AIIE and recipient of AIIEs Distinguished Research Award, Innovative Achievement Award and the Gilbreth Award. He is a member of the Na- tional Academy of Engineering. Dr. Pritsker served as a member of the Board of Directors of the Winter Simulation Conference from 1970 to 1974 and 1980 to 1987, and as Board Chairman in 1984 and 1985.

1208 Pritsker (chair), Henriksen, Fishwick and Clark

JAMES 0. HENRlKSEN is the president of Wolverine Software Corporation located in Annandale, Virginia (a suburb of Washington, D.C.) He is a frequent contributor to the litera- ture on simulation and has presented many papers at the Winter Simulation Conference. He served as the Business Chairman of the 1981 Winter Simulation Conference and has served on the Board of Directors of the conference as the ACM representative.

PAUL A. FISHWICK is an Assistant Professor in the Department of Computer and Information Sciences at the University of Florida. He received the BS in Mathematics from the Pennsylvania State University, MS in Applied Science from the College of William and Mary, and PhD in Computer and Information Science from the University of Pennsylvania in 1986. He also has six years of industriaVgovernment production and research experience working a t Newport News Shipbuilding and Dry Dock Co. (doing CADICAM parts definition research) and at NASA Langley Research Center (studying engineering database models for structural engineering). His research interests are in computer simulation modeling and analysis methods for complex systems. He is a member of IEEE, IEEE Society for Systems, Man and Cybernetics, IEEE Computer Society, The Society for Computer Simulation, AGM and AAAI. Dr. Fishwick was chairman of the IEEE Computer Society Technical Committee on Simulation (TCSIM) for two years (1988-1990) and he is on the editorial boards of several journals inlcuding the ACM Transactions on Modeling and Computer Simulation, The Trans- actions of the Society for Computer Simulation, International Journal of Computer Simulation, and the Journal of Systems Engineering.

GORDON M. CLARK is a professor of Indus- trial and Systems Engineering at the Ohio State University. During the 1988189 academic year he was on sabbatical with the IBM Corporation in their Application Systems Division. He received the B.I.E. degree in Industrial Engi- neering from The Ohio State University in 1957, a M.Sc. in Industrial Engineering from the University of Southern California, and a Ph.D. fromThe Ohio State University in 1969. He was responsible for the development of several combat simulations a t The Ohio State Univer-

sity while under contract with the U.S. Army (1965-1974). He was Associate Editor of Opera- tions Research (1975-19781, and a member of the Board of Directors of the Military Operations Research Society (1972-1976). He has consulted in the areas of simulation modeling and analysis and manufacturing systems for industrial companies and Battelle Memorial Institute. His research interests include simulation optimiza- tion, applications in manufacturing systems, and approximations to nonstationary queueing systems. He is a member of ORSA, TIMS, IIE, SCS, and SIGMA XI.