Page History

Key Concepts and Terms

AlarmItem

A tag monitored by the Alarm Module, containing information such as tag name, alarm condition, AlarmGroup,

Purpose and Key Concepts

The Alarms module is designed to provide real-time monitoring and notification of events or conditions that require immediate attention. This is done by evaluating tags values in real-time to generate alarms when the monitored value reaches a defined limit or condition. The module evaluates the conditions of AlarmItems and compares their current value with the set limit to determine whether an alarm should be triggered or not. The module can evaluate conditions such as exceeding a limit, falling below a limit, or entering/exiting a range.

The configuration of the Alarms module is performed on the sections: AlarmGroup, AlarmArea, AlarmItem, and AuditTrail.

AlarmGroup

An AlarmGroup is a collection of AlarmItems that share common properties and characteristics. Each AlarmGroup can have its own configuration properties, such as AckRequired, AutoAckTime, and Sound, that apply to all of its AlarmItems. The configuration of AlarmGroup is on the Project Explorer, at Alarms → AlarmGroup.

AlarmArea

An AlarmArea is a hierarchical grouping of AlarmGroup that allows for a more organized and structured approach to managing alarms. An AlarmArea can have child AlarmArea, allowing for a hierarchical structure of AlarmGroup and AlarmItems. The configuration of AlarmArea is on the Project Explorer, at Alarms → Area.

AlarmItem

An AlarmItem is a tag or expression that is monitored by the Alarms module. It contains information such as the tag name, the alarm condition (what triggers the alarm), and the associated AlarmGroup. Each AlarmItem can have its own configuration properties, such as Limit, Deadband, and Message, that define the alarm behavior and characteristics. The configuration of AlarmItems is on the Project Explorer, at Alarms → Items.

AuditTrail

The AuditTrail is a feature of the Alarms module that logs all changes made to the AlarmGroup and AlarmItems, including creation, modification, and deletion events. It is a way to track and record the history of changes made to the alarm configuration, providing a clear audit trail of who made what changes and when. The configuration of the AuditTrail is on the Project Explorer, at Alarms → Global Settings → AuditTrail.

Items (Basic configuration)

An Item is essentially an alarm, it needs to be bonded to a numerical tag to monitoring the variation range.

Interface

When opening the Alarm environment, the Items tab will load, by default only some column will appear, these are to the basic Item configuration, but right clicking on header table you can see and check the remain columns to edit, like the follow image.

Image Removed

TagName

The tag used on alarm can be internal to FrameworkX or an External Tag, as this is a brief approach, we only will talk about the internal tags. For advanced users there is an explanation of concepts at the end of this section.

The tags created on environment Unified Namespace\Tags are known as internal tags, to use these tags like a sensor to an alarm, only start to fill the field TagName with the respective name and the software will suggest the tags that the name match.

Condition

The list of possible conditions is quite extensive, for a basic understanding we separate some of the most common ones in the following table:

Alarm Condition Basic Options

Field

Description

Hi

Tag >= limit

Lo

Tag <= limit

Equal

Tag = limit

Changed

Tag value changed.

NotEqual

Tag different from limit

Limit

There are 3 Limits to config, they are called Limit, Limit1 and Limit2, as this is a brief description, we will only deal with the Limit, without indexes. For advanced users there is an explanation of concepts at the end of this section.

This value refers to the condition chosen in the previous item.

Message

It's possible to choose a message to appear to the user when an alarm is triggered. This message can be customized in the Message column.

Groups

There are three groups by default, but the user can create as many as necessary. An explanation of how to create more groups can be found at the end of this section, along with information for advanced users.

Image Removed

Certainly, each AlarmItem must be necessarily associated with a group, as they define several general characteristics of the alarm, such as:

1. Whether user acknowledgment is required.
2. Whether it will have sound.
3. Minimum time for the condition to trigger the alarm.
4. Type of notification.

These are some of the basic characteristics of a Group, and the names of the respective columns and descriptions are provided in the following table.

Areas

By default, we haven`t any created area, but to better understand the concept, here is an abstract scenario were using this concept. 

If the solution will used into a physical structure that have different work areas like for example two sheds, called "Shed A" and "Shed B" and each shed have two and three sides respectively, it`s possible to configure the areas like on the following image:

.

AlarmGroup

Collection of AlarmItems sharing properties such as AckRequired and AutoAckTime.

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.

Configuring the Alarms Module

Configuration Workflow

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.

Working with the Alarms Module

Global Settings

In this display there is some options to customize the solution, these options will be addressed one by one.

Image Removed

alarm Logging Database

Previously called as AlarmHstorian, these options allow to select the Database where the data will be logged, as well as lifetime to the data log.

To setup the Database, left click on the engine icon.

Image Removed

