Guards and Effects


Guards and Effects are used to control the flow of the simulation and to execute additional actions or effects during the course of a simulation.


Guards and Effects



See also


Guards are conditional statements that are evaluated anytime the simulator needs to decide which path to take next. Guards typically have the following characteristics:

Defined on transitions and control flows to govern how simulation proceeds
Written in Javascript
May refer to variables defined during simulation




Adding Guards

Guards are defined on the transition or control flow in the properties dialog for the connector of interest. A Guard is typically a piece of Javascript that will evaluate to either true or false. For example the following is a conditional statement that refers to a current variable (Balance) being greater than zero. Note the use of the "this" prefix to indicate the variable is a member of the current class context.





Evaluation Semantics

During execution the Simulator will examine all possible paths forward and evaluate any guard conditions. Based on this evaluation the following may occur:

A single valid path forward evaluates to true. The simulator will follow that path.
Two valid paths are found. The simulator will block waiting for some manual input via the console window to resolve the deadlock.
No valid path exists. Same response as when two paths are found - wait for the user to change the execution context using the console window.
No paths evaluate to true but a default (unguarded path) exists. The Simulator will take the unguarded path.





Effects are pieces of behavior that are executed at special times.

On entry to a state
On exit from a state
When transitioning from one state to another (transition effect)


Effects may either be a piece of Javascript code or a call to another Behavior element in the current simulation.




Javascript Effects

A Javascript effect may look like the example below, in which the Balance variable is decremented:




Call Behavior Effects

In the example below the effect is a call behavior effect. In this case it calls into a model Activity named "Decrement Balance" that is defined elsewhere. The simulation will then enter into that diagram/behavior and continue to execute until returning to the point at which the effect was invoked.




Order of Execution of Effects

In complex simulations which may involve transitioning out of deeply nested states into other deeply nested states in a different parent context, it is important to consider the following rules concerning the order of execution:


All exit actions (effects) encountered leaving a nested context are executed in order of most deeply nested to least deeply nested
All actions (effects) defined on transitions are executed next
Finally all entry effects are executed from the least deeply nested context to the most deeply nested.

So the basic rule is all exit actions followed by all transition actions and finally all entry actions.



Note on Javascript Variables

Javascript variables to be accessed and referred to during Simulation execution must be prefixed with either:


sim.  eg. sim.pedestrianwaiting - typically used for global simulation variables
this.  e.g. this.CustomerNumber - typically used to refer to owning class attributes


This is important to let the Javascript engine know you are referring to a SImulation variable and not a simple local variable used during basic calculations etc.  You can create Simulation variables of arbitrary scope and depth - eg. is a legitimate qualified name.