When a simulation reaches a point where any change of state (for any thread) requires a Trigger to proceed, the simulation is effectively paused and control returns to the system. The simulation is now effectively waiting for some form of event (a real world signal) to proceed. The Waiting Triggers list is useful in helping to determine which Trigger should be manually signalled.
Access Analyzer | Simulate | Simulation Events Window
The Waiting Triggers list on the Simulation Events tab is:
- Populated on each Simulation cycle with any Triggers that would have an immediate effect if signalled
- Populated with a discrete set (any duplicates are not shown as a Trigger is effectively broadcast to all transitions at once)
- Activated by double-clicking on the Trigger of interest
- Includes all possible triggers - including those activating transitions on parents of currently nested states
This example shows that the current simulation has hit a point where two possible Triggers can influence the flow of execution.
Due to the nature of Triggers and their effects, the list can refer to each of these example situations equally validly:
- A single state has two outgoing transitions which are respectively waiting for Hold and Pushdown; firing one of these will activate the associated transition in the simulation
- A single state has two or more possible triggers for the same transition, such as a security camera being switched on by a motion detector, sound detector or heat detector
- Two (or more) threads (concurrent regions) each have a state waiting on either Hold or Pushdown; firing one of these triggers will result in the thread(s) waiting on that trigger to proceed while the other thread(s) will remain blocked
- A child state is waiting on one of the triggers while a parent state is waiting on the other; firing a trigger will result in the associated transition being fired and either the child or parent proceeding accordingly
- Any combination of these