Alarms Module (Concept) provides the critical event detection and notification layer for FrameworX solutions, enabling operators to respond quickly to abnormal conditions and maintain safe, efficient operations.
Introduction to the Alarms Module 
The Alarms Module monitors and manages real-time alarm events, alerts, notifications, and Audit Trail information. It provides alerts for critical events and stores data for future analysis. Key functions include:
Real-time alarm states processing
Storage on any database provider
Hierarchical organization of alarms
System AuditTrail events and operator actions tracking
On this page:
Table of Contents maxLevel
2 minLevel 2 indent 10px exclude Steps style none
Understanding Alarms in Automation
Industrial processes require continuous monitoring to detect deviations from normal operation. The Alarms Module bridges the gap between raw sensor data and actionable operator responses by:
- Condition Monitoring - Detect when process values exceed safe or optimal ranges
- Event Notification - Alert operators through multiple channels
- State Management - Track alarm lifecycle from detection to resolution
- Compliance Recording - Maintain audit trails for regulatory requirements
Key Concepts
and Terms- AlarmItem
A tag monitored by the Alarm Module, containing information such as tag name, alarm condition, AlarmGroup, Limit, Deadband, and Message.
AlarmGroup
Collection of AlarmItems sharing properties such as AckRequired and LogEvents.
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 displays.
- Real-time alarm processing
- Hierarchical alarm management
- Dynamic language localization for messages
- High-precision timestamps
- Custom notifications (e.g., SMS, email)
- Store and Forward archiving
- Automated replication in hot-standby scenarios
Monitoring Tags and Evaluating Conditions
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 group.
- : Individual condition monitored for alarm generation based on tag values and defined limits
- AlarmGroup: Collection of alarm items sharing common acknowledgment, notification, and logging behaviors
- AlarmArea: Hierarchical organization structure for grouping alarms by location or function
- AuditTrail: Chronological record of system events, operator actions, and alarm occurrences for compliance
What It Does
The Alarms Module provides comprehensive alarm management through:
- Real-Time Evaluation - Continuously monitor tag values against configured conditions
- Intelligent Notification - Multi-channel alerts via sound, visual, email, SMS, or custom methods
- Acknowledgment Workflow - Require operator confirmation of critical alarms
- Hierarchical Organization - Group alarms by area, system, or responsibility
- Historical Logging - Record all alarm events for analysis and compliance
- Deadband Management - Prevent alarm flooding through time and value hysteresis
- Shift-Based Limits - Different alarm thresholds for different operational periods
Configuration Workflow
| Step | Action | Description |
|---|---|---|
| Create AlarmItems | Define conditions | Specify tags and limits to monitor |
| Configure AlarmGroups | Set behaviors | Define acknowledgment and notification |
| Build AlarmAreas | Create hierarchy | Organize by plant structure |
| Set Global Settings | System configuration | Database and audit trail setup |
Runtime Behavior
Alarm States
The module manages alarms through defined state transitions:
- Normal - No alarm condition exists
- Active - Condition detected, awaiting acknowledgment
- Acknowledged - Operator confirmed awareness
- Normalized - Condition cleared, awaiting final acknowledgment
Notification Methods
Alarms trigger notifications based on group configuration:
- Visual indicators on operator displays
- Audible alerts with configurable sounds
- Email and SMS through script integration
- External system interfaces via custom methods
Performance Management
Built-in features prevent alarm system overload:
- Deadbands prevent rapid re-triggering
- Priority levels highlight critical conditions
- Area filtering focuses operator attention
- Acknowledgment requirements ensure awareness
Feature Highlights
- Pre-Defined Groups - Critical, Warning, and AuditTrail groups ready to use
- FDA Compliance - 21 CFR Part 11 audit trail capabilities
- Flexible Database - Support for SQLite, SQL Server, PostgreSQL, and more
- Runtime Control - Start, stop, pause alarm evaluation dynamically
- Display Integration - AlarmViewer and AlarmArea controls for HMI
- Script Integration - Custom notification methods via Script Classes
- Distributed Architecture - Alarms evaluated centrally, viewed anywhere
- Localization Support - Multi-language alarm messages and displays
In this section...
| Page Tree | ||||
|---|---|---|---|---|
|
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.