Preconditions

How to define preconditions for a task

Preconditions for a task determine the conditions under which it will become available for execution in an ASM simulation.

Preconditions may be altered by configuration of the options of the pre-conditions tab of the task properties dialog.

When a task is first created, it has a default configuration of preconditions that allows simulation of any task network. This is shown in the dialog below.

In essence, the task will only be possible to start if all inputs are available, at least one input has been updated since the last time the task was attempted, and no work or rework is pending 'upstream'.  For this to work properly, you need to ensure that all Iterate Again (red) arrows point 'backwards' in the task network defined by black arrows, and that there are no cycles of black arrows.

Keep reading below for special configuration examples.

Limiting tasks to start only under certain additional conditions

You can additionally limit when the task will start by entering a function of the variables into the text box. Typically, this would be used to limit the task so it can start only when conditions set by other tasks in the process are met. For instance, you might require a certain number of iterations of a predecessor to be completed, or a certain input parameter to reach a certain level of "confidence" (where confidence could be modelled as a variable associated with the input parameter, that is increased each time some other tasks update that parameter)

Making task start depend ONLY on the state of simulation variables

By disabling all the checkboxes above the text field, it is possible to make the task's preconditions depend ONLY on the function entered in the field. In this case, any input connections to the task shown on the process flowchart are ignored by the simulation algorithm when deciding when the task should be started. When setting up a task in this way, you may wish to use the 'Pre-process' tab to configure the task so that once it is chosen for execution, it updates variables used in the precondition function. This can ensure that the task is not immediately re-selected to attempt again, once its precondition is met.

Making task start depend ONLY on the status of the task's input information (ie. not considering upstream rework)

The default preconditions allow each task to start only if no rework is waiting upstream. This is suitable for most situations. By disabling ONLY the "No upstream work is pending" option, you can configure tasks to depend only on their direct input conditions and the state of simulation variables. This can be useful for advanced configuration of the model, in which you want precise control over when particular tasks will execute. However, it may not be suitable for models that include complex intertwined flows, because it becomes difficult to specify the correct behaviour of each task.

If any tasks do not have the "No upstream work is pending" option selected, a model will usually need careful programming and testing to operate correctly. We have used the following procedure for turning an ASM process map into a simulation model without using the "No upstream work is pending" condition:

1. Start by reducing your ASM process map to a determistic case (set all task durations to be a single value, eg. 1 day) without any iterations (ie. set rework probabilities on iteration constructs to 0) and without any resource limitations (do not assign resources to tasks, or set up resources in the resource tab of the left pane of the main CAM window so that a very large number are available of each, to avoid constraints). This allows all tasks to be started as soon as their preconditions allow, and allows debugging of the flow logic without complicating the Gantt charts.
2. Using this simplified model, in most cases you should expect only one possible process to result (ie. 100 simulation runs would produce 100 processes of exactly the same duration)
3. Use the Gantt chart view obtained by right-clicking a histogram bin in the simulation results to check that the simplified model simulates 'all the way through' - in most cases, all tasks should be executed exactly once. If the simulation is incorrectly structured for simulation, or task properties (especially preconditions) are not correctly configured, some tasks may never be attempted. Others may be repeated (reworked) several times, this is indicated by red bars on the Gantt chart. 
4. To diagnose rework which happens where none should occur in the simplified model, look for ellipses which have multiple 'inputs' from directly-upstream tasks. This should only happen when the multiple tasks represent different ways of creating the same information - ie. where all but one of the tasks creating the information is a feedback from a 'downstream' iteration construct. In all other cases, the multiple inputs are usually supposed to designate an AND relationship - all the tasks are required to complete before the information in the deliverable is finalised. This MUST be modelled using an additional task which 'integrates' the outputs from the upstream tasks and 'creates' the deliverable.
5. Add in one iteration loop at a time and use the Gantt chart to check whether the correct set of tasks are re-attempted when the iteration occurs. Tasks following iteration must be configured with the correct precondition logic so that they are executed at the right time, if iteration occurs or if it does not. Essentially, it is necessary to consider what will happen AFTER iteration occurs. It is usually sufficient to choose from one of two default options provided in the preconditions tab of the task properties dialog: Should the task be triggered as soon as ANY one of its inputs is updated, or should it wait until ALL the inputs are updated? The answer depends on the structure of information flows in the model; typically a task which 'integrates' incoming information, where all the inputs must be updated if the iteration occurs, should be conigured as ALL logic (AND). Others should typically be configured as ANY logic (OR). The appropriate logic for each task can be selected using the radio buttons on the preconditions tab of the task properties dialog.
6. Be aware that iteration loops that 'overlap' cause complicated flow structures and can require careful debugging to configure correctly. In particular, it is possible to create models with tasks that should behave as ANY under some iteration circumstances, and ALL under others. There are two options for dealing with these: either simplify the structure of the model; or program the behaviour of those tasks using process variables and functions as explained on the page Configure ASM tasks.
7. Only once you are happy with the execution logic, add the probabilitistic durations, likelihoods of task failure, resource constraints etc.