System healthy? and Panel healthy? should they be the same? and why?

[Benzerari]

Last week a serious event happened in one of our customers sites, it was a genuine fire and the system did not trigger at all, it is an advanced 4000 (I am not blaming advanced system), fortunately there was no substantial damage in live/property, the system was displaying healthy, but when checked through View/Edit, No device was found in the loops. What ever the cause was human error ... of the last engineer who worked on or not..., why should the system not displaying 'No Device Log' instead of system healthy, because the panel was healthy with itself without the rest of device. I mean not the whole fire alarm system was healthy...

Should not be better, to be considered by BS, that first you buy an analogue addressable panel and power it up, instead of showing system healthy, it should show i.e.  'No Device Log' yet, just to make the difference between ‘Panel healthy’ without Device Log in it, and ‘System Healthy’ with the Device Log in it…
I hope I am making sense.

Thank you

M C Benzerari

[Allen Higginson]

Possible faults are (1) Faulty loop card (although you would assume that the panel would show this I have had a Morley do something similar) (2) System autolearnt with no field devices connected (again,I have seen this done after a modification on the loop but thankfully only the once!).

[Graeme]

if you power the Advanced panel up and connect the batteries,it will sit happily as normal.
As Buzz mantioned,if you happened to autolearn the panel which was previously up and running,without loop connected,it will again sit as normal.

or the erase all programming may have been used by accident.

[Benzerari]

Yes I do agree this is the way advanced or other analogue addressable panels are designed to show system healthy at the moment, despite that no device are learnt yet, or probably the engineer who dealt with may have done some thing wrong by mistake, either by learning the system without the loops connected as mentioned by Buzz, or the misuse of the program jumper as mentioned by Graim... what ever the reason is... my concern is completely more about the confusion raised from the loss of the program, when the system was still showing healthy despite that no device in the loops, and no one would know about, till the next weekly bell test.

Therefore, may I repeat my question as follows?

Should not be better to be considered by BS5839, that first you buy an analogue addressable panel and power it up, instead of the system displays 'System Healthy', it should show i.e.  'Panel Healthy, No Device Log Yet' with  beeping, just to make the difference between ‘Panel healthy’ on its own without 'Devices', and ‘System Healthy’ which means with the 'Device Log' linked to it…

I hope I am making sense about this concern.

Thanks

[Allen Higginson]

Agreed - there should be some sort of "check bit" on the device that lets the panel know that it is on the loop but not configured into the system for operation.

[John Dragon]

When you buy a conventional panel, most have eol devices fitted in the panel, therefore someone could install this panel without connecting any ancillaries to it?
There is no difference between this and what you are saying about an analogue addressable panel.
Whoever installs either type must be competent to do so, and must properly test it!
It is all too common to see poorly designed/installed/tested equipment, usually by electricians who buy the cheapest kit from a wholesaler. (apologies in advance to the minority of sparkies who do a good job!!!)

[monkeh]

When you buy a conventional panel, most have eol devices fitted in the panel, therefore someone could install this panel without connecting any ancillaries to it?
There is no difference between this and what you are saying about an analogue addressable panel.
Whoever installs either type must be competent to do so, and must properly test it!
It is all too common to see poorly designed/installed/tested equipment, usually by electricians who buy the cheapest kit from a wholesaler. (apologies in advance to the minority of sparkies who do a good job!!!)

this is my opinion.

the problem here is not with the equipment, but whoever was working on it before it went tits up.

you chould have checked the event log to see exactly when the devices were learnt off the system, and at the very least when there was last a successful test on it.

if it had been left in that way by an engineer, first off they should be strung up, and second they obviously put the panel in that state for a reason.  presumably if the panel did, as you say, register a fault when it had no devices in its programming, the engineer in question would have used a workaround such as wiring a single mcp up inside the panel to keep it clear of fault.


the problem in these cases isn't with the equipment, more with the people responsible for its correct operation.

[Benzerari]

When you buy a conventional panel, most have eol devices fitted in the panel, therefore someone could install this panel without connecting any ancillaries to it?
There is no difference between this and what you are saying about an analogue addressable panel.
Whoever installs either type must be competent to do so, and must properly test it!
It is all too common to see poorly designed/installed/tested equipment, usually by electricians who buy the cheapest kit from a wholesaler. (apologies in advance to the minority of sparkies who do a good job!!!)

Yes I agree there is no difference..., conventional system is sharing the same problem with analogue addressable one, if some engineer refits the EOLs of the faulty zones into their terminals at PCB levels, just to hide the faults in the zone circuits and go home early..., the panel will show healthy but the system in fact is NOT. or as you said when you buy brand new conventional panel and power it up it will show healthy too.

Yes I agree there is no thing in contrary to the requirement of BS5839.

However, addressable system is more computer based system, it can be programmed to display what we want it to show i.e. 'Panel Healthy, No Device Yet' and also deliver a beeping fault, this beeping can be cleared out only once the 'Device Log' is uploaded and updated, then lock its memory.

Is that against BS5839?

Thank you

[Graeme]

i can see where you are coming from but

if you install an a/a panel from scratch then you will know that you have to then autolearn the loops to get from system normal to any double address,open circuit etc faults to show.

Technically if you install a panel,add 240v and battery without autolearn,then the system is normal.

If you are working on an existing system,you need to the knowledge to get into engineer mode to make any alterations wether that be a modification or a erase all programming ,which will prompt you with "are you sure".

I could understand if the panel could be erased in a general user level but you if you require the engineer code to access the level where the programming can be altered then that deems you the competant person.

[Benzerari]

Agreed - there should be some sort of "check bit" on the device that lets the panel know that it is on the loop but not configured into the system for operation.

I think you have raised a great idea Buzz, to set a double security against losing the program, if all devices have an extra sort of 'Dill Switch' to be turned ON once learnt, in which the device can not be deleted from the panel by program either deliberately or by error, till you turn OFF the 'Dill Switch' of that device, and it would be simillar if the whole program is lost, a fault would be generated with a beeping, requiring an upload back of the program.

Also in that case, I would not call it error any more, if an engineer walks around and turn OFF all of that 'Dill Switches' to delete the program.

The other thing I think it is better to be considered, is that first you by an analogue addressable panel and power it up instead of displaying system healthy it should dislpay a message saying 'Devise Log required' and not 'System Healthy'

As far as I understood a fire alarm system is ( the panel , the cabling  and the devices ) when and only when every single element is healthy then the fire alarm system can display 'System Healthy'.

Thanks

[Graeme]

you could argue that the first thing you should do is check the control panel is not faulty.

that means power up on mains and battery with nothing else connected.and in the case of non addressable-with all eol's in the panel terminals.

if panel shows fault,then you know that the control panel is the cause.

[David Rooney]

Agreed - there should be some sort of "check bit" on the device that lets the panel know that it is on the loop but not configured into the system for operation.

I think you have raised a great idea Buzz, to set a double security against losing the program, if all devices have an extra sort of 'Dill Switch' to be turned ON once learnt, in which the device can not be deleted from the panel by program either deliberately or by error, till you turn OFF the 'Dill Switch' of that device, and it would be simillar if the whole program is lost, a fault would be generated with a beeping, requiring an upload back of the program.


Thanks

So your going to autolearn a fully loaded 4 loop system then go round every head tripping a dil switch ? I don't really see the point of that.

The control panels check the actual devices fitted against the map stored in memory... if it changes a fault is recorded. Kentecs show an "unexpected device" if a detector is added and not programmed on... other systems I know don't do this and devices can sit on a loop doing nothing till programmed on. This is wrong.

The scenario here is that the engineer must have autolearned the panel with no devices present... or didn't check any analogue values after auto learning or whatever.... Sounds like "engineer" error to me.

[Benzerari]

Agreed - there should be some sort of "check bit" on the device that lets the panel know that it is on the loop but not configured into the system for operation.

