A question of safety.........

Now I reckon I know the answer to this , but it seems that the machine builder has different ideas , I'd really welcome replies on this one .

The machine in question is a gas fired peanut roaster , the peanuts are conveyed through a heated airstream on a mesh conveyor . The machine is powered by a minimum of one , but sometimes up to 4 high output air heat gas burners - when I say high output , they can be around 750kW on a bigger machine . The mesh conveyor is driven by an motor/gearbox , generally through a VFD . On the old style machines , where there was no PLC , in the event of the conveyor stopping , the burners were reduced to low fire by breaking the control supply to the modulating valve , causing its closure , and then after a further short delay , the burner(s) was shutdown completely . This was done because peanuts are around 52% oil , and when a machine is working hard with a dark roast nut , it is a fine line between roast and fire , and when nuts catch fire , the results are fairly disasterous .

Now , our machinery manufacturer has dragged themselves into the PLC world , not because they want to , but because the market requires it .
The machine control with the exception of the gas/flame failure control is now handled by PLC , bearing in mind the process , would you allow the PLC to handle the low fire/ shut down of the burners (PID loop output to 0% , then shutdown after a predetermined time) , or would you leave this as a hardwired function ? or at least the cut off of control to the modulating valves in the event of a conveyor stop ?

My views are quite clear , but what do you guys think ?

What is detecting the "conveyor stop" condition? If it is the PLC then you already have a relatively unsafe system and you may as well let the PLC control the rest of the shutdown. If the detection is external to the PLC then by all means use safety rated external components control this shutdown.

There is a conveyor motion detector ( effectively two timers back to back ) checking the motion of the chain , either one will time out if a gearbox fault allows the drive to run but not turn the conveyor - these are in series with the VFD drive fault contacts , the drive enable contactor , and the overload associated with the drive . if all these conditions are met , a double pole relay is held in which interrupts the control cct to the burner modulating valve.

Keep it coming Bernie , I want these guys to realise the implications of using a PLC for safety !

IMO critical safety circuits should NEVER be controlled by a PLC.

You can have inputs to the plc for monitoring status/recording or to cause other things not critical to stop, but please do not have the PLC directly control the safety features.

If the old system was carried out with relays you should ask yourself what would have happened if a relay contact failed to open when required?
If using a plc, ask yourself what would happen if an output failed to turn off when required?
When plcs first emerged there was a lot of scaremongering from the HSE about the unpredictability of failures of plc outputs, i.e. they are just as likely to fail in the on state as the off state. Whereas it was considered that correctly used hardwired interlocks such as relays had a more predictable failure mode, i.e. off.
I personally don't think that this is necessarily the case. I don't think that it's fair to say that the plc based system is any less safe than the old system.
Hardwired systems are easier to defeat by a tech. with some wire links in his pocket. Plc systems are easier to defeat by a programmer with a laptop. Which is most likely to happen?
My views on any safety critical function are the same regardless of whether it is a plc, relay control or whatever. i.e. redundancy.
I always ask myself if one component fails to detect or change a dangerous state then another system should be in place to back it up, therefore there need to be two simultaneous failures of independant components before a dangerous situation can occur.

I agree with both concepts.

Have the PLC control the process at Process Control Limit "A", and hardwire the shutdown at Process Control Limit "B".

My thoughts are based on past experience with Turbine Controls. The controller would control at say up to 110% speed with a mechanical stop control at 120% speed.

Would that philosophy work for you here?

I'd be sure to validate any controls for all situations. Gas firing control makes a lot of people itchy. If you can prove it works, then more people tend to accept it.

My concern is the same - since the software can be changed by a tech on a mission with a laptop , we need to ensure safety with hard wiring - the one thing that is clear after a "happening" with a hardwired machine is that unless the tech puts the wires back in , then it is relatively easy to trace , the same with a PLC may not be the case -

