Grass Valley iControl V.6.02 - Manual (Page 321)

iControl
User Guide
311
Example — Using Pessimistic and Optimistic Alarm Logic
Consider a broadcast network with two identical signal pipelines: Pipeline #1 is on-air, while
Pipeline #2 is off-line, but configured to automatically take over should anything go wrong
with Pipeline #1. A typical use of iControl would be to create one virtual alarm to indicate a
problem on either pipeline, and another to monitor the status of the signal, regardless of
which pipeline is in use.
The first virtual alarm would use a pessimistic logic table to compare the status of each
pipeline. If both pipelines show GREEN, the virtual alarm shows GREEN. If, however, either
pipeline develops a critical error, the virtual alarm would turn RED.
The second virtual alarm would use an optimistic logic table to compare the status of the
signal on both pipelines. As long as the signal is active on either Pipeline #1 or #2, the virtual
alarm would remain GREEN.
Latches, Acknowledgment and Virtual Alarms
The status of a virtual alarm’s latched and acknowledgment components are derived from the
corresponding statuses of its sub-alarms. This has a side effect—for virtual alarms that are
calculated using pessimistic (AND) logic tables, resetting the latch will not necessarily make
the status of the latched component of the virtual alarm the same as the status of its current
component.
Resetting a latch on a virtual alarm sets the latched component of each of its sub-alarms to the
value of its current component. In turn, the statuses of each of the sub-alarms contribute to
the reset status for the virtual alarm. If there were virtual alarms included as sub-alarms, then
their sub-alarms are reset to the current status, and all these sub-alarms contribute to the
status of the top level virtual alarm. This pattern continues through all the levels of the virtual
alarm and is referred to as virtual alarm recursion.
Specify optimistic, pessimistic, or XOR alarm
logic here