Fail-Safe Design in Fire Alarm Interfaces
A held-open fire door, a magnetically locked exit — these are fine right up until the moment they are not. When a fire is detected, or the power fails, an interface that keeps a door locked or held open becomes a trap. Fail-safe design is the principle that says: on fire, and on failure, escape-related interfaces must move to the state that keeps people safe. It is one of the quieter but more important ideas in interface design. This guide covers what fail-safe means and what to check.
The central point is that escape-related interfaces should be arranged so that a fire signal, or a failure such as loss of power, moves them to the safe state — doors releasing, routes clear.
Who this is for
This is for competent fire alarm engineers designing, installing or maintaining interfaces that affect escape. The experience level assumed is competent engineer. Use it for the principles; which interfaces should be fail-safe, and how, comes from the fire strategy and design, implemented through the fire alarm within BS 5839-1 and BS 7273-4 where actuation applies. The engineer's job is to prove the interface does the safe thing on both fire and failure.
What fail-safe means
Fail-safe means an interface is arranged so that, on a fire signal or on a failure such as loss of power, it moves to the safe state — for example a magnetically held door release, or a held-open fire door closing, so that escape is not obstructed. For escape, the safe state is generally that doors release and routes are clear. The idea is that the interface's default under any failure is safety, not the convenient-but-dangerous state of a locked or held-open door. Which interfaces should be fail-safe, and how, comes from the fire strategy and design, implemented through the fire alarm within BS 5839-1 and BS 7273-4 where actuation applies. Fail-safe is a design intent, deliberately built in.
Why the failure state matters
The whole point of fail-safe is what happens when things go wrong. Because a fire or a power failure should never leave people trapped, interfaces affecting escape are generally arranged so that failure results in the safe condition — doors releasing rather than locking. An interface that fails locked could obstruct escape, which is simply unacceptable for a route people depend on in an emergency. So the behaviour on both fire signal and failure has to be considered, not just the normal operating case. This follows the fire strategy and BS 5839-1, with actuation of protection measures following BS 7273-4 where relevant. Designing for the failure case is exactly what separates a safe interface from a hazardous one.
Not every interface is the same
Fail-safe is not a single setting applied identically everywhere; the safe state depends on the function. For escape-related interfaces such as door releases, failing to the released state is generally required; other interfaces have their own appropriate behaviour defined by the cause and effect. From field experience, trouble arises when an interface's failure behaviour was never really thought through — a security lock wired so that a power cut leaves it secure but an escape route sealed. The point is that the behaviour on fire and on failure is deliberately designed, not left to chance. What each interface should do comes from the fire strategy and cause and effect, within BS 5839-1 and BS 7273-4 where actuation applies.
Proving fail-safe behaviour
On service, fail-safe interfaces must be proven to fail safely, which means testing the failure case, not just normal operation. Confirm escape-related interfaces move to the safe state on a fire signal and on power failure — that doors actually release — that behaviour matches the cause and effect, and that changes have not compromised the fail-safe arrangement. From field experience, interfaces that fail in an unsafe state, and door releases never actually proven on power failure, are serious findings precisely because they only reveal themselves in the emergency. Record results, and flag any interface whose failure behaviour could obstruct escape, so it is corrected before it matters.
Common points to check
Recurring issues include interfaces that fail in an unsafe state, door releases not proven on power failure, and changes compromising a fail-safe arrangement. Confirming escape-related interfaces move to the safe state on fire and on failure is the essential check.
When not to rely on this alone
When not to use this article: do not use it to design the failure behaviour for a specific interface. That comes from the fire strategy and cause and effect, within BS 5839-1 and BS 7273-4 where relevant, applied by competent professionals.
Relevant standards
Fail-safe interface behaviour sits within BS 5839-1, a code of practice, with actuation following BS 7273-4, serving the fire strategy. The legal duty for fire precautions and safe escape in most non-domestic premises sits under the Regulatory Reform (Fire Safety) Order 2005. Separate the legal duty from the recommended methods, and always work to current editions.
Professional disclaimer
This is an educational and workflow resource for competent engineers and does not replace the current British Standards, the fire strategy, the cause and effect, or competent judgement. Verify fail-safe behaviour against the documented cause and effect and by testing the failure case.
Related documentation
Use this with the current BS 5839-1 and BS 7273-4, the fire strategy and the system cause and effect. Record proof of safe-state behaviour on fire and on failure, and flag any interface whose failure could obstruct escape.