The Axeda® Platform supports alarm definitions, which are essentially templates for alarm instances sent in by assets. Alarm instances are messages that contain specific information about a problem on a specific asset. Alarm definitions are associated with models while alarm instances are associated with individual assets.
An alarm definition can be created automatically for the related model when an asset sends a new alarm instance to the Axeda® Platform. Alarm definitions can also be created manually, using the Axeda® Configuration application. Whether created automatically or manually, alarm definitions are managed at the model level through the Configuration application. For details, refer to the topic, View and manage alarm definitions.
Alarm instances may be generated in the following ways:
o By the asset - Assets running an agent and certain wireless tracking devices can send alarm instances to the Axeda Platform.
o By a rule - The execution of a rule on the Platform can also generate an alarm instance; when a certain condition is met, the server generates an alarm.
o By Web services or SDK operations - Axeda Web services and SDK operations can also be used to generate alarm instances.
Service technicians can monitor and manage alarm instances through the Axeda® Service application, from the Asset dashboard for each asset. Managing alarm instances includes not only performing service actions to correct the problem but also changing the state of the alarm instance. Different service organizations may have different workflows for resolving problems with assets.
Alarm states can help show the progress of problem resolution. For example, the initial state of a new alarm is Started. Once a service technician is ready to work on the problem he or she can set the state to Acknowledged. If the problem requires additional assistance from a development engineer, the technician can set the state to Escalated and notify that engineer. The engineer can indicate that he or she is working on it by setting the state to Acknowledged again. Once the issue is resolved, then the state can be set to Closed.
If an alarm is reported many times and the technician wants to suspend any future reports until the problem is resolved, the technician can temporarily change the disposition of the alarm to Suppressed. While any current instances of the alarm remain, but future instances are Closed and sent directly to the Historical Alarms page. When ready, the technician can change the disposition back to Unsuppressed and new instances of the alarm will be set to Started when they arrive. If the technician wants to prevent the alarm from ever appearing in the Service application again, the technician can change the disposition to Disabled. Once the disposition is Disabled, the alarm cannot be changed to any other state. All new instances of the alarm are discarded; the Platform has no record of them.
Click here to display a diagram that shows the possible state changes for a Started alarm within the lifecycle of an alarm in the Platform.
As you can see in the illustration, the lifecycle of an alarm has more steps than the state changes. First, an alarm instance is checked to see if it is a duplicate of an existing current alarm. The Platform checks the name of the alarm and the name of the associated asset only. If different data items or different values of a data item trigger the same alarm, the Platform does NOT distinguish between two instances of the alarm, each with a different data item or different value. It simply stores the information with the instance of the alarm with which it was sent. For example, a value of 100 for Temp_1 and a value of 200 for Temp_2 both generate the same alarm. If a current alarm instance exists with Temp_1 as the trigger and the asset sends in another instance of the alarm, with Temp_2 as the trigger, the Platform treats the second instance as a Duplicate. Temp_1 and its value are stored with the current alarm, while Temp_2 and its value are stored with the duplicate instance of the alarm. Similarly, if the asset sends an alarm of the same name but a different severity, then the Platform treats that alarm as a Duplicate as well. Duplicate is a Terminal state, meaning that the alarm instance is sent immediately to Historical Alarms and is not available to business rules. For a Duplicate alarm instance, the state is set to Duplicate. For more information about duplicate processing, refer to Duplicate Alarms.
Once an alarm instance is determined to not be a duplicate, the Platform checks the initial disposition currently configured for the alarm. The initial disposition for an alarm determines how new instances of the alarm will be processed. You have already seen how normal processing works - the alarm is Started and then its state can be changed as the problem is resolved. For an alarm instance to be in the Started state, the alarm definition must be Enabled and Unsuppressed. These settings are the defaults for any new alarm definition, whether defined through the Configuration application or created automatically when an instance of the alarm is detected by the Platform.
However, through the Axeda Configuration application and Axeda® Connected Product Management Applications Web services, alarm definitions can be disabled, re-enabled, suppressed, and unsuppressed for models; through the Axeda® Service application, alarm definitions can be enabled, disabled, suppressed, and unsuppressed for individual assets. These actions change the initial disposition and processing of a new alarm instance, as follows:
Disabled -- the alarm definition has been disabled. A new alarm instance will be discarded from the Platform immediately. No processing takes place; the alarm instance is not available for business rules.
Suppressed -- the alarm definition has been suppressed. A new alarm instance is processed as follows: the alarm instance is closed immediately upon receipt and sent directly to Historical Alarms. The state of the alarm is set to Suppressed. The alarm instance is not available for business rules.
Only if the initial disposition is Started is the alarm state available for evaluation in an IF statement of an Expression Rule or for state changes through the SetAlarmState action. An alarm with an initial disposition of Started can be transitioned through a SetAlarmState action or through Web services (in addition to the Axeda® Service application) to one of the following states: Acknowledged, Escalated, or Closed, as shown in the illustration above.
Notes: The Disable, Suppress, Enable, and Unsuppress actions affect FUTURE instances of alarms. State changes are not recorded in the Audit Log. However, changes to the initial disposition ARE recorded.
For alarms sent by Axeda IDM Agents, the alarm name is always set to "FaultGeneratedByAsset". To view the four components of the alarm, click the name of the alarm in the Alarms module of the Asset dashboard. The Alarm Details window appears; the Description field on this page contains the alarm components. If you are using the IDM Agents, you can avoid the alarms from being treated as duplicates by asking your Platform administrator to disable the duplicates from processing, or you can create an expression rule that creates a new alarm with a name that is based on the content of the FaultGeneratedByAsset and then immediately closes the FaultGeneratedByAsset alarm.
Important! If you are using an Alarm Point server to provided notifications about alarms through, for example, cellular telephones, and to transmit acknowledgements of alarms from service technicians to the Platform, keep in mind that, if duplicate processing is disabled, ALL instances of an alarm will be sent to the Alarm Point server and each one must be acknowledged separately. In addition, keep in mind that the alarm state will be set to "Acknowledged" on the Platform and the alarm will NOT be closed.
For information about using the Alarms module on the Asset dashboard, refer to Asset dashboard - Alarms module. For information about the Current Alarms page of the Axeda® Service pplication (which shows only alarms in the Started, Acknowledged, or Escalated states), refer to Current Alarms. For information about the Historical Alarms page (which shows ALL alarms), refer to Historical Alarms.
For information about configuring alarm definitions, refer to Create alarm definition. For information about managing alarm definitions at the model level, refer to View and manage alarm definitions. For information about managing alarm definitions at the asset level, refer to Alarm Definitions for an Asset (Service application).
For information about using the SetAlarmState action in an Expression Rule, refer to Expression Rule definition and to SetAlarmState() Action.
For information about using the Axeda Applications SDK and Web services to manage alarms, refer to the Axeda® Platform API Developer's Reference Guide and Axeda® Connected Product Management Applications Web Services Developer's Reference Guide.