Planning verification and the test matrix

Three weeks before testing starts, Gerry gives Sasha a job she hasn't done before: plan the north wing verification. 'Not the tests,' he says. 'The tests are easy. Plan the days. Who's where, with what, waiting for whom, and how we know when we're finished.' A good plan turns 585 devices and points, seven trades and a working hospital next door into a schedule that can actually be kept. This lesson covers the tools Sasha uses: the device schedule, the test matrix, the sequence of testing and the estimate of crew time.

Start from the device schedule

Every verification starts from a list of what is supposed to be there. On an addressable system that list comes from two places that should agree: the design's device schedule, which lists every device by drawing tag, type and room, and the panel's point list, which lists every address the panel knows. Sasha exports the point list from the programming software and compares it with Ravi's schedule before she plans anything. Any device on one list and not the other is a question to answer before test day, not during it.

For the north wing the comparison finds three differences: a heat detector in the penthouse on the drawings but not programmed, a monitor module in the panel for a pre-action valve that the north wing doesn't have, copied from another building's program, and two smoke detectors whose room descriptions are swapped. Each goes back to the installer as a pre-test item. The verification plan is built on the corrected list.

Conventional circuits and non-addressable devices need the same care. They don't appear in a point list, so the plan must list them from the drawings: each conventional zone, each notification appliance circuit and every device on it, and each relay output. On the north wing, all notification appliances are on conventional circuits fed by the panel and remote power supplies, so 182 horn-strobes and strobes appear only on the drawings and the circuit schedules.

The test matrix

The test matrix is a table with a row for every device, circuit or function and columns for everything that must be checked about it. For a detector the columns might be: location correct, type correct, address correct, description correct, alarm test, trouble test, result, date, tester. For a relay output: what it controls, the trade involved, the expected action, the time allowed and the observed result. The matrix is both the plan and the record: blank before testing, filled in as the work goes, and complete when every box has a result.

The matrix is also a checklist of what each test needs, which is where planning really happens. A heat detector test needs a heat tool and someone who knows which detectors are restorable. A waterflow test needs Luis and a drain. A duct detector test needs the air handler running and the controls technician present. Grouping tests by what they need, rather than simply walking the floors, is the difference between a three-day job and a six-day one.

Grouping and sequencing the tests

Sasha groups the work into four kinds of task:

• Field device tests that one or two technicians can do alone, floor by floor: smoke and heat detectors, manual stations, monitor modules.
• Tests that need another trade: waterflow and valve switches with the sprinkler fitter, duct detectors and fan shutdowns with the controls technician, elevator recall with the elevator mechanic, door releases with the door hardware supplier.
• System-level tests at the panel: power supplies, batteries, circuit fault tests, the network and the link to the monitoring station.
• Measurements that need quiet: sound levels in rooms with doors closed, which can't be done while other trades are drilling.

The order matters. Field devices are tested before interfaces, because an interface test is meaningless if the initiating device isn't proven. Panel and power tests come early, because a fault there affects everything else. Sound measurements go at the end of a day or on a weekend when the building is quiet. And integrated tests, which need the whole building ready, come last.

Hospitals add a constraint: the north wing is connected to the rest of Eastview. A general alarm from the north wing would, by the sequence of operation, sound the alert signal in adjacent wings and send a signal to the main panel. During verification, Bramwell's programmer puts the north wing node into a test mode agreed with the hospital so that north wing alarms are displayed at the main panel as test signals but don't sound elsewhere. Every day starts and ends with a check that the mode is set correctly, and that every network connection is restored when tests finish.

Estimating crew time

An estimate starts from the time per test and adds what really takes time: moving between rooms, setting up ladders, waiting for other trades, and recording. Gerry's rule of thumb, from many hospitals, is that pure test time is about half of the real time. Sasha builds her estimate floor by floor.

