Alarm States

Business Objects and Data Sources > States > Alarm States

Alarm States

The network component provides a graphical representation for the alarm state of managed objects. New raw alarms are represented by a round rectangle alarm balloon; new impact alarms are represented by an impact alarm cloud. In addition, a secondary alarm state representation is provided for cases when an object has both impact and raw alarms.

Figure 12.7 Representation of Alarm States in a Network

The following sections outline the characteristics of graphical representations of telecom object alarm conditions.

Graphical Cues for Alarm States

The main graphical cues for alarms are:

A color associated with the object base element (the alarm coding color scheme is illustrated in Table 12.1).
An alarm count summary displayed on the object base element (the contents of the summary is explained below).
A colored alarm balloon displaying also an alarm count summary.
A colored outline displayed around the object base element.
A secondary state icon for the secondary alarm state (see Primary and Secondary States.)

Alarm State Details

Alarms can be either new or acknowledged. The term outstanding alarms includes both new and acknowledged alarms.

The graphical representation of a telecom object alarm condition shows the number and highest severity of new alarms and the number and highest severity of outstanding alarms in the following manner:

The color of the base element and the color of the alarm balloon are those associated with the most severe new alarm (see Table 12.1).
The color of the outline around the base element is the one associated with the most severe outstanding alarm.
The alarm count summary in the base element displays the number of outstanding alarms.
The alarm count in the alarm balloon displays the number of new alarms.

Alarm Count Summary

An alarm count summary displays the number and highest severity of new or outstanding alarms. It is composed of:

A number indicating the amount of most severe new or outstanding alarms.
One or more letters indicating the highest severity of new or outstanding alarms (see Table 12.1).
An optional icon to represent the highest severity of new or outstanding alarms.
A plus sign indicating that there are also less severe new or outstanding alarms.

Primary and Secondary Alarm States

A telecom object can have raw and impact alarms at the same time, which introduces the concepts of primary and secondary alarm states. The primary alarm state has a more detailed representation than the secondary alarm state. By default, the primary alarm state is the raw alarm state.

The primary alarm state is identified by the following:

The color of the base element and the color of the alarm balloon, which correspond to the most severe new alarm.
The shape of the alarm balloon.
The color of the outline of the base element, which corresponds to the most severe outstanding alarm.
The alarm count summary in the base element displaying the number of outstanding alarms.
The alarm count in the alarm balloon displaying the number of new alarms.

The secondary alarm state is identified by the following:

The secondary alarm state icon.

Figure 12.8 LEFT: Primary Alarm State for Raw Alarms. RIGHT: Primary Alarm State for Impact Alarms

Alarm Severity Coding

JViews TGO provides two types of alarms: raw and impact alarms.

Raw alarms have a range of six severity levels, including the Cleared severity. These levels and their associated color and short text are shown in Table 12.1.

Table 12.1 Raw Alarm Color Coding Scheme

Severity	Color	Text
Critical	Red	C
Major	Red	M
Minor	Orange	m
Warning	Yellow	w
Unknown	Grey	u
Cleared	Not represented	Not represented

Note

The Cleared severity is never represented in alarm states.

Impact alarms have a range of ten severity levels, including the Cleared severity. These levels and their associated color, short text and icon are shown in Table 12.2.

Table 12.2 Impact Alarm Color Coding Scheme

Severity	Color	Text	Icon
Critical High	Red	!!
Critical Low	Red	!
Major High	Red	!!
Major Low	Red	!
Minor High	Orange	!!
Minor Low	Orange	!
Warning High	Yellow	!!
Warning Low	Yellow	!
Unknown	Grey	!
Cleared	Not represented	Not represented	Not represented

Note

The Cleared severity is never represented in alarm states.

You can extend the default severity levels of raw and impact alarms. You can add new severity levels and associate them with a color and label. Functions for extending severity levels, as well as examples, are provided in Customizing Alarm Severities in the Styling documentation.

Table 12.3 provides some alarm state examples and their associated visual representations.

Table 12.3 Alarm State Graphical Representations

Alarm State Values	Visual in Network and Equipment	Visual in Table and Tree	Comment
New Critical			The resource has one new critical alarm.
Outstanding Critical			The resource has one new critical alarm, plus less severe new alarms, and one acknowledged critical alarm.
New Major			The resource has one new major alarm, plus less severe new alarms.
New Minor			The resource has one new minor alarm.
Acknowledged Minor			The resource has two acknowledged minor alarms, plus acknowledged less severe alarms.
Outstanding Warning			The resource has three new warning alarms, plus two acknowledged warning alarms.
New Unknown			The resource has a new unknown alarm.
New Critical High Impact			The resource has a new critical high impact alarm; the primary alarm state is for impact alarms.
Impact Alarms			The resource has some impact alarms; the primary alarm state is for raw alarms.
New Minor Low Impact and Raw Alarms			The resource has a new minor low impact alarm and some raw alarms; the primary alarm state is for impact alarms.
Loss of Connectivity			The alarm collection process has been shut down or alarm counts are not reliable.
Not Reporting			Alarm reporting has been suspended because the resource was purposely taken offline, for example for repairs.

