Policy Models
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 initial nodes in a policy model, that is, nodes with no predecessors, must be Input nodes other than Query nodes.
- A family policy must contain one Current Entity node for entity families, or one Current Relationship node for relationship families.
- 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 APM 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 initial nodes in a policy model, that is, nodes with no predecessors, must be Input nodes other than Query nodes. A family policy must contain one Current Entity node for entity families, or one Current Relationship node for relationship families. | The Reading in Error node is a Current Entity node, which is a type of Input node. The Current Entity node is required for an entity family policy. |
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:
| 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. |
Add Nodes to the Model Canvas
Before You Begin
- Create a policy.
- Make sure you understand the basic principles of working with a policy model.
Procedure
Enable Grid in Model Canvas
About This Task
Procedure
Connect Nodes in a Policy Model
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- Add at least two nodes to the model canvas
- Note the following limitations with connections between nodes:
- You cannot connect nodes in a circular execution path (for example, if Node 1 is connected to Node 2, and Node 2 is connected to Node 3, you cannot connect Node 3 to Node 1).
- You cannot connect a node to itself.
- There cannot be more than one connections between two nodes.
Procedure
Configure Node Properties
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- Add and connect nodes in the policy model.
Procedure
Define Input Values
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- If you want the input value to be defined by a predecessor node, the nodes must be connected, either directly or indirectly.
About This Task
Steps:
Procedure
- Specify a user-defined constant value
- Specify a value or collection that is an output of a predecessor node:
Define Input Values
To illustrate the different ways to define input values, consider the following nodes and connections.
- The icon appears in the first input section, indicating that the input is defined by a predecessor node.
- The icon appears in the second input section, indicating that the input is a user-defined constant value.
Together, the Equipment Entity node and the Condition node to which it is connected indicate that an email message should be sent when an Equipment record has a value of A in the Criticality indicator field.
Configure Logic Paths
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- Add and connect nodes in the policy model.
About This Task
Procedure
Separate Logic Paths
Consider the following policy model:
- The Condition node evaluates the DA Reading Value that is associated with the OPC Tag record to determine if it is greater than or equal to 900.
- The Condition node is connected to the following nodes:
- Email Analysis (through the Yes connection)
- Create Recommendation (through the No connection)
- If the DA Reading Value is greater than or equal to 900, an email message will be sent. The logic is determined by the Yes logic path specified for the connection to the Email Analyst node.
- If the DA Reading Value is not greater than or equal to 900, a Policy Recommendation record will be created. This logic is determined by the No logic path specified for the connection to the Create Recommendation node.
Copy and Paste Nodes and Connections
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- Note the following:
- If you copy a node that contains a mapped field value from another node, the mapped field value will not be copied unless you also copy the node from which the values are mapped and the connector node between the two nodes.
- Connections will be copied only if you select the connection and both nodes that it connects.
- After you paste a node that requires a unique name (example; Point Value node), you must change the name of the copied node before you can save the policy.
- You cannot copy nodes and connections from one policy to another.