Modeling with Arena
The modeling of simple processing or storage steps is fairly straightforward, by picking the appropriate Arena component (basic process) and installing it with the proper parameters. It becomes interesting when components start to interact.
The simplest form of interaction is sequencing. The output of one component is connected to the input of another component, e.g. to model processing steps that follow each other.
By connecting outputs to inputs, a loop can be created that represents an iteration.
An example of iteration can occur when products are tested and if the test fails some work has to be redone.
There are also components that make a choice. These components have one input and two or more outputs. Depending on a condition, the input entities appear at one of the poutputs. This condition can be deterministic, e.g. when a loan is requested exceeding a certain amount A another path should be followed than loan requests for less than A.
It can also be nondeterministic, i.e. depending upon some random value.
We call a set of components that are connected by sequencing, choice and iteration a process. The ferry example shows three processes: cars that wish to travel from A to B, those that wish to travel from B to A and the ferry (which executes a loop).
When the modeled system is large, it will consist of many processes that do not interact very much. You may compare it to the situation in real life where many persons mind their own affairs, like driving cars or accessing the internet or whatever. Only in some special situations, e.g. when two cars meet at an intersection, the persons become aware of each other and must behave in a synchronized way, e.g. by giving or taking priority (or by colliding).
The way to model in Arena components that only interact occasionally is by using resources. In the above example, the road crossing is modeled as a resource. Initially, there are no cars at the crossing and the resource is available. Any car that wants to pass must seize the resource, then cross and finally release it. If a car wants to pass and the resource is occupied, it must wait until it becomes available.
When resources are not needed, processes are concurrent. When conducting a simulation, the computer will of course execute the steps of each process in a definite order, but the modeler of the system does not have to worry about that. He only starts to worry when the processes start to interact and must define resources and a behavior w.r.t. them in order to model a proper interaction.
We illustrate our approach with the ferry example. As mentioned, there are processes for cars that wish to travel from A to B and those that wish to travel from B to A. An A to B car driver wants to get on board at bank A and then to get off at bank B as soon as possible. In order to get on board, a resource is needed: a place on the ferry. In order to seize this resource, the ferry has to be at bank A. When getting off board, the ferry has to be at bank B. Also the cars cannot seize the place resource at the same time: they enter the ferry one at a time, so another resource (bar A) is needed.
In a simple model, the ferry may be modeled as a resource. However in the present model, the ferry interacts with resources by seizing and releasing bars. So it is natural to model it as a process that performs a never-ending loop.