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 can contain nodes that reference families. You must use policy instancesIdentifies the records to which logic in the policy model will be applied. 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 other 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 or 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 collectionA set of results from a Query node or a set of readings associated with input nodes such as Measurement Location, Health Indicator, or OPC Tag. 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 (i.e., 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 (e.g., 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.
- If a field has a Unit of Measure (UOM), associated with it, you must specify the value using the base UOM in which your database stores the values.

Example: 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 OPC Tag node which represents an OPC Tag record. When this policy is executed, if the DA Reading Value that is associated with the OPC Tag record is greater than or equal to 200, the GE Digital 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 explains 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 can contain nodes that reference families. You must use policy instancesIdentifies the records to which logic in the policy model will be applied. 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 other 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 collectionA set of results from a Query node or a set of readings associated with input nodes such as Measurement Location, Health Indicator, or OPC Tag. 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 DA 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 Analystnode, 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 or 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.