Policy Execution

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. 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. A Policy can be executed in the following ways:
  • Automatic execution
  • Scheduled execution
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.

About Active Policies and Policy Instances

When a policy is active, it means that the active policy instances that are associated with the policy will be executed according to the policy's defined execution settings.

Consider a policy with two instances, where one instance is active and one instance is inactive.

  • If the policy is active, the active policy instance will be executed according to the policy's execution settings.
  • If the policy is inactive, neither policy instance will be executed.

Configure Scheduled Execution

Before You Begin

  • Run the validation process to confirm that the policy logic is working correctly.
  • Verify that the correct time zone is specified for the policy.

About This Task

You can configure a policy to be executed automatically or executed according to a predefined schedule (or both). This topic describes how to configure a policy to be executed according to a predefined schedule.

Procedure

  1. Access the policy that you want to configure to be executed according to a defined schedule.
  2. In the Details workspace, in the Execution Settings section, select the Scheduled Execution check box.

    Options that you can use to specify the schedule appear.

  3. Select either One time or Recurrence.
  4. In the Start box, specify the date and time at which you want the first scheduled execution to occur.
  5. If you selected Recurrence, in the Every section, select the frequency at which you want the policy to be executed.
    Note:

    You can configure a policy to execute as frequently as every minute. However, due to performance impacts, policies should not be scheduled to execute at high frequencies in most circumstances. If you choose to execute a policy at a high frequency, consider the following guidelines to limit performance impact:

    • The policy should have a limited number of instances.
    • The policy should not use Query or R Script nodes.
    • If the policy uses tag inputs (such as GE Tag or OPC Tag), the range of the data retrieved should be limited.
    • If the policy uses tag input nodes, and the node does not provide start and end date inputs, a Collection Filter node should be used after the tag node.
    • If you want to access Measurement Location or Health Indicator values, an Entity node should be used to retrieve the latest health indicator value as an alternative to the Health Indicator or Measurement Location nodes, which run queries to find all of the related reading records.
    • The policy should have a limited number of instances.
    • The policy should not use a Query node.
    • If the policy uses tag inputs (such as GE Tag or OPC Tag), the range of the data retrieved should be limited.
    • If the policy uses tag input nodes, and the node does not provide start and end date inputs, a Collection Filter node should be used after the tag node.
    • If you want to access Measurement Location or Health Indicator values, an Entity node should be used to retrieve the latest health indicator value as an alternative to the Health Indicator or Measurement Location nodes, which run queries to find all of the related reading records.
  6. On the toolbar, select .
    The policy is saved. A summary of the schedule and the next date on which the policy will be executed appears below the schedule settings.

Results

  • When the policy is active, the active policy instances that are associated with the policy will be executed based on the defined schedule.

What To Do Next

Configure Automatic Execution

Before You Begin

About This Task

You can configure a policy to be executed automatically or executed according to a predefined schedule (or both). This topic describes how to configure a policy to be executed automatically.

Procedure

  1. Access the policy that you want to configure to be executed automatically.
  2. In the Details workspace, in the Execution Settings section, select the Automatic Execution check box.
  3. In the Design workspace, on the Properties window for each Input node that contains a Trigger check box, select or clear the Trigger check box as needed. You must select the Trigger check box for at least one Input node.
    When the Trigger check box is:
    • Selected, changes in a record or related readings represented by the node will trigger policy execution.
    • 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
  4. In the Policy section of the toolbar, select .
    The policy is saved.

Results

  • When the policy is active, the active policy instances associated with the policy will be executed automatically when the specified records or related reading values are updated.

What To Do Next

Activate or Deactivate a Policy

Before You Begin

Procedure

  1. Access the policy that you want to activate or deactivate.
  2. In the Details workspace, on the toolbar, either the button or the button is displayed.
    • If the button is displayed, the policy is active. To deactivate the policy, select this button.
    • If the button is displayed, the policy is not active. To activate the policy, select this button.

    On the button and on the Details tab, the active/inactive indicator changes to reflect your selection.

  3. In the Policy section of the toolbar, select .
    The policy is saved.

Results

  • If you activated the policy, the active policy instances that are associated with the policy will be executed according to the policy's execution settings.
  • If you deactivated the policy, none of the policy instances that are associated with the policy will be executed.

What To Do Next

Access Execution History

Procedure

  1. Access the policy for which you want to view the execution history.
  2. In the Design workspace, select the Execution History tab.
    The Execution History pane appears. On the left side of the pane, a list of the policy's instances appears. On the right side of the pane, execution summaries for all policy instances appear.
  3. On the left side of the pane, select a policy instance.
    On the right side of the pane, a summary of the execution results for the selected instance appears.
  4. On the right side of the pane, select a specific execution to view additional details on the policy canvas.
    Note:
    • If changes have been made to the policy model since the selected execution occurred, you will not be able to view the details of that execution on the canvas.
    • You can use the Actions and Errors check boxes to display only executions that resulted in actions or only the executions that resulted in errors.
  5. In the policy model, select a node to view additional details about the specific node's execution.