Alarms
Use alarms to indicate the status of a process or machine at runtime. Alarms indicate that something requires attention or intervention, such as a variable reaching a critical value.
TIP:
For example, a temperature variable may change from the normal set value and activate the alarm.
This section includes
- Alarm types, alarm events, alarm variables, and custom alarm types.
- Creating alarms and alarm types, and setting polling time for alarm variables.
- Displaying alarms with alarm grids, alarm log grids, filters, dynamic messages, counters, and widgets.
- Confirming, acknowledging, shelving, and unshelving alarms.
- Alarm statuses and OPC UA alarm state behavior.
Alarm types
FactoryTalk Optix Studio
includes several predefined alarm types. Different alarm types trigger different alarm event types. You can also create custom alarm types by configuring additional properties for the alarm.For more information, see Alarm types.
IMPORTANT:
To ensure that all alarm types are displayed in OPC
UA client projects, import all alarm types from the OPC UA server project. For more
information on how to publish and import nodes, see Add an OPC UA server
and Import nodes at runtime.
Alarms configuration
Create alarms with alarm object types and alarm object instances. Configure the variables polling time for alarms. For more information, see:
Use objects and preconfigured widgets to visualize alarms status at runtime. For more information, see:
TIP:
When a controller has a non-OPC UA server, to monitor the system, you must import the controller variables and reference the controller variables in the alarm objects. If the application exposes an OPC UA server,
FactoryTalk Optix Studio
may automatically communicate with OPC UA servers through the Applications
object. The application automatically reads alarm events exposed by the OPC UA server to display event status and alarm information.Alarms management
Use the alarm grid to confirm and acknowledge alarms at runtime. You can also configure the alarm grid to automatically confirm and acknowledge alarms. For more information, see Confirm and acknowledge alarms.
Alarm statuses
FactoryTalk Optix Studio
alarm statuses use OPC UA specifications. The status
displays the alarm activity, acknowledgment, confirmation, and whether earlier
states (branches) are maintained. For more information about branching, see Display multiple active alarms for an object.For more information, see UA Part 9: Alarms and Conditions - B.1 Examples
for Event sequences from Condition instances.
Status | Description |
|---|---|
Active, Not Acknowledged, Not Confirmed | The alarm is active and requires acknowledgment and confirmation.
This state indicates a new alarm event that needs operator
attention. |
Active, Acknowledged, Not Confirmed | The alarm is active and the operator acknowledged it, but
confirmation is still required. The operator responded, but has not
yet confirmed the alarm. |
Active, Acknowledged, Confirmed | The alarm is active, acknowledged, and confirmed. All required
actions are complete for the current alarm event. |
Inactive, Acknowledged, Not Confirmed | The alarm is inactive but was not confirmed after acknowledgment.
The alarm event ended, but confirmation is pending. |
Inactive, Acknowledged, Confirmed | The alarm is inactive, acknowledged, and confirmed. The alarm
event is fully resolved. |
Inactive, Not Acknowledged, Not Confirmed | The alarm is inactive and was not acknowledged or confirmed. No
operator action occurred before the alarm returned its default
state. |
Branch State (Active or Inactive, Pending
Acknowledgment/Confirmation) | If earlier alarm states are maintained, branch states may exist.
These states require separate acknowledgment and confirmation for
each branch. Branches are created if the alarm changes state before
acknowledgment or confirmation. |
Normal | The alarm is inactive and no action is required. The system is in
a normal state. |
disabled
Provide Feedback