R2 alarm import operation

The first thing to understand about importing R2 native alarms is that they are not oBIX “StatefulAlarms,” meaning there is no defined “lifecycle” of an alarm event (unlike with the AX alarming subsystem). However, R2 alarms do support the oBIX “AckAlarm” contract, allowing acknowledgment from AX.

Thus, as shown below, all R2 native alarms appear as “normal” (green alarm bell) source state events when routed to the AX Alarm Console. However, all of the “metadata” about each event, including the alarm state (normal, offnormal, etc.), exceeded value, and so on, is included in the alarm details of the alarm record.

Figure 32. Imported R2 alarms always have “Normal” source state in Alarm Console

Alarms are differentiated by alarm feed sources, which typically correspond to different NotificationClasses in the source R2 station (unless, for some reason you choose to only add the “ObixService” as a single alarm feed source). By mapping NotificationClasses to AX Alarm Classes, you can implement similar alarm routing techniques as used in the R2 station—and perhaps more, given that multiple Alarm Consoles can be added/linked to classes. See the next section “R2 alarm source determination” for further details.

R2 alarm source determination

When R2 native alarms from the Obix driver are received in the AX Alarm Console, they display a “Source” string as follows:

“R2ObixClientName-obixProxyPointName” (if the proxy point for the source R2 object exists in the station database). By convention, this equates to the source R2 station name-proxy point name.
If the alarm source R2 object is not proxied in the station, then “R2ObixClientName-alarmClassName”.

Therefore, native R2 alarms received that were generated by objects not represented with Obix proxy points will be grouped under a single row (alarm class) in the Alarm Console, and it will not be immediately apparent about the original source object(s) responsible. To investigate further, you must double-click that row, then double-click rows again for the final Alarm Details dialog. See “Example R2 alarm imports” on page 2-19.

NOTE: In this case especially, you must be careful about acknowledgement of a single row in the Alarm Console, as it may represent several different R2 alarm sources—the single acknowledgement will be applied to all underlying alarms (whether you are aware of them or not).Be sure to look at the Ack State column to see how many unacknowledged alarms exist!