beautypg.com

Understanding the alarm logic tables – Grass Valley iControl V.4.43 User Manual

Page 364

background image

Alarms in iControl

Understanding the Alarm Logic Tables

354

Understanding the Alarm Logic Tables

Understanding how the alarm logic tables work is important to being able to get predictable
results when you create a virtual alarm. Here are some points to keep in mind:

• When a GREEN sub-alarm status is compared with a YELLOW sub-alarm status, a

pessimistic table will define the result as YELLOW, because YELLOW is a worse condition
than GREEN. Conversely, an optimistic table will define the result as GREEN, because
GREEN is a better condition than YELLOW.

• When a sub-alarm has a status of BLUE (the alarm currently does not exist), and it is

compared with a GREEN sub-alarm, a pessimistic table would, in theory, define the result
as BLUE, because BLUE is a worse condition than GREEN. But, since BLUE means “status
does not exist”, it makes more sense to provide a result of GRAY, or “status undefined”, to
the virtual alarm. An optimistic table would define the result as GREEN, because GREEN is a
better condition than either BLUE or GRAY.

• Results based on sub-alarms with BLACK or WHITE status are exceptions to the rule, in that

it is not always evident which is better or worse.

• The acknowledgment component of an alarm status can only be GREEN, YELLOW,

ORANGE, RED or BLUE.

• Critical (red) has priority over Unknown (gray) by default in the calculation of a virtual

alarm. For example, if a signal loss occurs, the Signal Presence alarm turns red, while every
other alarm that depends on the signal presence is set to Unknown. In previous versions of
iControl, the Unknown alarms would take precedence in the calculation of the overall
status of the device, which would also be displayed as Unknown, even though a Critical
error has occurred (i.e. the signal was lost). As of iControl 3.20, the Critical alarm in this
example would have priority, making the overall alarm status red.

To revert to the old alarm priority behavior, set the system property:

com.miranda.icontrol.gsm.virtualAlarm.errorSupercedesUnknown

to false.

When you build a virtual alarm in iControl, you must choose which alarm logic table is to be
used to evaluate the statuses of its sub-alarms.

Note: It is possible to globally reverse the priorities of critical error (red) and
unknown (gray) statuses as they pertain to virtual alarms. This is done by setting the
following system property to true:

com.miranda.icontrol.gsm.virtualAlarm.errorSupercedesUnknown

Doing so slightly alters the combination rules of the alarm logic tables.

Additionally, we recommend setting the system property in the following properties
file on the server (not in a script) to avoid losing changes after an upgrade:

/usr/local/iControl/bin/conf/java_generic.properties