The Alarms extension of an R2ObixClient for an R2 station allows you to add “alarm feed” sources, such that native R2 events (alarms and alerts) in the station can be visible in the AX station’s AlarmService.
To configure, double-click the R2ObixClient’s Alarms extension, and in the Obix Alarm Manager view, perform a . Expand the services node, and then the NotificationService node. As shown in Figure 23, each R2 NotificationClass object is represented as a separate alarm feed, in addition to a “global” “ObixService” alarm feed.
Double-click any feed for the Add dialog. If desired, you can select a non-default local Alarm Class, but other properties are typically left at default.
If your AX station has an Alarm Class with the same AX name (as the discovered R2 NotificationClass node), then all imported
R2 alarms using that NotificationClass are automatically routed to that local Alarm Class—this overrides any Alarm Class specified in the Add dialog.
Click to add the ObixAlarmImport descriptor(s). These are the only objects added in this view, and they requires no further configuration.
Typically, you add all nodes discovered under the NotificationService, but not the node for the single discovered “ObixService”. This provides the ability for mapping different R2 NotificationClasses
to different AX AlarmClasses, rather than just “lumping” all native R2 alarms from the R2 station into a single feed with only one designated AX Alarm Class.
See the following subsections for additional R2 alarm import details:
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 NiagaraAX alarming subsystem). However, R2 alarms do support the oBIX “AckAlarm” contract, allowing acknowledgment from NiagaraAX.
Thus, as shown in Figure 24, all R2 native alarms appear as “normal” (green alarm bell) source state events when routed to an 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.
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.
When R2 native alarms from the Obix driver are received in an 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 sourceR2 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.
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!
As previously noted, all imported R2 alarms and alerts from any R2 station appear as “normal” source state events. Also, it is possible that alarms from different R2 source objects will appear under a single row in the Alarm Console (if they are not mapped as Obix proxy points). If you double-click to investigate, you see that they also appear as “normal.” As needed, double-click rows again for the final Alarm Record dialog. See Figure 25 and Figure 26.
As shown in the figures above, it may be needed to fully expand an imported R2 alarm record to understand its importance. Note that you can use the table options control in the Alarm Console to “Add An Alarm Data Column”, such as “fromState” and “toState”—these may be helpful if you anticipate a lot of R2 alarms like these.
Be aware of the fundamental difference about “alarm ack permissions” between the AX alarming model and the R2 alarming model:
-
In an AX system, a station user needs “admin write” permissions on the Alarm Class used to route the alarm in order to acknowledge it, regardless of what permissions (if any) that user may have on the source component that generated the alarm.
-
In an R2 system, a station user needs “command, alarm” permissions on the source object that generated the alarm in order to acknowledge it, regardless of what permissions (if any) that user may have on any of the NotificationClass objects.
Keep this in mind when assigning AX user permissions (using categories) to components in the AX station, noting the difference between accessing actions/properties of Obix proxy points vs. acknowledgement of alarms originated from those points.
Although the ability to see and acknowledge native r2 alarm/alert events from AX is included (as previously described), the source R2 station (JACE) must have its NotificationService config properties set as follows:
-
archiveMode=archive_local_no_SQL
-
alarmArchiveAddress, checkbox cleared
This prevents continuation of any R2 Web Supervisor handling of the station’s alarm/alert events.
Acknowledgement from AX can occur on individual events (within the popup window for that alarm source) or on all events if is pressed while that row is highlighted in the Alarm Console—regardless of how many underlying alarms may exist. This may prove problematic in actual job use. Note this especially applies if many R2 alarm-capable objects are not represented as Obix proxy points in the station.
If alarming is critical, for the reasons previously noted you may wish to transition all alarming to “native AX” alarming, instead of using the ObixClient Alarms feature. Do this by creating Obix proxy points for all objects that require alarming (or runtime/COS count events), and then adding to each point the necessary alarm extension(s), configuring them in AX. Note that extensions for R2 “alert” type events (runtime, COS counts) are found in the alarms folder of the kitControl palette.
In this “alarm re-engineering” scenario, you would typically create equivalent AlarmClasses for the NotificationClass objects used in the R2 station, configured with similar priorities and alarm recipient components.