Setting the Alarm Counters

JViews TGO offers two approaches to setting the alarm counters:

It is possible to combine the two computation models, having JViews TGO compute the alarm counters for some managed objects and the back end for the other managed objects.

The Back End Computes the Alarm State Counters

To set the counters:

Remove from the data source all alarms related to the managed object.
Set the computedFromAlarmList property of the alarm state to false.
Retrieve the counters from the back end and set the values in the alarm state.

To update the counter values according to changes in the back end:

Subscribe to the notification of alarm counter changes by the back end.
Update the alarm counter in the alarm state according to the back-end notifications.

JViews TGO Computes Alarm State Counters

JViews TGO can compute alarm state counters for a given managed object based on the list of alarms for this object.

To set the counters:

Use an IltDefaultDataSource for the data source.
Set the computedFromAlarmList property of the alarm state to true.
Retrieve the list of alarms for the managed object and create the corresponding IltAlarm objects. In the IltAlarm objects, set the managedObjectInstance attribute value to the object identifier of the managed object.
Add the IltAlarm objects in the same data source as the IltObject corresponding to the managed object.

To update the alarm state according to changes in the back end:

Subscribe to the notification of alarms and alarm list changes for the object.
Add, remove or update the IltAlarm business objects according to the changes.

The handlingAlarmReferences property of IltDefaultDataSource controls whether the alarm state consolidation occurs or not in a given data source. By default the consolidation is active.

Combining Alarm Counter Computation Models

You can have JViews TGO compute the alarm counters for some managed objects, and the back end compute the counters for the other managed objects. You can also switch from one computation model to the other for a given managed object.

Note

The concurrent use of the two models on the same managed object would result in inconsistent and inaccurate counters. Use IltAlarm.State.setComputedFromAlarmList to switch between the two modes. When the alarm counters are computed from the associated list of alarms, attempts to change the alarm counters directly with the alarm state APIs would trigger an IllegalStateException. Instead, update the associated IltAlarm objects.

How to Switch from Alarm Counters Computed by the Back End to Alarm Counters Computed by JViews TGO

Unsubscribe to the notification of alarm counter changes by the back end.
Disable the automatic alarm counter computation of the alarm state using the method IltAlarm.State.setComputedFromAlarmList. This will reset the counters to zero.
Retrieve the list of alarms for the managed object and create the corresponding IltAlarm objects. In the IltAlarm, set the ManagedObjectInstanceAttribute value to the object identifier of the managed object.
Add the IltAlarm objects in the same data source as the IltObject corresponding to the managed object.
Subscribe to alarm list change notifications by the back end.
Add, remove or update IltAlarm objects according to the back-end notifications.

How to Switch from Alarm Counters Computed by JViews TGO to Alarm Counters Computed by the Back End

Unsubscribe to the notification of alarm list changes by the back end.
Remove from the data source all the alarms related to the managed object.
Enable the automatic alarm counter computation of the alarm state using the method IltAlarm.State.setComputedFromAlarmList. This will reset the counters to zero
Retrieve the counters from the back end and set the values in the alarm state.
Subscribe to the notification of alarm counter changes by the back end.
Update the alarm counters in the alarm state according to the back-end notifications.

Defining Alarm States with the API

Alarms carried by telecom objects are described in the same way as states. Alarms are held by one of the IltObjectState object attributes and are modeled using an instance of the class IltAlarm.State, which is a subclass of IltState. The alarm state object includes the following information:

For each alarm severity:

The number of new alarms of this severity
The number of acknowledged alarms of this severity

Boolean indicators for special conditions:

Not Reporting: the equipment has ceased reporting alarms.
Loss of Connectivity: the connection with the equipment has been lost, thus making the recorded number of alarms unreliable.

The alarm model is the same for most of the existing object state classes. When the alarm information is based on the alarm model, you can retrieve this information by calling the method IltObject.getAlarmState.

How to Set Alarm Counters

The API for managing alarms is directly available from the IltObject class.

The following code line retrieves the object state corresponding to the alarms for an object named paris.

IltAlarm.State alarms = paris.getAlarmState();

The following code line shows how to set the count of new alarms to the object.

alarms.setNewAlarmCount(IltAlarm.Severity.Critical, 2);

To set the count of acknowledged alarms, use the following code:

alarms.setAcknowledgedAlarmCount(IltAlarm.Severity.Critical, 2);

Alarms can be set either directly, as shown above, or incrementally, as in the following code where a new critical alarm is added to the same network element.

How to Set Alarms Incrementally

alarms.addNewAlarm(IltAlarm.Severity.Critical);
System.out.println("Critical alarms on Paris: "
         + alarms.getNewAlarmCount(IltAlarm.Severity.Critical));

The printed output is the following:

Critical alarms on Paris: 3 new

How to Set Special Alarm Statuses

Special alarm statuses are set and unset using dedicated APIs.

To switch to the loss-of-connectivity mode, use the following:

alarms.setLossOfConnectivity(true);

To switch to the not-reporting mode, use the following:

alarms.setNotReporting(true);

Loading Alarm States in XML

For details on how to load alarm states in XML, please refer to Alarm States.

PREVIOUS NEXT