NICET SSI study materials
NICET SSI study resources

Smoke Control Driven by the Building Automation System

NICET SSI · Put your knowledge to work in context.

All case studies

Smoke Control Driven by the Building Automation System

An 11-story hotel with a six-story atrium uses the building automation system to drive smoke control: 14 rooftop units, 62 smoke dampers, six stairwell pressurization fans on variable-frequency drives, and relief dampers, all on a BACnet MS/TP trunk at 19.2 kbps with a 10-second polling interval. The written sequence of operations says that on any alarm in a smoke zone, the associated rooftop units stop, the stairwell fans start, and the dampers in the zone open. At the first smoke control test, the fans started about three seconds after the alarm, before the dampers had traveled; the duct high-pressure safety switch tripped and shut down two fans. The fire command center graphics showed all 62 dampers “open” throughout because the automation system displays the last commanded state rather than a physical end switch. The only manual override of the smoke control sequence is a login to the automation workstation. Two of the six fans never proved running at all, and no one noticed because the graphic is driven by the command, not by a status input.

1. Explain the sequencing and verification failure and write the corrected start logic.

Read the worked answer

Root cause: the system commands and then believes itself. There is no interlock on proven position, and no distinction between “commanded open” and “open.”

The fan started on a timer, not on a condition, so it pressurized a duct system with closed dampers and drove the high-pressure switch to trip. The two fans that never ran were invisible because the only feedback path is the command itself, propagated over a 19.2 kbps trunk polling every 10 seconds - feedback that is slow, unverified, and not supervised.

Corrected sequence:

  1. Alarm in zone → stop the associated air-handling units (stop supply before or simultaneously with the smoke exhaust configuration, per the engineer's design intent).
  2. Command the smoke zone dampers open and the relief path open.
  3. Collect end-switch proof from each damper in the zone - hardwired, supervised, wired to a monitored input, not inferred from the network.
  4. Start the pressurization fans only when proof is present, or on a bounded timeout (e.g., 60 seconds) that annunciates a damper-failure trouble and still starts the fan.
  5. Modulate the drives to hold the design stairwell-to-corridor pressure differential while staying under the door-opening force limit, and monitor the differential, not just fan speed.
  6. Annunciate any device that fails to prove within the timeout at the fire command center, as a distinct trouble, not a generic “command failure.”

The alternative, common in retrofits, is to start the fans first and ramp slowly so the pressure switch is never tripped. That is acceptable only if the design engineer confirms the pressure switch will not shut the fans down and the resulting airflow does not damage closed dampers. Get that in writing.

2. What is wrong with using the automation graphics and a workstation login for smoke control status and override, and what should be provided instead?

Read the worked answer

Three separate problems.

  1. The status is a lie. Graphics driven by commanded state will show a green damper that is physically stuck shut. Anyone using that screen during a fire - a firefighter, a responding engineer - is being actively misled. Smoke control status must derive from physical position switches and fan running contacts.
  2. The override is not an override. A login to a general-purpose workstation is not a firefighter's control interface. It depends on the network, on the automation server, on the workstation being powered, and on someone knowing a password. The fire command center needs dedicated, labeled, physical or dedicated-interface controls that can seize the smoke control equipment from the automation system and place it in manual.
  3. The control circuits themselves are unprotected. If the wiring between the command point and the fan or damper runs through the fire area without protection, the sequence can be defeated by the fire it is designed for. Control and status circuits serving smoke control equipment must be protected for the required duration, typically with a listed circuit integrity method or a rated enclosure.

What to provide: a dedicated smoke control panel at the fire command center showing, per fan and per damper, proven position from supervised end switches; manual auto/manual selector switches for each fan and damper group; an unambiguous “in automatic / in manual” indication; and a clear statement of what the panel can and cannot do when the automation network is down. Manual control must work with the network gone.

Review the sequence against the engineer's design and the applicable smoke control standard before programming anything - the automation vendor is not the authority on the sequence.

3. What test record and retest procedure do you propose before the AHJ will accept the system?

Read the worked answer

Test procedure:

  • A step-by-step written sequence of operations with an expected response time for each step, agreed by the design engineer before the test.
  • One zone at a time, with all other zones undisturbed; verify that unrelated zones do not respond.
  • Visual confirmation of damper blade position at every accessible damper, cross-checked against the panel indication. Where a damper is inaccessible, state the sampling basis and use an alternative verification (airflow measurement, pressure differential) explicitly accepted by the engineer.
  • Fan status verified from the running contact and from measured airflow or pressure, not from the drive's speed command.
  • Stairwell pressure differentials recorded with doors closed and with the required doors open, plus door-opening force measurements at representative doors.
  • Each step time-stamped, each instrument identified with its calibration date.

Retest scope: retest every zone, not only the zone that failed. The defect is in the logic, so it affects all zones, and a partial retest invites the AHJ to distrust the entire submission.

Documentation: the sequence of operations, point-to-point verification sheets, the pressure and force readings, a narrative of the failure and the correction, the engineer's confirmation of design intent, and signatures from the testing agent, the automation vendor, and the AHJ witness. Also record the automation system version and configuration under test, because a later firmware or program change can silently alter the sequence - put a change-control and retest requirement into the owner's maintenance procedure.