DLB

Faults and Safety Routines

15 posts in this topic

Hi, Please could someone explain how faults are usually dealt with in PLC Logic? I know this is a pretty general question. I have a process that runs as a continual task (which I have developed using Use Cases in the Functional Specification for the system). but I don't know how to efficiently code for alternate scenarios ie when the continual process doesn't run smoothly. I have some code together but feel as though I could be doing things better and wondered how more experiences programmers deal with these scenarios. Also I am currently using a GuardLogix PLC but I am unsure when I should be using Safety routines? I'm fairly new to PLC programming so if you could keep replies as simple as possible that would be really good :) Thanks

Share this post


Link to post
Share on other sites
I've not used the Safety PLC's much, can yu program in Ladder in GuardLogix? If so can you indirectly address bits and words? I use an ISA-3A First Out Tracker that is very useful for tracking the event that stops the process. If you can indirectly address I'd be happy to share the program files with you. I've used it in Control Logix as well as SLC-500's.

Share this post


Link to post
Share on other sites
Thanks for your reply :) I'm not quite sure what you mean by ISA-3A? By indirectly addressing bits and words I figured you might be referring to alias tags? Yes you can program in ladder. The RSLogix5000 Interface using this PLC and Safety Partner (1756L61S and 1756LSP) appears exactly the same as using a non-safety PLC. Then again, my experience with diferent PLC's is very limited.

Share this post


Link to post
Share on other sites
All the usual forms of programming are supported with Guardlogix. The difference is in the hardware. Where in a normal safety operation you would rely on redundancy (a second control bank) Guardlogix has built in software that checks itself for faults so it is protected with diagnostics. This combined with the dual processor system that works by comparing the results of each individual processor running the same program and verifying the states of every bit, gives you an equivelant safety of a redundant control.

Share this post


Link to post
Share on other sites
When doing fault code I split up the faults into different action levels, Level 1 stops all processes, level 2 stops certain processes that are associated with the faults, level 3 and info messages to the operator and then I add in system hardware faults, these are faults that help the operator or tech diagnose the system. As for the safety routine, all functions that deal with the equipment safety goes in here. Gate monitoring E-stop functions, light curtains, and two hand starts are a few examples of different thing that might be in the safety task. An example of this would be if you had a motor running a piece of equipment and there is to be guard around the motor to insure no access is allowed in the area when in motion. In the task you would have the some type of feedback from the guards that would tell you that the guard had been removed, this would control a starter for the motor. If the signal from the guard was removed the motor started would turn off and stay off until the guard was put back in place. The idea is to place all parts of the machine that need to be at a safe state under certain conditions in this task, and use safety I/O with these functions. Keep in mind that while programming in the safety task, that task can only read and right to safety I/O and tags created in the program. No no-safety related tags and I/O can be read or written to. The normal program can read safety I/O and tags but cannot write to them. The last project I did using Guard Logix, I had four drives that I had to control speed and current, being that the drives speed reference and I/O could not be read or written to in the safety task though Ethernet, I had to wire digital I/O to the drive and tie them to safety I/O. I then controlled the I/O in the safety task and gave a status marker to from the safety program to the normal program to tell it when it was allowed to give speed references to the drive and allow the drives to run.

Share this post


Link to post
Share on other sites
Makes sense, thanks :) When you say that a fault can stop a process, how is this implemented? Is there a way to have a certain routine interrupt all other routines? Or would there need to be some sort of 'trigger' set to 0 or 1 depending on whether any faults were present, which would in turn enable/disable the routines containing the main process logic? Hope that makes sense! Thanks

Share this post


Link to post
Share on other sites
Most times I set the fault bit and then use that bit in the code that pertains to the function or the whole process. Another way I do it is I group the faults together on one or two DINT files that are for that function and then compare the word with zero. If the word is not EQU 0 then set a Fag to tell the rest of the program there is a fault active and to stop the function or process.

Share this post


Link to post
Share on other sites
Fantastic! Thanks for that. Seems logical :) Although if the word is not equal to 0 I'll set a 'flag' haha .....typo's can be humourous

Share this post


Link to post
Share on other sites
Sorry everyone for the typo, i messed up.

Share this post


Link to post
Share on other sites
Lol. I was only joking when I commented on it, I just found it funny as I read through it :) Thanks again for the help, massively appreciated!

Share this post


Link to post
Share on other sites
My first response should be that I mistyped the standard, it's ISA-F3A.I may have misunderstood the initial post. I'm talking about determining what alarm shut down the process. I get the feeling that you are working with a process that has to be systematically shut down, thus the need for a fault routine to safely back down a process. In my world when there is an alarm/fault we trip the whole system back to an immediate failsafe position. We don't need to sequence the stop. Regarding ISA-(F)3A, it's a standard written by the Instrument Society of America. There are acutally quite a few different annunciators mapped out in their "Annunciator Sequences and Specifications standard ISA-S18.1 (1979). I have not been able to find a newer book with the Standards and Practices for Instrumentation, the one I have is the sixth edition printed in 1980. I'm sure there are more recent copies, but the basics most likely have not changed. My biggest task is converting the ladder into a function block that can be used when the customers request all function block programming. I have not been able to find a pre-engineered add-on for control logix in cyber space. Anyone else ever have a need for one of these?

