GPSS (General Purpose Simulation System)
This page was last modified on 8 June 2016, at 20:39.
|Designed by||Geoffrey Gordon|
|OS||UNIX, Linux, Windows, DOS and other|
|HGPSS, aGPSS, JGPSS|
General Purpose Simulation System (GPSS) is a discrete time simulation general-purpose programming language, where a simulation clock advances in discrete steps. A system is modelled as transactions enter the system and are passed from one service (represented by blocs) to another.
GPSS was developed by Geoffrey Gordon of IBM in 1961. Gordon developed first 5 versions of the language: GPSS (1961), GPSS II (1963), GPSS III (1965), GPSS/360 (1967) and GPSS V (1971). After IBM stopped supporting GPSS V, the next version GPSS/H was made by Wolverine Software company and J. Henriksen in 1978. The first GPSS version for PC and DOS system - GPSS/PC - was made 1984 by Minuteman Software company. This company also made GPSS World Modeling System - currently the most popular development environment for GPSS.
Model (program) in GPSS language is a sequence of statements called blocks which imitate particular events in queueing model. This events show how entities called transactions move trough the model, and how are they affected in particular moments in time. As queueing model can have many transactions at time and as GPPS implements event paradigm, GPSS interpreter can execute different program parts alternately to imitiate transaction delays.
GPSS language simulation allows following actions:
1. Model transaction movement;
2. Plan model events by exectuting them according to their time progression;
3. Store statistics;
4. Increase model time.
GPSS objects can be divided into the following subcategories:
1. Dynamic objects – transactions (can be created, moved, or destroyed);
2. Operating blocks – set model logic and transactions paths. Following events can happen in blocks:
- creation and destruction of transactions;
- change of object attribute;
- transaction lock for a period of time;
- change of path of the transaction.
3. Device objects;
4. Calculation objects;
5. Memory objects;
6. Group objects;
7. Statistics objects.
Block - basic structure of GPSS. Essentially, model is a seqence of blocks. Frequently used blocks are:
GPSS blocks have the following format:
<label> <operator_name> <operands> [<comment>]
The usual program structure in GPSS is:
SIMULATE descriptions of functions, arrays, queues etc. statements modeling transaction movements START A,B,C END.
Transaction is a process that represents the real-world system you are modeling. It is: • Executed by moving from block to block.
• Each transaction in the model is contained in exactly one block,
• But one block may contain many transactions
Objects that represent component parts of the real system. Their state can be changed by transaction going trough them and they can change the flow of transactions in a model. There are several types of these objects:
1. One channel device (FACILITY) - GPSS provides the facility modeling concept to represent limited availability of a service. A facility is a resource that can be used by only one transaction at a time.
2. Multichannel device (STORAGE) - GPSS provides the storage modeling concept to represent a limited number of unit capacity. A storage is a resource that can be used by several transactions at a time until it becomes empty.
3. Logic keys (LOGIC) - represent a switch with two states.
Calculation objects are used to describe relationships between model components with the use of mathematical apparatus. They include:
1. Variables - expressions that include constants, attributes, arithmetic and logic opertions and functions.
2. Boolean variables
Most versions of language also include some kind of random generator.
Memory objects give access to saved values. They include:
2. Matrixes of cells.
They are used to store numerical informations. Any transaction can read or write into them.
1. Queues - used to store transactions if device is unavaliable.
2. Tables - used to tabulate statistic information, usually to get empirical distributions of random variables.
Include numerical groups, transaction groups and lists.
In the process of modeling transactions are stored in the lists. There are five types of lists, and transaction can only be in of them at at time:
1. current events;
2. future events;
3. device's delay;
4. softirq's of one channel device;
One channel device has:
1. softirq list
2. irq list
3. delay list
4. retry list
Multichannel device has:
1. delay list
2. retry list
User list includes transactions that were deleted by user from the list of current events and moved to user list as temporary inactive. They are used to organize queue with behaviour different from FIFO.
The aim is to simulate one day of operation of a barber shop. Customers arrive in a random constant flow, enter the shop, queue if the barber is busy, get their hair cut on a first-come first-served basis, and then leave the shop. We wish to know the average and maximum waiting line, as well as the number of customers.
SIMULATE ; Define model * * Model segment 1 * GENERATE 18,6 ; Customer arrive every 18±6 mn QUEUE Chairs ; Enter the line SEIZE Joe ; Capture the barber DEPART Chairs ; Leave the line ADVANCE 16,4 ; Get a hair cut in 16±4 mn RELEASE Joe ; Free the barber TERMINATE ; Leave the shop * * Model segment 2 * GENERATE 480 ; Timer arrives at time = 480 mn TERMINATE 1 ; Shut off the run * * Control cards * START 1 ; Start one run END ; End model
The "program" is comprised between the
END statements, and is divided into "model segments" and "control cards".
The first segment models customers. The
GENERATE block creates a flow of Transactions and schedules them to enter the model with an inter-arrival time uniformly distributed over the range 18±6. It is the programmer's responsibility to interpret these transaction as customers and to understand that the time is to be counted in minutes. The Transactions start their existence in the
GENERATE block and progress from Block to Block, according to certain rules, until they reach a
TERMINATE which remove them from the model.
Normally transactions progress from one block to the next one, so the customer transactions will leave the
GENERATE block to enter the
QUEUE Chairs block. This block simulates a waiting line, and collects statistics accordingly. In the example, it materialize a line of chairs and, at the end of the simulation, we will know, among other things, the maximum queue size (how many chairs are needed) and the average waiting time. The
QUEUE block requires the name of the queue as a parameter, because more than one queue may exist in the model. Each one is associated with a
DEPART block, which is triggered when the transaction leaves the queue. GPSS remembers which transactions are in the queue, so that it possible to know the average time spent, and to check that no buggy transaction is leaving a queue without previously entering in it.After the
QUEUE chairs block, the transaction will try to proceed to the
SEIZE Joe block, a block simulating the capture of the Facility named Joe. Facilities model single servers of capacity one. If the facility is busy, the
SEIZE will deny the attempting transaction the right to enter. In the example, the customer will wait in the
QUEUE block. If it is free, or as soon as it becomes available, the transaction will be allowed to capture the facility, mark it as busy to others transactions and start to count the service time and other statistics, until the same transaction passes the corresponding
RELEASE Joe block.
RELEASE pairs are linked by the facility name, because many independent facilities may exist in the model. They can model operators, like a barber, a repairman, an agent, but also pieces of equipment, like a crane, a gas station, an authorization document, etc., in fact anything with capacity one. To simulate multiple parallel servers, like a team of five barbers, or an oven with a capacity of 10, GPSS uses entities named
After a customer seizes Joe, she proceeds to the next statement which is
ADVANCE 16,4, whose task is to freeze the entity for a prescribed length of time, here a random number picked between 16-4=12 and 16+4=20mn. Other service time distributions are available through GPSS
FUNCTION (a somehow different notion than function in other programming languages). During that time, other transactions will be allowed to move through the model, blocking some other facilities that may exist in the model, but not Joe because this facility is busy with the frozen customer. After the prescribed time, the customer will wake up, proceed to the next statement, which will free Joe, and
Then the next transaction on the previous block, that is a customer sitting on a chair, will be able to
SEIZE Joe. To select the "next" transaction, GPSS uses the first-come first-served basis, with priority. Other selection policies can be programmed by direct manipulation of the future event chain entity.
In parallel to this first segment, simulating the customer behavior, a second model segment simulates the end of the day. At time 480mn = 8h a entity is
GENERATEd, which will
TERMINATE on the next block. This time, the
TERMINATE as a parameter of 1, meaning a special counter is decreased by 1. When that counter reaches 0, the program stops and the output is printed. This special counter is setup with the
START statement. In the example, it is set to one, thus the simulation will finish after one run of 480 mn in simulated time.
The output contains:
FACILITY AVERAGE NUMBER AVERAGE SEIZING PREEMPTING UTILIZATION ENTRIES TIME/TRAN TRANS. NO. TRANS. NO. Joe .860 26 15.884 26 QUEUE MAXIMUM AVERAGE TOTAL ZERO PERCENT AVERAGE $AVERAGE TABLE CURRENT CONTENTS CONTENT ENTRIES ENTRIES ZEROS TIME/TRANS TIME/TRANS NUMBER CONTENTS Chairs 1 .160 27 12 44.4 2.851 5.133 1 $AVERAGE TIME/TRANS = AVERAGE TIME/TRANS EXCLUDING ZERO ENTITIES
It indicates that Joe was busy 86.0% of the time, gave a hair cut to 26 customers and that hair cut took 15.88 minutes on the average. Incidentally, Joe was cutting the hair of customer number 26 when the simulation was closed. No programming provisions were taken for the barber to finish the hair cut before to close the shop.
It indicates also that a maximum of 1 customer was observed waiting his turn, in facts the number of waiting customer was on the average 0.160. A total of 27 customers did enter the queue, so that customer number 27 was still sitting, waiting his turn, when Joe closed the shop. Out of these 27 customers, 12 were served without having to wait. In facts, the queue was empty 44.4% of the time. The average waiting time was 2.851 mn, and the average waiting time for the 15=27-12 customers who did really wait was 5.133 mn.
http://agpss.com/ - good GPSS version to start working
http://www.minutemansoftware.com/reference/r3.htm - list of statements for GPSS
1. Greenberg, Stanley (1972). GPSS Primer. New York: Wiley-Interscience. ISBN 0471324906.
2. Schriber, Thomas (1974). Simulation using GPSS. Wiley. ISBN 9780471763109.