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 blocks) to another. It is used primarily as a process flow oriented simulation language;[1] this is particularly well-suited for problems such as a factory.
GPSS was developed by IBM's Geoffrey Gordon at the beginning of the 1960s. He named it Gordon's Programmable Simulation System. The name was changed when IBM decided to release it as a product.[2]
The "General Purpose" part of the new name was to create a standard in waiting-line simulations.
The original releases were for IBM's 7044 & 7090 mainframes. Subsequently, there were releases for IBM 360,[3]Univac 1108 and CDC.[4][5][6]
Over time, other implementations, in other languages and targeted at different size systems, were developed, including DEC's VAX, a specialized APL version for large-scale Univac systems,[7] and Macintosh, among others.[8]
JGPSS (Java General Purpose Simulation System) is a Java-based tool that was developed to teach the GPSS simulation language.[2][9]
GPSS resembles a LEGO structure where blocks are chosen by the modeller for specific functions to imitate a particular system.[10]
The language is neither procedural, object-oriented or functional programming. The world is simulated with entities moving through the model.[11] These entities, called Transactions, are envisioned as moving from Block to Block, where a Block is a line of code and represents unit actions that affects the Transaction itself or other entities.
Blocks can be facility-oriented (such as machines in a job shop) or transaction-oriented (such parts of work-in-process, signals in electronic components or documents in a bureaucratic procedure). GPSS automatically keep track of statistics which brings in fixed form at the end of a simulation as standard report. GPSS is one of the oldest language candidate of first object-oriented approach because while transactions are truly instances of model objects, blocks are methods in the modern concept of OOP.
Entities can be broadly classified in Resources, Computational entities and Statistical entities.[11] Resources, like Facilities and Storages represent limited capacity resources. Computational entities, like Ampervariables (variables), Functions and random generators are used to represent the state of Transactions or elements of their environment. Statistical entities, like Queues or Tables (histograms) collect statistical information of interest.
The following example, taken from Simulation using GPSS,[12] is the "Hello world!" of GPSS and will illustrate the main concepts.
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 SIMULATE
and 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.
The SEIZE
/ 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 STORAGE
s.
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 TERMINATE
.
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 an entity is GENERATE
d, 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 set up 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 closing the shop.
It indicates also that a maximum of 1 customer was observed waiting his turn, in fact 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 fact, the queue was empty 44.4% of the time. The average waiting time was 2.851 min, and the average waiting time for the 15=27-12 customers who did really wait was 5.133 min.
GPSS is a process flow oriented simulation language
simplify the development of a complete simulation tool following the GPSS syntax. This paper presents ... In the original, GPSS meant Gordon's Programmable Simulation System, in honor of Geoffrey Gordon, its creator.
IBM has available GPSS III for the 7044 and 7090 series and GPSS/360 for the larger 360 ... GPSS II has also been available on the UNIVAC 1108
about the simulation modeling language GPSS. ... summarized; sources comparing GPSS and other .... Corporation's GPSS for Univac 1108 hardware)
Background: The General Purpose Simulation System (GPSS) is a ... manufacturers that have produced versions of GPSS are UNIVAC (Gorchow, 1968), CDC
GPSS-like ... in the APL version of GPSS, although APL happens to be an interpretive language. ... Univac Corporation, GPSS 1100 for UNIVAC 1108 system.
Learn simulation building a simulation engine. JGPSS is an implementation of the GPSS system based in Java.
In 2011, GPSS, the General Purpose Simulation System, ... class room the students can study a very simple Lego railroad model
By: Wikipedia.org
Edited: 2021-06-18 18:13:13
Source: Wikipedia.org