SIMON(ID:6584/sim023)

Algol-based simulation language 

for SIulation MONitor

Simulation language based on Tocher's three phase simulation model, and created as a series of 20 extensions to Algol 60 revised.

Paul Hills, Bristol College UK 1963
Related languages
ALGOL 60 => SIMON   Based on
SIMON => SIMON II   Evolution of
References:
  • Hills, P.R. "SIMON - a Simulation language in ALGOL" view details Extract: Introduction
    INTRODUCTION
    The simulation by digital computer of industrial plants and processes is a powerful method of'the Operational Research Analyst. Briefly the method consists of setting up in a computer a system which behaves in sufficient detail in the same way as the process of which it is a model. The construction of this model alone leads to a greater understanding of the process, but once built it enables the effects of altering the control system or the process itself to be investigated without effecting the real plant. Also future or hypothetical plants may be modelled and then tested without any need for real construction.

    Programming such simulation falls into three parts:
    1.   Storage space must be allocated to hold-all the quantities representing the geographical and the functional relationships between the entities making up the process and this storage must be sufficient for all possible configurations of the process;

    2.   A control system must be set up to make all the changes of relationship in the model which take place with time;

    3.   An initiation and monitoring system must be set up which sets the inter-relation of entities at some starting point and then provides the 'visual' contact of the analyst with the model.

    The writing of such programmes will obviously be both laborious and complex unless some effort is made to provide an automatic programming language. The general purpose languages such as FORTRAN are not in themselves sufficient for this purpose and much work has been done towards providing special purpose languages. Once developed such languages may have wide use in all types of control and management problems.

    Several languages exist or are being developed for simulation purposes. It is the purpose of this paper to describe a language, SIMON, which is in the form of a set of ALGOL procedures and which may be used therefore on any machine which has an Algol compiler.
    Furthermore, since the procedures are in Algol, they may be modified or extended as desired by the programmer.

    Simon has been used on Elliott 503 and 803, English Electric KDF 9, and I.C.T. Atlas computers. Extract: Simulation Model
    Simulation Model
    Simon is designed to be used for writing the programme for a simulation using the Tocher model. In this a series of machines (called in  Simon, entities) is formulated, each of which can exist in a number of discrete  states. These machines must be so chosen that, by describing the state of each  machine at a given time, the state of the model is entirely described at that  time.
    Two methods are used for storing the machine-state information, corresponding to two common ways in which access  to the information is required. First, information is stored in locations  allocated to an entity so that direct access to the state of a particu­lar  machine may be made. Secondly, entity names may be added to lists of entities  (called in Simon, sets) with some common attribute. This is so that any machine  having a particular state may be found. This method, since the lists are  ordered, may also be used for the formation of queues.
    As simulation time progresses, the state of the model will change and since the machine states are discrete the  changes will be instantaneous and occur at intervals of time. It is pertinent to  note here that of course many real-life processes have continuous changes taking  place, for example a tank may fill slowly and continuously. However, this may be  approximated to as closely as necessary by choosing as many states for the  machine representing the tank, between empty and full, as required. Between  state changes the model will remain unaltered and it is only necessary then to  observe it at state-change time. Simulation time can therefore jump forward over  the intervals between changes. At any time, after the change at that time has  been made, the time must be found at which the next change takes place so that  the appropriate jump may be made. This time will be the time at which one of the  machines in the model will change its state.
    At any time the model machines will fall into two classes; those engaged in activities which will end at a time in the future merely due to  the passing of time and those which are in 'waiting' states which will continue  for ever without the intervention of another machine. Tocher has called the  former time-dependent and the latter time-independent. In order to find the next  event it is necessary to inspect the times at which the time-dependent machines  will change and choose the earliest. These time values will have been given to  their machines when the machines were set into the time-dependent state  according to the way in which they might occur in practice, by sampling from  probability distributions. The storage of the time values is made in locations  associated with the entity and in order to facilitate the search, the names of  machines in the time-dependent state are added to a list (called in Simon,  timeset), Some machines will be time-dependent in certain states but  time-independent in others, so the addition and withdrawal of names to and from  the timeset will be done as the simulation progresses.
    Extract: Programme Structure
    Programme Structure
    Simon places no restriction on the way in which the programme is written, but a three phase structure has been  found most convenient and the facilities have been provided with this in view.  The three phases are as follows:

    A phase
    contains the search among the members of timeset for the member with the least time and the jump forward of  simulation time to that time.

    B phase
    contains the 'disengaging' instructions which will bring the time-dependent state of the particular machine  to an end. These will therefore consist of instructions for each of the machines  which can be time-dependent (or if several machines are similar then an  instruction for them all). The jump from A phase to the appropriate B phase  instruction is made by storing as part of the descriptive information associated  with entities the label number of the B phase instructions.

    C phase
    contains the 'engaging' instructions which, if conditions are right, set up new time-dependent states.  These are preceded by the necessary conditions for the change to be made and are  tested in turn. If a conditional test is passed then the instruction is obeyed,  but this may release a machine which will allow the condition for an  instruc­tion written earlier in the programme. At the end of each  conditional instruction there­fore a jump is made to the start of C phase.  After the last condition has been tested and failed a return is made to A  phase
    Extract: Initiation, Monitoring and Completion
    Initiation, Monitoring and Completion
    Instructions for setting the model in a starting position, which is usually some fre-quently occurring state, precede the A phase and are obeyed once at the start of the programme. They declare the machines as entities, state how much information is to be associated with them, declare the names of sets which will be used, read in any dis-tribution data to be used in sampling, state the appropriate B phase label for time-dependent entities and then describe the starting state. After these instructions the A phase is entered into and then the programme cycles through the three phases.

    Monitoring is done by including as a C phase instruction the printing of the relevant data in suitable format or the storage of this data in suitable form for later printing if required. Special routines are provided for the formation of histograms as the simu-lation proceeds.

    Also in the C phase instructions will be a completion instruction which will be preced-ed by the condition that 'if the required running time has elapsed then' and will con-tain any final output and the stop instruction. Extract: Simon Facilities
    Simon Facilities
    The facilities described here are the improved version 'Simon II' (June 1965) which is a modification of 'Simon I' (June 1963) in the light of experience and use.

    5.1.    Entities and Sets
    1.
    ENTITY (NAME, REFERENCE NUMBER);
    specifies that the name, which must have been declared in the programme heading as an integer array, is to be used to represent an entity; The array dimensions will de-pend on the number of pieces of state information to be stored. However Name (O) is used for storage of the system identifier value and is therefore reserved. The entity name as such when it is to be added to sets must be called as Name (O). The other values of the index may be used for storage of numbers representing the state infor-mation. It is recommended that names for these numbers should be used to avoid errors. For example if a man's location is to be stored ('man' having been declared to be an integer array (0:1) and also specified to be an entity) then the following may be used:-
    location: = 1; home: = 1; office: = 2; man(location): = home;



    2.
    GROUPENTITY (NAME, NUMBER OF MEMBERS, REFERENCE NUMBER);
    allows the specification of a series of entities of like name at one go. In this case 'name' will be declared as a two dimensional array, the first index range being (O:N) where N is the number of members.

    In both cases the reference number can be any integer but it is intended that this should primarily be used as a store for the appropriate B phase instruction label num-ber for any entity when found in the timeset. For entities specified in a groupentity all members will have the same reference number but distinction can be made by use of 'memnum' described below.

    3.
    SET(NAME);
    specifies that the name, which must have been declared as an integer identifier, will be used as a set name.


    5.2    Listing procedures

    4.
    ADDFIRST(NAME) TO: (SET NAME)
    adds the given entity name to a given set name, to make it the leading member.

    5.
    ADDLAST(NAME) TO: (SET NAME)
    as (4) only as last member.

    6.
    BEHEAD(SET NAME);
    erases the first member of the given set.

    7.
    BETAIL(SET NAME);
    erases the last member of the given set.

    8.
    DELETE(NAME) FROM: (SET NAME);
    erases the specified member from the given set.

    9.
    ROTATE(SET NAME,N);
    rotates the given set list making first last, second first etc.N times.


    5.3    Implicit Names
    10.
    HEADOF(SET NAME);
    is used to refer indirectly to the entity name at the head of the given set name list.

    11.
    TAILOF(SET NAME);
    as 10, only tail instead of head.

    The above set statements may be used in depth if required, i.e. ADDFIRST TAILOF(SET 1)) TO: (SET 2);


    5.4     Reference to Numerical Values
    12.
    SIZEOF(SET NAME);
    takes the value of the numbers of members in the given set list.

    13.
    MEMNUM('GROUPENTITY' NAME);
    takes the value of the index number of one of a group of entities with a common name.

    14.
    REFNUM(ENTITY NAME);
    takes the value of the specified reference number from the entity.


    5.5     Time Values
    15.
    SETTIME(ENTITYNAME) TO: (VALVE);
    stores the given value (which must be integer) as the time to be associated with the entity referred to. 'Value' may also be replaced by any arithmetic operation giving an integer result.

    16.
    TIMEVALUE(ENTITY NAME);
    takes the value of the time associated-with the entity.


    5.6     Distribution Sampling
    17.
    RANDOM(NUMBER);
    takes the next value in a stream of uniformly distributed random integers, range 0 to 99; where 'number' specifies which of 10 streams is to be used. A special call with number taking the value zero merely reads into the computer a random number from a data tape which may be of use in 'de-bugging'.

    18.
    DISTRIBUTION(NAME, REF. NUMBER);
    reads in the co-ordinates of a cumulative probability distribution in the order value, percentage probability. The first value of percentage probability must be zero and the last 100. Preceding this data must be the number given as reference number in the call. This is to check that the right data has been presented when the call is made. 'Name' must be declared as an integer array dimension (0:20).

    19.
    SAMPLE(DISTRIBUTION NAME);
    takes a value sampled randomly from the distribution date of the given name.




    5.7     Data Compiling
    20.
    HISTOGRAM(NAME, LOWBOUND, ZONEWIDTH);
    provides for the compiling of a histogram to have the given name. The histogram will have eleven zones: one below the value given by lowbound, nine within consecutive zone-widths above the lowbound and the final above 9 zonewidths above lowbound.

    21.
    ADD TO(NAME, VALUE);
    adds the specified value to the named histogram.

    22.
    WRITEDOWN (NAME,'TITLE')
    prints out the named histogram in tabular form preceded by the specified title. Also printed are the mean and variance of the values in the histogram.


    5.8     A phase Scan
    A special facility for use in the A phase.

    23.
    SCAN(TIMESET) FOR: (MEMBER) WITH: (LEASTTIME);
    looks at those entities which are in the timeset at the time when the instruction is obeyed and finds the one with the smallest timevalue associated with it. 'Member' may then be used as an indirect reference to the member found and 'leasttime' takes its time value.
          in Hollingdale, S.M. (ed.) "Digital Simulation in Operations Research", English Universities Press, London, 1965 view details