Alarms, Events and Audit Trail

This section presents the features available in Action.NET for setting up mechanisms for generating alarm messages and events. also presents the Audit Trail facility for a project.

 

Alarms description pages

  • This page details several aspects of alarm and events setup

  • Next page shows how to do Audit Trail setup

  • Alarm Group Sound

  • Alarm Send Email

Configuring alarm options

You can configure general behavior settings for event alarms that determine how the system handles alarms during startup and how long alarms and events should remain in the Alarm Historian. On the Edit>Alarms screen at its top, there are several configuration options.

To configure general alarm options:

  1. Go to Edit> Alarms > Groups.

  2. In the text box Initial Disable Time, at the top of the tab, type how long the system should wait during startup before considering that an alarm state should be an alarm.

    • During system start-up, IEDs may display alarms because they have not been initialized. This setting tells the system to wait for the configured time period, to let the boot complete, before the system considers alarms.

  3. In the field Life Time, enter the time that the Alarm Historian should keep the alarm data, in days.

  4. Checking the check-box "Enable Limits by Shift" , the mechanism for choosing sets of limits per "shift" is triggered at run time to implement, for example, limits differentiated by periods of the day. (light load, medium, heavy).

  5. The option Ignore Alarms During TimeDeadband, when marked activates the mechanism of non-generating alarms for tags denro of the dead band period, in which the time TimeDeadband (dead band time) was set.

Configuring alarm groups

Alarm groups allow you to configure settings for the behavior that will run when an alarm occurs. Use alarm groups to configure common behavior settings for use with multiple alarm events. Group settings determine actions such as whether a confirmation is required, whether a sound is played, what is recorded, and how alarms are shown.
The Action.NET comes with some predefined alarm groups that you can use, or if you prefer you can create others according to your needs and criteria.
To create a new group set the group name in the Alarms>Groups tab, where the behavior of the alarm item is specified.
The groups predefined in the Action.NET are:

  • Critical - critical messages that require recognition.

  • SystemEvent - System events that can be recorded on the Audit Trail.

  • Warning -Warning messages that do not require recognition.

To set up alarm groups:

  1. Go to Edit> Alarms > Groups .

  2. Enter or select the information as needed.

Column

Description

Name

Enter a name for the alarm group. The system indicates whether the name is not valid, showing the cell with the red outline.

AckRequired

If you choose Yes, in this option, the alarm remains in the alarm list until someone recognizes the alarm by double-clicking the app.

Sound

Select, from some available, typical MS-Windows, the sound that will play when the alarm occurs.

Gig

Select List so that an alarm message is displayed in the Alarm Object window in the

LogEvents

Select under what conditions you want the alarm to be registered with the Alarm Historian:

  • None- Alarm will not be logged. never.

  • Active - Records the alarm when it's active.

  • ActiveAck - Records when the alarm is active and recognized.

  • ActiveNorm - Records when the alarm returns to normal.

  • All - Registers in all the above conditions.

Colors

Select the colors you want to use for each state, both for text and for text background. The states are:

  • ActiveTag's in the alarm state.

  • Standardised- Tag was in the alarm state, but has already gone to normal state and still needs to be recognized.

  • Acknowledge - Recognized- Tag has been recognized, but is still in an alarm state.

ACKtimeout

Sets a timeout for alarm recognition. If the alarm is not recognized after the specified time, the alarm returns to the active state again

AutoAckTime

If the alarm is not recognized after the specified time, the system recognizes the alarm automatically

Notificationmethod 

Name of a method of some Script Class of type Server, odque will be called when any state change occurs
alarm in this group. The method has to have the prototype:

void NotificationName(AlarmEventInfo[] info).

See also "Subscribing Notifications" 

ActiveTimeDeadBand

Time in seconds to be used as dead band at the input dbandem alarm state. If the state of the point returns to normal before
this time has elapsed, the alarm will not be generated.

Description

Enter a description of this alarm group.

[Other columns]

For definitions of other columns that are available in many tables, see "Description of common columns" .

  • Keep adding as many alarm groups as you need.

  • If necessary, right-click a row to cut, copy, paste, or delete the row from the table.

  • See the following sections related to the other alarm tabs: "Configurando Alarm items"

Configuring Logical Alarm Areas

