Page History

Key Concepts

and Terms

AlarmItem

A tag monitored by the Alarm Module, containing information such as tag name, alarm condition, AlarmGroup,

Below is a list of key concepts essential to understanding the Alarms Module.

Alarm Item

An Alarm Item is a tag or expression monitored by the Alarms module. It contains information such as the tag name, the alarm condition (the trigger of the alarm), and the associated Alarm Group. Each Alarm Item can have its configuration properties, such as Limit, Deadband, and Message, that define the alarm behavior and characteristics.

Alarm Group

An Alarm Group is a collection of Alarm Items with common properties and characteristics. Each Alarm Group can have configuration properties, such as Ack Required, Auto Ack Time, and Sound, that apply to all its Alarm Items. 

Alarm Area

An Alarm Area is a structured grouping of Alarm Groups, providing an organized approach to alarm management. It can contain child Alarm Areas, creating a hierarchical structure for Alarm Groups and Alarm Items. This hierarchy enhances the organization and management of alarms.

Audit Trail

The Audit Trail is a feature that logs all changes made to the Alarm Group & item including creation, modification and deletion of events. Providing a clear audit trail of who made what changes and when, it is a way to track and record the history of changes made to the alarm configuration

Understanding the Alarms Module

Such as other modules, the alarm module run in a separate process from TServer.exe, it means that the alarm operations occur at the same time that other events in the solution bringing reliability to process monitoring.

When an alarm is triggered, it can be acknowledged by any client logged in with a user with matching access level through the Alarm Viewer, this also can be done through other ways like: Tag properties, Alarm Group or Alarm Item's runtime properties.

Features Highlights

The Alarms Module offers the following key features:

AlarmGroup

Collection of AlarmItems sharing properties such as AckRequired and AutoAckTime.

AlarmArea

Hierarchical grouping of AlarmGroups for better organization.

Audit Trail

Logs changes and events when executing the solution, tracking who made changes and when. Useful for troubleshooting, analysis, and compliance.

Understanding the Alarms Module

Module Features

• AlarmViewer Control and AlarmAreas Control for displaysThe Alarm Window displays active alarms and their state changes on the screen.
• Real-time alarm processing to quickly identify and respond to critical events.
• Organizing and managing alarms in a hierarchical structure for enhanced flexibility and control.
• Hierarchical alarm managementIt considers universal time and daylight saving time for accurate timestamps.
• Dynamic language localization of alarm messages for easy understanding.for messages
• High-precision timestamps up to 0.1ms for accurate and reliable data.

Components and Functionalities

Children Display
style h4 excerptType rich content

• Custom notifications (e.g., SMS, email)
• Store and Forward archiving
• Automated replication in hot-standby scenarios

Monitoring Tags and Evaluating Conditions

The Alarms functionality allows users evaluate if tag values satisfy certain conditions in real-time. With that the software platform can send notifications to users or take actions based on specific conditions.

When monitoring tags, users can set up one or more conditions to evaluate. For example, a user might set up a condition to trigger an alarm if the value of a tag exceeds a certain threshold. Also, it's possible to bind any alarm trigger with a Script Task through the property "Alarm.Item.<AlarmID>.State", chaining an automatic process. 

When the Module Alarm is execution, all tags defined on AlarmItems are subscribed, so the alarm conditions are evaluated every time the tag as new value. 

If a condition is reached, the alarm is issued, according to the behavior defined by its AlarmGroup. Notifications are sent if enabled to that groupConditions can be based on a variety of factors, such as tag values, tag quality, or any object property.

Configuring the Alarms Module

Configuring an alarm involves creating an AlarmsItem object. Creating an AlarmsItem involves selecting a system Tag and associating a condition to generate an alarm event. Once done, it is necessary to specify which alarm group this item belongs to. The alarm item will inherit properties and attributes defined in the alarm groups. Finally, based on your process hierarchy defined on AlarmsAreas, you can specify which place the alarm item belongs to. So, to create and manage alarm items, go to Alarms/Items; to customize and fine-tune the groups of alarms, go to Alarms/Groups; and to define the process hierarchy and organize your alarm systems, go to Alarms/Areas.

Configuration Workflow

