Overview
The Alarms Module comes with default configurations when setting up a new solution.This page outlines the fundamental steps to set them upalarm process starts when a monitored tag or expression violates a set condition. It triggers an alarm event and sends notifications (visual, audible, email, etc.) based on the alarm group's settings. Operators acknowledge the alarm and begin troubleshooting the root cause. Once addressed, the alarm condition clears, and the system may automatically clear or require manual alarm clearing. Optionally, an auto-acknowledgment timeout may be in place. All alarm events, state changes, and user actions can be logged within the system, providing a robust audit trail for analysis, troubleshooting, and compliance.
On this page:
| Table of Contents | ||||
|---|---|---|---|---|
|
Alarms
ModuleTo configure the Alarms Module follow the steps below:
Once you have configured your Alarms, integrate them with other modules within the software environment, such as the Displays Module, to visualize alarms in real-time in tables, custom graphics, and objects.
Working with the Alarms Module
The modules inside the platform are connected and can be used together to create advanced solutions. This page presents how you can use the Alarms Module combined with other modules available on the platform.
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 three buttons that you can use to control the module.
Events Cycle
Triggering
An alarm workflow begins when a monitored tag or expression meets a defined alarm condition. This condition might signal a value exceeding a limit, a rapid rate of change, or another system event. The system detects the condition and generates an alarm event.
Notification
The system sends out notifications based on the configuration of the associated AlarmGroup. These notifications can include visual alerts on operator screens, audible alarms, emails, text messages, or integration with external systems. Notifications target the appropriate personnel based on alarm priority and area.
Acknowledgment
Operators acknowledge alarms, indicating awareness of the issue. The AlarmGroup might require acknowledgment before certain actions occur or to silence audible notifications. Acknowledgment status is tracked within the system.
Resolution
Operators investigate and address the root cause of the alarm. This might involve corrective action, system adjustments, or equipment maintenance. Once the underlying issue is resolved, the alarm condition clears.
Clearing and Auto-Acknowledgment
When the alarm condition no longer exists, the alarm clears. Some alarms might clear automatically, while others might require manual clearing by an operator. The Alarms Module can also employ auto-acknowledgment timeouts, where an alarm automatically transitions to an acknowledged state after a set period if the operator has not taken action.
Logging and Audit Trails
The Alarms Module logs alarm events, acknowledgments, state changes, and any associated user actions. This log creates a comprehensive audit trail. It assists in troubleshooting, analyzing system performance, and ensuring compliance with any required standards or regulations.
Runtime Execution
Once the AlarmGroup and items have been configured, the Alarms Module can be executed to start monitoring the specified tags and conditions. During Runtime, the Alarms Module continuously evaluates the conditions of the AlarmItem and generates alarms when the conditions are met. The alarms are then added to the alarm database and can be visualized and acknowledged by the operators. The runtime behavior of the Alarms Module can be controlled through runtime attributes such as alarm logging level, acknowledge timeout, and alarm retention time
Intra-module interaction
The Alarms Module easily integrates with other modules within the software environment. Here are some examples of how to use the Alarms Module in conjunction with other modules:
- Displays Module: Users can create displays that visualize alarms in real-time in tables, custom graphics, and objects, 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, allowing operators to respond quickly.
- Scripting Module: Custom Scripts can handle alarm notifications, defining the behavior of the Notification Method property of the Alarm Group and allowing for more customized notifications based on the type and severity of the alarm.
- Reporting Module: Users can generate detailed alarm reports.
- Datasets Module: The Alarm Historian database is where the Alarms Module stores all alarm events and audit trail information.
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.
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
You can read more about these tools and see a list of properties used to monitor the module on the Alarms Monitor page.
In this section:
| Page Tree | ||||
|---|---|---|---|---|
|
...