Control unit and annunciator testing

The annual inspection at Tamarind House starts at the control unit, not in the field. Gerry opens the cabinet, photographs the display, and reads the event history back to the last visit before he presses a single button. 'The panel remembers everything that happened this year,' he tells Sasha. 'Read it first. It tells you what's been failing and what the owner has been living with.' This lesson covers the inspection and testing of the control unit, transponders and annunciators: the parts of the system that receive signals, decide what to do and show people what is happening.

Inspecting the control unit

The visual inspection comes first. The control unit should be in its approved location, accessible, with nothing stored in front of it, and with the cabinet closed and locked when the technician isn't working on it. The technician checks that:

• the power lamp is on and the display shows normal, with no alarm, supervisory, trouble or disabled conditions, or, if there are any, that each one is recorded and explained;
• the cabinet, door, lock and wiring inside are in good condition, with no signs of water, overheating, damaged insulation, loose connections or added wiring that doesn't belong;
• the zone or point descriptions are current and match the building, with a zone chart or floor plan nearby where the standard or the authority requires one;
• the operating instructions are posted, and the documentation is where it should be (Lesson 2);
• the circuit breaker or disconnect for the primary supply is identified, marked in red or as the code requires, and locked or protected against being switched off by accident.

Gerry adds two checks of his own. He compares the software version and the date of the last program change with last year's report; a change he didn't make means someone else has worked on the system, and the changes must be found and tested. And he checks the panel clock, because an event history with the wrong time is hard to match to anything.

Reading the event history

Every modern control unit keeps a log of events: alarms, supervisory signals, troubles, resets and changes, each with a date and time. The history shows problems the annual test alone wouldn't reveal: a detector that has gone into trouble every few weeks, a ground fault that comes and goes in wet weather, a manual station that someone tampers with, or a long period when the system was in trouble and nobody called for service.

# Summarize a year of control unit events
events = [("2026-01-14", "trouble", "L2-044 dirty"), ("2026-02-02", "trouble", "ground fault"),
          ("2026-02-03", "restore", "ground fault"), ("2026-03-21", "alarm", "L1-012 smoke"),
          ("2026-04-11", "trouble", "ground fault"), ("2026-04-13", "restore", "ground fault"),
          ("2026-06-30", "trouble", "L2-044 dirty"), ("2026-08-05", "supervisory", "VS-2 closed"),
          ("2026-08-05", "restore", "VS-2 closed"), ("2026-09-18", "trouble", "AC power off"),
          ("2026-09-18", "restore", "AC power off"), ("2026-10-27", "trouble", "L2-044 dirty")]
from collections import Counter
kinds = Counter(k for d, k, w in events if k != "restore")
print("events by type:", dict(kinds))
repeat = Counter(w for d, k, w in events if k == "trouble")
for what, n in repeat.items():
    if n >= 2:
        print(f"repeated trouble: {what} ({n} times) - investigate")
print("alarms this year:", [w for d, k, w in events if k == "alarm"])

events by type: {'trouble': 6, 'alarm': 1, 'supervisory': 1}
repeated trouble: L2-044 dirty (3 times) - investigate
repeated trouble: ground fault (2 times) - investigate
alarms this year: ['L1-012 smoke']

At Tamarind House the history shows a detector reporting dirty three times, a ground fault that appears after heavy rain, one alarm in March that the owner says was cooking in a staff kitchen, and a valve supervisory signal in August that cleared the same day. Each one becomes a question for the owner and a task for the visit: the dirty detector is cleaned or replaced and sensitivity-tested, the ground fault is traced, and the August supervisory signal is matched against the sprinkler contractor's work records.

Testing the control unit functions

NFPA 72 Table 14.4.3.2 lists the control unit functions to be tested annually. They include the operation of each indicator and the display, the alarm, supervisory and trouble functions, the operation of switches such as acknowledge, silence and reset, and the transmission of each signal type to the supervising station. Each function is tested by producing the condition and observing the result, following the manufacturer's instructions for the specific control unit.

Trouble signals are tested by creating each fault the control unit supervises: opening a circuit, shorting one where the circuit class requires it to be detected, grounding a conductor, removing a device, disconnecting the primary supply and disconnecting the battery. For each fault the technician confirms that the control unit gives an audible and visual trouble signal, identifies the circuit or point, transmits a trouble to the monitoring station, and restores normally when the fault is cleared.

