Implementing an override on safety PLC

cardosocea

Member
Join Date
Nov 2016
Location
Fields of corn
Posts
2,622
Hello,

I have an application where I need to implement an override of a temperature trip. Essentially, this is a distillation column, but when running a boil-out cycle, the temperature has to be raised past the trip for normal operation.

Now, I've thought about wiring a key switch that when moved would increase the trip limit for a given time (2 hours) and once reset would require a 24 hour interval to allow the operation again. At the same time, if the override was active, the feed valves to the column would be closed shut.

The problem is that the nearest Safety IO is at a fair distance from the location where the switch would be installed and I was wondering if it would be possible to connect the switch to the nearest PLC which would transmit the status to the Safety PLC along with a watchdog bit and so on.

I have to run a risk assessment and get someone else to verify the design before changing anything, but would like your opinion on whether the network communication on this would be feasible or to disregard it straight off the bat and bite the bullet with a cable run?

Thanks in advance.

Edit: Forgot to say that this is running on a safety plc, not hardwired trip.
 
Last edited:
Sounds odd.

You sure the safety of the system is designed properly? What would protect the safety of the system during the boil-out?
 
You sure the safety of the system is designed properly? What would protect the safety of the system during the boil-out?

The change would raise the trip limit. So the SIS would work during boil out but on a higher level. This has to do with the material we usually feed it which won't be present in the boil out stage.

However, this means that an interlock on the override would need to be added to ensure that people didn't use the switch in operation.
 
If this is an HMI somewhere, connected to the SIS? But in a bypass that requires a UID and PWD, so there is traceability. When the bypass is enabled it interlocks the normal feed valve, and cannot be bypassed.

I still don't like it.
 
I have an application where I need to implement an override of a temperature trip. Essentially, this is a distillation column, but when running a boil-out cycle, the temperature has to be raised past the trip for normal operation.

Now, I've thought about wiring a key switch that when moved would increase the trip limit for a given time (2 hours) and once reset would require a 24 hour interval to allow the operation again. At the same time, if the override was active, the feed valves to the column would be closed shut.
That switch probably must be a safety switch with double contacts, and should go into a safety input on the PLC. If the risk assessment covers this, then it should be OK to implement.

The problem is that the nearest Safety IO is at a fair distance from the location where the switch would be installed and I was wondering if it would be possible to connect the switch to the nearest PLC which would transmit the status to the Safety PLC along with a watchdog bit and so on.
[..] would like your opinion on whether the network communication on this would be feasible or to disregard it straight off the bat and bite the bullet with a cable run?
For safety PLCs, a networked connection is as good as or even safer than a wired connection. The "watchdog" will already be a part of the safety PLCs connection to the safety input.

If you think about connecting the switch to regular inputs on the other PLC and then somehow transmit the information to the safety PLC, then that is a no-go.
There are safety PLCs that now support that two safety PLCs exchange safety signals, but I dont think that is what you are suggesting.

The safety inputs can be several 100 m away from the switch. The current / voltage drop is so low that it will not be a problem. Unless it is more complex, then it wont be worth the expense to place a remote safety PLC input station.
 
If this is an HMI somewhere, connected to the SIS? But in a bypass that requires a UID and PWD, so there is traceability. When the bypass is enabled it interlocks the normal feed valve, and cannot be bypassed.

I still don't like it.

The existing SCADA doesn't implement audit or even has a user login, so whilst that was my first thought I had to abandon it. The switch however will be a key switch that will be under permit control. So although not ideal, it's better than no control. I too don't like logic around trips, but the cleaning requires a higher temperature than is safe to run the process at.
It also beats the current alternative of removing the temperature probe from the column...

On what grounds is the limit decided? Does the safe temperature depend on the material inside the system?

The safe temperature depends on the material inside the system. To run a cleaning cycle, the temperature needs to be higher than what is used for the normal process.
 
That switch probably must be a safety switch with double contacts, and should go into a safety input on the PLC. If the risk assessment covers this, then it should be OK to implement.
Yes. I was thinking a NO and NC contact and both to be checked before allowing the process to run.

If you think about connecting the switch to regular inputs on the other PLC and then somehow transmit the information to the safety PLC, then that is a no-go.

This was my thinking hence the doubt on whether it could be implemented. I can see how it would be somewhat dependent on the logic created, but it doesn't account for any shenanigans in the communication which a safety PLC to safety PLC link will likely do.

Guess it's a new cable or position the switch elsewhere.


Thanks for the help.
 
I was wondering if it would be possible to connect the switch to the nearest PLC which would transmit the status to the Safety PLC along with a watchdog bit and so on.

I have to run a risk assessment and get someone else to verify the design before changing anything, but would like your opinion on whether the network communication on this would be feasible or to disregard it straight off the bat and bite the bullet with a cable run?


There's nothing inherently unsafe about network communication. With Profisafe, the safety is all taken care of at the protocol level. The possibility of a network fault is considered so remote a possibility as to be ignored in the calculation, because the protocol already has the necessary checks in place. I assume CIP Safe is similar.



Hypothetically, could it be safe? Maybe, but you'd have to get it certified yourself. You'd be way away from your vendors certification at that point. It'd cost way more in paperwork and engineering to do the unsafe PLC to safety PLC comms the "right" way than it would to just run the cable, or add a remote safety device near the IO.


Just run the cable.
 
cardosocea,