Share this post


Link to post
Share on other sites
It depends highly on the process. For me, there are various forms of this. Before you go anywhere with this, you need to do a risk assessment. The risk assessment will tell you that without any safe guards, what the possible consequence is, and what the probability of that consequence is. Then depending on the risk assessment method, you either set your own standard of an acceptable risk or it sets one for you. This is called a risk matrix. The way this works for instance is that if say there is a chance of a fatality but the chance of it happening is very low might be treated the same way as something where the consequence is a first aid case but the chance of it happening is extremely high. In both cases you may want to increase the level of safety in the process to lower that probability. The way that the probability comes about depends on the type of failure under consideration. Generally speaking, PLC's have very low failure rates in the first place, and wiring by itself without extenuating circumstances even less so. Sensors are a little more prone to failure, and most electromechanical actuators, whether valves, conveyors, pumps, or what have you, are relatively unreliable. There are a few different methodologies as well to determine risk. Markov modelling is the best and most accurate, but also extremely tedious and prone to all sorts of unknowns that have to be estimated in the equations. Fault tree analysis is a little more conservative and takes a "logic gate" type approach...basically you have all the faults and combinations of faults possible and do a cut-through analysis to calculate the overall probability. LOPA is the simplest in that you have essentially a lookup table approach. With LOPA since you don't take into account combinations of faults, it is very important that every single safety feature is independent of every other one. To give you an example with the SIL (safety integrity level system), I might have say a valve that has only a rating of SIL 0, but a safety rated valve might be SIL 1, and a combination of two valves in series (by the manufacturer's rating or via fault tree) might be rated SIL 2. A standard ControlLogix PLC and ladder logic is rated SIL 2 if implemented correctly (GuardLogix is needed for SIL 3). The layout of my IO, power, etc., is important to reach a rating over SIL 1. So the PLC might drive both valves in parallel and may have a SIL 2 rated sensor on the input side. Generally speaking, the safety logic needs to be independent of all other routines, and needs to have complete override control. To implement a LOPA type scheme, you would put in separate block valves, pumps, etc., that ONLY operate for a safety override and bring the process to an unconditionally safe state. With fault tree, you CAN mix process control which would allow for instance sharing of sensors and/or valves, BUT things get very complicated very quickly with this approach. In a GuardLogix PLC, you'd load the safety logic into safety ladders. Again, those rungs would use their own independent sensors and controls as a completely separate layer of the system that has the capability to 100% override the lower level basic control system. One of the big fallacies by the way with these things is that operators are between 35% and 90% reliable (SIL 1 or worse) depending on the situation (plenty of time to think and react, under little or no stress, eyes on task or something else, etc.). So any time that you require a HUMAN to be involved in the safety loop, for instance, hitting an E-Stop, the best you could ever hope for in the ideal situation is SIL 1. To even achieve this, that pretty much has to be their SOLE job function. You can't for instance be the operator running the process AND the one doing the safety function unless the process runs itself and the job of the human is to act as a second monitoring layer and shut it down if the control system does something incorrect. Anyways, so each SIL level corresponds to roughly a factor of 10 reduction in probability of the failure if implemented correctly. So you can reduce the probability with a ControlLogix PLC with no special coding by a factor of 10, by careful selection of equipment and implementation, by a factor of 100, and with GuardLogix, by a factor of 1000. Over a SIL 3, it becomes increasingly difficult to even do it. In those scenarios, a process redesign is almost always recommended.

Share this post


Link to post
Share on other sites
Some really interesting points there. Some that I hadn't even considered! I'll can see that I'll be referring back to this post in the future :) Thanks!

Share this post


Link to post
Share on other sites

As I stare out looking at my process. No drawings, no wire labels, 10 people " improved " it over the 15 years. Now asked to fix machine and integrate safety system, Sil3, catD. How much they ask, into the abyss we go. Ahh, should have stayed at GM 

Share this post


Link to post
Share on other sites

Man, that is some good advice.  And very thorough.

If you are stuck for generating a fault in a hurry, the most common practice is to use an overcycle timer.

Just run a dedicated fault timer with the timer enable based on monitoring your output (raise cylinder solenoid) and it's verifying input (cylinder raised prox switch).  Set your TON timer running when you set your output (raise cylinder solenoid) and cut the timer enable off when you get the input verifying the state change (cylinder raised prox switch).

Not just set an appropriate preset for the timer.  Should it take 2 seconds for your input prox to see the motion when you turn on your motion output?  Set your preset to 5 seconds.

Did your TON get a DN bit?  Latch on a fault bit.  Use the fault bit to halt your process as appropriate.

Edited by DataSurfer

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now