Alarms Module (Reference) provides comprehensive alarm management capabilities for monitoring, notification, and compliance in FrameworX solutions.

  • Real-time monitoring of process conditions
  • Hierarchical alarm organization
  • Flexible acknowledgment workflows
  • Comprehensive audit trail logging
  • Multi-channel notifications
  • FDA 21 CFR Part 11 compliance

In this page:

Module Components

Configuration Workflow and Designer UI

SectionDesigner UI PathPurpose
ItemsAlarms → ItemsDefine monitored conditions and limits
GroupsAlarms → GroupsConfigure shared alarm behaviors
AreasAlarms → AreasCreate hierarchical organization
Global SettingsAlarms → Global SettingsSystem-wide configuration

Configuration Workflow

StepActionPurpose
1. Create AlarmItemsDefine tag conditionsSet what to monitor
2. Configure GroupsSet behaviorsDefine how alarms act
3. Build AreasCreate hierarchyOrganize by location/function
4. Global SettingsConfigure systemSet database and audit trail

Runtime Architecture

Alarm Lifecycle

  • Normal - No alarm condition
  • Active - Condition triggered
  • Acknowledged - Operator confirmed
  • Normalized - Condition cleared, awaiting ack
  • Return - Back to normal state

Execution Control

  • Run/Pause/Stop alarm evaluation
  • Monitor active alarm counts
  • View performance metrics

Alarm Namespace

Access alarm objects at runtime:

csharp

// Alarm Items
bool isActive = @Alarm.Item.HighTemp.Active;
DateTime activeTime = @Alarm.Item.HighTemp.ActiveTime;

// Alarm Groups  
int criticalCount = @Alarm.Group.Critical.ActiveCount;
bool ackRequired = @Alarm.Group.Critical.AckRequired;

// Alarm Areas
@Alarm.Area.Production.AckAll();
int areaCount = @Alarm.Area.Production.AlarmCount;

// Global Settings
@Alarm.GlobalSettings.AuditTrail.AddCustomMessage("Event logged");
bool auditEnabled = @Alarm.GlobalSettings.AuditTrail.IsEnabled;

Key Concepts

AlarmItem

Individual monitored condition with:

  • Tag reference
  • Trigger condition (Hi, Lo, RateOfChange, etc.)
  • Limit values
  • Associated group and area

AlarmGroup

Collection sharing common properties:

  • Acknowledgment requirements
  • Notification methods
  • Sounds and colors
  • Logging preferences

AlarmArea

Hierarchical organization structure:

  • Plant/process area grouping
  • Filtering and navigation
  • Area-based operations

Global Settings

System-wide configuration:

  • Database connection
  • Startup behavior
  • Audit trail
  • Shift-based limits

Display Integration

AlarmViewer Control

  • Real-time alarm display
  • Sorting and filtering
  • Acknowledgment interface
  • Historical view

AlarmArea Control

  • Hierarchical navigation tree
  • Area-based filtering
  • Visual alarm indicators

Configuration example:

xml

<AlarmViewer>
  <List>OnlineAlarms</List>
  <AreaFilter>Production.Line1</AreaFilter>
  <ShowAcknowledged>false</ShowAcknowledged>
</AlarmViewer>

Notification Methods

Built-in Notifications

  • Visual alerts in displays
  • Sound alerts (configurable per group)
  • Database logging

Custom Notifications

Via Script Classes:

csharp

public void SendAlarmNotification(AlarmEventArgs args)
{
    // Email notification
    EmailService.Send(args);
    
    // SMS alert
    SMSService.Alert(args);
    
    // External system
    SCADA.LogAlarm(args);
}

Audit Trail

Configuration

  1. Enable in Global Settings
  2. Select events to log
  3. Configure retention period

Custom Messages

csharp

@Alarm.GlobalSettings.AuditTrail.AddCustomMessage(
    message: "Batch started",
    areaName: "Production",
    objectName: "Reactor1",
    value: "Batch#123"
);

Compliance Features

  • User logon/logoff tracking
  • Operator action logging
  • Tag change recording
  • System event capture

Database Configuration

Supported Databases

  • SQLite (default)
  • SQL Server
  • PostgreSQL
  • MySQL
  • Oracle

Schema

  • AlarmEvents - Active alarm records
  • AlarmHistory - Historical alarm data
  • AuditTrail - Audit log entries

Maintenance

  • Set retention period (Life Time)
  • Regular archival recommended
  • Index optimization for performance

Best Practices

Design

  1. Group strategically - Use groups for common behaviors
  2. Build logical hierarchy - Areas match plant structure
  3. Set appropriate limits - Avoid nuisance alarms
  4. Use deadbands - Prevent alarm flooding
  5. Configure priorities - Critical alarms stand out

Operations

  1. Test notifications - Verify all alert methods
  2. Train operators - Clear acknowledgment procedures
  3. Regular review - Analyze alarm performance
  4. Maintain database - Archive historical data
  5. Document settings - For compliance audits

Performance

  1. Optimize conditions - Simple expressions perform better
  2. Batch operations - Group related alarms
  3. Manage retention - Balance history vs storage
  4. Monitor metrics - Track evaluation performance

Troubleshooting

Common Issues

Alarms not triggering:

  • Verify tag values
  • Check enable conditions
  • Confirm group active
  • Review deadband settings

Database issues:

  • Check connection string
  • Verify permissions
  • Monitor disk space
  • Review retention settings

Performance problems:

  • Reduce evaluation frequency
  • Optimize complex conditions
  • Increase deadbands
  • Archive old data

Notification failures:

  • Verify script methods
  • Check sound file paths
  • Review email configuration
  • Test network connectivity

Advanced Topics

For deep technical understanding: → See [Alarms Engine (Reference)]

For monitoring runtime performance: → See [Alarms Monitor (Reference)]

For custom sound configuration: → See [Alarm Groups Sounds]

For email notifications: → See [Alarm Email Notifications]




In this section...




  • No labels