1999: SIMULATION USING GPSS/H - Informs Sim

1 Proceedings of the 1999 Winter SIMULATION ConferenceP. A. Farrington, H. B. Nembhard, D. T. Sturrock, and G. W. Evans, USING GPSS/HRobert C. CrainJames O. HenriksenWolverine Software Corporation2111 Eisenhower Avenue, Suite 404 Alexandria, VA 22314-4679, is a traditional SIMULATION language that is wellknown for its speed and dependability. In GPSS/H , theprocess-interaction world view has been combined withmany advanced features to make an extremely powerfuland flexible tool, capable of handling large, complicatedmodels with ease, yet still providing exceptionally following sections provide an overview ofGPSS/H and its process-interaction world view, adiscussion of model-building interfaces includingtradeoffs associated with graphical modeling environ-ments, and a summary of advanced and recently-addedGPSS/H features.

2 Finally, the use of special-purposesimulators is discussed, along with features of GPSS/Hwhich make it very well-suited for use as the engine insuch INTRODUCTIONThe widespread success of GPSS/H has resulted fromboth the superiority of its original design and thesubsequent years of improvement and it is a SIMULATION language, GPSS/H requires someprogramming-style effort, but it does so within anintuitive modeling framework that can be readily usedwithout extensive programming experience. It is wellsuited for modeling both simple systems and large,complex many new SIMULATION tools have beenintroduced over the past decade, they have often beendesigned for specific classes of applications.

3 In strongcontrast, GPSS/H continues to be one of the most general,flexible, and powerful SIMULATION environments currentlyavailable. GPSS/H is in use around the globe modelingmanufacturing, transportation, distribution, tele-communications, hospitals, computers, logistics, mining,and many other types of queuing PRODUCT OVERVIEWGPSS/H is a discrete-event SIMULATION language. Modelsare developed with an editor and saved in ordinary textfiles. With GPSS/H , the text files are subsequentlycompiled directly into memory and executed. Exceptionallyfast compilation and execution encourage rapidprototyping and iterative model uses the natural and intuitive process-interaction approach to modeling.

4 The modeler specifiesthe manner in which objects flow through a system. As aresult, a GPSS/H model reads like a flowchart of thesystem being modeled. This modeling approach contributesgreatly to the ease and speed with which SIMULATION modelscan be the model has been built, the processrepresentation is executed by GPSS/H , and the activities of objects are automatically controlled and GPSS/H Process RepresentationAn object in a GPSS/H model might be a patient, atelephone call, a truck, a data packet, or any other type ofindividually identifiable entity. The representations ofthese objects in GPSS/H are called transactions.

5 As themodel executes, many transactions can be flowing throughthe model simultaneously just as many objects wouldbe moving through the real-world system being addition, multiple transactions can, while flowingthrough the model, execute the same GPSS/H modelstatements at the same instant in simulated time withoutany intervention by the modeler. The execution of aprocess-interaction SIMULATION model is thus similar to amulti-threaded computer program. This differs greatlyfrom the single-threaded, sequential execution of mostgeneral-purpose programming languages, and is a goodreason why such languages are usually not good tools forwriting SIMULATION SIMULATION projects focus on the optimal use ofsystem resources such as people, machines, conveyors,182 Crain and Henriksencomputers, physical space, and so on.

6 In a GPSS/Hsimulation model, transactions ( objects ) compete for theuse of these system resources. As transactions flow throughthe process representation, they automatically queue upwhen they can t gain control of a necessary resource. Themodeler does not have to specify the transaction s waitingtime or its queuing behavior for this to occur. Hence, thepassage of time in a GPSS/H model can be representedimplicitly, as in the case of a part waiting for a machine tobecome free, or explicitly, as in the case of a part beingprocessed by a GPSS/H model, like most real-world systems, mayconsist of multiple processes operating at the same , each such process may affect the otherprocesses in the system.

7 For example, two parallelmanufacturing processes may converge to a singleinspection point where they are competing for a singleresource the inspector. GPSS/H provides the capabilityfor multiple parallel processes to interact with each otherautomatically. Transactions ( objects ) may be sentbetween processes; they may control or share commonresources; or they may influence the (global) operation ofall MODELING A SYSTEM: TEXT VS. PICTURESO ften, the power and ease-of-use of a SIMULATION tool areconfused with the model-building interface provided by thetool.

8 That interface may be comprised of icons, menus anddata forms; or as with GPSS/H it may consist of textentry; or it may be a combination of the Developing and Editing ModelsMany SIMULATION tools try to build models visually . Iconsare placed on the computer screen to represent systemcomponents, links between them are drawn, and then theoperating characteristics of each component are specifiedby moving through a series of predefined menus and dataforms. One advantage of this approach is that even novicescan build simple models quickly but not models of complicated systems requires morethan simply placing and connecting icons on the screen.

9 Tomodel many processes, an explicit programmingenvironment must be provided. For example, thecomplicated operating logic of a microprocessor-basedequipment-controller often needs a proceduralspecification it is simply too cumbersome to representsuch logic visually. As a result, models of complex (realworld) systems built USING the iconic approach often stillrequire the modeler to create substantial amounts ofprogramming code, USING a procedural and text-basedrepresentation, to supplement the visual , large visual models can become verycumbersome to view, edit, and document.

10 Large modelscan be comprised of many screens of icons and links,many of them with associated programming code reachableonly by going through multiple levels of or even just browsing such models forces theuser to navigate through a labyrinth of icons, menus, click-buttons, data fields, and code contrast, a text-based interface allows browsing amodel simply by scrolling and reading. There is no need totry to remember what details are associated with an icon, orto shift back and forth between icons and forms at onelevel, and text-based procedural logic at a more detailed representation in part of a modelsimply requires continuing to work in the same style asbefore, but adding detail to the modeling tools can also force their usersto make the model fit within a rigid framework boundedby the available icons, menus and forms.