Logic of the ASM simulation

Overview of ASM simulation logic

The basic logic is very simple, although it quickly builds up to give complex behaviour - especially in large models including interconnected concurrent workflows with many possibilities for rework. 

• The yellow boxes are simple tasks. They take a certain set of inputs (the input arrows) and, once complete, produce a certain set of outputs (the output arrows). All inputs are required together and all outputs are produced together.
• The red boxes are compund tasks. Similar to a simple task, but can have one or more output 'scenarios'. Each scenario represents a different 'forward branch' and contain one or more deliverables. 
• The blue ellipses are deliverables, representing information.
• The green diamond is an iteration construct - a decision gate which when it is visited can fail, causing update of previous information (upstream) or can create new information (downstream). The red arrow indicates the 'failure' scenario -  actually named 'Iterate again'. The black arrow represents a 'success' scenario connected. Note that many deliverables can be connected to any scenario, eg. failure could update multiple previous deliverables.
• It is possible to connect any type of node to any other type for the ASM simulation. The different sorts of connections are interpreted as follows:
• Tasks can either be connected to blue ellipses (deliverables) or can be connected directly to another task. In terms of simulation, a direct task-task connection is treated as an 'implicit deliverable' - in other words, it behaves in the same way as though a single ellipse were connected in-line between the two tasks.
• A connection from a task to a deliverable indicates that when the task is complete, it creates or updates the deliverable. Where a deliverable has more than one input arrow from predecessor tasks, the logic only requires one of those inputs to be 'activated' for the deliverable to be created or updated. An example of this situation is visible in the screenshot below: the ellipse labelled 'B' on the top-right of the worksheet. In this case, the model indicates that this information is initially created by cokmpletion of the simple task just above the ellipse, which feeds into it via an arrow. However, failure of the iteration construct (green diamond) located at the bottom of the diagram may later cause that information to be updated - in which case certain tasks requiring that information, directly or indirectly, must eventually be revisited.
• When a task has multiple input arrows from predecessor tasks or items of information, the task (usually) requires all those items of information to be created by predecessors before it is able to start. (if information which is used as input to a task is not created as output of any other task, the simulation assumes that information is an 'input' to the process and this information will be made available from the start of the simulation). Depending on the configuration of the task, it may be re-attempted when only one of the inputs is updated by rework - it may require all the inputs to be updated by rework before the task is re-attempted - or it may require a specified sub-set of inputs to be updated before the task is re-attempted.The appropriate configuration depends on the structure of the model and on its desired behaviour. More information on configuring these preconditions for task execution is provided below.
• When a deliverable is connected directly to one or more other deliverables, this indicates a 'data' relationship which indicates that the downstream deliverable contains/is comprised from the information in the upstream deliverable(s). Furthermore the simulation assumes such deliverables are created when the directly-upstream deliverables have all been created, and that they are updated when one or more of those upstream deliverables is updated by rework. The creation/updation of a deliverable which contains/is comprised from other deliverables happens immediately in the simulation, ie. there is no time delay and it is assumed that the creation of the downstream deliverable does not require a specific task to be performed.