this is my opinion due to my recent work in hazardous locations.

the process is a distillation process, ok.
distillation of what?
what is the area classified as before, during, and after production?
what is the area inside the distillation process classified as before the boil out?
do you need any time delays to clear excess fumes/gases?
what are the upper and lower concentration level limits?
what are the residual gas levels before the boil out process?
will the boil out process interfere or cause the process system to be compromised in any way?
if you close the valves to the process as you state, will the chemicals / gases corrupt the next process after the boil out?

you must look at the entire process from start to finish and after the process is finished before doing the boil out for possible issues.

I do not know your process, but having worked in a class 1 div 1,2 area for over 5 years, I have learned to ask lots of questions.
james
 
Last edited:
There's nothing inherently unsafe about network communication. With Profisafe, the safety is all taken care of at the protocol level. The possibility of a network fault is considered so remote a possibility as to be ignored in the calculation, because the protocol already has the necessary checks in place. I assume CIP Safe is similar.

Yes, but I was thinking of a comms between non-safe PLC to safe PLC.

this is my opinion due to my recent work in hazardous locations.

the process is a distillation process, ok.
distillation of what?
what is the area classified as before, during, and after production?
what is the area inside the distillation process classified as before the boil out?
do you need any time delays to clear excess fumes/gases?
what are the upper and lower concentration level limits?
what are the residual gas levels before the boil out process?
will the boil out process interfere or cause the process system to be compromised in any way?
if you close the valves to the process as you state, will the chemicals / gases corrupt the next process after the boil out?

you must look at the entire process from start to finish and after the process is finished before doing the boil out for possible issues.

I do not know your process, but having worked in a class 1 div 1,2 area for over 5 years, I have learned to ask lots of questions.
james

As explained above, this is currently done now... but to overcome the trip, the temperature probe is removed from the column.
I'm afraid I can't say what the material being distilled is and there won't be any installation in a hazardous area.
 
Yes, but I was thinking of a comms between non-safe PLC to safe PLC.
A non-safety PLC cannot be part of a safety solution. Also, non-safety inputs cannot be part of the essential safety solution, even if they are in a safety PLC.
edit. In the typical safety PLC program, you simply cannot connect safety functions to non-safety inputs. However, you can still create something that is principally wrong, such as connecting non-safety devices to safety inputs. In that case the safety PLC program cannot know that you are using non-safety devices. However, the next step is to validate the safety, and it will fail.
When you validate the safety (for example with Sistema), you must take all the devices in the safety into account. Some things such as contactors can be used because you can get or assume a MTTFD or B10D values that can go into the formula for calculating the achieved Performance Level. For things like regular relays and PLCs you cannot get a MTTFD or B10D, and thus the safety validation fails.

I am thinking that the switch in question must be a key-switch that traps the key when it enables the override. And the key must be a specially ordered key with a unique encoding. Only 1 (one) key with the encoding must exist, and when not used in the switch the key must be in the hands of a specially trained person.
 
Last edited:
A non-safety PLC cannot be part of a safety solution. Also, non-safety inputs cannot be part of the essential safety solution, even if they are in a safety PLC.
edit. In the typical safety PLC program, you simply cannot connect safety functions to non-safety inputs. However, you can still create something that is principally wrong, such as connecting non-safety devices to safety inputs. In that case the safety PLC program cannot know that you are using non-safety devices. However, the next step is to validate the safety, and it will fail.
When you validate the safety (for example with Sistema), you must take all the devices in the safety into account. Some things such as contactors can be used because you can get or assume a MTTFD or B10D values that can go into the formula for calculating the achieved Performance Level. For things like regular relays and PLCs you cannot get a MTTFD or B10D, and thus the safety validation fails.

I am thinking that the switch in question must be a key-switch that traps the key when it enables the override. And the key must be a specially ordered key with a unique encoding. Only 1 (one) key with the encoding must exist, and when not used in the switch the key must be in the hands of a specially trained person.

There should be a way to also prevent startup of the potentially dangerous process if the key is in wrong position.
 
There should be a way to also prevent startup of the potentially dangerous process if the key is in wrong position.
One way could be to have two key-switches for the same key. Each enabling one of the two modes. It is called trapped key with key interlock (*). But that would cause a state of none of the modes being enabled for the time that you transport the key from one switch to the other, so you cannot have a change-over without stopping. I think that is not acceptable for cardosocea.

I think that this is a case where there must be a specially trained and authorized operator that can be entrusted with the key. And extra signalling.

*: And then it is absolutely critical that only 1 key exists with the particular encoding. We use a system like this.
 

Similar Topics

Hello, I have a project where I need to use a CLX to communicate with a 3rd party device that exchanges data via XML formatted commands and HTTP...
Replies
4
Views
1,656
Hello All, I am working on designing a new HMI interface using InTouch. Now I want to implement an easter egg but it's becoming quite arduous...
Replies
6
Views
1,921
Hi all, For the sake of organization and consistency would it make sense to group devices found in the unit's control panel (E-stop/safety...
Replies
4
Views
1,926
Here is a post that will assist in implementing the Omron CX Server DDE. Utilizing the CX Server DDE Manager will allow us to provide a link to...
Replies
0
Views
2,552
I have put together a post to read memory areas from the Omron PLC using VBA. This is a serial communication using (Sysmac Way) Host Link...
Replies
0
Views
2,905
Back
Top Bottom