Overview of the Policy Designer Module

Traditionally, many companies attempt to improve equipment and location performance by identifying historical trends and using them to define future actions. For example, the results of a Reliability Distribution Analysis may indicate that a type of equipment fails about every six months, so a strategy might be implemented to replace equipment of that type every five months (that is, one month prior to the next predicted failure). In reality, however, some equipment of that type could last longer than six months (for example, for eight months), and in these cases, replacing the equipment too early would result in unnecessary costs. Waiting until the equipment fails, however, is also not the best plan.

The objective of Policy Designer is to develop and execute strategies based upon historical data and dynamic data, which is obtained by monitoring conditions in real time. Using Policy Designer, you can define policies that:

  • Retrieve information about current conditions.
  • Allow you to identify emerging trends of equipment performance.
  • Apply some logic to that data based on historical trends.
  • Initiate actions that will mitigate future risk.

More Details

An engineer might know that when a motor reaches 200 degrees, it will begin to fail. Historical data might also tell him that the same motor operating continuously will overheat about every three months. Rather than implementing a strategy to replace the motor every three months, as suggested by the historical data, he can create a policy to take action when threshold temperature conditions are actually met. If the policy retrieves a reading from a process historian indicating that the motor has reached 200 degrees, policy logic can create a recommendation automatically for a technician to replace the equipment and send an email message to notify the engineer. In this way, the company can save money by avoiding unnecessary replacements and still prevent failures that will occur if the equipment is replaced too late. Further, employees who do not have the expertise to analyze real-time data can implement strategies based upon emerging trends immediately.

Policies can be configured to monitor current conditions continuously and perform a variety of actions automatically based on criteria that have been defined by the policy owner. You can also use Policy Designer to create and update composite health indicators that indicate the overall health of a piece of equipment.

Related Information:

Access the Policy Designer Overview Page


In the module navigation menu, select Tools > Policy Designer.

The Policy Designer Overview page appears.

The Policy Designer Overview page contains the following sections that summarize the number of Policies and Policy Recommendations:

  • Policies: Contains a list of all active and inactive Policies.
  • My Policy Recommendations: Contains a list of the Policy Recommendation records assigned to you.
  • Overdue Policy Recommendations: Contains a list of the Policy Recommendation records that are past target completion dates with pending recommended actions.
Note: The Policy Designer Overview page is not updated automatically when you return to the previously opened tab. You can select to update the page.

The Count of Executions per Policy for Last 30 Days section in the Policy Designer Overview page displays a graphical summary of the execution results for the 20 Policies that were most active in the past 30 days. You can select an execution result to access the corresponding Policy.

Policy Designer Workflow

This workflow provides the basic, high-level steps for using Policy Designer. The steps and links in this workflow do not necessarily reference every possible procedure.

  1. Begin a policy by providing a name and description for the policy.
  2. Build a policy model, which includes nodes and connections that represent the inputs, logic, and resulting actions for the policy.
    Note: Interaction with the model design canvas, such as adding and moving nodes, is not available on touch-screen devices.
  3. Create policy instances, which define the specific records to which logic in the policy model will be applied.
  4. Run the validation process to confirm that the policy logic is working correctly.
  5. Define execution settings to specify whether you want the policy to be executed automatically or executed according to a predefined schedule (or both).
  6. Activate the policy and policy instances so that they will be executed according to your defined execution settings.