Input Nodes

Consider the following nodes and connections.

As shown in the following image, you can use the Properties window for the Condition node to select the A Constant node and its value, which is A. With these options selected, the Condition node evaluates whether or not the value in the Criticality Indicator field of a specified Equipment record is A.

Regardless of the Equipment records specified via policy instances, the Condition node will always compare the value in the Criticality Indicator field to A.

Entity nodes are often the starting point in policy models because they pvoride successor nodes with fields to evaluate. For example, consider the following nodes and connection.

In this example, the Equipment Entity node provides the Condition node with a field, Criticality Indicator, to evaluate.

Point Value node

The following example illustrates how you can use the Point Value node to represent values from fields in different families for each policy instance. Consider the following nodes and connection.

In this example, the Point Value node Cost represents cost values of various types. This model evaluates each cost value to determine whether or not it is greater than 150.

The particular record and field containing each cost value are defined by policy instances. For example, you might create two policy instances, where:

• One policy instance maps the Cost field from the Action family to the Cost Point Value node.
• The other policy instance maps the Total Cost field from the Work History family to the same Cost Point Value node.

By using the Point Value node in this way, the policy can use one Input node to access values in multiple families and evaluate them against the same criteria.

Predix Time Series node

The following is an example of how you can use the Predix Time Series node with other nodes in a policy model to access and analyze Time Series data.

In this example, the Predix Time Series node collects data from the current week, as shown by the values specified in the following image of the Properties window for the Predix Time Series node.

The Collection Filter node filters the data designated as 0 from the Predix Time Series output collection.

Finally, this example policy is configured so that the user receives an email notification if the count of the readings with bad quality exceeds three instances.

Query Alerts node

The following example illustrates a policy that is scheduled for daily execution and configured to notify a user about the active alerts generated for an asset:

In this example, the Query Alerts node is used to retrieve all the alerts generated for an asset within the 24 hours. A Collection Filter node is used to filter the active alerts that have a Severity greater than 2. The Count node and Greater Than nodes are used to evaluate if any active alert with severity greater than 2 has been generated for the asset. If such alerts have been generated for the asset, an email notification with information on the asset and the number of alerts generated for the asset is sent to a specified user.

The following image illustrates the Properties window of the Query Alerts node described in the example.

Query Time Series node

The example below explains how to use a Query Time Series node in a sub policy, to retrieve average reading values from a standard list of tags for an asset without needing to configure a large number of inputs for each policy instance. The example assumes that you have a coherent tag naming strategy in your Predix Essentials system.

For example, Tag ID = <asset id>_<parameter name>

The main policy contains a Constant node named Parameter List with Data Type configured as Data Frame and Value configured to contain a single column of parameter names that you want to use in the policy.

The Properties window of the Sub Policy node is shown in the following images.

The Sub Policy node is configured to iterate over collection. Since the Tag Name input to the node is configured to use the Value (i.e. collection) output and Parameter Name column from the Constant node, the sub policy is executed for each parameter name.

The Asset ID, Start Time, and End Time inputs are all configured to use single value outputs from the prior nodes. These values remain the same for all iterations of the sub policy.

After the sub policy has executed for each parameter name, the main policy continues to execute additional logic on the collection of values returned from the sub policy. For example, the output from the Sub Policy node could be passed directly into a data frame input of an R Script node.

The sub policy design is shown in the following image.

A Text node in the sub policy concatenates the Asset ID value with the required tag name to create the Tag ID value to be used in the Query Time Series node.

The Properties window of the Text node is shown in the following image.

The calculated Tag ID value is passed into the Query Time Series node, which retrieves the raw Time Series data.

The Properties window of the Query Time Series node is shown in the following image.

An Average node computes the average value of readings that were retrieved by the Query Time Series node. An Is Null node is used to insert the value NA in case the Average node output is null, which happens if no readings are found within the time range. The Return Value nodes pass the Average value, Start Time, End Time and Tag ID for each iteration back to the main policy for further processing.

In the main policy, these values are accessed as a single collection containing four columns with one row for each parameter name that was processed.

Query node

The following example illustrates how you can use the Query node with other nodes in a policy model to access and analyze Policy Event records using the Events Query in the baseline Predix Essentials Catalog.

Consider the following nodes and connections.

In this example, the Policy Events Query Query node is connected to the Equipment Entity node and to a Collection Filter node, which is then connected to various additional Condition, Calculation, and Action nodes.

As shown in the following image, you can use the Properties window for the Query node to specify the query whose results you want to use in the policy model. You can also see that the specified query contains a prompt, Asset Key, and that a system field from the Equipment Entity node, Entity Key, is used to supply values to the prompt.

When you connect the Query node to a successor node, in the Properties window of the successor node, you can select the Result Set option to evaluate the full query results.

In this example, the Collection Filter node is used to filter the query results. As you can see in the following image of the Properties window for the Collection Filter node, the query results are filtered to include only the policy events that lasted longer than 10 seconds, occurred within the last month, and have the name IOW Excursion.

The subsequent Calculation and Condition nodes evaluate the filtered query results and trigger actions when the specified conditions are met. Specifically, the remaining nodes in this policy work together to send an email message and to create a recommendation if the filtered query contains more than two results or if the total duration of the query results exceeds 4 minutes.

User node

The following example illustrates how you can use the User node to access the email address, which exists in the Human Resource family, and the User ID, which exists in the Security User family, for the same person. Consider the following nodes and connections.

In this example, the Engineer User node is connected to an Email Contact node and a Create Recommendation node.

As shown in the following image, you can use the Properties window for the Email Contact node to select the User node and the Email Address field in the Human Resource family.

Additionally, as shown in the following image, you can use the Properties window for the Create Recommendation node to select the User node and, in this case, a field in the Security User family, User ID.