Understanding Alarm Stories

The alarming philosophy of AVEVA Enterprise SCADA is that the alarm summary should always display the current state of the system. For instance, consider the following scenario:

• An analog point is in the "high" alarm state.

• Said point is flashing and unacknowledged.

If the analog point transitions to a "high-high" alarm state, the system replaces the "high" alarm with a "high-high" alarm to reflect the current state of the point.

Compare this with how other SCADA systems operate. For instance, System Platform would add two separate alarms, each of which the Controller would have to acknowledge separately. AVEVA believes the Enterprise SCADA philosophy is better: it reduces the number of alarms a Controller needs to acknowledge, and never misleads a Controller as to the current state of the system.

However, this does make analysis and auditing of the alarms more complex, as the system does not write a single row to the Alarm Audit (almaudit) table to represent the entire history of the alarm. Rather, the system logs an event for every stage of the alarm’s lifecycle. We call this the Alarm Story.

An Alarm Story will always have a start event, and will almost always include a Controller acknowledge event. However, the total number of events in an Alarm Story will vary according to changes in the field, Controller actions, suppressions and inhibits, and other Controller actions.

The following new columns were added to the almaudit table:

• alarmGUID - This column links together all the events that describe the Alarm Story, such that an integrator can use simple Microsoft SQL GROUP BY statements to isolate the Alarm Story for one alarm.

• alarmAuditType - This column describes the state of the alarm, such that an integrator can use Microsoft SQL PIVOT commands to create a single row, with all the suitable timestamps required for analysis and metric calculation.

The following alarm functionality takes advantage of Alarm Stories.

• Generic Database Alarms

  • Transitioning between normal and abnormal states

  • Transitioning between abnormal states

  • Transitioning between normal states

  • Status/Multistate SustainCOS and Unsustained alarms

  • Simultaneous alarms with different categories

  • Inhibiting Abnormal alarms

  • Inhibiting Normal alarms

  • Manual entry point alarms

  • Alarm Parking and pre-parking

  • Alarm purge

    • Bulk and individual alarm purging

  • Deletion of alarms

    • Deletion of orphaned alarms (The RealTime database [RTDB] record has been deleted.)

    • Deletion of lower priority alarms

    • Requested alarm deletion

  • Re-Alarming

• Application Alarms

• System Alarms

• Alarm Acknowledgement

  • Persistent alarms

  • Non-persistent alarms

  • Bulk acknowledgement and individual acknowledgement

• Timed Inhibits with the STATE_ALARM_REDUCTION configuration setting enabled

• Timed Alarm Suppression