Fire alarm interface with access control doors

[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!

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.

Graeme,

Your reply threw me for a bit! Please check the note again.

I've now checked with my technical mole at Apollo and can confirm that none of their interfaces yet function as relay energised for normal condition (thereby allowing loop power failure to cause the relay to de-energise for fail-safe applications). This option might be available in the future.

However there are a limited number of panel manufacturers who have a feature in their configuration software to command an addressable interface relay to energise for it's 'normal' condition and release in it's 'operate' condition. In this circumstance the relay would also release on loop power failure.

In all events it appears that no-one has yet written a software configuration that tells designated interfaces to release on any fault anywhere on the system, which is required by BS7273-4. This sort of configuration should be quite easy to write although it still wouldn't provide the necessary requirement (within BS7273-4) of also operating the relays if the protocol stream failed in some way i.e. the message to operate couldn't get through. The only way to do this would to write a new protocol/configuration where the interface relay would be continually reminded by the protocol to remain energised when everything is in the 'normal' condition. In this scenario the relay would release to 'operate condition' immediately it received a protocol signal to do so, or after a pre-determined time period of not receiving the 'reminder' signal or immediately power failed.

[Galeon]

So we are back to relay logic , permanently energised fire relay along with fault relay , and bobs your uncle.

[Graeme]

Wiz

Copied off my pc from Apollo

*Note:For these units removal of loop power will
cause a "set" relay to reset. Contact Technical Sales
if in doubt

[Wiz]

Wiz

Copied off my pc from Apollo

*Note:For these units removal of loop power will
cause a "set" relay to reset. Contact Technical Sales
if in doubt

Thanks for your reply Graeme.

The text quoted just means that if the interface realy has been turned on it will then obvoiusly release if you remove the power from the loop. If it hasn't turned on, then removing the loop power does nothing to it.This is obviously not the same thing as being fail-safe in the context of the 7273-4 recommendations etc.

[Wiz]

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 !!

You are right on both the above, David, as I read it as well.

Also it means the removal of any detector and not just one that might be protecting the area around the doors.

Also I think it is not only detector spacings in the corridors but the position of detectors in rooms leading on to those corridors in L3 systems.

And at the beginning it tells you that recommendations in BS7273-4 overide anything in BS5839-1 and at the end it tells you that much of the recommendations might be altered in the future by other documents etc.

Whoever worked on this BS should be put in the stocks and pelted with rotten fruit!

Obviously, the recommendations could all be made clearer to us if Lord Toddy or one of his cohorts were to publish a 'guide' on this BS. However, I suspect they are as baffled as the rest of us on this one!

[Wiz]

So we are back to relay logic , permanently energised fire relay along with fault relay , and bobs your uncle.

Sorry Galeon, but Bob is not even close to being your father's brother if the fault relay does not operate for every fault everywhere on the system in 7273-4. If it does operate for every fault anywhere, then your assertion seems to be right.

But even then, the problem of getting the 'fault' information to an addressable interface realy is huge.

And, by the way, does the fault relay also have to be normally energised, just in case of failure?

Furthermore all 'normally energised' recommendations always ignore the fact that in any function you always need something to 'turn on' to be able to 'denergise' something. You can never make anything totally fail-safe so why knock yourself out to make, say 9 steps of a function fail-safe when it still need something at the beginning of the function to 'turn on' anyway!

In my opinion, the benefits achieved by meeting the BS7273-4 are mostly minimal against the cost of achieving them.

[Graeme]

Wiz

Copied off my pc from Apollo

*Note:For these units removal of loop power will
cause a "set" relay to reset. Contact Technical Sales
if in doubt

Thanks for your reply Graeme.

The text quoted just means that if the interface realy has been turned on it will then obvoiusly release if you remove the power from the loop. If it hasn't turned on, then removing the loop power does nothing to it.This is obviously not the same thing as being fail-safe in the context of the 7273-4 recommendations etc.

Wiz

Now i have read it back the penny has dropped.

cheers

G

[colin todd]

Wiz et al, Since I drafted BS 7273-4 under contract to BSI it is unlikely that I am baffled by it. I was aksed by BSI if I would like to write a guide to the code, but I told them as the recs are all self explanatory there was no need/no market. As for faults causing release of doors, this had been a specific requirement of Home Office Guides since time immemorial.

The fact that we actually specified how it was to happen, and the shock and horror expressed in this site, simply endorses the fact that the fire alarm trade never ever did give the enforcing authorities what they asked for, and the fact that the enforcing authorties were incompetent to judge what they were looking at. Take a look at the circuit in an early CFOA guidance note on the subject, and you will find that the circuit would fail a schoolboy in GCSE physics and does not reflect how fire alarm systems do the interface.

I still remember the horror of the CFOA rep when I told him that no fire alarms systems at all ever worked the way specified in all the govt guides on legislation, and that inspecting officers had been walking past that for decades, while we tried to explain this to them.

We do some seminars on BS 7273-4, although we dont bother marketing them to any extent cos I thought it as all so obvious that there was no living to be had explaining the obvious. Clearly I was wrong. You read it here first.

[Wiz]

Colin, I apologise for putting you in the stocks and pelting you with rotten fault. 

I wasn't actually sure if you were involved in BS7273-4 but I still apologise for inciting the population to riot.

In response to your reply I wanted to now highlight the parts of BS7273-4 that annoy/confuse me, but I don't currently have the time to fully do it justice. I am today departing on holiday for a week. By the same token, I didn't want to not respond for more than a week, or you and others might have thought I was hiding!

On my return, I hope to raise a few issues for discussion that might help the rest of us to more fully understand this BS, but to give you all something be getting on with whilst I am away, I'd like to raise a couple of examples that support, I hope, my assertion that BS7273-4 is very confusing and is not,as you, state 'self explanatory' (well it is self-explanatory, of course. It's just not explained very well!):

