Fire alarm interface with access control doors

[Ricardo]

May I ask the techy gurus for clarification as to what is best for electrically operated latch/keep doors and the interface with a fire alarm system? This is a question I was posed earlier:-

Is an individual fire alarm interface required at each door? Or can the electrically operated doors be de-energized simultaneously from the Access Control Panel

Each of the doors will have a key fob entry on the entrance side with a green break glass and push button operation on the exit side.
In the event of a fire (or loss of power) the doors will be de-energized and the handles can be operated to exit

What I was thinking was we need to ensure that any such interface does not impede the use of the fire alarm system in any way, and meet the recommendations of BS 7273-4 for interfacing fire alarm systems with doors.

[Galeon]

You are not dealing with door hold open devices , so I don't see an issue.

[Benzerari]

Firstable, I think it's better to have a separate power supplies for door access, ...how many...depends of how many doors to operate and how far from each others...

In one site with a 5 Gent Gigilon systems all networked, in 5 different buildings, linked physically to each other, I have seen one interface of one node, monitoring the whole sites doors, any node goes in fire condition it sends fire signals through the comms. to the node in question to release all doors, and it works OK, Thanks for Paul who programmed the builds.

[Big_Fella]

When it comes to access controlled doors, theres a very simple way through this... Unless the access control system is wired in fire resistant cabling (which it won't be) you will need an interface at each set of controlled doors.  If not, and the cable burns through the doors wouldn't release.  In some instances the doors may not be equipped witha green break glass on the access control system !

[Ricardo]

Thanks for the feedback all.

[Wiz]

Ricardo, if you are hoping to comply with BS7273-4 then I wish you luck. It is the most difficult to understand BS ever. I've never met anyone who can give a reasonable explanation of it.

Do you realise, for example, it appears that your doors must always automatically release, within a pre-determined time, whenever there is a fault, of any type, anywhere on the fire alarm system?

I'm going to hazard a guess that anyone giving you advice on this forum regarding electrically powered locks in respect of fire alarm systems, is basing their knowledge on pre BS7273-4 requirements only.

If I am wrong, then I'd would be great if they could enlighten us all with a summary of the recommendations.

[Ricardo]

Thanks for that Wiz, I have had a look at this BS, thats part of the reason I have asked here for advice, its quite daunting for me a simple FS chap like me.

[Galeon]

True wiz , to many vodkas = panadol .
I don't think the manufacturers have caught up with this yet and thats the problem ie Hochiki to my knowledge their interfaces fail if the loop goes down , there is rather large thread already on this methinks.

[Wiz]

Galeon, the thread you mention only touched on a small part of a bigger problem. The phyiscal loop-failure part of it, in terms of losing power to a loop-powered device, is only a minimal part of the problem and is quite easily resolved by building an interface that needs power to keep the relay in the 'normal non-fault' position (and obviously changing over on power failure). This is currently what Hochiki do and Apollo don't.
The bigger problem meeting 7273 is that these loop-powered interfaces also need to operate even when the loop is perfectly o.k., but there is a fault of any type anywhere else, on the whole system! To achieve this requires, at a minimum, a new control application software and possibly a complete new protocol!

BS7273-4 is the pits!

[Galeon]

You dont rate it then mate , lets all go back to relay logic , now you are talking 

[Wiz]

Yes Galeon, you can't beat simplicity wherever it is possible.

Adding myriad layers of difficulty and cost to achieve only a small enhancement is scandalous.

[kurnal]

Yes Galeon, you can't beat simplicity wherever it is possible.

Adding myriad layers of difficulty and cost to achieve only a small enhancement is scandalous.

Perhaps Mr Todd may be persuaded to give us his opinion on this one?

[Galeon]

I await the rapier wit to do some slashing 

[Graeme]

Galeon, the thread you mention only touched on a small part of a bigger problem. The phyiscal loop-failure part of it, in terms of losing power to a loop-powered device, is only a minimal part of the problem and is quite easily resolved by building an interface that needs power to keep the relay in the 'normal non-fault' position (and obviously changing over on power failure). This is currently what Hochiki do and Apollo don't.
The bigger problem meeting 7273 is that these loop-powered interfaces also need to operate even when the loop is perfectly o.k., but there is a fault of any type anywhere else, on the whole system! To achieve this requires, at a minimum, a new control application software and possibly a complete new protocol!

BS7273-4 is the pits!

Wiz

according to my Apollo notes the I/O and output units fail safe when loop power is removed. Altough i'm sure i have pulled loop with an output unit on and it did not affect it.

[David Rooney]

BS7273-4 is the pits!

Spot on.... isn't there also something about releasing doors if you take a detector head out as well as changing the spacing in a corridor depending on if the adjoining doors are fire rated etc ?

This must be one of the most widely ignored unworkable BS's since BS's began !!