 |
GPSS/H - Serving the simulation community since 1977 |
The first version of the GPSS language was introduced by IBM in October, 1961. Thus, it has been in continuous, world-wide use for over 40 years. There are very few programming languages of any kind for which this is true.
GPSS introduced the transaction-flow modeling paradigm. Under this paradigm, active "consumer" objects, called transactions, travel through a block diagram representing a system, competing for the use of passive "server" objects. This modeling paradigm is extremely general and has been adopted in a large number of simulation languages. Terminology differs from language to language. Transactions may be called items, entities, tokens, etc., but the basic architecture is the same: active objects compete for passive resources while traveling through a diagram representing a system.
GPSS was designed by Geoffrey Gordon as a tool for use by non-programmers. It is interesting to note that over 40 years later, “no programming required” is still featured as a virtue in advertisements for simulation software. Historically, GPSS models were developed by drawing block diagrams and manually typing character-based representations of blocks. Over time, the sizes of GPSS models grew well beyond what Geoffrey Gordon had ever anticipated. While drawing a 100-block diagram is relatively easy, drawing a 5000-block diagram is difficult. As users began developing larger and larger models, and as they became more comfortable with typing in blocks without first having drawn them, GPSS came to be viewed as a true programming language.
GPSS/H Emerges in 1977
GPSS/H was first placed into commercial service in November, 1977. Over the ensuing years, it has become well known for its speed and dependability. In GPSS/H, the transaction flow world view has been extended with many advanced features to make an extremely powerful and flexible tool capable of handling large, complicated models with ease, yet still providing exceptionally high performance.
GPSS/H has been a very successful product. Its success is the result of both the superiority of its original design and subsequent years of improvement and enhancement. Most of the enhancements developed for GPSS/H have been improvements to it as a programming language. The landmark modeling concepts developed by Geoffrey Gordon remain largely intact, although improvements and additions have been made to them, as well.
Since it is a simulation language, GPSS/H requires some programming-style effort, but it does so within the intuitive modeling framework Gordon designed to be readily used without extensive programming experience. It is well suited for modeling both simple systems and large, complex systems.
Although many new simulation tools have been introduced over the past decade, they have often been designed for specific classes of applications. In strong contrast, GPSS/H continues to be one of the most general, flexible, and powerful simulation environments currently available. GPSS/H is in use around the globe modeling manufacturing, transportation, distribution, telecommunications, hospitals, computers, logistics, mining, and many other types of queuing systems.
Representing a System in GPSS/H
In a GPSS/H model a transaction can represent a patient, a telephone call, a truck, a data packet, or any other type of individually identifiable entity that has a behavior. As a model executes, many transactions can flow through the model simultaneously—just as many “objects” would move through the real-world system being modeled. In addition, while flowing through the model, multiple transactions can execute the same GPSS/H model statements at the same instant in simulated time without any intervention by 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, and is a good reason why such languages are usually poor tools for writing simulation models.
Many simulation projects focus on the optimal use of system resources such as people, machines, conveyors, computers, physical space, and so on. In a GPSS/H simulation model, transactions compete for the use of these system resources. As transactions flow through the process representation, they automatically queue up when they can’t gain control of a necessary resource. The modeler does not have to specify the transaction’s waiting time or its queuing behavior for this to occur. 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 become free, or explicitly, as in the case of a part being processed by a machine.
A GPSS/H model, like most real-world systems, may consist of multiple processes operating at the same time. Furthermore, each such process may 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, e.g., an 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
The presence or absence of a single characteristic—such as a “visual” interface for building models—is insufficient to determine a tool’s ease-of-use. Whether a tool is “easy to use” depends upon the combination of general characteristics and specific features that are heavily used when real-world models are built.
Moreover, the ease-of-use that is claimed for almost all simulation tools can mean many things—that the tool is easy to learn, easy to use once learned, easy to use when modifying models, easy to use when building simple models, or easy to use when building large, complex models. Rarely is a product equally good at all of these, but equally rarely is the prospective user informed about which “ease-of-use” is being claimed.
Another meaning, which is often overlooked yet very important when modeling complex, real-world systems, is that of ease in verifying that the tool’s inner workings, when running the model, are accurately mimicking the operation of the actual system. If such verification is difficult, it may not be done. The risks of not doing it have been pointed out by Schriber and Brunner (1997).
A simulation language’s ease-of-use is rarely constant over the duration of a simulation project. The ease-of-use of a tool that is optimized for developing small models may diminish as a model gets larger and larger, and more details of system operation have to be incorporated into a model. Conversely, a tool that requires a bit more study to master may be harder to use in the early stages of a project, but offer downstream rewards when it is able to meet modeling requirements for a large, complex system. Scalability of technology is an important contributor to ease-of-use. GPSS/H has excellent scalability. It is able to handle very large models (10’s of thousands of blocks) and
The GPSS/H Interactive Debugger provides invaluable assistance for rapid model development and verification. Prior to the advent of GPSS/H in 1977, most simulation tools featured batch-oriented, non-interactive debugging. To debug a model, one typically generated a large trace file and very carefully proofread the trace file to verify model correctness.
In GPSS/H, 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. As you build your model, you want to feel confident that it's right. Our sophisticated debugger is a quick and efficient tool for verifying your model. Unlike many debuggers, GPSS/H gives you access to virtually all of your data, and it doesn't slow down model execution.