| HTML |
|---|
<style>
.text-span-6 {
background-image: linear-gradient(99deg, rgba(170, 163, 239, .5), rgba(125, 203, 207, .5));
border-radius: 50px;
padding-left: 15px;
padding-right: 15px;
}
#title-text {
display: none;
}
.panelgradient {
background-image: linear-gradient(180deg, #d5def0, whitesmoke);
border-radius: 8px;
flex-direction: column;
justify-content: center;
align-items: center;
padding: 4rem;
display: flex;
position: relative;
}
</style>
<div class ="panelgradient">
<h1 style="text-align: center;">Alarms, Audit and Notifications</h1>
</div> |
Introduction to Alarms Module
The Alarms Module provides features and tools to manage alarms within the software platform. To create an AlarmItem, select a Tag and associate a condition that, when triggered, will create an alarm event. Then, assign this item to the target AlarmGroup (Warning, Critical, or AuditTrail) to inherit its properties and attributes. Specify its placement within the process hierarchy through AlarmAreas.
On this page:
| Table of Contents | ||||
|---|---|---|---|---|
|
Key Concepts and Terms
Below is a list of key concepts essential to understanding the Alarms Module.
| Panel | ||
|---|---|---|
| ||
AlarmItemAn AlarmItem is a tag or expression monitored by the Alarms module. It contains information such as the tag name, the alarm condition (the trigger for the alarm), and the associated AlarmGroup. Each AlarmItem can have its configuration properties, such as Limit, Deadband, and Message, that define the alarm behavior and characteristics. |
| Panel | ||
|---|---|---|
| ||
AlarmGroupAn AlarmGroup is a collection of AlarmItems with common properties and characteristics. Each AlarmGroup can have configuration properties, such as Ack Required, Auto Ack Time, and Sound, that apply to all its AlarmItems. |
| Panel | ||
|---|---|---|
| ||
AlarmAreaAn AlarmArea is a structured grouping of AlarmGroups, providing an organized approach to alarm management. It can contain child AlarmAreas, creating a hierarchical structure for AlarmGroups and AlarmItems. This hierarchy enhances the organization and management of alarms. |
| Panel | ||
|---|---|---|
| ||
AuditTrailThe Audit Trail is a feature that logs all changes made to the AlarmGroup & 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
The alarm module runs in a separate process from TServer.exe. The alarm operations occur at the same time that other events in the solution occur. This improves reliability in process monitoring.
When an alarm is triggered, it can be acknowledged by any user (with matching access level) through the Alarm Viewer.
Examples: Tag properties, AlarmGroup or AlarmItem's runtime properties.
Features Highlights
The Alarms Module offers the following key features:
- The 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.
- It considers universal time and daylight saving time for accurate timestamps.
- Dynamic language localization of alarm messages for easy understanding.
- High-precision timestamps up to 0.1ms for accurate and reliable data.
Monitoring Tags and Evaluating Conditions
The Alarms functionality allows users to evaluate if tag values are set to their specific conditions in real-time. Notifications can be sent to users or automatic actions can be taken based on set conditions.
To monitor tags users can set up conditions to evaluate. For example, a user can set up a condition to trigger an alarm if the value of a tag exceeds a certain threshold. Also, it's possible to trigger automation with a ScriptTask through the property "Alarm.Item.<AlarmID>.State.”
Conditions can be based on a variety of factors, such as tag values, tag quality, or any object property.
Configuring the Alarms Module
Step 1: To create an AlarmItem, select a Tag and associate its Conditions.
Step 2: Assign the AlarmItem to the target AlarmGroup (Warning, Critical, or Audit Trail). This also applies its properties and attributes.
Step 3: Define the placement within the process hierarchy through AlarmAreas.
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 | Optionally, you can optimize the communication, grouping Points with similar requirements to the same AccessType. Learn more at AccessType. |
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 changes in conditions.
Runtime Execution
You can control the Alarms Module execution while running your solution. You can Run, Pause, or Stop the Alarms Module directly from the platform.
Access Runtime → Runtime Diagnostics to find the tools you can use to control the module.
Monitoring the Module
The Alarms Monitor lets you see real-time information about the module when the solution is runtime. 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
Read more about these tools and see a list of properties used to monitor the module here → Alarms Monitor
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.
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 Visualizing Alarms Here →
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.
Read more about email information, here → Alarm Email Notifications
Alarm Historian Database definition 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.
External System Interaction
The Alarms Module can send alarm notifications through emails or SMS messages.
Read more about this feature here → Alarm Email Notifications
Advanced Alarms Topics
The Alarms module also includes several advanced features and options to further customize its functionality.
- Custom Alarm States
- Filter Based on Condition
- Configure Active Alarms During Specific Times
- 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. The following are some of the settings that can be customized:
- Alarm Notification: Sets up how alarms notify users.
- Sound: Sets the sound played when an alarm goes off. (Read more about sound configuration → AlarmGroup Sounds)
- Display: Sets the display options for the alarms.
- Audit-Trail: Defines whether or not to log alarms and events.
- Database: Determines the database where alarm information is stored.
- Security: Sets up security settings for the Alarms Module.
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.
Using Pre-Defined Groups
The Alarms module provides a predefined Alarm Group 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 Alarm Group, you simply need to select it from the list of available groups and configure additional properties as needed.
Some common Alarm Groups that may be available, include:
- High Priority Alarms
- Medium Priority Alarms
- Low Priority Alarms
- Equipment Alarms
- Production Alarms
Using predefined Alarm Groups can save time and effort in configuring the Alarms module. Additionally, you can customize these predefined 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:
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
#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:
- 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.
In this section:
| Page Tree | ||||
|---|---|---|---|---|
|