Alarm Handling

In a manufacturing environment, it is frequently imperative to establish alarm configurations that initiate monitoring only once the system is fully operational. This is particularly relevant for machines that require a certain amount of time to power up and attain operational parameters, as is the case with furnaces and motors. These machines might take minutes to achieve the desired speed or temperature within the process. In such a scenario, the operational deployment of the Alarm Module could potentially result in the inadvertent triggering of multiple alarms.

To align with this context, certain adjustments become essential to prevent such undesired occurrences.

Image Removed

1

• Ver com Roberto

• Ver com Roberto

Enable Audit Trail

It`s possible to customize the data that will be logged on audit trail.

Image Removed

Understanding the Alarms module

Such as other modules, the alarm module run in a separate process from TServer.exe, it means that the alarm operations occur at the same time that other events in the solution bringing reliability to process monitoring.

The AlarmGroup can be used to group similar alarms together and define their behavior, such as whether they require acknowledgment, their sound and color settings, and their notification settings. The AlarmArea allows organizing the alarms into a hierarchical structure to reflect the plant's physical layout. The AuditTrail feature logs all alarm and acknowledgment events and allows for tracking changes made to the alarm configuration.

The AlarmHistorian feature allows the Alarms module to save alarms and their state changes in a separate database, allowing for efficient storage and retrieval of alarms data. The Alarms module can be configured to store alarms data on a target database of your choice.

When an alarm is triggered, it can be acknowledged by any client logged in with a user with matching access level through the AlarmWindow, this also can be done through other ways like: Tag properties, Alarm Group or Alarm Item's runtime properties.

The Alarms module can be integrated with other modules such as the Historian Module to allow for storing alarms data alongside process data. Overall, the Alarms module provides an efficient and comprehensive solution for monitoring and managing alarms in real-time.

Features Highlights

The Alarms module offers the following key features:

• The AlarmHistorian allows the Alarms module to save alarms and their state changes in a separate database (it is different from AuditTrail that only saves when editing the settings).

• The Alarm Window object used to displaying active alarms and their state changes on displays
• Real-time alarm processing to quickly identify and respond to critical events

• Agnostic storage on any database provider, making it flexible and easy to use

• Hierarchy organization and management of alarms for greater flexibility and control

• Notification events via SMS or email to keep users informed of critical events

• Universal time and daylight saving considered 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 evaluate if tag values satisfy certain conditions in real-time. With that the FrameworkX can send notifications to users or take actions based on specific conditions.

When monitoring tags, users can set up one or more conditions to evaluate. For example, a user might set up a condition to trigger an alarm if the value of a tag exceeds a certain threshold. Also, it's possible to bind any alarm trigger with a Script Task through the property "Alarm.Item.<AlarmID>.State", chaining an automatic process. 

Conditions can be based on a variety of factors, such as tag values, tag quality, or any object property.  or the state of other alarms. Users can also define complex conditions by combining multiple factors using logical operators.

In addition to monitoring tags, the Alarms module allows users to evaluate conditions based on the state of other alarms. This enables users to create more complex alarm scenarios, such as triggering an alarm only if two or more conditions are met simultaneously.

Once you have set up your AlarmGroup, AlarmArea, and AlarmItem, you can use the Alarms module to monitor your process and respond to any abnormal changes in conditions.

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.

Integration with Other Modules

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.

Image Added

Monitoring the Alarms Module Execution

The Alarms Monitor lets you see real-time information about the module when the solution is running. It showcases total, unacknowledged, active alarms, their priority, and the most recent alarm notification.

→ Read more about Alarms MonitorThe Alarms module can be integrated with other FactoryStudio 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 the AlarmViewer Control and AlarmAreas Control.

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. For Email information, go to the  

→ Read more about  Alarm Email Notifications page.

Customizing Alarm Sounds

Sets the sound played when an alarm goes off.

→ Read more about at AlarmGroup Sounds.

Alarms Advanced Topics

Alarm Execution Process

Presents in the detail the processes when executing the Alarm Engine. 

→ Read more about Alarm Execution Process

Alarm Runtime Attributes

The Alarms Namespace exposes properties and methods from the .NET objects used by the Alarm Module execution.

→ Read more about Alarms Runtime Attributes

Anchor
BestPractices BestPractices

Best Practices and Troubleshooting

AlarmHistorian Database definition on Datasets

The AlarmHistorian database is where the Alarms module stores all alarm events and audit trail information. The AlarmHistorian database can be defined using datasets in FactoryStudio, 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.

Advanced Features and Options

The Alarms module also includes several advanced features and options to further customize its functionality. These include the ability to create custom alarm states, the ability to filter alarms based on specific conditions, the ability to configure alarms to only be active during certain time periods, and the ability to define custom properties for alarm events and audit trail entries. These advanced features provide additional flexibility and control over the Alarms module's behavior.

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:

#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 AlarmGroupAlarm Group, areasAlarm Area, and itemsAlarm 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.

Common Issues and Solutions

The Alarms module can be customized to meet specific requirements. This section will cover the various configuration options available in the Alarms module.

The following are some of the settings that can be customized:

Sound: This setting allows the user to specify the sound that should be played when an alarm is raised.

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.

The next sections will cover how to create and manage AlarmGroup, AlarmArea, and AlarmItem.

Creating and Managing AlarmGroup

AlarmGroup are a way to group together alarms that share common characteristics, such as the same priority, area, or notification method. In FrameworkX, AlarmGroup are created and managed using the "Group" tab.

To create a new Alarm Group, follow these steps:

1. Open the Alarm in the Designer.

2. Click on the "AlarmGroup" tab.

3. Click the "New item..." button.

4. Give the group a name, description, and choose the desired settings for that group, such as the priority level, notification method, etc.

5. Click "Ok" to create the new group.

Once an Alarm Group has been created, it can be edited, disabled, or deleted. To edit an existing Alarm Group, follow these steps:

1. Open the Alarm in the Designer.

2. Click on the "AlarmGroup" tab.

3. Select the group you want to edit from the list of groups.

4. In the selected row, edit the desired properties.

5. Make the desired changes to the group settings.

6. Click "Save" to save the changes.

To disable an Alarm Group, follow these steps:

1. Open the Alarm in the Designer.

2. Click on the "AlarmGroup" tab.

3. Select the group you want to disable from the list of groups.

4. Click the "Disable" button.

5. Confirm that you want to disable the group.

To delete an Alarm Group, follow these steps:

1. Open the Alarm in the Designer.

2. Click on the "AlarmGroup" tab.

3. Select the group you want to delete from the list of groups.

4. Click the "Delete Selected Item" button.

5. Confirm that you want to delete the group.

Alarm Group Configuration Properties

Column/Field

Description

Name

Enter a name for the alarm group. The system allows you to know if the name is not valid.

AckRequired

If required, the alarm stays in the alarm list until someone acknowledges the alarm by double-clicking it in the application.

Enter a time deadband that will create a delay after an alarm occurs. The alarm will trigger again only after the deadband.

AckTimeout

Defines a timeout for acknowledging the alarm. If the alarm is not acknowledged after the specified time, the alarm becomes active again.

AutoAckTime

If the alarm is not acknowledged after the specified time, the system acknowledges the alarm.

Sound

Select the sound that will play when the alarm occurs.

Show

Select the list for the alarm to display in the alarm window in the application.

LogEvents

Select when you want the alarm to be logged to the alarm historian:

• None - Alarms are not logged.

• Active - Log when alarm is active.

• ActiveAck - Log when the alarm is active and acknowledged.

• ActiveNorm - Log when the alarm returns to normal.

• All - Log all of the above conditions.|

Colors

Select the colors you want to use for each state:

• Active - Configured alarm is in the alarm state.

• Normalized - Configured alarm was in the alarm state, but is no longer in the alarm state and still needs to be acknowledged.

• Acknowledged - Configured alarm has been acknowledged, but it is still in the alarm state.|

Description

Enter a description of the alarm group.

Using Pre-Defined Groups

The Alarms module provides pre-defined AlarmGroup that you can use to quickly configure alarms for common applications. These pre-defined groups have pre-configured properties that make it easier to create and configure alarms for specific purposes.

To use a pre-defined Alarm Group, you simply need to select it from the list of available groups and configure any additional properties as needed. The available pre-defined groups may vary depending on the version of the Alarms module that you are using and the features that have been installed.

Some common AlarmGroup that may be available, include:

1. High Priority Alarms
   This group is used to track critical alarms that require immediate attention. The alarms in this group will typically have a high priority and may be configured to generate notifications or take other actions automatically.

2. Medium Priority Alarms
   This group is used to track alarms that are important, but not as critical as high priority alarms. The alarms in this group may have a lower priority than those in the high priority group, and may not require immediate attention.

3. Low Priority Alarms
   This group is used to track alarms that are less critical than medium priority alarms. The alarms in this group may have a lower priority than those in the medium priority group and may not require immediate attention.

4. Equipment Alarms
   This group is used to track alarms related to specific pieces of equipment or systems. The alarms in this group may be configured to generate notifications or take other actions specific to the equipment being monitored.

5. Production Alarms
   This group is used to track alarms related to production processes or activities. The alarms in this group may be configured to generate notifications or take other actions related to the production process being monitored.

Using pre-defined AlarmGroup can save time and effort in configuring the Alarms module, as the properties of the alarms in the group are already pre-configured. However, you can still customize these pre-defined groups or create new ones as needed to fit your specific requirements.

Defining and Organizing AlarmArea Hierarchy

The AlarmArea Hierarchy allows you to organize your alarms based on location, equipment, or process hierarchy. This enables you to easily identify and prioritize alarms and alerts based on their importance.

To define and organize alarms areas hierarchy, follow these steps:

1. In the Alarm Configuration window, select the AlarmArea tab.

2. Click the 'New Level...' button to create a new Alarm Area.

3. Enter a unique name and description for the Alarm Area.

4. Optionally, set the priority for the Alarm Area. The priority determines the order in which the AlarmArea appear in the Alarm Group tree.

5. Repeat steps 2-4 to add additional AlarmArea.

6. To create a hierarchy, drag and drop AlarmArea onto each other to create parent-child relationships.

7. To edit an Alarm Area, select it in the Alarm Group tree and click the Edit button.

8. To delete an Alarm Area, select it in the Alarm Group tree and click the Delete button.

Organizing your alarms into an AlarmArea Hierarchy can greatly simplify alarm management, allowing you to quickly identify the source of an alarm and take appropriate action. It also allows you to easily customize alarm priorities and notifications based on your specific needs.

Adding and Editing AlarmItem

The AlarmItem is the core object of the Alarms module, which represents a condition that triggers an alarm event when a certain criterion is met. Here we will discuss how to add new AlarmItem or modify the existing ones.

To add a new alarm item, follow these steps:

1. Open the AlarmItem configuration page by selecting Alarms > AlarmItem in the Project Browser.

2. Click the 'New Level...' button at the bottom of the AlarmItem list.

3. In 'Alarms > Items', enter the required fields, which include Tag Name, Condition, and Alarm Group.

4. You can also configure optional fields such as Limit, Deadband, Setpoint, Setpoint Deadband, Group, Area, Priority, Message, and Priority Order.

5. Click OK to save the new Alarm Item.

To modify an existing Alarm Item, follow these steps:

1. Open the 'Alarms > Items' configuration page by selecting Alarms > AlarmItem in the Project Browser.

2. Select the Alarm Item you want to modify from the list.

3. Modify the fields as required.

4. Click OK to save the changes.

It is important to note that any changes made to the AlarmItem will take effect immediately, and the new or modified AlarmItem will be evaluated against the tag values in real-time.

Alarm Items Configuration Properties

Column/Field

Description

TagName

Enter a tag name or click "..." to select a tag.

Condition

Select the condition you want to use for this alarm event (see the table below).

Limit

Enter a value for the alarm limit to be used for the condition you selected.

Disable

Check the disable option to disable the item.

Deadband

Sets the deadband value. E.g.: for a Hi alarm item with limit as 100 and deadband as 10, the limit value is now 110; for a Lo alarm item, setting the deadband as 10 means the limit value is 90. 

Setpoint

Set a value or a tag that you want to compare other values to to determine if there is a deviation. 

SetpointDeadband

Set the deadband for the setpoint when compared with the deviation. 

Group

Select the alarm group that should control what happens when this alarm occurs.

Priority

Enter a priority value that controls where the alarm displays in the list. The higher the number, the higher the priority. You can use the same priority for more than one alarm event. Enter 0 (zero) for alarms to be at the end of the list.

AuxValue

Enter a Tag property.

TemplateID

--------------------

Comment

Comments about the alarm item.

Message

Enter the text that displays in the alarm list.

Alarm Condition Options

Field

Description

Hi

Tag >= limit

HiHi

Tag >= limit (when acknowledged, a Hi alarm is automatically acknowledged for the same Tag)

Lo

Tag <= limit

LoLo

Tag <= limit (when acknowledged, a Lo alarm is automatically acknowledged for the same Tag)

RateOfChange

Tag rate of change >= limit

DeviationMinor

Absolute value (tag - Setpoint) > limit

DeviationMajor

Absolute value (tag - Setpoint) > limit

Equal

Tag = limit

GreaterThan

Tag > limit

GreaterEqual

Tag >= limit

LessThan

Tag < limit

LessEqual

Tag <= limit

Changed

Tag value changed

ChangedUp

Tag value increased

ChangedDown

Tag value decreased

NotEqual

Tag different from limit

may encounter some issues in its operation. Here are some common issues and their solutions:

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.

Alarms Runtime Attributes

The T.Modules.Alarm has the properties of the alarm server. The Alarm.Group object has the list of all defined groups and their properties.The Alarm.Item object has all AlarmItem and their properties.The tag properties are connected with the Alarms module.

Example

 Tag.Tagname.Hi.Limit

 Configuration and runtime status of the HI Limit condition for the tag. The naming of all tag properties follow this same method.

In this section: