Safety and PLC???

Hello everybody,

I came across this article in another discussion group and I thought since most of you are professionals in PLC world ,I can gain more knowledge about the issue by posting it here.Is using PLC as a control device safe? How safe it can be? what precautions we have to take?



"
I'm not the Chicken Little type but recently (a few weeks apart)I've run accross three systems that depended solely on PLC inputs for safety. These imprudent designs were discovered after the units had been running for some time. This has prompted me to say something about safety (an issue seldom talked about on these types of forums).
With one unit (an elevator) all the outputs went on, and the elevator took off with the doors open, crushing a cleaning cart, and causing significant damage to the elevator cab, and landing door frame.
On a second unit, a PLC input stayed on with no power applied to it. This caused a pump to run continuiously and eventually burning out the motor and pump.

On a third unit a PLC output stayed on dispite the program logic, causing the machine to over-ride the final limit, crashing the machine while the operator looked on astonished with both hands in the air showing that he was off the momentary "safety" run buttons.

In all three of these cases providence intervened and nobody was hurt. However this was just a matter of luck.

"

Thank you

Atatari,

Here in Belgium and I think Europa in general have regulations according the use of a PLC as safety device. It's NOT allowed to build an emergency stop fully on software. The same goes also for proximity switches and other safety equipment. Normaly the emergency stops should be fully designed in hardware. But,

With a special ASi-network you are allowed to use emergency stops on an industrial network.( Vendors Vega(IFM), Pepperl&fuchs eso).
There are also special PLC's which are specialy designed to build your emergency stops with software. (Pilz eso).

When in your installation are proximity switches, emergency stops or other important devices according safety please don't let normal PLC's handle it. Just build it in the hardware and NOT in the software unless you make use of systems/equipment the are certified for it 'see above.

Rudi

"This has prompted me to say something about safety (an issue seldom talked about on these types of forums)."
Hmmm.. I think that safety IS adressed at this forum, though it might not be the most frequent topic. Safety is an integral part of ANY control design.

But I aggree that the use of a standard PLC for safety is both bad practice and plain unlawful most places in the world.

There are a special breed of "safety" PLCs from several vendors, but I have never seen on in real life.

A person could write a book on the questions you posed, and I'm sure there will be some lively discussion about PLCs as safety devices, but this is how I look at it from my perspective:

"A PLC can NEVER be used as the primary safety device."

I always use safety relays for guards and e-stops. Of course, I bring the state of these relays into the PLC as inputs, and I write further code to make the machine even more safe, but I always design the safety circuit to make the machine inherently safe. Honestly, the thought that PLC code is responsible for the safety circuit in an elevator gives me the shivers.

In my experence safety could be improved but there has always been at least the minimum of an Emergency Machine Off button that killed incoming power, including the power to the PLC. The devices connected to the PLC outputs are also configured to be in the safest position when not active so power off goes to a safe position. This sometimes still leaves room for problems but takes care of the basics.

Any time you talk about safety the first thing you need to do is step WAY back and do a proper safety audit.
Like S7Guy said, I think most of us will automatically use hardware e-stops in our design. The typical safety issue I run across is when the system has not been fully analyzed from a safety standpoint. You really need to go through the system with a fine tooth comb always asking "What happens if...". If the failure/condition will put someone in danger then you need to look at it with an eye toward safety and design accordingly, usually with hardware interlocks.
Also, I may be in the minority on this, but by and large I don't inherently consider product/machine damage as a safety issue. So if a machine can hurt itself but not a person I may add redundancy but I will not approach it as a full-blown safety issue.

So to summarize this ramble, I don't think most people trust plcs with safety issues. I think most people who use plcs for safety issues don't recognise the safety issue in the first place.

Keith

Any machinery have to go through a risk assessment procedure. In any country. The rules vary, but the risk assessment have to be done.

The risk assessment will/must state every safety issue and all senseble messure to reduce the risk, have to be done. So it's much more than emergency stop issues.

When the risk assessment is done properly, you will never end up with a safety system based on the PLC only. Some machinery is so complex in operation you need use a safety PLC. A safety PLC has to comply to a (vast) number of regulations, but include double CPU's manufactured by two different suppliers. The two CPU's has to double check each others operation and only when all checksums are equal an operation can take place. Furthermore are all input and output circuits checked at a sample rate.

More technical features apply, just look at Allen-Bradley/Pilz/Siemens etc.

Jesper, in the factory where I work a Pilz safety PLC is used on an industrial freezer. It's the only equipment where I saw one used but they do exist

I have used the Pilz safety PLC once for a gantry type palletizing robot with two palletizing zones.

As the robot palletizes in zone A the operator can change the (full) pallet in zone B. So when operating in zone A the safety PLC opens for access through gates for zone B. The safety PLC has to at all times monitor which zone is active, i.e. which zone is palletizing, and checks as well that all limit switches are operating OK. If the robot for some reason, e.g. a programming fault in the palletizing routine, tries to enter the inactive zone, the power to all drives are cut and an alarm goes on.

This kind of operation can only be done with a safety PLC as the same limit switches sometimes have to allow the robot to go from one zone to the other and sometimes have to cut the power.

