Policy Examples

Policy Model Basic Principles

A policy model is made up of nodes and connections that define the policy logic. In order to build a functioning policy model, you must understand several basic principles.

Configuring a Policy Model

The following principles apply to working with a policy model:

Policy models do not reference specific records. Rather, they contain nodes that reference families. You must use policy instances to identify the individual records whose values are evaluated when the policy is executed.
The first node in a policy model must be an Input node rather than a Query node.
A node can use an input from any predecessor node in the same logic path, even if the nodes are not directly connected.
Any number of nodes can use an input from the same predecessor node.
With the exception of the Or node and the Case node, a node will be executed only when all necessary preceding nodes have been successfully executed.
A policy model can often be arranged in various configurations without impacting the execution results. You may want to arrange the policy model in the configuration that provides the best visual representation of the policy.
Connections that start at a Condition or Logic node can be configured to create separate logic paths in a policy model. Specifically:
- If the connection property is Yes, the corresponding path will be followed when the logical result of the Condition of Logic node is yes. If you do not configure a logic path for a connection, a Yes path is assumed but does not appear on the model.
- If the connection property is No, the corresponding path will be followed when the logical result of the Condition or Logic node is no.

Configuring Node Properties

Most nodes have outputs that successor nodes can use as inputs. You must specify inputs for each successor node using the Properties window that appears when you select the node in the policy model.
Note: Outputs and inputs may represent either a single value or a collection of values. The types of outputs that each node generates and the types of inputs that each node accepts is different for each node. When building a policy model, you must use corresponding input and output types.
Any numeric values entered in Calculation nodes should be entered in the format matching the user's culture setting. For example, a user with German culture would enter 4,5 to represent four and a half, whereas a user with US-English culture would enter 4.5.
There are specific formats in which you can enter dates and times and amounts of time (that is, time spans). Refer to the respective topics for details.
When using a policy node to update values in a record:
- If a field has complex behavior defined by field-level rules (for example, rules for valid values) and field-level behaviors, this behavior will not be reflected in the Properties window or detected by policy validation. Therefore, you are responsible for ensuring that the values you specify are valid according to any baseline or custom field-level rules for the corresponding field.
- If a field value is defined by a system code, the value that you specify in the corresponding section must be the system code, not the value that is displayed to the end user.

Policy Model Principles Illustrated

The principles for working with a policy model can be illustrated through the following example model:

In this example model, the node named Temperature is an OT Connect Tag node which represents a process historian tag. When this policy is executed, if the Latest Reading Value that is associated with the process historian tag is greater than or equal to 200, the Predix Essentials system will send an email message to the email address that is specified in the Human Resource record that is associated with the Analyst User node.

The following table describes each of the policy model basic principles in the context of this example:


Policy Model Principle	Example
Policy models do not reference specific records. Rather, they contain nodes that reference families. You must use policy instances to identify the individual records whose values are evaluated when the policy is executed.	The Temperature and Analyst nodes represent families. The specific records whose values are evaluated are determined by policy instances.
The first node in a policy model must be an Input node rather than a Query node.	The Temperature node is an OPC Tag node, which is a type of Input node.
Most nodes have outputs that successor nodes can use as inputs. You must specify inputs for each successor node using the Properties window that appears when you select the node in the policy model. Note: Outputs and inputs may represent either a single value or a collection of values. The types of outputs that each node generates and the types of inputs that each node accepts is different for each node. When building a policy model, you must use corresponding input and output types.	The output Latest Reading Value from the Temperature node is used as an input to the Condition node. This output represents a single value, which corresponds to the type of input that the Condition node accepts. The value 200 is used as the second input to the Condition node, but it is not an output from another node. Instead, it is a constant value that is specified directly in the Properties window for the Condition node.
A node can use an input from any predecessor node in the same logic path, even if the nodes are not directly connected.	The Email Contact node can use an input from the Temperature node even though the two nodes are not directly connected.
Any number of nodes can use an input from the same predecessor node.	The Email Contact node and the Condition node can both use inputs from the Temperature node.
With the exception of the Or node and the Case node, a node will be executed only when all necessary preceding nodes have been successfully executed.	The Email Contact node will be executed only when all of the nodes preceding it have been successfully executed. If, for example, the condition defined in the Condition node was not met or if an error occurred when executing the Analyst node, the Email Contact node would not be executed.
A policy model can often be arranged in various configurations without impacting the execution results. You may want to arrange the policy model in the configuration that provides the best visual representation of the policy.	The execution results of the policy would be identical even if the Analyst node were connected to the Temperature node or the Condition node. The current configuration, however, provides a clear visual representation of the policy because the Email Contact node is the only node in the model that uses an input value from the Analyst node.
Connections that start at a Condition or Logic node can be configured to create separate logic paths in a policy model. Specifically: If the connection property is Yes, the corresponding path will be followed when the logical result of the Condition of Logic node is yes. If you do not configure a logic path for a connection, a Yes path is assumed but does not appear on the model. If the connection property is No, the corresponding path will be followed when the logical result of the Condition or Logic node is no.	A property is not defined for the connection between the Condition node and the Email Contact node, therefore, a value of Yes is assumed. This means that an email message is sent only if the preceding condition is true. If the condition is false, policy execution will not continue.

