Activity
Mon
Wed
Fri
Sun
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
What is this?
Less
More

Memberships

Functional Safety Play Book

258 members • Free

5 contributions to Functional Safety Play Book
Trip and process valves
Hi all. I would like to hear everyone’s views and opinions on having one valve for control and one valve for safety, Or if they would have one valve that does both. If you have one valve what’s are your argument for, independence, CCF, and control system errors.
1 like • 24d
Hi @Tom Atkinson In my experience for similar scenarios we have always kept separate with one valve for safety and one valve for control. This mainly relates to independence requirements, for example, the LOPA takes credit for the BPCS closing the control valve, so the safety valve requires to be independent from this. Providing independence ok and no double credits being taken the standard does permit a single valve to be shared across safety and the BPCS, but not if failure of that component could place a demand upon the SIF. For example, an overfill valve being shared across both would not be allowed as failure of that shared valve could lead to an overfill scenario and place a demand upon the SIF. Separate to that if this is not the case then consideration would be for the types of valves in question. I have often come across scenarios where the modulating control valve is a globe valve and wouldn’t provide tight shut off (if this was required) that the ball valve would provide, so for this reason a separate valve was required. In relation to your other considerations such as control system related issues then providing no conflicts with any of the detail listed above (independence requirements, shut off type, etc) and the valve can be shared then this can be minimised by having the BPCS control signals to the valve positioner and the safety signal to the solenoid valve, so regardless of the BPCS command, the air to the valve would be shutoff and vented by the safety solenoid valve upon activation. I don’t believe CCF would apply even if two valves in this case as one would be for the BPCS and one safety, so either way with only one safety valve couldn’t be applied.
Shared components
Hi All. Just thought I would post in here to get others thoughts on a scenario I have come across recently. I know it’s best practice to avoid a single element being used in multiple SIFs, but are there any factors to take into consideration for the calculation. For example, several vessels have a common feed supply and whilst each have their own level sensor and logic solver, the common feed line overfill trip valve is shared for all vessels. Each SIF will have a calculation of all components, but all are actually using the same valve. My understanding is no common cause can really be applied as all have a 1oo1 output function. On another note, the configuration would also result in more demands on the valve with it being shared. Downtime and maintenance would also be impacted if shared. Again, just to get other thoughts on other factors that should be taken into account in this scenario. Thanks, Craig
0 likes • Mar 17
@Harvey Dearden Thanks for this input and sharing the book you have published on FS. Will look into getting this.
2 likes • Mar 17
@Tom Atkinson Thanks for the input Tom. Yes each vessel has a routing valve for level control as part of the BPCS (controlled from an LT). The overfill valve is independent from the BPCS and operated by the safety system if a vessel high level switch activates. Each tank has its own high level so 1oo1, but all shut the same overfill valve on the common supply line (upstream of the branch off to each vessel). That’s an interesting one you have mentioned. I think the key thing there, and my understanding as to how you have set it up now is the input side is only a 1oo1, and not a 1oo20 say, as whilst the same valves shut, each tank only has one level switch, so regardless of the other tank switches if that specific tank level rises only one level switch can respond to protect against an overfill scenario. I would also need to know more details on the scenario but just when you mentioned a separate valve for this purpose - I think that’s a key point in the LOPA. I have reviewed sites where they had one inlet valve that was shared between the BPCS and the safety system. They did have a separate safety relay to deenergise but ultimately the same valve and when referencing their LOPA credit had been taken for a BPCS high level trip. In this case not suitable and a modification to correct as not independent.
Mission Time
Hi all, thanks for accepting. First of all, I am new in functional safety and sorry for my bad english😊. Actually I have some doubt about one of variable in PFDavg calculation namely mission time, couple of question to all: 1. What will happen in the end of mission time?should end user decommissioned the plant?or just replace everything and the mission time will get restarted? 2. If it depend on end user, than based on what consideration usually for them to determine the correct mission time?and what is the reason behind that? 3. Since by the time PFDavg will get derated, and SIL claimed may decreased over the time, shouldn't end user decide to set the mission time before the SIL/RRF drops beyond the rating it should be? Hope you guys can share your knowledge. Thanks,
0 likes • Mar 16
@Iyan Putra Hi Iyan. I would just echo others comments here already in regard to the setting of the mission time and proof tests to ensure they are realistic to what the Asset will actually adhere to. It’s also got to make sense in terms of not just stating components will be replaced or overhauled to a new condition to improve the calculation. I noted above that a LOPA has been carried out and although no SIL requirement they still want to have safety rated trips. It’s very difficult to do this without really having a target as there are so many other factors that can be taken into account in addition to the mission time. Increasing proof tests and mission time can help with the calculation but it’s also more cost and effort involved when it may not actually be required. The system can then also be more costly to implement in terms of equipment and architecture selected in the design. Just thought I’d mention this when you noted the logic solver was SIL 3 capable as I have come across clients before that think buying SIL rated components make the given system SIL rated.
Proof test coverage
Something that always makes me pause when reviewing designs… Proof test coverage that somehow always ends up being 100% effective. On paper it looks great. The numbers work nicely. The SIL calculation passes comfortably. But in the real world I always find myself thinking: Can we really detecting every dangerous failure with that test? In my experience, this is a major cause of rework. If the design progresses to the point where commissioning documents are written and then a FSA or design review reveals overly optimistic proof test coverage it’s a lot of work to correct. Anyone else experiencing this?
1 like • Mar 7
I agree @Richard Kelly and have also come across this before when looking at PTC values used in calculations, particularly on the final element with valves. Quite often the proof test will check the actuator and valve physically move, but the proof test is carried out during a shutdown, so there would be no indication if the valve wasn’t sealing. Unless there was a flow and differential pressure across the valve being measured or an inline flow transmitter, then if carried out offline the proof test would never capture this. There is guidance for realistic values to use but have again come across some optimistic values edging towards 100%. Testing elements offline can also be very different to when the process is in operation at higher pressures and higher/lower temperatures.
Mentoring & Experience Sharing
One of the things I want this community to support is learning through experience, not just content. We have a mix of: - early-career engineers looking to build knowledge - more experienced practitioners and leaders who’ve seen projects succeed (and fail) I’ve created a Mentoring Discussion space for this. If you’re: - happy to offer occasional guidance or perspective → comment “mentor” - looking for guidance or career direction → comment “mentee” - open to either → comment “both” There’s no formal commitment here — this is about practical conversations, not long-term programmes. I’ll help connect people where it makes sense. If you’re unsure whether you’re “experienced enough” to mentor — you probably are.
0 likes • Mar 7
Both
1-5 of 5
Craig Berry
2
10points to level up
@craig-berry-3824
Lead E,C&I Engineer at IDEA

Active 17d ago
Joined Jan 28, 2026