Alarm Integration

The SoftYon driver offers three options on how to integrate C-Bus alarms into Niagara.

  • Point Alarm interface uses the C-Bus point attribute InAlarm.
  • C-Bus Alarm interface captures C-Bus alarm messages directly from the bus. The driver passes the messages as alarms to the alarm console.
  • Event Log works similar to the C-Bus alarms. The driver writes the messages as event records to history.

You can use all three methods to integrate alarms into Niagara.

Point Alarm Interfaces

Point alarms are alarms related to a control point. Typical point alarm events are Out of Range alert on analogue points or Change of State alarm on digital points.

Each control point in the SoftYon driver has the property called InAlarm monitoring the alarm status of the data point in the C-Bus controller. The driver maps InAlarm into the Niagara point status - all data points with active InAlarm have the point status set to {alarm}.

The mapping works even on control points without alarm extension. For such control points the status is set to {alarm} but there is no alarm event generated. When the C-Bus alarm condition disappears, and InAlarm changes to false and the control point status reverts to {ok}.

The InAlarm attribute is part of the C-Bus refresh (CoV) mechanism. The property value is updated along with point value and point mode immediately after any change. However, not all C-Bus data points can set the InAlarm property! Only C-Bus points with the point attribute AlarmDisabled set to FALSE will generate alarms. Additionally, there is a lot of other C-Bus attributes affecting alarm generation ( Hi/Lo Limits, ActiveState, AlarmState, etc.). Without CARE application knowledge, it’s not easy to decide whether a control point will change the InAlarm attribute. You can see the essential C-Bus point attribute values in the Point Sheet View (double click on a control point in the navigation tree). The view gives you an overview of the alarm-related attributes. However, going step by step through all Point Sheets to discover alarm relevant information is not an efficient method. Fortunately, SoftYon driver offers a much better solution as we will see later in this document.

You can use one of the following alarm extensions if you need the alarms to be visible in the Niagara alarm console:

Niagara Alarm Extension

To define your own alarm algorithm to replace the definition on the C-Bus controller, use the standard Niagara AlarmExtension. Although it is quite unusual, there will indeed be integrators who use this mode. If you decide to use this method, please note that you must set the Ignore C-Bus Alarm alarm status to TRUE in Tuning Policy. This setting disables the colour of data points based on the InAlarm value. If you leave the value to FALSE, you may find that the text will be red (InAlarm = true), while your algorithm will classify the status as normal.

SoftYon Alarm Extensions

The SoftYon driver offers a set of alternate alarm extensions. You will find them in the SoftYon Driver Palette. The only difference between Niagara alarm extensions and SoftYon alarm extensions is the ability to use SoftYon extensions in the Batch Editor, which is not possible with original Niagara alarm extensions. Please note that the SoftYon alarm extensions work only with SoftYon control points, do not try to add this extension to other point types.

SoftYon InAlarm Extension

This is the preferred method for the point alarm integration. Use the SoftYon InAlarmExtension like any other Niagara point alarm extension. The InAlarmExtension has the pre-defined algorithm based on the InAlarm value. Niagara will generate an alarm when the InAlarm value changes to TRUE. Alarm algorithm based on the InAlarm property value has a significant advantage - you do not have to know anything about alarm conditions defined in the C-Bus controller. Additionally, when using the InAlarm Extension, the driver will automatically import the alarm text from the controller as Offnormal text into the Niagara alarm source property. You can use InAlarm extension in the Batch Editor.

Alarm Manager View

As we have seen, not all C-Bus points will generate alarms, and it makes no sense to set the InAlarm Extension on points with disabled alarming. The question is - how can we discover such points without the knowledge about the application running in the C-Bus controller? The answer is the Alarm Manager View. You find this view on all C-Bus controller components.

Alarm Manager View generates a lot of traffic on the C-Bus. We advise you to disable (set enabled = FALSE) all other C-Bus controllers while engineering your alarm extensions via Alarm Manager View.

Alarm Manager View lists alarm relevant information for all points in the database. High/Low limits for analogue points, Active State, Alarm State or Service Interval for digital points, etc.

You can Add/Remove alarm extensions to/from control points directly in the Alarm Manager environment - in the table select point(s) where you are going to add/remove an extension and click the Add or Remove button. When adding an extension, you should first specify alarm class and extension type from the pulldown list.

C-Bus Alarms

While the SoftYon point alarm interface relies on the InAlarm point attribute and Niagara alarm extension mechanism, the C-Bus alarm interface catches alarm messages directly from the bus. Excel controllers send the alarms on the C-Bus as broadcast messages. The SoftYon driver captures these alarm messages and uses the C-Bus Alarm Source Info component to pass captured information to the Niagara alarm framework. C-Bus alarms are per default disabled, and you have to set the Enabled property to TRUE to activate the feature.

C-Bus controllers generate alarms on events like Low battery or Module Error (C-Bus System Alarms) or point events like exceeding limits, changes of point state etc. (C-Bus Point Alarms). If you are using a Point Extension to generate point alarms, you should avoid creating duplicate C-Bus alarm records for the same event. Use the property Suppress Point Alarms to filter the point alarms. When TRUE (default), only C-Bus system alarms are passed to the Niagara alarming.

Of course, you can abandon point alarm generation via alarm extensions and generate all alarm types via C-Bus alarm interface. This is the most straightforward method of alarm integration - on all C-Bus Alarm Source Info components enable C-Bus alarms and disable Suppress Point Alarms.

C-Bus Alarm Console Recipient

All C-Bus alarms coming from one Excel controller have the common alarm source. In the alarm console, only the youngest alarm occurrence is visible, and all older alarm records remain hidden. Older alarms are visible only in the popup window after double-clicking a table row. And much worse - if a user acknowledges an alarm in the console, all alarm records, including the hidden records, are acknowledged too and disappear from the console.

What is not a big problem for point alarms could be a severe complication for system alarms. A user could acknowledge a bunch of warnings that were never visible on the top of the alarm console! To avoid this behaviour, SoftYon driver provides you with a specialised C-Bus Alarm Console. You find this console in the SoftYon palette. C-Bus alarm console works like the standard Niagara console with one exception - if there is more then one alarm from the same Excel controller, the user cannot acknowledge all these alarms in the central console window with only one mouse click. Click on the Acknowledge button opens the detail popup window where all alarms can be acknowledged, either one by one or as a group.

Event Log

Event Log is a simplified version of the C-Bus alarm list in a Honeywell station. If enabled, C-Bus alarm messages captured from the bus are passed to the local history table. There is no colouring, prioritizing, etc.. In the history table, all alarm messages are listed like in the Honeywell station's alarm screen.