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.grassvalley.icontrol.gsm.virtualAlarm.errorSupercedesUnknown
to false.
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 |
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.
