Locks, egress, and life safety boundaries

Lock and egress behaviour depends on the opening, failure condition and approved design. Check the requirements for each door with the responsible site professionals.

Overview#

Security and life safety can require different behaviour from the same opening. “Fail safe” and “fail secure” are hazard conclusions for a specific door and failure, not universal lock properties or synonyms for unlocked/locked.

Separate functions#

• entry authorisation and security locking;
• required egress and accessibility;
• fire/emergency release or stair re entry where applicable;
• lockdown/security emergency policy;
• mechanical key/manual override;
• powered door/gate machinery safety;
• monitoring of door, latch/lock, power, and release circuits;
• operator and emergency service procedure.

One software integration must not arbitrate these functions casually.

Authority hierarchy#

The authority having jurisdiction, adopted building/fire/egress/electrical/accessibility rules, approved fire strategy, door hardware schedule, and qualified designers determine required behaviour. PACS logic implements only its approved part. A convenience API, VMS rule, BMS sequence, or cloud workflow can't override independent required safety functions.

IEC 60839-11-1:2013 addresses electronic access control system/component scope, but local adopted codes and product listings govern openings. Generic release wiring or timing is unsafe; use the approved site design, listed product instructions, and applicable authority requirements.

Boundary design#

PACS authorization -> security-control input
approved emergency/fire interface -> independently engineered release function
local egress hardware -> direct required egress path
monitor contacts -> observation only unless approved logic says otherwise

Document which system owns each output, the electrical normal/degraded states, priority, latching/reset, supervision, manual override, and evidence. Avoid undocumented parallel relays that make the effective logic impossible to prove.

Software/integration rules#

• Expose named operations such as an approved temporary access request, not unrestricted raw output control.
• Scope by site/door/action; require strong operator/workload identity and current authorisation.
• For high impact bulk/lockdown operations, use separate permission, target preview, reason, confirmation, dual control where required, and abort/recovery.
• Don't retry an indeterminate actuation blindly.
• Never infer safe physical state from response, lock output bit, or door contact alone.
• Keep enterprise/cloud/analytics availability outside independent required egress/emergency paths.

Degraded states#

The approved design must cover loss of mains/battery/PoE, controller/server/network/time/identity, broken/shorted wiring, fire input fault, stuck relay, jammed hardware, door propping, mechanical override, and simultaneous emergencies. Monitor the layers without creating unsafe automatic correction.

Change and testing#

Any firmware, rule, integration, wiring, lock, door, fire interface, or emergency procedure change can alter the approved system. Physical acceptance testing requires written site authority, affected person coordination, responsible fire/safety/security personnel, independent observation, emergency/egress preservation, abort criteria, manual override, and restoration evidence.

Return to Access control systems.