Circuit class matters. A Class A circuit, or a circuit with fault isolation, must keep working beyond a single open, and the test confirms it: Gerry opens a Class A loop in the middle and checks that devices on both sides still report. A circuit that goes dead beyond the open is a deficiency, often caused by a return leg that was never connected or a loop programmed as Class B.

Silence, acknowledge and reset

The silence function stops the audible signals while the alarm remains; the standard requires that a later alarm from another device re-sounds the signals, and many control units also re-sound after a set time. Acknowledge stops the panel's own sounder and marks the event as seen. Reset returns the system to normal only after the initiating device has been restored. Each is tested, and each is checked against the sequence of operation: in a two-stage system, for example, the acknowledge function may stop the automatic transfer to the second stage within the allowed time, and the test confirms the timer runs as designed.

# Check the alert-to-alarm timer in a two-stage system (or a positive alarm sequence)
design_s = 180
measured = [("first test", 177), ("second test", 181)]
for name, t in measured:
    ok = abs(t - design_s) <= 5
    print(f"{name}: transfer after {t} s (design {design_s} s)  {'OK' if ok else 'CHECK PROGRAMMING'}")

first test: transfer after 177 s (design 180 s)  OK
second test: transfer after 181 s (design 180 s)  OK

At Eastview General Hospital, which uses positive alarm sequence on some detectors, staff must acknowledge within 15 seconds and have up to 180 seconds to investigate before the general alarm sounds. Sasha times the investigation period twice, and both fall within a few seconds of the design value.

Transponders and networked panels

Larger systems have transponders or networked panels that serve parts of the building and report to a main control unit. Each is inspected and tested like a control unit, and the network itself is tested: a fault on the network wiring must be reported, and where the network is Class A or fault-tolerant, a single open must not stop communication. The main panel must show events from every node correctly. At Eastview, Gerry opens the network loop at one node and confirms that every node still reports to the main panel through the other direction.

Annunciators and displays

Annunciators repeat the control unit's information at the fire department's entrance or another approved location, so that firefighters can see where the alarm is without going to the panel. Each one is inspected for location, condition and legibility, and tested by producing an alarm, a supervisory and a trouble signal and confirming that each is displayed correctly, with the right location text, and that any controls on the annunciator, such as silence or fan controls, work. The zone or floor plan at the annunciator must match the building; an annunciator that says 'fourth floor east' when the alarm is on the fifth floor is worse than none.

Graphic annunciators and firefighter displays with floor plans are checked device by device against the building. Remote displays at a security desk or a building automation workstation, if they aren't part of the listed fire alarm system, are checked for correct information, but their failure is reported separately from the fire alarm's required functions.

Recording what the control unit shows

The control unit section of the report records the panel's make and model, its software version, the event history findings, each function tested and its result, each trouble test and its result, and the condition of the cabinet, wiring and documentation. Faults found are listed as deficiencies with enough detail that another technician could find them: 'Loop 2, Class A return leg not connected at L2-001, devices beyond open lost' is useful; 'loop problem' isn't.

Software and programming checks

Modern control units are computers, and their programming is part of the system. The inspection confirms that the program in the panel is the one recorded in the documentation: the software version, the program date and, where the panel provides one, a checksum or program identifier. If the program has changed since the last inspection and no record explains why, every function the change could have affected must be found and tested, because the change may have been made by someone who didn't test it. Gerry also keeps a copy of the current program in the documentation cabinet and in Bramwell's files, so that a failed control unit can be restored quickly.

Remote access is a newer concern. Many panels can now be connected to a network for monitoring or programming. The inspection checks that any remote connection is the one the owner authorized, that default passwords have been changed, and that the connection is recorded in the system documents. A panel that can be reprogrammed from outside the building without anyone knowing is a risk the owner should know about.

# Compare the panel's program identity with the documentation
documented = {"version": "4.12.3", "program date": "2025-11-02", "checksum": "7A3C"}
panel = {"version": "4.12.3", "program date": "2026-05-18", "checksum": "91F0"}
for k in documented:
    same = documented[k] == panel[k]
    print(f"{k:13s} documented {documented[k]:11s} panel {panel[k]:11s} {'same' if same else 'CHANGED'}")
if documented != panel:
    print("program changed since last inspection: find the change record and test affected functions")

version       documented 4.12.3      panel 4.12.3      same
program date  documented 2025-11-02  panel 2026-05-18  CHANGED
checksum      documented 7A3C        panel 91F0        CHANGED
program changed since last inspection: find the change record and test affected functions

Finally, the technician checks that the panel's operating instructions match what the panel actually does, because a responder under pressure will follow the card on the door, not the manual in the cabinet.