Alarms generated by a driver in a remote controller station can be configured to display in the
Supervisor station.
To configure alarms in one station to be received in another station you add a StationRecipient under the AlarmService container of the sending (source) station. You then link the AlarmClass component to the StationRecipient.
It is not necessary to use the same AlarmClass component in the both stations (although that is one approach). In the receiving station (often, the
Supervisor), you can configure all alarms from a remote station to route to a single local AlarmClass or, use a prepend or append scheme to route to different (but associated) alarm classes, where all schemes work based on
the names of the alarm classes.
Prepend and append
The Alarm Class property of a NiagaraStation’s Alarms extension offers two options: Prepend and Append. An associated text string adds a message. If you set up each remote station under the
Supervisor’s NiagaraNetwork to replicate the station database, each remote controller station can have identically-named AlarmClass components along with other identical characteristics.
Consider a large chain store where each remote controller is installed at one retail store and each controller station these
alarm classes: tempAlarm, humAlarm, runAlarm, accessAlarm, and so on. In the
Supervisor station, you want separate alarm classes (and routing) for individual stores, so you create AlarmClass components named storeA_tempAlarm, storeB_tempAlarm, and so forth.
Now in the
Supervisor’s NiagaraNetwork, under each NiagaraStation’s Alarms extension, you would set the Alarm Class property to pre-append the store identifier to the alarm class name: storeA_, storeB_, etc.) as you set up when you created
and named the AlarmClass components in each remote station.
Figure 19. Alarms properties under a NiagaraStation
When a store alarm comes to this
Supervisor, the station adds the prepend text to the originating AlarmClass from the remote station such that routing looks for that named AlarmClass, for example: storeB_humAlarm or storeW_runAlarm. This maintains the original alarm class mapping at the store station level
as well as segregating by store in the
Supervisor station.
NOTE: This strategy does not automatically create virtual alarm classes in the
Supervisor station. You still have to manually create all the needed AlarmClass components. AlarmClass component naming should match the Prepend or Append scheme as configured under the NiagaraStations in the
Supervisor station’s NiagaraNetwork.