# Verification plan for the north wing: device counts by floor and crew time
floors = {
    "1": {"smoke": 38, "heat": 6, "manual": 8, "monitor": 6, "nac_devices": 30},
    "2": {"smoke": 44, "heat": 5, "manual": 6, "monitor": 5, "nac_devices": 32},
    "3": {"smoke": 40, "heat": 6, "manual": 4, "monitor": 4, "nac_devices": 30},
    "4": {"smoke": 38, "heat": 7, "manual": 6, "monitor": 3, "nac_devices": 30},
    "5": {"smoke": 38, "heat": 7, "manual": 7, "monitor": 3, "nac_devices": 30},
    "6": {"smoke": 38, "heat": 7, "manual": 7, "monitor": 3, "nac_devices": 30},
    "P": {"smoke": 0, "heat": 3, "manual": 0, "monitor": 2, "nac_devices": 0},
}
minutes = {"smoke": 4, "heat": 5, "manual": 3, "monitor": 6, "nac_devices": 2}
overhead = 2.0          # real time is about twice the pure test time
crew = 2                # technicians on field devices
day_hours = 7
total_h = 0
for f, d in floors.items():
    pure = sum(d[k] * minutes[k] for k in d) / 60
    real = pure * overhead
    total_h += real
    print(f"floor {f}: {sum(d.values()):3d} devices, {pure:4.1f} h testing, {real:4.1f} h with overhead")
print(f"field devices: {total_h:.0f} technician-hours = {total_h / crew / day_hours:.1f} days for {crew} technicians")

floor 1:  88 devices,  5.0 h testing, 10.1 h with overhead
floor 2:  92 devices,  5.2 h testing, 10.4 h with overhead
floor 3:  84 devices,  4.8 h testing,  9.5 h with overhead
floor 4:  84 devices,  4.7 h testing,  9.4 h with overhead
floor 5:  85 devices,  4.8 h testing,  9.5 h with overhead
floor 6:  85 devices,  4.8 h testing,  9.5 h with overhead
floor P:   5 devices,  0.5 h testing,  0.9 h with overhead
field devices: 59 technician-hours = 4.2 days for 2 technicians

The field devices alone come to about four working days for two technicians. On top of that Sasha plans a day at the panel for power and circuit tests, two days of trade-dependent tests (waterflow, valves, duct detectors and fans, elevators, doors), an evening of sound measurements, and two days held for retests. Integrated testing, which Owen runs, follows on its own schedule. With access limits in the operating suite and the psychiatric unit, the whole north wing verification is planned for three weeks, with a crew of two or three.

Access, keys and people

A plan that ignores access fails on the first morning. Sasha's plan lists, for each day, the rooms that must be open, the keys or cards needed, the ceilings that must be closed and the equipment that must be running. The north wing's operating suite has positive-pressure rooms that the infection control team won't let anyone enter during final cleaning, so its detectors are scheduled before the cleaning crew arrives. The psychiatric unit's doors lock electrically, so its tests are scheduled with the hospital's security staff present. The mechanical penthouse needs an escort from the general contractor's site superintendent. Each of these goes into the schedule as a constraint, with a named person responsible.

Equipment goes into the plan as well: two ladders and a lift for the atrium, test aerosol, a heat tool, a detector removal tool, a sound level meter calibrated within the last year, a multimeter, a battery load tester, radios for every person and copies of the drawings. Gerry insists on a printed set of drawings for each crew even though everyone has a tablet. 'When the tablet dies in the penthouse, I still want to know where the heat detectors are.'

Knowing when you're finished

The plan must define finished. For a new system the answer is: every row in the matrix has a pass result, every failure has been corrected and retested, every measurement is recorded, every document is received, and the report or record is signed. Sasha's plan includes a daily tally of rows complete, rows failed and rows not yet tested, so that everyone can see progress.

# Daily progress tally from the test matrix
matrix = ["pass"] * 412 + ["fail"] * 9 + ["retest pass"] * 14 + [""] * 150
done = sum(1 for r in matrix if r == "pass")
failed = sum(1 for r in matrix if r == "fail")
retest = sum(1 for r in matrix if r == "retest pass")
todo = sum(1 for r in matrix if r == "")
total = len(matrix)
print(f"rows: {total}  passed: {done + retest}  open failures: {failed}  not tested: {todo}")
print(f"complete: {100 * (done + retest) / total:.0f} %")
print("ready to report" if failed == 0 and todo == 0 else "not finished")

rows: 585  passed: 426  open failures: 9  not tested: 150
complete: 73 %
not finished

Building the matrix from the programming file

On an addressable system Sasha doesn't type the matrix by hand. She exports the point list from the panel's programming software as a spreadsheet, adds columns for each check, and adds rows for everything the panel doesn't know about: conventional notification appliances, end-of-line devices, power supplies, the monitoring link and each interface. The result is a single file that the crew fills in on tablets during the day and that prints as the device record section of the report. Starting from the panel's own list means every address the panel knows will be tested; starting from the drawings means every device the design wanted will be tested. Using both, and reconciling them, means both are true.