Continuous Event Detection Window behavior after Gateway restart – new eventId generated

Ignition
1

Hi,

I'm trying to understand the expected behavior of the Continuous Event Detection Window in Ignition 8.3 after a Gateway restart.

We noticed this behavior with some real alarms, so we reproduced it with a very simple test alarm to remove our tag logic from the equation.

Configuration

Ignition version: 8.3

Gateway Alarming Settings:

  • Continuous Event Detection Window: 10 minutes
  • Live Event Limit: 5
  • Notify Initial Events: disabled

For the test we created a simple alarm called Alarm test.

The alarm condition was kept TRUE during the entire test, and the alarm had:

  • Active Delay: 180 seconds
  • Alarm state before restart: Active / Unacknowledged

Test

The alarm became active at:

08:15:08.118
eventId = ea153058-ccf6-4c07-a8b1-88ac1d6d153d
eventType = 0 (Active)
eventFlags = 0

We then performed a Gateway restart, without changing the alarm condition.

The Gateway startup event was recorded at:

08:16:18.167
evt:System Startup

After startup, a new Active event was generated at:

08:19:01.251
eventId = 3041a2bd-e03b-4029-8669-3d39fb8cddb9
eventType = 0 (Active)
eventFlags = 0

So the sequence in the Alarm Journal is essentially:

08:15:08   ACTIVE     eventId A

             ↓ Gateway restart

08:16:18   System Startup

08:19:01   ACTIVE     eventId B

There is no Cleared event for eventId A in the Alarm Journal.

The alarm condition remained TRUE throughout the test, and the Gateway restart was well within the configured 10-minute Continuous Event Detection Window.

What we are trying to understand is:

Is this the expected behavior?

Our interpretation of the description of Continuous Event Detection Window was that an Active/Unacknowledged event could be retained across a short Gateway restart, preventing a new event from being generated after startup.

In this case, however, the previous eventId is left in the journal with only its Active event, and after startup a new Active event with a new eventId is generated.

The 180-second Active Delay may also be relevant, since the new Active event appears approximately three minutes after startup. We would like to understand how Active Delay interacts with Continuous Event Detection during Gateway startup.

We originally discovered this with alarms that can remain active for hours or days, where after a Gateway restart the old eventId can remain in the Alarm Journal without a Cleared event and a new eventId is subsequently created for the same alarm.

Thanks!

2

There is a patch in 8.3.7 to fix alarm events being restored during a restart. This may fix the narrow issue. However, there's always been quite a few alarming anomalies, so I don't want to overstate the solution.

3

Is this the expected behavior?

No. However, Bobby is correct, this was an issue that impacted 8.3.0 -> 8.3.6. This issue was fixed in 8.3.7 via IGN-15609.

Essentially, the way the Continuous Event Detection Window works is during gateway shutdown a file is persisted to disk in the root Ignition directory in a file: .alarms_[timestamp]. On gateway start the gateway checks for this file, checks the configured Event Detection Window and restores those alarms (including their eventIds) if less time than the configured Event Detection Window has elapsed. The bug was caused because that file wasn't making it to disk, feel free to double check this is what you're seeing. Sorry, I mis-remembered this issue, the bug wasn't due to the file not making it to disk, it was an issue on startup. Updating to 8.3.7+ will fix this.

We would like to understand how Active Delay interacts with Continuous Event Detection during Gateway startup.

In the working model, 8.3.7+, Active Delay won't impact the Event Detection Window. When an alarm is created for the first time we generate a new eventId which is associated with the Cleared Acked initial event. When Active Delay expires, the alarm will transition to an Active Unacked state. Regardless of Active/Cleared or Unacked/Acked state, an alarm event that is restored on gateway startup from the persisted file on disk will retain it's eventId.