Alarm Scenarios
In a general scenario AMU receives the asset property value changes in a sequential order and each new value is evaluated and an alarm created if breaking an alarm rule. But there are scenarios where the values from an asset could be delivered out of sync, meaning an older value received slightly after a newer one. An example, explaining the possibility of having values slightly out of sync .values: If the connection is lost between ThingWorx and Kepware, there is a Store & Forward mechanism in Kepware that will send all the buffered values to ThingWorx using multiple threads after the connection is restored.
 |
• AMU does not handle milliseconds. It handles timestamp up to 1 second resolution. But as we may receive values that have the exact same timestamp to the second, but with different milliseconds, there are scenarios below to explain how the Event Model is going to deal with such timestamps.
• AMU does not have versions on alarm rules. This means that any value received (in sync or out of sync) will always be evaluated against the alarm rule that is current, regardless of the timestamp of the value.
|
The following sections explain how AMU is going to handle asset property values under different scenarios.
Scenario 1: Value received in the past triggers a new alarm
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 • value #1 - Timestamp 03:00:00 value 23.0 • value #2 - Timestamp 03:01:00 value 23.5 • value #3 - Timestamp 02:58:00 value 25.2 | Alarm Events • No alarm is created when processing value #1 and value #2. • An alarm is created when processing value #3. • The start time of the alarm is 02:58:00 as this is this value that first triggered this alarm. • The end time is 03:00:00 as the value following the one that triggered the alarm is inside normal operating range. • The status of the newly created alarm event is closed. |
 | |
Scenario 2: Value received in the past will require the update of an existing alarm based on start time and value
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 • value #1 - Timestamp 03:01:00 value 25.1 • value #2 - Timestamp 02:58:00 value 25.2 | Alarm Events • An alarm is created when processing value #1 with a start Time of 03:01:00. There is no end time as alarm is still open. • When processing value #2, as it is a value that would open an alarm for the same rule that value #1 already opened, the following changes are applied to the existing alarm: ◦ Change the start time of the alarm created by value #1 from 03:01:00 to 02:58:00. ◦ The status of the alarm is not changed as the alarm is still open. |
 | |
Scenario 3: Value received in the past will require the update of an existing alarm based on end time and value
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 • value #1 - Timestamp 03:00:00 value 25.1 • value #2 - Timestamp 03:05:00 value 24.5 • value #3 - Timestamp 03:03:00 value 24.8 | Alarm Events • An alarm is created when processing value #1 with a start time of 03:00:00. There is no end time as alarm is still open. • When processing value #2, as it is a value that is inside normal operating range, the following changes are applied to the existing alarm: ◦ Set the end time of the alarm created by value #1 to 03:05:00 ◦ Set the status of the alarm to close. • When processing value #3, as it is a value that is inside normal operating range, but out of sync, the following changes are applied to the existing alarm: ◦ Change the end time of the alarm closed by value #2 from to 03:05:00 to 03:03:00. ◦ There is no change to the status of the alarm as it is already closed. |
 | |
Scenario 4: Value received in the past will require the update of an existing alarm based on value and boundaries (Below vs Above range)
Example | Expected Result |
|---|---|
Alarm Rule is: Value NOT in between 20 and 25 • value #1 - Timestamp 03:00:00 value 19.8 • value #2 - Timestamp 02:58:00 value 25.2 | Alarm Events • An alarm is created when processing value #1 based on alarm rule and the value of 19.8 received (below 20). ◦ The start time is 03:00:00 and there is no end time as alarm is still open. • When processing value #2, as the alarm already exists, the following changes are applied to the existing alarm: ◦ Change the start time of the alarm created by value #1 from 03:00:00 to 02:58:00. ◦ The status of the alarm is not changed as it is still open. |
 | |
Scenario 5: Receiving a value in the past does not have any impact on alarms
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 • value #1 - Timestamp 02:00:00 value 20 • value #2 - Timestamp 02:10:00 value 26 • value #3 - Timestamp 02:05:00 value 23 | Alarm Events • No alarm is created when processing value #1 as it is in normal operating range. • An alarm is created when processing value #2, based on alarm rule and the value of 26 received which is greater than 25. ◦ The start time is 02:10:00 and there is no end time as alarm is still open. • When processing value #3, as the alarm already exists, and this value is inside normal operating range, there is no impact on any alarm. |
 | |
Scenario 6: Receiving a value in the past forcing the split of an alarm
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 • value #1 - Timestamp 03:00:00 value 23.0 • value #2 - Timestamp 03:05:00 value 25.2 • value #3 - Timestamp 03:10:00 value 25.4 • value #4 - Timestamp 03:07:00 value 24.8 | Alarm Events • No alarm is created when processing value #1 as it is in normal operating range. • An alarm is created when processing value #2, based on alarm rule and the value of 25.2 received which is greater than 25. ◦ The start time is 03:05:00 and there is no end time as alarm is still open. • When processing value #3, as the alarm already exists, there is no impact on the existing alarm that is still open. • When processing value #4, which has a value inside normal operating range, but a timestamp in between two values outside of normal operating range, there will be a split in the alarm. ◦ The alarm created at 03:05:00 is closed because the next value received is in the normal operating range. ◦ But since the value #4 is outside the normal operating range, a new alarm is created at 03:10:00. |
 | |