Burnerman , what is your view on adjustable purge timers (hardwired) ? the same people for years used a fixed (5 minutes timer) in the panel , now for no good reason (for me) they have changed to an adjustable one - and we all know what the customer has a habit of doing with the adjustable ones .

I should add (edit) that you are quite right about what happened when an old style system failed - I wholeheartedly agree that contacts can weld etc - PLC's are reliable - my problem in this case is the programmer !! a bit of history here , some of my software was cut and pasted into this application , it has my name all over it - unfortunately the "programmer" did not put the loop into manual for the stop condition , only moved 0% into the manual CV , so only unless the operator intervened and put the loop into manual would the output be removed from the modutrol -

10baseT said:

Burnerman , what is your view on adjustable purge timers (hardwired) ? the same people for years used a fixed (5 minutes timer) in the panel , now for no good reason (for me) they have changed to an adjustable one - and we all know what the customer has a habit of doing with the adjustable ones .

Click to expand...

In my experience purge timers are generally set down to zero, either by the commissioning engineer who then forgets to turn it up again, or subsequently by impatient operators.

Fixed timers or timers with a minimum setting at least should be used.

Another thing to note: how many installations are carried out without the required purge time being calculated?
EN746-2 refers to 5 complete volume changes of the combustion chamber and flue duct. On some low temperature oven and air heater applications, i.e. where the burner is relatively small compared to the size of the combustion chamber and flue ways, I've seen calculated purge times of half an hour or more.

Wherever possible I tend to use a burner control box with a built-in pre-purge time. Honeywell RM7800 boxes have a plug-in purge timer card which can be bought in various ranges from 2 seconds up to 30 minutes, so you're not stuck with the usual 30 or 45 seconds provided on most boxes which were designed basically for boilers.

Hi

When it comes to safety and risk issues I think you should usually try to assess somehow -

i) the likelihood of something going wrong
ii) the consequences of something going wrong
iii) the cost of prevention and/or the cost of recovery

To take a really trivial example, compare rainfall and meteor strikes. Rainfall scores high in (i), very low in (ii) and very low in (iii). Meteor strikes score low in (i) but potentially catastrophic in (ii) and incalculable in (iii). And yet, compare how many people buy umbrellas compared to meteor shelters? All this demonstrates is that risk (probability) itself is not a decision-making factor alone.

In this case I genuinely don't know the answer to your (i). From what you say, (ii) is rated as unacceptable - either for process safety or personnel safety. And equally you probably wouldn't be discussing this with us if (iii) was a major drawback. So the balance of issues would seem to indicate you need some kind of safety system. If you're proposing using a standard PLC, I would then recommend a separate safety system - probably hard-wired. If you want to trust human safety to a PLC on its own you'll almost always be better off getting a specifically designed 'fail-safe' PLC with appropriate certification and ratings. With either choice, if the worst ever comes to the worst, you can then demonstrate you took all reasonable precautions during the design of the system. I assume from your flag that you'll be working with HSE regulations. You certainly want to stay the right side of them if it ever comes to litigation.

Regards

Ken

both relays & PLC contacts are subject to failure. If a tech on a mission is your concern, password protect the program. If safety is your concern, have the control option split..i.e., have the safety circuit hardwired & monitored by the plc. Just keep in mind that hardwiring fails more often than a well written program.

There are two possible issues here, which can be interlinked.
1, Safety
2, Regulations.

Talking from an Australian view point, any automated gas equipment can only use components rated as fit for use by the Australian Gas Association. Most of these components are electromechanical. You can use a PLC to control these components, but they have their own in built overrides. After this, the entire system has to be approved by the gas board. any modifications and the entire system also has to be re-approved. The system is slow an very conservative, but has proven to be quite safe.
The possibility may be that the manufacturer has already had their system approved, and is lothe to go through the approval process a second time.

Just to add a bit of extra information, the Pilz safety PLC has cards and software available for handling gas burners and this type of function. If you showed them this PLC, they may be willing to use it, since it was designed especially for this type job.

