In combination this sequence of blocks is very common in models because it models the acquisition for a fixed time period of a resource or group of resources. All we need to emphasise at this stage is that as part of the `SEIZE' block you can define the priority of the seize (lowest number = highest priority) which is important when several entities may require a single resource at the same time. Notice also that you may `SEIZE' more than one resource at a time and later release them at different times. For example if the lathe requires an operator to set up the job on the lathe which can the be allowed to run without operator supervision we could model this as follows
As your models become more complex you will have to guard against some simple errors such as attempting to release more resources than you seized in the first place or forgetting altogether to release a resource ! The latter problem usually manifests itself by the model coming to a halt with an `entity limit exceeded' error as entities continue to wait in the preceding queue for a resource that is never available.
A key data item to collect in any experiment is the number of entities which pass a particular point in a model. In ARENA the `COUNT' block is provided for this purpose. The `COUNT' block is the simplest of the data collection blocks and it is always used in conjunction with a `COUNTERS' element. The `COUNT' block requires a counter ID and an increment (which defaults to 1). The ID can be an attribute name thus enabling a single count block to record totals into several counters.
The count increment can be any expression which truncates to an integer and thus it can be used to collect information other than simply the number of entities passing the block.
In a computer system model there are 5 message types which may be transmitted. If the model entities are messages and we give each entity an attribute message_type then the following `COUNT' block will record in a separate counter the number of each type of message passing this point in the model
In order to function correctly the `COUNTERS' element must define 5 counters with the same names that are used for the 5 attribute values (this could simply be the numbers 1..5 )
A useful feature of the `COUNT' block is that if in the `COUNTERS' element we specify a count limit then when the count reaches or exceeds that limit the simulation run will cease.
The `DISPOSE' block is the method used in ARENA to model the departure of entities from the system. It requires no parameters and simply removes an entity from the model destroying the contents of its attributes in the process.
The `REPLICATE' element controls the conditions under which the model is run and can be used to set up multiple replications with various parameters to define how statistics are handled between replications. Read the appendix to this chapter for more detail on these options. In the example above `REPLICATE' is used simply to tell ARENA to run the simulation for 480 minutes.
In chapter XX you learn the importance of model verification and these two features are an important aid in that process.
An ARENA model can contain many entities, which are apparently moving simultaneously but because the PC is a serial machine ARENA is forced to move only one entity at a time. It operates by moving this active entity through the diagram as far as possible before it encounters a status or time delay (e.g. a QUEUE or DELAY block). It then goes on to move any other required entities at the current simulation time. Time is then advanced to the next event. As a consequence of this it can often be difficult to pin down a logical error in the model. The `TRACE' element and the Debug features are a great help in this debugging process.
`TRACE' has four parameters which define respectively the simulation time to start and stop the trace operating, a list of parameters to display at each trace step and a trace condition which limits the display of trace information to times when the condition is true.
Add to example `WORK0B.DOE' above a `TRACE' element and set the parameters to :
beginning time 0.0
Ending time 10
Trace expression NQ(Lathe_Q)
This will start the trace working at time 0 and stop it at time 10. The value of the number of entities in the lathe queue will be displayed. To view the results of a trace operation either pause the simulation (i.e. press esc) or when the simulation run is complete but before you select end click on `COMMAND'. This will produce an output something like the following :
SIMAN System Trace Beginning at Time: 0.0
Seq# Label Block System Status Change
_____ ________________ ________ _____________________________________________
TIME: 0.0 ENTITY: 2
| 1 | 7$ | CREATE | Next creation scheduled at time 10.0 |
| 2 | 6$ | ASSIGN | PROCESS_TIME set to 9.01852 |
| 3 | 5$ | QUEUE | Entity 2 sent to next block |
| 4 | 4$ | SEIZE | Seized 1 unit(s) of resource LATHE |
| 5 | 3$ | DELAY | Delayed by 9.01852 until time 9.01852 |
| NQ(LATHE_Q) = 0.0 | |||
| TIME: 9.01852 ENTITY: 2 | |||
| 6 | 2$ | RELEASE | LATHE available increased by 1 to 1 |
| 7 | 1$ | COUNT | Counter NUM_JOBS incremented by 1 to 1 |
| 8 | 0$ | DISPOSE | Disposed entity 2 |
| NQ(LATHE_Q) = 0.0 |
One problem with the trace command is that it produces far too much output most of which is irrelevant to the current debugging activity. You should practice using the other debugging features which include :
You should practice using all these features with simple models, where you understand what is going on before you attempt to use them in earnest on a difficult problem in a complex simulation.