8.3 Project II: Simulation Environment

This project consists of two parts: Simulation of a group of machines and development of general abstractions for simulation.

8.3.1 Part 1: Simulation of a group of machines

The goal of this part is to construct a model, that makes it possible to simulate a collection of machines, making it possible to evaluate the capacity of the machines in relation to a given flow of production orders.

The system consists of a number of machine groups. Each machine group consists of a number of identical machines. A single machine can handle part of an order.

A production order is characterised by a sequence of machine groups MG1, MG2, ..., MGi and an associated sequence of manufacturing times T1, T2, ..., Ti. The order must therefore be fulfilled by one machine in group MG1 for a time period of T1, followed by a machine in machine group MG2 in T2 period, etc.

New production orders are placed in the system at irregular times. At any given time, the system will have a number of orders under manufacturing. This may cause queues to build at certain machine groups if there is not sufficient manufacturing capacity in the machine group.

The simulation model must simulate arrival and manufacturing of a sequence of production orders for a given period of time. In the simulated period of time, the system must at regular intervals print the number of orders, waiting at each machine group.

8.3.2 Part 2: Development of general abstractions for simulation

As a part of the project, a number of general abstractions (patterns) must be developed. These patterns must enable simulation of discrete events. Describe events is one method for studying the behaviour of large systems of coordinating objects, and for evaluating the effects of changes, that may be too costly to test in practice. The following concepts are characteristic of such systems:

1. A varying number of processes are active simultaneously and gives rise to discrete events at irregular times.
2. Queues may build up when an object must wait to be served by another object, that is serving some other object.

It is not always necessary to deal with real concurrency in the simulation in order to represent processes, that are concurrent in the system we want to make a simulation model for. It is most often sufficient to maintain a sequence of objects with markings of the time of the next time they need to be activated.

An order in the model can e.g. be represented as a process, that wanders from machine to machine, requesting for service. If the machine is idle, the order can immediately be effectuated and the machine can simulate busy for the period of time, it takes to deal with the order. If the machine is busy, the order must wait in a queue of orders, waiting to be serviced by that particular machine. When the machine is finished dealing with an order, it can fetch another order from the queue.

The simulation model will use the concept of simulated time that often is represented by a variable time that denoted the current time and which is updated at certain occasions. The active phases of a process is usually dealt with instantaneously with respect to the simulated time, since it is difficult to simulate a contiguous span of time.

The passing of time is often simulated by the active process suspending execution for some period of time T and the process will then be resumed, when the global time variable have been increased with T.

The general abstraction mechanisms must therefore include:

1. A process concept for simulation of simultaneous processes.
2. A queue mechanism that allows processes to wait. This will imply an operation, e.g.
   wait(Q)
   where Q is a queue and where the result is that the calling process is suspended and entered into the Q. There must also be an operation, e.g.
   activate(X)
   where X is a suspended process, that is removed from the queue, where it is waiting and then resumed.
3. A concept of time. This may be a variable time and a operation , e.g.
   hold(T)
   hat suspends an active process for T time units.
4. An operation to start the simulation, e.g.
   simulate(startProcess, endTime)
   where startProcess is the first active process and endTime is the time, where the simulation is to stop (it is assumed, that the simulation starts at time 0).

8.3.3 Part 3: Development of an interface for simulation

Finally, this project can be extended with demands for constructing an interface, either for the specification of a simulation, or for visualising the dynamics of a running simulation. This interface construction can be realised using GuiEnv or using Bifrost.

8.3.4 Remarks:

It is not expected that this project will result in a full-fledged simulation system. It is part of the project to restrict the project properly and to make the more informal parts of the project formulation precise. The main effort must be places on development and implementation of the general abstractions for simulation.

The design of the system should cover all important aspects of the project. Restrictions must be stated precisely. The implementation should also cover all important aspects. It should be relatively easy to add missing functionality (e.g. without making major changes in the program).