Another feature available in the alarm treatment is the configuration of Logical Areas where you can allocate alarm items. These logical areas are defined at the project level, and can also be defined as Sub Areas within areas, allowing the configuration of hierarchically arranged logical groupings.
The facility is used for group treatment of alarms from the same area. You can then obtain information on how many alarms are active or recognized in an area or sub area. You can enable or disable all alarms in an area (including its subareas), or only sub-areas.
In power utilities, it is generally used to identify a "bay" subdivision of the electrical system into Regional, Substations and Voltage Sectors. The logical areas of alarms exist precisely to extend this hierarchical definition to the groupings of alarm items. The hierarchy can reflect things like, UHEs, Substations, Stress Sectors.
It is defined in the tab Areas of the workspace of Alarms.

To create Areas:

  1. Go to Edit > Alarms> Areas.

  2. Right-click on the AlarmAreas root and select New York, U. area.

Enter a name for the area.

  1. Right-click on the new Area and select again.New Area to create a subarea.

  2. Continue adding child or sibling levels and inserting new areas as needed.

    • If necessary, right-click an Area to rename or delete.

Example of using AREAS

In the example of the following figure there is, as a first level the RESERVATORIO, SE and UGS areas of the JAU UHU. When registering the alarm items, in the AREA column you must fill in the Areas in which you want these items to belong.


Once created, the AREA will be available in the existing list in the AREA column of the
Alarm Items.

An AREA is a specific object that has as properties, counters of alarm ed, recognized, enabled, disabled, etc. as shown in the figure below. The area of JAU_UGS_JAU_UG1 and properties that can be viewed at run time is shown.

Configuring Alarm Items

When you set up alarm items, you can configure the specific threshold values that should generate an alarm. Each row in this table of Items from Alarm refers to an alarm. You can have multiple lines for the same tag to set different boundaries for multiple tracks or states of a tag. In turn each Item refers to an Alarm Group, to set the display behavior and actions during alarm state transitions (active / normal).

To set up alarm items:

  1. Go to Edit> Alarms > Items.

  2. Enter or select the information as needed.

Column

Description

TagName

Enter a tag name or click ... to select a tag.

Condition

Select from a set of possible events the condition you want to use for generating this alarm. For the DeviationMinor or DeviationMajor conditions, specify a limit, then use the nominal value column to define a value or tag whose value must be compared to obtain the current deviation.

Limit

Enter a value for the alarm threshold that corresponds to the condition you selected. You can define up to three paera limits the same condition using the Limits mechanism chosen by "shifts" or slots. The other columns are Limit1 and Limit2.

Group

Select an alarm group, among those already defined, that will be used to control the behavior required when alarm transitions occur. See "Configuring Alarm Groups" 

Priority

Enter a priority value that controls the position where the alarm is displayed on the Object with the alarm list. The higher the number, the higher the priority. You can use the same priority for more than one alarm event. Type 0 (zero) for alarms that should go to the end of the list.

Message

Enter the text that will appear in the alarm list.

Area

Choose from the AREA list in which you want this item to be included. You can choose any level or sublevel of areas. The chosen area will be considered the LOCATION for this item. See also "Configuring Logical Alarm Areas"

Deadband

Dead band in engineering units of the tag itself. Used for the boundary condition, it sets a range around the threshold value within which the alarm state is not changed.

Setpoint

Value set to evaluate deviationminor and deviationmajor alarm conditions. The condition occurs when the current value of the tag is diverted from this value

Deadband SetPoint 

Represents the dead band for the Setpoint property. Sets a range of values around the setpoint in which it is not generated
diversion alarm.

AuxValue

In this column can be included the tag of a point, related to the alarm item, which one wishes to be passed in the alarm structure when of an alarm state transition. For example: in the event that this alarm item indicates the opening of a circuit breaker, the current measuring point tag could be put into the circuit breaker.

[Other columns]

For definitions of other columns that are available in many tables, see "Description of common columns" 

  • Keep adding as many alarm items as you need.

  • If necessary, right-click a row in the table to cut, copy, paste, or delete the row.

EditAlarmsItems.Condition

This is the column in which the condition is defined. In it you can choose the following events. See in each case the evaluation condition that is used for the generation of alarm events.

  • Hi: Tag > = limit

  • HiHi: Tag > = limit (when automatically recognized recognizes Hi alarm same tag)

  • Lo: Tag <= limit

  • LoLo: Tag <= limit (when recognized automatically recognizes alarm Lo the same tag)

  • RateOfChange: Change Tag Rate> = Limit

  • DeviationMinor: Absolute value (tag - Setpoint)> limit (nominal value set in setpoint column)

  • DeviationMajor: Absolute value (tag - Setpoint)> limit (nominal value set in setpoint column)

  • Equal: Tag = limit

  • GreaterThan: Tag> boundary

  • GreaterEqual: Tag> = limit

  • LessThan: Tag <limit

  • LessEqual >: Tag < = limit

  • Changed: Tag value changed

  • ChangedUp: Tag value increased

  • ChangedDown: Tag value decreased

  • Not Equal: tag not equal to the limit.

