Rule Objects

Rule objects can be created in the I/O Model tree to control the way data sources are browsed. Often the number of items contained in a data source can be enormous and browsing the entire namespace can at best, be time consuming and at worst, possibly overload the server. OPC UA servers have no server side browse filters and the OPC Classic browse filters are limited in their implementation options. Rule objects allow you to selectively control the browsing and discovery of objects by setting logical conditions. According to whether the conditions are met, discovered objects can be enabled or disabled or even discarded entirely. Rules can also be implemented to run Lua scripts, for example, a discovered I/O item meeting the rule conditions, can be set to have its values automatically historized via a Lua script embedded in the rule.

Rule Objects are only functional when placed beneath the Connector or Datasource objects. Rules will have no effect if placed directly beneath the Core. More information on the placement of Rules and the effect on browsing can be found in the Rule Placement section of this page.

Rule Elements

A rule is made up of three parts: its target, its conditions and its action. The properties of every targeted object in the namespace of the data source being browsed is run against the rule conditions, if it meets those conditions (returns True) then the specified action is executed against the object. Multiple rules can be applied to data source browsing and rules are implemented in alphanumeric order.

Rule Target

Rules can be set to target any object in the I/O Model tree however I/O items and I/O nodes are the most commonly targeted objects. The action of the rule will be directly on the targeted object type and therefore will also affect any items beneath the target. The target of a rule can be set either when creating the rule with the Create Rule wizard or configured later in the Object Properties panel.

Rule Target can be set in the Create Rule Wizard (left) or the Object Properties Panel (right)
Figure 1. Rule Target can be set in the Create Rule Wizard (left) or the Object Properties Panel (right)

Rule Conditions

Rule conditions can be specified on creation of the object or changed on the fly afterwards. The Conditions Builder allows you to easily create rule conditions following logic statements. A Rule can have multiple conditions that are satisfied by different property types and values. Examples of simple Rule conditions might be:

  • Does the discovered object name begin with Int?

  • Does the discovered object have an engineering unit?

These conditions can be combined with AND/OR operators to refine rule conditions to exact specifications. The conditions are entered using the conditions builder available in the create rule wizard or via the object properties panel.

Rule Conditions Builder is accessible in the Create Rule Wizard (left) or the Object Properties panel (right)
Figure 2. Rule Conditions Builder is accessible in the Create Rule Wizard (left) or the Object Properties panel (right)

Once the Conditions builder is open click Add Condition. Here conditions can be defined using the drop-down menus to specify the Model property, Operator and Value. In the example shown below the condition is defined as: does the discovered I/O Item name contain “Int”?

Conditions Builder - Add Condition
Figure 3. Conditions Builder - Add Condition

Click Add Condition to add further conditions to the rule.

Conditions Builder - Adding another condition
Figure 4. Conditions Builder - Adding another condition

Click on the greyed-out Logic tab to access the chart showing the logic connections between conditions. The default is that all the conditions must be met for the rule action to be implemented so multiple conditions are connected by an AND operator.

Conditions Builder - Logic Diagram
Figure 5. Conditions Builder - Logic Diagram

Select the AND operator and click the Toggle button to change the operator to OR:

Conditions Builder - Logic diagram AND/OR toggle
Figure 6. Conditions Builder - Logic diagram AND/OR toggle

If either condition is met, then the rule action will be implemented.

Rule Action

When the conditions of a rule are met by a discovered item, different actions can be implemented. These actions are detailed in the table below:

Table 1. Rule Actions
Action Name Action Explanation Continue Searching for Rules?

Continue

Continue searching for Rules, or create object in its default state

Yes

Disable

Disable object and stop searching for applicable rule

No

Discard

Discard object and stop searching for applicable rules

No

Enable

Enable object and stop searching for applicable rules

No

Script

Execute script in the rule; script determines whether further rules should apply

Depends on the Script

Stop

Stop searching for rules and create object in its default state

No

The third column indicates whether a discovered item is subjected to further rules after a particular rule action is implemented. This is of particular importance when you create multiple rules in the I/O model tree, as the order the rules are implemented will affect browsing results. For example, using a rule that implements the STOP action means that no other rules will be applied to items that met the conditions of the STOP Rule. You could therefore implement a STOP rule followed by a DISCARD rule during browsing: items that meet the condition of the STOP rule would therefore be unaffected by the DISCARD rule (regardless of whether they meet the conditions of the DISCARD rule or not). If a rule action is set to SCRIPT, the rule will run an embedded Lua script. The script should be written to return a function which implicitly gets as argument the currently found object. For instance, if a discovered item meets the rule conditions, the following script would be run which would set the items properties to historize values:

Embedded Lua Script in Rule - Historizes Items meeting Rule Conditions
Figure 7. Embedded Lua Script in Rule - Historizes Items meeting Rule Conditions

The return value of the script specifies any further action (and therefore whether the search for applicable rules continues). The return value of this script is set to “CONTINUE”, therefore other rules can be applied to the item. Changing the return to “STOP” or “DISABLE” would prevent other rules from being applied (however in the case of “DISABLE” the discovered item would be created in the I/O model tree and then disabled).

If no return value is specified in the script (or a return value is specified other than the actions listed in the table above) then the action will be returned as "CONTINUE" as default and the search for applicable rules will continue.

Further information on the implementation of Lua scripts by rules is available in the Lua Scripting section. Here you can find information on the Lua functions that can or cannot be called when the script is embedded in a Rule object.

Rule Placement

Rules situated beneath a Connector will be applied to the browsing of all data sources that lie beneath that Connector. A Rule situated beneath a data source will only be applied to the browsing of that data source. If Rules are situated beneath both Connector and data source, the Rule beneath the data source is applied first, then Rules higher up in the tree hierarchy.

Placement of Rules in I/O model tree - Order in which they are implemented
Figure 8. Placement of Rules in I/O model tree - Order in which they are implemented
For rules to be implemented during browsing they must be placed beneath the Connector object or a Data source in the I/O Model tree.