Mixing Rules and Actions with Triggered Conditions

Axeda strongly recommends that you either set and unset conditions with Rules and Actions OR configure conditions with one or more triggers - Missing Asset messages, alarms, and/or data expressions as part of their definitions. However, should you use both, you should understand the consequences.

The following basic rules apply:

1.       If a Rule or Action sets a condition, then the Platform always forces the condition to the specified condition in the Set action and unsets all other conditions.

2.       If a rule has multiple actions that change the condition, the actions always execute in sequential order. If a rule sets the condition in multiple actions, the condition is set to the condition set by the last action in the sequence. For example, a rule evaluates three data items and, based on their values, sets the condition first to 5, then to 3, and finally to 7. After the rule executes, the condition is 7.

3.       If a built-in trigger sets a condition, then the Platform always unsets any condition that was previously set by a Rule or Action. A condition with a built-in trigger does not unset a condition previously set by another condition that has a built-in trigger. Only if a built-in trigger is no longer true does the Platform unset a condition that has a built-in trigger. For example, a condition called Warning has three alarms associated with it; the condition cannot be unset until all three alarms are either closed or acknowledged.

4.       To unset a condition that has been set by a Rule or Action, you must create a Change asset condition action that unsets the condition. However, if that condition has a built-in trigger and that trigger is true when the Unset action runs, that condition will NOT be unset.

5.       If you have a Rule/Action condition and a built-in trigger condition and they both evaluate the same data item for the same value but set the condition to different conditions, then the condition set by the Rule/Action condition takes precedence over the built-in trigger condition. This is true even if the severity level of the built-in trigger condition is higher than that of the Rule/Action condition.

For example, AnalogItem1 is tested for a value of 4 by both a Rule and a built-in trigger condition. If the test is true, then a Change asset condition action associated with the Rule sets the condition to Warning, with a severity level of 4. Also, if the test is true, the built-in trigger condition sets the condition to Error, with a severity level of 6. The condition is set to Warning, with the severity level of 4. In general, try to avoid this situation. Choose either the Rule/Action condition OR the built-in trigger condition, but not both.

Mixed Usage Example

Set up the following built-in trigger conditions:

o        AlarmCondition1 - Sets the condition to Emergency when AlarmCondition1 is received. Emergency has a severity of 10 and a red icon.

o        AlarmCondition2 - Sets the condition to Warning when AlarmCondition2 is received. Warning has a severity of 3 and a yellow icon.

Set up the asset condition, Error, with a severity level of 5 and an orange icon (no trigger).

Set up a Rule/Action called SwitchA that sets the condition to Error when a value of 1 is received for the data item SwitchA.

The following table lists five trigger messages and the resulting changes in the condition of the asset as they occur. Assume that the starting condition is Good.

The following activities take place between 9 am and Midnight:

1.       AlarmCondition1 arrives at 9 am, setting the condition to Emergency (10).

2.       At Noon, the SwitchA rule/action is generated, unsetting the Emergency condition and setting the condition Error (5).

3.       At 3 pm a user acknowledges AlarmCondition1; this message has no effect on the condition.

4.       At 9 pm, AlarmCondition2 arrives, unsetting the condition set by the SwitchA rule (Error) and setting the condition Warning (3).

5.       At Midnight, AlarmCondition1 arrives again, removing the condition Warning from the Status field but NOT unsetting it (the alarm has not been acknowledged or set inactive, nor has it moved out of the severity range). The condition is once again set to Emergency; Emergency appears in the Status field on the Asset dashboard and in the Status column of any page listing the asset and its status. In addition, if you click the Status field on the Asset dashboard, you will see that AlarmCondition2 is still set.