A chiller outlet crosses its high limit six times in ten minutes and returns to normal five times. One platform creates eleven “alarms,” each with a timestamp, severity, and message. Acknowledging the first leaves ten more tasks. Another platform keeps only the latest row to reduce noise, but then loses when the excursion began, how often the signal changed, and which rule version made the decision. These outcomes look opposite, yet they share one modeling error: an occurrence, a persistent abnormal condition, an operator alarm, and a channel notification have been compressed into one record.
The central conclusion is that an event is an immutable fact about something that occurred, while an alarm is a controlled episode derived from one or more facts because a person or process must respond. Acknowledgement, return to normal, closure, shelving, and suppression belong to alarm workflow; email, SMS, HMI delivery, and ticket creation are delivery or response results. Separating these objects allows a platform to preserve evidence without overwhelming operators and to answer four distinct questions: what happened, whether the condition still exists, who knows about it, and why it is or is not being shown.
This article does not present one project’s field names as an industry standard. Current Grus code restricts alarm workflow to open → acknowledged → resolved → closed, records actor, timestamp, previous state, comment, device, and trace_id, and publishes durable alarm.opened and alarm.resolved platform events. We reran six focused tests and obtained 6 passed. That evidence demonstrates state protection, audit history, owner/tenant authorization, and event publication in one implementation. It does not establish field alarm performance, certification, acceptable alarm rates, or a universal choice of state names.
1. A threshold crossing should not automatically become an alarm
An industrial data path contains at least four semantics. An observation is a value and quality for one point at observed_at. An event is an immutable discrete fact, such as a temperature entering the high range, a pump changing from running to stopped, or a communication link failing at 10:03. An alarm is created when the platform determines that an abnormal condition requires timely response from an assigned role. A notification is one attempt to deliver an alarm or other information through an HMI, email, SMS, webhook, or ticketing system.
An accepted event cannot be acknowledged or closed. An operator cannot make high_limit_entered un-happen; the operator can only acknowledge the alarm caused by that occurrence. A notification is not the alarm either. A failed SMS does not make the abnormal condition false, while a successful SMS does not prove that a person understood and accepted responsibility. Writing delivery state into alarm state allows a channel failure to alter operational truth. Writing acknowledgement into the event destroys replay and audit semantics.
Not every state change deserves an alarm. Maintenance-mode entry, batch changeover, recipe loading, and a planned valve closure may be valuable events without requiring immediate response. IEC 62682:2022 describes the primary alarm-system function as notifying operators about abnormal process conditions or equipment malfunctions and supporting their response. It also identifies alarm/event logs, historians, and performance metrics as related capabilities. The practical boundary is that an event qualifies as an alarm only when the abnormal condition, possible consequence, responsible role, and expected response are explicit. A red color or severity: high alone does not make a record actionable.
When one alarm_event table carries all four responsibilities, familiar failures follow. A mutable row erases history. Every oscillation creates a new task. Delivery retries create duplicate “alarms.” A return-to-normal event deletes an unacknowledged responsibility. A maintenance filter hides the source occurrence. Adding another type column does not repair these failures unless the implementation also defines which objects are immutable and which transitions are allowed.
2. Preserve facts, correlation, and response in three record types
A minimum implementation does not need to reproduce every process-industry state on day one, but it does need three durable record types. event_occurrence stores source, device, point, event ID, event type, occurrence time, receipt time, quality, raw lineage, and rule or model version. It is append-only and has no operator status. alarm_episode stores why response is required, whether the condition is active, severity, responsibility scope, first and last occurrence, a correlation key, the triggering rule version, and workflow state. alarm_action appends acknowledgement, shelving, unshelving, assignment, return to normal, closure, comments, ticket links, and notification results.
| Object | Key fields | Mutability | Question answered |
|---|---|---|---|
event_occurrence |
event_id, source_ref, event_type, occurred_at, received_at, quality, payload_hash, rule_version |
append-only | What happened, when, and according to which source? |
alarm_episode |
alarm_id, correlation_key, condition_state, workflow_state, severity, owner_scope, first_event_id, last_event_id |
state-machine controlled | Does the condition require response and who owns it? |
alarm_action |
action_id, alarm_id, action, actor, acted_at, reason, previous_state, trace_id |
append-only | Who did what, why, and under which authority? |
The important decision after this table is that alarm_episode is an operational projection over occurrences, not replacement storage for them. Occurrences and actions preserve immutable evidence. The episode maintains a convenient current aggregate. If an episode is closed incorrectly, the platform can rebuild it from events and actions. If the entire history was overwritten inside one alarm row, the same mistake becomes unrecoverable data loss.
condition_state and workflow_state must also remain separate. A temperature may have returned to normal while the operator has not acknowledged the excursion. The condition may still be active after an operator has acknowledged and started work. One status cannot express both axes without creating the illusion that acknowledgement clears the condition or that return to normal completes the response. A minimum design can use active/inactive and unacknowledged/acknowledged/closed, then add confirmed, shelved, suppressed, or out_of_service only when the operating process requires them.
3. Model an alarm as an episode, not a repeatedly overwritten message
An episode spans the first occurrence that satisfies an alarm condition through condition recovery and the required response closure. It may contain many raw samples, enter and exit events, rule evaluations, notification attempts, and operator actions. The episode gives an operator one stable work object. Eleven chiller oscillations should not create eleven unrelated tasks, yet showing one task must not delete eleven facts.
Episode creation requires an explainable correlation_key. Typical inputs include tenant_id + asset_id + alarm_definition_id + operating_mode. “Everything from the same device within five minutes” is not enough. A time window can bound the search, but it cannot replace semantics. Low lubrication pressure and high winding temperature on the same motor may demand different owners and actions. The same sensor evaluated before and after a rule-version change also needs a version boundary so a new definition does not reinterpret old evidence silently.
A restrained workflow starts at open, moves to acknowledged when the responsible role accepts it, becomes resolved after condition recovery and required repair evidence, and becomes closed when review or ticket obligations are complete. The current Grus implementation enforces this chain and rejects open → resolved with ALARM_STATE_NOT_ALLOWED. It records timestamps for acknowledgement, resolution, and closure and appends audit actions. This is not the only valid state model, but it proves one critical invariant: workflow transitions must be protected by explicit rules rather than allowing any PATCH request to set any state.
flowchart LR
E("Event occurrence
immutable fact"):::blue --> O("Create alarm episode
open + active"):::orange
O -->|operator acknowledges| A("Acknowledged
acknowledged + active"):::violet
A -->|condition returns| R("Resolved
resolved + inactive"):::green
R -->|evidence complete| C("Closed
closed + inactive"):::slate
O -->|condition returns first| U("Recovered, not acknowledged
open + inactive"):::cyan
U -->|review and acknowledge| R
O -.->|maintenance policy| S("shelved / suppressed
transitions still retained"):::red
A -.->|maintenance policy| S
S -.->|visibility restored| O
S -.->|visibility restored| A
O --> H("Append action / audit"):::blue
A --> H
R --> H
C --> H
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
classDef red fill:#FFF1F2,stroke:#E11D48,color:#881337,stroke-width:2px;
The “recovered but not acknowledged” path matters. OPC UA Part 9 models alarms as Conditions with Active, Acknowledge, Shelving, and Suppressed states. Its acknowledgement model may require clients to retain and acknowledge a previous Condition state after the condition has changed. An implementation can be simpler than the specification, but it should not assume that condition inactive means operator acknowledged. Otherwise, a short excursion disappears from the responsibility queue merely because the process returned to normal.
4. Deduplication, correlation, and suppression reduce noise without deleting facts
Alarm floods are controlled by three different mechanisms. Event deduplication accepts a retried or replayed event_id + payload_hash once. The same event ID with different content should fail closed with a collision reason rather than overwrite history. Episode correlation attaches repeated occurrences from the same alarm definition, asset, and operating context to one active episode. Notification suppression reduces current display or channel delivery during maintenance, shutdown, alarm floods, or ownership handover while preserving the underlying occurrences and episode transitions.
These mechanisms cannot be compressed into “do not alarm again for ten minutes.” Debounce can filter a noisy input but may delay the first response. Deduplication removes duplicate delivery, not genuine changes. Correlation reduces task count while retaining occurrence count, first time, and last time. Suppression changes visibility and delivery; it should not stop condition state transitions. OPC UA Part 9 explicitly states that state transitions continue while an alarm is suppressed, out of service, or shelved, even though clients normally do not display it. This distinction prevents a maintenance window from becoming a false claim that nothing occurred.
Suppression is itself an auditable action. The record needs actor or automatic policy, maintenance work order, scope, start and expiry time, affected definition or asset, and the result of automatic unsuppression. Silence, acknowledgement, shelving, suppression, and disablement should not share one button. Silence changes sound. Acknowledgement records responsibility. Shelving is a temporary operator choice. Suppression is usually driven by system context. Disablement prevents the definition from participating. Their authorization, duration, and audit requirements differ.
Root-cause correlation should not close dependent alarms automatically. A power failure may cause twenty devices to report offline. Those episodes can be grouped under an incident or causal cluster and the likely root cause can be promoted. The downstream events still prove the blast radius. Incident closure can trigger review of dependent episodes only when recovery conditions and policy are explicit; a generic “correlated” flag must not flatten their states.
5. Use time, versions, and audit records to handle late data and rule changes
Industrial events need at least occurred_at, received_at, and processed_at. occurred_at represents the device or edge observation. received_at records when the platform accepted it. processed_at records when a rule or projection completed. After an offline device uploads buffered data, these times may differ by hours. Database creation time alone makes an old failure look new. Device time alone can corrupt ordering when the source clock is wrong. The model should retain all three plus time quality and specify which one drives alarm creation, response SLA, and audit.
A late event should not rewrite a closed episode automatically. Accept the occurrence by stable event ID, then use episode range, rule version, and closure policy to append late evidence, reopen, create a supplemental episode, or send the item to manual review. The decision needs a reason code. “Ignored late data” without a reason cannot distinguish duplication, expiry, authorization failure, incompatible rule version, or a software defect.
Rule lineage must be equally explicit. An episode should reference alarm_definition_id, rule_version, threshold and deadband/on-delay/off-delay artifact, and activation time. New occurrences use the active definition. An existing episode normally retains the version that created it unless a migration plan explicitly requests reevaluation. Editing a rule in place and recalculating every active alarm can change severity, ownership, and closure condition at once, producing an unexplained change in the operator’s work object.
Audit has to explain both system decisions and human decisions. The system trail covers source occurrence, rule execution, correlation selection, suppression reason, notification delivery, and state projection. The human trail covers acknowledgement, comment, assignment, ticket, closure evidence, and overrides. Grus appends an audit record for each transition with previous_status, new status, operator, comment, device, severity, and trace_id, and supports target, trace, and device queries. The focused tests also verified that a vendor can update only alarms in its service-owner scope. Workflow authorization therefore belongs with asset responsibility boundaries, not only with front-end button visibility.
6. Before production, rehearse six failures
The first release needs only a provable skeleton: append-only event occurrences, controlled alarm episodes, append-only actions and audits, a stable correlation key, separate condition and workflow states, rule versions, and basic notification records. Root-cause graphs, machine-learned prioritization, and automatic ticket orchestration can wait. When facts and state transitions are not trustworthy, advanced correlation only produces unexplained results faster.
Rehearse at least six failures. First, redeliver the same event and verify that an episode links it once. Second, send the same event ID with different content and verify fail-closed collision evidence. Third, return the condition to normal before acknowledgement and verify that the episode remains reviewable. Fourth, attempt an illegal transition such as open → resolved and verify that the API rejects it without changing current state. Fifth, change the condition repeatedly during maintenance suppression and verify that occurrence and active/inactive history remain. Sixth, deliver an old-rule event late and verify that it does not reopen or rewrite a closed episode without an explicit reason.
Each rehearsal must check four outcomes: current episode state, complete occurrence history, explainable action/audit history, and independent notification state. A red lamp disappearing from an HMI is not acceptance evidence because the UI may have filtered the data. A new database row is not enough either because the owner may be unable to receive or acknowledge it. A minimum acceptance matrix crosses API, storage, audit, authorization, and channel boundaries.
Rollback is layered as well. A bad rule version rolls back the definition and active pointer without deleting generated events. A faulty correlation algorithm rebuilds the episode projection while preserving old and new correlation results plus migration audit. A broken channel or template retries delivery without changing the alarm. A faulty state-machine release first freezes unsafe transitions, then recalculates current projection from occurrences and actions. Rebuilding from immutable facts is the most important rollback capability in an alarm model. If recovery depends on guessing what a row contained before it was overwritten, the design has no reliable audit base.
Runtime metrics should follow the same boundaries. The event layer measures acceptance, duplicates, collisions, lateness, and quarantine. The episode layer measures standing alarms, chattering, active duration, and repeat correlation. Workflow measures acknowledgement delay, unclosed alarms, overrides, and authorization rejection. Notification measures delivery delay, failure, retry, and channel degradation. A single “alarm count” cannot locate whether a problem belongs to field input, a rule, an operator process, or a channel.
7. When a simple event table is enough
An append-only event table plus query views can be sufficient when the system only records data, no person must respond, and there is no acknowledgement, assignment, suppression, ticket, compliance audit, or response SLA. A small device may also leave protection to hardwired control or a controller and only record state changes upstream. A full alarm lifecycle in that context adds synchronization, authorization, and UI cost without corresponding value.
An independent alarm episode becomes necessary when an abnormal condition creates a time-bounded response obligation, or when the same condition moves across HMI, SMS, tickets, shifts, and audits. Multi-tenancy, multiple service owners, maintenance windows, late uploads, rule versions, causal grouping, and compliance evidence further require separate action logs and authorization boundaries. Device count is not the deciding factor; accountable response is.
Using ISA-18.2, IEC 62682, or OPC UA Alarms & Conditions terminology does not by itself prove compliance. The standards provide useful lifecycle, state, and responsibility references. A site still needs its own alarm philosophy, priority model, permitted response time, HMI rules, performance goals, and audit requirements based on process risk and organization. This article did not validate flood capacity, operator workload, long-term availability, safety integrity, or certification, so those conclusions must be measured and reviewed at the target site.
Conclusion
The first step toward fewer industrial alarms is not a larger silence button. Stop treating every event as an alarm and every notification as response. An immutable event explains what happened. An alarm episode explains whether response remains necessary. Condition and workflow need separate axes. Action and audit records explain who did what. Notification records independently explain whether delivery succeeded. Only with these boundaries can deduplication, correlation, shelving, and suppression reduce noise without deleting evidence.
Rollout can stay small. Preserve stable event IDs, three timestamps, and rule versions. Add alarm episodes and protected transitions. Then add action/audit, ownership scope, and notification records. Introduce suppression, causal grouping, and performance governance only after that foundation is replayable. For a platform that currently stores everything in one table, add immutable events and actions first, then split the existing status into condition and workflow axes. Do not begin by rewriting history; first prove that one real alarm can be replayed, explained, and rolled back.
For adjacent data boundaries, read Industrial Telemetry Pipeline Architecture and Industrial Tag Modeling and Governance. The telemetry path preserves observations, the tag contract stabilizes measurement meaning, and the alarm model governs actionable abnormal conditions and response. None should replace the others.