About Policy Execution

When a policy is executed, input values are evaluated against the logic in the policy model. The input values for each execution are supplied by a specific policy instance. You can configure a policy to be executed automatically or according to a predefined schedule (or both). Each time a policy is executed, the results of the execution are recorded in the execution log, which you can view on the Execution History pane.

IMPORTANT: Only active policies will be executed. Further, only the active policy instances that are associated with an active policy will be executed.

Automatic Execution

When automatic execution is configured, individual policy instances are executed when records belonging to the policy instance are updated. Additionally:

For records represented by a Measurement Location, OPC Tag, or Health Indicator node, policy execution is also triggered by changes in related Reading records.
For AMS Asset records represented by an AMS Asset node, policy execution is also triggered by changes in related AMS Asset Alert records.
For GE Tag records represented by an GE Tag node, policy execution is also triggered by changes in related GE Tag Event records.

Automatic execution works in conjunction with the selection in the Trigger check box that appears on the Properties window for all Input nodes except Query, Constant, and Point Value nodes. When the Trigger check box is:

Selected: Changes in a record or related readings represented by the node will trigger policy execution. The Trigger check box is selected by default.
Cleared: Changes in a record or related readings represented by the node will not trigger policy execution.

IMPORTANT: You should ensure that the Trigger check box is selected for only the inputs where you want changes in the record to trigger policy execution.

For example, suppose that you have a policy that contains an Entity node that represents an Equipment record, but this particular Entity node does not influence any of the logic in the policy model that determines if action is needed. Rather, other Entity nodes (e.g., representing Measurement Location records that are linked to the Equipment record) influence the actual logic in the policy model. In this case, you can exclude the associated Equipment record from triggering the policy execution by clearing the Trigger check box for that node. By doing this, only the changes in the relevant records will trigger policy execution.

When Should Automatic Execution be Used?

Use automatic execution when the policy is designed to monitor one or more values that change with time and when an action is needed in response to a specific change. Consider the following examples:

The policy monitors readings related to an OPC Tag. When a reading value crosses a defined a threshold, the policy creates or closes a policy event.
The policy monitors the status of a Health Indicator record. When the Health Indicator enters the Alert state, the policy sends an email to the responsible user.

Scheduled Execution

When scheduled execution is configured, all active instances that are associated with a policy are executed according to the schedule that you define.

When Should Scheduled Execution be Used?

Use scheduled execution when the policy is designed to evaluate data over a period of time or when automatic execution could produce misleading results.

Consider the following examples of policies designed to evaluate data over a period of time:

Using the Threshold Statistics node, the policy analyzes threshold excursions during the previous month for values related to an OPC Tag or Health Indicator.
The policy evaluates conformance to an asset strategy by comparing the actual count of readings added for a measurement location within the previous week to the expected count.

Consider the following example of a policy monitoring values where automatic execution could produce misleading results:

The policy evaluates combined information from a Rounds Route that includes multiple measurement locations for a single asset.

Because mobile users can enter readings in any order and could change a previously entered reading value before finalizing the Route, using automatic execution in this scenario could trigger executions where one or more readings are from an earlier Route execution or are otherwise invalid.

Instead of using automatic execution, the policy could be scheduled to run at a similar frequency to the Route. For example, if the Route is completed during the morning shift on every weekday, the policy could be scheduled to execute after the end of the shift. The policy could check whether new Readings have been added for all the required inputs before proceeding with the evaluation of the results.

Considerations for Scheduled Policies

You can take steps to prevent delays in policy execution by considering the number of policies you are scheduling and the number of instances associated with each.

When scheduling multiple policies, you can configure the policy schedules at different times so that the executions are staggered throughout the day.

All active instances of a scheduled policy are submitted for execution at the same time. Therefore, when scheduling a policy with a large number of instances, you can stagger the executions by creating multiple copies of the policy, each with a subset of the instances. You can then schedule each of the policies to be executed at a different time. This approach may be especially advantageous when users are located in multiple time zones, as you could configure relevant policy instances to be executed outside of normal business hours such that results are available in different locations as needed.