Pre-Defined AlarmGroups

The Alarms module provides a predefined AlarmGroup to quickly configure alarms for common applications. These groups have pre-configured properties that make it easier to create and configure alarms for standard purposes.

To use a predefined AlarmGroup, you simply need to select it from the list of available groups and configure additional properties as needed. 

The pre-defined AlarmGroups are:

• Critical: High Priority Alarms that requires acknowledgement and History logging.
• Warning: Medium Priority Alarms and Low Priority Alarms, which don't require acknowledgment, but are logged.
• Audit Trail: Alarms and Events that don't show on Operator Displays, but are records on the History log.

AlarmHistorian Database on Datasets

The Alarm Historian database is where the Alarms module stores all alarm events and audit trail information. The AlarmHistorian database can be defined using datasets, which allows for easy configuration and modification of the database properties. The datasets can define the database connection settings, the schema of the database tables, and the properties of the alarm events and audit trail entries.

Device Module Configuration Workflow

Action

Where 

Comments

Create Channels

Devices → Channels

Identify the required field devices and protocols the project requires, create channels accordingly. Learn more at Device Channels.

Create Nodes

Devices → Nodes

Identify the Network addresses and relevant information to all stations and devices that need connectivity. Learn more at Devices Nodes.

Map Tags to Point addresses

Devices → Points

Optionally, you can Copy Tags from Excel/CSV from Excel or execute Import Wizards. Learn more at Device Points.

Create or Customize AccessTypes

Devices → AccessTypes

Working with the Alarms Module

Once you have set up your AlarmGroup, AlarmArea, and AlarmItem, you can use the Alarms module to monitor your process and respond to any abnormal changes in conditions.

Runtime Execution

You can control the Alarms Module execution while running your solution. You can   Run,   Pause, or or Stop   the Alarms Module directly from the platform. 

Access   Runtime → / Runtime Diagnostics  to to find the three buttons that tools you can use to control the module.

Image RemovedImage Added

Monitoring the Alarms Module Execution

The Alarms Monitor lets you see real-time information about the module when the solution is runtimerunning. It showcases total, unacknowledged, active alarms, their priority, and the most recent alarm notification.

Additionally, the Runtime Diagnostic provides additional information from the modules through three essential diagnostic tools:

• Module Information 
• Property Watch
• Trace Window

You can read more about these tools and see a list of properties used to monitor the module on the Alarms Monitor page.

Intra-Module Interaction

The Alarms module can be integrated with other modules to enhance its functionality. For example, the Display module can be used to display alarms on a graphical screen, and the Reporting module can be used to generate reports that include alarms and their details. Additionally, the Scripting module can be used to handle alarm notifications, as well as to create custom alarms and modify the runtime behavior of the Alarms module→ Read more about Alarms Monitor.

Visualizing Alarms on Displays

The Displays module can be used to create displays that visualize alarms in real-time. The alarms can be displayed in tables, custom graphics, objects and others with the ability to sort and filter based on various alarm properties. The displays can also include interactive components, such as acknowledging alarms and displaying alarm details, to allow operators to quickly respond to alarms.

→ Read more about the AlarmViewer Control and AlarmAreas Control.

Handling Notifications with Scripts

The Scripting module can be used to create custom scripts that handle alarm notifications. These scripts can define the behavior of the Notification Method property of the AlarmGroup, allowing for more customized notifications based on the type and severity of the alarm. The scripts can also define notification methods beyond the built-in options, such as sending emails or SMS messages. For Email information, go to the Alarm Email Notifications page

AlarmHistorian Database definition on Datasets

The AlarmHistorian database is where the Alarms module stores all alarm events and audit trail information. The AlarmHistorian database can be defined using datasets, which allows for easy configuration and modification of the database properties. The datasets can define the database connection settings, the schema of the database tables, and the properties of the alarm events and audit trail entries.

External System Interaction

The Alarms Module can send alarm notifications through emails or SMS messages. For more details on this feature and how to use it access the Alarm Email Notifications page.

Advanced Alarms Topics

