ASM Simulation


The ASM toolbox provides a flexible discrete-event simulation model, designed for simulating interconnected and iterative processes such as found in engineering design. The toolbox is intended to simulate 'one off' processes, such as projects, in which each task might ideally be visited only once. In such situations complexity arises from the structure of information flows between activities, which constrains the sequence in which they can be executed, combined with the possibility for some tasks to 'fail' and require rework of certain predecessors (depending on the information flow structure). The ASM simulation algorithm helps to calculate where this rework will occur and thus what its impact will be.

ASM is not designed to model and simulate 'flow' processes, such as manufacturing lines (for this, see the Organisation Dynamics toolbox).

ASM process simulations can be created using simple probabilistic constructs or can be 'programmed' to have specific behaviour, depending on the modellers requirements. It is possible to create 'virtual experiments' to understand the impact of changes to a process, or to explore its sensitivity to certain parameters (such as task durations) and export results to Excel for further processing.

Overview of the simulation logic

An ASM model comprises a set of tasks and deliverables. Each task requires the deliverables which are connected as inputs to be created by a predecessor, before it can begin. The task may also require certain resources to be available, and may compete with other tasks for those resources - according to its priority. The task takes a specified duration. When it is complete, one output scenario is selected. Depending on which scenario is selected, a different route through the process may result. This may involve the creation of deliverables for the first time, or may trigger an update of deliverables which were already created, potentially resulting in iteration of one or more tasks.

Each of these actions can be specified in a very simple way, eg. as a probability of task failure or a probability distribution of task duration. Each aspect of the behaviour of the task can also be programmed using variables and functions of those variables. This provides a flexible capability to set up virtual processes, which can be used as the basis of computational experiments to explore the properties, behaviour and performance of those processes or to established how the cost/duration might respond to proposed changes.

Creating an ASM simulation

Typically the following process is followed to create an ASM simulation (see below for practical hints and tips):

  1. Decide on the application (see below for some examples)
  2. Build an ASM process flow model which conforms to the logic of the ASM simulation
  3. Configure the properties of tasks in the model, as required, possibly using simulation variables and resource limitations for more advanced behaviour
  4. Use the debug mode and the Gantt chart to ensure the simulation logic runs as expected
  5. Run simulations
  6. Use the simulation results explorer to view/export the results.
  7. Design and execute simulation experiments to analyse and explore different configurations of the process.

When creating models which incorporate iteration, it is important to understand the task interruption model used in the ASM.

Hints and tips for creating an ASM simulation

 The ASM simulation logic with default setup of all tasks' preconditions is able to correctly determine the sequences of tasks that emerge following rework, even if a model contains multiple, non-nested, intertwined feedback paths. 

It is necessary that red arrows emerging from iteration constructs always 'feed back' in the process flow, such that you can trace a path through to the task that caused the iteration once again. All black arrows must 'feed forward'; no cycles of black arrows may exist or the simulation will not terminate.

Although the ASM can correctly simulate any model that follows these rules, it is often best not to think of simulation as a 'black box' which creates all the possible processes from any model you feed it. When building a model, it is important to test it rigorously by viewing different Gantt charts, to ensure that it is correctly configured and behaves in the way you expect, before drawing any conclusions from simulation.