Simulation Using gpss/H
Yüklə 83,97 Kb. Pdf görüntüsü
|
- Bu səhifədəki naviqasiya:
- 2.1 GPSS/H Process Representation
- 3 GRAPHICAL MODELING — GOOD AND BAD
- 3.1 Developing and Editing Models
- 3.2 What Defines an Easy-to-Use Simulation Tool
- 4 IMPORTANT FEATURES OF GPSS/H
- 4.1 GPSS/H File and Screen I/O
- 4.2 Scripting Language for Experiment Control
- 4.3 Statistically Robust Random-Number Streams
- 4.4 Validation and Debugging
- 5 FEATURES OF GPSS/H RELEASE 3
- 6 BUILDING A SIMULATOR USING GPSS/H
- 6.1 Data-Entry Front End
- Programs Text Files Batch File Executable
- 6.5 Run-Time Versions Provide an Economical Simulation Engine
- AUTHOR BIOGRAPHY ROBERT C. CRAIN
| SIMULATION USING GPSS/H Robert C. Crain Wolverine Software Corporation 7617 Little River Turnpike, Suite 900 Annandale, Virginia 22003-2603, U.S.A.
GPSS/H is a tried-and-true simulation tool whose user base, both commercial and academic, continues to grow despite the presence of many “new” simulation technology trends. The process-interaction world view combines with the advanced features available in GPSS/H to make one of the most powerful and flexible tools available, capable of handling the largest simulation projects with ease, yet still providing exceptionally high performance. The following sections provide an overview of GPSS/H and its process-interaction world view, a discussion of model-building interfaces including the advantages and pitfalls of graphical modeling environments, and a summary of advanced and recently- added GPSS/H features. Finally, the special-purpose simulator is discussed, along with features of GPSS/H which make it ideal for use as the engine in such a simulator.
The widespread success of GPSS/H stems both from the superiority of its original design and from years of improvements and enhancements. GPSS/H requires some programming-style effort, but does so within a natural modeling framework that can be readily used without extensive programming experience. It is equally well suited for modeling simple systems and for modeling large, complex systems. Although many new simulation tools have been introduced over the past decade, they are often designed for a limited set of applications. In strong contrast, GPSS/H continues to be one of the most general,
available. GPSS/H is presently applied worldwide to model manufacturing, transportation, distribution, telecommunications, hospitals, computers, logistics, mining, and many other types of queuing systems.
GPSS/H is a discrete-event simulation language. As is true with most languages, models are developed with an editor and saved in text files. With GPSS/H, the text files are subsequently compiled directly into memory and executed. Rapid prototyping and iterative model development are encouraged by exceptionally fast compilation and execution. GPSS/H uses the intuitive and natural process-
the sequence of events, separated by lapses in time, which describes the manner in which “objects” flow through a system. A GPSS/H model thus resembles the structure of a flowchart of the system being modeled. This intuitive modeling approach contributes greatly to the ease and speed with which simulation models can be built.
After the model has been built, the process representation is executed by GPSS/H, and the activities of “objects” are automatically controlled and monitored.
An “object” in a GPSS/H model might be a patient, a telephone call, or any other type of discrete entity. The representations of these entities in GPSS/H are called transactions. As the model executes, many transactions may be flowing through the model simultaneously—just as many “objects” would be moving through the real- world system being modeled. In addition, multiple transactions can execute GPSS/H model statements at the same instant in (simulated) time without any special action required of the modeler. The execution of a process-interaction simulation model is thus similar to a multi-threaded computer program. This differs greatly from the single-threaded, sequential execution of most general-purpose programming languages. Many simulation projects focus on the use of system resources such as people, machines, conveyors, computers, physical space, and so on. In a GPSS/H Proceedings of the 1997 Winter Simulation Conference ed. S. Andradóttir, K. J. Healy, D. H. Withers, and B. L. Nelson 567
simulation model, transactions (“objects”) compete for the use of these system resources; as transactions flow through the process representation, they automatically queue up when unable to gain control of a necessary resource. The modeler does not need to specify the transaction’s waiting time or its queuing behavior. Hence, the passage of time in a GPSS/H model can be represented implicitly, as in the case of a part waiting for a machine to be free, or explicitly, as in the case of a part being processed by a machine. Like most real-world systems, a GPSS/H model may consist of multiple processes operating simultaneously. Furthermore, each process may in some way affect the other processes in the system. For example, two parallel manufacturing processes may converge to a single inspection point where they are competing for a single resource—the inspector. GPSS/H provides the capability for multiple parallel processes to interact with each other automatically. Transactions (“objects”) may be sent between processes; they may control or share common resources; or they may influence the (global) operation of all processes. 3 GRAPHICAL MODELING — GOOD AND BAD Often, the power and ease-of-use of a simulation environment are confused with the model-building interface provided by the tool. That interface may be comprised of menus and data forms, or—as with GPSS/H—it may consist of text entry, or it may be a combination of the two. One current approach in simulation is to try to build models visually. Icons are placed on the computer screen to represent system components, and then the operating characteristics of each component are specified by moving through a series of menus and data forms. One inherent advantage of this approach is that even novices can build simple models quickly—although not necessarily accurately. Building models of complicated systems, however, requires more than simply placing icons on the screen. To model many processes, a limited programming environment must be provided. For example, a part routing based on a time-dependent math equation cannot be represented visually. As a result, models of complex (real world) systems built using the visual approach often require the modeler to create substantial amounts of programming code in addition to the visual representation.
Graphical modeling tools can force their users to make the model fit within a rigid framework bounded by the available menus and forms. The advantage of such a rigid framework is that it tends to steer even a beginning modeler through the model-building process. The disadvantage is that the framework may not be versatile enough to accurately model complicated systems. For an excellent discussion of this point, see Banks and Gibson (1997).
Additionally, large visual models can become very cumbersome to view, edit, and document. Large models can be comprised of many “screens” of icons, many of them with associated program code reachable only by going through multiple levels of menus. Editing—or even just browsing—these models forces the user to navigate through a labyrinth of icons, menus, click- buttons, data fields, and code segments. 3.2 What Defines an Easy-to-Use Simulation Tool? A tool’s ease-of-use cannot be evaluated meaningfully based on the presence or absence of a single characteristic. Whether a tool is “easy-to-use” is deter- mined by the combination of general characteristics and specific features that are frequently used in model development. Simulation software should be selected based on how well it is suited to the detail and complexity of the specific type of model to be developed. The ease-of-use associated with a simulation tool can mean—among other things—that it is easy to learn, easy to use repetitively, easy to use when modifying models, easy to use when building simple models, or easy to use when building large, complex models. Tools that are claimed to be “easy-to-use” often fall short when modeling complex, real-world systems. Graphical model building, often touted as a breakthrough in ease-of-use, springs from attempts to apply to simulation recent trends in the design of computer interfaces used primarily for word-processing, spreadsheets, database access, and the like. Although a graphical user interface is well suited for many kinds of tasks, it is not always practical for developing simulation models—especially in circumstances where programming is necessary to define the operations of complex processes. There is a point at which a graphical environment can present its user with more barriers than advantages. For example, proponents of graphical modeling techniques frequently claim shorter model development time, but this is primarily because users of graphical tools tend to build simpler models. As was discussed in section 3.1, creating and editing complex models with graphical tools can require more time than creating and editing such models in a text-based environment. 568 Crain
4 IMPORTANT FEATURES OF GPSS/H Several unique characteristics make Wolverine’s GPSS/H an excellent choice for a general simulation environment. A key feature of GPSS/H is the conceptual flexibility to model a wide range of different types of systems: any system that can be described as a process flow, with objects and resources acting upon each other, can be modeled. This may include people on a mass transit system, tasks in an office environment, or data flow within a computer network. Definition flexibility is also provided within the language: complex math formulas, expressions, and constants can be used virtually anywhere in the model. To promote model readability, elements and entities may be specified by names instead of numbers. Basic simulation output data, such as queuing and service statistics, are automatically provided without any programming, which greatly aids incremental model development. GPSS/H is available for PCs and SUN SPARC workstations. On the PC, GPSS/H Professional runs as a true 32-bit application under Windows 3.x, Windows 95, Windows NT, OS/2, or even plain DOS, providing tremendous speed as well as model size that is limited only by the computer’s available memory. Running under Windows, OS/2, and Unix, GPSS/H uses virtual memory, which allows model size to exceed the amount of physical memory (RAM) installed in the machine. 4.1 GPSS/H File and Screen I/O The file and screen I/O built into GPSS/H provide a variety of ways to get data into a model and to produce custom output. GPSS/H can read directly from the keyboard or from text files, and it can write directly to the screen or to text files. The GETLIST statement and the BGETLIST block read integer, character, and double-precision floating-point data. Input data files are free-format (values on each line are simply separated by blanks), and special actions may be specified for error and end-of-file conditions. Customized output is generated using the PUTPIC statement and the BPUTPIC block. These use a very intuitive “picture” type of format specification, which follows the “what you see is what you get” convention. Special provisions are included to allow easily formatted tabular output. Character strings can also be manipulated using built-in capabilities. 4.2 Scripting Language for Experiment Control The results produced by a single run of a simulation model can only provide single estimates of random variables that may be subject to wide variations. Careful experimental design, using multiple runs, is essential to accurately predict the behavior of the model outputs. GPSS/H provides the tools to build a complete experimental framework. A complete scripting language is available to construct experiments and control model execution. Experiments can be automated with DO loops and IF- THEN-ELSE structures. Statistics collection may be totally or selectively reset, and/or data values assigned, both during a model run and before or after each run in a series of runs. The experimental specifications and parameters, like any other model data, can be read in from a data file or from the keyboard if desired.
The need to provide multiple independent streams of random numbers for use in different parts of the model (or in the same parts for different runs) is very important, particularly after a model is largely complete and the modeler is concentrating on validation and the running of experiments. The indexed Lehmer random number generator provided in GPSS/H was designed and implemented specifically to provide exceptionally simple, straightforward control of the random number streams used in a model. Modelers can easily specify any number of streams and guarantee that they will be independent (that they will not be autocorrelated due to overlap). GPSS/H also automatically detects any accidental overlap, providing an extra measure of protection to users. 4.4 Validation and Debugging The GPSS/H Interactive Debugger conveniently provides for rapid model development and verification. Simple debugger commands are used to control a model’s execution and to examine its status. Functions are provided to “step” through the model, to set breakpoints and traps that interrupt model execution based on multiple criteria, and to return to a previously saved state of the model. Almost all data values can be examined, including local data, global data, transaction attributes, entity statistics, and array data values. • The debugger provides a “windowing” mode that displays source code, model status, and interactive user input as the model runs. • A modeler can interrupt a long-running model at any time and use the debugging features to make sure that everything is running correctly before resuming execution.
• The GPSS/H debugger has almost no effect on execution speed. Because of this, many modelers use the debugger as their everyday run-time environment for GPSS/H.
GPSS/H is continually improving and evolving. Numerous enhancements, under development as of this writing, will be discussed in the tutorial session. Persons unable to attend may obtain the latest information by contacting Wolverine Software Corporation. Some of the more significant additions to the widely- used GPSS/H Professional version have been: • The BLET Block and the LET Statement can be used to assign a value to any GPSS/H data item. Unless you need the rarely used range-type assignments, there is no longer any reason to use the ASSIGN, SAVEVALUE, and MSAVEVALUE Blocks. The BLET Block provides a single, straightforward syntax for assigning values to all GPSS/H data items. For example, using BLET to assign a value of 1 to the Transaction parameter named ALEX is quite intuitive: BLET PF(ALEX)=1 Using indirect addressing, such as assigning a value to the Parameter specified by the number given in PF(ALEX), is similarly intuitive, yet is not likely to be written by accident: BLET PF(PF(ALEX))=1 • GPSS/H supports convenient built-in random- variate generators for 26 statistical distributions. • GPSS/H Professional is bundled with ExpertFit™, the highly-regarded distribution-fitting software from Averill M. Law and Associates. • GPSS/H Professional supports user-written external routines in both C and FORTRAN. Although it is rarely necessary to go “outside” GPSS/H when developing a model, it can be helpful in special situations. For example, it might be desirable to use scheduling software from the real system as a component of the simulation model. Similarly, a modeler might want to use pre-existing computational code, or need to write extremely complex computational routines that can become somewhat cumbersome as GPSS/H Blocks. Other special situations might involve the need to interface with non-ASCII data files, or to develop a specialized user-interface. • CHECKPOINT and RESTORE statements allow a model to save its state at a predetermined point during execution, then make repeated runs using that state as the starting point. In many cases, CHECKPOINT and RESTORE can be much easier to use than the traditional READ and SAVE statements. • The SYSCALL statement and the BSYSCALL Block, which take an operating system command line as an operand, allow a running GPSS/H model to shell out to the operating system to perform the specified command. SYSCALL and BSYSCALL are especially useful when using existing programs to perform data analysis during model execution or between simulation runs. The models can communicate with the external programs through data files. The ability to shell out to the host operating system has also been implemented in the GPSS/H Interactive Debugger. In order to use this feature, one merely types a “$” followed by the operating system command at the debugger command line prompt. • The operations that can be performed on Transactions in a User Chain were extended. The SCANUCH and ALTERUCH Blocks allow examining and changing the Parameters of such Transactions without having to UNLINK and reLINK them. They operate on User Chains in exactly the same way as SCAN and ALTER operate on Groups. • Floating-point Parameters can be examined and/or modified during operations on both User Chains and Groups.
6 BUILDING A SIMULATOR USING GPSS/H Earlier in this paper, the capabilities of visual-based modeling tools were contrasted with those of languages. Regardless of which approach is used, the modeler must still build from scratch a model that represents the physical system of interest. Modeling complex systems correctly requires intimate knowledge of both the simulation software and the system under study. (Schriber and Brunner 1995) However, not everyone who can benefit from using simulation has the time or the training necessary to build simulation models. As a result, a third type of modeling-tool, the special- purpose simulator, has emerged as a way of providing simulation capabilities to users with little or no modeling experience. Special-purpose simulators are most commonly developed under circumstances where: 570 Crain
• a single model development effort can benefit multiple users • modeling expertise can only be obtained from indirect sources such as internal or external consultants In these cases, it makes sense to have an experienced simulationist develop the model, freeing the end-user from learning modeling and simulation-software skills. The special-purpose simulator is thus a custom-built analysis tool designed by an experienced simulation- model builder. At its heart is a data-driven model of a specific system or set of similar systems. The simulator provides its user with a method to easily modify model parameters, define experiments, run tests, and get results. A simulator is usually comprised of a data-entry front end, a simulation engine, and an output browser. The simulation engine runs a parameterized model which accepts user-specified data at execution time. Combining these tools brings the power of simulation analysis into the hands of the non-simulationist.
The front end is the means by which the user of a special-purpose simulator modifies the run parameters without changing the underlying model. This may take several forms, the most basic and rarely used of which involves manually editing a text file. In another approach, the model itself prompts the user for input from the keyboard as the model executes. Still other designs require modifying data by using an external spreadsheet or database program. No matter which approach is used, the purpose of the front end is to conveniently produce a data file which can be used by the simulation model as it executes. A more advanced approach integrates a customized front-end data-entry program, a simulation engine, and an output browser under a single outer shell (Figure 1). Typically created using a general-purpose programming language or a tool such as Visual Basic, the shell may be menu-driven. Data-entry “windows” and dialog boxes guide the user through the process of specifying parameters, running the model, and viewing the output. The shell may also provide built-in help facilities and data “range-checking” (e.g., verifying that all operation times are non-negative before executing). 6.2 Simulation Model The most important component of the special-purpose simulator is the underlying model. Since the end user is generally prevented from modifying the model, this component determines the maximum flexibility offered by the simulator. It must be generic enough to accept a broad range of inputs, and it must be updated periodically to insure that the model remains valid. Simulation Engine Simulation Model Output Browser Menu-Driven Front End (Enter model parameters and write data file) (Run parameterized model (Format and view results) S H E L L Control returns to "shell" after each component finishes executing and read data file) Output File Data File Programs Text Files Batch File Executable Figure 1: Components of a Special Purpose Simulator A static simulation model can be produced and its design frozen when the simulator is initially created, or model code can be generated “on-the-fly” every time that the model parameters are modified by a user. In either case, user input is not limited to operating- parameter values — a user can also alter logic embedded deeply within the model. For example, based on a user- specified value, the model could select one of three different order-picking algorithms that have been pre- coded into the model. 6.3 Simulation Engine The simulation engine runs the model and generates output. There are several features to look for when selecting the engine. Most importantly, the language used for the engine must be flexible enough to handle the demands that a generalized model places on the software. Flexibility is crucial in the areas of file input, file output, and control logic within the model. Execution speed is also a primary concern. The faster a model executes, the better—time executing a model is often down-time for the user. GPSS/H’s speed and built-in flexibility make it the ideal simulation engine for a special-purpose simulator. An excellent example of the use of GPSS/H as a simulation engine is given in Coughlan and Nolan (1995).
6.4 Output Browser The output browser displays the data generated by the model in an easy-to-understand form. If the simulator’s user has limited experience in simulation modeling, the standard-style statistical reports provided by the engine may be difficult to decipher. Custom-formatted output, including summary statistics, should always be used to present simulator results. Statistical analysis of the output can be performed directly by the shell program, by a spreadsheet or similar program, or by a specialized statistical software product. For special-purpose simulators running under Microsoft Windows, SIMSTAT, from MC2 Analysis Systems, reads and analyzes standard output data generated by GPSS/H. Animation is yet another form of simulation output. Animating a generalized model can sometimes present obstacles. Accounting for variations in resource numbers and capacities, flow and routing-patterns, and physical layout dimensions makes animating a generic model more difficult than animating a specific model. However, a basic animation helps confirm model validity to the non-simulationist. High quality animations can be generated by coupling a GPSS/H model with Proof Animation™, a general-purpose animation tool. 6.5 Run-Time Versions Provide an Economical Simulation Engine A simulator is generally developed for a single application, where it is intended to be used by many people. However, each user must have a copy of the simulation software in order to execute the model. For a simulator used by dozens or even hundreds of users, the cost of the simulation software may render a project too expensive. Wolverine’s Run-time GPSS/H offers a solution to this problem. Run-time GPSS/H is identical to Wolverine’s 32-bit GPSS/H Professional, except that it can only run models which previously have been specially compiled with the regular Professional version. The run-time version allows economical distribution of high-performance GPSS/H-based simulators. Security is another important feature provided by the run-time version. Since only pre-compiled models can be run, the end user cannot view or edit the model “source” code. The user has access only to the data files used by the front-end and the output browser; hence, confidential models can be safely distributed. Even
“project-specific” pre-compiled models that can only be run by a specially designated group of users.
GPSS/H has a strong history of success in both commercial and academic environments. The product continues to evolve in functionality and to grow in use. Although GPSS/H uses a more traditional text-based model definition, it continues to forge a reputation for the robustness, modeling flexibility, ease-of-use and very high performance that experienced modelers demand for their projects.
Banks, J. 1991. Selecting simulation software. In Proceedings of the 1991 Winter Simulation Conference, ed. B.L. Nelson, W.D. Kelton, and G.M. Clark, 15-20. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers. Banks, J, J.S. Carson II, and J.N. Sy. 1996. Getting started with GPSS/H. 2d ed. Annandale, Virginia: Wolverine Software Corporation. Banks, J. and R. Gibson. 1997. Simulation modeling: some programming required. IIE Solutions February 1997: 26-31. Coughlan, K.L., and Paul J. Nolan. 1995. Developing special purpose simulators under Microsoft Windows. In Proceedings of the 1995 Winter Simulation Conference, ed. C. Alexopoulos, K. Kang, W.R. Lilegdon, and D. Goldsman, 969-976. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers. Henriksen, J.O., and R.C. Crain. 1998. GPSS/H
Wolverine Software Corporation. Law, A.M., and W.D. Kelton. 1982. Simulation
Book Company. Schriber, T.J. 1991. An introduction to simulation using
Schriber, T.J., and D.T. Brunner 1995. Inside simulation software: how it works and why it matters. In
Sadowski, and A.F. Seila, 45-54. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers. Smith, D.S., D.T. Brunner, and R.C. Crain. 1992. Building a simulator with GPSS/H. In Proceedings of the 1992 Winter Simulation Conference, ed. J.J. Swain, D. Goldsman, R.C. Crain, and J.R. Wilson. 357-360. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers. 572 Crain
Wolverine Software Corporation. 1996. Using Proof Animation. 2d ed. Annandale, Virginia: Wolverine Software Corporation. AUTHOR BIOGRAPHY ROBERT C. CRAIN joined Wolverine Software Corporation in 1981. He received a B.S. in Political Science from Arizona State University in 1971, and an M.A. in Political Science from The Ohio State University in 1975. Among his Wolverine responsi- bilities is that of chief developer for PC and workstation implementations of GPSS/H. Mr. Crain is a Member of IEEE/CS and ACM. He served as Business Chair of the 1986 Winter Simulation Conference and General Chair of the Twenty-Fifth Anniversary Winter Simulation Conference in 1992. Simulation Using GPSS/H 573 Document Outline
Yüklə 83,97 Kb. Dostları ilə paylaş:
|