The making of decisions is a common process in all human activities. Many decisions can be represented in an `IF - THEN - ELSE' format. For example `If the traffic light is red stop the car else proceed' or `If the bank overdraft exceeds [sterling]100,000 the company must cease trading'. Likewise many systems both natural and man made are subject to the influence of stochastic variability and decisions are made, in effect, on the basis of probability. For example : `30% of all customers will pay by credit card' or `5% of all components produced will have faults and 1% of all components will have to be scrapped.' All simulation languages will provide features to model both probabilistic and deterministic decisions. In `ARENA' this role is taken by the BRANCH block.
The BRANCH block is quite sophisticated and so we will start by looking at its simplest applications first.
A component can be processed on either a fast or a slow lathe. The decision has been taken to use the fast lathe for components with a processing time in excess of 10 time units. We can model this situation in ARENA with a BRANCH statement using a single IF and ELSE clause as follows :
The condition `proc_time > 10' can be expressed, as here, in `C' syntax or if you are more familiar with it FORTRAN syntax `'proc_time.GT.10'. Appendix A has a complete list of syntax options for use with IF clauses. The parameter `Max number of branches' has been defaulted to `infinity' in this example. We will return to this later.
Simple probabilistic branching is handled in the same way as the following example illustrates.
In a manufacturing process 5% of the products are found to be defective and require reworking, 1% are found to be only fit for scrap and the remainder can be sent on for packing. in ARENA :
In this example the maximum number of branches to take is set to 1. notice that the probabilities sum to 99% effectively leaving 1% for the scrap queue. It is up to you to ensure that this is always the case !. This particular block has three branches and the order of evaluation is always from top to bottom. Thus when an entity arrives at the BRANCH block a uniform random number between 0 and 1 is generated. If the number is less than or equal to 0.94 the entity proceeds along the first branch to PACK_Q. If this fails a second random number is generated and if this is less than or equal to 0.05 the second branch is taken. If both of the former tests fail then the entity leaves the branch block routed to the SCRAP_Q.
This ordering is important since it is possible, in the same BRANCH block to mix both deterministic and probabilistic branching. Consider the following two statements which can generate quite different results :
In (a) if the attribute A 1 is greater than 2 then the entity will always transfer to L1. However in (b) there is a 50% chance that an entity with A1 greater than 10 will be transferred to L2. In both examples we assume only one branch is taken.
Let us now turn to the parameter which defines the maximum number of branches to be taken. At first this may appear to be slightly mysterious, why for one entity entering a block should we expect more than one to leave? In fact in many situations this is perfectly normal as shown by the following example :
An entity in the form of a lorry load of goods arrives at a warehouse. The goods are checked and if found to be satisfactory are sent to the warehouse (90%) and if faulty are held in goods reception. In either case a report is sent to the office. Using ARENA we would model this situation as follows (First setting the maximum number of entities to 2) :
The copies of the original entity generated have all the attribute values of the original entity. The is a small difference between the original and the copies but that need not concern us in this introductory course.
Two final points concerning `BRANCH'
* If you simply want to generate copies of an entity do not use `BRANCH' but use the simpler `DUPLICATE' command instead.
* For a small number of links to a `BRANCH' block using the ARENA linking tool improves clarity but if a large number of branches emanate from the block use a label or a `ROUTE block to effect the transfer.
It is a common requirement that the capacity (quantity) of a resource will need to change during the simulation. For example a shop may have four assistants who all work from 9.00 a.m. to 12.00 a.m. From noon until 2.00 p.m. each assistant in turn is given a half hour break and then for the remainder of the opening hours (2.00 p.m. until 5.00 p.m.) all four assistants are again working in the shop. Fig 8.13 shows the change in capacity of the resource `ASSISTANT' during the working day.
Two of the simplest ways in ARENA of changing resource capacity are to use the `SCHEDULES' element or the `ALTER' block.
Essentially the `SCHEDULES element consists of a schedule identifier (number or name) and a list of number pairs which define the schedule. As an illustration take the example above. We must supply a schedule identifier (e.g. SHIFT_ROTA) and a list of number pairs in the sequence Capacity*Duration repeated.
Data for Schedules Element
|
Schedule |
Capacity |
Duration |
|
SHIFT_ROTA |
4 |
3 |
|
3 |
2 |
|
|
4 |
3 |
When capacity is increased the effect is immediate with the number of idle resources being increased by the capacity change. For a decrease in capacity there is a complication to the extent that all the resources may be `busy' at the time the schedule calls for a reduction. There are several ways to handle this situation but only the default option (known as `ignore') is discussed here. When a capacity decrease is called for the required number of idle resources are, if available, removed. Otherwise the remaining resources are removed as they become available when an entity passes the appropriate `RELEASE' block.
The schedules element needs to be linked to a specific resource which is achieved using the `RESOURCES' element where we change the field `Capacity' to `Schedule' and follow it with the name of the particular schedule we wish the resource to follow. You will immediately see that many different resources can follow a common schedule but a single resource cannot follow more than one schedule.
A useful feature of the `SCHEDULES' element in ARENA is that it auto-repeats. For example if two drills are available for the first two 8 hour shifts of the day but only one is available for the remaining 8 hour shift this is represented as :
Data for Schedules Element
| Schedule | Capasity | Duration |
| Drill_avail |
2 |
16 |
|
1 |
8 |
This defines the schedule for a twenty four hour period but if the simulation runs for five consecutive days the schedule will automatically be repeated each day.
The `ALTER' block is usually employed to make a single change in a resource capacity at some point in the model. This, for example, makes it very useful for modelling the removal of a piece of machinery for servicing at a particular time. The same rules for capacity decrease are used as for the `SCHEDULES' element with `ignore' as the default option. If an attempt is made to reduce resource capacity below zero the value defaults to zero.