General Reference

In the Properties window for some nodes, you can specify a date and time that should be used when evaluating values. For example, consider the following Properties window for a Collection Filter node that is configured to filter Measurement Location reading values to only those that were recorded in the past 7 days.

You can define specific date and time values in the standard format YYYY-MM-DD HH: mm: ss, where the time values use a 24-hour time format.

Alternatively, you can use a combination of acceptable values to specify dates and times that are relative to the time at which the policy is executed.

Specifying Relative Dates and Times

When using relative dates and times, the actual date and time that is evaluated depends on the date and time at which the policy is executed. For example, if you specify a relative date of Sunday, the Predix Essentials system will use the most recent Sunday (at 12:00:00 A.M. in the policy's time zone) relative to the date and time that the policy is being executed. So, if a policy is executed on Friday, July 13, the evaluated date would be Sunday, July 8, as illustrated in the image below, where:

• The yellow star identifies the policy execution date.
• The red box indicates the evaluated date relative to the policy execution date.

You can adjust relative date and time values by adding operators and variables to the relative date:

• Operator: Specifies whether or not time should be added to or subtracted from the relative date and time. You can use the + (plus sign) or - (minus sign) operators.
• Variable: Specifies the amount of time to add to or subtract from the relative date and time.

For example, if you specify Sunday + 4 hours, the evaluated date will be 4:00:00 A.M. on the most recent Sunday.

Acceptable Format for Relative Date and Time Values

• Relative dates and times are determined in respect to the policy's time zone.
• These values are not localized, so you must enter them in English.

Acceptable Format for Variables

The following table describes the variables you can use with relative dates. Note that these values are not localized, so you must enter them in English.

How the Policy Time Zone Affects Relative Dates and Times

When you specify a date and time that is relative to 12:00:00 A.M. of a specific day, the date range criteria and the policy time zone work together to determine the range of data that is included in the evaluation.

For example, suppose that you set up two policies to evaluate the exact same data, but one policy uses Eastern Time (UTC - 5) and the other uses Pacific Time (UTC - 8). If you specify that the policy should evaluate reading values starting at the relative time of today + 4 hours, the start time will be interpreted as 4:00:00 A.M., in the policy's time zone, of the current day. Because 4:00 A.M. Eastern Time occurs 3 hours earlier than 4:00 A.M. Pacific Time, each of those policies will end up evaluating a different set of data.

The following image illustrates this difference, where:

• The start and end time for the policy using Eastern Time is represented by the red shaded region.
• The start and end time for the policy using Pacific Time is represented by the green shaded region.

In the Properties window for some nodes, you can specify an amount of time (i.e., a time span) that should be used when evaluating values. For example, consider the following Properties window for a Comparison node that is configured to determine whether or not the Accumulated Time output of a Threshold Statistics node is greater than 3 days.

Acceptable Format for Amounts of Time

The following table describes the values that you can use to specify an amount of time to evaluate. Note that:

• These values are not localized, so you must enter them in English.
• You can use negative numbers.
• You cannot specify a number of months or years because some months and years have a different number of days. Instead, you should specify a number of days (e.g., 30 days or 365 days).

To streamline the creation of calculations in policies, you can use constants to specify certain values. These constants can be specified in a Constant or Point Value node with an appropriate data type, and then used as an input to any other node in your policy.

The following table describes the supported constants:

After you validate or execute a policy, detailed results of the validation or execution can be viewed on the model canvas. Validation details appear on the model canvas automatically when you run the validation process. Execution details appear when you select a past execution on the Execution History pane.

Node Color-Coding

To indicate the results of an execution, the nodes in the policy model are color-coded as follows:

Green

Indicates that the node was executed successfully (i.e., the node was configured correctly, the source value was valid, and the execution produced a valid result)

Pale yellow

Indicates that the node was executed successfully, but raised a warning that the policy designer should review and address if needed.

Red

Indicates that the node was not executed successfully due to an error. When a node's execution encounters an error, subsequent nodes in the model will not be executed.

Gray

Indicates that the node was not executed. This may be expected (i.e., due to the policy logic) or unexpected (i.e., due to errors in the execution of preceding nodes).

The following example diagram shows nodes in each of these states:

Node Execution Details Window

After you validate or execute a policy, you can select a node in the policy model to view the execution details of the node in the Node Execution Details window. If the node was successfully executed, the inputs and outputs (for example, certain values, logical results, or actions) of the node appear in the execution details of the node. If the execution of the node resulted in a warning or error, the window provides additional details about the cause of the warning or error. In addition to the execution details of the node, the Node Execution Details window for the Sub Policy node contains the View Execution Details link. You can use the link to view the model and execution details of the sub policy that is mapped to the node.

The following image is an example of the Node Execution Details window for a Condition node that was executed successfully with a logical result of Yes.

Note that the same node could have also been executed successfully with a logical result of No (e.g., 800 is not greater than or equal to 900).

Each time a policy is executed, the execution results are recorded in the execution log. You can view a summary of each execution in the Execution History pane. Summaries include items such as warning messages, errors, returned values, and actions. For example, you might see the following summary information:

• No Action Taken: The policy was executed but no actions were triggered. For example, this might occur if the policy's input values did not meet the conditions defined in the policy logic.

  

• <Action Taken>: The policy was executed and resulted in actions. The actions are listed in the Summary column of the grid.

  

• Errors Occurred: There was an error in the policy logic, and no action was taken. For example, this might occur if a node's Properties window did not contain a value in a required field.

  

When you select an execution summary in the Execution History pane, detailed execution results are displayed on the model canvas. However, if changes have been made to the policy model since the selected execution occurred, you will not be able to view that details of that execution on the canvas.

During validation and execution of policies involving numeric values, Units of Measure (UOMs) are handled in the following ways for conversion and display of the values:

• If numeric values with different base UOMs are calculated or compared, the policy must be configured to apply the required UOM conversions before performing any action on the values or updating any of the values in other records.
• If a numeric value is required to be displayed in the execution summary of a policy or in a notification triggered by the policy, the value appears in the base UOM and not in the UOM Conversion Set associated with the user.
• Any value that you specify to be updated in a record through a policy is considered to be in the base UOM of the corresponding field.

Family Policy records store basic information about Family policies. The following table provides an alphabetical list and description of the fields that exist in the Family Policy family and that are displayed on the baseline Family Policy datasheet (unless otherwise noted). The information in the table reflects the baseline state and behavior of these fields. This list is not comprehensive.

This family is not enabled for site filtering, which means that records in this family can be accessed by any user with the appropriate license and family privileges. See the Site Filtering section of the documentation for more information.

By default, this family is configured to be excluded from global search, and not to use Rules or Family Policies.

Policy Recommendation records store basic information about recommendations that have been created as a result of a policy. The following table provides an alphabetical list and description of some of the fields that exist in the Policy Recommendation family. The information in the table reflects the baseline state and behavior of these fields. This list is not comprehensive.

This family is enabled for site filtering, which means that records in this family can be assigned to a specific site, and will only be accessible to users who are assigned to the same site and have the appropriate license and family privileges. For more information, refer to the Sites section of the documentation.

By default, this family is configured to be included in global search, and to use Rules.