Scenario 7: Alarm rules based on limits changing over time
Example | Expected Result | ||||
|---|---|---|---|---|---|
Alarm Rule is: Value > Upper Reject Limit (Time Dependent) • value #1 - Timestamp 03:00:00 value 23.0 (Limit = 25.0) • value #2 - Timestamp 03:05:00 value 25.2 (Limit = 25.0) • value #3 - Timestamp 03:10:00 value 23.6 (Limit = 25.8) • value #4 - Timestamp 03:07:00 value 25.7 (Limit = 25.8) | Alarm Events • No alarm is created when processing value #1 as it is in normal operating range(Limit is 25.0 until 03:05:59). • An alarm is created when processing value #2, based on alarm rule and the value of 25.2 received which is greater than the limit (25.0) at that time. ◦ The start time is 03:05:00 and there is no end time as alarm is still open. • When receiving value #3, below two things happen ◦ The new value of 23.6 is now inside normal operating range as the limit at 03:10:00 is 25.8 (since 03:06:00). ◦ This means the alarm created previously is closed with an end time of 03:10:00. • When receiving value #4, below two things happen. ◦ The new value of 25.7 is now inside normal operating range as the limit at 03:07:00 is 25.8 (since 03:06:00).
◦ This means the alarm closed previously will have end time adjusted to 03:07:00 due to out of sequence value #2 which got inserted.
| ||||
 | |||||
Scenario 8: Out of limits value received in the past with the same timestamp (except milliseconds) as a value already received
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 • value #1 - Timestamp 03:00:00.568 value 25.1 • value #2 - Timestamp 03:05:00 value 24.3 • value #3 - Timestamp 03:00:00.235 value 25.2 | If a value is received for a tag at a specific time (in this case 03:00:00), and other values are received at the same time, but at different milliseconds, the new values are ignored. |
 | |
Scenario 9: Inside limits value received in the past with the same timestamp (except milliseconds) as a value already received
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 • value #1 - Timestamp 03:00:00.568 value 25.1 • value #2 - Timestamp 03:05:00 value 24.3 • value #3 - Timestamp 03:00:00.235 value 25.2 | If a value is received for a tag at a specific time (in this case 03:00:00), and other values are received at the same time, but at different milliseconds, the new values are ignored. |
 | |
Scenario 10: Out of sync value received after alarm rule change will not create an alarm
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 (Up to 02:59:59) Alarm Rule is: Value > 26 (Up to 03:00:00) • value #1 - Timestamp 03:00:00 value 23.0 • value #2 - Timestamp 03:01:00 value 23.5 • value #3 - Timestamp 02:58:00 value 25.2 | Alarm Events • No alarm is created when processing value #1 and value #2. • If the alarm rule would not have been changed, value #3 would have generated an alarm. But it won’t as there is no versions of alarm rules. This means that when receiving the value at 02:58:00 it is out of sync since it is received after 03:00:00. This new value is evaluated against the current rule, which is value greater than 26. So, no alarm is created. |
 | |
Scenario 11: Out of sync value forcing an alarm to be closed due to alarm rule change
Example | Expected Result |
|---|---|
Alarm Rule is: Value > 25 (Up to 02:59:59) Alarm Rule is: Value > 26 (Up to 03:00:00) • value #1 - Timestamp 02:58:00 value 25.2 • value #2 - Timestamp 03:02:00 value 26.1 • value #3 - Timestamp 02:59:00 value 25.2 | Alarm Events • An alarm is created when receiving value #1, according to the rule at this time, which is value greater than 25. • When receiving value #2, there is no change to the alarm. It is important to note though that as the alarm rule was changed at 03:00:00, and value #2 comes at least at 03:02:00, it is evaluated against the new alarm rule, which is value greater than 26. • When receiving value #3, two things are happening ◦ Even if the timestamp of value #3 value is 02:59:00 and at that time the alarm rule was still “value greater than 25”, the active the alarm rule is used at the time of the evaluation, which in this case is at least 03:02:00 as value #3 is received after this time. So, since 25.2 is not greater than 26, 25.2 is now considered inside operating range and the alarm must be closed. ◦ But by closing this alarm, it means that value #2 (26.1) that previously had no impact, now has an impact. A new alarm is created as this value (26.1) received at 03:02:00 must be evaluated against the current alarm rule, which is value greater than 26, which is outside of the operating range. |
 | |