# Chapter 8

# SIMULATION USING ARENA

Discrete Event Simulation can be performed using either one or a combination of the paradigms discussed in chapter 2. A quick search of the literature will reveal very many language implementations. However in practice very few of these are widely used. Of the widely available languages SIMAN/ARENA is one of the most popular.

This chapter makes no attempt to teach simulation but concentrates exclusively on techniques for building and debugging models in ARENA which is the latest implementation of the SIMAN/CINEMA system.

## 8.1 Introduction

ARENA is the latest implementation of the SIMAN simulation environment. SIMAN, which is mainly a process orientated package has antecedents going back to the early days of computer based simulation. Pritsker and associates developed two of the earliest discrete event simulation languages (GASP & Q-GERT) in (XXX). Partially out of these languages grew the very successful SLAM language still widely used today. C.D. Pegden who led the original development team for SLAM moved on to incorporate some of the algorithms from SLAM into his own language SIMAN which can also be seen to incorporate features found also in other early languages (e.g. GPSS).

SIMAN is a general purpose simulation language but many of its special features which distinguish it from its rivals are strongly orientated towards manufacturing simulation. Subsequent to the development of SIMAN an animation feature known as Cinema was added. The animation was, and remains in ARENA, a simple pictorial representation of the simulation thus, for example, the relative speed of movement of icons on the screen is no reflection of the relative speed of the entities within the model.

SIMAN suffered from an obscure and not always logical syntax which slows the development of models down. To overcome this problem two simple graphical model building tools (BLOCKS & ELEMENTS) were added to the system. They have both been much improved and incorporated into ARENA.

## 8.2 Structure of SIMAN

To use ARENA it is not necessary to understand the structure of SIMAN in great detail but it does help to have an overview of the system and its basic philosophy of model development. If for no other reason it will help you understand some of the error messages which appear from time to time !

SIMAN divides a simulation project into two basic components : a model frame and an experiment frame. In essence the model frame contains the all the information about the geometry of the model (e.g. position and number of machines, routing of entities, positions for collecting statistics etc.). The experiment frame contains information about a particular experiment to be performed on the model (e.g. the run duration, lists of all queues, statistics to be collected, number & types of resources, resource schedules etc.).

## 8.3 Structure of ARENA

ARENA is built upon SIMAN and when an ARENA model is created it is implemented in SIMAN code which is then compiled and run. ARENA is, in effect, a high level graphical front end for SIMAN in which models are built by placing icons onto a drawing board and then linking these icons or blocks together to define the model logic. In addition to the ease of creating a model ARENA has two major advantages over SIMAN :

- The ARENA template which bring together complex high level modules into single modules whose parameters are accessible via data entry forms.
- The ease of generating an animation of the simulation.

Each icon representing a block or an element performs a specific function or group of functions. The parameters required to carry out these functions can be entered in a `dialog box' obtained by double clicking on the icon. Let us take on simple example : the `DELAY' block.

Any entity reaching this block will will be delayed at the block for a specified time which can be set with the `duration' parameter in the DELAY dialog box (Fig. 8.1)

The duration parameter can be a fixed value, one of the statistical distributions, or a calculation involving entity attributes and variables. In the simplest application all the other parameters (discussed in later sections) can be defaulted.

The movement of entities between blocks can be controlled in one of three basic ways :

- Linking the blocks together using either the automatic linking or the linking tool. In the following example the entity visits in turn the blocks `SEIZE' , `DELAY' and `RELEASE'

- Transfering the entity to a labelled block. Notice in the `DELAY' block there is a `label' parameter to give the block a label if it is to be the target of a transfer and a `Next label` field if you wish to forward the entity to a labelled block.
- Using a special transfer block such as `ROUTE'.