Image Removed

You can select which events should be logged in audit trail files (records for audit tracking). This setting is valid for the system events you want to select, below are those of the default group SystemEvent. On the Edit>Alarms screen, at its top there are several configuration options.

Image Removed

To set up the Audit Trail:

1. Go to Edit> Alarms > Groups .

2. Click AuditTrail: Settings .

   • The configuration window of the Audit Trail. Mark the types of events you want to be logged

3. To enable event logging, in the Groups tab table column LogEvents, select the Enable

4. After selecting Enable, select the events that you want to record.

5. Click OK.

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.

void NotificationName(AlarmEventInfo[] info). 

• 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.

• 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).

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.

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.

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.

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.