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 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.

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”?

Click Add Condition to add further conditions to the rule.

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.

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

If either condition is met, then the rule action will be implemented.
The Proccessing Order
Rules one the same hierarchical level of the object tree are applied in alphanumerical order. Therefore it is good practice to begin the names of the rule objects with digits to enforce the order in which you want the rules to be applied. E.g. rule '09 Xyz' is applied before rule '10 Abc'. Whether the proccessing of the rules is stopped or continued after a rule has been applied, depends on the Rule Action for each rule. See the third column in the table below.
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:
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:

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.

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. |