Previous | Table of Contents | Next |
Contents
This chapter contains the following sections.
Section Title |
Page |
||||
“Information Model? | 5-2 | ||||
“API? | 5-6 |
The alarms & events interface provides a client with a way to subscribe for alarms and events generated within RTUs, devices,
or any software. The server supports various filter functions so that the client can compose a filter matching its current
interest in alarms and events. Once the client sets up a filter specification it has to supply the server a callback object
used by the server to notify the client with generated alarms and events.
Events just reports state changes while alarms have an associated alarm state and fault state. Alarms are generated with the
intent to gain attention to a condition that needs operator intervention. Hence alarms and events are recorded and presented
to operators. Alarm presentation usually involves acoustic annunciation and some highlighting (e.g., red color and/or blink,
etc.). An operator shall acknowledge the alarm state and the fault state disappear when the fault causing the alarm disappears.
Equipment and functions that may generate alarms and events are:
• Process instrumentation making sensor data and actuation capabilities available.
• Remote terminal units (RTUs) or substation control systems, reading sensor data, and controlling actuators.
• Process communication units connecting to RTUs or substation control systems.
• SCADA subsystem making processed sensor data and control capabilities available to operators, applications, or other systems.
• Energy Management System (EMS) - subsystem using the SCADA subsystem for extended processing and control.
An example flow of alarms, events, and acknowledgments are shown in Figure 5-1.
Figure 5-1 Alarms, events and acknowledgment flows in a SCADA/EMS