Multiple Alarm Items for a Tag

It should be noted that a tag can have one or more records in this table, depending on the desired behavior. The figure below shows examples of tags with four alarm records (analog variables), two records (events that you want two distinct behaviors), and an alarm record (equipment state signaling).

NOTE - Items that refer to the same tag must be distinct as to the Condition and Threshold properties so as not to create situations of ambiguity.

Enable Limits per Turn

The "Enable Limits per turn" is especially oriented to systems that need to implement the Load Levels functionality ( Light, Medium, and Heavy). When it is chosen in the table Items, as shown in the figure below, three columns appear to specify the limits for each load level.


The attribute CurrentShift informs the current shift: (0 = light, 1=medium and 2= heavy)

The attribute EnableLimitsByShift informs you whether or not the feature is enabled, respectively. If enabled just create a routine that at each hour sets the shift: "Alarm.CurrentShift = x" where x = 0 / 1 / 2.

Viewing Alarms and Events

To view alarms and events, you can use the available alarm list object to be placed on screens or reports. See the section "Setting up an Alarm Window" , for more information

Alarm Acknowledgment

There are several ways to perform alarm recognition:

  • Using the Alarms View Object on the screens.

  • The properties of tags.

  • The runtime properties of alarm groups or alarm items.

Acknowledge all alarms

  • You can use the <Alarm.AckAll> which recognizes all active alarms.

Acknowledge a single Alarm or the Highest Priority Alarm

  • The <Alarm.PriorityItem.UnAck> property allows for recognition of the highest priority alarm (configured in <Edit.Alarms.Items> in the "Priority" column), if there is a pending alarm recognition.

Acknowledge a specific alarm

  • To recognize a specific alarm use the property<Alarm.Items.IDxx.Unack>.

  • To check the contents of the IDXX alarm columns, go to the Alarm item and add the ID column (right-click the table and select ID).

Subscribing Notifications

To apply custom actions using dot NET scripts, you can subscribe to alarm and event notifications.
Typical use is to create a procedure for sending sms or email warnings, performing custom calculations, adding custom notification messages or audio alarms, text-to-speech audio alarms, and any kind of custom action scheduled using Microsoft. NET Framework.
To subscribe to alarm events, you must create a method in any script server class, with the following prototype:

void NotificationName(AlarmEventInfo[] info)

With each new alarm transition event generated this method will be called.
Finally, you need to select this method in Edit> Alarms> Groups in the Column
Notificationmethod in the Groups table.
The method name may vary, which is important are the expected parameters of the method. The AlarmEventInfo structure is defined in the Alarm namespace in referencing the runtime classes.
See in http://www.spinengenharia.com.br/help/an-2016/runtime/index.html .

Alarm database and Table Schema

The database used to store alarms is defined in Edit-Datasets-DBs by the database connection object with the name AlarmHistorian.
By default, when a new project is created, the AlarmHistorian is set to use the Distributed SQLite database along with the Action.NET.

WARNING - The SQLite database should be used for regular-sized banks that do not require the facilities made available for more robust client/server data management systems. If you are expected to use larger databases, you must define another SQL manager for Alarm Historian Database.


To define another database to store the Alarm Historian database, you only need to create a new database connection, as explained in "Configuring Database Connections" naming it as AlarmHistorian.

The Alarm Module automatically creates the required tables in the database. An example of a table schema is available when you open any file with extension. TAlarm, created while running applications using the standard SQLite database for alarm logging.

Runtime Alarm Object

The namespace Alarm has the properties of the alarm server.
The object Alarm.Group has the list of all defined groups and their properties. The object Alarm.Item has all the alarm items and their properties.
The following properties of tags are related to the alarm module:

  • tag.tagname.Hi: configuration and execution status of the HI alarm.

  • The names similar to other types of alarm.

See in http://www.spinengenharia.com.br/help/an-2016/runtime/index.html , for the full programming reference on runtime objects.

On this page:

 

Â