Door Release Through a Polled Software Gateway
A nine-story Class B office tower is being commissioned with 38 electromagnetic door holders and 22 card-reader doors fitted with magnetic locks. The fire alarm is a networked system with four nodes; the access control system is a separate head-end that polls the fire panel every 60 seconds through a Modbus TCP gateway. During the integrated acceptance test, the Level 3 doors released 42 seconds after the corridor smoke detector alarmed, and the Level 1 magnetic locks never released at all because the access control head-end had been placed in a software “masked” state for a service window. The building operator now wants the Level 1 records room to stay locked during any fire alarm to protect archived media. The AHJ has issued a temporary certificate of occupancy and has stated that a second failed test will result in the certificate being pulled. The integrator proposes adding a 30-second delay relay to “smooth” the release so occupants are not caught by doors swinging during evacuation.
1. Diagnose the failure mechanism and state what interface the door hardware should use instead.
Read the worked answer
Two independent defects, one timing and one logic.
- Timing: the release is a software event. The access control head-end learns about the alarm on a 60-second poll, then the head-end must arbitrate, write to the controller, and the controller must drop lock power. The 42 seconds observed is roughly one poll cycle plus processing - it is not a fixed value. On a different day the same design could take 59 seconds, or never fire if the queue is congested. A life-safety release cannot be a function of scheduled polling.
- Logic: the head-end was “masked,” and nothing annunciated. A masked interface is indistinguishable from a working one until it is needed.
The correct interface is a direct, supervised, hardwired link from the fire alarm control unit - a listed control relay or addressable relay module - to the lock power circuit, so that lock power is removed by a relay, not by a database transaction. The interface must fail safe: unlock on any alarm signal in the protected area, on loss of the fire alarm link, on loss of the access control head-end, and on loss of normal power. Egress doors must unlatch without delay and without a two-step process. Door holders belong on a supervised 24 VDC circuit controlled by the fire alarm, not on a network command. The access control system may monitor the release, but it must never be the release path.
2. How do you respond to the operator's request to keep one room locked during an alarm, and to the integrator's proposed 30-second delay relay?
Read the worked answer
The delay relay is a refusal, not a negotiation. A 30-second delay on egress door release is exactly the wrong direction; the observed problem is a delay that no one designed and no one can bound. Explain that occupants and responding firefighters cannot be asked to wait out a timer that exists only to hide a software latency, and that the relay would convert an intermittent defect into a permanent, documented code violation.
The records room needs a different answer than “keep it locked.” Work through the options with the operator:
- Is the door on a required means of egress? If yes, no lock scheme can defeat it during an alarm; the answer is a fail-safe lock with a compliant release and a local alarm on the door.
- If the room is not on an egress path and the door is not a required exit, asset protection can be achieved with delayed egress hardware, an access-controlled door with a request-to-exit device, or a door-position switch that reports an open door - all of which still release on alarm.
- Offer compensating measures: a second, protected egress path, relocating the media, or a vault within the room.
Document the operator's request, the options offered, and the decision in writing. If the operator insists on a non-releasing lock, escalate to the AHJ rather than accept it - the integrator's exposure and yours are identical.
3. What must the retest prove, and what documentation do you hand the AHJ?
Read the worked answer
Test intent: stop testing “the doors” and start testing the interface.
- Walk every one of the 60 doors and record release time from alarm activation to physical unlatch, measured with a stopwatch, not read from a log. Any door over about one second is a fail.
- Test the failure modes, not just the happy path: de-energize lock power, pull the interface wiring at a sample of doors while armed, disable the access control head-end, and confirm each door still releases and the panel annunciates a supervisory/trouble condition rather than going silent.
- Verify elevator recall, if any hoistway or lobby doors are interlocked, on the same alarm.
- Exercise the masked-state scenario explicitly: the panel must show an off-normal condition when the interface is not healthy.
Documentation package:
- Revised sequence of operations showing the hardwired release path.
- Point-to-point verification sheets signed by the fire alarm technician and the access control technician, one per door.
- The manufacturer's listing information for the relay module and lock power transfer arrangement.
- Test records with times, names, and instrumentation.
- Updated record of completion and as-built riser showing the release circuit.
Give the AHJ a short cover memo stating what failed, why, what changed, and the test results - an inspector who has to reconstruct the story from raw sheets will assume the worst.