GPSS Discrete Event Simulation Language


General Purpose Simulation System is a language designed for discrete event modeling. The language as it exists today is the result of more than twenty years of evolution. While GPSS has its roots in the early days of mainframe computing, its basic ideas have proven suitable for application to todays problems using modern computing environments. The popularity of GPSS is due, in part, to its power of expression. A short, easily understood GPSS model would require many pages of FORTRAN coding to accomplish a similar goal. The GPSS user is free to concentrate on the important issues in the model being developed since the language itself collects statistics, produces tabulated results and performs a host of mundane tasks one would prefer not to deal with. The purpose of this brief article is to present some basic terminology and concepts which will enable the person meeting GPSS for the first time to understand the broad range of applications, power and ease of use that this language brings to the simulationist.

GPSS provides a set of abstract components of various types and a set of operators called blocks which perform certain actions on the individual components. The transaction is the component which moves through a sequence of blocks that has been designed to model the system being studied. The state of the components of the model determines the details of how a block of a given type will operate. For example, a block which permits a transaction to take control of a piece of equipment will not allow the transaction to proceed if the equipment is already at maximum capacity.

Several different types of equipment components are available in GPSS. A facility is an entity which is either available for use or is in use by at most one transaction at a time. A storage is similar but has a capacity which may be specified to suit the needs of the model builder. Finally, a logic switch is a simple ON/OFF element which may be set and tested to modify the path of a transaction through the blocks of the model.

We need to emphasize that these components are abstractions. In a model of a factory operation, transactions could represent units being assembled; facilities might represent robot welders and a logic switch could be used to simulate a machine breakdown. Someone modeling a high-speed communications network, on the other hand, might have transactions correspond to messages, facilities to transmission lines and storages represent message buffer space. Whatever the application, GPSS entities provide a natural parallel to the parts of the system of interest.

As transactions move through blocks which operate on equipment entities, GPSS collects equipment usage and transaction behavior statistics such as average contents, average occupancy time, maximum contents and the like, for inclusion in a report produced automatically when the model run completes.

Additional measurement and reporting capabilities are provided by the queue and table entities. The QUEUE and DEPART blocks may be placed around a block or group of blocks where waiting transactions may gather. The queue will collect and report waiting-line statistics such as maximum and average queue lengths, average delay, percentage of transactions that were delayed, and so on. A TABULATE block enters a sample value into a frequency count table (histogram) which is included in the standard report at the end of the run.

GPSS provides an underlying control mechanism which is transparent to the user but which ensures that competition between transactions (for use of a facility, for instance) is consistently arbitrated and that transactions are moved through the blocks of the model in an orderly and efficient way. This control mechanism also administers the GPSS clock which provides the time-base for models.

The GPSS clock is also an abstraction. It measures time in clock units. A clock unit is interpreted appropriately by the person designing the model. In the factory model a clock unit could correspond to a second or a minute, while in the communication network the finer resolution of a one- millisecond clock unit would be more suitable.

Function entities are provided to describe various types of numeric relationships. They may be used to produce random variates from theoretical or empirical probability distributions. They may also be used to modify transaction behavior depending on system-wide, entity or transaction attributes.

Variable entities can be used to perform arithmetic calculations in all implementations of GPSS. The greater flexibility of GPSS/VX and GPSS/C versions permits arithmetic expressions to be entered wherever a constant is permitted.

Certain modeling situations may take advantage of the set concepts embodied in the group entity-type. Other situations will benefit from the use of COUNT and SELECT blocks which permit a number of entities to be examined in a single operation.

GPSS provides entities known as savevalue's and matrix savevalue's which are numeric storage locations available for use or reference by all transactions. In addition, each transaction has a set of private numeric attributes called parameter's which may be used to hold a variety of information as required by the user, such as a part number code or the size or weight of an item represented by a transaction.

A rich set of Standard Numerical Attributes (SNA's) provide a convenient notational way to access components of a model. For instance, Q$BOXOFFICE represents the current contents of the queue entity named BOXOFFICE. This SNA may be used wherever a numeric value is allowed. A simple balking situation could be represented by the block

         TEST L  Q$BOXOFFICE,FN$BALK,GOAWAY
which allows transactions to pass through if the current length of the BOXOFFICE lineup is less than the value returned by the function BALK, and otherwise re-directs them to the block GOAWAY. BALK may be written to return a random variate from any desired probability distribution; or it may return a value varying with the time of day in the model or a value dependent on the number of packages (represented by a transaction parameter) the theatre patron is carrying.

Simulation Software's GPSS products all feature interactive debugging capability which allows setting breakpoints in the model, single-stepping and examining attributes of model entities. Each implementation has additional innovative tools designed to make debugging a much shorter task. Features such as conditional breakpoints and animated displays optimize the model-development process, while internally-compiled code and optimizations shorten the run-times for production model runs.

A SIMPLE GPSS MODEL

The following brief example models a bank with a individual queues for each of five tellers. The transactions are customers and facilities are used to represent the bank tellers.

1.           SIMULATE
2.   LINES   EQU         1(5),Q,F
3.   ARRIVE  FUNCTION    RN5,BE
4.           GENERATE    20,FN$ARRIVE
5.           SELECT MIN  1,LINES,LINES+4,,Q
6.           QUEUE       P1
7.           SEIZE       P1
8.           DEPART      P1
9.           ADVANCE     90,20
10.           RELEASE     P1
11.          TERMINATE   1
12.          START       100
13.          END
The following is a line-by-line description of the model:
  1. SIMULATE is a control statement.
  2. EQU defines LINES as the name of the first of a group of 5 corresponding queues and facilities - the lineups and tellers.
  3. Defines ARRIVE as the name of a function transforming a random number between 0 and 1, into a value from a builtin exponential ("BE") distribution - a commonly-used in simulating arrival processes. The random number is taken from the fifth builtin stream of such numbers ("RN5").
  4. Customers arrive an average of 20 seconds apart with a random variation determined by sampling the function ARRIVE defined in the previous line.
  5. Set parameter 1 of each entering transaction to the number of the queue with the MINimum length.
  6. Join the queue whose number is now in parameter 1.
  7. When the corresponding facility is available take possession of it.
  8. Now leave the lineup, recording the delay time in the queue statistics.
  9. Delay for an average of 90 seconds with a variation of 20 seconds either way, representing time for the banking to be done. The delay is chosen randomly with uniform probability in the 70 to 110 second range. The facility remains in use for this period. The random number used to determine the actual delay time is taken from the first random number stream, thus the arrival times and delay times are statistically independent.
  10. Free the facility for use by the next transaction.
  11. Destroy the transaction. Count 1 complete customer cycle.
  12. Run the model until 100 customers have reached the TERMINATE block.
  13. END marks the last line of the model.
David Martin <dave@csd.uwo.ca>