Policy Examples

You can use Policy Designer to accomplish tasks in a wide variety of scenarios. These examples illustrate a few of these scenarios.

Basic Policy and Policy Instance

Suppose that a certain motor is known to fail when it exceeds a temperature of 200 degrees. Part of the strategy for maintaining the motor might be to create a policy that continually monitors the motor's temperature.

In this example, temperature readings are gathered as readings associated with a process historian tag, ehich is represented in a policy by an OT Connect Tag node.

Policy Model

Policy Logic Summary

If the temperature of the motor exceeds 200 degrees, an email message will be sent to the responsible analyst. This policy would likely be configured to execute automatically when records belonging to a policy instance are updated.

Individual Node Descriptions


Node Name	Node Type	Description
Temperature	OT Connect Tag	Represents the process historian tag whose associated reading values are inputs to the policy. The specific process historian tags that this policy monitors are identified by the policy instances belonging to this policy.
Analyst	User	Represents the system user whose information is used by the policy. The specific user records used by this policy are identified by the individual policy instances belonging to this policy. Note: User nodes retrieve data from records in the Security User and Human Resource families.
Latest Reading Value > 200	Comparison	Defines the logic that will be applied to values associated with the process historian tag that the OT Connect Tag node represents. Specifically, this Condition node specifies that the policy logic will continue (i.e., an email message will be sent) only when the Latest Reading Value is greater than or equal to 200.
Email Contact	Email Contact	Represents an action to send an email message. The email message will be sent to the email address defined in the specific user record that is included in the corresponding policy instance.

Policy Instance

A policy instance that is associated with this policy might look like this:

...where:

The specific process historian tag is A1113F.
The User ID associated with the specific user record is bwilliams.

When this policy is executed, if the process historian tag A1113F has a Latest Reading Value that is greater than or equal to 200, the Predix Essentials system will send an email message to the user with the User ID bwilliams.

If you want to apply the same logic to monitor the temperatures of additional motors, you can define an additional policy instance for each specific process historian tag whose related Latest Reading Values contain the temperature readings for the motors that you want to monitor.

Monitoring a Single Value

Suppose a factory contains a heat exchanger shell, which can fail as a result of hot hydrogen attack. Part of the mitigation strategy for the heat exchanger shell, therefore, is to monitor the temperature of the process stream exposed to the shell component to ensure that it does not exceed 600 degrees Fahrenheit.

Context

The following table outlines how this policy is used within a larger workflow that also includes other Predix Essentials modules or features.


Step	Module	Task
1	RBI	Assess the risk of loss of containment for a heat exchanger shell, which is associated with the damage mechanism Hot Hydrogen Attack.
2	OT Connect	Create a Source Tag record representing the process historian tag that record the process stream temperature of the heat exchanger shell.
3	AHM	Optionally create a Health Indicator record based on the Source Tag record.
4	Policy Designer	Create a policy to monitor the temperature values retrieved from the process historian.

Policy Model

Policy Logic Summary

If the temperature of the heat exchanger shell rises above 600 degrees Fahrenheit more than once during a specified interval:

A Policy Recommendation record will be created and configured to create a work request for immediate corrective action.
An email message will be sent to a process engineer.

This policy should be configured with a scheduled execution frequency of once a week.

Individual Node Descriptions


Node Name	Node Type	Description
Temperature	OPC Tag	Provides reading values that are passed to the Above 600 F node.
Last Week	Collection Filter	Defines the time range for which historical reading values will be retrieved from the process historian. Note that if no time range is defined, all the available readings for the tag will be retrieved, subject to a maximum of 1,000,000 readings per retrieval.
Above 600 F	Threshold Statistics	Compares the collection of reading values returned by the Temperature node to the threshold value 600, and counts number of times that reading values exceed the threshold value.
Count > 1	Comparison	Compares 1 to the number of times that the reading values exceeded the threshold.
Create Recommendation	Create Recommendation	Creates a Policy Recommendation record linked to the Asset and assigned to the User.
Email Contact	Email Contact	Sends an email message.
Engineer	User	Supplies a User ID to the Create Recommendation node and an email address to the Email Contact node.
Asset	Entity	Represents the asset to which the Policy Recommendation record will be linked.

Monitoring Multiple Values

Suppose a factory contains a highly critical pump, which can pose risk if one of its bearings fails. Part of the mitigation strategy for the pump, therefore, is to perform a vibration analysis and monitor multiple variables in order to create a composite view of the pump's condition.

Context

The following table outlines how this policy is used within a larger workflow that also includes other Predix Essentials modules or features.


Step	Module	Task
1	ASM	Assess the risk of bearing failure for the pump.
2	OT Connect	Create a Source Tag record representing the process historian tag that records the process stream temperature of the heat exchanger shell.
3	AHM	Create Health Indicator records based on the process historian tag.
4	Policy Designer	Create a policy to monitor the values that are stored in the process historian.

