8.4.2 Using BLOCKS.TPO & ELEMENTS.TPO

We will now repeat the example using the BLOCKS and ELEMENTS templates.

Staring with a blank modelling screen the first task is to add the BLOCKs and ELEMENTS panels to the model. As an alternative to the method used in the last example use the Template - Attach submenu in the model development window.

Adding the blocks is identical to that followed in 8.4.1 above. When complete the model should look like the following (Fig. 8.4) :

Often the automatic linking of blocks is not convenient. In this case place all the blocks first and then link them appropriately with the linking tool which is the third button from the right on the tool bar. A successful link can only be made between the appropriate points on the blocks which are indicated by the small black squares in Fig. 8.4. To make a link as shown between the `QUEUE' block and the `SEIZE' block first `Click' on the depart point of the queue block then drag the link to an appropriate point on the diagram and `click' again. This will drop an anchor at the point selected and you can continue in this way until the entry point of the `SEIZE' block is reached.

As with the example in 8.4.1 it is necessary to add the appropriate parameters to each block by opening the data form for the block. The values to use are shown in table 8.1 Any other parameters in the dialog boxes are allowed to assume their default values.

We now need to add an experiment frame as shown in Fig. 8.5

The order of the elements is irrelevant as the elements are all `stand alone'. Their function is to define the parameters used in the model and with the `REPLICATE' element the experimental conditions. The appropriate parameters are indicated in table 8.2

The model should now run and produce the answer 47 as before.

To view the answer this time when the simulation has run to completion but before selecting end click on the command button. The summary report is stored in a text file in the same directory as the model file and with the same name but with the file extension `.OUT' thus it can be recovered for redisplay at any time but it will be overwritten if you re-run the model.

This example can be found as WORK0B.DOE on the solutions disk.

From the example above the relationship between the model frame blocks and the experiment frame elements should be becoming a little clearer. For example if the workpiece entity needs to seize a `Lathe' this is only possible if a resource lathe has been specified in the `RESOURCES' element. The `RESOURCES' element contains all the information necessary to completely specify the role of the lathe in the model (e.g. how many lathes are available, does their availability follow a schedule ? etc.). Similarly for all the components (variables, attributes, queues, counters etc) of the model. In the remainder of this chapter we will examine some of the basic modelling constructs available in ARENA and how they are used. You should refer to the appendix to the chapter for a fuller description of each block or element discussed and, of course, to the ARENA handbooks for a complete description of all the modules and templates.

As we proceed with our discussion you will encounter a set of 10 worksheets which you should complete when the occur before continuing to re-inforce and deepen your understanding of the concepts discussed.

8.5 CREATE, ASSIGN, QUEUE

Let us commence by examining how these three blocks are used in our example model. The `CREATE' blocks function is to generate new entities for the model. To fully specify the creation of entities we need to provide four pieces of information :

1. The time at which the first batch of entities will arrive {0}

2. The number of entities contained in each batch {1}

3. The inter-arrival time between batches

4. The total number of batches that will be created {}

Notice that by changing these four parameters you can use the `CREATE' statement to control a very wide range of entity arrival conditions into the model. For example you could declare the first batch of entities to arrive at time 3.6 time units, each batch to contain 12 entities and the inter-arrival time to be normally distributed with a mean of 7 time units and a standard deviation of 1.5 time units creating a total of 125 batches (i.e 1500 entities in total). Initially all this may be a little daunting but fortunately (as with many blocks) ARENA provides default values for each of these parameters as indicated within the {} braces above. In our example we defaulted everything except the inter-arrival time which we fixed at the constant value of 10.

The `ASSIGN' statement is used to give values to attributes and variables. The values given can, as in the example above, be simple numerical values or defined by an equation which my involve other attributes and variables. In the example we have assigned a value from the uniform distribution between 8 and 12 minutes to the attribute `process_time'. Attributes are carried through the model with each entity having its unique set. In this example the `process_time' will be used by the entity later to control the duration associated with the `DELAY' block. Notice we could have missed out the `ASSIGN' statement altogether and simply entered the value from the uniform distribution directly into the `DELAY' block. We chose not to do this because if we later wish to process different job types on the lathe (see WORKSHEET 1) which have different processing time values we could not put the values directly into the `DELAY' block.

The `QUEUE' block is where we hold jobs until the lathe is available. In the `QUEUES' element we define the characteristics of our particular queue. For example we can define the rule for selecting jobs from the queue. We have accepted the default value of First - In - First - Out (FIFO) but we could equally have chosen Last - In - First - Out (LIFO) or many other possibilities including special rules defined by the user. In practice many queues have a finite size (e.g. only a certain number of people can queue in a Post Office) and this leaves us with the problem of what to do with entities which arrive at the queue when it is full. The ARENA `QUEUE' block provides for this with a diversionary path (known as `BALK') down which the excess entities are sent. A common modelling sequence is to count and dispose of such entities as shown below :