For me , the only safe thing to do is to ensure that the shutdown is done in hardware - sure the PLC can also do the same thing , but because the nature of the beast , an approved hardwired system is a must .
I'd be the first to agree that a well programmed PLC can be at least as safe as a hardwired system - the problem in this case is that it wasn't a well programmed PLC , and from what I can see it was never properly tested as a system .
UK regulations are equally clear on the subject - got to be hardwired or approved "safety" PLC .
As doug mentioned , a proper safety and risk assessment is the key to this , and the project engineer didn't carry out either !

I completely agree with stasis in this case , password protect the program - these machines use a Llandis and Gyr LGK type flame failure relay , and if I opened the panel to find one taken to bits , with boards hanging out , then I'd stop the machine and condemn it , with a machine like this , I take the same view with the software - I maintain that software can be tested fully , and after that has happened , there is no need to go messing around with it - password protect it .
For the life of me , I also can't understand why the company has gone over to an adjustable purge timer - as burnerman mentioned , the first thing the impatient customer does is turn it down to the minimum - which may be OK when the machine is new and all the valves are gas tight , but after a few years , and maybe the odd valve lets by , we can end up with a 40' container sized box , partially full up with an explosive mix of gas and air , you can guess the rest .

10baseT, you say "our machine manufacturer". I read this as your company buying from them. Where is their technical file? Where ios their risk assesment? Where is their declaration of conformity with reference to current standards for the build of this equipment? Am I being naiive, or isn't this a case of "you don't comply; we don't buy"?


Steve.

Hi Steve - just by way of clarification - I build control systems for this company who is a machine builder in Europe , the majority of the machinery that they sell is covered by CE legislation .However , and it is a big however , they have habit of copying software where they think they can get away with it - in this case , they have botched togather software from myself and two other major software houses , the results are dangerous in this case because the software was lashed together by a third party (the company was too cheap to pay for a proper job ?! ) and the programmer didn't pick up on the hardware deficiencies , and worse didn't understand the safety implications of what he was doing .

As you mention , there is no risk assessment , technical file ,Functional design specification , in fact any document that we would expect of a project like this .

In this case , my name is splashed all over block headers in the software ( and not just me , other programmers as well) , if there is ever a problem (the machine ended up in Europe) , I can see a knock on the door coming !

The functional design spec is something that I have tried to introduce , but it is an uphill struggle to get them to draw up this document as soon as an order looks firm . They maintain that for the past 600 years they have managed without all of this :- "we have always done it like this" , they don't seem to understand that we all owe a duty of care for the work we do , and the information we provide -
For me safety is something never worth compromising , for the extra 10 minutes it takes to do the job properly , it is good to sleep at night .

It is somewhat worrying that a big company seems to care less than the individuals who have taken the trouble to post here . Thanks for the posts guys !

10baseT said:

Hi Steve - just by way of clarification - I build control systems for this company who is a machine builder in Europe , the majority of the machinery that they sell is covered by CE legislation .However , and it is a big however , they have habit of copying software where they think they can get away with it - in this case , they have botched togather software from myself and two other major software houses , the results are dangerous in this case because the software was lashed together by a third party (the company was too cheap to pay for a proper job ?! ) and the programmer didn't pick up on the hardware deficiencies , and worse didn't understand the safety implications of what he was doing .

Click to expand...

10baseT said:

In this case , my name is splashed all over block headers in the software ( and not just me , other programmers as well) , if there is ever a problem (the machine ended up in Europe) , I can see a knock on the door coming !

Click to expand...

If your ( and others ) name is in the code I presume that there is also a copyright notice there as well. This sounds like unauthorized use of your code.

If, for business reasons, you don't want to use legal leverage ( read law suit ) to force them to remove your code then at the very least you may want them to sign an agreement stating that you do not agree with the design or use of your code in this way. This wouldn't save the lives of anyone using this machinery but it may save yours.

Just a thought.