8.4 Simulation languages

---

8.4 Simulation languages

As the use of simulation has increased, so has the development of new simulation languages. Simulation languages have been developed because of the unique needs of the modeling community to have system routines to keep track of time, maintain the state of the simulation, collect statistics, provide stimulus, and control interaction. All of these previously had to be done by each individual programmer.

Early languages provided basic services by adding a callable routine from programming languages. These early languages provided for time and event management but little else. This chapter will look at four languages and discuss the aspects they possess that aid in the simulation process. We will not, however, cover languages that are built on top of basic simulation languages, such as Network II.5 and others.

8.4.1 GASP IV

GASP IV was developed in the early 1970s as a general-purpose simulation language and is still in use with variations today. As such we use this as a basic model for most languages in existence today. GASP IV is a FORTRAN-based simulation language that provides routines and structure to support the writing of discrete events, continuous and combined discrete events, and continuous simulation models. Discrete event models in GASP IV are written as a collection of system and user FORTRAN subroutines. GASP IV provides the user with the following routines: time management, file management (event files, storage and retrieval, copying of events, and finding of events), and data collection and analysis (both observation-based and time-based statistics). The user must develop a set of event routines that define and describe the mathematical-logical relationships for modeling the changes in state corresponding to each event and their interactions.

As an example of GASP IV's use and structure, our bank teller problem will be examined once again. In order to model this problem in GASP we must determine the events of interest, their structure, and the boundaries upon which they are triggered. To simplify the example, it is assumed that there is no time delay between the ending of service for one customer and the beginning of another (if there is one waiting). The important measures or states will be the number of customers in the system and the teller's status. From these two system events a customer's arrival and a teller's end of service occur. These are also chosen as the points at which significant changes to a system's status occur. The activity that occurs is the beginning of service; this can be assumed to occur either when a customer arrives at an empty line or when the teller ends service to a customer.

Entities in GASP are represented by arrays of attributes, where the attributes represent the descriptive information about the entity that the modeler wishes to keep. Entities are the elements that are acted on during the simulation. Their attributes are adjusted based on occurrences of interest. A variable "busy" is used to indicate the status of the teller, and attribute (1) of customer is used to mark the customer's arrival time to the teller line. To make the simulation operate, the system-state must be initialized to some known values; in this case the teller is initialized not busy and the first arriving customer must be scheduled to arrive. Additionally, to keep the model running, the arriving customer must schedule another customer's arrival in the future based on a selected random time distribution. Statistics will be taken when service completes on the length of wait time and the number of customers waiting, in service, and in total. When we look at the GASP code we need to examine the structure of a typical GASP program (see Figure 8.3). As indicated by this figure, GASP IV exists as a single program in FORTRAN. Therefore, making it function requires a main program and a call to the GASP program that will begin the simulation. Another function of the main program is to set up limits on the system, such as number of files, input, output, limits on events, and so on. Figure 8.4 depicts the main program for our example.

