Technical Article

Alarm and Event Handling and Processing in Process Control Systems

January 23, 2023 by Munir Ahmad

Events that cause alarms are not the most common events in a process system, but they must be handled with proper care, being both resolved and recorded in order to prevent hazards and downtime.

The critical data from power systems is monitored by inspecting the collected and calculated values to confirm that these process values and states lie within permissible limits. Violation of limit values and indications are defined as ‘events’ resulting in event processing in the SCADA system.

Events and alarms are generated as a result of changes detected in the status of power system objects, as well as in computer control systems with RTUs/PLCs, front-end servers, workstations, and networks.

Monitoring functions are included in nearly every SCADA control system, like status change reported from RTU/PLC (usually called data acquisition) and monitoring of status change in response to control operation, like device control of a circuit breaker.

Each collected and calculated indication value is compared with the previous value stored in the real-time database. The new state of indication can be monitored and compared with the present normal value and generate a normal/non-normal operation status of the device, which could be used for presentation in the event list. Likewise, analog values include limit values for monitoring alarm/warning limits.


alarm and event handling processing for in process control systems

Figure 1. Events and alarms are generated as a result of changes detected in the status of power system objects, as well as in computer control systems with RTUs/PLCs, front-end servers, workstations, and networks. Image used courtesy of leonidkos

 

Standard Event Processing Functions

The standard event processing functions contain functions for the following:

  • Event/Alarm registration. Events are registered and sorted in chronological order in the event/alarm list.

  • Delay handling of events. Event processing can be delayed in order to suppress a transient intermediate status of a breaker e.g. 00/11. For analog values, a short excess of a limit could also be suppressed.  Similarly for command supervision, when a command is issued, a timer is initiated. If no feedback is received before the timer expires, an alarm is generated.

  • Sequence of event recording. The events are time-tagged (in milliseconds) in the RTU. In the sequence of event recording functions, the events are time-tagged in the RTU, therefore the RTU must be able to handle time tagging.

 

Task Processing for SCADA Events

An event in the SCADA system is defined as any change in the detected state of power or control system. That change may be caused by a system response change in the process or in the SCADA system itself, or it may be caused by operator actions. Event presentations always give a detailed and selected view of the event status of the power system. Event processing functions maintain the event lists and alarm lists. The event lists are a historical record of the events while the alarm lists are just the current alarm status of objects.

In general, any SCADA system can perform several tasks for event processing:

  1. Partition of event storage for different sets of lists

  2. Classification of events for the subsystem, e.g., production and transmission systems and control systems

  3. Counting persistent and unacknowledged alarms per subsystem and station

  4. Initiating system response due to an event by activating different functions such as updating the operator screen, audible alarm, or mimic diagram

Event status is determined through event processing groups, and event class is determined by data type, which will be discussed later.

 

Flowchart of event processing, from event generation to final action.

Figure 2. Flowchart of event processing, from event generation to final action.

 

Event processing functions maintain an event list and an alarm list, which are further subdivided into the following event sublists:

  • Power system event

  • Control system event

  • Program traps event

  • Database maintenance

  • Power system alarm

  • Control system alarm

The multiple lists presented to the operator are all extracted from these internal sublists. The key concept that is necessary to understand is that the event processing for an object involves the event processing group parameters and object subsystem identification to determine the particular sublist to update. The event sublist is designed to wrap around the list, meaning that more recent events always replace the oldest event in the sublist.

 

Sub-system No.

Sub-System

1

Maintenance System

2

Telecontrol system

3

Control System

4

Power System

Table 1. Sample table subsystem division

 

SCADA Event Classification

Events are classified with respect to the following parameters:

 

1. System Part: System, Subsystem, Station

Events are associated with objects, perhaps an analog value, generator, transformer, RTU, etc. and are assigned to one or more levels of the system hierarchy. The breakdown of the system, subsystem, and stations is primarily intended for display hierarchy, list presentation, and authority control. It can also be used as a sorting criterion for event reports and status lists, as well as summary alarm indication for presentation. The subsystem identity is used for further subdivision of the process and control system.

 

2. Event Status

The event processing functions analyze the events and assign one or more statuses to the event. Each status reflects the way the event is presented to the operator. The event presentation possibilities are identified as:

  • Message presented directly in alarm list

  • Unacknowledged alarm, presented in the alarm list and in single line diagrams, remaining active until acknowledged manually by an operator

  • Persistent alarm, presented in alarm list and single line diagram, persisting until the alarm state disappears

 

3. Event class: Data type, Point class, Reason code, Priority

The event is also assigned a unique class that is used to construct the message and the event clause parameter and for sorting the presentation into priority order. The event class consists of four independent parameters:

 

Data Type 

Data type is the concept from the database point of view and data is determined for which the events belong like indications, measured and setpoint values, and control system devices. Standard data types include:

  • Indication
  • Measured value
  • Accumulator
  • Setpoint and regulation command
  • Control system unit
  • Remote terminal unit
  • General System Event

 

Point Class

Point class refers to a group of objects based on the type of device and position in the process. Examples of point classes are breakers, isolators, transformer fault signals, high voltage active power readings, etc.

 

Reason Code 

The reason code is utilized for the classification of the event with respect to its cause. Examples of reason codes are spontaneous events, control responses, etc.

 

Priority

Each event is given a certain priority based on the point class and cause of the event. Each combination of these two can be given priority.

 

Event class parameter descriptions.

Figure 3. Event class parameter descriptions.


 

Alarm Processing

An alarm group constitutes the processing to be performed when an analog value crosses a limit, when an indicator changes its status, or when an accumulator increment crosses a limit. Several kinds of treatment can be stated for an alarm group, such as persistent alarm, audible alarm, log-on printer, etc. The alarm list is structured according to the same principles as the event list. 

While the event list is a continuous record of all events, the messages in an alarm sublist reflect the current alarm status of objects. Messages with different alarm statuses are distinguished by means of color and symbol. 

There are mainly two types of alarms, momentary or persistent. 

 

Persistent Alarms

These alarms remain in the alarm list and are related to those objects for which a normal state or condition has been defined and the alarm condition occurs as the result of the transition of the object (value or state) to the abnormal condition.

 

Momentary Alarms

Contrary to persistent alarms, which remain in the alarm list until the indication or analog value returns to its normal status/value, momentary alarms are removed from the alarm list when acknowledged by the operator. Some alarms could be configured to remain in the system until an operator deletes them.

 

Alarm Handling in Process Control Systems

Events that cause alarms are not the most common events in a process system, but they must be handled with proper care, being both resolved and recorded in order to prevent hazards and downtime.