Rule Objects

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

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.

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.

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:

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

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.