The Alarms module also includes several advanced features and options to further customize its functionality. These include the ability to create custom alarm states, the ability to filter alarms based on specific conditions, the ability to configure alarms to only be active during certain time periods, and the ability to define custom properties for alarm events and audit trail entries. These advanced features provide additional flexibility and control over the Alarms module's behavior.

Advanced Configuration

The Alarms module can be customized to meet specific requirements. This section will cover the various configuration options available in the Alarms module.

The following are some of the settings that can be customized:

→ Read more about  Alarm Email Notifications.

Customizing Alarm Sounds

Sets the sound played when an alarm goes off.

→ Read more about at AlarmGroup Sounds.

Alarms Advanced Topics

Alarm Execution Process

Presents in the detail the processes when executing the Alarm Engine. 

→ Read more about Alarm Execution Process

Alarm Runtime Attributes

The Alarms Namespace exposes properties and methods from the .NET objects used by the Alarm Module execution.

→ Read more about Alarms Runtime Attributes

Anchor
BestPractices BestPractices

Best Practices and Troubleshooting

Best Practices and Recommendations

To ensure the smooth operation of the Alarms module, follow these best practices:

• Use clear and descriptive names for Alarm Group, Alarm Area, and Alarm Item.
• Configure alarms with proper priority and severity levels.
• Use deadbands and delays to prevent alarm flooding.
• Regularly check and maintain the alarm configuration.
• Configure notifications and acknowledge alarms in a timely manner.

Sound: This setting allows the user to specify the sound that should be played when an alarm is raised.

In addition to the global settings, the Alarms module can be customized further by creating AlarmGroup, AlarmArea, and AlarmItem. These can be used to group and organize alarms based on specific criteria.

The next sections will cover how to create and manage AlarmGroup, AlarmArea, and AlarmItem.

The Alarms module provides pre-defined AlarmGroup that you can use to quickly configure alarms for common applications. These pre-defined groups have pre-configured properties that make it easier to create and configure alarms for specific purposes.

To use a pre-defined Alarm Group, you simply need to select it from the list of available groups and configure any additional properties as needed. The available pre-defined groups may vary depending on the version of the Alarms module that you are using and the features that have been installed.

Some common AlarmGroup that may be available, include:

1. High Priority Alarms
   This group is used to track critical alarms that require immediate attention. The alarms in this group will typically have a high priority and may be configured to generate notifications or take other actions automatically.

2. Medium Priority Alarms
   This group is used to track alarms that are important, but not as critical as high priority alarms. The alarms in this group may have a lower priority than those in the high priority group, and may not require immediate attention.

3. Low Priority Alarms
   This group is used to track alarms that are less critical than medium priority alarms. The alarms in this group may have a lower priority than those in the medium priority group and may not require immediate attention.

4. Equipment Alarms
   This group is used to track alarms related to specific pieces of equipment or systems. The alarms in this group may be configured to generate notifications or take other actions specific to the equipment being monitored.

5. Production Alarms
   This group is used to track alarms related to production processes or activities. The alarms in this group may be configured to generate notifications or take other actions related to the production process being monitored.

Using pre-defined AlarmGroup can save time and effort in configuring the Alarms module, as the properties of the alarms in the group are already pre-configured. However, you can still customize these pre-defined groups or create new ones as needed to fit your specific requirements.

Alarms Runtime Attributes

The Alarms Namespace exposes properties and methods from the .NET objects used by the Alarms Module execution. You can use these properties and methods on your Displays or to create Scripts. The Alarms Runtime Attributes page lists all options available.

Troubleshooting and Best Practices

Common Issues and Solutions

The Alarms module may encounter some issues in its operation. Here are some common issues and their solutions:

Alarm not firing

Check the tag name, condition, and alarm item configuration. Ensure the tag is valid and the condition is met.

Alarm not acknowledged

Check the alarm acknowledgement configuration. Ensure that the alarm acknowledges property is set and the acknowledgement timeout is not expired.

Database connection error

Check the database connection string and ensure that the database is reachable.

Alarm flooding

Check the alarm configuration and ensure that the deadband settings are properly configured.

Notification not received

Check the notification configuration and ensure that the notification method is properly set.

Best Practices and Recommendations

To ensure the smooth operation of the Alarms module, follow these best practices:

.

In this section: