An alert alarm clears before its 60-second escalation delay expires, so the Warning redirection is aborted, yet the engineer still needs a reliable count of those completed, non-escalated occurrences. Follow the transition path: the point enters Alert, the delay runs, and either Warning or Clear terminates the pending outcome. A live counter should follow those transitions; an event-log query should reconstruct them only for reporting.
Where does the counting path stop?
Layer one first. For a report query, the reporting client must reach the event database through its configured network and database session. Confirm that the event log is accessible and that point events appear with usable timestamps before investigating query logic. The request stops at stored records; it does not observe the alarm state directly.
A live counter takes a shorter path: point alarm transition to Logic, Calculation point, or Method Alarm Redirection, then to an Internal Analog Point holding the result. This path avoids repeatedly scanning historical records, but its result depends on every required transition reaching the counter logic.
| Path | Sender | Intermediate hops | Result location | Primary check |
|---|---|---|---|---|
| Event-log report | Report or query client | Network session, database service, event records | Query result | Target-point events and timestamps are present |
| Transition logic | Alarm state change | Logic or Calculation execution | Counter point | Alert, Warning, and Clear transitions execute once |
| Paired redirections | Severity-specific alarm redirection | Immediate method execution | Internal Analog Point | Low and Elevated filters are mutually correct |
Which counting approach fits the requirement?
| Approach | Counting rule | Best use | Main limitation |
|---|---|---|---|
| Event-log query | Count Alert occurrences having no Warning before their matching Clear | Occasional reports and historical analysis | Repeated correlation can be expensive for live display |
| Logic or Calculation point | Track each occurrence and increment only when it clears without Warning | Live count with explicit occurrence semantics | Requires retained state and transition handling |
| Paired Method Alarm Redirections | Add one at low severity; subtract one at Elevated severity | Simple, database-efficient running total | An active Alert is provisionally counted during the 60-second window |
Use the event log when the count is requested occasionally or must be recalculated for a historical interval. Use transition-driven Logic or a Calculation point when operators need a continuously available count. Prefer the transition-logic method for this requirement because it records the outcome only after Clear proves that escalation did not occur.
The paired-redirection method is efficient when provisional counting is acceptable. Configure one Method Alarm Redirection with a 0 s delay for low severity to increment an Internal Analog Point, and another with a 0 s delay for Elevated severity to decrement it. After completed occurrences, the arithmetic represents Alert entries minus escalations. During an active Alert that has not yet cleared or escalated, however, the value is temporarily one higher.
Why is an event-log query more than a severity count?
Counting all Alert records and subtracting all Warning records works only when every escalation produces exactly one matching Warning record and the selected time range contains both sides of every occurrence. Boundary conditions break that arithmetic. An Alert near the end of the reporting interval may escalate after the interval, while an Alert created before the interval may clear inside it.
Build a historical query around alarm occurrences rather than independent severity totals. Read the actual event-log schema to identify the point key, event timestamp, alarm state or severity, and any occurrence or sequence key supplied by the system. Then apply this decision path:
- Select events for the target point and requested reporting interval, including enough boundary context to resolve occurrences crossing the interval edges.
- Order the events by the database's occurrence sequence when available; otherwise use its event ordering and timestamp fields.
- Start an occurrence when the point transitions into Alert.
- Mark that occurrence escalated if it reaches Warning before its corresponding Clear.
- Count the occurrence only if Clear arrives without an intervening Warning.
Do not group solely by timestamp. Multiple transitions can share timestamp resolution, and clock or display-time conversion can distort ordering. Use the event database's native ordering field where one exists. Also define whether the report counts occurrences that started during the interval or occurrences whose Clear outcome occurred during it; those are different reporting rules.
Why does transition logic give the cleanest live count?
The alarm has three relevant states: pending at Alert, disqualified at Warning, and decided at Clear. Incrementing on the initial Alert transition is premature because the final outcome remains unknown for 60 seconds. Retaining two internal flags lets the logic defer the count until the outcome is final.
Pseudocode:
On Alert transition:
mark the occurrence pending
clear the escalated marker
On Warning transition:
mark the occurrence escalated
On Clear transition:
if the occurrence is pending and not escalated:
increment the count
clear both occurrence markersTrigger the Logic or Calculation point from alarm transitions, not from a periodic database scan. Serialize updates to the counter so two executions cannot read the same old value and write the same new value. Store the count and occurrence markers in objects that retain the required state across normal execution cycles. Define operator reset behavior separately from automatic counting.
How should the live counter be configured?
- Create an Internal Analog Point to hold the count. Set its initial value according to the reporting policy: zero for a new accounting period, or a controlled restored value when continuity is required.
- Create retained state for whether the current alarm occurrence is pending and whether it reached Warning.
- Trigger the Logic or Calculation point on the target alarm's Alert, Warning, and Clear transitions.
- On Alert, start one pending occurrence. Ignore duplicate evaluations that do not represent a new transition.
- On Warning, disqualify the pending occurrence. Do not decrement the total because this method has not incremented it yet.
- On Clear, increment the Internal Analog Point only when the occurrence remained pending and never reached Warning. Then clear the retained occurrence state.
- Add an explicit, access-controlled reset method if the counter represents a shift, batch, or maintenance period. Record resets separately so a zero cannot be mistaken for missing execution.
If implementing paired redirections instead, apply the low-severity and Elevated-severity filters to separate immediate redirections, both at 0 s. Confirm that each method changes the same Internal Analog Point exactly once. Prevent a manual counter reset while an Alert is pending; a later Elevated decrement could otherwise drive the value below zero.
How is the result verified?
| Test sequence | Expected transition-logic result | Expected paired-redirection behavior |
|---|---|---|
Alert, then Clear before 60 seconds
|
Increment once at Clear | Increment at Alert and retain the increment |
| Alert, remain active through escalation, then Clear | No increment | Increment at Alert, decrement at Warning |
Alert active for less than 60 seconds
|
No change until outcome is known | Temporary increment while pending |
| Repeated evaluation without a state transition | No additional count | No additional method execution |
Run each sequence from a known counter value and compare the Internal Analog Point against the alarm event records. Include a restart or service interruption during the 60-second pending window and verify that the retained state follows the site's continuity policy. Finally, test one non-escalated occurrence followed by one escalated occurrence and confirm that only the first contributes to the completed non-escalated count.
FAQ
Why does subtracting Warning counts from Alert counts give the wrong result?
Independent totals lose occurrence pairing and fail at reporting-window boundaries. Correlate each Alert with its Warning and Clear transitions before counting it.
Why does the paired-redirection counter increase before 60 seconds?
The low-severity Method Alarm Redirection executes immediately at 0 s. Its increment remains provisional until Warning causes the matching decrement or Clear confirms a non-escalated occurrence.
Why does the live counter sometimes go negative?
A decrement executed without its matching increment, or the counter was reset while an occurrence was pending. Check severity filters, duplicate or missing transitions, and reset timing.
Why does the event-log report disagree with the live point?
Check whether the report counts occurrences by Alert time or Clear time, whether it includes interval-boundary events, and whether the live point was reset. Those policies must match before the values can agree.
How do I verify that cleared alerts are counted correctly?
Start from a known value, trigger Alert, clear it before 60 seconds, and confirm one increment. Then allow a second Alert to reach Warning and confirm that the completed non-escalated count does not increase.