Figure 8.3: Basic model of GASP IV control.

 Dimension nset (1000) common/gcom/atrib (100, DP(100), DDL (100, DTNOW, II,MFA,MSTOP,NCLNR,NCRDR,NPRINT,NNRUN, NNSET,NTAPE,SS(100),SSL(100),TNEXT,TNOW,XX(100) Common Q Set Equivalence Nset(1),Qset(1)) NNSet=1000 NCRDR=5 NPRINT=6 NTAPE=7 Call GASP Stop End 

Figure 8.4: GASP IV main FORTRAN program.

Once GASP has been called, the program runs under control of the GASP subprogram calling sequences. The GASP system's executive takes over and initializes the simulation using the user-supplied routine Intlc. Once initialized, it begins simulation by examining the event list; if any events exist, it pulls them out, executes them, and takes statistics. The loop continues until the end conditions are met or an error occurs. To control events and make sense of them in FORTRAN requires the user to supply an event-sequencing routine called Event. This event-control routine is called with the attribute number of the intended event. It will use this to call the actual event. For our bank teller example this routine is illustrated in Figure 8.5 with its two events shown. When this routine is called with an appropriate number, the intended event is called, executed, and control is returned to the event routine, which in turn returns control to the executive routine.

 Subroutine Event (I) Goto (1,2), I 1 Call arrival   return 2 Call end SRU   return End 

Figure 8.5: Subroutine Event for bank teller problem.

These events are called based on what Filem (1) has stored in it. Filem (1) is operated on in a first-come, first-served basis, removing items one at a time. The events are stored in Filem (1) as attributes: attribute (1) is the time of the event, attribute (2) is the event type, and all other attributes are added user attributes for the entity. Figure 8.6 gives an example of how the file is initialized.

 Subroutine INTLC common/gcom/atrib (100, DP(100), DDL (100, DTNOW, II,MFA,MSTOP,NCLNR,NCRDR,NPRINT,NNRUN, NNSET,NTAPE,SS(100),SSL(100),TNEXT,TNOW,XX(100) Equivalence (xx(1), Busy) Busy=0 Atrib(2)=1 Call filem return end 

Figure 8.6: Subroutine Intlc for bank teller problem.

Figure 8.6 illustrates the initialization routine for the bank teller simulation. Filem (1), the event file, is loaded with the first arrival event (a customer) and the teller is set to not busy.

Once Filem (1) has an event stored, the simulation can begin. The first event is a customer arrival indicated by the contents of attribute (2) of Filem (1), which is the only event at this time. The arrival event (see Figure 8.7) performs the scheduling of the next arrival.

 Subroutine Arrival common/gcom/atrib (100, DP(100), DDL (100, DTNOW, II,MFA,MSTOP,NCLNR,NCRDR,NPRINT,NNRUN, NNSET,NTAPE,SS(100),SSL(100),TNEXT,TNOW,XX(100) Equivalence (xx(1), Busy) TIMST(Busy,TNOW,ISTAT) Attrib(1)=TNOW+expon(20.,1) Attrib(2)=1 Call filem(1) Call filem(2,attrib(1)) if (Busy=0) go to return 10 Busy =1 attrib(1)=TNOW+unfrm(10.,25,1) attrib(2)=1 attrib(3)=TNOW Call filem(1) return end 

Figure 8.7: Arrival routine Event code.

After the next arrival is scheduled, the preset arrival is placed in the queue (Filem [2]). Then a test is made to see if the teller is busy. If so, we return to the main program or else we schedule an end of service event for the preset time plus a number chosen uniformly between 10 and 25.

The second event, the end of service, is shown in Figure 8.8. This code determines statistics of time in system and busy statistics. The code also checks to see if there is any user in the queue, removes one if there is, and schedules another end of service for this user.

 Subroutine end SRU common/gcom/atrib (100, DP(100), DDL (100, DTNOW, II,MFA,MSTOP,NCLNR,NCRDR,NPRINT,NNRUN, NNSET,NTAPE,SS(100),SSL(100),TNEXT,TNOW,XX(100) TIMST(subusy,TNOW,T,ISTAT) TSYS=TNOW-Attrib(3) Call col CT(TSYS,1) if(NNQ(2), 6T,0) go to 10 busys=0 return 10 Call schd((2,unfrm(10.,25,1) attrib) return end 

Figure 8.8: End of service routine.

This simple example shows how GASP could be used to model a wide array of event-based models. Details of this language can be found in [14].

8.4.2 GPSS

General-Purpose Simulation System (GPSS) is a process-oriented simulation language for modeling discrete systems. It uses a block-structuring notation to build models. These provide a set of standard blocks (see Figure 8.9) that provides the control and operations for transactions (entities). A model is translated into a GPSS program by the selection of blocks to represent the model's components and the linkage of them into a block diagram defining the logical structures of the system. GPSS interprets and executes the block diagram defined by the user, thereby providing the simulation. This interpretation is slow and, therefore, the language cannot be used to solve large problems.

Figure 8.9: Basic GPSS modeling component blocks.

To illustrate GPSS we will again examine our bank teller system. It is viewed as a single-server queuing system with our teller and n customer arrivals (see Figure 8.10). Customers arrive with a mean interarrival time of 10 minutes, exponentially distributed. The teller provides service to the customers in a uniform time between 5 and 15 minutes. The simulation will take statistics on queue length, utilization of teller, and time in system. The simulator builds the diagram shown in Figure 8.10 from the model of a queuing system based on the statistics to be taken. This structure is then translated to the code seen in Figure 8.11. The code is broken down into four sections. The top section is used to define the data needed to approximate an exponential distribution and set up markers for the time-dependent statistics.

Figure 8.10: GPSS model for the bank teller problem.

 1 * 2 Simulate 3 * 4 XPDIS function RN1,C24 5 0.0, 0.0/0.1, 0.104/0.2, 0.222/0.3, 0.355/0.4, 0.509/0.5, 0.69 6 0.6, 0.915/0.7, 1.2/0.75, 1.38/0.8, 1.6/0.84, 1.83/0.88, 2.12/0.9 7 2.3/0.92, 2.52/0.94, 2.81/0.95, 2.99/0.96, 3.2/0.97, 3.5/0.98 8 4.0/0.99, 4.6/0.995, 5.3/0.998, 6.2/0.999, 7.0/0.9997, 8 9 * 10 TISYS table MP1,0,5,20 11 * 12 * model segment 13* 14 Generate 10, FN$XPDIS 15 Mark P1 16 Queue Waitq 17 Seize SRVR 18 Depart Waitq 19 Advance 10,5 20 Release SRVR 21 Tabulate TISYS 22 Terminate 23 * 24 * timing segment 25 * 26 Generate 480 27 Terminate 1 

Figure 8.11: GPSS code for the bank teller problem.

The second segment is the main simulation code, and it performs the tasks of generating customers (14), taking statistics on arrival time (15), queuing up arriving customers (16), scheduling service (17; when free, take control), departing the waiting line (18), delaying the exit by the appropriate service time of the teller (19), releasing the teller for the next customer (20), taking statistics on the customer's time in the system (21), and exiting the system (27).

The third segment is a timing segment and is used to schedule the end of service routine. The model will schedule a dummy transaction at time 480, which will cause the terminate instruction to execute (counter set to 0). The fourth section, the control segment, begins the simulation by setting the termination counter and giving control over to the model segment.

This example shows some features of GPSS. GPSS is a simple modeling method that became widely used. However, this language was doomed by its interpretive operation, which made it extremely slow. The reader is encouraged to consult [15] for details of the language.

8.4.3 Simscript

Simscript was developed in the late 1960s as a general-purpose simulation language. See [16] for details about the language. It provides a discrete simulation modeling framework with English-like free-form syntax making for very readable and self-documenting models. Simscript supports two types of entities: permanent and temporary. For example, in the bank teller problem, the teller is permanent and the clients are temporary. Permanent entities exist for the entire duration of the simulation, whereas the temporary entities come and go during it. Attributes of the entities are named, increasing their readability and meanings.

A Simscript simulation is built of three pieces: a preamble, a main program, and event subprograms. The preamble defines the components of the model (entities, variables, arrays, etc.). The main program initializes all elements to begin the simulation. The events define the user events used to model a system. To define these components we will again use the bank teller problem. We will assume arrivals are 10 minutes apart on average and exponentially distributed, and the teller service time is uniformly distributed between 5 and 15 minutes. Figure 8.12 depicts code for this problem. It indicates many of Simscript's features, as follows:

• Line 2 describes the wait time as being a system entity that has statistics associated with it, and it is a permanent entity since it is not indicated as being temporary. Therefore, we can keep statistics on it over the life of the model.

• Line 3 defines a temporary entity customer and indicates that it belongs to the wait time.

• Lines 6 and 7 define the event names and their attributes.

• Lines 9-14 define statistics to be taken on this entity.

 A: 1 Preamble 2 the system owns a wait line and has a status temporary entities 3 every customer has an enter time and may belong to the wait line 4 event notices include arrival and stop simulation 5 every departure has a teller 6 define busy to mean 1 7 define idle to mean 0 8 define time in bank as a real variable 9 tally no customers as the number, AV time and the mean, 10 and Var time as the variance of time in bank 11 accumulate avg util as the mean, and Var util as the 12 Variance of status 13 accumulate Ave waitline length as the mean, and 14 var waitline length as the variance of N wait line 15 end B: 1 main 2 let status=idle 3 schedule an arrival now 4 schedule a stop simulation in 8 hours 5 start simulation 6 end C: 1. Event arrival 2 schedule an arrival in exponential F(10.,1) minutes 3 create a customer 4 let enter time (customer)=time V 5 if status=busy 6 file the customer in the wait line 7 return 8 else 9 let status=busy 10 schedule a departure given customer in Uniform F(56.,15.,1) minutes 11 return 12 end D: 1 event departure given customer 2 define customer as an integer variable 3 let time in back=1440.*(time v-enter time(customer) 4 destroy the customer 5 if the wait line is empty 6 let status=idle 7 return 8 else 9 remove the first customer from the wait line 10 schedule a departure given customer in Uniform F(5., 15., 1) minutes 11 return 12 end E: 1 event stop simulation 2 start new page 3 skip 5 lines 4 print 1 line thus 5 single teller wait line example 6 skip 4 lines 7 print 3 lines with no customers, av time, and var time thus 8 Number of customers = ********* 9 Average time in bank = ****.**** 10 Variance of time in bank = ****.**** 11 skip 4 lines 12 print 2 lines with avg util and var util thus 13 Average teller utilization = ****.**** 14 Variance of utilization = ****.**** 15 Skip 4 lines 16 print 2 lines with avg queue length and var queue length thus 17 Average wait line length = ****.**** 18 Variance of wait time = ****.**** 19 stop 20 end 

Figure 8.12: Simscript bank teller pension code.

The main program or section is shown in section B. This portion sets up the initial conditions (i.e., setting the status of the teller to idle, scheduling the first arrival, and scheduling a stop in the simulation). The next three sections define the arrival, departure, and stop events. The arrival event schedules the next arrival to keep the event flow going, creates a customer, gives it time information, places it in the wait line, and schedules a teller service if the line is empty. The departure event computes a customer's time in the bank, removes the customer, and schedules the next customer. The stop event outputs the collected statistics.

8.4.4 Slam II

Slam II, a simulation language for alternative modeling, was developed by Pritsker and Associates, West Lafayette, Indiana, in the late 1970s. It is a combined modeling language providing for queuing network analysis, discrete event, and continuous modeling in integrated form. Slam II provides features to easily integrate the three forms.

At the highest end the modeler can use a network structure consisting of nodes and branches representing queues, servers, and decision points to construct a model of a system to be simulated. This, in turn, can be easily translated into Slam II code. Additionally, Slam provides the ability to mix events and continuous models with network models by use of event nodes that call event code for discrete and/or continuous models. As in the previous languages, the event-oriented Slam models are constructed of a set of events and the potential changes that can occur with each of them. These events define how the model interprets the event and state changes. Slam provides a set of standard support subprograms to aid the event-oriented modeler. As was the case in GASP, the Slam continuous models are built by specifying a set of continuous differential, or difference, equations that describe the dynamic behavior of the state variables. These equations are coded in FORTRAN (Slam's base language) using Slam's state variables.

Slam II uses a set of basic symbols to describe the system being modeled, as does GPSS. Figure 8.13 depicts the basic Slam II symbols and their associated code statements. Only the first three characters of the statement names and the first four characters of node labels are significant. They will be used in the example of the bank teller. As before, we wish to have customers arriving on an average of every 10 minutes with an exponential distribution and the first one to start at time 0. Additionally, the teller services the customers with a uniform distribution from 5 to 15 minutes. The resulting Slam network model is shown in Figure 8.14. References to nodes are made through node labels (NLBLs). When a node label is required, it is placed in a rectangle and appended to the base of the symbol.

 
Figure 8.13: Basic symbols and statements for Slam models.

Figure 8.14: Slam II bank teller problem network model.

The code for this network is shown in Figure 8.15. The first line of the code defines the modeler, the name of the model, and its date and version. The second line defines the limits of the model and files one USR attribute and up to 100 concurrent entities in the system at a time. Line 3 identifies this code as network code, and line 4 creates customers with a mean of 10 minutes exponentially distributed. Line 5 defines queue 1 as a teller with no initial customers in its queue, an infinite queue with service uniformly distributed from 5 to 15 minutes. Line 7 takes statistics or time in system from entities as they leave the server. Line 8 indicates that the simulation will run for 100 entities and then end.

 1                   Gen, Fortier, Bankteller, 5/22/2002,1; 2                   Limits, 2, 1,100 3                   Network 4                   Create, Expon(10.), 0, 1; 5                   Teller Queue(1),0,~; 6                   Activity (1)/1, Unifrm(5.,15.); 7                   Term 100; Colct, Ini(1), system time„1; 8                   end networks; 

Figure 8.15: Slam II bank teller problem code.

This code is extremely simple and provides much flexibility as to how to expand the system. To look at the tellers' operations in more detail, the queue could be replaced by an event node and the code for the teller event supplied to model (very similar to the code seen in earlier figures). (See [17].)

---