We have been getting feedback from security integrators that competing companies and/or clients have insisted that a software or firmware-based fire trip is adequate for the release of doors during a fire alarm. Read on to find out why a software fire trip is a fundamentally flawed practice.
A software/firmware trip is an interface to the fire indicator panel using an access control input. System logic then uses this input to send a signal to the door controllers to unlock doors during a fire alarm.
The Australian National Construction Code 2022, volume one, part D3D26 covers fire trips. To paraphrase; any fail-safe lock in a required exit path, must unlock automatically on activation of the fire system (dry or wet.) With a few exceptions, (like detention centres) this covers most doors in most buildings.
There is no specific wording saying that this must or must not be via direct relay, software, fail-safe connection or other method. Take note of that word “automatically.”
However, the accepted industry best practice is to use a fail-safe connection from the FIP to a dedicated relay that directly cuts the lock power circuit. There are several reasons why this is accepted and why software-based trips are a dangerous practice.
A software-triggered fire release relies on the software and access controllers all being programmed correctly and being online. I will break this down further:
- In most cases, there is only one fire trip signal to the access control system per building, however, there is often more than one access controller. If the network or other connection (RS485) between door controllers fails, then the fire trip will not work for some or all doors.
- If the trip is transferred from one controller to another via software, this leaves the fire trip system vulnerable to server and/or, again, network outages.
- Network and server failures would be likely during an actual fire.
- It is hard to test/confirm that the door is set fail safe. A software trip will unlock a fail-secure door also.
- Programming errors can lead to some or all doors not unlocking during a fire. Imagine a scenario where a tech has changed settings and accidentally, post-install deletes the fire trip functionality. How would you know?
- Similarly, a software-triggered fire trip is a security vulnerability. An error could result in all doors being unlocked.
- Testing of a software-based fire trip is problematic. How do you trigger the test? And will that perfectly match a real-world scenario?
- A software-based fire trip can never be 100% fail safe. In fact, it is guaranteed to not work under several scenarios.
The above problems are greatly reduced/eliminated using a failsafe, hardware-based interface. It is simple to test, cost effective, reliable and easier to fault find.
To conclude, it is the authours profesional opinion that a software-based trip fails to meet code as it can’t guarantee, due to the above-mentioned problems, that doors will automatically unlock during a fire system activation. Some people will argue with me on that point. I would ask those people if they would feel comfortable explaining their rationale to the coroner.