SCADA Alarm Management Skill

1. Alarm Philosophy

An alarm philosophy documents the principles governing every alarm in a facility. It is the foundation of ISA-18.2 compliance and should be established before any alarm is configured.

Fuuz tip: Store the alarm philosophy as a Document record with category AlarmPhilosophy.

2. Alarm Lifecycle (ISA-18.2 States)

ISA-18.2 State Diagram

+------+  alarm  +-------+  acknowledge  +-------+  clear   +------+
| NORM |-------->| UNACK |-------------->| ACKED |--------->| NORM |
+------+         +-------+              +-------+          +------+
                    |                                         ^
                    +--- clear (before ack) ------------------+
                    |                                         ^
                    +-- clear --> RTN-UNACK -- acknowledge ---+

Side states (enter/exit from any active state):
  SUPPRESSED    logic-based or state-based hide from operator
  SHELVED       time-limited disable (auto-returns on expiry)
  OUT-OF-SERVICE  disabled for maintenance (manual re-enable)

ISA-18.2 to Fuuz State Mapping

Fuuz State Transitions

           trigger              acknowledge             clear
  NORM --> ACTIVE (alarmStateId) --> ACTIVE_ACK --> CLEARED
             |                                        ^
             +------ clear (before acknowledge) ------+

• Active alarms identified by clearedAt: { _isNull: true }

3. Priority Classification

ISA-18.2 recommends 3-4 priority levels in a pyramid -- few critical, more low-priority.

Target distribution (pyramid): ~5% Critical, ~15% High, ~30% Medium, ~50% Low. An inverted pyramid indicates poor rationalization.

4. Alarm Rationalization

Rationalization is the structured review documenting and justifying every alarm.

Alarm Classification Categories

5. Alarm Design Parameters

Setpoint, Deadband, and Limit Diagram

Value
  ^
  |--- upperLimit + deadband ------- alarm triggers (HighLimit)
  |--- upperLimit ------------------- alarm clears
  |--- upperWarning + deadband ------ alarm triggers (HighWarning)
  |--- upperWarning ----------------- alarm clears
  |=== setPoint +/- tolerance ======= normal operating range
  |--- lowerWarning ----------------- alarm clears
  |--- lowerWarning - deadband ------ alarm triggers (LowWarning)
  |--- lowerLimit ------------------- alarm clears
  |--- lowerLimit - deadband -------- alarm triggers (LowLimit)
  v

Fuuz DataPoint Limit Fields

Limit Evaluation Priority (first match wins)

1. HighLimit / LowLimit -- value > upperLimit + deadband or value < lowerLimit - deadband
2. HighWarning / LowWarning -- value > upperWarning + deadband or value < lowerWarning - deadband
3. Deviation -- |value - setPoint| > tolerance + deadband

Deadband Behavior

Two applications of deadband:

1. Limit deadband -- Offset added to limit thresholds before triggering
2. Active alarm deadband -- New alarm only when |currentValue - lastTriggerValue| > deadband

Example: upperLimit=100, deadband=5
  Value 103 --> below 105 (limit+deadband) --> NO alarm
  Value 106 --> above 105 --> HighLimit ALARM (triggerValue=106)
  Value 104 --> |104-106|=2 < 5 --> SKIP (within active alarm deadband)

Delay Timers

Implementable in flow logic (timer node before alarm creation):

6. Performance Metrics (ISA-18.2 Benchmarks)

Key definitions:

• Standing alarm -- active (uncleared) > 24 hours; chronic condition needing re-rationalization
• Chattering alarm -- > 3 state changes/min; needs deadband or setpoint adjustment
• Nuisance alarm -- triggers but requires no operator action; candidate for removal
• Alarm flood -- rate exceeds 10/10 min per operator; requires suppression or grouping

7. Advanced Alarm Management

Suppression

Fuuz: Guard node in alarm flow checks suppression condition before creating alarm. Log suppressed alarms for audit.

Shelving

Operator-initiated, time-limited disable. Max 8-12 hours (one shift). Require supervisor approval for safety alarms. Record who, when, why, duration.

Fuuz: Set alarmEnabled = false on DataPoint + scheduled flow to re-enable after duration.

Flooding Management

1. Suppression logic -- auto-suppress consequential alarms during known upsets
2. First-out annunciation -- highlight first alarm in cascade for root-cause identification
3. Alarm grouping -- group by equipment, cause, area, or time window
4. Prioritized display -- during floods, show only Critical/High; queue Medium/Low
5. Post-flood review -- analyze for rationalization improvements

Grouping Strategies

8. Fuuz Implementation Mapping

Alarm Evaluation Flow

TelemetryRaw Create (DataChanges trigger)
  --> Query DataPoint + Active Alarms (clearedAt _isNull: true)
  --> Guard: alarmEnabled == true
  --> JavaScript: Evaluate limits with deadband (priority order)
  --> Guard: alarm condition detected
  --> Mutate: Create Alarm (alarmStateId: ACTIVE)
  --> Optional: Publish to UNS

DataPoint-to-Alarm Relationship

DataPoint (1) --------> (*) Alarm
  upperLimit, lowerLimit       limitType, limitValue
  upperWarning, lowerWarning   triggerValue, deviation
  setPoint, tolerance          alarmStateId
  deadband, alarmEnabled       triggeredAt, acknowledgedAt, clearedAt
  isCritical, alarmPriority    dataPointId (FK), notes

Alarm Schema

UNS Alarm Topic

fuuz/{site}/{area}/{line}/{cell}/{equipment}/alarm

Example Queries

Active alarms:

query ActiveAlarms {
  alarm(where: { clearedAt: { _isNull: true } }, orderBy: [{ field: triggeredAt, direction: desc }]) {
    edges { node { id code limitType alarmStateId triggeredAt dataPoint { code asset { code } } } }
  }
}

Standing alarms (active > 24h):

query StandingAlarms($threshold: DateTime!) {
  alarm(where: { clearedAt: { _isNull: true }, triggeredAt: { _lt: $threshold } }) {
    totalCount
    edges { node { id code dataPointId triggeredAt limitType } }
  }
}

9. Cross-References

Version History