I think you have raised a great idea Buzz, to set a double security against losing the program, if all devices have an extra sort of 'Dill Switch' to be turned ON once learnt, in which the device can not be deleted from the panel by program either deliberately or by error, till you turn OFF the 'Dill Switch' of that device, and it would be simillar if the whole program is lost, a fault would be generated with a beeping, requiring an upload back of the program.


Thanks

So your going to autolearn a fully loaded 4 loop system then go round every head tripping a dil switch ? I don't really see the point of that.

The control panels check the actual devices fitted against the map stored in memory... if it changes a fault is recorded. Kentecs show an "unexpected device" if a detector is added and not programmed on... other systems I know don't do this and devices can sit on a loop doing nothing till programmed on. This is wrong.

The scenario here is that the engineer must have auto learned the panel with no devices present... or didn't check any analogue values after auto learning or whatever.... Sounds like "engineer" error to me.

Yes I totally agree about this bit, the engineer must be well trained and if he does any mistakes he has to pay the price for any bad incident that could happen, the idea is to minimise the loss of program in very short time (few seconds) through a misdealing with programming stuff, more particularly when it happen by error,. In other words is to BLOCK the human error that could cause the program to be lost while the system still displays 'System Healthy'. It is just extra security measures.

Once the device is learnt it holds its place in the configuration by turning its 'Dil Switch' ON, and to delete that device from the panel either by error or deliberately it prompts you to the message 'Device Locked', that 'Dill Switch when turned OFF it sends back a permission signal to the panel to delete the device and like that it would take longer time to delete the whole 'Device Log' even on purpose or by error, this expansion in time when deleting 'Device Log' may give more time to who ever is dealing with the programming to be reminded each time he delete or lose a device from the configuration. and when losing the whole 'Device Log' by error the panel would display 'Device Log required' with Yellow LED ON and a beeping. Which can not be cleared out, till
1.   All ‘Dil Switches’ turned OFF if deleting them on propose. or
2.   Upload back the 'Device Log'.

AND JUST NOT THE PANEL DISPALYS ' SYSTEM HEALTHY'

The only disadvantage of this is the time consuming and cost of the commissioning, also a little change in the protocol of comunication and the hardware of both (Device and panel) . A part from that it is just double security measures.

Am I making sense?

[John Dragon]

Just as much to the point, was the customer carrying out his weekly tests? If so, then the problem would have become evident instead of becoming evident in the event of a real fire.

Rely on competent engineers instead of pointless safeguards like dil switches!  If you really feel the need for a double safeguard, why not see if a panel manufacturer could incorporate something like "System Healthy - 87 devices active" into their display???        See what sort of response you get?

[Benzerari]

Just as much to the point, was the customer carrying out his weekly tests? If so, then the problem would have become evident instead of becoming evident in the event of a real fire.

Rely on competent engineers instead of pointless safeguards like dil switches!  If you really feel the need for a double safeguard, why not see if a panel manufacturer could incorporate something like "System Healthy - 87 devices active" into their display???        See what sort of response you get?

The loss of the program can be caused by many ways: competent engineer who missed out some thing by error, earth fault which can corrupt the data, loop card failed, using the internal reset button while the memory is open, and many others depending upon the makes...

Do you see it normal that a panel not programmed at all, WIHTOUT 'Device Log' displays 'System Healthy', and programmed WITH certain number of 'Device Log' displays the same message 'System Healthy' too? You may say, so what? What is wrong?

However, it was just the incident stated in the first thread of this topic that has led me to think about this double security, and I believe every single engineer have seen such incident at least once in his entire work experience. A loss of the program while the panel still displaying ‘System Healthy’ and the worse thing is that no one would know about till the next weekly bell test or service…

I think, it has to be made some sort of difference between 'Panel Healthy' on its own and 'System Healthy' with the devices and the cabling? The ‘Dil Switch’ method is not the only way to double secure the program…

It could be programmed a warning message that appears say each 10mn to remind who ever the user of the system… the message could be i.e. ‘Panel Healthy, Device Log Required’ but just not ‘System Healthy’ for ever, where there is no ‘Device Log’…;)