I am currently replacing the PLC in a conveyor line where the E-Stops are wired only to the PLC. Every line in this plant was wired the same way when I hired on. Now I have rewired them and have this one left to do. It is apparent from the wiring and programming I've seen here that the folks who did the work were relatively new at it. When I started here one of the first things I looked for was properly set up E-stops. Some of the E-stops were wired in series with a regular stop button.
The E-stops are now wired to a pair of control relays which kill controls voltage and 3-Phase, have redundant switches at each E-stop station, and require the operator to check that the condition which caused the E-stop has been corrected before allowing the line to restart.
I wire my E-stops to the PLC's inputs through a separate set of contacts. This allows me to display, on the Panelview, the particular E-stop that has been tripped.
If you are new to programming read these posts and heed the info. The last phase of any program I write is the "What if..." phase. It is unbelievable what line and machine operators will try to get away with and often you can prevent injury causing actions by safe design.
We have a phrase we use here; "Automation is not a corrective action for a lack of Discipline".

This thread echos another thread I started on ADCs forum. I have been witness to the aftermath of three accidents that could have been leathel, where the PLC was used as a safety device. In one case all the PLC outputs locked on. In another case a 110vac input locked on.

The major issue is to remember that the PLC is Not a safety device.

Mike

I think I will play Devil's advocate here.
[qoute]
With one unit (an elevator) all the outputs went on, and the elevator took off with the doors open, crushing a cleaning cart, and causing significant damage to the elevator cab, and landing door frame.[/quote]
Even in full harware/relay systems devices can short or be false triggered causing damage.

On a second unit, a PLC input stayed on with no power applied to it. This caused a pump to run continuiously and eventually burning out the motor and pump.

Click to expand...

I have never seen an input stay on unless there was power from somewhere. THere can be situations where power is reverse fed.

On a third unit a PLC output stayed on dispite the program logic, causing the machine to over-ride the final limit, crashing the machine while the operator looked on astonished with both hands in the air showing that he was off the momentary "safety" run buttons.

Click to expand...

The outputs may be relay or transistor, either can fail closed just like a relay could.

The PLC is a DEVICE...a TOOL to use to automate process. It is not up to the PLC to be the safety factor, it can only do what it has been told to do. Can a system be safe using a PLC....That would depend on the designer/programmer

Guys like me have jobs because NOTHING is infallible, all devices can fail. People make mistakes.

I dont see a problem using a plc in any situation. Safety comes from determining risks an devising a system to compensate for problems that occur. That is not the PLC's job.

I don't think anyone saying that safety devices are infallible. But the fact that they are safer than PLCs is not even debatable.

For instance, I tend to favor Pilz safety relays, and use them quite often (there are other companies that work just as well, I'm sure). One item that they offer is the two-hand safety relay. Of course, I'm sure that every one of us here can program two-hand safety logic in the PLC in two minutes, and it would probably work fine for years, but that isn't the issue.

For instance, let's say that I program a two-hand control, I test it and it works fine. And, it is on a fairly complex machine that requires a program change every year or so. A year after I leave the company, another programmer "screws up" some of the indirect addressing, touches the timers that I was using for the two-hand control, and as a result allows a ram to come down on someone's hand. Yes, it is a mistake that shouldn't happen, but incorrect addressing happens all the time.

On the other hand, if I had used a two-hand safety relay instead, and wired the ram solenoid through the relay, the accident never would have happened. Sure, the guy can still screw up the logic, but at a minimum, the ram will not come down unless the two hand is pressed. Can it still fail? Sure, but the chances are far more remote.

The three examples quoted in the original post are the reason we interrupt the Control AND Primary voltage in our situations. Even if an output sticks, running the control and primary through relays (or contactors in some cases) which open during an E-stop condition will remove the energy needed to run the output devices. The chances of both the inputs and the relays sticking closed at the same time are less likely. This will NOT necessarilly work in every application; you might need a device to stay powered to prevent a dangerous situation.

rsdoran

The origional post quoted yours truly, on the AutomationDirect.com forum.

I would respectfully suggest that you pull out some of your old textbooks on the structure and design of transistors, opto-isolators etc.. Also review the wiring diagram of a basic 8 pt input unit and you will see that the opto unit is isolated from the TTL or transister that send the signal to the CPU.

Solid state components often fail in the on/closed position. In the case of an input point, wheither or not there is power on the led side ot he opto isolator has nothing to do with the failure, or shorting of the photo-transister that it's lighting up.

The same holds true in the output issue also. (opto-isolation)

Regarding the 1st case the image regester in the cpu was damaged and put on all outputs. This had nothing to do with the failure or welding of io contacts etc. This was a setup with and STD backplane. It ran for years before this failure occured.

On the case of the machine crash, the safety run swithces were soley providing power to the plc inputs. The plc output commons were wired directly to the main power supply. This incident could have been easaly prevented by using the safety run buttons to supply power to the output commons as well as the inputs. This is commonly refered to as redundancy.

These failure may be rare, and that why I brought this up. Just because you have been fortunate, or young enough not to have experinece an I/O failure of this nature does not negate the fact that they can and do occure.

I'm not ready to risk anybodys life by betting on the "odds" of failures when the cost of prevention is so little.

I dont know what your up to, but in my busniess we build control systems that lock up human beings (maybe your kids, siblings, or parents) in a box and move that box around in a building. These pepole are totally helpless to do anything to save theirselves in the event of a catastrophic failure caused by one of these conditions. Using a PLC as a safety device it totally unacceptable.

Have a safe day!

Mike