Fire panels - ease of use (etc.)

[FireStopper]

Very interesting, but it sounds like an ad for Bill Gates.  Embedded TCP/IP applications, whether over GPRS or intranet in this context must run unattended, 24/7 and conform to EN54.   Until hard drives retain data reliably for 10 years they are not really something we want in a fire control panel.   Fortunately, there are other technical solutions, if the market wants them.

Title: Monitoring fire alarm systems over TCP/IP Network

[FireStopper]

The control panel would have a large easy to read LCD display and just two large coloured push buttons (Say blue and yellow in colour)...

There is a lot to be said for improving ease of use - the trouble is that most engineers are used to dealing with complex interfaces and it can be harder to make something simple than it is to make it complicated.  This kind of thing is really a job for a specialist in cognitive ergonomics (human factors analysis)... the kind of people you don't often find around on the shop floor designing things when deadlines are short and costs have to be kept down...  Perhaps if there was some way to get academic interest on board- human factors analysis is done for MOD stuff, why not fire panels?

[Benzerari]

I joined this board because I am an engineer recently moved into the fire systems industry.  One thing I would be interested in is this:  What issues can you highlight regarding ease of use of fire system control panels?  Are there things that the industry has taken for granted as the "way things are done" that could be improved upon?  Are there things that fire control panels could do that would help the fire services?  Are there failings in current fire control panels that need to be addressed?  If we conform to BS EN 54, is that enough?  Are there any accessibility issues regarding how users use fire panels, and read the displays/lamps? How about internet linked fire systems? Systems with wireless links? Anything at all that I haven't mentioned?  Please feel free to post anything relevant especially if it might influence the design of new systems.

Then

Title: Monitoring fire alarm systems over TCP/IP Network

Very interesting, but it sounds like an ad for Bill Gates.  Embedded TCP/IP applications, whether over GPRS or intranet in this context must run unattended, 24/7 and conform to EN54.   Until hard drives retain data reliably for 10 years they are not really something we want in a fire control panel.   Fortunately, there are other technical solutions, if the market wants them.

What are these technical solutions if the market wants them? Expose them to the members and coleagues. We are here to learn from each other

Thanks for Bill Gate because of him we are enjoying this firenet online forum it is based on multi-client server program or dynamic database... etc

[FireStopper]

...Thanks for Bill Gate...

I do appreciate your bringing some new ideas into the discussion; you would certainly be correct to point out that Gates bashing isn't really related to my original point.  There are surely more than enough other places on the www to discuss the pros and cons of underlying operating systems.  

So, whatever the underlying technology happens to be, it's really the user experience that counts.   Would users benefit from better networking connectivity?  Anyone who has an internet modem at home knows that it's possible to access web page data and configure settings over TCP/IP, and with much lighter hardware requirements than a typical PC.  Everything that you currently set up via a keypad or by a local link between a PC and a fire control panel could be done over a network, and at appropriate access levels.  For instance, the basic access level would allow anyone to view a networked mimic of the panel LEDs and display with no controls operable.   Then to silence alarms, activate evacuation alarms etc, you would have to go through an access procedure (e.g. username / password).   Other networking protocols could be useful, e.g. if there is an alarm, send a TCP/IP message to a server on a central guard post giving details of the activated sensors and allowing instant display of their locations (this message could be sent to multiple destinations).

I'm sure a lot of manufacturers are interested in this sort of technology (and have demonstrated prototypes) but are wary of potential reliability issues and figuring out how to satisfy EN standards if for example there is "black box" software in the part of the panel that communicates with the network.

But as I said originally I would like to focus more on the human interface, accessibility issues, new ways of communicating with panels that could make a critical difference in how quickly a suitable response can be made to a fire hazard.   It's always tempting to focus on potential difficulties with technology, so if we are to encourage development of ideas for better systems we need to think more about what is needed, and then worry about how to do the detailed technical implementation after we have specified what we want.

There is also the issue of how panels themselves work, and how sensor loops work.  Are systems for configuring sensors, zones etc. too complex?

[Graeme]

I used to use Aritech fire panels until a few years ago. Some found them complicated but they had some really useful diagnostics options that i would love to see on the panel i use now.

for example you could look at each device on the loop and see when it reached it's highest and lowest analogue values.This was the only way i could find a very intermittent loop open circuit fault.When i checked the values of all devices i noticed that they all had a low reading of 0 at the same time,so i knew the duff bit of cable was between the panel and the first device.
The loop test tested an open circuit and counted how many devices it saw on the send and return sides.

But the most handy was when in test mode you could ask for an exception report which told you any devices you have missed.

The cause and effect is easier to programme.

[Galeon]

I joined this board because I am an engineer recently moved into the fire systems industry.  One thing I would be interested in is this:  What issues can you highlight regarding ease of use of fire system control panels?  Are there things that the industry has taken for granted as the "way things are done" that could be improved upon?  Are there things that fire control panels could do that would help the fire services?  Are there failings in current fire control panels that need to be addressed?  If we conform to BS EN 54, is that enough?  Are there any accessibility issues regarding how users use fire panels, and read the displays/lamps? How about internet linked fire systems? Systems with wireless links? Anything at all that I haven't mentioned?  Please feel free to post anything relevant especially if it might influence the design of new systems.

Then

Title: Monitoring fire alarm systems over TCP/IP Network

Very interesting, but it sounds like an ad for Bill Gates.  Embedded TCP/IP applications, whether over GPRS or intranet in this context must run unattended, 24/7 and conform to EN54.   Until hard drives retain data reliably for 10 years they are not really something we want in a fire control panel.   Fortunately, there are other technical solutions, if the market wants them.

What are these technical solutions if the market wants them? Expose them to the members and coleagues. We are here to learn from each other

Thanks for Bill Gate because of him we are enjoying this firenet online forum it is based on multi-client server program or dynamic database... etc

You might like to know he wasn't behind all the techy stuff , worked in his house , analogue addressable system , with specialist application of air sampling not surprising he is very well covered .

[monkeh]

I must agree about the new KAC design, it's very fiddly and potentially easy to break/jam. I have no idea whose idea it was to redesign it when the original model had lasted the best part of 30 years with only slight tweeks here and there, but they obviously weren't end users.

'If it isn't broke - don't fix it'!

Far as I know the call point was redesigned as the test mechanism could be operated with a screwdriver and the BS called for a "special tool" etc.

But absolutely agree, new call point is a complete pain.

they could have just replaced the screw with a allen key type...

i have had the all the problems mentioned too but anyone else now think that since thay have been on the market the model before now look really old fashioned?

the new ones can still be opened pretty easily with a screwdriver.

in fact easier because at least there's no screws to be damaged leaving you with the option of smashing th whole thing off the wall and replacing it, or drilling the screw out.

also the little plastic extrusion in the centre of the top ridge of where the glass sits is perfrect for people who like to flip the glass round after its been broken.

overall the new mcps are just rubbish really.

the only positive is the test key. i broke off the two  probes for the new style mcps and just kept the miniature old style part - ideal for getting into tight spots like above stair handrails.