Alarm Queue
The Alarm Queue is every alarm SBN holds that no one has resolved yet. How a signal became an alarm — translation, zone matching, priority — is the Signal Path module; what the operator does with it is the Dispatch module. This module is the queue itself: which alarms you see, in what order, what every colour means, and the actions available before an alarm is ever treated. The queue lives on the Alarm Queue tab of Service/Data Entry (#559); Alarm Queues (#538) watches several queues side by side.
How the module progresses
- Know what the queue is showing you.
- Pick your view — whose alarms, in what order.
- Read an alarm line — colours and operator actions.
- Act from the queue — get, view, acknowledge.
1. Know what the queue is showing you
Task: name the parts of the Alarm Queue tab and control how often and how much it shows.
One line per incident — not per signal. The parameters pane on top selects what is displayed; the grid below is the queue, and each line is an incident: one line per installation and monitoring group, holding every signal that has arrived for it since it opened. The line carries the text and priority of the highest-priority signal in the incident — a later signal of equal or higher priority takes over the line, lower ones join underneath — and its Events column strings the signals together. Other alarm-management products list one line per signal; here the operator works incidents, and opening one shows the signals inside it. There are up to 16 queues — the Queue No field switches between them, and which queue an alarm lands in follows from its monitoring group (the Signal Path module). Multi-page queues page with the navigation buttons; #538 lines up several queue numbers and scrolls through them with Next.
The tab maintains itself. Refresh Interval [ALT+F11] sets the automatic refresh anywhere from 0 to 300 seconds. Hide/Unhide Parameters [F6] trades the parameters pane for more alarm lines. A flashing line means the operator who owned that alarm has logged out — it needs a new owner.
Worked example (Branch TRAIN): open the Alarm Queue tab with signals present, name the parameters pane and the grid, switch to another queue number and back, and set the refresh interval to 30 seconds.
Guided practice: hide the parameters, say what you gained and lost, unhide them — then explain to a colleague what a flashing line would demand of you.
Independent practice: the queue looks frozen. List, in order, the three things you would check — refresh interval, queue number, view parameters — and what each would explain.
2. Pick your view — whose alarms, in what order
Task: choose the view that answers the question you are asking, and predict which alarms each view shows.
Four scopes:
View | Shows |
|---|---|
Private | the operator's own queue — unassigned alarms this terminal can take (terminal and skills permitting) plus alarms it already handled. Log out with alarms still private and they stay yours; a new signal on one of them goes to the master queue for reassignment |
Master | every signal in the selected queue |
Customer | the alarms of one selected CID |
Merged | everything this operator is currently handling, across all queues |
Two orders. Priority puts the most urgent first — priority 1 at the top, and within equal priority the oldest first. Chronological shows the most recent first. Use Skills filters the queue to alarms matching the operator's skills (set up in #1811 and on the installation's Basics tab); unticked, skills are ignored.
Worked example (Branch TRAIN): with signals in the queue, cycle Private → Master → Customer (pick your own CID) → Merged and say, per view, why each line qualified to appear.
Guided practice: flip Priority and Chronological on the master view and explain the resorting you watched — which alarm moved to the top, and by which rule.
Independent practice: a supervisor asks "is anyone sitting on old alarms?" and a colleague asks "what's everything on the JEWELLERS installation?" Name the view and sort that answers each in one glance.
3. Read an alarm line — colours and operator actions
Task: state an alarm's exact status from its colour and Operator Action code alone.
Colour is status. The defaults:
Colour | Status |
|---|---|
Red | new alarm |
Yellow | acknowledged |
Green | acknowledged, and a monitoring action has been performed |
Dark green | a timer is running on the alarm |
Dark red | the timer expired |
Ice blue | parked |
Purple | parked, and a new signal arrived from the same installation |
Dark ice blue | parked with a timer running |
Dark purple | parked and the timer expired |
Colours are defined in Alarm Queue Colors (#1649); changing the defaults is discouraged — a queue everyone reads the same way is the point. A priority cutoff (option-driven) can additionally colour high-priority incidents differently.
The Operator Action column narrates the last thing done: ACX an acknowledgement (one configured event logs as ACK instead), and timer-related codes such as TM2 (timer attached) and T2O (timer expired) appear with dispatch actions. Timers, parking and the actions that set them are the Dispatch module — here you read them.
Worked example (Branch TRAIN): walk the queue top to bottom with signals present and call each line's exact status from colour + Operator Action, out loud, before checking by any other means.
Guided practice: two lines are ice blue and purple. Explain the difference to a new operator in two sentences — and say which of the two deserves attention first, and why.
Independent practice: a dark red line sits mid-queue. Reconstruct its likely history — colour by colour — from new to now.
4. Act from the queue — get, view, acknowledge
Task: pull up an alarm's installation, preview an alarm, and acknowledge a customer's signals — knowing exactly what each does and does not do.
Get Installation [ALT+F1] loads the selected alarm's installation into the top of the Data Entry screen — the installation context without touching the alarm.
View Selected Alarm in Queue [F2] shows the alarm in the Dispatch tab, view only — treating it requires getting the alarm, which is the Dispatch module's first move.
Acknowledge [F7] works in the Customer view only: it acknowledges all the selected customer's signals — the lines turn yellow, ACX appears in Operator Action, the acknowledgement is recorded in the event list with its time, and the alarms show in Dispatch. Acknowledged is not resolved: the alarms are still in the queue, marked as seen.
Worked example (Branch TRAIN): select an alarm on your own installation, Get Installation and confirm the installation on screen; back in the queue, View it in Dispatch and point at what you can read but not do.
Guided practice: in Customer view on your CID, acknowledge — then account for everything that changed: colours, Operator Action, the event list, and what did not change.
Independent practice: a caller says "ignore the alarms from my account, we're testing all afternoon". Say what acknowledging does and does not promise, what colour the lines will be an hour from now if nothing else happens — and name the module whose tools would silence the testing properly.
5. Quick reference
Key | Does |
|---|---|
[ALT+F1] | Get Installation |
[F2] | View Selected Alarm in Dispatch (view only) |
[F6] | Hide/Unhide Parameters |
[F7] | Acknowledge (Customer view only) |
[ALT+F11] | Refresh Interval (0–300 s) |
Colours: red new · yellow acknowledged · green acknowledged + action · dark green timer running · dark red timer expired · ice blue parked · purple parked + new signal · dark ice blue parked + timer · dark purple parked + timer expired.
One-liners: 16 queues, selected by Queue No; #538 watches several at once · Private keeps your alarms across logout, but new signals on them escalate to Master · Priority = most urgent first (1 on top, oldest first within a level) · Chronological = newest first · Use Skills filters by #1811 + Basics-tab skills · flashing = owner logged out · acknowledged ≠ resolved.