1) In Clause 5.1.1 for example, various 'reaction' times are quoted for different fault circumstances; These include: 3s, 60s, 120s, 17m & 32m. These are all in one small section of the BS! Are so many different times really necessary?

2) There are over 80 'notes' in addition to the recommendations and commentary. Not all of these notes clearly state to which clause they refer to. Some pages have so many notes on them that some of these notes are nowhere close (on the page) to the clause they refer to (I believe this to be true, but then again I can't really tell!). Were so many notes really necessary and couldn't they have been identified in a better way?

I trust you will see from the posts on this thread already that we are all finding this BS too difficult to understand and a 'guide' is desperately needed if the recommendations of this BS are to be implemented in the real world. Only you profess to understand it!

[colin todd]

The times were necessary to be inclusive to all products. The 3 second is because that is easily achievable, and, if the power fails to locked doors on means of escape, it was considered that their criticality was such that they should fail safe more or less immediately. The 60 secs for self-closing fire doors then allows a short time delay for a device that might not be able to meet the 3 seconds. In practice for most devices, it will be immediate anyway, but there is no reason to rule out a short delay if it doesnt matter anyway. The 15 minutes is actually the European Standard plus 2 minutes, to allow for transmission of the fault warning that can take 15 minutes to even be identified under the EN. Ditto the 30 minutes. The 120 s allows fo radio based systems that do not continuously trasmit a signal.

I have always worked by the principle that when you write standard you should never effectively "bar" the use of existing products or those in innovation unless you think you really really must on the grounds of safety. The times in question accommodate all equipment on the market as a sort of lowest common denominator.

While the background to the times may not seem intuitive to you, I cannot see how it confuses or precludes simple application of the code, as the recommendations are quite clear. Whether you agree with them is more or less irrelevant to your ability to comply if that is what you are trying to do.

The notes simply amplify points for the purpose of clarification, so making the text shorter to read and a shorter (and hence cheaper) standard overall. Ther proximity to the matters with which they are associated is the result of a new house style of BSI. Personally, I do not like it, but I suppose the answer is that, if I was that bothered, I should have said so when the new house style was out for consultation, much as people had the opportunity to comment on the draft BS 7273-4 if they were that bothered. And TW will be pleased to know that what he recommends is exactly how BS codes of note have been produced for years. The idea of committees wordsmithing text went out donkeys years ago.