Policy Model

Policy Logic Summary

If the pump conditions indicate a pending failure (i.e., all of the conditions specified in the policy logic are true):

A Policy Recommendation record will be created and configured to create a work request for immediate corrective action.
An email message will be sent to a reliability engineer.
The corresponding policy instance will be deactivated so that only one recommendation is created and only one email is sent for the same failure condition.

Individual Node Descriptions


Node Name	Node Type	Description
Bearing Temp	OPC Tag	Provides Latest Reading Values that are evaluated by the Bearing Temp > 200 node.
Pressure	OPC Tag	Provides Latest Reading Values that are evaluated by the Pressure < 100 node.
Flow	OPC Tag	Provides Latest Reading Values that are evaluated by the Flow > 200 node.
Vibration Level	Measurement Location	Provides Measurement Location readings that are evaluated by the Last Reading and Value > .15 nodes.
Asset	Entity	Represents the Equipment family and supplies a criticality indicator to the Condition node Criticality Indicator = A.
Pressure < 100	Comparison	Evaluates the process historian pressure readings to determine if any readings are less than 100.
Bearing Temp > 200	Comparison	Evaluates the process historian temperature readings to determine if any readings are greater than 200.
Flow > 200	Comparison	Evaluates the process historian flow readings to determine if any readings are greater than 200.
Last Reading	Last	Evaluates the collection of readings associated with the Vibration Level node and returns the last row in the collection, which, in this case, contains the most recent reading.
Value > .15	Comparison	Evaluates the value in the Value field of the Measurement Location reading returned by the Last Reading node to determine if it is greater than .15.
Criticality Indicator = A	Comparison	Evaluates the value in the Criticality Indicator field in the Equipment record to determine if it contains the value A.
Engineer	User	Supplies user information to the Create Recommendation and Email Contact nodes.
Create Recommendation	Create Recommendation	Creates a Policy Recommendation record if all of the preceding conditions are met.
Deactivate This Instance	Deactivate This Instance	Deactivates automatically the policy instance whose values caused the Deactivate This Instance node to be executed.
Email Contact	Email Contact	Sends an email message.

Creating Health Indicator Value Records

The policy in this example illustrates how you can manipulate multiple readings to create health indicator readings that represent the overall health of an asset.

Suppose you are using Asset Health Manger to monitor the health of a pump using the following indicators, which are tracked using Health Indicator records whose primary source records are Measurement Location records:

Flow Rate
Pressure
Lubrication
General operation
Vibration

You can use Asset Health Manager to evaluate the health of the pump in terms of these individual indicators by viewing gauges and trends for them on an individual basis. But you might also want to evaluate the overall health of the pump as a composite view of all of these underlying factors. If so, you can create a policy that facilitates this.

Context

The following table outlines how this policy is used within a larger workflow that also includes other Predix Essentials modules or features.


Step	Module	Task
1	Rounds	Create the Measurement Location records that will be used to measure the pump's conditions. Complete the Rounds workflow to yield reading values for those checkpoints.
2	Asset Health Manager	Create Health Indicator records based on the Measurement Location records.
3	Policy Designer	Create a policy to monitor the values that are stored in the Health Indicator records and create a new health indicator that indicates the overall health of the pump.

Policy Model

Policy Logic Summary

The values in the existing Health Indicator records will be used in calculations that determine an overall, single value that provides a composite view of the pump's health. This calculated value is stored in a Health Indicator Value record that gets created automatically each time the policy is executed and is linked to a different Health Indicator record that will be used to evaluate the overall health of the pump.

This policy would likely be configured with a scheduled execution of once a day.

Individual Node Explanation


Node Name	Node Type	Description
Flow, Pressure, Lube Check, Ops Check, and Vibration	Health Indicator	Represents various existing Health Indicator records whose primary source records are Measurement Locations. These records provide the values used in successor nodes to determine the overall health of the pump.
Alert Level + 1	Add	Adds 1 to the value in the Alert Level field in the corresponding Health Indicator record. The resulting value (n+1) is used as the denominator in the successor Divide nodes.
20 / <Health Indicator name> Alert	Divide	Divides 20 by the result of the corresponding Add node. This value represents the Health Index contribution for each node. 20 is used as the numerator to ensure that each individual Health Indicator has equal weight, (i.e., since there are five Health Indicators, 20 is one-fifth of 100).
Various	Add	Combines the results from the Division nodes. This sum represents the overall health index of the pump on a numeric scale between 1 and 100, where a higher value is better than a lower value.
Round to nearest integer	Round	Rounds the value of the overall health index to the nearest integer.
Health Index	Add Value to Health Indicatorr	Adds the rounded value of the overall health index to a new Health Indicator Value record and links the record to a Health Indicator record.
Health Indicator	Health Indicator	Represents the Health Indicator record to which the Health Indicator Value record will be linked when the policy is executed.