Understanding Alarms
Alarms should be added after the basic values are already understandable. In other words, do not start here if the project still cannot read or simulate the underlying tags.
Start Here
Use this page when:
- your project already has stable live values
- you know which conditions should require operator attention
- you want to turn abnormal conditions into visible and traceable events
Before You Continue
Make sure:
- the related tags are already debugged
- you know the normal operating range for the values you plan to monitor
- you can explain who needs to respond when the alarm appears
If you want copy-ready alarm names, thresholds, levels, and messages, use Configuration Sample Data.
What You Should Be Able to Do After This Page
After reading this page, you should be able to:
- explain how alarm conditions become active and historical records
- describe alarm levels, categories, groups, and constraints
- identify the first small set of alarms worth configuring
What are Alarms?
Alarms are automated notifications triggered when equipment or process conditions exceed safe operating limits. They alert operators to abnormal situations requiring immediate attention, such as high temperature, excessive pressure, or equipment faults.
When to Use Alarms?
Alarms are essential for:
- Equipment Fault Detection: Monitor temperature, pressure, flow, and other critical parameters
- Process Anomaly Alerts: Detect out-of-spec conditions, flow disruptions, or process deviations
- Safety Event Notifications: Respond to fire, gas leaks, or emergency stop conditions
- Communication Failures: Alert when network connections or device communications fail
- Equipment Health Monitoring: Track maintenance schedules and equipment lifecycle
- Production Quality Issues: Identify defects or out-of-tolerance products
- Compliance Violations: Ensure adherence to safety standards and regulations
Where You Work in the Alarm Module
Unlike the View Editor or Tag Manager, alarm work is spread across configuration, runtime display, and historical review.
| Work Area | Where | What you do there |
|---|---|---|
| Alarm Configuration | Alarm setup pages in Editor | Define levels, categories, groups, constraints, and alarm points |
| Real-time Alarm Display | Runtime alarm table or alarm viewer component | Watch active alarms and support operator response |
| Historical Alarm Review | Data Management → Alarm Management → Historical Table | Review recovered alarms, durations, and root-cause patterns |
| Alarm Analysis Views | Dedicated dashboard or alarm analysis view | Summarize counts, durations, and alarm distribution by category or level |
For a first project, focus on only two work areas first:
- the configuration side where alarms are created
- the historical or real-time table where you confirm the alarm behaves correctly
Understanding the Alarm System
Alarm Data Flow
Key Concepts
| Concept | Description |
|---|---|
| Alarm Group | Organizes related alarms for easier management (e.g., Starter_Alarms, Safety_Alarms) |
| Alarm Level | Indicates severity (e.g., Critical, High, Medium, Low) |
| Alarm Category | Classifies alarms by type for analysis (e.g., Temperature, Pressure, Equipment Fault) |
| Trigger Condition | Logical expression that activates the alarm |
| Alarm Constraint | Delay before triggering to avoid nuisance alarms |
| Real-time Table | Stores currently active alarms |
| Historical Table | Archives recovered alarms for analysis |
Alarm Data Tables
AI SCADA automatically manages two alarm data tables:
Real-time Alarm Table
Purpose: Stores currently active alarms.
Location: Data Management → Alarm Management → Real-time Table
Behavior:
- When an alarm triggers, a record is added
- When the alarm recovers, the record is moved to the historical table (if recording is enabled)
Fields:
| Field | Description |
|---|---|
| Alarm Name | Unique identifier |
| Alarm Message | Description |
| Alarm Level | Severity |
| Alarm Category | Classification |
| Trigger Time | When the alarm activated |
| Status | Active |
Historical Alarm Table
Purpose: Archives recovered alarms for analysis and compliance.
Location: Data Management → Alarm Management → Historical Table
Behavior:
- Records are added when alarms recover (if recording is enabled)
- Records are never automatically deleted (configure retention policy if needed)
Fields:
| Field | Description |
|---|---|
| Alarm Name | Unique identifier |
| Alarm Message | Description |
| Alarm Level | Severity |
| Alarm Category | Classification |
| Trigger Time | When the alarm activated |
| Recovery Time | When the alarm cleared |
| Duration | How long the alarm was active |
| Status | Recovered |
📷 [UG-ALARM-UNDER-01] Historical Alarm Table showing recovered alarms with duration
Recommended First Alarm Set
For a first project, keep the alarm scope small and obvious:
| Alarm | Example condition | Why start here |
|---|---|---|
| High temperature | {Temperature} > 80 | Easy to test and easy to display |
| Low pressure | {Pressure} < 0.8 | Complements the main analog values |
| Communication loss | {Dev_<ChannelName>_State} == false | Important for real-device projects |
If you are using internal tags, start with the first two alarms and add communication alarms later when a real channel exists.
Next Steps
Now that you understand the alarm system, learn how to configure alarms:
- Creating Alarms: Set up alarm levels, categories, groups, and alarm points
- First Success Checkpoint: Return here first if the base project path is not yet stable
- Displaying Alarms: Show alarms on views and create analysis dashboards
- Alarms Reference: Return here later for expression syntax, best practices, and troubleshooting